Tech-invite3GPPspaceIETFspace
21222324252627282931323334353637384‑5x

Content for  TS 23.558  Word version:  19.1.0

Top   Top   Up   Prev   Next
0…   5…   6…   6.2a…   6.2b…   6.3…   6.4…   7…   8…   8.3…   8.3.3…   8.3.3.3…   8.4…   8.4.3…   8.4.4…   8.5…   8.6…   8.6.3…   8.6.4…   8.6.6…   8.7…   8.8…   8.8.2.5…   8.8.2A…   8.8.3…   8.8.4…   8.8.5…   8.9…   8.14…   8.14.3…   8.15…   8.17…   8.17.3…   8.17.4…   8.18…   8.19…   8.20…   9…   A…   A.4…   A.5…   B…   E…

 

8.8.2.5  S-EES executed ACRp. 163

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.
Reproduction of 3GPP TS 23.558, Fig. 8.8.2.5-1: S-EES executed ACR
Up
Step 1.
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.
Phase I: ACR Detection
Step 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
Step 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.
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.
Step 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 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.
Phase III: ACR Execution
Step 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.
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.
Step 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 received it in ACR launch in step 2, the S-EES sends ACR parameter information request which includes Prediction expiration time.
Step 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. 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.
Step 7.
The S-EES sends the target information notification to the EEC as described in clause 8.8.3.5.3.
Step 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).
Step 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.
Step 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.
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.
Phase IV: Post-ACR Clean up
Step 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.
Step 12.
The S-EAS sends the ACR status update message to the S-EES as specified in clause 8.8.3.8.
Step 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.
Step 14.
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.
Up

8.8.2.6  EEC executed ACR via T-EESp. 166

In this scenario, the EEC is triggered as a result of the UE's movement as described in clause 8.8.1.1 or by an AC as described in clause 8.14.2.4. 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.
Reproduction of 3GPP TS 23.558, Fig. 8.8.2.6-1: EEC executed ACR via T-EES
Up
Phase I: ACR Detection
Step 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
Step 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.
Phase III: ACR Execution
Step 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.
Step 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 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.
Step 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.
Phase IV: Post-ACR clean up
Step 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.
Step 7.
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.
Up

8.8.2.7  ACR for direct EAS bundle, executed by EEC |R18|p. 169

In this scenario, the EEC executes necessary ACR for AC-EAS service session(s) in a bundle, and it follows the scenario described in clause 8.8.2.3 with the following differences:
  • all T-EAS(s) in a bundle requiring service continuity are discovered and selected during step 3. If the affinity is set to strong, then T-EASs are from the same EDN.
  • all bundled T-EAS endpoints are sent to the corresponding S-EES(s) in the ACR request and the S-EES(s) may apply AF traffic influence for the received T-EAS(s) in step 4a.
  • Each associated EES (i.e. EES serving bundle EASs) aggregates ACR status update from its served and bundled EASs in step 7 and step 8 and sends ACR complete notification to the EEC in step 9.
  • The EEC collects ACR complete notifications in step 9 and completes the ACR for the EAS bundle.
Up

8.8.2.8  ACR for EAS bundle, executed by S-EAS |R18|p. 169

In this scenario, the main S-EAS executes and triggers necessary ACR for all AC-EAS service session(s) in a bundle.
This scenario description is same as described for Figure 8.8.2.4-1 except for the following clarifications:
Pre-condition:
  1. The main S-EAS may depend on the receipt of ACR management events from its 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 main S-EAS may also depend on the receipt of UE location notification from its 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 main S-EAS has subscribed to continuously receive the respective events; and
  2. The EEC has subscribed to receive ACR information notifications for target information notification events and ACR complete events from S-EESs serving the EAS bundle, as described in clause 8.8.3.5.2.
Reproduction of 3GPP TS 23.558, Fig. 8.8.2.8-1: S-EAS executed ACR for EAS bundle
Up
Phase I: ACR Detection
Step 1.
ACR is detected, the procedure is same as step 1 of clause 8.8.2.4.
Phase II: ACR Decision
Step 2.
The main S-EAS performs ACR decision for bundled EASs.
Phase III: ACR Execution
Step 3.
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).
Step 4.
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.
Step \step 5.
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.
Phase IV: Post-ACR Clean up
Step 6.
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.
Up

8.8.2.9  ACR for EAS bundle, executed by S-EES |R18|p. 171

In this scenario, a main S-EES (serving a main S-EAS) executes and triggers necessary ACR for AC-EAS service session(s) in a bundle.
This scenario description is same as described for Figure 8.8.2.5-1 except for the following clarifications:
Pre-condition:
  1. The AC at the UE already has a connection with S-EASs in a bundle;
  2. The EEC subscribes to receive ACR information notifications for target information notification events and ACR complete events from S-EESs serving the EAS bundle, as described in clause 8.8.3.5.2;
  3. The main S-EAS may subscribe to receive ACR management notifications for "ACR facilitation" events to the main S-EES, in order to enable ACR detection at the main S-EES.
Reproduction of 3GPP TS 23.558, Fig. 8.8.2.9-1: S-EES executed ACR for EAS bundle
Up
Phase I: ACR Detection
Step 1.
The main S-EES detects the need for ACR, the procedure is same as step 2 of clause 8.8.2.5.
Phase II: ACR Decision
Step 2.
The main S-EES performs ACR decision for bundled EASs.
Phase III: ACR Execution
Step 3.
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.
Step 4.
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.
Step 5.
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).
Step 6.
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.
Phase IV: Post-ACR Clean up
Step 7.
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.
Up

Up   Top   ToC