WO2025214906A1

WO2025214906A1 - Methods and apparatuses for application context relocation

Info

Publication number: WO2025214906A1
Application number: PCT/EP2025/059317
Authority: WO
Inventors: Wenliang Xu
Original assignee: Telefonaktiebolaget LM Ericsson AB
Current assignee: Telefonaktiebolaget LM Ericsson AB
Priority date: 2024-04-08
Filing date: 2025-04-04
Publication date: 2025-10-16
Anticipated expiration: 2026-10-08

Abstract

Methods and apparatuses for application context relocation (ACR) are disclosed According to an embodiment, a first edge enabler server (EES) receives or sends a request for discovering one or more candidates of a second edge application server (EAS), in an ACR for one or more group members in an application group from a first EAS to the second EAS. The request comprises an identifier (ID) of the application group. The first EES sends or receives a response to the request.

Description

P111033W002

METHODS AND APPARATUSES FOR APPLICATION CONTEXT RELOCATION

Technical Field

[0001] Embodiments of the disclosure generally relate to communication, and, more particularly, to methods and apparatuses for application context relocation (ACR).

Background

[0002] This section introduces aspects that may facilitate better understanding of the present disclosure. Accordingly, the statements of this section are to be read in this light and are not to be understood as admissions about what is in the prior art or what is not in the prior art.

[0003] Edge computing is a concept that enables services to be hosted close to the service consumers and provides benefits such as efficient service delivery with significant reduction in end-to-end latency and decreased load on the transport network. The benefits of edge computing will strengthen the promise of 5th generation (5G) and expand the prospects for several new and enhanced use cases - including virtual and augmented reality, Internet of things (loT), industrial loT, autonomous driving, real-time multiplayer gaming, etc.

[0004] The 3rd generation partnership project (3GPP) SA6 initiated normative specification work on the architecture for enabling edge applications (EDGEAPP) from Release 17. The objective of the work is to define an enabling layer to facilitate communication between the application clients (ACs) running on the user equipment (UE) and the edge application servers (EASs) deployed on the edge data network (EDN). This includes aspects of service provisioning and EAS discovery. In addition, the work aims to provide support services such as application context transfer between EASs for service continuity, service enablement and capability exposure application programming interfaces (APIs) towards the EAS. The normative specification for EDGEAPP is written in 3GPP technical specification (TS) 23.558 V19.1.0. In release 18, more functions are added, e.g., application roaming, edge computing federation, service continuity between edge and cloud.

Summary

[0005] This summary is provided to introduce a selection of concepts in a simplified form that are further described below in the detailed description. This summary is not intended to identify key features or essential features of the claimed subject matter, nor is it intended to be used to limit the scope of the claimed subject matter.

[0006] One of the objects of the disclosure is to provide an improved solution for application context relocation (ACR). In particular, one of the problems to be solved by the disclosure is that currently there is no solution about how a common edge application server (EAS) serving a group of user equipments (UEs) in an edge data network (EDN) can be relocated to another common EAS.

[0007] According to a first aspect of the disclosure, there is provided a method at a first EAS. The method may comprise sending, to a first edge enabler server (EES), a first request for discovering one or more candidates of a second EAS, in an ACR for one or more group members in an application group from the first EAS to the second EAS. The first request may comprise an identifier (ID) of the application group. The method may further comprise receiving, from the first EES, a first response to the first request.

[0008] With the above first aspect, the ACR between common EASs for one or more group members in an application group can be distinguished from the conventional ACR so that it is possible to ensure the uniqueness of the common EAS for the application group in corresponding EDN. [0009] In an embodiment of the disclosure, the first request may further comprise a list of UE IDs in the application group.

[0010] In an embodiment of the disclosure, the method may further comprise sending, to the first EES, a second request for subscribing to a notification of an ACR management event. A type of the subscribed ACR management event may be ACR monitoring event or ACR facilitation event, and the second request may comprise the ID of the application group. The method may further comprise receiving, from the first EES, a second response to the second request.

[0011] In an embodiment of the disclosure, the method may further comprise sending, to the first EES, a third request for declaring an EAS selected as the second EAS. The third request may comprise a list of UE IDs in the application group. The method may further comprise receiving, from the first EES, a third response to the third request.

[0012] In an embodiment of the disclosure, the ACR from the first EAS to the second EAS may be one of: an ACR decided by the first EAS; and an ACR decided by the first EES.

[0013] According to a second aspect of the disclosure, there is provided a method at a first EES. The method may comprise receiving or sending a request for discovering one or more candidates of a second EAS, in an ACR for one or more group members in an application group from a first EAS to the second EAS. The request may comprise an ID of the application group. The method may further comprise sending or receiving a response to the request.

[0014] With the above second aspect, the ACR between common EASs for one or more group members in an application group can be distinguished from the conventional ACR so that it is possible to ensure the uniqueness of the common EAS for the application group in corresponding EDN.

[0015] In an embodiment of the disclosure, the request may further comprise a list of UE IDs in the application group.

[0016] In an embodiment of the disclosure, the request may be a first request received from the first EAS, and the response may be a first response sent to the first EAS.

[0017] In an embodiment of the disclosure, the request may be a fifth request sent to a second EES, and the response may be a fifth response received from the second EES.

[0018] In an embodiment of the disclosure, the method may further comprise determining one or more candidates of the second EAS based on the list of UE IDs in the application group.

[0019] In an embodiment of the disclosure, at least one EAS may be determined from one or more registered EASs in a first EDN corresponding to the first EES and one or more existing common EASs in one or more second EDNs, based on the list of UE IDs in the application group, so that each of the at least one EAS is a unique common EAS for the application group in corresponding EDN.

[0020] In an embodiment of the disclosure, determining the at least one EAS may comprise one or more of: when all UEs in the application group is within an overlapping area between a first service area of the first EDN and second service areas of the one or more second EDNs, checking whether there is an existing common EAS for the application group in the second EDN corresponding to the overlapping area; when there is an existing common EAS for the application group in the second EDN, determining an EAS from the one or more registered EASs in the first EES and the existing common EAS; when there is no existing common EAS for the application group in the second EDN, determining an EAS from the one or more registered EASs in the first EES; when at least one UE in the application group is not within the overlapping area, determining an EAS from the one or more registered EASs in the first EES; for a first subset of all UEs in the application group that is within at least one overlapping area with at least one second EDN, when there is at least one existing common EAS for the application group in the at least one second EDN, determining, for the first subset, one of the at least one existing common EAS; and for a second subset of all UEs in the application group that is not within the overlapping area, determining, for the second subset, an EAS from the one or more registered EASs in the first EES.

[0021] In an embodiment of the disclosure, the method may further comprise, when a registered EAS in the first EES is determined as a common EAS for the application group, update common EAS information for the application group at a repository entity based on information about the registered EAS.

[0022] In an embodiment of the disclosure, the fifth response may comprise one or more EASs discovered by the second EES. The method may further comprise determining, as a common EAS for the application group, one of the one or more discovered EASs. The method may further comprise storing information about the determined common EAS to a repository entity.

[0023] In an embodiment of the disclosure, the method may further comprise receiving, from the repository entity, information about an existing common EAS for the application group. The existing common EAS may be different from the determined common EAS.

[0024] In an embodiment of the disclosure, the method may further comprise receiving, from the first EAS, a second request for subscribing to a notification of an ACR management event. A type of the subscribed ACR management event may be ACR monitoring event or ACR facilitation event, and the second request may comprise the ID of the application group. The method may further comprise sending, to the first EAS, a second response to the second request.

[0025] In an embodiment of the disclosure, the method may further comprise receiving, from the first EAS, a third request for declaring an EAS selected as the second EAS. The third request may comprise a list of UE IDs in the application group. The method may further comprise sending, to the first EAS, a third response to the third request.

[0026] In an embodiment of the disclosure, the method may further comprise one or more of: sending, to each of edge enabler clients (EECs) for UEs indicated in the list of UE IDs, information about the selected EAS. The method may further comprise sending, to each of the EECs for the UEs indicated in the list of UE IDs, a notification about an ACR complete event.

[0027] In an embodiment of the disclosure, the method may further comprise sending, to a repository entity, a fourth request for updating common EAS information at the repository entity. The fourth request may comprise the ID of the application group. The method may further comprise receiving, from the repository entity, a fourth response to the fourth request.

[0028] In an embodiment of the disclosure, the fourth request may further comprise one or more of: an ID of a common EAS; an endpoint of the common EAS; an ID of the first EES; information about an EDN where the common EAS resides; and security credentials which result from a successful authorization for an edge computing service.

[0029] In an embodiment of the disclosure, a fourth response to the fourth request may comprise one or more of: a first indicator indicating that the fourth request was successful, or a second indicator indicating that the fourth request has failed; and a third indicator indicating a failure cause when the fourth request has failed. [0030] In an embodiment of the disclosure, the repository entity is an edge configuration server edge repository (ECS-ER).

[0031] In an embodiment of the disclosure, the ACR from the first EAS to the second EAS may be one of: an ACR decided by the first EAS; and an ACR decided by the first EES.

[0032] According to a third aspect of the disclosure, there is provided a method at a second EES. The method may comprise receiving, from a first EES, a fifth request for discovering one or more candidates of a second EAS, in an ACR for one or more group members in an application group from a first EAS to the second EAS. The fifth request may comprise an ID of the application group. The method may further comprise sending, to the first EES, a fifth response to the fifth request.

[0033] With the above third aspect, the ACR between common EASs for one or more group members in an application group can be distinguished from the conventional ACR so that it is possible to ensure the uniqueness of the common EAS for the application group in corresponding EDN.

[0034] In an embodiment of the disclosure, the fifth request may further comprise a list of UE IDs in the application group.

[0035] In an embodiment of the disclosure, the method may further comprise determining one or more candidates of the second EAS based on the list of UE IDs in the application group.

[0036] According to a fourth aspect of the disclosure, there is provided a repository entity. The method may comprise receiving, from a first EES, a fourth request for updating common EAS information at the repository entity, in an ACR for one or more group members in an application group from a first EAS to a second EAS. The fourth request may comprise an ID of the application group. The method may further comprise sending, to the first EES, a fourth response to the fourth request.

[0037] With the above fourth aspect, a new procedure is introduced to support updating of common EAS information so as to ensure the uniqueness of the common EAS for the application group in corresponding EDN.

[0038] In an embodiment of the disclosure, the method may further comprise one or more of: determining whether there is a stored EAS serving the application group within a same EDN; when there is a stored EAS serving the application group within the same EDN, updating information about the stored EAS based on common EAS information indicated in the fourth request; and when there is no stored EAS serving the application group within the same EDN, rejecting the fourth request.

[0039] In an embodiment of the disclosure, the fourth request may further comprise one or more of: an ID of a common EAS; an endpoint of the common EAS; an ID of the first EES; information about an EDN where the common EAS resides; and security credentials which result from a successful authorization for an edge computing service.

[0040] In an embodiment of the disclosure, a fourth response to the fourth request may comprise one or more of: a first indicator indicating that the fourth request was successful, or a second indicator indicating that the fourth request has failed; and a third indicator indicating a failure cause when the fourth request has failed.

[0041] In an embodiment of the disclosure, the repository entity may be an ECS-ER.

[0042] According to a fifth aspect of the disclosure, there is provided a first EAS. The first EAS may comprise at least one processor and at least one memory. The at least one memory may contain instructions executable by the at least one processor, whereby the first EAS may be operative to send, to a first EES, a first request for discovering one or more candidates of a second EAS, in an ACR for one or more group members in an application group from the first EAS to the second EAS. The first request may comprise an ID of the application group. The first EAS may be further operative to receive, from the first EES, a first response to the first request.

[0043] In an embodiment of the disclosure, the first EAS may be operative to perform the method according to the above first aspect.

[0044] According to a sixth aspect of the disclosure, there is provided a first EES. The first EES may comprise at least one processor and at least one memory. The at least one memory may contain instructions executable by the at least one processor, whereby the first EES may be operative to receive or send a request for discovering one or more candidates of a second EAS, in an ACR for one or more group members in an application group from a first EAS to the second EAS. The request may comprise an ID of the application group. The first EES may be further operative to send or receive a response to the request.

[0045] In an embodiment of the disclosure, the first EES may be operative to perform the method according to the above second aspect.

[0046] According to a seventh aspect of the disclosure, there is provided a second EES. The second EES may comprise at least one processor and at least one memory. The at least one memory may contain instructions executable by the at least one processor, whereby the second EES may be operative to receive, from a first EES, a fifth request for discovering one or more candidates of a second EAS, in an ACR for one or more group members in an application group from a first EAS to the second EAS. The fifth request may comprise an ID of the application group. The second EES may be further operative to send, to the first EES, a fifth response to the fifth request.

[0047] In an embodiment of the disclosure, the second EES may be operative to perform the method according to the above third aspect.

[0048] According to an eighth aspect of the disclosure, there is provided a repository entity. The repository entity may comprise at least one processor and at least one memory. The at least one memory may contain instructions executable by the at least one processor, whereby the repository entity may be operative to receive, from a first EES, a fourth request for updating common EAS information at the repository entity, in an ACR for one or more group members in an application group from a first EAS to a second EAS. The fourth request may comprise an ID of the application group. The repository entity may be further operative to send, to the first EES, a fourth response to the fourth request.

[0049] In an embodiment of the disclosure, the repository entity may be operative to perform the method according to the above fourth aspect.

[0050] According to a ninth aspect of the disclosure, there is provided a computer program product. The computer program product may comprise instructions which when executed by at least one processor, cause the at least one processor to perform the method according to any of the above first to fourth aspects.

[0051] According to a tenth aspect of the disclosure, there is provided a computer readable storage medium. The computer readable storage medium may store thereon instructions which when executed by at least one processor, cause the at least one processor to perform the method according to any of the above first to fourth aspects.

[0052] According to an eleventh aspect of the disclosure, there is provided a first EAS. The first EAS may comprise a sending module for sending, to a first EES, a first request for discovering one or more candidates of a second EAS, in an ACR for one or more group members in an application group from the first EAS to the second EAS. The first request may comprise an ID of the application group. The first EAS may further comprise a reception module for receiving, from the first EES, a first response to the first request.

[0053] According to a twelfth aspect of the disclosure, there is provided a first EES. The first EES may comprise a first transceiving module for receiving or sending a request for discovering one or more candidates of a second EAS, in an ACR for one or more group members in an application group from a first EAS to the second EAS. The request may comprise an ID of the application group. The first EES may further comprise a second transceiving module for sending or receiving a response to the request.

[0054] According to a thirteenth aspect of the disclosure, there is provided a second EES. The second EES may comprise a reception module for receiving, from a first EES, a fifth request for discovering one or more candidates of a second EAS, in an ACR for one or more group members in an application group from a first EAS to the second EAS. The fifth request may comprise an ID of the application group. The second EES may further comprise a sending module for sending, to the first EES, a fifth response to the fifth request.

[0055] According to a fourteenth aspect of the disclosure, there is provided a repository entity. The repository entity may comprise a reception module for receiving, from a first EES, a fourth request for updating common EAS information at the repository entity, in an ACR for one or more group members in an application group from a first EAS to a second EAS. The fourth request may comprise an ID of the application group. The repository entity may further comprise a sending module for sending, to the first EES, a fourth response to the fourth request.

[0056] According to a fifteenth aspect of the disclosure, there is provided a method implemented in a communication system. The communication system may include any two or more of: a first EAS, a first EES, a second EES and a repository entity. The method may comprise any two or more of: steps of the method according to the above first aspect, steps of the method according to the above second aspect, steps of the method according to the above third aspect, and steps of the method according to the above fourth aspect.

[0057] According to a sixteenth aspect of the disclosure, there is provided a communication system. The communication system may include any two or more of: a first EAS according to the above fifth or eleventh aspect, a first EES according to the above sixth or twelfth aspect, a second EES according to the above seventh or thirteenth aspect, and a repository entity according to the above eighth or fourteenth aspect.

[0058] According to some embodiment(s) of the disclosure, the ACR between common EASs for one or more group members in an application group can be distinguished from the conventional ACR so that it is possible to ensure the uniqueness of the common EAS for the application group in corresponding EDN. Moreover, a new procedure is introduced to support updating of common EAS information so as to ensure the uniqueness of the common EAS for the application group in corresponding EDN.

Brief Description of the Drawings

[0059] These and other objects, features and advantages of the disclosure will become apparent from the following detailed description of illustrative embodiments thereof, which are to be read in connection with the accompanying drawings.

[0060] FIG. 1 is a diagram illustrating an architecture for enabling edge applications;

[0061] FIG. 2 is a flowchart illustrating a service provisioning procedure;

[0062] FIG. 3 is a flowchart illustrating EAS discovery procedure; [0063] FIGs. 4A and 4B are diagrams illustrating a first exemplary scenario of common EAS relocation;

[0064] FIG. 5 is a diagram illustrating a second exemplary scenario of common EAS relocation;

[0065] FIGs. 6A and 6B are diagrams illustrating a third exemplary scenario of common EAS relocation;

[0066] FIGs. 7A and 7B are flowcharts each illustrating a process according to an embodiment of the disclosure;

[0067] FIGs. 8A and 8B are flowcharts each illustrating a process according to an embodiment of the disclosure;

[0068] FIG. 9 is a flowchart illustrating a method performed by a first EAS according to an embodiment of the disclosure;

[0069] FIG. 10 is a flowchart illustrating a method performed by a first EAS according to an embodiment of the disclosure;

[0070] FIG. 11 is a flowchart illustrating a method performed by a first EAS according to an embodiment of the disclosure;

[0071] FIG. 12 is a flowchart illustrating a method performed by a first EES according to an embodiment of the disclosure;

[0072] FIG. 13 is a flowchart illustrating a method performed by a first EES according to an embodiment of the disclosure;

[0073] FIG. 14 is a flowchart for explaining the method of FIG. 13;

[0074] FIG. 15 is a flowchart for explaining the method of FIG. 13;

[0075] FIG. 16 is a flowchart illustrating a method performed by a first EES according to an embodiment of the disclosure;

[0076] FIG. 17 is a flowchart illustrating a method performed by a first EES according to an embodiment of the disclosure;

[0077] FIG. 18 is a flowchart illustrating a method performed by a first EES according to an embodiment of the disclosure;

[0078] FIG. 19 is a flowchart illustrating a method performed by a first EES according to an embodiment of the disclosure;

[0079] FIG. 20 is a flowchart illustrating a method performed by a first EES according to an embodiment of the disclosure;

[0080] FIG. 21 is a flowchart illustrating a method performed by a first EES according to an embodiment of the disclosure;

[0081] FIG. 22 is a flowchart illustrating a method performed by a second EES according to an embodiment of the disclosure;

[0082] FIG. 23 is a flowchart illustrating a method performed by a second EES according to an embodiment of the disclosure;

[0083] FIG. 24 is a flowchart illustrating a method performed by a repository entity according to an embodiment of the disclosure; [0084] FIG. 25 is a flowchart illustrating a method performed by a repository entity according to an embodiment of the disclosure;

[0085] FIG. 26 is a flowchart illustrating a process of source EAS (S-EAS) decided ACR;

[0086] FIG. 27 is a flowchart illustrating a procedure for discovering target EAS (T-EAS);

[0087] FIG. 28 is a flowchart illustrating a procedure for subscribing to notification of ACR management event;

[0088] FIG. 29 is a flowchart illustrating a procedure for updating common EAS information;

[0089] FIG. 30 is a flowchart illustrating a process of source EES (S-EES) executed ACR;

[0090] FIG. 31 is a block diagram illustrating an apparatus suitable for use in practicing some embodiments of the disclosure;

[0091] FIG. 32 is a block diagram illustrating a first EAS according to an embodiment of the disclosure;

[0092] FIG. 33 is a block diagram illustrating a first EES according to an embodiment of the disclosure;

[0093] FIG. 34 is a block diagram illustrating a second EES according to an embodiment of the disclosure; and

[0094] FIG. 35 is a block diagram illustrating a repository entity according to an embodiment of the disclosure.

Detailed Description

[0095] For the purpose of explanation, details are set forth in the following description in order to provide a thorough understanding of the embodiments disclosed. It is apparent, however, to those skilled in the art that the embodiments may be implemented without these specific details or with an equivalent arrangement.

[0096] FIG. 1 is Figure 6.2-4 of 3GPP TS 23.558 V19.1.0 and illustrates the basic architecture for enabling edge applications. As shown in FIG. 1 , the edge data network (EDN) is a local data network. Edge application server(s) (EAS(s)) and the edge enabler server (EES) are contained within the EDN. The edge configuration server (ECS) provides configurations related to the EES, including details of the EDN hosting the EES. The user equipment (UE) contains application client(s) (AC(s)) and the edge enabler client (EEC). The EAS(s), the EES and the ECS can interact with the 3GPP core network. When service enabler layer architecture (SEAL) notification management service is used, the EES and the ECS interacts with the SEAL notification management server and the SEAL EEC interacts with SEAL notification management client.

[0097] EDGE-1 reference point enables interactions between the EES and the EEC. It supports: a) registration and de-registration of the EEC to the EES; b) retrieval and provisioning of EAS configuration information; and c) discovery of EASs available in the EDN. EDGE-4 reference point enables interactions between the ECS and the EEC. It supports: a) provisioning of edge configuration information to the EEC.

[0098] FIG. 2 is Figure 8.3.3.2.2-1 of 3GPP TS 23.558 V19.1.0 and illustrates the request-response model for service provisioning. At step 1 , the EEC sends a service provisioning request to the ECS. At step 2, the ECS processes the request. At step 3, the ECS responds to the EEC's request with a service provisioning response. More details can be found from clause 8.3.3 of 3GPP TS 23.558 V19.1.0. Note that the EEC can also be notified with service provisioning information change in subscribe-notify model as described in clause 8.3.3.2.3 of 3GPP TS 23.558 V19.1 .0. [0099] FIG. 3 is Figure 8.5.2.2-1 of 3GPP TS 23.558 V19.1.0 and illustrates the request-response model for EAS discovery. At step 1 , the EEC sends an EAS discovery request to the EES. At step 2, the EES checks if the EEC is authorized to discover the requested EAS(s). At step 3, if the processing of the request was successful, the EES sends an EAS discovery response to the EEC. More details can be found from clause 8.5 of 3GPP TS 23.558 V19.1.0. Note that the EEC can also be notified with EAS information change in subscribe-notify model as described in clause 8.5.2.3 of 3GPP TS 23.558 V19.1.0.

[00100] With respect to common EAS discovery and selection, S6-240772 provides end-to-end (E2E) procedure about how a common EAS is discovered and selected for a group of UEs.

[00101] In Rel-18, common EAS discovery and selection is only supported for initial EAS discovery. There is currently no solution about how a common EAS serving a group of UEs in an EDN can be relocated to another common EAS.

[00102] Therefore, how to support common EAS relocation needs to be specified. The inventors of the present disclosure find that the common EAS relocation may happen when some application group members in an application group move to a new EDN coverage area, and their application sessions will be relocated from the old common EAS to a new common EAS. The common EAS relocation may also happen when a common EAS is relocated due to maintenance reason (e.g. graceful shutdown) or overload reason, which can be detected by source EAS (S-EAS) or source EES (S-EES).

[00103] In the first case mentioned above, the application session is relocated individually. And in the second case mentioned above, the application sessions are relocated together. Correspondingly, it would be desirable for edge enabler layer (EEL) to distinguish different need and facilitate the relocation.

[00104] The present disclosure proposes an improved solution for application context relocation (ACR). The solution may be applicable to the architecture or communication system shown in FIG. 1. Note that the term "communication system” refers to a system following any suitable communication standards, such as the first generation (1 G), 2G, 2.5G, 2.75G, 3G, 4G, 4.5G, 5G communication protocols, and/or any other protocols either currently known or to be developed in the future. Furthermore, the communications between a terminal device and a network entity (or a network function) in the communication system may be performed according to any suitable generation communication protocols, including, but not limited to, 1 G, 2G, 2.5G, 2.75G, 3G, 4G, 4.5G, 5G communication protocols, and/or any other protocols either currently known or to be developed in the future. The specific terms used herein do not limit the present disclosure only to the communication system related to the specific terms, which however can be more generally applied to other communication systems. The network entity (or function) in the communication system may be implemented either as a network element on a dedicated hardware, as a software instance running on a dedicated hardware, or as a virtualized function instantiated on an appropriate platform, e.g. on a cloud infrastructure.

[00105] The term UE or terminal device may also be referred to as, for example, device, access terminal, mobile station, mobile unit, subscriber station, or the like. It may refer to any end device that can access a wireless communication network and receive services therefrom. By way of example and not limitation, the UE or terminal device may include a portable computer, an image capture terminal device such as a digital camera, a gaming terminal device, a music storage and playback appliance, a mobile phone, a cellular phone, a smart phone, a tablet, a wearable device, a personal digital assistant (PDA), or the like. [00106] In an Internet of things (loT) scenario, a UE or terminal device may represent a machine or other device that performs monitoring and/or measurements, and transmits the results of such monitoring and/or measurements to another UE or terminal device and/or a network equipment. In this case, the UE or terminal device may be a machine-to-machine (M2M) device, which may, in a 3GPP context, be referred to as a machine-type communication (MTC) device. Particular examples of such machines or devices may include sensors, metering devices such as power meters, industrial machineries, bikes, vehicles, or home or personal appliances, e.g. refrigerators, televisions, personal wearables such as watches, and so on.

[00107] Hereinafter, the solution will be described in detail with reference to FIG. 4A to FIG. 35.

[00108] FIGs. 4A and 4B illustrate a first exemplary scenario of common EAS relocation in which an embodiment of the present disclosure is applicable. The first scenario is due to individual UE movement. FIG. 4A illustrates the status before a UE (e.g. UE#3) moves, and FIG. 4B illustrates the status after the UE (e.g. UE#3) moves. Suppose UE#1~ UE#4 are in the same application group. In FIG. 4A, initially, UE#1, UE#2 and UE#3 are connected to common EAS#1 in EDN-A and UE#4 is connected to common EAS#2 in EDN-B. EAS#1 in EDN-A and EAS#2 in EDN-B synchronize information with each other.

[00109] In FIG. 4B, after UE#3 moves to EDN-B coverage area, its application session is relocated with common EAS#2 in EDN-B. As a result, UE#1 and UE#2 are connected to common EAS#1 in EDN-A, and UE#3 and UE#4 are connected to common EAS#2 in EDN-B.

[00110] FIG. 5 illustrates a second exemplary scenario of common EAS relocation in which an embodiment of the present disclosure is applicable. In the second scenario, common EAS relocation happens within the same EDN due to maintenance or overload in the original EAS. As shown in FIG. 5, common EAS for UE#1 , UE#2 and UE#3 are relocated from EAS#1 to EAS#2 in the same EDN due to maintenance or overload in EAS#1.

[00111] FIGs. 6A and 6B illustrates a third exemplary scenario of common EAS relocation in which an embodiment of the present disclosure is applicable. In the third scenario, the common EAS is relocated to a different EDN due to maintenance or overload in the original EAS. FIG. 6A illustrates the status before relocation and FIG. 6B illustrates the status after relocation. In FIG. 6A, UE#1 and UE#2 are in the overlapping area of EDN-A and EDN-B, and they are connected to common EAS#1 in EDN-A. UE#3 and UE#4 are connected to common EAS#2 in EDN-B.

[00112] In FIG. 6B, since there is an existing common EAS in EDN-B (which is EAS#2), UE#1 and UE#2 are connected to common EAS#2. Note that instead of connecting UE#1 and UE#2 to common EAS#2 in EDN- B, a new EAS (locally registered in EES of EDN-A) in EDN-A can be used as common EAS for UE#1 and UE#2 because adding more UEs to EAS#2 will probably lead to EAS#2 overload.

[00113] FIGs. 7A and 7B are flowcharts each illustrating a process according to an embodiment of the disclosure. As shown, there are five entities involved in the process: an EEC, a first EAS, a first EES, a second EES and a repository entity. The process may be at least part of an ACR for one or more group members in an application group from the first EAS to the second EAS. Thus, the EEC may be in a UE which is a group member of the application group. Although one EEC is shown, there may be multiple EECs involed in the process, and these multiple EECs may be in corresponding UEs which are group members of the application group. The first EAS may be a source EAS (S-EAS) serving the UE(s). The first EES may be a source EES (S-EES) serving the UE(s). The second EES may be a target EES (T-EES). The second EAS, which will be also mentioned below, may be a target EAS (T-EAS). The repository entity may be an ECS edge repository (ECS-ER) or any other suitable entity having similar functionality. For example, in a case where ECS-ER is not employed, every EES in the same EDN may synchronize with each other to act as the ECS-ER. The processes of FIGs. 7A and 7B relates to an ACR decided by the first EAS. The process of FIG. 7A may be applicable to the above first scenario and the process of FIG. 7B may be applicable to the above second and third scenarios. Note that only those blocks relevant to the present disclosure are shown in FIGs. 7A and 7B and some blocks involved in the ACR may be omitted so as not to obscure the principle of the present disclosure.

[00114] In the process of FIG. 7A, at block 701 , the first EAS sends, to the first EES, a second request for subscribing to a notification of an ACR management event. A type of the subscribed ACR management event is ACR monitoring event, and the second request comprises an ID of the application group. With the ID of the application group, the first EES can know that the UE, for which the notification of the ACR management event is subscribed, is a group member of the application group. Accordingly, when needing to determine a second EAS for the UE (e.g. when the UE moves to a different EDN), the first EES can determine a common EAS for the UE, as the second EAS. At block 702, the first EES sends, to the first EAS, a second response to the second request.

[00115] Since the ACR monitoring event is subscribed, the first EES may check whether the UE moves to a different EDN, based on detected user plane path change report sent from the 3GPP core network. If the UE moves to a different EDN, the first EES may check whether a second EAS is available in the different EDN, as described in steps 2-4 of clause 8.8.3.2 of 3GPP TS 23.558 V19.1 .0.

[00116] Specifically, if the first EES cannot find a second EAS in the cached or registered information, the first EES may retrieve the address of a second EES from an ECS at step 2 of clause 8.8.3.2 of 3GPP TS 23.558 V19.1.0. Then, at block 703 (which is step 3 of clause 8.8.3.2 of 3GPP TS 23.558 V19.1.0), the first EES may send, to the second EES, a fifth request for discovering one or more candidates of the second EAS. The fifth request comprises the ID of the application group. With the ID of the application group, the second EES can know that a common EAS needs to be discovered. At block 704 (which is step 4 of clause 8.8.3.2 of 3GPP TS 23.558 V19.1.0), the second EES may send, to the first EES, a fifth response to the fifth request. The fifth response may comprise one or more EASs discovered by the second EES. The first EES may determine, as a common EAS for the application group, one of the one or more discovered EASs.

[00117] At block 705, the first EES may send, to the repository entity, a storage request for storing information about the determined common EAS to the repository entity. At block 706, the repository entity may send, to the first EES, a storage response to the storage request. If there is no existing common EAS for the application group in the different EDN, the determined common EAS may be used as the second EAS. If there is an existing common EAS for the application group in the different EDN and the existing common EAS is different from the determined common EAS, the repository entity may return information about the existing common EAS to the first EES in the storage response. Then, the returned existing common EAS may be used as the second EAS for the application group.

[00118] At block 707, the first EES sends, to the first EAS, an ACR management notification. The ACR management notification may comprise information about the second EAS, to indicate that ACR may be required. At block 708, the first EAS sends, to the first EES, an acknowledgement to the notification. At block 709, the first EAS may make the decision to perform the ACR. Then, steps 4-10 of clause 8.8.2.4 of 3GPP TS 23.558 V19.1.0 may be performed to complete the ACR. [00119] In the process of FIG. 7B, the first EAS may detect that an ACR is required for an application group due to maintenance reason or overload reason. Then, at block 710, the first EAS may make the decision to perform the ACR. At block 711 , the first EAS sends, to the first EES, a first request for discovering one or more candidates of a second EAS. The first request comprises an ID of the application group. Since the ACR is initiated due to maintenance reason or overload reason, the first request further comprises a list of UE IDs in the application group. With the list of UE IDs in the application group, the first EES may consider resource consumption of the UEs indicated in the list of UE IDs when determining a second EAS for the application group.

[00120] Thus, at block 712, the first EES determines one or more candidates of the second EAS based on the list of UE IDs in the application group. As mentioned above, if the first EES cannot find a second EAS in the cached or registered information, the first EES may retrieve information from the ECS. For instance, information about one or more second EESs and information about one or more second EDNs corresponding to the one or more second EESs may be retrieved. Then, at least one EAS may be determined from one or more registered EASs in a first EDN corresponding to the first EES and one or more existing common EASs in the one or more second EDNs, based on the list of UE IDs in the application group, so that each of the at least one EAS is a unique common EAS for the application group in corresponding EDN. More details about the determination will be described later with reference to FIGs. 14 and 15.

[00121] If a registered EAS in the first EES is determined as a common EAS for the application group, the first EES may send, to the repository entity, a fourth request for updating common EAS information at the repository entity at block 713. The fourth request comprises the ID of the application group. The fourth request may further comprise one or more of: an ID of the common EAS; an endpoint of the common EAS; an ID of the first EES; information about an EDN where the common EAS resides; and security credentials which result from a successful authorization for an edge computing service. With the ID of the application group, the repository entity may determine whether there is a stored EAS serving the application group within a same EDN. If there is a stored EAS serving the application group within the same EDN, the repository entity may update information about the stored EAS based on common EAS information indicated in the fourth request. If there is no stored EAS serving the application group within the same EDN, the repository entity may reject the fourth request. At block 714, the repository entity may send, to the first EES, a fourth response to the fourth request. The fourth response may comprise one or more of: a first indicator indicating that the fourth request was successful, or a second indicator indicating that the fourth request has failed; and a third indicator indicating a failure cause when the fourth request has failed. With this newly introduced procedure for updating common EAS information, the uniqueness of the common EAS for the application group in corresponding EDN can be ensured.

[00122] If the first EES cannot find the at least one EAS at block 712, the first EES may send to the second EES, a fifth request for discovering one or more candidates of the second EAS at block 715. The fifth request comprises the ID of the application group. Since the ACR is initiated due to maintenance reason or overload reason, the fifth request further comprises the list of UE IDs in the application group. Accordingly, at block 716, the second EES determines one or more candidates of the second EAS based on the list of UE IDs in the application group. At block 717, the second EES may send, to the first EES, a fifth response to the fifth request. The fifth response may comprise one or more EASs discovered by the second EES. The first EES may determine, as a common EAS for the application group, one of the one or more discovered EASs at block 718. [00123] At block 719, the first EES may send, to the repository entity, a storage request for storing information about the determined common EAS to the repository entity. At block 720, the repository entity may send, to the first EES, a storage response to the storage request. Similar to block 706, if there is an existing common EAS for the application group in the second EDN and the existing common EAS is different from the determined common EAS, the repository entity may return information about the existing common EAS to the first EES in the storage response. Then, the returned existing common EAS may be used as the second EAS for the application group. If there is no existing common EAS for the application group in the second EDN, the determined common EAS may be used as the second EAS.

[00124] At block 721 , the first EES sends, to the first EAS, a first response to the first request. The first response may comprise information about the second EAS. At block 722, the first EAS sends, to the first EES, a third request for declaring an EAS selected as the second EAS. The third request comprises the list of UE IDs in the application group. With the third request, the second EAS whose information is sent at block 721 is confirmed by the first EAS so as to trigger subsequent operations of the ACR. With the list of UE IDs in the application group, the first EES can know that the ACR is to be performed for a group of UEs, and thus, batch processing needs to performed for these UEs. At block 723, the first EES sends, to the first EAS, a third response to the third request.

[00125] Since batch processing needs to be performed, the first EES sends, to each of EECs for UEs indicated in the list of UE IDs, information about the selected EAS at block 724. The first EES also sends, to each of the EECs for the UEs indicated in the list of UE IDs, a notification about an ACR complete event at block 725 when the ACR is completed.

[00126] FIGs. 8A and 8B are flowcharts each illustrating a process according to an embodiment of the disclosure. The processes of FIGs. 8A and 8B are similar to the processes of FIGs. 7A and 7B. The main differences between them lie in that the processes of FIGs. 8A and 8B relate to an ACR decided by the first EES. The process of FIG. 8A may be applicable to the above first scenario and the process of FIG. 8B may be applicable to the above second and third scenarios. Note that only those blocks relevant to the present disclosure are shown in FIGs. 8A and 8B and some blocks involved in the ACR may be omitted so as not to obscure the principle of the present disclosure.

[00127] In the process of FIG. 8A, at block 801 , the first EAS sends, to the first EES, a second request for subscribing to a notification of an ACR management event. A type of the subscribed ACR management event is ACR facilitation event, and the second request comprises an ID of the application group. With the ID of the application group, the first EES can know that the UE, for which the notification of the ACR management event is subscribed, is a group member of the application group. Accordingly, when needing to determine a second EAS for the UE (e.g. when the UE moves to a different EDN), the first EES can determine a common EAS for the UE, as the second EAS. At block 802, the first EES sends, to the first EAS, a second response to the second request.

[00128] Since the ACR facilitation event is subscribed, the detection by the first EES may be triggered at block 803 by the user plane path change notification received from the 3GPP core network. For example, the first EES may check whether the UE moves to a different EDN, based on the received notification. If the UE moves to a different EDN, the first EES may decide to execute an ACR at block 804 based on such detection.

[00129] Then, the first EES may check whether a second EAS is available in the different EDN, as described in steps 2-4 of clause 8.8.3.2 of 3GPP TS 23.558 V19.1.0. Specifically, if the first EES cannot find a second EAS in the cached or registered information, the first EES may retrieve the address of a second EES from an ECS at step 2 of clause 8.8.3.2 of 3GPP TS 23.558 V19.1.0. Then, at block 805 (which is step 3 of clause 8.8.3.2 of 3GPP TS 23.558 V19.1 .0), the first EES may send, to the second EES, a fifth request for discovering one or more candidates of the second EAS. The fifth request comprises the ID of the application group. With the ID of the application group, the second EES can know that a common EAS needs to be discovered. At block 806 (which is step 4 of clause 8.8.3.2 of 3GPP TS 23.558 V19.1.0), the second EES may send, to the first EES, a fifth response to the fifth request. The fifth response may comprise one or more EASs discovered by the second EES. The first EES may determine, as a common EAS for the application group, one of the one or more discovered EASs.

[00130] At block 807, the first EES may send, to the repository entity, a storage request for storing information about the determined common EAS to the repository entity. At block 808, the repository entity may send, to the first EES, a storage response to the storage request. If there is no existing common EAS for the application group in the different EDN, the determined common EAS may be used as the second EAS. If there is an existing common EAS for the application group in the different EDN and the existing common EAS is different from the determined common EAS, the repository entity may return information about the existing common EAS to the first EES in the storage response. Then, the returned existing common EAS may be used as the second EAS for the application group.

[00131] At block 809, the first EES sends, to the first EAS, an ACR management notification. The ACR management notification may comprise information about the second EAS, to initiate application context transfer (ACT) between the first EAS and the second EAS. At block 810, the first EAS sends, to the first EES, an acknowledgement to the notification. Then, steps 10-14 of clause 8.8.2.5 of 3GPP TS 23.558 V19.1.0 may be performed to complete the ACR.

[00132] In the process of FIG. 8B, the first EAS may detect that an ACR is required for an application group due to maintenance reason or overload reason. Then, at block 810, the first EAS may make the decision to perform the ACR. At block 812, the first EES determines one or more candidates of the second EAS based on a list of UE IDs in the application group. As mentioned above, if the first EES cannot find a second EAS in the cached or registered information, the first EES may retrieve information from the ECS. For instance, information about one or more second EESs and information about one or more second EDNs corresponding to the one or more second EESs may be retrieved. Then, at least one EAS may be determined from one or more registered EASs in a first EDN corresponding to the first EES and one or more existing common EASs in the one or more second EDNs, based on the list of UE IDs in the application group, so that each of the at least one EAS is a unique common EAS for the application group in corresponding EDN. More details about the determination will be described later with reference to FIGs. 14 and 15.

[00133] If a registered EAS in the first EES is determined as a common EAS for the application group, the first EES may send, to the repository entity, a fourth request for updating common EAS information at the repository entity at block 813. At block 814, the repository entity may send, to the first EES, a fourth response to the fourth request. With this newly introduced procedure for updating common EAS information, the uniqueness of the common EAS for the application group in corresponding EDN can be ensured.

[00134] If the first EES cannot find the at least one EAS at block 812, the first EES may send to the second EES, a fifth request for discovering one or more candidates of the second EAS at block 815. The fifth request comprises an ID of the application group. Since the ACR is initiated due to maintenance reason or overload reason, the fifth request further comprises the list of UE IDs in the application group. Accordingly, at block 816, the second EES determines one or more candidates of the second EAS based on the list of UE IDs in the application group. At block 817, the second EES may send, to the first EES, a fifth response to the fifth request. The fifth response may comprise one or more EASs discovered by the second EES. The first EES may determine, as a common EAS for the application group, one of the one or more discovered EASs at block 818.

[00135] At block 819, the first EES may send, to the repository entity, a storage request for storing information about the determined common EAS to the repository entity. At block 820, the repository entity may send, to the first EES, a storage response to the storage request. Similar to block 706, if there is an existing common EAS for the application group in the second EDN and the existing common EAS is different from the determined common EAS, the repository entity may return information about the existing common EAS to the first EES in the storage response. Then, the returned existing common EAS may be used as the second EAS for the application group. If there is no existing common EAS for the application group in the second EDN, the determined common EAS may be used as the second EAS. Then, steps 5b and 6-14 of clause 8.8.2.5 of 3GPP TS 23.558 V19.1 .0 may be performed to complete the ACR.

[00136] Based on the above description, one of the basic ideas of the present disclosure is that for group- based application session relocation (due to maintenance reason or overload reason), the EES service consumer gives the number of UEs in EAS discovery request so that the EES can consider group need for resource consumption on the T-EAS when identifying T-EAS(s).

[00137] Another basic idea of the present disclosure is that application group ID is included in ACR management event so that the EES receiving EAS discovery delegation in ACR monitoring and ACR facilitating events can use application group ID for common T-EAS discovery and selection.

[00138] Yet another basic idea of the present disclosure is that the number of UEs is used in selected T-EAS declaration from S-EAS to S-EES, so that the S-EES can perform batch processing for the UEs.

[00139] Yet another basic idea of the present disclosure is that during interaction with ECS-ER, update service operation is introduced.

[00140] FIG. 9 is a flowchart illustrating a method performed by a first EAS according to an embodiment of the disclosure. At block 902, the first EAS sends, to a first EES, a first request for discovering one or more candidates of a second EAS, in an ACR for one or more group members in an application group from the first EAS to the second EAS. The first request comprises an ID of the application group. The first EAS may be a source EAS serving the application group. The first EES may be a source EES serving the application group. The second EAS may be a target EAS which is to serve the one or more group members after the ACR. With the ID of the application group, the first EES can know that a common EAS needs to be discovered. Optionally, the first request may further comprise a list of UE IDs in the application group. With the list of UE IDs in the application group, the first EES can be allowed to consider resource consumption of the UEs indicated in the list of UE IDs when determining a second EAS for the application group.

[00141] At block 904, the first EAS receives, from the first EES, a first response to the first request. With the method of FIG. 9, the ACR between common EASs for one or more group members in an application group can be distinguished from the conventional ACR so that it is possible to ensure the uniqueness of the common EAS for the application group in corresponding EDN. [00142] FIG. 10 is a flowchart illustrating a method performed by a first EAS according to an embodiment of the disclosure. At block 1006, the first EAS sends, to the first EES, a second request for subscribing to a notification of an ACR management event. A type of the subscribed ACR management event is ACR monitoring event or ACR facilitation event, and the second request comprises the ID of the application group. With the ID of the application group, the first EES can know that the UE, for which the notification of the ACR management event is subscribed, is a group member of the application group. Accordingly, when needing to determine a second EAS for the UE, the first EES can determine a common EAS for the UE, as the second EAS. At block 1008, the first EAS receives, from the first EES, a second response to the second request. With the method of FIG. 10, the same effect as the method of FIG. 9 can be achieved.

[00143] FIG. 11 is a flowchart illustrating a method performed by a first EAS according to an embodiment of the disclosure. At block 1110, the first EAS sends, to the first EES, a third request for declaring an EAS selected as the second EAS. The third request comprises a list of UE IDs in the application group. With the list of UE IDs in the application group, the first EES can know that the ACR is to be performed for a group of UEs, and thus, batch processing needs to performed for these UEs. At block 1112, the first EAS receives, from the first EES, a third response to the third request. With the method of FIG. 11 , it can facilitate the implementation of the ACR for a group of UEs. Note that in the methods of FIGs. 9-11 , the ACR from the first EAS to the second EAS may be one of: an ACR decided by the first EAS; and an ACR decided by the first EES.

[00144] FIG. 12 is a flowchart illustrating a method performed by a first EES according to an embodiment of the disclosure. At block 1202, the first EES receives or sends a request for discovering one or more candidates of a second EAS, in an ACR for one or more group members in an application group from a first EAS to the second EAS. The request comprises an ID of the application group. As a first option, the request may be a first request received from the first EAS, and the response may be a first response sent to the first EAS. With the ID of the application group, the first EES can know that a common EAS needs to be discovered. Optionally, the first request further comprises a list of UE IDs in the application group. With the list of UE IDs in the application group, the first EES can be allowed to consider resource consumption of the UEs indicated in the list of UE IDs when determining a second EAS for the application group.

[00145] As a second option, the request may be a fifth request sent to a second EES, and the response may be a fifth response received from the second EES. With the ID of the application group, the second EES can know that a common EAS needs to be discovered. Optionally, the fifth request further comprises a list of UE IDs in the application group. With the list of UE IDs in the application group, the second EES can be allowed to consider resource consumption of the UEs indicated in the list of UE IDs when determining a second EAS for the application group.

[00146] At block 1204, the first EES sends or receives a response to the request. For the above first option, the first EES sends a first response to the first request. For the above second option, the first EES receives a fifth response to the fifth request. With the method of FIG. 12, the ACR between common EASs for one or more group members in an application group can be distinguished from the conventional ACR so that it is possible to ensure the uniqueness of the common EAS for the application group in corresponding EDN.

[00147] FIG. 13 is a flowchart illustrating a method performed by a first EES according to an embodiment of the disclosure. The method of FIG. 13 may be used in the above first option of FIG. 12, or may be used in the scenario shown in FIG. 8B. At block 1306, the first EES determines one or more candidates of the second EAS based on the list of UE IDs in the application group. For example, at least one EAS may be determined from one or more registered EASs in a first EDN corresponding to the first EES and one or more existing common EASs in one or more second EDNs, based on the list of UE IDs in the application group, so that each of the at least one EAS is a unique common EAS for the application group in corresponding EDN. The information about the one or more second EDNs may be retrieved by the first EES from an ECS. Information about the one or more existing common EASs may be obtained by the first EES from repository entities (e.g. ECS-ERs) of the one or more second EDNs.

[00148] For example, block 1306 may be implemented as blocks 1408-1414 of FIG. 14, or blocks 1516-1518 of FIG. 15. At block 1408, when all UEs in the application group is within an overlapping area between a first service area of the first EDN and second service areas of the one or more second EDNs, the first EES may check whether there is an existing common EAS for the application group in the second EDN corresponding to the overlapping area. At block 1410, when there is an existing common EAS for the application group in the second EDN, the first EES may determine an EAS from the one or more registered EASs in the first EES and the existing common EAS. The resource consumption of the UEs indicated in the list of UE IDs may be considered when determining the EAS. At block 1412, when there is no existing common EAS for the application group in the second EDN, the first EES may determine an EAS from the one or more registered EASs in the first EES. Similarly, the resource consumption of the UEs indicated in the list of UE IDs may be considered. At block 1414, when at least one UE in the application group is not within the overlapping area, the first EES may determine an EAS from the one or more registered EASs in the first EES. In the method of FIG. 14, all UEs in the application group are considered as a whole so that either a registered EAS or an existing common EAS is determined as the second EAS. So this method may be called centralized load reallocation method.

[00149] Alternatively, at block 1516, for a first subset of all UEs in the application group that is within at least one overlapping area with at least one second EDN, when there is at least one existing common EAS for the application group in the at least one second EDN, the first EES may determine, for the first subset, one of the at least one existing common EAS. At block 1518, for a second subset of all UEs in the application group that is not within the overlapping area, the first EES may determine, for the second subset, an EAS from the one or more registered EASs in the first EES. Note that there may be multiple first subsets.

[00150] As an exemplary example, suppose that there are two second EDNs, EDN x and EDN y; there is an existing common EAS x in EDN x; there is an existing common EAS y in EDN y; and the two second EDNs have the same overlapping area with the first EDN. If all UEs in the application group are within the overlapping area, then sessions for some UEs may be relocated to EAS x and sessions for remaining UEs may be relocated to EAS y. If a first part of UEs in the application group are within the overlapping area and a second part of UEs in the application group are not within the overlapping area, then sessions for the first part of UEs may be distributed between EAS x and EAS y, and sessions for the second part of UEs may be relocated to a locally registered EAS.

[00151] The method of FIG. 15 may be called distributed load reallocation method. It is more complex than the centralized load reallocation method because the first EES and/or the first EAS need to know the determined second EASs and their corresponding UEs so as to proceed with subsequent operations of the ACR. Note that depending on the specific application scenario, it is possible that merely part of blocks 1408- 1414 or blocks 1516-1518 may be performed.

[00152] FIG. 16 is a flowchart illustrating a method performed by a first EES according to an embodiment of the disclosure. At block 1306, the first EES determines one or more candidates of the second EAS based on the list of UE IDs in the application group. At block 1620, when a registered EAS in the first EES is determined as a common EAS for the application group, the first EES updates common EAS information for the application group at a repository entity based on information about the registered EAS. With the method of FIG. 16, the uniqueness of the common EAS for the application group in corresponding EDN can be ensured.

[00153] FIG. 17 is a flowchart illustrating a method performed by a first EES according to an embodiment of the disclosure. At block 1202, the first EES sends a fifth request for discovering one or more candidates of a second EAS, in an ACR for one or more group members in an application group from a first EAS to the second EAS. The fifth request comprises an ID of the application group. At block 1204, the first EES receives a fifth response to the fifth request. The fifth response comprises one or more EASs discovered by the second EES.

[00154] At block 1722, the first EES determines, as a common EAS for the application group, one of the one or more discovered EASs. For example, the resource consumption of the UEs indicated in the list of UE IDs may be considered when determining the common EAS. At block 1724, the first EES stores information about the determined common EAS to a repository entity. Optionally, the first EES may receive, from the repository entity, information about an existing common EAS for the application group. The existing common EAS is different from the determined common EAS. With the method of FIG. 17, the uniqueness of the common EAS for the application group in corresponding EDN can be ensured.

[00155] FIG. 18 is a flowchart illustrating a method performed by a first EES according to an embodiment of the disclosure. At block 1828, the first EES receives, from the first EAS, a second request for subscribing to a notification of an ACR management event. A type of the subscribed ACR management event is ACR monitoring event or ACR facilitation event, and the second request comprises the ID of the application group. With the ID of the application group, the first EES can know that the UE, for which the notification of the ACR management event is subscribed, is a group member of the application group. Accordingly, when needing to determine a second EAS for the UE, the first EES can determine a common EAS for the UE, as the second EAS. At block 1830, the first EES sends, to the first EAS, a second response to the second request. With the method of FIG. 18, the same effect as the method of FIG. 12 can be achieved.

[00156] FIG. 19 is a flowchart illustrating a method performed by a first EES according to an embodiment of the disclosure. At block 1932, the first EES receives, from the first EAS, a third request for declaring an EAS selected as the second EAS. The third request comprises a list of UE IDs in the application group. With the list of UE IDs in the application group, the first EES can know that the ACR is to be performed for a group of UEs, and thus, batch processing needs to be performed for these UEs. At block 1934, the first EES sends, to the first EAS, a third response to the third request. With the method of FIG. 19, it can facilitate the implementation of the ACR for a group of UEs.

[00157] FIG. 20 is a flowchart illustrating a method performed by a first EES according to an embodiment of the disclosure. As shown, the method comprises blocks 1932-1934 described above, and blocks 2036-2038. At block 2036, the first EES sends, to each of EECs for UEs indicated in the list of UE IDs, information about the selected EAS. At block 2038, the first EES sends, to each of the EECs for the UEs indicated in the list of UE IDs, a notification about an ACR complete event. With the method of FIG. 20, the same effect as the method of FIG. 19 can be achieved. Note that one or more of blocks 2036-2038 may be performed depending on the specific application scenario.

[00158] FIG. 21 is a flowchart illustrating a method performed by a first EES according to an embodiment of the disclosure. At block 2140, the first EES sends, to a repository entity, a fourth request for updating common EAS information at the repository entity. The fourth request comprises the ID of the application group. The fourth request may further comprise one or more of: an ID of a common EAS; an endpoint of the common EAS; an ID of the first EES; information about an EDN where the common EAS resides; and security credentials which result from a successful authorization for an edge computing service.

[00159] At block 2142, the first EES receives, from the repository entity, a fourth response to the fourth request. The fourth response may comprise one or more of: a first indicator indicating that the fourth request was successful, or a second indicator indicating that the fourth request has failed; and a third indicator indicating a failure cause when the fourth request has failed. With the method of FIG. 21 , a new procedure is introduced to support updating of common EAS information so as to ensure the uniqueness of the common EAS for the application group in corresponding EDN. Note that in the methods shown in FIGs. 12-21 , the ACR from the first EAS to the second EAS may be one of: an ACR decided by the first EAS; and an ACR decided by the first EES.

[00160] FIG. 22 is a flowchart illustrating a method performed by a second EES according to an embodiment of the disclosure. At block 2202, the second EES receives, from a first EES, a fifth request for discovering one or more candidates of a second EAS, in an ACR for one or more group members in an application group from a first EAS to the second EAS. The fifth request comprises an ID of the application group. With the ID of the application group, the second EES can know that a common EAS needs to be discovered. Optionally, the fifth request further comprises a list of UE IDs in the application group. With the list of UE IDs in the application group, the second EES may consider resource consumption of the UEs indicated in the list of UE IDs when determining a second EAS for the application group.

[00161] At block 2204, the second EES sends, to the first EES, a fifth response to the fifth request. With the method of FIG. 22, the ACR between common EASs for one or more group members in an application group can be distinguished from the conventional ACR so that it is possible to ensure the uniqueness of the common EAS for the application group in corresponding EDN.

[00162] FIG. 23 is a flowchart illustrating a method performed by a second EES according to an embodiment of the disclosure. At block 2202, the second EES receives, from a first EES, a fifth request for discovering one or more candidates of a second EAS, in an ACR for one or more group members in an application group from a first EAS to the second EAS. The fifth request comprises an ID of the application group and a list of UE IDs in the application group. At block 2204, the second EES determines one or more candidates of the second EAS based on the list of UE IDs in the application group. At block 2204, the second EES sends, to the first EES, a fifth response to the fifth request. With the method of FIG. 23, the same effect as the method of FIG. 22 can be achieved.

[00163] FIG. 24 is a flowchart illustrating a method performed by a repository entity according to an embodiment of the disclosure. At block 2402, the repository entity receives, from a first EES, a fourth request for updating common EAS information at the repository entity, in an ACR for one or more group members in an application group from a first EAS to a second EAS. The fourth request comprises an ID of the application group. The fourth request may further comprise one or more of: an ID of a common EAS; an endpoint of the common EAS; an ID of the first EES; information about an EDN where the common EAS resides; and security credentials which result from a successful authorization for an edge computing service.

[00164] At block 2404, the repository entity sends, to the first EES, a fourth response to the fourth request. The fourth response may comprise one or more of: a first indicator indicating that the fourth request was successful, or a second indicator indicating that the fourth request has failed; and a third indicator indicating a failure cause when the fourth request has failed. With the method of FIG. 24, a new procedure is introduced to support updating of common EAS information so as to ensure the uniqueness of the common EAS for the application group in corresponding EDN.

[00165] FIG. 25 is a flowchart illustrating a method performed by a repository entity according to an embodiment of the disclosure. At block 2402, the repository entity receives, from a first EES, a fourth request for updating common EAS information at the repository entity, in an ACR for one or more group members in an application group from a first EAS to a second EAS. The fourth request comprises an ID of the application group. At block 2506, the repository entity determines whether there is a stored EAS serving the application group within a same EDN. At block 2508, when there is a stored EAS serving the application group within the same EDN, the repository entity updates information about the stored EAS based on common EAS information indicated in the fourth request. At block 2510, when there is no stored EAS serving the application group within the same EDN, the repository entity rejects the fourth request. At block 2404, the repository entity sends, to the first EES, a fourth response to the fourth request. With the method of FIG. 25, the same effect as the method of FIG. 24 can be achieved.

[00166] Based on the above description, to address the above relocation cases, there may be two change requests (CRs) proposed for 3GPP TS 23.558 V19.1 .0. The CRs contain detailed information including figures and procedure (& message impact). Note that the added content proposed by the CRs relative to 3GPP TS 23.558 V19.1.0 will be highlighted with underlines, and deleted content will be represented by “[...]”.

[00167] The title of the main CR is "Common EAS relocation”. The proposed change in the main CR affects Core Network. The reason for change is that the common EAS relocation can happen: when some application group members in a group move to a new EDN coverage area, their application session will be relocated from the old common EAS to a new common EAS; when a common EAS is relocated due to maintenance reason (e.g. graceful shutdown) or overload reason, which can be detected by S-EAS or S-EES. How to support common EAS relocation needs to be specified. In the 1st case, the application session is relocated individually. And in the 2nd case, the application sessions are relocated together. Correspondingly, EEL should be able to distinguish different need and facilitate the relocation.

[00168] Summary of change is as below: 1) add changes in the following procedures to support common EAS relocation: T-EAS discovery; Selection T-EAS declaration; ACR management events; 2) it further supports the following ACR scenarios: S-EAS decided ACR in cl.8.8.2.4; S-EES executed ACR in cl.8.8.2.5. If not approved, EEL support for common EAS relocation in service continuity will be missed.

[00169] The first change is shown as below.

8.5.3.2 EAS discovery request

Table 8.5.3.2-1 describes information elements for the EAS discovery request. Table 8.5.3.2-2 provides further detail about the EAS Discovery Filter information element.

Table 8.5.3.2-1: EAS discovery request

Table 8.5.3.2-2: EAS discovery filters

[00170] The second change is shown as below. FIG. 26 is Figure 8.8.2.4-1 and illustrates S-EAS decided ACR. 8.8.2.4 S-EAS decided ACR scenario

In this scenario, the S-EAS may detect the need of ACR locally or is notified by the S-EES via ACR management notifications or UE location notifications. The S-EAS make the decision about whether to perform the ACR, and starts the ACR at a proper time.

NOTE 1 : For this clause, S-EAS either supports ACR detection capability or performs subscription for ACR management event to EES. Pre-conditions:

1. The S-EAS may depend on the receipt ACR management events from the S-EES, e.g. "user plane path change" events or "ACR monitoring" events as described in clause 8.6.3, to detect the need for an ACR. The S-EAS may also depend on the receipt of UE location notification from the S-EES as described in clause 8.6.2.2.3, to detect the need for an ACR. For the following procedure it is assumed that the S-EAS has subscribed to continuously receive the respective events from the S-EES; and

2. The EEC has subscribed to receive ACR information notifications for target information notification events and ACR complete events from the S-EES, as described in clause 8.8.3.5.2.

S-EAS decided ACR is outlined with four main phases: detection, decision, execution and clean up.

Phase I: ACR Detection

1. The S-EAS either receives ACR management notifications from source Edge Enabler Sever indicating that ACR may be required ("ACR monitoring" event), or self detects the need for ACR (e.g. upon receipt of a "user plane path change" event or UE location notification). If the ACR management notification indicates "ACR monitoring" event, then the notification will also contain the T-EAS information (see clause 8.6.3.2.3). The S-EAS may detect that ACR may be required for an expected or predicted UE location in the future as described in clause 8.8.1.1.

NOTE 2: How the S-EAS self detects the local need for ACR is outside the scope of this specification.

Phase II: ACR Decision

2. The S-EAS makes the decision to perform the ACR If the S-EAS has received information of on-going ACR, then it should not initiate an ACR with the same ACR identity uniquely identified by ACID, EEC ID (or UE ID), S-EAS endpoint and T-EAS endpoint again, per clause 8.6.3.2.3. NOTE 3: How the S-EAS determines when to start the ACR is outside the scope of this specification. The ASP can have service agreement with ECSP regarding which EES API to use for ACR detection.

Phase III: ACR Execution

3. The S-EAS discovers the T-EAS as described in clause 8.8.3.2. When in step 1 the ACR has been triggered for service continuity planning, then UE Location and Target DNAI values in the Retrieve T-EES procedure contain the expected UE Location and expected Target DNAI. After S-EAS determines the T-EAS to use, the S-EAS may apply the AF traffic influence with the N6 routing information of the T-EAS in the 3GPP Core Network (if applicable).

If T-EAS discovery results in no T-EAS, and if ACR to CAS is supported, then the procedure for ACR with CAS applies as specified in clause 8.8.2A.4.

4. The S-EAS sends selected T-EAS declaration message to S-EES, to inform S-EES the determined T-EAS to use as described in clause 8.8.3.7. The S-EAS may send the ACID and Predicted/Expected UE location or Expected AC Geographical Service Area to the EES. When the EES receives the predicted/expected UE location or Expected AC Geographical Service Area from the EAS, then the EES will determine to monitor the UE mobility.

In the case of S-EAS overload or maintenance, the S-EAS includes list of UEs for which ACR is required in the Selected T-EAS declaration message to the S-EES to indicate S- EES to perform ACR for UEs in the group.

5. If the T-EES is different than the S-EES and the EEC Context at the S-EES is not stale, the S-EES initiates EEC Context Push relocation with the T-EES as described in clause

8.9.2.3. Otherwise, if the T-EES is the same as the S-EES, EEC Context Push relocation is skipped.

6. Based on the T-EAS selection information received from the S-EAS, the S-EES sends the target information notification to the EEC as described in clause 8.8.3.5.3. The selected T- EES may be included in the target information and the ACID which corresponds to the selected target EAS is included in the notification sent to the EEC as described in clause

8.8.3.5.3.

If ACR is initiated for a list of UEs, the S-EES sends the ACR information notification (Target information notification) message to EEC for the identified UEs.

NOTE 4: Step 6 can be performed after step 4. The S-EES can send target information notification to the EEC immediately after having the target information in order to avoid EEC to initiate another ACR with the same identity. 7. The S-EAS transfers the application context to the T-EAS selected in step 3. This process is out of scope of the present specification.

When in step 1 the ACR has been triggered for service continuity planning, if the UE does not move to the predicted location, the EEC does not connect to T-EES, the AC does not connect to the T-EAS.

NOTE 5: The S-EAS or T-EAS can further decide to terminate the ACR, and the T-EAS can discard the application context based on information received from EEL and/or other methods (e.g. monitoring the location of the UE). It is up to the implementation of the S-EAS and T-EAS whether and how to make such a decision.

NOTE 6: When in step 1 the ACR has been triggered for service continuity planning, the S- EAS and the T-EAS can wait for the UE to move to the predicted location before they perform the Post ACR Clean up steps 8 and 9 if it is the EAS monitoring whether the UE moves to the predicted/expected location. When the S-EAS and the T-EAS do not wait for the UE (e.g., if the UE does not move to the predicted location), the S-EAS and the T-EAS can perform Post ACR Clean up with failure messages.

NOTE 7: If the S-EAS and T-EAS are main EASs forming proxy bundle, other EASs of the bundle may transfer the application contexts in this step. How to execute ACT is out of scope of this document.

Phase IV : Post-ACR clean up

8. The S-EAS sends the ACR status update message to the S-EES as specified in clause 8.8.3.8.

9. The T-EAS sends the ACR status update message to the T-EES as specified in clause 8.8.3.8. If the status indicates a successful ACT, and that the EEC Context relocation procedure was attempted but failed, then the T-EES indicates the failure to the T-EAS with the ACR status update response.

NOTE 8: If the EDGE-3 subscription initialization result indicates failure, then the EAS can perform the required EDGE-3 subscriptions at the T-EES.

NOTE 9: Steps 8 and 9 can occur in any order.

10. If the status in step 8 indicates a successful ACT, for non -planning case the S-EES sends the ACR information notification (ACR complete) message immediately to the EEC to confirm that the ACR has completed as specified in clause 8.8.3.5.3. For the service continuity planning case, if it is EES monitors the UE mobility, then only when S-EES detects the UE has moved to the predicted/expected UE location or Expected AC Geographical Service Area and the status in step 8 indicates a successful ACT, then the S- EES sends ACR information notification (ACR complete) message to the EEC indicating that UE has moved to the predicted location when the ACR type is service continuity planning. If the EEC Context relocation procedure was attempted, then the notification includes EEC context relocation status IE, indicating the result of the EEC context relocation procedure. If the EEC context relocation status indicates that the EEC context relocation was not successful, then the EEC may perform the required EDGE-1 operations such as create subscriptions at the T-EES.

If ACR is initiated for a list of UEs, the S-EES sends the ACR information notification (ACR complete) message to EEC for the identified UEs.

[00171] In the above clause 8.8.2.4, the following underlined contents are relevant to the changes proposed by the CRs.

In this scenario, the S-EAS may detect the need of ACR locally or is notified by the S-EES via ACR management notifications or UE location notifications.

1. The S-EAS may depend on the receipt ACRmanagement events from the S-EES, e.g. "user plane path change" events or "ACR monitoring" events as described in clause 8.6.3, to detect the need for an ACR.

1. The S-EAS either receives ACR management notifications from source Edge Enabler Sever indicating that ACR may be required ("ACR monitoring" event)

3, _ The S-EAS discovers the T-EAS as described in clause 8, 8, 3, 2,

4, _ The S-EAS sends selected T-EAS declaration message to S-EES, to inform S-EES the determined T-EAS to use as described in clause 8, 8, 3, 7,

[00172] The third change is shown as below. FIG. 27 is Figure 8.8.3.2-1 and illustrates Discover T-EAS procedure.

8.8.3.2 Discover T-EAS

Figure 8.8.3.2-1 illustrates the procedure for fetching T-EAS information. This procedure may be utilized by a S-EAS, which undertakes the transfer of application context information to a T-EAS directly, or can be invoked by the S-EES itself on deciding to execute ACR. T-EAS discovery procedure also supports EAS retrieval which enables a S-EAS to obtain T- EAS(s) serving the application group so that the S-EAS can start communication with obtained EAS(s) for EAS synchronization.

Pre-conditions:

1. Information related to the EES is available with the S-EAS, if the procedure is triggered by the S-EAS. la. The S-EAS sends the EAS discovery request to the S-EES or the S-EES decides to execute the ACR. The EAS discovery request from the S-EAS includes the requestor identifier [EASID] along with the security credentials and includes EAS discovery filter matching its EAS profile. If target DNAI is available at the S-EAS via User Plane Path change event, the S-EAS provides the S-EES with the target DNAI. The S-EAS also includes an EAS service continuity support indicator indicating that the S-EAS decided ACR according to clause 8.8.2.4 is to be used for the ACR. The S-EAS includes the bundle ID and bundle type indicating the proxy bundle case to which the S-EAS belongs to. The request may include prediction expiration time.

The EAS may send EAS discovery request with EAS ID, Application Group ID and EAS synchronization support, which indicates the request to obtain EAS(s) currently serving the Application Group ID with the requested EAS ID in order to perform EAS synchronization.

The Application group ID is included in the EAS discovery request if the S-EAS wants to discover a common EAS for the group. If the EAS discovery request is triggered by S-EAS due to overload or maintenance reason for the Application Group, the S-EAS also includes list of UE IDs in the EAS discovery request.

NOTE 1: The trigger condition to invoke the Discover T-EAS API is up to application service logic, which is out of scope of this specification. lb. The S-EES either receive the target DNAI for T-EES discovery from the step la or by the user plane management event notification from the core network.

2. If the request is received from the S-EAS, the S-EES checks whether the requesting EAS is authorized to perform the discovery operation.

If Application Group ID and EAS synchronization support in EAS characteristics are received and the ECS-ER is available, the S-EES checks with the ECS-ER with the received EAS ID and Application Group ID and obtains a list of EAS(s) supporting EAS synchronization and serving the application group for the desired application service identified by the EAS ID as described in clause 8.20. Step 2 to step 4 are skipped.

If the UE location is not known to the S-EES or provided by the S-EAS request, then the S-EES may interact with 3GPP core network to retrieve the UE location. If the S-EES decided to execute the ACR or when the requesting EAS is authorized, the S-EES checks if there exists a T-EAS information (registered or cached) that can satisfy the requesting EAS information, additional query fdters and the Expected AC Service KPIs and the Minimum required AC Service KPIs if received from the EEC during the EAS discovery or from the S-EAS in step 1. In this case, the S-EES may collect Edge load performances from AD AES or OAM to find T-EAS(s) that satisfies the Expected AC service KPIs or the Minimum required AC Service KPIs. The S-EES may determine the use of statistics or prediction for evaluating KPIs based on the situation of the T-EAS discovery. The S-EES also considers number of UEs within the Application Group for needed resource consumptions when identifying T-EASIs). If Application Group ID is not received and if Flfl the S-EES finds the T-EAS(s) in the cached or registered information, the flow either continues with step 5 for the S-EAS triggered discovery or stops for the S-EES decided ACR execution, else the S-EES retrieves the T-EES address from the ECS as specified in clause 8.8.3.3 and continues with step 3.

If Application group ID is available in the S-EES (e.g. received in step la or ACR management event subscription), the S-EES retrieves T-EES information and corresponding EDN connection information from the ECS as described in clause 8, 8, 3, 3,

If UE ID list is available in the S-EES (e.g. received in step la) and:

- if at least one UE in the application group is still within the source EDN service area but not within EDN overlapping area, the S-EES tries to identify a T-EAS within registered EAS(s). If any T-EAS satisfying the need for Application Group is found, the S-EES updates the common EAS with the T-EAS in the ECS-ER (if the ECS-ER is available) as described in clause 8,20.2.x and continues with step 5,

- if all UEs in the application group are within EDN overlapping area (multiple different EDN connection information received from the ECS), the S-EES checks if there is available common EAS in each overlapping EDN in other EDNs by using procedure described in clause 8,20.2.2. If any common EAS is found, the S-EES decides whether to select an available common EAS or locally registered T-EAS as common EAS considering resources needed for the Appplication Group and continues with step 5 , Updating common EAS with registered T-EAS in the ECS-ER is needed when locally registered T-EAS is selected by the S-EES.

If no common EAS is found in other EDNs for the EDN overlapping area or no registered T-EAS can be found, the S-EES continues with step 3,

If Prediction expiration time is provided then the EES may determine whether to identify the instantiable but not instantiated EAS as T-EAS based on Prediction expiration time and the predicted EAS deployment time information obtained from AD AES.

Editor's Note: Whether and how the EES can obtain the EAS deployment time (e.g., from AD AES) is FFS.

3. The S-EES invokes the EAS discovery request on the T-EES retrieved from the ECS. The EAS discovery request includes the requestor identifier [EESID] along with the security credentials and includes EAS discovery filter. In the EAS discovery filter, the S-EES may include prediction expiration time, the Expected AC Service KPIs and the Minimum required AC Service KPIs if received from the EEC during the EAS discovery or from the S-EAS in step 1.

The S-EES also includes the EEC service continuity support indicator received from the EEC during EAS discovery. If in step 1 the S-EES received an EAS service continuity support indicator from the S-EAS, then the S-EES includes this EAS service continuity support indicator and its own EES service continuity support indicator indicating the ACR scenarios supported by the EES. If in step 1 the S-EES decided to execute the ACR, the S- EES includes the EAS service continuity support indicator received from the S-EAS during EAS registration and includes an EES service continuity support indicator indicating that the S-EES executed ACR according to clause 8.8.2.5 is to be used for the ACR.

Upon receiving the request, the T-EES may trigger the ECSP management system to instantiate the T-EAS that matches with EAS discovery filter IES (e.g. ACID) as in clause 8.12.

4. The T-EES discovers the T-EAS(s) and responds with the discovered T-EAS information to the S-EES. To filter T-EAS(s), the T-EES utilizes the discovery filters (e.g. Expected AC Service KPIs and the Minimum required AC Service KPIs) and the indications which ACR scenarios are supported by the AC, the EEC, the T-EES and the S-EAS. If T-EES gets the Expected AC service KPIs or the Minimum required AC Service KPIs, the T-EES may collect edge load analytics from AD AES (as specified in clause 8.8.2 of TS 23.436 [28]) or performance data from 0AM to find T-EAS(s) that satisfies the Expected AC service KPIs or the Minimum required AC Service KPIs. The T-EES may determine the use of statistics or prediction for evaluating KPIs based on the situation of the T-EAS discovery. The T-EES also considers the number of UEs received from the S- EES in step 3 for needed resource consumptions when identifying T-EAS(s). The S-EES may cache the T-EAS information.

When the bundle EAS information (i.e. list of EASID) is provided and the bundle type indicating the direct bundle, and the S-EES received associated T-EES(s) along with part of EAS ID list in the step2 from the ECS, then the S-EES discover the target direct bundle EAS(s) which belongs to same EDN for all the associated S-EES(s). The request message contains direct bundle EAS(s) information (i.e. list of EASID and direct bundle type).

Then the S-EES receives the direct bundle T-EAS(s) information from each associated T- EES(s).

NOTE 2: T-EES(s) may belongs to same EDN.

NOTE 3: The edge load analytics from AD AES can be either statistics or predictions on the T- EAS. NOTE 4: The statistical KPI value can be used for both normal ACR and service continuity planning.

When the ECS-ER is available and common EAS information corresponding to the Application Group ID (received in step la or ACR management event subscription) is not available, then the S-EES identifies one T-EAS for the application group and interacts with the ECS-ER to store the common EAS information as described in clause 8,20.2.3. If common EAS information is already available corresponding to the Application Group ID in the repository, then the ECS-ER returns the common EAS information to the S-EES as described in clause 8,20.2.3.

5. If the request was received from the S-EAS, the S-EES responds to the S-EAS with the discovered T-EAS Information.

For responding S-EAS requesting EAS serving the application group for EAS synchronization, only EAS endpoint and EAS ID are included in EAS profile of Discovered EAS list.

[00173] The fourth change is shown as below.

8.8.4.17Selected target EAS declaration request

Table 8.8.4.17-1 describes information elements for the selected target EAS declaration request sent from the S-EAS to the S-EES.

Table 8.8.4.17-1: Selected target EAS declaration request

[00174] The fifth change is shown as below. FIG. 28 is Figure 8.6.3.2.2-1 and illustrates ACR management event API: Subscribe operation. 8.6.32.2 Subscribe

Figure 8.6.3.2.2-1 illustrates the subscribe operation between the EAS and the EES for ACR management event notifications.

1. The EAS sends ACR management event subscribe request (e.g. tracking the UE's user plane path change continuously). The EAS shall include UE Identifier or UE Group ID for "user plane path change", "ACR monitoring" and "ACR facilitation" events. a. The EAS may include the "user plane path change" event to indicate the EES to notify the EAS when the EES detects there is a user plane path change for the application traffic and the EAS may include Subscription Type (Early and/or Late notification defined in clause 5.6.7 of 3GPP TS 23.501 [2]) and/or Indication of EAS Acknowledgement in the event subscription. b. The EAS may include the "ACR monitoring" event to indicate the EES to notify the EAS when the EES detects there is a need for the ACR (e.g. when T-EAS is available at the target DNAI). The EAS may also include the Event Filters to specify the conditions to match for notifying the event, e.g., inter-EDN mobility, intra-EDN mobility. c. The EAS may include the "ACR facilitation" event to request the EES to make the decision for ACR, discover the T-EAS(s), influence the traffic for the selected T-EAS and notify the S-EAS of the selected T-EAS. If required, the EAS can add an indication to request service continuity planning. d. The EAS may include the "ACT start/stop" event to indicate the EES to notify the EAS of the need for start or stop ACT to or from another EAS for a particular UE. The EES may also use "ACT start" event to notify the EAS of the ACR parameters. e. The EAS may include the “ACR Selection” event to indicate the EES to notify the EAS of the selected ACR scenario list applicable to ACs using the EAS.

For "ACR monitoring" event and "ACR faciliation" event The EAS may include Application Group ID to indicate that the EES needs to discover a common T-EAS for an application group.

2. The EES checks if the EAS is authorized for this operation.

If authorized, and if the subscription in step 1 includes at least one of the "user plane path change", "ACR monitoring" and "ACR facilitation" events, the EES may invoke the PFD management procedure with the 3GPP Core Network as described in 3GPP TS 23.682 [10] and 3GPP TS 23.502 [8] with an application id. The traffic filter information sent by the EAS is used in requesting PFD management service. Further the EES provides the same application id for requesting user plane path management event service.

NOTE 1: PFD management can be optionally supported in MNO. If EES cannot invoke step 2a, it responds EAS with appropriate error.

NOTE 2: The EES can map the EASID into the application id that is used to invoke the PFD management procedure. 3. If the subscription in step 1 includes at least one of the "user plane path change", "ACR monitoring" and "ACR facilitation" events, the EES checks if there exists a subscription with the 3GPP core network for the user plane path management event notifications corresponding to the UE information obtained in step 1 as described in

3GPP TS 23.501 [2] and 3GPP TS 23.502 [3], which may be triggered by other EAS for the same UE. The EES checks the availability of the user plane path management event service for the UE(s). a. if a subscription with 3GPP core network does not exist, then the EES subscribes with the 3GPP core network (PCF, NEF or SCEF+NEF) for the user plane path management event notifications of the UE(s) as described in 3GPP TS 23.501 [2] and

3GPP TS 23.502 [3] If the EAS provides Subscription Type and/or Indication of EAS Acknowledgement, the EES include the type of subscription and/or the indication of "AF acknowledgement to be expected" as information on AF subscription to corresponding SMF events within the AF Request; b. if a subscription with 3GPP core network exists, then the EES uses the locally cached user plane path management event notification information of the UE(s) to respond to the EAS.

The EES stores the subscription related to the EAS.

4. If the event is "user plane path change", the EES may subscribe to UE expected behaviour analytics (UE mobility and UE communication) for the group of UEs as described in 3GPP TS 23.288 [18],

5. If EAS is authorized, the EES responds with ACR management event subscribe response. If EAS is not authorized, the EES provides a rejection response with cause information.

If the target UE(s) and the 3GPP network support mobility between 5GC and EPC, the EES monitors the availability of the user plane path management event notification from the 3GPP network by utilizing Nnef APISupportCapability or Availability of service APIs event notifications provided by the CAPIF core function.

[00175] The sixth change is shown as below.

8.6.3.3.2 ACR management event subscribe request

Table 8.6.3.3.2-1 describes the information elements for an ACR management event subscribe request from the EAS to the EES.

Table 8.6.3.3.2-1: ACR management event subscribe request

[00176] The seventh change is shown as below.

8.6.3.3.4 ACR management event notification

Table 8.6.3.3.4-1 describes the information elements for an ACR management event notification from the EES to the EAS.

Table 8.6.3.3.4-1: ACR management event notification

[00177] The second CR is for "update” interaction with ECS-ER. The title of the second CR is "Common EAS information update in ECS-ER”. The proposed change in the second CR affects Core Network. The reason for change is that when a common EAS is relocated due to maintenance reason (e.g. graceful shutdown) or overload reason, which can be detected by S-EAS or S-EES, a T-EAS discovery procedure is triggered by either S-EAS or S-EES. With ECS-ER deployed, the ECS-ER stored common EAS information needs to be updated.

[00178] Summary of the change is to add update procedure for common EAS storage in ECS-ER. If not approved, outdated info remains in ECS-ER which leads to incorrect common EAS being returned to consumer.

[00179] The first change is shown as below. FIG. 29 is Figure 8.20.2.x- 1 and illustrates Common EAS information update procedure.

8.20.2.x Common EAS information update

1 . The EES sends Common EAS information update request message to the ECS-ER. The request message includes EDN information, EES ID, EAS ID, EAS endpoint and Application Group ID.

2. Upon receiving the request, the ECS-ER checks if there is any stored EAS serving the application group for the EAS ID within the same EDN. If existing common EAS is found, the ECS-ER updates the EAS endpoint information for subsequent binding; otherwise, the ECS-ER rejects the EES request in step 3.

3. The ECS-ER responds the EES with Common EAS information update response message.

[00180] The second change is shown as below.

8.20.3.x Common EAS information update request

Table 8.20.3.x- 1 describes the information elements for common EAS information update request from the EES to the ECS-ER.

Table 8.20.3.4-1: Common EAS information update request

8, 20, 3, y Common EAS information update response

Table 8,20.3.y-l describes the information elements for common EAS information update response from the ECS-ERto the EES.

Table 8.20.3.V-1: Common EAS information update response

[00181] The third change is shown as below.

8.20.4. IGeneral

Table 8.20.4.1-1 illustrates the API for EAS information management.

Table 8.20.4.1-1: EAS information management APIs

[00182] The fourth change is shown as below.

8,20.4.xEecs_EASInfoManagement_Update operation

API operation name: Eecs EASInfoManagement Update Description: The consumer requests EAS information update service from the ECS.

Inputs: See clause 8,20.3.x,

Outputs: See clause 8,20, 3,v.

See clause 8,20,2.x for details of usage of this operation.

[00183] In addition, below text is for information which shows E2E view using the impacted procedures in the CRs, where relevant procedures are highlighted with underlines. FIG. 30 is Figure 8.8.2.5-1 and illustrates S-EES executed ACR.

8.8.2.5 S-EES executed ACR

Figure 8.8.2.5-1 illustrates the S-EES detecting, deciding and executing ACR from the S-EAS to the T-EAS. This may include EELManagedACR by S-EES when initiated by S-EAS as per clause 8.8.3.6. The EEC orthe S-EAS may also detect the ACR as illustrated in figure 8.8.2.5-1.

NOTE 1: For this clause, S-EAS either supports ACR detection capability or performs subscription for ACR management event to EES.

Pre-condition:

1. The AC at the UE already has a connection to the S-EAS;

2. The EEC is able to communicate with the S-EES;

3. The EEC has subscribed to receive ACR information notifications for target information notification events and ACR complete events from the S-EES, as described in clause 8.8.3.5.2;

4. The S-EAS optionally subscribed to receive ACR management notifications for "ACR facilitation" events to the S-EES, in order to enable detection at S-EAS.

5. In case of EELManagedACR, the T-EAS has subscribed to receive ACT status notifications as described in clause 8.8.3.6.2.3.

1. The S-EAS may initiate EELManagedACR with S-EES as specified in clause 8.8.3.6. The S-EAS and S-EES negotiate an address of the Application Context storage to S-EES. The S-EAS puts the Application Context at this address which can be further accessed by the S- EES when the ACT is required.

In the EELManagedACR case, the S-EES executes steps 2 (i.e., S-EES is the detection entity), 4, 5, 6, 7, 8, 9, 10, 11, 13 and 14. Rest of steps are skipped.

Phase I: ACR Detection

2. Detection entities (S-EAS, S-EES, EEC) detect that ACR may be required and identify the ACID and Predicted/Expected UE location or Expected AC Geographical Service Area as described in clause 8.8.1.1. The detection by the S-EES may be triggered by the User Plane path change notification received from the 3GPP Core Network due to S-EAS request for "ACR facilitation" event (see clause 8.6.3) or due to step 1 . The detection entity may detect that ACR may be required for an expected or predicted UE location in the future as described in clause 8.8.1.1.

Phase II: ACR Decision

3. The detection entity performs ACR launching procedure (as described in clause 8.8.3.4) with the ACR action indicating ACR determination and the corresponding ACR determination data. If the EEC or S-EAS detect the ACR event, the EEC or S-EAS may inform S-EES with ACID, and predicted/expected UE location or Expected AC Geographical Service Area in the ACR launching procedure.

4. The S-EES authorises the message if received. The S-EES decides to execute ACR based on the information received or local detection, and the information of EEC context or EAS profile, and then proceed the below steps. When the S-EES receives the predicted/expected UE location or Expected AC Geographical Service Area from the EEC or the EAS in ACR determination, or the S-EES received service continuity planning from EAS in ACR facilitation event subscription, then the S-EES will determine to monitor the UE mobility. If S-EES has received information of on-going ACR, then it should not initiate an ACR with the same ACR identity uniquely identified by ACID, EEC ID (or UE ID), S-EAS endpoint and T-EAS endpoint again per clause 8.6.3.2.3.

Phase III: ACR Execution

5a. The S-EES determines T-EES and T-EAS via the Discover T-EAS procedure in clause 8, 8, 3, 2 of the present document. When in step 2 the ACR has been triggered for service continuity planning, then UE Location and Target DNAI values provided in the Retrieve T-EES procedure contain the expected UE Location and expected Target DNAI. The S-EES may decide not to perform ACR if T-EAS is not available.

If T-EAS discovery results in no T-EAS, and if ACR to CAS is supported, then the procedure for ACR with CAS applies as specified in clause 8.8.2A.5.

5b. If required, the S-EES performs ACR parameter information procedure by sending the ACR parameter information request to the T-EES as described in clause 8.8.3.9. For example, when the ACR is for service continuity planning, and the S-EES has received it in ACR launch in step 2, the S-EES sends ACR parameter information request which includes Prediction expiration time.

6. If the T-EES is different than the S-EES and the EEC Context at the S-EES is not stale, the S-EES initiates EEC Context Push relocation with the T-EES as described in clause

7. The S-EES sends the target information notification to the EEC as described in clause 8.8.3.5.3.

NOTE 2: Step 7 can be performed after step 5. The S-EES can send target information notification to the EEC immediately after having the target information in order to avoid EEC to initiate another ACR with the same identity

8. The S-EES may apply the AF traffic influence with the N6 routing information of the T- EAS in the 3GPP Core Network (if applicable). 9. The S-EES sends the ACR management notification (e.g. as notification for "ACR facilitation" event or "ACT start" event as described in clause 8.6.3 or due to step 1) to the S-EAS to initiate ACT between the S-EAS and the T-EAS.

10. The Application Context is transferred from S-EAS to the T-EAS at implementation specific time. In the case of EELManagedACR, the S-EES accesses the Application Context from the address as per step 1 and the S-EES and T-EES engage in the ACT from S-EAS to the T-EAS (obtained as per step 5) in a secure way. Further the T-EAS accesses the Application Context made available by the T-EES. If S-EAS performs the ACT directly with T-EAS, the specification of such process is out of scope of the present document.

NOTE 3: The Application Context is encrypted and protected by the application layer. The S- EES and the T-EES engage in the packet level transport of the Application Context and they have no visibility to the content of the Application Context.

When in step 2 the ACR has been triggered for service continuity planning, if the UE does not move to the predicted location, the EEC does not connect to T-EES, the AC does not connect to the T-EAS.

NOTE 3: The S-EAS or T-EAS can further decide to terminate the ACR, and the T-EAS can discard the application context based on information received from EEL and/or other methods (e.g. monitoring the location of the UE). It is up to the implementation of the S-EAS and T-EAS whether and how to make such a decision.

NOTE 4: When in step 2 the ACR has been triggered for service continuity planning, the S- EAS and the T-EAS can wait for the UE to move to the predicted location before they perform the Post ACR Clean up steps 12 and 13 if it is the EAS monitoring whether the UE moves to the predicted or expected location. When the S-EAS and the T-EAS do not wait for the UE (e.g., if the UE does not move to the predicted location), the S-EAS and the T-EAS can perform Post ACR Clean up with failure messages.

NOTE 5: If the S-EAS and T-EAS are main EASs forming proxy bundle, other EASs of the bundle may transfer the application contexts in this step. How to execute ACT is out of scope of this document.

Phase IV : Post-ACR Clean up

1 l.In case of EELManagedACR, once the ACT is successful, the T-EES sends an ACT status notification to the T-EAS as described in clause 8.8.3.6.2.4, indicating that the Application Context is available.

12. The S-EAS sends the ACR status update message to the S-EES as specified in clause 8.8.3.8.

13. The T-EAS sends the ACR status update message to the T-EES as specified in clause 8.8.3.8. If the status indicates a successful ACT, and that the EEC Context relocation procedure was attempted but failed, then the T-EES indicates the failure to the T-EAS with the ACR status update response. NOTE 6: If the EDGE-3 subscription initialization result indicates failure, then the EAS can perform the required EDGE-3 subscriptions at the T-EES.

NOTE 7: Steps 12 and 13 can occur in any order.

14. If the status in step 12 indicates a successful ACT or in the EELManagedACR case, the S- EES sends the ACR information notification (ACR complete) message immediately to the EEC to confirm that the ACR has completed as specified in clause 8.8.3.5.3. Forthe service continuity planning case, if it is EES monitors the UE mobility, then only when S- EES detects the UE has moved to the predicted/expected UE location or Expected AC Geographical Service Area and the status in step 12 indicates a successful ACT, then the S-EES sends ACR information notification (ACR complete) message to the EEC when the ACR type is service continuity planning. If the EEC Context relocation procedure was attempted, then the notification includes EEC context relocation status IE, indicating the result of the EEC context relocation procedure. If the EEC context relocation status indicates that the EEC context relocation was not successful, then the EEC may perform the required EDGE-1 operations such as create subscriptions at the T-EES.

NOTE 8: The Application Client mechanism to support switchover of the application traffic to T-EAS is out of scope of the specification.

[00184] FIG. 31 is a block diagram illustrating an apparatus suitable for use in practicing some embodiments of the disclosure. For example, any one of the first EAS, the first EES, the second EES and the repository entity described above may be implemented through the apparatus 3100. As shown, the apparatus 3100 may include a processor 3110, a memory 3120 that stores a program, and optionally a communication interface 3130 for communicating data with other external devices through wired and/or wireless communication.

[00185] The program includes program instructions that, when executed by the processor 3110, enable the apparatus 3100 to operate in accordance with the embodiments of the present disclosure, as discussed above. That is, the embodiments of the present disclosure may be implemented at least in part by computer software executable by the processor 3110, or by hardware, or by a combination of software and hardware.

[00186] The memory 3120 may be of any type suitable to the local technical environment and may be implemented using any suitable data storage technology, such as semiconductor based memory devices, flash memories, magnetic memory devices and systems, optical memory devices and systems, fixed memories and removable memories. The processor 3110 may be of any type suitable to the local technical environment, and may include one or more of general purpose computers, special purpose computers, microprocessors, digital signal processors (DSPs) and processors based on multi-core processor architectures, as non-limiting examples.

[00187] Based on the above description, the present disclosure also provides a computer program product. The computer program product may comprise instructions which when executed by at least one processor, cause the at least one processor to perform the method according to any of the above method embodiments.

[00188] In addition, the present disclosure also provides a computer readable storage medium. The computer readable storage medium may store thereon instructions which when executed by at least one processor, cause the at least one processor to perform the method according to any of the above method embodiments.

[00189] FIG. 32 is a block diagram illustrating a first EAS according to an embodiment of the disclosure. As shown in FIG. 32, the first EAS 3200 may comprise a sending module 3202 and a reception module 3204. The sending module 3202 may be configured to send, to a first EES, a first request for discovering one or more candidates of a second EAS, in an ACR for one or more group members in an application group from the first EAS to the second EAS. The first request may comprise an ID of the application group. The reception module 3204 may be configured to receive, from the first EES, a first response to the first request.

[00190] FIG. 33 is a block diagram illustrating a first EES according to an embodiment of the disclosure. As shown in FIG. 33, the first EES 3300 may comprise a first transceiving module 3302 and a second transceiving module 3304. The first transceiving module 3302 may be configured to receive or send a request for discovering one or more candidates of a second EAS, in an ACR for one or more group members in an application group from a first EAS to the second EAS. The request may comprise an ID of the application group. The second transceiving module 3304 may be configured to send or receive a response to the request.

[00191] FIG. 34 is a block diagram illustrating a second EES according to an embodiment of the disclosure. As shown in FIG. 34, the second EES 3400 may comprise a reception module 3402 and a sending module 3404. The reception module 3402 may be configured to receive, from a first EES, a fifth request for discovering one or more candidates of a second EAS, in an ACR for one or more group members in an application group from a first EAS to the second EAS. The fifth request may comprise an ID of the application group. The sending module 3404 may be configured to send, to the first EES, a fifth response to the fifth request.

[00192] FIG. 35 is a block diagram illustrating a repository entity according to an embodiment of the disclosure. As shown in FIG. 35, the repository entity 3500 may comprise a reception module 3502 and a sending module 3504. The reception module 3502 may be configured to receive, from a first EES, a fourth request for updating common EAS information at the repository entity, in an ACR for one or more group members in an application group from a first EAS to a second EAS. The fourth request may comprise an ID of the application group. The sending module 3504 may be configured to send, to the first EES, a fourth response to the fourth request. The modules described above may be implemented by hardware, or software, or a combination of both.

[00193] As such, it should be appreciated that at least some aspects of the exemplary embodiments of the disclosure may be practiced in various components such as integrated circuit chips and modules. It should thus be appreciated that the exemplary embodiments of this disclosure may be realized in an apparatus that is embodied as an integrated circuit, where the integrated circuit may comprise circuitry (as well as possibly firmware) for embodying at least one or more of a data processor, a digital signal processor, baseband circuitry and radio frequency circuitry that are configurable so as to operate in accordance with the exemplary embodiments of this disclosure.

[00194] It should be appreciated that at least some aspects of the exemplary embodiments of the disclosure may be embodied in computer-executable instructions, such as in one or more program modules, executed by one or more computers or other devices. Generally, program modules include routines, programs, objects, components, data structures, etc. that perform particular tasks or implement particular abstract data types when executed by a processor in a computer or other device. The computer executable instructions may be stored on a computer readable medium such as a hard disk, optical disk, removable storage media, solid state memory, RAM, etc. As will be appreciated by one skilled in the art, the function of the program modules may be combined or distributed as desired in various embodiments. In addition, the function may be embodied in whole or in part in firmware or hardware equivalents such as integrated circuits, field programmable gate arrays (FPGA), and the like.

[00195] References in the present disclosure to "one embodiment”, "an embodiment” and so on, indicate that the embodiment described may include a particular feature, structure, or characteristic, but it is not necessary that every embodiment includes the particular feature, structure, or characteristic. Moreover, such phrases are not necessarily referring to the same embodiment. Further, when a particular feature, structure, or characteristic is described in connection with an embodiment, it is submitted that it is within the knowledge of one skilled in the art to implement such feature, structure, or characteristic in connection with other embodiments whether or not explicitly described.

[00196] It should be understood that, although the terms "first”, "second” and so on may be used herein to describe various elements, these elements should not be limited by these terms. These terms are only used to distinguish one element from another. For example, a first element could be termed a second element, and similarly, a second element could be termed a first element, without departing from the scope of the disclosure. As used herein, the term "and/or” includes any and all combinations of one or more of the associated listed terms.

[00197] The terminology used herein is for the purpose of describing particular embodiments only and is not intended to limit the present disclosure. As used herein, the singular forms "a”, "an” and "the” are intended to include the plural forms as well, unless the context clearly indicates otherwise. It will be further understood that the terms "comprises”, "comprising”, "has”, "having”, "includes” and/or "including”, when used herein, specify the presence of stated features, elements, and/or components, but do not preclude the presence or addition of one or more other features, elements, components and/ or combinations thereof. The terms "connect”, "connects”, "connecting” and/or "connected” used herein cover the direct and/or indirect connection between two elements. It should be noted that two blocks shown in succession in the above figures may, in fact, be executed substantially concurrently, or the blocks may sometimes be executed in the reverse order, depending upon the functionality involved.

[00198] The present disclosure includes any novel feature or combination of features disclosed herein either explicitly or any generalization thereof. Various modifications and adaptations to the foregoing exemplary embodiments of this disclosure may become apparent to those skilled in the relevant arts in view of the foregoing description, when read in conjunction with the accompanying drawings. However, any and all modifications will still fall within the scope of the non-Limiting and exemplary embodiments of this disclosure.

Claims

1 . A method at a first edge application server, EAS, the method comprising: sending (902), to a first edge enabler server, EES, a first request for discovering one or more candidates of a second EAS, in an application context relocation, ACR, for one or more group members in an application group from the first EAS to the second EAS, wherein the first request comprises an identifier, ID, of the application group; and receiving (904), from the first EES, a first response to the first request.

2. The method according to claim 1, wherein the first request further comprises a list of user equipment, UE, IDs in the application group.

3. The method according to claim 1 or 2, further comprising: sending (1006), to the first EES, a second request for subscribing to a notification of an ACR management event, wherein a type of the subscribed ACR management event is ACR monitoring event or ACR facilitation event, and the second request comprises the ID of the application group; and receiving (1008), from the first EES, a second response to the second request.

4. The method according to any of claims 1 to 3, further comprising: sending (1110), to the first EES, a third request for declaring an EAS selected as the second EAS, wherein the third request comprises a list of UE IDs in the application group; and receiving (1112), from the first EES, a third response to the third request.

5. The method according to any of claims 1 to 4, wherein the ACR from the first EAS to the second EAS is one of: an ACR decided by the first EAS; and an ACR decided by the first EES.

6. A method at a first edge enabler server, EES, the method comprising: receiving or sending (1202) a request for discovering one or more candidates of a second edge application server, EAS, in an application context relocation, ACR, for one or more group members in an application group from a first EAS to the second EAS, wherein the request comprises an identifier, ID, of the application group; and sending or receiving (1204) a response to the request.

7. The method according to claim 6, wherein the request further comprises a list of user equipment, UE, IDs in the application group.

8. The method according to claim 6 or 7, wherein the request is a first request received from the first EAS, and the response is a first response sent to the first EAS; or wherein the request is a fifth request sent to a second EES, and the response is a fifth response received from the second EES.

9. The method according to claim 7 or 8, further comprising: determining (1306) one or more candidates of the second EAS based on the list of UE IDs in the application group.

10. The method according to claim 9, wherein at least one EAS is determined from one or more registered EASs in a first edge data network, EDN, corresponding to the first EES and one or more existing common EASs in one or more second EDNs, based on the list of UE IDs in the application group, so that each of the at least one EAS is a unique common EAS for the application group in corresponding EDN.

11. The method according to claim 10, wherein determining the at least one EAS comprises one or more of: when all UEs in the application group is within an overlapping area between a first service area of the first EDN and second service areas of the one or more second EDNs, checking (1408) whether there is an existing common EAS for the application group in the second EDN corresponding to the overlapping area; when there is an existing common EAS for the application group in the second EDN, determining (1410) an EAS from the one or more registered EASs in the first EES and the existing common EAS; when there is no existing common EAS for the application group in the second EDN, determining (1412) an EAS from the one or more registered EASs in the first EES; when at least one UE in the application group is not within the overlapping area, determining (1414) an EAS from the one or more registered EASs in the first EES; for a first subset of all UEs in the application group that is within at least one overlapping area with at least one second EDN, when there is at least one existing common EAS for the application group in the at least one second EDN, determining (1516), for the first subset, one of the at least one existing common EAS; and for a second subset of all UEs in the application group that is not within the overlapping area, determining (1518), for the second subset, an EAS from the one or more registered EASs in the first EES.

12. The method according to claim 11 , further comprising: when a registered EAS in the first EES is determined as a common EAS for the application group, updating (1620) common EAS information for the application group at a repository entity based on information about the registered EAS.

13. The method according to claim 8, wherein the fifth response comprises one or more EASs discovered by the second EES; and wherein the method further comprises: determining (1722), as a common EAS for the application group, one of the one or more discovered EASs; and storing (1724) information about the determined common EAS to a repository entity.

14. The method according to claim 13, further comprising: receiving (1726), from the repository entity, information about an existing common EAS for the application group, the existing common EAS being different from the determined common EAS.

15. The method according to any of claims 6 to 14, further comprising: receiving (1828), from the first EAS, a second request for subscribing to a notification of an ACR management event, wherein a type of the subscribed ACR management event is ACR monitoring event or ACR facilitation event, and the second request comprises the ID of the application group; and sending (1830), to the first EAS, a second response to the second request.

16. The method according to any of claims 6 to 15, further comprising: receiving (1932), from the first EAS, a third request for declaring an EAS selected as the second EAS, wherein the third request comprises a list of UE IDs in the application group; and sending (1934), to the first EAS, a third response to the third request.

17. The method according to claim 16, further comprising one or more of: sending (2036), to each of edge enabler clients, EEGs, for UEs indicated in the list of UE IDs, information about the selected EAS; and sending (2038), to each of the EEGs for the UEs indicated in the list of UE IDs, a notification about an ACR complete event.

18. The method according to any of claims 6 to 17, further comprising: sending (2140), to a repository entity, a fourth request for updating common EAS information at the repository entity, wherein the fourth request comprises the ID of the application group; and receiving (2142), from the repository entity, a fourth response to the fourth request.

19. The method according to claim 18, wherein the fourth request further comprises one or more of: an ID of a common EAS; an endpoint of the common EAS; an ID of the first EES; information about an EDN where the common EAS resides; and security credentials which result from a successful authorization for an edge computing service.

20 The method according to claim 18 or 19, wherein a fourth response to the fourth request comprises one or more of: a first indicator indicating that the fourth request was successful, or a second indicator indicating that the fourth request has failed; and a third indicator indicating a failure cause when the fourth request has failed.

21. The method according to any of claims 12 to 14 and 18 to 20, wherein the repository entity is an edge configuration server edge repository, ECS-ER.

22. The method according to any of claims 6 to 21 , wherein the ACR from the first EAS to the second EAS is one of: an ACR decided by the first EAS; and an ACR decided by the first EES.

23. A method at a second edge enabler server, EES, the method comprising: receiving (2202), from a first EES, a fifth request for discovering one or more candidates of a second edge application server, EAS, in an application context relocation, ACR, for one or more group members in an application group from a first EAS to the second EAS, wherein the fifth request comprises an identifier, ID, of the application group; and sending (2204), to the first EES, a fifth response to the fifth request.

24. The method according to claim 23, wherein the fifth request further comprises a list of user equipment, UE, IDs in the application group.

25. The method according to claim 24, further comprising: determining (2306) one or more candidates of the second EAS based on the list of UE IDs in the application group.

26. A method at a repository entity, the method comprising: receiving (2402), from a first edge enabler server, EES, a fourth request for updating common edge application server, EAS, information at the repository entity, in an application context relocation, ACR, for one or more group members in an application group from a first EAS to a second EAS, wherein the fourth request comprises an identifier, ID, of the application group; and sending (2404), to the first EES, a fourth response to the fourth request.

27. The method according to claim 26, further comprising one or more of: determining (2506) whether there is a stored EAS serving the application group within a same edge data network, EDN; when there is a stored EAS serving the application group within the same EDN, updating (2508) information about the stored EAS based on common EAS information indicated in the fourth request; and when there is no stored EAS serving the application group within the same EDN, rejecting (2510) the fourth request.

28. The method according to claim 26 or 27, wherein the fourth request further comprises one or more of: an ID of a common EAS; an endpoint of the common EAS; an ID of the first EES; information about an EDN where the common EAS resides; and security credentials which result from a successful authorization for an edge computing service.

29. The method according to any of claims 26 to 28, wherein a fourth response to the fourth request comprises one or more of: a first indicator indicating that the fourth request was successful, or a second indicator indicating that the fourth request has failed; and a third indicator indicating a failure cause when the fourth request has failed.

30. The method according to any of claims 26 to 29, wherein the repository entity is an edge configuration server edge repository, ECS-ER.

31. A first edge application server, EAS (3100), comprising: at least one processor (3110); and at least one memory (3120), the at least one memory (3120) containing instructions executable by the at least one processor (3110), whereby the first EAS (3100) is operative to: send, to a first edge enabler server, EES, a first request for discovering one or more candidates of a second EAS, in an application context relocation, ACR, for one or more group members in an application group from the first EAS to the second EAS, wherein the first request comprises an identifier, ID, of the application group; and receive, from the first EES, a first response to the first request.

32. The first EAS (3100) according to claim 31 , wherein the first EAS (3100) is operative to perform the method according to any of claims 2 to 5.

33. A first edge enabler server, EES (3100), comprising: at least one processor (3110); and at least one memory (3120), the at least one memory (3120) containing instructions executable by the at least one processor (3110), whereby the first EES (3100) is operative to: receive or send a request for discovering one or more candidates of a second edge application server, EAS, in an application context relocation, ACR, for one or more group members in an application group from a first EAS to the second EAS, wherein the request comprises an identifier, ID, of the application group; and send or receive a response to the request.

34. The first EES (3100) according to claim 33, wherein the first EES (3100) is operative to perform the method according to any of claims 7 to 22.

35. A second edge enabler server, EES (3100), comprising: at least one processor (3110); and at least one memory (3120), the at least one memory (3120) containing instructions executable by the at least one processor (3110), whereby the second EES (3100) is operative to: receive, from a first EES, a fifth request for discovering one or more candidates of a second edge application server, EAS, in an application context relocation, ACR, for one or more group members in an application group from a first EAS to the second EAS, wherein the fifth request comprises an identifier, ID, of the application group; and send, to the first EES, a fifth response to the fifth request.

36. The second EES (3100) according to claim 35, wherein the second EES (3100) is operative to perform the method according to any of claims 24 or 25.

37. A repository entity (3100) comprising: at least one processor (3110); and at least one memory (3120), the at least one memory (3120) containing instructions executable by the at least one processor (3110), whereby the repository entity (3100) is operative to: receive, from a first edge enabler server, EES, a fourth request for updating common edge application server, EAS, information at the repository entity, in an application context relocation, ACR, for one or more group members in an application group from a first EAS to a second EAS, wherein the fourth request comprises an identifier, ID, of the application group; and send, to the first EES, a fourth response to the fourth request.

38. The repository entity (3100) according to claim 37, wherein the repository entity (3100) is operative to perform the method according to any of claims 27 to 30.

39. A computer readable storage medium storing thereon instructions which when executed by at least one processor, cause the at least one processor to perform the method according to any of claims 1 to 30.