Login| Sign Up| Help| Contact|

Patent Searching and Data


Title:
METHOD AND ENTITIES FOR HANDLING IDENTIFICATION OF AN NFVO
Document Type and Number:
WIPO Patent Application WO/2020/100147
Kind Code:
A1
Abstract:
The embodiments herein relate to a method performed by a VNFM (101) for handling identification of a NFVO (103). The VNFM (101) receives a registration request from the NFVO (103). The registration request comprises a NFVO address. If the NFVO (103) is not already registered with the VNFM (101), the VNFM (101) registers the NFVO (103) by generating a NFVO ID based on the NFVO address. The VNFM (101) sends a registration response to the NFVO (103). The registration response comprises the NFVO ID.

Inventors:
TADEPALLI RAGHAVENDRA RAO (IN)
TANDON RISHI (IN)
Application Number:
PCT/IN2018/050730
Publication Date:
May 22, 2020
Filing Date:
November 12, 2018
Export Citation:
Click for automatic bibliography generation   Help
Assignee:
ERICSSON TELEFON AB L M (SE)
TADEPALLI RAGHAVENDRA RAO (IN)
International Classes:
G06F9/44; G06Q10/00
Foreign References:
US20180191580A12018-07-05
Other References:
ANONYMOUS: "Network Functions Virtualisation (NFV); Management and Orchestration; Or-Vnfm reference point - Interface and Information Model Specification", ETSI GS NFV-IFA 007 V2.1.1, 1 October 2016 (2016-10-01), pages 1 - 130, XP055707415
ANONYMOUS: "Network Functions Virtualisation (NFV); Management and Orchestration; Report on Architectural Options", ETSI GS NFV-IFA 009 VI.1.1, 1 July 2016 (2016-07-01), pages 1 - 31, XP055707426
ANONYMOUS: "Network Functions Virtualisation (NFV) Release 3; Management and Orchestration; Ve-Vnfm reference point - Interface and Information Model Specification", ETSI GS NFV-IFA 008 V3.1.1, 1 August 2018 (2018-08-01), pages 1 - 133, XP055707430
Attorney, Agent or Firm:
SINGH, Manisha (IN)
Download PDF:
Claims:
CLAIMS:

1. A method performed by a Virtualised Network Function Manager, VNFM, (101), for handling identification of a Network Functions Virtualisation Orchestrator, NFVO, (103), the method comprising:

receiving (201, 701) a registration request from the NFVO (103), wherein the registration request comprises a NFVO address;

if the NFVO (103) is not already registered with the VNFM (101), registering (203, 703) the NFVO (103) by generating a NFVO identifier, ID, based on the NFVO address; and

sending (204, 704) a registration response to the NFVO (103), wherein the registration response comprises the NFVO ID.

2. The method according to claim 1, further comprising:

checking (202, 702) if the NFVO (103) is already registered with the VNFM

(101).

3. The method according to either of the preceding claims, further comprising:

creating (303, 705) an association between the NFVO ID and a Virtual Network Function, VNF, (100) which the NFVO (103) orchestrates.

4. The method according to claim 3, further comprising:

when the NFVO (103) has been registered, receiving (401, 501c, 706), from the NFVO (103), a request for or a trigger of a VNF Lifecycle Management, VNF LCM, operation for the VNF (100), wherein the request comprises the NFVO ID;

deriving (402, 502, 707), from the created association, that the NFVO (103) is orchestrating the VNF (100); and

directing (403, 503, 708) the LCM operation towards NFVO (103) orchestrating the VNF (100).

5. The method according to any of the preceding claims, wherein the registration request is received from each of a plurality of NFVOs (103), and wherein the NFVO ID is generated for each of the NFVOs (103) of the plurality and sent to the respective NFVO (103).

6. The method according to any of the preceding claims, wherein the registration request further comprises information associated with capabilities of the NFVO (103), and wherein the information associated with capabilities of the NFVO (103) comprises: a list of the capabilities or an end point (108) at which the capabilities are accessible.

7. The method according to any of the preceding claims, wherein the registration response comprises information associated with capabilities of the VNFM (101), and

wherein the information associated with capabilities of the VNFM (101) comprises: a list of the capabilities or an end point (108) at which the capabilities are accessible.

8. A method performed by a Network Functions Virtualisation Orchestrator, NFVO, (103) for handling identification of the NFVO, the method comprising:

sending (201, 801) a registration request to a Virtualised Network Function Manager, VNFM, (101), wherein the registration request comprises a NFVO address; and receiving (204, 802) a registration response from the VNFM (101), wherein the registration response comprises a NFVO identifier, ID, generated by the VNFM (101) based on the NFVO address.

9. The method according to claim 8, further comprising:

when the NFVO (103) has been registered, transmitting (401, 501c, 803), to the VNFM (101), a request for or a trigger of a VNF Lifecycle Management, VNF LCM, operation for the VNF (100), wherein the request comprises the NFVO ID.

10. The method according to any of claims 8-9, wherein the registration request further comprises information associated with capabilities of the NFVO (103), and

wherein the information associated with capabilities of the NFVO (103) comprises: a list of the capabilities or an end point (108) at which the capabilities are accessible.

11. The method according to any of claims 8-10, wherein the registration response comprises information associated with capabilities of the VNFM (101), and

wherein the information associated with capabilities of the VNFM (101) comprises: a list of the capabilities or an end point (108) at which the capabilities are accessible.

12. A Virtualised Network Function Manager, VNFM, (101) adapted to: receive a registration request from a Network Functions Virtualisation Orchestrator, NFVO, (103), wherein the registration request comprises a FVO address;

if the NFVO (103) is not already registered with the VNFM (101), register the NFVO (103) by generating a NFVO identifier, ID, based on the NFVO address; and to

send a registration response to the NFVO (103), wherein the registration response comprises the NFVO ID.

13. The VNFM (101) according to claim 12, being further adapted to:

check if the NFVO (103) is already registered with the VNFM (101).

14. The VNFM (101) according to of claims 12-13, being further adapted to:

create an association between the NFVO ID and a Virtual Network Function, VNF, (100) which the NFVO (103) orchestrates.

15. The VNFM (101) according to claim 14, being further adapted to:

when the NFVO (103) has been registered, receive, from the NFVO (103), a request for or a trigger of a VNF Lifecycle Management, VNF LCM, operation for the VNF (100), wherein the request comprises the NFVO ID;

derive, from the created association, that the NFVO (103) is orchestrating the VNF (100); and to

direct the LCM operation towards NFVO (103) orchestrating the VNF (100).

16. The VNFM (101) according to any claims 12-15, wherein the registration request is received from each of a plurality of NFVOs (103), and wherein the NFVO ID is generated for each of the NFVOs (103) of the plurality and sent to the respective NFVO (103).

17. A Network Functions Virtualisation Orchestrator, NFVO, (103) adapted to:

send a registration request to a Virtualised Network Function Manager, VNFM, (101), wherein the registration request comprises a NFVO address; and to

receive a registration response from the VNFM (101), wherein the registration response comprises a NFVO identifier, ID, generated by the VNFM (101) based on the NFVO address.

18. The NFVO (103) according to claim 17, being further adapted to: when the NFVO (103) has been registered, transmit, to the VNFM (101), a request for or a trigger of a VNF Lifecycle Management, VNF LCM, operation for the VNF (100), wherein the request comprises the NFVO ID. 19. A computer program comprising instructions which, when executed on at least one processor, cause the at least one processor to carry out the method according to any one of claims 1-7.

20. A carrier comprising the computer program of claim 19, wherein the carrier is one of an electronic signal, optical signal, radio signal or computer readable storage medium.

21. A computer program comprising instructions which, when executed on at least one processor, cause the at least one processor to carry out the method according to any one of claims 8-11.

22. A carrier comprising the computer program of claim 21, wherein the carrier is one of an electronic signal, optical signal, radio signal or computer readable storage medium.

Description:
METHOD AND ENTITIES FOR HANDLING IDENTIFICATION OF AN NFVO TECHNICAL FIELD

Embodiments herein relate generally to a Virtualised Network Function Manager (VNFM), a method performed by the VNFM, a Network Functions Virtualisation Orchestrator (NFVO) and a method performed by the NFVO. More particularly the embodiments herein relate to handling identification of an NFVO.

BACKGROUND

Network Functions Virtualization (NFV) is a network architecture where network services which are traditionally run on proprietary, dedicated hardware are instead virtualized.

The European Telecommunications Standards Institute (ETSI) NFV Industry Specification Group (ISG) has defined a reference architecture for NFV. Fig. la shows an example of the NFV reference architecture. As seen in fig. la, the NFV reference architecture comprises the following three main parts:

NFV Management and Orchestration (MANO)

Virtualised Network Function (VNFs) 100

Network functions virtualization infrastructure (NFVI)

As seen in fig. la, the MANO comprises a VNFM 101, a NFVO 103 and a Virtualized Infrastructure Manager(s) 104. There may be one or multiple instances of the VNFM 101. The ETSI NFV ISG defined MANO system stack identifies the VNFM 101 and the NFVO 103 as well-defined functional components and also defines an integration reference point named“Or-Vnfm” that provides a reference interface between these two functional entities VNFM 101 and NFVO 103 of the MANO system stack. ETSI GS NFV 002 Vl.2.1 (2014-12) defines the NFVO 103 and VNFM 101 as follows:

“The NFV Orchestrator is in charge of the orchestration and management of NFV infrastructure and software resources, and realizing network services on NFVI.

“ A VNF Manager is responsible for VNF lifecycle management (e.g. instantiation, update, query, scaling, termination). Multiple VNF Managers may be deployed; a VNF Manager may be deployed for each VNF, or a VNF Manager may serve multiple VNFs

The virtualized infrastructure manager 104 is adapted to control and manage the interaction of a VNF with computing, storage and network resources under its authority, as well as their virtualisation. One or multiple instances of the Virtualised Infrastructure Managers 104 may be deployed, but on is shown in fig. 1 for the sake of simplicity. Furthermore, the ETSI GS NFV 002 VI.2.1 (2014-12) describes that the Or-Vnfm reference point is used for:

• “ Resource related requests, e.g. authorization, validation, reservation, allocation, by the VNF Manager (s).

• Sending configuration information to the VNF manager, so that the VNF can be configured appropriately to function within the VNF Forwarding Graph in the network service.

• Collecting state information of the VNF necessary for network service lifecycle management

Fig. la shows that Vi-Vnfm is a reference point between the VNFM 101 and the Virtualised Infrastructure Manager 104. Or-Vi is a reference point between the Virtualised Infrastructure Managers 104 and the NFVO 104.

The reference architecture in fig. la shows n number of VNFs 100, where n is any positive integer larger than zero. ETSI GS NFV 002 VI.2.1 (2014-12) defines the VNF 100 as follows:

“A VNF is a virtualisation of a network function in a legacy non-virtualised network. Examples of NFs are 3GPP™ Evolved Packet Core (EPC) [i.2] network elements, e.g. Mobility Management Entity (MME), Serving Gateway (SGW), Packet Data Network Gateway (PGW); elements in a home network, e.g. Residential Gateway (RGW); and conventional network functions, e.g. Dynamic Host Configuration Protocol (DHCP) servers, firewalls, etc.” Ve-Vnfm is a reference point between the VNF 100 and the VNFM 101.

The VNF 101 is adapted to be connected to an Operations Support Systems and Business Support Systems (OSS/BSS) 108, which is the OSS/BSS of an operator. The OSS/BSS 108 is adapted to be connected to the NFVO 103 via an Os-Ma reference point.

The third main part of the NFV architecture is the NFVI which may be described as hardware and software components that build the environment where VNFs 100 are deployed, managed and executed. The NFVI can span several geographical locations. The NFVI and the VNF 100 are adapted to be connected to each other via a Vn-Nf reference point. The NFVI comprises virtual resources such as virtual computing 110, virtual storage 113 and virtual network 115. The NFVI comprises a virtualization layer 118 which abstracts hardware resources 120 and decouples the VNF software from the underlying hardware, thus ensuring a hardware independent lifecycle for the VNFs 100. The virtualization layer 118 is adapted to be connected to the hardware resources 120 via a Vi- Ha reference point. The hardware resources 120 may comprise computing hardware 123, storage hardware 125 and network hardware 128. The NFVI is adapted to be connected to the virtualized infrastructure manager(s) 104 via an Nf-Vi reference point.

The current interfaces assume a singularity of NFVO entity interfacing with a plurality of VNFM 101 entities. In future deployment environments, a plurality of NFVOs 103 can potentially interface with a plurality of VNFM 101 entities. This introduces a fundamental problem of managing the identities of NFVOs 103 across the plurality of VNFMs 101 such that for each VNF Lifecycle Management (LCM) operation the information is shared only between the corresponding NFVO 103 and VNFM.

Therefore, there is a need to at least mitigate or solve this issue.

SUMMARY

An objective of embodiments herein is therefore to obviate at least one of the above disadvantages and to provide improved handling of NFVO identification.

According to a first aspect, the object is achieved by a method performed by a VNFM for handling identification of a NFVO. The VNFM receives a registration request from the NFVO. The registration request comprises a NFVO address. If the NFVO is not already registered with the VNFM, the VNFM registers the NFVO by generating a NFVO ID based on the NFVO address. The VNFM sends a registration response to the NFVO. The registration response comprises the NFVO ID.

According to a second aspect, the object is achieved by a method performed by a NFVO for handling identification of the NFVO. The NFVO sends a registration request to a VNFM. The registration request comprises a NFVO address. The NFVO receives a registration response from the VNFM. The registration response comprises a NFVO ID generated by the VNFM based on the NFVO address.

According to a third aspect, the object is achieved by a VNFM adapted to receive a registration request from a NFVO. The registration request comprises a NFVO address. The VNFM is adapted to, if the NFVO is not already registered with the VNFM, register the NFVO by generating a NFVO ID based on the NFVO address. The VNFM is adapted to send a registration response to the NFVO. The registration response comprises the NFVO ID.

According to a fourth aspect, the object is achieved by a NFVO adapted to send a registration request to a VNFM. The registration request comprises a NFVO address. The NFVO is adapted to receive a registration response from the VNFM. The registration response comprises a NFVO ID generated by the VNFM based on the NFVO address.

Thanks to the NFVO ID generated, by the VNFM, based on the NFVO address, the NFVO can be uniquely identified in the context of the VNFM which has multiple NFVOs registered to it, this improves the handling of NFVO identification.

Embodiments herein afford many advantages, of which a non-exhaustive list of examples follows:

An advantage of the embodiments herein is that the VNFM is able to identify the NFVO initiating a Lifecycle Management operation over the Or-Vnfm interface.

Another advantage of the embodiments herein is that the VNFM can identify the initiating NFVO and send Grant requests only to that specific NFVO.

A further advantage of the embodiments herein is that the VNFM can identify the initiating NFVO and filter the events indicating the VNF Lifecycle Operation Occurrences and Create/Delete VNF Instance Identifiers, and optionally wait for an acknowledgement of such event delivery only from the NFVO that has initiated the Lifecycle Operation.

Another advantage of the embodiments herein is that the VNFM can identify the initiating NFVO and send Virtual Resource Management Requests only to that NFVO when indirect mode is used.

Furthermore, an advantage of the embodiments herein is that the VNFM can identify the VNF owning NFVO and send Grant requests only to that specific NFVO for VNFM initiated Lifecycle Operations, e.g. Auto-Scaling.

Another advantage of the embodiments herein is that the VNFM can discover the Lifecycle Management capabilities supported by the NFVO and the NFVO can discover the Lifecycle Management capabilities supported by VNFM as their respective capabilities are also exchanged in the registration request and response respectively.

The embodiments herein are not limited to the features and advantages mentioned above. A person skilled in the art will recognize additional features and advantages upon reading the following detailed description.

BRIEF DESCRIPTION OF THE DRAWINGS

The embodiments herein will now be further described in more detail by way of example only in the following detailed description by reference to the appended drawings illustrating the embodiments and in which:

Fig. la is a schematic block diagram illustrating an example of an NFV architecture. Fig. lb is a schematic block diagram illustrating an example of an NFV architecture.

Fig. 2 is a signaling diagram illustrating an example of a NFVO registration.

Fig. 3 is a signaling diagram illustrating an example of a create VNF identifier flow.

Figs. 4a-4b are signaling diagrams illustrating an example of a NFVO driven LCM

operation flow.

Figs. 5a-5b are signaling diagrams illustrating an example of a VNFM initiated operations

flow.

Fig. 6 is a signaling diagram illustrating an example of a delete VNF identifier flow.

Fig. 7 is a flow chart illustrating an example of a method performed by a VNFM.

Fig. 8 is a flow chart illustrating an example of a method performed by a NFVO.

Fig. 9 is a schematic block diagram illustrating embodiments of a VNFM.

Fig. 10 is a schematic block diagram illustrating embodiments of a NFVO.

The drawings are not necessarily to scale and the dimensions of certain features may have been exaggerated for the sake of clarity. Emphasis is instead placed upon illustrating the principle of the embodiments herein.

DETAILED DESCRIPTION

The embodiments herein relates to that the NFVO 103 registers with each VNFM 101 as a prerequisite step before initiating any Lifecycle management requests towards the VNFM 101, and the VNFM 101 assigns a unique identification to the NFVO 103. The NFVO 103 sends a unique NFVO address as part of the registration request and the VNFM 101 uses the unique NFVO address to generate the unique NFVO ID for that NFVO 103 within the context of the VNFM and returns the generated unique NFVO ID.

The NFVO 103 uses the VNFM provided unique NFVO ID in all subsequent interactions with the VNFM 101 over the Or-Vnfm interface. This unique NFVO ID may be provided in all subsequent interactions with the VNFM 101 if Or-Vnfm interface is implemented. The NFVO ID may be provided as part of a Hypertext Transfer Protocol (HTTP) header in all subsequent interactions. The term unique should be understood herein to mean that it is guaranteed to be unique within the context of a VNFM 101. The NFVOs 103 that register with the same VNFM 101 will have the same identifier, i.e. each NFVO 103 will have a distinctive, exclusive and unique Identifier within the scope of a VNFM 101.

Fig. lb illustrates an example of a NFV architecture. The architecture exemplified in fig. lb is different from the architecture in fig. la in that it comprises fewer entities and that it comprises a plurality of NFVOs 103 compared to one NFVO 103 in fig. la. However, any of the entities shown in fig. la may also be present in fig. lb, but are not shown here for the sake of simplicity.

Fig. lb illustrates m number of NFVOs 103 and n number of VNFMs 101. m and n are positive integer, and n and m may be the same or different number. Each NFVO 103 is adapted to be connected to one or more VNFMs 101. Each VNFM 101 is adapted to be connected to one or more NFVOs 103. The NFVO 103 and the VNFM 101 are adapted to be connected to each other via the Or-Vnfm reference point. A reference point may also be referred to as an interface. The VNFM 101 is adapted to be connected to p number of VNFs 100, where p is a positive integer.

It should be noted that the communication links in the architecture in fig. lb may be of any suitable kind including either a wired or wireless link. The link may use any suitable protocol depending on type and level of layer (e.g. as indicated by the Open Systems Interconnection (OS I) model) as understood by the person skilled in the art.

The embodiments herein enables a VNFM 101 to integrate with a plurality of NFVOs 103 and identify the source NFVO 103 of every request and thereby ensure that corresponding requests, for example grant for lifecycle management operations, are directed to the correct NFVO 103 in a scenario where there are multiple NFVOs 103.

The embodiments herein require the NFVO 103 to register with each VNFM 101 as a prerequisite step before initiating any Lifecycle management requests towards the VNFM 101. The VNFM 101 assigns a unique identification to the NFVO 103. The NFVO 103 sends a unique NFVO address, as part of the registration request and the VNFM 101 uses the NFVO address to generate the unique NFVO ID for that NFVO 103 within the context of the VNFM 101 and return the generated unique NFVO ID. The NFVO 103 uses the VNFM provided unique NFVO ID in all subsequent interactions with the VNFM 101 over the interface between the NFVO 103 and the VNFM 101, e.g. the“Or-Vnfm” interface. This unique NFVO ID is provided in all subsequent interactions with the VNFM 101 for example if the Or-Vnfm interface is implemented. The NFVO ID may be provided as part of the HTTP header in the subsequent interactions.

Additionally, the embodiments herein applies to scenarios where NFVO 103 is being replaced with different vendor’s NFVO 103 in a phased manner whereby during an interim phase both the NFVOs 103 are active and are orchestrating different network segments or regions.

Some examples methods for handling identification of a NFVO will now be described with reference to figs. 2-6. Fig. 2 illustrates an example method for NFVO registration with a VNFM 101, which method comprises at least one of the following steps to be performed in any suitable order than described below:

Step 201

The NFVO 103 sends a registration request message to the VNFM 101. The registration request is a request for registering the NFVO 103 with the VNFM 101. The registration request comprises a NFVO identification parameter in the context of NFVO 103. This NFVO identification may be referred to as a NFVO address, a first NFVO ID or nfvold. The term NFVO address will be used in the following when referring to this parameter. The address may be a Fully Qualified Domain Name (FQDN) or an IP address.

In addition to the NFVO address, the registration request may comprise NFVO service endpoint details, defined on the Or-Vnfm interface. The VNFM 101 receives the NFVO address and optionally also the NFVO service endpoint details from the NFVO 103. The registration request message may be a post request which is an http method used to send data to a server to create/update a resource.

Resource methods to be used for the method in fig. 2 may be of the post type.

This method creates a new NFVO registration, within the VNFM.

Table 1 below is an example of the registration request message:

Table 1

Table 2 below illustrates example of data types to be introduced in the registration request message:

Table 2

Step 202

The VNFM 101 checks if the NFVO identified with the NFVO address is already registered with it or not. If the NFVO address is already registered, then the VNFM 101 informs the NFVO 103 about this for example by returning an error message such as a HTTP error code of 412 to NFVO. Error code 412 indicates Precondition Failed.

Step 203

If the NFVO 103 is not already registered with the VNFM 101, then the VNFM 101 generates a NFVO ID using the NFVO address provided by the NFVO 103. The NFVO ID is generated within the context of the VNFM 101. The NFVO ID may be referred to as nfvoIdlnVnfm, second NFVO ID etc. The NFVO ID may be used within the context of VNFM 101 to identify each registered NFVO 103. The NFVO ID is a unique identification which identifies the particular NFVO 103. Two NFVOs 103 do not have the same NFVO ID. There is one unique NFVO ID for each NFVO 103 in case of multiple NFVOs 103. Step 204

The VNFM 101 sends a registration response message to the NFVO 103. The registration response message comprises the NFVO ID to the NFVO 103. It may also comprise service endpoints exposed by the VNFM 101 on the Or-Vnfm interface, e.g. links to the endpoints. The registration response message may be in the form of a HTTP 200 OK response code. The HTTP 200 OK response indicates that the request in step 201 has succeeded.

Table 3 below is an example of the registration response message:

Table 3

Table 4 below illustrates example of data types to be introduced in the registration request message:

Table 4

An example of a resource definition, i.e. a Uniform Resource Identifier (URI) may be as follows: {apiRoot}/vnflcm/v 1/registrations.

Fig. 3 illustrates an example method for a Create VNF Identifier Flow, which method comprises at least one of the following steps to be performed in any suitable order than described below:

Step 301

The NFVO 103 sends a create VNFIdentifier request message to the VNFM 101. The request message comprises the NFVO ID. The NFVO ID may be comprised in a HTTP header with this key and the value as the one returned in the registration call.

Step 302

The VNFM 101 checks if the NFVO 103 is already registered with it. If it is not already registered, the VNFM 101 returns an error indicating the same to the NFVO 103. Otherwise, if the NFVO is already registered, it accepts the create VNFIdentifier request message and performs the requested create VNFIdentifier operation.

Step 303

The VNFM 101 executes the create VNFIdentifier operation. The create VNFIdentifier operation comprises that the VNFM 101 generates a unique VNF Identifier. The create VNFIdentifier may also comprise that the VNFM 101 creates and stores a VNFOwningNFVO parameter which is an association between the requesting NFVO 103 and the generated unique VNF Identifier. Step 304

The VNFM 101 sends, to the NFVM 103, a response to the request message in step 301. The response message may be in the form of a HTTP 201 created message. The HTTP 201 Created success status response code indicates that the request in step 301 has succeeded and has led to the creation of the unique VNF Identifier. The created VNF Identifier is comprised in the response message

Step 305

The VNFM 101 sends a VnfldentifierCreationNotification message towards the NFVO 103 identified by the second NFVO ID.

A post condition may be that the VNF instance identifier may be created in the VNFM 101, and the state of the VNF instance may be not_instantiated in the VNFM 101.

Fig. 4a and 4b illustrate an example method for LCM operations initiated by the NFVO 103. A precondition for the method exemplified in figs. 4a and 4b may be that the NFVO 103 has already been registered with the VNFM 101, i.e. fig. 2. A further precondition may be that the VNF ID has been created for the VNFM 101 on which the LCM operation is triggered. The VNF ID may be created using e.g. the create VNFIdentifier operation exemplified in fig. 3. Fig. 4b is a continuation of fig. 4a such that the steps shown in fig. 4a are performed before the steps of fig. 4b. The method exemplified in fig. 4a and 4b comprises at least one of the following steps to be performed in any suitable order than described below:

Step 401

This step is seen in fig. 4a. The NFVO 103 initiates a LCM operation e.g. instantiate, towards the VNFM 101. This may be done by that the NFVO 103 sends a LCM operation request message to the VNFM 101. It may additionally send the NFVO ID to the VNFM 101 when initiating the LCM operation. The NFVO ID may be comprised in a HTTP header.

Step 402

This step is seen in fig. 4a. The VNFM 101 validates if the NFVO 103 identified by the NFVO ID is the owner of the VNF 100 for which the LCM operation is requested. If the NFVO ID is not the owner of the VNF 100, the VNFM 101 may reject the request in step 401 by sending an error message back to the NFVO 103. Else, if the NFVO ID is the owner of the VNF 100, the VNFM 101 may proceed with the LCM operation

Step 403

This step is seen in fig. 4a. The VNFM 101 creates a VNF-LCM operation occurrence resource for this operation. Based on the association generated in the create VNFIdentifier request in fig. 3, the VNFM 101 may direct the "Grant" request in step 405 towards the correct NFVO 103.

Step 404

This step is seen in fig. 4a. The VNFM 101 may send the LCM operation occurrence status messages only to the initiating NFVO 103 if so configured. In other words, the VNFM 101 may send a VNFLcmOperationOccuranceNotification (Starting) message to the NFVO 103 identified by the NFVO ID. The“Starting” parameter in the message indicates that the operation is in starting status when the message is sent.

Step 405

This step is seen in fig. 4a. A granting exchange between the VNFM 101 and the NFVO 103 identified by the NFVO ID takes place.

Step 406

This step is seen in fig. 4a. The VNFM 101 sends a VnfLcmOperationOccuranceNotification (Processing) message towards the NFVO 103 identified by the NFVO ID. The processing parameter in the sent message indicates that the VNFM 101 is in a processing state when sending the message.

Step 407

This step is seen in fig. 4b. The NFVO 103 may send a request message to the VNFM 101. The request message may be a get request message. The get request is used to request data from a specified resource. The get request comprises a VNFLCM Operation Occurrence Identifier (vnfLcmOpOccId), i.e. an identifier of the VNFM LCM operation.

Step 408

This step is seen in fig. 4b. The VNFM 101 may send a response message to the NFVO 103, i.e. a response to the request in step 407. The response message may be in the form of a HTTP 200 OK response code. The HTTP 200 OK response indicates that the request in step 407 has succeeded. The response message may comprise an indication of that the VNF LCM Operation Occurrence is in a processing state.

Steps 407-408 are alternatives to step 410-411. In other words, steps 407-408 are performed or steps 410-411 are performed.

Step 409

This step is seen in fig. 4b. The VNFM 101 may finish the LCM operation initiated by the NFVO 103 initiated in step 401. Step 410

This step is seen in fig. 4b. The VNFM 101 may send a VnfLcmOperationOccuranceNotification (completed) message to the NFVO 103 identified by the NFVO ID. The completed parameter in the sent message indicates that the VNFM 101 is in a completed state when sending the message.

Step 411

This step is seen in fig. 4b. The NFVO 103 may send a request message to the VNFM 101. The request message may be a get request message. The get request is used to request data from a specified resource. The get request comprises a vnfLcmOpOccId.

Step 412

This step is seen in fig. 4b. The VNFM 101 may send a response message to the NFVO 103, i.e. a response to the request in step 411. The response message may be in the form of a 200 OK response code. The 200 OK indicates that the request in step 407 has succeeded. The response message may comprise VnfLcmOpOcc: operation State=completed.

A post precondition of the method in figs. 4a and 4b may be that the VNF instance may be in instantiated state or not_instantiated state depending upon the triggered LCM operation.

Fig.5a and fig. 5b illustrate an example method of a VNFM Initiated LCM Operations Flow. The VNFM initiated LCM operation is either manual, e.g. EM driven flow, or auto-scale/heal. A precondition for the method exemplified in figs. 5a and 5b may be that the VNF instance is in instantiated state. LCM operations such as auto-scaling and/or auto healing may be enabled in the VNFM 101 by the NFVO 103, and the NFVO 103 may be registered with the VNFM 101 as in fig. 2. The auto-scaling and auto healing may triggered manually (step 501b) or automatically (step 501a). The NFVO 103 may also subscribe to Lifecycle Change Notifications. Fig. 5b is a continuation of fig. 5a, i.e. the steps of fig. 5a are performed before the steps of fig. 5b. The method exemplified in figs. 5a and 5b comprises at least one of the following steps to be performed in any suitable order than described below:

Step 501a

This step is seen in fig. 5a. The VNFM 101 initiates an LCM operation based on Fault Management/Performance Management (FM/PM) triggers automatically. Using other words, the VNFM 101 detects a virtual resource FM/PM Key Performance Indicator (KPI) violation condition. Step 501b

This step is seen in fig. 5a. The operator triggers a LCM operation on the VNF 100 from the VNFM 101. The operation is directly triggered from the VNFM 101.

Notification received by the Network Management System/Operations Support System (NMS/OSS) managing the VNF. This system in turn triggers the auto-scaling/auto- healing.

Step 501c

This step is seen in fig. 5a. The VNFM 101 triggers an LCM operation on the

VNF 100.

Step 502

This step is seen in fig. 5a. The VNFM 101 locates the reference to the NFVO 103 which orchestrates the VNF 100 on which the manual or auto LCM operation needs to be triggered. Using other words, the VNFM 101 retrieves the owning NFVO 103 based on the association generated in the create VNFIdentifier request. Then, the VNFM 101 may direct the "Grant" request towards the correct NFVO 103.

Step 503

This step is seen in fig. 5a. This is an optional step. The VNFM 101 may create a VNF-LCM operation occurrence resource for this operation. This may involve the VNFM 101 sending the LCM operation occurrence status messages only to the initiating NFVO 103 if so configured.

Step 504

This step is seen in fig. 5a. The VNFM 101 may send a vnfLcmOperationOccuranceNotification (starting) message towards the NFVO 103 identified by the NFVO ID. The“starting” parameter in the message indicates that the VNFM 101 is in a starting status when the message is sent.

Step 505

This step is seen in fig. 5a. A granting exchange takes place towards the NFVO 103 identified by NFVO ID.

Step 506

This step is seen in fig. 5b. The VNFM 101 may send a

VnfLcmOperationOccuranceNotification (procesing) message towards the NFVO 103 identified by the NFVO ID. The“processing” parameter in the message indicates that the VNFM 101 is in a processing status when the message is sent. Step 507

This step is seen in fig. 5b. This is an optional step. The NFVO 103 may send a GET..../vnf_lcm_op_occs/{vnfLcmOpOccId} message to the VNFM 101.

Step 508

This step is seen in fig. 5b. This step is seen in fig. 5b. The VNFM 101 may send a 200 OK (VnfLcmOpOcc:operationState=processing) message to the NFVO 103.

Step 509

This step is seen in fig. 5b. The VNFM 101 finishes the FCM operation.

Step 510

This step is seen in fig. 5b. The VNFM 101 sends a VnfFcmOperationOccuranceNotification (completed) message towards the NFVO 103 identified by NFVO ID. The“completed” parameter in the message indicates that the VNFM 101 is in a completed status when the message is sent.

Step 511

This step is seen in fig. 5b. This is an optional step. The NFVO 103 sends a GET .../vnf_lcm_op_occs/{vnfLcmOpOccId} message to the VNFM 101.

Step 512

This step is seen in fig. 5b. This is an optional step. The VNFM 101 sends a 200 OK (VnfFcmOpOcc:operationState=completed) message to the NFVO 103.

A post condition for the method illustrated in figs. 5a and 5b is that the VNF instance is in instantiated state, and that the VNF 100 instance has been scaled or healed.

Fig. 6 illustrates an example method for deleting the VNF Identifier. A precondition for the method exemplified in fig.6 is that the resource representing the VNF instance to be deleted needs to be in not_instantiated state. The method exemplified in fig. 6 comprises at least one of the following steps to be performed in any suitable order than described below:

Step 601

The NFVO 103 sends a delete request message to the Individual VNF Instance resource, i.e. the NFVO 103 sends a delete VNF Identifier to the VNFM 101 with an additional header to indicate the NFVO ID. The deleted VNF identifier may be sent in the form of delete .../vnflcm/vl/vnf_instances/{vnflnstanceld} and may comprise the following additional header: NFVO_ID_IN_VNFM - <NFVO ID returned in the registration flow by VNFM>. Step 602

The VNFM 101 validates if the NFVO 103 identified by the NFVO ID is the owner of the VNF 100 for which the delete operation is requested. If not it will reject the request with an error message. Thus, the VNFM 101 validates to see if the NFVO 103 triggering the delete operation is the one which created this VNF Identifier. If not, the delete operation is rejected with appropriate error.

Step 603

If the validation in step 602 confirms that the NFVO 103 is the owner of the VNF 100, then the VNFM 101 deletes the VNF instance resource and the associated VNF instance identifier.

Step 604

The VNFM 101 sends information indicating that the VNF identifier deletion is successful to the NFVO 103 which requested the VNF deletion. The information may be sent as a HTTP 204 No Content response message. The message may have an empty payload body.

Step 605

The VNFM 101 may send to the NFVO 103 a VnfldentiferDeletionNotification to indicate the deletion of the VNF instance resource and the associated VNF instance identifier. The notification may be optionally sent only towards the VNFOwningNFVO instead of to all registered NFVOs 103.

A post condition of the method exemplified in fig. 6 may be that the resource representing the VNF instance has been removed from the list of VNF instance resources. If the VNF instance is not in not_instantiated state, the VNFM 101 rejects the deletion request.

The method for handling identification of a NFVO according to some embodiments will now be described seen from the perspective of the VNFM 101. Fig. 7 is a flowchart describing the present method performed by the VNFM 101 for handling identification of a NFVO 103. The method comprises at least one of the following steps to be performed by the VNFM 101, which steps may be performed in any suitable order than described below:

Step 701

This step corresponds to step 201 in fig. 2. The VNFM 101 receives a registration request from the NFVO 103. The registration request comprises a NFVO address. The NFVO address may comprise a FQDN, an IP address or any other suitable address. The registration request may be received from each of a plurality of NFVOs

103.

The registration request may further comprise information associated with capabilities of the NFVO 103. The information associated with capabilities of the NFVO 103 may comprise: a list of the capabilities or an end point 108 at which the capabilities are accessible.

Step 702

This step corresponds to step 202 in fig. 2. The VNFM 101 may check if the NFVO 103 is already registered with the VNFM 101.

Step 703

This step corresponds to step 203 in fig. 2. If the NFVO 103 is not already registered with the VNFM 101, the VNFM 101 registers the NFVO 103 by generating a NFVO ID based on the NFVO address from step 701.

The NFVO ID may be generated for each of the NFVOs 103 of the plurality of NFVOs 103 and sent to the respective NFVO 103.

Step 704

This step corresponds to step 204 in fig. 2. The VNFM 101 sends a registration response to the NFVO 103. The registration response comprises the NFVO ID.

The registration response may comprise information associated with capabilities of the VNFM 101. The information associated with capabilities of the VNFM 101 may comprise: a list of the capabilities or an end point 108 at which the capabilities are accessible.

Step 705

This step corresponds to step 303 in fig. 3. The VNFM 101 may create an association between the NFVO ID and a VNF 100 which the NFVO 103 orchestrates.

Step 706

This step corresponds to step 401 in fig. 4a and step 501c in fig. 5a. When the NFVO 103 has been registered, the VNFM 101 may receive, from the NFVO 103, a request for or a trigger of a VNF LCM operation for the VNF 100. The request may comprise the NFVO ID.

Step 707

This step corresponds to step 402 in fig. 4a and step 502 in fig. 5a The VNFM 101 may derive, from the created association, that the NFVO 103 is orchestrating the VNF 100. Step 708

This step corresponds to step 403 in fig. 4a and step 503 in fig. 5a. The VNFM 101 may direct the LCM operation towards NFVO 103 orchestrating the VNF 100.

The method for handling identification of a NFVO according to some embodiments will now be described seen from the perspective of the NFVO 103. Fig. 8 is a flowchart describing the present method performed by the NFVO 103 for handling identification of a NFVO 103. The method comprises at least one of the following steps to be performed by the NFVO 103, which steps may be performed in any suitable order than described below:

Step 801

This step corresponds to step 201 in fig. 2. The NFVO 103 sends a registration request to a VNFM 101. The registration request comprises a NFVO address.

The registration request may further comprise information associated with capabilities of the NFVO 103. The information associated with capabilities of the NFVO 103 may comprise: a list of the capabilities or an end point 108 at which the capabilities are accessible.

Step 802

This step corresponds to step 204 in fig. 2. The NFVO 103 receives a registration response from the VNFM. The registration response comprises a NFVO ID generated by the VNFM 101 based on the NFVO address.

The registration response may comprise information associated with capabilities of the VNFM 101. The information associated with capabilities of the VNFM 101 may comprise: a list of the capabilities or an end point 108 at which the capabilities are accessible.

Step 803

This step corresponds to step 401 in fig. 4a and step 501c in fig. 5a. When the NFVO 103 has been registered, the NFVO 103 may transmit, to the VNFM 101, a request for or a trigger of a VNF LCM operation for the VNF 100. The request may comprise the NFVO ID.

In fig. 9, there is shown a VNFM 101 according to the embodiments herein.

The VNFM 101 comprises a an interface IF_VNFM 901, processor PRO_VNFM 903 and a memory, MEM_VNFM 905, in which memory instructions are stored for carrying out the method steps explained above. The VNFM 101 communicates via the interface IF_VNFM 901. The IF_VNFM 901 comprises both an external interface, communicating with a transmitter and receiver, and internal interfaces (not shown). The VNFM 101 is adapted to, e.g. by means of the PRO_VNFM 903, receive a registration request from a NFVO 103. The registration request comprises a FVO address. The registration request may be received from each of a plurality of NFVOs 103. The NFVO ID may be generated for each of the NFVOs 103 of the plurality and sent to the respective NFVO 103. The registration request may further comprise information associated with capabilities of the NFVO 103. The information associated with capabilities of the NFVO 103 may comprise: a list of the capabilities or an end point (108) at which the capabilities are accessible.

The VNFM 101 is adapted to, e.g. by means of the PRO_VNFM 903, if the NFVO 103 is not already registered with the VNFM 101, register the NFVO 103 by generating a NFVO ID based on the NFVO address.

The VNFM 101 is adapted to, e.g. by means of the PRO_VNFM 903, send a registration response to the NFVO 103. The registration response comprises the NFVO ID. The registration response may comprise information associated with capabilities of the VNFM 101. The information associated with capabilities of the VNFM 101 may comprise: a list of the capabilities or an end point 108 at which the capabilities are accessible.

The VNFM lOlmay be adapted to, e.g. by means of the PRO_VNFM 903, check if the NFVO 103 is already registered with the VNFM 101.

The VNFM 101 may be adapted to, e.g. by means of the PRO_VNFM 903, create an association between the NFVO ID and a VNF 100 which the NFVO 103 orchestrates.

The VNFM 101 may be adapted to, e.g. by means of the PRO_VNFM 903, when the NFVO 103 has been registered, receive, from the NFVO 103, a request for or a trigger of a VNF LCM operation for the VNF 100. The request may comprise the NFVO ID.

The VNFM 101 may be adapted to, e.g. by means of the PRO_VNFM 903, derive, from the created association, that the NFVO 103 is orchestrating the VNF 100.

The VNFM 101 may be adapted to, e.g. by means of the PRO_VNFM 903, direct the LCM operation towards NFVO 103 orchestrating the VNF 100.

In fig. 10, there is shown a NFVO 103 according to the embodiments herein. The NFVO 103 comprises a an interface IF_NFVO 1001, processor PRO_NFVO 1003 and a memory, MEM_NF O 1005, in which memory instructions are stored for carrying out the method steps explained above. The NFVO 103 communicates via the interface IF_NFVO 1001. The IF_NFVO 1001 comprises both an external interface, communicating with a transmitter and receiver, and internal interfaces (not shown). The NFVO 103 is adapted to, e.g. by means of the PRO_NFVO 1003, send a registration request to a VNFM 101. The registration request comprises a NFVO address. The registration request may further comprise information associated with capabilities of the NFVO 103. The information associated with capabilities of the NFVO 103 may comprise: a list of the capabilities or an end point 108 at which the capabilities are accessible.

The NFVO 103 is adapted to, e.g. by means of the PRO_NFVO 1003, receive a registration response from the VNFM 101. The registration response comprises a NFVO ID generated by the VNFM 101 based on the NFVO address. The registration response may comprise information associated with capabilities of the VNFM 101. The information associated with capabilities of the VNFM 101 may comprise: a list of the capabilities or an end point 108 at which the capabilities are accessible.

The NFVO 103 may be adapted to, e.g. by means of the PRO_NFVO 1003, when the NFVO 103 has been registered, transmit, to the VNFM 101, a request for or a trigger of a VNF LCM operation for the VNF 100. The request comprises the NFVO ID.

It should be noted that aspects of the embodiments herein may be utilized in connection with various services provided by a server or host computer to or from a user entity.

The above entities are adapted to communicate over known external telecom interfaces or via application programming interfaces (API) as appropriate.

It is noted that the features of the methods described above and in the following, may be implemented in software and carried out on a data processing device or other processing means caused by the execution of program code means such as computer- executable instructions. Here and in the following, the term processing means comprises any circuit and/or device suitably adapted to perform the above functions. In particular, the above term comprises general- or special-purpose programmable microprocessors, Digital Signal Processors (DSP), Application Specific Integrated Circuits (ASIC), Programmable Logic Arrays (PLA), Field Programmable Gate Arrays (FPGA), special purpose electronic circuits, etc., or a combination thereof. For example, the program code means may be loaded in a memory, such as a RAM (Random Access Memory), from a storage medium, such as a read-only memory (ROM) or other non-volatile memory, such as flash memory, or from another device via a suitable data interface, the described features may be implemented by hardwired circuitry instead of software or in combination with software. A computer program or computer program product is provided carrying out the method steps defined above.

Some embodiments described herein may be summarised in the following manner:

The NFVO 103 registers with each VNFM 101 as prerequisite step before initiating any Lifecycle management requests towards the VNFM 101. The NFVO 103 provides a NFVO address of itself that shall remain constant across restarts/upgrades/failure and recovery of the NFVO 103. The NFVO ID assigned by the VNFM 101 may be for example an Internet Protocol (IP) Address, Domain Name Server (DNS) hostname etc.,

The NFVO 103 may also include at least part of the Or-Vnfm interface and access information relevant for communication between VNFM 101 and NFVO 103 as part of the registration request.

The VNFM 101 in response assigns NFVO ID to the NFVO 103.

The VNFM 101 may also store the assigned NFVO ID of the NFVO 103 along with the NFVO address provided by the NFVO 103 in the registration request.

In all subsequent requests to the VNFM 101 the NFVO 103 shall include the NFVO ID provided by the VNFM 101.

The VNFM 101 may maintain a reference of the owning NFVO 103, identified by the NFVO ID provided during registration by the VNFM 101 against each VNF instance that is created on request from the NFVO 103. The term owning NFVO 103 means the NFVO 103 that is responsible for the lifecycle of the VNF 100, precisely the NFVO 103 that has requested the create VNFIdentifier on the Or-Vnfm interface towards the VNFM 101.

For every VNF Lifecycle Management operation while requesting the Grant from the NFVO 103, the VNFM 101 may retrieve the corresponding NFVO 103 from its memory and may only direct the Grant request to the appropriate NFVO 103.

The VNFM may optionally support filtering of VNF Lifecycle Operation Occurrence Notifications only to the owning NFFO 103.

The embodiments herein enable use of a single instance of a specific VNFM 101 from each VNF vendor across multiple market regions of an operator, while there is a plurality of NFVOs 103 for each market region.

The embodiments herein enable phased replacement of a NFVO 103 in scenarios where there is a singularity of NFVOs 103, for example swapping the NFVO function from one vendor to another. During such a transition phase both the NFVOs 103 can still integrate with a single instance of VNFM 101. The embodiments herein enables the VNFM 101 to direct VNF Lifecycle Operation change notifications, Grant requests related to VNFs 101 to the respective NFVO 103 that has instantiated the VNF 100 instead of broadcasting such messages/requests to all NFVOs 103.

The embodiments herein enable the NFVO 103 to discover the service endpoint definitions exposed by the VNFM 101 and vice-versa as part of the registration process, ref. fig. 2. When the NFVO 103 registers with the VNFM 101 based on the method described herein, it would also provide its service endpoint resources and connectivity information as part of the registration request. The VNFM 101 if it accepts the registration request acknowledges the NFVO 103 by providing a unique identifier for the NFVO 103 within the scope of the VNFM 101 and also presents the service endpoint resources provided by the VNFM 101. So the embodiments herein also enable service endpoint resources exchange between the NFVO 103 and VNFM 101. This will ease the process of integrating NFVO 103 and VNFM 101 from different vendors even when there is a singularity of NFVO 103.

If there are proprietary service endpoint resources defined by either NFVO 103 or VNFM 101, then these additional resource definitions (capabilities) would be exchanged during the proposed registration process. So, each NFVO service endpoint resources need not be configured on the VNFM 101 upfront, it will be fetched and stored during the NFVO registration process.

The embodiments herein are not limited to the above described embodiments. Various alternatives, modifications and equivalents may be used. Therefore, the above embodiments should not be taken as limiting the scope of the embodiments, which is defined by the appended claims. A feature from one embodiment may be combined with one or more features of any other embodiment.

It should be emphasized that the term“comprises/comprising” when used in this specification is taken to specify the presence of stated features, integers, steps or components, but does not preclude the presence or addition of one or more other features, integers, steps, components or groups thereof. It should also be noted that the words“a” or “an” preceding an element do not exclude the presence of a plurality of such elements.

The term“configured to” used herein may also be referred to as“arranged to”, “adapted to”,“capable of’ or“operative to”. The term“at least one of A and B” should be understood to mean“only A, only B, or both A and B.”

It should also be emphasised that the steps of the methods defined in the appended claims may, without departing from the embodiments herein, be performed in another order than the order in which they appear in the claims.