CN108574593B

CN108574593B - 一种nfv网络中许可证的管理系统和管理方法

Info

Publication number: CN108574593B
Application number: CN201710147528.5A
Authority: CN
Inventors: 冯爱娟
Original assignee: Huawei Technologies Co Ltd
Current assignee: Huawei Technologies Co Ltd
Priority date: 2017-03-13
Filing date: 2017-03-13
Publication date: 2019-11-15
Anticipated expiration: 2037-03-13
Also published as: WO2018166398A1; CN108574593A

Abstract

本发明实施例提供了一种NFV网络中许可证的管理方法和系统，通过软件提供商的第一许可证管理服务器与NFV网络范围内部署一个第二许可证管理服务器进行对接，进行了许可证的灵活和自动的管理，NFVO获取第一许可证管理服务器下发的许可证信息描述模板，NFVO根据该模板向第一许可证管理服务器申请许可证，第二许可证管理服务器从第一许可证管理服务器获取所需的许可证，将许可证信息发送给NFVO，实现许可证的灵活的自动管理。

Description

一种NFV网络中许可证的管理系统和管理方法

技术领域

本发明涉及NFV(Network Functions Virtualization，网络功能虚拟化)领域，尤其涉及一种NFV网络中许可证的管理系统。

背景技术

许可证(License)是软件销售的一种方式，按照特性、版本、容量和使用时间等方式对软件的使用进行授权，客户获得软件提供商所承诺的相应权利和License授权证书。

通信运营商中部署的网元，一般是由相应的软件提供商提供，目前一般的网元部署过程中License加载流程为：

1)License申请。设备软件安装人员从运营商处获取License相关参数信息，登陆软件提供商License网站，输入网元信息，要安装网元的ESN(设备序列号，标识运营商的这台设备)，以及网元规格(如用户数、业务处理能力等)，License网站根据这些信息生成License文件。

2)License下载。设备软件安装人员从软件提供商License网站上下载License文件

3)License加载。设备安装人员将下载的License文件加载到设备中，并激活License。

2012年10月13家Top运营商(AT&T、Verizon、VDF、DT、T-Mobile、BT、Telefornica等)发起成立ETSI NFV ISG(NFV：Network Functions Virtualization，网络功能虚拟化)，目标是基于现代化的虚拟化技术，网络设备可以基于通用硬件，如基于标准的大容量Server、存储和以太网，不同软件提供商提供的应用以软件形式，远程自动部署在统一的云虚拟化基础设施上，从而降低成本，提高效率、增加敏捷能力。

NFV ISG定义了参考框架，如图1所示，各实体职责如下：

1)OSS，除传统的管理功能外，针对虚拟化应用与Orchestrator交互完成对网络的操作和维护。

2)Service，VNF and Infrastructure Description：数据仓库，含相关的模板及VNF软件镜像等。

3)NFVO，(NFV Orchestrator，NFV编排器)主要功能是实现运营商域内的NS(Network Service，网络服务，如IMS服务等)生命周期管理(如部署/扩容/缩容/下线等)，以及NFVI(NFV Infrastructure，NFV的基础设施层)资源编排、策略管理等功能；NFVO根据NSD(NS Descriptor，NS信息模型描述模板)分解出对各VNF(Virtual Network Function，虚拟化的网络功能)的需求，配合VNFM(VNF Manager，VNF管理器)实现VNF的部署。

4)VNFM(VNF Manager，VNF管理器)，主要功能是实现VNF的生命周期管理，如部署/扩容/缩容/下线等自动化能力；VNFM根据模板及VNF容量需求，分解出对虚拟机等虚拟资源的需求，与Orchestrator、VIM(Virtualized Infrastructure Manager)配合完成VNF的实例化。

5)VIM，主要功能是实现对整个基础设施层资源(含计算、存储、网络资源)的管理和监控。

NFV网络使网元功能可以运行在各种通用的硬件上，并通过MANO系统，将网元部署过程自动化，运营商可以根据业务需要快速动态地进行扩容和缩容。

在NFV网络中，网元(本申请文件中网元即指VNF，或称VNF网元)的部署同样需要网元的软件提供商提供的软件License。当前部署的一些NFV网络中还是采用传统的License管理方法，即开通某一个VNF网元时，需要由软件提供商的客户服务人员手动从软件提供商的License网站上下载相关的License文件，加载到对应的VNF网元上，实现VNF网元的激活。但传统的License管理方式不够灵活，不能实现自动的License管理。因此，在NFV网络中，需要提供一种更为灵活和自动的License管理方式，提高License管理和使用的效率。

发明内容

有鉴于此，本发明提供了一种NFV网络中License的管理方法和系统，可以使得运营商能够更为灵活的管理和使用License，提高License使用的效率，以满足NFV网络灵活的弹性伸缩和资源调配。

本申请提供了一种在NFV网络中管理License的系统，该系统包括Global LicenseManager201(Global LM)，其为软件提供商的License交付系统，在本文中也可以称为第一许可证管理服务器，还包括Local License Manager202(Local LM)，其为部署在NFV网络范围内、与Global LM对接，用于在NFV网络中进行License管理的节点，在本文中也可以称为第二许可证管理服务器，Local LM可以与多个软件提供商的Global LM进行对接，也可以是专门负责与某一个软件提供商的Global LM进行对接的专用设备，这种情况下，一般该Local LM也是由与其对接的软件提供商提供，则Local LM就可以作为Global LM在运营商网络内的一个License管理代理，实现在运营商网络范围内的License的分发和控制。由于Global LM和Local LM此时为同一个软件提供商提供，两个网元之间的通信安全和信息互信程度更高。

其中，Global LM用于生成许可证信息描述模板(License Descriptor)，并将该License Descriptor下发给NFVO，所述License Descriptor中包括License DescriptorID、VNFD ID以及许可信息选择项，许可信息选择项可以包括运营商在采购License时可以选择一些功能或特性列表等，Global LM还用于向Local LM发送License；

NFVO收到License Descriptor后，根据License Descriptor向Local LM提出License的申请请求，Local LM可以根据NFVO的License申请请求，根据从Global LM处获取到的License，向NFVO发送License信息，以便NFVO根据这些License信息，向VNF网元提供软件的许可。这里的License信息可以为License对应的数量、特性、功能等信息，如果VNF网元需要使用License文件激活的方式，则License信息可以包括License文件的激活码、License的标识或者下载地址等信息，这样VNF可以根据这些信息，获取或下载License文件，并根据激活码激活License。License文件不直接发送给NFVO，更有利于软件提供商对于License文件的控制，避免NFVO获取到完整的License文件。

在本申请中Global LM可以有多种方式将License Descriptor发布给NFVO，例如在和运营商客户签订了订单后，可以根据订单信息，通过Local LM向NFVO发送LicenseDescriptor，也可以在软件提供商向NFV运营商发布VNF Package时，将Global LM生成的License Descriptor一并下发，这样在VNF Package上架过程中，NFVO就可以获得LicenseDescriptor，NFVO可以对License Descriptor进行校验，当校验失败时，NFVO还可以根据License Descriptor ID或VNFD ID向Local LM申请License Descriptor，Local LM再向Global LM申请License Descriptor。

通过VNF Package和License Descriptor一同发布，可以实现VNF Package加载的过程和License申请的过程同步，更便于License申请和NFV加载过程的自动同步，提高License申请的效率。

Local LM向Global LM获取License的时机也较为灵活，例如可以在订单签订后，Global LM根据从订单管理系统接收到的信息，主动向Local LM发送对应的License，也可以在NFVO部署VNF网元的过程中，向Local LM申请License，Local LM再向Global申请获取License。Global LM可以和软件提供商的订单管理系统连接，实现License的自动下发。

在一些情况下，比如Local LM与Global LM通信异常，无法从Global LM获得许可证时，Local LM也可以作为Global LM的代理或者基于Global LM的授权，Local LM在本地生成许可证，并将生成的许可证信息下发给NFVO，以便及时满足VNF网元部署的需要，等Local LM与Global LM的通信恢复后，Local LM向Global LM上报其生成的许可证的情况，Global LM更新其记录的向NFV网络提供的许可证信息，以便进行计费。本申请并不限于通信异常的场景，即便在通信正常的情况下，Local LM也可以作为Global LM的代理或者基于Global LM的授权同样也可以生成许可证。Local LM能够本地生成许可证，有利于该系统更加稳定的提供服务，提高了系统的稳定性和安全性，这样即便Global LM因为某些原因一时服务提供许可证时，Local LM可以代替Global LM生成许可证，保证VNF网元的即时部署。

在触发申请或者释放License的过程中，可以由Local LM订阅VNF LCM的过程，从而触发NFVO申请或释放License，可以由NFVO在VNF LCM过程中，主动来触发进行License的申请和释放。

进一步的，本申请提供的NFV网络中License的管理系统，还可以包括NFVO，NFVO获取License Descriptor，以及申请License的过程之前已经做过描述，进一步的，NFVO可以在收到Global LM发布的License Descriptor后，保存License Descriptor ID与VNFD ID的对应关系，这样，在部署NVF时，就可以根据VNFD ID查找到所需申请的LicenseDescriptor ID，从而根据该License Descriptor ID对应的License Descriptor，完成许可证的申请。通过保存对应关系，提高了查找效率。

此外，在NFVO确定需要申请License时，NFVO可以触发运营商的OSS系统来向软件提供商的订单管理系统采购所需的License。

由于Local LM上拥有NFV网络上整网的License信息，这样NFV网络运营商就可以以Local LM作为网络资源调配的一个指挥中心，根据整网的许可证信息以及网络业务的需要，灵活的进行VNF许可证的申请或者释放，调配许可证资源和分布，另外，NFVO也可以从Local LM上获取NFV网络上整网的License信息，这样NFVO也可以作为网络资源调配的指挥中心，灵活的进行VNF许可证的申请或者释放，调配许可证资源和分布。由于NFVO控制着NFV网元的部署，NFVO对整网的运行情况也较为了解，NFVO更适合于来居中灵活调配License的申请、释放，从而调整VNF的缩容、扩容等。

相应的，本申请也提供了一种NFV网络中License的管理方法，因方法实现的流程与以上提供的系统描述过程基本一致，不再重复描述。

本申请还提供了一种许可证管理服务器，对应于Global LM210，其包括许可证模板和许可证生成单元2011，许可证模板发布单元2013，许可证发放单元2015，许可证模板和许可证生成单元2011可以与软件提供商的订单管理系统相连，根据从软件提供商订单管理系统中获得的客户的订单信息等，生成相应的License Descriptor和License，通过许可证模板发布单元2013将License Descriptor发布给NFVO的许可证模板接收单元2031，通过许可证发放单元2015，将License发送给Local LM的许可证管理单元2023；许可证模板和许可证生成单元2011还可以从Local LM的许可证管理单元2023处接收来自Local LM的License申请，从而生成相应的License，下发给Local LM。

本申请还提供了一种许可证管理服务器，对应Local LM202，包括许可证申请接收单元2021，许可证管理单元2023和许可证发放单元2025，许可证申请接收单元2021用于从NFVO的许可证申请单元2033处获得License申请的请求，然后将该License申请请求发给许可证管理单元2023，许可证管理单元2023负责保存和更新License信息，判断当前可用的License是否可以满足本次申请的需求，如果可以，则将相应的License信息通过许可证发放单元2025发送给NFVO的许可证接收单元2035，如果License不足，可以向NFVO反馈需要采购License的通知消息，NFVO根据所述通知消息，触发NFV网络运营商的OSS系统向软件提供商的订单管理系统购买所需的许可证。

本申请还提供了一种NFVO203，包括许可证模板接收单元2031，许可证申请单元2033，许可证接收单元2035，许可证模板接收单元2031可以从多种渠道获得Global LM发布的License Descriptor，许可证申请单元2033根据许可证模板接收单元2031接收到的License Descriptor，进行License的申请。许可证接收单元2035接收Local LM的许可证发放单元2025发送的License信息。许可证申请单元2033进一步用于保存LicenseDescriptor ID与VNFD ID的对应关系，这样，在部署NVF时，就可以根据VNFD ID查找到所需申请的License Descriptor ID，从而根据该License Descriptor ID对应的LicenseDescriptor，完成许可证的申请。

以上服务器和NFVO的各功能单元更进一步的功能，可参考方法和系统实施例中的描述，不再展开详细说明，本领域技术人员有能力根据本发明实施例提供的方法和系统描述，灵活的实现上述功能单元的具体功能。

本申请还提供了一种计算机程序产品，当该计算机产品被执行时，其用于执行上述所介绍的Global LM、Local LM或者NFVO所执行的方法。

本申请还提供一种计算机可读存储介质，所述计算机可读存储介质中存储有指令，所述指令用于执行上述所介绍的Global LM、Local LM或者NFVO所执行的方法。

本发明实施例通过NFV网络中License的管理方法和系统，实现了在NFV网络中License的灵活和自动的管理和使用，提高了License使用的效率，可以帮助NFV运营商进一步提升网络管理效率，根据整网的License情况，合理规划和使用License，做出网络部署的调整，有利于促进NFV网络的发展。

附图说明

图1是NFV网络的参考架构示意图；

图2是本发明一实施例提供的一种License管理系统架构示意图；

图3是本发明一实施例提供的License管理系统架构及网元内部逻辑单元结构示意图；

图4是本发明一实施例提供的执行Global LM功能的计算机硬件结构图；

图5是本发明一实施例提供的一个License Descriptor上架过程的流程图；

图6是VNF网元实例化过程的流程图；

图7是本发明一实施例提供的由Local LM在VNF实例化过程中触发申请License的流程图；

图8是本发明一实施例提供的Local LM中保存License的状态机示意图；

图9是本发明一实施例提供的License释放的过程示意图；

图10是本发明一实施例提供的由NFVO触发实现License申请或释放的流程示意图；

图11是本发明一实施例提供的根据VNF上报信息进行扩容的过程示意图。

具体实施方式

下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行描述。

如图2所示，为本发明实施例提供的一种License管理的系统，包括GlobalLicense Manager 201(简称Global LM)，Local License Manager202(简称Local LM)两个逻辑功能实体，以及NFVO203。该系统可以进一步包括VNFM 204以及VNF 205两个网元。

Global LM 201，是软件提供商的License交付系统，用于实现License的交付，向运营商发布License Descriptor(许可证信息描述模板)，向Local LM分发License；License Descriptor可以通过Local LM发送给NFVO，也可以在VNF Package上架过程中，通过OSS或者NFVO portal(NFVO门户网站或者人机界面)发送给NFVO；

Local LM 202，部署在VNF网络范围内，作为在运营商网络内管理License的节点，从Global LM处获取运营商购买的License，接收NFVO的License申请，向NFVO发送相应的License信息。Local LM可以与多个软件提供商的Global LM进行对接，也可以是专门负责与某一个软件提供商的Global LM进行对接的专用设备，这种情况下，一般该Local LM也是由与其对接的软件提供商提供，则Local LM就可以作为Global LM在运营商网络内的一个License管理代理，实现在运营商网络范围内的License的分发和控制。由于Global LM和Local LM此时为同一个软件提供商提供，两个网元之间的通信安全和信息互信程度更高。

NFVO 203，用于获取License Descriptor，根据License Descriptor，在部署VNF网元过程中，结合业务需要，向Local LM申请部署VNF网元所需要的License信息，向LocalLM发出License申请需求，并接收Local LM发送的License信息。

License Descriptor是承载License产品信息的信息描述模板，可以看做License的功能清单列表，如表1示例，

表1

License Descriptor中可以包括License Descriptor ID(License Descriptor文件的唯一标识)，软件提供商信息，产品信息，VNFD ID，以及客户可以选择的功能或特性的列表，还可以包括License的使用地域或时间等，这些可供客户选择的功能或特性的列表可统称为许可信息选择项，不同的设备提供商提供的License Descriptor模板格式和许可信息选择项的内容可能会有所不同，例如软件提供商信息和产品信息可以通过其他方式获取，因此在本表单中为可选项。License Descriptor其目的是让运营商可以根据LicenseDescriptor方便的进行License的申请，能够基于License Descriptor快速的生成License的申请需求。License Descriptor类似于NFV中其他模板(如VNFD)的格式，可以采用Tosca、Yang等模型，描述语言可以为XML或者Yaml等。

Global LM201负责生成发布给客户(本申请文件中，客户均指license的采购方，即一般为NFV网络的运营商)的License Descriptor，并将生成的License Descriptor提供给运营商网络内的NFVO。Global LM将License Descriptor下发给NFVO可以有多种方式，例如Global LM可以与软件提供商的订单管理系统连接，根据与客户签订的订单信息，将对应于订单信息的License Descriptor下发给Local LM，然后Local LM将License Descriptor发布给NFVO，也可以为NFVO通过Local LM主动向Global LM申请获取License Descriptor；也可以在软件提供商向运营商发送VNF Package(包括VNF网元的软件包等文件，参见现有标准中的定义)时，将该VNF Package对应所需的License Descriptor一并下发给NFVO，或者由运营商的OSS系统向Global LM申请，Global LM将License Descriptor发送给OSS系统，由OSS系统发送给NFVO，或者由运营商从软件提供商提供的客户支持网站中下载。

NFVO获取到License Descriptor后，NFVO就可以根据License Descriptor来进行License的申请，因此可以将NFVO获取到License Descriptor的过程，称之为License的上架过程。NFVO获取到License Descriptor后，保存License Descriptor，还可以记录License Descriptor中License Descriptor ID与VNFD ID的对应关系，例如将两者的对应关系单独存储在一个单独的表单中，这样在后续VNF实例化的过程中需要申请对应的License时，可以根据需要实例化的VNF对应的VNFD ID，快速查找到对应的LicenseDescriptor ID，从而找到申请License所需的License Descriptor，实现License的快速申请。

为了说明Global LM、Local LM和NFVO的内部处理逻辑，图3进一步呈现了三个设备内部的逻辑单元及其连接关系，以实现上述描述的具体功能。

其中Global LM201包括许可证模板和许可证生成单元2011，许可证模板发布单元2013，许可证发放单元2015，许可证模板和许可证生成单元2011可以与软件提供商的订单管理系统相连，根据从软件提供商订单管理系统中获得的客户的订单信息等，生成相应的License Descriptor和License，通过许可证模板发布单元2013将License Descriptor发布给NFVO的许可证模板接收单元2031(通过VNF Package一并下发，或者通过Local LM的许可证模板转发单元2027)，通过许可证发放单元2015，将License发送给Local LM的许可证管理单元2023；许可证模板和许可证生成单元2011还可以从Local LM的许可证管理单元2023处接收来自Local LM的License申请，从而生成相应的License，下发给Local LM。

Local LM202包括许可证申请接收单元2021，许可证管理单元2023和许可证发放单元2025，许可证申请接收单元2021用于从NFVO的许可证申请单元2033处获得License申请的请求，然后将该License申请请求发给许可证管理单元2023，许可证管理单元2023负责保存和更新License信息，判断当前可用的License是否可以满足本次申请的需求，如果可以，则将相应的License信息(具体内容参见后面流程图中的描述)通过许可证发放单元2025发送给NFVO的许可证接收单元2035；如果License不足，可以向NFVO(许可证申请单元2033)反馈需要采购License的通知消息，NFVO根据所述通知消息，触发NFV网络运营商的OSS系统向软件提供商的订单管理系统购买所需的许可证，或者许可证管理单元2023向Global LM的许可证模板和许可证生成单元2011发送License申请，获得相应的License，或者许可证管理单元2023还可以作为Global LM的代理，或者基于Global LM的授权，生成License，并向Global LM(例如许可证发放单元2015，由许可证发放单元2015来进行License的记录管理)上报生成License的情况。

NFVO203包括许可证模板接收单元2031，许可证申请单元2033，许可证接收单元2035，许可证模板接收单元2031可以从多种渠道获得Global LM发布的LicenseDescriptor，许可证申请单元2033根据许可证模板接收单元2031接收到的LicenseDescriptor，进行License的申请。许可证接收单元2035接收Local LM的许可证发放单元2025发送的License信息。许可证申请单元2033进一步用于保存License Descriptor ID与VNFD ID的对应关系，这样，在部署NVF时，就可以根据VNFD ID查找到所需申请的LicenseDescriptor ID，从而根据该License Descriptor ID对应的License Descriptor，完成许可证的申请。

NFVO203还可以包括许可证接收单元2035，其用于从Local LM(如许可证管理单元2023)处获取整网的License信息，这样NFVO就可以作为网络资源调配的指挥中心，灵活的进行VNF许可证的申请或者释放，调配许可证资源和分布。

需要说明的是，Global LM和Local LM的名字本身并不构成对其技术内涵的限定，只是为了行文的统一和方面。所谓Global LM，可以理解为软件提供商的License系统可以面向全球的运营商客户提供License管理的服务，如果是面向亚洲运营商提供License服务的设备，也可以命名为AsiaLicenseManager，在本文中可将部署在软件提供商侧的License服务器称之为第一许可证管理服务器；Local LM如果是运营商独立建设并对接多个软件提供商的License服务器，也可以称为运营商的License集中管理服务器，在本文中可将部署在运营商网络范围内的与软件提供商的第一许可证管理服务器对接的License服务器统称为第二许可证管理服务器。

本申请文件中Global LM和Local LM介绍的都是实现的逻辑功能，在具体部署时，Global LM可以集成在软件提供商的网站服务器中，也可以与软件提供商的订单管理和计费系统集成在一起，本发明并不做限定；Local LM在NFV网络中可以是独立部署的网元，也可以将Local LM的逻辑功能集成在VNFM中或者NFVO中，或者集成在运营商的OSS系统中。

以上介绍的Global LM、Local LM和NFVO的相关功能可以通过集成电路/IC等硬件形式实现相应的功能，也可以通过计算机软件执行相应的计算机程序实现来。

如图4所示，为执行本发明中Global LM功能的计算机硬件结构，本申请文件仅以Global LM的实现为例，Local LM和NFVO的计算机功能实现也是同样的方式，不同的仅仅是在存储器中存储不同的软件代码，具体软件代码的逻辑单元和功能在上述实施例中均有描述，再次不再重复描述。

计算机设备400包括至少一个处理器401，通信总线402，存储器403以及至少一个通信接口404。

处理器401可以是一个通用中央处理器(central processing unit，CPU)，微处理器，特定应用集成电路(application-specific integrated circuit，ASIC)，或一个或多个用于控制本发明方案程序执行的集成电路。

通信总线402可包括一通路，在上述组件之间传送信息。

通信接口404，使用任何收发器一类的装置，用于与其他设备或通信网络通信，如以太网，无线接入网(radio access network，RAN)，无线局域网(wireless local areanetworks，WLAN)等。

存储器403可以是只读存储器(read-only memory，ROM)或可存储静态信息和指令的其他类型的静态存储设备，随机存取存储器(random access memory，RAM)或者可存储信息和指令的其他类型的动态存储设备，也可以是电可擦可编程只读存储器(electricallyerasable programmable read-only memory，EEPROM)、只读光盘(compact disc read-only memory，CD-ROM)或其他光盘存储、光碟存储(包括压缩光碟、激光碟、光碟、数字通用光碟、蓝光光碟等)、磁盘存储介质或者其他磁存储设备、或者能够用于携带或存储具有指令或数据结构形式的期望的程序代码并能够由计算机存取的任何其他介质，但不限于此。存储器可以是独立存在，通过总线与处理器相连接。存储器也可以和处理器集成在一起。

其中，存储器403用于存储执行本发明方案的应用程序代码，如图中所示其存储有Global LM的三个功能单元对应的逻辑代码，并由处理器401来控制执行。处理器401用于执行存储器403中存储的应用程序代码，从而实现Global LM的逻辑功能。

在具体实现中，作为一种实施例，处理器401可以包括一个或多个CPU，例如图4中的CPU0和CPU1。

在具体实现中，作为一种实施例，计算机设备400可以包括多个处理器，例如图4中的处理器401和处理器408。这些处理器中的每一个可以是一个单核(single-CPU)处理器，也可以是一个多核(multi-CPU)处理器。这里的处理器可以指一个或多个设备、电路、和/或用于处理数据(例如计算机程序指令)的处理核。

在具体实现中，作为一种实施例，计算机设备400还可以包括输出设备405和输入设备406。输出设备405和处理器401通信，可以以多种方式来显示信息。上述的计算机设备400可以是一个通用计算机设备或者是一个专用计算机设备。在具体实现中，计算机设备400可以是台式机、便携式电脑、网络服务器、掌上电脑(personal digital assistant，PDA)、移动手机、平板电脑、无线终端设备、通信设备、嵌入式设备或有图4中类似结构的设备。本发明实施例不限定计算机设备400的类型。

通过以上提供的NFV网络中的License的管理系统，可以使得License的申请和释放自动灵活，NFVO可以在部署VNF网元的过程中自动的完成License的申请，也可以在VNF网元释放时，自动进行License的释放。由于运营商侧在Local LM中具有了全局的License信息的整体视图，NFV网络运营商就可以根据实际的业务需要，进行更为灵活的网络资源调配，License的管理效率大大提高。

以下将结合附图，对License Descriptor的上架、License的申请/扩容以及缩容/释放等具体过程，对本发明实施例提供的License的管理系统和方法做进一步说明。

如图5所示，为一个License Descriptor上架的一个具体过程，包括如下步骤：

501、软件提供商向NFV网络运营商提供VNF Package时，将Global LM生成的License Descriptor打包在VNF Package中一并下发，图中501之步骤仅用来说明GlobalLM是生成License Descriptor，实际将VNF Package发布给运营商有很多种方式，本发明并不限定VNF Package的下发方式，VNF Package中包含有VNFD和License Descriptor。例如，本实施例中可以软件提供商的在线支持系统发给运营商的OSS系统或者NFVO的Portal，或者从软件提供商提供的装有VNF Package的光盘中获取，或者由运营商的OSS系统或者NFVO的Portal从软件提供商提供的在线支持系统或者其他下载VNF Package的网站中获取。

502、客户通过OSS系统或者NFVO的Portal(统称为Sender)将软件提供商发布的License Descriptor上架到NFVO，License Descriptor指令可以采用现有的On-boardVNFPackage指令，在该指令中增加参数标识来标记是License Descriptor的上架请求，并携带License Descriptor信息，或新增上架License Descriptor指令；

503、NFVO对License Descriptor进行校验(许可证模板接收单元2031)，校验的内容包括但不限于：

·是否存在License Descriptor

·License Descriptor中定义的VNFD是否包含在软件包或已经上架到NFVO

·License Descriptor与VNFD中对产品信息的描述是否一致，比如软件

提供商信息、产品信息、产品版本等等

504、当校验成功，NFVO(许可证模板接收单元2031)保存该License Descriptor，并记录该License Descriptor ID与VNFD ID的对应关系，以便在VNF LCM(LifecycleManagement，生命周期管理)过程中根据VNFD ID快速找到所需的License Descriptor，以便进行License申请。

如果校验失败则执行506a及之后的步骤，校验失败的原因可能是VNF Package中没有License Descriptor信息，License Descriptor与VNFD中对产品信息的描述不一致，或者License Descriptor中定义的VNFD不包含在软件包中等情况。

505、NFVO(许可证模板接收单元2031)向Sender返回上架成功的通知响应，其可以为现有的上架VNF Package响应，在该响应中携带参数以指示License Descriptor上架成功，也可以是新增的License Descriptor上架成功响应消息。

506、NFVO通知Local LM已经上架该License Descriptor，在该通知消息中可以携带License Descriptor，也可以只携带License Descriptor ID和/或VNFD ID。至此License Descriptor上架完成。如果Local LM需要校验License Descriptor，可以进一步从Global LM处获取License Descriptor，并以从Global LM处获得的License Descriptor为准保存，参见后续步骤7至步骤12.

506a、NFVO通知Local LMLicense Descriptor校验失败，可以在校验失败通知消息中携带失败原因和VNFD ID。

507、Local LM可以根据VNFD ID向Global LM发起获取License Descriptor请求，在该请求中可以携带运营商标识信息以及VNFD ID信息；

508、Global LM确定是否可以向该运营商发送License Descriptor，例如校验该运营商是否购买了对应的产品，如果可以，则向Local LM发送License Descriptor；

509、Global LM向Local LM返回对应的License Descriptor；

510、Local LM保持License Descriptor信息。

511、Local LM向NFVO返回获取到的License Descriptor；

512、NFVO执行与步骤504中同样的保存License Descriptor的步骤，并在步骤512a中类似步骤505向Sender发送上架VNF Package的响应。

至此，上述实施例描述了通过与VNF Package一同发布License Descriptor，或者由NFVO来触发向Local LM和Global LM获取License Descriptor的过程。通过VNF Package和License Descriptor一同发布，可以实现VNF Package加载的过程和License申请的过程同步，更便于License申请和NFV加载过程的自动同步，提高License申请的效率。

License Descriptor的上架，也可以是由Global LM(许可证模板发布单元2013)将License Descriptor主动发送给Local LM(许可证模板转发单元2027)，例如根据与客户签订的订单主动通过Local LM向NFVO发送License Descriptor，NFVO保存相应的LicenseDescriptor，具体过程和上述流程中508-512是类似的，就不再重复描述。

接来下描述在License Descriptor上架后，License管理的具体过程。

本发明实施例中License的管理和使用，根据不同的场景，可以有多种灵活的方式。总体上来说，是由软件提供商的Global LM将License发送给Local LM，License保存于Local LM，NFVO在需要使用License时，向Local LM提出License申请需求，Local LM再将License信息发给NFVO，实现License的申请下发。当需要释放License时，NFVO通知LocalLM进行License的释放或者去激活。由于NFV网络中，没有专门的硬件设备，软件都是加载在通用硬件构成的虚拟化资源之上，因此，NFV中的License不需要捆绑具体的硬件设备信息，License可以在多个VNF网元之间以共享资源池的方式使用，比如某一个30万用户的特性A对应的License之前加载在VNF1网元之上，VNF1网元释放后，这个License可以再分配给VNF2网元使用。

例如，当软件提供商与运营商客户签订了采购协议后，根据订单中的信息，GlobalLM可以主动向Local LM发送运营商采购的网元对应的License，也可以和上述过程中描述的License Descriptor的发送过程一同发送给客户。例如客户采购了某个网元特性100万用户的License，Global LM主动将100万用户的License发送给Local LM，由Local LM保存这个100万用户的License(可理解为集中采购或者打包采购模式)，在实例化VNF过程中，Local LM可以根据VNF的实际需要，进行License的分发，例如网元VNF1申请使用30万用户的License，Local LM根据这个申请，向NFVO发送可以支持30万用户的License信息，LocalLM更新可用的License为70万用户(100万减30万)。又或者，在实例化VNF过程中，根据本次网元部署的需求，触发Local LM向Global LM申请对应的License，Global再将对应的License通过Local LM下发给NFVO(可以理解为分批采购或随用随付模式)，或者Local LM在本地判断当前的License是否可以满足本次VNF的部署需要，如果不满足，提示NFVO需要申请额外的License，触发NFVO向Global LM申请新的License。当采用分批采购或者随用随附模式的情况下，软件提供商的软件就像Apple应用商店里的软件一样，运营商使用某一个软件，可以由运营商的OSS系统向软件提供商的订单管理系统进行在线的订单申请，在完成付费或根据后付费协议等，订单管理系统通知Global LM将将客户所需的License及时的下发给客户。

License的释放也是类似的，例如可以根据和客户签订的网络规划变更的订单，由Global LM向Local LM下发释放License的通知，Local LM在本地做License的更新，释放相应的License资源。或者NFVO根据对网络负载运行情况的检测，确定可以释放或者缩容VNF网元后，将License释放通知消息发送给Local LM，Local LM进行License的更新，释放License资源。释放License通知消息中可以包括对应的VFND ID、要释放的License的数量和对应的功能、特性等信息。Local LM释放License后，可以通知给Global LM，以便软件提供商根据变化的License使用情况，对运营商的软件使用进行合理的计费。

License的搬迁，就是License释放和License申请过程的结合，将某些VNF网元的License释放后，再分配到其他需要的VNF网元上。

在本发明实施例中，Local LM上具有运营商对于某一个软件提供商的全网License整体视图，如果Local LM对接各个软件提供商的Global LM，则Local LM就具有了多个软件提供商的整体License视图。NFVO也可以从Local LM处获取运营商所购买的整网的License的信息(例如可用的License数量等)，例如定期向Local LM发送许可证查询请求，Local LM定期向NFVO回复最新的许可证使用情况的信息，这样，运营商可以在Local LM或者NFVO上，掌控整网的License信息，从而根据整网的License信息以及网络业务需要对NFV网络部署进行扩容、缩容、释放或者搬迁处理。

举例来说，以中国移动为例，其在中国多个省份都部署有NFV网络，可以有一个或几个集中的NFVO来进行整网的统一License管理。例如以EPC网络服务为例，其在广东省、上海市等各省市部署有EPC网元，假设广东省部署的EPC网元申请的License为满足500万用户的使用需求，上海市的EPC网元申请的License为满足300万用户的使用需求，当上海市因为重大项目需要，或者基于网络动态负载的监控，确定需要从广东省释放License并加载到上海市时，NFVO即可以根据其掌握的整网License的情况，确定从广东省释放100万用户的License，将这100万用户的License转移部署在上海市。当然，License的共享还要受到License本身的地域限制，如果License限制的可共享使用的License范围限制在某一个省内，则这样的License就不能做跨省的共享，即License要在其限制的地域范围内共享。

下面结合具体的应用场景，描述License管理的具体过程。

为了更好地理解在VNF实例化过程中，图6是对实例化过程中的一个具体描述，VFN实例化过程因为现有技术过程，可参考相关的标准文本，如ETSI GS NFV-IFA 007 V2.1.1(2016-10)，以下简称IFA007。

601、NFVO向VNFM发起Create VNF Identifier的请求(参考IFA007 Table7.2.2.2-1)

602、VNFM向NFVO返回vnfInstanceId(参考IFA007 Table 7.2.2.3-1)

603、VNFM向NFVO发送VnfIdentifierCreationNotification的通知(参考IFA007Table8.6.7.3-1)

604、NFVO向VNFM发起Instantiate VNF的请求(参考IFA007 Table 7.2.3.2-1)

605、VNFM向NFVO返回VNF lifecycleOperationOccurrenceId(参考IFA007Table7.2.3.3-1)

606、VNFM根据vnfInstanceId找到对应的vnfdId，进而获取到VNFD，解析实例化VNF所需的资源信息，并向NFVO请求操作和资源的授权(参考IFA007 Table 6.3.2.2-1)

607、NFVO向VNFM返回Grant lifecycle operation response(参考IFA0076.3.2.3)

608、VNFM启动VNF实例化过程；并向NFVO发送VNFLifecycleOperationChangeNotification(参考IFA007 8.6.2.3)

609、VNF实例化完成后，VNFM告知NFVO该VNF的实例化操作完成(参考IFA0078.6.2.3-1)

下面结合图7所示，具体说明一个由Local LM来做License申请(含扩容)触发的应用实例。

701、由Local LM向VNFM订阅VNF LCM状态变化通知，根据当前标准定义，在以下事件发生时，VNFM会向订阅者Local LM发送通知：

·创建VNF实例ID：VNF Identifier创建通知(即步骤601)

·生命周期管理操作(例如实例化、扩容)：VNF的生命周期状态变化通知(含实例ID、开始or完成、生命周期动作“如实例化/扩容/termination”、….)

·删除VNF实例ID：VNF Identifier删除通知

702、VNFM进行VNF实例化(图6所示的过程)或者VNF扩容；

703、根据Local LM的订阅请求，VNFM向Local LM发送生命周期状态变化通知，Local LM可以在收到实例化或者扩容开始或结束的通知时，启动License的处理过程。

在实例化或扩容开始时，申请License可以保证实例化的网元能够获得足够的License资源，避免由于无法获得License而导致实例化或扩容的VNF无法使用；也可以在实例化或扩容结束后再申请License，因为实例化/扩容过程可能失败，在实例化/扩容结束后申请License，可以避免实例化或扩容失败而导致的申请的License不被使用。

704、Local LM向NFVO获取该VNF实例化/扩容所需要的License信息

705、NFVO(许可证模板接收单元2031)根据在实例化/扩容过程中获取的vnfInstanceId(步骤402)得到对应的VNFD ID，再根据VNFD ID，查找之前保存的VNFD ID和得到对应的License Descriptor ID的对应关系，快速查找到对应的License Descriptor，结合业务的需要，确定所需要的功能特性以及使用量，对License Descriptor进行按需适配。

706、NFVO(许可证模板接收单元2031)向Local LM(许可证申请接收单元2021)返回所需的License信息(各种控制项，例如所需申请License的功能特性以及使用量等，在该申请中，需要添加运营商信息)

本实例中，例如申请的License信息如下表2所示：

表2

707、Local LM(许可证管理单元2023)根据NFVO的License需求，确定当前可用的License是否可以满足需求，如果可以满足需求，则直接执行步骤712；

在Local LM中可以通过状态机的方式对License进行动态管理，具体如图8所示，License的状态可以分为激活态和去激活态，去激活态中又进一步分为子状态1和之状态2，子状态1表示License尚未分配给NFV实例，而子状态2则为临时状态，表示已分配给NFV实例，但VNF实例还未完成激活的过程。在子状态2该License不能分配给其他实例，目的是防止在激活过程中，其他VNF实例也来申请。

在步骤707中，Local LM可以检查现有的License库中，在子状态1的License数量是否满足需求，如果满足，则有将此License分配给该实例使用，并将相关License的状态更新到子状态2，进行Step712操作。

如果子状态1中的License数量不能满足需求，则Local LM根据客户已购的License数量，检查现已使用量是否超标，如果没有超标，由Local LM向Global LM触发License申请流程(步骤708)；如果超标，可以告知NFVO，由NFVO来决策是否申请新的License，再通过Local LM向Global LM申请新的License。

一般来说，对于需要使用License文件来激活VNF网元时，可以采用状态机的方式的，对即将分配使用的License文件进行状态精细化管理，防止同一个License文件被两个NFV实例申请使用，而对于License池化的方案，也可以不使用状态机记录的方式进行License的管理，只需要确定当前分配激活的License的总量在可用的License范围内即可，即在Local LM中保存当前可用的License数量，当有VNF网元实例化后，就将使用的License数量进行相应扣减，VNF网元释放后，即将相应的License数量进行增加。

例如如下表3所示，可以在Local LM中记录License使用情况，当前EPCMMEV5.0产品网元的License可使用数量为总用户数100000，特性A为50000，特性B为30000，而本次实例化EPCMMEV5.0所需申请的License为总用户数X，特性A使用量为A1，特性B使用量为B1，如果当前申请的License小于当前可用的License数量，就可以进行License的分配，并在Local LM上扣将相应的License数量，如果本次实例申请超出了可用License范围，就可以通知NFVO申请额外的License。

表3

708、Local LM(许可证管理单元2023)向Global LM(许可证模板和许可证生成单元2011)触发License申请流程。

709、Global LM(许可证模板和许可证生成单元2011)生成的License，根据License控制的方式不同，可以有多种形式。例如对于License池化的方案，生成的License就可以为License许可使用的特性/功能/用户数等许可项信息，这些信息可以通过许可证文件的形式发放，也可以通过其他形式，如附带在消息体参与中来发放。而对于需要通过License文件下发给VNF网元才能实现License激活的License控制方式，Global生成的License可以为授权证书、许可文件、激活码等形式或者其组合，各软件提供商可根据自己的机制，做不同的组合。

对于扩容的情况下，Global LM可以只提供本次新增加的License，也可以将本次新增的License连同历史上分配的License打包在一起，合成一个新的License，释放掉原来的License。

710、Global LM(许可证发放单元2015)向Local LM(许可证管理单元2023)返回License，Global LM一般需要加密传输License，确保信息安全传输。

711、Local LM(许可证管理单元2023)记录新的License信息，更新可用的License的数量等信息。

当Local LM与Global LM连接异常的情况，Local LM无法向Global LM申请新的License，此时Local LM也可以作为Global LM的代理，或者基于之前Global LM的授权，在本地生成License，例如许可证管理单元2023无法向Global LM发送License申请请求，无法从Global LM收到License，则Local LM(许可证管理单元2023)可以生成License，并将License信息通过许可证发放单元2025发送给NFVO。后续，当Local LM与Global LM恢复通信后，Local LM(许可证管理单元2023)向Global LM(许可证模板和许可证生成单元2011)发送其生成的License的情况，例如数量、特性、功能等信息，以便Global LM更新其记录的向NFV网络提供的许可证信息。

712、Local LM(许可证发放单元2025)通知NFVO(许可证接收单元2035)申请到的License信息，以便NFVO可以根据License信息向VNF网元提供软件许可。

对于License池化方案来说，License信息可以包括授权使用的功能、特性以及对应的数量等信息，Local LM可以对从Global LM处收到的License进行一定的加工处理或者转化后，将这些License信息发送给NFVO，在步骤713中，NFVO根据收到的License信息，向VNF发送激活License的消息，通知VNF可以使用的License信息。

如果需要通过License文件来激活VNF，Global LM向Local下发的License即为License文件，License文件中可以包括激活码信息，则此时Local LM向NFVO提供的License信息可以包括激活码以及许可证文件的下载地址(如Local LM的接入地址，如IP地址等)或者许可证文件的标识等信息，则在步骤713中，NFVO向VNF发送的激活License的消息中携带激活码以及许可证文件的下载地址或者许可证文件的标识等，则在步骤714中，VNF网元根据许可证文件的下载地址或者许可证文件的标识等，从Local LM中下载对应的许可证文件，并用获取的激活码激活许可证文件，完成License的激活。

Local LM也可以将许可文件和激活码一起发送给NFVO，则VNF网元就可以直接根据NFVO提供的许可文件和激活码，激活License。

对于License池化方案，不需要为VNF网元提供独立的许可文件，只需要在LocalLM中保存记录License使用的数量信息，并通知NFVO可为VNF网元分配使用的License的信息即可，不需要VFN网元获取具体的License文件，步骤714即可省略，但这样的管理方式，软件提供商对于License的控制就会弱化，由于没有许可文件的限制，VNF网元可以超出限制的License数量工作，此时软件提供商可以通过VNF网元定期上报的使用量的情况，来监控运营商客户是否在规定的License许可范围内使用软件，或者根据超出License数量的使用情况来进行计费的调整。

如果Local LM与VNFM合一部署时，也可由Local LM直接通知VNF实例所需的License信息。

715、Local LM记录License激活信息，该License进入激活态。

716、VNF实例通过VNFM通知NFVO激活信息。

图9为一个License释放的过程示意图，如图9所示，包括：

901、VNFM根据Local LM的订阅(参见701)，当有终止VNF或者缩容VNF事件发生时，向Local LM发送VNF LCM状态变化通知(Terminate VNF或缩容)

902、Local LM向NFVO获取该实例对应的License释放方式

903、NFVO可根据业务需要，确定完全释放License或者仅是去激活License，并将释放或者去激活的License信息通知给Local LM，当去激活时，运营商后续还可以再使用该License。如果是释放VNF网元，则可以携带要释放的VNF网元的实例ID，如果是缩容，则可以携带缩容的VNF网元的实例ID以及减少的License的信息，例如License的数量等；

904、Local LM刷新License状态，如果是去激活License，则Local LM将这些License添加到可用License数量当中，如果用状态机管理，可以将这些License的状态设置为去激活态-子状态1，如果是完全释放License，则在本地释放相应的License资源，并可以通知Global LM，以便与Global LM根据License使用情况进行计费调整。

905、Local LM通知NFVOLicense释放/去激活完成。

906、当License释放时，Local LM向Global LM通知License释放通知。

上述过程中描述的License的申请(含扩容)和释放(含缩容)过程，为Local LM触发，除此之外，也可以由NFVO来触发License的申请和释放。

如下图10所示，为由NFVO触发实现License申请或释放的流程，包括：

1001、NFVO基于VNF的生命周期管理操作，例如实例化、扩容或者释放等，NFVO触发相应的License文件的申请或释放流程；

以实例化为例，可以在如步骤601至步骤609的各个环节中NFVO触发向Local LM申请License文件。可以其中步骤609已经完成了实例化，其他步骤均未完成实例化。NFVO可以在实例化前或者实例化后根据VNF的需要，向Local LM申请相应的License文件。

1002、NFVO结合业务的需要，确定License操作行为，例如申请新的License，执行步骤1003a，或者释放License，执行步骤1003b，向Local LM发送申请License或者释放License的请求。具体过程与步骤705类似。

后续步骤与上述实施例基本一致，主要区别是License申请/扩容或者释放的触发网元主体不同，上面两个实施例为Local LM进行触发License的申请和释放，而本实施例为NFVO触发。由于触发后具体的实现过程与图7和图9实施例中的实现基本一致，不再重复描述。

下面结合图11为例，提供一种根据VNF上报的信息进行扩容的实现过程，包括：

1101、在运行过程中，VNF统计与许可控制项(如特性或功能使用量等)相关的实例业务量的使用情况，根据预先的配置定时、周期性或者在触发门限时向Local LM发送统计信息，例如可以规定超过许可的License使用量的百分比(如90％，100％或者120％等，具体数值的确定取决于软件提供商和运营商之间的策略安排)作为触发门限，统计信息可以包括各种类型的License使用统计，如基于忙时、闲时的统计，基于功能或者特性的使用情况统计，日、周或者月用户数统计等等；

1102、Local LM根据VNF上报的统计信息，确定License的使用是否达到告警阈值或超过上限；

1103、Local LM根据自身的控制策略向NFVO发送告警或者扩容提示，所述控制策略可以为Global LM下发给Local LM，或者配置在Local LM上的，或者有运营商的OSS系统发送给Local LM，例如控制策略可以为检测到连续3周超出了告警阈值或License上限等；

1104、NFVO收到Local LM的告警或者扩容提示后，根据业务需要确定是否扩容，申请额外的License资源，或者根据整网的License视图情况以及业务的整体运行情况，对网络资源进行调整，释放掉一些网络资源利用率低的VNF，将释放掉的License增加到License不足的VNF上。

如果VNF的License使用比例低，Local LM也可以通知给NFVO，这样NFVO就可以根据提示，进行相应的缩容处理。

后续对于License的申请、扩容的过程以及释放、缩容的过程，可参见前述描述，例如图7和图9对应的具体License的申请和释放的过程。

类似于图11中的过程，VNF也可以将运行过程中，向NFVO上报许可控制项的使用情况的统计信息，在NFVO上配置控制策略，由NFVO根据控制策略，确定是否需要申请额外的License进行扩容，或者释放License资源。

应理解，上述实施例中所述的流程图，可以通过计算机程序指令和/或硬件操作来实现。这些计算机程序指令可以被提供给通用计算机、专用计算机的处理器或者其他可编程数据处理装置，从而通过计算机的处理器或者其他可编程数据处理装置执行的所述指令生成用于实现在所述流程图中所指明的功能的装置。

这些计算机程序指令还可以存储在可引导计算机或其他可编程数据处理装置以特定方式运行的计算机可用或计算机可读存储器中，从而存储在计算机可用或计算机可读存储器中的指令产生这样的制品，所述制品包括实现在所述流程图/或框图的一个或多个框中所指明的功能的指令。

所述计算机程序指令还可以被加载到计算机或者其他可编程数据处理装置上，以使在所述计算机或其他可编程数据处理装置上进行一系列操作步骤来产生计算机实现的过程，从而在所述计算机或其他可编程数据处理装置上执行的所述指令提供用于实现在所述流程图和/或框图的一个或多个框中所指明的功能的步骤。

在以上介绍的多个示例性的设计中，本发明实施例所描述的上述功能可以在硬件、软件、固件或这三者的任意组合来实现。如果在软件中实现，这些功能可以存储于电脑可读的媒介上，或以一个或多个指令或代码形式传输于电脑可读的媒介上。电脑可读媒介包括电脑存储媒介和便于使得让电脑程序从一个地方转移到其它地方的通信媒介。存储媒介可以是任何通用或特殊电脑可以接入访问的可用媒体。例如，这样的电脑可读媒体可以包括但不限于RAM、ROM、EEPROM、CD-ROM或其它光盘存储、磁盘存储或其它磁性存储装置，或其它任何可以用于承载或存储以指令或数据结构和其它可被通用或特殊电脑、或通用或特殊处理器读取形式的程序代码的媒介。此外，任何连接都可以被适当地定义为电脑可读媒介，例如，如果软件是从一个网站站点、服务器或其它远程资源通过一个同轴电缆、光纤电脑、双绞线、数字用户线(DSL)或以例如红外、无线和微波等无线方式传输的也被包含在所定义的电脑可读媒介中。所述的碟片(disk)和磁盘(disc)包括压缩磁盘、镭射盘、光盘、DVD、软盘和蓝光光盘，磁盘通常以磁性复制数据，而碟片通常以激光进行光学复制数据。上述的组合也可以包含在电脑可读媒介中。

Claims

1.一种网络功能虚拟化NFV网络中许可证的管理系统，其特征在于，该系统包括第一许可证管理服务器(201)，第二许可证管理服务器(202)，以及NFV编排器NFVO(203)，其中第一许可证管理服务器为软件提供商的许可证管理服务器，第二许可证管理服务器为部署在NFV网络范围内、与第一许可证管理服务器对接的许可证管理服务器，

第一许可证管理服务器用于生成许可证信息描述模板License Descriptor，并将该License Descriptor下发给NFVO，所述License Descriptor中包括License DescriptorID、虚拟化网络功能的描述符VNFD ID以及许可信息选择项，第一许可证管理服务器还用于向第二许可证管理服务器下发许可证；

NFVO，用于获取第一许可证管理服务器下发的License Descriptor，根据该LicenseDescriptor，向第二许可证管理服务器申请部署NFV网元所需要的许可证；NFVO在收到第一许可证管理服务器发布的License Descriptor后，保存License Descriptor ID与虚拟化网络功能的描述符VNFD ID的对应关系；

第二许可证管理服务器，用于接收NFVO的许可证申请请求，根据第一许可证管理服务器下发的许可证，向NFVO发送许可证信息，NFVO根据所述许可证信息为虚拟化的网络功能VNF提供软件使用许可；

其中，第二许可证管理服务器可作为第一许可证管理服务器的代理或者基于第一许可证管理服务器的授权，第二许可证管理服务器在本地生成许可证。

2.根据权利要求1所述的系统，其特征在于，第一许可证管理服务器用于将所述License Descriptor发送给第二许可证管理服务器，第二许可证管理服务器用于将获取到的所述License Descriptor发送给NFVO。

3.根据权利要求1所述的系统，其特征在于，软件提供商在向NFV运营商提供VNFPackage时，将所述第一许可证管理服务器生成的License Descriptor连同VNF Package一并下发，所述NFVO用于在VNF Package上架过程中获取所述License Descriptor。

4.根据权利要求3所述的系统，其特征在于，NFVO用于在收到License Descriptor后，进行License Descriptor校验，如果校验失败，则向第二许可证管理服务器发送通知消息，携带License Descriptor ID或虚拟化网络功能的描述符VNFD ID，

所述第二许可证管理服务器用于根据License Descriptor ID或虚拟化网络功能的描述符VNFD ID，向第一许可证管理服务器申请License Descriptor ID或虚拟化网络功能的描述符VNFD ID所对应的License Descriptor，第一许可证管理服务器用于将LicenseDescriptor发送给第二许可证管理服务器，第二许可证管理服务器再将LicenseDescriptor发送给NFVO。

5.根据权利要求1所述的系统，其特征在于，第一许可证管理服务器还用于与软件提供商的订单管理系统相连，在收到订单管理系统发送的NFV网络运营商的订单采购通知后，根据所述订单信息，向第二许可证管理服务器发送与订单信息对应的许可证。

6.根据权利要求1所述的系统，其特征在于，第二许可证管理服务器用于在接收到NFVO发送的许可证申请请求，确定本地没有可以满足申请需求的许可证后，向第一许可证管理服务器发送许可证申请请求，所述第一许可证管理服务器用于接收到第二许可证管理服务器发送的许可证申请请求后，向第二许可证管理服务器下发许可证。

7.根据权利要求1所述的系统，其特征在于，第二许可证管理服务器用于在接收到NFVO发送的许可证申请请求，确定本地没有可以满足申请需求的许可证后，向NFVO返回需要采购许可证的通知消息，NFVO根据所述通知消息，触发NFV网络运营商的OSS系统向软件提供商的订单管理系统购买所需的许可证；所述第一许可证管理服务器用于在收到所述订单管理系统发送的订单采购通知后，向第二许可证管理服务器发送与订单信息对应的许可证。

8.根据权利要1至7任一项所述的系统，其特征在于，所述第二许可证管理服务器用于订阅VNF生命周期管理LCM状态变化通知，在收到订阅状态变化通知消息后，根据所述VNF状态变化，触发NFVO申请或者释放许可证。

9.根据权利要求1至7任一权利要求所述的系统，其特征在于，第二许可证管理服务器根据整网的许可证信息以及网络业务需要，确定VNF的许可证的申请或释放；或者NFVO从第二许可证管理服务器获取整网的许可证信息，NFVO根据整网的许可证信息以及网络业务需要，确定VNF许可证的申请或释放。

10.根据权利要求1所述的系统，其特征在于，所述第二许可证管理服务器还用于向第一许可证管理服务器上报许可证使用情况，以便软件提供商根据许可证使用情况进行计费。

11.根据权利要求1至7任一权利要求所述的系统，其特征在于，NFVO还用于在VNF缩容或释放时，向第二许可证管理服务器发送许可证释放消息，所述第二许可证管理服务器用于根据所述许可证释放消息，释放或去激活相应的许可证。

12.根据权利要求1至7任一权利要求所述的系统，其特征在于，所述第二许可证管理服务器可以独立部署，也可以集成在NFVO、VNF管理器VNFM或者运营支撑系统OSS系统中。

13.根据权利要求1至7任一权利要求所述的系统，其特征在于，所述第二许可证管理服务器还用于作为第一许可证管理服务器的代理或者基于第一许可证管理服务器的授权，生成许可证，根据生成的许可证，向NFVO发送许可证信息，所述第二许可证管理服务器还用于向第一许可证管理服务器上报生成许可证的情况，所述第一许可证管理服务器在收到第二许可证管理服务器上报的生成许可证的情况后，更新第一许可证管理服务器上记录的向NFV网络提供的许可证信息。

14.一种NFV网络中许可证的管理方法，其特征在于，所述方法应用于包括第一许可证管理服务器(201)，第二许可证管理服务器(202)，以及NFVO构成的许可证的管理系统，其中第一许可证管理服务器为软件提供商的许可证管理服务器，第二许可证管理服务器为部署在NFV网络范围内、与第一许可证管理服务器对接的许可证管理服务器，所述方法包括，

NFVO获取所述第一许可证管理服务器下发的许可证信息描述模板，所述LicenseDescriptor中包括License Descriptor ID、虚拟化网络功能的描述符VNFD ID以及许可信息选择项；

NFVO根据所述License Descriptor，向第二许可证管理服务器申请部署NFV网元所需要的许可证；其中，NFVO在收到第一许可证管理服务器发布的License Descriptor后，保存License Descriptor ID与虚拟化网络功能的描述符VNFD ID的对应关系；

第二许可证管理服务器根据从第一许可证管理服务器下发的许可证，向NFVO发送许可证信息；其中，第二许可证管理服务器可作为第一许可证管理服务器的代理或者基于第一许可证管理服务器的授权，第二许可证管理服务器在本地生成许可证；

NFVO根据所述许可证信息为VNF提供软件使用许可。

15.根据权利要求14所述的方法，其特征在于，该方法还包括，

第二许可证管理服务器接收第一许可证管理服务器发送的License Descriptor，并将获取到的所述License Descriptor发送给NFVO。

16.根据权利要求14所述的方法，其特征在于，该方法还包括，

软件提供商在向NFV运营商提供VNF Package时，将所述第一许可证管理服务器生成的License Descriptor连同VNF Package一并下发，所述NFVO在VNF Package上架过程中获取所述License Descriptor。

17.根据权利要求16所述的方法，其特征在于，该方法还包括，

NFVO在收到License Descriptor后，进行License Descriptor校验，如果校验失败，则向第二许可证管理服务器发送通知消息，携带License Descriptor ID或虚拟化网络功能的描述符VNFD ID，

所述第二许可证管理服务器根据License Descriptor ID或虚拟化网络功能的描述符VNFD ID，向第一许可证管理服务器申请License Descriptor ID或虚拟化网络功能的描述符VNFD ID所对应的License Descriptor，获取第一许可证管理服务器下发的LicenseDescriptor，并将License Descriptor发送给NFVO。

18.根据权利要求14所述的方法，其特征在于，该方法还包括，

第二许可证管理服务器用于在接收到NFVO发送的许可证申请请求，确定本地没有可以满足申请需求的许可证后，向第一许可证管理服务器发送许可证申请请求，接收所述第一许可证管理服务器下发的许可证。

19.根据权利要求14所述的方法，其特征在于，该方法还包括，

第二许可证管理服务器用于在接收到NFVO发送的许可证申请请求，确定本地没有可以满足申请需求的许可证后，向NFVO返回需要采购许可证的通知消息，NFVO根据所述通知消息，触发NFV网络运营商的OSS系统向软件提供商的订单管理系统购买所需的许可证；所述第一许可证管理服务器用于在收到所述订单管理系统发送的订单采购通知后，向第二许可证管理服务器发送与订单信息对应的许可证。

20.根据权利要求14至19任一项所述的方法，其特征在于，该方法还包括，

所述第二许可证管理服务器用于订阅VNF LCM状态变化通知，在收到订阅状态变化通知消息后，根据所述NFV状态变化，触发NFVO申请或者释放许可证。

21.根据权利要求14至19任一权利要求所述的方法，其特征在于，该方法还包括，

第二许可证管理服务器根据整网的许可证信息以及网络业务需要，确定VNF的许可证的申请或释放，或者NFVO从第二许可证管理服务器获取整网的许可证信息，NFVO根据整网的许可证信息以及网络业务需要，确定VNF许可证的申请或释放。

22.根据权利要求14所述的方法，其特征在于，该方法还包括，

所述第二许可证管理服务器向第一许可证管理服务器上报许可证使用情况，以便软件提供商根据许可证使用情况进行计费。

23.根据权利要求14至19任一权利要求所述的方法，其特征在于，该方法还包括，

NFVO在VNF缩容或释放时，向第二许可证管理服务器发送许可证释放消息，所述第二许可证管理服务器用于根据所述许可证释放消息，释放或去激活相应的许可证。

24.根据权利要求14至19任一权利要求所述的方法，其特征在于，该方法还包括，

所述第二许可证管理服务器作为第一许可证管理服务器的代理或者基于第一许可证管理服务器的授权，生成许可证，根据生成的许可证，向NFVO发送许可证信息，所述第二许可证管理服务器向第一许可证管理服务器上报生成许可证的情况，所述第一许可证管理服务器在收到第二许可证管理服务器上报的生成许可证的情况后，更新第一许可证管理服务器上记录的向NFV网络提供的许可证信息。

25.一种网络功能虚拟化NFV网络中许可证的管理系统，其特征在于，该系统包括第一许可证管理服务器(201)，第二许可证管理服务器(202)，其中第一许可证管理服务器为软件提供商的许可证管理服务器，第二许可证管理服务器为部署在NFV网络范围内、与第一许可证管理服务器对接的许可证管理服务器，

第二许可证管理服务器，用于接收NFVO根据所述License Descriptor提交的许可证申请请求，根据第一许可证管理服务器下发的许可证，向NFVO发送许可证信息；其中，第二许可证管理服务器可作为第一许可证管理服务器的代理或者基于第一许可证管理服务器的授权，第二许可证管理服务器在本地生成许可证。

26.根据权利要求25所述的系统，其特征在于，

第一许可证管理服务器用于将所述License Descriptor发送给第二许可证管理服务器，第二许可证管理服务器用于将获取到的所述License Descriptor发送给NFVO。

27.根据权利要求25所述的系统，其特征在于，第一许可证管理服务器还用于与软件提供商的订单管理系统相连，在收到订单管理系统发送的NFV网络运营商的订单采购通知后，根据所述订单信息，向第二许可证管理服务器发送与订单信息对应的许可证。

28.根据权利要求25所述的系统，其特征在于，第二许可证管理服务器用于在接收到NFVO发送的许可证申请请求，确定本地没有可以满足申请需求的许可证后，向第一许可证管理服务器发送许可证申请请求，所述第一许可证管理服务器用于接收到第二许可证管理服务器发送的许可证申请请求后，向第二许可证管理服务器下发许可证。

29.根据权利要求25所述的系统，其特征在于，第二许可证管理服务器用于在接收到NFVO发送的许可证申请请求，确定本地没有可以满足申请需求的许可证后，向NFVO返回需要采购许可证的通知消息，NFVO根据所述通知消息，触发NFV网络运营商的OSS系统向软件提供商的订单管理系统购买所需的许可证；所述第一许可证管理服务器用于在收到所述订单管理系统发送的订单采购通知后，向第二许可证管理服务器发送与订单信息对应的许可证。

30.根据权利要求25至29任一权利要求所述的系统，其特征在于，第二许可证管理服务器根据整网的许可证信息以及网络业务需要，确定VNF的许可证的申请或释放。

31.根据权利要求25至29任一权利要求所述的系统，其特征在于，

所述第二许可证管理服务器用于作为第一许可证管理服务器的代理或者基于第一许可证管理服务器的授权，生成许可证，根据生成的许可证，向NFVO发送许可证信息，所述第二许可证管理服务器用于向第一许可证管理服务器上报生成许可证的情况；

所述第一许可证管理服务器用于在收到第二许可证管理服务器上报的生成许可证的情况后，更新第一许可证管理服务器上记录的向NFV网络提供的许可证信息。