WO2019210946A1

WO2019210946A1 - Management device for slice management in a network, method and computer program for managing network slices

Info

Publication number: WO2019210946A1
Application number: PCT/EP2018/061193
Authority: WO
Inventors: Spyridon VASSILARAS; Georgios Paschos; Kostas KATSALIS; Konstantinos Samdanis; Xueli AN
Original assignee: Huawei Technologies Co., Ltd.
Priority date: 2018-05-02
Filing date: 2018-05-02
Publication date: 2019-11-07

Abstract

A management device for slice management of a communication network is configured to determine path information about one or more network devices for operating a slice, to determine configuration information for a virtual network function to be placed on the one or more network devices based on the path information and to provide the configuration information to at least one of the network devices and/or to a control entity for at least one of the network devices. A slice management method comprises the steps receiving, by a management device from a control entity, input; processing, by the management device, of the input to determine an output, wherein the output comprises path information about one or more network devices for operating a slice and configuration information for a virtual network function to be placed on the one or more network devices based on the path information and providing the configuration information to at least one of the network devices and/or to a control entity for at least one of the network devices. A computer program may have a program code for performing the method.

Description

TITLE

Management device for slice management in a network, method and computer program for managing network slices

TECHNICAL FIELD The present invention generally relates to the field of managing communication networks. More specifically, the present invention relates to devices and methods for managing network slices.

BACKGROUND

Communication networks, in particular cellular communication networks, have often been architected to support specific predefined services, namely voice, messaging, and Internet access. However, wireless networks and their operators are expected to support a number of diverse vertical industry applications in order to expand the wireless market. Next-generation networks should simultaneously accommodate applications and services with requirements as diverse as ultra-low latency and high resilience (URLL) for real-time control of critical systems or scalability to hundreds of thousands of connected devices towards the Internet-of-Things (loT). Network Slicing is a key enabling technology for this paradigm shift.

The concept of network slicing has been refined by NGMN, 3GPP and ITU and has been adopted and adapted by the main Telecom manufacturers and Telecom operators. According to 3GPP's definition, a Network Slice Instance (NSI) as defined in 3GPP TS 28.801 is "a set of network functions and the resources for these network functions which are arranged and configured, forming a complete logical network to meet certain network characteristics." This way, different NSI can be used to accommodate the requirements of different services types. Network functions can be implemented either as Virtual Network Functions (VNF) which can be run by a suitable physical network node or as Physical Network Functions (PNF) whose location (physical node performing this function) is fixed. An NSI is expected to span multiple network domains. 3GPP TR 28.801 vl5 defines the following entities regarding the orchestration and management of NSIs:

• Communication Service Management Function (CSMF): This entity is responsible for translating the communication service related requirements to network slice related requirements.

• Network Slice Management Function (NSMF): This entity is responsible for

management and orchestration of NSI. It derives network slice subnet related requirements from network slice related requirements.

• Network Slice Subnet Management Function (NSSMF): This entity is responsible for management and orchestration of network slice subnet instances (NSSI). An NSSI is a set of network functions and the resources for these network functions which are arranged and configured to form a logical network for a specific subnet. For example, the RAN-NSSMF is responsible for the management of the RAN NSSIs. The NSSI is defined by a sub-network blueprint (TR23.799).

For the 3GPP network the logical architecture combining the above entities into a complete network slice management and orchestration system is shown in Fig. 1 for the case of disaggregated RAN. The orchestration and management entities are however the same also in the case of other designs, for example vanilla LTE or Cloud-RAN designs.

For the 3 Standard Slice Types (STT), namely eMBB, URLLC, and MloT, standard or network-specific performance values have been defined in 3GPP TR22.891 and TS 23.501. However, service provisioning with e2e guarantees on per NSI basis remains a challenge for the integrated mobile-transport network. In particular, the problem of appropriately embedding VNFs on physical nodes and selecting the physical paths interconnecting these nodes at a minimum "cost", while respecting: a) e2e NSI QoS requirements and b) physical link and node capacity constraints, is considered a hard problem both from the mathematical and systemic point of view.

Up to now the way to slice the network was relying on VLAN tagging (L2) or MPLS label tagging and VPN tunneling (L3), where each flow was identified with a specific label and/or transferred within a specific VPN tunnel. For each slice/flow, bandwidth was guaranteed in software, through packet classification and traffic rate limitation on each hop. Furthermore, traditional Path Computation Elements (PCE) are used for slice unaware routing based on QoS, policy, or price. Deployments of PCE separate the computation element from the client (called PCC) that requests computation services. Communications between the PCE and PCC are achieved using the Path Computation Element Communication Protocol (PCEP) over TCP as defined in IETF RFCs 5440, 5441 and 5520.

PCE procedures are however slice unaware and the control plane functionalities are just based on the routing protocol used.

PCE procedures can take into account QoS requirements when discovering a path. For example, the following patent and paper describe the basic LARAC algorithm for finding a constrained min-cost path. However, this basic algorithm does not take into consideration VNF placement, neither the simultaneous embedding of many service chains under node and link capacity constraints.

• Alpar JQttner and lldiko Mecs, "Lagrange Quality of Service Routing," US Patent US7020086 B2, Mar. 2006

• Juttner, B. Szviatovski, I. Mecs and Z. Rajko, "Lagrange Relaxation Based Method for the QoS Routing Problem," Proceedings IEEE INFOCOM 2001. Anchorage, AK, 2001, pp. 859-868 vol.2.

However, in the light of 5G network slicing, the supporting orchestration and management systems are not just used for path computations with the minimum cost or highest bandwidth. They need also to consider the need for a joint optimization of where NSI functions (like VNFs or PNFs) should be placed and how these will be interconnected over the network. This requires sophistication on both the orchestration and the control planes that need to be tightly integrated in order to provide the required slice guarantees.

SUMMARY

Having recognized the above-mentioned disadvantages and problems, the present invention aims to improve the state of the art. In particular, an object of the present invention is to address the above-mentioned issues and to provide a way to reliably identify resources and functions required for the configuration of a network slice. The above-mentioned object is achieved by the features of the independent claims. Further embodiments of the invention are apparent from the dependent claims, the description and the figures.

According to a first aspect of the invention, the invention relates to a management device for slice management of a communication network. The management device is configured to determine path information about one or more network devices for operating a slice. The management device is configured to determine configuration information for a virtual network function to be placed on the one or more network devices based on the path information. The management device is configured to provide the configuration information to at least one of the network devices and/or to a control entity for at least one of the network devices.

The path information, which may define a service chain, may comprise predefined requirements for the slice which must be obeyed when determining the network configuration information. The management device may be implemented as a Network Slice Management Function, NSMF, in particular of a Service Level Agreement SLA. The management device can be a Network Slice Subset Management Function, NSSMF, in particular an NSSMF of a Radio Access Network, RAN-NSSMF. The management device may be configured to provide the configuration information by a transmission of the configuration information to the network devices and/or the control entity. The management device may also be configured to store the configuration information into a database that is accessible by the network devices and/or the control entity.

Thereby, a network slice may be implemented via chaining and operating virtual network functions on the respective network devices according to the path information and the configuration information.

According to an implementation of the first aspect, the path information may comprise information about at least one of: a Fronthaul; a Midhaul; a Backhaul and an end-to-end path of the slice.

The Fronthaul, Midhaul and Backhaul are each domains with a different scope of the communication network. In some aspects, these domains may overlap. An end-to-end path defined by the path information may extend over any of the Fronthaul, Midhaul and/or Backhaul of the network. Thereby, it is unambiguous how the slice should be implemented within the network.

According to an implementation of the first aspect, the path information may comprise information about one or more VNFs and/or one or more value added services placed on one or more network devices for operating the slice.

The network devices may each provide an individual set of virtual network functions, VNF, and/or value added services. Thereby, it is further specified how the network slice is to be implemented within the network.

According to an implementation of the first aspect, the path information may comprise an optimal set of network devices for operating the slice. In particular, the slice may fulfil one or more Quality-of-Service, QoS parameters, e.g., a pre-defined latency between two or more network devices for operating the slice.

The path information for all service chains, functions and/or slices is thus determined as a solution to an optimization problem. Different QoS parameters may be fulfilled. In particular, a jitter and/or an energy consumption requirement may be fulfilled in addition to or instead of a pre-defined latency. The management device may be an NSMF or an NSSMF.

Thereby, the slice may be configured with the parameters that were requested for the slice from the management device.

According to an implementation of the first aspect, the control entity may be another management device, in particular an NSSMF.

Thereby, the management device may directly instruct a management device in contact with a transport network to implement the slice.

According to an implementation of the first aspect, the management device may be configured to receive from the control entity information related to at least one of: a network topology, capability, slice configuration and/or resource allocation.

A resource allocation may be a process to obtain a resource, in particular by a request. Such a resource may in particular be a communication resource or a computational resource on a network device. Furthermore, allocation may also comprise to directly reserve a resource, i.e. without a prior request, because of internal management or control operations. For each resource or network function configuration information can be organized in a template, in particular an at least partly completed template. A template may be a combination of parameters and sub-functions.

Thereby, the management device may receive information that is useful to determine the configuration information and/or to determine the scope of the resources controlled by the control entity.

According to an implementation of the first aspect, the configuration information may comprise one or more of the following:

- topology information;

- capability information;

- functional information;

- security information;

- performance information.

Topology information may comprise a set of physical nodes and/or physical links.

Capability information may comprise information about link capacities. Functional information may comprise information about virtual and/or physical network functions. Security information may comprise information regarding authorization and authentication credentials on per slice basis. Performance information may relate to quality of service, e.g. measured packet error rates.

Thereby, the virtual network function to be configured using this information can be correctly chosen to implement the constraints defined by the information.

According to an implementation of the first aspect, the configuration information comprises information on a configuration of resources and/or functions of a transport network.

The control entity may, in this case, be a domain controller or an element manager.

Thereby, the resources and/or the functions to be configured for implementing a network slice are conveyed directly to the control entity which can implement them.

According to an implementation of the first aspect, the management device may be configured to receive monitoring information from one or more of the network devices and/or from one or more management entities, wherein each monitoring information is related to one or more of the network devices for operating the slice. Thereby, problems within the network can be identified.

According to an implementation of the first aspect, the monitoring information comprises at least one of:

- performance information, in particular latency;

- utilization information, in particular bandwidth;

- Fault management or resilience information.

Thereby, the correct implementation of the constraints relating to each network slice may be verified.

According to a second aspect of the invention, a slice management method comprises the steps:

- receiving, by a management device from a control entity, input ;

- processing, by the management device, of the input to determine an output, wherein the output comprises path information about one or more network devices for operating a slice and configuration information for a virtual network function to be placed on the one or more network devices based on the path information;

- providing the configuration information to at least one of the network devices and/or to a control entity for at least one of the network devices.

Thereby, a slice may be performed via the virtual network function on the respective network device or devices. According to an implementation of the second aspect, the receiving step comprises: requesting, by the management device from the control entity, at least one of

- a network topology;

- capability;

- slice configuration;

- resource allocation and

receiving, by the management device, the requested information as input.

Thereby, the management device may receive information that is useful to determine the configuration information and/or to determine the scope of the resources controlled by the control entity According to an implementation of the second aspect, the processing step comprises:

- processing input from one or more of the control entities to obtain an intermediate output;

- sending the intermediary output to the control entity for determining a minimum cost path information according to a quality of service-parameter;

- receiving the minimum cost path information as additional input and

- repeating these steps until an optimal path fulfilling the quality-of-service parameters has been found.

Thereby, a distributed determination of path information and/or configuration information may be obtained, reducing the transfer of domain local information among domains.

According to an implementation of the second aspect, the method further comprises requesting configuration of a slice.

Thereby, a network slice can be practically implemented. According to a third aspect, the invention relates to a computer program having a program code for performing the method according to the second aspect, when the computer program runs on a computing device.

Thereby, the method can be performed in an automatic and repeatable manner.

Advantageously, the computer program can be respectively performed by the management device according to the first aspect or by the control entity according to some implementations of the first aspect.

It should be noted that the above apparatuses may be implemented based on a discrete hardware circuitry with discrete hardware components, integrated chips or arrangements of chip modules, or based on a signal processing device or chip controlled by a software routine or program stored in a memory, written on a computer-readable medium or downloaded from a network such as the internet.

It shall further be understood that a preferred embodiment of the invention can also be any combination of the dependent claims or above embodiments with the respective independent claim. These and other aspects of the invention will be apparent from the embodiments described below.

BRIEF DESCRIPTION OF THE DRAWINGS

To illustrate the technical features of embodiments of the present invention more clearly, the accompanying drawings provided for describing the embodiments are introduced briefly in the following. The accompanying drawings in the following description are merely some embodiments of the present invention, but modifications of these embodiments are possible without departing from the scope of the present invention as defined in the claims. Fig. 1 shows a schematic overview over a network slice management and

orchestration architecture as defined in 3GPP TR 28.801 comprising a management device according to an embodiment of the invention;

Fig. 2 shows a schematic overview of changes to a path computation element in order to make it slice-aware according to an embodiment of the invention;

Fig. 3 shows a schematic overview of a centralized computation model according to an embodiment of the invention;

Fig. 4 shows a schematic overview of a distributed computation model according to an embodiment of the invention;

Fig. 5 shows an example simplified representation of a message exchange for a network as well as a network function chain to be embedded in the network;

Fig. 6 shows an example simplified representation of a message exchange for

advanced PCE operations according to an embodiment of the invention;

Fig. 7 shows a network graph produced by a path determination algorithm;

Fig. 8 shows an example network graph comprising gateway nodes for an instance of the reduced graph produced during advanced PCE operations;

Fig. 9 shows a protocol flow diagram of a management device carrying out

centralized computation procedures that form a functional element used many times according to an embodiment of the invention; Fig.10 shows a protocol flow diagram of a management device carrying out a high level centralized computation to determine the optimal slice configuration according to an embodiment of the invention and

Fig.11 shows a network instance diagram of a management device carrying out decentralized computation procedures according to another embodiment of the invention for the multi-domain advanced PCE problem.

DETAILED DESCRIPTION

Fig. 1 shows a schematic overview over a network slice management and orchestration architecture as defined in 3GPP TR 28.801. In a communication network 10, a management device, which in this case comprises an NSMF 12, is provided to communicate with control entities 14, 16, 18 of various parts of the network. The control entities 14, 16, 18 each have an overview of the physical and/or virtual network functions and/or network devices controllable by them. The control entities 14, 16, 18 may be local management entities.

The NSMF 12 is configured to determine configuration information for one or more virtual network functions to be placed on one or more network devices as well as path information about the network devices for operating one or more slices. The path information may comprise interconnection path information about interconnection paths among the network devices hosting virtual network functions. The configuration information may comprise virtual network function placement and/or embedding information. The NSMF 12 is also configured to provide the configuration information to at least one of the network devices and/or to a control entity 14, 16, 18 for at least one of the network devices.

The control entities 14, 16, 18 may configure network devices within their domains, for example through a controller, according to the path information and/or the configuration information. To this end, the path information may comprise information about paths in a fronthaul, a midhaul and/or a backhaul and/or an end-to-end path of the slice. The path information may also comprise information about paths in multiple network domains. The path information and/or the configuration information may also comprise information about virtual network functions forming one or more service chains. The path information may also comprise information about multiple service chains.

Each service chain whose embedding information is determined by the NSMF 12 may need to fulfil one or more quality of service, QoS, parameters. Such parameters may for example be a latency, a jitter and/or an energy consumption. The latency may be a predefined latency between two or more network devices for operating the slice. The chain embedding and interconnection path information may in particular be determined by the NSMF 12 in way so that it comprises an optimal set of network devices for operating the slice. In this context, an optimal set of network devices is a set of network devices which fulfills the quality of service parameters.

The control entity 14, 16, 18 to which the NSMF 12 provides the configuration information may not only be an NSSMF 14, 16, 18 but may also be another NSMF or a completely different entity like a local controller according to the communication network it is implemented in.

The network devices may each provide an individual set of virtual network functions, VNF, and/or value added services.

Fig. 2 shows a schematic overview of changes to a path computation element in order to make it slice-aware according to an embodiment of the invention. To allow the NSMF 12 to determine the path information and the configuration information, a variety of inputs 20 may be available to the NSMF 12 and/or the NSSMF 14, 16, 18. In particular, the inputs 20 may comprise information relating to a network topology, a network capability, a slice configuration and/or a resource allocation. The NSMF 12 may, for example, receive information about physical nodes, their latencies, their bandwidth, slices configured, slice templates, allocated resources and/or any of the resources named as input 20 in Fig. 2 as well as others falling into their respective domains from any of the control entities 14, 16, 18.

From the input 20, output 22 is generated by a processing entity 24. The output 22 comprises path information and/or configuration information to implement a network slice to fulfil the constraints of the input 20.

In particular, the configuration information may comprise a topology information, for example regarding the use of certain links between nodes. The configuration may further comprise capability information, for example the required capabilities to be configured on said links. Furthermore, the configuration information may comprise functional information, for example which virtual and/or physical network functions should be configured at which node of the slice. The configuration information may also comprise security information, for example the required encryption of certain links. The configuration information may also comprise performance information, for example for configuring performance parameters of a network node.

Fig. 3 shows a schematic overview of a centralized computation model according to an embodiment of the invention. In this computation model, the NSMF 12 by means of the processing entity 24 carries out the determination of the output 22 comprising path information and the configuration information based on the input 20 and a monitoring information provided by the NSSMF 14 of the transport network. This particular NSSMF 14 is shown here for example. Any of the NSSMF 14, 16, 18 or any other control entity may be used instead.

The monitoring information provided by the NSSMF 14 may comprise performance information, in particular latency, utilization information, in particular bandwidth and/or for the management or resilience information. The monitoring information may comprise further information not explicitly mentioned here.

The configuration information in the output 22 may comprise information on the configuration of resources and/or functions of a transport network. The above- mentioned information that is comprised as configuration information in the output 22 may thus be applied to resources and/or functions of a transport network.

The output 22 is transmitted via an interface 26 to the NSSMF 14. Configuration information in general can be organized as a template, in particular an at least partly completed template. The template may comprise any combination of parameters and functions. The NSSMF 14 thus may create a slice template 28 which comprises the configuration information and/or the path information from the output 22 in a way that is usable for configuring network devices of the transport network. In particular, the slice template 28 may be used to configure element managers 30 directly or by intermediary of a domain controller 32. Fig. 4 shows a schematic overview of a distributed computation model according to another embodiment of the invention.

In this embodiment, the NSMF 12 and the NSSMFs 14 share the load of processing the input 20. In particular, the NSMF 12 may carry out processing on its processing unit 24 with relation to the input 20 that is available to the NSMF 12. In particular, the processing may comprise determining path information about one or more network devices for operating a slice and/or determining configuration information for a virtual network function to be placed on the one or more network devices based on the path information. The results of the processing may be transmitted to the NSSMFs 14 for further processing in another processing unit 34. This processing is carried out using input 36 from the domain of each NSSMF 14.

Fig. 5 shows shows an example simplified representation of a message exchange for a network as well as a network function chain to be embedded in the network. The sequence of the message exchange may also be interpreted as a flowchart of a centralized slice embedding determination protocol according to the schematic overview of figure 3. A method for determining the path information and/or configuration information may comprise any subset of the steps and/or message exchanges shown therein. For simplicity, Fig. 5 shows the interactions of the NSMF 12 with a single NSSMF 14, although similar interactions will be carried out with all involved NSSMFs 14, 16, 18.

In this embodiment, the NSMF 12 will request input from the NSSMF 14, possibly combined that input 20 with information available within the NSMF 12 and process that input 20 to obtain an output 22 which comprises path information and/or configuration information.

To achieve this, the NSMF 12 may, in a first step 60, request network topology information from an NSSMF 14, for example via the interface 26. In a second step 62, the NSSMF 14 may transmit network topology information to the NSMF 12. In the third step 64, the NSMF 12 may request capabilities information from the NSSMF 14. In a fourth step 66, the NSSMF 14 may transmit capabilities information to the NSMF 12. In a fifth step 68, the NSMF 12 may process the input 20 comprising the network topology information and/or the capabilities information and/or further information to obtain and output 22 which comprises path information and/or configuration information.

The NSMF 12 may then, for example, send a network slice request in a further step 70 which may cause the NSSMF 14 to configure devices in its transport network. The NSSMF 14 may, in a further step 72, send a response which may comprise information about the slice and/or whether the slice was successfully created and/or other information relating to the slice.

Also, the NSMF 12 may, in a further step 74, request reservation of a resource from the NSSMF 14. This request may cause the NSSMF 14 to reserve resources in its transport network. Furthermore, the NSSMF 14 may, in a further step 76, sent a response which may indicate whether the resources were successfully reserved.

Fig. 6 shows a protocol flow diagram of a management device carrying out decentralized computation procedures according to another embodiment of the invention. For simplicity, it shows the interactions of the NSMF 12 with a single NSSMF 14, although similar interactions will be carried out with all involved NSSMFs 14.

In this embodiment, the NSMF 12 may request, in a step 80, domain information from the NSSMF 14, for example about which part of a network topology it controls. In particular, the NSMF 12 may request a list of physical nodes controlled by the NSSMF 14. The NSSMF 14 may, in a step 82, transmit a list of physical nodes and/or other domain information to the NSMF 12. The NSMF 12 may repeat these steps for every NSSMF 14, 16, 18 or any other control entity that it wishes to control.

In a further step 84, the NSMF 12 may process the information received in step 82 together with information available within the NSMF 12 to obtain an intermediate output 38 which it may send, in a step 86, to the NSSMF 14. The NSSMF 14 may process that intermediate output 38 as an input and may respond, in the further step 88, with a minimum cost path information which may be optimized for one or more quality of service parameters. That minimum cost path information may complement the input 20 of the NSMF 12.

Steps 84, 86 and 88 may then be repeated, also for other NSSMFs 14, 16, 18 and/or other control entities. The repetition stops as soon as an optimal path has been found according to the quality of service parameters required. Once the repetition stops, steps 70, 72, 74, 76 may be carried out.

Appropriately embedding VNFs on physical nodes and selecting the physical paths interconnecting these nodes at a minimum "cost", while respecting: a) e2e NSI QoS requirements and b) physical link and node capacity constraints, is considered a hard problem both from the mathematical and systemic point of view. The invention addresses this problem by:

• Defining advanced computational procedures to accommodate joint VNFs embedding and routing in support of Network Slicing for the end-to-end integrated network.

• Defining appropriate messaging procedures between the NSSMF 14, 16, 18 entities and the NSMF 12 to facilitate dynamic network configuration and VNF embedding during advanced path computation.

• Analyze the communication stages between the mobile and the transport networks during processing for finding the optimal VNF embedding and network pipes.

• Establishing mechanisms that are able to provide e2e service guarantees for VNF chains in the light of network slicing.

• Defining NSSMF 14, 16, 18 slice oriented interactions with Element Managers 30 or Domain controllers 32 to facilitate dynamic network configuration and flexible VNF embedding

The path information referenced above may also be referred to as a routing path.

Determining path information may also be referred to as path computation, in particular routing path computation.

Note that the SLA mapping mechanics between the mobile and the transport network to drive the input to our advanced computational procedures for slice aware routing paths computations are not precisely defined by the invention and can be suitably selected by the operator.

Technical Approach

We consider that end-to-end communication services rely on interconnected NFs (Physical Network Functions (PNFs) and/or Virtualized Network Functions (VNFs)) between the Radio Access Network, RAN, and the Core or Core Network, CN. We also consider that VNFs can also be deployed inside the transport network like DPI or Firewalls.

From PCE to Advanced Computations

The invention defines an approach where instead of the monolithic operation of simple path computations performed in the PCE, advanced computational procedures are used to accommodate features like VNFs placement and routing in support of Network Slicing.

A high level design of the approach is depicted in Fig. 2. For the slice aware advanced computational procedures, the invention employs the core concepts of input 20, information processing 24, and output 22 as follows:

• Input 20, 36: Besides physical topologies and the SLAs (like in the case of PCE), advanced computational procedures also consider input 20, 36 like: a) current and desired NSSI state and performance; b) desired VNF chains; c) physical network/systems topologies; d) monitoring OAM information; and e) available VNF libraries. The list is not exhaustive and can be enriched depending for example on technology specific requirements of the transport network.

• Processing 24, 34, 68, 84: The following primitive objectives of the advanced computations operations can be identified for example: a) admission control; b) pre emption; and c) network embedding. The invention targets network embedding operations. New policies need to be designed that are able to optimize the operational environment, while at the same time intra-NSSI optimizations, respecting the SLAs.

• Output 22: In the light of Network Slicing the output of enhanced computational operations is not just a route, but a NSSI template describing for example how VNF embedding must be performed together with the routing information. After the end-to- end solution is derived, NSSMF 14, 16, 18 entities interacts with the corresponding Domain Controllers 32 (e.g. SDN controllers) or directly with network Element Managers 32 (EM) for the actual enforcement of the slice template.

The invention exploits and extends the available interfaces used for the communication between the end-to-end NSMF 12 management and orchestration system and the NSSMF 14, 16, 18 systems of slice aware networks. The invention also considers the design of new mechanisms that are able to provide end-to-end service guarantees for VNF chains in the light of network slicing.

More specifically, we consider the following two cases of advanced computations on the way NSMF 12 and NSSMF 14, 16, 18 interact during processing. These cases are depicted in Figs. 3 and 4:

• Case 1 (Fig. 3): Computations or processing 24 are performed only in the NSMF 12 end-to-end. NSSMF 14 is informed through the specific template created after computations are made. NSSMF 14 is only responsible for the lifecycle management of the NSSI.

• Case 2 (Fig. 4): In the second case NSMF 12 and NSSMFs 14 need to interact during computation in order to derive the end-to-end solution. The e2e solution is assembled in the NSMF 12 via an iterative process.

Input 20, Output 22 and Advanced computation procedures for slice-aware minimum cost embedding

In this section we describe in detail a modeling approach on how to solve the hard problem of service chains' network embedding on per NSI basis. We also elaborate on how the integrated NSMF 12-NSSMFs 14, 16, 18 system is operating, which are the input 20, output 22 parameters and how the computational procedures 24, 34 are performed.

By means of minimum cost network embedding on per NSI basis, the core problem solved by our invention can be stated as follows. Given a physical network with specific topology, available resources, and cost of using these resources and a bunch of VNF/PNF chains with specific resource demands to be embedded on this given physical network, find the minimum cost embedding of all these chains subject capacity, VNF/PNF embedding, end-to-end QoS and integrality constraints on per NSI basis. The QoS constraint can be any additive constraint in the sense that the sum of the values of a certain QoS parameter over all links and nodes in a path must be less than or equal to a quality of service required value. Such QoS parameters can be, e.g., latency, jitter, energy consumption, etc. Multiplicative constraints (such as Packet Error Rates) can also be handled by adding the logarithms of the per link parameters. In the following we will use latency as the QoS constraint, but note that any additive or multiplicative constraint can be handled. To formally define the problem we use the following mathematical formulation. From an implementation perspective, these will be input 20 parameters to the slice-aware advanced computational procedures 24, 34 subsystem:

Input Parameters: Depending on the way the problem is solved (centrally by the NSMF 12 or distributed by both the NSSMFs 14, 16, 18 and the NSMF 12) these parameters are passed to the corresponding entity that is responsible for driving the advanced path computation procedures 24, 34.

INPUT 20: A physical network graph G(V,E,c,p,d) where: o V is the set of physical nodes (MTs, RUs, routers or VMs) o E is the set of physical links (wireless or wireline) o b is a vector containing all physical link capacities, b_q (e e E), and physical node capacities, b„(n e V) o c is a vector containing all physical link costs, c_e (e e E), and physical node costs, c_v (v e V) o d is a vector containing all physical link delays, d_e (e e E) and physical node delays, d„(v e V)

A very simplified example of physical network is shown in Fig. 7. In this Figure, solid lines represent wireline links 42, whereas dotted lines denote wireless links 40. Multiple wireless links 40 between the same pair of nodes 44 denote different service classes which offer different delays and capacities usually at the relevant cost. Note that a single wireless physical node 44 might in fact denote the set of all mobile nodes 44 running the considered application in a particular physical area.

INPUT: A number of K NF chains. For each chain k = 1, 2, ... ,K , S_k(N_k,L_k,t_k,6_k,\4) where: o N_k is the set of virtual nodes 44 (VNFs or PNFs) o L is the set of virtual links 40, 42 o t_k vector containing all virtual link capacity demands, t_n (neN_k),and virtual node resource demands, ti (I e L_k) o 6_k is the end-to-end delay requirement o V_k is the set of all sets V_n where each set of physical nodes V_n contains all

embedding options for virtual node n e N_k

Note that two different sets V_n,V_m e V_k might be overlapping which means that two (or more) different NFs can be embedded onto the same physical node 44 (provided that the physical node 44 has available resources to accommodate their aggregate demands). In this case the virtual link 40, 42 connecting the two NFs is embedded to an empty path with zero cost and delay. A simplified example of an NF chain that needs to be embedded on the physical network is also shown in Fig. 7 that represents the problem in an abstract graph format.

Output 22: The output parameters are part of a slice template that is created by the orchestration entities after the computation procedures are performed:

For each NSI, every chain S, : o Each virtual node 44 n e N_k is embedded to a physical node 44 v = f(h). o Each virtual link I = (m,n) e L_k is routed through a unique path r(f(iti),f(h)).

More specifically, these parameters are used inside the slice template and are passed from the NSSMF 14, 16, 18 entity to the Domain Controllers 32 that are responsible for the execution of the necessary installation/instantiation/ configuration of the network elements and VNFs. A domain controller 32 can interact with an ETSI MANO system for this purpose.

Advanced Computational Procedures

The invention may make use of Advanced Computational Procedures. These are either performed only in the NSFM 12 (case 1) or jointly by NSMF 12 and NSSMF 14, 16, 18 (case 2).

In order to produce the output 22 the following constraints must be met:

^■ Node capacity constraints: the sum of the resource demands of all virtual nodes 44 (from all chains) that are embedded on a given physical node v, 44 needs to be less than or equal to b_n. ^■ Link capacity constraints: the sum of the link capacity demands of all virtual links 40, 42 (from all chains) whose physical path contains physical link e, 40, 42 needs to be less than or equal to b_q.

^■ Node embedding constraints: Each virtual node n, 44 must be embedded in one of the nodes 44 in each embedding options set (f(h) e V_n ).

^■ End-to-end latency constraints: for each chain k the sum of the physical link 40, 42 and node 44 latencies in the end-to-end embedded chain must be no greater than 6_k. This sum includes all the latencies incurred over physical nodes 44 to which the virtual nodes 44 of the chain have been embedded and the latencies incurred over the physical nodes and links in all paths connecting the virtual links 40, 42 of the chain.

First, we are going to explain the novel algorithm for solving this problem and then describe a centralized and a hierarchical implementation of this algorithm in a complete system. In order to explain the algorithm, we will follow a bottom-up approach. We will first describe the building blocks and then explain how the high level algorithm is using these building blocks to solve the entire problem. We will also make the simplifying assumption that nodes 44 have unlimited resource capacity, no cost for using the resources and incur zero delay. We will extend the algorithm to cover the general case later on.

Building block 1 (Path Computation Element - PCE): Find a min-cost path between two nodes 44 in the graph that can accommodate a given flow given the costs and capacities of all the physical links 40, 42.

This is easily achieved by running the well-known Dijkstra's algorithm on a modified graph, derived from graph G when deleting all links 40, 42 with capacity smaller than the demand of the given flow. Note that the same building block can be used with link costs that are no the original link costs but have been properly modified. We can call this building block as PCE (vi, V , t, G(V,E,c,P)) where Vi and V are the source and destination nodes 44, t is the requested capacity, and G a physical graph.

Building block 2 (Chain Embedding No QoS - CENQ): Find a min-cost single chain embedding (no e2e QoS constraint). This building block can find a min-cost single chain embedding without any end-to-end latency guarantees. It can be implemented by the following algorithm (although other implementations are also possible).

Step 1: Create the "reduced graph" as follows:

First, for every NF n in the chain take the nodes 44 in the set V_n set and add them to the reduced graph. Exclude the nodes 44 that have not enough capacity to accommodate the demand of the corresponding NF. For instance in Fig. 7, we assume that node 8 has not enough capacity to accommodate the demand of VNF D. Nodes 44 that belong to more than one set V_n are duplicated in the reduced graph. For example nodes E.15 and F.15 in Fig. 8 correspond to physical node 15 which belongs to both V_E and V_F. In case that the cardinality of the set corresponding to the first NF in the chain is greater than one, add one extra "starting node". Similarly, add an extra "ending node 46" in case the cardinality of the set corresponding to the last NF is greater than one. In Fig. 8 the "ending node 46" X has been added.

Then for every pair of nodes 44 in neighboring sets add a reduced link 40, 42 as shown in Fig. 8. The cost of each reduced link is set equal to the cost of the minimum cost path connecting the respective nodes in the physical network (from which physical links with capacity less than the demand of the associated virtual link have been removed) times the demand of the corresponding virtual link 40, 42. For instance, the cost of link (B.2, C.7) in Fig. 8 is set equal to the cost of the minimum cost path between nodes 2 and 7 in the physical network times the demand t(B,C). This cost can be obtained by using building block 1: PCE (2, 7, t_(B,c>, G( ,E ,c , ^ )). The reduced links connecting the "starting" and "ending" nodes 48, 46 to the rest of the reduced graph are assigned a zero cost.

Step 2: Run Dijkstra's algorithm on the reduced graph to find the min-cost path from the "starting" to the "ending" node 48, 46. Substitute the single node 44 corresponding to the first (last) NF for the starting (ending) node 48, 46 if no "starting" ("ending") node exists. The returned path solves the chain embedding problem. The nodes 44 in the path indicate where to embed the NFs and the reduced links 40, 42 in the path correspond to physical network paths 40, 42 interconnecting the physical nodes 44, 46, 48 to which NFs have been embedded. We can call building block 2 as CENQ (G (n,E,o,b), S(N,L,t,V)) where G is a physical network graph and S is the NF chain. Note that the latency information is not needed as CENQ calculates the optimal chain embedding without guaranteeing latency constraints.

Building block 3 (Chain Embedding with end-to-end QoS - CEQ):

The algorithm for finding a minimum cost single chain embedding with end-to-end QoS guarantees is a novel algorithm which lies at the core of our invention. It is an extension of the well-known LARAC algorithm which finds a single constrained min-cost path but does not cover the combined node embedding and end-to-end constrained path problem we are considering in this invention. We denote a call to building block 3 by CEQ(G(V,E,c,p,d), S(N,L,t,6,V)) and expect CEQ to return both the embedding solution and the cost of this solution. The Flow Chart of CEQ is shown in Fig. 9. In this Flow Chart, we denote by e_c, 8_d, and ec candidate NF chain embeddings that are returned by calling CENQ with modified costs. We also use functions d(s) and C(E) which compute the end- to-end delay and cost of NF chain embedding e, respectively.

Top-level problem: Min-cost, multiple NF chain embedding, with end-to-end QoS and capacity constraints

Finally, we use a Column Generation (CG) and rounding approach to solve the complete problem. Column Generation is a well-known algorithm for solving the min-cost multi- commodity flow problem (MCF). When using CG to solve the MCF, a set of routes is maintained at each iteration and an optimal solution over this set of routes is calculated. Adding new routes in the set is achieved by finding min-cost paths on the network with appropriately modified costs (using, e.g., Dijkstra). In our case, we replace Dijkstra with CEQ and add new chain embeddings (instead of new routes) to the set of solutions until convergence.

The above CG method finds a solution to the LP relaxation of the problem, i.e., for the case where each NF chain can be split over more than one embedding e so that a fraction of the demanded resources is accommodated by each embedding. In case we are constrained to unsplittable embeddings, CG needs to be followed by rounding. Many rounding algorithms are known in the literature. Rounding does not guarantee that the optimal integral embedding solution will be found, only a feasible integral solution is guaranteed. One possible implementation of the CG method for solving this problem is the following:

First we need to write an LP formulation of the problem. We define the set ¾ which is the set of all possible embeddings of NF chain S which satisfy the end-to-end QoS constraint and the multiset i which is the union of all sets ¾ , k=l,...,K, and assume that the cardinality of if is Q. We also define the following vectors and matrices: f = [fi , ... , fcj', which represents a vector of decision variables, i.e., f_q is the fraction of the corresponding NF chain going through embedding e_q. Note that this vector has a very large number of elements. For f_q e {0,1} we have the integral version of the problem, whereas for f_q e [0,1] the LP relaxation; g = [gi , ... , gq ]', which represents the cost coefficients (g_q is the total cost of embedding £_q, including the cost of all physical links in the embedding);

D is a real matrix of size | E | ^c Q whose elements are the product of a {0,1} variable indicating if physical link e is used by embedding e or not times the utilization of the link (which is equal to the demand ti of the virtual link / going through this physical link);

P is a binary indicator matrix of size K ^c Q where a row identifies all embeddings that can be used by the corresponding chain.

The multiple chain embedding problem is then formulated as follows (we denote by 1 a column vector with all elements equal to 1, and by 0 a column vector with all elements equal to 0): min g'f

s.t. Df < b

Pf = 1 (1-1)

f > 0

Let us define u = [m, s]' the vector of dual variables corresponding to the constraints of the primal problem m < 0 is the vector of size | E | ^c 1 corresponding to the capacity constraints, while s e R is the vector of size K ^c 1 corresponding to the flow conservation constraints. For the sake of clarity, we set m > 0 and modify accordingly the sign of its coefficients in the dual formulation. The dual formulation of the problem is as follows:

The main idea of the CG method is that instead of solving the full problem (1.1) over the set of all possible embeddings If, we solve it for a subset of if (which we will denote byff) and based on this solution we identify new embeddings that can be added to ffin order to improve the solution. Each new embedding adds a new column to the constraint matrices D and P, hence the name Column Generation. There are several variants of CG depending on whether we also remove certain embeddings from ffas we go on, and the number of embeddings we add to / remove from

at each iteration. In traditional CG we add and remove exactly one embedding/column at each iteration. The flow chart of one possible CG implementation for solving problem (1.1) is shown in Fig. 10. Note that in this implementation we only add new embeddings to the set

and keep solving a restricted version of problem (1.1) on this set until a solution is found whose dual is a feasible solution to problem (1.2). This solution is known from duality theory to be an optimum solution to the unrestricted problem (1.1). Upon finding the optimum solution to the relaxed LP problem (1.1) any known method for rounding this solution to an integer solutions (such as randomized rounding) can be used to obtain such an integer solution to the corresponding ILP problem.

Note that CG is not the only way of solving the LP problem (1.1) but it is a very efficient methods especially for centralized implementation. A Lagrange relaxation approach is another possible method which might lead to better distributed implementations more suitable to the hierarchical implementation embodiment according to Fig. 6. The present invention aims at protecting all possible ways to solve problem (1.1).

One of the invention's objects is the design of a system that is able to support advanced path computation procedures in the light of network slicing. Furthermore, we advance the current state of the art in the way e2e and local orchestration and management systems are jointly operating to undertake the advanced computation procedures execution. Regarding the path computation procedures the invention is targeting minimum cost embeddings of multiple NF chains on the same physical network while respecting capacity constraints and providing end-to-end QoS guarantees. The approach considered and the way the NSMF (e2e) and NSSMF (local domain) entities are interacting to solve the complicated NF chain embedding problem, can be easily extended to include physical node costs, capacities and delays.

• We define the appropriate messaging procedures between the NSSMF entities and the NSMF to facilitate dynamic network configuration and VNF embedding during advanced path computation procedures.

• The input/processing/output processes defined, accommodate joint VNFs embedding and routing for the end-to-end integrated network.

• We establish the algorithmic mechanism that is able to provide the challenging and important problem of e2e service guarantees though VNF chains embedding in the light of network slicing.

• We also consider the NSSMF 14, 16, 18 interactions with Element Managers 30 or Domain controllers 32 to facilitate dynamic network configuration and flexible VNF embedding.

We present 2 further embodiments of our invention with different degrees of distributed operation. More specifically we will start by presenting a centralized embodiment in which the NSMF 12 collects all network information and runs all computations locally to decide how to embed the VNF chains. We will then describe a hierarchical embodiment in which the NSMF offloads some of the computations to the NSSMFs.

Further embodiment: Centralized computations at the NSMF 12:

The centralized approach is the easiest to describe and can serve as a basis for understanding the hierarchical approach. In this embodiment the NSMF needs to collect all relevant information about the physical network (on which the VNF/PNF chains need to be embedded) and all the VNF/PNF chains that need to be embedded.

More specifically, in order to perform the necessary computations and decide on the VNF/PNF embeddings, the NSMF 12 needs to collect the following information:

• Information to construct the physical network graph G (V,E,c, ,d) as defined above. • Information about all VNF/PNF chains. For each chain k, S_k (N_k,L_k,t_k,6_k,\4) as defined in Section 3.:

Furthermore:

• NSMF 12 also keeps track of which pNodes and pLinks belong to each NSSMF 14, 16, 18 domain.

• Algorithm outputs vNodes-> pNodes and vLinks->physical paths embeddings.

• The NSMF 12 breaks the e2e embedding to pieces according to network

domains and sends each piece to the corresponding NSSMF.

• Local NSSMFs 14, 16, 18 are only responsible for the lifecycle management of the NSSI.

There are several variants related to the way information is gathered and updated.

Some information (such as network topology) is static or slowly changing but other information (such as remaining resources) is dynamic and needs to be collected periodically. One can implement different ways of keeping the information up to date such as periodic update requests by the NSMF 12 or notifications by the NSSMFs 14, 16, 18 when there is a change in parameters or a combination of both.

Similarly, there are different approaches to Network Chain embedding management. As the chain embedding requests will arrive dynamically or in batches, one approach is to handle each new request (batch of requests) independently by embedding it on the remaining of the network resources (leaving previous embeddings unaffected). Another approach is to wait for a certain amount of time to gather a number of requests and embed all of them together. Finally, re-optimization of all NF embeddings (new requests and already embedded) is an extreme option that keeps the network at an optimal state at the expense of frequent reconfigurations of existing embedding. One possible exchange of messages between the NSMF 12 and the NSSMFs 14, 16, 18 in order to provide multiple NF chain embeddings with centralized computations is shown in Fig. 5. In this Figure, we denote by G_m the sub-network of physical network G controlled by the m-th NSSMF 14. We also denote the embedding solution for a single chain S as f(S) and the part of it which goes through the domain of NSSMF 14, m, f_m(S). The set of all chains passing through the domain of NSSMF 14, m is denoted by Q_m. In this timing diagram we depict the case in which the network topology remains relatively unchanged and thus is communicated to the NSMF 12 only once in step 62. Then a bunch request to embed K NF chains is received and the NSMF 12 asks from all the NSSMFs 14 and receives the current state of physical node and links remaining capacities, costs and incurred delays in step 64. Based on this information the NSMF 12, in step 68, performs the advanced computations described above. It then splits the solution into parts so that each end-to-end chain embedding is divided into the embedding associated to each sub-network and sends each part to the NSSMF 14 controlling sub-network m in step 70. The NSSMF 14 confirms that the requested resources are available and reserves them in step 72. Upon collecting positive responses from all NSSMFs 14, 16, 18, the NSMF 12confirms the resource request in step 74 and the embeddings are realized on the physical network. Finally, the NSSMFs 14, 16, 18confirm that they have completed the embedding process to the NSMF 12 in step 76, at which stage the process has completed successfully.

Further embodiment: Hierarchical NSMF / NSSMFs implementation:

In this embodiment we propose a hierarchical implementation of the advanced computations needed to determine the NF chain embeddings. Hierarchical means that the NSMF 12 runs the Top-Level part of the algorithm, the CEQ and the CENQ, while the PCE function is performed at the appropriate NSSMF 14, 16, 18. More specifically, we assume that each NSSMF 14, 16, 18 controls a single network domain and will be in charge for managing NSSIs. On the borders between domains there are Gateway nodes which belong to both domains and play the role of forwarding packets from one domain to the other. A NSSMF 14, 16, 18 can run the PCE function to determine the min cost route between two nodes lying in its domain (including the gateway nodes). We also assume that each set of embedding options V_n for a given VNF lies entirely in a single domain.

In order to implement the algorithm presented in Fig. 6, the NSMF does not need to know all the topological information of the physical network G(V,E,c,p,d). It receives the NF chains S_k and needs to learn to which domain (and NSSMF 14, 16, 18) each V_n belongs. It can get this information either by the service requesting the chain, by asking the NSSMF14, 16, 18, or by keeping a DB of nodes in the network and their associated domain. Then we need to extend the network graph and NF chains S as shown in Fig. 10. For each domain border it includes one more virtual node (in this example R) in the chain which can be embedded to anyone of the gateway nodes between the two domains (in this example nodes 11, 12 and 13). The two new virtual links (in this example (D, R) and (R, E)) take the cost and resource demand of the link they have replaced (in this example (D, E)). The new virtual node (in this example R) has zero cost and resource demand.

In fact, the NSMF 12 does not need to have complete knowledge of this physical network graph, only enough information to construct the reduced graph resulting from this physical network graph. To achieve this it will call the PCE running in the corresponding NSSMF 14, 16, 18 in step 86 to get the reduced graph link connecting two reduced graph nodes. For example the PCE running in NSSMF 14, 16, 18 of domain 1 will return the reduced link information for (C.7, D.8) and (D.7, R12) in step 88. The NSSMF 14, 16, 18 will return the solution to the NSMF 12 consisting of the physical path, cost and delay. This gives enough information to the NSMF 12 to solve the reduced primal problem (1.1) find the solution to (1.2) and update the physical link costs for the next generation of the CG procedure. Note that at each iteration these costs will be passed down to the CEQ which will calculate appropriate costs to pass down to the CENQ which will call the PCE of the associated NSSMFs 14, 16, 18 with the appropriately modified physical link costs. The PCEs will find new min-cost paths and send them back to the CENQ. This iterative process will thus generate considerable traffic overhead but will parallelize the solution and won't require the NSMF 12 to have complete topology information of the full physical network graph.

In Fig. 6, we provide a possible exchange of messages between the NSMF 12 and the NSSMF's 14 in order to provide multiple NF chain embeddings with hierarchical computations. In this case the NSMF 12 does not need to know the complete network topology. In the implementation shown in the Figure, it only learn all the physical nodes in the network and which nodes are controlled by each NSSMF 14, 16, 18 in step 80. (In an alternative implementation it only learns the gateway nodes and after each embedding request the network domain of all nodes included in the location embedding sets of the chain requests). After receiving the request to embed K chains, the NSMF 12 can build the extended NF chains (based on the knowledge about gateway nodes). It then proceeds to perform the advanced computations described above in step 84. Along the computation it will make multiple calls to the function PCE (vi, V2, t, G(V,E,c,P)) for different pairs of source-destination nodes and modified costs c. These calls will be sent to the NSSMF 14, 16, 18 controlling the source and destination nodes in step 86 which will run the PCE and return the answer (including the cost and delay of the path as well as all physical links contained in the path) back to the NSMF 12 in step 88. Upon completing the advanced calculations and determining the optimal embeddings the remaining of the process is the same as in the centralized implementation case.

In some embodiments, a domain controller 32 may be comprised in or may be an NSSMF 14, 16, 18. In some embodiments, a control entity may be an NSMF 12 or an NSSMF 14, 16, 18. The management device may be comprised in an NSMF 12.

While the invention has been illustrated and described in detail in the drawings and the foregoing description, such illustration and description are to be considered illustrative or exemplary and not restrictive. The invention is not limited to the disclosed embodiments. From reading the present disclosure, other modifications will be apparent to a person skilled in the art. Such modifications may involve other features, which are already known in the art and may be used instead of or in addition to features already described herein.

In the claims, the word "comprising" does not exclude other elements or steps, and the indefinite article "a" or "an" does not exclude a plurality. A single processor or other unit may fulfil the functions of several items recited in the claims. The mere fact that certain measures are recited in mutually different dependent claims does not indicate that a combination of these measures cannot be used to advantage. A computer program may be stored/distributed on a suitable medium, such as an optical storage medium or a solid-state medium supplied together with or as part of other hardware, but may also be distributed in other forms, such as via the Internet or other wired or wireless telecommunication systems.

Claims

1. A management device (12) for slice management of a communication network, configured to:

- determine path information about one or more network devices for operating a slice;

- determine configuration information for a virtual network function to be placed on the one or more network devices based on the path information ;

- provide the configuration information to at least one of the network devices and/or to a control entity (12, 14, 16, 18) for at least one of the network devices.

2. The management device of the preceding claim, wherein the path information comprises information about at least one of:

- a Fronthaul;

- a Midhaul;

- a Backhaul;

- an end-to-end path of the slice.

3. The management device of one of the preceding claims, wherein the path

information comprises information about one or more VNFs and/or one or more value added services placed one or more network devices for operating the slice.

4. The management device of one of the preceding claims, wherein the path

information comprises an optimal set of network devices for operating the slice, in particular wherein the slice fulfills one or more Quality-of-Service, QoS parameters, e.g. a pre-defined latency between two or more network devices for operating the slice.

5. The management device of one of the preceding claims, wherein the control entity is another management device, in particular an NSSMF (14, 16, 18).

6. The management device according to the preceding claim, configured to receive from the control entity information related to at least one of:

- a network topology; - capability;

- slice configuration;

- resource allocation.

7. The management device, wherein the configuration information comprises one or more of the following:

- topology information;

- capability information;

- functional information;

- security information;

- performance information.

8. The management device according to one of the preceding claims, wherein the configuration information comprises information on a configuration of resources and/or functions of a transport network.

9. The management device of one of the preceding claims, configured to receive monitoring information from one or more of the network devices and/or from one or more management entities, wherein each monitoring information is related to one or more of the network devices for operating the slice.

10. The management device according to the preceding claim, wherein monitoring information comprises at least one of:

- performance information, in particular latency;

- utilization information, in particular bandwidth;

- Fault management or resilience information.

11. A slice management method, comprising the steps:

- receiving, by a management device(12) from a control entity (14, 16, 18), input

(20);

- processing (24, 68, 84), by the management device (12), of the input (20) to determine an output (22), wherein the output comprises path information about one or more network devices for operating a slice and configuration information for a virtual network function to be placed on the one or more network devices based on the path information;

12. The slice management method according to claim 11, wherein the receiving step comprises:

requesting (60, 64), by the management device (12) from the control entity (14,

16, 18), at least one of

- a network topology;

- capability;

- slice configuration;

- resource allocation and

receiving (62, 66), by the management device (12), the requested information as input (20).

13. The slice management method according to claim 11 or 12, wherein the

processing step comprises:

- processing (84) input (20) from one or more of the control entities (14, 16, 18) to obtain an intermediate output (38);

- sending (86) the intermediary output (38) to the control entity (14, 16, 18) for determining a minimum cost path information according to a quality of service- parameter;

- receiving (88) the minimum cost path information as additional input (20) and

- repeating these steps (84, 86, 88) until an optimal path fulfilling the quality-of- service parameters has been found.

14. The slice management method according to any of the claims 11 to 13, comprising the step:

- requesting (70) configuration of a slice.

15. Computer program having a program code for performing the method according to any of the claims 11 to 14, when the computer program runs on a computing device.