Content for &nbsp; TS 23.558 &nbsp; Word version:&nbsp; 19.3.0

Same as step 1 described for Figure 8.8.2.2-1.

Phase II: ACR Decision

Same as step 2 described for Figure 8.8.2.2-1.

Phase III: ACR Execution

If the change in the UE's location triggers a need to change the S-EAS but the EEC is not provided with a T-EAS, the EEC informs the AC of the unavailability of a suitable EDN for the new location of the UE.

The AC triggers the UE to perform DNS resolution for the CAS relevant for the AC. The UE may need to establish a new PDU connection to the CAS.

The AC sends ACR request to the EEC and the EEC responds ACR response to the AC.

Figure 8.8.2A.3-1: Enabling ACR with CAS - EEC executed ACR via S-EES

The EEC performs ACR launching procedure (as described in clause 8.8.3.4) to the S-EES with the ACR action indicating ACR initiation and the corresponding ACR initiation data (along with the details of the CAS and without the need to notify the EAS). The S-EES may apply the AF traffic influence with the N6 routing information of the CAS in the 3GPP Core Network (if applicable), as described in clause 8.8.3.4. Based on the received CAS information, the S-EES informs the CAS with the S-EES endpoint information by selected EES declaration request as described in clause 8.8.3.10.

Step 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 CAS.

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

The S-EAS or CAS can further decide to terminate the ACR, and the CAS can discard the application context (e.g. based on monitoring the location of the UE). It is up to the implementation of the S-EAS and CAS whether and how to make such a decision.

Phase IV: Post-ACR Clean up

Step 9.

Same as step 9 described for Figure 8.8.2.2-1.

Step 10.

Same as step 11 described for Figure 8.8.2.2-1.

8.8.2A.3 Enabling ACR with CAS - EEC executed ACR via S-EES p. 181

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

This scenario description is same as described for Figure 8.8.2.3-1 except for the following clarifications:

Pre-conditions:

Same pre-conditions apply described for Figure 8.8.2.3-1.

Reproduction of 3GPP TS 23.558, Fig. 8.8.2A.3-1: Enabling ACR with CAS - EEC executed ACR via S-EES

Phase I: ACR Detection

Same as step 1 described for Figure 8.8.2.3-1.

Phase II: ACR Decision

Same as step 2 described for Figure 8.8.2.3-1.

Phase III: ACR Execution

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, this procedure results in unavailability of T-EESs that are relevant to the supplied applications and the new location of the UE. Service provisioning or discovery of relevant T-EAS may not result in EES configuration or T-EAS is not discovered respectively. If no T-EES is available based on service provisioning response, the AC or EECtriggers the UE to perform DNS resolution for the cloud application server relevant for the AC as described in clause 8.14.2.5.3, 8.14.3.12 and 8.14.3.15. The UE may need to establish a new PDU connection to the CAS.

The EEC performs ACR launching procedure (as described in clause 8.8.3.4) to the S-EES with the ACR action indicating ACR initiation and the corresponding ACR initiation data (along with the details of the CAS and 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 and/or EAS profile. The S-EES may apply the AF traffic influence with the N6 routing information of the CAS 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 CAS. Based on the received CAS information, the S-EES informs the CAS with the S-EES endpoint information by selected EES declaration request as described in clause 8.8.3.10. 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.

The S-EAS transfers the application context to the CAS at implementation specific time. This process is out of scope of the present specification.

Phase IV: Post-ACR Clean up

Same as step 7 described for Figure 8.8.2.3-1.

Figure 8.8.2A.4-1: Enabling ACR with CAS - S-EAS decided ACR scenario

Same as step 9 described for Figure 8.8.2.3-1.

8.8.2A.4 Enabling ACR with CAS - S-EAS decided ACR p. 182

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

This scenario description is same as described for Figure 8.8.2.4-1 except for the following clarifications:

Pre-conditions:

Same pre-conditions apply described for Figure 8.8.2.4-1.

Reproduction of 3GPP TS 23.558, Fig. 8.8.2A.4-1: Enabling ACR with CAS - S-EAS decided ACR scenario

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

Phase I: ACR Detection

Same as step 1 described for Figure 8.8.2.4-1.

Phase II: ACR Decision

Same as step 2 described for Figure 8.8.2.4-1.

Phase III: ACR Execution

If the ACR required is self detected, the S-EAS requests the S-EES to discover the targets. When S-EES determines that no relevant EAS is available for the UE's location, the discovery response returns T-EAS discovery failure. After S-EAS determines to use CAS and performs the DNS query/discovery, the S-EAS may apply the AF traffic influence with the N6 routing information of the CAS in the 3GPP Core Network (if applicable).

The S-EAS sends selected CAS declaration message to S-EES, to inform S-EES the determined CAS to use as described in clause 8.8.3.7, where T-EAS in that procedure is assumed to be CAS. Based on the received CAS information, the S-EES informs the CAS with the S-EES endpoint information by selected EES declaration request as described in clause 8.8.3.10.

Based on the CAS 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 S-EAS transfers the application context to the CAS selected in step 3. This process is out of scope of the present specification.

Phase IV: Post-ACR Clean up

Figure 8.8.2A.5-1: Enabling ACR with CAS - S-EES executed ACR

Same as step 8 described for Figure 8.8.2.4-1.

Step 8.

Same as step 10 described for Figure 8.8.2.4-1.

8.8.2A.5 Enabling ACR with CAS - S-EES executed ACR p. 184

Figure 8.8.2A.5-1 illustrates the S-EES detecting, deciding and executing ACR from the S-EAS to the CAS. This may include EELManagedACR by S-EES when initiated by S-EAS as per clause 8.8.3.6.

This scenario description is same as described for Figure 8.8.2.5-1 except for the following clarifications:

Pre-conditions:

Same pre-conditions apply described for Figure 8.8.2.5-1, with the clarification that T-EAS is CAS and pre-condition 5 for EELManagedACR is not applicable.

Reproduction of 3GPP TS 23.558, Fig. 8.8.2A.5-1: Enabling ACR with CAS - S-EES executed ACR

Same as step 1 described for Figure 8.8.2.5-1.

Phase I: ACR Detection

Same as step 2 described for Figure 8.8.2.5-1.

Phase II: ACR Decision

Same as step 3 described for Figure 8.8.2.5-1.

Same as step 4 described for Figure 8.8.2.5-1.

Phase III: ACR Execution

The S-EES determines the targets via the Discover T-EAS procedure in clause 8.8.3.2.

If T-EAS discovery fails, then S-EES triggers DNS query message using the endpoint information (e.g., FQDN) in the S-EAS profile (e.g., EASID).

Based on the determination of CAS, the S-EES informs the CAS with the S-EES endpoint information by selected EES declaration request as described in clause 8.8.3.10. For EELmanagedACR, the CAS subscribe to S-EES to receive ACT status notifications.

Same as step 7 described for Figure 8.8.2.5-1.

Figure 8.8.2A.6-1: CAS decided ACR with T-EAS Discovery via S-EES

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

Step 8.

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

Step 9.

The Application Context is transferred from S-EAS to the CAS 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 either engage in the ACT from S-EAS to the CAS (obtained as per step 5) in a secure way. Further the CAS accesses the Application Context. The S-EAS may also perform the ACT directly with CAS, the specification of such process is out of scope of the present document.

Phase IV: Post-ACR Clean up

Step 10.

Same as step 11 described for Figure 8.8.2.5-1.

Step 11.

Same as step 12 described for Figure 8.8.2.5-1.

Step 12.

If the status in step 11 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.

8.8.2A.6 CAS decided ACR scenario via last S-EES p. 185

In this scenario, the CAS detects the need for ACR and makes the decision about whether to perform the ACR and starts the ACR at a proper time.

During the ACR execution phase, the CAS may need to determine an EES in the service area of the EEC before continuing with T-EAS discovery. The CAS may send the EAS discovery request to the S-EES that selects an appropriate T-EES and T-EAS as per clause 8.8.3.2 where the CAS acts as a S-EAS.

Pre-conditions:

The CAS has a business relationship with the ECSP, otherwise, the EES will reject the CAS request during authorization.
Prior to being connected to the CAS, the EEC was connected to an S-EES that may still hold its context and the CAS knows the S-EES (e.g. as in clause 8.8.3.10 when ACR is performed from EAS to CAS).
AC has obtained the UE ID as per clause 8.14.2.6 and forwarded it to the CAS while performing ACR from EAS to CAS as described in clause 8.8.2A.1 or the CAS knows UE ID having used the procedure defined in clause 8.6.5.

Reproduction of 3GPP TS 23.558, Fig. 8.8.2A.6-1: CAS decided ACR with T-EAS Discovery via S-EES

Phase I: ACR Detection

The CAS detects the need for ACR. The CAS either receives ACR management notifications from S-EES 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).

Phase II: ACR Decision

The CAS makes the decision to perform the ACR.

Phase III: ACR Execution

Same as steps 3 to 5 in clause 8.8.2.4 where the CAS acts as an S-EAS and it may provide the UE ID in the T-EAS discovery request for the S-EES to identify the UE during discovery. If ACR monitoring event is used in step 1, the T-EAS discovery in step 3 of clause 8.8.2.4 is skipped by the CAS.

If the S-EES can communicate with the EEC, step 6 from clause 8.8.2.4 is performed to notify the EEC of the selected T-EES. Otherwise, the notification is sent to the EEC via the SEAL notification management service as described in clause 9.1 if the EEC has subscribed to receive notifications from the S-EES or via Application Triggering via core network.

Same as step 7 in clause 8.8.2.4 where the CAS acts as an S-EAS.

Phase IV: Post-ACR Clean up

Same as step 8 to step 9 in clause 8.8.2.4 where the CAS acts as an S-EAS.