In Edge Computing deployment, one application service might be served by multiple Edge Application Servers typically deployed in different sites. These multiple Edge Application Server instances that host same content or service may use a single IP address (anycast address) or different IP addresses. Before an application/UE starts to connect to the service, it is very important for the application/UE to discover the IP address of one suitable Edge Application Server (e.g. the closest one), so that the traffic can be locally routed to the Edge Application Server via UL CL/BP mechanisms, and service latency, traffic routing path and user service experience can be optimized. Also once a discovered Edge Application Server becomes non-optimized (e.g. after the UE moves far away), a new Edge Application Server may be used to replace the old one to serve the application/UE. The reselection of an Edge Application Server can be triggered by events either in the 5GS or in the application layer. For example, in the first case it can be triggered by a User Plane change initiated by the network such as a mobility event (e.g. handover), or a failure event which ultimately is a 5GS criterion. In the second case it can be initiated due to an Edge Application Server may become congested or unavailable. This requirement depends on whether the application can tolerate a change of Application server instance. The following aspects shall be studied to support the efficient discovery of Edge Application Sever:

• How can a UE discover a suitable Edge Application Server to serve the application/UE?
• Consider scenarios (if any) for which the UE needs to be aware that there is an application server in the Edge Hosting Environment and scenarios (if any) for which the UE does not need to be aware that there is an application server in the Edge Hosting Environment.
• What information (if any) can be used to assist such a discovery mechanism?
• What (if any) additional information may need to be discovered about the EAS through such a discovery mechanism?
• Whether and if yes how to support UE rediscovery of Edge Application Server when the previous Edge Application Server becomes non-optimal or unavailable to the UE?
• Whether the need to ensure the discovery of Edge Application Server and PSA UPF selection and reselection are jointly carried out? If so, how?
  • The MNO is in control of the edge and provides the edge computing infrastructure, the connectivity and the application platform, and manages the Edge Application Servers.
  • The MNO hosts its own or a 3rd party application platform on its edge computing infrastructure. MNO provides the routing and IP network stitching between the connectivity and the platform which exposes APIs for application management.
  • The MNO provides distributed connectivity to a DN, and cloud providers host the application servers on their application platform on the edge.

If the solutions to this key issue use DNS the following aspects should also be considered:

• How can DNS resolution take into account different PSAs for different applications?
• Does the 5GC needs to assist the DNS resolution?

With edge computing being deployed for 5G systems, UE mobility and application server relocation need to be considered when designing solutions for optimal deployment of edge solutions. For example, as the UE moves across the 5G system, the UE location may change and require the network and the edge to deal with the change of UE location. 3GPP Rel-16 specifications already address some of these aspects and the key issue is to study potential improvements. Clause 6.5.2 of TS 22.261 contains requirements that are related to this key issue. SA WG1 defined the term Service Hosting Environment that has been translated and broadened in SA WG2 work in the present TR to Edge Hosting Environment as the environment providing support required for Edge Application Server's execution. The requirements from SA WG1 are thus being interpreted as applying to the Edge Hosting Environment. The following scenarios of UE mobility and application server relocation will be investigated:

• Change of the serving Edge Application Server with no change of DNAI. This includes:
• Change of the Edge Application Server e.g. due to the serving Edge Application Server becoming congested or being in outage condition. This assumes EAS IP address change.
• Change of the DNAI depending on the location of the UE to better serve the UE. This may imply EAS IP address change but in some cases the old EAS may be kept as long as the UE transaction is not over.

The following scenarios of UE mobility and application service relocation will be investigated:

• Potential improvements of the coordination of change of the Edge Application Server and (local) PSA to support seamless change, e.g. preventing or reducing packet loss.

This key issue will study the following aspects in order to support service continuity:

• What triggers should be considered, and which functional entities trigger the changes to support service continuity for the scenarios described above.
• Whether existing SA WG2 mechanisms (e.g. ULCL/BP insertion/relocation, SSC mode 2/3, AF influence on traffic routing, and LADN) suffice or whether there are gaps to be addressed that could introduce improvements in Quality of Experience compared to existing solutions.
• How to handle changes of the (local) PSA when applications do not support the change of client address.
• How to handle change of the serving EAS (without UE mobility) to support seamless change, e.g. preventing or reducing packet loss.
• How to handle coordination of change of the Edge Application Server and PSA to support seamless change, e.g. preventing packet loss. This should consider the already specified mechanisms in clause 4.3.6.3 of TS 23.502 "Notification of User Plane Management Events".
• Evaluate and determine whether and how seamless change of Edge Application Server can be enabled considering:
  • Different Edge hosting models described in the key issue #1.
  • Stateful and Stateless applications.

With edge computing deployment, it is expected that a set of edge computing functions or edge application servers running on edge hosting environment will need to interact with the 5GS to access to 5GS functionality and information, and/or to provide information to 5GS for the provisioning of connectivity services supporting edge computing. The interaction for exposure of network information between the 5GS and the edge computing functions need to be studied. As part of the study, latency of network exposure needs to be considered. Current network exposure mechanism in 5GS is designed based on NEF and other control plane NFs, e.g. AMF, SMF, PCF etc. For applications deployed in edge hosing environments, the Edge Application Servers or Application Functions may be locally deployed, but in current Rel-16, some Control Plane NFs involved in network exposure, e.g. NEF and PCF, are likely deployed centrally to avoid frequently relocation. This may result in a less than efficient network exposure path in terms of latency. For some network information to be exposed, the long exposure latency is tolerable. However, some real time network information, e.g. network congestion condition or real-time user path latency, can change very frequently. If this information needs to be delivered to Application servers or Application Functions timely, undesirable latency may make the information obsolete cause applications to adjust their behaviour (e.g. adjust the resolution of video stream, or switch levels of driving automation) based on out-of-date network information. Examples of existing QoS information that may need to be exchanged quickly between network and Application Functions (e.g. Edge Application Servers) include:

1. The AF may subscribe to receive QoS congestion condition notifications.
2. The AF may request 5GC to monitor QoS status (e.g. over-the-air and/or end-to-end data path) and receive QoS measurement reports.

This key issue addresses exposure of information to Application Functions deployed in the edge (e.g. Edge Application Servers), including:

• Which information that have already existed in Rel-16 needs to be exposed with low latency to the edge computing functions by the 5GS?
• How does the 5GC determine whether a network information need to be exposed with low latency?
• How to expose the network information to the application functions deployed in the edge with low latency?
• Whether and how to maintain the exposure when the UE moves out of the coverage of NF(s) supporting the exposure?

For some of edge computing use case scenarios, although Application Servers are deployed in the local N6-LAN, centralized deployed Application Server(s) may still be required for other processing. In such edge computing scenarios:

• UL traffic related to an application may be first steered over local N6-LAN to Application Server(s) for local-processing, and then further steered to the central Application Server(s).
• DL traffic related to an application may be first routed via Application Server(s) in the central N6-LAN, then steered to Application Server(s) in local N6-LAN for local-processing, and finally provided to the UE.

1. The following aspects will be studied in this key issue:
   • How to steer application traffic for processing at different locations (e.g. at the local Application first and then at the central application server(s)/or UE, or at the central application server first and then at the local application server), e.g. via DN/internet, back via the 5GC or using multiple PDU sessions.
2. Depending on the architecture for the item 1) above:
   1. Whether and how is the 5GC made aware that (UL/DL) application traffic needs to be processed via the local N6-LAN and the central N6-LAN;
   2. How to provide the 5GC with information about service functions in N6-LAN (both local and central) that application traffic needs to travel through, e.g. service function order and location;
   3. How can local 5GC NF(s) distinguish the UL traffic and the DL traffic that need to be processed via either the local N6-LAN or the central N6-LAN, or both.

Solutions defined for this key issue should consider:

• How to guarantee proper enforcement of the Policy Rules, QoS handling, Packet marking, packet buffering and rest of UPF functions.
• How to guarantee proper usage reporting for usage monitoring and charging.

In order to activate the traffic routing towards Local (access to) Data Network, the SMF should be configured with the requested DNAI. For ETSUN case, either SMF or I-SMF should be configured with the requested DNAI. For some of edge computing use case scenarios, the SMF or I-SMF of the PDU Session may not be configured with the requested DNAI. In this case the mechanism to activate the traffic routing towards the Local Data Network should be studied. The key issue aims at studying the following:

• Whether Rel-16 ETSUN solution is sufficient to support the use case above and if there is a gap.
• If Rel-16 ETSUN solution is not sufficient (there is a gap), study potential solutions on how to activate the traffic routing towards Local Data Network when the SMF does not support the requested DNAI, or for ETSUN case both SMF and I-SMF do not support the requested DNAI in the AF request.