WO2020098946A1

WO2020098946A1 - Network node and method for supporting a service based architecture

Info

Publication number: WO2020098946A1
Application number: PCT/EP2018/081434
Authority: WO
Inventors: Artur Hecker; Xun XIAO; Chenghui Peng; Jianjun Wu
Original assignee: Huawei Technologies Co., Ltd.
Priority date: 2018-11-15
Filing date: 2018-11-15
Publication date: 2020-05-22
Also published as: CN113039752A; CN113039752B

Abstract

The present invention provides a network node for supporting a Service Based Architecture (SBA) of a network system comprising a plurality of network nodes. The network node is configured to connect to the plurality of network nodes; discover related information about at least one Network Function (NF) service provided by at least one other network node, wherein the related information comprises a routing information of the NF service; and provide the related information to at least one other network node.

Description

NETWORK NODE AND METHOD FOR SUPPORTING A SERVICE BASED

ARCHITECTURE TECHNICAL FIELD

The present invention relates generally to the field of a Service Based Architecture (SBA) of a network system. The invention specifically presents a network node and a corresponding method for supporting the SBA of a network system comprising a plurality of network nodes.

BACKGROUND

The next generation of mobile networks, e.g., the Fifth Generation (5G) is expected to support many new types of connections between various devices such as cars, wearables, sensors, actuators, etc., 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 may have a deep impact on the core network architecture. In the conventional mobile networks, services mainly refer to the access of portable devices in human hands for data and voice services, merely. Basically, the core networks can apply the same treatment to portable devices following the best- effort principle. Hence, those services are predictable and how to respond them can be well pre-planned. However, with various new service requests, the service patterns turn to be relatively heterogeneous. Consequently, the service requests to the 5G network may hardly be predicted. A proper method to meet the requirements is to agilely respond the incoming services in a dynamic way.

Moreover, efficiently responding the distinct and the unpredictable service requests is not an easy task. For example, the administratively pre-planned approaches with static network deployment do not work. Recently, Software-Defined Networking (SDN) and Network Function Virtualization (NFV) are mentioned as the two key enablers to realize a flexible and a programmable network infrastructure. Conventionally, the SDN abstracts everything as a flow and moves the complexity of the flow treatment to a logically centralized element called the SDN Controller (SDNC). Hence, the SDN reduces all network elements to dumb flow treatment devices, which are only responsible for flow processing. With these concepts, the SDN fuses all of the management and the control plane (CP) intelligence at the SDNC. In return, the common abstraction and the locally available data may simplify the development of the network control and the management applications.

Furthermore, the NFV turns the existing network functions (e.g., were mainly implemented before by dedicated and specialized hardware) into virtualized function modules that can be more easily deployed or removed as needed.

With this two enabling technologies (i.e., the SDN and the NFV), responding new service requests may become easier than before. For example, any network functions (NFs) may be deployed or allocated on-demand (NFV’ s features) and their forwarding behaviours may be remotely programmed (SDN’s features), similar to installing and running a computer program.

Due to the heterogeneous service requests (e.g., not limited to the 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, the 3GPP SA2 defines the architecture of the 5G network as a Service-Based Architecture (SBA) in which the network functions (NFs) should be modularized, and each service should be composed by combining the required NFs. Specifically, the NFs may offer different functionalities, and consequently, the NFs may also be able to provide different services.

In addition, for every NF, the services offered by the NF should be self-contained, acted upon and managed, independently, from other NF services offered by the same NF (e.g., for scaling, healing, etc.). Moreover, multiple NFs may together form a NF chain and may provide a service, as a whole. The key benefits of the SB A can be summarized as:

• Modularization of the NFs makes a single NF more resilient. If the NF fails, it will not affect the other NF entities.

• The composition capability of the multiple NF services enable a more agile and a dynamic service providing mechanism, especially, this is further amplified by virtualization, where any NF can be quickly instantiated, e.g., in any location and at any time.

• The interfaces between the 3GPP-specific NFs (e.g., the NFs that exchange information) can be standardized, thus, every vendor follows the same definition of those interfaces, and thereby a seamless integration can be achieved.

According to the definitions from 3GPP SA2, the standardized interfaces are called reference points, and the interfaces as a whole are called service-based interfaces (SBIs). Moreover, the communication of two NFs with each other and over the SBIs, is also defined in 3GPP.

More specifically:

• The HTTP/2 is used as the transport protocol over the SBIs.

• The RESTful API is the principle to design the interfaces.

• The OpenAPI is the programming language to implement the APIs.

• The JSON format is used as the data format exchanged over the interfaces.

Although the goal and requirements of the SBIs are clearly established. However, only the protocols that may run over the SBI are defined. For example, the implementation of the SBA/SBIs such that the network nodes in the system can form such a promising architecture is not known, particularly, when the network nodes are distributed across the network domain.

Moreover, the NFs require an SBI layer to be able to offer the NF service registration, the NF service discovery, and even the NF service scheduling, whose solutions are still missing. Generally, three conventional solutions have been proposed including static pre-configured devices, virtualization within a cloud, and autonomic networking, which will be discussed in the following,

1. Static pre-configured devices

With a massive momentum, the NFV technology gets many attentions by the telecom operators. For example, many operators are interested in planning of a replacement for the dedicated physical devices, while using virtualization platforms to run their NF service. However, the progress is still low, and actually, not every operator finishes the full embrace with the NFV technology. Moreover, from the operator’s perspective, upgrading to a fully virtualized telecom network is concerned with many factors, e.g., the OPEX/CPEX, the performance issues and the reliability issues. Therefore, at a very large extent, the network services are still provided by the pre-configured devices running as physical nodes at a physical location (such as the server rooms). In addition, many vendors are still selling those dedicated devices, and such a deployment is still popular among the operators.

Furthermore, realizing an SBA with the dedicated devices is also possible, e.g., by sacrificing the flexibility and the agility. In this technique, by referring to the standard, the references points that are defined to have communications, will be directly connected, either with the direct cables or by connecting to a communication network dedicated to the control plane communication whose routing policy will also be configured. This is typically the current main jobs of the network engineers of a vendor. They install the devices on-site, and perform a heavy configurations of those devices such that the devices may be adapted to work properly. Afterward, when the pre-configuration is completed, the location is determined and the topology of connections among the network function devices are fixed.

The main disadvantages of the static pre-configuration can be summarized as follow:

I. It significantly restricts the flexibility of the network.

For example, the processing capability of a certain NF is equals to the number of devices installed, which is also determined once the installation and the configuration are done. If more capability is needed, more devices must be installed and configured once again with the existing part. Similarly, if less capability is needed (e.g., due to the green policy), the corresponding devices have to be removed. All of these processes requires buying additional devices and materials that connect them.

II. It limits the topological features of network services to the topological definition of the infrastructure.

For example, an ultra-low latency service has a hard requirement to the end-to-end latency. If the end-to-end delay occur, e.g., from the physical location of an NF to the service point, the requirement is already failed, therefore, the service cannot be fulfilled, and it actually will never be fulfilled. The reason is that, since the location providing such a service is decided and fixed, therefore, a change of the location closer to the service point is difficult. In other word, the infrastructure’s structure defines the corresponding topology of the services. A better technique is to decouple the two layers such that the service layer is not restricted by the physical topology. This leads to the virtualization that will be discussed below.

2. Virtualization within a cloud

In order to overcome the disadvantages of building a network with dedicated physical devices, virtualizations move a big step where the NF can be run, e.g., as a software piece over the COTS (commercially available off-the-shelf). The virtualization also promotes the hypo deployment of the datacenter. An important novel feature provided by the virtualization is that the NF can be easily added and/or removed, when it is required. Adding a new NF equals to running a new NF instance in the machine, while removing it is just equal to killing the program, even states are externalized from the processing logic of an NF instance, namely stateless NF. Thus, the flexibility of the NFs is largely improved.

However, first of all, this does not completely resolves the issue where, the pre configuration efforts that are needed for installing dedicated physical devices are converted to the full installation and the configurations of a datacenter. So far, it is not determined yet that, with bringing the datacenters in, whether it decreases or increases the costs, e.g., when comparing with those single devices. Secondly, the datacenters cannot be located everywhere in the network, but still they are located at several centralized locations in the network. Therefore, the coordination among multiple datacenters are needed which requires much more efforts at the management layer. However, at the management layer, the solutions for a seamless cross-datacenter are still rare. The reality is that the current orchestration and the management tools require much more efforts, in order to be able to correctly operate one datacenter or multiple ones, e.g., the Open Networking Automation Platform (ONAP). For example, once a datacenter’s capacity is extended, the new part should be carefully configured, such that it can be successfully used and is further visible to the management tool. Furthermore, the network services still have to be configured by the management tool, e.g., which NF instances and at what location should be connected to other NF instances, how the transport connections among them should be provisioned, etc. Those decisions should be made at a relatively higher layer, which further deteriorates the agility and the performance of the network service providing. Last but not least, in the current network infrastructure, not every part supports virtualization. Therefore, operators face a hybrid network infrastructure, which also raises another concern that is how the virtualized part can work with the non- virtualized part.

3. The autonomic networking

As it is proposed by the Internet Engineering Task Force Autonomic Networking Integrated Model and Approach (IETF ANIMA) working group, the autonomic networking aims to define a fully Autonomous Network Infrastructure (ANI) and an Autonomic Service Agents (ASAs) that can seamlessly run over the infrastructure, in order to provide the network services (both for the control plane and the data plane). The key features include resource node auto-discovery, control plane auto-bootstrapping, key identity infrastructure bootstrapping, etc.

In the mobile telecommunication networks, ASAs can be seen as the NF services that form the network services. However, ANIMA- ANI does not consider techniques for improving the support of the ASA’s running. For example, ASA will not be automatically, e.g., discovered, registered and later on utilized, although the control plane connectivity is established. In other words, ANIMA focuses more on the infrastructure and the resource layer, rather than on the service layer. The main disadvantages and insufficiencies can be summarized as follow:

I. ANIMA does not specifically design solutions for wireless mobile networks.

Generally, ANIMA does not specifically design solutions for wireless mobile networks. Therefore, running ASAs over ANI cannot be trivially mapped to running NF services for the mobile network. For example, NFs standardized in 3GPP have specific reference points (i.e., interfaces) for communicating to other NFs, and the connectivity between the NF pairs has to be provided. However, ANI does not consider any specific service between any two ASAs (i.e., the NFs), rather to provide a generic communication channel and let the ASAs to customize their connections when needed.

II. ANI focuses more at the resource layer.

ANI focuses more at the resource layer where the control plane can autonomously integrate a new network node that is verified or cut an obsolete node that exits the network. However, scaling in and out which is happening at the higher layer is also not handled, particularly, for the discovery, the registration, etc. Therefore, ANI cannot be directly used to fulfil the requirement of the SBA where the NF services should be correlated, whenever necessary.

III. ANI designed by ANIMA supports very limited communication models.

For example, so far, unicasting model and flooding model are supported. However, services of the NFs clearly require one to many (i.e., multicast-like), prescription and subscription (i.e., Pub/Sub) communication model, which are not supported.

In summary, although ANIMA reaches much further than the simple virtualization of the network, however, it does not solve the problem targeted in the present invention.

Requirements of the SBA

Based on the discussions of the prior art, the concrete requirements that should be fulfilled by the SBA (according to the definitions from 3GPP) can be summarized as follow: I. Autonomous resource onboarding.

This fundamental requirement comes from the resource layer. For example, when there is a new resource node added into the network or cut out from the network domain, the system should be able to adapt to that. Specifically, the inter-connectivity should be automatically done by the system and the routing should be updated (e.g., established, pruned, etc.) such that every node in the network can see a newly added node and disconnect to a leaving node.

II. Autonomous NF service onboarding

The autonomous NF service onboarding is similar to what the resource onboarding is. However, in the autonomous NF service onboarding the NF services running on distributed network nodes should be able to be discovered. This requirement is important for the future wireless mobile networks (e.g., the 5G), because services provided by different NFs constitute a network service provided to the users. So far, as it is discussed above, this is explicitly done by connecting them by either pre-configuration or physical connections with dedicated devices.

III. An advanced communication models for the NF services running on distributed resource nodes.

A more advanced communication models for the NF services running on distributed resource nodes is necessary, e.g., when an NF instance needs to communicate with multiple NF instances with synchronous and asynchronous ways (e.g., Pub/Sub). Clearly, a simple unicast and flooding are not efficient. As a result, a more efficient ways, e.g., multicasting, should be supported, which is not independently supported by the resource node.

Other considerations include scalability and supporting of the other defined features (e.g., network slicing where isolated NF services are provisioned to provide network services to a particular customer and end-to-end SLA is guaranteed).

Moreover, the network nodes as the ultimate playground of running NF services currently are still separately considered as a basic device when deploying a network. In order to make the connected network nodes meaningful where a certain network service can be provided to the user entities, customizations with heavy configurations must be done. On the one hand, this introduces unnecessary efforts to the network operators, where for each particular service, specific configuration or updates have to be made; on the other hand, such a long round-trip management way, still cannot satisfy the requirement on the service requests becoming faster and faster where a flexible SBA is needed. Therefore, it is clear that there is gap between providing the NF services via SBA and the current schemes of network node deployment and NF service configuration. Considering all the necessary requirements discussed above, solutions to build such an SBA/SBI are missing.

SUMMARY In view of the above-mentioned problems and disadvantages, the present invention aims to improve the conventional devices and methods for supporting a service based architecture of a network system.

An objective is in particular to provide a network node and a method, for supporting the SBA of a network system. The network system may be distributed between multiple network nodes, and the network nodes should support the SBA such that the SBA for future networks (e.g., 5G) is fulfilled. For example, an SBI agent may be provided in each network node. The SBI agent may include different modules and may further be configured to establish the SBI for the local NFs. Furthermore, the SBI agent of each network node may be the interface to other SBI agents located in other network nodes.

The objective is achieved by the solution provided according to embodiments of the invention in the enclosed independent claims. Advantageous implementations of the embodiments are further defined in the dependent claims.

The main advantages and a brief discussion of the solution, can be summarized as follows: 1. Simplifying the design and realization of the NF. For example, with the network node (e.g., an extension of the SBI agent in the network node), an NF does not have to consider how to reach other NFs when it has to send/forward information. Instead, the NF only has to delegate the send/receive jobs to the network node (e.g., the SBI agent in the network node) and accesses to other NF services through the information provided by the network node (e.g., the information may be stored in the network function instance Service Routing Table (nfiSRT) located on the network node). The design of an NF only has to consider its processing logic.

2. Improving the flexibility of the network control.

For example, since the SBI agents will be collectively adaptive to the dynamic of the network nodes, any newly added network node will be automatically recognized and on- boarded to the network domain. Note that the present invention is not limited to the type of the network node as well as of its transport connections, therefore, even if the environment is hybrid, the SBI agent (i.e., its different modules) can scale in and out the network domain, automatically, and where the network nodes are connected if they are reachable.

3. Modularizing the architecture design of a resource node so that every part is adjustable.

For example, the SBI agent may be modularized. Moreover, the different modules may adopt different solutions or implementations in such a way that replacing one of the module with another protocol may not affect the other modules. For instance, the SBI agent may have a routing module. Moreover, the routing module may use any routing protocol in order to build the routing layer among the network nodes. Different routing protocols may have completely different algorithms and may build completely different routing overlay.

This may enhance the applicability of the SBI agent when the network nodes are at distinct scenarios. A typical situation is that the network nodes may be the nodes of an Internet of the Things (IoT) network or the nodes of a virtual network in a datacenter. For both of the two types of the networks, its routing strategy should also be heterogeneous, due to the distinct constraints such as the energy consumptions, the topology features, etc, in which with the modularized feature, the users may easily change the concrete realization. 4. Moving steps forward for building an SB A.

This feature matches the requirement and the definition of SBA from 3GPP, as well as, the clear trend to the future network where flexibility and agility are the key features. The SBI agents together can be considered as a distributed realization of the SBI, where the NF services can be arbitrarily accessed and composed when necessary so as to offer a new service. Therefore, how to discover the existing NF services across the network and how to maintain the accessibility of the identified NF services are the key challenges. With the extension of the SBI agent on every network node, the network node has the functionality to autonomously establish an SBI for the NFs. As a result, a critical feature of an SBA is fulfilled.

A first aspect of the invention provides a network node for supporting a SBA of a network system comprising a plurality of network nodes, the network node being configured to connect to the plurality of network nodes; discover related information about at least one Network Function (NF) service provided by at least one other network node, wherein the related information comprises a routing information of the NF service; and provide the related information to at least one other network node.

The first aspect of the present invention directly targets a possibly hybrid, dynamic and distributed environment, and aims to fulfil the requirement of the SBA. The first aspect of the invention proposes an autonomous solution that fills the gap between providing the NF services via the SBA and the available schemes of network node deployment and the NF service configuration.

For example, the network node (hereinafter the network node and the resource node are used interchangeably) may be extended by inclusion of an SBI agent. Every network node in the network system may include an SBI agent. All of the SBI agents across all the network nodes may collectively establish the SBI layer. The SBI layer may delegate some critical jobs that currently have to be done in an administrative process.

Specifically, the network node of the first aspect (e.g., its SBI agent) may enable one or more of: • Autonomous network node onboarding.

• Autonomous network node transport layer configuration.

• Network node routing service.

• NF service routing.

For instance, the network node may have different modules. Each module may have its interface to other modules and the concrete solutions or realizations of each module may be pluggable. By running resource-to-resource protocols, the SBI agents may together build the connectivity routing layer for the selected neighbours and the NF services may be dynamically discovered, registered and may further be accessible to other NFs. Based on that, the flexible network services may be composed, which may improve the agility of the network.

In an implementation form of the first aspect, the at least one NF service and/or its related information are maintained in a network function instance Service Routing Table (nfiSRT) stored on the network node.

This is beneficial, since by creating the nfiSRT, the NF services may easily be able to reach other NF services. Moreover, the requirement and the definition of SBA from 3GPP is fulfilled. In addition, the network node may be flexible, agile, etc.

In a further implementation form of the first aspect, the network node is further configured to gather network nodes providing NF services; and generate a friend list in the nfiSRT indicating a list of the network nodes providing a NF service.

For example, the friend list may include the other network nodes that are selected as “friends”. The procedure may be such that, initially, the network nodes being selected, afterward the routing may be built among those selected network nodes (i.e., the friends), and finally the NF services may be provided to (or obtained from) the selected nodes.

In a further implementation form of the first aspect, the related information of the NF service comprises an interface being used by the network node and/or at least one other network node for obtaining the NF service. This is beneficial, since it simplifies the design and realization of NF without considering to handle traffic forwarding. For example, the NF may be able to delegate the send or the receive jobs to the network node (e.g., to an SBI agent which may be located in the network node) and may further access to other NF services by using information in the nfiSRT.

In a further implementation form of the first aspect, the data related to the NF service is provided, in particular transmitted, in a dynamic procedure to the at least one other network node.

This is beneficial, since the NF services are dynamically discovered, registered and may further be accessible to other NFs. Moreover, it improves the agility of the network.

In a further implementation form of the first aspect, the network node is further configured to provide a notification to at least one other network node when a network node is connected to or disconnected from the network system.

For example, the network node may have different modules. Moreover, the different modules of the network node may build a routing layer among the selected nodes. Therefore, different information such as notification may be exchanged between the network nodes. In some embodiments, the network nodes that are newly added to the network system can be automatically added to the network system. For example, each network node may be configured to connect to an additional network node, when the additional network node is connected to the network system. Moreover, each network node may discover the related information about at least one NF service provided by the additional network node. In addition, each network node in the network system may provide the related information of the at least one NF service provided by the additional network node to at least one other network node.

In a further implementation form of the first aspect, the transmitted data related to the NF service includes one or more of:

• The current types of the NF services.

• The current load of each NF. • The capability configuration of each NF.

This is beneficial, since the NF services may be discovered, their related information may be provided to other network nodes or NF. Moreover, each network node may exchange the information about the local running NF services in a dynamical procedure.

In a further implementation form of the first aspect, the network node is further configured to add an additional NF service and its related information to the nfiSRT based on a predefined criterion.

This is beneficial, since each network node may be able to determine which NF services should be included in its local nfiSRT. Moreover, the architecture design of a resource node is simplified such that every part is adjustable.

In a further implementation form of the first aspect, the predefined criterion is based on at least one of:

• The distribution of the NFs located on the network node.

• The current loads of the NFs located on the network node.

• The possible usage of the additional NF service by the network node.

This is beneficial, since it enable building the nfiSRT in a location that the NF services can easily reach another NF services.

In a further implementation form of the first aspect, the network system is based on a distributed network system.

This is beneficial, since a distributed design of the network system may be provided that fulfill the SBA for the future network systems such as the 5G. In a further implementation form of the first aspect, the network node is further configured for one or more of:

• A physical device.

• A server machine.

• A virtual machine.

This is beneficial, since the SBI agent can be pre-installed on every resource node which may be the physical device, the server machine, the virtual machine, without limiting the present disclosure to a specific type of the network systems. Moreover, the SBA of a broad range of the network systems including different devices, e.g., the physical devices, the server machines, and the virtual machines may be supported.

A second aspect of the invention provides a method for supporting a service based architecture of a network system comprising a plurality of network nodes, the method comprises connecting to the plurality of network nodes; discovering related information about at least one Network Function, NF, service provided by at least one other network node, wherein the related information comprises a routing information of the NF service; and providing the related information to at least one other network node.

In an implementation form of the second aspect, the at least one NF service and/or its related information are maintained in an nfiSRT stored on the network node.

In a further implementation form of the second aspect, the method further comprises gathering network nodes providing NF services; and generating a friend list in the nfiSRT indicating a list of the network nodes providing a NF service.

In a further implementation form of the second aspect, the related information of the NF service comprises an interface being used by the network node and/or at least one other network node for obtaining the NF service.

In a further implementation form of the second aspect, the data related to the NF service is provided, in particular transmitted, in a dynamic procedure to the at least one other network node. In a further implementation form of the second aspect, the method further comprises providing a notification to at least one other network node when a network node is connected to or disconnected from the network system.

In a further implementation form of the second aspect, the transmitted data related to the NF service includes one or more of:

• The current types of the NF services.

· The current load of each NF.

• The capability configuration of each NF.

In a further implementation form of the second aspect, the method further comprises adding an additional NF service and its related information to the nfiSRT based on a predefined criterion.

In a further implementation form of the second aspect, the predefined criterion is based on at least one of: · The distribution of the NFs located on the network node.

• The current loads of the NFs located on the network node.

• The possible usage of the additional NF service by the network node.

In a further implementation form of the second aspect, the network system is based on a distributed network system.

In a further implementation form of the second aspect, the method is for one or more of:

• A physical device.

· A server machine.

• A virtual machine.

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 schematically illustrates a network node for supporting the SBA of a network system according to an embodiment of the present invention.

FIG. 2 schematically illustrates the network node including an SBI agent for supporting the SBA of the network system according to an embodiment of the present invention.

FIG. 3 schematically illustrates the network node including the different modules of the SBI agent for supporting the SBA of the network system according to an embodiment of the present invention.

FIG. 4 schematically illustrates the network node being exemplary a datacenter supporting the SBA of a network of datacenters according to an embodiment of the present invention.

FIG. 5 schematically illustrates the network node being exemplary a datacenter within a backhaul hierarchical datacenters, supporting the SBA, according to an embodiment of the present invention. FIG. 6 schematically illustrates the network node being exemplary a mobile edge computing device supporting the SBA according to an embodiment of the present invention.

FIG. 7 schematically illustrates a method for supporting the SBA of a network system according to an embodiment of the present invention.

DETAILED DESCRIPTION OF EMBODIMENTS

FIG. 1 schematically illustrates a network node 100 for supporting the SBA of a network system 1 according to an embodiment of the present invention. The network system 1 comprises a plurality of network nodes 110 and 120.

The network node 100 is configured to connect to the plurality of network nodes 110 and

120.

For example, the network system 1 includes a group of network nodes 110, 120 and network links. The network nodes (also referred as resource nodes) may scale from a virtual machine (VM), a Commercial Off-The-Shelf (COTS) server, a COTS server rack to a datacenter. The networks nodes may have networking interfaces (capabilities) and storages, where the latter capability is optional. The network links (e.g., 113) refer a connection linking two resource nodes (e.g., 110 and 120), where a network link 113 can be any of wireless, fiber, cable, and/or virtual connection (e.g. VPN link). Every network node runs resource control peer stack (e.g., with its compute environment) and at least one network interface can be used by the control peer stack (i.e., operating system level). Each network node is not isolated, however, there is at least one interface connecting to an environment where there are more network nodes.

The network node 100 is further configured to discover related information 112, 122 about at least one NF service 111, 121 provided by at least one other network node 110, 120, wherein the related information 112, 122 comprises a routing information of the NF service. For example, each network node form the plurality of network nodes 110, 120 may provide network function services 111 and 121, respectively. Moreover, the network node 100 may discover the related information 112, 122 of the NF services 111 and 121, respectively. The related information may be, for example, routing information, interfaces to be used, location of the NF services within the network, types of the services, number and/or identification information of the network nodes providing the services, routing information of the NF services, a metric information, etc.

Moreover, the network node 100 is further configured to provide the related information 112, 122 to at least one other network node 120, 110. For example, the network node 100 may discover the related information 122 of the NF service 121 of the network node 120. The related information may be the routing information of the NF service 121. Moreover, the network node 100 may provide the discovered related information 122 of the NF service 121 of the network node 120, to the network node 110.

FIG. 2 schematically illustrates the network node 100 including an SBI agent 202 for supporting the SBA of the network system 1 according to an embodiment of the present invention.

The network node 100 includes several NFs 201, an SBI agent 202 (e.g., for discovery of the NF service), a computing unit 203, a forwarding logic unit 204, an NF service routing table 205, and a storage 206.

The network node 110 includes several NFs 211, an SBI agent 212 (e.g., for discovery of the NF service), a computing unit 213, a forwarding logic unit 214, an NF service routing table 215, and a storage 216.

The network node 100 is connected to the network node 110 by several links including a link based on the R2R Protocol Suite (routing to routing protocol suite) 216 and a link 217, in the network system 1.

In order to fulfil the key requirements of the SBA/SBI, an extension is provided on the resource node 100 so that all resource nodes 110, 120 distributed in the network domain 1 form a distributed system facilitating upper layer NFs 201, 211 to provide network services. Specifically, a resource agent, called SBI agent 202, 212 is introduced in order to establish the SBI for the local running NFs 201, 211, and it is also the interface to other agents where all resources work together as a distributed system where the SBI across all resource nodes 100, 110 can be created. Among the resource agents 100, 110 and over the interface, several control peer protocols are adopted. The architectural view of the extended resource node 110, 110 and the interfaces to other resource nodes is shown in the FIG. 2.

An objective of introducing the SBI agents 202, 212 is to establish a NF instance service routing table (nfiSRT) 205, 215 on every resource node 100, 110. An example of the nfiSRT is shown in Table I below. The local nfiSRT 205, 215 helps the local running NFs 201, 211 to forward their processing packets to other NFs, which may locate at different

resource nodes. Note that discovering NF services on other nodes, is not possible based on the conventional devices and methods. Table I. An Example ofNF Instance Service Routing Table ( nfiSRT)

FIG. 3 schematically illustrates the network node 100 including different modules 301, 302, 302, 304 of the SBI agent 202 for supporting the SBA of the network system 1 according to an embodiment of the present invention.

The SBI agent 202 comprises four main components (e.g., corresponding specific protocol modules), which are shown as in FIG 3.

The SBI agent 202 includes a resource node (or agent) discovery module (R2R/D) 301. This module (R2R/D 301) is optional, as it depends on the configuration and the boundary of a trusted domain where all network nodes in this domain are equipped by the SBI agent 202 and will cooperate with each other. In other words, such a trusted domain can be pre configured, by whatever means, as it is generally known. For example, the resource nodes 100, 110 (devices) from the same vendor may be baked with the SBI agent logic and may work together. Another example is that an administrator of an operator has full control over the resource nodes, and by assuming every resource node will provide compute resource, the administrator can configure those resource nodes to have the SBI agent, and thus, they may know each other and may work with each other by default.

The SBI agent 202 further comprises a resource node (or agent) transport module (R2R/T)

302. The R2R/T module 302 provides the SBI agent a connection to the other nodes (i.e., SBI agents). Similar to the discovery module, this module is also optional because how the transport layer could be, also depends on the environment where the resource nodes are deployed.

For example, the transport layer may be within a full physical connectivity where the resource nodes 100, 110, 120 located at the same place, and are connected by wired cables to the network interfaces. However, the resource nodes 100, 110, 120 may locate at completely different locations where connections among them could be virtual links (e.g., tunneling, VPN and so on). Moreover, the two possibilities could be combined in a certain case. Therefore, assuming that the infrastructure layer may be done, in advance, and the SBI agent 202 may utilize the point-to-point connectivity, no matter how the connection is realized. Note that this assumption does not imply that every resource node 100, 110, 120 can access and communicate to the other resource nodes (i.e., traffic routing via multiple hops). Rather, the traffic routing may be done, e.g., by the following mandatory modules.

The SBI agent 202 further comprises a resource node (or agent) routing module (R2R/R)

303. The R2R/R module 303 is mandatory. This module helps an SBI agent 202 to reach other SBI agents (e.g., 212) if one agent wants to send information to other agents. The routing module 303 will bootstrap the routing layer and routing information will be maintained at local side so that whenever traffics (either from the agent itself or other parts like upper layer NFs) can correctly reach its destination. The R2R/R module 303 provides a connected resource layer where if there is a new resource node added in the network domain 1, it will be automatically included. Similarly, if there is a resource node exits the network domain 1, the R2R/R module 303 will get updated across the network domain 1, and every other resource node will observe this event. The SBI agent 202 further comprises a NF service routing module (R2R/S) 304. The R2R/S module 304 is also mandatory. In addition to the basic routing layer, the NF service routing is the key to establish the SBI, because that is the information that every NF 201 needs whenever the NF 201 wants to forward packets to other NFs (e.g., 211) for further processing.

Specifically, the service routing module (the R2R/S module 303) first tries to discover the existing NF services (e.g., 121) running on other resource nodes 110. Selected NF services 121 and its routing information 122 will be stored by the SBI agent to the nfiSRT 205. Selection rules here depends on the configuration of the policy. For example, in an aggressive way, the SBI agent 202 may broadcast the local NF services 201 of their own and other network nodes 110, 120 may simply stores that information (which may be inefficient). Another possible policy is that the SBI agent 202 may save the routing information of those NF services relevant to the service chain with respect to the definitions in 3GPP where one NF 201 will certainly forward its processed packets to the next specific NF 211, while other NFs are not interesting thus their routing information is not required. This module provides large space to smartly introduce various service routing algorithms, even if a scheduling function, thus it is quite open to adapt any existing or new solutions.

In some embodiments, certain information may be exchanged over the interface between any two network nodes 100, 110, e.g., in order to build the nfiSRT 205, 215 on every network node 100, 110. For example, every network node 100, 110 may have the SBI agent 202, 212, moreover, the related information 112, 122 may be exchanged over the interfaces between any two SBI agents 202, 212, or the like.

The first set of information that may be exchanged is the resource node information. An SBI agent 202 will utilize the R2R/D 301 to yield a‘friend’ list where the resource nodes 100, 110 in the list are trusted and will work with each other. After that, the SBI agent 202 does not have to store all the friend information, while on the other hand, a neighbour selection procedure can be applied, therefore, a subset of friends will be kept and those resource nodes 100, 110 become the‘neighbours’ of the SBI agent 202. Note that, such a procedure determines the topological features of the connectivity among the resource nodes 100, 110 (e.g., their SBI agents 202, 212), because, if a resource node 100 is selected by many other nodes 110, 120, it naturally becomes a hub of several others (considering that it gets higher in-degree than some others). Moreover, once the neighbours are determined, a point-to-point transport layer may be conducted, e.g., according to the characteristics of the transport media (e.g., this may be done by the R2R/T module 302).

Given the selected neighbours, the routing among them may be established by the R2R/R module 304 so that a resource node that is not selected by some other resource nodes can still be reached. The R2R/R module 304 runs a routing protocol that may utilize either an existing one or be a new one. The routing information of other resource nodes may be maintained in the routing table indicating over which interface, the network node 100 or the SBI agent 202 may be able to reach the other resource nodes 110, 120 or the SBI agents 212. This routing information may be utilized by the service routing module 303.

Based on the routing information provided or maintained by the R2R/R module 304, the R2R/S module 303 may build the nfiSRT 205, and may indicate on which interfaces an NF service can be found. Specifically, the R2R/S module 303 of the SBI agent 202 on every node keeps exchanging the information about the local running NF services in a dynamical procedure.

The information exchanged may contain information of those NFs services. For example, the information may be the current types of the NF services, the current load of each NF, the capability configuration of each NF, etc.

Based on the received information of the NF services, e.g., from other SBI agents, the agent decides which NF services shall be included in the local nfiSRT, and based on a predefined criterion. The criterion, for example, could consider the distribution of the local NFs and their current loads, or even some predictions on the possibility of using other NF services on other nodes, so that a better decision may be made. After this procedure, the nfiSRT 205 is built and the local NF services can forward their packets after their own processing.

In the following three embodiments based on three typical scenarios at different scales in which the service routing tables (i.e., nfiSRT) are established, by the SBI agents are presented, without limiting the present discourse to a specific network node or network system. FIG. 4 schematically illustrates the network node 100 being exemplary a datacenter supporting the SB A of a network 1 of datacenters 100, 110 according to an embodiment of the present invention.

As discussed, in some embodiments, the service routing may be between a pluralities of datacenters. The datacenter 100 (datacenter A) includes the SBI agent 202, the datacenter controller 401, the NF1 201 and the NF3 located in the unit 402. Moreover, the datacenter A 100 further includes several other NFs located in c2 403, c3 404, and c4 405.

The datacenter 110 (datacenter B) includes the SBI agent 212, the datacenter controller 411, the NF1 211 and the NF4 located in the unit 412. Moreover, the datacenter B 110 further includes several other NFs located in c2 413, c3 414, and c4 415.

For example, the NF services 201, 211 may run in different datacenters 100, 110 and there might be multiple instances for the same NF service. The NF instances 201 in one datacenter 100 have to know the information of other services provided by other NF instances 211 running in another datacenter 110.

In some embodiments, the operator may distribute the NF instances at different locations to provide the network services, in order to achieve load-balance and/or improve the response time.

Moreover, the operator may dynamically migrate the NF instances 201, 211 across different datacenters 100, 110 when optimizing the global system performance. As a result, NF instances 201, 211 need to be updated from time to time so that consistent information about the NF services can be known. Although this can be done, e.g., each time and whenever such a change occurs by the reconfiguration performed by the management plane, this is quite inefficient. Instead, if the resource nodes 100, 110 themselves can be adaptive to the changes with the local running NF services/instances and dynamically propagate such updated information in a distributed procedure, this largely improves the flexibility and scalability of the network. The connection between the datacenters may be established at the infrastructure layer. For example, the bandwidth and latency are guaranteed, thereby the resource for the connection may be fully provisioned. The SBI agents 202, 212 may act like an interface between the datacenters 100, 110. Here, an SBI agent 202, 212 may be responsible for gathering and exchanging NF instances/services with other SBI agents 202, 212 within the other datacenters.

For the state collection, the states of the NF instances/services that running in the datacenter, and their locations may be collected through the hypervisor layer (e.g., a datacenter controller 401, 411) provided by a datacenter management tool. Note that, any change of NF services/instances occurring in the datacenters 100, 110 may be observed by the SBI agents 202, 212. With the collected/monitored information of the NF instances/services, two SBI agents 202, 212 may start to exchange their NF service information to the others. Note that the SBI agents 202, 212 do not have to trivially exchange all information they have, but a strategical policy may be introduced here, so that the exchanged information may be optimized. For example, the SBI agents 202, 212 may subscribe the NF service information they are interested in for the local NFs so that once the specific NF service is ready or being updated, the subscribing SBI agents may be notified.

In this embodiment, the R2R/S module 303 of the SBI agent 202 is activated, because node discovery, transport layer and routing are directly provided by the infrastructure.

In some embodiment, only the R2R/S module 303 of the SBI agent 202 may be activated, without limiting the present disclosure to any specific structure of the SBI agent.

FIG. 5 schematically illustrates the network node 100 being exemplary a datacenter within a backhaul hierarchical datacenters network 1, supporting the SB A, according to an embodiment of the present invention.

In some embodiments, there might be multiple datacenters including the datacenter A 100, the datacenter B 110, and the datacenter C 120 working with each other, and the service routing may be established. Moreover, the multiple datacenters 100, 110, 120 may have a hierarchical organization, wherein several datacenters locating at relatively edge of the network have to associate with a centralized datacenter at the core network. The datacenter 100 (datacenter A) includes the SBI agent 202, the datacenter controller 401, the NF1 201 and the NF3 located in the unit 402.

The datacenter 110 (datacenter B) includes the SBI agent 212, the datacenter controller 411, the NF1 211 and the NF3 located in the unit 412. Moreover, the datacenter B 110 further includes several other NFs located in c2 413.

The datacenter 120 (datacenter C) includes the SBI agent 502, the datacenter controller 511, the NF1 501 and the NF4 located in the unit 512. Moreover, the datacenter C 120 further includes several other NFs located in c2 513.

For example, the main difference is that multiple tenants may deploy their services in those datacenters 100, 110, 120, though the proprietor of the datacenters may the same. This may be mapped to the business model that multiple virtual mobile operators may rent the infrastructure resource from a carrier to provide their own services. As a result, services from different tenants may be placed into those datacenters 100, 110, 120. In this case, the owner of the infrastructure (i.e., the bigger carrier) has no responsibility to manage the NF instances/services and how they should be connected. Therefore, each tenant has to figure out how to organize those NF instances/services by themselves.

For example, between two datacenters 100 and 110 a generic networking connection (e.g., TCP/IP) may be provided. For each tenant, its SBI agent running in each datacenters may have to discover the neighbor SBI agents running at another datacenters. Specifically, each SBI agent 202, 212, 502 may show its appearance over the connection, and may exchange identity with other SBI agents 202, 212, 502, if they are online. In this way, the SBI agents 212, 502 at the edge part will identify the SBI agent 202 responsible for the centralized datacenter 100 and establish association with the centralized datacenter 100. Once all online SBI agents are identified, similar to the process introduced in the datacenter-based case, the SBI agents 202, 212, 502 start to share their NF service/instance information among themselves, where local updates may be synchronized (mainly with the centralized SBI agents), and every SBI agent gains the NF service/instance information, and may further create the local service routing table (i.e. nfiSRT). In this embodiment, the R2R/R module 304 and the R2R/S module 303 of the SBI agent 202 may be activated.

FIG. 6 schematically illustrates the network node 100 being exemplary a mobile edge computing device supporting the SBA according to an embodiment of the present invention.

The resource node 100 includes the SBI agent 202, the NF3 201 and the local resource 601. The resource node 110 includes the SBI agent 212, the NF2 211, the NF 5 and the local resource 611. The resource node 120 includes the SBI agent 502, the NF1 501, the NF 4 and the local resource 621.

For example, the NF instances/services may be deployed across the whole network domain 1 where an NF instance may run at a base station (BS), at an MEC node and/or in a datacenter. This may be mapped to the use cases where services are provided with ultra- low latency requirement, and thus the NFs must be closer to the user equipment (UE) as much as possible, in order to avoid the latency that is naturally introduced from the transport and infrastructure layers. Moreover, the links among different resource nodes 100, 110, 120 may suffer a bad quality, having no quality of service (QoS) guarantee, and even a high network dynamic (e.g., resource node up/down). It may further be assumed that any resource node once joins in the network, is not isolated alone. The main differences of this scenario to the previous cases are that the network is fully dynamic. Therefore, the main challenge is that, if all the NF service management is done, e.g., by the management layer, wherein network dynamic is reported to the controller, and then the corresponding configuration updates are applied to the resource layer, this may not be sufficient for the service requirement. Moreover, another challenge is that the report of information to the management layer may also introduce scalability issues, because the centralized controller becomes the bottleneck. In other words, due to potentially high network dynamic, the NF services affected by the network changes must be handled as soon as possible.

Here, the SBI agents 202, 212, 502 of a tenant are pre-installed on every resource node 100, 110, 120, which could be a physical device, a server machine or a pure VM. First of all, the SBI agents 202, 212, 502 may have to be adaptive to the resource node dynamic. Specifically, whenever a resource node is added to the network (e.g., 100), its local SBI agent 202 will show its appearance to any adjacent resource nodes 110, 120 in which their SBI agents 212, 502 will be able to enroll the new SBI agent 202 after certain authentication process if needed. After that SBI agents 202, 212, 502 will select several other SBI agents 202, 212, 502 and create connections at the transport layer (e.g., establishing a VPN connection from one resource node to another resource node if possible). Once the transport layer is formed, the SBI agents 202, 212, 502 will start to establish routing layer among the resource nodes 100, 110, 120 (i.e., among their SBI agents). Similar to the process of creating service routing, the local NF instance/service information may be constantly exchanged (considering the some update policies). As a result, the SBI agents 202, 212, 502 cooperatively build the service routing that they are all interested in, respectively.

In this embodiment, all modules (301, 302, 303, and 304) of the SBI agent 202 may be activated.

Note that, the possible realizations and scenarios are not exhaustively listed here. Its variants may exist and details of implementations may also be different.

FIG. 7 schematically illustrates a method 700 for supporting the SB A of a network system 1 according to an embodiment of the present invention. The method may be performed by the network nodes 100, 110, and 120, as discussed above.

The method 700 comprises a first step 701 of connecting to the plurality of network nodes

110, 120.

The method 700 further comprises a step 702 of discovering related information 112, 122 about at least one NF service 111, 121 provided by at least one other network node 110, 120, wherein the related information comprises a routing information of the NF service.

The method 700 further comprises a further step 703 of providing the related information 112, 122 to at least one other network node 110, 120.

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. Network node (100) for supporting a Service Based Architecture, SB A, of a network system (1) comprising a plurality of network nodes (110, 120), the network node (100) being configured to:

connect to the plurality of network nodes (110, 120);

discover related information (112, 122) about at least one Network Function, NF, service (111, 121) provided by at least one other network node (110, 120), wherein the related information (112, 122) comprises a routing information of the NF service; and provide the related information (112, 122) to at least one other network node (120,

110).

2. Network node (100) according to claim 1, wherein

the at least one NF service (111, 121) and/or its related information (112, 122) are maintained in a network function instance Service Routing Table, nfiSRT (205), stored on the network node (100).

3. Network node (100) according to claim 1 or 2, further configured to

gather network nodes (110, 120) providing NF services (111, 121); and

generate a friend list in the nfiSRT (205) indicating a list of the network nodes (110,

120) providing a NF service (111, 121).

4. Network node (100) according to any one of claims 1 to 3, wherein

the related information (112, 122) of the NF service comprises an interface being used by the network node (100) and/or at least one other network node (110, 120) for obtaining the NF service (111, 121).

5. Network node (100) according to any one of claims 1 to 4, wherein

the data related to the NF service is provided, in particular transmitted, in a dynamic procedure to the at least one other network node (110, 120).

6. Network node (100) according to any one of claims 1 to 5, further configured to automatically recognize and connect to a new network node, when the new network node is added to the network system (1).

7. Network node (100) according to claim 6, further configured to discover related information about at least one NF service provided by the new network node (1).

provide the related information of the at least one NF service provided by the new network node to at least one other network node (110, 120).

8. Network node (100) according to any one of claims 1 to 7, wherein

the provided data related to the NF service includes one or more of:

the current types of the NF services;

the current load of each NF;

the capability configuration of each NF.

9. Network node (100) according to any one of claims 1 to 8, further configured to add an additional NF service and its related information to the nfiSRT (205) based on a predefined criterion.

10. Network node (100) according to claim 9, wherein

the predefined criterion is based on at least one of:

the distribution of the NFs located on the network node (100);

the current loads of the NFs located on the network node (100);

the possible usage of the additional NF service by the network node (100).

11. Network node (100) according to any one of claims 1 to 10, wherein

the network system (1) is based on a distributed network system.

12. Network node (100) according to any one of claims 1 to 11, further configured for one or more of:

a physical device;

a server machine;

a virtual machine.

13. A method (700) for supporting a Service Based Architecture, SB A, of a network system (1) comprising a plurality of network nodes (110, 120), the method (700) comprises:

connecting (701) to the plurality of network nodes (110, 120);

discovering (702) related information (112, 122) about at least one Network

Function, NF, service (111, 121) provided by at least one other network node (110, 120), wherein the related information (112, 122) comprises a routing information of the NF service; and

providing (703) the related information (112, 122) to at least one other network node (110, 120).