Method and apparatus for service continuity
By setting an information element in ACR request messages to differentiate between normal and planned service continuity, the method addresses synchronization gaps in edge computing systems, ensuring seamless service continuity and preventing interruptions.
Patent Information
- Application Number
- JP2025174787
- Authority / Receiving Office
- JP · JP
- Patent Type
- Applications
- Current Assignee / Owner
- Priority Date
- 2021-05-18
- Filing Date
- 2025-10-16
- Publication Date
- 2026-02-18
AI Technical Summary
Existing edge computing systems lack synchronization in service continuity planning, leading to suboptimal traffic routing and service interruptions when user equipment moves to new locations, as edge application servers do not differentiate between normal and planned service continuity.
Implementing a method where edge enabler clients and servers set an information element in ACR request messages to indicate the type of service continuity, distinguishing between normal and planned service continuity, ensuring seamless application context relocation.
Ensures proper execution of application context relocation, preventing suboptimal traffic routing and service interruptions by aligning edge application server actions with planned service continuity, thereby maintaining service continuity.
Smart Images

Figure 2026027266000001_ABST
Abstract
Description
[Technical Field]
[0001] Non-limiting, exemplary embodiments of the present disclosure relate generally to the field of communications, and more particularly to methods and apparatus for service continuity. [Background technology]
[0002] This section introduces aspects that may facilitate a better understanding of the present disclosure. Accordingly, the statements in 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 outside the prior art.
[0003] Edge computing is a network architecture concept that enables cloud computing capabilities and service environments to be deployed closer to user equipment (UE), promising several benefits compared to cloud environments, including lower latency, higher bandwidth, reduced backhaul traffic, and the prospect of new services. 3rd Generation Partnership Project (3GPP) TS23.558 V2.1.0, the disclosure of which is incorporated herein by reference in its entirety, provides an application layer architecture and related procedures for enabling edge applications on 3GPP networks.
[0004] 3GPP TS23.558 V2.1.0 specifies the application layer architecture, procedures, and information flows required to enable edge applications on 3GPP networks. It includes architectural requirements for enabling edge applications, an application layer architecture that satisfies those architectural requirements, and procedures that enable the deployment of edge applications. One of the primary areas of focus is minimizing the impact on edge-based applications so that they do not require redevelopment of key applications for UEs at the edge.
[0005] Figure 1 shows an example architecture for enabling edge applications. Figure 1 is identical to Figure 6.2-4 of 3GPP TS23.558 V2.1.0. The Edge Data Network (EDN) is a local data network. The Edge Application Server (EAS) and Edge Enabler Server (EES) are included within the scope of the EDN. The Edge Configuration Server (ECS) provides relevant configuration to the Edge Enabler Server (EES), including details of the edge data network hosting the EES. The UE includes an application client and an edge enabler client. The Edge Application Server (EAS), Edge Enabler Server, and Edge Configuration Server may interact with the 3GPP core network.
[0006] There may be several functional entities in edge computing. For example, one or more application clients (ACs) may reside in a UE. One or more edge enabler clients (EECs) may reside in a UE. One or more edge configuration servers (ECSs) may be deployed to support one edge data network. One ECS may be deployed to support one or more EDNs. One or more ECSs may be deployed by a public land mobile network (PLMN) operator. One or more ECSs may be deployed by an edge computing service provider (ECSP). One or more edge enabler servers (EESs) may reside in an EDN. One or more EESs may reside in an EDN per ECSP. One or more edge application servers (EASs) may reside in an EDN. EASs belonging to the same EAS identifier (ID) may be provided by multiple ECSPs in an EDN.
[0007] The EDGE-1 reference point may enable interaction between an edge enabler server and an edge enabler client. The EDGE-2 reference point enables interaction between the EES and 3GPP core network functions and APIs for retrieving network capability information. The EDGE-3 reference point enables interaction between the EES and EAS. The EDGE-4 reference point enables interaction between the ECS and EEC. The EDGE-5 reference point enables interaction between the AC and EEC. The EDGE-6 reference point enables interaction between the ECS and EES. The EDGE-7 reference point enables interaction between the EAS and 3GPP core network functions and APIs for retrieving network capability information. The EDGE-8 reference point enables interaction between the ECS and 3GPP core network functions and APIs for retrieving network capability information. The EDGE-9 reference point enables interaction between two EESs.
[0008] When a UE moves to a new location, a different EAS may be better suited to serve the AC in that UE. Such a transition may also be the result of a non-mobility event and requires support from the enabling layer to maintain service continuity. Alternatively, the EAS may be changed due to load balancing or operation and maintenance (O&M) reasons.
[0009] Figure 2 shows a high-level overview of the Application Context Relocation (ACR) procedure.
[0010] Step 1. A detection entity detects that an application context relocation may be required.
[0011] Step 2. A decision-making entity determines whether application context relocation is necessary.
[0012] Step 3. The execution entity performs the application context relocation.
[0013] Step 4. All required entities may perform actions after the application context relocation.
[0014] ACR can be performed for service continuity planning, where planning means that the first three steps of the ACR procedure, namely, detection, determination, and execution, are performed for the planned / predicted location of the UE, in which case the target EAS (T-EAS) will serve the UE when it moves to the planned location. Summary of the Invention
[0015] This Summary is provided to introduce certain 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.
[0016] Service continuity planning is a value-added feature of the edge enabler layer that provides support for seamless service continuity when information about planned, projected, or expected behavior is available in the EES or provided by the EEC.
[0017] To implement service continuity planning, the EES may utilize:
[0018] - Information provided by the EEC, such as the AC schedule, the geographical service area of the planned AC, the planned service KPIs (Key Performance Indicators), and the preferred ECSP list; and
[0019] 3GPP Core Network Capabilities used by the EES as described in Section 8.10.3 of 3GPP TS23.558 V2.1.0
[0020] Currently, five ACR scenarios (triggered by the UE or EDN) are specified in 3GPP TS23.558 V2.1.0, section 8.8.2.2, 8.8.2.3, 8.8.2.4, 8.8.2.5, and 8.8.2.6, respectively, for additional details regarding service continuity planning for ACR.
[0021] The cleanup stage of ACR is only executed when the UE moves to the planned location. Also, the Application Context Transfer (ACT) in planned service continuity is different from that in normal service continuity. In planned service continuity, the application context in the target EAS (T-EAS) is synchronized with the latest information in the source EAS (S-EAS) from the time when the UE has not yet moved to the predicted / planned location until the time when the UE actually moves to the predicted / planned location. Therefore, to use it differently from ACT and to control when the cleanup stage starts, the edge entity responsible for triggering ACT and subsequent cleanup stages needs to be synchronized with the type of service continuity (i.e., normal or planned) detected by other edge entities.
[0022] In all ACR scenarios specified in 3GPP TS23.558 V2.1.0, section 8.8.2, the following applies:
[0023] For the scenario detected, decided and executed by the EEC via itself (Scenario #1 in Section 8.8.2.2 of 3GPP TS23.558 V2.1.0), the EEC as the detecting entity knows whether it is a planned service continuity. It is assumed that the EEC can notify the AC about the service continuity type via EDGE-5.
[0024] For scenarios detected, determined and executed by the S-EAS (Scenario #3 in Section 8.8.2.4 of 3GPP TS23.558 V2.1.0), the S-EAS as the detecting entity and ACT executing entity knows whether it is a planned service continuity.
[0025] For scenarios involving execution via the source EES (S-EES) detected and determined by the EEC (Scenario #2 in Section 8.8.2.3 of 3GPP TS23.558 V2.1.0), the S-EES as the ACT execution entity does not know if it is the planned service continuity.
[0026] For scenarios involving detection and decision by the EEC and execution via the Target EES (T-EES) (Scenario #5 in Section 8.8.2.6 of 3GPP TS23.558 V2.1.0), the T-EES as the ACT execution entity does not know if it is the planned service continuity.
[0027] For the scenario determined and executed by S-EES (Scenario #4 in Section 8.8.2.5 of 3GPP TS23.558 V2.1.0), the following applies: a) When it is detected by the EEC, the S-EAS as the ACT execution entity does not know whether it is for a normal ACR or a planned ACR. b) If it is detected by the S-EAS, the S-EAS as the detection entity and ACT execution entity knows whether service continuity planning is required. c) If it is detected by the S-EES, the S-EAS as the ACT performing entity does not know whether it is for a normal ACR or a planned ACR.
[0028] From the above analysis, for scenarios #2, #5 and #4 (a and c), there is a gap in synchronizing Service Continuity Planning information to Edge Application Server when Service Continuity Planning detection is done by Edge Enabler Layer.
[0029] To overcome or mitigate at least one of the above-referenced problems or other problems, improved service continuity management would be desirable.
[0030] In a first aspect of the present disclosure, there is provided a method performed by an edge enabler client, the method including detecting a need for application context relocation (ACR), the method further including setting an information element in an ACR request message indicating a type of service continuity, and the method further including sending the ACR request message to an edge enabler server.
[0031] In one embodiment, the edge enabler server is a source edge enabler server.
[0032] In one embodiment, the ACR is performed by the edge enabler client via the source edge enabler server.
[0033] In one embodiment, the ACR is performed by the source edge enabler server.
[0034] In one embodiment, the edge enabler server is a target edge enabler server.
[0035] In one embodiment, the ACR is performed by the edge enabler client via the target edge enabler server.
[0036] In one embodiment, if the information element indicating the type of service continuity in the ACR request message is set, the ACR request message indicates that the ACR is triggered for service continuity planning.
[0037] In one embodiment, if the information element indicating the type of service continuity is omitted in the ACR request message, the ACR request message indicates that the ACR is triggered for normal service continuity.
[0038] In one embodiment, the type of service continuity includes at least one of service continuity planning or normal service continuity.
[0039] In a second aspect of the present disclosure, there is provided a method executed by an edge enabler server, the method including determining that application context relocation (ACR) is required, the method further including setting an information element indicating a type of service continuity in a notification message for the ACR, and the method further including sending the notification message for the ACR to an edge application server.
[0040] In one embodiment, determining that an application context relocation (ACR) is required includes receiving an ACR request message from an edge enabler client, the ACR request message including the information element indicating the type of service continuity, and determining that the ACR is required based on the ACR request message including the information element indicating the type of service continuity.
[0041] In one embodiment, determining that application context relocation (ACR) is required includes detecting that the ACR is required, and determining that application context relocation (ACR) is required based on the detection.
[0042] In one embodiment, if the information element indicating the type of service continuity is set in the notification message for the ACR, the notification message for the ACR indicates that the ACR is triggered for service continuity planning.
[0043] In one embodiment, if the information element indicating the type of service continuity is omitted in the notification message for the ACR, the notification message for the ACR indicates that the ACR is triggered for normal service continuity.
[0044] In a third aspect of the present disclosure, there is provided a method executed by an edge application server. The method includes receiving a notification message for application context relocation (ACR) from an edge enabler server. The notification message for the ACR includes an information element indicating a type of service continuity. The method further includes determining whether the ACR is triggered for service continuity planning based on the information element indicating the type of service continuity. If the ACR is triggered for service continuity planning, the method further includes sending an ACR completion message to the edge enabler server to confirm that the ACR is completed after a user equipment associated with the ACR moves to a scheduled location.
[0045] In a fourth aspect of the present disclosure, there is provided an edge enabler client, the edge enabler client comprising: a processor; and a memory coupled to the processor; the memory including instructions executable by the processor; the edge enabler client operable to detect that an application context relocation (ACR) is required; the edge enabler client further operable to set an information element indicating a type of service continuity in an ACR request message; and the edge enabler client further operable to send the ACR request message to an edge enabler server.
[0046] In a fifth aspect of the present disclosure, there is provided an edge enabler server. The edge enabler server includes a processor and a memory coupled to the processor. The memory includes instructions executable by the processor. The edge enabler server is operable to determine that application context relocation (ACR) is required. The edge enabler server is further operable to set an information element indicating a type of service continuity in a notification message for the ACR. The edge enabler server is further operable to send the notification message for the ACR to an edge application server.
[0047] In a sixth aspect of the present disclosure, there is provided an edge application server. The edge application server includes a processor and a memory coupled to the processor. The memory includes instructions executable by the processor. The edge application server is operable to receive a notification message for application context relocation (ACR) from an edge enabler server. The notification message for the ACR includes an information element indicating a type of service continuity. The edge application server is further operable to determine whether the ACR has been triggered for service continuity planning based on the information element indicating the type of service continuity. If the ACR has been triggered for service continuity planning, the edge application server is further operable to send an ACR completion message to the edge enabler server to confirm that the ACR has been completed after a user equipment associated with the ACR moves to a scheduled location.
[0048] In a seventh aspect of the present disclosure, there is provided an edge enabler client comprising a detection module, a setting module, and a sending module. The detection module may be configured to detect that an application context relocation (ACR) is required. The setting module may be configured to set an information element indicating a type of service continuity in an ACR request message. The sending module may be configured to send the ACR request message to an edge enabler server.
[0049] In an eighth aspect of the present disclosure, there is provided an edge enabler server. The edge enabler server includes a determination module, a setting module, and a sending module. The determination module may be configured to determine that application context relocation (ACR) is required. The setting module may be configured to set an information element indicating a type of service continuity in a notification message for the ACR. The sending module may be configured to send the notification message for the ACR to an edge application server.
[0050] In a ninth aspect of the present disclosure, an edge application server is provided. The edge application server includes a receiving module, a determining module, and a transmitting module. The receiving module may be configured to receive a notification message for application context relocation (ACR) from an edge enabler server. The notification message for the ACR includes an information element indicating a type of service continuity. The determining module may be configured to determine whether the ACR is triggered for service continuity planning based on the information element indicating the type of service continuity. If the ACR is triggered for service continuity planning, the transmitting module may be configured to send an ACR completion message to the edge enabler server to confirm that the ACR is completed after a user equipment associated with the ACR moves to a scheduled location.
[0051] In a tenth aspect of the present disclosure, there is provided a computer program product comprising instructions that, when executed on at least one processor, cause the at least one processor to perform any of the methods according to the first, second and third aspects of the present disclosure.
[0052] In an eleventh aspect of the present disclosure, there is provided a computer-readable storage medium storing a set of instructions that, when executed on at least one processor, cause the at least one processor to perform any of the methods according to the first, second and third aspects of the present disclosure.
[0053] Embodiments herein provide many advantages, a non-exhaustive list of examples of which follows: Some embodiments herein may resolve issues when an edge application server, such as an S-EAS or a T-EAS, does not have knowledge of whether the ACR is for normal service continuity or service continuity planning, allowing the edge application server, such as an S-EAS or a T-EAS, to properly send an ACR complete message at the correct time. Some embodiments herein may avoid situations where an AC connects to a T-EAS before the UE has moved to its scheduled location, resulting in suboptimal traffic routing or service interruption. Embodiments herein are not limited to the features and advantages mentioned above. Those skilled in the art will recognize additional features and advantages after reading the following detailed description. [Brief explanation of the drawings]
[0054] The above and other aspects, features, and benefits of various embodiments of the present disclosure will become more fully apparent, by way of example, from the following detailed description, which takes reference to the accompanying drawings, in which like reference numerals or letters are used to designate similar or equivalent elements. The drawings are presented to facilitate a better understanding of the embodiments of the present disclosure, are not necessarily drawn to scale, and are as follows:
[0055] [Figure 1] 1 illustrates an exemplary architecture for enabling edge applications. [Figure 2] 1 shows a high-level overview of the Application Context Relocation (ACR) procedure. [Figure 3]1 shows a schematic diagram of the high-level architecture of a 4G network. [Figure 4] 1 illustrates a schematic diagram of a high-level architecture within a fifth generation network according to an embodiment of the present disclosure. [Figure 5] 1 shows a flowchart of a method according to an embodiment of the present disclosure. [Figure 6] 10 shows a flowchart of a method according to another embodiment of the present disclosure. [Figure 7] 10 shows a flowchart of a method according to another embodiment of the present disclosure. [Figure 8a] 1 illustrates a notification operation between an EES and an EAS for continuous ACR management event notification according to one embodiment of the present disclosure. [Figure 8b] 1 illustrates a procedure for an EEC to perform ACR via S-EES according to one embodiment of the present disclosure. [Figure 9] 1 illustrates a procedure by which the S-EES detects, determines, and executes an ACR from the S-EAS to the T-EAS according to one embodiment of the present disclosure. [Figure 10] 1 illustrates a procedure for an EEC to perform ACR via a T-EES according to one embodiment of the present disclosure. [Figure 11] 1 illustrates an ACR launch procedure by an EEC according to one embodiment of the present disclosure. [Figure 12] FIG. 1 is a block diagram illustrating an apparatus suitable for practicing some embodiments of the present disclosure. [Figure 13] FIG. 2 is a block diagram illustrating an edge enabler client according to an embodiment of the present disclosure. [Figure 14] FIG. 2 is a block diagram illustrating an edge enabler server according to an embodiment of the present disclosure. [Figure 15] FIG. 1 is a block diagram illustrating an edge application server according to an embodiment of the present disclosure. DETAILED DESCRIPTION OF THE INVENTION
[0056] Embodiments of the present disclosure will now be described in more detail with reference to the accompanying drawings. It should be understood that these embodiments are discussed solely to enable those skilled in the art to better understand and implement the present disclosure, rather than to suggest any limitation on the scope of the present disclosure. Throughout this specification, references to features, advantages, or similar terms do not imply that all of the features and advantages that may be realized with the present disclosure should or will appear in any single embodiment of the present disclosure. Rather, terms referring to features and advantages are understood to mean that the particular feature, advantage, or characteristic described in connection with an embodiment is included in at least one embodiment of the present disclosure. Furthermore, the described features, advantages, and characteristics of the present disclosure may be combined in any suitable manner in one or more embodiments. Those skilled in the art will recognize that the present disclosure can be practiced without one or more of the specific features or advantages of a particular embodiment. In other instances, additional features and advantages may be recognized in some embodiments, which may not appear in all embodiments of the present disclosure.
[0057] As used herein, the term "network" refers to a network that conforms to any suitable wireless communications standard, such as New Radio (NR), Long Term Evolution (LTE), LTE-Advanced, Wideband Code Division Multiple Access (WCDMA), High-Speed Packet Access (HSPA), Code Division Multiple Access (CDMA), Time Division Multiple Access (TDMA), Frequency Division Multiple Access (FDMA), Orthogonal Frequency Division Multiple Access (OFDMA), Single-Carrier Frequency Division Multiple Access (SC-FDMA), and other wireless networks. A CDMA network may implement a radio technology such as Universal Terrestrial Radio Access (UTRA). UTRA includes WCDMA and other derivatives of CDMA. A TDMA network may implement a radio technology such as Global System for Mobile Communications (GSM). An OFDMA network may implement a radio technology such as Evolved UTRA (E-UTRA), Ultra Mobile Broadband, IEEE 802.11 (Wi-Fi), IEEE 802.16 (WiMAX), IEEE 802.20, Flash OFDMA, an ad hoc network, a wireless sensor network, etc. In the following description, the terms "network" and "system" may be used interchangeably. Furthermore, communication between two devices in a network may occur according to any suitable communication protocol, including, but not limited to, communication protocols as defined by a standardization body such as 3GPP. For example, the communication protocol may include first generation (1G), 2G, 3G, 4G, 4.5G, 5G communication protocols, and / or any other protocol either currently known or to be developed in the future.
[0058] The term "network function" refers to any suitable function that can be implemented in a network entity (physical or virtual) of a communications network. For example, a network function may be implemented either as a network element on dedicated hardware, as a software instance running on dedicated hardware, or as a virtualized function instantiated on a suitable platform, such as a cloud infrastructure. For example, a 5G system (5GS) may include multiple NFs, such as an Access and Mobility Function (AMF), a Session Management Function (SMF), an Authentication Service Function (AUSF), a Unified Data Management Function (UDM), a Policy Control Function (PCF), an Application Function (AF), a Network Exposure Function (NEF), a User Plane Function (UPF), and a Network Repository Function (NRF), a Radio Access Network (RAN), a Service Communication Proxy (SCP), a Network Data Analytics Function (NWDAF), a Network Slice Selection Function (NSSF), a Network Slice Specific Authentication and Authorization Function (NSSAAF), etc. For example, a 4G system (such as LTE) may include a Mobility Management Entity (MME), a Home Subscriber Server (HSS), a Service Capability Exposure Function (SCEF), etc. In other embodiments, the network functions may include different types of NFs, depending, for example, on the particular network.
[0059] The term "terminal device" refers to any end device capable of accessing and receiving services from a communications network. By way of example and not limitation, a terminal device may refer to a mobile terminal, user equipment (UE), or other suitable device. A UE may be, for example, a subscriber station (SS), a portable subscriber station, a mobile station (MS), or an access terminal (AT). Terminal devices may include, but are not limited to, portable computers, imaging terminal devices such as digital cameras, gaming terminal devices, music storage and playback appliances, mobile phones, cellular phones, smartphones, voice over IP (VoIP) phones, wireless local loop phones, tablets, wearable devices, personal digital assistants (PDAs), portable computers, desktop computers, wearable terminal devices, in-vehicle wireless terminal devices, wireless endpoints, mobile stations, laptop-embedded equipment (LEE), laptop-mounted equipment (LME), USB dongles, smart devices, and wireless customer-premises equipment (CPE). In the following description, the terms "terminal device," "terminal," "user equipment," and "UE" may be used interchangeably. As one example, a terminal device may represent a UE configured for communication according to one or more communication standards promulgated by 3GPP, such as the 3GPP LTE or NR standards. As used herein, "user equipment" or "UE" may not necessarily have a "user" in the sense of a human user who owns and / or operates the associated device. In some embodiments, a terminal device may be configured to transmit and / or receive information without direct human interaction. For example, a terminal device may be designed to transmit information to a network on a predetermined schedule, when triggered by an internal or external event, or in response to a request from the communication network.Alternatively, a UE may represent a device intended for sale to or operation by a human user, but which may not initially be associated with a particular human user.
[0060] As yet another example, in an Internet of Things (IoT) scenario, a terminal device may represent a machine or other device that performs monitoring and / or measurements and transmits results of such monitoring and / or measurements to other terminal devices and / or network equipment. The terminal device, in this case, may be a machine-to-machine (M2M) device, which may also be referred to as a machine-type communication (MTC) device in the 3GPP context. As one specific example, the terminal device may be a UE implementing the 3GPP Narrowband IoT (NB-IoT) standard. Specific examples of such machines or devices are sensors, metering devices such as power meters, industrial machinery, or household or personal appliances, e.g., refrigerators, televisions, clocks, and other personal wearable items. In other scenarios, the terminal device may represent a vehicle or other equipment capable of monitoring and / or reporting its operational status or other functions associated with its operation.
[0061] References herein to "one embodiment," "an embodiment," "an exemplary embodiment," etc., indicate that while the described embodiment may include a particular feature, structure, or characteristic, not all embodiments necessarily include that particular feature, structure, or characteristic. Moreover, such phrases do not necessarily refer to the same embodiment. Furthermore, when a particular feature, structure, or characteristic is described in the context of one embodiment, it is contemplated that it is within the knowledge of one of ordinary skill in the art to employ that feature, structure, or characteristic in the context of other embodiments, whether or not explicitly stated.
[0062] Although terms such as "first," "second," etc. may be used herein to describe various elements, it should be understood that such elements are not limited by these terms. These terms are merely used to distinguish one element from another. For example, a first element could be referred to as a second element, and similarly, a second element could be referred to as a first element, without departing from the scope of the exemplary embodiments. As used herein, the term "and / or" includes any and all combinations of one or more of the associated listed items.
[0063] As used herein, the phrase "at least one of A and / or B" or "at least one of A or B" should be understood to mean "A only, B only, or both A and B." The phrase "A and / or B" should be understood to mean "A only, B only, or both A and B."
[0064] The terminology used herein is for the purpose of describing particular embodiments only and is not intended to limit the concepts described herein. 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," as used herein, specify the presence of stated features, elements, and / or components, but do not exclude the presence or addition of one or more other features, elements, components, and / or combinations thereof.
[0065] It should be noted that these terms, as used in this document, are only used to facilitate description and distinction between nodes, devices, networks, etc. As technology develops, other terms having similar / identical meanings may also be used.
[0066] In the following description and claims, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this disclosure belongs, unless defined otherwise.
[0067] It should be noted that some embodiments of the present disclosure are primarily described in the context of cellular networks, as defined by 3GPP, which are used as a non-limiting example for certain exemplary network configurations and system deployments. Therefore, the descriptions of the exemplary embodiments provided herein specifically refer to terminology directly related thereto. Such terminology is used solely in the context of the non-limiting examples and embodiments presented and is not intended to limit the present disclosure in any way. Rather, any other system configuration or radio technology, such as a wireless sensor network, may equally be utilized, so long as the exemplary embodiments described herein are applicable.
[0068] 3 and 4 illustrate some 3GPP system architectures in which embodiments of the present disclosure may be implemented. For clarity, the system architectures of FIGS. 3 and 4 depict only some example elements. In practice, a communication system may further include any additional elements suitable for supporting communications between terminal devices or between terminal devices and other communication devices, such as a landline telephone, a service provider, or some other network node or terminal device. A communication system may provide communications and various types of services to one or more terminal devices to facilitate terminal device access to and / or use of services provided by or via the communication system.
[0069] FIG. 3 shows a schematic diagram of the high-level architecture in a 4G network, and is identical to FIG. 4.2-1a of 3GPP TS23.682V16.9.0, the disclosure of which is incorporated herein by reference in its entirety. The system architecture of Figure 3 may include several example elements, such as an SCS, an AS, an SCEF, a Home Subscriber Server (HSS), a UE, a Radio Access Network (RAN), a Serving General Packet Radio Service (GPRS) Support Node (SGSN), a Mobility Management Entity (MME), a Mobile Switching Center (MSC), a Serving Gateway (S-GW), a Gateway GPRS Support Node (GGSN) / Packet Data Network (PDN) Gateway, a Machine Type Communication Interworking Function (MTC-IWF), a Charging Data Function (CDF) / Charging Gateway Function (CGF), a Machine Type Communication - Authentication, Authorization, and Accounting (AAA), a Short Message Service (SMS) - Service Center (SC) / Gateway MSC (GMSC) / Interworking MSC (IWMSC), and an Internet Protocol Short Message Gateway (IP-SM-GW). The network elements and interfaces shown in Figure 3 may be identical to the corresponding network elements and interfaces as described in 3GPP TS23.682 V16.9.0.
[0070] FIG. 4 schematically illustrates a high-level architecture within a fifth-generation network according to one embodiment of the present disclosure. For example, the fifth-generation network may be a 5GS. The architecture of FIG. 4 is identical to FIG. 4.2.3-1 described in 3GPP TS23.501 V17.0.0, the disclosure of which is incorporated herein by reference in its entirety. The system architecture of FIG. 4 may include several exemplary elements, such as an AUSF, an AMF, a data network (DN), a NEF, an NRF, an NSSF, a PCF, an SMF, a UDM, a UPF, an AF, a UE, an (R)AN, a service communication proxy (SCP), a network slice specific authentication and authorization function (NSSAAF), a network slice admission control function (NSACF), etc.
[0071] According to an example embodiment, a UE may establish a signaling connection with the AMF over reference point N1 as shown in Figure 4. This signaling connection may enable the exchange of non-access stratum (NAS) signaling between the UE and the core network, including a signaling connection between the UE and the (R)AN and an N2 connection between the (R)AN and the AMF for the UE. The (R)AN may communicate with the UPF over reference point N3. The UE may establish a protocol data unit (PDU) session to a DN (a data network, e.g., an operator network or the Internet) through the UPF over reference point N6.
[0072] As further shown in Figure 4, the exemplary system architecture also includes service-based interfaces, such as Nnrf, Nnef, Nausf, Nudm, Npcf, Namf, Nnsacf, and Nsmf, exposed by NFs, such as NRF, NEF, AUSF, UDM, PCF, AMF, NSACF, and SMF. In addition, Figure 4 also shows several reference points, such as N1, N2, N3, N4, N6, and N9, that can support interactions between NF services in the NFs. For example, these reference points can be realized by identifying several NF service customers and providers and their interactions through the corresponding NF service-based interfaces for the purpose of performing specific system procedures.
[0073] The various NFs shown in Figure 4 may be responsible for functions such as session management, mobility management, authentication, security, etc. The AUSF, AMF, DN, NEF, NRF, NSSF, PCF, SMF, UDM, UPF, AF, UE, (R)AN, SCP, and NSACF may include functionality as defined, for example, in section 6.2 of 3GPP TS23.501 V17.0.0.
[0074] Figure 5 illustrates a flowchart of a method according to one embodiment of the present disclosure that may be performed by a device implemented in, at, or as an edge enabler client, such as the EEC of Figure 1, or a device communicatively coupled to the edge enabler client. As such, the device may provide means or modules for accomplishing various portions of method 500, as well as means or modules for accomplishing other processes in conjunction with other components.
[0075] In block 502, the edge enabler client may detect that application context relocation (ACR) is required. In one embodiment, the edge enabler client detects that ACR may be required as described in Section 8.8.1 of 3GPP TS23.558 V2.1.0. The EEC may detect that ACR may be required for a UE's planned or predicted location in the future as described in Section 8.8.1 of 3GPP TS23.558 V2.1.0.
[0076] As described in 3GPP TS23.558 V2.1.0, section 8.8.1, when a UE moves to a new location, a different EAC may be more suitable to serve the ACs in that UE. Such a transition may also be the result of a non-mobility event and requires support from an enabling layer to maintain service continuity.
[0077] Supporting service continuity for AC in the UE can minimize service interruption while replacing S-EAS with T-EAS.
[0078] Generally, the S-EAS is associated with an application context, which is transferred from the S-EAS to the T-EAS to support service continuity.
[0079] The capabilities for supporting service continuity provided at the edge enabler layer may take into account a variety of application layer scenarios that may involve an AC and one or more EASs.
[0080] For service continuity, the following intra-EDN, inter-EDN and Local Area Data Network (LADN) related scenarios are supported: - UE mobility, including predicted or planned UE mobility for the following cases: - Overload situations in S-EAS or EDN for the following cases: - Maintenance aspects such as graceful shutdown of EAS.
[0081] To support the need for ACR, the roles of the following entities are identified: - a detection entity that detects or predicts the need for ACR; - the decision-making entity that makes the decision that an ACR is required; and - The executing entity that executes the ACR.
[0082] The detection entity detects the possible need for ACR by monitoring various aspects such as the UE location or predicted / scheduled UE location and instructs the decision-making entity to determine whether ACR is required. The AC, EEC, EES, and EAS can potentially play a role in detection.
[0083] The decision-making entity determines that ACR is required and instructs the execution entity to perform ACR.
[0084] The execution entity performs ACR when and as instructed by the decision-making entity.
[0085] After determining that another EAS should serve the UE, the S-EAS may determine whether the existing application context is transferred to the new EAS.
[0086] The EAS may utilize the following capabilities provided by the EES to support service continuity at the application layer: - Subscribe to service continuity related events and receive corresponding notifications; - Obtain T-EAS, and - ACR from S-EAS to T-EAS.
[0087] The EES may utilize the following capabilities provided by the ECS to support service continuity at the application layer: - Obtain T-EES.
[0088] The EEC may determine whether ACR is required by detecting whether the UE has moved or is predicted or scheduled to move outside the service area (see Section 7.3.3 of 3GPP TS23.558 V2.1.0). The service area may be provided to the EEC by the ECS during service provisioning or by the EES during EAS discovery. For a Session and Service Continuity (SSC) Mode 3 PDU session, the EEC may determine that ACR is required if the UE receives a PDU Session Modification command as specified in Section 4.3.5.2 of 3GPP TS23.502 V17.0.0. For an SSC Mode 3 IPv6 multihomed PDU session, the EEC may determine that ACR is required if the UE is notified of the existence and availability of a new IPv6 prefix as specified in Section 4.3.5.3 of 3GPP TS23.502 V17.0.0.
[0089] For an Internet Protocol version 6 (IPv6) multihomed PDU session in SSC mode 3, the EEC can recognize the above notification regarding the IPv6 prefix configuration due to a change in the PDU session anchor (PSA) UPF based on the UE implementation.
[0090] After a successful ACR: - The EEC will be notified of its completion by the EAS, and - The EEC will be notified of its completion by the EES.
[0091] In general, there are several steps required to perform the ACR procedure. Potential roles of the edge enablement layer in the ACR procedure include: - Providing detection events, - Selection of T-EAS, and - Support for application context transfer from S-EAS to T-EAS.
[0092] When the UE is connected to a 5G Core Network (5GC), the EES / EAS acting as an AF may utilize AF traffic influence functionality from the 3GPP Core Network (CN) as specified in 3GPP TS23.502 V17.0.0.
[0093] ACR can be performed for service continuity planning, where planning means that ACR detection, determination and execution are performed for the planned / predicted location of the UE, in which case the T-EAS will serve the UE when it moves to the planned location.
[0094] Service continuity planning is a value-added feature of the Edge Enabler layer that provides support for seamless service continuity when information about planned, projected, or expected behavior is available in the EES or provided by the EEC. To implement this functionality, the EES may use: - Information provided by the EEC, such as AC schedules, planned AC geographical service areas, planned service KPIs, and preferred ECSP list; and - 3GPP core network capabilities used by the EES, as described in clause 8.10.3.
[0095] At block 504, the edge enabler client may set an information element in the ACR request message indicating the type of service continuity.
[0096] In one embodiment, the information element indicating the type of service continuity may be an indication of service continuity planning or an indication of normal service continuity.
[0097] The service continuity planning indication indicates whether the ACR request is for service continuity planning. If the service continuity planning indication is omitted in the ACR request, it implies normal service continuity.
[0098] In one embodiment, the ACR request may be the same as the ACR request as described in Section 8.8.4.4 of 3GPP TS23.558 V2.1.0, except that it further includes an information element indicating the type of service continuity (normal or planned). If the above information element is omitted in the ACR request, it indicates normal service continuity.
[0099] In one embodiment, the type of service continuity includes at least one of service continuity planning or normal service continuity.
[0100] In one embodiment, the information element may be an indication of service continuity planning or an indication of normal service continuity.
[0101] In one embodiment, the information element may be of type service continuity planning or normal service continuity.
[0102] The information element indicating the type of service continuity planning may be any suitable information, such as a bit.
[0103] At block 506, the edge enabler client may send the ACR request message to the edge enabler server.
[0104] In one embodiment, the edge enabler server is a source edge enabler server.
[0105] In one embodiment, ACR is performed by an edge enabler client via a source edge enabler server. For example, this embodiment may be applied to the procedure for an EEC to perform ACR via an S-EES as described in Section 8.8.2.3 of 3GPP TS23.558 V2.1.0. In the procedure for an EEC to perform ACR via an S-EES, when the EEC detects that ACR is triggered for service continuity planning, the EEC indicates it (e.g., a type called "service continuity planning") in an ACR request message to the S-EES. When ACR is triggered for service continuity planning, the S-EES indicates it (e.g., a type called "service continuity planning") in an ACR notify message to the S-EAS.
[0106] In one embodiment, ACR is performed by a source edge enabler server. For example, this embodiment may be applied to the procedure for the S-EES to detect, determine, and execute ACR from the S-EAS to the T-EAS, as described in Section 8.8.2.5 of 3GPP TS23.558 V2.1.0. In the procedure for the S-EES to detect, determine, and execute ACR from the S-EAS to the T-EAS, when the EEC detects that ACR is triggered for service continuity planning, it indicates this (e.g., a type called service continuity planning) in an ACR request message to the S-EES. When ACR is triggered for service continuity planning, the S-EES indicates an information element indicating this (e.g., a type called service continuity planning) in an ACR notification message to the S-EAS.
[0107] In one embodiment, the edge enabler server is a target edge enabler server.
[0108] In one embodiment, ACR is performed by an edge enabler client via a target edge enabler server. For example, this embodiment may be applied to the procedure for an EEC to perform ACR via a T-EES as described in Section 8.8.2.6 of 3GPP TS23.558 V2.1.0. In the procedure for an EEC to perform ACR via a T-EES, when the EEC detects that ACR is triggered for service continuity planning, the EEC indicates it (e.g., a type of "service continuity planning") in an ACR request message to the T-EES. When ACR is triggered for service continuity planning, the T-EES indicates it (e.g., a type of "service continuity planning") in an ACR notification message to the T-EAS.
[0109] In one embodiment, if an information element indicating the type of service continuity (such as an indication of service continuity planning) is set in the ACR request message, the ACR request message indicates that ACR is triggered for service continuity planning.
[0110] In one embodiment, if the information element indicating the type of service continuity is omitted in the ACR request message, the ACR request message indicates that the ACR is triggered for normal service continuity.
[0111] 6 shows a flowchart of a method according to another embodiment of the present disclosure, which may be performed by a device implemented in, at, or as an edge enabler server, such as the EES of FIG. 1, or a device communicatively coupled to the edge enabler server. Thus, the device may provide means or modules for accomplishing various parts of the method 600, as well as means or modules for accomplishing other processes in cooperation with other components. The description of some parts described in the above embodiments will be omitted here for clarity.
[0112] At block 602, the edge enabler server may determine that an application context relocation (ACR) is required.
[0113] In one embodiment, the edge enabler server may receive an ACR request message including an information element indicating a type of service continuity from the edge enabler client and determine that ACR is required based on the ACR request message including the information element indicating the type of service continuity. For example, in block 506 of FIG. 5 , the edge enabler client may send an ACR request message to the edge enabler server, and the edge enabler server may receive the ACR request message including the information element indicating the type of service continuity from the edge enabler client and determine that ACR is required based on the ACR request message including the information element indicating the type of service continuity.
[0114] In one embodiment, the edge enabler server may detect that ACR is required and, based on the detection, determine that application context relocation (ACR) is required. For example, the edge enabler server may detect that ACR may be required as described in Section 8.8.1 of 3GPP TS23.558 V2.1.0. The edge enabler server may detect that ACR may be required for a planned or predicted location of the UE in the future as described in Section 8.8.1 of 3GPP TS23.558 V2.1.0.
[0115] In block 604, the edge enabler server may set an information element indicating a type of service continuity in the notification message for ACR. In one embodiment, the information element indicating the type of service continuity may be an indication of service continuity planning or an indication of normal service continuity.
[0116] The indication of service continuity planning indicates whether the notification message for ACR is for service continuity planning. If the indication of service continuity planning is omitted in the notification message for ACR, it indicates normal service continuity.
[0117] In block 606, the edge enabler server may send a notification message for the ACR to the edge application server, which may be the same as the EAS in FIG.
[0118] In one embodiment, the notification message for ACR may be an ACR management event notification as described in clauses 8.6.3.2.3 and 8.6.3.3.4 of 3GPP TS23.558 V2.1.0, except that it further includes an information element indicating the type of service continuity (normal or planned). If omitted, it implies normal service continuity. In one embodiment, the service continuity type information element may be applicable to an "ACR monitoring" event or any other suitable event.
[0119] 7 shows a flowchart of a method according to another embodiment of the present disclosure that may be performed by a device implemented in, at, or as an edge application server, such as the EAS of FIG. 1, or a device communicatively coupled to the edge application server. Thus, the device may provide means or modules for accomplishing various portions of method 700, as well as means or modules for accomplishing other processes in cooperation with other components. Descriptions of some portions described in the above embodiments are omitted here for clarity.
[0120] In block 702, the edge application server may receive a notification message for application context relocation (ACR) from the edge enabler server. The notification message for the ACR includes an information element indicating a type of service continuity. For example, in block 606 of FIG. 6, the edge enabler server may send the notification message for the ACR to the edge application server, and the edge application server may receive the notification message for application context relocation (ACR) from the edge enabler server.
[0121] In block 704, the edge application server may determine whether the ACR is triggered for service continuity planning based on an information element indicating a type of service continuity. For example, if the information element indicates a type of service continuity planning, the edge application server may determine that the ACR is triggered for service continuity planning. If the information element indicates a type of normal service continuity planning or is omitted, the edge application server may determine that the ACR is triggered for normal service continuity.
[0122] For handling in an EAS (such as T-EAS or S-EAS) after receiving an ACR notification message containing an information element indicating type Service Continuity Planning, the EAS shall start monitoring the UE's location (if not started previously). The S-EAS shall ensure that the application context in the T-EAS is synchronized with the latest information in the S-EAS from the time when the UE has not yet moved to the predicted / scheduled location to the time when the UE has actually moved to the predicted / scheduled location.
[0123] In block 706, after the user equipment associated with the ACR moves to the scheduled location in the case where the ACR is triggered for service continuity planning, the edge application server may send an ACR completion message to the edge enabler server to confirm that the ACR is completed.
[0124] In one embodiment, Table 8.6.3.3.4-1 of 3GPP TS23.558 V2.1.0 may be amended as shown in Table 1 below: Table 8.6.3.3.4-1 describes information elements for ACR management event notification from the EES to the EAS. [Table 1]
[0125] In one embodiment, Table 8.6.3.3.4-1 of 3GPP TS23.558 V2.1.0 may be amended as shown in Table 2 below. [Table 2]
[0126] 8a illustrates a notification operation between the EES and the EAS for continuous ACR management event notification according to one embodiment of the present disclosure. FIG. 8a is identical to FIG. 8.6.3.2.3-1 of 3GPP TS23.558 V2.1.0.
[0127] Step 1 in FIG. 8a: The EES detects an ACR management event for the UE (e.g., receives a user plane path management event notification for the UE from the 3GPP core network). In one embodiment, the EES may determine that application context relocation (ACR) is required. For example, the edge enabler server may receive an ACR request message from the edge enabler client, the ACR request message including an information element indicating a service continuity type, and may determine that ACR is required based on the ACR request message including the information element indicating the service continuity type. As another example, the EES may detect that ACR may be required as described in Section 8.8.1 of 3GPP TS23.558 V2.1.0. The edge enabler server may detect that ACR may be required for a planned or predicted location of the UE in the future, as described in Section 8.8.1 of 3GPP TS23.558 V2.1.0.
[0128] a. If the "User Plane Path Change" event is subscribed to, the EES may locally cache the detected user plane path management event notification with a timestamp as the latest information for the UE and start aggregating notifications for a group of UEs. The EES decides whether to aggregate and the aggregation period based on the analysis results received from the 3GPP core network, local policies, and user plane path management subscription information received from the EAS. The EES decides to notify the EASs that are subscribed to the "User Plane Path Management" event with user plane path management event notification information (e.g., DNAI).
[0129] b. If the "ACR monitoring" event is subscribed to, based on the detected user plane path change report sent from the 3GPP core network, the EES checks whether the target DNAI is within the EAS profile of the subscribing EAS, and if not, it further checks whether T-EAS is available for the target DNAI as described in steps 2 to 4 of section 8.8.3.2 of 3GPP TS23.558 V2.1.0.
[0130] c. If the "ACR Facilitation" event is subscribed to, based on the detected user plane path change report sent from the 3GPP core network, the EES checks whether the target DNAI is within the EAS profile of the subscribed EAS. If not, it further checks whether a T-EAS is available in the target DNAI as described in steps 2-4 of section 8.8.3.2 of 3GPP TS23.558 V2.1.0. If a T-EAS is available, the EES selects a T-EAS from the list of discovered EASs and applies AF traffic influence to the N6 routing information of the selected T-EAS in the 3GPP core network. The EES also notifies the S-EAS of the selected T-EAS endpoint.
[0131] Step 2 in Figure 8a: The EES sends an ACR management event notification to the EAS. The EES includes the UE's ACR management event notification information and, optionally, a timestamp. If the event that triggered the notification is a DNAI change, a timestamp can be included to indicate the generation of the user plane path management event notification information. The EES may provide only part of the information included in the user plane path management event notification from the 3GPP network (e.g., target DNAI). If the EAS provides "EAS acknowledgement indication," the EES waits for an acknowledgement from the EAS before sending an AF acknowledgement to the 3GPP core network. If a T-EAS is available, the EES notifies the EAS of the T-EAS endpoint; otherwise, this event notification will not be sent. In one embodiment, if an ACR is triggered for service continuity planning, the EES indicates this to the EAS in the ACR management event notification. In another embodiment, if an ACR is triggered for service continuity planning, the EES sets an indication of service continuity planning in the ACR management event notification to the EAS.
[0132] Step 3 in Figure 8a: If the EAS included an EAS Acknowledgement indication in the ACR path management event subscription request as described in section 8.6.3.2.1 of 3GPP TS23.558 V2.1.0, the EAS sends an EAS Acknowledgement to the EES in response to the ACR management event notification either immediately after or after the completion of the required ACT. The EAS may respond negatively, for example, the EAS may decide not to perform an ACR. The EES then sends an AF Acknowledgement to the 3GPP core network.
[0133] Figure 8b illustrates a procedure for an EEC to perform ACR via S-EES according to one embodiment of the present disclosure. Figure 8b is identical to Figure 8.8.2.3-1 of 3GPP TS23.558 V2.1.0.
[0134] Prerequisites:
[0135] 1. The UE's AC already has a connection to the S-EAS,
[0136] 2. EEC can communicate with S-EES.
[0137] Phase I: ACR detection
[0138] Step 1 in Figure 8b: The EEC detects that ACR may be required as described in Section 8.8.1 of 3GPP TS23.558 V2.1.0. The EEC may detect that ACR may be required for a planned or predicted UE location in the future as described in Section 8.8.1 of 3GPP TS23.558 V2.1.0.
[0139] Phase II: ACR decision
[0140] Step 2 of Figure 8b: The EEC decides to proceed with the required procedures to trigger the ACR.
[0141] Phase III: ACR execution
[0142] Step 3 of Figure 8b: The EEC determines the T-EES using the provided information or by performing a service provisioning procedure according to Section 8.3 of 3GPP TS 23.558 V2.1.0. If service continuity planning is triggered in step 1 of Figure 8b, the connectivity information and UE location in the service provisioning procedure (as specified in Section 8.3) include the planned connectivity information and the planned UE location. If the UE is within the coverage area of the T-EES, once the T-EES is selected, the UE may need to establish a new PDU connection to the target EDN. In that case, the EEC can discover and select the T-EAS by performing EAS discovery with the T-EES according to Section 8.5.2 of 3GPP TS 23.558 V2.1.0.
[0143] Step 4 of Fig. 8b: The EEC performs an ACR initiation procedure (as described in Section 8.8.3.4 of 3GPP TS23.558 V2.1.0) to the S-EES, and the ACR action indicates the initiation of ACR and corresponding ACR initiation data (together with the need to notify the EAS). In one embodiment, if ACR is triggered for service continuity planning in step 1 of Fig. 8b, the EEC indicates it to the S-EES in an ACR request message. In another embodiment, if ACR is triggered for service continuity planning in step 1, the EEC sets an indication of service continuity planning in the ACR request message to the S-EES. The S-EES approves the request from the EEC. The S-EES decides to perform ACR based on the information received from the EEC, the EEC context, and / or the EAS profile. The S-EES may apply AF traffic influence to the N6 routing information of the T-EAS in the 3GPP core network (if applicable) and send an ACR Notify message to the S-EAS to initiate ACT between the S-EAS and the T-EAS. In one embodiment, if ACR is triggered for service continuity planning, the S-EES indicates this to the S-EAS in the ACR Notify message. In another embodiment, if ACR is triggered for service continuity planning, the S-EES sets an indication of service continuity planning in the ACR Notify message to the S-EAS. The EEC also subscribes to receive ACR information notifications for ACR completion events from the S-EES as described in Section 8.8.3.5.2 of 3GPP TS23.558 V2.1.0.
[0144] Step 5 of Figure 8b: The S-EAS transfers the application context to the T-EAS at an implementation-specific point in time.
[0145] Phase IV: Post-ACR cleanup
[0146] In step 1 of Fig. 8b, when ACR is triggered for service continuity planning, if the UE does not move to the predicted location, the EEC does not connect to the T-EES and the AC does not connect to the T-EAS, and steps 6 and 7 of Fig. 8b are skipped.
[0147] Note: If ACR for service continuity planning is triggered in step 1 of FIG. 8b, steps 6 and 7 of FIG. 8b are executed after the UE moves to the predicted location.
[0148] Step 6 of Figure 8b: The S-EAS sends an ACR Complete message to the S-EES to confirm that the ACR is complete.
[0149] Step 7 of Figure 8b: The S-EES sends an ACR information notification message to the EEC to confirm that the ACR is completed, as specified in section 8.8.3.5.3 of 3GPP TS23.558 V2.1.0.
[0150] Figure 9 illustrates a procedure for the S-EES to detect, determine, and execute an ACR from the S-EAS to the T-EAS according to one embodiment of the present disclosure. Figure 9 is identical to Figure 8.8.2.5-1 of 3GPP TS23.558 V2.1.0.
[0151] The procedure of FIG. 9 may support automated ACR by the S-EES when initiated by the S-EAS as per section 8.8.3.6 of 3GPP TS23.558 V2.1.0.
[0152] Prerequisites:
[0153] 1. The UE's AC already has a connection to the S-EAS,
[0154] 2. EEC can communicate with S-EES,
[0155] 3. The EEC subscribes to receive ACR information notifications for target information notification events and ACR completion events from the S-EES as described in Section 8.8.3.5.2 of 3GPP TS23.558 V2.1.0.
[0156] Step 1 in Figure 9: The S-EAS may initiate automated ACR with the S-EES as specified in Section 8.8.3.6 of 3GPP TS23.558 V2.1.0. In this step, the S-EAS and S-EES negotiate the address of the application context storage for the S-EES. The S-EAS places the application context at this address, which can be further accessed by the S-EES in case of an ACT.
[0157] In this case, the S-EES performs steps 2 (i.e., S-EES detection), 4, 5, 6, 7, 8, 9, and 11 of Figure 9. The rest of the steps of Figure 9 are skipped.
[0158] Phase I: ACR detection
[0159] Step 2 in Figure 9: The detection entities (S-EAS, S-EES, EEC) detect that ACR may be required as described in section 8.8.1 of 3GPP TS23.558 V2.1.0. The detection by the S-EES may be triggered by a user plane path change notification received from the 3GPP core network due to an S-EAS request for an "ACR facilitation" event (see section 8.6.3 of 3GPP TS23.558 V2.1.0).
[0160] The detection entity may detect that an ACR may be required for a planned or predicted location of the UE in the future, as described in section 8.8.1 of 3GPP TS23.558 V2.1.0.
[0161] Step 3 of Figure 9: The detection entity performs the ACR initiation procedure (as described in Section 8.8.3.4 of 3GPP TS23.558 V2.1.0), and the ACR action indicates the ACR decision and the corresponding ACR decision data. In one embodiment, if ACR is triggered for service continuity planning in step 2 of Figure 9, the EEC indicates it to the S-EES in the ACR request message. In another embodiment, if ACR is triggered for service continuity planning in step 2, the EEC sets an indication of service continuity planning in the ACR request message to the S-EES.
[0162] Phase II: ACR decision
[0163] Step 4 of Figure 9: The S-EES acknowledges the above message if it is received. Based on the received information or local detection and the information in the EEC context or EAS profile, the S-EES decides to perform ACR and proceeds to the subsequent steps of Figure 9.
[0164] Phase III: ACR execution
[0165] Step 5 of Figure 9: The S-EES determines the T-EES and T-EAS via the Discover T-EAS procedure of Section 8.8.3.2 of this document. In step 2 of Figure 9, if ACR is triggered for service continuity planning, the UE location and target DNAI values provided in the Retrieve T-EES procedure include the intended UE location and intended target DNAI. The S-EES may decide not to perform ACR if T-EAS is not available.
[0166] Step 6 of Figure 9: The S-EES sends a target information notification to the EEC as described in section 8.8.3.5.3 of 3GPP TS23.558 V2.1.0.
[0167] Step 7 of Figure 9: The S-EES may apply AF traffic impact to the N6 routing information of the T-EAS in the 3GPP core network (if applicable).
[0168] Step 8 in Figure 9: The S-EES sends an ACR notification message to the S-EAS (e.g., as a notification for an "ACR facilitation" event) to initiate an ACT between the S-EAS and the T-EAS. In one embodiment, if an ACR is triggered for service continuity planning, the S-EES indicates this to the S-EAS in the ACR notification message. In another embodiment, if an ACR is triggered for service continuity planning, the S-EES sets an indication of service continuity planning in the ACR notification message to the S-EAS.
[0169] Step 9 of Figure 9: The application context is transferred from the S-EAS to the T-EAS at an implementation-specific time. In the case of automated ACR, the S-EES has access to the application context from the address per step 1 of Figure 9, and the S-EES and T-EES engage in ACTs from the S-EAS to the T-EAS (obtained per step 5 of Figure 9) in a secure manner. Furthermore, the T-EAS has access to the application context made available by the T-EES. The S-EAS may also perform ACTs directly with the T-EAS.
[0170] The application context is encrypted and protected by the application layer. S-EES and T-EES are involved in packet-level transport of the application context, and the contents of the application context are not visible to them.
[0171] Phase IV: Post-ACR cleanup
[0172] In step 2 of Figure 9, when ACR is triggered for service continuity planning, if the UE does not move to the predicted location, the EEC does not connect to the T-EES and the AC does not connect to the T-EAS, and steps 10 and 11 of Figure 9 are skipped.
[0173] If ACR for service continuity planning is triggered in step 2 of FIG. 9, steps 10 and 11 of FIG. 9 will be executed only after the UE moves to the scheduled location.
[0174] Step 10 of FIG. 9: The S-EAS sends an ACR Complete message to the S-EES to confirm that the ACR is complete.
[0175] Step 11 in Figure 9: The S-EES sends an ACR information notification message to the EEC to confirm that the ACR is completed, as specified in section 8.8.3.5.3 of 3GPP TS23.558 V2.1.0.
[0176] The application client mechanism may support the switchover of application traffic to the T-EAS.
[0177] 10 illustrates a procedure for an EEC to perform ACR via a T-EES according to one embodiment of the present disclosure. FIG. 10 is identical to FIG. 8.8.2.6-1 of 3GPP TS23.558 V2.1.0.
[0178] Prerequisites:
[0179] 1. EEC has S-EAS information to service AC.
[0180] Phase I: ACR detection
[0181] Step 1 in Figure 10: The EEC detects that ACR may be required as described in Section 8.8.1 of 3GPP TS23.558 V2.1.0. The EEC may detect that ACR may be required for a planned or predicted UE location in the future as described in Section 8.8.1 of 3GPP TS23.558 V2.1.0.
[0182] Phase II: ACR decision
[0183] Step 2 in Figure 10: The EEC decides to proceed with the required procedures for the ACR.
[0184] If supported, the AC may be involved in the decision.
[0185] Phase III: ACR execution
[0186] Step 3 of Figure 10: The EEC determines the T-EES using the provided information or by performing a service provisioning procedure according to Section 8.3 of 3GPP TS23.558 V2.1.0. If service continuity planning is triggered in step 1 of Figure 10, the connectivity information and UE location used in the service provisioning procedure include the planned connectivity information and the planned UE location. If the UE is within the coverage area of the T-EES, once the T-EES is selected, the UE may need to establish a new PDU connection to the target EDN. The EEC performs EAS discovery with the T-EES according to Section 8.5.2 of 3GPP TS23.558 V2.1.0.
[0187] Step 4 of Figure 10: The EEC performs the ACR initiation procedure (as described in Section 8.8.3.4 of 3GPP TS23.558 V2.1.0) to the T-EES, and the ACR action indicates the initiation of the ACR and the corresponding ACR initiation data (along with the need to notify the EAS). In one embodiment, if ACR is triggered for service continuity planning in step 1 of Figure 10, the EEC indicates this to the T-EES in an ACR request message. In another embodiment, if ACR is triggered for service continuity planning in step 1, the EEC sets an indication of service continuity planning in the ACR request message to the T-EES. The T-EES may apply AF traffic impact (if applicable) to the N6 routing information of the T-EAS in the 3GPP core network. The T-EES then sends an ACR notification message to the T-EAS. The EEC also subscribes to receive ACR information notifications for ACR completion events from the T-EES as described in section 8.8.3.5.2 of 3GPP TS23.558 V2.1.0. In one embodiment, if an ACR is triggered for service continuity planning, the T-EES indicates this to the T-EAS in an ACR notification message. In another embodiment, if an ACR is triggered for service continuity planning, the T-EES sets an indication of service continuity planning in the ACR notification message to the T-EAS.
[0188] Step 5 of FIG. 10: The T-EAS initiates an ACT between the S-EAS and the T-EAS.
[0189] Phase IV: Post-ACR cleanup
[0190] In step 1 of Figure 10, when ACR is triggered for service continuity planning, if the UE does not move to the predicted location, the EEC does not connect to the T-EES and the AC does not connect to the T-EAS, and steps 6 and 7 of Figure 10 are skipped.
[0191] NOTE 2: If ACR for service continuity planning is triggered in step 1 of Figure 10, steps 6 and 7 of Figure 10 will be executed only after the UE moves to the scheduled location.
[0192] Step 6 in Figure 10: The T-EAS sends an ACR complete message to the T-EES to confirm that the ACR is complete.
[0193] Step 7 of Figure 10: The T-EES sends an ACR information notification to the EEC as described in section 8.8.3.5.3 of 3GPP TS23.558 V2.1.0.
[0194] If the above procedure fails after step 4 of Figure 10, it will be terminated with an appropriate cause in an ACR response message to the EEC in step 7 of Figure 10. In that case, the EEC may proceed with attempting to obtain service from the T-EAS discovered in step 3 of Figure 10 without support for service continuity. Alternatively, the EEC may restart the current procedure by selecting a different T-EES starting from step 3 of Figure 10.
[0195] Support for ACR between EDNs operated by different ECSPs depends on the business agreements between the ECSPs.
[0196] 11 illustrates an ACR initiation procedure by an EEC according to an embodiment of the present disclosure, which is identical to Figure 8.8.3.4-1 of 3GPP TS23.558 V2.1.0.
[0197] Depending on the ACR action indicated in the ACR request, this procedure is used either for ACR initiation or ACR determination.
[0198] Prerequisites:
[0199] 1. The EEC is authorized to communicate with the EES as provided for in section 8.11.
[0200] Step 1 in Figure 11: The EEC sends an ACR request message to the EES to initiate ACR. The ACR request message includes an ACR action to indicate either an ACR initiation request or an ACR decision request. In one embodiment, the ACR request message may include a service continuity type to indicate whether the procedure to be initiated is for service continuity planning. In another embodiment, the EEC also sets an indication of service continuity planning in the ACR request message if service continuity planning is required.
[0201] The ACR request to initiate ACR is:
[0202] - including an indication of whether the EEC will request the EES to issue an EAS notification;
[0203] - Provides information used to perform AF traffic impact by EES, as per 3GPP TS 23.501 [2].
[0204] The ACR request for ACR determination notifies the EES that the EEC has detected the need for ACR.
[0205] Step 2 in Figure 11: The EES checks if the EEC is authorized for this action. If authorized, the EES processes the request and performs the required action.
[0206] In step 1, if the request is for ACR initiation:
[0207] - the EES may use the information provided in the request to apply AF traffic impacts to the N6 routing information of the T-EAS in the 3GPP core network (if applicable), as described in clause 5.6.7.1 of 3GPP TS 23.501 V17.0.0;
[0208] - If an EAS notification indication was provided in the request in step 1 and the EAS has subscribed to receive such notifications, the EES shall notify the EAS of the need to initiate an ACR.
[0209] If the request in step 1 is for ACR determination, the EES decides to perform ACR as described in section 8.8.2.5 of 3GPP TS23.558 V2.1.0.
[0210] Step 3 of Figure 11: The EES responds to the EEC's request with an ACR response message.
[0211] In one embodiment, Table 8.8.4.4-1 of 3GPP TS23.558 V2.1.0 may be amended as shown in Table 3 below. Table 8.8.4.4-1 describes the information elements for an ACR request sent from the EEC to either the S-EES or the T-EES. [Table 3]
[0212] In one embodiment, Table 8.8.4.4-1 of 3GPP TS23.558 V2.1.0 may be amended as shown in Table 4 below. [Table 4]
[0213] The various blocks / steps illustrated in Figures 5-11 may be viewed as method steps, as acts resulting from the operation of computer program code, and / or as a plurality of interlocked logic circuit elements configured to perform the associated functions. The schematic flowchart diagrams described above are generally described as logical flowchart diagrams. As such, the depicted order and labeled steps represent specific embodiments of the presented method. Other steps and methods may be conceived that are equivalent to the function, logic, or effect of one or more steps of the illustrated method, or portions thereof. Additionally, the order in which a particular method occurs may or may not strictly follow the order of the corresponding steps illustrated.
[0214] Embodiments herein provide many advantages, a non-exhaustive list of examples of which follows: Some embodiments herein may resolve issues when an edge application server, such as an S-EAS or a T-EAS, does not have knowledge of whether the ACR is for normal service continuity or service continuity planning, allowing the edge application server, such as an S-EAS or a T-EAS, to properly send an ACR complete message at the correct time. Some embodiments herein may avoid situations where an AC connects to a T-EAS before the UE has moved to its scheduled location, resulting in suboptimal traffic routing or service interruption. Embodiments herein are not limited to the features and advantages mentioned above. Those skilled in the art will recognize additional features and advantages after reading the following detailed description.
[0215] 12 is a block diagram illustrating an apparatus suitable for practicing some embodiments of the present disclosure. For example, the edge enabler client, edge enabler server, and edge application server described above may be implemented as or through an apparatus 1200.
[0216] The apparatus 1200 comprises at least one processor 1221, such as a digital processor (DP), and at least one memory (MEM) 1222 coupled to the processor 1221. The apparatus 1220 may further comprise a transmitter TX and a receiver RX 1223 coupled to the processor 1221. The MEM 1222 stores a program (PROG) 1224. The PROG 1224 may include instructions that, when executed on the associated processor 1221, enable the apparatus 1220 to operate according to embodiments of the present disclosure. The combination of the at least one processor 1221 and the at least one MEM 1222 may form a processing means 1225 adapted to implement various embodiments of the present disclosure.
[0217] Various embodiments of the present disclosure may be implemented in a computer program executable by one or more of the processors 1221, software, firmware, hardware, or a combination thereof.
[0218] MEM1222 may be of any type suitable for the local technology environment and may be implemented using any suitable data storage technology, including, by way of non-limiting example, semiconductor-based memory devices, magnetic memory devices and systems, optical memory devices and systems, fixed and removable memory.
[0219] The processor 1221 may be of any type suitable for the local technology environment, and may include, by way of non-limiting example, one or more of a general-purpose computer, a special-purpose computer, a microprocessor, a digital signal processor (DSP), and a processor based on a multi-core processor architecture.
[0220] In an embodiment in which the device is implemented as the edge enabler client, the memory 1222 contains instructions executable by the processor 1221, thereby causing the edge enabler client to operate according to any step of the method as described above relating to the edge enabler client.
[0221] In an embodiment in which the device is implemented as the edge enabler server, the memory 1222 contains instructions executable by the processor 1221, thereby causing the edge enabler server to operate according to any step of the method as described above relating to the edge enabler server.
[0222] In an embodiment in which the device is implemented as the edge application server, memory 1222 contains instructions executable by processor 1221 to cause the application server to operate according to any step of the method as described above relating to the application server.
[0223] 13 is a block diagram illustrating an edge enabler client according to one embodiment of the present disclosure. As illustrated, the edge enabler client 1300 includes a detection module 1302, a setting module 1304, and a sending module 1306. The detection module 1302 may be configured to detect that an application context relocation (ACR) is required. The setting module 1304 may be configured to set an information element indicating a type of service continuity in an ACR request message. The sending module 1306 may be configured to send the ACR request message to the edge enabler server.
[0224] 14 is a block diagram illustrating an edge enabler server according to one embodiment of the present disclosure. As illustrated, the edge enabler server 1400 includes a determining module 1402, a setting module 1404, and a sending module 1406. The determining module 1402 may be configured to determine that application context relocation (ACR) is required. The setting module 1404 may be configured to set an information element indicating a type of service continuity in a notification message for the ACR. The sending module 1604 may be configured to send the notification message for the ACR to the edge application server.
[0225] FIG. 15 is a block diagram illustrating an edge application server according to an embodiment of the present disclosure. As illustrated, the edge application server 1500 includes a receiving module 1502, a determining module 1504, and a sending module 1506. The receiving module 1502 may be configured to receive a notification message for application context relocation (ACR) from an edge enabler server. The notification message for the ACR includes an information element indicating a type of service continuity. The determining module 1504 may be configured to determine whether the ACR is triggered for service continuity planning based on the information element indicating the type of service continuity. The sending module 1506 may be configured to send an ACR completion message to the edge enabler server to confirm that the ACR is completed after a user equipment associated with the ACR moves to a scheduled location when the ACR is triggered for service continuity planning.
[0226] The terms unit or module may have their conventional meaning in the field of electronic equipment, electrical devices, and / or electronic devices, and may include, for example, electrical and / or electronic circuits, devices, modules, processors, memories, logic solid state and / or discrete devices, computer programs, or instructions for performing respective tasks, procedures, calculations, output and / or display functions, etc., such as those described herein.
[0227] Regarding the functional unit groups, the edge enabler client, the edge enabler server, and the edge application server may not require fixed processors or memories, and any computing resources and storage resources may be configured from the edge enabler client, the edge enabler server, and the edge application server in the communication system. The introduction of virtualization technology and network computing technology may improve the utilization efficiency of network resources and the flexibility of the network.
[0228] According to one aspect of the present disclosure, there is provided a computer program product tangibly stored on a computer-readable storage medium, the computer program product including instructions that, when executed on at least one processor, cause the at least one processor to perform any of the methods set forth above.
[0229] According to one aspect of the present disclosure, there is provided a computer-readable storage medium storing instructions that, when executed by at least one processor, cause the at least one processor to perform any of the methods set forth above.
[0230] Additionally, the present disclosure may also provide a carrier containing a computer program as described above, the carrier being one of an electronic signal, an optical signal, a radio signal, or a computer-readable storage medium, which may be, for example, a random access memory (RAM), a read only memory (ROM), a flash memory, a magnetic tape, an optical compact disc, or an electronic memory device, such as a CD-ROM, a DVD, a Blu-ray disc, etc.
[0231] The techniques described herein may be implemented by a variety of means, such that an apparatus implementing one or more functions of a corresponding apparatus described in connection with an embodiment includes not only conventional means but also means for implementing one or more functions of the corresponding apparatus described in connection with the embodiment, which may include separate means for each separate function or means that may be configured to perform one or more functions. For example, the techniques may be implemented in hardware (one or more devices), firmware (one or more devices), software (one or more modules), or a combination thereof. For firmware or software, implementation may be through modules (e.g., procedures, functions, etc.) that perform the functions described herein.
[0232] The exemplary embodiments herein are described above with reference to block diagrams and flowchart illustrations of methods and apparatus. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can each be implemented by various means, including computer program instructions, which can be loaded into a general purpose computer, special purpose computer, or other programmable data processing apparatus to produce machine, such that the instructions, running on the computer or other programmable data processing apparatus, generate means for implementing the functions identified in one or more of the flowchart blocks.
[0233] Furthermore, although acts are depicted in a particular order, this should not be understood as requiring that such acts be performed in that particular order or sequential order, or that all of the acts depicted be performed, to achieve desired results. In some situations, multitasking and parallel processing may be advantageous. Similarly, while the above discussion includes a number of specific implementation details, these should not be construed as limitations on the scope of the subject matter described herein, but rather as descriptions of features that may be specific to particular embodiments. Certain features described in the context of separate embodiments may also be implemented in combination in a single embodiment. Conversely, various features described in the context of a single embodiment may also be implemented in multiple embodiments separately or in any suitable subcombination.
[0234] While this specification contains many specific implementation details, these should not be construed as limitations on the scope of any implementation or what may be claimed, but rather as descriptions of features that may be specific to particular embodiments of a particular implementation. Multiple features described herein in the context of separate embodiments may also be implemented in combination in a single embodiment. Conversely, various features described in the context of a single embodiment may also be implemented in multiple embodiments separately or in any suitable subcombination. Moreover, while multiple features may be described above as operating in a combination and even claimed as such, in some cases, one or more features of a claimed combination may be carved out of the combination, and the claimed combination may be directed to a subcombination or variations of the subcombination.
[0235] It will be apparent to those skilled in the art that with the advancement of technology, the concept of the present invention can be implemented in various ways. The above-described embodiments are provided to illustrate rather than limit the present disclosure, and it will be understood that modifications and variations can be made without departing from the spirit and scope of the present disclosure, as those skilled in the art will readily understand. Such modifications and variations are considered to be within the scope of the present disclosure and the appended claims. The scope of protection of the present disclosure is defined by the appended claims.
Claims
1. A method (500) performed by an edge enabler client, comprising: Detecting (502) that an application context relocation (ACR) is required; Setting an information element indicating a type of service continuity in the ACR request message (504); and sending (506) the ACR request message to an edge enabler server.
2. The method of claim 1 , wherein the edge enabler server is a source edge enabler server.
3. The method of claim 2 , wherein the ACR is executed by the edge enabler client via the source edge enabler server.
4. The method of claim 2 , wherein the ACR is executed by the source edge enabler server.
5. The method of claim 1 , wherein the edge enabler server is a target edge enabler server.
6. The method of claim 5 , wherein the ACR is executed by the edge enabler client via the target edge enabler server.
7. 7. The method of claim 1, wherein if the information element indicating the type of service continuity in the ACR request message is set, the ACR request message indicates that the ACR is triggered for service continuity planning.
8. 7. The method of claim 1, wherein if the information element indicating the type of service continuity is omitted in the ACR request message, the ACR request message indicates that the ACR is triggered for normal service continuity.
9. 9. The method according to claim 1, wherein the type of service continuity is: Service continuity planning, or normal service continuity.
10. A method (600) performed by an edge enabler server, comprising: Determining (602) that an application context relocation (ACR) is required; setting (604) an information element in a notification message for the ACR indicating a type of service continuity; and sending (606) the notification message for the ACR to an edge application server.
11. 11. The method of claim 10, wherein determining that application context relocation (ACR) is required comprises: receiving an ACR Request message from an edge enabler client, the ACR Request message including the information element indicating the type of service continuity; determining that the ACR is required based on the ACR request message including the information element indicating the type of service continuity.
12. 12. The method of claim 11, wherein if the information element indicating the type of service continuity in the ACR request message is set, the ACR request message indicates that the ACR is triggered for service continuity planning.
13. 12. The method of claim 11, wherein if the information element indicating the type of service continuity is omitted in the ACR request message, the ACR request message indicates that the ACR is triggered for normal service continuity.
14. 11. The method of claim 10, wherein determining that application context relocation (ACR) is required comprises: Detecting that the ACR is required; and determining, based on the detection, that application context relocation (ACR) is required.
15. The method according to any one of claims 10 to 14, wherein the edge enabler server is a source edge enabler server and the edge application server is a source edge application server.
16. 16. The method of claim 15, wherein the ACR is executed by an edge enabler client via the source edge enabler server.
17. 16. The method of claim 15, wherein the ACR is executed by the source edge enabler server.
18. The method according to any one of claims 10 to 14, wherein the edge enabler server is a target edge enabler server and the edge application server is a target edge application server.
19. 20. The method of claim 18, wherein the ACR is executed by an edge enabler client via the target edge enabler server.
20. 20. The method of claim 10, wherein the notification message for the ACR indicates that the ACR is triggered for service continuity planning if the information element indicating the type of service continuity in the notification message for the ACR is set.
21. 20. The method of claim 10, wherein if the information element indicating the type of service continuity is omitted in the notification message for the ACR, the notification message for the ACR indicates that the ACR is triggered for normal service continuity.
22. 22. The method according to any one of claims 10 to 21, wherein the type of service continuity is: Service continuity planning, or normal service continuity.
23. A method (700) performed by an edge application server, comprising: receiving (702) a notification message for application context relocation (ACR) from an edge enabler server, wherein the notification message for the ACR includes an information element indicating a type of service continuity; determining (704) whether the ACR is triggered for service continuity planning based on the information element indicating the type of service continuity; and sending (706) an ACR completion message to the edge enabler server to confirm that the ACR has been completed after a user equipment associated with the ACR has moved to a scheduled location if the ACR was triggered for service continuity planning.
24. 24. The method of claim 23, wherein the edge enabler server is a source edge enabler server and the edge application server is a source edge application server.
25. 25. The method of claim 24, wherein the ACR is executed by an edge enabler client via the source edge enabler server.
26. 25. The method of claim 24, wherein the ACR is executed by the source edge enabler server.
27. 24. The method of claim 23, wherein the edge enabler server is a target edge enabler server and the edge application server is a target edge application server.
28. 28. The method of claim 27, wherein the ACR is executed by an edge enabler client via the target edge enabler server.
29. 29. The method of claim 23, wherein the notification message for the ACR indicates that the ACR is triggered for service continuity planning if the information element indicating the type of service continuity in the notification message for the ACR is set.
30. 29. The method of claim 23, wherein if the information element indicating the type of service continuity is omitted in the notification message for the ACR, the notification message for the ACR indicates that the ACR is triggered for normal service continuity.
31. 31. The method according to any one of claims 23 to 30, wherein the type of service continuity is: Service continuity planning, or normal service continuity.
32. An edge enabler client (1200), A processor (1221); a memory (1222) coupled to the processor (1221), the memory (1222) including instructions executable by the processor (1221), whereby the edge enabler client (1200) Detecting that an application context relocation (ACR) is required; setting an information element indicating a type of service continuity in an ACR request message; an edge enabler client operable to: send said ACR request message to an edge enabler server;
33. The edge enabler client of claim 32, wherein said edge enabler client is further operable to perform the method of any one of claims 2 to 9.
34. An edge enabler server (1200), A processor (1221); a memory (1222) coupled to the processor (1221), the memory (1222) including instructions executable by the processor (1221), whereby the edge enabler server (1200) determining that application context relocation (ACR) is required; setting an information element in a notification message for the ACR indicating a type of service continuity; sending the notification message for the ACR to an edge application server.
35. An edge enabler server according to claim 34, wherein said edge enabler server is further operable to perform a method according to any one of claims 11 to 22.
36. An edge application server (1200), A processor (1221); a memory (1222) coupled to the processor (1221), the memory (1222) including instructions executable by the processor (1221), thereby causing the edge application server (1200) to: receiving a notification message for application context relocation (ACR) from an edge enabler server, the notification message for the ACR including an information element indicating a type of service continuity; determining whether the ACR is triggered for service continuity planning based on the information element indicating the type of service continuity; and sending an ACR completion message to the edge enabler server to confirm that the ACR has been completed after a user equipment associated with the ACR has moved to a scheduled location when the ACR is triggered for service continuity planning.
37. An edge application server according to claim 36, wherein the edge application server is further operable to perform a method according to any one of claims 24 to 31.
38. 32. A computer readable storage medium storing instructions that, when executed by at least one processor, cause the at least one processor to perform the method of any one of claims 1 to 31.
39. 32. A computer program product comprising instructions which, when executed by at least one processor, cause the at least one processor to perform a method according to any one of claims 1 to 31.