Dynamic constrained network slice deployment

Abstract

Dynamic constrained network slice deployment A control node (250) identifies one or more constraints applying to deployment of a network slice by cloud applications executed on one or more nodes (220) of the communication network. Further, the control node (250) collects capability information of the nodes (220). The capability information respectively indicates one or more cloud applications that are supported by the node (220). Based on the identified one or more constraints and the collected capability information, the control node (250) computes configuration of the network slice.

Description

[0001] Dynamic constrained network slice deployment

[0002] Technical Field

[0003] The present invention relates to methods for controlling operation of a wireless communication network and to corresponding devices, systems, and computer programs.

[0004] Background

[0005] In communication networks, e.g., wireless communication networks based on the 4G (4th Generation) LTE (Long Term Evolution) or 5G (5th Generation) NR technology as specified by 3GPP (3rd Generation Partnership Project), it is known to implement infrastructure of the communication network using cloud computing and virtualization technologies. For example, network slicing may be used to provide resources of the communication network in a virtualized manner, thereby allowing for various kinds of optimization, e.g., concerning scaling, performance, or implementation cost. In this context, a network slice may be regarded as a virtualized network configuration designed to deliver customized network services. A network slice may be tailored to meet certain needs such as performance levels of services or the like. In this sense, a network slice logically corresponds to complete network, which is tailored to meet the specified needs. A network slice may be based on VNFs (Virtualized Network Functions) which correspond to discrete virtualized network functionalities that support operation of the overall network slice by executing specific tasks or services.

[0006] A typical starting point for deployment of a network slice is a set of predefined physical and / or virtualized network resources, such as physical nodes or clusters of physical nodes configured to provide one or more virtualized network resources. As a result, also physical locations of the resource used in the deployment are already defined. The physical locations may in turn be associated with constraints, e.g., concerning security, cost, availability, vulnerability, privacy or power efficiency. With existing network slice deployment strategies, consideration of such constraints can be rather challenging and may require considerable offline planning effort. This can for example be problematic if the utilized resources are subject to a failure, e.g., due to a crash or attack, and an alternative deployment of a network slice needs to be provided, taking into account the dynamic situation related to the available resources. Accordingly, there is a need for techniques which allow for efficient deployment of a network slice in a dynamic environment.

[0007] Summary

[0008] According to an embodiment, a method of controlling operation of a communication network is provided. According to the method, a control node identifies one or more constraints applying to deployment of a network slice by cloud applications executed on one or more nodes of the communication network. Further, the control node collects capability information of the nodes. The capability information respectively indicates one or more cloud applications that are supported by the node. Based on the identified one or more constraints and the collected capability information, the control node computes configuration of the network slice.

[0009] According to a further embodiment, a control node for a communication network is provided. The control node is configured to identify one or more constraints applying to deployment of a network slice by cloud applications executed on one or more nodes of the communication network. Further, the control node is configured to collect capability information of the nodes. The capability information respectively indicates one or more cloud applications that are supported by the node. Further, the control node is configured to, based on the identified one or more constraints and the collected capability information, compute configuration of the network slice.

[0010] According to a further embodiment, a control node for a communication network is provided. The control node comprises at least one processor and a memory. The memory contains instructions executable by said at least one processor, whereby the control node is operative to identify one or more constraints applying to deployment of a network slice by cloud applications executed on one or more nodes of the communication network. Further, the memory contains instructions executable by said at least one processor, whereby the control node is operative to collect capability information of the nodes. The capability information respectively indicates one or more cloud applications that are supported by the node. Further, the memory contains instructions executable by said at least one processor, whereby the control node is operative to, based on the identified one or more constraints and the collected capability information, compute configuration of the network slice.

[0011] According to a further embodiment, a computer program or computer program product is provided, e.g., in the form of a non-transitory storage medium, which comprises program code to be executed by at least one processor of a node for a communication network. Execution of the program code causes the node to identify one or more constraints applying to deployment of a network slice by cloud applications executed on one or more nodes of the communication network. Further, execution of the program code causes the node to collect capability information of the nodes. The capability information respectively indicates one or more cloud applications that are supported by the node. Further, execution of the program code causes the node to, based on the identified one or more constraints and the collected capability information, compute configuration of the network slice.

[0012] Details of such embodiments and further embodiments will be apparent from the following detailed description of embodiments.

[0013] Brief Description of the Drawings

[0014] Fig. 1 schematically illustrates a wireless communication network according to an embodiment.

[0015] Fig. 2A schematically illustrates a control architecture according to an embodiment.

[0016] Fig. 2B schematically illustrates an example of dynamic constraint information.

[0017] Fig. 2C schematically illustrates an example of set constraint information.

[0018] Fig. 3 schematically illustrates network slice deployment processes according to an embodiment.

[0019] Figs. 4A schematically represents an example of a network slice.

[0020] Figs. 4B schematically represents an example of network infrastructure for deploying the slice of Fig. 4A.

[0021] Fig. 4C shows network resources assumed in the example of Figs. 4A and 4B.

[0022] Figs. 5A, 5B, and 5C show representations of a network slice connectivity matrix in the example of Figs. 4A, 4B, and 4C.

[0023] Fig. 6 illustrates a representation of the network slice of Fig. 4A on the network infrastructure of Fig. 4B. Fig. 7 shows a connectivity matrix for data centers in the network slice.

[0024] Figs. 8A and 8B illustrate simplified representations of the network slice.

[0025] Figs. 9A, 9B, 9C, 9D, and 9E show representations for consideration of individual links of the network slice.

[0026] Fig. 10 illustrates a representation of the network slice where an eligible node is considered as root of a spanning tree.

[0027] Fig. 11 illustrates a connectivity matrix for the representation of Fig. 10.

[0028] Figs. 12A, 12B, 12C, 12D, and 12E show representations where the spanning-tree representation of Fig. 10 is combined with the relevant connectivity information from the connectivity matrix of Fig. 11.

[0029] Figs. 13A, 13B, 13C, and 13D illustrate combining of the connectivity matrices underlying the representations of Figs. 12A, 12B, 12C, 12D, and 12E.

[0030] Fig. 14 illustrates a result combining the connectivity matrices.

[0031] Figs. 15A and 15B show representations of possible solutions for deployment of the network slice.

[0032] Figs. 16 schematically represents a further example of a network slice.

[0033] Fig. 17 illustrates a representation of the network slice of Fig. 16 on assumed network infrastructure and taking into account constraints.

[0034] Figs. 18A, 18B, and 18C show representations for consideration of individual links of the network slice.

[0035] Figs. 19A, 19B, and 19C illustrate a representations of the network slice where a first node is considered as root of a spanning tree. Figs. 20A, 20B, and 20C illustrate a representations of the network slice where a second node is considered as root of a spanning tree.

[0036] Figs. 21 A, 21 B, and 21 C illustrate a representations of the network slice where a third node is considered as root of a spanning tree.

[0037] Fig. 22 and 23 schematically illustrates a virtualization-based transport architecture which may be used in network slice deployment according to and embodiment.

[0038] Figs. 24A and 24B illustrates an exemplary implementation of a virtual-endpoint protocol object according to an embodiment.

[0039] Fig. 25 illustrates an exemplary implementation of a TLV (Type Length Value) for representation of a network slice according to an embodiment.

[0040] Figs. 26A and 26B illustrate an exemplary implementation of CAN (Cloud Native Application) subobjects in the TLV of Fig. 25.

[0041] Fig. 27 shows an example of objective functions that can be included in a network slice request according to an embodiment.

[0042] Fig. 28 shows an example of error codes that can be returned in response to a network slice request according to an embodiment.

[0043] Figs. 29A, 29B, and 29C shows an exemplary implementation of a protocol information element for conveying CNA registry information according to an embodiment.

[0044] Fig. 30 shows a flowchart for schematically illustrating a method according to an embodiment.

[0045] Fig. 31 schematically illustrates structures of a physical node according to an embodiment.

[0046] Detailed Description

[0047] In the following, concepts in accordance with exemplary embodiments of the invention will be explained in more detail and with reference to the accompanying drawings. The illustrated embodiments relate to controlling operation of a communication network, in particular with respect to deployment of a network slice. The communication network may be a wireless communication network, e.g., based on the 5G NR technology specified by 3GPP. However, other technologies could be used as well, e.g., the 4G LTE technology specified by 3GPP or a future 6G (6thGeneration) technology. In the following detailed description, the communication network is often assumed to be based on the NFV (Network Functions Virtualization) architecture framework according to the ETSI ISG NFV specifications, Release 5 (see ETSI document “NFV Release 5 Description, v0.0.2 (2022-09). It is however noted that other virtualization architectures could be used alternatively or in addition, such as the O-RAN (Open Radio Area Network) architecture specified by the O-RAN Alliance.

[0048] In the illustrated concepts, a control node, e.g., an SDN (Software Define Network) controller (SDNC), identifies one or more constraints applying to deployment of a network slice by cloud applications executed on one or more nodes of the communication network. The cloud applications may correspond to CNAs (Cloud Native Applications). Further, the control node collects capability information of the nodes, e.g., using an enhanced version of the BGP (Border Gateway Protocol). The capability information respectively indicates one or more cloud applications that are supported by the node. Based on the identified one or more constraints and the collected capability information, the control node computes configuration of the network slice. This computation may be based on an enhanced version of the PCEP (Path Computation Element Communication Protocol). Details of protocol enhancements which may be utilized in the context of the illustrated concepts are explained below.

[0049] Security is an important concern in cloud-based network deployments. The illustrated concepts may be utilized to ensure that a CNA involved in a network slice is secure, e.g., is without any known vulnerability and complies with relevant laws, regulations or local policies. For this purpose, at least some of the constraints may relate to security. The configuration of the network slice may then be computed to satisfy such security constraints.

[0050] As noted above, the illustrated concepts may be implemented starting from known routing and path computation protocols, in particular BGP and PCEP. Such protocols may be enhanced by features related to a concept denoted as “flying endpoint” or “virtual endpoint”: an endpoint that is not statically anchored to a static location. Corresponding enhancements of BGP and PCEP are further explained below.

[0051] It is also noted that also more evolved constraints could be considered within the illustrated concepts. Examples of such constraints include: constraints related to usage of FOSS (Free and Open Source Software), constraints related defined using an SBOM (Software Bill of Materials), constraints based on (known) vulnerabilities of VNFs, or constraints based on location.

[0052] Fig. 1 illustrates exemplary structures of a wireless communication network which may be considered in the illustrated concepts. In particular, Fig. 1 shows UEs (User Equipments) 10 which are served by access nodes 100 of the wireless communication network. Here, it is noted that the wireless communication network may actually include a plurality of access nodes 100 that may serve a number of cells within the coverage area of the wireless communication network.

[0053] The access nodes 100 may be regarded as being part of an RAN (Radio Access Network) of the wireless communication network. Further, Fig. 1 schematically illustrates a CN (Core Network) 110 of the wireless communication network. In Fig. 1 , the CN 110 is illustrated as including a GW (gateway) 120 and one or more control node(s) 140. The GW 120 may be responsible for handling user plane data traffic of the UEs 10, e.g., by forwarding user plane data traffic from a UE 10 to a network destination or by forwarding user plane data traffic from a network source to a UE 10. Here, the network destination may correspond to another UE 10, to an internal node of the wireless communication network, or to an external node which is connected to the wireless communication network. Similarly, the network source may correspond to another UE 10, to an internal node of the wireless communication network, or to an external node which is connected to the wireless communication network. The GW may for example correspond to a UPF (User Plane Function) of the 5G Core (EGC) or to an SGW (Serving Gateway) or PGW (Packet Data Gateway) of the 4G EPC (Evolved Packet Core). The control node(s) 140 may for example be used for controlling the user data traffic, e.g., by providing control data to the access node 100, the GW 120, and / or to the UE 10.

[0054] As illustrated by solid double-headed arrows, the access node 100 may send DL wireless transmissions to at least some of the UEs 10, and some of the UEs 10 may send UL wireless transmissions to the access node 100.

[0055] The DL transmissions and UL transmissions may be used to provide various kinds of services to the UEs 10, e.g., a voice service, a multimedia service, or some other data service. Such services may be hosted in the CN 110, e.g., by a corresponding network node. By way of example, Fig. 2 illustrates an application service platform 150 provided in the CN 110. Further, such services may be hosted externally, e.g., by an AF (application function) connected to the CN 110. By way of example, Fig. 1 illustrates one or more application servers 160 connected to the CN 110. The application server(s) 160 could for example connect through the Internet or some other wide area communication network to the CN 110. The application service platform 150 may be based on a server or a cloud computing system and be hosted by one or more host computers. Similarly, the application server(s) 160 may be based on a server or a cloud computing system and be hosted by one or more host computers. The application server(s) 160 may include or be associated with one or more AFs that enable interaction with the CN 110 to provide one or more services to the UEs 10, corresponding to one or more applications. These services or applications may generate the user data traffic conveyed by the DL transmissions and / or the UL transmissions between the access node 100 and the respective UE 10. Accordingly, the application server(s) 160 may include or correspond to the above-mentioned network destination and / or network source for the user data traffic. In the respective UE 10, such service may be based on an application (or shortly “app”) which is executed on the UE 10. Such application may be pre-installed or installed by the user. Such application may generate at least a part of the user plane data traffic between the UEs 10 and the access node 100.

[0056] In the illustrated concepts, nodes of the wireless communication network may be virtualized in a network slice. Such virtualized nodes could for example correspond to nodes of the RAN, such as the access nodes 100 and / or related transport infrastructure, or to nodes of the CN 110, such as any of the nodes 120, 150, 160.

[0057] In the illustrated concepts, the available resources, which may be physical nodes, physical sites, or clusters of physical node which implement one or mor virtualized resources, may be configured to the network slice using SDN concepts and routing / path computation protocols. The result is a configuration of the network slice which satisfies the constraints. In some cases, multiple configurations could be found which satisfy the constraints. In such cases, additional criteria may be applied when selecting among such multiple configurations.

[0058] Fig. 2A schematically illustrates an example of an architecture which may be used in the illustrated concepts. More specifically, Fig. 2A shows a network 210 with nodes 220. Exemplary nodes are denoted as “Node 1”, “Node 2”, “Node 3”, and “Node 4”. Further, the architecture of Fig. 2 includes an SDN controller 250, which is an example of the control node of the illustrated concepts. , and an In the example of Fig. 2A, the architecture involves a an SDN controller 250.

[0059] As illustrated by broken arrows, the SDN controller 250 may collect information on the network status from the nodes 220. This information may specifically indicate CNAs supported by the nodes 220. The CNAs in turn have the purpose of implementing VNFs within the given NFV. More specifically, each of such CNAs may be related to a certain type of NFV, a certain type of VNF, and / or a certain version of a given type of VNF. In Fig. 2A, tables shown next to the nodes 220 indicate the CNAs supported by the respective node 220. As illustrated, Node 1 is assumed to support versioned CNAs denoted as “CNA1v1” (CNA #1 version 1), “CNA4v2” (CNA #4 version 2), “CNA5v1” (CAN #5 version 1), and “CNA8v5” (CNA #8 version 5). Node 2 is assumed to support versioned CNAs denoted as “CNA1v2” (CNA #1 version 2), “CNA5v3” (CNA #5 version 3), “CNA6v2” (CNA #6 version 2), and “CNA8v4” (CNA #8 version 4). Node 3 is assumed to support versioned CNAs denoted as “CNA5v2” (CNA #5 version 2), “CNA6v1” (CNA #6 version 1), “CNA7v6” (CNA #7 version 6), and “CNA8v5” (CNA #8 version 5). Node 4 is assumed to support versioned CNAs denoted as “CNA1v1” (CNA #1 version 1), “CNA2v2” (CNA #2 version 2), “CNA3v1” (CAN #3 version 1), and “CNA4v1” (CNA #4 version 1). Here, for example CNA1v1 (as for example supported by Node 1 and Node 4) and CNA1v2 (as for example supported by Node 2, correspond to the same type of CNA (namely CAN #1), but to different versions thereof (version 1 and version 2). The SDN controller 250 may collect the information during operation of the network, e.g., using BGP. Alternatively or in addition, some other control plane protocol or administrative protocol could be used for collecting the information. The control node stores the collected information in a dynamic constraints database 260. Further, the SDN controller 250 is provided with a set constraints database 270.

[0060] The set constraints database includes constraints that are statically set, e.g., by an administrator of the communication network. As mentioned above, these set constraints may for example relate to security, e.g., by specifying a required level of security. Fig. 2B shows the content of the dynamic constraints database 260 in the considered example, and Fig. 2C illustrates, by way of example, possible content of the set constraints database 270. As illustrated, the set constraints may specify a security level for per CNA. Alternatively or in addition, the set constraints may specify a security level for per node. In the illustrated example, the security levels are classified as “Low”, “Medium”, and “High”. It is however noted that this is merely and example and that other ways of distinguishing security levels could be used as well, e.g., a numeric metric. The security level can consider different factors like know vulnerabilities, the reliability of the vendors and others. In the case of the nodes, the security level could also be specified in terms of a maximum supported security level. The maximum supported security level supported by a node can consider for instance the country where the node is located, the security patches applied on the nodes or similar criteria. If now a new network slice needs to be deployed, a corresponding request (NW slice request of Fig. 2A) is addressed to the SDN controller 250. Based on the content of the dynamic constraints database 260 and the set constraints database 270, a path computation entity 280 of the SDN controller 250 performs a bundle of path computations. These path computations, may specify as ingress and egress endpoints only CNAs (optionally versioned) and the dynamic and set constraints. Upon successful path computation, the configuration of the network slice with the selected nodes and paths, e.g., in terms of LSPs (Label Switched Paths) is obtained. The set constraints may be defined in a comprehensive manner to allow consideration of various use cases. In Fig. 2C, such comprehensive definition is indicated by the field “Other”. One example would be to use this field to indicate FOSS to include or to exclude in the ONA to deploy.

[0061] In conventional path computation requests using PCEP, ingress and egress nodes (or ingress and egress node interfaces) are specified as addresses, e.g., IPv4 (Internet Protocol version 4) addresses or IPv6 (Internet Protocol version 6) addresses or “Unnumbered” addresses. These addresses specifying label limitations with the requested path attributes. When assuming that a network slice connecting 3 services Y-X-Z with latency constraints in the area 10.0.0.0 needs to be created, the nodes may be identified according to the availability of the requested services X, Y, Z that shall not use FOSS A (for example, the nodes 10.0.0.1, 10.0.0.2 and 10.0.0.3) and then the path computation shall be issued, for examples with two independent path computation requests: Request #1 : {Compute, from 10.0.0.1, to 10.0.0.2, delay 5} Request #2: {Compute, from 10.0.0.1, to 10.0.0.3, delay 15} or with a bundled request:

[0062] Request #1: [

[0063] {Compute, from 10.0.0.1, to 10.0.0.2, delay 5},

[0064] {Compute, from 10.0.0.1, to 10.0.0.3, delay 15},

[0065] ]

[0066] In the illustrated concepts, the ingress (“from”) and egress (“to”) addresses may be substituted by virtual endpoints (i.e., flying endpoints), e.g., in the form of software identifiers of the applications implementing the services. Such virtual endpoint can be associated with constraints to be used for selection of a node for implementing the endpoint. With such virtual endpoints, the above bundled request could have the following form:

[0067] [

[0068] {Compute, from: CNA-X {include [area: 10.0.0.0] ...}, to: CNA-Y {include [area: 10.0.0.0], exclude [FOSS-A], ...}, delay 5} {Compute, from: CNA-X {include [area: 1O.O.O.O] ...}, to: CNA-Z {include [area: 1O.O.O.O], exclude [FOSS-A], ...}, delay 15}

[0069] ]

[0070] The output of the request corresponds to the configuration of the network slice and the physical sites where CNA-X, CNA-Y, and CNA-Z shall be deployed according to the constraints.

[0071] Fig. 3 illustrates an example of processes which are based on the illustrated concepts. The processes of Fig.3 involve the SDN controller, which is provided with a BGP entity and an PCEP entity, and an exemplary node. It is however noted that corresponding interactions are typically performed with all nodes relevant for the deployment of the network slice. Each node is assumed to already have onboard a set of versioned CNAs (e.g., like in the example of Fig. 2A). Such versioned CNA may be an implementation of a NFV as a specific VNF, in a specific version of this VNF.

[0072] As illustrated by constraint configuration command 301, a user may first configure the set constraints. These constraints may include: security level supported by the nodes or security level required by the versioned CNA to run on a specific node. The SDN controller may then store the constraints in its constraints database, such as in the set constraints database 270.

[0073] In some scenarios, the processes may also involve deployment of one or more versioned CNAs on the node(s), as illustrated by CAN deployment command(s) 302.

[0074] The SDN controller then collects the capability information from the node(s), using the enhanced BGP, as illustrated by message 303. In particular, message 303 could be a message of the BGP-LS (BGP Link State) protocol, which is enhanced by further including a specific TLV (Type Length Value) associated to the node and containing the list of versioned CNAs deployed on the node and ready to be started. Further details concerning the corresponding enhancement of BGP are explained below. The SDN controller stores the collected capability information in its constraints database, such as in the dynamic constraints database 260, as indicated by message 304.

[0075] Subsequently the user may issue a request for a new network slice, like network slice instantiate request 311. This request may be issued using an enhanced version of PCEP, which also supports the concept of the virtual endpoints. As already indicated above, a flying endpoint may be regarded as an endpoint that is not yet anchored to a specific network node, it rather refers to the type of CNA that should be deployed, started and used. The path requested via PCEP is thus between two CNAs (ingress CNA and egress CNA) instead of between two nodes. The ingress endpoint of the path could be one of the nodes on which the required ingress CNA is present and the egress endpoint of the path could be one of the nodes on which the egress CNA is present.

[0076] A PCE (Path Computation Element) of the SDN controller computes the potential path(s) and deployment solution based on the request 311, as indicated by block 313. For this purpose, the PCE obtains the constraint information, including the set constraints and the collected dynamic constraints, from the constraints database, as indicated by message 312. For the path computation, the SDN controller may apply various kinds of routing-related procedures. Examples of such procedures are further explained below, in the context of specific examples.

[0077] Having successfully computed the path(s), the PCE may instantiate the path(s), by sending a path instantiate message 314 to the node(s). Further, the PCE may return the computed configuration of the network slice to the user, as indicated by message 315.

[0078] In the architecture of the illustrated concepts, the possibility to consider flying endpoints in the path computation implemented in the following manner:

[0079] Step 1 : The constraints specified for each CNA of the slice is resolved in a set of nodes of the network that satisfy the constraints. Such set of nodes is herein also referred to as “deployment options” of the CNA.

[0080] Step 2: A connectivity matrix of the network slice is used to represent connections between CNAs. In such connectivity matrix, each row can be substituted with the combinations of the of the deployment options of the two considered CNAs. At this stage a full mesh connectivity can be considered between nodes, assuming that any connectivity is feasible. Otherwise the full mesh can be reduced by removing unfeasible or unavailable connectivity.

[0081] Step 3: For each node which is eligible to be a deployment option, a spanning tree topology is considered where the node is the root and all other eligible nodes are the leaves: Such spanning tree representation has a single level of depth.

[0082] Step 4: The connectivity matrix of the network slice is applied to the spanning tree representation of the given eligible node. Only the matrix rows that connect the root to the leaves are considered. The matrix rows representing the connections between leaves are then discarded. In this way, connectivity loops can be avoided. Step 5: The remaining rows in each connectivity matrix of the spanning tree representations (corresponding to the different eligible nodes) can then be used to check whether a deployment option is possible.

[0083] The above procedure takes advantage of how L2 (Layer 2) networks of bridges operate using routing algorithms like Spanning Tree, Multiple Spanning Tree, Generic Attribute Registration Protocol (GARP) and multihoming. Spanning Tree algorithms may cut loops in the network blocking by ports. Multiple Spanning Tree algorithms allow usage of more than one tree at a time. GARP allows to identify the connectivity between two edge ports of a Spanning Tree topology. Multihoming allows a client to be connected to more edge ports of the bridged network, with only one of them will be open at a time.

[0084] In Step 1 , the constraints provided for each endpoint of the network slice can be used to filter and to identify a set of nodes matching the constraints, which then corresponds to the deployment options.

[0085] In Step 2, the eligible nodes may correspond to bridges of the network. Each CNA can be considered as a client of the bridged network attached to one edge port of each eligible node: When there is more than one eligible node, the CNA can be viewed as a client in a multihoming scenario. The actual connectivity of the network allows considering the bridged network as a full mesh.

[0086] In Step 3, the full mesh bridged network can be represented as a polygon, which is convex and regular, where the vertices of the polygon correspond to the eligible nodes and the edges together with the diagonals correspond to the links. Based on this representation of the bridged network, a Multiple Spanning Tree topology may be defined, with one Spanning Tree topology corresponding to each eligible node which acts the root node, with all the other nodes being directly connected to the root node and corresponding to the leaves of the Spanning Tree topology. Accordingly, each Spanning Tree topology has as active links only the two edges and the diagonals of the polygon, starting from the vertex corresponding to the root node.

[0087] In step 4, each node may “announce” the CNAs that it is connected to on the network slice, similar as in traditional bridged networks an edge port would announce the configured VLAN (Virtual Local Area Network) via GVRP (GARP for VLAN). In an actual bridged network, the GARP message used for the announcement is multicast and it is forwarded over root and designated ports. When a port of the tree is crossed in both direction by announcements for the same configuration, the port is opened for the connectivity. In the considered network slice deployment scenario, such behavior may be mimicked. Here, it may however further be considered that the network traffic is typically conveyed using tunnels, and that the traffic cannot be forwarded from one tunnel to another tunnel. Accordingly, the announcement of the CNAs would not happen for edge-edge communication (i.e. , communication between leaf nodes).

[0088] In Step 5, the connections identified by the Multiple Spanning Tree topology may be considered in view of only one access point to the network slice being required at a time, similar to a multihoming scenario.

[0089] In the following, the above procedures will be further explained in the context of specific examples.

[0090] As a first example, a case is considered where a network slice as represented in Fig. 4A is to be deployed in network infrastructure as illustrated in Fig. 4B. In Fig. 4A, the services to be provided in the network slice are denoted as “s1”, “s2”, “s3”, “s4”, and “s5”, and the required connectivity is illustrated by connections between the services, specifically, connectivity “s1- s2” between service s1 and service s2, connectivity “s1-s3” between service s1 and service s3, connectivity “s2-s3” between service s2 and service s3, connectivity “s3-s4” between service s3 and service s4, and connectivity “s4-s5” between service s4 and service s5. Each service may be implemented by a corresponding type of CNA. At least some of such CNAs may exist in different versions.

[0091] In Fig. 4B, nodes of the network are represented by circles, designated by numbers “1”, “, “2”, “3”, “4”, “5”, “6”, “7”, “8”, and “9”. Nodes that support deployment of CNAs, such as datacenters (herein also denoted with “de”), are illustrated with solid lines. In the illustrated example, these nodes correspond to the nodes “7”, “8”, “9”, and “10”. The other nodes may provide connectivity between the nodes and may correspond to routers (herein also denoted with “r”). Fig. 4C illustrates the assumed resource distribution in the considered example, as well as deployment constraints set for the network slice. These constraints, to be considered in step 1 , are as follows:

[0092] The CNA for s1 is allowed only on node “7” or “8” (corresponding to data centers dc7 and dc8.

[0093] The CNA for s3 is allowed only on node 10 (corresponding to data center dc10).

[0094] The CAN for s5 is allowed only on node 9 (corresponding to data center dc9).

[0095] The CNAs for s2 and s4 have no constraints. Figs. 5A, 5B, and 5C illustrate representations of a connectivity matrix of the network slice of this example. The matrix of Fig. 5A represents the connectivity between services as explained in connection with Fig. 5A. The matrix of Fig. 5B is an alternative representation indicating the connectivity options per service. Fig. 5C further includes the deployment constraints, also including the constraints due to the connectivity in the network as shown in Fig. 4B.

[0096] Based on the above, Fig. 6 shows a representation of the network slice on the given network infrastructure.

[0097] Starting from the full-mesh representation of Fig. 6, step 2 now considers the connectivity of the network slice in terms of the connectivity between the datacenters. Fig. 7 shows the corresponding connectivity matrix.

[0098] Based on this, the representation of the network slice can be further simplified by ignoring the complexity of the network and including only the eligible nodes, related connectivity, and the services of the slice with their respective access points as illustrated in Fig. 8A. In Fig. 8B, the representation of Fig. 8A is transformed to a polygonal representation, with the vertices of the polygon corresponding to the eligible nodes.

[0099] Figs. 9A, 9B, 9C, 9D, and 9E show representations of the network slice which are based on the representation of Fig. 8B and respectively focus on the individual links of the network slice. Specifically, the representation of Fig. 9A focusses on the link corresponding to the connectivity of service s1 and s2, the representation of Fig. 9B focusses on the link corresponding to the connectivity of service s2 and s3, the representation of Fig. 9C focusses on the link corresponding to the connectivity of service s1 and s3, the representation of Fig. 9D focusses on the link corresponding to the connectivity of service s3 and s4, and the representation of Fig. 9E focusses on the link corresponding to the connectivity of service s4 and s5.

[0100] In step 3, the eligible nodes are considered as root of a Spanning Tree topology. Fig. 10 shows a corresponding representation where node “7” is considered as the root node.

[0101] Then, in step 4 the connectivity matrices for the Spanning Tree topologies are obtained. Fig. 11 illustrates the result for the case where node “7” is considered as the root node. Then, in step 5 the connectivity information of the different Spanning Tree topologies is combined by comparing the Spanning Tree representations. Figs. 12A, 12B, 12C, 12D, and 12E show the resulting representations and related connectivity matrices for the case of considering node “7” as the root node.

[0102] The connectivity matrices are the combined as illustrated by Figs. 13A, 13B, 13C, and 13D. Here, common services (a column in both matrices with non-zero values) are considered by keeping only the common values. Other columns (with zero values in at least one of the two connectivity matrices) are ‘indifferent’. When starting from the connectivity matrices of Figs. 12A and 12B, i.e., the connectivity matrices for s1-s2 and s2-s3, it can be seen that the s2 column is the only with common values. The combination result is shown in Fig. 13A, where only the eligible nodes for s2 (dc7 and dc10) are kept. In a next iteration, the connectivity matrix of Fig. 13A is combined in a similar manner with the connectivity matrix of Fig. 12C, i.e., the connectivity matrix for s1-s3. It can be seen that dc8 as deployment option for s1 is not present in the connectivity matrix for s1-s3 and should therefore not be kept in the combination result, as shown in Fig. 13B. In a next iteration, the connectivity matrix of Fig. 13B is combined in a similar manner with the connectivity matrix of Fig. 12D, i.e., the connectivity matrix for s3-s4, the result being shown in Fig. 13C. In a still further iteration, the connectivity matrix of Fig. 13C is combined in a similar manner with the connectivity matrix of Fig. 12E, i.e., the connectivity matrix for s4-s5, the result being shown in Fig. 13D. Fig. 14 shows the final result with the eligible nodes for each service for the case of node “7” being considered as the root node. Figs. 15A and 15B illustrate corresponding deployment options of the network slice.

[0103] It is noted that while the above explanations focused on the case where node “7” is considered as the root node of the Spanning Tree topology, corresponding procedures are also performed for the cases where the other eligible nodes, i.e., node “8”, node “9”, and node “10” are considered as the root node. It may also occur that no solution is obtained for some of such different Spanning Tree topologies. If solutions are found for more than one Spanning Tree topologies, these solutions can be combined using a Multiple Spanning Tree algorithm.

[0104] Fig. 16 illustrates a further example of a network slice, with services denoted as “sA”, “sB”, and “sC”. As can be seen, in the example of Fig. 16 the services are connected in a ring topology (with service “sA” having connectivity to services “sB” and “sC”, service “sB” having connectivity to services “sA” and “sC”, and service “sC” having connectivity to services “sA” and “sB”. When further assuming strict deployment constraints, i.e., that service sA can deployed only on node “n1”, service “sB” can be deployed only on node “n2”, and service “sC” can be deployed only on node “n3”, the network slice can be mapped to the network infrastructure as illustrated in Fig. 17. In Fig. 17, a CNA for service sA is denoted by A1 , a CNA for service sB is denoted by B2, and a CNA for service sC is denoted by C3.

[0105] Figs. 18A, 18B, and 18C show representations for consideration of individual links of the network slice. Figs. 19A, 19B, and 19C illustrate representations of the network slice where node “n1” is considered as the root node of a Spanning Tree topology. Figs. 20A, 20B, and 20C illustrate representations of the network slice where node “n2” is considered as the root node of a Spanning Tree topology. Figs. 21 A, 21 B, and 21 C illustrate representations of the network slice where node “n3” is considered as the root node of a Spanning Tree topology.

[0106] As can be seen, the different individual Spanning Tree topologies do not result in a deployment solution for the network slice. When node “n1” is considered as the root node, connectivity for the services sB and sC is missing (as shown in Fig. 19B). When node “n2” is considered as the root node, connectivity for the services sC and sA is missing (as shown in Fig. 20C). When node “n3” is considered as the root node, connectivity for the services sA and sB is missing (as shown in Fig. 21A). However, by combining the individual Spanning Tree topologies using a Multiple Spanning Tree algorithm, a solution for deployment of the network slice can still be found (as corresponding to the representation shown in Fig. 17).

[0107] In cases where the above procedures produce multiple solutions for the deployment of the network slice, which all satisfy the set constraints, additional criteria may be applied to select among such solutions. For example, such additional criteria could be configured or indicated by the request for the network slice, e.g., in the request 311 of Fig. 3. For example, such criteria could be indicated by a PCEP Objective Function. If no PCEP Objective Function is specified in the request 311, a default mechanism could be applied to select one of the solutions. An example of such default mechanism would be to select the first solution provided as output of the path computation (and skipping computation of possible further solutions).

[0108] Th illustrated concepts may be applied on the basis of O-RAN transport infrastructure, as for example illustrated in Fig. 22. In the example of Fig. 22, an O-RAN Distributed Unit (O-DU) Node is connected through a transport network to an O-RAN Centralized Unit (O-CU) Node. The transport network may in turn include PE (provider edge) nodes connected through an IP network. The protocol stack of transport functions in the O-DU node and the O-CU node includes a physical (Phy) layer, an Ethernet layer, an IP (Internet Protocol) layer and an IPsec (IP secure) layer. Communication between the 0-Dll Node and the O-CU Node on the IPsec and IP layers is based on e2e (end-to-end) IP. Further of the utilized protocol(s) can be found in the 38.xxx series of the 3GPP specifications. The Ethernet layer may use protocols as defined in the IEEE 802.1 and IEEE 802.3 YANG specifications. The IP connectivity may generally be in accordance with the IETF (Internet Engineering Task Force) definitions.

[0109] As regards the IETF definitions, it may further be considered that the 3GPP virtualization technology is based on NFV according to the ETSI specifications. Among these specifications, I FA 032 specifies multi-site connectivity. As schematically illustrated in Fig. 23, a network service may in this case involve that a first VNF (VNF1) is connected through a virtual link to a second VNF (VNF2). These virtualized resources are implemented using NFVI (NFV infrastructure, specifically a first NFVI-PoP (Point-of-Presence) and a second NFVI-PoP, which are connected through a WAN (Wide Area Network). According to the ETS SOL 017 specification, the interface of a WIM (WAN Infrastructure Manager) to the ACTN (Abstraction and Control of TE Networks) architecture defined by IETF in RFC 8453, using PCEP and BGP-LS (BGP-Link State) as protocol, as stated in RFC 8637.

[0110] As explained above, implementations of the illustrated concepts may involve using PCEP to issue and handle instantiation and path computation for network slice deployment and BGB, specifically BGP-LS may be used to collect the capability information defining the dynamic constraints. In the following, examples are further explained, how PCEP and BGP could be enhanced in view of the illustrated concepts.

[0111] On exemplary protocol enhancement relates to the concept of the flying endpoint in path computation. For this purpose, the PCEP may be supplemented by a new Object Type, denoted as “Virtual-Endpoint”. The new object type may be introduced within “PCEP Object Class 4 - END-POINTS”. The present example assumes that the new Object Type is allocated Object-Type value 6, which is presently unassigned in the IANA (Internet Assigned Numbers Authority) PCEP Object definitions.

[0112] The existing Object Types of the END-POINTS class (Class 4) specify the requested endpoint with an address or a router-id with an interface-id, thereby identifying it univocally. Further, label restrictions may be associated with the endpoint. In the case of the new Virtual- Endpoint Object Type, also other TLVs may be inluced, such as an IRO (Include Route Object) for representing one or more of nodes that shall be considered as mandatory for the deployment, or an XRO (exclude Route Object) for representing the nodes that shall not be used. Further, an SRLG (Shared Risk Link Group) may be provided to include or exclude all nodes with links sharing a reported risk, and / or an LSPA (Label Switched Path Attribute) may be provided to include or exclude all nodes with links associated with certain administrative colors (or affinities). For the TLV(s) included in the Virtual-Endpoint Object, it may be up to the receiving PCE to fulfil them. For example, one or more TLVs could represent the required level of security of a node. The TLVs in the Virtual-Endpoint Object may follow a syntax as illustrated in Fig. 25A, where Fig. 25B illustrates the syntax of a definition of the Virtual- Endpoint Object.

[0113] Other definitions, like LSPA, I RO, XRO, metric-list, OF, IPV4-ADDRESS, and IPV6- ADDRESS are already available in IETF specifications.

[0114] The element denoted as “endpoint-choice” allows for coexistence with existing definitions. In this way, it is for example possible to request computation of a path where one endpoint is a flying endpoint correspond to the Virtual-Endpoint Object Type, specified in terms of a ONA, and the other endpoint is a conventional endpoint specified in terms of an address (IPv4 or IPv6) or a router-id with an interface-id.

[0115] Further, the PCEP may be supplemented by a new TLV as “VIRTUAL-ENDPOINT”. The VIRTUAL-ENDPOINT TLV. The present example assumes that the new TLV is allocated TLV-Type value 80, which is presently unassigned in the IANA PCEP definitions. Fig. 25 illustrates an exemplary format of the VIRTUAL-ENDPOINT TLV. As illustrated, the VIRTUAL-ENDPOINT TLV identifies a CNA. It is noted that the same CNA may run multiple in multiple instances in the same network slice, e.g., for georedundancy reasons. The CNA is identified by a UUID (in the illustrated example of 16 bytes). Further, an optional 32-bit number may be provided for identifying the CNA instance. Accordingly, the VIRTUAL- ENDPOINT TLV has a length of 16 bytes of for the CNA UUID, plus four optional bytes when also the instance of the CNA is identified.

[0116] The CNA UUID can be used to identify a specific CNA, the specific version of the CNA, or the type of the CNA. The CNA UUDI could also be used to identify or a part of the CNA software: For example, the CNA UUID may correspond to either a VNF, a version of the VNF, the NFV that the CNA implements, or a FOSS that the CNA uses. Various ways may be used to assign the UUID to the identified instance.

[0117] Further, the PCEP may be supplemented by a definition of a CNA subobject. The CNA subobject can be used in an XRO and / or in an I RO to include or to exclude a specific software. For example, if a certain FOSS shall not be used by the applications running on the network slice, the PCEP request addressed to the PCE can include an XRO with a CNA subobject identifying the software to be excluded. Further, if a certain FOSS shall be preferred to others, the PCEP request can include an I RO with a CNA subobject identifying the software to be included. Fig. 26A illustrates an exemplary format of the CNA subobject for I RO, and Fig. 26B illustrates an exemplary format of the CNA subobject for XRO. In the format of Fig. 26A, the definitions of L, Type, and Length may be in accordance with RFC 3209. In the format of Fig. 26B, the definitions of X and Length may be in accordance with RFC 5521. The present example assumes that the new IRO / XRO CNA subobjects are each allocated value 66, which are presently unassigned in the IANA PCEP definitions.

[0118] Typically, the network slice topology is composed of more than two nodes connected by only one link. As a result, computation of the configuration of the network slice may involve issuing multiple PCEP requests, each specifying the ASSOCIATION object indicating a Virtual Network Identifier corresponding to the network slice in the VIRTUAL-NETWORK-TLV. The PCEP request thereby allows concatenation of multiple requests for path computations that can be synchronized with SVEC (Synchronization VECtor) object whose “svec-list” may include the OF (Objective Function), e.g., as GOF (Global Objective Function). Fig. 27 shows a list of new OFs that can be introduced in the context of the illustrated concepts.

[0119] Further, an OF-List TLV can be introduced at Virtual-Endpoint level or at global level to specify a set of objective functions for choosing a solution among multiple feasible solutions. It is noted that the OFs listed in Fig. 27 are not exhaustive and that additional or alternative OFs may be introduced to address various use cases.

[0120] Further, the PCEP may be supplemented by a new Error Types of the PCEP-ERROR Object, to support reporting of CNA related errors. These Error Types are denoted as “CNA Error”. Fig. 28 shows a list of CNA Errors that can be introduced in the context of the illustrated concepts. The present example assumes that the new Error Type is allocated Error Type value 34, which is presently unassigned in the IANA PCEP definitions.

[0121] Further, the BGP-LS may be supplemented by an element BGP-LS, which is denoted as Cloud Native Application Registry NLRI (Network Layer Reachability Information). Using this element, nodes can advertise supported and available CNAs using BGP. The BGP already allows for reporting the link-state information stored in the topology database, either LSDB (Link State Database) or TED (Traffic Engineering Database) of the routers to a controller of the network, and such information may be used for feeding a PEC. For this purpose, the NLRI format was specified. Fig. 29A illustrates an exemplary format of the Cloud Native Application Registry NLRI.

[0122] If BGP uses local information, the Protocol-ID shall be ‘Static’ (protocol-id value 5, RFC 9552) as in already available in IETF definitions. The Identifier is the BGP-LS Instance Identifier (Instance-ID). For the local node descriptor (in accordance with RFC 9552), a new sub-TLV code point may be introduced, e.g., as illustrated in Fig. 29B. The CNA Descriptor TLV may have a format as illustrated in Fig. 29C. In the format of Fig. 29C, the CNA UIIID may represent a specific CNA, a version of a CNA, or a type of CNA. A CNA type (like an NFV) may have more than one implementation in the network, and each implementation may exist in multiple versions. A parent-child relationship may be utilized for addressing such dependencies, and the CNA Descriptor TLV may indicate dependent instances (childs). If there are no dependent CNA instances, e.g., no further versions of a CNA type, the child list is left empty.

[0123] Fig. 30 shows a flowchart for illustrating a method, which may be utilized for implementing the illustrated concepts. More specifically, the method may be used to implement the above- mentioned functionalities of controlling deployment of a network slice in a control node of a communication network, such as the above-mentioned SDN controller 250. In some cases, the control node could correspond to a virtual node implemented by a cloud application executed on multiple physical nodes. The communication network may be based on an NFV architecture, e.g., as specified by 3GPP.

[0124] If a processor-based implementation of the control node is used, at least some of the steps of the method of Fig. 30 may be performed and / or controlled by one or more processors of the control node. Such node may also include a memory storing program code for implementing at least some of the below described functionalities or steps of the method of Fig. 30.

[0125] At step 3010, the control node may receive a request. The Network Slice Instantiate Request 311 of Fig. 3 is an example of such request. The request may indicate a network slice to be deployed by cloud applications executed on one or more nodes of the communication network. In some scenarios, the request can be based on the PCEP or an enhanced version of the PCEP.

[0126] At step 3020, the control node identifies one or more constraints applying to the deployment of the network slice by cloud applications executed on one or more nodes of the communication network. The constraints may be set by an administrator of the communication network. The cloud applications may include or correspond to one or more VNFs. The above-mentioned CNAs are examples of such cloud applications. The nodes may include physical nodes of the communication network. For example, each node could correspond to a physical node. Alternatively or in addition, the nodes may include virtualized resources of the communication network. For example, each node could correspond to a cluster of physical nodes which implements a virtualized resource, such as a virtual node or a virtual link.

[0127] The one or more constraints may include at least one constraint relating to security level of the cloud application(s) executed by the node. Further, the one or more constraints may include an indication of geographical location not allowed for a node of the network slice. Further, the one or more constraints may include an indication of software not allowed on a node of the network slice, e.g., an indication of FOSS not allowed on a node of the network slice. In some scenarios, such indication of software not allowed on a node of the network slice may include or be based on at least one SBOM.

[0128] At step 3030, the control node collects capability information of the nodes. The capability information respectively indicates one or more cloud applications that are supported by the node.. The cloud applications may already be instantiated on the node. Alternatively, such supported cloud application could also be instantiated at a later stage, e.g., immediately before the network slice is deployed.

[0129] The control node may collect the capability information from the nodes. This may be accomplished during operation of the communication network. For this purpose, an enhanced version of the BGP or some other administrative protocol or control protocol may be utilized. The control node may store the collected information in a database, such as the dynamic constraints database 260 of Fig. 2.

[0130] At step 3040, the control node computes configuration of the network slice. This is accomplished based on the one or more constraints identified at step 3020 and the capability information collected at step 3030, the control node computing configuration of the network slice. The control node may then indicate the computed configuration of the network slice, e.g., in a response to the request of step 3010.

[0131] The computation of the configuration of the network slice may include selection of a subset of the nodes, e.g., by selecting nodes which satisfy the constraints identified at step 3020. The computation of the configuration of the network slice may be based on computation of at least one path connecting two of the nodes of the subset. The computation of such paths may be based on a path computation protocol, such as the PCEP. In some cases, the request of step 3010 may include a bundle of multiple path computation requests.

[0132] Further, the computation of the configuration may involve selection of at least one node for implementing an endpoint of the path, e.g., selection of a node for implementing an ingress endpoint of the path and / or selection of a node for implementing an egress endpoint of the path. The selection of the at least one node for implementing the endpoint may be based on definition of at least one virtual endpoint which is independent of the nodes. The above- mentioned flying endpoints are examples of such virtual endpoint. The at least one virtual endpoint may be defined in terms of the cloud application required in the node for implementing the endpoint of the network slice. Further, the at least one virtual endpoint may be defined in terms of one or more endpoint constraints for the selection of the node for implementing the endpoint of the network slice. The one or more endpoint constraints may include an indication of software not allowed in the node implementing the endpoint and / or an indication of software required in the node implementing the endpoint. The configuration of the network slice may be computed in response to a request which indicates the at least one virtual endpoint, such as the request of step 3010. It is noted that a computation applied to a network slice may potentially include computation of one or more paths, as different paths may be selected according to the required constraints. Accordingly, a virtual or physical endpoint may correspond to an an endpoint of a standalone path or an endpoint of a network slice.

[0133] At step 3050, the control node may deploy the network slice, e.g., by sending path instantiate commands to the nodes, as for example illustrated by message 314 of Fig. 3. Such path instantiate commands may be based on PCEP messages.

[0134] Fig. 31 illustrates a processor-based implementation of a physical node 3100 for a communication network, which may be used for implementing the above-described concepts. More specifically, the structures of the physical node 3100 may be used to implement the above-mentioned functionalities of the control node, such as the SDN controller 250. Further, the structures of the physical node 3100 may be used to implement cloud infrastructure for any of the above-mentioned nodes used for deployment of the network slice. For example, such node could be a virtual node based on a cluster of physical nodes having structures as illustrated in Fig. 31. As illustrated, the physical node 3100 may include one or more interfaces 3110. The interface(s) 3110 may for example be used for communicating with other nodes of the communication network.

[0135] Further, the physical node 3100 may include one or more processors 3150 coupled to the interface(s) 3110 and a memory 3160 coupled to the processor(s) 3150. By way of example, the interface(s) 3110, the processor(s) 3150, and the memory 3160 could be coupled by one or more internal bus systems of the physical node 3100. The memory 3160 may include a read-only memory (ROM), e.g., a flash ROM, a random-access memory (RAM), e.g., a dynamic RAM (DRAM) or static RAM (SRAM), a mass storage, e.g., a hard disk or solid state disk, or the like. As illustrated, the memory 3160 may include software 3170 and / or firmware 3180. The memory 3160 may include suitably configured program code to be executed by the processor(s) 3150 so as to implement or configure the above-described functionalities for controlling deployment of a network slice, such as explained in connection with Fig. 30.

[0136] It is to be understood that the structures as illustrated in Fig. 31 are merely schematic and that the node 3100 may actually include further components which, for the sake of clarity, have not been illustrated, e.g., further interfaces or further processors. Also, it is to be understood that the memory 3160 may include further program code for implementing known functionalities of RAN nodes, CN nodes, or other nodes of a communication network. According to some embodiments, also a computer program may be provided for implementing functionalities of the physical node 3100, e.g., in the form of a physical medium storing the program code and / or other data to be stored in the memory 3160 or by making the program code available for download or by streaming. Further, it is noted that in some scenarios multiple physical nodes 3100 with structures as illustrated in Fig. 31 could be used in combination, e.g., as a cloud system or cluster.

[0137] As can be seen, the concepts as described above may be used for efficient deployment of a network slice in a dynamic environment. Specially, offline planning may be reduced so that the network slice can be quickly deployed in an at least partly automated manner. Existing cloud technology, such as the NFV framework can be enhanced so that VNFs can be deployed and run more quickly. The utilized cloud infrastructure can be private cloud infrastructure or a public cloud infrastructure. Services providers may be allowed to manage a flexible and dynamic network and automate the deployment of their network service. Further, the illustrated concepts may enable more efficient usage of available resources, e.g., by enabling usage of more elaborated constraints. It is to be understood that the examples and embodiments as explained above are merely illustrative and susceptible to various modifications. For example, the illustrated concepts may be applied in connection with various kinds of communication technologies, not necessarily limited to wireless communication. Moreover, it is to be understood that the above concepts may be implemented by using correspondingly designed software to be executed by one or more processors of an existing device or apparatus, or by using dedicated device hardware. Further, it should be noted that the illustrated apparatuses or devices may each be implemented as a single device or as a system of multiple interacting devices or modules.

Claims

1. - 26 -Claims1. A method of controlling operation of a communication network, the method comprising: a control node (250; 3100) identifying one or more constraints applying to deployment of a network slice by cloud applications executed on one or more nodes (220; 3100) of the communication network; the control node (250; 3100) collecting capability information of the nodes (220; 3100), the capability information respectively indicating one or more cloud applications that are supported by the node (220; 3100); and based on the identified one or more constraints and the collected capability information, the control node (250; 3100) computing configuration of the network slice.

2. The method according to claim 1 , wherein the one or more constraints comprise at least one constraint relating to security level of the cloud application executed by the node (220; 3100).

3. The method according to claim 1 or 2, wherein the one or more constraints comprise an indication of geographical location not allowed for a node (220; 3100) of the network slice.

4. The method according to any of the preceding claims, wherein the one or more constraints comprise an indication of software not allowed on a node (220; 3100) of the network slice.

5. The method according to claim 4, wherein the one or more constraints comprise an indication of free and open-source software not allowed on a node (220; 3100) of the network slice.

6. The method according to claim 4 or 5, wherein the indication of software not allowed on a node of the network slice comprises at least one Software Bill of Materials, SBOM.

7. The method according to any of the preceding claims, wherein the cloud applications comprise one or more Virtualized Network Functions, VNFs.

8. The method according to any of the preceding claims, wherein the computation of the configuration comprises selection of a subset of the nodes.

9. The method according to any of the preceding claims, wherein the computation of the configuration comprises computation of at least one path connecting two of the nodes (220; 3100) of the subset.

10. The method according to claim 9, wherein the computation of the configuration comprises selection of at least one node (220; 3100) for implementing an endpoint of the path.

11. The method according to claim 10, wherein the selection of the at least one node for implementing the endpoint is based on definition of at least one virtual endpoint which is independent of the nodes (220; 3100).

12. The method according to claim 11 , wherein the at least one virtual endpoint is defined in terms of the cloud application required in the node (220; 3100) for implementing the endpoint of the path.

13. The method according to claims 11 or 12, wherein the at least one virtual endpoint is defined in terms of one or more endpoint constraints for the selection of the node (220; 3100) for implementing the endpoint of the path.

14. The method according to claim 13, wherein the one or more endpoint constraints comprise an indication of software not allowed in the node (220; 3100) implementing the endpoint.

15. The method according to claim 13 or 14, wherein the one or more endpoint constraints comprise an indication of software required in the node (220; 3100) implementing the endpoint.

16. The method according to any of claims 11 to 15, wherein the configuration of the network slice is computed in response to a request which indicates the at least one virtual endpoint.

17. The method according to any of the preceding claims, wherein the control node (250; 3100) collects the capability information from the nodes (220; 3100).

18. The method according to any of the preceding claims, wherein the control node (250; 3100) collects at least part of the capability information during operation of the communication network.

19. The method according to any of the preceding claims, wherein the constraints are set by an administrator of the communication network.

20. The method according to any of the preceding claims, wherein the communication network is based on a Network Functions Virtualization, NFV, architecture.

21. The method according to any of the preceding claims, wherein the nodes (220; 3100) comprise physical nodes of the communication network.

22. The method according to any of the preceding claims, wherein the nodes (220; 3100) comprise virtualized resources of the communication network.

23. A control node (250; 3100) for a communication network, the control node (250; 3100) being configured to: identify one or more constraints applying to deployment of a network slice by cloud applications executed on one or more nodes (220; 3100) of the communication network; collect capability information of the nodes (220; 3100) of the communication network, the capability information respectively indicating one or more cloud applications that are supported by the node (220; 3100); and based on the identified one or more constraints and the collected capability information, compute configuration of the network slice.

24. The control node (250; 3100) according to claim 23, wherein the control node (250; 3100) is configured to perform a method according to any one of claims 2 to 20.

25. The control node (250; 3100) according to claim 23 or 24, comprising: at least one processor (3150), and a memory (3160) containing program code executable by the at least one processor (3150), whereby execution of the program code by the at least one processor (3150) causes the control node (220; 3100) to perform a method according to any one of claims 1 to 22.- 29 -26. A computer program or computer program product comprising program code to be executed by at least one processor of a control node (250; 3100) of a communication network, whereby execution of the program code causes the control node (250; 3100) to perform a method according to any one of claims 1 to 22.

Images