Computing-Aware 5G Edge Enhancement

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 . 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.

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 , 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.

| EAS | : +-----+ : | (1 or More) | : | UPF | : \ / : |L-PSA|(N6)-------:----\---------/ : +-----+ : ..................................... ]]>

EAS: Edge Application Server, a server offering application services and residing in an edge DN.
EHE: Edge Hosting Environment, an environment providing support required for EAS's execution.
UPF: User Plane Function, supporting routing functionalities (similar to an IP-domain router).

Recently, the 3GPP 5G Rel-19 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.

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:

network metrics, such as bandwidth, latency, etc.
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 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 , 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.

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.

Network Metric: The 5G eEdge 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 has designated a SMF to manage the selection of the optimal UPF (from all candidate UPFs, e.g., UPF-1, …, UPF-m as in ) and the best EAS (from all instances, e.g., EAS-1, …, EAS-n as in ) 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 and the AF-influenced procedure as in the clause 4.3.6 of ). 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, OWAMP, OWAMP, etc.

There is no security concern.

There is no IANA requirement.