8.8.2 Scenarios

23.5583GPPArchitecture for enabling Edge ApplicationsRelease 18TS

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

8.8.2.1 General

ACR functionality can be implemented flexibly, and may be focused either in the EEC or in the EAS/EES. The scenarios in this clause are different with regards to

a) whether the EEC is involved in the detection phase and decision phase or detection and decision involve the S-EAS or S-EES only;

b) whether T-EAS discovery is performed between EEC and T-EES or between S-EES and T-EES;

c) whether the EEC sends an Application Context Relocation Request towards the S-EES, the T-EES or none at all; and

d) whether the Application Context is pushed from the S-EAS to the T-EAS or pulled by the T-EAS from S-EAS.

Generally, AC, EEC, EES and EAS implementations will support only a subset of these scenarios; therefore, during EAS discovery and T-EAS discovery the S-EES and T-EES shall take the ACR scenarios supported by the AC and EEC and any preferences indicated by the EEC for specific ACR scenarios into account when identifying the EAS(s) for the EAS discovery response, as specified in clause 8.5.2.2 and clause 8.8.3.2, or for the EAS discovery notification, as specified in clause 8.5.2.3.3.

Furthermore, when the EEC performs EAS discovery or T-EAS discovery, the EES or T-EES shall inform the EEC about the ACR scenarios which are supported by the EAS or T-EAS, respectively.

The EEC shall take the information about supported ACR scenarios provided by the ECS, S-EES and T-EES into account when selecting an EES for EAS discovery or T-EAS discovery, respectively, and when selecting an EAS for edge services.

For clarity of description, scenarios in clauses 8.8.2.2, 8.8.2.3, 8.8.2.4, 8.8.2.5 and 8.8.2.6 describe the relocation of a single application context to a new EAS. Multiple ACs can be active in the UE and relocation can be executed for each AC (or group of ACs) that requires service continuity.

For each of the scenarios in clauses 8.8.2.2, 8.8.2.3, 8.8.2.4, 8.8.2.5 and 8.8.2.6, ACR for one or more ACs can result in the same EEC receiving services from more than one EES, which have the registration for the required EASs that can serve the ACs. In scenarios described in clause 8.8.2.4 and clause 8.8.2.5, a successful EEC context relocation procedure enables the EEC to become implicitly registered to the target EES without the EEC sending an EEC registration request.

If selected ACR scenario list exists, the ACR scenarios are initiated based on this list.

NOTE: Details about overlapping of service continuity scenarios are provided in clause 8.x.

8.8.2.2 Initiation by EEC using regular EAS Discovery

In this scenario, ACR is a result of the UE moving to, or the UE expecting to move to, a new location which is outside the service area of the serving EAS. The EEC is triggered as a result of the UE’s movement as described in 8.8.1.1.

This scenario is based on Service Provisioning (as specified in clause 8.3) and EAS Discovery (as specified in clause 8.5) procedures to discover the T-EES and EAS that shall serve the AC as a result of the UE’s new location, and that shall receive the Application Context from the serving EAS.

This scenario relies on an interface between the EEC and AC over EDGE-5, which is out of the scope of this specification.

Pre-conditions:

1. The AC in the UE already has a connection to a corresponding S-EAS;

2. The preconditions listed in clause 8.3.3.2.2 with regards to the EEC are fulfilled; and

3. The EEC is triggered when it obtains the UE’s new location or is triggered by another entity such as an ECS notification

NOTE 1: This scenario is applicable only for an Edge-aware AC and EAS.

Figure 8.8.2.2-1: ACR initiated by the EEC and AC

Phase I: ACR Detection

1. The EEC detects the UE location update as a result of a UE mobility event and is provided with the UE’s new location as described in clause 8.8.1.1. The EEC can also detect an expected or predicted UE location in the future as described in clause 8.8.1.1.

NOTE 2: If the EEC is triggered by an external entity such as by a notification from the ECS, a list of new EESs (to be used as T-EESs) is provided by that notification and step 3 below is skipped.

Phase II: ACR Decision

2. Either the AC or the EEC makes the decision to perform the 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.

NOTE 3: Which applications require ACR can be decided based on the application profile, e.g. requirement of service continuity of the application.

If the change in UE’s location does not trigger a need to change the serving EAS, steps 3. onwards are skipped. The EEC remains connected to the serving EES(s) and the AC remains connected to its corresponding serving EAS.

Phase III: ACR Execution

3. The EEC performs Service Provisioning (as specified in clause 8.3) for all active applications that require ACR. Since the location of the UE has changed, the Service Provisioning procedure results in a list of T-EESs that are relevant to the supplied applications and the new location of the UE. When in step 1 the ACR for service continuity planning is triggered, then the Connectivity information and UE Location in the Service Provisioning procedure (as specified in clause 8.3) contains the expected Connectivity information and expected UE Location.

4. The EEC performs EAS discovery (as specified in clause 8.5) for the desired T-EASs by querying the T-EESs that were established in step 3 (or provided in the notification from the ECS – if it was the trigger). If EEC registration configuration for the EESs established in step 2 indicates that EEC registration is required, the EEC performs EEC registration with the EESs (as specified in clause 8.4.2.2.2) before sending the EAS discovery request. Step 5 is skipped if EAS discovery procedure results in only one discovered T-EAS.

When in step 1 the ACR for service continuity planning is triggered, and the "General context holding time" 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.

5. The AC and EEC select the T-EAS to be used for the application traffic.

NOTE 4: Several EEC registrations with different EESs may result from T-EAS discovery process during a single ACR operation.

6. The EEC performs ACR launching procedure (as described in clause 8.8.3.4) to the S-EES with predicted/expected UE location or Expected AC Geographical Service Area, the ACR action indicating ACR initiation and the corresponding ACR initiation data (without the need to notify the EAS). When the EES recives the predicted/expected UE location or Expected AC Geographical Service Area from the EEC, then the EES will determine to monitor the UE mobility. 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), as described in clause 8.8.3.4. If the EEC has not subscribed to receive ACR information notifications for ACR complete events from the S-EES, the EEC subscribes for the notifications as described in clause 8.8.3.5.2.

NOTE: It is expected that the AC will inform EAS about UE location monitoring is not needed7. 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. Otherwise, if the T-EES is the same as the S-EES, EEC Context Push relocation is skipped.

8. The AC is triggered by the EEC to start ACT. The AC decides to initiate the transfer of application context from the S-EAS to the T-EAS. There may be different ways of transferring context and they are all outside the scope of this specification.

When in step 1 the ACR for service continuity planning has been triggered, the AC connects to the T-EAS when the UE moves to the predicted location. Otherwise, the rest of this step is skipped.

After the ACT is completed, the AC remains connected to the T-EAS and disconnects from the S-EAS; the EEC is informed of the completion.

NOTE 5: Whether and how the AC initiates the ACT is out of scope of the present document

When in step 1 the ACR has been triggered for service continuity planning, if the UE does not move to the expected/predicted location the EEC does not connect to T-EES, the AC does not connect to the T-EAS. Post-ACR Clean-up is skipped.

NOTE 6: The S-EAS or T-EAS can further decide to terminate the ACR, and the T-EAS can discard the application context based on information received from EEL and/or other methods (e.g. monitoring the location of the UE). It is up to the implementation of the S-EAS and T-EAS whether and how to make such a decision.

NOTE 7: It is out of scope of this specification how the AC informs the S-EAS and T-EAS that ACT was part of service continuity planning. When in step 1 the ACR for service continuity planning is triggered, Post-ACR Clean up is performed after the UE moves to the predicted location.

Phase IV: Post-ACR Clean up

9. The S-EAS sends the ACR status update message to the S-EES as specified in clause 8.8.3.8.

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

NOTE 8: If the EDGE-3 subscription initialization result indicates failure, then the EAS can perform the required EDGE-3 subscriptions at the T-EES.

NOTE 9: Steps 9 and 10 can occur in any order.

11. If the status in step 9 indicates a successful ACT, the S-EES sends the ACR information notification (ACR complete) message to the EEC to confirm that the ACR has completed as specified in clause 8.8.3.5.3. Once 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 complete notify 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.

8.8.2.3 EEC executed ACR via S-EES

In this scenario, the EEC is triggered as a result of the UE’s movement as described in 8.8.1.1. Figure 8.8.2.3-1 illustrates the EEC executing ACR via the S-EES.

Pre-condition:

1. The AC at the UE already has a connection to the S-EAS; and

2. The EEC is able to communicate with the S-EES.

Figure 8.8.2.3-1: EEC executed ACR

Phase I: ACR Detection

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

Phase II: ACR Decision

2. The EEC decides to proceed required procedures for triggering 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.

Phase III: ACR Execution

3. The EEC determines the T-EES by using the provisioned information or performing service provisioning procedure per clause 8.3 of the present document. When in step 1 the ACR for service continuity planning is triggered, then the Connectivity information and UE Location in the Service Provisioning (as specified in clause 8.3) procedure contains the expected Connectivity information and expected UE Location. If the UE is within the service area of the T-EES, upon selecting 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 EEC registration with the selected T-EES as specified in clause 8.4.2.2.2. The EEC can then discover and select T-EAS by performing EAS Discovery with the T-EES per clause 8.5.2 of the present document.

NOTE 1: Several EEC registrations with different EESs may result from T-EAS discovery process during a single ACR operation.

4a. The EEC performs ACR launching procedure (as described in clause 8.8.3.4) to the S-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). The S-EES authorises the request from the EEC. The S-EES decides to execute ACR based on the information received from the EEC, EEC context and/or EAS profile. 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) and sends the ACR management notification for the "ACT start" event to the S-EAS, as described in clause 8.6.3, to initiate ACT between the S-EAS and the T-EAS. In ACT start, the S-EES includes indication of service continuity planning if the S-EES determine to monitor UE mobility. If the EEC has not subscribed to receive ACR information notifications for ACR complete events from the S-EES, the EEC subscribes for the notifications as described in clause 8.8.3.5.2.

4b. If the ACR request in step 6 includes ACR parameters, e.g. Prediction expiration time, 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.

Editor’s note: It is FFS whether this procedure can be merged with the EEC context relocation.

5. 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. Otherwise, if the T-EES is the same as the S-EES, EEC Context Push relocation is skipped.

6. The S-EAS transfers the application context to the T-EAS at implementation specific time. 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. Post-ACR Clean up is skipped.

NOTE 2: The S-EAS or T-EAS can further decide to terminate the ACR, and the T-EAS can discard the application context based on information received from EEL and/or other methods (e.g. monitoring the location of the UE). It is up to the implementation of the S-EAS and T-EAS whether and how to make such a decision.

NOTE 3: When in step 1 the ACR for service continuity planning is triggered, Post-ACR Clean up is performed after the UE moves to the predicted location.

Phase IV: Post-ACR Clean up

7. The S-EAS sends the ACR status update message to the S-EES as specified in clause 8.8.3.8.

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

NOTE 4: If the EDGE-3 subscription initialization result indicates failure, then the EAS can perform the required EDGE-3 subscriptions at the T-EES.

NOTE 5: Steps 7 and 8 can occur in any order.

9. If the status in step 7 indicates a successful ACT, the S-EES sends the ACR information notification (ACR complete) message to the EEC to confirm that the ACR has completed as specified in clause 8.8.3.5.3. Once 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 complete notify 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.

8.8.2.4 S-EAS decided ACR scenario

In this scenario, the S-EAS may detect the need of ACR locally or is notified by the S-EES via ACR management notifications or UE location notifications. The S-EAS make the decision about whether to perform the ACR, and starts the ACR at a proper time.

Pre-conditions:

1. The S-EAS may depend on the receipt ACR management events from the S-EES, e.g. "user plane path change" events or "ACR monitoring" events as described in clause 8.6.3, to detect the need for an ACR. The S-EAS may also depend on the receipt of UE location notification from the S-EES as described in clause 8.6.2.2.3, to detect the need for an ACR. For the following procedure it is assumed that the S-EAS has subscribed to continuously receive the respective events from the S-EES; and

2. The EEC has subscribed to receive ACR information notifications for target information notification events and ACR complete events from the S-EES, as described in clause 8.8.3.5.2.

Figure 8.8.2.4-1: S-EAS decided ACR

S-EAS decided ACR is outlined with four main phases: detection, decision, execution and clean up.

Phase I: ACR Detection

1. The S-EAS either receives ACR management notifications from source Edge Enabler Sever indicating that ACR may be required ("ACR monitoring" event), or self detects the need for ACR (e.g. upon receipt of a "user plane path change" event or UE location notification). If the ACR management notification indicates "ACR monitoring" event, then the notification will also contain the T-EAS information (see clause 8.6.3.2.3). The S-EAS may detect that ACR may be required for an expected or predicted UE location in the future as described in clause 8.8.1.1.

NOTE 1: How the S-EAS self detects the local need for ACR is outside the scope of this specification.

Phase II: ACR Decision

2. The S-EAS makes the decision to perform the ACR If the S-EAS 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.

NOTE 2: How the S-EAS determines when to start the ACR is outside the scope of this specification.

Phase III: ACR Execution

3. The S-EAS discovers the T-EAS as described in clause 8.8.3.2. When in step 1 the ACR has been triggered for service continuity planning, then UE Location and Target DNAI values in the Retrieve T-EES procedure contain the expected UE Location and expected Target DNAI. After S-EAS determines the T-EAS to use, the S-EAS may apply the AF traffic influence with the N6 routing information of the T-EAS in the 3GPP Core Network (if applicable).

4. The S-EAS sends selected T-EAS declaration message to S-EES, to inform S-EES the determined T-EAS to use as described in clause 8.8.3.7. The S-EAS may send the ACID and Predicted/Expected UE location or Expected AC Geographical Service Area to the EES. When the EES recives the predicted/expected UE location or Expected AC Geographical Service Area from the EAS, then the EES will determine to monitor the UE mobility.

6. Based on the T-EAS selection information received from the S-EAS, the S-EES sends the target information notification to the EEC as described in clause 8.8.3.5.3. The selected T-EES may be included in the target information and the ACID which corresponds to the selected target EAS is included in the notification sent to the EEC as described in clause 8.8.3.5.3.

7. The S-EAS transfers the application context to the T-EAS selected in step 3. This process is out of scope of the present specification.

NOTE 3: The S-EAS or T-EAS can further decide to terminate the ACR, and the T-EAS can discard the application context based on information received from EEL and/or other methods (e.g. monitoring the location of the UE). It is up to the implementation of the S-EAS and T-EAS whether and how to make such a decision.

NOTE 4: When in step 1 the ACR has been triggered for service continuity planning, Post-ACR Clean up is performed after the UE moves to the expected location.

Phase IV: Post-ACR clean up

8. The S-EAS sends the ACR status update message to the S-EES as specified in clause 8.8.3.8.

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

NOTE 5: If the EDGE-3 subscription initialization result indicates failure, then the EAS can perform the required EDGE-3 subscriptions at the T-EES.

NOTE 6: Steps 8 and 9 can occur in any order.

10. If the status in step 8 indicates a successful ACT, the S-EES sends the ACR information notification (ACR complete) message to the EEC to confirm that the ACR has completed as specified in clause 8.8.3.5.3. Once 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 complete notify 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.

8.8.2.5 S-EES executed ACR

Figure 8.8.2.5-1 illustrates the S-EES detecting, deciding and executing ACR from the S-EAS to the T-EAS. This may include EELManagedACR by S-EES when initiated by S-EAS as per clause 8.8.3.6. The EEC or the S-EAS may also detect the ACR as illustrated in figure 8.8.2.5-1.

Pre-condition:

1. The AC at the UE already has a connection to the S-EAS;

2. The EEC is able to communicate with the S-EES;

3. The EEC has subscribed to receive ACR information notifications for target information notification events and ACR complete events from the S-EES, as described in clause 8.8.3.5.2;

4. The S-EAS optionally subscribed to receive ACR management notifications for "ACR facilitation" events to the S-EES, in order to enable detection at S-EAS.

5. In case of EELManagedACR, the T-EAS has subscribed to receive ACT status notifications as described in clause 8.8.3.6.2.3.

Figure 8.8.2.5-1: S-EES executed ACR

1. The S-EAS may initiate EELManagedACR with S-EES as specified in clause 8.8.3.6. In this step, 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 this case, the S-EES executes steps 2 (i.e., S-EES detection), 4, 5, 6, 7, 8, 9, 10, 11, 13 and 14. Rest of steps are skipped.

Phase I: ACR Detection

2. 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 as described in clause 8.8.1.1. 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 step 1.

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

Phase II: ACR Decision

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

4. 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 EES recives the predicted/expected UE location or Expected AC Geographical Service Area from the EEC or the EAS in ACR determination, or the EES received service continuity planning from EAS in ACR facilitation event subscriprion, then the 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.

Editor’s note: It is FFS whether EES monitor the UE mobility based on the UE type (e.g. no mobility device).

Phase III: ACR Execution

5a. 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 values provided in the Retrieve T-EES procedure contain the expected UE Location and expected Target DNAI. The S-EES may decide not to perform ACR if T-EAS is not available.

5b. 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 recievd it in ACR launch in step 2, the S-EES sends ACR parameter information request which includes Prediction expiration time.

Editor’s note: It is FFS whether this procedure can be merged with the EEC context relocation.

6. 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. Otherwise, if the T-EES is the same as the S-EES, EEC Context Push relocation is skipped.

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

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

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

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

NOTE 1: The Application Context is encrypted and protected by the application layer. The S-EES and the T-EES engage in the packet level transport of the Application Context and they have no visibility to the content of the Application Context.

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. Post-ACR Clean up is skipped.

NOTE 3: When in step 2 the ACR has been triggered for service continuity planning, Post-ACR Clean up is performed after the UE moves to the expected location.

Phase IV: Post-ACR Clean up

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

12. The S-EAS sends the ACT status update message to the S-EES as specified in clause 8.8.3.8.

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

NOTE 4: If the EDGE-3 subscription initialization result indicates failure, then the EAS can perform the required EDGE-3 subscriptions at the T-EES.

NOTE 5: Steps 12 and 13 can occur in any order.

14. If the status in step 12 indicates a successful ACT, the S-EES sends the ACR information notification (ACR complete) message to the EEC to confirm that the ACR has completed as specified in clause 8.8.3.5.3. Once 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 complete notify 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.

NOTE 6: The Application Client mechanism to support switchover of the application traffic to T-EAS is out of scope of the specification.

8.8.2.6 EEC executed ACR via T-EES

In this scenario, the EEC is triggered as a result of the UE’s movement as described in 8.8.1.1. Figure 8.8.2.6-1 illustrates the EEC executing ACR via the T-EES.

Pre-condition:

1. The EEC has the S-EAS information that serves the AC.

2. The EES will monitor the UE mobility to Predicted/Expected UE location.

Figure 8.8.2.6-1: EEC executed ACR via T-EES

Phase I: ACR Detection

Phase II: ACR Decision

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

NOTE 1: If supported, the AC can be involved in the decision. It is out of scope of the present document how the AC is involved.

Phase III: ACR Execution

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.

NOTE 2: Several EEC registrations with different EESs may result from T-EAS discovery process during a single ACR operation.

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

5. 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. Post-ACR Clean up is skipped.

NOTE 4: When in step 1 the ACR has been triggered for service continuity planning, Post-ACR Clean up is performed after the UE moves to the expected location.

Phase IV: Post-ACR clean up

6. 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. Once 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 complete notify message to the EEC indicating that UE has moved to the predicted location when the ACR type is service continuity planning.

NOTE5: If the EDGE-3 subscription initialization result indicates failure, then the EAS can perform the required EDGE-3 subscriptions at the T-EES.

7. The T-EES sends the ACR information notification (ACR complete) message to the EEC as described in clause 8.8.3.5.3. 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.

NOTE 6: The support of ACR between EDNs operated by different ECSPs is dependent on business agreement between the ECSPs.