Patent Description:
This specification relates to service distribution more particularly to service distribution in the Service-Based Architecture (SBA) such as the SBA used in Fifth Generation (<NUM>), core network.

The Third Generation Partnership Project (3GPP) is working on <NUM>, and one of the planned changes it to implement a so-called Service Based Architecture, SBA. This is currently being specified in 3GPP SA2 group, in the <NUM> core network architecture document <NUM>, see overall <NUM> SBA architecture in <FIG> (prior art) illustrating the local breakout and the home routing roaming architectures as specified in 3GPP Technical Specification (TS) <NUM> V1. <NUM>: 3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; System Architecture for the <NUM> System; Stage <NUM> (Release <NUM>) and overall <NUM> procedures: 3GPP TS <NUM> V0. <NUM>: 3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; Procedures for the <NUM> System; Stage <NUM> (Release <NUM>)). The idea behind SBA is that a number of the interfaces and protocols within the core network (including roaming interfaces) are changed from legacy telecom style to more modern, web-based APIs. Additionally, in an SBA representation, network functions (e.g. Access and mobility function, AMF or Session Mobility Function, SMF, see <FIG> (Prior art)) within the Control Plane enables other authorized network functions to access their services. The details of these "modern" protocols are being worked on, and these details matter as different ways of using web technology will result in large differences in how flexible, easy to secure, future-proof, or efficient <NUM> core systems will be.

The <NUM> networks are also expected to run over cloud and virtualization frameworks such as Network Functions Virtualization, NFV. One definition of NFV is provided by the Open Platform for NFV, OPNFV:.

"NFV enables complex network functions to be performed on compute nodes in data centers. A network function performed on a compute node is called a Virtualized Network Function (VNF). So that VNFs can behave as a network, NFV also adds the mechanisms to determine how they can be chained together to provide control over traffic within a network.

There are many implementations of NFV. One such implementation is described by OPNFV. OPNFV facilitates the development and evolution of NFV components across various open source ecosystems, such as OpenStack®. OpenStack® is open source software for managing telecommunications infrastructure for NFV, <NUM>, loT and business applications.

Several virtualization techniques can be used. For instance, containers allow processes to be isolated from each other and from the underlying framework. As described in Open Network Function Virtualization Forum, OPNFV:.

"Containers virtualize the operating system as opposed to the entire machine. As a result, containers are much lighter than virtual machines, but suffer from isolation and security issues by virtue of sharing a common kernel. As an aside, for this reason many users run containers inside virtual machines. Given their small footprint, containers are popular in cloud native micro-services-based software architectures.

Another virtualization technique uses serverless implementations. Serverless computing can be described as a cloud computing execution model in which the cloud provider such as Amazon Web Services, AWS, dynamically manages the allocation of machine resources. Serverless computing allows to build and run applications and services without thinking about provisioning, scaling, and managing any servers.

Serverless computing still requires servers. The name "serverless computing" is used because the server management and capacity planning decisions are completely hidden from the developer or operator. Serverless code can be used in conjunction with code deployed in traditional styles, such as microservices.

More concretely, serverless computing involves services that are not running permanently, but rather are started on demand when some action is required. Once the action completed, the service is stopped, and memory or other resources dedicated to it are returned to the operating system. For some services, if state information is needed, the state is written to either stable storage or stored in a common database service.

Document <CIT> may be construed to disclose a network function virtualization NFV fault management apparatus, device, and method. The apparatus includes: a first receiving unit, configured to receive a fault subscription message sent by at least one subscription node in an NFV system, where the fault subscription message includes: a node identifier of the at least one subscription node and fault information to which a subscription is requested; a second receiving unit, configured to receive a fault publish message sent by at least one fault publish node in the NFV system; a matching unit, configured to perform matching between the fault information to which a subscription is requested and the fault publish message, and generate a fault notification message; and a notification unit, configured to notify the fault notification message to a corresponding subscription node associated with the node identifier of the at least one subscription node. According to the present invention, real-time and quick location and notification of node fault information can be implemented.

Document <CIT> may be construed to disclose a method of generating a network slice. The method comprises a network slice orchestrator (NWSO) receiving from a network slice manager (NWSM) a request for a new network slice, the NWSO adding a new service to the new network slice, the NWSO determining a network slice descriptor (NWSD) for the new network slice, the NWSO transmitting to a resource orchestrator (RO) a request for an instantiation of the network slice using enhanced network function virtualization management and orchestration (E-MANO). A method of modifying a network slice is also disclosed. The method comprises a NWSO receiving from a NWSM a request to add a new service to a network slice, the NWSO adding a new service to the network slice, the NWSO determining a NWSD for the network slice with the added service, and the NWSO transmitting to a RO a request for an instantiation of the added service on the network slice using E-MANO. A method of terminating a network slice is also provided. The method comprises a NWSO receiving from a NWSM a request to terminate a network slice, the NWSO determining the subnetworks to terminate, and the NWSO transmitting to a RO a request for a termination of the slice specific network functions (NFs).

Embodiments described herein describe a serverless Core network that can be applied in the fifth Generation Service Based Architecture or in any environment using Service Based Architecture such as One M2M. The solution can be applied between networks or between a network and a radio access network. The embodiments presented herein share the following elements of the solution:.

According to the disclosure, there are provided methods, a carrier and entities according to the independent claims. Developments are set forth in the dependent claims.

According to one aspect, a method for provisioning a service in a first network, such as a home network or serving network) is provided. The method comprises the steps of maintaining in a software repository, one or more software images (I1, I2,. Ii) of corresponding one or more services and where each service is identified by a service identifier (Si) and storing configuration information related to the one or more services in a database repository of the first network.

In another aspect, the method further comprises the step of publishing to a second network a list of the one or more services. The first network may share roaming agreement with the second network. Or, if the first network is a serving network, then the second network may be a radio access network, such as <NUM> RAN, interworking with the serving network.

In another aspect, the list of the one or more services comprises associated service description for each service, and the associated service description comprises information related to associated software image and information related to associated service trigger.

In another aspect, the method further comprises maintaining identical software images between the first network and the second network and may also include the step of providing the configuration information related to the one or more services upon request from the second network.

In accordance with one aspect, a method for providing a service by an entity in a serving network (or a second network or RAN) is provided. , the method comprises receiving and storing one or more software images (I1, I2,. ) for one or more services of a first network and where each service is identified by a service identifier (Si) and upon detecting a trigger indicating a request for a service of the one or more services, instantiating the software image of the service in the serving network.

In another aspect, the method further comprises receiving a list of the one or more service identifiers of home services as published by the first network wherein the list of the one or more services may comprise associated service description for each service, and where the associated service description comprises information related to associated software image and information related to associated service trigger.

In yet another aspect, storing the one or more software images may further comprise applying local modifications to the one or more software images and storing the one or more software images as modified in a local repository. Alternatively, the local modifications comprise adaptation to a special hardware used in the serving network.

In another aspect, the method comprises retrieving from the first network up-to-date configuration data for the instantiated software image of the service and may also comprise removing the software instance for the service once the service as requested is provided.

In one aspect, receiving the one or more software images is in response to sending a request to a software repository wherein the request is sent to an address provided in the information related to the associated software image published by the first network.

In accordance with one aspect, an apparatus is provided for performing the embodiments of the method in the first network.

In accordance with another aspect an apparatus is provided for performing embodiments of the method in the second network.

In the following description, numerous specific details are set forth. However, it is understood that embodiments may be practiced without these specific details. In other instances, well-known circuits, structures, and techniques have not been shown in detail in order not to obscure the understanding of the description. Those of ordinary skill in the art, with the included description, will be able to implement appropriate functionality without undue experimentation.

Further, when a particular feature, structure, or characteristic is described in connection with an embodiment, it is submitted that it is within the knowledge of one skilled in the art to implement such feature, structure, or characteristic in connection with other embodiments whether or not explicitly described.

It will be further understood that the terms "comprises," "comprising," "includes," and/or "including" when used herein, specify the presence of stated features, integers, steps, operations, elements, and/or components, but do not preclude the presence or addition of one or more other features, integers, steps, operations, elements, components, and/or groups thereof.

Embodiments in this disclosure relate to <NUM> core networks but, is also applicable in a more general case of any networks consisting of a "visited" network and a "home" network, also referred to a visited public Land Mobile Network, VPLMN and a home, HPLMN. In an embodiment, the term "serving" network is used to refer to the network where the UE is connected and where the service is provided to the UE. The serving network may be a visited network or a home network depending on whether the UE is roaming or not. The service provided to the UE in the serving network may be a home service instantiated at the serving network when the serving network is a visited network. The networks may also consist of a "Network Access Server" and a "central control point. ", or a "client" and a "server". The central idea of this disclosure also extends beyond the core network, into various control aspects in the Radio Access Network (RAN).

Current networks, such as for example 3GPP Evolved Packet Core used with <NUM> radio access network and specified in 3GPP TS <NUM> operate largely based on continuously running services on servers, e.g., Authentication, Authorization and Accounting, AAA servers, proxy servers, Mobility management servers, address assignment servers such as DHCP and routing nodes such as Serving gateway, SGW, Packet gateway nodes, PGW, etc. This may usually consume more resources than is necessary. Similar services are also required in the new Service based architecture, SBA, of the <NUM> core network specified in 3GPP TS <NUM> and illustrated in <FIG> for the roaming SBA architecture.

Additionally, current networks (<NUM> or <NUM>, or similar) have many services that are provided in the home network, and just routing the necessary signaling traffic from a visited network to the home network can be challenging at times. For instance, complex AAA systems are needed to manage the necessary relationships, and various intermediate services that are needed when requesting something from the home network can cause delay in message processing.

This specification describes embodiments of using serverless style implementation of some of these Core network services more specifically <NUM> Core network services by pre-distributing software images of the services to the roaming partners and instantiating the service in the roaming/visited network on a need basis. By doing so, unnecessary resource usage should be eliminated, idle capacity should be reduced if not eliminated, services scale more efficiently and service fulfillment would be allowed to happen closer to the actual end user, e.g., in the visited network. In other words, services can execute close to the user's actual location, and provide quick round-trip times and responsiveness.

The services are defined by the home operator, and when instantiated at the visited (or roaming) network, the software is run for the home operator. Additionally, pre-distribution of software images for the services to the roaming network enables quick launch of services compared to downloading them dynamically during the start of a session.

Database entries for the optional state information associated to the service allow the minimal amount of data necessary to be shared between networks or operator's networks. Additionally, changes to the database entries are handled efficiently as needed.

In summary, the following aspects of the solution proposed in the embodiments herein comprise:.

The following is a non-exhaustive list of home services that are planned to be offered in the <NUM> core network as specified in 3GPP which could be instantiated in the visited network:.

Embodiments of this specification relate to roaming situations where the same user roams into many different visited networks over time.

Embodiments also apply to a more general case of any access networks consisting of a "visited" network and a "home network", or even a "Network Access Server" and a "central control point". Embodiments described herein may also be applicable in various control aspects in the Radio Access Network, RAN. The embodiments herein are described for UEs roaming a "visited network" and the need to access services of the "home network".

In an aspect, a system method is provided where serverless computing is used to instantiate services (home services) on a need basis in a roaming network (visited network), the method comprises the following components:.

As previously indicated, the services could also be instantiated in a radio access network by the core network, in which case the method comprises the following components:.

<FIG> illustrates the components of a serverless service based architecture that can apply to a 3GPP <NUM> Core network or to other SBA networks in a roaming use case (visited network and home network) in accordance with one embodiment.

Services running using serverless computing (or serverless method) consist of a software image of the service and an associated optional database for storage of any data that might be needed to store state or configuration information for the service. The software images can be standardized software image formats for a given platform, e.g., containers are one way to represent the software.

<FIG> further illustrates distribution of at least one software image from a home operator network <NUM> to its roaming partners, i.e., visited network <NUM>. Only one visited network <NUM> is illustrated in <FIG>, but the home network can distribute to multiple visited networks <NUM> at a time. Each roaming/visited network <NUM> can maintain a directory of these images and can acquire updates in some fashion. One simple way to do this would be to run a file synchronization method such as well-known remote synchronization (rsync), but obviously more advanced methods, such as Docker Hub, can also be used.

As previously stated, the service consists of a software image and an optional database. The software image further consists of a base (shared by all/most users of the system, i.e., all networks including home and visited networks) and optional operator specific layers. The operator specific layers can contain extensions or modifications to the executable code that provides the service. For example, base image could be a minimalistic HTTP server and operator specific addition would consist of the Python runtime and audio processing codec. Using this system, the base image would be pre-provisioned in all visited operators network <NUM>. Additional layers would be applied as a need for them is detected (e.g., a roaming agreement is established).

Furthermore, the visited network <NUM> would be able to access the relevant database entries from the home network <NUM>. Various well- known methods could be used to allow the visited network <NUM> to access the database in the home network <NUM>. Some of those methods include but are not limited to:.

Whatever method is used to access the database, the necessary keys and information needed to access the database can be directly embedded in the software images, for example as part of the operator specific layers.

Once these prerequisite steps are in place, the visited network <NUM> can launch services as needed in serverless fashion, i.e., by launching the software image as a new container when a predefined event happens. The service runs in the visited network <NUM> as if it was executing in the home network <NUM>. For instance, if the service is about IP address management, the arrival of a DHCP packet may trigger the starting of the IP address management service. The DHCP server instance can then contact anything else that is needed for its execution, e.g., reach out to its corresponding database in the home network <NUM> as needed.

<FIG> illustrates a message flow for service provisioning from the home network <NUM> to the serving network <NUM> and service instantiation and execution in the visited network <NUM> in accordance with an embodiment.

Example of services are described above. Referring to <FIG>, the service provisioning and the service instantiation occur at different times independently of each other. Service provisioning may of course be performed when the service is triggered by the serving network, but that might introduce delays in execution and delivery of the service. In the embodiment illustrated in <FIG> for a roaming scenario, provisioning is performed independently of the service instantiation.

To enable serverless roaming, the home operator network <NUM> and roaming operator network <NUM> first establish roaming agreement shown at step <NUM>. Roaming agreements enable the home network <NUM> to publish services to a visited network <NUM>. If the home network <NUM> and the visited network <NUM> are <NUM> core network, see above for a possible list of services published by the home network <NUM>. At step <NUM>, the home network <NUM> stores software images that are used by the services to a software repository <NUM>. At step <NUM>, the repository <NUM> stores the images and associated service identifiers (Si). The software repository <NUM> can be operator specific or shared by a set of operators in which case the repository <NUM> may be maintained outside the home operator <NUM>. At step <NUM>, the home operator network <NUM> publishes a set of services to the visited network <NUM> and may include the service description. The service description consists of information of the associated software image (li) and service trigger (Ti).

At steps <NUM> and <NUM>, the visited network <NUM> retrieves the software images from the software repository <NUM>. The visited network <NUM> may already have some of the software images (li) due to earlier installations of the services. The service identifiers (Si) are globally unique but re-usable (e.g., same version of DHCP server can be identified with same identifier Si across operators). If the visited network <NUM> requires local modifications to the software images (Ii) (e.g., adaptation to specific hardware) these are applied in the optional step <NUM>. The software images (li) and the associated triggers (Ti) are stored in the visited network <NUM> at step <NUM>.

In an embodiment, if the user is non-roaming (i.e., user is @home) or the user is roaming but requesting services of the visited network <NUM>, e.g., location-based services), the services provided by the network to which the user is directly connected (i.e., home or visited) may be instantiated on a need basis within that network. In this case, the software images of the services will already be stored in the same network where the service is instantiated and the service provisioning steps <NUM> and <NUM> of <FIG> from the home network <NUM> to the visited network <NUM> will be omitted.

At step <NUM>, when a trigger event is detected, the visited network <NUM> launches the associated service as shown in step <NUM> using the associated software image. The service can potentially retrieve from home network (database) up-to-date. The trigger may be initiated by an access network <NUM> (e.g., a base station) a UE <NUM> or and/or a network entity in the visited network <NUM>. The access network <NUM> and/or UE <NUM> can interact with the service instantiated in the visited network <NUM> and can interact with the home network <NUM> using the service. When the interaction is over, the service is stopped at step <NUM> and the resources are released.

There can be various kind of triggers for each service. The events triggering the instantiation of the service may be detected through IP packet inspection or through explicit messages received from the UE <NUM>, or messages received at the access network <NUM> or at a network entity in the visited network <NUM>. The following are examples of such triggers:.

When the service is instantiated in the visited network, it is executed as if it is executed in the home network <NUM>.

<FIG> is a flow chart illustrating a method 400a of provisioning of a software image of a service from a home service to a visited network as executed by the home network in accordance with one embodiment. This method may be executed by one or more entities in the home network. The steps presented herein may be executed by different entities of the home network or by one entity comprising various functions. An example of an entity may be a Network function repository function, NRF, as specified in <NUM> Core network of 3GPP but enhanced to support the embodiments herein. Other entities may also be used.

The method 400a comprises the step 401a of maintaining in a software repository one or more software images (I1, I2,. Ii) of corresponding one or more services and where each service is identified by a service identifier (Si). The software images consist of two parts: the base (shared by all/most users of the system) and optional operator specific layers. The operator specific layers can contain extensions or modifications to the executable code that provides the service. For example, base image could be a minimalistic HTTP server and operator specific addition would add their Python runtime and audio processing codec. The base images would be pre-provisioned to all operators using this system and additional layers would be applied when need for them is detected (e.g., a roaming agreement is established).

The software repository may be maintained by the home network or may be maintained externally in which case it may be shared by many operator's networks. In addition, at step 402a the entity in the home network executes the step of storing the data required to configure a software image of a service in a separate database in the home network.

In the embodiment involving a home and a visited network, the home network maintains roaming agreements with one or more visited networks.

A list of services available or provided by the home network for its users may be published. A service description associated with a published service may be included in the publishing step if executed. The service description for each service comprises information of associated software image such as the address of the Software repository where the software image is stored, and information related to associated service trigger.

Following the publication of the services, if the software repository is maintained by the home network, the software repository and perhaps via the entity in the home network, may receive a request from a visited network for one or more software images for one or more services identified by the service identifier S1, S2,. The home network provides the requested one or more software images (I1, I2,. Ii) to the visited network, in particular to the requesting entity in the visited network.

When a software image is distributed to one or more visited network, a synchronization scheme must be maintained, so any changes to the software image must result in updating the distributed copy. Mechanisms such as rsync, Docker Hub and the likes can be used.

In an embodiment, an entity in the home network provides the configuration information related to the one or more services upon request from the visited network. This would be the case if a particular service is instantiated at the visited network.

<FIG> is a flow chart illustrating a method 400b of instantiating a home service in a visited network in accordance with one embodiment. This method may be executed by one or more entities in the visited network. The following steps may be executed by different entities of the visited network or by one entity comprising various functions. An example of an entity may be a Network function repository function, NRF, as specified in <NUM> Core network of 3GPP but enhanced to support the embodiments herein. Other entities may also be used.

The method 400b comprises the step 401b of receiving and storing one or more software images (I1, I2,. ) for one or more services of a first network and where each service is identified by a service identifier (Si). The one or more software images are received in response to sending a request to the software repository. The address of the software repository may be configured in the visited network entity or received by the home network. If the visited network entity received a published list of the one or more service identifiers identifying the home services that can be provided to a user roaming in that visited network, the received service publication may include the associated service description for each service. The service description may comprise information related to the associated software image and information related to associated service triggers. The address information of the software repository from where to retrieve the software images of the home network may be included in the associated service description information. The retrieval of the software images can be triggered by establishment of the roaming agreements or upon receiving the service publication by the home network.

After receiving the software images, the entity in the visited network may execute the step of applying local modifications to the received software images such as adaptation to specific hardware adaptation and store the modified software images I'<NUM>, I'<NUM>. to a local software repository. If no local modification is required, it stores the software images I1, I2,. as received from the home network. The service triggers for instantiating the software image of the service are also stored locally.

At step 402b, upon detecting by an entity in the visited network a trigger indicating a request for a service in the home network but for which a software image is available, instantiating the software image of the service in the visited network. Once instantiated, the entity may execute the step of retrieving from the home network up-to-date configuration data for the instantiated software image of the service. Once the software image of the service is configured, it provides the service as if it was provided by the home network. Once the service is provided, the instantiation is removed, hence preventing the associated resources from idling.

<FIG> is a schematic block diagram of a network entity <NUM> in a first network or second network or serving network according to some embodiments of the present disclosure. As illustrated, the network entity <NUM> includes one or more processors <NUM> (e.g., Central Processing Units (CPUs), Application Specific Integrated Circuits (ASICs), Digital Signal Processors (DSPs), Field Programmable Gate Arrays (FPGAs), and/or the like), memory <NUM>, and a network interface(s) <NUM>. In some embodiments, the functionality of the network node <NUM> described above may be fully or partially implemented in software that is, e.g., stored in the memory <NUM> and executed by the processor(s) <NUM>.

<FIG> is a schematic block diagram that illustrates a virtualized embodiment of the network entity <NUM> according to some embodiments of the present disclosure. As used herein, a "virtualized" network entity <NUM> is a network entity <NUM> in which at least a portion of the functionality of the network entity <NUM> is implemented as a virtual component (e.g., via a virtual machine(s) executing on a physical processing node(s) in a network(s)). As illustrated, the network entity <NUM> includes one or more processing nodes <NUM> coupled to or included as part of a network(s) <NUM>. Each processing node <NUM> includes one or more processors <NUM> (e.g., CPUs, ASICs, DSPs, FPGAs, and/or the like), memory <NUM>, and a network interface <NUM>.

In this example, functions <NUM> of the network entity <NUM> whether it is the network entity in the first network or in the second network described herein are implemented at the one or more processing nodes <NUM> (e.g., distributed across multiple processing nodes <NUM>) in any desired manner. In some particular embodiments, some or all of the functions <NUM> of the network entity <NUM> described herein are implemented as virtual components executed by one or more virtual machines implemented in a virtual environment(s) hosted by the processing node(s) <NUM>.

In some embodiments, a computer program including instructions which, when executed by the at least one processor <NUM>, <NUM> causes the at least one processor <NUM>, <NUM> to carry out the functionality of the network entity <NUM> or a processing node <NUM> according to any of the embodiments described herein is provided. In some embodiments, a carrier containing the aforementioned computer program product is provided. The carrier is one of an electronic signal, an optical signal, a radio signal, or a computer readable storage medium (e.g., a non-transitory computer readable medium such as the memory <NUM>, <NUM>).

<FIG> is a schematic block diagram of the network entity <NUM> according to some other embodiments of the present disclosure. The network entity <NUM> includes one or more modules <NUM>, each of which is implemented in software. The module(s) <NUM> provide the functionality of the network entity <NUM> described herein in the first network or home network and the network entity <NUM> in a second network, a serving network or a visited network.

The following acronyms are used throughout this disclosure.

Claim 1:
A method (400a) for provisioning a software image (I1, <NUM>, ...Ii) of a service from a home service to a visited network (<NUM>) as executed by a home network (<NUM>), the method comprising:
- maintaining (401a) in a software repository (<NUM>), one or more software images of corresponding one or more services and where each service is identified by a service identifier (Si), wherein the software images are containers according to the Open Network Function Virtualization Forum, OPNFV;
- storing (402a) configuration information related to the one or more services in a database repository of the home network; and
- publishing, to the visited network, a list of the one or more services; and
- maintaining identical software images between the home network and the visited network.