COMMUNICATION SYSTEM AND METHOD FOR PROVIDING VIRTUAL NETWORK FUNCTIONS - Patent application

Abstract

According to one embodiment, a communications system is described that includes a network function virtualization orchestration system configured to provide a virtual network function for an application of a communications network, and a virtual network function sharing management component configured to establish a sharing profile of the virtual network function, the sharing profile specifying whether the virtual network function may be shared with another communications network. The network function virtualization orchestration system is configured to satisfy the request from the other communications network for provision of the virtual network function by sharing the provided virtual network function with the other communications network if the sharing profile specifies that the virtual network function may be shared with the other communications network.

Description

[Technical field]

[0001] The present disclosure relates to a communication system and method for providing virtual network functionality. [Background technology]

[0002] Network functions of the 5G Core Network and 5G RAN, as well as other network functions such as firewalls, may be implemented as virtual network functions, i.e., in virtual machines and / or containers running on commodity servers, rather than on dedicated telecommunication hardware. This increases the flexibility regarding the resource provisioning used by the network functions and the ability to perform resource allocation to deal with dynamic load increases. Nevertheless, approaches that allow efficient use of available computational resources are desirable, especially in the case of complex network architectures that include multiple interconnected communication networks and / or communication networks divided into multiple network slices. Summary of the Invention

[0003] According to one embodiment, a communications system is provided that includes a network function virtualization orchestration system configured to provide a virtual network function for a communications network, and a virtual network function sharing management component configured to establish a sharing profile for the virtual network function, the sharing profile specifying whether the virtual network function may be shared with another communications network.

[0004] The network function virtualization orchestration system is configured to satisfy a request from another communication network by sharing the provided virtual network function with the other communication network in response to a request from the other communication network for the provision of a virtual network function if a sharing profile specifies that the virtual network function may be shared with the other communication network.

[0005] The drawings are not necessarily to scale, emphasis instead generally being placed upon illustrating the principles of the invention.

[0006] In the following description, various aspects are described with reference to the following drawings. [Brief description of the drawings]

[0007] [Figure 1] 1 illustrates a mobile wireless communication system. [Diagram 2] This shows an architecture including the Network Functions Virtualisation Management and Orchestration (NFV-MANO) architecture framework. [Diagram 3] We present a VNF sharing scenario in which a network service (NS) is shared between two different tenants. [Figure 4] A sharing scenario is shown in which two network services are shared between two network slice subnets. [Diagram 5] 1 illustrates network slicing in 3GPP from a management perspective. [Figure 6] 1 illustrates slice management from a 3GPP perspective. [Figure 7] 1 illustrates the addition of a VNF sharing manager to a VNF generic Operation, Administration and Maintenance (OAM) function, according to one embodiment. [Figure 8] 1 shows a flow diagram illustrating conversion of a (non-shared) VNF to a shared VNF by a VNF Sharing Manager. [Figure 9] Indicates the state of the VNFs controlled by the VNF Sharing Manager. [Figure 10] Illustrates the use of virtual network slices. [Figure 11]1 shows a flow diagram for configuration of a shared VNF. [Figure 12] A flow diagram illustrating the workflow of a Network Slice Subnet Management Function (NSSMF) requesting a shareable VNF is shown. [Figure 13] 1 illustrates a communication system according to one embodiment. [Figure 14] 1 shows a flow diagram illustrating a method for providing network functionality. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0008] The following detailed description refers to the accompanying drawings, which show by way of example specific details and aspects of the present disclosure in which the present invention may be practiced. Other aspects may be utilized, and structural, logical, and electrical changes may be made, without departing from the scope of the present invention. Various aspects of the present disclosure are not necessarily mutually exclusive, since some aspects of the present disclosure may be combined with one or more other aspects of the present disclosure to form new aspects.

[0009] Various examples corresponding to aspects of the present disclosure are described below.

[0010] Example 1 is a communications system including a network function virtualization orchestration system configured to provide a virtual network function for an application of a communications network; and a virtual network function sharing management component configured to establish a sharing profile for the virtual network function, the sharing profile specifying whether the virtual network function may be shared with another communications network, and the network function virtualization orchestration system is configured, in response to a request from another communications network for provision of a virtual network function, if the sharing profile specifies that the virtual network function may be shared with the other communications network, to satisfy the request by sharing the provided virtual network function with the other communications network.

[0011] Example 2 is the communications system of example 1, wherein the network function virtualization orchestration system is configured to receive a request from another communications network and, in response to receiving the request, configured to request the virtual network function sharing management component to check whether a sharing profile specifies that the virtual network function may be shared with the other communications network.

[0012] Example 3 is the communications system of examples 1 or 2, wherein the communications system includes a plurality of network slices, and the virtual network function sharing management component is configured to share virtual network functions between the communications network and the other communications network by treating the other communications network as a virtual network slice and sharing virtual network functions between the virtual network slice and one or more of the plurality of network slices.

[0013] Example 4 is the communication system of example 3, wherein the virtual network function sharing management component is configured to maintain an abstract representation of the virtual network function for each network slice and virtual network slice in which the virtual network function is shared.

[0014] Example 5 is the communications system of any one of Examples 1-4, wherein the network function virtualization orchestration system is configured to delegate lifecycle management and / or configuration management of the virtual network function to the virtual network function sharing management component if the sharing profile specifies that the virtual network function may be shared with another communications network.

[0015] Example 6 is the communication system of any one of Examples 1-5, wherein the virtual network function sharing management component is configured to configure the virtual network function according to requirements for use of the virtual network function received from the communication network and the other communication network if the sharing profile specifies that the virtual network function may be shared with another communication network.

[0016] Example 7 is the communications system of any one of Examples 1-6, wherein the network function virtualization orchestration system is configured to create the virtual network function in response to a request from the communications network for provision of the virtual network function.

[0017] Example 8 is the communication system of any one of Examples 1-7, wherein the sharing profile specifies whether the virtual network function may be shared with any other communication network.

[0018] Example 9 is the communication system of any one of Examples 1 to 8, in which the request from another communication network for provision of a virtual network function is for the same application as the communication network.

[0019] Example 10 is the communication system of any one of Examples 1 to 9, wherein the application is a network function of a core network of the mobile communication network.

[0020] Example 11 is the communication system of any one of Examples 1-10, wherein the virtual network function sharing management component is configured to manage a sharing status of the virtual network functions via a state machine.

[0021] Example 12 is the communication system of any one of Examples 1 to 11, wherein the virtual network function sharing management component is configured to transition between a virtual network function that is shareable with another communication network and a virtual network function that is not shareable with another communication network during operation of the virtual network function.

[0022] Example 13 is a method for providing a virtual network function, the method including providing a virtual network function for an application of a communications network; establishing a sharing profile for the virtual network function, the sharing profile specifying whether the virtual network function may be shared with another communications network; and, in response to a request from another communications network for the provision of the virtual network function, if the sharing profile specifies that the virtual network function may be shared with another communications network, satisfying the request from the other communications network by sharing the provided virtual network function with the other communications network.

[0023] It should be noted that one or more features of any of the above examples may be combined with any one of the other examples. In particular, examples described in the context of a device are equally valid for a method.

[0024] According to further embodiments, there is provided a computer program and computer readable medium comprising instructions which, when executed by a computer, cause the computer to perform the method of any one of the above examples.

[0025] Various examples are described in more detail below.

[0026] FIG. 1 illustrates, in simplified form, a mobile wireless communications system 100 configured in accordance with Fifth Generation (5G) standards, for example, as specified by the Third Generation Partnership Project (3GPP).

[0027] The mobile radio communication system 100 comprises a mobile radio terminal device 102, such as User Equipment (UE), etc. The mobile radio terminal device 102, also called subscriber terminal, forms the terminal side, while the other components of the mobile radio communication system 100 described below are part of the mobile communication network side, i.e. part of a mobile communication network (e.g. public land mobile network PLMN).

[0028] Furthermore, the mobile wireless communication system 100 includes a Radio Access Network (RAN) 103, which may include multiple radio access network nodes, i.e., base stations configured to provide radio access according to a Fifth Generation (5G) radio access technology (5G New Radio). It should be noted that the mobile wireless communication system 100 may also be configured according to Long Term Evolution (LTE) or another mobile wireless communication standard (e.g., non-3GPP access such as WiFi), although 5G is used here as an example. Each radio access network node may provide wireless communication with the mobile wireless terminal device 102 over the air interface. It should be noted that the radio access network 103 may include any number of radio access network nodes.

[0029] The mobile radio communication system 100 further comprises a Core Network (5GC) 119 including an Access and Mobility Management Function (AMF) 101 connected to the RAN 103, a Unified Data Management (UDM) 104 and a Network Slice Selection Function (NSSF) 105, where in the following example the UDM may further comprise an actual UE subscription database, for example known as a Unified Data Repository (UDR). The Core Network 119 further comprises an Authentication Server Function (AUSF) 114, a Policy Control Function (PCF) 115 and an Application Function (AF) 120.

[0030] The core network 119 may have multiple core network slices 106, 107, and for each core network slice 106, 107, an operator (also called a Mobile Network Operator MNO) may create multiple core network slice instances 108, 109. For example, the core network 119 includes a first core network slice 106 with three core network slice instances 108 for providing Enhanced Mobile Broadband (eMBB) and a second core network slice 107 with three core network slice instances (CNI) 109 for providing Vehicle-to-Everything (V2X).

[0031] Typically, when a core network slice is deployed (i.e., created), network functions (NFs) are instantiated or (if already instantiated) referenced to form a core network slice instance, and the network functions belonging to the core network slice instance are configured with a core network slice instance identification information.

[0032] Specifically, in the illustrated example, each instance 108 of the first core network slice 106 includes a first Session Management Function (SMF) 110 and a first User Plane Function (UPF) 111, and each instance 109 of the second core network slice 107 includes a second Session Management Function (SMF) 112 and a second User Plane Function (UPF) 113. The SMFs 110, 112 are for handling Protocol Data Unit (PDU) sessions, i.e., for creating, updating and removing PDU sessions and managing session contexts with the User Plane Function (UPF).

[0033] The RAN 103 and the core network 119 form the network side of a mobile radio communication system, or in other words a mobile radio communication network. The mobile radio communication network and the mobile terminals accessing the mobile radio communication network together form the mobile radio communication system.

[0034] Similar to the core network 119, the RAN 103 may also be sliced, i.e., may include multiple RAN slices. The RAN slices and the core network slices 106, 107 may be grouped to form a network slice.

[0035] In the following, a "network slice" (or simply a "slice") generally refers to a core network slice, but may also include a RAN slice or even a transport network slice.

[0036] Single network slice selection assistance information (S-NSSAI) identifies a network slice and consists of the following: Slice / Service type (SST), which describes the expected network slice behavior in terms of features and services Slice Differentiator (SD), which is optional information that complements the slice / service type and distinguishes between multiple network slices of the same slice / service type.

[0037] A network slice instance (NSI) is identified by an NSI ID.

[0038] An NSSAI may include one or more S-NSSAIs.

[0039] The Allowed NSSAI is an NSSAI provided by the serving Public Land Mobile Network (PLMN), e.g., during the registration procedure, and indicates the S-NSSAI value allowed by the network for the UE within the serving PLMN of the current registration area.

[0040] A Configured NSSAI is an NSSAI provisioned in a UE, which may be applicable to one or more PLMNs.

[0041] The Requested NSSAI is an NSSAI that the UE provides to the network during registration to establish a PDU session to the requested network slice.

[0042] The mobile wireless communication system 100 may further include an OAM function (or entity) 116 implemented, for example, by one or more Operation, Administration and Maintenance (OAM) servers connected to the RAN 103 and the core network 119 (connections not shown for simplicity). The OAM 116 may include a Management Data Analytics Service (MDAS). The MDAS may provide, for example, analysis reports on the network slice instance load. Various factors may affect the network slice instance load, for example, the number of UEs accessing the network, the number of QoS flows, and the resource utilization of different NFs associated with the network slice instance.

[0043] Additionally, the core network 118 includes a Network Repository Function (NRF).

[0044] The core network 119 may further include a Network Data Analytics Function (NWDAF) 117. The NWDAF is responsible for providing network analysis and / or forecasting information upon request from the network functions.

[0045] Various network functions can be implemented on dedicated hardware, i.e. so-called Advanced Telecommunications Computing Architecture (ACTA) devices. This means that the network functions are implemented as physical network functions deployed on special hardware. The software for implementing the network functions is tightly coupled to the hardware.

[0046] However, it may be desirable to implement network functions as software applications running on virtual machines (and / or containers) deployed on non-dedicated hardware as well, i.e., on commercial off-the-shelf (COTS) servers (i.e., on general-purpose or open computing platforms, i.e., devices). This is made possible by using virtualization technologies (e.g., hypervisors, operating system (OS) containers, etc.), where network functions (e.g., SMF, PCF, etc.) can be deployed on virtual machines (VMs) and / or containers. As such, they are referred to as virtual network functions (VNFs).

[0047] Management and orchestration (MANO) is a key element of the European Telecommunications Standards Institute (ETSI) network functions virtualization (NFV) architecture. MANO is an architectural framework that orchestrates network resources for cloud-based applications and the lifecycle management of virtual network functions (VNFs) and network services. It is therefore critical to ensure rapid and reliable NFV deployment at scale. MANO includes several functional blocks and functions such as NFV orchestrator (NFVO), VNF manager (VNFM) and virtual infrastructure manager (VIM).

[0048] 2 shows an architecture 200 that includes a simplified version of the Network Functions Virtualisation Management and Orchestration (NFV-MANO) architectural framework, which includes a collection of functional blocks and functions, data repositories used by these functional blocks, and reference points and interfaces through which these functional blocks exchange information for the purpose of managing and orchestrating NFV.

[0049] The architecture 200 includes an operations support system and business support system (OSS / BSS) 201, and an NFV-MANO including an NFVO 202, a VNFM 203, a VIM 204, a container Infrastructure Service Management (CISM) 205, and a CIS Cluster Management (CCM) 217.

[0050] The NFVO 202 manages network services (NS) 206, which in this example includes the following virtualization functions: AMF 208, SMF 209, and PCF 210, and RAN components 207. A network service (NS) is a composition of physical and virtual network functions and / or services defined by its functional and behavioral specifications.

[0051] The architecture 200 further includes an NFVI 211 that includes hardware and software components that create the virtualized environment in which the VNFs are deployed.

[0052] In this example, the AMF 208, SMF 209 and PCF 210 are implemented as VNFs, i.e., NFs that can be deployed on an NFVI 211. The SMF 209 is implemented by a container 212 running in a virtual machine, the PCF 210 on a virtual machine 213, and the AMF 208 in a container 214, all running on a COTS server 215. In contrast, the RAN component 207 is implemented on an ATCA device 216, i.e., it is a physical network function.

[0053] The NFVO 202 manages the NS lifecycle and coordinates the management of the NS lifecycle, the VNF lifecycle is supported by the VNFM 203, and the NFVI resource management is supported by the VIM 204, CISM 205 and CCM 217, ensuring optimized allocation of required resources and connectivity.

[0054] The VNFM 203 is responsible for the lifecycle management of the VNFs, regardless of whether the VNFs are deployed on VMs or containers.

[0055] The VIM 204 is responsible for controlling and managing NFVI compute, storage and network resources, typically within an operator's infrastructure domain. The CISM 205 is responsible for orchestrating and managing container infrastructure services and the containerized workloads instantiated on them. The CCM 217 is responsible for managing container clusters.

[0056] With regard to Network Functions, it should be noted that 3GPP is responsible for the management and configuration of Network Functions (NFs) and the interactions between NFs, but not for the management of virtualized network function aspects. Indeed, the 3GPP functions remain the same from an application perspective, whether a network function is virtualized or not. From an ETSI NFV perspective, NFV-MANO handles the orchestration and management of both the virtualized resources and the deployed VNFs, remaining agnostic to the actual VNF application (e.g., if the VNF application is a virtualized PCF or a virtualized SMF).

[0057] Regarding VNF management, not only VNF instantiation but also life cycle management (LCM) operations such as updates, scaling, etc. are performed by NFV-MANO (NFVO / VNFM / CISM / VIM), and VNF configuration can be performed by element managers through interactions with OSS.

[0058] A VNF can be part of multiple network services, which can be shared among multiple network slices (or network slice subnets) according to 3GPP and NFV-MANO. Furthermore, multi-tenancy is possible without considering 3GPP network slicing, i.e. an NFV environment can be shared among multiple tenants (in the multi-tenancy sense) and a service provider can offer NFVs to the tenants. Multiple users consume services from the same NFV-MANO or from a dedicated NFV-MANO. Different sharing scenarios can be realized without referring to the network slicing mechanism defined by 3GPP and the correlation between shared resources with specific network slice descriptors (NSDs) or identifiers (e.g. NSI-IDs).

[0059] 3 particularly illustrates a sharing scenario in which a network service 301 is shared between two tenants 302, 303. Different VNFs that are part of the shared network service are also shared between different tenants 302, 303.

[0060] FIG. 4 illustrates a sharing scenario in which two network services 401, 402 are shared between two network slice subnet instances 403, 404.

[0061] With respect to the touchpoint between the 3GPP network slicing management model and the ETSI NFV management model, one or more network slice subnet instances are mapped to one or more shared network services.

[0062] There are various options for deploying network slices using NFV Network Services (NS). Multiple NSs as deployment units for one network slice instance with connectivity provided by NFV Multiple NSs as deployment units for one network slice instance without NFV-provided connectivity for inter-network slice subnets A single NS as the deployment unit for one network slice instance · Network slice instance transport network connection management using multi-site connection service Figure 5 shows network slicing in 3GPP from a management perspective.

[0063] The Communication Service Management Function (CSMF) 501 is responsible for translating communication service requirements into network slice requirements.

[0064] The Slice Management Function (NSMF) 502 serves the end-to-end management and orchestration of network slice instances (NSIs) 503, i.e., realization of network slices.

[0065] Network Slice Subnet Management Functions (NSSMF) 504, 505, 506 are responsible for managing and orchestrating subnetwork slice instances 503 within a particular domain. For example, Transport Network Slice Subnet Instance (TN-NSSI) 507 is the realization of a network slice on a transport domain, and Core-NSSI 508 is the realization of a network slice on a core domain. NSI 503 is a composition of multiple NSSIs 507, 508, 512.

[0066] The NSSMFs 504, 505, and 506 are connected to respective domain controllers 509, 510, and 511.

[0067] FIG. 6 shows slice management from a 3GPP perspective.

[0068] 5, there is an NSMF 601 and multiple NSSMFs 602. Additionally, there is an OSS 603 and an orchestration system (e.g., NFV-MANO) 604 that manages the VNFs and NFVI 605, as described above.

[0069] 6, the OSS 603 may follow normal procedures to configure the application aspects of the shared VNF 606 via an element manager (EM) 611. A VNF 607 belonging to a first communication network 608 (e.g., a first tenant) and a VNF 609 belonging to a second communication network 610 are also connected to the shared VNF 606.

[0070] From the NFV-MANO 604 perspective, there is no entity managing the mapping of VNFs and PNFs and other communication resources to Network Slice Subnet Instances (NSSIs), i.e., NFV-MANO is not aware of slices.

[0071] According to various embodiments, a technique is described that allows two networks 608, 610 (608 may be 3GPP slice aware and 610 may belong to a tenant but is slice unaware) to share the same VNF 606 and independently configure allowed parameters. This covers the concept of general VNF sharing while also being able to provide support for network slicing. It holds the mapping of NSSI to network services and VNFs / PNFs. This can be used to apply filters and expose slice specific information from VNF generic OAM functions to NFV-MANO (or OSS, etc.).

[0072] Specifically, according to various embodiments, an entity denoted as the VNF Shared Manager is included in the VNF Generic OAM Functionality Framework, which provides the following functions: The VNF sharing manager may convert non-sharable (regular VNFs) to sharable VNFs and vice versa (without disrupting the operation of the VNFs). This can be used to manage not only the pre-provisioning aspects, but also VNF configuration and management without continuous interaction with the NFV-MANO (e.g. VNFM). It interacts with other VNF generic OAM functions and uses their services. It manages multi-tenancy of shared VNFs, which can be used not only by network slices but also by other tenants in a generic way. Multitenancy can be enabled without considering strict network slicing association as defined by 3GPP. Multitenancy can be enabled by considering both network slicing-based requirements and operational requirements from other systems (e.g., non-3GPP). It uses virtual network slices to enable management and control of shareable VNFs from 3GPP slice-aware management systems as well as non-3GPP management systems. It applies slicing at the VNF level and maintains operational isolation between different tenants. This controls the enforcement of VNF policies per tenant / slice. This enables automated VNF configuration per tenant / slice, taking into account the VNF application, allocated virtualized resources as well as physical resources. · The VNF sharing manager can partially execute VNFM-related operations on the VNF LCM after negotiation with MANO (VNFM). It maintains the appropriate mapping between network slice instances and / or between network slice subnet instance identifiers and MANO resources / VNFs passed from other management entities (such as NSSMF) and maintains mapping between identifiers and MANO resources / VNFs from other non-3GPP management systems. In addition to the 3GPP slice management system, it also interacts with other orchestration and management systems (e.g. SMO in the case of O-RAN or industrial management systems). It automates VNF configuration and management by interacting with other VNF generic OAM functions, without interaction with the VNFM.

[0073] FIG. 7 illustrates the addition of a VNF sharing manager 700 to a VNF generic OAM function 701, according to one embodiment.

[0074] The VNF generic OAM function 701 provides functions in a unified manner, facilitating management of different types of VNFs from an operator's perspective and simplifying the design of individual VNFs. The VNF generic OAM function can interact with NFV-MANO, OSS / BSS, VNF / VNFC, NFVI / Host and other VNF generic OAM functions.

[0075] Examples of VNF generic OAM functions 701 are a network configuration manager 702, a VNF upgrade function 703, a VNF configuration manager 704, and a traffic enforcer 705.

[0076] The VNF sharing manager 700 can also connect to a 3GPP slice management 712, including the NSMF and NSSMF as described with reference to Figure 6, an OSS / BSS 713 (e.g., corresponding to OSS 603), and an NFV-MANO entity 714 as described with reference to Figure 2. Additionally, the VNF sharing manager 700 can connect to an external management system 715, which is assumed to be slice unaware.

[0077] The VNF generic OAM function 701 is connected to the VNF / VNFC 716.

[0078] FIG. 8 shows a flow diagram 800 illustrating the conversion of a (non-shared) VNF 801 (corresponding to one of the VNFs 716) to a shared VNF by a VNF Sharing Manager 802 (corresponding to the VNF Sharing Manager 700).

[0079] At 811, the OSS / BSS 803 (e.g., corresponding to the OSS / BSS 713) requests the NFVO of the MANO architecture 804 (e.g., corresponding to the MANO component 714) to create a VNF. Conventional procedures may be used for this purpose.

[0080] At 812, MANO 804 instantiates the VNF 801 (as requested) using conventional procedures.

[0081] At 813, the element manager 805 is attached to the VNF 801 using conventional procedures.

[0082] At 814, for each deployed VNF, MANO 804 passes a VNF sharing profile to the VNF Sharing Manager or requests the VNF Sharing Manager 802 to create a VNF sharing profile if not provided.

[0083] At 815, for each deployed VNF, the VNF Sharing Manager 802 compiles a VNF sharing profile (if not provided by MANO) (depending on the resources used, the applications being shared such as AMF, PCF, etc.) and derives sharing properties, e.g., which functions can be shared and the conditions under which the functions can be shared.

[0084] Assume that an external management system 806 (e.g., OSS or NSSMF 712, etc., corresponding to external management system 715) makes a request to use VNF 801 (which is assumed to be sharable) at 816. The request may come internally from MANO as well, due to VNF LCM operations.

[0085] At 817, MANO 804 notifies the VNF Sharing Manager 802 about the request of 816 to check if sharing is allowed or if a new dedicated VNF needs to be created.

[0086] At 818, the VNF Sharing Manager 802 checks the VNF Sharing Profile and responds with VNF sharing capabilities and whether to share, enables the probe to set the VNF to "shared" mode, and updates the VNF sharing status state machine.

[0087] At 819, the VNF Sharing Manager 802 notifies MANO 804 about enabling sharing. After sharing the VNF 801, the VNF configuration can be delegated to the VNF Sharing Manager 802 and the VNF LCM is negotiated between the VNF Sharing Manager and MANO depending on the sharing profile.

[0088] At 820, MANO 804 replies to the external management system 806 that it may use the (now shared) VNF 801. It also notifies the VNF sharing manager 802.

[0089] At 821, for VNF configuration, interaction between OSS 803 or external OSS 806 and VNF 801 can be performed through VNF Sharing Manager 802 depending on the sharing profile.

[0090] At 822, after sharing is enabled, a further EM 807 or directly an external OSS 806 can configure the VNF 801 through the VNF Sharing Manager 802. The VNF Sharing Manager 802 can interact with the rest of the generic OAM functions to configure specific VNF aspects (e.g., network parameters through a network configuration manager).

[0091] A similar flow may be applied to convert a shared VNF to a non-shared VNF.

[0092] FIG. 9 illustrates the state of the VNFs controlled by the VNF Sharing Manager.

[0093] If a VNF is shareable according to the sharing profile, the VNF may be in a shared state 901 or a non-shared state 902. If it is not shareable, it may only be in a non-shared state 902. The VNF sharing manager may convert a VNF from shareable to non-shareable and vice versa.

[0094] The request for a shared VNF may originate from the NSSMF, but also from an OSS or an external system and may be sent to another system such as MANO or Service Oriented Network Auto Creation (SONAC) or Open RAN-Service Management and Orchestration (O-RAN SMO).

[0095] However, the VNF sharing manager 802 needs to know who is using the VNF 801 and how they are using it, because this also impacts the delegation and authorization of the VNF LCM. For 3GPP-based slice recognition requests, this information is typically available, since specific blueprints are used. However, for other management systems or tenants, there are typically no specific templates defined to use for the shared VNF 801.

[0096] Thus, according to various embodiments, the VNF Sharing Manager 700 enables management and control of sharable VNFs from 3GPP slice-aware management systems and non-3GPP management systems (e.g., external slice-unaware management systems 715) using virtual network slices, which means that, according to various embodiments, in order to use common procedures internally for slice-aware and slice-unaware tenants, the latter are abstracted using a Virtual Network Slice (VNS).

[0097] For each external tenant, the VNF Sharing Manager 802 exposes a VNS API to the tenant. This API can also be exposed by MANO 804 on behalf of the VNF Sharing Manager 802.

[0098] Each tenant must respond with the VNS information requested by the VNF Sharing Manager 802.

[0099] FIG. 10 illustrates the use of virtual network slices.

[0100] For each network slice instance (NSI) or virtual NSI (vNSI) network slice, an abstract representation of the VNFs 1001, 1002 is maintained. A VNF sharing manager 1003 allows a specific view of the VNFs per NSI or vNSI, so that they can manage specific VNF objects 1004.

[0101] Instances of VNS and abstract VNF ​​objects 1004 are identified using appropriate IDs.

[0102] The VNF Sharing Manager 1003 maintains an inventory service with a mapping of shared VNF information per NSI-ID and VNSI-ID. It is responsible for ensuring isolation between different slice or virtual slice operations and ensuring isolation between different VNF / VNFC instances. It knows who is using the VNF 1005 and how the user wants to use it (requirements).

[0103] VNF requirements passed by slice-aware and slice-unaware tenants are passed in a single format. In a simple "default" format, the VNF Sharing Manager 1003 instantiates a VNS for a single VNF for slice-unaware tenants of VNFs. More complex relationships between the VNS and MANO 1006 are also possible (not only considering "singleton" VNFs, but also network services, VNFFGs, VNFCs, etc.). The VNF Sharing Manager 1003 exposes a VNS management interface to tenants and virtual NSI LCM operations in a "northbound" interface towards external management functions 1007.

[0104] The northbound interface of the VNF sharing manager 1003 facilitates interaction with the OSS / BSS 1008, NFV-MANO 1006, NFVI, NSMF 1009, NSSMF 1010, tenant management system 1007, etc.

[0105] The VNF sharing manager 1003 further includes a "southbound" interface for interaction with the VNFs 1005 and a "west-east" interface for interaction with other VNF generic OAM functions. The VNF sharing manager 1003 can interact with the VNFs directly or through other VNF generic OAM functions (e.g., a VNF configuration manager).

[0106] It should be noted that the VNF generic OAM functions are also compatible with the VNF configuration method according to ETSI NFV. The VNF sharing manager 1003 can be realized and managed as a Common VNF or a Platform as a Service (PaaS) service according to ETSI NFV.

[0107] FIG. 11 shows a flow diagram 1100 for VNF configuration.

[0108] The components described with reference to FIG. 7, namely, VNF Sharing Manager 1101, NSSMF 1102, NFV-MANO 1103, NFVI 1104, VNF 1105, Network Configuration Manager 1106, Traffic Enforcer 1107, Metrics Aggregator 1109, Metrics Analyzer 1108, Log Aggregator 1111, Log Analyzer 1110 and Notification Manager 1112 are involved in the flow.

[0109] The VNF Sharing Manager 1101 can autonomously determine the shared VNF behavior after contention resolution between all NSIs and virtual NSIs (vNSIs) without considering any interaction with the NFV-MANO 1103. As an example shown in FIG. 11 and described below, the VNF Sharing Manager 1101 performs VNF network reconfiguration by invoking the VNF Network Configuration Manager 1106 and the Traffic Enforcer 1107 to invoke traffic enforcer behavior, taking into account slicing and virtual slicing requirements from users of the VNFs.

[0110] At 1113, automated decision-making is enabled for the shared VNFs 1105 (e.g., delegated by MANO 1103 to the VNF Sharing Manager 1101).

[0111] At 1114, the VNF sharing manager 1101 collects VNF data from the metrics analyzer 1108 and / or the log analyzer 1110. Metrics data and log data are collected from the metrics aggregator 1109 and the log aggregator 1111 and relate to VNF data, MANO data, NFVI data, etc.

[0112] At 1115, it is assumed that the VNF Sharing Manager 1101 receives updates regarding slice requirements from the NSSMF 1102 (either directly or through interaction with NFV-MANO).

[0113] At 1116, the VNF sharing manager 1101 aligns with the QoS and / or operational requirements for the NSI or vNSI (indicated per NSI and / or vNSI by the NSSMF 1102 in this example).

[0114] At 1117, in response to 1116, the VNF Sharing Manager 1101 decides to take network reconfiguration action and informs the VNF Network Configuration Manager 1106 (and the Traffic Enforcer 1107) accordingly.

[0115] At 1118, a reconfiguration action is applied (the network configuration manager 1106 is invoking the traffic enforcer 1107).

[0116] At 1119, the VNF Sharing Manager 1101 notifies the MANO 1103 about the reconfiguration.

[0117] 12 shows a flow diagram 1200 illustrating the workflow of an NSSMF 1201 requesting a shareable VNF. The NFV-MANO 1202 and the VNF Sharing Manager 1203, e.g. as described with reference to FIG. 7, are also involved in the flow.

[0118] At 1204, the NFV-MANO 1202 instantiates the VNF using normal procedures 1204 and notifies the VNF sharing manager 1203 about it.

[0119] At 1205, the VNF Sharing Manager 1203 compiles a VNF sharing profile for the VNF (if not provided by NFV-MANO).

[0120] At 1206, the NSSMF 1201 requests to use a VNF for a particular network slice.

[0121] In 1207, the NFV-MANO 1202 requests the VNF Sharing Manager 1203 to check whether the VNF can be shared.

[0122] At 1208, the VNF sharing manager 1203 performs the requested checks based on the VNF sharing profile. In this example, it is assumed that the VNF is shareable.

[0123] At 1209, the VNF sharing manager 1203 creates an abstract VNF ​​representation assigned to the network slice.

[0124] At 1210, the VNF Sharing Manager 1203 notifies the NFV-MANO 1202 that the VNF can be shared.

[0125] In 1211, the NFV-MANO decides on VNF autonomous LCM and / or configuration delegation to the VNF sharing manager 1203.

[0126] At 1212, the NFV-MANO 1202 acknowledges the request of the NSSMF at 1206 and informs it how to communicate with the VNF Sharing Manager 1203.

[0127] At 1213, the involved NFV-MANO entities (e.g., NFVO, VNFM) and / or EM and NSSMF 1201 are notified of any updates that occur.

[0128] At 1214, the VNF Sharing Manager 1203 autonomously performs VNF configuration and / or management operations based on requirement updates received from the management system (e.g., NSSMF 1201) and the status of the VNFs and participating systems (see flow in FIG. 11).

[0129] At 1215, the VNF Sharing Manager 1203 notifies consumers (who have subscribed to notifications).

[0130] If the request to use a VNF comes from a slice-unaware management system of a particular tenant, rather than from the NSSMF 1201, then that management system uses the virtual network slice API to request the use of the VNF. The flow is then similar, but before 1209, the VNF sharing manager compiles a virtual network slice representation for the tenant.

[0131] In summary, in accordance with various embodiments, a communication system is provided as shown in FIG.

[0132] FIG. 13 illustrates a communication system 1300 according to one embodiment.

[0133] The communications system 1300 includes a network function virtualization orchestration system 1301 configured to provide virtual network functions for applications in a communications network 1302 .

[0134] Additionally, the communication system 1300 includes a virtual network function sharing management component 1303 configured to establish a sharing profile for the virtual network function, the sharing profile specifying whether the virtual network function can be shared with another communication network 1304.

[0135] The network function virtualization orchestration system 1301 is configured to satisfy a request from another communication network 1304 by sharing the provided virtual network function with the other communication network 1304 if a sharing profile specifies that the virtual network function may be shared with the other communication network 1304 in response to a request from the other communication network 1304 for the provision of a virtual network function.

[0136] In other words, according to various embodiments, sharing of virtual network functions is enabled, and the capabilities of the shared virtual network functions are stored in a sharing profile of the virtual network functions.

[0137] Various embodiments provide support for both sharing options, i.e., sharing of virtual network functions between network slices and between one or more network slices and a non-network slicing aware communication system (corresponding to the "another" communication network in FIG. 13), e.g., via NFV-MANO. In particular, mechanisms are provided to handle multi-tenancy and network slicing of VNF operations in a uniform manner. Rather than providing VNF sharing only in the context of network slicing, various embodiments provide a generic way to associate VNFs with multiple network services owned by different tenants, even when different NFV-MANO systems are used.

[0138] The approach of Figure 13 can be applied in many use cases, for example in industrial automation and O-RAN environments, for example, a virtual network function is a firewall between various networks (and thus may be used and configured by multiple networks), for example, a firewall between a mobile communications network in a factory, a factory intranet, and a local area network connecting the factory robotic devices.

[0139] The approach of FIG. 13 may be implemented using extensions on the VNF generic OAM function framework. The VNF generic OAM functions can be easily used in conjunction with the approach of FIG. 13 (e.g., VNF Shared Manager) without impacting the design and implementation of the VNF. The approach of FIG. 13 allows flexibility as to how VNF configuration and management can be further simplified and optimized. Various embodiments can operate on a multi-technology VNF environment (e.g., VM-based and / or container-based).

[0140] Thus, various embodiments enhance the orchestration mechanisms of telecommunication operators with additional methods and / or mechanisms and interfaces that can enable shared VNF management from a network slicing perspective and beyond. These enable uniform management of virtual network slices that are uniformly managed by the network operator. This type of management can be utilized as a network service and be part of a unified orchestration plane. Additionally, additional network services can be engineered using the VNF sharing manager.

[0141] Various embodiments enable management of VNF multi-tenancy without consideration of slicing and / or external NFV-MANO. As noted above, VNF shared components may be included as part of a VNF generic OAM function framework.

[0142] If the sharing profile specifies that the virtual network function cannot be shared with another communication network, then network function virtualization orchestration system 1301 satisfies the request from the other communication network in a manner other than by sharing the provided virtual network function with the other communication network. For example, network function virtualization orchestration system 1301 may satisfy the request by sharing another virtual network function or may create a virtual network function to satisfy the request from the other communication network.

[0143] The communication system may, for example, execute a method as shown in FIG.

[0144] FIG. 14 shows a flow diagram 1400 illustrating a method for providing virtual network functionality.

[0145] At 1401, a virtual network function for an application in a communications network is provided.

[0146] At 1402, a sharing profile is established for the virtual network function, the sharing profile specifying whether the virtual network function can be shared with another communication network.

[0147] At 1403, if the sharing profile specifies that the virtual network function may be shared with another communications network in response to a request from the other communications network for the provision of the virtual network function, the request from the other communications network is satisfied by sharing the provided virtual network function with the other communications network.

[0148] For example, according to various embodiments, a method for optimizing deployment and operation of a shared network service is provided, the method including: Receive requests from management systems to: To deploy or update a network service using one or more shared VNFs To create one or more virtual network slice instances and map them to different tenants ○ To validate incoming input and make it compliant with different tenant policies Receives information from a shared VNF (or VNF component) regarding: ○Shared VNF status, shared VNF failure management information, shared VNF performance management information, shared VNF configuration information Expose and transform per-slice or per-virtual slice instance information to one or more management systems or one or more other shared VNFs with respect to: ○Shared VNF status, shared VNF failure management information, shared VNF performance management information, shared VNF configuration information Automate shared VNF configuration and management operations Maintaining isolation between network slice instances running on a shared VNF and virtual network slice instances The components of the communication system may be implemented, for example, by one or more circuits. A "circuit" may be understood as any kind of logic implementation entity, which may be a dedicated circuit or a processor executing software stored in a memory, firmware, or any combination of these. Thus, a "circuit" may be a hardwired logic circuit, or a programmable processor, e.g., a programmable logic circuit such as a microprocessor. A "circuit" may also be a processor executing software, e.g., any kind of computer program. Any other kind of implementation of each of the above functions may also be understood as a "circuit".

[0149] While particular embodiments have been described, it should be understood by those skilled in the art that various changes in form and detail may be made therein without departing from the spirit and scope of the disclosed embodiments as defined by the appended claims, the scope of which is therefore indicated by the appended claims, and all changes that come within the meaning and range of equivalence of the claims are therefore intended to be embraced.

Claims

1. 1. A communication system comprising: A network function virtualization orchestration system configured to provide virtual network functions for applications of a communications network; a virtual network function sharing management component configured to establish a sharing profile for the virtual network function; wherein the sharing profile specifies whether the virtual network function may be shared with another communications network, and the network function virtualization orchestration system is configured, in response to a request from the other communications network for provision of a virtual network function, if the sharing profile specifies that the virtual network function may be shared with the other communications network, to satisfy the request by sharing the provided virtual network function with the other communications network; The communication system includes a plurality of network slices, and the virtual network function sharing management component is configured to share the virtual network function between the communication network and the other communication network by treating the other communication network as a virtual network slice and sharing the virtual network function between the virtual network slice and one or more of the plurality of network slices.

2. 2. The communication system of claim 1, wherein the network function virtualization orchestration system is configured to receive the request from the other communication network and, in response to receiving the request, to request the virtual network function sharing management component to check whether the sharing profile specifies that the virtual network function may be shared with the other communication network.

3. The communication system of claim 2 , wherein the virtual network function sharing management component is configured to maintain an abstract representation of the virtual network function for each network slice and virtual network slice where the virtual network function is shared.

4. 4. The communication system of claim 1, wherein the network function virtualization orchestration system is configured to delegate lifecycle management and / or configuration management of the virtual network function to the virtual network function sharing management component if the sharing profile specifies that the virtual network function may be shared with the other communication network.

5. 2. The communication system of claim 1, wherein the virtual network function sharing management component is configured to configure the virtual network function according to requirements for use of the virtual network function received from the communication network and the other communication network if the sharing profile specifies that the virtual network function may be shared with the other communication network.

6. The communication system of claim 1 , wherein the network function virtualization orchestration system is configured to create the virtual network function in response to a request for provision of the virtual network function from the communication network.

7. The communication system of claim 1 , wherein the sharing profile specifies whether a virtual network function can be shared with any other communication networks.

8. The communication system of claim 1 , wherein the request from the other communication network to provide a virtual network function is for the same application as the communication network.

9. The communication system of claim 1 , wherein the application is a network function of a core network of a mobile communication network.

10. The communication system of claim 1 , wherein the virtual network function sharing management component is configured to manage a sharing status of the virtual network function by a state machine.

11. 2. The communication system of claim 1, wherein the virtual network function sharing management component is configured to transition, during operation of the virtual network function, between a virtual network function that is shareable with the other communication network and a virtual network function that is not shareable with the other communication network.

12. 1. A method for providing virtual network functions, comprising: providing a virtual network function for an application of a communications network; establishing a sharing profile for the virtual network function, the sharing profile specifying whether the virtual network function may be shared with another communication network; in response to a request from the other communications network for the provision of a virtual network function, if the sharing profile specifies that the virtual network function may be shared with the other communications network, satisfying the request from the other communications network by sharing the provided virtual network function with the other communications network; a communication system including a plurality of network slices, wherein the virtual network function is shared between the communication network and the other communication network by treating the other communication network as a virtual network slice and sharing the virtual network function between the virtual network slice and one or more of the plurality of network slices.

Images