MECHANISM FOR CONTROLLING SERVICE MIGRATION

DESCRIPTION

BACKGROUND

Field

The present disclosure relates to a mechanism allowing to control service migration in a communication network. In particular, the disclosure relates to a mechanism allowing to control service migration in mobile edge computing environment, and more particularly to a service migration server implementation for edge computing.

Examples of embodiments relate to apparatuses, methods and computer program products relating to assisting and deciding on service migration.

Background Art

The following description of background art may include insights, discoveries, understandings or disclosures, or associations, together with disclosures not known to the relevant prior art, to at least some examples of embodiments of the present disclosure but provided by the disclosure. Some of such contributions of the disclosure may be specifically pointed out below, whereas other of such contributions of the disclosure will be apparent from the related context.

Live service migration is an active area of research [Mach, Ono]. The two techniques for moving context of virtual machines, i.e. memory state, from a source to a destination are pre-copy memory migration and post-copy memory migration. Pre-copy memory migration contains two phases: warm up phase and stop-and-copy phase. Pre-copy phase starts with an iterative or incremental push of memory pages of the application while the service is still running at the source. The warm up phase continues until either the remaining size of dirty memory pages is small enough to be transmitted in less than a given target interval tolerable to service. The stop-and-copy phase starts thereafter and leads to down time of the service for the duration of copying the remaining and frozen memory pages.

In Post-copy alternative the migration is initiated by suspending the application at the source leading to service down time which is typically considerable larger than the pre-copy approach. However, as can be observed this depends on the service and the size of its context. Often a service consists of multiple virtual machines (VMs) that need to be migrated which causes a dependency in the order in which VMs are to be migrated.

References

[Mach] Machen A., Wang S., Leung K., Jun Ko B., Salonidis T., Live service migration in mobile edge clouds, Issue 1, Volume 25, IEEE Wireless Communications, 03 August 2017.

[Ono] Onoue K., Imai S., Matsuoka N., Scheduling of Parallel Migration for Multiple Virtual Machines, IEEE 31st International Conference on Advanced Information Networking and Applications, 2017.

The following meanings for the abbreviations used in this specification apply:

3GPP 3 ^rd Generation Partnership Project

AF Application Function

ALTO Application-Layer Traffic Optimization

AMF Access Mobility Function

DB Database DNAI Data Network Address Identifier

DNN Data Network Name

ETSI European Telecommunications Standards Institute

LF Linux Foundation

MAS Migration Assistance Server

MEC Multi-access Edge Computing

MED Migration Decision Engine

NWDAF Network Data Analytics Function

NEF Network Exposure Function

NF Network Function

PCF Policy Charging Function

QoE Quality of Experience

QoS Quality of Service

SMF Session Management Function

UE User Equipment

UPF User Plane Function

URI Uniform Resource Identifier

VM Virtual Machine

SUMMARY

Various exemplary embodiments of the present disclosure aim at addressing at least part of the above issues and/or problems and drawbacks.

Various aspects of exemplary embodiments of the present disclosure are set out in the appended claims.

According to an example of an embodiment, there is provided, for example, an apparatus for use by a communication network control element or function configured to assist service migration, comprising at least one processing circuitry, and at least one memory for storing instructions to be executed by the processing circuitry, wherein the at least one memory and the instructions are configured to, with the at least one processing circuitry, cause the apparatus at least to obtain network and service related data, wherein the network and service related data are associated with a service providing network element or function, to generate assistance information based on the network and service related data, wherein the assistance information comprises at least one of network function properties including properties corresponding to the service providing network element or function, and cost mapping data associated with the network function properties, including pairwise costs between end points of the service providing network element or function and another service providing network element or function, and to transmit the assistance information.

Furthermore, according to an example of an embodiment, there is provided, for example a method for use by a communication network control element or function configured to assist service migration, comprising obtaining network and service related data, wherein the network and service related data are associated with a service providing network element or function, generating assistance information based on the network and service related data, wherein the assistance information comprises at least one of network function properties including properties corresponding to the service providing network element or function, and cost mapping data associated with the network function properties, including pairwise costs between end points of the service providing network element or function and another service providing network element or function, and transmitting the assistance information.

According to further refinements, these examples may include one or more of the following features:

- The network and service related data may be obtained from at least one of a network exposure function, network data analytics services, and a service providing network element or function;

- Network service information, which may be derived from the network and service related data, wherein the network service information may be associated with a network service of the service providing network element or function, may be abstracted. Further, the cost mapping data may be based on a combination of the abstracted network service information with application status information, wherein the application status information may be derived from the network and service related data and may be indicative of the network function properties corresponding to the service providing network element or function, may be created;

- The network and service related data may be obtained by receiving information indicating a property and status of a service providing network element or function, and/or by acquiring the network and service related data periodically, and/or by acquiring the network and service related data from a mobile edge platform manager;

- The obtained network and service related data may be gathered and stored in a first data base, the gathered network and service related data may be classified with respect to an associated service providing network element or function or an associated event, the classified network and service related data may be synchronized and aggregated with respect to the gathered and stored network and service related data, maybe based on a result of the synchronization and aggregation, the gathered and stored network and service related data may be updated, the updated network and service related data may be abstracted to be configured to comply to a communication protocol associated with the assistance information; and the abstracted network and service related data may be stored in a second database;

- An instruction to execute a selection procedure for selecting an end point of a target service providing network element or function may be received based on the network and service related data, a result of the selection procedure may be transmitted, and a traffic redirection request comprising a request to redirect a traffic associated with the selected target service providing network element or function to a core network control element or function may be forwarded; - A traffic redirection request comprising a request to redirect a traffic associated with a service providing network element or function to a core network control element or function may be forwarded;

- To receive service context associated with a service migration procedure from one service providing network element or function; and to forward the service context to another service providing network element or function;

- The network and service related data and application level status information may be obtained; and the assistance information may be transmitted by using a communication protocol based on a modified ALTO protocol, wherein the modified ALTO protocol may be configured to be extended by at least one of inclusion of attributes from cellular networks and of application level information, and information on resource management actions.

According to an example of an embodiment, there is provided, for example, an apparatus for use by a communication network control element or function configured to decide about service migration, comprising at least one processing circuitry, and at least one memory for storing instructions to be executed by the processing circuitry, wherein the at least one memory and the instructions are configured to, with the at least one processing circuitry, cause the apparatus at least to receive assistance information, wherein the assistance information comprises at least one of network function properties including properties corresponding to a service providing network element or function, and cost mapping data associated with the network function properties, including pairwise costs between end points of the service providing network element or function and another service providing network element or function, to acquire local information, wherein the local information comprises a service profile associated with a local service providing network element or function and with properties of the local service providing network element or function corresponding to the apparatus, respectively, and to conduct a selection procedure on basis of the assistance information and the local information for selecting a target service providing network element or function. Furthermore, according to an example of an embodiment, there is provided, for example a method for use by a communication network control element or function configured to decide about service migration, comprising receiving assistance information, wherein the assistance information comprises at least one of network function properties including properties corresponding to a service providing network element or function, and cost mapping data associated with the network function properties, including pairwise costs between end points of the service providing network element or function and another service providing network element or function, acquiring local information, wherein the local information comprises a service profile associated with a local service providing network element or function and with properties of the local service providing network element or function corresponding to the apparatus, respectively, and conducting a selection procedure on basis of the assistance information and the local information for selecting a target service providing network element or function.

According to further refinements, these examples may include one or more of the following features:

- Network and service related data which may be associated with a service providing network element or function corresponding to the apparatus may be transmitted;

- Based on the assistance information and the local information, the selection procedure may be executed, or an instruction to execute the selection procedure may be transmitted;

- A service migration procedure may be directly initiated by communicating a service migration request with the selected target service providing network element or function, or a service migration procedure may be initiated by communicating the service migration request with the selected target service providing network element or function via a communication network control element or function configured to assist service migration;

- At least one of a signalling indicative of start and ending of the service migration procedure may be transmitted to a mobile edge platform manager, and a signalling indicative of release of resources allocated for the service migration procedure may be transmitted to the mobile edge platform manager;

- If the service migration procedure is completed, a traffic redirection request which may comprise a request to redirect a traffic corresponding to a service flow associated with the service migration procedure may be transmitted;

- Service context associated with the service migration procedure may be directly transmitted to a service providing network element or function; or service context associated with the service migration procedure may be transmitted by using distributed database transfer via a communication network control element or function configured to assist service migration.

In addition, according to embodiments, there is provided, for example, a computer program product for a computer, including software code portions for performing the steps of the above defined methods, when said product is run on the computer. The computer program product may include a computer-readable medium on which said software code portions are stored. Furthermore, the computer program product may be directly loadable into the internal memory of the computer and/or transmittable via a network by means of at least one of upload, download and push procedures.

Any one of the above aspects enables to assist and decide about a service migration procedure to thereby solve at least part of the problems and drawbacks identified in relation to the prior art.

Thus, improvement is achieved by apparatuses, methods, and computer program products enabling to assist and decide about a service migration procedure.

BRIEF DESCRIPTION OF THE DRAWINGS Some embodiments of the present disclosure are described below, by way of example only, with reference to the accompanying drawings, in which :

Figure 1 shows a diagram illustrating an example of a migration assistance server in 5G - MEC architecture;

Figure 2 shows, in a simplified (MEC) system architecture, a diagram illustrating an example MAS and MDE with their external interfaces;

Figure 3 shows a flowchart illustrating steps corresponding to a method for use by a server including a MAS according to an example of embodiments;

Figure 4 shows a flowchart illustrating steps corresponding to a method for use by a host including a MDE according to an example of embodiments;

Figure 5 shows a block diagram illustrating a server including a MAS according to an example of embodiments; and

Figure 6 shows a block diagram illustrating a host including a MDE according to an example of embodiments.

DESCRIPTION OF EMBODIMENTS

In the last years, an increasing extension of communication networks, e.g. of wire based communication networks, such as the Integrated Services Digital Network (ISDN), Digital Subscriber Line (DSL), or wireless communication networks, such as the cdma2000 (code division multiple access) system, cellular 3 ^rd generation (3G) like the Universal Mobile Telecommunications System (UMTS), fourth generation (4G) communication networks or enhanced communication networks based e.g. on Long Term Evolution (LTE) or Long Term Evolution-Advanced (LTE-A), fifth generation (5G) communication networks, cellular 2 ^nd generation (2G) communication networks like the Global System for Mobile communications (GSM), the General Packet Radio System (GPRS), the Enhanced Data Rates for Global Evolution (EDGE), or other wireless communication system, such as the Wireless Local Area Network (WLAN), Bluetooth or Worldwide Interoperability for Microwave Access (WiMAX), took place all over the world. Various organizations, such as the European Telecommunications Standards Institute (ETSI), the 3 ^rd Generation Partnership Project (3GPP), Telecoms & Internet converged Services & Protocols for Advanced Networks (TISPAN), the International Telecommunication Union (ITU), 3 ^rd Generation Partnership Project 2 (3GPP2), Internet Engineering Task Force (IETF), the IEEE (Institute of Electrical and Electronics Engineers), the WiMAX Forum and the like are working on standards or specifications for telecommunication network and access environments.

Basically, for properly establishing and handling a communication between two or more end points (e.g. communication stations or elements or functions, such as terminal devices, user equipments (UEs), or other communication network elements, a database, a server, host etc.), one or more network elements or functions (e.g. virtualized network functions), such as communication network control elements or functions, for example access network elements like access points, radio base stations, relay stations, eNBs, gNBs etc., and core network elements or functions, for example control nodes, support nodes, service nodes, gateways, user plane functions, access and mobility functions etc., may be involved, which may belong to one communication network system or different communication network systems.

Edge computing brings computing resources closer to the end users and user equipments (UEs). By doing this it provides low latency and high bandwidth as well as a possibility to exploit real-time access to radio network information for the benefit of the applications that are provisioned to use edge resources. ETSI MEC is the leading standardization body, but there are a number of other initiatives developing and experimenting with the edge computing concepts, such as Open Edge Computing Initiative and LF Edge of Linux Foundation.

The generic multi-access edge computing (MEC) system architecture consists of MEC orchestrator, MEC platform management and MEC platform in MEC host. The MEC platform hosts the cloud resources at the edge. It hosts the MEC applications and MEC system services that benefit from close proximity to the edge and access network. Essentially the MEC host and the MEC platform have limited scope, coverage and resources due the access network to which it is deployed.

Both ETSI ISG MEC (Industry Specification Group for Multi-access Edge Computing) and 3GPP are working on integration of edge computing support into 5G architecture. The MEC orchestrator is a MEC system level functional entity that acts as an Application Function (AF) of 5G reference architecture and interacts through the Network Exposure Function (NEF) to access 5G network resources. In some scenarios it may interact even directly with the relevant 5G NFs bypassing the network exposure function (NEF) if the application function (AF) is considered a trusted entity. Consequently, MEC platform can interact with 5G NFs and other resources when acting in the role of an AF. The MEC hosts, i.e. the host level functional entities, are most often deployed close to the access network in the 5G system. While the NEF as a Core Network function is a system level entity deployed centrally together with similar NFs, an instance of NEF can also be deployed in the edge to allow low latency, high throughput service access from a MEC host.

The physical resources at the network edge and in the mobile edge host are limited in comparison to a central data center due to economical and practical reasons related to physical sites. Not all possible applications that may benefit and need edge cloud resources can be running in all edge hosts of a network operator, unless the applications/services are very few and stateless. The application images of all applications can, however, be stored locally at the edge hosts and maybe some of the most critical applications can be running all the time. But sharing of the same application run-time context across all edge hosts of a larger network is likely to be impractical due to the required transport capacity needed between the mobile hosts, the amount of needed memory and latency reasons. This leads to service migration between the source and the target edge hosts/platforms where the run-time application level context of a given MEC service is moved from a host to another host that is better positioned to provide the service. It is to be noted that context re-establishment is always an alternative to service migration. The crucial distinction is that of performance benefits that context relocation, if well engineered, could offer to transport layers: use of radio resources is typically more costly than the use of backhaul resources between the mobile edge hosts.

In a case where a group of UEs running a low latency MEC/edge service moves from a service area of source MEC host to target MEC host, each UE cloud re-establishment its own service context after the handover. However, this will cause additional application level transactions between the UE and the target MEC host: cost of ^{UE^ reactivation messages with the target). The more UEs are reactivating their context the more application level is messaging over the air. If this cost is higher than the cost of service migration of the low latency service, then the service migration is well-justified. It should be noted that there should be a sufficient number of UEs or the service should be especially important to justify service migration, otherwise context re-establishment should be preferable. Clearly, before evaluating whether the cost of service migration is justifiable, proper target host(s) must be identified. Identification of candidate target MEC host and calculating the cost of migration both need 5G system level as well as MEC platform level status information. Service migration decision needs visibility to status of candidate edge host resources, radio access status, as well as to network load on a path between the eNB/gNB and MEC host.

Hence, an issue is the optimal selection of the target MEC host among multiple candidates so that the service migration cost is minimized. This involves the selection of suitable target candidate hosts with sufficient resources for the service to be migrated, availability of the service image on the host (optional, but most likely needed), cost/delay of the application context transfer (service migration) between the source and the target hosts and the cost of the radio access capacity increase due to the service migration. The initial selection, i.e. selection of the first MEC server, is based on 3GPP UE subscription information, DNN, service area information among other policies from the operator and AF provided to PCF when the UE set up a PDU session for the MEC application. An Application Function may influence UPF (re)selection and traffic routing via PCF or NEF. Within the following specification it is defined in detail how an AF would assist to select a MEC server and associated UPFs selected both for the initial server selection as well as in cases of service migration.

One approach for selecting the target MEC host for service migration is based on peer-to-peer content distribution, where a client should select a peer from where to download requested content. This has been addressed by the IETF ALTO WG (Working Group) that has developed ALTO protocol. The base ALTO protocol is designed to expose network information through services such as cost maps, endpoint cost service and Endpoint property service on IP networks. While ALTO use cases focus on peer-to-peer applications, ALTO can be applied to other environments. An ALTO server collects information about available peers and their capabilities. An ALTO client requests available ALTO information from the ALTO server using the ALTO Protocol. The ALTO information provided by the ALTO server can be updated dynamically based on network conditions or can be seen as policies that arise updated on a longer time scale.

In the following, different exemplifying embodiments will be described using, as an example of a communication network to which examples of embodiments may be applied, a communication network architecture based on 3GPP standards for a communication network, such as a 5G/NR, without restricting the embodiments to such an architecture, however. It is obvious for a person skilled in the art that the embodiments may also be applied to other kinds of communication networks like 4G and/or LTE where mobile communication principles are integrated, e.g. Wi-Fi, worldwide interoperability for microwave access (WiMAX), Bluetooth®, personal communications services (PCS), ZigBee®, wideband code division multiple access (WCDMA), systems using ultra-wideband (UWB) technology, mobile ad-hoc networks (MANETs), wired access, etc.. Furthermore, without loss of generality, the description of some examples of embodiments is related to a mobile communication network, but principles of the disclosure can be extended and applied to any other type of communication network, such as a wired communication network or datacenter networking.

The following examples and embodiments are to be understood only as illustrative examples. Although the specification may refer to "an", "one", or "some" example(s) or embodiment(s) in several locations, this does not necessarily mean that each such reference is related to the same example(s) or embodiment(s), or that the feature only applies to a single example or embodiment. Single features of different embodiments may also be combined to provide other embodiments. Furthermore, terms like "comprising" and "including" should be understood as not limiting the described embodiments to consist of only those features that have been mentioned; such examples and embodiments may also contain features, structures, units, modules etc. that have not been specifically mentioned.

A basic system architecture of a (tele)communication network including a mobile communication system where some examples of embodiments are applicable may include an architecture of one or more communication networks including wireless access network subsystem(s) and core network(s). Such an architecture may include one or more communication network control elements or functions, access network elements, radio access network elements, access service network gateways or base transceiver stations, such as a base station (BS), an access point (AP), a NodeB (NB), an eNB or a gNB, a distributed or a centralized unit, which controls a respective coverage area or cell(s) and with which one or more communication stations such as communication elements or functions, like user devices or terminal devices, like a UE, or another device having a similar function, such as a modem chipset, a chip, a module etc., which can also be part of a station, an element, a function or an application capable of conducting a communication, such as a UE, an element or function usable in a machine-to-machine communication architecture, or attached as a separate element to such an element, function or application capable of conducting a communication, or the like, are capable to communicate via one or more channels via one or more communication beams for transmitting several types of data in a plurality of access domains. Furthermore, core network elements or network functions, such as gateway network elements/functions, mobility management entities, a mobile switching center, servers, databases and the like may be included.

The general functions and interconnections of the described elements and functions, which also depend on the actual network type, are known to those skilled in the art and described in corresponding specifications, so that a detailed description thereof is omitted herein. However, it is to be noted that several additional network elements and signaling links may be employed for a communication to or from an element, function or application, like a communication endpoint, a communication network control element, such as a server, a gateway, a radio network controller, and other elements of the same or other communication networks besides those described in detail herein below.

A communication network architecture as being considered in examples of embodiments may also be able to communicate with other networks, such as a public switched telephone network or the Internet. The communication network may also be able to support the usage of cloud services for virtual network elements or functions thereof, wherein it is to be noted that the virtual network part of the telecommunication network can also be provided by non-cloud resources, e.g. an internal network or the like. It should be appreciated that network elements of an access system, of a core network etc., and/or respective functionalities may be implemented by using any node, host, server, access node or entity etc. being suitable for such a usage. Generally, a network function can be implemented either as a network element on a dedicated hardware, as a software instance running on a dedicated hardware, or as a virtualized function instantiated on an appropriate platform, e.g., a cloud infrastructure.

Furthermore, a network element, such as communication elements, like a UE, a terminal device, control elements or functions, such as access network elements, like a base station (BS), an gNB, a radio network controller, a core network control element or function, such as a gateway element, or other network elements or functions, as described herein, and any other elements, functions or applications may be implemented by software, e.g. by a computer program product for a computer, and/or by hardware. For executing their respective processing, correspondingly used devices, nodes, functions or network elements may include several means, modules, units, components, etc. (not shown) which are required for control, processing and/or communication/signaling functionality. Such means, modules, units and components may include, for example, one or more processors or processor units including one or more processing portions for executing instructions and/or programs and/or for processing data, storage or memory units or means for storing instructions, programs and/or data, for serving as a work area of the processor or processing portion and the like (e.g. ROM, RAM, EEPROM, and the like), input or interface means for inputting data and instructions by software (e.g. floppy disc, CD-ROM, EEPROM, and the like), a user interface for providing monitor and manipulation possibilities to a user (e.g. a screen, a keyboard and the like), other interface or means for establishing links and/or connections under the control of the processor unit or portion (e.g. wired and wireless interface means, radio interface means including e.g. an antenna unit or the like, means for forming a radio communication part etc.) and the like, wherein respective means forming an interface, such as a radio communication part, can be also located on a remote site (e.g. a radio head or a radio station etc.). It is to be noted that in the present specification processing portions should not be only considered to represent physical portions of one or more processors, but may also be considered as a logical division of the referred processing tasks performed by one or more processors.

It should be appreciated that according to some examples, a so-called "liquid" or flexible network concept may be employed where the operations and functionalities of a network element, a network function, or of another entity of the network, may be performed in different entities or functions, such as in a node, host or server, in a flexible manner. In other words, a "division of labor" between involved network elements, functions or entities may vary case by case.

Figure 1 shows a diagram illustrating an example of a migration assistance server in 5G - MEC architecture.

In the following, a Migration Assistance Server (MAS) 110, also referred to as an apparatus for use by a communication network control element or function configured to assist service migration, is introduced that collects information for service migration needs. Furthermore, a Migration Decision Engine (MDE) 120, also referred to as an apparatus for use by a communication network control element or function configured to decide about service migration, is introduced that uses this information from the MAS 110 to select a fitting target MEC host 130, also referred to as a target service providing network element or function. According to examples of the disclosure, the MDE 120 initiates service migration based on the information received from the MAS 110 and uses also local (edge service and platform specific) information from the MEC host 130. The MDE 120 is acting as client towards the MAS 110 and is part of a MEC platform or a separate MEC application. The MAS 110 relays traffic steering requests from MDEs 120 to SMF and PCF (comprised within core network control service providing elements or functions 150) as needed and if authorized. The MDEs 120 communicate between each other as well, to start an actual service migration process. It should be noted that the service migration may be triggered by UE handovers, but the migration decision is not only based on UE movements but rather the capacity status of MEC platforms (source and target) and service QoE provided by the application at the edge. Other reasons for service migration could be load balancing and scheduled maintenance operations or need to deploy a new service of higher priority to already congested MEC host 130. Still further potential triggers for triggering service migration are e.g. derivable from Addad et al., describing "Network Slice Mobility in Next Generation Mobile Systems: Challenges and Potential Solutions", in IEEE Network Magazine.

Figure 1 shows how the MAS 110 is connected to the integrated 5G MEC architecture. The MAS 110 appears as an AF in 5G architecture. The MAS 110 subscribes to 5G relevant notifications (e.g. traffic load statistics, handovers, radio information, and other triggers) via NEF 140 (N33). It may also use network data analytics services (NWDAF) 160 offered through NEF 140. The MDE 120 decides to which target MEC host 130 a service will be migrated based on the local information (service profile) and the information about the candidate MEC hosts obtained from the MAS 110. After target host selection the MDE 120 starts the migration process contacting the selected host through Mp3 interface and sends traffic redirect request of the service flows to the MAS 110 that then sends these traffic redirect requests to SMF and to PCF. If the services to be migrated are maintaining their state in a separate DB, the MAS 110 acts as a mediator between the source and target MEC host state DBs. The MAS 110 may use the North bound API provided by NEF 140.

Further, the MEC 130 according to Figure 1 communicates with a UPF 170, which further communicates with a gNB 180. A UE 190 may be present which communicates with the gNB 180. All of the entities UPF 170, gNB 180, and UE 190 communicate with the Core Network 150.

Figure 2 shows a diagram illustrating, in a simplified (MEC) system architecture, an example MAS 110 and MDE 120 with their external interfaces. In particular, Figure 2 illustrates a more detailed picture of the configuration as shown in Figure 1.

The MAS 110 server provides a "global and synchronized view" of the available resources at the MEC platforms and application servers. In that sense it acts similarly to an ALTO server by creating and maintaining network and cost maps. It collects MEC application and MEC platform information using the MDE 120 entity in the MEC platform. This collected information may also be referred to as representing one part of network and service related data. The MAS 110 may provide the Endpoint Cost Service that provides path costs between the source and eligible target MECs 130 and selects the target MEC host 130 on behalf of the MDE 120. Such path costs may also be referred to as representing one part of assistance information.

It should be noted that the ALTO Endpoint Cost Service can select the target MEC 130 on behalf of the MDE 120 only if (i) one single metric is used and (ii) the cost is requested in ordinal mode. Thus, direct use of ALTO Endpoint ranking cost service is not possible when several metrics are used but needs to be enhanced. In the latter case, the MDE may query multiple ALTO metrics via RFC8189 210 and use its own ranking function that can leverage local parameters not available or useful to the ALTO server. Also, the MAS 110 relays traffic rerouting request to the SMF/PCF after the service migration is completed from the MDEEDs.

The MAS 110 optimizes the procedures by having a mapping information on MEC hosts 130, their relation to UPF 170 and UPF 170 association to eNB/gNB 180. The MAS 110 holds a detailed network topology mapping table with identifiers of the MEC host 130, UPF 170, DNAI, tracking areas and eNB/gNB ID. Such mapping information may also be referred to as representing one part of network service information derivable from the collected network and service related data. This mapping information combined with mobility and event notifications from Radio Resource Management such as handover messages or Event A3 (neighbour becomes offset better than PCell/ PSCell) provides early indication of coming handover, which allows optimizing the selected procedure. Such mobility and event notifications may also be referred to as representing one part of application status information also derivable from the collected network and service related data.

The MAS 110 is consolidating the information from the (5G) network into the cost maps together with the status information it receives from the MEC hosts 130/MDEs 120. The MEC hosts 130 do not need to subscribe individually to potentially multiple notifications (such as handover events, congestion notifications or location services, etc. provided by different 5G function ) but all that goes via the MAS 110 should and must have an access authorization to subscribe with the relevant (core and RAN) network functions.

It is to be noted that the MAS 110 can be adopted to access different networks such as 4G and 5G networks without impacting on the MEC hosts 130 or on the MDEs 120, since it is the MAS 110 that shields these network details from the remaining entities.

Similarly to ALTO server, the MAS 110 forms a network map that is used to calculate a MAS cost map that contains pairwise costs between source and destination end points (e.g. MEC hosts 130). The end points and possible intermitted nodes should be modelled as Abstracted Network Elements (ANEs), which is being specified within [draft-ietf-alto-path-vector] (https://tools.ietf.org/html/draft-ietf-alto-path-vector-08) . An ANE is some part of the network that can be a server, a link or a group of links, a Data Center, a loose network node. They can have multiple properties, such as CPU load, interface type, link capacity, RAM, etc. These properties describe an endpoint or entity and are conveyed by the ALTO unified property service, which is being specified within [draft-ietf-alto-unified-props-new-09] (https://tools.ietf.org/html/draft-ietf-alto-unified-props-n ew-09).

However, according to examples of embodiments, the MAS 110 may use the path vector abstraction instead of the single node abstraction of the base line ALTO to include the full information on intermediate network elements on the path. The path vector abstraction uses path vectors with ANEs to provide network graph view for applications. A path vector consists of a sequence of ANEs that end-to-end traffic goes through. Therefore, the MAS cost maps created by the MAS 110 provide array-like cost values rather than single scalar costs, similarly to path vector abstraction. Additionally, the MEC selection method enables trade-offs between different attributes (e.g. available CPU capacity, available radio capacity, cost of backhaul) when selecting the target MEC host 130, as this method can perform applicable to multi-objective optimization. An ALTO service allows an ALTO Client to retrieve several cost metrics in a single request for an ALTO filtered cost map and endpoint cost map. In addition, it extends the constraints to further filter those maps by allowing an ALTO Client to specify a logical combination of tests on several cost metrics. These definitions are valid for MDE 120 and MAS 110 to support multi-cost optimizations. If the MEC host server states are stored in a separate DB, the MAS 110 acts as a relay or a mediator between the source and target DB of the MEC hosts 130, bypassing Mp3 interface.

The MDE 120 is using the services of the MAS 110 through a protocol that is a modification of the ALTO protocol to provide service migration relevant cost metrics (server load, transport network load and delay, radio access load, etc.) for candidate MEC hosts 130. Current ALTO protocol doesn't support updates from ALTO clients to ALTO servers. The MDE 120 co-located with the ALTO Client sends notifications to the MAS 110 that injects it to a data base, such a an ALTO server input data base. This information involves status data updates notifications for potential migration events from MDEs 120 from the MAS 110, request from MDEs 120 to the MAS 110 to redirect traffic flows. According to exemplary embodiments the MDEs 120 will use HTTP posts to update the MAS 110 with the newest end point property information. Still according to various exemplary embodiments there may be applied other means, such as a Mobile edge platform manager 220. The MDE 120 instances in the MEC host 130 communicate with each other over specified interfaces, such as Mp3 reference point of MEC system architecture. A source MDE 120 instance sends a migration request message to the MDE 120 of the selected target MEC host 130, which initiates the actual service migration process. A target MEC 130 is selected based on: (i) properties and capabilities of the candidate MECs 130, (ii) properties and performance of network path between source and target MEC 130. The MDE 120 needs to make quick and correct decisions and on the other hand plays at the application layer. Therefore, it will preferably to use abstractions of information on network paths and application endpoint, as provided by the IETF ALTO protocol.

According to some examples of embodiments, the MDE 120 initiates service migration upon receiving at least one of cell load and handover triggers, in a pro-active way for better load balancing or performance, and as instructed by the MEC management system.

As indicated above, ALTO services need to be extended by at least one of inclusion of attributes from cellular networks (cell load, service and tracking areas) and application level information about the context, e.g. size and dynamicity of the context, and an ALTO property calendar.

Regarding the communication between the MAS 110 and the MDE 120, there is information from the network that consist of network performance and monitoring data (QoS, bits transferred, dropped packets, number of handovers etc. that is low level information). This can be further processed to network service information (these are the primitive services that customers buy, for example broadband connection to certain service provider, or a phone call to certain end user or VPN connection between two sites). However, application data is more specific to an application and beyond the visibility of the network, for instance but not limited thereto: use of a CPU, use of memory per certain application running at the edge cloud, use of central cloud. The MEC host 130 has visibility to this data in the edge clouds.

The MDE 120 has access to local MEC platform specific information. It knows the requirements and current status of the local services. It also interfaces the MEC life cycle manager of the local services and keeps them updated about the migration process. It should report to the MEC life cycle manager about start and ending of a service migration and when the resources of allocated for a migrated source service instance can be released.

Each end point has to support the "https" URI scheme and Transport Layer Security (TLS) similar to ALTO. Note that ETSI MEC APIs as well as 3GPPP SBA APIs both use similar URI based scheme which should be used also between the MDE 120 and the MAS 110 to easy interfacing both MEC and 3GPP 5G network functions.

As example, the MEC Platform hosting the MEC Application Enablement function and the MDE function uses the URI https://mecl2- pinewood.operator.com/{servicename}/{version}/.

This way e.g. the MDE could be found with DNS query with FQDN mecl2- pinewood.operator.com/mde/vl.

The MDE 120 requests path-vectors based cost maps per MEC application from the MAS 110 using HTTP based requests with application id/name query parameters using extended ALTO- protocol. The MDE 120 may delegate the target MEC host 130 selection to the MAS 110, or it may perform the selection on its own based on the cost map. The MDEs 120 may send filtering request parameters such as, src, dst, metrics, logical constraints as per ALTO-protocol and its extensions. After the selection of the target MEC host 130, the source MDE 120 contacts the target MDE 120 in the selected MEC host 130 using the associated IP addresses (or other identifiers) to the target MEC. The MDE 120 starts the service migration process (and agree whether pre-copy memory migration or post-copy memory migration should be applied) using a protocol not defined in this invention report. Once the migration process has reached its end and the service is running at the target MEC host 130, the target MDE 120 sends a traffic redirect request to the MAS 110 that relays it to NEF/SMF and finally to UPF 170.

There are several exemplary embodiments of how the ANE and end point properties are collected to feed the MAS Data Base from MEC platforms. According to various exemplary embodiments the MDEs 120 post the properties and their status (using HTTP POSTs) once there is a new property (e.g. MEC application) or an update to an existing one. According to at least some exemplary embodiments the MAS 110 collects periodically the information of available properties and their status using HTTP GETs from MDEs 120 URLs. And still according to various exemplary embodiments the MAS 110 collects this information over Mm5-interface from different Mobile edge platform managers that need to collect the relevant status information. The two former approaches can be implemented as an application overlay, whereas the third one requires changes in multiple components of a MEC system.

As already outlined above, one MDE 120 corresponding to one MEC host 130 may use the Mp3 interface to directly communicate with a different MDE 120 corresponding to a different MEC host 130. However, as indicated by the dashed one-directed arrows 230 within Figure 2, the one MDE 120 may also communicate with the other MDE 120 via the MAS 110.

In this case, services associated with a MDE 120 may be store in a local DB associated with a MEC host 130 corresponding to the MDE 120. Therefore, if data is e.g. to be transferred from one DB corresponding to one MDE 120 to another DB corresponding to another MDE 120, the MAS 110 may serve as some kind of "relay" or "mediator" between a source and target MDE 120 (a source and target MEC host 130). More specifically, how service context is to be transferred between MDEs 120 (with each MDE 120 corresponding to a different MEC host 130), that is directly or via the MAS 110, may depend on how the service context is maintained within a service. For instance, if the services have their context in a DB, then the MAS 110 is acting as a mediator. However, if the context is contained in the service itself, direct transfer may be a better and more efficient option.

Figure 3 shows a flowchart illustrating steps corresponding to a method for use by a server including a MAS 110 in order to assist service migration according to an example of embodiments.

In particular, according to Figure 3, in S310, network and status related data are obtained. The network and service related data are e.g. associated with a service providing network element or function.

For example, according to some examples of embodiments, the network and service related data are obtained from at least one of a network exposure function, network data analytics services, and a service providing network element or function.

Further, according to Figure 3, in S320, assistance information are generated based on the network and service related data. The assistance information comprises e.g. network function properties including properties corresponding to the service providing network element or function, and cost mapping data associated with the network function properties, including pairwise costs between end points of the service providing network element or function and another service providing network element or function.

In addition, according to at least some exemplary embodiments, the method may further comprise abstracting network service information derived from the network and service related data, wherein the network service information are associated with a network service of the service providing network element or function, and creating the cost mapping data based on a combination of the abstracted network service information with application status information, wherein the application status information are derived from the network and service related data and are indicative of the network function properties corresponding to the service providing network element or function.

Additionally, according to various exemplary embodiments, the network and service related data may be obtained by at least one of receiving information indicating a property and status of a service providing network element or function, and/or acquiring the network and service related data periodically, and/or acquiring the network and service related data from a mobile edge platform manager.

Further, according to at least some exemplary embodiments, the method may comprise gathering and storing the obtained network and service related data in a first data base, classifying the gathered network and service related data with respect to an associated service providing network element or function or an associated event. The method may further comprise synchronizing and aggregating the classified network and service related data with respect to the gathered and stored network and service related data, updating, based on a result of the synchronization and aggregation, the gathered and stored network and service related data, abstracting the updated network and service related data to be configured to comply to a communication protocol associated with the assistance information; and storing the abstracted network and service related data in a second database.

In addition, according to at least some exemplary embodiments, the method may further comprise receiving an instruction to execute a selection procedure for selecting an end point of a target service providing network element or function based on the network and service related data, transmitting a result of the selection procedure, and forwarding a traffic redirection request comprising a request to redirect a traffic associated with the selected target service providing network element or function to a core network control element or function.

Further, according to at least some exemplary embodiments, the method may further comprise forwarding a traffic redirection request comprising a request to redirect a traffic associated with a service providing network element or function to a core network control element or function.

Furthermore, according to Figure 3, in S330, the assistance information are transmitted.

In addition, according to at least some exemplary embodiments, the method may further comprise receiving service context associated with a service migration procedure from one service providing network element or function; and forwarding the service context to another service providing network element or function.

According to at least some exemplary embodiments, the method may further comprise obtaining the network and service related data and application level status information; and transmitting the assistance information by using a communication protocol based on a modified ALTO protocol. The modified ALTO protocol may be configured to be extended by at least one of inclusion of attributes from cellular networks and of application level information, and information on resource management actions. Information on resource management actions may e.g. cover a calendar (array of time slots) exposing for each time slot an information on network event/status or some network management action, such as, but not limited to this, "maintenance", "poor availability", "ok", and/or management actionX.

Figure 4 shows a flowchart illustrating steps corresponding to a method for use by a host including a MDE 120 for deciding about service migration according to an example of embodiments; In particular, according to Figure 4, in S410, assistance information are received. The assistance information comprises e.g. network function properties including properties corresponding to a service providing network element or function, and cost mapping data associated with the network function properties, including pairwise costs between end points of the service providing network element or function and another service providing network element or function.

Further, according to Figure 4, in S420, local information are acquired. The local information comprises e.g. a service profile associated with a local service providing network element or function and with properties of the local service providing network element or function corresponding to the apparatus 600, respectively.

Furthermore, according to Figure 4, in S430, a selection procedure is conducted. The selection procedure is e.g. conducted on basis of the assistance information and the local information for selecting a target service providing network element or function.

In addition, according to at least some exemplary embodiments, the method may further comprise executing, based on the assistance information and the local information, the selection procedure, or transmitting an instruction to execute the selection procedure.

According to at least some exemplary embodiments, the method may further comprise transmitting network and service related data associated with a service providing network element or function corresponding to the apparatus 600.

Furthermore, according to various exemplary embodiments, the method may further comprise initiating a service migration procedure by directly communicating a service migration request with the selected target service providing network element or function or initiating a service migration procedure by communicating the service migration request with the selected target service providing network element or function via a communication network control element or function configured to assist service migration.

In addition, according to at least some exemplary embodiments, the method may further comprise at least one of transmitting to a mobile edge platform manager a signalling indicative of start and ending of the service migration procedure, and transmitting to the mobile edge platform manager a signalling indicative of release of resources allocated for the service migration procedure.

Furthermore, according to various exemplary embodiments, the method may further comprise transmitting, if the service migration procedure is completed, a traffic redirection request comprising a request to redirect a traffic corresponding to a service flow associated with the service migration procedure.

Additionally, according to various exemplary embodiments, the method may further comprise directly transmitting service context associated with the service migration procedure to a service providing network element or function; or transmitting service context associated with the service migration procedure by using distributed database transfer via a communication network control element or function configured to assist service migration.

In the following, further exemplary embodiments are described in relation to the above described method.

Figure 5 shows a diagram of a network element or function representing a communication element or function according to some examples of embodiments, e.g. a server including a MAS, which is configured to conduct a control procedure as described in connection with some of the examples of embodiments. It is to be noted that the communication element or function like the server including the MAS may include further elements or functions besides those described herein below. Furthermore, even though reference is made to a communication element or function, the element or function may be also another device or function having a similar task, such as a chipset, a chip, a module, an application etc., which can also be part of a network element or attached as a separate element to a network element, or the like. It should be understood that each block and any combination thereof may be implemented by various means or their combinations, such as hardware, software, firmware, one or more processors and/or circuitry.

The communication element or function shown in Figure 5 may include a processing circuitry, a processing function, a control unit or a processor 510, such as a CPU or the like, which is suitable to assist a service migration procedure. The processor 510 may include one or more processing portions or functions dedicated to specific processing as described below, or the processing may be run in a single processor or processing function. Portions for executing such specific processing may be also provided as discrete elements or within one or more further processors, processing functions or processing portions, such as in one physical processor like a CPU or in one or more physical or virtual entities, for example. Reference sign 531 and 532 denote input/output (I/O) units or functions (interfaces) connected to the processor or processing function 510. The I/O units 531 may be used for communicating with an MEC entity, such as a MEC host 130, as described in connection with Figures 1 and 2, for example. The I/O units 532 may be used for communicating with other communication elements, like Core Network elements as described in connection with Figures 1 and 2. The I/O units 531 and 532 may be a combined unit including communication equipment towards several entities, or may include a distributed structure with a plurality of different interfaces for different entities. Reference sign 520 denotes a memory usable, for example, for storing data and programs to be executed by the processor or processing function 510 and/or as a working storage of the processor or processing function 510. It is to be noted that the memory 520 may be implemented by using one or more memory portions of the same or different type of memory. The processor or processing function 510 is configured to execute processing related to the above described communication control processing. In particular, the processor or processing circuitry or function 510 includes one or more of the following sub-portions. Sub-portion 511 is a processing portion which is usable as a portion for obtaining data. The portion 511 may be configured to perform processing according to S310 of Figure 3. Furthermore, the processor or processing circuitry or function 510 may include a sub portion 512 usable as a portion for generating assistance information. The portion 512 may be configured to perform a processing according to S320 of Figure 3. In addition, the processor or processing circuitry or function 510 may include a sub-portion 513 usable as a portion for transmitting assistance information. The portion 513 may be configured to perform a processing according to S330 of Figure 3.

Figure 6 shows a diagram of a network element or function representing a communication element or function according to some examples of embodiments, e.g. a host including a MDE, which is configured to conduct a control procedure as described in connection with some of the examples of embodiments. It is to be noted that the communication element or function like the host including the MDE may include further elements or functions besides those described herein below. Furthermore, even though reference is made to a communication element or function, the element or function may be also another device or function having a similar task, such as a chipset, a chip, a module, an application etc., which can also be part of a network element or attached as a separate element to a network element, or the like. It should be understood that each block and any combination thereof may be implemented by various means or their combinations, such as hardware, software, firmware, one or more processors and/or circuitry.

The communication element or function shown in Figure 6 may include a processing circuitry, a processing function, a control unit or a processor 610, such as a CPU or the like, which is suitable for deciding about service migration. The processor 610 may include one or more processing portions or functions dedicated to specific processing as described below, or the processing may be run in a single processor or processing function. Portions for executing such specific processing may be also provided as discrete elements or within one or more further processors, processing functions or processing portions, such as in one physical processor like a CPU or in one or more physical or virtual entities, for example. Reference sign 631 and 632 denote input/output (I/O) units or functions (interfaces) connected to the processor or processing function 610. The I/O units 631 may be used for communicating with a MEC entities, such as a target MEC host 130, as described in connection with Figures 1 and 2, for example. The I/O units 632 may be used for communicating with other communication elements, like Core Network elements as described in connection with Figures 1 and 2. The I/O units 631 and 632 may be a combined unit including communication equipment towards several entities, or may include a distributed structure with a plurality of different interfaces for different entities. Reference sign 620 denotes a memory usable, for example, for storing data and programs to be executed by the processor or processing function 610 and/or as a working storage of the processor or processing function 610. It is to be noted that the memory 620 may be implemented by using one or more memory portions of the same or different type of memory.

The processor or processing function 610 is configured to execute processing related to the above described communication control processing. In particular, the processor or processing circuitry or function 610 includes one or more of the following sub-portions. Sub-portion 611 is a processing portion which is usable as a portion for receiving data. The portion 611 may be configured to perform processing according to S410 of Figure 4. Furthermore, the processor or processing circuitry or function 610 may include a sub portion 612 usable as a portion for acquiring local information. The portion 612 may be configured to perform a processing according to S420 of Figure 4. In addition, the processor or processing circuitry or function 610 may include a sub-portion 613 usable as a portion for conducting a selection procedure. The portion 613 may be configured to perform a processing according to S430 of Figure 4.

It should be appreciated that

- an access technology via which traffic is transferred to and from an entity in the communication network may be any suitable present or future technology, such as WLAN (Wireless Local Access Network), WiMAX (Worldwide Interoperability for Microwave Access), LTE, LTE-A, 5G, Bluetooth, Infrared, and the like may be used; additionally, embodiments may also apply wired technologies, e.g. IP based access technologies like cable networks or fixed lines.

- embodiments suitable to be implemented as software code or portions of it and being run using a processor or processing function are software code independent and can be specified using any known or future developed programming language, such as a high-level programming language, such as objective-C, C, C++, C#, Java, Python, Javascript, other scripting languages etc., or a low-level programming language, such as a machine language, or an assembler.

- implementation of embodiments is hardware independent and may be implemented using any known or future developed hardware technology or any hybrids of these, such as a microprocessor or CPU (Central Processing Unit), MOS (Metal Oxide Semiconductor), CMOS (Complementary MOS), BiMOS (Bipolar MOS), BiCMOS (Bipolar CMOS), ECL (Emitter Coupled Logic), and/or TTL (Transistor-Transistor Logic).

- embodiments may be implemented as individual devices, apparatuses, units, means or functions, or in a distributed fashion, for example, one or more processors or processing functions may be used or shared in the processing, or one or more processing sections or processing portions may be used and shared in the processing, wherein one physical processor or more than one physical processor may be used for implementing one or more processing portions dedicated to specific processing as described,

- an apparatus may be implemented by a semiconductor chip, a chipset, or a (hardware) module including such chip or chipset; - embodiments may also be implemented as any combination of hardware and software, such as ASIC (Application Specific IC (Integrated Circuit)) components, FPGA (Field-programmable Gate Arrays) or CPLD (Complex Programmable Logic Device) components or DSP (Digital Signal Processor) components.

- embodiments may also be implemented as computer program products, including a computer usable medium having a computer readable program code embodied therein, the computer readable program code adapted to execute a process as described in embodiments, wherein the computer usable medium may be a non-transitory medium.

Although the present disclosure has been described herein before with reference to particular embodiments thereof, the present disclosure is not limited thereto and various modifications can be made thereto.