8.8.1 General

23.5583GPPArchitecture for enabling Edge ApplicationsRelease 18TS

8.8.1.1 High level overview

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.

NOTE 1: The scenarios which require ACR for service continuity, cannot use non-overlapping LADNs.

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.

NOTE 2: After a decision that another EAS is to serve the UE, the S-EAS can decide if the existing Application Context is transferred to the new EAS.

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 3GPP TS 23.502 [3], 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 3GPP TS 23.502 [3].

NOTE 3: For IPv6 multi-homed PDU Session of SSC mode 3, the EEC can be aware of the notification about the IPv6 prefix configuration due to change of PSA UPF based on the UE implementation.

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 3GPP TS 23.502 [3].

A high level overview of ACR is illustrated in Figure 8.8.1.1-1.

Figure 8.8.1.1-1: High level overview of ACR

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.

8.8.1.2 ACR with service continuity planning

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.

NOTE 1: The information elements of the Application Context and how the Application Context is synchronized between the S‑EAS and the T‑EAS is up to implementation of the application.

NOTE 2: In the case of EELManagedACR, the Application Context synchronization is accomplished using the same mechanism as when transferring the context from the S‑EES to the T‑EES.

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.

8.8.1.3 Unused contexts handling during ACR including service continuity planning

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:

a) The UE remains communicating with the S-EAS, e.g. the UE does not move to the service area of the T-EAS; or

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

NOTE: Timeouts if required for discarding unused contexts for ACR scenarios can be specified in stage 3.