WO2023019489A1 - Device and method for application context relocation - Google Patents

Abstract

The present disclosure relates to edge computing, particularly to mechanisms for managing ACR procedures. To this end, the disclosure proposes network entities for managing an ACR procedure for a UE from a source entity to a target entity. A first network entity is configured to: create an ACR session for the ACR procedure; and maintain session information of the ACR session in the first network entity, wherein the session information comprises an ACR session ID of the ACR session, and at least one of: information about the source entity, information about the target entity, and an ID of the UE. A second network entity is configured to: send a launching request for the ACR procedure to the first network entity, wherein the launching request comprises at least an ID of the UE and an ID of the second network entity.

Description

DEVICE AND METHOD FOR APPLICATION CONTEXT RELOCATION TECHNICAL FIELD

The present disclosure relates generally to the field of communication systems, and particularly to edge computing. The disclosure proposes networkentities andmethodsformanaging an Application Context Relocation (ACR) procedure in edge applications.

BACKGROUND

Edge Computing is a network architecture concept that enables cloud computing capabilities and service environments, which are deployed close to the user equipment (UE) . It promises several benefits such as lower latency, higher bandwidth, reduced backhaul traffic, and prospects for new services compared to cloud environments. It enables operator and third-party services to be hosted close to the UE, to achieve an efficient service delivery through the reduced end-to-end latency and load on the transport network.

Notably, when a UE moves to a new location, different Edge Application Servers (EASs) can be more suitable for serving Application Clients (ACs) in the UE. Generally, the source EAS (S-EAS) is associated with an application context. To support service continuity, this application context from the S-EASis transferred to a target EAS (T-EAS) .

3 ^rd Generation Partnership Project (3GPP) supports service continuity for Edge-Aware Applications. Application Context Relocation (ACR) refers to the end-to-end service continuity procedure. Currently, five different scenarios of ACR have been specified in 3GPP TS 23.558 specification. These ACR scenarios are classified depending on the initiator of the ACR: AC-initiated ACR (in this case, the ACR is initiated by the Edge Enabler Client (EEC) as per decision from AC) , EAS-initiated ACR, EEC-initiated ACR, and Edge Enabler Server (EES) initiated ACR.

Based on the current ACR scenarios, once the initiator (e.g. AC, EEC, EAS, EES) triggers the ACR procedure (no matter the EEC or S-EAS triggers the EES, or, EES is  self-triggered) , there is no mechanism to cancel or modify it by the initiator of the ACR. Further, there can be multiple and simultaneous active ACRs initiated by the same initiator. A new initiated ACR may impact an ongoing ACR.

Service continuity planning means that the ACR is triggered for an expected or predicted location of the UE in the future. If the ACR for service continuity planning starts, the application context is transferred from the S-EAS to the T-EAS for future use. The UE connects to the T-EAS, only after moving to the predicted location. However, if the prediction is changed or cancelled by the ACR initiator (AC, EEC, S-EAS, or EES) , the application context transfer continues as the S-EAS and T-EAS (transmitter and receiver of Application Context) do not have any knowledge of how to handle the Application Context initially transferred.

These issues will lead to the accumulation of stale Application Contexts at the T-EAS which may require complicated processing at the Application Layer to decide to perform a clean-up. An improved ACR procedure is thus desired.

SUMMARY

In view of the above, the present disclosure introducesmechanisms for managing ACR procedures. An objective is to enableACR modification or cancellation. One aim is to provide a method for managing the ongoing ACR procedures. One further objective is to provide notifications to entities involved in the ACR procedures thus allowing all involved entities to have the same understanding of the ACR procedures.

A first aspect of the disclosure provides a first network entity for managing an ACR procedure for a UE from a source entity to a target entity, wherein the first network entity is configured to: create an ACR session for the ACR procedure; and maintain session information of the ACR session in the first network entity, wherein the session information comprises an ACR session identifier, ID, of the ACR session, andat least one of: information about the source entity, information about the target entity, and an ID of the UE.

A source entity here can be any of anS-EAS or anS-EES or any combination of both. A target entity can be any of a T-EAS or a T-EES or any combination of both.

This disclosure proposes an entity for handling ACR procedures. The first network entitymay be an EES that is trigged by other entities or self-triggered to launch an ACR procedure. For instance, the first network entity may be one of the S-EES and the T-EES of the ACR procedure. This disclosure introduces an ACR session creation that allows the first network entity keeps necessary information about the ACR procedure. Such a mechanism enables the first network entity to further manage (e.g., modify, or cancel) the ACR procedure after it is launched. The ACR session ID can be implicit identification or an explicit ID. For example, a combination of the ID of the UE and the T-EAS endpoint can be used for implicit identification of the ACR session. In another example, an implicit identification can comprise of at least one of the:

- the ID and/or address of the UE,

- EEC ID,

- information of the source entity,

- information of the target entity,

- information of the transmitter of an application context transfer (ACT) corresponding to the ACR procedure, e.g. the S-EAS endpoint address,

- information of the receiver of the ACT, e.g. the T-EAS endpoint address.

In an implementation form of the first aspect, the session information further comprises one or more of the following:

- an ID of a second network entity for initiating the ACR procedure for the UE,

- information about a third network entity for initiating an ACT corresponding to the ACR procedure,

- information about a transmitter and/or receiver of the ACT,

- a routing requirement of the receiver of the ACT,

- an expected completion time of the ACR procedure,

- a priority indicator of the ACR procedure.

For example, the second network entity may be an EEC or EAS that initiates the ACR procedure for the UE. The second network entity may refer to as the ACR initiator in this application. The third network entity may refer to as the ACT initiator. Notably, ACT  refers to the transfer of the Application Context between the S-EAS and the T-EAS, which is a part of the service continuity procedure.

In an implementation form of the first aspect, the first network entity is further configured to:generate the ACR session ID for the ACR session, or obtain the ACR session ID from the second network entity.

In an implementation form of the first aspect, the first network entity is further configured to: receive a launching request from the second network entity, wherein the launching request comprises the ID of the UE, and the ID of the second network entity; and send a launching response to the second network entity, after the ACR session is created, wherein the launching response comprises the ACR session ID.

Optionally, the first network entity may be trigged by other entities or self-triggered to create an ACR session.

The third network entity can further be the ACR initiator, i.e., the second network entity. In an implementation form of the first aspect, the launching request further comprises one or more of the following:

- the information about the third network entity,

- the information about the transmitter and/or receiver of the ACT,

- the routing requirement of the receiver of the ACT,

- the expected completion time of the ACR procedure,

- the priority indicator of the ACR procedure,

- the ACR session ID.

In an implementation form of the first aspect, the launching request further comprises a first indicator, wherein the first network entity is further configured to based on the first indicator, send a first ACR notification to the third network entity, the first ACR notification comprising the ACR session ID and indicating a start of the ACR session for the ACR procedure.

Notably, the first indicator is indicative of whether to send the first ACR notification to the third network entity.

In an implementation form of the first aspect, the first network entity is further configured to send a first ACR notification to the third network entity, the first ACR notification comprising the ACR session ID and indicating astartof the ACR session for the ACR procedure. In other words, the first indicator is optional. Thus, the first network entity can initiate to send the first ACR notification by itself.

Optionally, the first network entity may also notify the third network entity about an ACR completion priority indication and/or expected ACR completion time or duration.

In an implementation form of the first aspect, the first network entity is further configured to provide the session information to at least one of the source entity and the target entity.

In an implementation form of the first aspect, the first network entity is further configured to: update the session information of the ACR session; and provide the updated session information to the at least one of the source entity and the target entity, wherein the updated session information indicates a modification or cancellation of the ACR procedure.

In an implementation form of the first aspect, the first network entity is further configured to: modify the ACR session for the ACR procedure when receiving a modification request comprising the ACR session ID of the ACR session, from the second network entity; andsend a modification response to the second network entity, wherein the modification response indicates a status of the modification of the ACR procedure associated with the ACR session ID.

In an implementation form of the first aspect, the first network entity is further configured to: cancel the ACR session for the ACR procedure when receiving a cancellation request comprising the ACR session ID of the ACR session, from the second network entity; and send a cancellation response to the second network entity, wherein the cancellation response indicates a status of the cancellation of the ACR procedure associated with the ACR session ID.

This disclosure further proposes mechanisms for ACR modification handling at the ACR handler, thus allows the first network entity to further update or modify the (ongoing) ACR procedure after it is launched. The particular ACR session that needs to be modified or cancelled can be identified using the unique ACR session ID.

In an implementation form of the first aspect, the modification request comprises one or more of the following:

- an updated routing requirement of the receiver of the ACT,

- an updated expected completion time of the ACR procedure,

- an updated priority indicator of the ACR procedure, and

- information about an updated receiver of the ACT;

and wherein the first network entity is configured to update the session information of the ACR session based on the modification request.

Optionally, the status in the modification response may include the status or result of the modification, e.g., success, failure, etc. Optionally, the status in the cancellation responses may include the status or result of the cancellation, e.g., success, failure, etc.

In an implementation form of the first aspect, the modification and cancellation responses comprise the ACR session ID.

This disclosure introduces an ACR session modification mechanism that allows the first network entity to modify the ACR procedure after it is launched, for instance when a new T-EAS is detected, or UE predicted location is changed, etc. In this way, during the ongoing ACR procedure, ACR sessions can be handled based on UE location tracking.

In an implementation form of the first aspect, the modification request further comprises a second indicator, wherein the first network entity is further configured to based on the second indicator, send a second ACR notification to the third network entity, the second ACR notification comprising the ACR session ID and indicating a modification of the ACR session for the ACR procedure.

In an implementation form of the first aspect, the first network entity is further configured to send a second ACR notification to the third network entity, the second ACR notification comprising the ACR session ID and indicating a modification of the ACR session for the ACR procedure. In other words, the second indicator is optional. Thus, the first network entity can initiate to send the second ACR notification by itself.

In an implementation form of the first aspect, the cancellation request comprises one or more of the following:

- the ID of the UE,

- the ID of the second network entity,

- the information about the third network entity, and

- the information about the receiver of the ACT.

This disclosure introduces an ACR session cancellation mechanism that allows the first network entity to cancel the ACR procedure after it is launched. In this way, during the ongoing ACR procedure, ACR sessions can be handled based on UE location tracking. Therefore, when a new ACR that impacts an ongoing ACR procedure is detected, for instance when the predicted location of UE changes, the old ACR session may be cancalled.

In an implementation form of the first aspect, the cancellation request further comprises a third indicator, wherein the first network entity is further configured to base on the third indicator, send a third ACR notification to the third network entity, the third ACR notification comprising the ACR session ID and indicating that the ACT is to be cancelled.

In an implementation form of the first aspect, the first network entity is further configured to send a third ACR notification to the third network entity, the third ACR notification comprising the ACR session ID and indicating that the ACT is to be cancelled. In other words, the third indicator is optional. Thus, the first network entity can initiate to send the third ACR notification by itself.

In an implementation form of the first aspect, the first network entity is further configured to receive a modification confirmation, which confirms the modification of the ACR procedure, from the at least one of the source entity and the target entity.

In an implementation form of the first aspect, the first network entity is further configured to receive a cancellation confirmation, which confirms the cancellation of the ACR procedure, from the at least one of the source entity and the target entity.

The modification confirmation is indicative of confirming that a request to modifythe ACR procedure or a request to cancel the ACR procedure has been received and/or processed, e.g. authenticated, and/or the required process will be or has been handled, i.e., the modification or cancellation process is started or finished.

In an implementation form of the first aspect, the first network entity is further configured to: send a retrieve request to an edge configuration server to obtain information about a fourth network entity, wherein the retrieve request comprises information about a receiver or transmitter of the ACT, which is registered into the fourth network entity; andreceive a retrieve response from the edge configuration server, wherein the retrieve response comprises the information about the fourth network entity.

Such implementation may be used:

- by the S-EES to identify the T-EES by including the T-EAS information within the retrieve request.

- by the T-EES to identify the S-EES by including the S-EAS information within the retrieve request.

To identify an EES means to obtain the information, e.g., endpoint address, of the EES.

In an implementation form of the first aspect, the retrieve request further comprises one or more of: location information of the UE, and the ID of the UE.

The information about the third network entity, the transmitter of the ACT, the receiver of the ACT, or the updated receiver of the ACT can be an address or ID of the third network entity, the transmitter of the ACT, the receiver of the ACT, or the updated receiver of the ACT.

In an implementation, the session information can also include an indication of whether the first ACR notification, the second ACR notification, and/or the third ACR notification is required or not. The first network entity can store it at the time of session creation as a part of the session information.

A second aspect of the disclosure provides a second network entity for initiating an ACR procedure for a UE from a source entity to a target entity, wherein the second network entity is configured to: send a launching request for the ACR procedure to a first network entity, wherein the launching request comprises at least an ID of the UE and an ID of the second network entity, and receive a launching response comprising an ACR session ID of an ACR session, from the first network entity in response to the launching request.

This disclosure further proposesan ACR initiator, i.e., the second network entity, which may trigger the first network entity to create, modify, or cancel an ACR session. The second network entity may be an EEC or EAS that initiates the ACR procedure for the UE. Optionally, the second network entity may provide an ACR session ID to the first network entity. In this case, the launching request further comprises an ACR session ID of an ACR session, for indicating the first network entity to create the ACR session for the ACR procedure. Alternatively, the first network entity may generate the ACR session ID by itself. In such a case, the second network entity may be further configured to receive a launching response from the first network entity, wherein the launching response comprises the ACR session ID of the ACR session.

In an implementation form of the second aspect, the launching request further comprises one or more of the following:

- information about a third network entity for initiating an ACT corresponding to the ACR procedure,

- information about a transmitter and/or receiver of the ACT,

- a first indicator that indicates the first network entity to send a first ACR notification indicating a start of the ACR procedure to the third network entity,

- a routing requirement of the receiver of the ACT,

- an expected completion time of the ACR procedure,

- a priority indicator of the ACR procedure.

In an implementation form of the second aspect, the second network entity is further configured to send a modification request comprising the ACR session ID for a modification of the ACR procedure to the first network entity; and receive a modification response from the first network entity, wherein the modification response indicates a status of the modification of the ACR procedure associated with the ACR session ID.

In an implementation form of the second aspect, the second network entity is further configured to send a cancellation request comprising the ACR session ID for a cancellation of the ACR procedure to the first network entity; and receive a cancellation response from the first network entity, wherein the cancellation response indicates a status of the cancellation of the ACR procedure associated with the ACR session ID.

Optionally, the modification response may include the status or result of the modification, e.g., success, failure, etc. Optionally, the cancellation responses may include the status or result of the cancellation, e.g., success, failure, etc.

In an implementation form of the second aspect, the modification request comprises one or more of the following:

- an updated routing requirement of the receiver of the ACT,

- an updated expected completion time of the ACR procedure,

- an updated priority indicator of the ACR procedure,

- information about an updated receiver of the ACT,

- a second indicator that indicates the first network entity to send a second ACR notification indicating a modification of the ACR session for the ACR procedure to the third network entity.

In an implementation form of the second aspect, the cancellation request comprises one or more of the following:

- the ID of the UE,

- the ID of the second network entity,

- the information about the third network entity,

- the information about the receiver of the ACT,

- a third indicator that indicates the first network entity to send a third ACR notification for cancelling the ACT to the third network entity.

In an implementation form of the second aspect, the modification and cancellation responses comprise the ACR session ID.

A third aspect of the disclosure providesa third network entity for initiating an ACT, being configured to: receive a first ACR notification from a first network entity, wherein the first ACR notification comprises an ACR session ID of an ACR session, and indicates a start of the ACR session for an ACR procedure for a UE from a source entity to a target entity; initiate the ACT corresponding to the ACR procedure; and create an ACT session for the ACT.

In this disclosure, the third network entity may refer to as the ACT initiator. Notably, ACT refers to the transfer of the Application Context between the S-EAS and the T-EAS, which is a part of the service continuity procedure.

In an implementation form of the third aspect, the third network entity is further configured to associate the ACT session with an ACT session ID that corresponds to the ACR session ID.

In an implementation form of the third aspect, the third network entity is further configured to receive a second ACR notification from the first network entity, wherein the second ACR notification comprises the ACR session ID, and indicates a modification of the ACR session for the ACR procedure.

In an implementation form of the third aspect, the third network entity is further configured to receive a third ACR notification from the first network entity, wherein the third ACR notification comprises the ACR session ID, and indicates to cancel the ACT; and cancel the ACT session corresponding to the ACT.

In an implementation form of the third aspect, the third network entity is further configured to identify the ACT session based on the ACR session ID.

A fourth aspect of the disclosure provides a fourth network entity for managing an ACR procedure for a UE from a source entity to a target entity, the fourth network entity being configured to: receive session information of an ACR session corresponding to the ACR  procedure from a first network entity, wherein the session information comprises an ACR session ID of the ACR session, andat least one of: information about the source entity, information about the target entity, and an ID of the UE.

The fourth network entity may also be referred to as the remote EES. The remote EES may be one of the S-EES and the T-EES. Possibly, when the first network entity is the S-EES, the fourth network entity is the T-EES. When the first network entity is the T-EES, the fourth network entity is the S-EES. Possibly, the S-EES and the T-EES can be the same entity.

In an implementation form of the fourth aspect, the session information further comprises one or more of the following:

- an ID of a second network entity for initiating the ACR procedure for the UE,

- information about a third network entity for initiating an ACT corresponding to the ACR procedure,

- information about a receiver of the ACT,

- a routing requirement of the receiver of the ACT,

- an expected completion time of the ACR procedure, and

- a priority indicator of the ACR procedure.

In an implementation form of the fourth aspect, the fourth network entity is further configured to receive updated session information of the ACR session from the first network entity, wherein the updated session information indicates a modification of the ACR procedure; and send a modification confirmation, which confirms the modification of the ACR procedure, to the first network entity.

In an implementation form of the fourth aspect, the fourth network entity is further configured to receive updated session information of the ACR session from the first network entity, wherein the updated session information indicates cancellation of the ACR procedure; and send a cancellation confirmation, which confirms the cancellation of the ACR procedure, to the first network entity.

A fifth aspect of the disclosure provides a method performed by a first network entity for managing an ACR procedure for a UE from a source entity to a target entity, comprising:  creating an ACR session for the ACR procedure; and maintaining session information of the ACR session in the first network entity, wherein the session information comprises an ACR session ID of the ACR session, and at least one of: information about the source entity, information about the target entity, and an ID of the UE.

Implementation forms of the method of the fifth aspect may correspond to the implementation forms of the first network entity of the first aspect described above. The method of the fifth aspect and its implementation forms achieve the same advantages and effects as described above for the first network entity of the first aspect and its implementation forms.

In an implementation form of the fifth aspect, the method further comprisesmodifying or cancelling the ACR session for the ACR procedure.

A sixth aspect of the disclosure provides a method performed by a second network entity for initiating an ACR procedure for a UE from a source entity to a target entity, comprising:

sending a launching request of the ACR procedure to a first network entity, wherein the launching request comprises at least an ID of the UE and an ID of the second network entity, and receiving an ACR session ID of an ACR session from the first network entity in response to the launching request.

Implementation forms of the method of the sixth aspect may correspond to the implementation forms of the second network entity of the second aspect described above. The method of the sixth aspect and its implementation forms achieve the same advantages and effects as described above for the second network entity of the second aspect and its implementation forms.

In an implementation form of the sixth aspect, the method further comprisesmodifying or cancelling the ACR session for the ACR procedure.

A seventh aspect of the disclosure provides a method performed by a third network entity for initiating an ACT, comprising: receiving a first ACR notification from a first network entity, wherein the first ACR notification comprises an ACR session ID of an ACR  session, and indicates a start of the ACR session for an ACR procedure for a UE from a source entity to a target entity; initiating an ACT corresponding to the ACR procedure; and creating an ACT session for the ACT.

Implementation forms of the method of the seventh aspect may correspond to the implementation forms of the third network entity of the third aspect described above. The method of the seventh aspect and its implementation forms achieve the same advantages and effects as described above for the third network entity of the third aspect and its implementation forms.

In an implementation form of the seventh aspect, the method further comprisesmodifying or cancelling the ACT corresponding to the ACR procedure.

A eighth aspect of the disclosure provides a method performed by a fourth network entity for managing an ACR procedure for a UE from a source entity to a target entity, comprising: receiving session information of an ACR session corresponding to the ACR procedure from a first network entity, wherein the session information comprises an ACR session ID of the ACR session, and at least one of: information about the source entity, information about the target entity, and an ID of the UE.

Implementation forms of the method of the eighth aspect may correspond to the implementation forms of the fourth network entity of the fourth aspect described above. The method of the eighth aspect and its implementation forms achieve the same advantages and effects as described above for the fourth network entity of the fourth aspect and its implementation forms.

In an implementation form of the eighth aspect, the method further comprisesmodifying or cancelling the ACR session for the ACR procedure.

A ninth aspect of the disclosure provides a computer program product comprising a program code for carrying out, when implemented on a processor, the method according to the fifth aspect and any implementation forms of the fifth aspect, the sixth aspect and any implementation forms of the sixth aspect, the seventh aspect and any implementation  forms of the seventh aspect, or the eighth aspect and any implementation forms of the eighth aspect.

It has to be noted that all devices, elements, units and means described in the present application could be implemented in the software or hardware elements or any kind of combination thereof. All steps which are performed by the various entities described in the present application as well as the functionalities described to be performed by the various entities are intended to mean that the respective entity is adapted to or configured to perform the respective steps and functionalities. Even if, in the following description of this disclosure, a specific functionality or step to be performed by external entities is not reflected in the description of a specific detailed element of that entity which performs that specific step or functionality, it should be clear for a skilled person that these methods and functionalities can be implemented in respective software or hardware elements, or any kind of combination thereof.

BRIEF DESCRIPTION OF DRAWINGS

The above described aspects and implementation forms of the present disclosure will be explained in the following description of specific embodiments in relation to the enclosed drawings, in which

FIG. 1 shows an examplearchitecture for enabling edge applications.

FIG. 2 shows an ACR procedure in edge applications.

FIG. 3 (a) shows ACR launching procedure, and (b) shows a selected target EAS declaration procedure.

FIG. 4 shows a conventionalEEC-initiated ACR procedure.

FIG. 5 shows a first network entity according to an embodiment of the disclosure.

FIG. 6 shows an ACR session creation procedure according to an embodiment of the disclosure.

FIG. 7 shows a second network entity according to an embodiment of the disclosure.

FIG. 8 shows a third network entity according to an embodiment of the disclosure.

FIG. 9 shows a fourth network entity according to an embodiment of the disclosure.

FIG. 10 shows an ACR session modification procedure according to an embodiment of the disclosure.

FIG. 11 shows an ACR session cancellation procedure according to an embodiment of the disclosure.

FIG. 12 shows Remote EES endpoint information retrieving according to an embodiment of the disclosure.

FIG. 13 shows a method according to an embodiment of the disclosure.

FIG. 14 shows a method according to an embodiment of the disclosure.

FIG. 15 shows a method according to an embodiment of the disclosure.

FIG. 16 shows a method according to an embodiment of the disclosure.

DETAILED DESCRIPTION OF EMBODIMENTS

Illustrative embodiments of methods and network entities for updating ACR in a wirelesscommunication system are described with reference to the figures. Although this description provides a detailed example of possible implementations, it should be noted that the details are intended to be exemplary and in no way limit the scope of the application.

Moreover, an embodiment/example may refer to other embodiments/examples. For example, any description including but not limited to terminology, element, process, explanation, and/or technical advantage mentioned in one embodiment/example is applicative to the other embodiments/examples.

FIG. 1 shows an architecture for enabling edge applications. Edge Data Network (EDN) is a local Data Network that supports the architecture for enabling edge applications. Edge Application Servers (EASs) and Edge Enabler Servers (EESs) are contained within the EDN. Edge Configuration Server (ECS) provides configurations related to the EES, including details of the EDN hosting the EES. The UE contains Application Clients (ACs) and the EEC. The EAS (s) , the EES (s) , and the ECS can interact with the 3GPP Core Network.

As previously mentioned, when a UE moves to a new location, a different EAS, namely, the T-EAS, may become more suitable than the S-EAS for serving the ACs in the UE. FIG. 2 shows an example of ACT from the S-EAS to the T-EAS. ACT refers to the transfer of the Application Context between the S-EAS and the T-EAS, which is a part of the service continuity procedure. Application Context refers to a set of data about the Application Client that resides in the EAS.

As previously mentioned, current ACR scenarios are classified intoAC-initiated ACR, EAS-initiated ACR, EEC-initiated ACR, and EES-initiated ACR. EEC and EAS can send a trigger to EES to launch ACR. Three ACR triggering (launching) procedures are defined in 3GPP specification TS 23.558: ACR launching with the action Initiation (triggered by EEC) , ACR launching with the action Determination (triggered by EEC or S-EAS) , and selected T-EAS declaration (triggered by S-EAS) .

FIG. 3 shows examples of an ACR launching procedure. FIG. 3 (a) shows the ACR launching scenarios with the action Initiation or with the action Determination, in which an ACR request is sent from the EEC (or the S-EAS) either to the S-EES or the T-EES. Table 1-1 describes information elements for the ACR request. Table 1-2 describes the information elements for the ACR response sent from the S-EES to the EEC.

Table 1-1

Table 1-2

FIG. 3 (b) shows an example of a selected T-EAS declaration procedure. The S-EAS sends a selected target EAS declaration request message to the S-EES. The request  includes the information of the selected T-EAS as described in Table 2-1. The S-EES checks whether the requesting EAS is authorized to perform operation. If authorized, the S-EES responds to the received request with the selected target EAS notification declaration response message as described in Table 2-2. The S-EES also determines the selected T-EES based on the declared T-EAS selection, which may be included in the target information notification sent to the EEC.

Table 2-1

Information element	Status	Description
UE ID	M	The identifier of the UE.
Security credentials	M	Security credentials.
Selected EAS ID	M	Selected EAS identifier.
Selected EAS Endpoint	M	Endpoint of the selected EAS.

Table 2-2

Information element	Status	Description
Successful response	O	Indicates that the request was successful.
Failure response	O	Indicates that the request failed.
> Cause	O	Indicates the failure cause.

As previously described, there are several issues with current ACR scenarios and procedures as follows:

1. Once the EEC, S-EAS triggers the EES or EES is self-triggered to perform the ACR, there is no mechanism to cancel or modify it by the initiator (e.g. AC, EEC, EAS, EES) of the ACR.

2. There can be multiple and simultaneous active ACRs initiated by the same initiator and when any modification or cancellation of the ACR is initiated, it is required to detect the correct ACR to apply the modification or cancellation. Such a mechanism is missing.

3. If there is an ongoing ACR initiated by Initiator A and subsequently if another Initiator B initiates an ACR which may impact the ongoing ACR, a mechanism is missing to detect the impacted ongoing ACR. If impacted, a mechanism is missing related to the action for the impact (e.g. Modify the ongoing ACR, Cancel the ongoing ACR, Reject the newly initiated ACR by the Initiator) .

4. If the ACT is handled between S-EAS and T-EAS without involving EES (s) , then there is no mechanism to modify or cancel the ACT.

FIG. 4 showsan existing EEC-initiated ACR procedure currently specified in 3GPP TS 23.558. Notably, in step 4, EEC performs ACR launching procedure to the S-EES. In step 6, the S-EAS transfers the application context to the T-EAS at an implementation-specific time. Step 4 is executed only once during the ACR procedure. It should be noted that after step 4, EEC cannot modify or cancel the ACR. The ACR continues without involving the EEC, until the success or failure of the procedure.

The ACR launching is made only once by EES. There is no mechanism to modify or cancel that process by EEC including providing any change to the IEs of ACR request. Further, there is neither a mechanism to distinguish between multiple and simultaneous ACRs from the EEC, nor a mechanism to detect the impact on ongoing ACR by EES due to ACR initiated by S-EAS (another initiator) . Regarding step 6, there is no mechanism at EES to modify or cancel the ACT triggered by the EES due to ACR.

In case of service continuity planning, if the prediction is changed or cancelled by the ACR initiator (AC, EEC, S-EAS, or EES) , the ACT still continues as the S-EAS and T-EAS (transmitter and receiver of Application Context) do not have any knowledge of how to handle the Application Context initially transferred.

It may be worth mentioning that after ACR initiation, the initiating entity can initiate another ACR. For example: After the ACR launching procedure with ACR initiation indication in step 4 of FIG. 4, the EEC can initiate another ACR procedure from the beginning and perform another ACR launching procedure with different ACR initiation data in the newly initiated procedure. In the existing solutions, the logical connection of the new ACR initiation to the previous ongoing ACR (s) is unknown. The new ACR initiation does not cancel or modify the previous ACR initiation (s) . A new ACR initiated which impacts an ongoing ACR is not detected. An ongoing ACR continues until it ends, successfully or with failure. If ACT is handled at the application layer without involving EES, then ACT is not controlled due to either modification or cancellation of ACR. During ongoing ACR, the EES handling of ACR behavior based on UE location tracking is missing.

According to the current specification, only the ACR initiator knows whether the ACR is a normal ACR or it is for a future location. In the case of service continuity planning, the S-EAS and T-EAS keep on synchronizing the application context until explicit Application intervention. In an example, a vehicular UE may perform service continuity planning for several points on the path. In case of the path is changed, several ongoing ACRs related to that path continue independently.

Embodiments of this disclosure thus propose mechanisms to enable the following ACR actions:

· ACR modification/update request -This is an explicit indication to EES to modify the ACR processing based on time or indication of delaying the ACR or immediate completion of the ACRand/or change of the receiver of the ACT, i.e. T-EAS.

· ACR cancellation request -This is an explicit indication to EES to cancel ongoing ACR.

· Enhance the Notification to EAS that ACR has modified or cancelled the normal ACR or service continuity planning ACR–This is required to let the Application layer manage the ACT as per the request.

· Optionally an indication in the ACT that it is for Service Continuity Planning with optional suggested action –This is required to between the S-EAS and T-EAS to manage the ACT (e.g. accelerate the ACT, delay the ACT, or cancel the ACT) .

FIG. 5 shows a first network entity 100 according to an embodiment of the disclosure. The first network entity 100 may comprise processing circuitry (not shown) configured to perform, conduct or initiate the various operations of the first network entity 100 described herein. The processing circuitry may comprise hardware and software. The hardware may comprise analog circuitry or digital circuitry, or both analog and digital circuitry. The digital circuitry may comprise components such as application-specific integrated circuits (ASICs) , field-programmable arrays (FPGAs) , digital signal processors (DSPs) , or multi-purpose processors. The first network entity 100 may further comprise memory circuitry, which stores one or more instruction (s) that can be executed by the processor or by the processing circuitry, for example under control of the software. For instance, the memory circuitry may comprise a non-transitory storage medium storing executable software code which, when executed by the processor or the processing  circuitry, causes the various operations of the first network entity 100 to be performed. In one embodiment, the processing circuitry comprises one or more processors and a non-transitory memory connected to the one or more processors. The non-transitory memory may carry executable program code which, when executed by the one or more processors, causes the first network entity 100 to perform, conduct or initiate the operations or methods described herein.

The first network entity 100 is designed for managing an ACR procedure for a UE from a source entity to a target entity. The first network entity is configured to create an ACR session for the ACR procedure. The first network entity is further configured to maintain session information of the ACR session in the first network entity. The session information comprises an ACR session ID of the ACR session, and at least one of: information about the source entity, information about the target entity, and an ID of the UE. The ACR session ID can be implicit identification or an explicit ID.

Embodiments of this disclosure introduce a mechanism for creating ACR sessions with all involved entities. FIG. 6 shows an ACR session creation procedure according to an embodiment of the disclosure. The ACR handler may be the first network entity 100 shown in FIG. 5, which is triggered by other entities or self-triggered to launch an ACR procedure. For instance, the first network entity 100 may be one of the S-EES and the T-EES of the ACR procedure. This disclosure introduces an ACR session creation that allows the first network entity 100 keeps necessary information about the ACR procedure. Such a mechanism enables the first network entity to further manage (e.g., modify, or cancel) the ACR procedure after it is launched.

1. Optionally, the ACR handler, i.e., the first network entity 100, receives an ACR launching request (e.g., by means of ACR initiation or ACR determination or selected T-EAS declaration) , from the ACR initiator (EEC, EAS) , i.e., a second network entity 200. Alternatively, the ACR handler is self-triggered to launch ACR. Optionally, the ACR launching request may include a first indicator, which is indicative of whether to send a first ACR notification to a third network entity 300.

2. The ACR handler performs an authorization check and upon successful authorization, creates an ACR session, e.g., the ACR session 101 as shown in FIG. 5, for  the ACR procedure.

i. ACR handler may generate an ACR session ID for the ACR session 101 (alternatively, the ACR session ID may be received in step 1 from the ACR initiator) .

ii. UE ID must be determined from step 1.

iii. Optionally, remote EES endpoint can be determined in different manners, e.g., the remote EES endpoint may be determined from step 1, being retrieved from the ECS (will be discussed later) , or retrieved from local cache corresponding to the ACT initiator (EAS) information received in step 1.

3. If S-EES is handling the ACR launching request, then S-EES sends the ACR session information to the T-EES. If T-EES is handling the ACR launching request, then T-EES sends the ACR mapping information to the S-EES as per the ACR session information. The Remote EES stores the ACR session information.

The ACR session information, e.g., the session information 102 shown in FIG. 5, which is created and stored at the EES (ACR handler) may include one or more of the following:

- information about the second network entity 200 that initiates the ACR procedure for the UE: e.g., EEC ID (if EEC is initiator) , S-EAS ID (e.g., IP address, if S-EAS is initiator) , or EES ID (e.g., IP address, if EES is initiator) ,

- UE identifier (the target UE for which the ACR is launched) ,

- information about ACT initiator (S-EAS) and ACT receiver (T-EAS) endpoints: e.g., information about a third network entity 300 for initiating an ACT corresponding to the ACR procedure, information about a transmitter and/or receiver of the ACT,

- S-EES and/or T-EES endpoints,

- a routing requirement of the receiver of the ACT, e.g., Data Network Access Identifier (DNAI) and N6 traffic routing requirements associated with T-EAS,

- an expected ACR completion time or duration,

- a priority indicator of the ACR procedure, e.g., ACR completion priority indicator (HIGH, LOW, NORMAL, URGENT) ,

- ACT initiator (EAS) notification indication, i.e., whether to notify EAS about the ACR situation.

4. The Remote EES provides a response to the ACR handler.

5. If an EAS notification indication (e.g., the first indicator) is provided in step 1, then the ACR handler sends anACR notification (e.g., the first ACR notification) to indicate ACR start to the ACT initiator (EAS) , i.e., the third network entity 300. Optionally, the ACR notification may be provided with the ACR session ID and the ACR completion priority indicator, and/or expected ACR completion time or duration. The EAS may create an ACT session for ACT, and use this ACR session ID as the ACT session ID or may create a new ACT session ID. The ACT session ID may correspond to the ACR session ID. EAS stores the mapping of the ACR session ID and the ACT session ID. If EES itself is the ACT initiator the above processing for ACR session ID and the ACT session ID is performed by the EES. The ACT initiator uses the ACR completion priority indicator and/or Expected ACR completion time or duration to complete the ACT with the ACT receiver.

6. The ACR handler (EES) sends an ACR launching response to the ACR initiator (EEC or EAS) with the ACR session ID.

Embodiments of this disclosure further introduce asecond network entity 200 for initiating an ACR procedure for a UE from a source entity to a target entity. FIG. 7 shows the second network entity 200 according to an embodiment of the disclosure. The second network entity 200 is configured to send a launching request 201 for the ACR procedure to a first network entity 100. The first network entity 100 may be the first network entity shown in FIG. 5 or FIG. 6. The launching request 201 comprises at least an ID of the UE and an ID of the second network entity 200. The second network entity 200 is further configured to receive an ACR session ID 202 of an ACR session 101 from the first network entity 100 in response to the launching request 201.

As mentioned in a previous embodiment, the first network entity 100 may obtain an ACR session ID 202 of an ACR session 101 from the ACR initiator, i.e., the second network entity 200. In this case, the launching request 201 further comprises the ACR session ID 202, for indicating the first network entity 100 to create the ACR session 101 for the ACR procedure.

The second network entity 200may be further configured toreceive a launching response from the first network entity 100. Optionally, the launching response may comprise the ACR session ID 202 of the ACR session 101.

For instance, the launching request 201 may include information elements describes in Table 3-1.

Table 1-1

For example, the launching request 201 may comprise a first indicator that is indicative of whether to send a first ACR notification indicating a start of the ACR procedure to the third network entity 300. The first indicator here may be the “ACT initiator (EAS) notification indication” described in Table 3-1.

The ACR launching response may include information elements describes in Table 3-2.

Table 3-2

Embodiments of this disclosure further introduce a third network entity 300 for initiating an ACT corresponding to an ACR procedure for a UE from a source entity to a target entity. FIG. 8 shows the third network entity 300 according to an embodiment of the disclosure. The third network entity 300 is configured to receive a first ACR notification 301 from a first network entity 100. The first network entity 100 may be the first network entity shown in FIG. 5 or 6. The first ACR notification 301 comprises an ACR session ID of an ACR session and indicates a start of the ACR session for the ACR procedure. The third network entity 300 is further configured to initiate the ACT corresponding to the ACR procedure, and create an ACT session 302 for the ACT.

Embodiments of this disclosure further introduce a fourth network entity 400 for managing an ACR procedure for a UE from a source entity to a target entity. FIG. 9 shows the fourth network entity 400 according to an embodiment of the disclosure. The fourth network entity 400 is configured to receive session information 102 of an ACR session 101 that corresponds to the ACR procedure from a first network entity 100. The first network entity 100 may be the first network entity shown in FIG. 5 or 6. The session information 102 comprises an ACR session ID of the ACR session and at least one of: information about the source entity, information about the target entity, and an ID of the UE.

As discussed in previous embodiments, step 3 of FIG. 6 include the ACR handler providing session information to the remote EES. Optionally, the first network entity 100 may send an ACR session information creation request (which includes a whole or part of information elements as shown in Table 4-1) to the remote EES, i.e., the fourth network entity 400. Accordingly, the fourth network entity 400 may send ACR session information creation response (which includes a whole or part of information elements as shown in Table 4-2) to the first network entity 100.

Table 4-1

Possibly, the “ACT initiator (EAS) notification indication” shown in Table 4-1 may be the first indicator discussed in the previous embodiment.

Table 4-2

Embodiments of this disclosure further introduce a mechanism for ACR modification handling at the ACR handler. FIG. 10 shows an ACR session modification procedure according to an embodiment of the disclosure. The ACR handler may be the first network entity 100 shown in FIG. 5, which is triggered by other entities or self-triggered to modify an ACR procedure. For instance, the first network entity 100 may be one of the S-EES and the T-EES of the ACR procedure. The ACR initiator (EEC or EAS) may be the second network entity 200 shown in FIG. 7. This disclosure introduces an ACR session modificationmechanism that allows the first network entity 100 to further update or modify the ACR procedure after it is launched.

Notably, the ACR procedure here is an ongoing ACR procedure for a UE. ACT corresponding to the ACR procedure is also triggered to be performed.

B1. Optionally, the ACR initiator (EEC or EAS) may trigger an ACR modification request to the ACR handler (EES) . Alternatively, the ACR handler (EES) can be self-triggered due to the detection of several trigger conditions (e.g., UE moving faster, UE moving slowly, UE not moving, UE started moving, new T-EAS detected, UE predicted location changed, etc. ) . The ACR modification request includes ACR session ID and/or ACR modification data.

For examples:

- If UE moving faster is detected, then the ACR completion priority indication is set to URGENT.

- If UE moving slowly is detected, then ACR completion priority indication is set to NORMAL

- If UE not moving is detected, then the ACR completion priority indication is set to LOW.

- If the UE started moving is detected, then the ACR completion priority indication is set to HIGH.

- If a new ACT receiver (T-EAS) is encountered, then ACR completion priority indication is determined based on the comparison of the expected ACR completion time or duration of the current ACT receiver and the new ACT receiver, and/or the previous ACR completion priority indication used for the current ACT receiver.

For instance, the expected ACR completion time or duration is computed by calculating the speed of the UE towards the location of the new ACT receiver. Optionally, the speed of the UE may be included in the request.

B2. If ACR modification request is authorized, the associated ACR session information is retrieved using the ACR Session ID, or the combination of one or more of: UE ID, ACT initiator (S-EAS) endpoint information, and current ACT receiver (T-EAS) information provided in step B1. Notably, as shown in FIG. 10, if new ACT receiver information is provided, then Case B is executed, else Case A is executed.

Case A: ACR modification with current ACT receiver

B3. If ACT initiator (EAS) notification is set to “yes” then, e.g., the ACR modification request comprises an indicator indicating the ACR handler to send an ACR notification to the ACT initiator, the ACR handler (EES) notifies the ACT initiator (EAS) about the ACR completion priority indication and/or expected ACR completion time or duration.

B4. The ACT initiator (EAS) identifies the ACT session by resolving the ACT session ID based on the ACR session ID received in step B3. The ACT initiator uses the received ACR completion priority indication and/or expected ACR completion time to modify the ACT characteristics by changing the ACT throughput (e.g., size of data per message) and rate of data delivery towards the current ACT receiver.

B5. The ACR handler (EES) sends an ACR session information modification request to the remote EES of the current ACT receiver (T-EAS) . The remote EES of the current ACT receiver updates the ACR session information corresponding to the ACR session ID received in the request.

B6. The remote EES of the current ACT receiver (T-EAS) sends an ACR session information modification response to the ACR handler (EES) confirming the modification of the ACR session information.

Case B: ACR modification with new ACT receiver

B3. If a new ACT receiver is provided, the ACR handler (EES) may firstly retrieve the remote EES of the new ACT receiver (details are discussed in FIG. 12) and sends the ACR session information creation request to the remote EES of the new ACT receiver (T-EAS) . The remote EES of the new ACT receiver creates the ACR session information corresponding to the ACR session ID received in the request.

B4. The remote EES of the new ACT receiver (T-EAS) sends an ACR session information modification response to the ACR handler (EES) confirming the creation of the ACR session info.

B5. If the ACT initiator (EAS) notification is set to “yes” , e.g., the ACR modification request comprises an indicator indicating the ACR handler to send an ACR notification to the ACT initiator, the ACR handler (EES) may notify the ACT initiator (EAS) about the ACR completion priority indication and/or expected ACR completion time or duration and new ACT receiver information.

B6. The ACT initiator (EAS) identifies the ACT session by resolving the ACT session ID based on the ACR session ID received in step B5. The ACT initiator uses the received ACR completion priority indication and/or expected ACR completion time to create a new ACT session with the new ACT receiver and cancels the ACT session with the current ACT receiver.

B7. The ACR handler (EES) sends an ACR session information cancellation request to the Remote EES of the current ACT receiver. The remote EES of the current ACT receiver removes the ACR session information corresponding to the ACR session ID received in the request.

B8. The remote EES of the current ACT receiver sends an ACR session information cancellation response confirming the cancellation of the ACR session information.

For both Case A and Case B:

B9. The ACR handler sends an ACR modification response to the ACR initiator indicating the status of the modification corresponding to the ACR session ID.

According to this embodiment, the first network entity 100 may be further configured to modify the ACR session 101 for the ACR procedure when receiving a modification request from the second network entity 200. For instance, the modification request may include information elements describes in Table 5-1.

Table 5-1

The first network entity 100 may be further configured to send a modification response comprising the ACR session ID to the second network entity 200. The modification response indicates a status of the modification of the ACR procedure associated with the ACR session ID. Notably, the status means a status or result of the modification, e.g., success, failure, etc. The modification response may include information elements describes in Table 5-2.

Table 5-2

According to this embodiment, once the ACR procedure needs to be modified, the first network entity 100 may be configured to update the session information of the ACR session 101. Further, the first network entity 100 may be configured to provide the updated session information to the at least one of the source entity and the target entity, wherein the updated session information indicates a modification of the ACR procedure.

As shown in step B5 of Case A, the ACR handler may send ACR session information modification request (information elements as shown in Table 6-1) to the remote EES, i.e., the fourth network entity 400. Accordingly, the fourth network entity 400 may send ACR session information modification response (information elements as shown in Table 6-2) to the first network entity 100.

Table 6-1

Table 6-2

As shown in step B7 of Case B, as the modified ACR procedure requires a new ACT receiver, the ACR handler may send an ACR session information cancellation request (information elements as shown in Table 7-1) to the remote EES of the current ACT receiver, i.e., the fourth network entity 400. Accordingly, the fourth network entity 400 may send ACR session information cancellation response (information elements as shown in Table 7-2) to the first network entity 100.

Table 7-1

Table 7-2

As shown in step B3 of Case A, and step B5 of Case B, the ACR handler may send an ACR notification, i.e., the second ACR notification, to the third network entity 300, the second ACR notification comprises the ACR session ID, and indicates a modification of the ACR session 101 for the ACR procedure.

Embodiments of this disclosure further introduce a mechanism for ACR cancellation at ACR handler. FIG. 11 shows an ACR session cancellation procedure according to an embodiment of the disclosure. The ACR handler may be the first network entity 100 shown in FIG. 5, which is trigged by other entities or self-triggered to cancel an ACR procedure. For instance, the first network entity 100 may be one of the S-EES and the T-EES of the ACR procedure. The ACR initiator (EEC or EAS) may be the second network entity 200 shown in FIG. 7. This disclosure introduces an ACR session cancellation mechanism that allows the first network entity 100 to cancel the ACR procedure after it is launched.

Notably, the ACR procedure here is an ongoing ACR procedure for a UE. ACT corresponding to the ACR procedure is also triggered to be performed.

C1. Optionally, the ACR initiator (EEC or EAS) may trigger an ACR cancellation request to the ACR handler (EES) . Alternatively, the ACR handler (EES) may be self-triggered for ACR cancellation. The ACR cancellation request includes at leastan ACR session ID of an ACR session.

For example, the ACR cancellation request may include information elements shown in Table 8-1.

Table 8-1

C2. If ACR cancellation request for ACR cancellation is authorized, the associated ACR session information is retrieved using the Session ID or the combination of UE ID, S-EAS endpoint information and the current T-EAS information provided in step C1.

C3. If the ACT initiator (EAS) notification is set to “yes” then, the ACR handler (EES) sends a notification to the ACT initiator (EAS) with ACR cancelled indication.

C4. The ACT initiator (EAS) identifies the ACT session by resolving the ACT session ID based on the ACR session ID received in step B3. The ACT initiator cancels the ACT session with the ACT receiver.

C5. The ACR handler (EES) sends an ACR session information cancellation request to the remote EES of the ACT receiver. The remote EES of the ACT receiver removes the ACR session information corresponding to the ACR session ID received in the request.

C6. The remote EES of the ACT receiver sends an ACR session information cancellation response confirming the cancellation of the ACR session info.

C7. The ACR handler sends an ACR cancellation response (information elements as shown in Table 8-2) to the ACR initiator indicating the status of the cancellation corresponding to the ACR session ID.

Table 8-2

It should be noted that in the previous embodiments regarding ACR modification and ACR cancellation, the ACR handler, i.e., the first network entity 100, may send an ACR  notification to the ACT initiator. The ACR notification comprises at least the ACR session ID of the ACR session. Optionally, the ACR notification may also comprise an expected ACR completion time or duration in which the ACR is expected to be completed, and/or ACR completion priority indicator. Optionally, the ACR notification may also comprise an ACR cancelled indication, which is indicative of whether the ACR is cancelled.

For instance, the modification request sent by the second network entity 200 may further comprise a second indicator, which is indicative of whether to send a second ACR notification to the third network entity 300. The first network entity 100 is further configured to, based on the second indicator, send a second ACR notification to the third network entity 300. The second ACR notification may comprise the ACR session ID and indicate a modification of the ACR session for the ACR procedure. The second indicator here may be the “ACT initiator (EAS) notification indication” described in Table 5-1.

For instance, the cancellation request sent by the second network entity 200 may further comprise a third indicator, which is indicative of whether to send a third ACR notification to the third network entity 300. The first network entity 100 is further configured to, based on the third indicator, send a third ACR notification to the third network entity 300. The third ACR notification may comprise the ACR session ID and indicate that the ACT is to be cancelled. The third indicator here may be the “ACT initiator (EAS) notification indication” described in Table 8-1.

It may be worth mentioning that as described in previous examples and embodiments, there are three messages for a request from ACR initiator to ACR handler: ACR launching request (as shown in Table 3-1) , ACR modification request (as shown in Table 5-1) , and ACR cancellation request (as shown in Table 8-1) . These messages are similar as they are all requests from ACR initiator to ACR handler. In a specific implementation, it is possible to combine them into one message. Notably, if any of the ACR launching request, ACR modification request, and ACR cancellation request are combined into the same message, the corresponding responses (the ACR launching response, ACR modification response, and ACR cancellation response) may be combined accordingly.

This disclosure also proposes a mechanism for retrieving the Remote EES endpoint information from the ECS. FIG. 12 shows a retrieving procedure according to an embodiment of this disclosure.

D1. The ACR handler (S-EES) sends aretrieve EES request (e.g., may include UE location information or UE identity, EASID of the S-EAS, or the target DNAI) to the ECS in order to identify the T-EES which has an EAS available to serve the given Application Client in the UE. The retrieve EES request may include information elements described in Table 9-1.

D2. If the request contains the UE identity (e.g., GPSI) but the UE location is not known to the ECS, then the ECS may interact with the 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. If the request is only for the ACT receiver endpoint, then the ECS determines the corresponding Remote EES endpoint where the ACT receiver endpoint is registered.

D3. The ECS sends aretrieve EES response (EASID of the S-EAS, list of T-EES (s) information) to the S-EES. The list of T-EES (s) information includes the endpoint for each of the T-EES (s) , e.g., IP address determined in step D2. The retrieve EES response may include information elements described in Table 9-2.

Notably, the EES discovery initiated by the S-EES can be restricted only to its registered ECS.

Table 9-1

Table 9-2

Table 10

It may be worth mentioning that according to embodiments of this disclosure, the second network entity 200, the third network entity 300, and the fourth network entity 400 may comprise processing circuitry (not shown) configured to perform, conduct or initiate the various operations of these entities described herein. The processing circuitry may comprise hardware and software. The hardware may comprise analog circuitry or digital circuitry, or both analog and digital circuitry. The digital circuitry may comprise components such as application-specific integrated circuits (ASICs) , field-programmable  arrays (FPGAs) , digital signal processors (DSPs) , or multi-purpose processors. The second network entity 200, the third network entity 300, and the fourth network entity 400 may further comprise memory circuitry, which stores one or more instruction (s) that can be executed by the processor or by the processing circuitry, for exampleunder control of the software. For instance, the memory circuitry may comprise a non-transitory storage medium storing executable software code which, when executed by the processor or the processing circuitry, causes the various operations of these entities to be performed. In one embodiment, the processing circuitry comprises one or more processors and a non-transitory memory connected to the one or more processors. The non-transitory memory may carry executable program code which, when executed by the one or more processors, causes the second network entity 200, the third network entity 300, and the fourth network entity 400 to perform, conduct or initiate the operations or methods described herein.

FIG. 13 shows a method 1300 according to an embodiment of the disclosure. In a particular embodiment of the disclosure, the method 1300 is performed by afirst network entity 100 shown in FIG. 5, FIG. 6, FIG. 10, FIG. 11, or FIG. 12. The method 1300 comprises a step 1301 of creating an ACR session 101for the ACR procedure; and a step 1302 of maintaining session information 102 of the ACR session 101 in the first network entity 100. The session information 102 comprises an ACR session ID of the ACR session 101, at least one of: information about the source entity, information about the target entity, and an ID of the UE. The method 1300 may further comprise modifying or cancelling the ACR session 101.

FIG. 14 shows a method 1400 according to an embodiment of the disclosure. In a particular embodiment of the disclosure, the method 1400 is performed by a second network entity 200 shown in FIG. 6, FIG. 7, FIG. 10, or FIG. 11. The method 1400 comprises a step 1401 of sending a launching request 201 of the ACR procedure to a first network entity 100. Possibly, the first network entity 100 is the first network entity shown in FIG. 5, FIG. 6, FIG. 7, FIG. 10, or FIG. 11. The launching request 201 comprises at least an ID of the UE and an ID of the second network entity 200. The method 1400 further comprises a step 1402 of receivinga launching response 202 comprising an ACR session ID of an ACR session 101, from the first network entity 100 in response to the launching request 201.

Optionally, the launching request 201 further comprises an ACR session ID of an ACR session 101, for indicating the first network entity 100 to create the ACR session 101 for the ACR procedure.

Possibly, the method 1400 may further comprise a step of sending a modification request of the ACR procedure to the first network entity 100, wherein the modification request comprises at least the ID of the UE and the ACR session ID.

Possibly, the method 1400 may further comprise a step of sending a cancellation request of the ACR procedure to the first network entity 100, wherein the cancellation request comprises at least the ID of the UE and the ACR session ID.

FIG. 15 shows a method 1500 according to an embodiment of the disclosure. In a particular embodiment of the disclosure, the method 1500 is performed by a third network entity 300 shown in FIG. 8, FIG. 6, FIG. 10, or FIG. 11. The method 1500 comprises: a step 1501 of receiving a first ACR notification 301 from a first network entity 100, wherein the first ACR notification301 comprises an ACR session ID of an ACR session101, and indicates a start of the ACR session 101 for an ACR procedure for a UE from a source entity to a target entity. Possibly, the first network entity 100 is the first network entity shown in FIG. 5, FIG. 6, FIG. 8, FIG. 10, or FIG. 11.

The method 1500 comprises a step 1502 of initiating an ACT corresponding to the ACR procedure, and a step 1503 of creating an ACT session for the ACT.

Possibly, the method 1500 may further comprise a step of receiving a second ACR notification from the first network entity 100, wherein the second ACR notification comprise the ACR session ID of the ACR session 101, and indicate the modification of the ACR session 101; and a step of modifying the ACT session 302 corresponding to the ACR session ID of the ACR session 101.

Possibly, the method 1500 may further comprise a step of receiving a third ACR notification from the first network entity 100, wherein the third ACR notification comprise the ACR session ID of the ACR session 101, and indicate the cancellation of  the ACR session 101; and a step of cancelling the ACT session 302 corresponding to the ACR session ID of the ACR session 101.

FIG. 16 shows a method 1600 according to an embodiment of the disclosure. In a particular embodiment of the disclosure, the method 1600 is performed by a fourth network entity 400 shown in FIG. 6, FIG. 9, FIG. 10, or FIG. 11. The method 1600 comprises a step 1601 of receiving session information102 of an ACR session 101 corresponding to the ACR procedure from a first network entity 100. Possibly, the first network entity 100 is the first network entity shown in FIG. 5, FIG. 6, FIG. 9, FIG. 10, or FIG. 11. The session information 102 comprises an ACR session ID of the ACR session 101, and at least one of: information about the source entity, information about the target entity, and an ID of the UE.

Possibly, the method 1600 may further comprise a step of receiving a modification request for the ACR session 101 corresponding to the ACR procedure from the first network entity 100, wherein the modification request comprises at least one of: the ACR session ID of the ACR session 101, information about the source entity, information about the target entity, an ID of the UE, and in case of modification updated session information 102.

Possibly, the method 1600 may further comprise a step of receiving a cancellation request for the ACR session 101 corresponding to the ACR procedure from the first network entity 100, wherein the cancellation request comprises at least one of: the ACR session ID of the ACR session 101, information about the source entity, information about the target entity, an ID of the UE, and in case of modification updated session information 102.

The present disclosure has been described in conjunction with various embodiments as examples as well as implementations. However, other variations can be understood and effected by those persons skilled in the art and practicing the claimed disclosure, from the studies of the drawings, this disclosure and the independent claims. In the claims as well as in the description the word “comprising” does not exclude other elements or steps and the indefinite article “a” or “an” does not exclude a plurality. A single element or other unit may fulfill the functions of several entities or items recited in the claims. The mere fact that certain measures are recited in the mutual different dependent claims does not  indicate that a combination of these measures cannot be used in an advantageous implementation.

Furthermore, any method according to embodiments of the disclosure may be implemented in a computer program, having code means, which when run by processing means causes the processing means to execute the steps of the method. The computer program is included in a computer readable medium of a computer program product. The computer readable medium may comprise essentially any memory, such as a ROM (Read-Only Memory) , a PROM (Programmable Read-Only Memory) , an EPROM (Erasable PROM) , a Flash memory, an EEPROM (Electrically Erasable PROM) , or a hard disk drive.

Moreover, it is realized by the skilled person that embodiments of the first network entity 100, the second network entity 200, the third network entity 300and the fourth network entity 400, respectively, comprises the necessary communication capabilities in the form of e.g., functions, means, units, elements, etc., for performing the solution. Examples of other such means, units, elements and functions are: processors, memory, buffers, control logic, encoders, decoders, rate matchers, de-rate matchers, mapping units, multipliers, decision units, selecting units, switches, interleavers, de-interleavers, modulators, demodulators, inputs, outputs, antennas, amplifiers, receiver units, transmitter units, DSPs, trellis-coded modulation (TCM) encoder, TCM decoder, power supply units, power feeders, communication interfaces, communication protocols, etc. which are suitably arranged together for performing the solution.

Especially, the processor (s) of the first network entity 100, the second network entity 200, the third network entity 300and the fourth network entity 400, respectively, may comprise, e.g., one or more instances of a Central Processing Unit (CPU) , a processing unit, a processing circuit, a processor, an Application Specific Integrated Circuit (ASIC) , a microprocessor, or other processing logic that may interpret and execute instructions. The expression “processor” may thus represent a processing circuitry comprising a plurality of processing circuits, such as, e.g., any, some or all of the ones mentioned above. The processing circuitry may further perform data processing functions for inputting, outputting, and processing of data comprising data buffering and device control functions, such as call processing control, user interface control, or the like.

Claims (38)

1. A first network entity (100) for managing an application context relocation, ACR, procedure for a user equipment, UE, from a source entity to a target entity, the first network entity (100) being configured to:

   create anACR session (101) for the ACR procedure; and

   maintain session information (102) of the ACR session (101) in the first network entity (100) , wherein thesession information (102) comprisesan ACR session (101) identifier, ID, of the ACR session (101) and at least one of: informationabout the source entity, information about the target entity, and an ID of the UE.
2. The first network entity (100) according to claim 1, wherein the session information (102) further comprises one or more of the following:

   - an ID of a second network entity (200) for initiating the ACR procedure for the UE,

   - information about a third network entity (300) for initiating an application context transfer, ACTcorresponding to the ACR procedure,

   - information about a transmitter and/or receiver of the ACT,

   - a routing requirement of the receiver of the ACT,

   - an expected completion time of the ACR procedure,

   - a priority indicator of the ACR procedure.
3. The first network entity (100) according to claim 1 or 2, further configured to:

   generate the ACR session ID for the ACR session (101) , or

   obtain the ACR session ID from the second network entity (200) .
4. The first network entity (100) according to claim 2 or 3, further configured to:

   receive a launching request (201) from the second network entity (200) , wherein the launching request (201) comprises the ID of the UE, and the ID of the second network entity (200) ; and

   send a launching response (202) to the second network entity (200) , after the ACR session (101) is created, wherein the launching response (202) comprises the ACR session ID.
5. The first network entity (100) according to claim 4 and claim 2 or3, wherein the launching request (201) further comprises one or more of the following:

   - the information about the third network entity (300) ,

   - the information about the transmitter and/or receiver of the ACT,

   - the routing requirement of the receiver of the ACT,

   - the expected completion time of the ACR procedure,

   - the priority indicator of the ACR procedure,

   - the ACR session ID.
6. The first network entity (100) according to claim 5, wherein the launching request (201) further comprises a first indicator, wherein the first network entity (100) is further configured tobased on the first indicator:

   send a first ACR notification (301) to the third network entity (300) , the first ACR notification comprising the ACR session ID and indicating a start of the ACR session (101) for the ACR procedure.
7. The first network entity (100) according to one of the claims 1 to 6, further configured to:

   provide the session information (102) to at least one of the source entity and the target entity.
8. The first network entity (100) according to claim 7, further configured to:

   update thesession information (102) of the ACR session (101) ; and

   provide the updated session information to the at least one of the source entity and the target entity, wherein the updated session information indicates a modification or cancellation of the ACR procedure.
9. The first network entity (100) according to claim 8, further configured to:

   modify or cancel the ACR session (101) for the ACR procedure when receiving a modification or cancellation requestcomprising the ACR session ID, respectively, from the second network entity (200) ; and

   send a modification or cancellation responseto the second network entity (200) , wherein the modification or cancellation response indicates a status of the modification or cancellation of the ACR procedure associated with the ACR session ID.
10. The first network entity (100) according to claim 9, wherein the modification request further comprises one or more of the following:

    - an updated routing requirement of the receiver of the ACT,

    - an updated expected completion time of the ACR procedure,

    - anupdated priority indicator of the ACR procedure, and

    - information about an updated receiver of the ACT;

    and wherein the first network entity (100) is configured to update the session information (102) of the ACR session (101) based on the modification request.
11. The first network entity (100) according to claim 9 or 10, wherein the modification request further comprises a second indicator, wherein the first network entity (100) is further configured to based on the second indicator:

    send a second ACR notification to the third network entity (300) , the second ACR notificationcomprising the ACR session ID and indicating a modification of the ACR session (101) for the ACR procedure.
12. The first network entity (100) according to claim 9, wherein the cancellation request comprises one or more of the following:

    - the ID of the UE,

    - the ID of the second network entity (200) ,

    - the information about the third network entity (300) , and

    - the information about the receiver of the ACT.
13. The first network entity (100) according to claim 12, wherein the cancellation request further comprises a third indicator, wherein the first network entity (100) is further configured to base on the third indicator:

    send a third ACR notification to the third network entity (300) , the third ACR notification comprising the ACR session ID and indicating that the ACT is to be cancelled.
14. The first network entity (100) according to one of the claims 8 to 13, further configured to:

    receive a modification or cancellation confirmation, which confirms the modification or cancellation of the ACR procedure, from the at least one of the source entity and the target entity.
15. The first network entity (100) according to one of the claims 2 to 14, wherein the first network entity (100) is further configured to:

    send a retrieve request to an edge configuration server to obtain information about a fourth network entity (400) , wherein the retrieve request comprises information about a receiver or transmitter of the ACT which is registeredinto the fourth network entity (400) ; and

    receive a retrieve response from the edge configuration server, wherein the retrieve response comprises the information about the fourth network entity (400) .
16. The first network entity (100) according to claim 15, wherein the retrieve request further comprises one or more of: location information of the UE, and the ID of the UE.
17. A second network entity (200) forinitiating an application context relocation, ACR, procedure for a user equipment, UE, from a source entity to a target entity, the second network entity (200) being configured to:

    send a launching request (201) for the ACR procedure to a first network entity (100) , wherein the launching request (201) comprises at least an ID of the UE andan ID of the second network entity (200) , and

    receive a launching response (202) comprisingan ACR session identifier, ID, of an ACR session (101) , from the first network entity (100) in response to the launching request (201) .
18. The second network entity (200) according to claim 17, wherein the launching request (201) further comprises one or more of the following:

    - information about a third network entity (300) for initiating an application context transfer, ACT corresponding to the ACR procedure,

    - information about a transmitter and/or receiver of the ACT,

    - a first indicator that indicates the first network entity (100) to send afirst ACR notification (301) indicating a start of the ACR procedure to the third network entity (300) ,

    - a routing requirement of the receiver of the ACT,

    - an expected completion time of the ACR procedure,

    - a priority indicator of the ACR procedure.
19. The second network entity (200) according to claim 17 or 18, configured to:

    send a modification or cancellation request comprising the ACR session IDfor a modification or cancellation of the ACR procedure to the first network entity (100) ; and

    receive a modification or cancellation response from the first network entity (100) , wherein the modification or cancellation responseindicates a status of the modification or cancellation of the ACR procedure associated with the ACR session ID.
20. The second network entity (200) according to claim 19, wherein the modification request further comprises one or more of the following:

    - an updated routing requirement of the receiver of the ACT,

    - an updated expected completion time of the ACR procedure,

    - an updated priority indicator of the ACR procedure,

    - information about an updated receiver of the ACT,

    - a second indicator that indicates the first network entity (100) to send a second ACR notification indicating a modification of the ACR session (101) for the ACR procedure to the third network entity (300) .
21. The second network entity (200) according to claim 20, wherein the cancellation request comprises one or more of the following:

    - the ID of the UE,

    - the ID of the second network entity (200) ,

    - the information about the third network entity (300) ,

    - the information about the receiver of the ACT,

    - a third indicator that indicates the first network entity (100) to send a third ACR notification for cancelling the ACT to the third network entity (300) .
22. A third network entity (300) for initiating an application context transfer, ACT, being configured to:

    receive a firstapplication context relocation, ACR, notification (301) from a first network entity (100) , wherein the first ACR notification (301) comprises an ACR session  identifier, ID, of anACR session (101) , and indicates a start of theACR session (101) for an ACR procedure for a user equipment, UE, from a source entity to a target entity;

    initiate the ACT corresponding to the ACR procedure; and

    create an ACT session (302) for the ACT.
23. The third network entity (300) according to claim 22, furtherconfigured to:

    associate the ACT session (302) with an ACT session ID that corresponds to the ACR session ID.
24. The third network entity (300) according to claim 22 or 23, further configured to:

    receive a second ACR notification from the first network entity (100) , wherein the second ACR notification comprises the ACR session ID, and indicates a modification of the ACR session (101) for the ACR procedure.
25. The third network entity (300) according to one of the claims 22 to 24, further configured to:

    receive a third ACR notification from the first network entity (100) , wherein the third ACR notification comprises the ACR session ID, and indicates to cancel the ACT; and

    cancel the ACT session (302) corresponding to the ACT.
26. The third network entity (300) according to claim 24or 25, further configured to:

    identify the ACT session (302) based on the ACR session ID.
27. A fourth network entity (400) for managing an application context relocation, ACR, procedure for a user equipment, UE, from a source entity to a target entity, the fourth network entity (400) being configured to:

    receive session information (102) of anACR session (101) corresponding to the ACR procedure from a first network entity (100) , wherein the session information (102) comprisesan ACR session identifier, ID, of the ACR session (101) and at least one of: information about the source entity, information about the target entity, and an ID of the UE.
28. The fourth network entity (400) according to claim 27, wherein the session information (102) further comprises one or more of the following:

    - an ID of a second network entity (200) for initiating the ACR procedure for the UE,

    - information about a third network entity (300) for initiating an application context transfer, ACTcorresponding to the ACR procedure,

    - information about a transmitter and/or receiver of the ACT,

    - a routing requirement of the receiver of the ACT,

    - an expected completion time of the ACR procedure, and

    - a priority indicator of the ACR procedure.
29. The fourth network entity (400) according to claim 27 or 28, further configured to:

    receive updated session information (102) of the ACR session (101) from the first network entity (100) , wherein the updated session information (102) indicates a modification or cancellation of the ACR procedure; and

    send a modification or cancellation confirmation, which confirms the modification or cancellation of the ACR procedure, to the first network entity (100) .
30. A method (1300) performed bya first network entity (100) for managing an application context relocation, ACR, procedure for a user equipment, UE, from a source entity to a target entity, comprising:

    creating (1301) an ACR session (101) for the ACR procedure; and

    maintaining (1302) sessioninformation (102) of the ACR session (101) in the first network entity (100) , wherein the session information (102) comprisesan ACR session identifier, ID, of the ACR session (101) , and at least one of: information about the source entity, information about the target entity, and an ID of the UE.
31. The method (1300) according to claim 30, further comprises:

    modifying or cancellingtheACR session (101) .
32. A method (1400) performed by a second network entity (200) for initiating an application context relocation, ACR, procedure for a user equipment, UE, from a source entity to a target entity, comprising:

    sending (1401) a launching request (201) of the ACR procedure to a first network entity (100) , wherein the launching request (201) comprises at least an ID of the UE and an ID of the second network entity (200) , and

    receiving (1402) alaunching response (202) comprisingan ACR session identifier, ID, of an ACR session (101) , from the first network entity (100) in responseto the launching request (201) .
33. The method (1400) according to claim 32, further comprises:

    sending a modification or cancellation request comprising the ACR session ID for amodification or cancellationof the ACR procedure to thefirst network entity (100) .
34. A method (1500) performed by a third network entity (300) for initiating an application context transfer, ACT, comprising:

    receiving (1501) a first application context relocation, ACR, notification (301) from a first network entity (100) , wherein the first ACR notification (301) comprises an ACR session identifier, ID, of an ACR session (101) , and indicates a start of the ACR session (101) for an ACR procedure for a user equipment, UE, from a source entity to a target entity;

    initiating (1502) an ACT corresponding to the ACR procedure; and

    creating (1503) an ACT session (302) for the ACT.
35. The method (1500) according to claim 34, comprising:

    receiving a second or thirdACR notification from thefirst network entity (100) , wherein the second and third ACR notification comprise the ACR session ID of theACR session (101) , and indicate respectivelythe modificationor cancellation of the ACR session (101) ;

    respectively modifying or cancellingthe ACT session corresponding to the ACR session ID of theACR session (101) .
36. A method (1600) performed by a fourth network entity (400) for managing an application context relocation, ACR, procedure for a user equipment, UE, from a source entity to a target entity, comprising:

    receiving (1601) session information (102) of an ACR session (101) corresponding to the ACR procedure from a first network entity (100) , wherein the session information  (102) comprisesan ACR session identifier, ID, of the ACR session (101) , and at least one of: information about the source entity, information about the target entity, and an ID of the UE.
37. The method (1600) according to claim 36, comprising:

    receiving a modification or cancellation request for theACR session (101) corresponding to the ACR procedure from thefirst network entity (100) , wherein the modification or cancellation request comprises at least one of: the ACR session ID of the ACR session (101) , information about the source entity, information about the target entity, an ID of the UE, and in case of modificationupdatedsession information (102) .
38. A computer program product comprising a program code for carrying out, when implemented on a processor, the method according to one of theclaims30to 37.

Images