Virtual network function and physical network function software upgrades

Abstract

The present disclosure relates to a method and system for upgrading a service instance of a VNF or PNF executed in ONAP. The method includes: when loading an updated VNF or PNF package, creating a new network resource associated with the VNF or PNF package. Adding an upgrade path artifact to the new network resource, the upgrade path artifact including information about which existing network resources can be upgraded to the new network resource. Updating a service template associated with the VNF or PNF package by replacing the existing network resource with the new network resource and by generating an upgrade artifact including an upgrade option indicating which version the service template can be upgraded from. Upgrading the corresponding VNF or PNF service instance by executing an upgrade workflow using the upgrade artifact of the upgraded service template associated with the VNF or PNF service instance.

Description

[0001] Priority Statement Pursuant to 35 U.S.C.S. 119(e) and 37 C.F.R.S. 1.78

[0002] This non-provisional patent application claims priority based on a prior U.S. provisional patent application No. 62 / 859,856 filed on June 11, 2019 in the name of QIANG, and entitled “Virtual Network Function (VNF) and Physical Network Function (PNF) Software Upgrade.” Technical Field

[0003] The present disclosure relates to network service upgrades, and more particularly, to VNF and PNF software upgrades. Background Art

[0004] The Open Network Automation Platform (ONAP) provides a comprehensive platform for real-time, policy-driven orchestration and automation of physical and virtual network functions, which will enable software, networking, information technology (IT), cloud providers and developers to quickly automate new services and support full lifecycle management. By unifying member resources, ONAP will accelerate the development of a vibrant ecosystem around a globally shared network automation architecture and implementation with an open standards focus faster than any one of its own product clouds.

[0005] New fifth generation (5G) use cases require ONAP to support PNF and VNF onboarding and upgrades.

[0006] Several solutions have been discussed, including https: / / wiki.onap.org / display / DW / 5G+-+PNF+Software+Update and https: / / wiki.onap.org / display / DW / Change+Management+Extensions. Summary of the invention

[0007] One problem is that the current ONAP software upgrade procedure does not support service-level lifecycle management (LCM) operations such as upgrades, and also has difficulty supporting service-level schema updates.

[0008] The present disclosure relates to a solution that allows VNF and PNF software upgrades and mode updates with service-level operations. The proposed solution allows upgrading selected network services using ONAP architecture with designed upgrade options.

[0009] A method for upgrading a service instance of a virtual network function (VNF) or a physical network function (PNF) executed in an open network automation platform (ONAP) is provided. The method includes: when an updated VNF package or PNF package is loaded, creating a new network resource associated with the VNF or PNF package. The method includes adding an upgrade path artifact to the new network resource, the upgrade path artifact including information about which existing network resources can be upgraded to the new network resource. The method includes updating the service template by replacing the existing network resources of the service template associated with the VNF or PNF package with the new network resources and generating an upgrade artifact including at least one upgrade option indicating from which at least one version the service template can be upgraded. The method includes upgrading the corresponding VNF or PNF service instance by executing an upgrade workflow using an upgrade artifact of the upgraded service template associated with the VNF or PNF service instance.

[0010] A system for upgrading a service instance of a virtual network function (VNF) or a physical network function (PNF) executed in an open network automation platform (ONAP) is provided, the system comprising a processing circuit and a memory. The memory contains instructions executable by the processing circuit, whereby the system is operable to: create a new network resource associated with the VNF or PNF package when an updated VNF package or PNF package is loaded. The system is operable to add an upgrade path artifact to the new network resource, the upgrade path artifact including information about which existing network resources can be upgraded to the new network resource. The system is operable to update the service template by replacing the existing network resources of the service template associated with the VNF or PNF package with the new network resource and generating an upgrade artifact including at least one upgrade option indicating which at least one version of the service template can be upgraded. The system is operable to upgrade the corresponding VNF or PNF service instance by executing an upgrade workflow using an upgrade artifact of the upgraded service template associated with the VNF or PNF service instance.

[0011] A non-transitory computer-readable medium is provided on which instructions are stored for upgrading a service instance of a virtual network function (VNF) or a physical network function (PNF) executed in an open network automation platform (ONAP). The instructions include: when an updated VNF package or PNF package is loaded, creating a new network resource associated with the VNF or PNF package. The instructions include adding an upgrade path artifact to the new network resource, the upgrade path artifact including information about which existing network resources can be upgraded to the new network resource. The instructions include updating the service template by replacing the existing network resources of the service template associated with the VNF or PNF package with the new network resources and generating an upgrade artifact including at least one upgrade option indicating which at least one version the service template can be upgraded from. The instructions include upgrading the corresponding VNF or PNF service instance by executing an upgrade workflow using an upgrade artifact of the upgraded service template associated with the VNF or PNF service instance.

[0012] The method(s) provided herein bring(s) improvements to the way ONAP is operated. BRIEF DESCRIPTION OF THE DRAWINGS

[0013] Figure 1 is a schematic illustration of an example of service level operation of a PNF software upgrade and mode update procedure.

[0014] Figure 2 is a schematic illustration of a high-level description of a PNF software (SW) upgrade.

[0015] Figure 3 is another schematic illustration of a high level description of a PNF SW upgrade.

[0016] Figure 4 is a schematic illustration of an example Service Orchestration (SO) workflow for a software upgrade.

[0017] Figure 5 is a schematic illustration of an example preparation workflow for a software upgrade.

[0018] Figure 6 It is a schematic illustration of the impact of the application programming interface (API).

[0019] Figure 7 is a schematic illustration of the upgrade procedure to support use case 1 and use case 2.

[0020] Figure 8 is a schematic illustration of a system in which the steps described herein may be performed.

[0021] Fig. 9 is a flow chart of an example method.

[0022] Fig.10is a flow chart of another example method.

[0023] Fig.11 A flow chart of a method for upgrading a service instance of a virtual network function (VNF) or a physical network function (PNF) executed in an Open Network Automation Platform (ONAP). DETAILED DESCRIPTION

[0024] Various features will now be described with reference to the accompanying drawings in order to fully convey the scope of the present disclosure to those skilled in the art.

[0025] Many aspects will be described in terms of a sequence of acts or functions. It will be appreciated that according to some aspects, some functions or acts may be performed by specialized circuits, by program instructions executed by one or more processors, or by a combination of both.

[0026] Additionally, the computer readable carrier or carrier wave may contain a suitable set of computer instructions that will cause the processor to perform the techniques described herein.

[0027] The functions / actions described herein may not be performed in the order recorded in the action sequence, or may be performed simultaneously. In addition, in some diagrams, some blocks, functions or actions may be optional, and may or may not be performed.

[0028] In this disclosure, "upgrade path information", "upgrade options" and "upgrade artifacts" may be used interchangeably. There are two levels of information: resource upgrade paths and service upgrade options. Both are needed to support service-level lifecycle management (LCM) operations. Resource upgrade paths indicate how resources can be upgraded, including from which version. Service upgrade options indicate which of the resources within a template can be upgraded.

[0029] "Upgrade path information" may also be used interchangeably with service "LCM information". LCM information is information containing "upgrade artifacts". "Upgrade artifacts" may be used interchangeably with "LCM metadata". "Upgrade artifacts" are stored in service templates. "Upgrade options" also contain service-level upgrade path information stored in service templates. Both "upgrade artifacts" and "upgrade options" may be stored in a variety of ways such as metadata data, artifact files, etc. The final names of these information, artifacts, options, etc. may vary in versions of ONAP.

[0030] Figure 1 The upgrade procedure in the context of ONAP is shown. After describing how to deploy the first PNF package, there are some new steps in the procedure, which will be described in more detail.

[0031] At step 101, the vendor 5 provides the software image and license 100a to the operator 7, who in turn provides it to the PNF-Secure Shell (SSH) File Transfer Protocol (SFTP) 25, from which it will be possible to retrieve the software image at run time. Then, at step 102, the PNF package A 100b is provided from the vendor 5 to the operator 7.

[0032] The design time phase begins with the operator 7 providing a PNF package to the service design and creation (SDC) 9, which loads the PNF and creates a resource (Resource A) associated with the PNF package A (step 103). The controller design studio (CDS) 11 uploads the blueprint script and adds a repository uniform resource locator (URL) and a user identifier (ID) / password to the loaded PNF (step 104).

[0033] Next, the SDC 9 and CDS 11 associate the implemented CDS blueprint (CBA) with the PNF resource A, i.e., add the blueprint name and version as attributes to the PNF resource A model (step 105). Then, in step 106, the SDC 9 and CDS 11 create a service A with the PNF resource A. As a result of step 106, a service template A 107 is created, which contains the resource A 108 and the service template name and version or revision (in this case, revision 1.0). The service template A 107 is stored in the SDC directory 13.

[0034] The runtime phase begins after the service template A is distributed (step 109) to the virtual infrastructure deployment (VID) 15 or the command line interface (CLI) and service orchestration (SO) 17. At this point, there is an instantiation of service A, including PNF plug and play (PnP) (step 110), and a service instance object A 111 is created. The service instance object A 111 defines: it uses model-version-id 1 and includes an unchanging universal unique identifier (UUID) and a model version UUID, as shown in the PNF instance object 112.

[0035] The upgrade procedure begins after the supplier 5 provides the new software image and license 115a to the operator 7 (at step 116), who in turn provides it to the SFTP 25, from which it will be possible to retrieve the software image at runtime. Then, at step 117, the PNF package B 115b is provided from the supplier 5 to the operator 7.

[0036] The design time phase of a new PNF package B 115b begins with the operator 7 providing the PNF package to the SDC 9, which loads the PNF (step 118).

[0037] When loading an updated PNF or VNF package, in step 1, a new network resource (Resource B) is created. Upon creation, an upgrade path artifact is added to the resource package (Resource B). The upgrade path artifact includes information about which existing network resource models can be upgraded to the new resource model. Figure 1 In the example above, resource A will be upgraded to resource B and the upgrade path artifact will provide the added information at service design time.

[0038] The CDS 11 then uploads the blueprint script and adds the repository URL and user ID / password to the newly loaded PNF (step 119).

[0039] SDC 9 and CDS11 associate CBA with PNF resource B, that is, add the blueprint name sdnc_model_name and version sdnc_model_version as attributes to the PNF resource B model (step 120). These attributes will be used by the upgrade workflow at runtime.

[0040] Then, at step 121, the SDC 9 and CDS 11 update service A by including PNF resource B and excluding PNF resource A. As a result of step 121, service template A 107 is updated and contains resource B 108 and the service template name and version or revision (in this case, revision 1.0). Service template A 107 is stored in the SDC directory 13.

[0041] In step 2, at service design time, in this example, service template A is updated from revision 1.0 to revision 2.0, and resource A is replaced with resource B. When updating a service template, the operator uses the resource upgrade path artifact as a reference and generates an upgrade artifact to be stored in the service template. The upgrade artifact stored in the service template contains upgrade options that indicate how the service template can be upgraded and from which version of the service template it can be upgraded to the current version. The upgrade options will be used at runtime to upgrade the service instance. It is envisioned that in some instances, in order to upgrade a service template to a given revision, it may first be necessary to upgrade it to an intermediate revision. For example, it may be necessary to upgrade a service template from version 2.0 to 3.0 by upgrading from version 2.0 to 2.5 and then from version 2.5 to 3.0.

[0042] The runtime phase begins after the updated service template A is distributed (step 123) to the VID 15 or CLI and SO 17. In step 3, the SO workflow is executed, which will upgrade the service instance based on the upgrade artifact contained in resource B 122. When selecting the target service instance, the operator also selects the allowed upgrade options based on the upgrade artifact in the service template. Once the upgrade option is selected, the service orchestration 17 executes the designed upgrade workflow 124 and updates the service.

[0043] The SO workflow 124 generates a CDS self-service API request 125, which contains the PNF instance ID, and contains the blueprint name and version generated in step 120. With this, the controller / blueprint processor (Software Defined Network Controller (SDNC) 21) executes the blueprint script, including sending (one or more) Netconf requests to the VNF / PNF 23 instance (step 126). At this point, the software image can be retrieved from SFTP 25. When the upgrade is complete, the SO 17 also updates the Active and Available Inventory (AAI) 19 with the active software version (step not shown).

[0044] At this point, the instance of service A is updated to version (or revision) 2. Service instance object A 127 defines: It uses model-version-id 2 and UUID, as shown in PNF instance object 128, indicating that the service instance is model version 2 of service (PNF) instance 1.

[0045] Current Development Status In ONAP, VNF software upgrades are supported by leveraging the Lifecycle Management Application Programming Interface (LCM API) using Ansible and Chef, and by leveraging the “generic” service orchestration building blocks.

[0046] With support from External Management (EM), using only ansible protocol, PNF software upgrades are supported in Casablanca and updated in Dublin. There is a plan to use LCM API with existing service orchestration building blocks. There is impact only on Software Defined Network Controller (SDNC) (no impact on End-to-End (E2E) solutions yet).

[0047] There are three target use cases.

[0048] Use Case 1: Use ONAP for service design and instantiation. Use ONAP to manage VNF / PNF functions such as data collection / event processing. Use ONAP for VNF / PNF LCM operations.

[0049] For this use case, a solution is needed to support VNF / PNF software upgrades and PNF schema updates while considering service-level impact.

[0050] Use Case 2: Use ONAP for service design and instantiation. Use ONAP to manage some VNF / PNF functions such as data collection / event processing. Use external management system for VNF / PNF LCM operations.

[0051] For this use case, a solution is needed to support VNF / PNF mode updates while considering service-level impact.

[0052] Use Case 3: ONAP is used only for PNF software upgrades (e.g., software remediation). ONAP is not used to manage any new features supported by the new software version. For this use case, a solution is needed to support PNF software updates without impacting the PNF models and service templates.

[0053] Reference now Figure 2 and Figure 3 , which show the prerequisites and proposed PNF SW upgrades for Use Case 3.

[0054] PNF software upgrade is an aspect of software management. The purpose of this procedure is to upgrade the software currently running on the PNF to the target software version without affecting the PNF mode and service template.

[0055] The solution for Use Case 3 proposes enhancements and additions to PNF in-place software updates. It leverages vendor specific YANG models to support direct PNF NETCONF interfaces. It enhances the Service Orchestration In-place Software Upgrade workflow with generic Service Orchestration building blocks that can be used for workflow design in design time. It allows the use of Controller Design Studio self-service APIs between Service Orchestration and Controller with support for PNF in-place software upgrades. It enhances virtual infrastructure deployment to demonstrate single PNF in-place software upgrades. It enhances Service Orchestration procedures to support activities and available inventory updates after software upgrade completion.

[0056] refer to Figure 2 , as a prerequisite, ONAP should be ready to use. Service orchestration upgrade workflow should be ready to use. Design a service design with a PNF resource and create a service template (including CDS Blueprint (CBA) association for implementation) and distribute it at runtime. Service instantiation is done including PNF plug and play. With the connection between PNF-ONAP and PNF-Secure Shell File Transfer Protocol (SFTP), the PNF instance is up and running.

[0057] Reference now Figure 3 , Figure 3An upgrade of a PNF instance is shown. In step 1, the vendor 5 delivers a new software image to the operator 7 and stores the software image in the SFTP server 25. In step 2, at VID 15, the operator 7: selects the workflow and PNF instance; provides the target software version; and starts the upgrade procedure. In step 3, the SO 17 executes the workflow: In step 3a, the service orchestration sends (one or more) CDS requests with action identifiers {action name, blueprint name, blueprint version} to the blueprint processor inside the controller (SDNC) 21 using the CDS self-service API. In step 3b, the controller / blueprint processor executes the blueprint script, including sending (one or more) Netconf requests to the VNF / PNF instance 23. In step 3c, when the upgrade is complete, the SO 17 updates the active and available inventory AAI 19 with the active software version.

[0058] Figure 4 An example of a service orchestration workflow for a software upgrade is shown. The workflow includes: pre-check; downloading the software if no software image is available in the PNF; activating the software; and post-checking before the upgrade is completed. If the activation step goes as expected, the PNF runs the new version of the software, otherwise, it runs the old version. If the activation step was previously performed, the PNF runs the new version of the software, otherwise, it runs the old version. Figure 5 If the preparation workflow shown in is followed (where the software image is downloaded before the upgrade), the software image may be available in the PNF.

[0059] Figure 6 The API impact of the software upgrade procedure and the interaction between VID 15 and SO 17 are shown. After the VID retrieves the list of PNF instances from AAI 19, the user selects the PNF instance and retrieves the workflow associated with the PNF instance from the service orchestration. The user can then select the workflow and software version. This triggers the execution of the software upgrade procedure as in Figure 4 The service-level software upgrade workflow described in .

[0060] refer to Figure 7 , Figure 7 The next steps to support use case 1 and use case 2 are shown.

[0061] To support use cases 1 and 2, service-level lifecycle management (LCM) operations should be enabled, including: VNF / PNF software upgrade using updated service templates; VNF / PNF model update using updated service templates; and service template update using multiple resource instances. This should include: updating the design-time service template using the vendor-provided load pack; upgrading the runtime service instance based on the updated service template; and updating the runtime catalog when the software upgrade is complete.

[0062] Some issues to support use cases 1 and 2 include the following. SDC / Modeling should: allow the use of vendor-provided load packs to load requested software versions; support software versions in internal models; and model upgrade path information. VID 15 User Interface (UI) and API should allow service-level operations. Service Orchestration 17 should allow workflow execution at the service level. AAI 19 should: support updating resource model IDs / versions; and support updating service model identifiers (IDs) / versions.

[0063] The following six-step process presents an example of a detailed procedure.

[0064] In step 1, the vendor provides the operator with an upgrade package, which includes a new software image. In step 2, the operator loads the upgrade package and creates or updates the resource at ONAP design time. During this step, the operator also adds upgrade path information to the resource template. The upgrade path information includes: the allowed upgrade paths by which the resource can be upgraded from the (previously) existing resource to the current resource; the expected upgrade procedures; the upgrade script; etc.

[0065] In step 3, the operator updates the existing service template by replacing the existing resources with the newly created or updated resources. In this step, upgrade options are added to the service template. The upgrade options include information about how the old version of the service template can be upgraded to the current version; and what the expected service-level operations are, such as which resources can be upgraded, how the services can be migrated during the upgrade, the resource upgrade sequence indicating which corresponding resources must be upgraded first, upgraded at the same time, or upgraded in a later step, etc. It should be noted that multiple upgrade options may coexist in one service template.

[0066] In step 4, the updated service template is distributed to runtime. In step 5, at runtime, the operator selects the existing service instances to be upgraded, the upgrade options allowed by the service template, and the workflow to be run. The upgrade procedure is then initiated.

[0067] In step 6, when the upgrade procedure is executed, service-level operations are performed according to the selected upgrade options (one or more) defined in the service template. When each upgradeable resource within the service instance is upgraded, the workflow at the resource level is executed according to the upgrade path information defined in the resource template.

[0068] Figure 88 is a schematic block diagram illustrating a virtualization environment 800 in which some functions may be virtualized. Boxes shown with dashed lines may be optional. As used herein, virtualization may be applied to a node (e.g., a virtualized base station or a virtualized radio access node), a network server, or a device (e.g., any type of communication device), and refers to an implementation in which at least a portion of the functionality is implemented as one or more virtual components (e.g., via one or more applications, components, functions, virtual machines, or containers executed on one or more physical processing nodes in one or more networks).

[0069] Some or all of the functionality described herein may be implemented as virtual components executed by one or more virtual machines or containers implemented in one or more virtual environments 800 hosted by one or more of the hardware nodes 830 .

[0070] The functions may be implemented by one or more applications 820 (which may alternatively be referred to as software instances, virtual appliances, network functions, virtual nodes, virtual network functions, etc.) operable to implement the steps of the methods described herein. The applications 820 run in a virtualized environment 800, which provides hardware 830 including processing circuitry 860 and memory 890. The memory 890 contains instructions 895 executable by the processing circuitry 860, whereby the applications 820 are operable to provide any of the related features, benefits, and / or functions disclosed herein.

[0071] The virtualized environment 800 includes a general or special purpose network hardware device 830, which includes a collection of one or more processors or processing circuits 860, which may be commercial off-the-shelf (COTS) processors, specialized application-specific integrated circuits (ASICs), or any other type of processing circuit including digital or analog hardware elements or special purpose processors. Each hardware device may include a memory 890-1, which may be a non-persistent memory for temporarily storing instructions 895 or software executed by the processing circuit 860. Each hardware device may include one or more network interface controllers 870 (NICs), also known as network interface cards, which include physical network interfaces 880. Each hardware device may also include a non-transitory, persistent, machine-readable storage medium 890-2, in which software 895 and / or instructions executable by the processing circuit 860 are stored. The software 895 may include any type of software, including software for instantiating one or more virtualization layers 850 (also known as hypervisors), software for executing virtual machines 840 or containers, and software that allows the functions described herein to be performed.

[0072] A virtual machine 840 or container includes virtual processing, virtual memory, virtual networking or interfaces, and virtual storage devices, and may be run by a corresponding virtualization layer 850 or hypervisor. Different instances of a virtual appliance 820 may be implemented on one or more virtual machines 840 or containers, and may be implemented in different ways.

[0073] During operation, processing circuitry 860 executes software 895 to instantiate a hypervisor or virtualization layer 850, which may sometimes be referred to as a virtual machine monitor (VMM). Virtualization layer 850 may provide a virtual operating platform that appears to virtual machines 840 or containers as networked hardware.

[0074] like Figure 8 As shown, hardware 830 can be an independent network node with common or specific components. Hardware 830 may include antenna 8225, and some functions may be implemented via virtualization. Alternatively, hardware 830 may be part of a larger hardware cluster (e.g., such as in a data center or customer premises equipment (CPE)), where many hardware nodes work together and are managed via management and orchestration (MANO) 8100, which, among other things, oversees lifecycle management of application 820.

[0075] One or more radio units 8200 may be coupled to one or more antennas 8225, each radio unit 8200 including one or more transmitters 8220 and one or more receivers 8210. The radio unit 8200 may communicate directly with the hardware node 830 via one or more appropriate network interfaces, and may be used in combination with virtual components to provide a virtual node with radio capabilities, such as a radio access node or base station.

[0076] Some signaling may be performed using a control system 8230 , which may alternatively be used for communications between the hardware node 830 and the radio unit 8200 .

[0077] exist Fig. 9 In the drawings, functions or actions shown with dashed lines may be optional and may or may not be performed. Fig. 9 A method 900 for upgrading a service instance of a virtual network function (VNF) or a physical network function (PNF) executed in an open network automation platform (ONAP) is shown, the method comprising: executing an upgrade workflow; and updating the service instance.

[0078] There may be additional steps before executing the upgrade workflow. When an updated PNF or VNF package is loaded, a new network resource is created. An upgrade path artifact is added to the associated resource package, where the upgrade path artifact includes information about which existing network resource models can be upgraded to the new resource model. The upgrade path artifact provides additional information used at service design time.

[0079] Still before executing the upgrade workflow, there can be additional steps. At service design time, when a service template is updated, an upgrade artifact stored in the service template is generated using the resource upgrade path artifact as a reference. The upgrade artifact in the service template contains upgrade options that indicate how the service template can be upgraded and will be used at runtime to upgrade the service instance.

[0080] Additional steps may include: at runtime, when selecting a target service instance, selecting allowed upgrade options based on upgrade artifacts in the service template.

[0081] exist Fig.10 In the drawings, functions or actions shown with dashed lines may be optional, or may or may not be performed. Fig.10 A method 1000 for upgrading a service instance of a virtual network function (VNF) or a physical network function (PNF) executed in an open network automation platform (ONAP) is shown. The method includes the following steps: at runtime, distributing a service template; selecting an existing service instance to upgrade, upgrade options allowed by the service template, and a workflow to run; and initiating the upgrade procedure by running the workflow.

[0082] There can be additional steps before executing the upgrade workflow.

[0083] Receive an upgrade package from the vendor that includes a new software image.

[0084] At design time, when an upgrade PNF or VNF package is loaded, a network resource template is created or updated, and an upgrade path is added to the network resource template, wherein the upgrade path includes information about which existing network resource models can be upgraded to the new resource model, and wherein the upgrade path artifact provides additional information used at service design time; or wherein the upgrade path includes: allowed upgrade paths from which resources can be upgraded from (previously) existing resources to current resources; upgrade procedures; upgrade scripts; and the like.

[0085] The method may include: updating a service template by replacing an existing resource template with a network resource template; and adding upgrade options to the service template. The upgrade options may include information about how an old version of the service template can be upgraded to a current version; what the expected service level operation is, such as which resources can be upgraded, how services can be migrated during the upgrade, a resource upgrade sequence indicating the order (sequential or parallel) in which the corresponding resources will be upgraded, etc.

[0086] exist Fig.11 In the drawings, functions or actions shown with dashed lines may be optional and may or may not be performed. Fig.11 A method 1100 for upgrading a service instance of a virtual network function (VNF) or a physical network function (PNF) executed in an open network automation platform (ONAP) is shown. The method includes: when an updated VNF package or PNF package is loaded, creating (step 1102) a new network resource associated with the VNF or PNF package. The method includes adding (step 1103) an upgrade path artifact to the new network resource, the upgrade path artifact including information about which existing network resources can be upgraded to the new network resource. The method includes updating (step 1104) the service template by replacing the existing network resources of the service template associated with the VNF or PNF package with the new network resources and by generating an upgrade artifact including at least one upgrade option indicating from which at least one version the service template can be upgraded. The method includes upgrading (step 1105) the corresponding VNF or PNF service instance by executing an upgrade workflow using the upgrade artifact of the upgraded service template associated with the VNF or PNF service instance.

[0087] The method may further include receiving (step 1101) an upgrade package from a vendor, the upgrade package including a new software image to be used to upgrade the VNF or PNF service instance.

[0088] The upgrade path artifact may further include at least one of the following: an upgrade procedure and an upgrade script. The upgrade option may further include instructions for processing at least one service-level operation. The at least one service-level operation may include one or more of the following: which resources may be upgraded, how services may be migrated during the upgrade, and a resource upgrade sequence indicating the order in which corresponding resources will be upgraded. The order in which corresponding resources will be upgraded may be characterized by sequential or parallel.

[0089] A system for upgrading a service instance of a virtual network function (VNF) or a physical network function (PNF) executed in an open network automation platform (ONAP), such as system 800, is provided, which includes a processing circuit and a memory. The memory contains instructions executable by the processing circuit, whereby the system is operable to: create a new network resource associated with the VNF or PNF package when an updated VNF package or PNF package is loaded. The system is operable to add an upgrade path artifact to the new network resource, the upgrade path artifact including information about which existing network resources can be upgraded to the new network resource. The system is operable to update the service template by replacing the existing network resources of the service template associated with the VNF or PNF package with the new network resources and generating an upgrade artifact including at least one upgrade option indicating which at least one version of the service template can be upgraded. The system is operable to upgrade the corresponding VNF or PNF service instance by executing an upgrade workflow using the upgrade artifact of the upgraded service template associated with the VNF or PNF service instance.

[0090] A non-transitory computer-readable medium, such as a non-transitory storage device 890-2, is provided on which instructions for upgrading a service instance of a virtual network function (VNF) or a physical network function (PNF) executed in an open network automation platform (ONAP) are stored. The instructions include: when an updated VNF package or PNF package is loaded, a new network resource associated with the VNF or PNF package is created. The instructions include adding an upgrade path artifact to the new network resource, the upgrade path artifact including information about which existing network resources can be upgraded to the new network resource. The instructions include updating the service template by replacing the existing network resources of the service template associated with the VNF or PNF package with the new network resources and generating an upgrade artifact including at least one upgrade option indicating which at least one version of the service template can be upgraded from. The instructions include upgrading the corresponding VNF or PNF service instance by executing an upgrade workflow using an upgrade artifact of the upgraded service template associated with the VNF or PNF service instance.

[0091] Modifications will occur to those skilled in the art who have benefited from the teachings presented in the foregoing description and the associated drawings. It will therefore be appreciated that modifications in specific forms, such as those different from those described above, are intended to be included within the scope of the present disclosure. The foregoing description is merely illustrative and should not be considered restrictive in any way. The scope sought is given by the appended claims, not by the foregoing description, and all variations and equivalents falling within the scope of the claims are intended to be included therein. Although specific terms may be employed herein, they are used in a general and descriptive sense only and not for purposes of limitation.

Claims

1. A method for upgrading a service instance of a virtual network function (VNF) or a physical network function (PNF) executed in an Open Network Automation Platform (ONAP), comprising: -When an updated VNF package or PNF package is loaded, a new network resource associated with the VNF or PNF package is created; - adding an upgrade path artifact to the new network resource, the upgrade path artifact comprising information about which existing network resources can be upgraded to the new network resource, and at least one of: an upgrade procedure and an upgrade script; - updating the service template by replacing existing network resources of the service template associated with the VNF or PNF package with the new network resources and by generating an upgrade artifact including at least one upgrade option indicating from which at least one version the service template can be upgraded; as well as -Upgrading the corresponding VNF or PNF service instance by executing the upgrade workflow using the upgrade artifact of the upgraded service template associated with the VNF or PNF service instance.

2. The method as claimed in claim 1 further includes receiving an upgrade package from a supplier, wherein the upgrade package includes a new software image to be used to upgrade the VNF or PNF service instance.

3. The method of claim 1, wherein: The upgrade option further includes instructions for processing at least one service level operation.

4. The method of claim 3, wherein: The at least one service-level operation includes one or more of the following: which resource is upgradeable, how services can be migrated during the upgrade, and a resource upgrade sequence indicating an order in which corresponding resources are to be upgraded.

5. The method of claim 4, wherein: The order in which the corresponding resources are to be upgraded is characterized by being sequential or parallel.

6. A system for upgrading a service instance of a virtual network function (VNF) or a physical network function (PNF) executed in an Open Network Automation Platform (ONAP), the system comprising a processing circuit and a memory containing instructions executable by the processing circuit, whereby the system is operable to: -When an updated VNF package or PNF package is loaded, a new network resource associated with the VNF or PNF package is created; - adding an upgrade path artifact to the new network resource, the upgrade path artifact comprising information about which existing network resources can be upgraded to the new network resource, and at least one of: an upgrade procedure and an upgrade script; - updating the service template by replacing existing network resources of the service template associated with the VNF or PNF package with the new network resources and by generating an upgrade artifact including at least one upgrade option indicating from which at least one version the service template can be upgraded; as well as -Upgrading the corresponding VNF or PNF service instance by executing the upgrade workflow using the upgrade artifact of the upgraded service template associated with the VNF or PNF service instance.

7. A non-transitory computer-readable medium having stored thereon instructions for upgrading a service instance of a virtual network function (VNF) or a physical network function (PNF) executed in an Open Network Automation Platform (ONAP), the instructions comprising: -When an updated VNF package or PNF package is loaded, a new network resource associated with the VNF or PNF package is created; - adding an upgrade path artifact to the new network resource, the upgrade path artifact comprising information about which existing network resources can be upgraded to the new network resource, and at least one of: an upgrade procedure and an upgrade script; - updating the service template by replacing existing network resources of the service template associated with the VNF or PNF package with the new network resources and by generating an upgrade artifact including at least one upgrade option indicating from which at least one version the service template can be upgraded; as well as -Upgrading the corresponding VNF or PNF service instance by executing the upgrade workflow using the upgrade artifact of the upgraded service template associated with the VNF or PNF service instance.

Images