WO2021115553A1

WO2021115553A1 - A service based interface for a network entity

Info

Publication number: WO2021115553A1
Application number: PCT/EP2019/084236
Authority: WO
Inventors: Artur Hecker; Xun XIAO; Chenghui Peng; Jianjun Wu
Original assignee: Huawei Technologies Co Ltd
Current assignee: Huawei Technologies Co Ltd
Priority date: 2019-12-09
Filing date: 2019-12-09
Publication date: 2021-06-17
Anticipated expiration: 2022-06-09

Abstract

The present invention relates to the field of mobile communication, in particular to 5G mobile networks. A service based interface, SBI, associated to a network entity (101) is provided. The SBI (100) is configured to identify a local resource (102) of the network entity (101) and at least one local network function, NF, (103) of the network entity (101); to obtain a service request (104) from a local NF (103); to discover a service (105) and/or information related to a service (106) based on the service request (104); to process the service request (104) based on at least one of: a priority of the service request (104), the discovered service (105) and/or information related to a service (106), and the identified local resource (102) and at least one local NF (103).

Description

A SERVICE BASED INTERFACE FOR A NETWORK ENTITY

TECHNICAL FIELD

The present disclosure relates to the field of mobile communication, in particular to 5G mobile networks. More specifically, a service based interface, SBI, for a network entity (NE), e.g. according to 5G, is provided which allows for resource management and service handling at a network function (NF) instance running at a local node.

BACKGROUND

The next generation of mobile networks (5G) is expected to support many new types of connections between various devices such as cars, wearables, sensors and actuators from both private and industrial environments. The new types of connections usually imply very distinct service requests on latency, data rate and so on, which naturally ask for different treatments and thereby pose challenges to the control of the 5G networks.

In particular, supporting various new types of services means a deep impact on the core network architecture. In today’s mobile network, services mainly refer to the access of portable devices in human hands for data and voice services only. Core networks can apply basically the same treatment to portable devices following the best-effort principle. Hence, those services are predictable and how to respond them can be well preplanned. With various new service requests, however, service patterns turn to be quite heterogeneous. Consequently, service requests to the 5G network are hard to be predicted. A proper way to meet the requirements is to agilely respond to the incoming services in a dynamic way.

Efficiently responding to distinct and unpredictable service requests is not an easy task. Recently, Software-Defined Networking (SDN) and Network Function Virtualization (NFV) are considered to realize a flexible and programmable network infrastructure. The idea behind SDN is to move the complexity of network flow treatment to a logically centralized element called SDN Controller (SDNC). Hence, the SDN view reduces all network elements to flow treatment devices, which are only responsible for flow processing. With these concepts, SDN fuses all management and control plane (CP) intelligence at the SDNC. In return, the common abstraction and the locally available data simplify the development of network control and management applications. NFV further turns existing network functions (NFs), which were mainly implemented by dedicated and specialized hardware before, into virtualized function modules that can be easily deployed or removed as needed.

Due to heterogeneous service requests (not limited to human-to-human mobile communications), the architecture of the next generation wireless mobile network (e.g. 5G) aims to be more flexible, dynamic and agile. Therefore, 3GPP SA2 defines the architecture ofthe 5Gnetwork as service-based architecture (SBA), wherein NFs should be modularized, and any service should be composed by combining required NFs. In specific, NFs may offer different functionalities thus the NFs will be able to provide different services. For each NF, its service may be self-contained, acted upon and managed independently from other NF services offered by the same NF (e.g. for scaling, healing). Multiple NFs may together form an NF chain to provide a service as a whole.

The standardized interface of a 3GPP NF is called a service-based interface (SBI), which defines services provided from an NF to other NFs. An equivalent representation in 3GPP specification is a reference point - a conceptual point at the conjunction of two non-overlapping functional groups. For example, an access management function (AMF) provides information subscription and notification over its SBI.

Over SBI, the way how two NFs communicate with each other is also defined in 3GPP. Specifically, HTTP/5 can be used as the transport protocol over SBIs. The interfaces may be designed by using the RESTful Application Program Interfaces (API).

SBI simplifies the functionality of an NF because all interactions will be handled by the SBI (happening over the references points) while NFs can focus on the processing logic of the network services. However, realizing the SBI is not a trivial task because the SBI has to take care of both the communication between NFs and the support to local running NFs on a network entity. This is more complicated than just realizing an independent/local processing logic of an NF. In general, the realization of an SBI includes: 1) the resource-to-resource (R2R) part and 2) the in-resource control part. The R2R part is responsible for establishing the connectivity of one NF to another NF, service discovery of network services in the network domain, and messaging among NFs. In contrast, the in-resource control part of SBI aims to realize the requirements of SBI defined by 3 GPP for local resource management and act as a middleware working together with the R2R part to support NF instances running in the host node.

The concept of service modularization exists widely in the engineering world where non-overlapped functions/modules are decoupled and designed independently so that they can evolve separately and have least interference to each other. Functional decoupling requires a better interface design for the system and efficient engineering solutions for implementation. An existing technique, which tries to build the desired SBI, particularly the in-resource control part, is discussed in the following.

On-demand pre-configuration is an approach to realize an interface implicitly during the deployment of modularized functions. For example, in order to turn a cluster of physical commercial of the shelf (COTS) products into a virtualized platform as cloud resources, every node must be configured with a virtualization tool. After manually installing the virtualization tool, all the resource is linked to a so-called cloud controller. By the cloud controller, a virtual machine (VM), which normally encapsulates an application (App) service, is deployed to a resource node (In a 3GPP scenario, the App can be an NF instance). If two Apps (i.e. two NF instances) work together and thus have to exchange information, a routing path will be established by the controller as well. The interface becomes more complicated if multiple NF instances have to communicate with each other in a multicast fashion.

In this case, the SBI is associated with the deployed NF instances on-demand. In other words, if a new pair of NF instances are deployed, a new interface might be configured individually. With an increasing number of service requests (more NF instances must be deployed, thereby more interfaces must be configured), pre-configuration in such a way is inefficient. This becomes even more evident in case of NF instance deployment under a dynamic situation, such as when NF instances are migrated in the cloud cluster from time to time, which leads to an unnecessary coordination of their interfaces as well. On-demand configuration solutions only work in a cloud environment. However, in many cases, dedicated physical devices are still widely used in many operators’ networks. Unfortunately, configuration after virtualization via a controller cannot cover the latter case. Secondly, the on-demand pre-configuration separates the virtualization and interface establishment into two independent steps.. Thirdly, the interface specifically configured for VM deployment decreases the opportunity of multiplexing of the interface.

That is, none of the above solutions provides the requirements necessary for realizing the in-resource control part of an SBI.

SUMMARY

In view of the above-mentioned problems and disadvantages, it is an objective of embodiments of the present invention to improve the conventional SBI.

An objective is achieved by the embodiments of the invention as described in the enclosed independent claims. Advantageous implementations of the embodiments of the invention are further defined in the dependent claims.

A first aspect of the present invention provides a service based interface, SBI, associated to a network entity, wherein the SBI is configured to identify a local resource of the network entity and at least one local network function, NF, of the network entity; obtain a service request from a local NF; discover a service and/or information related to a service based on the service request; process the service request based on at least one of: a priority of the service request, the discovered service and/or information related to a service, and the identified local resource and at least one local NF.

In particular, the local NF is an NF operated by the network entity.

In particular the local resource of the network entity includes a physical resource of the network entity and/or a virtual resource of the network entity. In particular the local resource includes at least one of: a CPU, a memory, a storage, an I/O device, a network device, a forwarding logic. In an implementation form of the first aspect, the SBI is further configured to provide access to the identified local resource to the identified local NF.

In other words, the identified local NF can access the identified local resource, based on a decision of the SBI.

This is beneficial, as a more effective way of handling the service request can be realized, when then SBI can also provide access to an identified resource, in addition to identifying the resource.

In a further implementation form of the first aspect, the SBI is further configured to provide access to the identified local resource to the identified local NF by providing a resource handler, and/or by means of a hypervisor mechanism.

In other words, the identified local NF can access the identified local resource, by means of a resource handler, and/or by means of a hypervisor mechanism.

This ensures that the identified local NF can effectively access the identified local resource.

In a further implementation form of the first aspect, the SBI is further configured to discover the service or the information related to a service from a local NF service table.

In particular, the local NF service table may be called NF instance service routing table (nfiSRT).

This is beneficial, as the local NF service table is a common available source for service routing information which can be accessed by all NFs of a network entity. Thus, the NFs do not have to maintain this information by themselves.

In a further implementation form of the first aspect, the SBI is further configured to preconfigure the local NF service table based on information obtained from at least one other network entity. This ensures that the information stored in the local NF service table can be gathered from various resources.

In a further implementation form of the first aspect, the SBI is further configured to initiate the discovery of the service or the information related to a service from at least one other network entity, if the service or the information related to a service cannot be discovered from the local NF service table.

This ensures that service discovery can be based on information obtained from various resources.

In a further implementation form of the first aspect, the SBI is further configured to provide the service or information related to a service to the requesting local NF.

This ensures a versatile and effective manner of service discovery.

In a further implementation form of the first aspect, the service request is a request for sending information to another NF, or for receiving information from another NF.

This is beneficial, as communication between NFs can be facilitated by the SBI.

In particular, the service includes sending information to another NF, or receiving information from another NF.

In particular, the information related to a service includes at least one of: source of a service, destination of a service, source IP address of a service, destination IP address of a service, source port of a service, destination port of a service.

In a further implementation form of the first aspect, the SBI is further configured to determine the priority of the service request based on a type of the service request, and/or based on the local NF that provides the service request.

This enables various ways of reliably detecting a priority of the service request. In a further implementation form of the first aspect, the SBI is further configured to assign a priority to the service request using a queuing mechanism.

In particular, several queues can be used, each of which relating to a different priority.

This provides a reliable and effective way of assigning a priority to a service request.

In a further implementation form of the first aspect, the SBI is further configured to adjust resource allocation of a local NF based on the identified local resources.

Thereby the SBI can improve overall resource consumption in a communication network.

In a further implementation form of the first aspect, the SBI further includes an application programming interface, API, for communication with a NF or a network entity.

This allows for versatile ways of communication with the SBI.

A second aspect of the present invention provides a method for operating a service based interface, SBI, associated to a network entity, wherein the method comprises the steps of: identifying, by the SBI, a local resource of the network entity and at least one local network function, NF, of the network entity; obtaining, by the SBI, a service request from a local NF; discovering, by the SBI, a service and/or information related to a service based on the service request; processing, by the SBI, the service request, based on at least one of: a priority of the service request, the discovered service and/or information related to a service; and the identified local resource and at least one local NF.

In an implementation form of the second aspect, the method further includes providing access, by the SBI, to the identified local resource to the identified local NF. In a further implementation form of the second aspect, the method further includes providing access, by the SBI, to the identified local resource to the identified local NF by providing a resource handler, and/or by means of a hypervisor mechanism.

In a further implementation form of the second aspect, the method further includes discovering, by the SBI, the service or the information related to a service from a local NF service table.

In a further implementation form of the second aspect, the method further includes preconfiguring, by the SBI, the local NF service table based on information obtained from at least one other network entity.

In a further implementation form of the second aspect, the method further includes initiating, by the SBI, the discovery of the service or the information related to a service from at least one other network entity, if the service or the information related to a service cannot be discovered from the local NF service table.

In a further implementation form of the second aspect, the method further includes providing, by the SBI, the service or information related to a service to the requesting local NF.

In a further implementation form of the second aspect, the service request is a request for sending information to another NF, or for receiving information from another NF.

In a further implementation form of the second aspect, the method further includes determining, by the SBI, the priority of the service request based on a type of the service request, and/or based on the local NF that provides the service request.

In a further implementation form of the second aspect, the method further includes assigning, by the SBI, a priority to the service request using a queuing mechanism.

In a further implementation form of the second aspect, the method further includes adjusting, by the SBI, resource allocation of a local NF based on the identified local resources. In a further implementation form of the second aspect, the SBI further includes an application programming interface, API, for communication with a NF or a network entity.

A third aspect of the present invention provides a computer program product including program code for performing the method according to the method of the second aspects and its implementation forms, when the program code is run by a processor.

According to still a further aspect, the invention also relates to a (non-transitory) computer readable medium and said mentioned computer program code, wherein said computer program code is included in the computer readable medium, and the computer medium comprises of one or more from the group: ROM (Read-Only Memory), PROM (Programmable ROM), EPROM (Erasable PROM), Flash memory, EEPROM (Electrically EPROM) and hard disk drive.

The second aspect and third aspects and their implementation forms include the same advantages as the first aspect and its respective implementation forms.

It has to be noted that all devices, elements, units and means described in the present application could be implemented in the software or hardware elements or any kind of combination thereof. All steps which are performed by the various entities described in the present application as well as the functionalities described to be performed by the various entities are intended to mean that the respective entity is adapted to or configured to perform the respective steps and functionalities. Even if, in the following description of specific embodiments, a specific functionality or step to be performed by external entities is not reflected in the description of a specific detailed element of that entity which performs that specific step or functionality, it should be clear for a skilled person that these methods and functionalities can be implemented in respective software or hardware elements, or any kind of combination thereof. BRIEF DESCRIPTION OF DRAWINGS

The above-described aspects and implementation forms of the present invention will be explained in the following description of specific embodiments in relation to the enclosed drawings, in which

FIG. 1 shows a schematic view of an SBI according to an embodiment of the present invention. FIG. 2 shows a schematic view of an SBI according to an embodiment of the present invention in more detail.

FIG. 3 shows a schematic view of an SBI according to another embodiment of the present invention.

FIG. 4 shows a schematic view of an SBI according to an embodiment of the present invention in more detail.

FIG. 5 shows a schematic view of a method according to an embodiment of the present invention.

DETAILED DESCRIPTION OF EMBODIMENTS

FIG. 1 shows a schematic view of an SBI 100 which is associated to a network entity 101. The SBI 100 may also be called SBI agent 100, wherein in particular the in-resource control part of the SBI agent 100 is referred to by the wording “SBI 100”. The network entity 101 may also be called network node 101, resource node 101 or resource entity (RE) 101. Although in FIG. 1 the SBI 100 is illustrated inside the network entity 101, the association of the SBI 100 to the network entity 101 can mean that the SBI 100 is part of the network entity 101, or that the SBI 100 is external to the network entity 101 (that is, the SBI 100 is not comprised by the network entity 101), but e.g. communicates with the network entity 101. The SBI 100 is in particular configured to identify a local resource 102 of the network entity 101 and at least one local NF 103 of the network entity 101, to obtain a service request 104 from a local NF 103, to discover a service 105 and/or information related to a service 106 based on the service request 104, and to process the service request 104 based on at least one of: a priority of the service request 104, the discovered service 105 and/or information related to a service 106, and the identified local resource 102 and at least one local NF 103. It is to be noted that the local resource 102 and the local NF 103 are comprised by the network entity 101, but not necessarily by the SBI 100. The service request 104 is sent by the local NF 103 to the SBI 100. Although the service 105 and the information related to a service 106 are illustrated outside the network entity 101, either one or both of them can also be operated or provided by the network entity 101. The service 105 and/or the information related to a service can however also be operated/provided outside the network entity 101, as shown in the figure. Although it is illustrated in FIG. 1 that the service request 104 is obtained from a local NF 103, the service request 104 can also be obtained from an external entity, e.g. a remote network entity.

The SBI 100 is now going to be described in more detail in view of FIG. 2 to 4 below. All of the features which are discussed below are optional features of the SBI 100.

Embodiments of the present invention can be operated in an environment containing a group of network nodes 101 and network links. Network nodes 101 can also be referred to as resource nodes (REs) 101 in the following discussion. Networks nodes 101 e.g. can have networking interfaces (capabilities) and storages, where the latter capability is optional. Network links are referred to as a connection linking two resource nodes 101. Every network node may have a minimum compute capability to execute lightweight control program where a local resource is accessible over an internal interface at operating system level and at least one network interface can be used by the control peer stack (i.e. operating system level). Every node does not need to be isolated but there is at least one interface connecting to an environment where there are more network nodes.

Embodiments of the present invention provide a distributed self-organized in-resource control layer, wherein the in-resource control layer is integrated in every network node 101. The provided features are illustrated in FIG. 2. The RE 101 and the SBI 100 of FIG. 2 include all features of the corresponding entities of FIG. 1. In FIG. 2, a local SBI agent 100, acts as a local resource interface as well as an interface to other network nodes (SBI agents) 101*.

Every SBI agent 100 is further adapted to 1) abstract local resource 102 and provide access handlers to local NF instances 103, meanwhile both resource states and running NF instance states are monitored; 2) delegate and handle service request 104 from the NF instances 103 with a progressive service discovery mechanism where the information of the service request 104 is first looked up in the local NF service tables 401 (which is e.g. illustrated in FIG. 4), otherwise, the SBI agent 100 triggers distributed service discovery with respect to the service requests 104. After that, the discovery result is returned to the requesting NF instance 103; 3) deliver and dispatch information with prioritization mechanism; 4) (optional) orchestrate (e.g. scaling in / out) the running NF instances 103 among all network nodes 101, 101*.

FIG. 3 shows the RE 101 and the SBI 100 as already illustrated in FIG. 1 and FIG. 2 in more detail. The entities shown in FIG. 3 include the features of the corresponding entities of FIG. 1, respectively of FIG. 2. FIG. 3 in particular shows some of the modules which are comprised by the SBI 100.

A first module of the SBI 100 is a local resource and state control module. This module is responsible for identifying the resource capability of the network node 101 and its full state monitoring. In specific, when a network node 101 is bootstrapped (e.g. powered on with a physical device or deployed and run as a virtual node), this module starts to identify the resource 102 of the node, for example, how many CPUs / memory / network interfaces the network node has. This information is normally accessed from the operating system level and corresponding handlers to the respective resource are formed and prepared for higher layer access later on. In addition to the resource capability identification and abstraction, this module also monitors the states of the deployed NF instances 103. Expected tasks include how much resource (CPU/Memory /Network Interfaces) an NF instance is consuming, if there is any resource conflict happening between two different NF instances and there is any special requirement from an NF instance, how the resource isolation performs, etc.. All this information / states will be collected and saved as the execution history of the network node. This information is prepared by the in-resource part of the SBI 100, but it can be accessed by the R2R part of the SBI 100 and even actively shared with other network nodes, which depends on the scenario of how this information shall be utilized. On the other hand, if local adjustment is required, the state of the local resource consumptions and NF instances will be used as well.

A second module is a service request 104 handling module (labeled “Req. Handler” in FIG. 3). This module directly serves the local running NF instances 103. NF instances 103 send communication requests to some other NF instances 103, probably running at other network nodes 101* in FIG. 2. The requests from the NF instances 103 can be sending and retrieving information from another NF instances, and NF service discovery, usually source and destination information are specified in the request. Note that, for service discovery, the destination information can be a general flag or a special tag specified in the request. Each request will be analyzed and determined how this request will be handled.

To determine how the request should be handled, embodiments of the present invention provide a progressive service discovery mechanism (labeled “PSDM” in FIG. 3) for the request handling. The mechanism utilizes the information that can be provided by the R2R part of the SBI 100 to check if the service information is already available at the local side, and if so, an inefficient service discovery step can be avoided. This is an example to show the two parts of SBI 100 work together. Since the SBI 100 will build an NF instance service routing table (called nfiSRT) 401 with the R2R part, if the destination information of a service request 104 from a local NF instance 103 can be found in nfiSRT, the service request module can directly deliver the request to the corresponding NF instance 103, according to the routing information there. Otherwise, a service discovery request will be triggered and executed by the SBI R2R part.

The progressive service discovery mechanism improves the efficiency of handling the service requests 104. Traditionally, a service request 104 is delivered according to the destination IP address, therefore, an NF instance 103 has to maintain the IP address information for relevant NF services 105 by itself. If such information is not available, a discovery procedure must be done so that the destination information can be known. This causes a drawback that a destination is known by some of NF instances 103 while not available to all NF instances 103 that could be interested in the information as well. Furthermore, this information is not proactively prepared and established, but based on individual communication requirement and separately done with the network routing layer. The nfiSRT 401 aims to resolve this issue and provide a commonly available service routing information to all NF instances 103 in the network node 101, and such information will be distributedly established by the SBI R2R part. With the help from nfiSRT 401, NF instances 103 are free to do service discovery while its service requests are fully delegated by the service request module together with the SBI R2R part.

A third module is a messaging dispatcher module. This module is responsible for how the service requests 104 (or in general messages) are delivered to remote and at local. A priority of service requests 104 from different NF instances 103 is different. Some requests ask for a higher priority especially for control purposes of mobile telecommunication networks. Therefore, requests are not be treated as best effort. This module allows to differentiate the priority of the service requests 104 from different NF instances 103. A queueing mechanism is used here to assign different priorities to the coming service requests, classifying them into different queues where requests in each queue have different priorities, thus will be served by a biased order.

In addition to prioritization for the local service requests 104, service requests 104 from remote will also be differentiated with different priorities. Service queues for the remote incoming requests will be created, and requests enqueued in there will be dequeued with different priorities and dispatched to respective NF instances (i.e. recipients).

This module also works with the R2R part in order to access the networking capability so that the requests can be eventually delivered and received.

An optional module is an orchestration module (labeled with “NF Orch.” in FIG. 3). According to the states of the local resource 102 and resource consumptions of current local NF instances 103, orchestration can be done to optimize the resource utilization. It is to be noted that orchestration is not necessarily to be done by SBI 100 at this level, because with the limited view of resource states and consumptions, an optimal decision is not easy to make. Instead, it is appropriate to make the orchestration decision based on global information from the network domain. However, a local optimization is still possible, which depends on the optimization objectives. Therefore, such a feature is an optional feature.

All these features are encapsulated by an API layer that exposes the local interfaces to the NF instances 103. Any NF instance 103 can access the service via the API exposed by the in-resource control part of the SBI.

An important aspect of embodiments of the present invention is to give a synthetic solution providing a distributed realization of the SBI 100 that particularly focuses on the in-resource control part (while the other part is a R2R part focusing on the node-to- node interactions). The embodiments of the present invention propose a local SBI agent 100 acting as a middleware layer to provide resource management and support services 105 for the NF instances 103 running at the local side. It is specifically designed to consider the requirements of future wireless mobile networks where NF services 105 are modularized and in-network composed to provide network services.

As outlined above, the SBI agent 100 (the in-resource control part) has three main features supported by the in-resource control part. The first feature is general resource abstraction, management and states monitors for both local resource and NF instances 103; the second feature is service request handling the service requests 104 from the NF instances 103. This feature includes a progressive service discovery mechanism utilizing the information provided by the SBI R2R part so that unnecessary (repeated and/inefficiently) service discovery activities can be avoided. The third feature is a prioritization mechanism for message delivery and dispatch. Services of the proposed features are encapsulated as a northbound API layer to enable easy access by NF instances.

First, a generic resource abstraction layer is available. This is different from the most cloud virtualization tools where a certain hypervisor and a management tool must be installed. After that the resource node can be accessible. Also later utilizations of the resource only support virtualization manner. In other words, if the resource is not virtualized, the resource cannot be accessed. The embodiments of the present invention do not differentiate the type of a network node while no matter if the network node is a physical device or a COTS that will be virtualized, the SBI agent 100 provides its abstraction and accessible handlers of the resources. Note that, abstraction is not what virtualization does, instead, it is a representation of the resource of the network.

Second, the embodiments of the present invention not only monitors the states of the host node 101 where the whole resource comes from, but also collects the states of the running NF instances 103, which could be VMs running over a virtualized node or just isolated Apps for different network services running in the physical device. The full stack information will be collected and saved, and available to be accessed by other modules of SBI agent.

Third, the embodiments of the present invention provide a common layer to delegate service requests of running NF instances 103. At the same time, by utilizing the information prepared by the SBI R2R part, a more efficient service request processing is proposed so that unnecessary service discovery can be avoided. In prior art methods, service requests from respective NF instances will be directly mapped to the network routing layer, and if the routing information is not available to an NF instance, a discovery process for the NF instance will take place. The embodiments of present invention open such an information and makes it public to all local NFs, therefore, if another NF service is either prepared, found and/or proactively discovered once, this information will be available to all NFs. Therefore, to handle a service request 104, a progressive service discovery mechanism is used where it always starts with a local matching and search.

Fourth, the embodiments of the present invention provide a prioritization possibility if service requests 104 must be handled with different priorities, which is important to some requests from the control plane of the future wireless mobile networks. Prior art schemes do not explicitly provide such a mechanism by taking the requirements of the network services into considerations. Rather a best-effort service model is assumed and if any differentiation is needed, some extra mechanisms/protocols must be introduced manually or handled by the controller. Different from that, our solution specifies egress and ingress service requests to different queues, and for the requests in each queue, a biased service order will be applied so that requests asking for a higher priority will be served at first. It is worth to note that the in-resource control part of the distributed SBI 100 realization will never work alone, there are many places where the in-resource control part can be supported by the R2R part so that a certain functionality can be achieved.

In the following, further optional embodiments of the invention are discussed. First implementation options of the present invention are discussed and after that it is illustrated how the embodiments of the present invention can be realized in concrete scenarios at different scales.

Implementation of Modules of SBI In-resource Control Part: a) Resource abstraction and state monitoring module:

An implementation of the first module is resource abstraction and state monitoring. This can be either 1) an operating system based resource abstraction layer and/or 2) a virtualization hypervisor-type abstraction layer.

For the first type of resource abstraction, it is not preferred to virtualize the resource but to directly retrieve the resource handlers from the hardware. For the second type of resource abstraction, which are widely used nowadays in clouding computing, are hypervisor techniques. Embodiments of the present invention can select one of the existing solutions and use it as the resource abstraction and state monitor module. There are system level interfaces provided by those typical resource abstraction layer products, therefore required state information can be easily retrieved from there. Collected information will be kept by this module and provided to other modules if necessary. b) Service request handling module

This module implements a queueing layer to differentiate the priority of service requests 104 from different NF instances 103. In addition to the queueing layer, a progressive service discovery mechanism has to be implemented and integrated with the procedure of handling service requests 104.

For the queueing layer, queueing toolboxes or protocols can be utilized. According to the specific requirements, the number of queues for both message delivery and message local dispatch can be configured either in a static way or in a dynamic way. This module provides interfaces to receive the service requests 104 from both local NF instances 103 and from SBI R2R part in case any incoming service request arrive in.

For the progressive service discovery mechanism, there cannot directly be used any existing solution because it is a combined solution, which utilizes the information from another module. For this module, its implementation can be a submodule of the service request handling module and links to the queueing layer. Whenever a service request is going to be delivered, it goes through the procedure of the progressive service discovery. c) Northbound APIs to NF Instances:

For this part, HTTP5 and RESTful APIs can be selected. The classes of the exposed APIs correspond to the logical functions of the proposed modules. In specific, they are: APIs for resource handler (including local filesystem), APIs for state monitoring, APIs for local service requests (sending/receiving).

In summary, the implementations of the modules here integrate some other modules introduced in the previous section in order to optimize the reusability of the implementation. For example, messaging delivery and dispatching can reuse the same queueing layer, although different queues will be used in reality. Therefore, the number of actually implemented modules is less than the number of logical modules introduced before. The whole architectural implementation is illustrated in FIG. 4.

In the following, an operating example of the present invention is given:

The implemented modules work together to provide a fully functional in-resource control part of an SBI agent 100. With the selected techniques for the modules, as an example, it is now illustrated how the modules shall work together. In the following discussion, we assume that the choices in the following table are the solutions of each module:

With a Kernel-based Virtual Machine, KVM, the SBI agent 100 can access the system information of the network node 101 (e.g. CPU, Memory /Disk Storage and Network interface). All this properties can be retrieved by system calls to the KVM library. For example, in order to check the node information of the host, an API (for example localhost. hypervisor. nodeinjo( ) ) can directly be called to return the general information of the node. In addition, another API (for example “ localhost.list_networks( )”) can be called to check the networking information such as interfaces, routing and so on. For resource abstraction, APIs can be used provided by the KVM library to review every aspects of the resource node. KVM library also provides monitoring tools. With KVM library, even local NF instances can be managed such as creation, stop, and termination of the virtual instances.

A queueing layer and asynchronous messaging capability are e.g. provided by message queuing protocols (MQP). An MQP acts as a local messaging server to receive requests from clients (i.e. NF instances). With a certain library of an MQP, a client (i.e. an NF instance) can connect to an MQP messaging server with an API - MQP.BlockingConnection(MQP.ConnectionParameters( ‘localhost’)). After that, a queue can be created by calling channel.queue_declare(queue= ’queue_name’). In order to send a request to the queue given by the name of queue_name, the NF instance can publish with an API - channel.basic_publish(exchange=”, routing_key=’dest_id’, body=’request_body’). Multiple queues can be also created in order to have service isolation between different NF instances. Note that, the properties of a queue (e.g. queue length) can be configured or modified before or after the queue is created.

For priority differentiation, a queue can be given 0 or more priorities. To declare a priority queue, the x-max-priority optional queue argument can be used. This argument should be a positive integer between 1 and 255, indicating the maximum priority the queue should support. NF instances 103 then can publish prioritized messages using the priority field of basic.properties.

Note that NF instances 103 can be both senders and receivers. An NF instance 103 is a sender when it sends its service request to the queueing layer. On the other hand, an NF instance 103 is a receiver when the service request 104 from remote is dispatched to the local NF instance 103. Furthermore, the queueing layer bridges local NF instances 103 to the R2R part of the SBI agent 100 to eventually reach out the network node. Between the queueing layer and the R2R part, every egress service request will go through the progressive service discovery mechanism.

For the API part, it basically exposes all necessary services provided by the sub-modules with a HTTP format. There can be a local service point (e.g. Tocalhosf) as a listener, and RESTful APIs can be generated accordingly, which will not be listed here.

Embodiments of the invention thus, in summary, provide an SBI with an in-resource control part. The in-resource part of the SBI according to embodiments of the present invention is agnostic to resource types. In other words, the in-resource control supports both virtualized resources (as done by virtualization platforms) and traditional dedicated physical devices. In the former case, the in-resource part of the SBI can be initiated and can link to a virtual node after it is deployed. In the latter case, the in-resource part can be a firmware working directly after the product is shipped and installed. This is beneficial, as it is not supported by the virtualization schemes according to the prior art.

The in-resource part of the SBI according to embodiments of the present invention can abstract local resources autonomously. This means that once a node is powered on, handlers to its local resource (including computing, networking and or storage) become available. In this way, anNF instance can easily access those resources whenever needed and its own implementation is simplified. Autonomous local resource abstraction also facilitates the resource scheduling when a location to deploy an NF will have to be decided.

In addition to the resource abstraction, serving and monitoring local NF instances is also supported by embodiments of the present invention. The states of local NF instances have to be monitored and collected, which will be needed for other usages such as service scheduling and information statistics. Therefore, the in-resource part not only can monitor the states of the local resources, but also can collect the information of the running services on the node. Storing the collected information is also required, which will involve storage management that partly works with the R2R part of the SBI. Further, a local message/event responding/dispatching mechanism is provided by embodiments of the present invention. This particularly means that the in-resource part of the SBI can provide diverse communication schemes and prioritization for the NF instances running in distributed nodes. In the prior art, neither virtualization technology nor autonomic networking provides such an option while advanced communication modes (e.g. event subscription and multicast) have to be handled case by case. The embodiments of the present invention allow that the in-resource part of the SBI supports most common communication modes and the capability of prioritization in message delivering and dispatching.

That is, the in-resource part of the SBI according to embodiments of the present invention forms a middle-layer ubiquitously running on every resource node (both physical nodes and virtualized nodes) to provide NF instances (co-working with the R2R part of the SBI) smooth support.

FIG. 5 shows a schematic view of a method 500 according to an embodiment of the present invention. The method 500 is for operating a service based interface, SBI, 100 associated to a network entity 101.

The method 500 comprises the step of identifying 501, by the SBI 100, a local resource 102 of the network entity 101 and at least one local network function, NF, 103 of the network entity 101. The method 500 comprises a further step of obtaining 502, by the SBI 100, a service request 104 from a local NF 103. The method 500 comprises a further step of discovering 503, by the SBI 100, a service 105 and/or information related to a service 106 based on the service request 104. The method 500 comprises a further step of processing 504, by the SBI 100, the service request 104, based on at least one of: a priority of the service request 104, the discovered service 105 and/or information related to a service 106; and the identified local resource 102 and at least one local NF 103.

The present invention has been described in conjunction with various embodiments as examples as well as implementations. However, other variations can be understood and effected by those persons skilled in the art and practicing the claimed invention, from the studies of the drawings, this disclosure and the independent claims. In the claims as well as in the description the word “comprising” does not exclude other elements or steps and the indefinite article “a” or “an” does not exclude a plurality. A single element or other unit may fulfill the functions of several entities or items recited in the claims. The mere fact that certain measures are recited in the mutual different dependent claims does not indicate that a combination of these measures cannot be used in an advantageous implementation.

Claims

1. A service based interface, SBI, (100) associated to a network entity (101), wherein the SBI (100) is configured to: -identify a local resource (102) of the network entity (101) and at least one local network function, NF, (103) of the network entity (101);

- obtain a service request (104) from a local NF (103);

- discover a service (105) and/or information related to a service (106) based on the service request (104); - process the service request (104) based on at least one of: a priority of the service request (104), the discovered service (105) and/or information related to a service (106), and the identified local resource (102) and at least one local NF (103).

2. The SBI (100) according to claim 1, wherein the SBI (100) is further configured to provide access to the identified local resource (102) to the identified local NF (103).

3. The SBI (100) according to claim 1 or 2, wherein the SBI (100) is further configured to provide access to the identified local resource (102) to the identified local NF (103) by providing a resource handler, and/or by means of a hypervisor mechanism.

4. The SBI (100) according to any one of the preceding claims, wherein the SBI (100) is further configured to discover the service (105) or the information related to a service (106) from a local NF service table (401).

5. The SBI (100) according to any one of the preceding claims, wherein the SBI (100) is further configured to preconfigure the local NF service table (401) based on information obtained from at least one other network entity.

6. The SBI (100) according to any one of the preceding claims, wherein the SBI (100) is further configured to initiate the discovery of the service (105) or the information related to a service (106) from at least one other network entity, if the service (105) or the information related to a service (106) cannot be discovered from the local NF service table (401).

7. The SBI (100) according to any one of the preceding claims, wherein the SBI (100) is further configured to provide the service (105) or information related to a service (106) to the requesting local NF (103).

8. The SBI (100) according to any one of the preceding claims, wherein the service request (104) is a request for sending information to another NF, or for receiving information from another NF.

9. The SBI (100) according to any one of the preceding claims, wherein the SBI (100) is further configured to determine the priority of the service request (104) based on a type of the service request (104), and/or based on the local NF (103) that provides the service request (104).

10. The SBI (100) according to any one of the preceding claims, wherein the SBI (100) is further configured to assign a priority to the service request (104) using a queuing mechanism.

11. The SBI (100) according to any one of the preceding claims, wherein the SBI (100) is further configured to adjust resource allocation of a local NF (103) based on the identified local resources (102).

12. The SBI (100) according to any one of the preceding claims, wherein the SBI (100) further includes an application programming interface, API, (201) for communication with aNF (103) or a network entity (101).

13. A method (500) for operating a service based interface, SBI, (100) associated to a network entity (101), wherein the method (500) comprises the steps of:

- identifying (501), by the SBI (100), a local resource (102) of the network entity (101) and at least one local network function, NF, (103) of the network entity (101);

- obtaining (502), by the SBI (100), a service request (104) from a local NF (103);

- discovering (503), by the SBI (100), a service (105) and/or information related to a service (106) based on the service request (104);

- processing (504), by the SBI (100), the service request (104), based on at least one of: a priority of the service request (104), the discovered service (105) and/or information related to a service (106); and the identified local resource (102) and at least one local NF (103).

14. A computer program product including program code for performing the method according to claim 13, when the program code is run by a processor.