Content for  TS 23.558  Word version:  19.3.0

The S-EAS may initiate EELManagedACR with S-EES as specified in clause 8.8.3.6. The S-EAS and S-EES negotiate an address of the Application Context storage to S-EES. The S-EAS puts the Application Context at this address which can be further accessed by the S-EES when the ACT is required. In the EELManagedACR case, the S-EES executes steps 2 (i.e., S-EES is the detection entity), 4, 5, 6, 7, 8, 9, 10, 11, 13 and 14. Rest of steps are skipped.

Detection entities (S-EAS, S-EES, EEC) detect that ACR may be required and identify the ACID and Predicted/Expected UE location or Expected AC Geographical Service Area or by an S-EES subscription to the monitoring event UE mobility for area of interest as described in clause 8.8.1.1A. The detection by the S-EES may be triggered by the User Plane path change notification received from the 3GPP Core Network due to S-EAS request for "ACR facilitation" event (see clause 8.6.3) or due to receiving an EELManagedACR request in step 1. The S-EES detection may also be triggered due to EDN overload based on the edge load analytics information received from ADAES by procedure described in clause 8.8.3.11. The detection entity may detect that ACR may be required for an expected or predicted UE location in the future as described in clause 8.8.1.1A.

The detection entity performs ACR launching procedure (as described in clause 8.8.3.4) with the ACR action indicating ACR determination and the corresponding ACR determination data. If the EEC or S-EAS detect the ACR event, the EEC or S-EAS may inform S-EES with ACID, and predicted/expected UE location or Expected AC Geographical Service Area in the ACR launching procedure. The EEC may also detect a tunnel server update and inform the S-EES with the new tunnel information. For S-EAS detected case, the S-EAS includes list of UEs for which ACR is required in the ACR request to indicate S-EES to perform ACR for UEs in the group as the S-EAS is overloaded and may not meet to KPIs for common EAS. For S-EES detected case, the S-EES may detect that ACR may be required based on edge performance of load analytics of the S-EAS receved in Edge analytics Notification from ADAE server as specified in clause 8.8.3.7 of TS 23.436.

The S-EES authorises the message if received. The S-EES decides to execute ACR based on the information received or local detection, and the information of EEC context or EAS profile, and then proceed the below steps. When the S-EES receives the predicted/expected UE location or Expected AC Geographical Service Area from the EEC or the EAS in ACR determination, or the S-EES received service continuity planning from EAS in ACR facilitation event subscription, then the S-EES will determine to monitor the UE mobility. If S-EES has received information of on-going ACR, then it should not initiate an ACR with the same ACR identity uniquely identified by ACID, EEC ID (or UE ID), S-EAS endpoint and T-EAS endpoint again per clause 8.6.3.2.3. For S-EES detected case, if the ACR is decided for the common EAS, the S-EES determines list of all UEs of the application group ID that are currently connected to S-EAS.

The S-EES determines T-EES and T-EAS via the Discover T-EAS procedure in clause 8.8.3.2 of the present document. When in step 2 the ACR has been triggered for service continuity planning, then UE Location and Target DNAI and tunnel information provided in the Retrieve T-EES procedure contain the expected UE Location and expected Target DNAI and tunnel information. The S-EES may decide not to perform ACR if T-EAS is not available. If T-EAS discovery results in no T-EAS, and if ACR to CAS is supported, then the procedure for ACR with CAS applies as specified in clause 8.8.2A.5.

If required, the S-EES performs ACR parameter information procedure by sending the ACR parameter information request to the T-EES as described in clause 8.8.3.9. For example, when the ACR is for service continuity planning, and the S-EES has received it in ACR launch in step 2, the S-EES sends ACR parameter information request which includes Prediction expiration time.

If the T-EES is different than the S-EES and the EEC Context at the S-EES is not stale, the S-EES initiates EEC Context Push relocation with the T-EES as described in clause 8.9.2.3. If ACR is initiated for common EAS, S-EES may initiate EEC context push relocation for EECs in the identified UEs for the application group. Otherwise, if the T-EES is the same as the S-EES, EEC Context Push relocation is skipped. Otherwise, if the T-EES is the same as the S-EES, EEC Context Push relocation is skipped.

The S-EES sends the target information notification to the EEC as described in clause 8.8.3.5.3.

The S-EES may apply the AF traffic influence with the N6 routing information of the T-EAS in the 3GPP Core Network (if applicable).

The S-EES sends the ACR management notification (e.g. as notification for "ACR facilitation" event or "ACT start" event as described in clause 8.6.3 or due to step 1) to the S-EAS to initiate ACT between the S-EAS and the T-EAS. For S-EES detected case, the notification includes list of UEs for which ACT from S-EAS to T-EAS is required as the S-EAS is not aware of the list of UEs identified for the ACR.

The Application Context is transferred from S-EAS to the T-EAS at implementation specific time. In the case of EELManagedACR, the S-EES accesses the Application Context from the address as per step 1 and the S-EES and T-EES engage in the ACT from S-EAS to the T-EAS (obtained as per step 5) in a secure way. Further the T-EAS accesses the Application Context made available by the T-EES. If S-EAS performs the ACT directly with T-EAS, the specification of such process is out of scope of the present document. For S-EES detected case, the S-EAS initiates application context transfer towards T-EAS for all ACs for the received list of UE(s) in the notification. When in step 2 the ACR has been triggered for service continuity planning, if the UE does not move to the predicted location, the EEC does not connect to T-EES, the AC does not connect to the T-EAS.

In case of EELManagedACR, once the ACT is successful, the T-EES sends an ACT status notification to the T-EAS as described in clause 8.8.3.6.2.4, indicating that the Application Context is available.

The S-EAS sends the ACR status update message to the S-EES as specified in clause 8.8.3.8. In the case of S-EAS overload or maintenance, the S-EAS includes a list of UEs (which are part of the application group) in the ACR status update message for which ACT is successful.

The T-EAS sends the ACR status update message to the T-EES as specified in clause 8.8.3.8. If the status indicates a successful ACT, and that the EEC Context relocation procedure was attempted but failed, then the T-EES indicates the failure to the T-EAS with the ACR status update response. In the case of S-EAS overload or maintenance, the T-EAS includes a list of UEs (which are part of the application group) in the ACR status update message for which ACT is successful.

If the status in step 12 indicates a successful ACT or in the EELManagedACR case, the S-EES sends the ACR information notification (ACR complete) message immediately to the EEC to confirm that the ACR has completed as specified in clause 8.8.3.5.3. For the service continuity planning case, if it is EES monitors the UE mobility, then only when S-EES detects the UE has moved to the predicted/expected UE location or Expected AC Geographical Service Area and the status in step 12 indicates a successful ACT, then the S-EES sends ACR information notification (ACR complete) message to the EEC when the ACR type is service continuity planning. If the EEC Context relocation procedure was attempted, then the notification includes EEC context relocation status IE, indicating the result of the EEC context relocation procedure. If the EEC context relocation status indicates that the EEC context relocation was not successful, then the EEC may perform the required EDGE-1 operations such as create subscriptions at the T-EES. If ACR is initiated for common EAS, the S-EES sends the ACR information notification (ACR complete) message to EEC for the identified UEs.

The EEC detects that ACR may be required as described in clause 8.8.1.1. The EEC may detect that ACR may be required for an expected or predicted UE location in the future as described in clause 8.8.1.1A. The EEC may also detect that ACR may be required for the tunnel server update as described in clause 8.8.1.1A.

The EEC decides to proceed with required procedures for ACR. If the EEC has received information of on-going ACR, then it should not initiate an ACR with the same ACR identity uniquely identified by ACID, EEC ID (or UE ID), S-EAS endpoint and T-EAS endpoint again per clause 8.8.3.5.3.

The EEC determines the T-EES by using the provisioned information or performing service provisioning procedure per clause 8.3. When in step 1 the ACR for service continuity planning is triggered, then the Connectivity information and UE Location used in the service provisioning procedure contain the expected Connectivity information and expected UE Location. If the UE is within the service area of the T-EES, upon selecting the T-EES the UE may need to establish a new PDU connection to the target EDN. If EEC registration configuration for the T-EES indicates that EEC registration is required, the EEC performs registration with the selected T-EES as specified in clause 8.4.2.2.2. The EEC performs EAS Discovery with the T-EES per clause 8.5.2. When in step 1 the ACR for service continuity planning is triggered, and the "General context holding time duration" is included in the replied EAS discovery response, the EEC can make ACR request before it reaches respective T-EAS service area within the time period indicated by the IE.

The EEC performs ACR launching procedure (as described in clause 8.8.3.4) to the T-EES with predicted/expected UE location or Expected AC Geographical Service Area, the ACR action indicating ACR initiation and the corresponding ACR initiation data (with the need to notify the EAS). When the T-EES receives the predicted/expected UE location or Expected AC Geographical Service Area from the EEC, then the T-EES will determine to monitor the UE mobility. If the received ACR initiation request contains an EEC context ID and the S-EES Endpoint, the T-EES performs an EEC Context Pull relocation (clause 8.9.2.2). The T-EES may apply the AF traffic influence with the N6 routing information of the T-EAS in the 3GPP Core Network (if applicable). Then the T-EES sends the ACR management notification with "ACT start" event message to the T-EAS, the T-EES includes indication of service continuity planning if the T-EES determines to monitor UE mobility during post-ACR phase. If the ACR request in ACR launching procedure includes ACR parameters, e.g. Prediction expiration time, the T-EES includes the ACR parameters in the notification to T-EAS. The EEC also subscribes to receive ACR information notifications for ACR complete events from the T-EES, as described in clause 8.8.3.5.2.

The T-EAS initiates ACT between the S-EAS and the T-EAS. This process is out of scope of the present specification. When in step 1 the ACR has been triggered for service continuity planning, if the UE does not move to the predicted location the EEC does not connect to T-EES, the AC does not connect to the T-EAS.

The T-EAS sends the ACR status update message to the T-EES as specified in clause 8.8.3.8. If the status indicates a successful ACT, and that the EEC Context relocation procedure was attempted but failed, then the T-EES indicates the failure to the T-EAS with the ACR status update response.

The T-EES immediately sends the ACR information notification (ACR complete) message to the EEC as described in clause 8.8.3.5.3 for non-planning case. For the service continuity planning case, if it is EES monitors the UE mobility, then only when T-EES detects the UE has moved to the predicted/expected UE location or Expected AC Geographical Service Area and the status in step 6 indicates a successful ACT, then the S-EES sends ACR information notification (ACR complete) message to the EEC indicating that UE has moved to the predicted location when the ACR type is service continuity planning. If the EEC Context relocation procedure was attempted, then the notification includes EEC context relocation status IE, indicating the result of the EEC context relocation procedure. If the EEC context relocation status indicates that the EEC context relocation was not successful, then the EEC may perform the required EDGE-1 operations such as create subscriptions at the T-EES. If the procedure fails after step 4, it will be terminated with an appropriate cause in the ACR information notification to the EEC in step 7. The EEC may then proceed attempting to obtain services from the T-EAS discovered in step 3 without service continuity support. Alternatively, the EEC may resume the present procedure starting with step 4 and selecting a different T-EES discovered in step 3 with EAS service continuity support.

ACR is detected, the procedure is same as step 1 of clause 8.8.2.4.

The main S-EAS performs ACR decision for bundled EASs.

The main S-EAS discovers from all candidate T-EAS(s) in EAS bundle as described in clause 8.8.3.2. If the affinity is set to strong, then T-EASs are from the same EDN. The main S-EAS may apply AF traffic influence for all bundled T-EAS(s).

The procedure is same as step 4 to step 6 of clause 8.8.2.4. The main S-EAS sends selected T-EAS declaration message to the main S-EES with the selected T-EASs, the main S-EES sends selected T-EAS(s) to the EEC.

The main S-EES informs associated S-EESs with bundled T-EASs. Then ACT starts between the S-EAS(s) and T-EAS(s) in a bundle requiring service continuity.

During post-ACR, all S-EASs and T-EASs send ACR status update to S-EES and T-EES, respectively, as described in step 8 and step 9 of clause 8.8.2.4. The EEC collects ACR complete notifications from all S-EESs and ACR for EAS bundle is completed.

The main S-EES detects the need for ACR, the procedure is same as step 2 of clause 8.8.2.5.

The main S-EES performs ACR decision for bundled EASs.

The main S-EES discovers all candidate T-EAS(s) in EAS bundle as described in clause 8.8.3.2. If the affinity is set to strong, then T-EASs are from the same EDN.

The procedure is same as step 5b to step 10 of clause 8.8.2.5. The main S-EES sends selected T-EAS(s) to the EEC, triggers application traffic influence for T-EAS(s) and notifies the main S-EAS with selected T-EAS of the same EAS service. The main S-EES may notify more S-EAS(s) with selected T-EAS of the corresponding EAS service.

The main S-EES performs ACR launching procedure (as described in clause 8.8.3.4) with the ACR action indicating ACR initiation and the corresponding ACR initiation data to the associated S-EES(s).

The associated S-EES(s) notifies the corresponding bundled S-EAS(s) and ACT starts between the S-EAS(s) and T-EAS(s) in a bundle requiring service continuity.

During post-ACR, all S-EASs and T-EASs send ACR status update to S-EES and T-EES, respectively, as described in step 12 and step 13 of clause 8.8.2.5. The EEC collects ACR complete notifications from all S-EESs and ACR for EAS bundle is completed.