Tech-invite3GPPspaceIETF RFCsSIP
Quick21222324252627282931323334353637384‑5x

Content for  TS 23.558  Word version:  17.4.0

Top   Top   Up   Prev   Next
0…   5…   6…   7…   8…   8.4…   8.5…   8.6…   8.6.3…   8.6.6…   8.7…   8.8…   8.8.3…   8.8.4…   8.9…   A…   B…   C…   D…

 

8.8  Service continuityWord‑p. 114

8.8.1  GeneralWord‑p. 114

8.8.1.1  High level overviewWord‑p. 114

When a UE moves to a new location, different EASs can be more suitable for serving the ACs in the UE. Such transitions can result from a non-mobility event also, requiring support from the enabling layer to maintain the continuity of the service.
This clause describes the features that support service continuity for ACs in the UE to minimize service interruption while replacing the S-EAS, with a T-EAS.
Generally, one AC on the UE has one associated application context at the S-EAS. To support service continuity, this application context is transferred from the S-EAS to a T-EAS.
The capabilities for supporting service continuity provided at the Edge Enabler Layer may consider various application layer scenarios in which there may be involvement of AC and one or more EAS(s).
Following intra-EDN, inter-EDN and LADN (overlapping LADN service areas) related scenarios are supported for service continuity:
  • UE mobility, including predictive or expected UE mobility;
  • Overload situations in S-EAS or EDN; and
  • Maintenance aspects such as graceful shutdown of an EAS.
To support the need of ACR, following entity roles are identified:
  • detection entity, detecting or predicting the need of ACR;
  • decision-making entity, deciding that the ACR is required; and
  • execution entity, executing ACR.
A detection entity detects the probable need for ACR by monitoring various aspects, such as UE's location or predicted/expected UE location and indicates to the decision-making entity to determine if the ACR is required. The EEC, EES and EAS can potentially perform the detection role:
A decision-making entity determines that ACR is required and instructs the execution entity to perform ACR.
An execution entity performs ACR as and when instructed by the decision-making entity.
The EAS may utilize the following capabilities provided by the EES for supporting service continuity at the application layer:
  • Subscribe to service continuity related events and receive corresponding notifications;
  • Discover the T-EAS; and
  • ACR from a S-EAS to a T-EAS.
The EES can utilize the following capabilities provided by the ECS for supporting service continuity at the application layer:
  • Retrieve the T-EES.
The EEC may determine if the ACR is required by detecting that the UE moved or is predicted or expected to move outside the service area (see clause 7.3.3). The service area can be provided to the EEC by either the ECS during Service Provisioning or EES during EAS Discovery. For the PDU Session of SSC mode 3, if the UE receives PDU Session Modification Command as specified in clause 4.3.5.2 of TS 23.502, the EEC may determine that the ACR is required. For IPv6 multi-homed PDU Session of SSC mode 3, the EEC may determine that ACR is required if the UE is notified of the existence and availability of a new IPv6 prefix as specified in clause 4.3.5.3 of TS 23.502.
After successful ACR:
  • The EES is informed of the completion by the EAS; and
  • The EEC is informed of the completion by the EES.
In general, a number of steps are required in order to perform ACR. The potential roles of an edge enablement layer in ACR include:
  • providing detection events;
  • selecting the T-EAS(s); and
  • supporting the transfer of the application context from the S-EAS(s) to the T-EAS(s).
If the UE is connected to the 5GC, the EES/EAS acting as AF may utilize AF traffic influence functionality from the 3GPP CN as specified in TS 23.502.
A high level overview of ACR is illustrated in Figure 8.8.1.1-1.
Copy of original 3GPP image for 3GPP TS 23.558, Fig. 8.8.1.1-1: High level overview of ACR
Figure 8.8.1.1-1: High level overview of ACR
(⇒ copy of original 3GPP image)
Up
ACR can be performed for service continuity planning, which means that the first three steps in Figure 8.8.1.1-1 detection, decision and execution, are performed as defined in clause 8.8.1.2, e.g. when the UE is predicted to move outside the service area of the serving EAS. In such a case the T-EAS is to service the UE when it moves to the expected location.
EES can handle multiple ACR requests simultaneously. When there are multiple simultaneous ACR, the ACR shall be uniquely identified by ACID, EEC ID (or UE ID), S-EAS endpoint and T-EAS endpoint.
Up

8.8.1.2  ACR with service continuity planningWord‑p. 116

Service continuity planning is an Edge Enabler Layer value-add feature of providing support for seamless service continuity, when information about planned, projected, or anticipated behaviour is available at EESs or provided by EECs.
To implement this functionality an EES may utilize:
  • information provided by the EEC e.g., AC Schedule, Expected AC Geographical Service Area, Expected Service KPIs, Preferred ECSP list; and
  • 3GPP core network capabilities utilized by EES as described in clause 8.10.3.
In service continuity planning, the Application Context may be duplicated and sent from the S-EAS to the T-EAS before the UE moves to the expected location. In this case, the Application Contexts in S-EAS and T-EAS are synchronized when the Application Context is updated until the AC connects to the T-EAS.
For additional details on service continuity planning for ACR, see clauses 8.8.2.2, 8.8.2.3, 8.8.2.4, 8.8.2.5 and 8.8.2.6.
Up

8.8.1.3  Unused contexts handling during ACR including service continuity planningWord‑p. 116

The interval between ACT initiation and ACR status update message from EAS to EES (i.e. taking the context into use) can be significant (e.g. in the predicted case). During this interval, the following events are possible:
  1. The UE remains communicating with the S-EAS, e.g. the UE does not move to the service area of the T-EAS; or
  2. The UE moves to a service area served by a different T-EAS (other than the T-EAS towards which the ACR was initiated).
For the ACRs initiated by the EEC, in case of events a) and b) the EEC should re-send an ACR request with the information of the current ACR and the updated information as described in clause 8.8.3.4 and defined in clause 8.8.4.4. For a) if the action is initiation the EEC sets T-EAS endpoint under ACR initiation action to indicate the S-EAS. For b) if the action is initiation the UE sets T-EAS endpoint under ACR initiation action to the new T-EAS.
Up

8.8.2  ScenariosWord‑p. 116

8.8.2.1  GeneralWord‑p. 116

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
  1. whether the EEC is involved in the detection phase and decision phase or detection and decision involve the S-EAS or S-EES only;
  2. whether T-EAS discovery is performed between EEC and T-EES or between S-EES and T-EES;
  3. whether the EEC sends an Application Context Relocation Request towards the S-EES, the T-EES or none at all; and
  4. 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.
Up

8.8.2.2  Initiation by EEC using regular EAS DiscoveryWord‑p. 117

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 clause 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
Copy of original 3GPP image for 3GPP TS 23.558, Fig. 8.8.2.2-1: ACR initiated by the EEC and AC
Figure 8.8.2.2-1: ACR initiated by the EEC and AC
(⇒ copy of original 3GPP image)
Up
Phase I: ACR Detection
Step 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.
Phase II: ACR Decision
Step 2.
Either the AC or the EEC makes the decision to perform the ACR.
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
Step 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.
Step 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.
Step 5.
The AC and EEC select the T-EAS to be used for the application traffic.
Step 6.
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 (without the need to notify the EAS). 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.
Step 7.
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.
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 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.
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.
Phase IV:
Post-ACR Clean up
Step 9.
The S-EAS sends the ACR status update message to the S-EES as specified in clause 8.8.3.8.
Step 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.
Step 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. 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.
Up

8.8.2.3  EEC executed ACR via S-EESWord‑p. 120

In this scenario, the EEC is triggered as a result of the UE's movement as described in clause 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.
Copy of original 3GPP image for 3GPP TS 23.558, Fig. 8.8.2.3-1: EEC executed ACR
Figure 8.8.2.3-1: EEC executed ACR
(⇒ copy of original 3GPP image)
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 required procedures for triggering ACR.
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 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.
Step 4.
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 (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 Notify message to the S-EAS to initiate ACT between the S-EAS and the T-EAS. 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.
Step 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.
Step 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.
Phase IV:
Post-ACR Clean up
Step 7.
The S-EAS sends the ACR status update message to the S-EES as specified in clause 8.8.3.8.
Step 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.
Step 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. 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.
Up

8.8.2.4  S-EAS decided ACR scenarioWord‑p. 121

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.
Copy of original 3GPP image for 3GPP TS 23.558, Fig. 8.8.2.4-1: S-EAS decided ACR
Figure 8.8.2.4-1: S-EAS decided ACR
(⇒ copy of original 3GPP image)
Up
S-EAS decided ACR is outlined with four main phases: detection, decision, execution and clean up.
Phase I: ACR Detection
Step 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.
Phase II: ACR Decision
Step 2.
The S-EAS makes the decision to perform the ACR
Phase III:
ACR Execution
Step 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).
Step 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.
Step 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.
Step 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.
Step 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.
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.
Phase IV:
Post-ACR clean up
Step 8.
The S-EAS sends the ACR status update message to the S-EES as specified in clause 8.8.3.8.
Step 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.
Step 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. 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.
Up

8.8.2.5  S-EES executed ACRWord‑p. 123

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.
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.
Copy of original 3GPP image for 3GPP TS 23.558, Fig. 8.8.2.5-1: S-EES executed ACR
Figure 8.8.2.5-1: S-EES executed ACR
(⇒ copy of original 3GPP image)
Up
Step 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
Step 2.
Detection entities (S-EAS, S-EES, EEC) detect that ACR may be required 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.
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.
Phase III:
ACR Execution
Step 5.
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.
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. 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. Post-ACR Clean up is skipped.
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 ACT 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, 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. 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.
Up

8.8.2.6  EEC executed ACR via T-EESWord‑p. 126

In this scenario, the EEC is triggered as a result of the UE's movement as described in clause 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.
Copy of original 3GPP image for 3GPP TS 23.558, Fig. 8.8.2.6-1: EEC executed ACR via T-EES
Figure 8.8.2.6-1: EEC executed ACR via T-EES
(⇒ copy of original 3GPP image)
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.
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.
Step 4.
The EEC performs ACR launching procedure (as described in clause 8.8.3.4) to the T-EES with the ACR action indicating ACR initiation and the corresponding ACR initiation data (with the need to notify the EAS). 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 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. Post-ACR Clean up is skipped.
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 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.
Up

Up   Top   ToC