WO2023027477A1

WO2023027477A1 - Method and system for application context relocation between edge and cloud deployments

Info

Publication number: WO2023027477A1
Application number: PCT/KR2022/012587
Authority: WO
Inventors: Basavaraj Jayawant Pattan; Nishant Gupta; Sapan Pramodkumar SHAH; Narendranath Durga Tangudu; Arunprasath Ramamoorthy
Original assignee: Samsung Electronics Co., Ltd.
Priority date: 2021-08-23
Filing date: 2022-08-23
Publication date: 2023-03-02

Abstract

The disclosure relates to a 5G or 6G communication system for supporting a higher data transmission rate. The proposed method assists the ACs (100a) to find a suitable EAS/ the T-EAS during a mobility event associated with the UE (100) and/or a non-mobility event associated with the edge server (300), and/or a trigger event, and transfers of application context from the S-EAS (300a) to the CAS (500) is one of a key feature of overall edge enabler layer, and contributes significantly to overall design of an architecture for enabling edge applications.

Description

METHOD AND SYSTEM FOR APPLICATION CONTEXT RELOCATION BETWEEN EDGE AND CLOUD DEPLOYMENTS

The present invention relates to edge computing service. The invention in particular relates to method and system for Application Context Relocation (ACR) between edge and cloud deployments. The present application is based on and claims priority from an Indian Provisional Application Number 202141038182 filed on 23rd August 2021, the disclosure of which is hereby incorporated by reference herein.

5G mobile communication technologies define broad frequency bands such that high transmission rates and new services are possible, and can be implemented not only in "Sub 6GHz" bands such as 3.5GHz, but also in "Above 6GHz" bands referred to as mmWave including 28GHz and 39GHz. In addition, it has been considered to implement 6G mobile communication technologies (referred to as Beyond 5G systems) in terahertz bands (for example, 95GHz to 3THz bands) in order to accomplish transmission rates fifty times faster than 5G mobile communication technologies and ultra-low latencies one-tenth of 5G mobile communication technologies.

At the beginning of the development of 5G mobile communication technologies, in order to support services and to satisfy performance requirements in connection with enhanced Mobile BroadBand (eMBB), Ultra Reliable Low Latency Communications (URLLC), and massive Machine-Type Communications (mMTC), there has been ongoing standardization regarding beamforming and massive MIMO for mitigating radio-wave path loss and increasing radio-wave transmission distances in mmWave, supporting numerologies (for example, operating multiple subcarrier spacings) for efficiently utilizing mmWave resources and dynamic operation of slot formats, initial access technologies for supporting multi-beam transmission and broadbands, definition and operation of BWP (BandWidth Part), new channel coding methods such as a LDPC (Low Density Parity Check) code for large amount of data transmission and a polar code for highly reliable transmission of control information, L2 pre-processing, and network slicing for providing a dedicated network specialized to a specific service.

Currently, there are ongoing discussions regarding improvement and performance enhancement of initial 5G mobile communication technologies in view of services to be supported by 5G mobile communication technologies, and there has been physical layer standardization regarding technologies such as V2X (Vehicle-to-everything) for aiding driving determination by autonomous vehicles based on information regarding positions and states of vehicles transmitted by the vehicles and for enhancing user convenience, NR-U (New Radio Unlicensed) aimed at system operations conforming to various regulation-related requirements in unlicensed bands, NR UE Power Saving, Non-Terrestrial Network (NTN) which is UE-satellite direct communication for providing coverage in an area in which communication with terrestrial networks is unavailable, and positioning.

Moreover, there has been ongoing standardization in air interface architecture/protocol regarding technologies such as Industrial Internet of Things (IIoT) for supporting new services through interworking and convergence with other industries, IAB (Integrated Access and Backhaul) for providing a node for network service area expansion by supporting a wireless backhaul link and an access link in an integrated manner, mobility enhancement including conditional handover and DAPS (Dual Active Protocol Stack) handover, and two-step random access for simplifying random access procedures (2-step RACH for NR). There also has been ongoing standardization in system architecture/service regarding a 5G baseline architecture (for example, service based architecture or service based interface) for combining Network Functions Virtualization (NFV) and Software-Defined Networking (SDN) technologies, and Mobile Edge Computing (MEC) for receiving services based on UE positions.

As 5G mobile communication systems are commercialized, connected devices that have been exponentially increasing will be connected to communication networks, and it is accordingly expected that enhanced functions and performances of 5G mobile communication systems and integrated operations of connected devices will be necessary. To this end, new research is scheduled in connection with eXtended Reality (XR) for efficiently supporting AR (Augmented Reality), VR (Virtual Reality), MR (Mixed Reality) and the like, 5G performance improvement and complexity reduction by utilizing Artificial Intelligence (AI) and Machine Learning (ML), AI service support, metaverse service support, and drone communication.

Furthermore, such development of 5G mobile communication systems will serve as a basis for developing not only new waveforms for providing coverage in terahertz bands of 6G mobile communication technologies, multi-antenna transmission technologies such as Full Dimensional MIMO (FD-MIMO), array antennas and large-scale antennas, metamaterial-based lenses and antennas for improving coverage of terahertz band signals, high-dimensional space multiplexing technology using OAM (Orbital Angular Momentum), and RIS (Reconfigurable Intelligent Surface), but also full-duplex technology for increasing frequency efficiency of 6G mobile communication technologies and improving system networks, AI-based communication technology for implementing system optimization by utilizing satellites and AI (Artificial Intelligence) from the design stage and internalizing end-to-end AI support functions, and next-generation distributed computing technology for implementing services at levels of complexity exceeding the limit of UE operation capability by utilizing ultra-high-performance communication and computing resources.

The principal object of the embodiments herein is to provide a method for Application Context Relocation (ACR) between an edge server (i.e. Edge Data Network (EDN)) and a Cloud Application Server (CAS) by detecting, by detecting entity (e.g., EEC, S-EAS, and S-EES), a requirement of the ACR based on a mobility event associated with a User Equipment (UE) and/or a non-mobility event associated with the edge server, and/or a trigger event. Then, a decision entity (e.g., EEC, AC, S-EAS, and S-EES) determines whether to perform the ACR based on an application profile of the UE and the detected mobility event and/or detected non-mobility event and/or detected trigger event. Then, an execution entity (e.g., EEC, AC, S-EAS, and S-EES) transfer’s network service(s) relates to an application context from a Source Edge Application Server (S-EAS) of the edge server to the CAS in order to maintain continuity of the network service in response to determining that the ACR is performed. As a result, a user of the UE's edge applications receives reliable services (service continuity) from the edge server and/or the CAS, which enhances user's experience.

Another object of the embodiment herein is to assist the AC to find a suitable EAS during mobility and transfer of application context from the S-EAS to the T-EAS is one of a key feature of overall edge enabler layer. The proposed method contributes significantly to overall design of an architecture for enabling edge applications. Without the key feature, there would be no service continuity in certain geographic areas where applications service rendering may be unavailable via the EAS.

Another object of the embodiment herein is the CAS initiated ACR, wherein the CAS detects the need for the ACR and decides for whether to perform the ACR and start the ACR at an appropriate time. When the ACR happens between the S-EAS and the CAS, the S-EAS can be the CAS. During the ACR execution phase, the CAS needs to know the S-EES before continuing with T-EAS discovery. Once the CAS knows the S-EES, the T-EAS discovery and the remaining steps are similar to the "S-EAS decided ACR scenario" as specified in 3GPP TS 23.558, where the CAS acts like the S-EAS.

Accordingly, the embodiment herein is to provide a method for Application Context Relocation (ACR) between an edge server and a Cloud Application Server (CAS). The method includes receiving, by a User Equipment (UE), network service (e.g., audio service, video service, etc.) relates to an application context from a Source Edge Application Server (S-EAS) of the edge server, where the UE includes an Application Client (AC) and an Edge Enable Client (EEC). Further, the method includes detecting, by the UE, a requirement of the ACR in order to maintain continuity of the network service based on a mobility event associated with the UE and/or a non-mobility event associated with the edge server, and/or a trigger event. Further, the method includes determining, by the UE, whether to perform the ACR based on an application profile of the UE and the detected mobility event and/or detected non-mobility event and/or detected trigger event. Further, the method includes performing, by the UE, the ACR, where the network service relates to Application Context Transfer (ACT) from the S-EAS to the CAS and the transferred application context maintains continuity of the network service for the UE.

In an embodiment, the method includes sending, by the S-EAS, an ACR status update message to a Source-Edge Enabler server (S-EES) of the edge server. Further, the method includes sending, by the S-EAS, an ACR information notification message to the EEC on the successful transferring of the network service relates to the application context from the S-EAS to the CAS, where the CAS performs required Core Network (CN) capability exposure subscriptions upon receiving the application context.

In an embodiment, the mobility event indicates a new location of the UE which is outside a service area of the S-EAS, the non-mobility event includes one or more conditions to initiate the ACR between the edge server and the CAS, and the trigger event is triggered by an Edge Configuration Server (ECS) by sending a notification to the UE, where the notification indicates that a suitable target EAS is not available for the new location of the UE.

In an embodiment, where one or more condition includes detecting, by the UE, that the edge server is not available for a new location of the UE based on a failed service provisioning response from an Edge Configuration Server (ECS); detecting, by the UE, that a suitable target EAS is not available for the new location, wherein the UE sends a service provisioning request to the edge server for the suitable target EAS and the UE receives a failed service provisioning response in response to detecting that the suitable target EAS is not available for the new location of the UE; detecting, by the UE, that the edge server is available for the new location and the suitable target EAS is not available for the new location based on an EAS discovery response; detecting, by the UE, that the suitable target EAS is overloaded for the new location; and detecting, by the UE, that the CAS serves the UE for the new location and the suitable target EAS is available for the new location, wherein the ACR is initiated to maintain continuity of the network service via the suitable EAS.

In an embodiment, where performing, by the UE, the ACR, wherein the network service relates to an Application Context Transfer (ACT) from the S-EAS to the CAS and the transferred application context maintains continuity of the network service for the UE includes performing, by the UE, service provision procedure for all active applications that require the ACR for a new location of the UE, where the service provision procedure results in failure to discover a suitable target EAS for the new location; performing, by the UE, a Domain Name System (DNS) resolution for relevant CAS for the AC, where the UE establishes a new Protocol Data Unit (PDU) connection to the CAS; performing, by the UE, an ACR launching procedure to a Source-Edge Enabler server (S-EES) with an ACR action indicating an ACR initiation and corresponding ACR initiation data, where the S-EES utilizes an Application Function (AF) traffic influence with N6 routing information of the CAS in a 3GPP Core Network (CN); and transferring, by the UE, the network service relates to the application context from the S-EAS to the CAS, where the transferred application context maintains continuity of the network service for the UE.

In an embodiment, where an EEC attempts to discover the suitable target EAS with S-EES provisioned in a service provisioning response when the service provision procedure is completed without supplying application information but S-EES information is provisioned.

In an embodiment, where the AC remains connected to the CAS and disconnects from the S-EAS in response to a successful transformation of the network service relates to the application context from the S-EAS to the CAS.

In an embodiment, the method includes terminating, by the S-EAS and/or the CAS, the ACR based on location information of the UE; and discarding, by the CAS, the application context based on the location information of the UE and/or information received from an Edge Enabler Layer (EEL), where the EEL includes the S-EAS, the EEC, and the ECS and interactions between these entities.

In an embodiment, where the S-EES authorizes the request from an EEC and executes the ACR based on information received from the EEC and/or an EAS profile.

In an embodiment, the method includes sending, by the UE, an ACR management notification for ACT start event to the S-EAS to initiate the ACR between the S-EAS and the CAS.

Accordingly, the embodiment herein is to provide a method for the ACR between the edge server and the CAS. The method includes sending, by the S-EAS of the edge server, the network service relates to the application context by the UE. Further, the method includes performing, by the S-EAS, an action(s) to determine the requirement of the ACR in order to maintain continuity of the network service. Further, the method includes determining, by the S-EAS, whether to perform the ACR based on the action(s). Further, the method includes performing, by the S-EAS, the ACR, where the network service relates to the ACT from the S-EAS to the CAS and the transferred application context maintains continuity of the network service for the UE.

In an embodiment, the method includes sending, by the S-EAS, the ACR status update message to the S-EES of the edge server. Further, the method includes sending, by the S-EAS, the ACR information notification message to the EEC on successful transferring of the network service relates to the application context from the S-EAS to the CAS, where the CAS performs required CN capability exposure subscriptions upon receiving the application context.

In an embodiment, the action(s) includes receiving, by the S-EAS, the ACR management notification from the S-EES of the edge server, where the ACR management notification indicates the requirement of the ACR and contains CAS information; or self-detecting, by the S-EAS, the requirement of the ACR based on the user plane path change event.

In an embodiment, where performing, by the S-EAS, the ACR, wherein the network service relates to the ACT from the S-EAS to the CAS and the transferred application context maintains continuity of the network service for the UE includes sending, by the S-EAS, a request to the S-EES of the edge server to discover the suitable target EAS; performing, by the S-EAS, the DNS resolution to select CAS when the S-EAS detects that the suitable target EAS is not available for the new location for the UE; sending, by the S-EAS, a selected CAS declaration message to the S-EES, where the S-EES sends a target information notification to the EEC of the UE to indicate the selected CAS for the network service related to the application context; and transferring, by the S-EAS, the network service relates to the application context from the S-EAS to the CAS, where the transferred application context maintains continuity of the network service for the UE.

In an embodiment, the method includes terminating, by the S-EAS and/or the CAS, the ACR based on the location information of the UE; and discarding, by the CAS, the application context based on the location information of the UE and/or information received from the EEL.

In an embodiment, the S-EAS utilizes the AF traffic influence with the N6 routing information of the CAS in the 3GPP CN.

Accordingly, the embodiment herein is to provide a method for the ACR between the edge server and the CAS. The method includes performing, by the S-EES of the edge server, an action to determine the requirement of the ACR in order to maintain continuity of the network service. Further, the method includes performing, by the S-EES, the ACR launching procedure with the ACR action indicating the ACR initiation and corresponding ACR initiation data. Further, the method includes determining, by the S-EES, whether to perform the ACR based on the location information, and/or EEC context information, and/or EAS profile. Further, the method includes performing, by the S-EES, the ACR, where the network service relates to the ACT from the S-EAS of the edge server to the CAS and the transferred application context maintains continuity of the network service for the UE.

In an embodiment, the method includes receiving, by the S-EES, the ACR status update message from the S-EAS; and sending, by the S-EES, the ACR information notification message to the EEC on successful transferring of the network service relates to the application context from the S-EAS to the CAS, where the CAS performs required CN capability exposure subscriptions upon receiving the application context.

In an embodiment, where the action includes receiving, by the S-EES, a user plane path change notification from the 3GPP CN to determine the requirement of the ACR.

In an embodiment, where performing, by the S-EES, the ACR, wherein the network service relates to the ACT from the S-EAS of the edge server to the CAS and the transferred application context maintains continuity of the network service for the UE includes performing, by the S-EES, the DNS resolution to select CAS when the S-EAS detects that the suitable target EAS is not available for the new location for the UE; sending, by the S-EES, the target information notification to the EEC of the UE; applies, by the S-EES, the AF traffic influence with the N6 routing information of the CAS in the 3GPP CN; sending, by the S-EES, the ACR management notification for the ACT start event to the S-EAS to initiate the ACR between the S-EAS and the CAS; and transferring, by the S-EES, the network service relates to the application context from the S-EAS of the edge server to the CAS, where the transferred application context maintains continuity of the network service for the UE.

In an embodiment, where the application context is encrypted and protected by the application layer and the S-EES engages in a packet level transport of the application context with no visibility to a content of the application context.

Accordingly,, the embodiment herein is to provide a system for the ACR between the edge server and the CAS. The CAS is configured to interact with the S-EES of the edge server by using an EDGE-14 interface, the ECS by using an EDGE-15 interface, the 3GPP CN using an EDGE-16 interface, the S-EAS of the edge server using a first application data traffic interface, and the UE using a second application data traffic interface. The edge server is configured to interact with one or more of the UE, the CAS, the 3GPP CN, and the ECS by using one of an existing application data traffic interface, an existing edge interface, the first application data traffic interface, and the EDGE-14 interface, where the edge server includes the S-EAS and the S-EES. The UE is configured to interact with one or more of the edge server, the CAS, the 3GPP CN, and the ECS using one of the existing application data traffic, the existing edge interface, the second application data traffic interface, and the EDGE-16 interface. The ECS is configured to interact with one or more of the edge server, the CAS, the 3GPP CN, and the UE using one of the existing edge interfaces and the EDGE-15 interface.

Accordingly, the embodiments herein provide the UE for the ACR between the edge server and the CAS. The UE includes an ACR controller coupled with a processor and a memory. The ACR controller receives the network service relates to the application context from the S-EAS of the edge server, where the UE includes the AC and the EEC. Further, the ACR controller detects the requirement of the ACR in order to maintain continuity of the network service based on the mobility event associated with the UE and/or the non-mobility event associated with the edge server, and/or the trigger event. Further, the ACR controller determines whether to perform the ACR based on the application profile of the UE and/or the detected mobility event and/or detected non-mobility event, and/or detected trigger event. Further, the ACR controller performs the ACR, where the network service relates to the ACT from the S-EAS to the CAS and the transferred application context maintains continuity of the network service for the UE.

Accordingly, the embodiments herein provide the S-EAS for the ACR between the edge server and the CAS. The S-EAS includes an ACR controller coupled with a processor and a memory. The ACR controller sends the network service relates to the application context by the UE. Further, the ACR controller performs the action to determine the requirement of the ACR in order to maintain the continuity of the network service. Further, the ACR controller determines whether to perform the ACR based on the action. Further, the ACR controller performs the ACR, where the network service relates to the ACT from the S-EAS to the CAS and the transferred application context maintains continuity of the network service for the UE.

Accordingly, the embodiments herein provide the S-EES for the ACR between the edge server and the CAS. The S-EES includes an ACR controller coupled with a processor and a memory. The ACR controller performs the action to determine the requirement of the ACR in order to maintain continuity of the network service. Further, the ACR controller performs the ACR launching procedure with the ACR action indicating the ACR initiation and corresponding ACR initiation data. Further, the ACR controller determines whether to perform the ACR based on the location information and/or the EEC context information, and/or the EAS profile. Further, the ACR controller performs the ACR, where the network service relates to the ACT from the S-EAS of the edge server to the CAS and the transferred application context maintains continuity of the network service for the UE.

Accordingly, the embodiments herein provide the CAS for ACR. The CAS includes an ACR controller coupled with a processor and a memory. The ACR controller interacts with the S-EES of the edge server by using an EDGE-14 interface, the ECS by using an EDGE-15 interface, the 3GPP CN using an EDGE-16 interface, the S-EAS of the edge server using a first application data traffic interface, and the UE using a second application data traffic interface. Further, the ACR controller detects a need for ACR and decide whether to perform the ACR and start the ACR at an appropriate time.

These and other aspects of the embodiments herein will be better appreciated and understood when considered in conjunction with the following description and the accompanying drawings. It should be understood, however, that the following descriptions, while indicating preferred embodiments and numerous specific details thereof, are given by way of illustration and not of limitation. Many changes and modifications may be made within the scope of the embodiments, and the embodiments herein include all such modifications.

This invention is illustrated in the accompanying drawings, throughout which like reference letters indicate corresponding parts in the various figures. The embodiments herein will be better understood from the following description with reference to the drawings, in which:

FIG. 1 illustrates an existing architecture for enabling edge applications, according to the prior art;

FIG. 2 illustrates an architecture for enabling edge applications with support for Application Context Relocation (ACR) between an edge server and a Cloud Application Server (CAS), according to the embodiments as disclosed herein;

FIG. 3A illustrates a block diagram of a User Equipment (UE) for the ACR between the edge server and the CAS, according to the embodiments as disclosed herein;

FIG. 3B illustrates a block diagram of a Source Edge Application Server (S-EAS) of the edge server for the ACR between the edge server and the CAS, according to the embodiments as disclosed herein;

FIG. 3C illustrates a block diagram of a Source-Edge Enabler server (S-EES) of the edge server for the ACR between the edge server and the CAS, according to the embodiments as disclosed herein;

FIG. 3D illustrates a block diagram of the CAS for the ACR between the edge server and the CAS, according to the embodiments as disclosed herein;

FIG. 4 illustrates a scenario of the ACR initiated by the EEC and Application Clients (ACs) of the UE for edge and cloud deployments, according to the embodiments as disclosed herein;

FIG. 5 illustrates a scenario of the ACR executed by an Edge Enable Client (EEC) of the UE for the edge and cloud deployments, according to the embodiments as disclosed herein;

FIG. 6 illustrates a scenario of the ACR decided by the S-EAS for the edge and cloud deployments, according to the embodiments as disclosed herein; and

FIG. 7A and FIG. 7B illustrates a scenario of the ACR executed by the S-EES for the edge and cloud deployments, according to the embodiments as disclosed herein.

The embodiments herein and the various features and advantageous details thereof are explained more fully with reference to the non-limiting embodiments that are illustrated in the accompanying drawings and detailed in the following description. Descriptions of well-known components and processing techniques are omitted so as to not unnecessarily obscure the embodiments herein. Also, the various embodiments described herein are not necessarily mutually exclusive, as some embodiments can be combined with one or more other embodiments to form new embodiments. The term "or" as used herein, refers to a non-exclusive or, unless otherwise indicated. The examples used herein are intended merely to facilitate an understanding of ways in which the embodiments herein can be practiced and to further enable those skilled in the art to practice the embodiments herein. Accordingly, the examples should not be construed as limiting the scope of the embodiments herein.

As is traditional in the field, embodiments may be described and illustrated in terms of blocks which carry out a described function or functions.　These blocks, which may be referred to herein as managers, units, modules, hardware components or the like, are physically implemented by analog and/or digital circuits such as logic gates, integrated circuits, microprocessors, microcontrollers, memory circuits, passive electronic components, active electronic components, optical components, hardwired circuits and the like, and may optionally be driven by firmware. The circuits may, for example, be embodied in one or more semiconductor chips, or on substrate supports such as printed circuit boards and the like.　The circuits constituting a block may be implemented by dedicated hardware, or by a processor (e.g., one or more programmed microprocessors and associated circuitry), or by a combination of dedicated hardware to perform some functions of the block and a processor to perform other functions of the block.　Each block of the embodiments may be physically separated into two or more interacting and discrete blocks without departing from the scope of the disclosure.　Likewise, the blocks of the embodiments may be physically combined into more complex blocks without departing from the scope of the disclosure.

The accompanying drawings are used to help easily understand various technical features and it should be understood that the embodiments presented herein are not limited by the accompanying drawings. As such, the present disclosure should be construed to extend to any alterations, equivalents, and substitutes in addition to those which are particularly set out in the accompanying drawings. Although the terms first, second, etc. may be used herein to describe various elements, these elements should not be limited by these terms. These terms are generally only used to distinguish one element from another.

Throughout this disclosure, the terms "edge server", "EDN" and "edge deployment" are used interchangeably. Throughout this disclosure, the terms "CAS" and "cloud deployment" are used interchangeably.

3rd Generation Partnership Project (3GPP) is developing a technical specification (3GPP TS 23.558) that provides application layer architecture and related procedures for enabling edge applications over 3GPP networks for a User Equipment (UE), as illustrated in FIG. 1. When the UE moves to a new location, different Edge Application Servers (EASs) may be more suitable for serving Application Clients (ACs) in the UE. Such transitions can result from a non-mobility event also, requiring support from an enabling layer to maintain the continuity of a service i.e. to minimize service interruption while replacing a Source-EAS (S-EAS), with a Target-EAS (T-EAS). Generally, the S-EAS is associated with an application context. To support service continuity, the application context is transferred from the S-EAS to the T-EAS. Capabilities for supporting the service continuity provided at an edge enabler layer may consider various application layer scenarios in which there may be involvement of the ACs and one or more EAS(s).

In deployments, service rendering may be unavailable via the EAS (e.g., S-EAS, T-EAS, etc.) at certain geographic locations, for example, due to the EAS being overloaded, the EAS not being deployed, the EAS being shut down, or an Edge Data Network (EDN) not being available. In such cases, a user of the UE's edge applications receives unreliable services (no service continuity) from the edge/EDN as suitable S-EAS/T-EAS is not available for a current location and/or the new location of the UE, which degrades user's experience. Furthermore, the user of the UE's edge applications wishes to keep receiving service from a cloud application server as the suitable S-EAS/T-EAS is not available for the current location and/or the new location of the UE. However, 3GPP TS 23.558 does not address application switching at the edge/EDN or in the cloud application server. Thus, it is desired to address the above-mentioned disadvantages or other shortcomings or at least provide a useful alternative for Application Context Relocation (ACR) between the edge/ EDN and the cloud application server/cloud deployments.

FIG. 1 illustrates an existing architecture (1000) for enabling edge applications, according to the prior art. The Edge Data Network (EDN) (30) is a local Data Network. Edge Application Servers (EAS(s)) (30a) and Edge Enabler server (EES) (30b) are included within the EDN (30). Edge Configuration Server (ECS) (40) provides configurations related to the EES (30b), including details of the EDN (30) hosting the EES (30b). The UE includes an Application Client (AC) (10a) and an Edge Enable Client (EEC) (10b). The EAS(s) (30a), the EES (30b), and the ECS (40) can interact with a 3GPP Core Network (20).

Generally, the AC (10a), the EEC (10b), the EES (30b), and the EAS (30a) implementations will support only a subset of scenarios; therefore, during an EAS discovery and a T-EAS discovery a Source Edge Enabler server (S-EES) and a Target Edge Enabler server (T-EES) (not shown in FIG.1) shall take an ACR scenario supported by the AC (10a) and the EEC (10b) and any preferences indicated by the EEC (10b) for specific ACR scenarios into account when identifying the EAS(s) (30a) for an EAS discovery response, or the EAS discovery notification. Furthermore, when the EEC (10b) performs the EAS discovery or T-EAS discovery, the EES (30b) or T-EES shall inform the EEC (10b) about the ACR scenarios which are supported by the EAS (30a) or Target Edge Application Server (T-EAS) (not shown in FIG.1), respectively.

The EEC (10b) shall take the information about supported ACR scenarios provided by the ECS (40), the S-EES, and the T-EES into account when selecting the EES (30b) for the EAS discovery or T-EAS discovery, respectively, and when selecting the EAS (30a) for edge services. For each of the scenarios, performing the ACR procedure for one or more ACs (10a) can result in the same EEC (10b) receiving services from more than one EES (30b), which have the registration for the required EASs (30a) that can serve the ACs (10a). In certain scenarios, a successful EEC context relocation procedure enables the EEC to become implicitly registered to the target EES.

Various interfaces are available in the existing architecture, including EDGE-1, EDGE-2, EDGE-3, EDGE-4, EDGE-5, EDGE-6, EDGE-7, EDGE-8, and EDGE-9, same as described in in 3GPP TS 23.558.

Accordingly, the embodiment herein is to provide a method for Application Context Relocation (ACR) between an edge server and a Cloud Application Server (CAS). The method includes receiving, by a User Equipment (UE), network service relates to an application context from a Source Edge Application Server (S-EAS) of the edge server, where the UE includes an Application Client (AC) and an Edge Enable Client (EEC). Further, the method includes detecting, by the UE, a requirement of the ACR in order to maintain continuity of the network service based on a mobility event associated with the UE and/or a non-mobility event associated with the edge server, and/or a trigger event. Further, the method includes determining, by the UE, whether to perform the ACR based on an application profile of the UE and the detected mobility event and/or detected non-mobility event and/or detected trigger event. Further, the method includes performing, by the UE, the ACR, where the network service relates to Application Context Transfer (ACT) from the S-EAS to the CAS and the transferred application context maintains continuity of the network service for the UE.

Accordingly, the embodiment herein is to provide a system for the ACR between the edge server and the CAS. The CAS is configured to interact with the S-EES of the edge server by using an EDGE-14 interface, the ECS by using an EDGE-15 interface, the 3GPP CN using an EDGE-16 interface, the S-EAS of the edge server using a first application data traffic interface, and the UE using a second application data traffic interface. The edge server is configured to interact with one or more of the UE, the CAS, the 3GPP CN, and the ECS by using one of an existing application data traffic interface, an existing edge interface, the first application data traffic interface, and the EDGE-14 interface, where the edge server includes the S-EAS and the S-EES. The UE is configured to interact with one or more of the edge server, the CAS, the 3GPP CN, and the ECS using one of the existing application data traffic, the existing edge interface, the second application data traffic interface, and the EDGE-16 interface. The ECS is configured to interact with one or more of the edge server, the CAS, the 3GPP CN, and the UE using one of the existing edge interface and the EDGE-15 interface.

Accordingly, the embodiments herein provide the UE for the ACR between the edge server and the CAS. The UE includes an ACR controller coupled with a processor and a memory. The ACR controller receives the network service relates to the application context from the S-EAS of the edge server, where the UE includes the AC and the EEC. Further, the ACR controller detects the requirement of the ACR in order to maintain continuity of the network service based on the mobility event associated with the UE and/or the non-mobility event associated with the edge server, and/or the trigger event. Further, the ACR controller determines whether to perform the ACR based on the application profile of the UE and/or the detected mobility event and/or detected non-mobility event and/or detected trigger event. Further, the ACR controller performs the ACR, where the network service relates to the ACT from the S-EAS to the CAS and the transferred application context maintains continuity of the network service for the UE.

Unlike existing methods and systems, the proposed method provides the ACR between the edge server (i.e. Edge Data Network (EDN)) and the CAS by detecting, by detecting entity (e.g., EEC, S-EAS, and S-EES), the requirement of the ACR based on the mobility event associated with the UE and/or the non-mobility event associated with the edge server, and/or the trigger event. Then, a decision entity (e.g., EEC, AC, S-EAS, and S-EES) determines whether to perform the ACR based on an application profile of the UE and the detected mobility event and/or detected non-mobility event and/or detected trigger event. Then, an execution entity (e.g., EEC, AC, S-EAS, and S-EES) transfer's network service(s) relates to an application context from a Source Edge Application Server (S-EAS) of the edge server to the CAS in order to maintain continuity of the network service in response to determining that the ACR is performed. As a result, a user of the UE's edge applications receives reliable services (service continuity) from the edge server and/or the CAS, which enhances user's experience.

Unlike existing methods and systems, the proposed method assists the AC to find a suitable EAS during mobility, and transfers of application context from the S-EAS to the T-EAS is one of key features of the overall edge enabler layer. The proposed method contributes significantly to overall design of an architecture for enabling edge applications. Without this key feature, there would be no service continuity in certain geographic areas where application service rendering may be unavailable via the EAS.

This invention/proposed method addresses this problem through application context relocation (ACR) for enabling service continuity between edge and cloud deployments. To support the need for the ACR, the following entity roles are identified,

Detection entity, detecting or predicting the need for ACR;

Decision-making entity, deciding that the ACR is required; and

Execution entity, executing ACR.

The scenarios are different with regards to which entities execute the above-mentioned roles,

Initiation of the ACR by the EEC using a regular EAS Discovery

The EEC executed the ACR via the S-EES

The S-EAS decided the ACR scenario

The S-EES executed the ACR

The EEC executed the ACR via the T-EES

Referring now to the drawings and more particularly to FIGS. 2 through 7, where similar reference characters denote corresponding features consistently throughout the figures, there are shown preferred embodiments.

FIG. 2 illustrates an architecture (2000) for enabling edge applications with support for Application Context Relocation (ACR) between an edge server (300) and a Cloud Application Server (CAS) (500), according to the embodiments as disclosed herein. The proposed architecture (2000) includes a UE (100), a 3GPP core network (200), an edge server (300), an Edge Configuration Server (ECS) (400), and a Cloud Application Server (CAS) (500). The UE (100) includes an Application clients (ACs) (100a) and an Edge Enabler Client (EEC) (100b). The edge server (300) includes an Edge Application Server (EAS) (300a) and Edge Enabler Server (EES) (300b).

The proposed architecture (2000) enables interactions between the EAS (300a) and the CAS (500). Compared to the EDGE APP (Rel-17) architecture, a new entity Cloud Application Server (CAS) (500) is proposed along with a new reference point EDGE-14 (between the EES (300b) and the CAS (500)), an EDGE-15 (between the ECS (400) and the CAS (500)) and an EDGE-16 (between the 3GPP core network (200) and the CAS (500)).

The CAS (500) interaction with the EES (300b) is supported via the EDGE-14 reference point and the CAS (500) is supported by the ECS (400) via the EDGE-15 reference point. The CAS (500) and the EAS (300a) interaction is supported as an application data traffic (i.e. a first application data traffic interface), which is out of scope of this application. The CAS (500) interaction with the 3GPP core network (200) happens over the EDGE-16 reference point, which is similar to the EDGE-7 reference point.

Since the EAS (300a) may have service area restrictions, once the UE (100) is moving out of a current edge coverage, to keep service continuity, the application client (i.e. AC (100a)) needs to connect to either another EAS in new EDN (not shown in FIG. 2) or the CAS (500). The proposed architecture (2000) supports the ACR between the edge server (300) and the cloud server (500) following scenarios:

Condition-1: For locations where the edge server (300) (i.e. EDN) is not available, a default action is based on a failed service provisioning response (i.e. non-availability of the EDN at a particular location) from the ECS (400).

Condition-2: When AC profiles are sent in a service provisioning request and a particular EAS (e.g., EAS (300a)) is not available then the EDN (300) non-availability for that EAS (300a) is inferred through a service provisioning response.

Condition-3: For the locations where the EDN (300) is available but the EAS (300a) is not available, a default action is based on an indication from the EES (300b) (in the EAS discovery response) about the non-availability of the EAS (300a) at that particular location.

Condition-4: the EAS (300a) and the EDN (300) are available but the EAS (300a) is overloaded or not in a position to serve the EEC (100b)/the UE (100) due to any reason.

The conditions above are just examples and all of them can co-exist.

The default action when the required EDN (300)/EAS (300a) is unavailable, the UE (100) initiates a DNS query to help the AC (100a) to reach the CAS (500).

Alternative Default Action: the ECS (400) can be configured with information about the default AS (i.e. CAS) e.g. Domain name, IP address, etc. for the scenarios where the EDN (300)/the EAS (300a) is not available (for example, EDN/EAS not available at certain locations and like so).

In an embodiment, enhancements to the entities (e.g. EAS, EES, ECS, etc.) and interfaces in FIG. 2 is shown below in Table 1,

[Table 1]

In an embodiment, the ECS discovery and service provisioning procedures (specified in 3GPP TS 23.558) include the domain name configuration of the application required for the DNS query to establish a connection with the CAS (500). If only the domain name is configured, the UE (100) consumes the services from the CAS (500) by performing the DNS query of the domain name configured by the ECS (400).

In an embodiment, the service provisioning by the ECS (400) includes the list of cloud configuration information (for each application) which is obtained by the ECS (400) acting as a DNS client, for the domain name of the application.

In an embodiment, the T-EAS discovery by the EEC (100b) includes a list of cloud configuration information (for each application) which is obtained by the EES (300b) acting the DNS client, for the domain name of the application.

In another embodiment, the CAS (500) performs registration and de-registration to the S-EES with appropriate parameters for edge (e.g., edge server (300)) to the cloud (e.g., CAS (500)) switching.

In an embodiment for discovering the T-EAS (as specified in TS 23.558), in Step 2 of Figure 8.8.3.3-1 of 3GPP TS 23.558, if the T-EES retrieval is done without supplying the application information but the EES (300b) information is provisioned, then the S-EES attempts to discover the relevant T-EAS with the EES provisioned in the response if any. Otherwise, the edge server (300) to the CAS (500) switching is required and

steps

3 and 4 of Figure 8.8.3.3-1 of 3GPP TS 23.558, are skipped. Further, in step 4 when the T-EAS is not available, the edge server (300) to the CAS (500) switching is required.

FIG. 3A illustrates a block diagram of the UE (100) for the ACR between the edge server (300) and the CAS (500), according to the embodiments as disclosed herein. Examples of the UE (100) include, but are not limited to a smartphone, a tablet computer, a Personal Digital Assistance (PDA), an Internet of Things (IoT) device, a wearable device, etc.

In an embodiment, the UE (100) includes a memory (110), a processor (120), a communicator (130), and an ACR controller (140).

In an embodiment, the memory (110) stores network service relates to an application context and a requirement of the ACR in order to maintain continuity. The memory (110) stores instructions to be executed by the processor (120). The memory (110) may include non-volatile storage elements. Examples of such non-volatile storage elements may include magnetic hard discs, optical discs, floppy discs, flash memories, or forms of electrically programmable memories (EPROM) or electrically erasable and programmable (EEPROM) memories. In addition, the memory (110) may, in some examples, be considered a non-transitory storage medium. The term "non-transitory" may indicate that the storage medium is not embodied in a carrier wave or a propagated signal. However, the term "non-transitory" should not be interpreted that the memory (110) is non-movable. In some examples, the memory (110) can be configured to store larger amounts of information than the memory. In certain examples, a non-transitory storage medium may store data that can, over time, change (e.g., in Random Access Memory (RAM) or cache). The memory (110) can be an internal storage unit or it can be an external storage unit of the UE (100), a cloud storage, or any other type of external storage.

The processor (120) communicates with the memory (110), the communicator (130), and the ACR controller (140). The processor (120) is configured to execute instructions stored in the memory (110) and to perform various processes. The processor (120) may include one or a plurality of processors, maybe a general-purpose processor, such as a central processing unit (CPU), an application processor (AP), or the like, a graphics-only processing unit such as a graphics processing unit (GPU), a visual processing unit (VPU), and/or an Artificial intelligence (AI) dedicated processor such as a neural processing unit (NPU).

The communicator (130) is configured for communicating internally between internal hardware components and with external devices (e.g. eNodeB, gNodeB, server, etc.) via one or more networks (e.g. Radio technology). The communicator (130) includes an electronic circuit specific to a standard that enables wired or wireless communication.

The ACR controller (140) is implemented by processing circuitry such as logic gates, integrated circuits, microprocessors, microcontrollers, memory circuits, passive electronic components, active electronic components, optical components, and hardwired circuits, or the like, and may optionally be driven by firmware. The circuits may, for example, be embodied in one or more semiconductor chips, or on substrate supports such as printed circuit boards and the like.

In an embodiment, the ACR controller (140) receives network service related to an application context from a Source Edge Application Server (S-EAS) (300a) of the edge server (300), where the UE (100) includes an Application Client (AC) (100a) and an Edge Enable Client (EEC) (100b). The ACR controller (140) detects a requirement of the ACR in order to maintain continuity of network service based on a mobility event associated with the UE (100) and/or a non-mobility event associated with the edge server (300), and/or a trigger event, where the UE (100) does not receive the network service related to the application context from the S-EAS (300a). The mobility event indicates a new location of the UE (100) which is outside a service area of the S-EAS (300a), the non-mobility event includes one or more conditions to initiate the ACR between the edge server (300) and the CAS (500), and the trigger event is triggered by an Edge Configuration Server (ECS) (400) by sending a notification to the UE (100), where the notification indicates that a suitable target EAS is not available for the new location of the UE (100).

One or more condition includes detecting, by the ACR controller (140), that the edge server (300) is not available for a new location of the UE (100) based on a failed service provisioning response from an Edge Configuration Server (ECS) (400); detecting, by the ACR controller (140), that a suitable target EAS is not available for the new location, wherein the UE (100) sends a service provisioning request to the edge server (300) for the suitable target EAS and the UE (100) receives a failed service provisioning response in response to detecting that the suitable target EAS is not available for the new location of the UE (100); detecting, by the ACR controller (140), that the edge server (300) is available for the new location and the suitable target EAS is not available for the new location based on an EAS discovery response; detecting, by the ACR controller (140), that the suitable target EAS is overloaded for the new location; and detecting, by the UE (100), that the CAS (500) serves the UE (100) for the new location and the suitable target EAS is available for the new location, where the ACR is initiated to maintain continuity of the network service via the suitable EAS.

The ACR controller (140) determines whether to perform the ACR based on an application profile of the UE (100) and the detected mobility event and/or detected non-mobility event and/or detected trigger event. The ACR controller (140) performs the ACR, where the network service relates to the ACT from the S-EAS (300a) to the CAS (500) and the transferred application context maintains continuity of the network service for the UE (100).

The ACR controller (140) performs a service provision procedure for all active applications that require the ACR for the new location of the UE (100), where the service provision procedure results in failure to discover the suitable target EAS for the new location. The ACR controller (140) performs a Domain Name System (DNS) resolution for relevant CAS for the AC (100a), where the UE (100) establishes a new Protocol Data Unit (PDU) connection to the CAS (500). The ACR controller (140) performs an ACR launching procedure to the S-EES (300b) with an ACR action indicating an ACR initiation and corresponding ACR initiation data, wherein the S-EES (300b) utilizes an Application Function (AF) traffic influence with N6 routing information of the CAS (500) in a 3GPP Core Network (CN) (200). The ACR controller (140) transfers the network service relates to the application context from the S-EAS (300a) to the CAS (500), where the transferred application context maintains continuity of the network service for the UE (100).

The EEC (100b) attempts to discover the suitable target EAS with S-EES provisioned in a service provisioning response when the service provision procedure is completed without supplying application information but S-EES information is provisioned. The AC (100a) remains connected to the CAS (500) and disconnects from the S-EAS (300a) in response to a successful transformation of the network service relates to the application context from the S-EAS (300a) to the CAS (500). The S-EES (300b) authorizes the request from an EEC and executes the ACR based on information received from the EEC and/or an EAS profile.

The ACR controller sends an ACR management notification for ACT start event to the S-EAS (300a) to initiate the ACR between the S-EAS (300a) and the CAS (500).

Although the FIG. 3A shows various hardware components of the UE (100) but it is to be understood that other embodiments are not limited thereon. In other embodiments, the UE (100) may include less or more number of components. Further, the labels or names of the components are used only for illustrative purpose and does not limit the scope of the invention. One or more components can be combined together to perform the same or substantially similar function for the ACR between the edge server (300) and the CAS (500).

FIG. 3B illustrates a block diagram of the S-EAS (300a) of the edge server (300) for the ACR between the edge server (300) and the CAS (500), according to the embodiments as disclosed herein.

In an embodiment, the S-EAS (300a) includes a memory (310a), a processor (320a), a communicator (330a), and an ACR controller (340a).

In an embodiment, the memory (310a) stores the network service relates to the application context. The memory (310a) stores instructions to be executed by the processor (320a). The memory (310a) may include non-volatile storage elements. Examples of such non-volatile storage elements may include magnetic hard discs, optical discs, floppy discs, flash memories, or forms of electrically programmable memories (EPROM) or electrically erasable and programmable (EEPROM) memories. In addition, the memory (310a) may, in some examples, be considered a non-transitory storage medium. The term "non-transitory" may indicate that the storage medium is not embodied in a carrier wave or a propagated signal. However, the term "non-transitory" should not be interpreted that the memory (310a) is non-movable. In some examples, the memory (310a) can be configured to store larger amounts of information than the memory. In certain examples, a non-transitory storage medium may store data that can, over time, change (e.g., in Random Access Memory (RAM) or cache). The memory (310a) can be an internal storage unit or it can be an external storage unit of the S-EAS (300A), a cloud storage, or any other type of external storage.

The processor (320a) communicates with the memory (310a), the communicator (330a), and the ACR controller (340a). The processor (320a) is configured to execute instructions stored in the memory (310a) and to perform various processes. The processor (320a) may include one or a plurality of processors, maybe a general-purpose processor, such as a central processing unit (CPU), an application processor (AP), or the like, a graphics-only processing unit such as a graphics processing unit (GPU), a visual processing unit (VPU), and/or an Artificial intelligence (AI) dedicated processor such as a neural processing unit (NPU).

The communicator (330a) is configured for communicating internally between internal hardware components and with external devices (e.g. eNodeB, gNodeB, server, etc.) via one or more networks (e.g. Radio technology). The communicator (330a) includes an electronic circuit specific to a standard that enables wired or wireless communication.

The ACR controller (340a) is implemented by processing circuitry such as logic gates, integrated circuits, microprocessors, microcontrollers, memory circuits, passive electronic components, active electronic components, optical components, hardwired circuits, or the like, and may optionally be driven by firmware. The circuits may, for example, be embodied in one or more semiconductor chips, or on substrate supports such as printed circuit boards and the like.

In an embodiment, the ACR controller (340a) sends the network service relates to the application context by the UE (100). The ACR controller (340a) performs an action to determine the requirement of the ACR in order to maintain continuity of the network service. The action includes receiving the ACR management notification from the S-EES (300b) of the edge server (300), where the ACR management notification indicates the requirement of the ACR and contains CAS information; and self-detecting the requirement of the ACR based on a user plane path change event.

The ACR controller (340a) performs the ACR, where the network service relates to the ACT from the S-EAS (300a) to the CAS (500) and the transferred application context maintains continuity of the network service for the UE (100). The ACR controller (340a) sends a request to the S-EES (300b) of the edge server (300) to discover the suitable target EAS. The ACR controller (340a) performs the DNS resolution to select CAS when the S-EAS (300a) detects that the suitable target EAS is not available for the new location for the UE (100). The ACR controller (340a) sends a selected CAS declaration message to the S-EES (300b), where the S-EES (300b) sends a target information notification to the EEC (100b) of the UE (100) to indicate the selected CAS for the network service related to the application context. The ACR controller (340a) transfers the network service relates to the application context from the S-EAS (300a) to the CAS (500), where the transferred application context maintains continuity of the network service for the UE (100). The ACR controller (340a) terminates the ACR based on the location information of the UE (100). The ACR controller (340a) discards the application context based on the location information of the UE (100) and/or information received from an Edge Enabler Layer (EEL). The S-EAS (300a) utilizes the AF traffic influence with the N6 routing information of the CAS (500) in the 3GPP CN (200).

The ACR controller (340a) sends an ACR status update message to the S-EES (300b) of the edge server (300). The ACR controller (340a) sends an ACR information notification message to the EEC (100b) on the successful transferring of the network service related to the application context from the S-EAS (300a) to the CAS (500), where the CAS (500) performs required Core Network (CN) capability exposure subscriptions upon receiving the application context.

Although the FIG. 3B shows various hardware components of the S-EAS (300a) but it is to be understood that other embodiments are not limited thereon. In other embodiments, the S-EAS (300a) may include less or more number of components. Further, the labels or names of the components are used only for illustrative purpose and does not limit the scope of the invention. One or more components can be combined together to perform the same or substantially similar function for the ACR between the edge server (300) and the CAS (500).

FIG. 3C illustrates a block diagram of the S-EES (300b) of the edge server (300) for the ACR between the edge server (300) and the CAS (500), according to the embodiments as disclosed herein.

In an embodiment, the S-EES (300b) includes a memory (310b), a processor (320b), a communicator (330b), and an ACR controller (340b).

In an embodiment, the memory (310b) stores the network service relates to the application context. The memory (310b) stores instructions to be executed by the processor (320b). The memory (310b) may include non-volatile storage elements. Examples of such non-volatile storage elements may include magnetic hard discs, optical discs, floppy discs, flash memories, or forms of electrically programmable memories (EPROM) or electrically erasable and programmable (EEPROM) memories. In addition, the memory (310b) may, in some examples, be considered a non-transitory storage medium. The term "non-transitory" may indicate that the storage medium is not embodied in a carrier wave or a propagated signal. However, the term "non-transitory" should not be interpreted that the memory (310b) is non-movable. In some examples, the memory (310b) can be configured to store larger amounts of information than the memory. In certain examples, a non-transitory storage medium may store data that can, over time, change (e.g., in Random Access Memory (RAM) or cache). The memory (310b) can be an internal storage unit or it can be an external storage unit of the S-EES (300b), a cloud storage, or any other type of external storage.

The processor (320b) communicates with the memory (310b), the communicator (330b), and the ACR controller (340b). The processor (320b) is configured to execute instructions stored in the memory (310b) and to perform various processes. The processor (320b) may include one or a plurality of processors, maybe a general-purpose processor, such as a central processing unit (CPU), an application processor (AP), or the like, a graphics-only processing unit such as a graphics processing unit (GPU), a visual processing unit (VPU), and/or an Artificial intelligence (AI) dedicated processor such as a neural processing unit (NPU).

The communicator (330b) is configured for communicating internally between internal hardware components and with external devices (e.g. eNodeB, gNodeB, server, etc.) via one or more networks (e.g. Radio technology). The communicator (330b) includes an electronic circuit specific to a standard that enables wired or wireless communication.

The ACR controller (340b) is implemented by processing circuitry such as logic gates, integrated circuits, microprocessors, microcontrollers, memory circuits, passive electronic components, active electronic components, optical components, hardwired circuits, or the like, and may optionally be driven by firmware. The circuits may, for example, be embodied in one or more semiconductor chips, or on substrate supports such as printed circuit boards and the like.

In an embodiment, the ACR controller (340b) performs an action to determine the requirement of the ACR in order to maintain the continuity of the network service. The action includes receiving, by the S-EES (300b), a user plane path change notification from the 3GPP CN (200) to determine the requirement of the ACR. The ACR controller (340b) performs the ACR launching procedure with the ACR action indicating the ACR initiation and corresponding ACR initiation data. The ACR controller (340b) determines whether to perform the ACR based on the location information and/or the EEC (100b) context information, and/or the EAS profile. The ACR controller (340b) performs the ACR, where the network service relates to the ACT from the S-EAS (300a) of the edge server (300) to the CAS (500) and the transferred application context maintains continuity of the network service for the UE (100).

The ACR controller (340b) performs the DNS resolution to select CAS when the S-EAS (300a) detects that the suitable target EAS is not available for the new location for the UE (100). The ACR controller (340b) sends the target information notification to the EEC (100b) of the UE (100). The ACR controller (340b) applies the AF traffic influence with the N6 routing information of the CAS (500) in the 3GPP CN (200). The ACR controller (340b) sends the ACR management notification for the ACT start event to the S-EAS (300a) to initiate the ACR between the S-EAS (300a) and the CAS (500). The ACR controller (340b) transfers the network service relates to the application context from the S-EAS (300a) of the edge server (300) to the CAS (500), where the transferred application context maintains continuity of the network service for the UE (100). The application context is encrypted and protected by an application layer and the S-EES (300b) engages in a packet level transport of the application context with no visibility of a content of the application context.

The ACR controller (340b) receives the ACR status update message from the S-EAS (300a). The ACR controller (340b) sends the ACR information notification message to the EEC (100b) on successful transferring of the network service relates to the application context from the S-EAS (300a) to the CAS (500), where the CAS (500) performs required CN capability exposure subscriptions upon receiving the application context.

Although the FIG. 3C shows various hardware components of the S-EES (300b) but it is to be understood that other embodiments are not limited thereon. In other embodiments, the S-EES (300b) may include less or more number of components. Further, the labels or names of the components are used only for illustrative purpose and does not limit the scope of the invention. One or more components can be combined together to perform the same or substantially similar function for the ACR between the edge server (300) and the CAS (500).

FIG. 3D illustrates a block diagram of the CAS (500) for the ACR between the edge server (300) and the CAS (500), according to the embodiments as disclosed herein.

In an embodiment, the CAS (500) includes a memory (510), a processor (520), a communicator (530), and an ACR controller (540).

In an embodiment, the memory (510) stores the network service relates to the application context. The memory (510) stores instructions to be executed by the processor (520). The memory (510) may include non-volatile storage elements. Examples of such non-volatile storage elements may include magnetic hard discs, optical discs, floppy discs, flash memories, or forms of electrically programmable memories (EPROM) or electrically erasable and programmable (EEPROM) memories. In addition, the memory (510) may, in some examples, be considered a non-transitory storage medium. The term "non-transitory" may indicate that the storage medium is not embodied in a carrier wave or a propagated signal. However, the term "non-transitory" should not be interpreted that the memory (510) is non-movable. In some examples, the memory (510) can be configured to store larger amounts of information than the memory. In certain examples, a non-transitory storage medium may store data that can, over time, change (e.g., in Random Access Memory (RAM) or cache). The memory (510) can be an internal storage unit or it can be an external storage unit of the CAS (500), a cloud storage, or any other type of external storage.

The processor (520) communicates with the memory (510), the communicator (530), and the ACR controller (540). The processor (520) is configured to execute instructions stored in the memory (510) and to perform various processes. The processor (520) may include one or a plurality of processors, maybe a general-purpose processor, such as a central processing unit (CPU), an application processor (AP), or the like, a graphics-only processing unit such as a graphics processing unit (GPU), a visual processing unit (VPU), and/or an Artificial intelligence (AI) dedicated processor such as a neural processing unit (NPU).

The communicator (530) is configured for communicating internally between internal hardware components and with external devices (e.g. eNodeB, gNodeB, server, etc.) via one or more networks (e.g. Radio technology). The communicator (530) includes an electronic circuit specific to a standard that enables wired or wireless communication.

The ACR controller (540) is implemented by processing circuitry such as logic gates, integrated circuits, microprocessors, microcontrollers, memory circuits, passive electronic components, active electronic components, optical components, hardwired circuits, or the like, and may optionally be driven by firmware. The circuits may, for example, be embodied in one or more semiconductor chips, or on substrate supports such as printed circuit boards and the like.

The ACR controller (540) is configured to interact with the S-EES (300b) of the edge server (300) by using the EDGE-14 interface, the ECS (400) by using the EDGE-15 interface, the 3GPP CN (200) using the EDGE-16 interface, the S-EAS (300a) of the edge server (300) using the first application data traffic interface, and the UE (100) using the second application data traffic interface.

In an embodiment, the ACR controller (540) initiated the ACR, the ACR controller (540) detects the need for the ACR and decides whether to perform the ACR and start the ACR at an appropriate time. When the ACR happens between the S-EAS (300a) and the ACR controller (540), the S-EAS (300a) can be the ACR controller (540). During the ACR execution phase, the ACR controller (540) needs to know the S-EES (300b) before continuing with T-EAS discovery. Once the ACR controller (540) knows the S-EES (300b), the T-EAS discovery and the remaining steps are similar to the "S-EAS decided ACR scenario" as specified in 3GPP TS 23.558, where the ACR controller (540) acts like the S-EAS (300a).

Similarly, in another embodiment, where the AC (100a) connected to the ACR controller (540) now needs to avail edge services can follow one of the below sequences for the ACT from the ACR controller (540) to the S-EAS (300a):

Taking cues from FIG. 4, upon the ACR controller (540) or the AC (100a) detecting the need for the ACR to the edge, the AC (100a) on its own or upon receiving directions from the ACR controller (540) can trigger the EEC (100b) to connect to the edge. The trigger, depending on the information available at the AC (100a) on its own, or from the ACR controller (540) can include the details of the S-EES (300b) and or the S-EAS (300a). Depending on the information provided by the AC (100a), the EEC (100b) can skip service provisioning and EAS discovery or both and help the AC connection to the S-EAS (300a). Once connected, the AC (100) can trigger the ACR controller (540) to perform ACT with the S-EAS (300a).

Upon detecting the need to connect to the edge, the EEC (100b) can perform the service provisioning and EAS discovery procedures and find a suitable EES (e.g., target EES (T-EES)) and an EAS (e.g., target EAS (T-EAS)). Further, the EEC (100b) can request the S-EES (300b) initiate the ACR procedures and instruct the S-EAS (300a) to perform the ACT with the ACR controller (540). In the scenario, the S-EES (300B) and the S-EAS (300a) act as the T-EES and the T-EAS while the ACR controller (540) acts as a source of the application context.

In an embodiment, where the ACR controller (540) knows about EES and EAS deployments, the ACR controller (540) provides EES and EAS addresses, for finding a route to T-EAS for transferring application context, to the EEC (100b) via the AC (100a), for the EEC (100b) to connect with the T-EAS.

In an embodiment, where the ACR controller (540) knows about the EDN (300) and EES deployments, the ACR controller (540) provides the EES address to the EEC (100b) via the AC (100a), for the EEC (100b) to discover the T-EAS and connect to it.

The ACR controller (540) terminates the ACR based on the location information of the UE (100). The ACR controller (540) discards the application context based on the location information of the UE (100) and/or the information received from the EEL.

FIG. 4 illustrates a scenario of the ACR initiated by the EEC (100b) and the AC (100a) of the UE (100) for edge and cloud deployments, according to the embodiments as disclosed herein.

The scenario handles the ACR as a result of the UE (100) moving to, or the UE (100) expecting to move to, a new location that is outside the service area of the S-EAS (300a). It further relies on the EEC (100b) being triggered as a result of the UE's movement. The scenario is based on the service provisioning (as specified in 3GPP TS 23.558) and DNS procedures to discover the CAS (500) that shall serve the AC (100a) as a result of the UE's new location, and that shall receive the application context from the S-EAS (300a) (or multiple S-EASs). The scenario below describes the relocation of a single application context to the CAS (500). However, it should be repeated for each active AC (100a) in the UE (100) for which the EAS (e.g., S-EAS (300a)) or the EDN (300) is not available at that UE location

The pre-conditions:

The AC (100a) in the UE (100) already has a connection to a corresponding S-EAS (300a);

The preconditions for the service provisioning - request/response model as specified in 3GPP TS 23.558 with regards to the EEC (100b) are fulfilled; and

The EEC (100b) is triggered when it obtains the UE's new location or is triggered by another entity such as an ECS notification.

In phase-1(ACR detection): at step 401, the EEC (100b) detects the UE location update as a result of the UE mobility event and is provided with the UE's new location as described in 3GPP TS 23.558. The EEC (100b) can also detect an expected or predicted UE location in the future as described in 3GPP TS 23.558. If the EEC (100b) is triggered by an external entity such as by a notification from the ECS (400), the unavailability of new EESs (to be used as T-EESs) is provided by that notification, and step-403 (phase-3) below is skipped.

In phase-2 (ACR decision): at step 402, either the AC (100a) or the EEC (100b) decides to perform the ACR. Which applications require the ACR can be decided based on the application profile, e.g. requirement of service continuity of the application.

In phase-3 (ACR execution): at step 403, the EEC (100b) performs the service provisioning (as specified in 3GPP TS 23.558) for all active applications that require the ACR. Since the location of the UE (100) has changed, this procedure results in the unavailability of T-EESs that are relevant to the supplied applications and the new location of the UE (100). If the service provisioning is done without supplying the application information but EES information is provisioned, the EEC (100b) attempts to discover the relevant T-EAS with the EES provisioned in the service provisioning response, if any. The service provisioning or discovery of the relevant T-EAS may not result in EES configuration or the relevant T-EAS is not discovered respectively. If the change in UE's location does not trigger a need to change the S-EAS (300a), the subsequent steps will not take place. The EEC (100b) remains connected to the S-EES (300B) (or multiple S-EES) and the AC (100a) (or multiple AC) remains connected to their corresponding S-EAS (300a).

At step 404, if the change in the UE's location triggers a need to change the S-EAS (300a) but the EEC (100b) is not provided with the relevant T-EAS, the EEC (100b) informs the AC (100a) of the unavailability of a suitable EDN for the new location of the UE (100). At step 405, the AC (100a) triggers the UE (100) to perform DNS resolution for the CAS (500) relevant for the AC (100a). The UE (100) may need to establish a new PDU connection to the CAS (500). At step 406, the EEC (100b) performs an ACR launching procedure (as described in 3GPP TS 23.558) to the S-EES (300b) with the ACR action indicating ACR initiation and the corresponding ACR initiation data (along with the details of the CAS (500) and without the need to notify the EAS (e.g., S-EAS (300a))). The S-EES (300b) may apply an AF traffic influence with N6 routing information of the CAS (500) in the 3GPP core network (200) (if applicable), as described in 3GPP TS 23.558.

At step 407, the AC (100a) is triggered by the EEC (100b) to start ACT. The AC (100a) decides to initiate the transfer of application context from the S-EAS (300a) to the CAS (500). After the ACT is completed, the AC (100a) remains connected to the CAS (500) and disconnects from the S-EAS (300a); the EEC (100b) is informed of the completion of the ACT. The S-EAS (300a) or the CAS (500) can further decide to terminate the ACR, and the CAS (500) can discard the application context (e.g. based on monitoring the location of the UE (100)). It is up to the implementation of the S-EAS (300a) and the CAS (500) whether and how to make such a decision.

In phase-4 (Post-ACR clean-up): at step 408, the S-EAS (300a) sends an ACR status update message to the S-EES (300b) as specified in 3GPP TS 23.558. At step 409, if the status in step 408 indicates a successful ACT, the S-EES (300b) sends an ACR information notification (ACR complete) message to the EEC (100b) to confirm that the ACR has been completed as specified in 3GPP TS 23.558. The CAS (500) can perform the required CN capability exposure subscriptions upon receiving the application context.

FIG. 5 illustrates a scenario of the ACR executed by the EEC (100b) of the UE (100) for the edge and cloud deployments, according to the embodiments as disclosed herein. In the scenario, the EEC (100b) executes the ACR via the S-EES (300b) as a result of the UE's movement.

The pre-condition:

The AC (100a) at the UE (100) already has a connection to the S-EAS (300a); and

The EEC (100b) is able to communicate with the S-EES (300b).

In phase-1(ACR detection): at step 501, the EEC (100b) detects that the ACR may be required as described in 3GPP TS 23.558. The EEC (100b) may detect that ACR may be required for an expected or predicted UE location in the future as described in 3GPP TS 23.558.

In phase-2(ACR decision): at step 502, the EEC (100b) decides to proceed required procedures for triggering the ACR.

In phase-3(ACR execution): at step 503, the EEC (100b) performs the service provisioning (as specified in 3GPP TS 23.558) for all active applications that require the ACR. Since the location of the UE (100) has changed, this procedure results in the unavailability of the relevant T-EAS that are relevant to the supplied applications and the new location of the UE (100), as per the assumption of the scenario. The service provisioning or discovery of the relevant T-EAS may not result in the EES configuration or T-EAS is not discovered respectively. The AC (100a) triggers the UE to perform the DNS resolution for the CAS (500) relevant to the AC (100a). The UE (100) may need to establish the new PDU connection to the CAS (500). Several EEC registrations with different EESs may result from the T-EAS discovery process during a single ACR operation.

At step 504, the EEC performs the ACR launching procedure (as described in 3GPP TS 23.558) to the S-EES (300b) with the ACR action indicating ACR initiation and the corresponding ACR initiation data (along with the details of the CAS (500) and with the need to notify the S-EAS (300a)). The S-EES (300b) authorizes the request from the EEC (100b). The S-EES (300b) decides to execute the ACR based on the information received from the EEC (100b) and/or EAS profile. The S-EES (300b) may apply the AF traffic influence with the N6 routing information of the CAS (500) in the 3GPP core network (200) (if applicable) and sends the ACR management notification for the "ACT start" event to the S-EAS, to initiate the ACT between the S-EAS (300a) and the CAS (500). If the EEC (100b) has not subscribed to receive ACR information notifications for ACR complete events from the S-EES (300b), the EEC (100b) subscribes to the notifications as described in 3GPP TS 23.558.

At step 505, the S-EAS (300a) transfers the application context to the CAS (500) at implementation specific time. The S-EAS (300a) or CAS (500) can further decide to terminate the ACR, and the CAS (500) can discard the application context based on information received from the EEL and/or other methods (e.g. monitoring the location of the UE (100)). It is up to the implementation of the S-EAS (300a) and the CAS (500) whether and how to make such a decision.

In phase-4(Post-ACR clean-up): at step 506, the S-EAS (300a) sends the ACR status update message to the S-EES (300b) as specified in 3GPP TS 23.558. At step 507, if the status in step 507 indicates the successful ACT, the S-EES sends the ACR information notification (ACR complete) message to the EEC to confirm that the ACR has been completed as specified in 3GPP TS 23.558.

FIG. 6 illustrates a scenario of the ACR decided by the S-EAS (300a) for the edge and cloud deployments, according to the embodiments as disclosed herein. In the scenario, the S-EAS (300a) may detect the need for ACR locally or is notified by the S-EES (300b) via ACR management notifications for "ACR monitoring" events. The S-EAS (300a) decides whether to perform the ACR and starts the ACR at an appropriate time.

The pre-conditions:

The S-EAS (300a) may depend on the receipt of certain user plane path management events from the S-EES (300b), e.g. "user plane path change" events or "ACR monitoring" events, to detect the need for the ACR. For the following procedure it is assumed that the S-EAS (300a) has subscribed to continuously receive the respective events from the S-EES (300b); and

The EEC (100b) has subscribed to receive ACR information notifications for target information notification events and ACR complete events from the S-EES, as described in 3GPP TS 23.558.

In phase-1(ACR detection): at 601, the S-EAS (300a) either receives ACR management notifications from the S-EAS (300a) indicating that the ACR may be required ("ACR monitoring" event) or self-detects the need for ACR (e.g. upon receipt of a "user plane path change" event). If the ACR management notification indicates an "ACR monitoring" event, then the notification will also contain the CAS information (as per 3GPP TS 23.558). The S-EAS (300a) may detect that ACR may be required for an expected or predicted UE location in the future as described in 3GPP TS 23.558.

In phase-2(ACR decision): at 602, the S-EAS (300a) decides to perform the ACR.

In phase-3(ACR execution): at 603, if the ACR required is self-detected, the S-EAS (300a) requests the S-EES (300b) to discover the targets as described in 3GPP TS 23.558. When the S-EES (300b) determines that no relevant EAS is available for the UE's location it finds out the details of the CAS (500), e.g. via a DNS query/discovery, and provides the details of the CAS (500) to the S-EAS (300a). After the S-EAS (300a) determines to use the CAS (500), the S-EAS (300a) may apply the AF traffic influence with the N6 routing information of the CAS (500) in the 3GPP core network (200) (if applicable). EAS endpoint in discovery could be a Fully Qualified Domain Name (FQDN) of the CAS (500), identical to the FQDN used in the DNS query.

At 604, the S-EAS (300a) sends a selected CAS declaration message to the S-EES (300b), to inform the S-EES (300b) the determined CAS (500) to use as described in 3GPP TS 23.558. At 605, based on the CAS selection information received from the S-EAS (300a), the S-EES (300b) sends the target information notification to the EEC (100b) as described in 3GPP TS 23.558. At 606, the S-EAS (300a) transfers the application context to the selected CAS (500) in step 603. The S-EAS (300a) or the CAS (500) can further decide to terminate the ACR, and the CAS (500) can discard the application context based on information received from the EEL and/or other methods (e.g. monitoring the location of the UE (100)). It is up to the implementation of the S-EAS (300a) and the CAS (500) whether and how to make such a decision.

In phase-4(Post-ACR clean-up): at 607, the S-EAS (300a) sends the ACR status update message to the S-EES (300b) as specified in 3GPP TS 23.558. At 608, if the status in step 608 indicates the successful ACT, the S-EES (300b) sends the ACR information notification (ACR complete) message to the EEC (100b) to confirm that the ACR has been completed as specified in 3GPP TS 23.558.

FIG. 7A and FIG. 7B illustrates a scenario of the ACR executed by the S-EES (300b) for the edge and cloud deployments, according to the embodiments as disclosed herein. In the scenario, the S-EES (300b) detects, decides, and executes the ACR from the S-EAS (300a) to the CAS (500). This may include EELManagedACR by the S-EES (300b) when initiated by the S-EAS (300a) as per 3GPP TS 23.558.

The pre-condition:

The AC (100a) at the UE (100) already has a connection to the S-EAS (300a);

The EEC (100b) is able to communicate with the S-EES (300b);

The EEC (100b) has subscribed to receive ACR information notifications for target information notification events and the ACR complete events from the S-EES (300b), as described in 3GPP TS 23.558;

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

In the case of the EELManagedACR, the CAS (500) has subscribed to receive ACT status notifications as described in 3GPP TS 23.558.

At step 701, the S-EAS (300a) may initiate the EELManagedACR with the S-EES (300b) as specified in 3GPP TS 23.558. In this step, the S-EAS (300a) and the S-EES (300b) negotiate an address of the application context storage to the S-EES (300b). The S-EAS (300a) puts the application context at this address which can be further accessed by the S-EES (300b) when the ACT is required. In this case, the S-EES (300b) executes steps 2 (i.e., S-EES detection), 4 to 9, and 11. The rest of the steps are skipped.

In phase-1(ACR detection): at step 702, detection entities (the S-EAS (300a), the S-EES (300b), and the EEC (100b)) detect that ACR may be required as described in 3GPP TS 23.558. The detection by the S-EES (300b) may be triggered by the user plane path change notification received from the 3GPP core network (200) due to the S-EAS request for "ACR facilitation" event (as per 3GPP TS 23.558) or due to step 701. The detection entity may detect that ACR may be required for an expected or predicted UE location in the future as described in 3GPP TS 23.558.

In phase-2(ACR decision): at step 703, the detection entity performs the ACR launching procedure (as described in 3GPP TS 23.558) with the ACR action indicating ACR determination and the corresponding ACR determination data. At step 704, the S-EES (300b) authorizes the message if received. The S-EES (300b) decides to execute ACR based on the information received or local detection, and the information of EEC context or EAS profile, and then proceed with the below steps.

In phase-3(ACR execution): at step 705, the S-EES (300b) determines the targets via the Discover T-EAS procedure in 3GPP TS 23.558. When the S-EES (300b) determines that no relevant EAS is available for the UE's location it finds out the details of the CAS (500), e.g. via the DNS query/discovery. At step 706, the S-EES (300b) sends the target information notification to the EEC (100b) as described in 3GPP TS 23.558. At step 707, the S-EES (300b) may apply the AF traffic influence with the N6 routing information of the CAS (500) in the 3GPP core network (200) (if applicable). At step 708, the S-EES (300b) sends the ACR management notification (e.g. as notification for "ACR facilitation" event or "ACT start" event as described in clause 8.6.3 of 3GPP TS 23.558 or due to step 701) to the S-EAS (300a) to initiate the ACT between the S-EAS (300a) and the CAS (500).

At step 709, the application context is transferred from the S-EAS (300a) to the CAS (500) at implementation specific time. In the case of the EELManagedACR, the S-EES (300b) accesses the application context from the address as per step 701, and the S-EES (300b) either engages in the ACT from the S-EAS (300a) to the CAS (500) (obtained as per step 705) in a secure way or the S-EES (300b) shares the storage location of the application context with the CAS (500). Further, the CAS (500) accesses the application context. The S-EAS (300a) may also perform the ACT directly with the CAS (500). The application context is encrypted and protected by the application layer. The S-EES (300b) engages in the packet level transport of the application context and has no visibility of the content of the application context.

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

In phase-4(Post-ACR clean-up): at step 710, the S-EAS (300a) sends the ACT status update message to the S-EES (300b) as specified in 3GPP TS 23.558. At step 711, if the status in step 710 indicates the successful ACT, the S-EES (300b) sends the ACR information notification (ACR complete) message to the EEC (100b) to confirm that the ACR has been completed as specified in 3GPP TS 23.558.

In an embodiment, the CAS (500) initiated the ACR, the CAS (500) detects the need for the ACR and decides for whether to perform the ACR and start the ACR at an appropriate time. When the ACR happens between the S-EAS (300a) and the CAS (500), the S-EAS (300a) can be the CAS (500). During the ACR execution phase, the CAS (500) needs to know the S-EES (300b) before continuing with T-EAS discovery. Once the CAS (500) knows the S-EES (300b), the T-EAS discovery and the remaining steps are similar to the "S-EAS decided ACR scenario" as specified in 3GPP TS 23.558, where the CAS (500) acts like the S-EAS (300a).

Similarly, in another embodiment, where the AC (100a) connected to the CAS (500) now needs to avail edge services can follow one of the below sequences for the ACT from the CAS (500) to the S-EAS (300a):

Taking cues from FIG. 4, upon the CAS (500) or the AC (100a) detecting the need for the ACR to the edge, the AC (100a) on its own or upon receiving directions from the CAS (500) can trigger the EEC (100b) to connect to the edge. The trigger, depending on the information available at the AC (100a) on its own, or from the CAS (500) can include the details of the S-EES (300b) and or the S-EAS (300a). Depending on the information provided by the AC (100a), the EEC (100b) can skip service provisioning and EAS discovery or both and help the AC connection to the S-EAS (300a). Once connected, the AC (100) can trigger the CAS (500) to perform ACT with the S-EAS (300a).

Upon detecting the need to connect to the edge, the EEC (100b) can perform the service provisioning and EAS discovery procedures and find a suitable EES (e.g., target EES (T-EES)) and an EAS (e.g., target EAS (T-EAS)). Further, the EEC (100b) can request the S-EES (300b) initiate the ACR procedures and instruct the S-EAS (300a) to perform the ACT with the CAS (500). In the scenario, the S-EES (300B) and the S-EAS (300a) act as the T-EES and the T-EAS while the CAS (500) acts as a source of the application context.

In an embodiment, where the CAS (500) knows about the EES and EAS deployments, the CAS (500) provides EES and EAS addresses, for finding a route to T-EAS for transferring application context, to the EEC (100b) via the AC (100a), for the EEC (100b) to connect with the T-EAS.

In an embodiment, where the CAS (500) knows about the EDN (300) and the EES deployments, the CAS (500) provides the EES address to the EEC (100b) via the AC (100a), for the EEC (100b) to discover the T-EAS and connect to it.

The embodiments disclosed herein can be implemented using at least one hardware device and performing network management functions to control the elements.

The foregoing description of the specific embodiments will so fully reveal the general nature of the embodiments herein that others can, by applying current knowledge, readily modify and/or adapt for various applications such specific embodiments without departing from the generic concept, and, therefore, such adaptations and modifications should and are intended to be comprehended within the meaning and range of equivalents of the disclosed embodiments. It is to be understood that the phraseology or terminology employed herein is for the purpose of description and not of limitation. Therefore, while the embodiments herein have been described in terms of preferred embodiments, those skilled in the art will recognize that the embodiments herein can be practiced with modification within the scope of the embodiments as described herein.

Claims

A method for Application Context Relocation (ACR) between an edge server (300) and a Cloud Application Server (CAS) (500), wherein the method comprises:

receiving, by a User Equipment (UE) (100), at least one network service relates to an application context from a Source Edge Application Server (S-EAS) (300a) of the edge server (300), wherein the UE (100) comprises at least one of an Application Client (AC) (100a) and an Edge Enable Client (EEC) (100b);

detecting, by the UE (100), a requirement of the ACR in order to maintain continuity of the at least one network service based on at least one of a mobility event associated with the UE (100), a non-mobility event associated with the edge server (300), and a trigger event;

determining, by the UE (100), whether to perform the ACR based on an application profile of the UE (100) and the at least one detected mobility event, detected non-mobility event, and detected trigger event; and

performing, by the UE (100), the ACR, wherein the at least one network service relates to an Application Context Transfer (ACT) from the S-EAS (300a) to the CAS (500) and the transferred application context maintains continuity of the at least one network service for the UE (100).
The method as claimed in claim 1, wherein the method further comprises:

sending, by the S-EAS (300a), an ACR status update message to a Source-Edge Enabler server (S-EES) (300b) of the edge server (300); and

sending, by the S-EAS (300a), an ACR information notification message to the EEC (100b) on successful transferring of the at least one network service relates to the application context from the S-EAS (300a) to the CAS (500), wherein the CAS (500) performs required Core Network (CN) capability exposure subscriptions upon receiving the application context.
The method as claimed in claim 1, wherein one or more condition comprises:

detecting, by the UE (100), that the edge server (300) is not available for a new location of the UE (100) based on a failed service provisioning response from an Edge Configuration Server (ECS) (400);

detecting, by the UE (100), that a suitable target EAS is not available for the new location, wherein the UE (100) sends a service provisioning request to the edge server (300) for the suitable target EAS and the UE (100) receives a failed service provisioning response in response to detecting that the suitable target EAS is not available for the new location of the UE (100);

detecting, by the UE (100), that the edge server (300) is available for the new location and the suitable target EAS is not available for the new location based on an EAS discovery response;

detecting, by the UE (100), that the suitable target EAS is overloaded for the new location; and

detecting, by the UE (100), that the CAS (500) serves the UE (100) for the new location and the suitable target EAS is available for the new location, wherein the ACR is initiated to maintain continuity of the at least one network service via the suitable EAS.
The method as claimed in claim 1, wherein performing, by the UE (100), the ACR, wherein the at least one network service relates to the ACT from the S-EAS (300a) to the CAS (500) and the transferred application context maintains continuity of the at least one network service for the UE (100) comprises:

performing, by the UE (100), service provision procedure for all active applications that require the ACR for a new location of the UE (100), wherein the service provision procedure results in failure to discover a suitable target EAS for the new location;

performing, by the UE (100), a Domain Name System (DNS) resolution for relevant CAS for the AC (100a), wherein the UE (100) establishes a new Protocol Data Unit (PDU) connection to the CAS (500);

performing, by the UE (100), an ACR launching procedure to a Source-Edge Enabler server (S-EES) (300b) with an ACR action indicating an ACR initiation and corresponding ACR initiation data, wherein the S-EES (300b) utilizes an Application Function (AF) traffic influence with N6 routing information of the CAS (500) in a 3GPP Core Network (CN) (200); and

transferring, by the UE (100), the at least one network service relates to the application context from the S-EAS (300a) to the CAS (500), wherein the transferred application context maintains continuity of the at least one network service for the UE (100).
A method for Application Context Relocation (ACR) between an edge server (300) and a Cloud Application Server (CAS) (500), the method comprising:

sending, by a Source Edge Application Server (S-EAS) (300a) of the edge server (300), at least one network service relates to an application context to by a User Equipment (UE) (100);

performing, by the S-EAS (300a), at least one action to determine a requirement of the ACR in order to maintain continuity of the at least one network service;

determining, by the S-EAS (300a), whether to perform the ACR based on the a least one action;

performing, by the S-EAS (300a), the ACR, wherein the at least one network service relates to an Application Context Transfer (ACT) from the S-EAS (300a) to the CAS (500) and the transferred application context maintains continuity of the at least one network service for the UE (100).
The method as claimed in claim 5, wherein the method further comprises:

sending, by the S-EAS (300a), an ACR status update message to a Source-Edge Enabler server (S-EES) (300b) of the edge server (300); and

sending, by the S-EAS (300a), an ACR information notification message to the EEC (100b) on successful transferring of the at least one network service relates to the application context from the S-EAS (300a) to the CAS (500), wherein the CAS (500) performs required Core Network (CN) capability exposure subscriptions upon receiving the application context.
The method as claimed in claim 5, wherein the at least one action comprises:

receiving, by the S-EAS (300a), an ACR management notification from a Source-Edge Enabler server (S-EES) (300b) of the edge server (300), wherein the ACR management notification indicates the requirement of the ACR and contains CAS information; or

self-detecting, by the S-EAS (300a), the requirement of the ACR based on a user plane path change event.
The method as claimed in claim 5, wherein performing, by the S-EAS (300a), the ACR, wherein the at least one network service relates to the ACT from the S-EAS (300a) to the CAS (500) and the transferred application context maintains continuity of the at least one network service for the UE (100) comprises:

sending, by the S-EAS (300a), a request to a Source-Edge Enabler server (S-EES) (300b) of the edge server (300) to discover a suitable target EAS;

performing, by the S-EAS (300a), a Domain Name System (DNS) resolution to select CAS when the S-EAS (300a) detects that the suitable target EAS is not available for a new location for the UE (100);

sending, by the S-EAS (300a), a selected CAS declaration message to the S-EES (300b), wherein the S-EES (300b) sends a target information notification to an Edge Enable Client (EEC) (100b) of the UE (100) to indicate the selected CAS for the at least one network service related to the application context; and

transferring, by the S-EAS (300a), the at least one network service relates to the application context from the S-EAS (300a) to the CAS (500), wherein the transferred application context maintains continuity of the at least one network service for the UE (100).
A method for Application Context Relocation (ACR) between an edge server (300) and a Cloud Application Server (CAS) (500), the method comprising:

performing, by a Source-Edge Enabler server (S-EES) (300b) of the edge server (300), at least one action to determine a requirement of the ACR in order to maintain continuity of at least one network service,

performing, by the S-EES (300b), an ACR launching procedure with an ACR action indicating an ACR initiation and corresponding ACR initiation data;

determining, by the S-EES (300b), whether to perform the ACR based on at least one of location information, Edge Enable Client (EEC) (100b) context information, and EAS profile; and

performing, by the S-EES (300b), the ACR, wherein the at least one network service relates to an Application Context Transfer (ACT) from a Source Edge Application Server (S-EAS) (300a) of the edge server (300) to the CAS (500) and the transferred application context maintains continuity of the at least one network service for the UE (100).
The method as claimed in claim 9, wherein the method further comprises:

receiving, by the S-EES (300b), an ACR status update message from the S-EAS (300a); and

sending, by the S-EES (300b), an ACR information notification message to the EEC (100b) on successful transferring of the at least one network service relates to the application context from the S-EAS (300a) to the CAS (500), wherein the CAS (500) performs required Core Network (CN) capability exposure subscriptions upon receiving the application context.
The method as claimed in claim 9, wherein the at least one action comprises:

receiving, by the S-EES (300b), a user plane path change notification from a 3GPP Core Network (CN) (200) to determine the requirement of the ACR.
The method as claimed in claim 9, wherein performing, by the S-EES (300b), the ACR, wherein the at least one network service relates to the ACT from the S-EAS (300a) of the edge server (300) to the CAS (500) and the transferred application context maintains continuity of the at least one network service for the UE (100) comprises:

performing, by the S-EES (300b), a Domain Name System (DNS) resolution to select CAS when the S-EAS (300a) detects that the suitable target EAS is not available for a new location for the UE (100);

sending, by the S-EES (300b), a target information notification to an Edge Enable Client (EEC) (100b) of a User Equipment (UE) (100);

applying, by the S-EES (300b), Application Function (AF) traffic influence with N6 routing information of the CAS (500) in a 3GPP Core Network (CN) (200);

sending, by the S-EES (300b), an ACR management notification for ACT start event to the S-EAS (300a) to initiate the ACR between the S-EAS (300a) and the CAS (500); and

transferring, by the S-EES (300b), the at least one network service relates to the application context from the S-EAS (300a) of the edge server (300) to the CAS (500), wherein the transferred application context maintains continuity of the at least one network service for the UE (100).
A User Equipment (UE) (100) for Application Context Relocation (ACR) between an edge server (300) and a Cloud Application Server (CAS) (500), wherein the UE (100) comprising:

a memory (110);

a processor (120); and

a ACR controller (140), operably connected to the memory (110) and the processor (120), configured to:

receive at least one network service relates to an application context from a Source Edge Application Server (S-EAS) (300a) of the edge server (300), wherein the UE (100) comprises at least one of an Application Client (AC) (100a) and an Edge Enable Client (EEC) (100b);

detect a requirement of the ACR in order to maintain continuity of the at least one network service based on at least one of a mobility event associated with the UE (100), a non-mobility event associated with the edge server (300), and a trigger event;

determine whether to perform the ACR based on an application profile of the UE (100) and the at least one detected mobility event, detected non-mobility event, and detected trigger event; and

perform the ACR, wherein the at least one network service relates to an Application Context Transfer (ACT) from the S-EAS (300a) to the CAS (500) and the transferred application context maintains continuity of the at least one network service for the UE (100).
A Source Edge Application Server (S-EAS) (300a) for Application Context Relocation (ACR) between an edge server (300) and a Cloud Application Server (CAS) (500), wherein the S-EAS (300a) comprising:

a memory (310a);

a processor (320a); and

a ACR controller (340a), operably connected to the memory (310a) and the processor (320a), configured to:

send at least one network service relates to an application context to by a User Equipment (UE) (100);

perform at least one action to determine a requirement of the ACR in order to maintain continuity of the at least one network service;

determine whether to perform the ACR based on the a least one action;

perform the ACR, wherein the at least one network service relates to an Application Context Transfer (ACT) from the S-EAS (300a) to the CAS (500) and the transferred application context maintains continuity of the at least one network service for the UE (100).
A Source-Edge Enabler server (S-EES) (300b) for Application Context Relocation (ACR) between an edge server (300) and a Cloud Application Server (CAS) (500), wherein the S-EES (300b) comprising:

a memory (310b);

a processor (320b); and

a ACR controller (340b), operably connected to the memory (310b) and the processor (320b), configured to:

perform at least one action to determine a requirement of the ACR in order to maintain continuity of at least one network service,

perform an ACR launching procedure with an ACR action indicating an ACR initiation and corresponding ACR initiation data;

determine whether to perform the ACR based on at least one of location information, Edge Enable Client (EEC) (100b) context information, and EAS profile; and

perform the ACR, wherein the at least one network service relates to an Application Context Transfer (ACT) from a Source Edge Application Server (S-EAS) (300a) of the edge server (300) to the CAS (500) and the transferred application context maintains continuity of the at least one network service for the UE (100).