8.8.3 Procedures
23.5583GPPArchitecture for enabling Edge ApplicationsRelease 18TS
8.8.3.1 General
8.8.3.2 Discover T-EAS
Figure 8.8.3.2-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.
Pre-conditions:
1. Information related to the EES is available with the S-EAS, if the procedure is triggered by the S-EAS.
Figure 8.8.3.2-1: Discover T-EAS
1. 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 8.8.2.4 is to be used for the ACR.
NOTE: The trigger condition to invoke the Discover T-EAS API is up to application service logic, which is out of scope of this specification.
2. 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 8.8.3.3 and continues with step 3.
3. The S-EES invokes the EAS discovery request on the T-EES retrieved from the ECS. The EAS 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 8.8.2.5 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.
4. 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.
5. If the request was received from the S-EAS, the S-EES responds to the S-EAS with the discovered T-EAS Information.
8.8.3.3 Retrieve T-EES procedure
Figure 8.8.3.3-1 illustrates the procedure for the S-EES to retrieve the T-EES information from the ECS.
Pre-condition:
1. The S-EES has been pre-configured with the address of the ECS; and
2. The AC at the UE already has on-going application traffic with the S-EAS.
Figure 8.8.3.3-1: Retrieve T-EES procedure
1. 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.
2. 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.
3. 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 8.3.3.3.3-2.
NOTE: The Retrieve EES request initiated by the S-EES can be restricted only to its registered ECS.
8.8.3.4 ACR launching procedure
Figure 8.8.3.4-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 8.8.1.3.
If this procedure is triggered by the S‑EAS, the procedure is used for ACR determination.
Pre-condition:
1. 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
2. Information related to the S‑EES is available with the S-EAS, if the procedure is triggered by the S‑EAS.
Figure 8.8.3.4-1: ACR launching procedure
1. The EEC or the S‑EAS sends an ACR request message to the EES in order to start ACR. The ACR request message may include Predicted/Expected UE location or Expected AC Geographical Service Area to indicate that the EES should detect whether the UE has moves to the Predicted/Expected UE location or Expected AC Geographical Service Area or not in ACR clean-up phase. 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 3GPP TS 23 501 [2].
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.
2. 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 3GPP TS 23.501 [2], clause 5.6.7.1; and
NOTE: The simultanenous EAS connectivity information sent by EES is used to maintain both S-PSA and T-PSA in supporting simultaneous connectivity with both S-EAS and T-EAS during the service continuity as described in clause 6.3.4 of 3GPP TS 23.548 [20].
Editor’s note: Since the 3GPP CN only supports simultaneous PSA connectivity in SSC mode 3 or session breakout, it is FFS whether EES should firstly know PDU session capability before invoking AF traffic influence API.
Editor’s note: It is FFS how to convey the simu-EAS connectivity info to EES.
– 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 8.8.2.5.
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.
3. 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 8.8.2.6 or upon reception of the ACR status update with failed result from T-EAS for other scenarios.
8.8.3.5 ACR information subscription
8.8.3.5.1 General
Clause 8.8.3.5.2 and clause 8.8.3.5.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.
8.8.3.5.2 Subscribe
Figure 8.8.3.5.2-1 illustrates the ACR information subscription procedure between the EEC and the EES.
Pre-conditions:
1. The EEC has received information (e.g. URI, IP address) related to the EES;
2. The EEC has received appropriate security credentials authorizing it to communicate with the EES as specified in clause 8.11; and
3. The EEC has optionally acquired a Notification Target Address to be used in its subscriptions to notifications.
NOTE: How the EEC acquires the notification target address or a notification channel URI to receive the notifications is out of scope of this release. The notification target address can terminate at the EEC (e.g. in an IoT device) if the deployment supports EEC reachability, or it can terminate at a push notification service. Details of the push notification service are out of scope of this release.
Figure 8.8.3.5.2-1: ACR information subscription
1. 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.
2. 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.
3. 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.
8.8.3.5.3 Notify
Figure 8.8.3.5.3-1 illustrates the ACR information notification procedure between the EEC and the EES, which can be used by the EES to notify the EEC of the following:
– target information, i.e. the details of the selected T-EAS and, if required, the selected T-EES, during ACR as described in clauses 8.8.2.4 and 8.8.2.5;
NOTE: The T-EAS and T-EES information can be used to determine the PDU session(s) to provide connectivity to the T-EAS and the T-EES. If the ACR does not require change in EES, i.e. T-EES is same as S-EES, then the T-EES information can be skipped.
– ACR complete events.
Pre-conditions:
1. The EEC has subscribed with the EES for the ACR information as specified in clause 8.8.3.5.2.
Figure 8.8.3.5.3-1: ACR information notification
1. An event (e.g. ACR complete, or Target information notification) occurs at the EES that satisfies trigger conditions for providing ACR information to a subscribed EEC.
2. 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). Upon receiving the target information notification to indicate start of the ACR execution, the EEC avoids triggering a second ACR execution for the same ACR identity (ACID, UE ID, S-EAS endpoint and T-EAS endpoint) until the current ACR execution is completed.
Editor’s note: In order to start detect or decide, till how long the detection entity should wait for current ACR to complete, is FFS
8.8.3.5.4 Subscription update
Figure 8.8.3.5.4-1 illustrates the ACR information subscription update procedure between the EEC and the EES.
Pre-conditions:
1. The EEC has subscribed with the EES for the ACR information as specified in clause 8.8.3.5.2.
Figure 8.8.3.5.4-1: ACR information subscription update
1. The EEC sends an ACR information subscription update request to the EES.
2. Upon receiving the request from the EEC, the EES checks if the EEC is authorized for the operation. If authorized, the EES updates the subscription.
3. The EES sends an ACR information subscription update response to the EEC.
8.8.3.5.5 Unsubscribe
Figure 8.8.3.5.5-1 illustrates the ACR information unsubscribe procedure between the EEC and the EES.
Pre-conditions:
1. The EEC has subscribed with the EES for the ACR information as specified in clause 8.8.3.5.2.
Figure 8.8.3.5.5-1: ACR information unsubscribe
1. The EEC sends an ACR information unsubscribe request to the EES.
2. Upon receiving the request from the EEC, the EES checks if the EEC is authorized for the operation. If authorized, the EES terminates the subscription of the EEC.
3. The EES sends an ACR information unsubscribe response to the EEC.
8.8.3.6 EELManagedACR procedure
8.8.3.6.1 General
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.
8.8.3.6.2 Procedure
8.8.3.6.2.1 General
This clause describes the procedures for S-EAS to request for EELManagedACR and for T-EAS to subscribe for ACT status notification.
8.8.3.6.2.2 ACR request
Figure 8.8.3.6.2.2-1 illustrates the procedure for EELManagedACR performed by the Edge Enabler Servers.
Pre-conditions:
1. Information related to the S-EES is available with the S-EAS.
2. The T-EAS has subscribed to the ACR related event from the T-EES.
3. The EEC has subscribed to the ACR related event from the S-EES.
Figure 8.8.3.6.2.2-1: ACR procedure
1. 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.
2. 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.
NOTE: How the EES accesses the Application Context related to the EAS from the address of the Application Context storage is up to implementation and outside the scope of the present document.
3. The S-EES determines the EELManagedACR operations to be executed as specified in clause 8.8.2.5.
8.8.3.6.2.3 ACT status subscription
Figure 8.8.3.6.2.3-1 illustrates the procedure for T-EAS to subscribe for ACT status during EELManagedACR.
Figure 8.8.3.6.2.3-1: ACR procedure
1. The T-EAS sends an ACT status subscription request to the T-EES.
2. The T-EES checks whether the requesting T-EAS is authorized to perform the operation. If it is authorized, the T-EES creates the subscription.
3. The T-EES responds with the ACT status subscription response
8.8.3.6.2.4 ACT status notification
Figure 8.8.3.6.2.4-1 illustrates the procedure for T-EES to notify the T-EAS about the status of ACT during EELManagedACR.
Pre-conditions:
1. ACT between the S-EES and T-EES has competed.
Figure 8.8.3.6.2.4-1: ACR procedure
1. The T-EES sends ACT status notification to the T-EAS, notifying about the status of the ACT between the Application Context received from the S-EES.
2. On receiving a notification about successful ACT, the T-EAS may initiate the ACR status update procedure as described in clause 8.8.3.8.
8.8.3.7 Selected T-EAS declaration
Figure 8.8.3.7-1 illustrates the interactions between the S-EAS and the S-EES for the selected T-EAS declaration.
Pre-conditions:
1. The S-EAS has discovered and selected the T-EAS as described in clause 8.8.3.2.
Figure 8.8.3.7-1: Selected target EAS declaration procedure
1. 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.
2. 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.
8.8.3.8 ACR status update procedure
Figure 8.8.3.8-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.
Pre-condition:
1. The ACT procedure between the S-EAS and the T-EAS is either successfully completed or failed.
Figure 8.8.3.8-1: ACR status update procedure
1. 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.
2. 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.
3. The EES responds with ACR status update response message to the EAS.
NOTE: If EES is not changed during ACR, the T-EES and S-EES are the same server.
8.8.3.9 ACR parameter information procedure
Figure 8.8.3.9-1 illustrates the procedure for sending ACR parameters from S-EES to the T-EES and T-EAS. The procedure may be used by the S-EES at the beginning of the ACR execution to provide ACR parameters, e.g. prediction expiration time, to the T-EES and T-EAS. The procedure may also be used during an ongoing ACR to update ACR parameters.
Pre-condition:
1. The ACR has been launched to the S-EES.
Figure 8.8.3.9-1: ACR parameter information procedure
1. The S-EES sends the ACR parameter information to the T-EES.
2. The T-EES checks if the requestor is authorized for this operation. If authorized, the T-EES processes the request
3. If the request is authorized and if the T-EAS has subscribed to receive ACR notifications, the EES shall notify the T-EAS by sending an ACR management notification, with "ACT start" event including ACR parameters from the request in step 1, e.g. Prediction expiration time.
NOTE: The T-EAS can use the ACR parameters to handle the ACR. For example, the T-EAS can consider prediction expiration time in deciding whether and for how long to wait for the AC of the UE to connect to it. If the ACT is performed, and the AC does not connect to the T-EAS by "Prediction expiration time", the EAS can send ACT failure with the appropriate cause to the EES. In that case, the T-EAS can delete the transferred application context. If the EAS had included indication of EAS Acknowledgement within ACR management subscribe request, the EAS sends EAS Acknowledgement as a response to the ACR management notification. The EAS can indicate the failure or rejection of the ACT in the Acknowledgement.
4. The EES responds to the requestor’s request with an ACR parameter information response message.
Editor’s note: The changes to the ACR scenarios in clause 8.2.2 to include ACR parameter information is FFS.