Figure 220.127.116.11-1 illustrates the procedure for fetching T-EAS information. This procedure may be utilized by a S-EAS, which undertakes the transfer of application context information to a T-EAS directly, or can be invoked by the S-EES itself on deciding to execute ACR.
Information related to the EES is available with the S-EAS, if the procedure is triggered by the S-EAS.
The S-EAS sends the EAS discovery request to the S-EES or the S-EES decides to execute the ACR. The EAS discovery request from the S-EAS includes the requestor identifier [EASID] along with the security credentials and includes EAS discovery filter matching its EAS profile. If target DNAI is available at the S-EAS via User Plane Path change event, the S-EAS provides the S-EES with the target DNAI. The S-EAS also includes an EAS service continuity support indicator indicating that the S-EAS decided ACR according to clause 18.104.22.168 is to be used for the ACR.
If the request is received from the S-EAS, the S-EES checks whether the requesting EAS is authorized to perform the discovery operation. If the UE location is not known to the S-EES or provided by the S-EAS request, then the S-EES may interact with 3GPP core network to retrieve the UE location. If the S-EES decided to execute the ACR or when the requesting EAS is authorized, the S-EES checks if there exists a T-EAS information (registered or cached) that can satisfy the requesting EAS information, additional query filters and the Expected service KPIs and the Minimum required service KPIs if received from the EEC during the EAS discovery or from the S-EAS in step 1. If the S-EES finds the T-EAS(s) in the cached or registered information, the flow either continues with step 5 for the S-EAS triggered discovery or stops for the S-EES decided ACR execution, else the S-EES retrieves the T-EES address from the ECS as specified in clause 22.214.171.124 and continues with step 3.
The S-EES invokes the EAS discovery request on the T-EES retrieved from the ECS. The S-EES discovery request includes the requestor identifier [EESID] along with the security credentials and includes EAS discovery filter. In the EAS discovery filter, the S-EES may include the Expected service KPIs and the Minimum required service KPIs if received from the EEC during the EAS discovery or from the S-EAS in step 1.
The S-EES also includes the EEC service continuity support indicator received from the EEC during EAS discovery. If in step 1 the S-EES received an EAS service continuity support indicator from the S-EAS, then the S-EES includes this EAS service continuity support indicator and its own EES service continuity support indicator indicating the ACR scenarios supported by the EES. If in step 1 the S-EES decided to execute the ACR, the S-EES includes the EAS service continuity support indicator received from the S-EAS during EAS registration and includes an EES service continuity support indicator indicating that the S-EES executed ACR according to clause 126.96.36.199 is to be used for the ACR.
Upon receiving the request, the T-EES may trigger the EAS management system to instantiate the T-EAS that matches with EAS discovery filter IEs (e.g. ACID) as in clause 8.12.
The T-EES discovers the T-EAS(s) and responds with the discovered T-EAS information to the S-EES. To filter T-EAS(s), the T-EES utilizes the discovery filters (e.g. Expected service KPIs and the Minimum required service KPIs) and the indications which ACR scenarios are supported by the AC, the EEC, the S-EES and the S-EAS. The S-EES may cache the T-EAS information.
The S-EES sends the Retrieve EES request (UE location information or UE identity, EASID of the S-EAS, target DNAI) to the ECS in order to identify the T-EES which has an EAS available to serve the given AC in the UE.
If the request contains the UE identity (e.g. GPSI) but the UE location is not known to the ECS, then the ECS interacts with 3GPP core network to retrieve the UE location. The ECS determines T-EES(s) as per the parameters (e.g. EASID, target DNAI) in the request and the UE location information.
The ECS sends the Retrieve EES response including the list of EDN configuration information to the S-EES. The list of EDN configuration information includes the EDN details with the endpoint information of T-EES(s) as described in Table 188.8.131.52.3-2.
Figure 184.108.40.206-1 illustrates the ACR launching procedure by the EEC or the S-EAS.
If this procedure is triggered by the EEC, depending on the ACR action indicated in the ACR request, the procedure is used for either ACR initiation or ACR determination. This procedure of the ACR initiation can be re-sent as described in clause 220.127.116.11.
If this procedure is triggered by the S-EAS, the procedure is used for ACR determination.
The EEC has been authorized to communicate with the EES as specified in clause 8.11, if the procedure is triggered by the EEC; and
Information related to the S-EES is available with the S-EAS, if the procedure is triggered by the S-EAS.
The EEC or the S-EAS sends an ACR request message to the EES in order to start ACR. The ACR request message includes ACR action to indicate either ACR initiation request or ACR determination request. If the procedure is triggered by the S-EAS, the ACR request message is only for ACR determination.
An ACR request for ACR initiation sent by the EEC:
includes an indication of whether the EEC requests the EES to perform EAS notification; and
provides information used by EES to perform AF traffic influence as in TS 23.501.
An ACR request for ACR determination sent either by the EEC or the EAS informs the EES that the need for ACR has been detected by the requestor.
The EES checks if the requestor is authorized for this operation. If authorized, the EES processes the request and performs the required operations.
If the request in step 1 is for ACR initiation:
the EES may use information provided in the request to apply the AF traffic influence with the N6 routing information of the T-EAS in the 3GPP Core Network (if applicable), as described in TS 23.501, clause 18.104.22.168; and
if the EAS notification indication in ACR initiation data is provided in the step 1 request and the EAS has subscribed to receive such notification, the EES shall notify the EAS indicated in the ACR initiation data about the need to start ACR by sending an ACR management notification for the "ACT start" event, as described in clause 8.6.3.
If the request in step 1 is for ACR determination, the EES decides to execute ACR as described in clause 22.214.171.124.
If the request in step 1 includes Previous T-EAS Endpoint:
if the previous EAS notification indication is provided in the step 1 request and the EAS has subscribed to receive such notification, the EES shall notify the EAS about the cancellation of the ACR with the previous T-EAS by sending an ACR management notification for the "ACT stop" event, as described in clause 8.6.3.
The EAS will inform the remote EAS about application context cancellation, which is outside the scope of this specification. The T-EAS sends the ACR status update message to the T-EES which will include failed result with an appropriate cause indicating the reason for the failure.
The EES responds to the requestor's request with an ACR response message.
In case of re-sending ACR initiation, if serving EES was changed and EEC context was relocated, the T-EES can clean up any relocated EEC context either indicated in the re-sent ACR request for scenario described in clause 126.96.36.199 or upon reception of the ACR status update with failed result from T-EAS for other scenarios.
Clause 188.8.131.52.2 and clause 184.108.40.206.3 together illustrate the ACR information procedure based on Subscribe/Notify model.
The ACR information procedure is utilized as a building block for a part of Post-ACR Clean up in clause 8.8.2 and Target information notification.
The EEC sends an ACR information subscription request to the EES. The request from EEC may include the ACIDs to indicate to the EES which ACs are served by the EEC that need to receive ACR information via EEL.
Upon receiving the request from the EEC, the EES checks if the EEC is authorized to subscribe ACR information about the requested EAS(s). If the request is authorized, the EES creates and stores the subscription for ACR information.
The EES sends an ACR information subscription response to the EEC, which includes the subscription identifier and may include the expiration time, indicating when the subscription will automatically expire. To maintain the subscription, the EEC shall send an ACR information subscription update request prior to the expiration time. If an ACR information subscription update request is not received prior to the expiration time, the EES shall treat the EEC as implicitly unsubscribed.
The EES sends an ACR information notification to the EEC with the ACR information determined in step 1. The ACR information notification may include ACID to indicate the application context relocation of the AC is complete. If the S-EES has received the successful EEC Context Push response from T-EES, along with registration ID and the registration expiration time in the EEC Context Push relocation procedure, then the ACR information notification towards EEC also includes the registration ID and registration expiration time under EEC context relocation status (for successful status).
This clause introduces a procedure for ACR performed by the Edge Enabler Servers.
When S-EES receives a request for EELManagedACR from S-EAS, the S-EES performs the service operations for the service continuity including detecting the event which may trigger the ACR, making the ACR decision, discovering the T-EAS, accessing and transferring the Application Context to the T-EES/T-EAS, notifying the T-EAS about the available Application Context, notifying the 3GPP network about ACR information, notifying the EEC about the T-EAS information (as per EEC subscription).
The EELManagedACR procedure is designed as an asynchronous operation wherein the S-EES will generate notifications (e.g. failure of any ACR related operation) to the S-EAS while performing the ACR operations.
The S-EAS sends an EELManagedACR service request (UE identifier, EAS characteristics for ACR) to request the S-EES to handle all the service operations of the ACR. The S-EAS may initiate this request with S-EES based on different triggers (e.g. when Application Client is connecting to the S-EAS). An address for accessing the Application Context may be provided if available, which allows the S-EES to access the Application Context generated by the S-EAS for ACT.
The S-EES checks whether the requesting EAS is authorized to perform the operation. If it is authorized, the S-EES responds with an EELManagedACR service response. If no address for accessing Application Context is provided by S-EAS in step 1, then the S-EES provides an address for storing the Application Context by S-EAS.
The S-EAS sends Selected target EAS declaration request message to the S-EES. The request includes the information of the selected T-EAS and may include ACID to indicate which AC the T-EAS is intended for.
The S-EES checks whether the requesting EAS is authorized to perform operation. If authorized, the S-EES responds to the received request with Selected target EAS notification declaration response message. The S-EES also determines the selected T-EES based on the declared T-EAS selection, then S-EES checks whether the EEC (serving the ACs) has subscribed for ACR related information.
Figure 220.127.116.11-1 illustrates the procedure for ACR status update, which is triggered by the S-EAS or the T-EAS. In the post-ACR clean up phase of service continuity scenarios described in clause 8.8.2, this procedure may be used by EAS to indicate the status of ACT to their registrar EESs; or used by the T-EAS to update the notification target address and allow the T-EES to indicate the status of EDGE-3 subscription relocation to the T-EAS including subscription ID update for EDGE-3 subscriptions; or both.
The ACT procedure between the S-EAS and the T-EAS is either successfully completed or failed.
The EAS sends ACR status update request message to the EES, the request may include the ACT result (success or failure). When sent by the T-EAS, the request may include a list of EDGE-3 subscription ID(s) and Notification Target Address for which the T-EAS wants to update. In case of EELManagedACR, the ACT result is not included by the T-EAS.
If the request is authorized by the EES, the EES processes the request. When sent by the T-EAS, if the EDGE-3 subscriptions are available in the T-EES or were successfully relocated during the EEC context relocation procedure, the T-EES updates the Notification Target Address if provided by the T-EAS and may update the list of EDGE-3 subscription ID(s) for the EDGE-3 subscriptions.
When the ACR status update request message of step 1 includes the ACT result, it shall also include the UEID and endpoint information of the other EAS involved in the ACT. The EES uses UEID and EAS endpoint information to identify the corresponding ACR. In cases where the ACT result indicates failure of the ACR (i.e. failure with a cause indicating cancellation of the ACR), the T-EES which receives the ACR status update request message removes the transferred EEC context.