GB2591474A - Improvements in and relating to MicroServices for MEC networks - Google Patents

Abstract

A method to provide a service in a Multi-access Edge Computing (MEC) network. A pod is provided in an edge cloud node, the pod comprising a software container for providing an application that offers a service to subscribers. The pod has an associated status related to an active subscriber, A, or to a previously active registered subscriber, R. Whilst the pod has one registered subscriber the pod is maintained in the cloud edge node. If the pod has no active or registered subscribers, it may be deleted after a configurable time period elapses. A user context associated with an active subscriber may be made available to other pods on the basis of a prediction of the subscriber’s behaviour, such as their speed or direction of travel. Use of an ambassador pattern to replicate data between edge clusters means that a subscriber’s user context is continually updated to all Persistent Volume Claims (PVC). This results in a seamless service migration since when a user equipment is switched from one edge cloud node to another no user context update is required and access to the service can continue uninterrupted. A pod may be defined as a service provider in Kubernetes terminology.

Description

Improvements in and relating to MicroServices For MEC Networks The present invention relates to a Multi-access Edge Computing (MEC) network, which is a network where certain services or functions are provided at the network's edge i.e. in the vicinity of a user, or local to the client's infrastructure, rather than in a centralised (or even dispersed) cloud.

This form of network architecture allows cloud computing capabilities and IT service environments to operate on the edge of a mobile network. This architecture has a number of significant advantages, such as allowing services to be provided to the end user with substantially reduced latency. However, two aspects of this technology are problematic to the Network Operator. The first is Capital Expenditure (CAPEX), which can be substantial for even a basic system with no clear use case for return on investment. The second is latency in migrating a service from one edge network to another for a subscriber who is mobile. Any resulting service interruption diminishes the advantages of deploying services at the edge of the network.

One seemingly obvious solution to this is to deploy all services to all edge networks for all subscribers, even if they are not using that service, or never registered on an edge network that has the service installed. This means that the mobile operator has to dimension their MEC for all services and all subscribers for every MEC in their network. This is prohibitively expensive in practice and so does not represent a realistic solution.

Furthermore, the idea of migrating services and contexts (the user/subscriber specific instantaneous state of the service, or application, i.e. all the information required in order to re-establish the service or application in a new location in exactly the same situation as the previous location) across roamed networks has the same issues. There would likely be resistance from a first mobile operator (A) allowing a second mobile operator (B) to deploy all services on their MEC for the chance that subscribers from A may roam and use that service on network B. Embodiments of the present invention aim to address shortcomings in the prior art, whether mentioned herein or not.

According to the present invention there is provided an apparatus and method as set forth in the appended claims. Other features of the invention will be apparent from the dependent claims, and the description which follows.

According to a first aspect of the present invention, there is provided a method of providing a service in a Multi-access Edge Computing, MEC, network, comprising the steps of: providing a pod in an edge cloud node, wherein the pod comprises a software container for providing an application that offers a service to one or more subscribers; associating with the pod a status related to an active or registered subscriber, wherein an active subscriber is currently interacting with the pod and a registered subscriber is not currently interacting with the pod, but has interacted previously; wherein, provided that the pod has at least one registered subscriber, the pod is maintained in the edge cloud node.

In an embodiment, a particular subscriber is held 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.

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

In an embodiment, the pod is deleted only after the configurable time period has elapsed.

In an embodiment, the configurable time period is determined on the basis of behaviour patterns of one or more subscribers.

In an embodiment, a user context associated with an active subscriber at the pod is made available to one or more other pods In an embodiment, the user context is made available by means of an ambassador pattern operable to replicate data between the pod and the one or more other pods. The one or more other pods may exist in the same edge cloud node as the original pod or may exist in one or more other edge cloud nodes.

In an embodiment, determining the one or more other pods is performed on the basis of a prediction of the subscriber's behaviour.

In an embodiment, the prediction is based upon one or more of: the subscriber's previous movements; and the subscriber's current position and/or speed and/or direction of travel.

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.

In an embodiment, the system comprises at least one pod associated with at least one registered or active subscriber.

In an embodiment, there is further provided a cluster network manager operable to manage services available on particular pods.

Embodiments of the invention adopt a novel use of the ambassador pattern (one of the standard design patterns for cloud compute systems) to replicate data between edge clusters to achieve consistent persisted context, which means that a subscriber's user context is continually updated to all Persistent Volume Claims PVCs. The result is seamless service migration since, when a UE is switched from one edge cloud node to another, no user context update is required, because it is already replicated at the target node. This means that the UE's access to the service can continue uninterrupted.

In order to ensure that services are available at the required edge network locations, embodiments of the invention introduce the concept of a 'static' Pod (where the Pod is the service provider in Kubernetes terminology). Such a Pod has the ability to remain in an edge network even after all registered users are no longer active and is therefore protected from termination.

In order to manage the availability of the distributed Pods embodiments of the invention introduce a centralised Cluster Network Manager (CNM). In the ETSI MEC architecture, such an entity may be collocated with the MEC Orchestrator (termed MEC Application Orchestrator in a Network Function Virtualisation deployment).

Embodiments of the invention provide a way for a network to deploy services in the form of software containers to MEC networks that a user normally registers on (e.g. the common Monday to Friday cells a user registers on 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 a MEC will only ever be for the typical users that camp on those cell sites within that MEC.

Embodiments of the invention will reduce, possibly significantly, the required CAPEX for typical MEC deployments. Furthermore, they will remove latency in service migration in a solution where services are migrated, or a solution where services only follow the user and require constant deletion and creation across MEC networks.

Although a few preferred embodiments of the present invention have been shown and described, it will be appreciated by those skilled in the art that various changes and modifications might be made without departing from the scope of the invention, as defined in the appended claims.

For a better understanding of the invention, and to show how embodiments of the same may be carried into effect, reference will now be made, by way of example only, to the accompanying diagrammatic drawings in which: Figure 1 shows a representation of typical users in terms of radio cell nodes visited; Figure 2 shows a typical prior art cloud-based system architecture; Figure 3 shows an architecture according to an embodiment of the present invention comprising static pods, Figure 4 shows a cluster deployment according to an embodiment of the present invention; Figure 5 shows a cluster network manager according to an embodiment of the present invention; Figure 6 shows an ambassador pattern in a system according to an embodiment of the present invention Figure 7 shows a typical MEC system reference architecture according to the prior art; Figure 8 shows a message flow illustrating monitored event notification according to an embodiment of the present invention; Figure 9 shows a message flow illustrating the instantiation of an application according to an embodiment of the present invention; Figure 10 shows a message flow illustrating the MEP making a request to the ME0 to instantiate an application according to an embodiment of the present invention; and Figure 11 shows a message flow illustrating notification by the MEO of changes in application instance location(s)/address(es) according to an embodiment of the present invention.

Embodiments of the invention provide a way to optimize cloud compute infrastructure on a MEC network, such that it only has deployed service containers and user context for the users that typically migrate to and use (or have used) that particular edge network.

The following description uses terms commonly used in cloud compute environments -specifically from the Kubernetes systems -but is equally applicable to any cloud based system. Cloud based networks typically describe how a network can automatically manage, connectivity, containerized workloads, lifecycle management and services, that facilitates both declarative configuration and automation. This means that an application developer does not have to think about, or build into their system: Network resilience; Deployment; Load balancing; Dimensioning of a system (i.e. the system horizontally scales); and Administration & Logging (health checks and aliveness reporting).

In this way the system is responsible for the application state, responsiveness and scalability.

It makes sure that 'workers' are spawned, instantiated and provide service for the end user.

The whole life cycle management is performed by the cloud compute infrastructure. In the example case presented herein, 'Kubernetes' is used as an example, but the skilled person will recognise that other systems or solutions are equally applicable. It uses a container system to spawn and manage deployed services to its compute cluster of nodes. It provides, as mentioned, scalability (i.e. bringing up workers and load balancing when needed), back-end services to scale databases and persistence, IP mapping of services to allow dynamic routing, administration and logging.

Embodiments of the invention reduce the typical required footprint of a MEC deployment and improve the way services are added and removed dynamically to a deployed MEC network.

The typical solution for MEC networks is to deploy 'containers' (lightweight deployable software packages which contain an Operating System (OS) and software required to run a service) that can support all subscribers on that network, even if no subscriber actually uses that service, or if a user no longer uses the service on that edge network.

The cost of infrastructure on the edge is expensive. It should be capable of spawning services for users that exist on that mobile network. Spawning a service on an edge network is not instantaneous or real time compared to typical telecom services that are built into the Core Network (CN). This means that to reduce a time to activate a service, a network could, in theory, deploy all services for all users on all edge networks. This would mean that all edge points have to be able to support all services for all users at all times. This would lead to a large increase in the CAPEX of a deployed edge network.

Further, migrating services when needed, as users migrate from one edge network to another, increases delay/latency, network traffic and degrades the user experience. This can be illustrated by considering a game edge service where moving from one cell location to another causes the game to hang due to latency.

Embodiments of the invention provide a way to address and alleviate these and other issues, i.e. to remove delay in migrating user services from one edge point to another and reduce CAPEX required for a MEC network that can support all users for all services on a mobile network.

The smallest development container using Ubuntu as the container host OS is approx. 100 MB before a service is deployed.

For a production system, a service can be deployed on 'Alpine Linux' containers which are around 5-10 MB before any service is deployed.

As will be appreciated, this would substantially impact a MEC network if containers are continually being deployed and removed due to subscriber movements. An alternative consideration would be the impact of a MEC network having services never being used but consuming compute resources.

There are situations where a user will move between the same cell sites on a day-to-day basis, with changes to such use patterns happening infrequently. For example, a person who is in the same job will likely move between the same cell sites from Monday to Friday. The cell sites are termed NodeB, eNodeB, or gNodeB in a 3G, 4G and 5G networks respectively, but are all simply referred to as NB in the context of this application. Figure 1 shows the typical path taken by two users -User A and User B. When utilising services offered by the mobile network (e.g. internet connectivity), User A will attach to NB-3, NB-1 and NB-5 over the course of each day based on their typical behaviour.

Likewise, User B will typically attach with only NB-4, NB-1 and NB-6 over the course of a day. VVhen such users utilise centralised cloud services via the core network, the fact that they attach to the mobile network through different (relatively closely spaced) NBs has little impact on ideal physical location of the serving cloud servers. However, in a MEC deployment where the "cloud like" services are offered through localised edge data networks (that may only be associated with a limited number of NBs) the physical location of the server, and what services are offered by each server, can become critical.

For instance, if there is an edge data network associated with each NB, then when a user is attached to a particular NB, it is likely the associated edge data network will be the most appropriate to serve that user. In support of that, embodiments of this invention address the problem of ensuring the required services are available at each edge point as they are required, without the need to deploy all services at all edge points, thereby addressing CAPEX and latency issues.

In the context of this application, the deployment and management of services is herein termed Enhanced Mobility for MicroServices. The term MicroServices is used since applications providing services deployed in a cloud based system typically adopt a microservice based design pattern. With this approach applications are offered as a collection of loosely coupled microservices, rather than as a single monolithic application. Each microservice is likely to have a narrower scope focused on a particular task. Such microservices then communicate between one another in order to provide an overall service, such as the Netflix or BBC I-Player application service. A container may then be used to package, deploy and run the application.

Initially, with this Enhanced Mobility For MicroServices approach, according to embodiments of the invention, services are deployed as a user moves from one edge network to another. This may be performed in a pre-emptive manner, if it is determined that a user is likely to move into the service area of new edge network. This involves building up a picture of the utilisation of services based on a user's typical behaviour. This is in order to make future service deployment decisions and suitable retention time periods for those deployments. This is defined herein as the 'configuration time period'.

For instance, based on a user's daily routine, if they typically utilise the Netflix service between the hours of 7pm and 11pm whilst attached to NB-3 the system will ensure (as far as possible, given other resource constraints) that the Netflix service is available in a time period that overlaps with that time in the edge network that has an association with that NB.

Given the picture built up for each service over time (which may include user granularity, i.e. specific user utilisation of a service), Enhanced Mobility For MicroServices according to an embodiment will retain a particular service at an edge point even if users are not actively using it. If a user has been active on that edge point within the 'configuration time period' the service is kept active within the edge data network that has the association to the particular NB. If the configuration time period' has expired, the service is removed from the cluster, freeing up resources for other services.

B

With specific user knowledge (i.e. the predicted times at which a particular user may use a service in a particular location), the Enhanced Mobility For MicroServices approach according to an embodiment of the invention ensures availability of the context associated with the use of the particular service at edge point(s) that it is anticipated a user may connect to (via attachment to the NB that is associated with the edge data network). Such user context may be associated with an on-going service (e.g. mid-game play), or that associated with resuming service (e.g. resuming a game at a particular point, level, score, media content, etc.). To achieve this, embodiments employ a novel use of the cloud computing "ambassador" design pattern for container-based distributed systems to replicate data between edge clusters.

Embodiments of the invention employ two major components: the first relates to the management of the physical deployment of pods with service containers (a software bundle containing the OS and all software libraries required to run the service); and the second relates to how a user context is managed for containers that are already active.

The Enhanced Mobility for MicroServices system according to an embodiment introduces a 'pod' classification, where a 'pod' is defined in Kubernetes terminology as a collection of related tightly-coupled containers providing a single function or service. In the context of embodiments of the invention, a 'pod' is classified as 'static' when it has the ability to remain in an edge network after all registered users are no longer using the pod and is therefore protected from termination. Pods are classified as 'legacy' if they do not support the Enhanced Mobility for MicroServices capability. With prior art container orchestration approaches, pods remain by default consuming resources until explicitly terminated without considering the registration state of users. If 'pods' were to migrate with users, which is also possible, it also has a drawback, that there is a lag in re-establishing the pod should a user wish to use the pod provided service once again. This lag would be even more problematic for a user using a service in one cloud node that moves to another and wishes to use the service there. Such a situation arises in particular with the introduction of edge computing, where the cloud nodes are physically separated (edge cloud nodes) and it is desirable for users to connect to the edge cloud node geographically closest to them.

A typical cloud based system, based on Kubernetes techniques, has an architecture comparable to that shown in Figure 2. In such a system, a 'pod' containing a software container will be maintained throughout its lifetime. The cloud compute platform (Edge Cloud Node) provides dynamic routing between pods, via the Virtual Ethernet adapters (Virtual Ether 01 & 02) and the bridge (Bridge 0). It is also able scale a service, when needed, via replication.

In the enhanced mobility system, according to an embodiment of the invention, pods that are labelled as 'Static' are given the capability to remain on the edge cloud node. In Figure 3, the static Pod 1 has metadata marked as 'static' and has registered subscribers and active subscribers. Throughout the figures in this application registered subscribers are indicated by an R in a circle (0) and active subscribers are indicated by an A in a circle (C)).

Here, active subscriber denotes a subscriber who is registered on this MEC node for the particular service in question and is currently interacting with the service with associated information exchanges. Registered subscriber denotes a subscriber who is registered on this MEC node for the particular service in question (if that is applicable for that service) and at a point in the past was in an active state. Users are held in a 'registered' state until one of: A) The 'Configurable time period' has elapsed B) They are physically de-registered for that service (e.g. no longer a Netflix customer for the Netflix Service) C) The subscriber hands over to a NB associated with the edge cloud node and transitions to 'active' state by interacting with the service.

They system may select users for pre-emptive removal in order to free up edge cloud node resources, e.g. to allow other pods to be created.

When there are no registered or active subscribers on a static pod, it is removed from the 20 node.

Figure 3 shows 2 pods. In pod 1 there is a registered subscriber and an active subscriber. In pod 2 there is an active subscriber. Should the active subscriber in Pod 2 move to a different cell site with a different edge network, the subscriber status would change to 'Registered'.

Maintaining records of when a subscriber enters and registers on a cell allows the pod to be managed efficiently. Once a pod only has 'registered' subscribers it will be removed from the cluster once the 'Configurable time period' has elapsed.

Each pod is given a time-to-live' based on a configuration period hmeout defined previously.

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 administration system (that will maintain the appropriate configuration period timeout for each pod) in the same way as the health, and aliveness checks commonly used in such a system. Hence, for a typical service, there are REST endpoints for health, aliveness, and time-to-live. The time-to-live period will always be taken from the point of the last user to switch their status to 'registered'.

The architecture of the enhanced mobility functionality deployed on an edge network corresponds exactly to the typical cloud-based system architecture of Figure 2, with the inclusion of the static pod concept shown in Figure 3.

Figure 4 shows an expanded deployment according to an embodiment of the invention in which a cluster of edge cloud nodes (Edge Cloud Nodes 1 and 2) is deployed for cell site NB-3, for the scenario first presented in Figure 1. Associated with the cell site NB-3 is a deployed edge network consisting of 2 edge cloud nodes that support 4 pods in total. Of the 4 pods, 3 pods are static (pods 1 -3) and one pod (pod 4) is a legacy 'pod', for which enhanced mobility functionality according to an embodiment of the invention does not apply. The cell site is shown with active and registered subscribers, based on the subscribers' status within the edge network. Within the edge network, Pods 1, 2 and 4 will be removed if the active user moves from the cell site and the local configuration time period has expired on each of those assets.

According to prior art procedures, dynamic routing is performed within the 'Cluster Network' logical block. Hence, any service mapped to a URL is routed to the correct Pod. If Pod 1 takes heavy traffic and the aliveness endpoint fails, Kubemetes will instantiate another pod replicating the pod and will automatically load balance between those pods.

A new element according to an embodiment of this invention is a Cluster Network Manager (CNM). To understand this, consider the case where there are two cell sites (NB-3 and NB-1, which were first shown in Figure 1).

In this scenario each cell site has a deployed edge network that contains a number of Kubernetes nodes and pods. This is shown in more detail in Figure 5. Nodes NB-3 and NB-1 take care of the deletion of pods simply using the metric for active subscribers and time-to-live of the pod. However a decision is required on what services to deploy for what subscriber within each MEC cluster network.

Notification of a subscriber happens via the Core Network (CN) or an app on the handset of the user. At this point a request is made to the CNM, shown in Figure 5. The CNM is responsible for all MEC cluster networks across the mobile network.

For example, when 'User A' wishes to use, for instance, 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 instance, 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 exist. The CNM knows what services are registered for which subscriber.

In the prior art ETSI MEC architecture the MEC Orchestrator (MEC), or MEC Application Orchestrator (MEAO) in a Network Function Virtualisation (NFV) based deployment, is responsible for service instantiation. However, requests for service instantiation are only made via the Operations Support System (OSS) and therefore the MEO wouldn't currently be aware of what services are registered for which subscriber. Therefore enhancements to the prior art ME0 are required in order for it to be able to fulfil the role of the CNM, according to an embodiment of the invention.

When a third party provides a service, it registers itself with the CNM providing a UserlD, MSISDN number, or another unique identity agreed by 3rd parties and the Mobile Operator. The CNM then manages deployment and lifecycle of services on the network.

Should 'User A' move back to NB-3 before the configuration period timeout has expired the BBC I-Player pod will still be available and that user will have access to all the edge services that this pod provides with minimal lag and therefore minimal service interruption Typically, in prior art systems, cluster routing is managed by the 'Cluster Network' shown in Figure 5. This routes packets to services and between services managing the Virtual IF (VIP) address between the edge cloud (Kubernetes) nodes within the cluster.

In the Enhanced Mobility For MicroServices setup, according to an embodiment of the invention, a cluster may be deployed to a single edge. Routing to the active servers does not change, as packets between the User Equipment (UE) and service still flow directly between the active edge node and the device.

Once a UE attaches to a node (NB) the pod application in the associated edge cloud node makes a PersistentVolumeClaims (PVC), which is the Kubernetes mechanism to request for block storage by a user. For example, in Figure 5, the UE attaches to NB-1, which will trigger pod 1 to update its state, i.e. active and registered users, plus the associated user context.

Through PVCs, data is dynamically persisted to a block storage device for all replicated containers on a Node for a legacy Kubernetes system, but not for a PVC on a different edge network (with its own cluster).

To achieve a consistent persisted context, the service in an Enhanced Mobility For MicroServic,e makes novel use of the cloud system ambassador design pattern to replicate data between edge clusters. This means that when the UE migrates to one 'static edge node from another 'static' edge node, no user context update is required. This is because the user context is continually updated to all PVC's for that subscriber. This is described in more detail below, which relates to typical design patterns for cloud compute systems.

There are three primary design patterns for container-based distributed systems. These represent some of the most common use cases for packaging containers together in a pod. Briefly, they are: 1. Sidecar: In this pattern, the secondary container extends and enhances the primary container's core functionality. This pattern involves executing non-standard or utility functions in a separate container. For example, a container that forwards logs or watches for updated configuration values can augment the functionality of a pod without significantly changing its primary focus.

2. Ambassador The ambassador pattern uses a supplemental container to abstract remote resources for the main container. The primary container connects directly to the ambassador container which in turn connects to and abstracts pools of potentially complex external resources, like a distributed Redis (https://redisiof) cluster. The primary container does not have to know about the actual deployment environment to connect to external services.

3. Adapter: The adapter pattern is used to translate the primary container's data, protocols, or interfaces to align with the standards expected by outside parties. Adapter containers enable uniform access to centralized services even when the applications they serve may only natively support incompatible interfaces.

The Enhanced Mobility For MicroServices, according to an embodiment of the invention, implements an 'Ambassador pattern which is used to synchronise context to other replicated services which are not be part of the same Cluster network (i.e. another edge cloud node or roamed edge network). This is shown in Figure 6, where the following steps (labelled 1, 2, 3) apply.

Step 1: User A, who is active, updates their context (i.e. interacts with the service) and data flows to the Netflix 'Pod' via the cluster network for NB-1. The Netflix pod located in Edge Cloud Node 2 of cluster network NB-1 is shown with an active user.

Step 2: The application for Enhanced Mobility is able to make use of the ambassador pattern to check with the CNM as to what other cluster networks have a Netflix service for that user (to determine whether the context needs to be synchronised with other pods). Alternatively the application using the ambassador pattern will be instructed by the CNM that context sync is to be performed. This may be when the pod is deployed and may also be changed throughout the pod's lifetime. The context update is replicated to the CNM.

Step 3: The CNM identifies any other cluster networks with the Netflix service which is 'static' and has that user 'registered', or predicted to be 'active' in the future (for instance based on historical data, or the use(s current direction and speed). The CNM then routes the message (i.e. that containing the required context updates, either a delta on the existing context, or a full replacement) to those cluster networks for that edge network. Therefore messages are automatically routed to the Netflix 'Pod' running on Edge Cloud Node 1, Pod 1, where the user is shown as 'registered'.

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

Step 2 and step 3 do not necessarily need to be repeated each time a user context is updated, as long as the pods offering the Netflix service in the other cluster networks are maintained in 'static state whilst a user's context is being transferred there. This can be achieved by setting the subscriber's state to 'registered' at those other cluster networks in response to a subscriber's user context being copied there and also by not applying the 'configurable time period' to the associated pod during the copying period.

The message flow set out above does not have to occur in real time. Since the handover is not instantaneous between NBs as long as the service is persisted via a 'Pod' or directly to the PVC for that edge network. The user context is always in sync for the edge cloud nodes running the user's service.

In the description so far, reference has been made to a generic form of network. The description which follows relates more specifically to ETSI MEC and provides more details of that specific configuration. It is not intended to be limiting but, rather, to offer a specific embodiment, described in terms related to the ETSI MEC configuration.

Embodiments of the invention provide a means to instantiate service-providing application servers at particular locations (on MEC hosts) based on predicted user behaviour in order to minimize the time taken to bring such services into operation. With this approach, application servers are then able to be removed in a controlled manner. This is because if a user has previously interacted with the service, it is desirable that the current user specific context is made available immediately when the user reconnects to the application server in order to avoid service interruption. This is regardless of whether the service is then offered through the original application server, or by an alternate application server if the user has moved location.

In the ETSI MEC system architecture, illustrated in Figure 7, the centralized MEC Orchestrator (MEO) is the entity responsible for making requests for application server instantiation 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 of the Cluster Network Manager (CNM) functionality described previously.

In the ETSI MEC system architecture, the MEC Platform (MEP) offers access to edge services and may collect service-related usage statistics through monitoring functionality. The MEP, along with the supporting virtualization infrastructure, is contained within the MEC host. The overall MEC system may consist of many MEC hosts, which are geographically distributed in order to provide services close to the end user. Therefore the MEC host is considered analogous to the distributed edge cloud node described previously.

In order to support prediction of user behaviour, embodiments of the invention support a mechanism to share the MEP collected service utilization (e.g. service API statistics) with the centralized MEO, since in the present EIS! MEC specifications there is no mechanism through which the MEO can be made aware of what services users are utilizing and through which application servers. This mechanism may be subscription-based and allows the MEO to be notified when a particular service is being actively used, potentially with user level granularity. This is shown in Figure 8.

With reference to Figure 8, a notification channel may be established directly from the MEP to MEO (rather than having to pass via the MEPM). The subscription could be established when the MEO originally makes the application instantiation request to the MEPM (see Figure 9), or there may be a separate request. Individual user identity may be anonymized using a "tag" to represent a user, which is a concept already provided by ETSI MEC. The MEO then possesses the necessary information to develop a statistical system-wide model in order to predict when a service is likely to be required at a particular location. The prediction may be used to make user specific decisions regarding application instantiation, ensuring consistent persisted application user context through the use of the ambassador design pattern to replicate data between edge clusters.

If user specific information cannot be made available, then application server usage information is still relevant in making application instantiation decisions. However, it would then not be possible for the MEO to directly trigger the process by which user specific contexts are made available as part of the instantiation process. Therefore there would likely be a delay in re-establishing the service for a particular user whilst their user specific state was made available at the application server.

If user specific information can be made available, that information may also be used to influence whether the MEO instantiates application instances at other locations. For example, if predictions indicate that a user is likely to connect to a particular NB at a certain time but it is already connected elsewhere then the MEO may not instantiate the instance at the predicted location at that time.

In an alternative embodiment, the MEP may develop its own distributed application server utilization model, which may be user specific. Such models may be developed per MEP in isolation. However, there may be advantages in supporting a communication channel between MEPs to share application server instance information and potentially user specific utilization of those instances between one another. ETSI MEC has defined the Mp3 reference point between MEPs, but information exchanges and APIs are not currently specified for that reference point. By use of such a channel, information may be shared system wide without necessarily involving the MEO, although with the current architecture, the MEO would have to be requested to instantiate an application server (such a request is not currently specified), as set out in Figure 10. The MEO is best placed to share with each MEP on which other MEC host's application server, instances of interest are located, since the application instance instantiation requests originate from the MEO. Therefore, in embodiments of the invention, the MEC is able to share the location and/or address of all other relevant application instances on other hosts with a particular MEP when making each application instantiation request (see Figure 7).

Further, updated information is provided through a notification mechanism should there be changes in application instance location(s)/address(es), as shown in Figure 11, which shows where, alternatively, notifications may be sent directly from the MEO to a MEP, rather than via the MEPM. Within the existing MEC specifications, the application instantiation request message sent from the OSS to the MEO provides the location constraints for application server placement, but it is only the MEO that is aware of all the instantiated application serve instance locations. Therefore the existing mechanism is insufficient. With an embodiment of the invention, by providing relevant application instance information on other hosts, each MEP then knows with which other MEPs to share relevant monitoring related information, e.g. that a certain user has connected to certain application instance and where to copy user context information to. Alternatively each MEP could query the MEO for the address/location of other relevant application instances.

The monitoring information collected by the MEP and passed to the MEO, and/or other MEPs, may have wider scope than just service utilization. For instance, it may include typical API logging information such as number of API calls, methods invoked, success rate of such requests, request response times. Such information could also feed into the MEO's application instantiation decision making process, since if a certain host is considered to be offering poor performance the MEO may decide not to instantiate on that host and rather steer users towards an alternative host.

Within ETSI MEC, an Application Mobility Service (AMS) has been specified. This enables service consumers, e.g. application instances, 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 an application instance that user context transfer is required and with that the target address the application instance should send the context to. The application instance is expected to inform the AMS about connected users (client applications), e.g. new connections to the application instance, and the status of application context transfers, e.g. when a transfer has been successfully completed. This enables the AMS to monitor relevant user specific events, such as those relating to handover. In support of application mobility the application descriptor (containing the necessary information to instantiate an application instance) has been enhanced to provide indication that the application supports user context transfer capability.

The current AMS is reactive in that user context transfer is only initiated after the user (UE) has handed over from a NB associated with the source application instance to a NB associated with the target application instance. Embodiments of the present invention deal with enabling pre-emptive measures to avoid service interruption, which involves using the ambassador application to offer an enhanced AMS and CNM capabilities at the MEO.

As an initial step, the application descriptor is enhanced to include an attribute to indicate that the described application supports 'user context copy capability'. This implies that associated application instances have means to copy a user context, and any subsequent updates to that context (either as a complete copy, or just the deltas), to a given location, e.g. a storage location at a potential target MEC host. This is via the proposed ambassador application. Also, an application instance of such an application is able to utilise that user specific context at the target application instance should the user switch to that instance and in that way continue their session without interruption, e.g. continue watching their Netflix movie. The consequence is that an instance of such an application is able to utilise the stored user context should the user disconnect from the application instance and then reconnect at a later time. This facilitates a quick transition from 'registered' to 'active' state described earlier, since the user context relevant for the 'active' state would be readily available.

The method used to indicate which application instance locations the source application instance should copy, and then subsequently update, the user context to was described earlier, i.e. by including information on other relevant application instances as part of the application instantiation process, which means that information is available at the MEC host. In the context of embodiments of this invention, this implies that the CNM makes that information available to the ambassador application associated with the application instance.

In an alternative embodiment, the ambassador application could query the CNM to provide that for a user when they connect. It is also possible that a subset of relevant application instances could be selected for a particular user based on user specific characteristics, e.g. based on a model of historical behaviour, or based on current behaviour such as the user's current speed and direction of travel. Since such information is dynamic in nature, the ambassador application is a suitable way of maintaining and providing up to date information on where to copy user context.

The steps associated with the use of the proposed enhanced AMS are: 1. Application instance, associated with a stateful application, registers with the enhanced AMS at the current edge host.

2. If the application instance provides indication that it supports 'user context copy capability', the AMS provides default list of locations (relating to other instances of the application at different hosts) that user contexts should be copied to. The list will be used by the ambassador algorithm associated with the application instance.

3. Application instance notifies AMS that a user application client is communicating with it. The subscriber will now be considered in 'active' state, as in Step 1 described previously. If there is an available user context for that subscriber, that will be utilised for the session with the client application. The location of the stored context may already been known to the application instance for a subscriber that was in 'registered' in state, otherwise the AMS can provide that. The application instance may also notify any backend component, e.g. a cloud component to the overall application.

4. If requested the AMS will provide the storage location of user context to the application instance, if it is available. The AMS may also provide a user specific list of locations associated with application instances that user contexts should be copied to (the overall list is maintained by the CNM, at the MED), linked to Step 2 described above. The list overwrites the default list of (2.) above.

5. The application instance, e.g. utilising the ambassador application described earlier, then copies the current context and any subsequent updates to the provided locations, linked to Step 3 described above. Locations may include those associated with application instances to which the user application client previously connected with.

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

At least some of the example embodiments described herein may be constructed, partially or wholly, using dedicated special-purpose hardware. Terms such as 'component, 'module' or 'unit' used herein may include, but are not limited to, a hardware device, such as circuitry in the form of discrete or integrated components, a Field Programmable Gate Array (FPGA) or Application Specific Integrated Circuit (ASIC), which performs certain tasks or provides the associated functionality. 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. These functional elements may in some embodiments include, by way of example, components, such as software components, object-oriented software components, class components and task components, processes, functions, attributes, procedures, subroutines, segments of program code, drivers, firmware, microcode, circuitry, data, databases, data structures, tables, arrays, and variables. Although the example embodiments have been described with reference to the components, modules and units discussed herein, such 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 appreciated that described features may be combined in any suitable combination. In particular, the features of any one example embodiment may be combined with features of any other embodiment, as appropriate, except where such combinations are mutually exclusive. Throughout this specification, the term "comprising" or "comprises" means including the component(s) specified but not to the exclusion of the presence of others.

Attention is directed to all papers and documents which are filed concurrently with or previous to this specification in connection with this application and which are open to public inspection with this specification, and the contents of all such papers and documents are incorporated herein by reference.

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

Each feature disclosed in this specification (including any accompanying claims, abstract and drawings) may be replaced by alternative features serving the same, equivalent or similar purpose, unless expressly stated otherwise. Thus, unless expressly stated otherwise, each feature disclosed is one example only of a generic series of equivalent or similar features.

The invention is not restricted to the details of the foregoing embodiment(s). 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 so disclosed.

Claims (12)

1. CLAIMS1. A method of providing a service in a Multi-access Edge Computing, MEC, network, comprising the steps of: providing a pod in an edge cloud node, wherein the pod comprises a software container for providing an application that offers a service to one or more subscribers, associating with the pod a status related to an active or registered subscriber, wherein an active subscriber is currently interacting with the pod and a registered subscriber is not currently interacting with the pod, but has interacted previously; wherein, provided that the pod has at least one registered subscriber, the pod is maintained in the edge cloud node.
2. 2. The method of claim 1 wherein a particular subscriber is held 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.
3. 3. The method of claim 2 wherein if the pod has no active or registered subscribers, the pod is deleted.
4. 4. The method of claim 3 wherein the pod is deleted only after the configurable time period has elapsed.
5. 5. The method of any of claims 2 to 4 wherein the configurable time period is determined on the basis of behaviour patterns of one or more subscribers.
6. 6. The method of any preceding claim wherein a user context associated with an active subscriber at the pod is made available to one or more other pods.
7. 7. The method of claim 6 wherein the user context is made available by means of an ambassador pattern operable to replicate data between the pod and the one or more other 35 pods.
8. 8. The method of claim 6 or 7 wherein determining the one or more other pods is performed on the basis of a prediction of the subscriber's behaviour.
9. 9. The method of claim 8 wherein the prediction is based upon one or more of: the subscriber's previous movements; and the subscriber's current position and/or speed and/or direction of travel.
10. 10. A system comprising an edge cloud node and a plurality of pods operable to perform the method of any of claims Ito 9.
11. 11 The system of claim 10 wherein the system comprises at least one pod associated with at least one registered or active subscriber.
12. 12. The system of claim 10 or 11 comprising a cluster network manager operable to manage services available on particular pods.