Patent Description:
In physical networks, network functions are often implemented as a combination of vendor-specific software and hardware, referred to as network nodes or network elements. In virtualised networks, software is decoupled from hardware, which means that infrastructure resources can be shared and reassigned. Virtual networks may thus comprise one or more virtual network functions (VNFs), each of which is an implementation of an executable software program that constitutes the whole or a part of a network function and can be deployed on virtualisation infrastructure.

The provision of network services by VNFs in the virtual network may be facilitated by a Network Functions Virtualisation Orchestrator (NFVO). The NFVO conducts the orchestration and management of network functions virtualisation infrastructure (NFVI) and is responsible for network service management including, for example, instantiating, scaling, updating and terminating network services. The NFVO may also support VNF lifecycle management, together with one or more VNF Managers (VNFMs). A VNFM is responsible for VNF lifecycle management including, for example, instantiating, updating, querying, scaling and terminating VNFs.

The management of VNFs thus requires cooperation between the NFVO and any VNFMs in the virtual network. However, when a new NFVO is deployed in a virtual network that already has a VNFM, the new NFVO may not be aware of any VNFs that have already been instantiated at the VNFM.

There is known a document related to VNF package on-boarding, namely <CIT>. However, devices and operations as in the invention now to be described are neither disclosed nor suggested in this document.

The solution in embodiments of the present disclosure provide the advantages of automating the discovery process and make the NFV MANO Units intelligent enough to find new VNF's for discovery. NFVOs and VNFMs compliance with this solution will enable the Telecom Service Providers and Enterprise customers to mix and match the NFVOs and VNFMs from different vendors and still have discovery feed technique automated. In consequence, product vendors will not have to spend time and effort to specify manually the VNF's to be discovered.

<FIG> shows an example of a system <NUM> comprising a network function virtualisation management and orchestration framework (NFV-MANO) <NUM>, a virtual network function (VNF) <NUM>, a Network Functions Virtualisation Infrastructure (NFVI) <NUM> and an operations support system or business support system (OSS/BSS) <NUM>.

Only one VNF <NUM> is shown, although the skilled person will appreciate that the system <NUM> may comprise many more VNFs <NUM>. A VNF referred to herein can be any implementation of a network function that can be deployed using software virtualisation techniques. A network function can be any functional building block within a network infrastructure. A functional building block may, for example, be a block within a network infrastructure that has well-defined external interfaces and a well-defined functional behaviour. In practical terms, a network function may, for example, be a network node, a physical appliance, or any other type of network function.

The NFVI <NUM> comprises resources upon which VNFs (such as the VNF <NUM>) may be deployed. Thus, for example, the NFVI <NUM> may comprise one or more of: virtualisation software, hardware and system management software.

The NFV-MANO <NUM> coordinates resources and manages the lifecycle of VNFs <NUM> in the system <NUM>. As illustrated, the NFV-MANO <NUM> comprises a Network Function Virtualisation Orchestrator (NFVO) <NUM>, a Virtual Network Function Manager (VNFM) <NUM> and a Virtualisation Infrastructure Manager (VIM) <NUM>.

The NFVO <NUM> conducts the orchestration and management of NFVI and software resources, and is responsible for realising network services on NFVI. This may include, for example, on-boarding, instantiating, scaling, updating and terminating network services. For example, on receiving a request to instantiate a network service (e.g. from the OSS/BSS <NUM>), the NFVO <NUM> may determine whether a VNF instance satisfying the requirements for providing the service has already been instantiated at the VNFM <NUM>. If the VNF instance has been instantiated, it may be used to deliver the requested service. If the VNF instance has not already been instantiated, the NFVO <NUM> may initiate instantiation of the VNF instance at the VNFM <NUM>.

The VIM <NUM> controls and manages virtualisation infrastructure (e.g. the NFVI <NUM>), including, for example computing, storage and networking resources. The VIM <NUM> may thus, for example, manage a repository of hardware and software, monitor resource usage, monitor and manage network connections and/or provide resource information to other nodes in the system <NUM>.

Together with the NFVO <NUM>, the VNFM <NUM> is responsible for lifecycle management for VNFs in the system (such as the VNF <NUM>). This may include, for example, instantiating, scaling, updating and terminating VNFs. Although only one VNFM <NUM> is shown, the skilled person will appreciate that the system <NUM> may comprise one or more VNFMs.

The NFVO <NUM> and the VNFM <NUM> may thus cooperate to manage the lifecycle of the VNF <NUM>. However, situations may arise in which an NFVO may be deployed in a system with an existing VNFM. For example, an NFVO may be deployed in a system that lacks an NFVO or a new NFVO may be deployed to replace an existing an NFVO.

In these situations, registration between the NFVO and the VNFM may be performed in order to establish an interface between the NFVO and the VNFM.

Registration may be a manual process. For example, an operator or a user may configure the NFVO with registration information for the VNFM and configure the VNFM with registration information for the NFVO.

Alternatively, the VNFM may register the NFVO by receiving one or more messages comprising registration information for the NFVO. The messages may be received from the NFVO, for example. Similarly, the NFVO may register the VNFM by receiving one or more messages comprising registration information for the VNFM (e.g. from the VNFM).

The registration information for the VNFM may comprise information enabling the NFVO to contact the VNFM. Similarly, the registration information for the NFVO may comprise information enabling the VNFM to contact the NFVO. For example, the registration information for the NFVO may comprise an Internet Protocol (IP) address and/or a port for the NFVO.

Therefore, the NFVO may be considered to be registered at the VNFM when the VNFM obtains the registration information for the NFVO. Similarly, the VNFM may be considered to be registered at the NFVO when the NFVO obtains the registration information for the VNFM.

As described above, registration between the NFVO and the VNFM may establish a reference point between the NFVO and the VNFM on which one or more interfaces may be exposed. However, even once an NFVO has registered a VNFM, the NFVO may not be aware of any VNFs that have already been instantiated at the VNFM, which means that the NFVO and the VNFM may not be able to effectively cooperate to manage the lifecycle of VNFs that are already instantiated at the VNFM.

The disclosure provides methods and apparatus for addressing these and other problems. In one aspect, the disclosure provides a method performed by an NFVO. The method comprises receiving, from a VNFM, identifying information for at least one VNF instance instantiated at the VNFM, wherein the identifying information is received from the VNFM in response to registration of one of the NFVO and the VNFM at the other of the NFVO and the VNFM. The method further comprises creating a record at the NFVO for the at least one VNF instance identified by the VNFM.

The present disclosure thus provides a method for identifying existing instances of VNFs that have already been instantiated at the VNFM to the NFVO. This enables efficient deployment of NFVOs in virtual networks, thereby improving the provision of services in virtual networks.

<FIG> is a flowchart of an example of a method <NUM> performed by a NFVO. The method <NUM> may be, for example, performed by the NFVO <NUM> described above in respect of <FIG>.

In step <NUM>, the NFVO <NUM> receives, from a VNFM, identifying information for at least one VNF instance instantiated at the VNFM. The VNFM may be, for example, the VNFM <NUM> described above in respect of <FIG>.

The identifying information may comprise, for example, a unique identifier for each of the at least one VNF instances instantiated at the VNFM <NUM> (e.g. a VNF Instance Identifier or VNF ID). The identifying information may further comprise supplementary information for the instance of the VNF, including, for example, one or more of: a name or type of the VNF, a creation time and/or date, an owner etc..

The identifying information may be comprised in a VnfldentifierNotification message. An example format for the VnfldentifierNotification is shown in Table <NUM>. The skilled person will appreciate that the message may comprise any combination of the elements shown in Table <NUM>.

The identifying information for the at least one VNF instance is received from the VNFM <NUM> in response to registration of one of the NFVO <NUM> and the VNFM <NUM> at the other of the NFVO <NUM> and the VNFM <NUM>.

Thus, the identifying information may be received in response to registration of the NFVO <NUM> at the VNFM <NUM>. That is, the VNFM <NUM> may send the identifying information upon registration of the NFVO <NUM> at the VNFM <NUM>.

Alternatively, the identifying information may be received in response to registration of the VNFM <NUM> at the NFVO <NUM>. In particular aspects, the NFVO <NUM> may, in response to registration of the VNFM <NUM> at the NFVO <NUM>, send a request to the VNFM <NUM> to identify one or more VNF instances that are instantiated at the VNFM <NUM>. The NFVO may thus receive the identifying information in step <NUM> in in response to the VNFM <NUM> receiving the request from the NFVO <NUM>.

The request may, for example, be sent over a lifecycle management (LCM) interface between the NFVO <NUM> and the VNFM <NUM>. The interface may be compliant with ETSI GS NFV-SOL <NUM>.

The request may be a request to identify all VNF instances that are instantiated at the VNFM <NUM>. The NFVO <NUM> may thus, in step <NUM>, receive identifying information for all the VNF instances that are instantiated at the VNFM <NUM>.

Alternatively, the request may specify one or more filters (e.g. criteria) for VNF instances to be identified to the NFVO <NUM>. The NFVO <NUM> may thus, in step <NUM>, receive identifying information only for VNF instances that satisfy the one or more filters. The one or more filters may comprise any combination of suitable filters. In particular aspects, the one or more filters may comprise one or more of the following filters for the one or more VNF instances to be identified by the VNFM: a type of VNF, a VNF provider, a VNF version, a provider of the one or more VNF instances, a version of the one or more VNF instances, a version of a VNF description (VNFD) for the one or more VNF instances, and a service to be provided using the one or more VNF instances (e.g. identified by a product or service name). For example, the request may specify that the VNFM <NUM> is to identify any instances of an evolved packet gateway (EPG) that are instantiated at the VNFM <NUM>. In which case, the NFVO <NUM> may receive, in step <NUM>, identifying information for any EPG instances that are instantiated at the VNFM <NUM>.

The request may be sent in one or more messages. For example, the NFVO <NUM> may send the VNFM <NUM> a first message requesting that the VNFM <NUM> identify one or more VNF instances that are instantiated at the VNFM <NUM> and a second message indicating one or more filters to be used by the VNFM <NUM>.

The NFVO <NUM> thus receives identifying information for at least one VNF instance instantiated at the VNFM <NUM> in response to registration of one of the NFVO <NUM> and the VNFM <NUM> at the other of the NFVO <NUM> and the VNFM <NUM>.

In particular aspects, the at least one VNF instances may have been instantiated at the VNFM <NUM> before the NFVO <NUM> registered at the VNFM <NUM>. For example, the NFVO <NUM> may receive identifying information only for VNF instances that were instantiated at the VNFM <NUM> before registration of the NFVO <NUM>.

In examples in which the NFVO <NUM> sends a request to the VNFM, the at least one VNF instances may be VNF instances that were instantiated at the VNFM <NUM> before the request was received by the VNFM <NUM>. Thus, for example, the VNF instance may not include VNF instances that were instantiated at the VNFM <NUM> after the request was received.

In step <NUM>, the NFVO <NUM> creates a record at the NFVO <NUM> for the at least one VNF instance identified by the VNFM <NUM>. The NFVO <NUM> may generate a VNF record for each of the at least one VNF instances identified in the identifying information received from the VNFM <NUM>. The record may comprise the identifying information received from the VNFM <NUM>.

In particular aspects, creating a record at the NFVO <NUM> may comprise generating a VNF identifier to identify the at least one VNF instance at the NFVO. The NFVO <NUM> may configure the record with a mapping between the identifying information received from the VNFM <NUM> and the VNF identifier generated at the NFVO <NUM>. Thus, the record may comprise both the VNF identifier and the identifying information. The VNF identifier generated at the NFVO may serve as a local identifier for the VNF instance (e.g. an identifier for the VNF instance as instantiated at the NFVO <NUM>).

The NFVO <NUM> may thus receive identifying information for at least one VNF instance at the VNFM and create a record at the NFVO <NUM> for the identified VNF instance.

In particular aspects, the method <NUM> may further comprise receiving identifying information for a further VNF instance in response to the further VNF instance being instantiated at the VNFM <NUM>. For example, the NFVO <NUM> may send a subscription request to the VNFM <NUM>, requesting to receive identifying information whenever a new VNF instance is instantiated at the VNFM <NUM>. The subscription request may be comprised in the request described above. Alternatively, the subscription request may be sent in another message. In either case, the NFVO <NUM> may receive identifying information for any further VNF instances as they are instantiated at the VNFM <NUM>. The NFVO <NUM> is thus kept informed of any VNF instances that are instantiated at the VNFM <NUM>, which enables the NFVO <NUM> to determine which services may be provided by VNF instances that have already been instantiated at the VNFM <NUM> without requiring any further signalling (e.g. to query the VNFM <NUM>).

The NFVO <NUM> may use the identifying information for the at least one VNF instances to perform discovery for the at least one VNF instances. For example, the NFVO <NUM> may query the VNFM <NUM> and/or a VIM (such as the VIM <NUM> described above in respect of <FIG>) for resource information relating to each of the at least one VNF instances that are instantiated at the VNFM <NUM>.

<FIG> is a flowchart of an example of a method <NUM> performed by a VNFM. The method <NUM> may be, for example, performed by the VNFM <NUM> described above in respect of <FIG>.

In step <NUM>, the VNFM <NUM> sends, to an NFVO, identifying information for at least one VNF instance instantiated at the VNFM in response to registration of one of the NFVO and the VNFM <NUM> at the other of the NFVO and the VNFM <NUM>. The NFVO may be, for example, the NFVO <NUM> described above in respect of <FIG>.

The identifying information may be, for example, the identifying information described above with respect to <FIG>. For example, the identifying information may be comprised in a VNFIdentifierNotification message as described above.

In some aspects, sending identifying information for at least one VNF instance instantiated at the VNFM <NUM> in response to registration of one of the NFVO <NUM> and the VNFM <NUM> at the other of the NFVO and the VNFM <NUM> may comprise sending the identifying information in response to registration of the NFVO <NUM> at the VNFM <NUM>.

For example, the VNFM <NUM> may send the identifying information to the NFVO <NUM> in response to the VNFM <NUM> obtaining registration information for the NFVO <NUM>.

The VNFM <NUM> may send the identifying information in response to registration of the VNFM <NUM> at the NFVO <NUM>. For example, the VNFM <NUM> may send the identifying information in response receiving a message from the NFVO <NUM> indicating that the VNFM <NUM> is registered at the NFVO <NUM>. The message may, for example, form part of a registration procedure between the NFVO <NUM> and the VNFM <NUM>.

The VNFM <NUM> may send the identifying information in response to receiving a request, from the NFVO <NUM>, to identify one or more VNF instances that are instantiated at the VNFM <NUM>, wherein the request is received in response to registration of the VNFM <NUM> at the NFVO <NUM>.

The request may be the request described above in reference to <FIG>. Thus, for example, the request may be a request to identify all VNF instances that are instantiated at the VNFM <NUM>. In which case, the VNFM <NUM> may send identifying information for all the VNF instances that are instantiated at the VNFM <NUM>.

In an alternative example, the request may specify one or more filters for VNF instances to be identified to the NFVO <NUM>. The VNFM <NUM> may thus send identifying information for only the VNF instances that are instantiated at the VNFM <NUM> that satisfy the filters. The one or more filters may be any combination of the filters described above in respect of <FIG>.

The request may be received in one or more messages. For example, the VNFM <NUM> may receive a first message from the NFVO <NUM> requesting that the VNFM <NUM> identify one or more VNF instances that are instantiated at the VNFM <NUM> and a second message indicating one or more filters to be used by the VNFM <NUM>.

In particular aspects, the at least one VNF instance may have been instantiated at the VNFM <NUM> before the VNFM <NUM> received the request from the NFVO <NUM>. Thus, the VNFM may only identify VNF instances to the NFVO <NUM> that were instantiated at the VNFM <NUM> before the VNFM <NUM> received the request to identify one or more VNF instances.

In other aspects, the at least one VNF instance may have been instantiated at the VNFM <NUM> before the NFVO <NUM> registered at the VNFM <NUM>. The VNFM <NUM> may send identifying information for at least one VNF instance that had already been instantiated at the VNFM before the VNFM <NUM> registered the NFVO <NUM>. For example, the at least one VNF instance may have been instantiated at the VNFM <NUM> before the NFVO <NUM> was deployed and the VNFM <NUM> may only inform the NFVO <NUM> of VNF instances that were instantiated at the VNFM <NUM> before the NFVO <NUM> was deployed.

The method <NUM> may further comprise sending identifying information for a further VNF instance to the NFVO <NUM> in response to the further VNF instance being instantiated at the VNFM <NUM>. The VNFM <NUM> may thus send identifying information, to the NFVO <NUM>, for any newly instantiated VNF instantiated VNF instances as they are instantiated at the NFVO <NUM>. For example, the VNFM <NUM> may receive a subscription request from the NFVO <NUM>, requesting that the VNFM <NUM> sends identifying information whenever a new VNF instance is instantiated at the VNFM <NUM>. The subscription request may, for example, be comprised in the request described above.

Aspects of the disclosure therefore provide methods for identifying, to an NFVO, an instance of a VNF that has already been instantiated at a VNFM. The skilled person will appreciate that the foregoing methods may, for example, form part of a registration process. For example, a registration process may be performed at or between the NFVO <NUM> and the VNFM <NUM> and one or more of the steps of the methods <NUM> and <NUM> may be performed as part of that process. Alternatively, one or more of the foregoing methods <NUM> and <NUM> may be performed in response to completion of a registration process between the NFVO <NUM> and the VNFM <NUM>.

<FIG> shows a schematic diagram of an NFVO <NUM> according to embodiments of the disclosure. The NFVO <NUM> may be configured to perform the method <NUM> of <FIG>. The NFVO <NUM> may be, for example, the NFVO <NUM> described above in respect of <FIG>.

The NFVO <NUM> comprises processing circuitry (or logic) <NUM>. The processing circuitry <NUM> controls the operation of the NFVO <NUM> and can implement the method <NUM> described above with respect to <FIG>, for example. The processing circuitry <NUM> can comprise one or more processors, processing units, multi-core processors or modules that are configured or programmed to control the NFVO in the manner described herein.

In particular implementations, the processing circuitry <NUM> can comprise a plurality of software and/or hardware modules that are each configured to perform, or are for performing, individual or multiple steps of the method described herein in relation to the NFVO <NUM>.

Briefly, the processing circuitry <NUM> of the NFVO <NUM> is operable to: receive, from a VNFM identifying information for at least one VNF instance instantiated at the VNFM, wherein the NFVO is operable to: receive the identifying information from the VNFM in response to registration of one of the NFVO and the VNFM at the other of the NFVO and the VNFM; and create a record at the NFVO for the at least one VNF instance identified by the VNFM.

Optionally, the NFVO <NUM> may comprise a machine-readable storage medium (e.g. a memory) <NUM>. In some examples, the memory <NUM> of the NFVO <NUM> can be configured to store instructions (e.g. program code) that can be executed by the processing circuitry <NUM> of the NFVO <NUM> to perform the method described herein in relation to the NFVO <NUM>. Alternatively or in addition, the memory <NUM> of the NFVO <NUM>, can be configured to store any requests, resources, information, data, signals, or similar that are described herein. The processing circuitry <NUM> of the NFVO <NUM> may be configured to control the memory <NUM> of the NFVO <NUM> to store any requests, resources, information, data, signals, or similar that are described herein.

In some examples, the NFVO <NUM> may optionally comprise a communications interface <NUM>. The communications interface <NUM> of the NFVO <NUM> can be for use in communicating with other nodes, such as other virtual nodes. For example, the communications interface <NUM> of the NFVO <NUM> can be configured to transmit to and/or receive from other nodes requests, resources, information, data, signals, or similar. The processing circuitry <NUM> of the NFVO <NUM> may be configured to control the communications interface <NUM> of the NFVO <NUM> to transmit to and/or receive from other nodes requests, resources, information, data, signals, or similar.

<FIG> shows a schematic diagram of a VNFM <NUM> according to embodiments of the disclosure. The VNFM <NUM> may be configured to perform the method <NUM> of <FIG>. The VNFM <NUM> may be, for example, the VNFM <NUM> described above in respect of <FIG>.

The VNFM <NUM> comprises processing circuitry (or logic) <NUM>. The processing circuitry <NUM> controls the operation of the VNFM <NUM> and can implement the method <NUM> described above with respect to <FIG>, for example. The processing circuitry <NUM> can comprise one or more processors, processing units, multi-core processors or modules that are configured or programmed to control the VNFM in the manner described herein. In particular implementations, the processing circuitry <NUM> can comprise a plurality of software and/or hardware modules that are each configured to perform, or are for performing, individual or multiple steps of the method described herein in relation to the VNFM <NUM>.

Briefly, the processing circuitry <NUM> of the VNFM <NUM> is operable to: send, to an NFVO identifying information for at least one VNF instance instantiated at the VNFM in response to registration of one of the NFVO and the VNFM at the other of the NFVO and the VNFM.

Optionally, the VNFM <NUM> may comprise a machine-readable storage medium (e.g. a memory) <NUM>. In some examples, the memory <NUM> of the VNFM <NUM> can be configured to store instructions (e.g. program code) that can be executed by the processing circuitry <NUM> of the VNFM <NUM> to perform the method described herein in relation to the VNFM <NUM>. Alternatively or in addition, the memory <NUM> of the VNFM <NUM>, can be configured to store any requests, resources, information, data, signals, or similar that are described herein. The processing circuitry <NUM> of the VNFM <NUM> may be configured to control the memory <NUM> of the VNFM <NUM> to store any requests, resources, information, data, signals, or similar that are described herein.

In some examples, the VNFM <NUM> may optionally comprise a communications interface <NUM>. The communications interface <NUM> of the VNFM <NUM> can be for use in communicating with other nodes, such as other virtual nodes. For example, the communications interface <NUM> of the VNFM <NUM> can be configured to transmit to and/or receive from other nodes requests, resources, information, data, signals, or similar. The processing circuitry <NUM> of the VNFM <NUM> may be configured to control the communications interface <NUM> of the VNFM <NUM> to transmit to and/or receive from other nodes requests, resources, information, data, signals, or similar.

By way of example, in the embodiments illustrated in <FIG> and <FIG> the interfaces <NUM>/<NUM>, the processor(s) <NUM>/<NUM>, and the memory <NUM>/<NUM> may be connected in series. Alternatively, these components <NUM>/<NUM>, <NUM>/<NUM> and <NUM>/<NUM> may be coupled to an internal bus system. The memory <NUM>/<NUM> 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. The memory, <NUM>/<NUM>, may include software and/or control parameters. The memory, <NUM>/<NUM>, may include suitably configured program code to be executed by the processor(s), <NUM>/<NUM>, so as to implement the above-described method.

Claim 1:
A method performed by a Network Functions Virtualisation Orchestrator, NFVO, (<NUM>) the method comprising:
sending, in response to registering a Virtual Network Function Manager, VNFM, (<NUM>) at the NFVO (<NUM>), a request to the VNFM to identify one or more Virtual Network Function, VNF, instances that are instantiated at the VNFM before the request was received by the VNFM (<NUM>);
receiving (<NUM>), from the VNFM identifying information for at least one Virtual Network Function, VNF, instance instantiated at the VNFM, wherein the identifying information is received from the VNFM in response to the VNFM receiving the request from the NFVO; and
creating a record (<NUM>) at the NFVO for the at least one VNF instance identified by the VNFM.