6.3 Edge Relocation

23.5483GPP5G System Enhancements for Edge ComputingRelease 17Stage 2TS

Tools: ARFCN - Frequency Conversion for 5G NR/LTE/UMTS/GSM

6.3.1 General

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 [2] and TS 23.502 [3].

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 [3]. 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

Annex F describes example procedure for EAS relocation on Release 16 capabilities.

6.3.2 Edge Relocation Involving AF Change

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 [2] 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 [3]. 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 [3].

Also if the AF relocation occurs during the early/late notification procedure described in clause 4.3.6.3 of TS 23.502 [3], 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 [3].

6.3.3 Edge Relocation Using EAS IP Replacement

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.

EAS IP replacement requires support of TCP/TLS/QUIC context transfer between EASs.

NOTE: The feasibility of this requirement, i.e. TCP/TLS/QUIC context transfer between EASs, depends on whether third party platforms support an individual real time TCP/TLS/QUIC context transfer between EASs.

6.3.3.1 EAS IP Replacement Procedures

6.3.3.1.1 Enabling EAS IP Replacement Procedure by AF

Figure 6.3.3.1.1-1: Enabling EAS IP replacement procedure by AF

NOTE 1: This procedure covers the scenarios that the UE moves from non-EC to EC or the AF decides to enable the EAS IP replacement in the middle of a session.

1. UE requests to establish a PDU Session.

2. UE is preconfigured with the Source EAS IP address or discovers the IP address of the application server for the service subject to Edge Computing and the Source EAS IP address is returned to the UE via EAS Discovery procedure as described in clause 6.2.

3. UE communicates with the Source EAS.

4a. EAS Relocation may be triggered by AF (e.g. due to the load balance between EAS instances in the EHE). When AF detects that the EAS is capable of runtime context mirroring and an optimal EAS is found, then AF decides to influence the traffic routing in 5GC. The EAS IP replacement information (i.e. source EAS IP address and port number, target EAS IP address and port number) is sent to the SMF within the AF Influence information and the SMF reconfigures the UL CL UPF for local traffic routing and Local PSA with EAS IP replacement information.

UL CL is configured by SMF to forward UL packet to Local PSA if the destination IP address is the Source EAS IP address.

Local PSA is configured by SMF to enforce the "Outer Header Creation" and "Outer Header Removal" as described in step 5. FARs "Outer Header Creation" and "Outer Header Removal" are reused for such an instruction from SMF to UPF.

Detailed enhancement to the AF Influence procedure is described in clause 6.3.3.2.

If a new Local PSA is selected by SMF, the SMF may configure the new Local PSA to buffer the uplink traffic per clause 6.3.5 and enforce the "Outer Header Creation" and "Outer Header Removal" as described in step 5.

If AF is not notified by 5GC that the 5GC supports EAS IP replacement mechanism, the AF does not include the target EAS identifier and does not initiate the AF triggered EAS IP replacement procedure.

If the 5GC does not support EAS IP replacement capability, the SMF should reject the AF request and step 5 is skipped.

4b. EAS Relocation may be also triggered by 5GC (e.g. due to UE Mobility). When Early/Late Notification procedure with enhancement described in clause 6.3.3.2 is triggered, the SMF notifies AF about the target DNAI and may provide the capability of supporting EAS IP replacement in 5GC. Based on the target DNAI, the AF selects a proper target EAS, then the AF triggers to mirror the runtime context between Source EAS and Target EAS. Once the Target EAS is ready, AF responds to SMF about the EAS IP replacement information. During the addition or change of UL CL and Local PSA as described in clause 4.3.5.4, 4.3.5.6 or 4.3.5.7 of TS 23.502 [3], SMF may (re)configure Local PSA for EAS IP address replacement between Source EAS and Target EAS.

5. Local PSA starts to perform "Outer Header Creation" and "Outer Header Removal" FARs as instructed by SMF, which results in EAS IP address replacement:

– For UL traffic, the destination IP address and port number are replaced with the Target EAS IP address and port number;

– For DL traffic, the source IP address and port number are replaced back with the Source EAS IP address and port number.

NOTE 2: In this solution, the PSA UPF need not to understand the logic of EAS IP replacement.

Then all subsequent uplink traffic of this EC service for this UE is forwarded to the target EAS.

NOTE 3: AF decides when and how to stop the Source EAS from serving the UE based on its local configuration.

6.3.3.1.2 EAS IP Replacement Update upon DNAI and EAS IP Change

Figure 6.3.3.1.2-1: EAS IP replacement update upon DNAI and EAS IP change

1. For UL traffic, the destination IP address is replaced with the old Target EAS IP address at Local PSA; for DL traffic, the source IP address is replaced back with the Source EAS IP address at Local PSA.

2. SMF configures Target UL CL with forwarding rules and Local PSA2 with FARs, as described in step 4 of clause 6.3.3.1.1.

Steps 3-4 are same as steps 5-6 described in clause 6.3.3.1.1 except that the UL CL, Local PSA and Target EAS in clause 6.3.3.1.1 are replaced by Target UL CL, Local PSA2 and new Target EAS respectively.

6.3.3.1.3 Disabling EAS IP Replacement Procedure

Figure 6.3.3.1.3-1: Disabling EAS IP replacement procedure

1. Local PSA performs "Outer Header Creation" and "Outer Header Removal" FARs as instructed by SMF, which results in EAS IP address replacement:

– For UL traffic, the destination IP address and port number are replaced with the old Target EAS IP address and port number;

– For DL traffic, the source IP address and port number are replaced back with the Source EAS IP address and port number.

2. Due to UE Mobility to a Non-EC environment, when Early/Late Notification is triggered for the change from the UP path status where a DNAI applies to a status where no DNAI applies, AF knows the UE moves out of EC environment and mirrors the runtime session context from old Target EAS to Source EAS. Once ready, the AF indicates SMF without providing source/target EAS IP addresses and port numbers, so the SMF disables the local routing at UL CL and the EAS IP replacement at Local PSA for this PDU Session.

3. UL and DL traffic goes through Remote PSA, no EAS IP address replacement happens at Remote PSA.

NOTE 1: AF decides when and how to stop the old Target EAS from serving the UE based on its local configuration. In case of AF relocation, AF doesn’t have to disable the EAS IP Replacement in 5GC.

6.3.3.2 Enhancement to AF Influence

The AF may additionally include Source and Target EAS IP address(es) and Port number(s) in the Nnef_TrafficInfluence_Create/Update or Nnef_TrafficInfluence_AppRelocationInfo or Nsmf_EventExposure_AppRelocationInfo request. Based on the Source EAS IP address(es) and Port number(s), the SMF knows which service flow(s) is(are) subject to EAS IP Replacement.

Using Early/Late Notification procedure, the SMF may notify the AF about the capability of supporting EAS IP replacement in 5GC, the AF sends an/a early/late notification response to the SMF when EAS relocation is completed. The SMF sends the "Outer Header Creation" and "Outer Header Removal" FARs to (target) Local PSA UPF and (target) Local PSA UPF starts the EAS IP address replacement as described in clause 6.3.3.1.

For load balancing purpose, the AF may move some UE(s) from the old Target EAS to the New Target EAS in the same L-DN identified by the DNAI. For the abnormal condition of EAS, the AF may move all the UEs being served by the source EAS to a target EAS in the same L-DN. For those purposes, the AF needs to include List of UEs, the source/old Target EAS IP address and port number for the impacted DNAI, the (new) Target EAS IP address and port number for the impacted DNAI in the Nnef_TrafficInfluence_Create/Update request. If 5GC does not support EAS IP replacement capability, the SMF should reject this AF request.

The additional parameters for enabling the EAS IP Replacement are defined in clause 5.6.7.1 of TS 23.501 [2] and clauses 4.3.6.3 and 4.3.6.4 of TS 23.502 [3].

6.3.4 AF Request for Simultaneous Connectivity over Source and Target PSA at Edge Relocation

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 [3]:

– 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 [3]. The request to PCF is described in clauses 5.2.5.3.2 and 5.2.5.3.3 of TS 23.502 [3]. The AF request for simultaneous connectivity over the source and the target PSA at relocation is authorized by PCF. The PCF checks whether the AF has an authority to make such a request.

Once the simultaneous connectivity over the source and the target PSA at relocation 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 [4]) in PCC rules.

6.3.5 Packet Buffering for Low Packet Loss

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.

NOTE 1: Upper layer solutions may still be needed when there are other EAS relocation scenarios (e.g. EAS (re)selection upon DNS cache entry expiry) not related to PSA change.

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 [2]. 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.

NOTE 2: To request uplink traffic buffering, the AF is expected to subscribe both Early and Late Notifications.

Figure 6.3.5-1: Packet buffering for low packet loss

1. The SMF decides to change the local PSA of a PDU Session with UL CL or SSC mode 3.

2. The SMF may send an early notification to the AF after target PSA (i.e. PSA2) is selected and waits for a notification response from the AF. The AF may reply in positive to the notification by indicating that buffering of uplink traffic to the target DNAI is needed as long as traffic to the target DNAI is not authorized by the AF. This is e.g. as defined in steps 1 and 2 of TS 23.502 [3] Figure 4.3.6.3-1.

3. For the procedures with ULCL/BP, the SMF configures the PSA2 as specified in step 2 in clause 4.3.5.6 and step 2 in clause 4.3.5.7 of TS 23.502 [3], which may request the PSA2 to buffer uplink traffic. The PSA1 (i.e. source PSA) keeps receiving downlink traffic from EAS1 and send it to the UE until it is released in step 7.

For the procedures with SSC mode 3, the SMF configures the PSA2 as specified in step 4 in clause 4.3.5.2 and in step 5-6 in clause 4.3.5.4 of TS 23.502 [3], which may request the PSA2 to buffer uplink traffic.

4. For the procedures with ULCL/BP, the SMF sends an N4 Session Modification Request to the UL CL to update the UL CL rules regarding to the traffic flows that the SMF tries to steer to PSA2. This is e.g. as defined in TS 23.502 [3] Figure 4.3.5.7-1 step 3.

5. The SMF sends a Late Notification to the AF. This corresponds e.g. to step 4a-c of TS 23.502 [3] Figure 4.3.6.3-1 and is e.g. also described in step 9 of TS 23.502 [3] Figure 4.3.5.7-1.

6a. A new EAS is selected by the application (e.g. at DNS cache entry expiry, the DNS Query is resolved and the response includes a new EAS that is near the new PSA (PSA2)). Any traffic sent to the new EAS is buffered at PSA2.

6b. The application layer completes the EAS relocation (This corresponds to step 4d of TS 23.502 [3] Figure 4.3.6.3-1). The UE context is completely relocated from the old EAS to new EAS. The old EAS stops to serve the UE

NOTE 3: Steps 6a and 6b are related which implies there is some sort of coordination at application layer that is outside of 3GPP scope.

7. When EAS relocation is completed, the AF sends a notification response to the SMF. This corresponds to step 4e-g of TS 23.502 [3] Figure 4.3.6.3-1(and is e.g. also described in step 6 or 7 of TS 23.502 [3] Figure 4.3.5.7-1) and may indicate that buffering of uplink traffic to the target DNAI is no more needed as traffic to the target DNAI /EAS is now authorized by the AF.

If the AF is changed during EAS relocation, see the details indicated in clause 6.3.2.

8. (if AF has indicated that buffering of uplink traffic to the target DNAI is no more needed as traffic to the target DNAI /EAS is now authorized by the AF) The SMF updates the PSA2 by indicating the PSA2 to send the buffered uplink packets (step 8b) and to stop buffering.

The SMF releases PSA1.

6.3.6 Edge Relocation Considering User Plane Latency Requirement

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 [3]. 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 [4]) 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 [3] 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.

6.3.7 Edge Relocation Triggered by AF

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 [3], 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 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.