Content for  TS 23.548  Word version:  19.0.0

Edge Relocation refers to the procedures supporting EAS changes and/or PSA UPF relocation. Edge Relocation may be triggered by an AF request (e.g. due to the load balance between EAS instances in the EHE) or by the network (e.g. due to the UE mobility). With Edge Relocation, the user plane path may be re-configured to keep it optimized. This may be done by PDU Session re-establishment using SSC mode 2/3 mechanisms or Local PSA UPF relocation using UL CL and BP mechanisms. The corresponding procedures are defined in TS 23.501 and TS 23.502. Due to Edge Relocation, the UE may need to re-discover a new EAS and establish the connectivity to the new EAS to continue the service. The re-discovery of EAS is specified in clause 6.2. Edge Relocation may result in AF relocation, for example, as part of initial PDU Session Establishment, a central AF may be involved. However, due to Edge Relocation another AF serving the Edge Applications is selected. The trigger of Edge Relocation by the network is specified in clause 4.3.6.3 of TS 23.502. Some EAS (re-)Discovery procedures in clause 6.2 may also trigger Edge Relocation. This clause further describes the following procedures:

• Edge Relocation involving AF change.
• Edge Relocation using EAS IP replacement.
• AF request for simultaneous connectivity for source and target PSA.
• Packet buffering for low Packet Loss.
• Edge Relocation considering User Plane Latency Requirements.
• Edge Relocation triggered by AF
• Edge Relocation for a set of UEs for common DNAI.

Annex F describes example procedure for EAS Relocation on Release 16 capabilities. For non-roaming PDU Session, the 5GC functions in the following clauses are located in the HPLMN. For LBO roaming PDU Session, the 5GC functions in the following clauses are located in the serving VPLMN. For HR-SBO PDU Sessions specified in clause 6.7, the AF may send to V-NEF an AF request to influence traffic routing as described in clause 4.3.6 of TS 23.502 for supporting Edge Relocation (e.g. for the purpose of subscription to UP path management events, especially for the change of local PSA UPF in VPLMN). In this case, the steps involving PCF in the following clauses are skipped.

This clause is related to scenarios where distributed Edge Application Server (EAS) deployed in local part of a Data Network or a central AS are relocated, and where the (E)AS relocation also implies AF relocation i.e. AF instance change. Application Function influence on traffic routing mechanism as described in clause 5.6.7 of TS 23.501 can be applied for a relocation of the AF. In the case that AF sends AF request via NEF, the target AF may invoke Nnef_TrafficInfluence_Create to deliver the relocation related information, including notification target address based on the procedure described in clause 4.3.6.2 of TS 23.502. Also, the source AF or target AF may invoke Nnef_TrafficInfluence_Update service operation to deliver the relocation information, including AF ID and notification target address based on the procedure described in clause 4.3.6.2 of TS 23.502. Also if the AF relocation occurs during the early/late notification procedure described in clause 4.3.6.3 of TS 23.502, the target AF invokes Nnef_TrafficIfluence_Create/Update at step 4e-a or Npcf_PolicyAuthorization_Create at step 4g-a to deliver the notification target address of the AF. In the case that AF directly interacts with PCF, the target AF may invoke Npcf_PolicyAuthorization _Create, or the source AF/target AF may invoke Npcf_PolicyAuthorization _Update service operation to deliver relocation information including notification target address based on the procedure described in clause 4.3.6.4 of TS 23.502. In the case of Edge relocation between two DNAI(s), an AF relocation may be triggered by SMF, e.g. due to UE mobility. In such cases, the SMF provides as described in clause 4.3.6.3 of TS 23.502 during early/late notification procedure the source AF with target AF ID as defined in Table 6.2.3.4-1. Target AF ID is used by source AF to communicate with the target AF.

EAS IP replacement enables the Local PSA UPF to replace the source/old Target EAS IP address and port number with the target/new target EAS IP address and port number for the Destination IP address and Destination Port number field of the uplink traffic and replace the target/new target EAS IP address and port number with the source/old Target EAS IP address and port number for the Source IP address and Source Port number field of the downlink traffic based on the enhanced AF Influence information for EAS IP replacement (i.e. source EAS IP address and port number, target EAS IP address and port number). The source AS IP address and port number are the destination IP address and port number of the uplink traffic, generated by UE, for a service subject to Edge Computing. The source EAS IP address is the one discovered by UE for a service subject to Edge Computing. To support Edge Relocation using EAS IP address and Port number replacement, in this clause the SMF shall instruct the UPF to use the FAR that contains Information elements of "IP Address and Port Number Replacement". EAS IP replacement requires support of TCP/TLS/QUIC context transfer between EASs.

EAS relocation can make use of network capabilities that, at PSA change, provide simultaneous connectivity over the source and the target PSA during a transient period. This is described in Annex F. AF may issue a request to the network on whether to provide simultaneous connectivity over the source and the target PSA at edge relocation. This may trigger the SMF to use a re-anchoring procedure that provides simultaneous connectivity over the source and target PSA, as described in TS 23.502:

• For Session Breakout, in clause 4.3.5.7 for Simultaneous change of Branching Point or UL CL and additional PSA for a PDU Session. This could involve the establishment of a temporary N9 forwarding tunnel between the source UL CL and target UL CL.

The AF request may include the following information:

• "Keep existing PSA" indication: If this indication is included, the SMF may decide to use a re-anchoring procedure that provides simultaneous connectivity over the source and target PSA, as described above.
• "Keep existing PSA timer": its value indicates the minimum time interval to be considered for inactivity for the traffic described. It may overwrite the SMF configurable period of time for how long the existing PSA is to be maintained after all active traffic ceases to flow on it.

AF traffic influence request via NEF is described in clause 5.2.6.7 of TS 23.502. The request to PCF is described in clauses 5.2.5.3.2 and 5.2.5.3.3 of TS 23.502. Once the simultaneous connectivity over the source and the target PSA at relocation requested by AF is authorized by the NEF, the AF request including the requirements is informed to the SMF via AF influenced Traffic Steering Enforcement Control (see clause 6.3.1 of TS 23.503) in PCC rules. If SMF determines that simultaneous connectivity over the source and the target PSA at relocation is not possible (e.g. the PDU Session is neither session breakout nor SSC mode 3) while it is requested, the SMF issues a failure notification towards the AF.

This procedure aims at synchronizing between EAS relocation and UL traffic from the UE, ensuring that UL traffic from the UE is sent to the new EAS only when EAS context transfer has been carried out. This procedure may be applied at change of local PSA. It consists of buffering uplink packets in the target PSA in order to prevent there is packet loss if the application client sends UL packets to a new EAS before the new EAS is prepared to handle them. During the buffering, the old EAS may continue to serve the UE over the former PSA. Buffering starts upon request by AF and continues till AF indicates otherwise. The EAS relocation procedure (e.g. the migration of the service context) happens at the application layer. That is outside the scope of 3GPP. As an alternative to this procedure, upper layer solutions can provide the needed synchronization between EAS relocation and UL traffic from the UE. Buffering of uplink packets is not meant to apply to all traffic being offloaded at the new PSA. AF may request the buffering for the UL traffic of applications that require so. When the AF subscribes Early/Late Notification of UP path change for a specific application, Traffic Description for this application is provided as described in clause 5.6.7 of TS 23.501. When AF receives such an Early/Late Notification and indicates that uplink traffic buffering is needed in the response (step 2 in Figure 6.3.5-1), this uplink traffic buffering is then activated for the traffic described by Traffic Description provided in the subscription to Early/Late Notification.

Edge relocation may be performed considering user plane latency requirements provided by the AF. In a network deployment where the estimated user plane latency between the UE and the potential PSA-UPF is known to the SMF, the 5GC provides the enhancement of AF influence to consider the user plane latency requirements requested by the AF so that the SMF decides to relocate the PSA-UPF based on AF requested requirements. The AF may provide user plane latency requirements to the network via AF traffic influence request as described in clause 5.2.6.7 of TS 23.502. The user plane latency requirements may include the following information:

• Maximum allowed user plane latency: The value of this information is the target user plane latency. The SMF may use this value to decide whether edge relocation is needed to ensure that the user plane latency does not exceed the value. The SMF may decide whether to relocate the PSA UPF to satisfy the user plane latency.

The AF request on the user plane latency requirements are authorized by PCF. The PCF checks whether the AF has an authority to make such a request. Once the user plane latency requirements requested by AF is authorized by the PCF, the AF request including the requirements is informed to the SMF via AF influenced Traffic Steering Enforcement Control (see clause 6.3.1 of TS 23.503) in PCC rules. After receiving the user plane latency requirements from AF via PCF, the SMF may take appropriate actions to meet the requirements e.g. by reconfiguring the user plane of the PDU Session as described in the step 6 of Figure 4.3.6.2-1 in TS 23.502 with the following considerations:

• In the case that the maximum allowed user plane latency is requested, the SMF decides not to perform PSA UPF relocation if the serving PSA satisfies the maximum allowed user plane latency. Otherwise, the SMF may decide to perform PSA UPF relocation if the target PSA UPF satisfies the maximum user plane latency. The SMF may select the PSA UPF with the shortest user plane latency among the PSA UPFs satisfying the maximum user plane latency requirements.

The AF may invoke the AF request targeting an individual UE address procedure as described in clause 4.3.6.4 of TS 23.502, due to EAS relocation. The EAS relocation may be due to AF internal triggers e.g. EAS load balance or maintenance, etc. or due to UP path change notification from SMF. The EAS relocation may include AF change or AF not change. The EAS relocation can happen with or without DNAI change. The AF may include the following information: Indication for EAS Relocation, target DNAI, traffic descriptor information and N6 routing information at target DNAI in the Nnef_TrafficInfluence_Create/Update Request to the NEF, or Npcf_PolicyAuthorization_Create/Update Request to the PCF. When the PCF receives an AF request for the same application, then the latest AF request message take precedence over any previous request if the traffic descriptor information is same. The AF may invoke the AF request targeting a set of UEs as described in clause 4.3.6.2 of TS 23.502, due to change of common EAS/common DNAI used by the set of UEs. Similar as the Edge relocation triggered by AF with target DNAI, the common DNAI is included instead of the target DNAI.