Improvements to microservices for MEC networks and improved methods and systems related thereto

Abstract

The present disclosure relates to a communication method and system for integrating a fifth generation (5G) communication system for supporting a higher data rate than a fourth generation (4G) system and a technology for the Internet of Things (IoT). The present disclosure can be applied to smart services based on 5G communication technology and IoT-related technology, such as smart homes, smart buildings, smart cities, smart cars, connected cars, healthcare, digital education, smart retail, safety and security services. A method for providing services in a multi-access edge computing MEC network is disclosed, comprising the following steps: providing a pod in an edge cloud node, wherein the pod includes a software container for providing an application for providing services to one or more subscribers; associating a state related to an active or registered subscriber with the pod, wherein the active subscriber is currently interacting with the pod, and the registered subscriber is not currently interacting with the pod, but has interacted before; wherein, assuming that the pod has at least one registered subscriber, the pod is maintained in the edge cloud node.

Description

Technical Field

[0001] The present invention relates to a multi-access edge computing (MEC) network. Background Art

[0002] In order to meet the increased demand for wireless data traffic since the deployment of 4G communication systems, efforts have been made to develop improved 5G or pre-5G communication systems. Therefore, 5G or pre-5G communication systems are also referred to as "beyond 4G networks" or "post-LTE systems". 5G communication systems are considered to be implemented in higher frequency (millimeter wave) bands (e.g., 60GHz bands) in order to achieve higher data rates. In order to reduce the propagation loss of radio waves and increase the transmission distance, beamforming, massive multiple-input multiple-output (MIMO), full-dimensional MIMO (FD-MIMO), array antennas, analog beamforming, and massive antenna technology are discussed in 5G communication systems. In addition, in 5G communication systems, system network improvements are being developed based on advanced small cells, cloud radio access networks (RANs), ultra-dense networks, device-to-device (D2D) communications, wireless backhaul, mobile networks, collaborative communications, collaborative multi-point (CoMP), receiving-end interference elimination, etc. In 5G systems, hybrid FSK and QAM modulation (FQAM) and sliding window superposition coding (SWSC) have been developed as advanced coded modulation (ACM), and filter bank multi-carrier (FBMC), non-orthogonal multiple access (NOMA) and sparse code multiple access (SCMA) as advanced access technologies.

[0003] As a human-centered connected network in which humans generate and consume information, the Internet is now developing towards the Internet of Things (IoT), in which distributed entities (such as things) exchange and process information without human intervention. The Internet of Everything (IoE), in which IoT technology and big data processing technology are combined with cloud server connection, has emerged. As IoT implementation has required technical elements such as "sensing technology", "wired / wireless communication and network infrastructure", "service interface technology" and "security technology", sensor networks, machine-to-machine (M2M) communication, machine type communication (MTC), etc. have been studied recently. Such an IoT environment can provide intelligent Internet technology services that create new value for human life by collecting and analyzing data generated between connected things. Through the integration and combination between existing information technology (IT) and various industrial applications, IoT can be applied to various fields, including smart homes, smart buildings, smart cities, smart cars or connected cars, smart grids, healthcare, smart appliances, and advanced medical services.

[0004] In line with this, various attempts have been made to apply 5G communication systems to IoT networks. For example, technologies such as sensor networks, machine type communications (MTC), and machine-to-machine (M2M) communications can be implemented through beamforming, MIMO, and array antennas. Cloud radio access networks (RANs) as an application of the above-mentioned big data processing technologies can also be considered as an example of the convergence between 5G technologies and IoT technologies.

[0005] A Multi-Access Edge Computing (MEC) network is a network in which certain services or functions are provided at the edge of the network, i.e., close to the user, or locally at the client infrastructure, rather than in a centralized (or even decentralized) cloud.

[0006] This form of network architecture allows cloud computing capabilities and IT service environments to operate at the edge of the mobile network. This architecture has many significant advantages, such as allowing services to be delivered to end users with greatly reduced latency. However, two aspects of this technology are problematic for network operators. The first is the capital expenditure (CAPEX), which can be huge even for basic systems without a clear return on investment use case. The second is the latency for mobile subscribers to migrate services from one edge network to another. Any resulting service disruption will undermine the advantages of deploying services at the edge of the network.

[0007] A seemingly obvious solution is to deploy all services to all edge networks for all subscribers, even if they are not using the service or have never registered on the edge network where the service is installed. This means that the mobile operator must size its MECs for all services and all subscribers in every MEC in its network. This is very expensive in practice and therefore does not represent a realistic solution.

[0008] Furthermore, the idea of ​​migrating services and context (the user / subscriber specific transient state of a service or application, i.e. all the information needed to recreate the service or application in the new location in exactly the same situation as in the previous location) across roaming networks has the same problem. A first mobile operator (A) may refuse to allow a second mobile operator (B) to deploy all services on their MEC so that a subscriber from A can roam on network B and use the service.

[0009] MEC systems are known in the art, and are generally provided to provide improved performance to consumers by physically locating certain resources at the edge of the network, ie away from the central core or the Internet, but close to the consumers.

[0010] Fig.12A general MEC system 100 is shown and how it relates to other entities in the system. Multiple user types 10 are able to connect to the MEC system 100. Such users 10 can access the MEC system 100 via, for example, fixed wired solutions, WiFi, or cellular technologies such as LTE or 5G.

[0011] The MEC system 100 includes various other entities, including locally hosted applications (apps), and if a user 10 requests access to such an app, the MEC system 100 is able to provide access to the user without recourse to any remote server or resource.

[0012] If desired, such remote resources may be accessed via core network 110 , which can utilize resources in centralized cloud 120 and / or Internet 130 .

[0013] The MEC system 100 is necessarily localized, and the availability of a particular resource to a user depends on where that user is located and which MEC system it has access to.

[0014] One issue with MEC systems is service continuity, especially when users move around and access services provided by different MEC application hosting environments within a single MEC system or across different MEC systems, or when switching between services provided in the cloud and MEC systems. Different solutions have been proposed whereby different entities (e.g., known entities such as application clients, edge enabling clients (EECs), edge enabling servers (EESs), or edge application servers (EASs)) can determine the need for application user context relocation.

[0015] However, the currently proposed solution is reactive, because application user context relocation is initiated only when an alternative application server instance is considered preferred. Therefore, during application user context relocation, service interruption will occur. Summary of the invention

[0016] Technical issues

[0017] The purpose of the embodiments of the present invention is to provide seamless service continuity in the aforementioned context.

[0018] Embodiments of the present invention are directed to addressing shortcomings in the prior art, whether mentioned herein or not.

[0019] Technical Solution

[0020] According to the present invention, there is provided an apparatus and a method as set out in the accompanying claims. Further features of the invention will become apparent from the dependent claims and the subsequent description.

[0021] According to a first aspect of the present invention, a method for providing services in a multi-access edge computing MEC network is provided, comprising the following steps: providing a pod in an edge cloud node, wherein the pod includes a software container for providing an application for providing services to one or more subscribers; associating a state related to an active subscriber or a registered subscriber with the pod, wherein the active subscriber is currently interacting with the pod, and the registered subscriber is not currently interacting with the pod, but has interacted with it before; wherein, assuming that the pod has at least one registered subscriber, the pod is maintained in the edge cloud node.

[0022] In an embodiment, a particular subscriber remains in a registered state until one or more of the following conditions apply: a configurable time period has elapsed; the particular subscriber is no longer registered with the service; or the particular subscriber becomes an active subscriber.

[0023] In an embodiment, if a pod has no active or registered subscribers, the pod is deleted.

[0024] In an embodiment, the pod is deleted only after a configurable period of time has elapsed.

[0025] In an embodiment, the configurable time period is determined based on a behavioral pattern of one or more subscribers.

[0026] In an embodiment, a user context associated with an active subscriber at a pod is made available to one or more other pods.

[0027] In an embodiment, the user context is made available through an ambassador mode operable to replicate data between the pod and one or more other pods. The one or more other pods may reside in the same edge cloud node as the original pod, or may reside in one or more other edge cloud nodes.

[0028] In an embodiment, determining the one or more other pods is performed based on a prediction of subscriber behavior.

[0029] In an embodiment, the prediction is based on one or more of: previous movements of the subscriber; and the subscriber's current location and / or speed and / or direction of travel.

[0030] According to a second aspect of the present invention, there is provided a system comprising an edge cloud node and a plurality of pods, operable to perform the method of the first aspect.

[0031] In an embodiment, the system includes at least one pod associated with at least one registered or active subscriber.

[0032] In an embodiment, a cluster network manager is also provided that is operable to manage the services available on a particular pod.

[0033] Embodiments of the present invention employ a novel use of the Ambassador pattern (one of the standard design patterns for cloud computing systems) to replicate data between edge clusters to achieve consistent persistent context, which means that the subscriber's user context is continuously updated to all persistent volume claims (PVCs). The result is seamless service migration because when a UE transitions from one edge cloud node to another, no user context update is required because it has already been replicated at the target node. This means that the UE's access to services can continue uninterrupted.

[0034] To ensure that services are available at the required edge network locations, embodiments of the present invention introduce the concept of a "static" Pod (where a Pod is a service provider in Kubernetes terminology). Such a Pod can remain in the edge network even after all registered users are no longer active, and is therefore protected from termination.

[0035] In order to manage the availability of distributed Pods, embodiments of the present invention introduce a centralized cluster network manager (CNM). In the ETSI MEC architecture, such an entity can be collocated with the MEC orchestrator (called MEC application orchestrator in network function virtualization deployment).

[0036] Embodiments of the present invention provide a way for the network to deploy services in the form of software containers to the MEC network where users are typically registered (e.g., a common Monday-Friday cell where a user is registered will only have those services that are unique to that user or group of users). In this way, the number of active services deployed to the MEC will be only for general users residing on those cell sites within that MEC.

[0037] Embodiments of the present invention will likely significantly reduce the CAPEX required for general MEC deployments. In addition, they will eliminate latency in service migration in solutions where services are migrated, or in solutions where services simply follow users and need to be constantly deleted and created across the MEC network.

[0038] According to a third aspect of the present invention, there is provided a method for managing access of a user equipment UE to a specific application in a telecommunications network, comprising the following steps: the network serves the UE from a first application server instance; the network detects the presence of the UE in an overlapping area of ​​coverage between a coverage area of ​​the first application server and a coverage area of ​​a second application server; as a result of the detection, the network establishes a copy of the UE's application user context at the second application server instance.

[0039] In an embodiment, one of the first and second application servers is associated with the MEC network.

[0040] In an embodiment, the first and second application servers are each associated with a different MEC network.

[0041] In an embodiment, the threshold for detecting entry into an overlap region is different from the threshold for detecting exiting an overlap region.

[0042] In an embodiment, the step of detecting the presence of a UE within the overlapping coverage area is based on the location of the UE, which is determined by one or more of the following: location information provided by the UE; the geographic location of the UE; RF signal related information provided by the UE or a telecommunications network associated with a serving cell and neighboring cells; a timing advance associated with the UE; and serving cell information.

[0043] In an embodiment, traffic rules are invoked whereby data traffic is directed to the first and second application servers such that the application user context of the UE may be maintained at the first application server instance and the second application server instance.

[0044] In an embodiment, the responses from the first and second application server instances are compared to check whether synchronization is maintained.

[0045] In an embodiment, if synchronization is not maintained, a synchronization recovery process is initiated.

[0046] In an embodiment, the overlapping area of ​​coverage is static or dynamic.

[0047] In an embodiment, the overlapping area of ​​coverage is dynamic and is defined based on one or more of resource availability in the network and UE-specific characteristics.

[0048] In an embodiment, the UE-specific characteristic is one of: pedestrian status; vehicle status; and speed.

[0049] In an embodiment, a copy of the UE's application user context at the second application server instance is maintained until the UE returns to the coverage area of ​​the first application server or becomes served by the second application server instance.

[0050] In an embodiment, if the UE becomes served by the second application server instance and is still in the overlapping area, a copy of the UE's application user context is maintained at the first application server instance, and if the UE is not in the overlapping area, the copy of the UE's application user context at the first application server instance is deleted.

[0051] According to a fourth aspect of the present invention, there is provided a system operable to perform the method of the third aspect.

[0052] Embodiments of the present invention provide significant advantages over the prior art

[0053] Embodiments of the present invention provide overlapping area definitions between service areas of two or more application servers, where one or more of the application servers are hosted by a MEC system.

[0054] Embodiments of the present invention provide that the overlap area definition includes UE specific characteristics, such as speed, vehicle status (potentially associated with a specific road), pedestrian user status. In addition, the same overlap area definition can be applied to UEs with similar characteristics.

[0055] Embodiments of the present invention provide for defining separate criteria (eg, different boundary locations) for entering and leaving the overlap region to introduce hysteresis, thereby helping to prevent UE ping-ponging (or rapid entry and exit) between being considered in and out of the overlap region.

[0056] Embodiments of the present invention provide that overlap region definitions may be dynamically adjusted based on edge data network (EDN) resource availability (eg, if resources are currently scarce, the overlap region may be reduced).

[0057] Embodiments of the present invention provide that an EDN configuration server (EDNCS) with cross-network visibility maintains and shares overlapping area definitions with distributed EESs in the network, or each EES maintains its own overlapping area definitions. The default overlapping area definitions can be fine-tuned based on application characteristics and UE characteristics. The latter are evaluated by the EES. In addition, the overlapping area definitions can be dynamically adjusted based on changes in EDN resource availability.

[0058] Embodiments of the present invention provide that the EES in the network uses a geolocation algorithm to determine whether the UE has entered or left the overlapping area. In addition, the actions caused by entering and leaving the overlapping area are initiated within the network, in particular within the EES. The geolocation algorithm can obtain user plane management information (including serving cell information, timing advance, UE serving / neighboring cell signal quality / strength measurement information) and input from the UE itself.

[0059] Embodiments of the present invention provide that there may be a centralized EES associated with application instances currently hosted in the cloud that would benefit from movement to the edge to detect a UE entering an overlap region with the edge.

[0060] Embodiments of the present invention provide that the EES associated with each EDN is responsible for detecting UEs entering / leaving the overlapping area, but in alternative embodiments this detection may be performed in a centralized manner.

[0061] Embodiments of the present invention provide that the peer EES entity is responsible for invoking traffic rules in the data plane to ensure that application layer traffic is routed to the replicated application server instance when the UE is in the overlapping region. The EES associated with the serving application instance server also has application server instance synchronization management capabilities, for example, to invoke a comparison of responses from each application server instance (within the data plane, or by a separate comparison entity) to check whether synchronization is maintained. If a loss of synchronization is detected, the EES can initiate a synchronization recovery process.

[0062] By providing intelligence in the network rather than in the UE, more efficient and responsive control can be achieved, ensuring that the network entity best suited to make such decisions (ie, the network) does so.

[0063] While several preferred embodiments of the present invention have been shown and described, it will be understood by those skilled in the art that various changes and modifications may be made without departing from the scope of the invention as defined in the appended claims. BRIEF DESCRIPTION OF THE DRAWINGS

[0064] For a better understanding of the invention, and to show how embodiments of the invention may be implemented, reference will now be made, by way of example only, to the accompanying drawings, in which:

[0065] Figure 1 shows a representation of a typical user according to the radio cell nodes visited;

[0066] Figure 2 A general prior art cloud-based system architecture is shown;

[0067] Figure 3 An architecture including a static pod according to an embodiment of the present invention is shown;

[0068] Figure 4 shows a cluster deployment according to an embodiment of the present invention;

[0069] Figure 5 A cluster network manager according to an embodiment of the present invention is shown;

[0070] Figure 6 An ambassador mode in a system according to an embodiment of the present invention is shown;

[0071] Figure 7 shows a general MEC system reference architecture according to the prior art;

[0072] Figure 8 shows a message flow illustrating monitored event notifications according to an embodiment of the present invention;

[0073] Fig. 9shows a message flow illustrating application instantiation according to an embodiment of the present invention;

[0074] Fig.10 A message flow illustrating a request from a MEP to a MEO to instantiate an application according to an embodiment of the present invention is shown;

[0075] Fig.11 shows a message flow for notifying an application instance of a location / address change by a MEO according to an embodiment of the present invention;

[0076] Fig.12 A known MEC system and its related entities are shown;

[0077] Fig.13 An application architecture for enabling edge applications is shown;

[0078] Fig.14 The concept of overlapping areas or equivalent application service areas between EDNs is shown;

[0079] Fig.15a and 15b The application mobility process according to an embodiment of the present invention is shown;

[0080] Fig.16 illustrates EAS replication according to an embodiment of the present invention; and

[0081] Fig.17 The EAS replication after switching according to an embodiment of the present invention is shown. DETAILED DESCRIPTION

[0082] Embodiments of the present invention provide a way to optimize the cloud computing infrastructure on a MEC network so that it only has deployed service containers and user contexts for users who typically migrate to and use (or have used) that particular edge network.

[0083] The following description uses terminology commonly used in cloud computing environments—particularly from Kubernetes systems—but is equally applicable to any cloud-based system. Cloud-based networking generally describes how the network automatically manages connectivity, containerized workloads, lifecycle management, and services, which facilitates declarative configuration and automation. This means that application developers do not have to think about or build into their systems: network elasticity; deployment; load balancing; system sizing (i.e., how the system scales horizontally); and management and logging (health checks and liveness reporting).

[0084] In this way, the system is responsible for application status, responsiveness and scalability. It ensures that "workers" are generated, instantiated and provide services to end users. The entire life cycle management is performed by cloud computing infrastructure. In the example case presented in this article, "Kubernetes" is used as an example, but the technician will recognize that other systems or solutions are equally applicable. It uses a container system to generate and manage services deployed to its node computing cluster. As mentioned above, it provides scalability (i.e., starting workers and load balancing when needed), backend services for extended databases and persistence, and IP mapping of services that allow dynamic routing, management and recording.

[0085] Embodiments of the present invention reduce the footprint typically required for MEC deployments and improve the way services are dynamically added and removed from deployed MEC networks. A general solution for MEC networks is to deploy a "container" (a lightweight deployable software package containing an operating system (OS) and software required to run a service) that can support all subscribers on the network, even if no subscriber is actually using the service, or the user is no longer using the service on the edge network.

[0086] The cost of the infrastructure at the edge is very expensive. It should be able to generate services for users present on that mobile network. Compared with general telecom services built in the core network (CN), generating services on the edge network is not instant or real-time. This means that in order to reduce the time to activate services, in theory, the network can deploy all services for all users on all edge networks. This means that all edge points must be able to support all services for all users at any time. This will lead to a significant increase in the CAPEX of the deployed edge network.

[0087] Additionally, migrating services when needed can increase latency / delay, network traffic, and degrade user experience as users migrate from one edge network to another. This can be illustrated by considering a gaming edge service where moving from one cell location to another causes the game to hang due to latency.

[0088] Embodiments of the present invention provide a method to address and mitigate these and other problems, namely, eliminating the latency of migrating user services from one edge point to another and reducing the CAPEX required for a MEC network that can support all users of all services on a mobile network.

[0089] A minimal development container using Ubuntu as the container host OS is approximately 100MB before the service is deployed.

[0090] For production systems, services can be deployed on an Alpine Linux container, which is approximately 5-10MB before any services are deployed.

[0091] Understandably, if containers are constantly deployed and removed due to user movement, this will have a significant impact on the MEC network. An alternative consideration is the impact on the MEC network with services that are never used but consume computing resources.

[0092] There are situations where users will move between the same cell sites every day, with changes in usage patterns occurring infrequently. For example, someone working the same job might move between the same cell sites from Monday to Friday. In 3G, 4G, and 5G networks, cell sites are referred to as NodeBs, eNodeBs, or gNodeBs, respectively, but in the context of this application, they are all referred to simply as NBs. Figure 1 A general path taken by two users - User A and User B - is shown.

[0093] When utilizing services provided by the mobile network (e.g., internet connectivity), user A will attach to NB-3, NB-1, and NB-5 every day based on their general behavior. Similarly, user B will typically only attach to NB-4, NB-1, and NB-6 throughout the day. When these users use centralized cloud services through the core network, the fact that they attach to the mobile network through different (relatively closely spaced) NBs has little impact on the ideal physical location of the service cloud server. However, in MEC deployments, it may become critical where "cloud-like" services are provided through localized edge data networks (which may be associated with only a limited number of NBs), and what services each server provides.

[0094] For example, if there is an edge data network associated with each NB, when a user is attached to a particular NB, the associated edge data network will likely be best suited to serve that user. To support this, embodiments of the present invention solve the problem of ensuring that required services are available at each edge point when needed, without the need to deploy all services at all edge points, thereby solving CAPEX and latency issues.

[0095] In the context of this application, the deployment and management of services are referred to herein as enhanced mobility of microservices. The term microservices is used because applications that provide services deployed in cloud-based systems typically adopt a microservice-based design pattern. With this approach, applications are provided as a collection of loosely coupled microservices rather than a single monolithic application. Each microservice may have a narrower scope that focuses on a specific task. Such microservices then communicate with each other to provide an overall service, such as a Netflix or BBC I-Player application service. Containers can then be used to package, deploy, and run the application.

[0096] Initially, according to an embodiment of the present invention, using this enhanced mobility solution for microservices, services are deployed as users move from one edge network to another. This can be performed in a preemptive manner if it is determined that the user is likely to move into the service area of ​​the new edge network. This involves building a service usage picture based on the user's general behavior. This is to make future service deployment decisions and determine appropriate retention time periods for these deployments. This is defined as a "configuration time period" in this article.

[0097] For example, based on the user's daily routine, if they typically use the Netflix service between the hours of 7pm and 11pm when attached to NB-3, the system will (to the extent possible, given other resource constraints) ensure that the Netflix service is available in the edge network associated with that NB during a time period overlapping with that time.

[0098] Given a picture built over time for each service (which may include user granularity, i.e., specific user usage of a service), enhanced mobility for microservices according to an embodiment will retain a specific service at an edge point even if the user is not actively using it. If the user is active on that edge point for a "configured time period," the service remains active in the edge data network associated with that specific NB. If the "configured time period" has expired, the service is removed from the cluster, freeing up resources for other services.

[0099] Leveraging specific user knowledge (i.e., predicted times when a particular user may use a service at a particular location), an enhanced mobility scheme for microservices according to an embodiment of the present invention ensures the availability of context associated with the use of a particular service at an edge point to which the expected user may be connected (via attachment to a NB associated with an edge data network). Such user context can be associated with an ongoing service (e.g., a game in progress), or with a resumed service (e.g., resuming a game at a specific point, level, score, media content, etc.). To achieve this, an embodiment employs a novel use of the cloud computing "ambassador" design pattern for container-based distributed systems to replicate data between edge clusters.

[0100] Embodiments of the present invention employ two main components: the first involves the management of the physical deployment of a pod with a service container (a software package containing an OS and all software libraries required to run a service); and the second involves how to manage user context for an already active container.

[0101] Enhanced mobility for microservice systems according to embodiments introduces a "pod" classification, where a "pod" is defined in Kubernetes terms as a collection of related tightly coupled containers that provide a single function or service. In the context of embodiments of the present invention, when a "pod" has the ability to be retained in the edge network after all registered users no longer use the pod and is therefore protected from termination, the "pod" is classified as "static". If the pod does not support enhanced mobility capabilities for microservice functions, it is classified as "traditional". Using the container orchestration method of the prior art, the pod keeps consuming resources by default until it is explicitly terminated, regardless of the user's registration status. If the "pod" migrates with the user (which is also possible), it also has a disadvantage that if the user wants to use the service provided by the pod again, there is a lag in the process of re-establishing the pod. For users who use services in one cloud node and move to another cloud node and want to use the service there, this lag is even more problematic. This situation especially arises with the introduction of edge computing, where cloud nodes are physically separated (edge ​​cloud nodes), and users are expected to connect to the edge cloud nodes that are geographically closest to them.

[0102] Based on Kubernetes technology, a general cloud-based system has Figure 2 An architecture similar to that shown in Figure 1. In such a system, a "pod" containing a software container will be maintained throughout its lifecycle. The cloud computing platform (edge ​​cloud node) provides dynamic routing between pods via virtual Ethernet adapters (virtual Ethernet 01 and 02) and bridges (bridge 0). It is also able to scale services via replication when needed.

[0103] According to an embodiment of the present invention, in an enhanced mobility system, a pod marked as "static" is given the ability to remain on an edge cloud node. Figure 3 In the example, static Pod 1 has metadata marked as "static" and has registered subscribers and active subscribers. In all figures of this application, registered subscribers are indicated by a circled R. Active subscribers are indicated by an A in a circle. express.

[0104] Here, an active subscriber means a subscriber that is registered on this MEC node for the specific service in question and is currently interacting with that service using the relevant information exchange. A registered subscriber means a subscriber that is registered on this MEC node for the specific service in question (if this is applicable to the service) and was active at some point in the past. A user is kept in the "registered" state until one of the following occurs:

[0105] A) The "configurable time period" has passed

[0106] B) they have actually been deregistered from the service (e.g. no longer a Netflix customer of the Netflix service)

[0107] C) The subscriber switches to the NB associated with the edge cloud node and transitions to the “active” state by interacting with the service.

[0108] The system may select users for preemptive removal in order to free up edge cloud node resources, for example to allow other pods to be created.

[0109] When there are no registered or active subscribers on a static pod, it will be removed from the node.

[0110] Figure 3 Two pods are shown. In pod 1, there are registered subscribers and active subscribers. In pod 2, there are active subscribers. If the active subscriber in pod 2 moves to a different cell site of a different edge network, the subscriber state will change to "registered". Maintaining a record of when a subscriber entered a cell and registered on the cell allows for efficient management of the pods. If a pod has only "registered" subscribers, it will be removed from the cluster after a "configurable time period" has passed.

[0111] Each pod is given a "time to live" based on a previously defined configured period timeout. This period can be configured on a pod-by-pod basis, or can be a default value for the network. In the case of Kubernetes, this can be obtained by querying the management system (which will maintain the appropriate configured period timeout for each pod) in the same way as the health and vitality checks normally used in such systems. Therefore, for general services, there are REST endpoints for health, vitality, and lifetime. The lifetime period will always be calculated from the time the last user transitioned its state to "registered".

[0112] The architecture of the enhanced mobility capabilities deployed on the edge network corresponds exactly to Figure 2 The general cloud-based system architecture includes Figure 3 The static pod concept shown.

[0113] Figure 4 The extended deployment according to an embodiment of the present invention is shown, wherein Figure 1In the scenario first presented in Figure 1, a cluster of edge cloud nodes (edge ​​cloud nodes 1 and 2) is deployed for cell site NB-3. Associated with cell site NB-3 is a deployed edge network consisting of 2 edge cloud nodes supporting a total of 4 pods. Of the 4 pods, 3 pods are static (pod1-3) and one pod (pod4) is a traditional "pod" to which the enhanced mobility functionality according to an embodiment of the present invention is not applicable. Based on the status of the subscriber in the edge network, the cell site is displayed as having active subscribers and registered subscribers. Within the edge network, if the active user moves from the cell site and the locally configured time period on each of these assets has expired, Pods 1, 2, and 4 will be removed.

[0114] According to the prior art process, dynamic routing is performed within the "cluster network" logic block. Therefore, any service mapped to a URL will be routed to the correct Pod. If Pod 1 has a lot of traffic and the vitality endpoint fails, Kubernetes will instantiate another pod that replicates this Pod and will automatically load balance between these pods.

[0115] The new element according to an embodiment of the present invention is the Cluster Network Manager (CNM). To understand this, consider the case where there are two cell sites (NB-3 and NB-1, which are first Figure 1 ).

[0116] In this scenario, each cell site has an edge network with several Kubernetes nodes and pods deployed. Figure 5 Nodes NB-3 and NB-1 simply use the metrics of active subscribers and lifetime of the pod to handle the deletion of the pod. However, it is necessary to decide what service to deploy for what subscriber in each MEC cluster network.

[0117] The subscriber is notified via the core network (CN) or the application on the user's mobile phone. At this time, a request is sent to the CNM, such as Figure 5 As shown in Figure 2, CNM is responsible for all MEC cluster networks across mobile networks.

[0118] For example, when 'User A' wishes to use, for example, the BBC I-Player service and attaches to the mobile network via NB-1, the CNM is responsible for ensuring that a BBC I-Player pod is available (in this case, on cluster 1 with pod number 1). The CNM will inform the edge network at NB-1 to create services (pods) for User A if they do not already exist. The CNM knows what service to register for which user.

[0119] In the ETSI MEC architecture of the prior art, the MEC orchestrator (MEO) or the MEC application orchestrator (MEAO) in a network function virtualization (NFV)-based deployment is responsible for service instantiation. However, requests for service instantiation are only made via the operation support system (OSS), so the MEO currently does not know what service is registered for which subscriber. Therefore, according to an embodiment of the present invention, it is necessary to enhance the MEO of the prior art so that it can perform the role of CNM.

[0120] When a third party provides a service, it registers itself with the CNM, providing a UserID, MSISDN number, or another unique identity agreed upon by the third party and the mobile operator. The CNM then manages the deployment and lifecycle of the service on the network.

[0121] If "User A" moves back to NB-3 before the configured period timeout expires, the BBC I-Player pod will still be available and the user will be able to access all edge services provided by the pod with minimal lag and therefore minimal service interruption.

[0122] Typically, in prior art systems, cluster routing is done by Figure 5 The "Cluster Network" management shown. This routes packets to and between services, and manages the virtual IP (VIP) addresses between edge cloud (Kubernetes) nodes within the cluster.

[0123] According to an embodiment of the present invention, in an enhanced mobility setting for microservices, a cluster can be deployed to a single edge. The routing to the active server does not change because packets between the user equipment (UE) and the service still flow directly between the active edge node and the device.

[0124] Once a UE attaches to a node (NB), the pod application in the associated edge cloud node makes PersistentVolumeClaims (PVC), which is a Kubernetes mechanism for requesting block storage by users. For example, in Figure 5 In the example, a UE attaches to NB-1, which triggers pod 1 to update its state, i.e., active and registered users, plus the associated user context. With PVC, data is dynamically persisted to block storage devices for all replicated containers on nodes in traditional Kubernetes systems, but this is not the case for PVCs on different edge networks (with their own clusters).

[0125] To achieve consistent persistent context, the services in Enhanced Mobility for Microservices novelly use the Cloud System Ambassador design pattern to replicate data between edge clusters. This means that when a UE migrates from one "static" edge node to another "static" edge node, no user context update is required. This is because the user context is continuously updated to all PVCs for that subscriber. This will be described in more detail below, which involves the general design pattern of cloud computing systems.

[0126] There are three main design patterns for container-based distributed systems. These represent some of the most common use cases for packaging containers together in pods. In short, they are:

[0127] 1.Sidecar: In this pattern, the auxiliary container extends and enhances the core functionality of the main container. This pattern involves performing non-standard or practical functions in a separate container. For example, a container that forwards logs or monitors updated configuration values ​​can enhance the functionality of a pod without significantly changing its main focus.

[0128] 2. Ambassador: The Ambassador pattern uses supplementary containers to abstract remote resources for the main container. The main container connects directly to the Ambassador container, which in turn connects to and abstracts a potentially complex pool of external resources, just like a distributed Redis (https: / / redis.io / ) cluster. The main container can connect to external services without having to know the actual deployment environment.

[0129] 3. Adapter: The adapter pattern is used to transform the data, protocol, or interface of the main container to meet the standards expected by external parties. Adapter containers support unified access to centralized services, even if the applications they serve may originally support only incompatible interfaces.

[0130] According to an embodiment of the present invention, enhanced mobility for microservices implements an "ambassador" mode for synchronizing context to other replicated services that do not belong to the same cluster network (i.e., another edge cloud node or a roaming edge network). Figure 6 , where the following steps (numbered 1, 2, 3) apply.

[0131] Step 1: Active user A updates their context (ie, interacts with the service) and data flows to the Netflix "Pod" via the cluster network of NB-1. The Netflix pod in edge cloud node 2 located in cluster network NB-1 is shown with an active user.

[0132] Step 2: Applications for enhanced mobility can leverage Ambassador mode to check with the CNM which other cluster networks have Netflix service for that user (to determine if context needs to change with other pods). Alternatively, applications using Ambassador mode will be instructed by the CNM to perform context synchronization. This can be done when the pod is deployed, or can change throughout the life of the pod. Context updates are replicated to the CNM.

[0133] Step 3: The CNM identifies any other cluster networks with Netflix service that are "static" and have users that are "registered" or predicted to be "active" in the future (e.g. based on historical data, or the user's current direction and speed). The CNM then routes the message (i.e., the message containing the desired context update, either a delta to the existing context, or a complete replacement) to those cluster networks of that edge network. Thus, the message is automatically routed to the Netflix "Pod", Pod 1, running on Edge Cloud Node 1, where the user is shown as "registered".

[0134] Alternatively, the CNM may control routing, but will facilitate direct communication between cluster networks to pass context, thereby avoiding the need for the context to traverse the CNM.

[0135] As long as the pods providing Netflix services in other cluster networks remain in a "static" state when the user's context is transferred there, steps 2 and 3 do not have to be repeated every time the user context is updated. This can be achieved by setting the subscriber's state to "registered" at those other cluster networks in response to the subscriber's user context being copied to those other cluster networks and also by not applying a "configurable time period" to the associated pods during the copy period.

[0136] The above message flow does not have to happen in real time. Because the switching between NBs is not instantaneous as long as the service persists via the "Pod" or the PVC directly to the edge network. For the edge cloud node running the user's service, the user context is always synchronized.

[0137] In the description so far, reference has been made to a general form of network. The following description relates more specifically to ETSI·MEC and provides more details of that particular configuration. This is not intended to be limiting, but rather to provide specific embodiments, described in terms relevant to the ETSI·MEC configuration.

[0138] Implementations of the present invention provide a means of instantiating service provisioning application servers at specific locations (on MEC hosts) based on predicted user behavior in order to minimize the time required to put these services into operation. Using this approach, application servers can be removed in a controlled manner. This is because if the user has previously interacted with the service, it is desirable that when the user reconnects to the application server, the current user-specific context is immediately available to avoid service interruption. This is independent of whether the service is provided by the original application server or by an alternative application server (if the user has moved locations).

[0139] In the ETSI MEC system architecture, Figure 7 As shown, the centralized MEC orchestrator (MEO) is the entity responsible for issuing application server instantiation requests to each MEC platform manager (MEPM) and has MEC system-wide visibility (i.e., knowledge of MEC host availability). On this basis, the MEO is the preferred location for the cluster network manager (CNM) functionality described earlier.

[0140] In the ETSI MEC system architecture, the MEC platform (MEP) provides access to edge services and can collect service-related usage statistics through monitoring functions. The MEP is contained in the MEC host along with the supporting virtualization infrastructure. The entire MEC system can consist of many MEC hosts that are distributed in different geographical locations to provide services to end users. Therefore, the MEC host is considered to be similar to the distributed edge cloud nodes described earlier.

[0141] To support prediction of user behavior, embodiments of the present invention support a mechanism to share the service utilization (e.g., service API statistics) collected by the MEP with the centralized MEO, since in the current ETSI MEC specification, there is no mechanism to enable the MEO to know what services users are utilizing and through which application servers. Such a mechanism can be subscription-based and allow the MEO to be notified when a specific service is actively used, potentially with user-level granularity. This Figure 8 shown.

[0142] refer to Figure 8 , a notification channel can be established directly from the MEP to the MEO (rather than having to go through the MEPM). The subscription can be established when the MEO initially issues an application instantiation request to the MEPM (see Fig. 9), there can also be individual requests. Individual user identities can be anonymized, using “tags” to represent users, a concept already proposed by ETSI MEC. The MEO then has the necessary information to develop statistical system-wide models to predict when a specific location may need service. This prediction can be used to make user-specific decisions about application instantiation, ensuring consistent and persistent application user context by replicating data between edge clusters using the Ambassador design pattern.

[0143] If user-specific information is not available, then the application server usage information is still relevant when making application instantiation decisions. However, it will not be possible for MEO to directly trigger the process of making user-specific context available as part of the instantiation process. Therefore, there may be a delay in reestablishing services for a particular user while their user-specific state is available on the application server.

[0144] If user-specific information is available, this information can also be used to influence whether MEO instantiates application instances at other locations. For example, if the prediction indicates that the user may be connected to a specific NB at a certain time, but it is already connected elsewhere, MEO may not instantiate the instance at the predicted location at that time.

[0145] In an alternative embodiment, the MEPs may develop their own distributed application server utilization model, which may be user-specific. Such a model may be developed individually per MEP. However, it may be advantageous to support a communication channel between MEPs to share application server instance information and potential user-specific utilization of those instances between each other. ETSI·MEC has defined an Mp3 reference point between MEPs, but no information exchange and APIs are currently specified for this reference point. By using such a channel, information can be shared system-wide without having to involve the MEO, although in the current architecture the MEO would have to be requested to instantiate an application server (such a request is not currently specified), e.g. Fig.10 As shown. The MEO is best suited to share with each MEP which application server of the other MEC host the instance of interest is located on, because the application instance instantiation request originates from the MEO. Therefore, in an embodiment of the present invention, when each application instantiation request is made, the MEO is able to share with the specific MEP the location and / or address of all other relevant application instances on other hosts (see Figure 7 ).

[0146] In addition, if the application instance location / address changes, updated information is provided through a notification mechanism, such as Fig.11 As shown, Fig.11It is shown that alternatively, notifications can be sent directly from MEO to MEPs instead of via MEPM. In existing MEC specifications, application instantiation request messages sent from OSS to MEO provide location constraints for application server placement, but only MEO knows the locations of all instantiated application service instances. Therefore, existing mechanisms are insufficient. Using embodiments of the present invention, by providing relevant application instance information about other hosts, each MEP then knows which other MEPs share relevant monitoring-related information, for example, a certain user has been connected to a certain application instance and where to copy the user context information. Alternatively, each MEP can query MEO for the addresses / locations of other relevant application instances.

[0147] The monitoring information collected by the MEP and passed to the MEO and / or other MEPs can have a wider scope than just service utilization. For example, it can include general API logging information such as the number of API calls, the methods called, the success rate of such requests, and the request response time. This information can also feed into the MEO's application instantiation decision-making process, because if a certain host is considered to provide poor performance, the MEO can decide not to instantiate on that host, and instead direct users to an alternate host.

[0148] Within ETSI MEC, an Application Mobility Service (AMS) has been specified. This enables a service consumer (e.g. an application instance) to register with the service and then benefit from MEC-assisted application mobility, for example in the process of transferring user context between application instances on different MEC hosts. The AMS provides an indication to the application instance that a user context transfer is required and the target address to which the application instance should send the context. The application instance is expected to notify the AMS about connected users (client applications), such as new connections to the application instance, and the status of application context transfers, such as when the transfer has been successfully completed. This enables the AMS to monitor relevant user-specific events, such as events related to handovers. To support application mobility, the application descriptor (containing the necessary information to instantiate an application instance) has been enhanced to provide an indication that the application supports user context transfer capabilities.

[0149] Current AMS is reactive in that user context transfer is initiated only after the user (UE) has switched from the NB associated with the source application instance to the NB associated with the target application instance. Embodiments of the present invention deal with enabling preemptive measures to avoid service disruptions, which involves providing enhanced AMS and CNM capabilities at MEO using Ambassador applications.

[0150] As an initial step, the application descriptor is enhanced to include an attribute indicating that the described application supports "user context copy capability". This implies that the associated application instance has a component that copies the user context and any subsequent updates to that context (either as a complete copy, or just incrementally) to a given location (e.g. a storage location on a potential target MEC host). This is via the proposed ambassador application. Furthermore, an application instance of such an application is able to utilize that user-specific context at the target application instance in the event that the user switches to that instance and in this way continues their session without interruption (e.g. continuing to watch their Netflix movie). The result is that an instance of such an application is able to utilize the stored user context in the event that the user disconnects from the application instance and reconnects later. This facilitates a quick transition from the previously described "registered" state to the "active" state, as the user context associated with the "active" state will be readily available.

[0151] The method for indicating to which application instance locations the source application instance should copy the user context and then subsequently update it has been described previously, namely by including information about other related application instances as part of the application instantiation process, which means that the information is available on the MEC host. In the context of embodiments of the present invention, this implies that the CNM makes the information available to the ambassador application associated with the application instance.

[0152] In an alternative embodiment, the Ambassador Application may query the CNM to provide this information to the user when they connect. It is also possible to select a subset of relevant application instances for a particular user based on user-specific characteristics, such as a model based on historical behavior, or based on current behavior such as the user's current speed and direction of travel. Because this information is dynamic in nature, the Ambassador Application is a suitable way to maintain and provide up-to-date information about where to copy the user's context.

[0153] The steps associated with the use of the proposed enhanced AMS are:

[0154] 1. The application instance associated with the stateful application is registered with the enhanced AMS on the current edge host.

[0155] 2. If the application instance provides an indication that it supports "user context copy capability", the AMS provides a default list of locations (related to other instances of the application on different hosts) where the user context should be copied to. The ambassador algorithm associated with the application instance will use this list.

[0156] 3. The application instance notifies AMS that a user application client is communicating with it. The subscriber will now be considered to be in the "active" state, as in step 1 described previously. If there is a user context available for this subscriber, then that user context will be used for the session with the client application. For subscribers in the "registered" state, the application instance may already know the location of the stored context, otherwise AMS can provide that location. The application instance may also notify any backend components, such as the cloud component of the overall application.

[0157] 4. If requested, the AMS will provide the application instance with the storage location of the user context, if it is available. The AMS may also provide a user-specific list of locations associated with the application instance to which the user context should be copied (the entire list is maintained by the CNM at the MEO), linked to step 2 above. This list overrides the default list of (2.) above.

[0158] 5. The application instance, for example using the Ambassador application described previously, then copies the current context and any subsequent updates to the provided location, linking to step 3 above. The location may include a location associated with an application instance to which the user application client was previously connected.

[0159] 6. Next, if the user performs a handoff to a NB associated with a new edge host, it will communicate with the application instance at that host. Communication with the previous application instance will cease and the user will transition from the "active" state to the "registered" state. The process then repeats from step 3.

[0160] Fig.13 A general scenario and certain network elements or entities related to embodiments of the present invention are shown.

[0161] The user equipment 200 communicates with a wireless cellular network 210. In this example, a 3GPP network is shown, but other forms of networks adapted to one or more other standards are also applicable. The telecommunications network 210 communicates with an edge data network (or MEC) 220. Various other entities and certain communication paths are shown, which will be described in more detail as needed.

[0162] The problem solved by the embodiments of the present invention can be summarized as when a UE switches to a new location, a different application server instance may be more suitable for serving the application client of the UE. Such an application server instance may be hosted in the cloud or in an edge data network. When switching between application server instances, it is desirable that there is no service interruption. The embodiments of the present invention solve the problem of seamless service continuity.

[0163] As mentioned above, existing methods are reactive. Some of them are defined in 3GPP standards. With such methods, application user context relocation is initiated only when an alternative application server instance is considered to be preferred. Therefore, during application user context relocation, service interruption will occur.

[0164] According to embodiments of the present invention, a number of alternatives are described.

[0165] First, seamless service continuity actions are managed by the network, rather than by the UE. This includes detecting the presence of the UE in a domain within the overlapping coverage area of ​​an application server zone through a network-hosted geolocation algorithm that is able to use user plane (UP) management information and information from the UE as input. In addition, UE-specific characteristics are included in the overlap area definition, and separate criteria are defined for entering and leaving the overlap area to prevent UE "ping-pong" between being considered in and out of the overlap area. This can be considered a form of hysteresis. In addition, the network is responsible for invoking traffic rules in the data plane to ensure that application layer traffic is routed to replicated application server instances serving the overlap area. In addition, a mechanism is provided to compare responses from replicated application server instances to ensure that synchronization is maintained, and if not, a resynchronization process is triggered.

[0166] The scheme of seamless service continuity according to an embodiment of the present invention assumes that an overlap zone (geographical area) is defined between edge data networks (EDN or MEC) (and between each EDN / MEC and the cloud, note that there may be geographical areas not covered by the EDN), and once a specific UE enters the overlap zone (assuming it is being served by an EAS instance hosted by one of the EDNs), seamless service continuity measures are triggered for it.

[0167] The EDN coverage area may be partitioned into one or more application service areas, in which case overlap areas are defined between application service areas. This approach is described assuming that the EES manages the seamless service continuity measures, but it is possible that the EAS may be more directly involved.

[0168] An EDN Configuration Server (EDNSC) may be used to maintain overlap region definitions (including which EDNs are associated with each overlap region) and provide the necessary information to each EES to allow it to manage the required seamless service continuity actions. However, it is also possible that the EESs themselves maintain overlap region definitions (again, each with its associated EDN). To support transitions between clouds and EDNs, there may be EESs associated with application instances hosted in the cloud. Information associated with an overlap region would include its geographic area, such as specific coordinates and the EDN (or application service region) with which it is associated. If overlap region definitions are maintained centrally, each EES would provide feedback information to the EDNCS to allow further fine-tuning of the definitions (e.g., how long resources in an adjacent EDN are reserved before a client application requires them).

[0169] Fine tuning may be required to optimize the size of the overlap region, which may be configured as an ongoing process. If it is too large, then additional resources in the neighboring EDN are more likely to be reserved unnecessarily. If it is too small, then the UE may be handed over to a new cell associated with a different EDN before the required EAS instance is available in the neighboring EDN.

[0170] The size of the overlap area can also be adjusted based on UE characteristics. For example, a UE identified as being on a train or on a main road may require an EAS instance in the EDN with overlapping coverage to be established earlier due to the UE speed compared to a slower moving UE (e.g., a pedestrian). Therefore, a larger overlap area can be established for a high mobility UE compared to a low mobility UE.

[0171] The defined boundaries may also be specified differently depending on whether the UE is entering or leaving the overlap area (to prevent ping-ponging between being considered in and out of the overlap area). This is a similar concept to hysteresis, with different thresholds defined for entering or leaving the area. Thus, there may be multiple overlap area definitions per EDN, which may be, for example, application service area specific, or may even be UE specific, or apply to groups of UEs with similar characteristics, or even per UE and application specific.

[0172] In addition, decisions may be made to expand or shrink the size of the overlap region based on changes in the availability of edge data network resources. For example, during periods of heavy load, where active application instances are consuming most of the available resources, it may be desirable to shrink the overlap region to reduce the amount of resources reserved in the adjacent EDN. To make such a decision, if a different entity is responsible for the overlap region definition, it should be made aware, such as the EES notifying the EDNCS.

[0173] Assuming that the overlap area is already available to the EES serving the EAS instance, then, if the UE position can be provided to the EES (with sufficient accuracy and precision), the EES can use the geographic boundaries directly to determine whether the UE is within those boundaries. However, it is likely that a secondary indirect source of UE position will also be required, as the UE position may not always be directly available (e.g., GPS often does not work indoors). Therefore, the presence of the UE in the overlap area can be determined by the geolocation capabilities within the EES through a combination of information elements, such as:

[0174] • RF information (serving and neighbor cell RF related measurements) has been used to make a cell change decision, for example if a neighbor cell becomes better than the serving cell, usually based on a threshold. A different set of thresholds may be used to provide an indication that the UE has moved into an overlapping area before a handover is triggered.

[0175] ● Timing Advance (TA) provides an indication of the distance to the serving cell (it is a measure of the round trip time between the base station and the UE), so a certain TA can be used as a threshold to indicate that the UE has moved into the overlapping area. Note that TA only provides the distance to the serving cell, not the angle to the serving cell, and therefore cannot indicate the direction to the serving cell.

[0176] ● When the EDN is associated with more than one cell or base station, the UE serving cell information (3GPP cell identity) may be sufficient to define the overlapping area. If the EES knows the cell location, the UE's serving cell location can be assumed as its location when checking whether the UE is within the geographical boundaries of the overlapping area.

[0177] The information required to determine this can be obtained by subscribing to relevant user plane management notifications from the 3GPP network (e.g., through the 3GPP capability exposure function, or via a proprietary interface) or from the UE itself. Such notification information may include that previously identified, such as: UE location; RF information; mobility / handover events (including serving cell changes); and UE timing advance.

[0178] As part of the geolocation process, information elements used as input may need to be filtered to introduce hysteresis and ensure that a single spurious measurement does not unnecessarily trigger seamless service continuity actions. Appropriate trigger thresholds for these additional information elements may be signaled to the EES, or determined by the EES itself.

[0179] In the following, the flow of events according to an embodiment of the present invention is described for a scenario in which a UE's application client is served by an EAS instance within a first EDN (EDN-A). The UE then moves to an overlapping area, and it switches to a coverage area associated with a second EDN (EDN-B). It then eventually moves out of the overlapping area. The flow highlights the steps necessary to maintain service continuity during these transitions. The prerequisites are first described, and then the complete flow is given.

[0180] The prerequisites are:

[0181] EAS instance 1 (EAS ins1) is hosted in EDN-A, and EAS instance 2 (EAS ins2) is hosted in EDN-B. Both are instances of the same EAS.

[0182] ● Traffic rules have been invoked to establish the application traffic path between the application client and EAS ins1.

[0183] EAS is available in EDN-A and EDN-B, and the EES in each EDN is aware of this

[0184] o In an alternative embodiment, upon detecting that the UE is in an overlapping area, the EES may invoke a procedure to establish an appropriate EAS instance in EDN-B. This instantiation procedure will ensure that the services consumed by the application instance, such as those provided by the underlying transport network, are available.

[0185] ●There is interaction between EDNCS and EES-A to establish the necessary overlapping areas which can be updated dynamically.

[0186] o The maximum overlap area is defined relative to the coverage area of ​​the EDN, i.e. the radio access network cells associated with it. However, the EDN coverage area can be divided into smaller areas based on the EAS service area

[0187] o The entry and exit points of the overlapping area may be different to introduce hysteresis, thereby preventing the UE from ping-ponging between being considered in and out of the overlapping area. Fig.14 This is illustrated by showing that the overlap entry and exit points are different. It also illustrates the nature of the overlap between EDN-A and EDN-B, and when each of EDN-A and EDN-B is considered to provide primary coverage. The entry and exit points can be fine-tuned based on UE characteristics, such as speed, vehicle status (potentially related to a specific road), pedestrian status.

[0188] ■ In particular, the figure shows how there are overlapping regions where EDN-B is considered to overlap with EDN-A and overlapping regions where EDN-A is considered to overlap with EDN-B.

[0189] ○ Overlapping areas can be dynamically adjusted based on EDN resource availability

[0190] Fig.15a and 15b The flow shown in detail in includes the following steps or messages:

[0191] 1. The application client is served by EAS ins1. Application traffic is routed via the data plane, which is implemented by the User Plane Function (UPF) in the 3GPP Service-Based Architecture (SBA)

[0192] 2. EES-A detects that the UE (hosting application client) has moved to the overlapping area, where EDN-B is considered to overlap with EDN-A

[0193] ● Detection can be done by leveraging user plane management information (e.g. cell ID, TA, measurement reports)

[0194] ● In an alternative embodiment, detection of a UE entering an overlapping area may be performed by a centralized entity (whether a centralized EES interacting with each distributed EES, or an EDNCS). In this case, processes such as in the next step are initiated by the centralized EES rather than EES-A. As in the distributed detection case, the centralized entity will still need to be provided with access to information related to the location of the detecting UE (whether it uses such information to determine the location itself, or is provided with the UE's location directly). The location in this context is not limited to geographic coordinates, and may simply be the UE's radio access service cell identifier.

[0195] ● In the case where application clients are currently served by application instances hosted in the cloud, EES-A will refer to the EES associated with the cloud application (rather than a specific EDN). The assumption is that while application clients may satisfactorily continue to be served via the cloud, relocation to the edge will provide additional advantages, including lower latency.

[0196] 3. EES-A initiates EEC registration with EES-B (directly, or potentially through the orchestration layer). The registration indicates that there is an active EAS instance (i.e., EAS ins1). Alternatively, EES-A may send a request to the EEC for it to initiate registration with EES-B.

[0197] 4. Through interaction with the EDNCS, an overlap region is established at EES-B where EDN-A is considered to overlap with EDN-B (this may be UE and EAS specific).

[0198] 5. Create traffic rules for EAS ins2.

[0199] 6. Confirmation is sent to EES-A

[0200] 7. EES-A now updates its traffic rules. The traffic flow generated after these 3 steps is Fig.16 , which will be described in more detail later.

[0201] ● Traffic rules (the terms routing and steering are also used in this context) established in the data plane to direct traffic to the serving EAS, and to direct the same traffic to the replicated EAS (once it is up and running) will ensure that application user context synchronization is maintained. This is because the replicated EAS instance will think that it is serving the application client and respond accordingly (for example, consider a video delivery application, both application instances will serve the same video frames simultaneously). The response from the replicated EAS instance will not be forwarded to the client application. However, the response can be compared with the response from the serving application instance (without necessarily checking the application layer content) to ensure consistency of the user state in the replicated EAS instance. If a difference is detected, a resynchronization step should be invoked, such as re-copying the stateful components of the application user context. Due to the time difference between the two EDNs, the response from EAS ins2 is expected to lag behind the response from EAS ins1, so this offset must be taken into account in the comparison.

[0202] • If the EAS instance has a backend connection, such as a connection to a partner application entity in the cloud, the traffic rules associated with that connection must also be updated to ensure that traffic originating from that entity is also reflected in EAS ins2.

[0203] 8. When the UE is in the overlapping area, the application user context synchronization between the two application instances will now be a continuous process (as highlighted in the previous step).

[0204] ● To achieve the initial synchronization, a snapshot of the source application instance may need to be copied to the target EDN (EDN-B) and restored there (e.g., Docker container checkpoint of EAS ins1 and Docker container start when EDN-B hosts EAS ins2). Then, confirmation that EAS ins2 is running will be sent to EES-A via EES-B. Once confirmation that the instance is running is received, any traffic from application clients destined for EAS ins1 should be forwarded to EAS ins2 during the initial synchronization process. It is important to note that EAS ins1 does not need to be stopped or paused while synchronization with the replicated application instance is achieved.

[0205] ● If the EAS is consuming EDN specific services (example services may include UE location, which may originate from an underlying network, such as a 3GPP access network), then these services will have to be reestablished as part of the synchronization process. In some cases, when the application client interacts with EAS ins1, those services will have to be provided via the source EDN, and only switched to the provisioned target EDN once the application client switches to interacting with EAS ins2.

[0206] ● The behavior of some applications may mean that it is not appropriate to have multiple instances at the same time. In this case, the application instance in EDN-B will be synchronized to the latest available state of EAS ins1, and then EAS ins2 will start with the most recent state of EAS ins1 after the UE switches to minimize service interruption, although in this case there may be a short interruption when EAS ins2 is transitioned to the running state.

[0207] 9. EES-A notifies EEC that the UE is in the overlapping area.

[0208] 10. Notification from EES-A provides the EEC with the EAS ins2 address to facilitate seamless transition between application instances after the switch.

[0209] 11. If the UE continues to move, there will be a UE handover between the cell associated with EDN-A and the cell associated with EDN-B. This is a trigger for switching the serving EAS instance (because EAS ins2 is now considered the preferred server, e.g., it better meets the application KPI requirements). The UE will now be in an overlapping area, where EDN-A is considered to overlap with EDN-B

[0210] 12. After successful handover, the application client will communicate with EAS ins2, which has the same application user context as EAS ins1, thus achieving seamless service continuity.

[0211] • There may be explicit signaling to trigger the application client to switch to EAS ins2, such as an interaction from the EEC to the application client. The switch may be delayed until both EES-A & B have updated their traffic rules and confirmation of this has been signaled to the EEC.

[0212] ● For applications where only the application user context is synchronized but not re-run, the communication from the application client will serve as a trigger to transition the EAS ins2 to the running state based on the latest available context.

[0213] 13. Both EESs will be notified of the switch, for example by subscribing to the relevant access network notifications.

[0214] 14. EES B updates its traffic rules. This update may be signaled to EES-A to trigger EES-A to update its traffic rules.

[0215] 15. EES-A updates its traffic rules. The traffic flow generated after these two steps is Fig.17 , which will be described in more detail later.

[0216] 16. As the UE continues to move, it moves out of the area where EDN-A is considered to overlap with the coverage area of ​​EDN-B.

[0217] 17. If this happens, then EES-B notifies the EEC that it has moved out of the overlapping area, so it will no longer register with EES-A

[0218] 18. EES-B sends a signal to EES-A to cancel the registration of EEC.

[0219] 19. EES-A then deletes (deactivates) the traffic rules associated with the application client.

[0220] 20. EES-A responds to EES-B to confirm the deregistration

[0221] 21. EES-B updates its traffic rules so that traffic is no longer forwarded to EAS ins1.

[0222] After step 21 above, the UE is considered to be in the non-overlapping area and is only served by EAS ins2.

[0223] In an alternative embodiment, where multiple instances of an application are not running simultaneously, but the application user context is still synchronized, steps 5, 7, 14, and 15 will not apply. In this case, the application user context available in EDN-B remains consistent with the latest user context in EDN-A. As a result, when the application client connects to EAS ins2, the latest application state information is already available without having to obtain it from EDN-A.

[0224] Fig.16Application-level traffic is shown between an application client for a UE in an overlapping area and a serving edge application server (EAS) instance 1 (thick double-ended arrow) of an edge application, which is replicated to edge application server instance 2 (thick double-ended arrow). Application-level traffic is transmitted via the data plane (thin arrows). In edge data network A (EDN-A), edge enabling server A (EES_a) configures the data plane to route traffic between the application client and its serving EAS instance (EAS-A_instance-1) using traffic rules. The data plane is also configured to forward traffic from the application client to a replicated EAS instance (EAS-A_instance-2) hosted in EDN-B via the data plane in EDN-B (thin dashed arrows).

[0225] The prerequisites are that: the application user context associated with the application client is already available in EDN-B to ensure that EAS-A_instance-2 is synchronized with EAS-A_instance-1 before traffic is forwarded to EAS-A_instance-2; and EAS-A_instance-2 is present and running. Traffic received from EAS-A_instance-2 in EDN-A (thin dashed arrow) is not forwarded to the application client, but can be compared with traffic received from EAS-A_instance-1 to check whether the two EAS instances are synchronized. This will only occur if the data plane in EDN-B has been configured to forward traffic from EAS-A_instance-2 to EDN-A. If the edge application has a (backend) cloud component, steps will be taken to ensure that any communication with the cloud component is reflected in EAS-A_instance-2. While this replication is maintained between the two application instances, the two instances will remain synchronized so that the application user context will remain consistent between the two instances.

[0226] Fig.17An updated scenario is shown when the instance to which the application client is connected switches from EAS-A_instance-1 to EAS-A_instance-2. The trigger for this switch can be a UE handoff in the underlying transport network, with the result that EAS-A_instance-2 becomes the preferred server due to the location of the UE and the access point through which it connects to the transport network. Now, application-level traffic between the application client and the serving edge application server (EAS) instance 2 (thick double-ended arrow) of the edge application is replicated to edge application server instance 1 (thick double-ended arrow). In edge data network B (EDN-B), edge enabling server B (EES_b) configures the data plane to route traffic between the application client and its serving EAS instance (EAS-A_instance-2) using traffic rules. The data plane is also configured to forward traffic from the application client to the replicated EAS instance (EAS-A_instance-1) hosted in EDN-A via the data plane in EDN-A (thin dashed arrow). Since the application client was previously served by EAS-A_instance-1, the application user context associated with the application client will already be available in EDN-A, so EAS-A_instance-1 will already be synchronized with EAS-A_instance-2 before traffic is forwarded to it.

[0227] Traffic received from EAS-A_instance-1 in EDN-A (thin dashed arrows) is not forwarded to the application client, but can be compared to traffic received from EAS-A_instance-2 to check that the two EAS instances remain in sync. This will only occur if the data plane in EDN-A has been configured to forward traffic from EAS-A_instance-1 to EDN-B. When this replication is maintained between the two application instances, the two instances will remain in sync, and the application user context will remain consistent between the two instances.

[0228] Fig.15a and 15b The example signal flows shown in the drawings are exemplary only, and those skilled in the art will appreciate that certain modifications may be made while still falling within the scope of the present invention as defined by the appended claims.

[0229] At least some of the example embodiments described herein can be constructed using dedicated hardware in part or in whole. Terms such as "component", "module" or "unit" used herein may include but are not limited to hardware devices, such as circuits in the form of discrete or integrated components, field programmable gate arrays (FPGAs) or application specific integrated circuits (ASICs), which perform specific tasks or provide associated functions. In some embodiments, the described elements may be configured to reside on a tangible, persistent, addressable storage medium, and may be configured to execute on one or more processors. In some embodiments, these functional elements may include, for example, components, such as software components, object-oriented software components, class components and task components, processes, functions, attributes, procedures, subroutines, program code segments, drivers, firmware, microcodes, circuits, data, databases, data structures, tables, arrays and variables. Although example embodiments have been described with reference to components, modules and units discussed herein, these functional elements may be combined into fewer elements or separated into additional elements. Various combinations of optional features have been described herein, and it will be understood that the described features may be combined in any suitable combination. In particular, the features of any one example embodiment may be appropriately combined with the features of any other embodiment, unless such combination is mutually exclusive. Throughout the specification, the term "comprise" or "comprising" means including specified components but does not exclude the existence of other components.

[0230] Please note that all papers and documents related to this application that were filed concurrently with or prior to this specification are open to the public with this specification, and the contents of all these papers and documents are incorporated herein by reference.

[0231] All features disclosed in this specification (including any accompanying claims, abstract and drawings), and / or all steps of any method or process so disclosed, may be combined in any combination, except combinations in which at least some of such features and / or steps are mutually exclusive.

[0232] Unless expressly stated otherwise, each feature disclosed in this specification (including any accompanying claims, abstracts and drawings) may be replaced by alternative features serving the same, equivalent or similar purpose. Therefore, unless expressly stated otherwise, each feature disclosed is merely an example of a series of equivalent or similar features.

[0233] The invention is not limited to the details of the foregoing embodiments. The invention extends to any novel one or any novel combination of the features disclosed in this specification (including any accompanying claims, abstract and drawings), or to any novel one or any novel combination of the steps of any method or process disclosed in this specification (including any accompanying claims, abstract and drawings).

Claims

1. A method for providing services in a multi-access edge computing MEC network, comprising: An edge application server EAS in the MEC network identifies an application context; determining, by the EAS, another EAS based on an expected UE location; replicating, by the EAS, the application context between the EAS and the another EAS to support service continuity; as well as The application context is sent by the EAS to the other EAS.

2. The method according to claim 1, further comprising: An application providing services to one or more subscribers is provided by the EAS in the MEC network; wherein the particular subscriber remains in a registered state until one or more of the following conditions apply: a configurable time period has elapsed; the particular subscriber is no longer registered with the service; or the particular subscriber becomes an active subscriber, and Wherein the configurable time period is determined based on a behavior pattern of the one or more subscribers.

3. The method according to claim 1, wherein: In the event that the instance of the EAS has no active or registered subscribers, the instance of the EAS is deleted. The method of claim 1 , wherein the instance of the another EAS is determined based on a prediction of a subscriber's behavior.

5. An edge application server EAS in a multi-access edge computing MEC network, comprising: The processor is configured as: Identify the application context; determining another EAS based on the expected UE location; replicating the application context between the EAS and the another EAS to support service continuity; as well as The application context is sent to the other EAS.

6. The EAS of claim 5, wherein: The processor is further configured to: providing an application that provides services to one or more subscribers; wherein the particular subscriber remains in a registered state until one or more of the following conditions apply: a configurable time period has elapsed; the particular subscriber is no longer registered with the service; or the particular subscriber becomes an active subscriber, and Wherein the configurable time period is determined based on a behavior pattern of the one or more subscribers.

7. The EAS of claim 5, wherein: In the event that the instance of the EAS has no active or registered subscribers, the instance of the EAS is deleted.

8. The EAS of claim 5, wherein the instance of the another EAS is determined based on a prediction of a subscriber's behavior.

Images