Internet-Draft CATS 5G Edge Enhance October 2024
Jiang Expires 12 April 2025 [Page]
Workgroup:
CATS Working Group
Internet-Draft:
draft-jiang-cats-usecase-5gedge-00
Published:
Intended Status:
Informational
Expires:
Author:
T. Jiang
China Mobile

Computing-Aware 5G Edge Enhancement

Abstract

This draft illustrates a computing-aware use case that is based on the study conclusion of the 3GPP 5G enhanced Edge Computing (eEdge). This use case takes into acount both network and computing metrics upon selecting edge application server (EAS) and user plane function (UPF).

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."

This Internet-Draft will expire on 12 April 2025.

Table of Contents

1. Introduction

3GPP 5G Edge Computing & its successive enhancements, i.e., eEdge, standardize reference architectures, connectivity models along with edge hosting envivorments (or EHE), etc., so as to enable operator and/or 3rd party services to be hosted close to an end device's (i.e., end user or UE) access point of attachment [TS.23.501][TS.23.548]. The eEdge service achieves an efficient service delivery through the reduced end-to-end latency and load on the transport network. Edge application servers, or EAS'es, are deployed in corresponding (edge) domain networks (DNs) that are connected via the N6 interface of a (PSA) UPF. A DN may be under the control of either the operator or 3rd parties.

1.1. 5G Enhanced Edge Architecture

A 5GC can select either a UPF according to provided traffic steering rules, or an EAS based on 'holistic better metrics', etc., and then forward traffic to enable the optimal access to the DN via a N6 interface. This may be based on the UE's local settings, the measured or collected EAS (or edge application server) runtime information, network policy or other related traffic rules. As shown in the Figure 1, either the C-PSA UPF or the L-PSA UPF could be optimally selected to foward the UE (uplink) traffic to an EAS with the better (or even the best) 'holistic' metrics.

     C-PSA: Central PSA UPF      L-PSA: Local PSA UPF
     DL: Downlink direction      UL: Uplink direction
     ULCL/BP: Uplink Classifier/Branch Point
     EAS: Edge App Server in Data Domain (DN)

     .....................................
     :         [-- 5G Core --]           :
     :       /  |        |               :
     :     N1   N2       N4              :
     :    /     |        |               <== DL
     :   /      |     +-------+  +-----+ :
     +----+  +-----+  |  UPF  |  | UPF | :    /---------\
     | UE |--| gNB |--|ULCL/BP|--|C-PSA+(N6)-/    DN or  \
     +----+  +-----+  +-------+  +-----+ :  |DN:local-part|
     :                    |              :  |             |
     :                    |          UL==>  |    EAS      |
     :                 +-----+           :  | (1 or More) |
     :                 | UPF |           :   \           /
     :                 |L-PSA|(N6)-------:----\---------/
     :                 +-----+           :
     .....................................

Figure 1: 5G Edge-Computing Architecture

1.2. Definitions of Terms

2. Computing-aware 5G Enhanced Edge (eEdge)

Recently, the 3GPP 5G Rel-19 [TR.23.700-49] studied how to effectively and optimally select (local) UPFs in 5G CN (Core Network) and EAS'es residing in DN (or edge hosting environment) with the consideration of the N6 (transport) delay between (local) PSA UPFs and EAS'es, and, possibly, the computing capabilities, e.g., compute power, memory, runtime load, storage, etc., of EAS'es.

2.1. EAS & Local-UPF Optimized Selection in 5G eEdge

The 5G enhanced Edge (or eEdge) explores to discover one suitable EAS to handle an edge application that can be served by multiple EAS'es deployed in different sites (i.e., DNs or local DNs). The suitability of an EAS is dependant on both of the following:

  1. network metrics, such as bandwidth, latency, etc.
  2. compute metrics or computing capabilities, such as processing power, storage capacity, AS load, etc.

Evidently, the integration of both network & compute metrics conform to the scope of the CATS charter.

The 3GPP 5G eEdge document [TR.23.700-49] provides a couple of 5G specific scenarios to justify the requirement. For example, when some of the available transport links in DNs get congested, a UE moves aways from the original location (very common in mobile network), or excessive load builds up on EAS(es), then a previously 'better-optimized' EAS may become less preferable, and thus a new EAS and/or local-PSA UPF need to be selected based on the weighted optimization of nework and compute metrics. The 5G eEdge emphasizes particularly on considering the EAS load and the end-to-end delay off the N6 interface between a local PSA and a candidate EAS residing in a (local) DN.

In the Figure 2, the UPF-1 to UPF-m indicate 'm' local PSA UPFs, all of which could fulfill an applicaiton service (AppService) to the UE (on the left side of the figure). The AppService is provisioned in multiple EAS'es that reside in remote DN(s) or local DN(s), denoted as EAS-1 to EAS-n. The selection of UPF and EAS may depend on both the N6 delay and EAS load.

     C-PSA: Central PSA UPF
     UPF-x(L-PSA): the x-th Local PSA UPF, x=1...m
     EAS-y: the y-th Edge App Server in DN, y=1...n
     DL: Downlink direction      UL: Uplink direction

     .....................................
     :         [-- 5G Core --]           :
     :       /  |        |               :
     :     N1   N2       N4              :
     :    /     |        |               :
     :   /      |     +-------+  +-----+ :
     +----+  +-----+  |  UPF  |  | UPF | :    /---------\
     | UE |--| gNB |--|ULCL/BP|--|C-PSA+(N6)-/    DN or  \
     +----+  +-----+  +-------+  +-----+ :  |DN:local-part|
     :                    |              :  |  --------   |
     :                    |              :  |   [EAS-1]   |
     :               +------------+      :  |             |
     :               |UPF-1(L-PSA)|(N6)-----|   [EAS-2]   |
     :               +------------+      :  |      .      |
     :                  ......           :  |      .      |
     :               +------------+      :  |      .      |
     :               |UPF-m(L-PSA)|(N6)-----|   [EAS-n]   |
     :               +------------+      :   \           /
     ....................................:    \---------/

Figure 2: CATS-aware 5G eEdge Use Case

2.2. Integrating 5G eEdge w/ CATS

This subsection shows how to implement the computing-aware 5G eEdge via mappings to CATS functional componenents, e.g., C-PS, C-NMA, C-SMA, etc.[CATS.Framework]

  • Network Metric: The 5G eEdge [TR.23.700-49] has concluded to integrate into the UPF/EAS optimized selection the end-to-end N6 delay over the transport network between (local) PSA UPFs and EAS'es.
  • Compute Metric: Load of EAS(es) located in (local) DNs. While it has been explored during the study phase of the 5G eEDGE, the conclusion is to leave it for further integration (e.g., in 6G).
  • SMF => C-PS: As of now, the 5G eEdge [TR.23.700-49] has designated a SMF to manage the selection of the optimal UPF (from all candidate UPFs, e.g., UPF-1, …, UPF-m as in Figure 2) and the best EAS (from all instances, e.g., EAS-1, …, EAS-n as in Figure 2) based on the network metric (i.e., the end-to-end N6-delay). Please note that the 5G eEdge conclusion leaves the normative extension for a SMF helping (UPF) select the best EAS potentially based on EAS-load to a future release (e.g., Rel-20 or beyond).
  • C-NMA, C-SMA: The combined functionalies of AF & SMF make it a C-NMA (according to both [TR.23.700-49] and the AF-influenced procedure as in the clause 4.3.6 of [TS.23.502]). However, thanks to the non-inclusion of the EAS-load metric, how to map C-SMA is un-determined now, which is probably for future extension.
  • Delay-measuring off N6 interface: The 5G eEdge proposes to leverage the existing IETF protocols & mechanisms, e.g., ICMP[RFC792], OWAMP[RFC4656], OWAMP[RFC5357], etc.

3. Security Considerations

There is no security concern.

4. IANA Considerations

There is no IANA requirement.

5. References

5.1. Normative References

[CATS.Framework]
Li, C., et al., "A Framework for Computing-Aware Traffic Steering (CATS)", draft-ietf-cats-framework, .
[RFC4656]
Shalunov, S., Teitelbaum, B., Karp, A., Boote, J., and M. Zekauskas, "A One-way Active Measurement Protocol (OWAMP)", RFC 4656, DOI 10.17487/RFC4656, , <https://www.rfc-editor.org/info/rfc4656>.
[RFC5357]
Hedayat, K., Krzanowski, R., Morton, A., Yum, K., and J. Babiarz, "A Two-Way Active Measurement Protocol (TWAMP)", RFC 5357, DOI 10.17487/RFC5357, , <https://www.rfc-editor.org/info/rfc5357>.
[RFC792]
Postel, J., "Internet Control Message Protocol", STD 5, RFC 792, DOI 10.17487/RFC0792, , <https://www.rfc-editor.org/info/rfc792>.
[TR.23.700-49]
"3GPP TR 23.700-49 v19.0.0: Study on Enhancement of support for Edge Computing in 5G Core network; Phase 3", 3GPP TR 23.700-49, .
[TS.23.501]
"3GPP TS 23.501 (V19.0.0): System Architecture for 5G System; Stage 2", 3GPP TS 23.501, .
[TS.23.502]
"3GPP TS 23.502 (V19.0.0): Procedures for the 5G System; Stage 2", 3GPP TS 23.501, .
[TS.23.548]
"3GPP TS 23.548: 5G System Enhancements for Edge Computing; Stage 2", 3GPP TS 23.548, .

5.2. Informative References

Author's Address

Tianji Jiang
China Mobile