Content for  TS 23.558  Word version:  18.1.0

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.

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.

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.

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.

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. If selected ACR scenario list exists, the ACR scenarios are initiated based on this list.

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

Phase I: ACR Detection Phase II: ACR Decision Phase III: Phase IV:

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.

Phase I: ACR Detection Phase II: ACR Decision Phase III: Phase IV:

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.

S-EAS decided ACR is outlined with four main phases: detection, decision, execution and clean up. Phase I: ACR Detection Phase II: ACR Decision Phase III: Phase IV:

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.

Phase I: ACR Detection Phase II: ACR Decision Phase III: Phase IV:

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.
2. The EES will monitor the UE mobility to Predicted/Expected UE location.

Phase I: ACR Detection Phase II: ACR Decision Phase III: Phase IV: