Patent Description:
A network functions virtualization (Network Functions Virtualization, NFV) technology can be simply understood as moving functions of network elements used in a telecommunications network from a current dedicated hardware platform to a universal commercial off-the-shelf (COTS, Commercial-off-the-shelf) product server. The NFV technology converts the network elements used in the telecommunications network into independent applications, and the independent applications may be flexibly deployed on a uniform infrastructure platform constructed based on other devices such as a standard server, memory, and switch. Resource pooling and virtualization are performed on an infrastructure hardware device by using a virtualization technology, to provide a virtual resource for an upper-layer application and decouple the application from hardware, so that a virtual resource can be quickly added for each application to quickly increase a system capacity, or a virtual resource can be quickly reduced to decrease a system capacity. This greatly improves network flexibility. With a shared resource pool constituted by general COTS servers, no hardware device needs to be independently deployed for a newly developed service. Therefore, it significantly shortens time to market of the new service.

The NFV technology is based on a cloud computing technology and a virtualization technology. Hardware devices such as general COTS computing/storage/network hardware devices may be decomposed into various virtual resources by using the virtualization technology, for use by various upper-layer applications. The virtualization technology implements decoupling between an application and hardware, so that a virtual resource supplying speed is greatly increased. The cloud computing technology can implement auto scaling of applications, and implement a match between a virtual resource and service load. This not only increases utilization of the virtual resource, but also increases a system response rate.

Virtualized telecom network functions gradually evolve into containers. Container as a service (Container as a Service, CaaS) is a specific type of platform as a service (Platform as a Service, PaaS) service. A container is an operating system-level virtualization technology. The container isolates different processes by using operating system isolation technologies, such as CGroup and NameSpace in Linux. A difference from a hardware virtualization technology lies in that, the container technology does not specially virtualize hardware, there is no independent operating system in a container, and resource sharing is implemented only through process isolation and resource usage restriction. By virtue of this important feature of the container technology, a container is more lightweight and easier to manage in comparison with a virtual machine. In a running state of a container, a group of common management operations are defined, such as starting, stopping, pausing, and deleting the container, to manage a lifecycle of the container.

Telecom services have high reliability requirements, and remote geographic redundancy is a common requirement. Network elements are provided by a plurality of vendors and may run on their own container management platforms. Currently, IoT and edge computing also have requirements on edge cloud deployment. One central data center and a plurality of edge clouds are a common deployment solution. In addition, a current mainstream container orchestration tool (such as K8S) can manage only a limited quantity of nodes. For example, the latest K8S version can manage a maximum of <NUM> nodes. Due to the foregoing factors, deployment and management of a multi-container service site (CaaS Cluster) become a basic requirement in an NFV service scenario.

However, current standards and solutions are not mature to support the deployment and management of a multi-container service site. In existing standards, a solution in which an NFV management platform manages a container is still under discussion, and no mature solution is available. The K8S does not have a specific solution to a scenario of hybrid orchestration of a virtual machine and a container.

<CIT> discloses systems and methods for network functions virtualization management and orchestration.

The object of the present invention is to provide a VNF service instantiation method, apparatus, and system, which in comparison with the conventional technology enable that a procedure and an interface of a multi-container service site in an NFV system are clearly described. This object is solved by the attached independent claims and further embodiments and improvements of the invention are listed in the attached dependent claims. Hereinafter, up to the "brief description of the drawings", expressions like ". aspect according to the invention", "according to the invention", or "the present invention", relate to technical teaching of the broadest embodiment as claimed with the independent claims. Expressions like "implementation", "design", "optionally", "preferably", "scenario", "aspect" or similar relate to further embodiments as claimed, and expressions like "example", ". aspect according to an example", "the disclosure describes", or "the disclosure" describe technical teaching which relates to the understanding of the invention or its embodiments, which, however, is not claimed as such.

According to the present invention, there is provided a virtualized network function VNF instantiation method as disclosed by the appended claim <NUM>.

The VNFM obtains a corresponding VNFD from a database based on the VNF instantiation request message, and obtains the deployment information of the corresponding container service instance from the VNFD.

According to the invention, the deployment information of the container service instance includes a name of a specified cluster.

If a selected CaaS cluster does not have sufficient resources, a physical server or a virtual machine resource is applied for from a virtualized infrastructure manager VIM, to add a resource to the selected CaaS cluster.

The present invention also provides a virtualized network function VNF instantiation apparatus as defined by the appended claim <NUM>.

The present invention also provides a virtualized network function VNF instantiation system as defined by the appended claim <NUM>.

An non-claimed example further provides a virtualized network function VNF service instantiation apparatus, where the apparatus includes a processor and a memory. The memory is configured to store a program for performing the foregoing method, and store data used in the foregoing method. The processor is configured to execute the program stored in the memory.

Another non-claimed example further provides a computer-readable storage medium. The computer-readable storage medium stores executable program instructions. When the executable program instructions are run, the executable program instructions are used to perform the steps in the foregoing method.

Yet another non-claimed example further provides a computer program product. When the computer product is executed, the computer product is used to perform the steps of the foregoing method.

The foregoing disclosure is provided for a scenario of one or more CaaS clusters in a MANO architecture. According to the foregoing solutions, problems of cross-site deployment and management of a container service in an NFV scenario are resolved, so that a container service of a VNF can be deployed in different CaaS clusters, and a MANO system can control and manage one or more CaaS clusters.

To make the objectives, technical solutions, and advantages of this application clearer, the following further describes implementations of this application in detail with reference to the accompanying drawings.

Before the embodiments of this application are further described in detail, an application scenario of the embodiments of this application is first described.

Because a container manager (CaaS Manager) in the embodiments of this application is deployed in an NFV architecture, the NFV architecture is first described herein. <FIG> is a schematic diagram of an NFV architecture according to an embodiment of this application. The NFV system architecture can be applied to various types of networks, for example, an operator's communications network or a local area network.

As shown in <FIG>, the NFV architecture mainly includes a MANO entity <NUM>, an NFVI <NUM>, a plurality of VNFs <NUM>, a plurality of element management (Element Management, EM) <NUM>, an operation support system/business support system (Operation Support System/Business Support System, OSSBSS) <NUM>, and the like. The MANO entity <NUM> further includes a network functions virtualization orchestrator (NFV Orchestrator, NFVO) 110a, one or more virtualized network function managers (Virtualized Network Function Manager, VNFM) 110b, and a virtualized infrastructure manager (Virtualized Infrastructure Manager, VIM) 110c.

For ease of subsequent description, the following describes functions of the modules in the NFV architecture in <FIG>.

The NFVO 110a is configured to: manage and process a network service descriptor (Network Service Descriptors, NSD) and a virtualized network function forwarding graph (VNF Forwarding Graph, VNFFG), manage a lifecycle of a network service, and cooperate with the VNFM to implement lifecycle management of a VNF and a global view function of a virtual resource.

The VNFM 110b is configured to implement VNF lifecycle management, including management of a virtualized network function descriptor (VNF Descriptor, VNFD) file, VNF instantiation, VNF instance auto scaling (including scaling out/up and scaling in/down), VNF instance healing (Healing), and VNF instance termination. The VNFM further supports receiving of an auto scaling (Scaling) policy delivered by the NFVO or defined in a VNFD, to implement auto scaling of the VNF.

The VIM 110b is responsible for managing (including reserving and allocating) a hardware resource and a virtual resource at an infrastructure layer, monitoring a status of the virtual resource and reporting a fault, and providing a virtual resource pool for an upper-layer application.

The OSS/BSS <NUM> refers to an existing operator's operation and maintenance system OSS/BSS.

The EM <NUM> is configured to perform conventional fault management, configuration management, account management, performance management, and security management (Fault Management, Configuration Management, Account Management, Performance Management, Security Management, FCAPS) functions for the VNF <NUM>.

The VNF <NUM> corresponds to a physical network function (Physical Network Function, PNF) in a conventional non-virtualized network, for example, a virtualized <NUM> core network (Evolved Packet Core, EPC) EPC node, such as a mobility management entity (Mobility Management Entity, MME), a serving gateway (Serving Gateway, SGW), or a packet data network gateway (Packet Data Network Gateway, PGW). Functional behavior and a status of a network function are unrelated to virtualization of the network function. NFV technologies require that the VNF and the PNF have same functional behavior and a same external interface.

In addition, the VNF <NUM> may include a plurality of VNF components (VNF Component, VNFC). Therefore, in actual application, one VNF <NUM> may be deployed on a plurality of virtual machines (Virtual Machine, VM), and each VM hosts a function of one VNF component. Certainly, one VNF <NUM> may alternatively be deployed on one VM.

The NFVI <NUM> includes a hardware resource, a virtual resource, and a virtualization layer. From a perspective of the VNF <NUM>, the virtualization layer and the hardware resource seem to be a complete entity that can provide a required virtual resource.

<FIG> is a schematic diagram of an NFV architecture in which one or more container as service sites (CaaS Cluster) are deployed according to an embodiment of this application.

One or more CaaS clusters are connected to an NFVO and/or a VNFM in a MANO system. Each CaaS cluster is deployed with one CaaS manager. A CaaS manager instantiates a container service in a CaaS cluster in which the CaaS manager is located, and manages and schedules a container service instance. The NFVO or the VNFM may obtain container resource status information in each CaaS cluster and send a container service request to the CaaS cluster after the NFVO or the VNFM is connected to the CaaS manager in each CaaS cluster.

A VNFD field of a VNF described in the conventional technology mainly includes parameters such as deployment flavour and VduProfile in the deployment flavour. The deployment flavour is used to describe a specific deployment solution for VNF deployment. The solution includes various deployment requirements, such as virtual resource specifications (such as a quantity of CPUs and a memory size of a virtual machine and a quantity of CPUs of containers) required for deployment, a lifecycle management operation supported by the VNF, an affinity/anti-affinity relationship between components, a supported monitoring indicator, and a scaling out/in parameter. VduProfile is used to describe specification information and a deployment quantity of virtual machines/containers. Functions of the foregoing parameters have been described in an existing standard.

However, during actual deployment in the embodiments of the present invention, deployment information of a container service instance needs to be added to the VNFD field that describes the VNF in the conventional technology. The deployment information may include but is not limited to the following types of information:.

For example, one or more CaaS clusters in which the container service instance is specifically deployed may be identified by a name, an ID, or a label of the one or more CaaS clusters.

If a VNF is divided into two parts that work in an active/standby mode, anti-affinity deployment is required between two CaaS clusters, that is, one part is deployed in each CaaS cluster.

The deployment weight is used to indicate the VNFM to allocate, based on a defined weight proportion, a container service instance that needs to be deployed to each CaaS cluster. For example, specific container service instances need to be deployed in a cluster A, a cluster B, and a cluster C, and deployment weights of the cluster A, the cluster B, and the cluster C are <NUM>, <NUM>, and <NUM>, respectively. In this case, <NUM>% (<NUM>/(<NUM>+<NUM>+<NUM>)) of the container service instances are deployed in the cluster A, and <NUM>% and <NUM>% of the container service instances are deployed in the cluster B and the cluster C, respectively. The quantity of container service instances is used to directly specify a quantity of instances that need to be deployed in each CaaS cluster. For example, it is specified that <NUM>, <NUM>, and <NUM> container service instances are deployed in the clusters A, B, and C, respectively. The quota is used to specify a maximum quantity of container service instances that can be deployed in each CaaS cluster. For example, a maximum of <NUM>, <NUM>, and <NUM> container service instances can be deployed in the clusters A, B, and C, respectively. During initial deployment and subsequent lifecycle management (such as scaling out), a quantity of container service instances deployed in each CaaS cluster cannot exceed the quantity specified by the quota.

That the deployment information of the container service instance is added to the VNFD field may be implemented in two manners:.

For a specific implementation of the foregoing manner (<NUM>), refer to the following manner:.

For an affinity/anti-affinity rule in a container deployment scenario, refer to the following manner:.

For the foregoing manner (<NUM>), refer to the following manner:.

For an affinity/anti-affinity rule, refer to the manner (<NUM>).

After receiving a virtualized network function VNF instantiation request message and before sending a service request to a CaaS manager, the NFVO or the VNFM needs to first obtain a corresponding VNFD from a database, and obtain deployment information of a container service instance from the VNFD; then selects a proper CaaS cluster based on information about a locally deployed CaaS cluster, including information such as a quantity and a processing capability (the foregoing information may be obtained in advance through query or based on external configuration); and sends the service request to a CaaS manager of a CaaS cluster that meets a condition. The service request includes container creation, update, query, deletion, and the like.

In addition to initiating the service request to the CaaS manager, the NFVO or the VNFM further needs to maintain a status of each CaaS cluster. That is, the NFVO or the VNFM periodically queries a status of a current VNF instance from a CaaS manager of each CaaS cluster. If the status is inconsistent with a status described in the VNFD, the NFVO or the VNFM triggers a corresponding service request, to create/delete/update a container, so that an actual status is consistent with the status described in the VNFD. In addition, the NFVO or the VNFM can further provide a DNS and a load balancing service between different CaaS clusters, so that VNFs deployed across sites can perform inter-site service communication smoothly.

The following further describes the technical solutions of the present invention by using several specific embodiments.

<FIG> is a flowchart of VNF instantiation. The VNF instantiation specifically includes instantiation of a container service instance and corresponding initialization configuration of a VNF instance. Steps are specifically as follows.

<NUM>: A VNFM receives a VNF instantiation request message from a sender, where the sender may be an NFVO or an EM; or an NFVO needs to perform VNF instantiation in a process of processing a network service (Network Service, NS) instantiation request; or an NFVO receives a granting (Granting) request that is initiated by a VNFM to request to authorize VNF instantiation.

<NUM>: The NFVO or the VNFM obtains deployment information of a container service instance from a VNFD corresponding to a VNF that needs to be instantiated. As described above, the deployment information of the container service instance may include: deployment location information of the container service instance; an affinity/anti-affinity rule; or a deployment weight (an instance is deployed based on a weight proportion) of a CaaS cluster, a quantity, or a quota.

<NUM>: The NFVO or the VNFM determines one or more container as service sites CaaS cluster based on the deployment information of the container service instance.

Specifically, the NFVO or the VNFM selects a proper CaaS cluster based on the deployment information, obtained from the VNFD, of the container service instance and locally stored information about each CaaS cluster.

If the deployment information of the container service instance includes a name or an ID of a CaaS cluster, the corresponding cluster is selected. For example, if a label of a CaaS cluster is specified, managed CaaS clusters are traversed to search for the CaaS cluster that includes the corresponding label.

Optionally, if the selected CaaS cluster does not have sufficient resources, and the NFVO or the VNFM has a capability of applying for a CaaS cluster resource from a VIM, the NFVO or the VNFM may apply for a physical server or a virtual machine resource from the VIM, and add the physical server or the virtual machine resource to a CaaS manager of the corresponding CaaS cluster for capacity expansion.

<NUM>: The NFVO or the VNFM sends a container service instance creation request to a container as service manager CaaS manager in each of the one or more CaaS clusters.

<NUM>: After receiving the request, the CaaS manager in each CaaS cluster performs a container service instance creation (instantiation) operation.

<NUM>: Each CaaS cluster sends a container service instance creation success response message to the NFVO or the VNFM.

<NUM>: The NFVO or the VNFM locally stores the deployment information of the container service instance, and then directly performs or notifies an EMS to perform initialization configuration on a VNF instance.

<NUM>: The NFVO or the VNFM initiates a VNF instantiation success response message to the sender sending the VNF instantiation request message.

<FIG> is a flowchart of querying/updating/deleting a VNF instance. Specific steps include as follows.

<NUM>: A VNFM receives a VNF instance query/update/deletion request message from a sender, where the sender may be an NFVO or an EM; or an NFVO needs to query/update/delete a container service instance of a VNF in a process of processing an NS (Network Service) instantiation request.

<NUM>: The NFVO or the VNFM obtains, from locally stored information, deployment location information of the container service instance of the VNF, that is, a CaaS cluster in which the container service instance of the VNF is deployed.

<NUM>: The NFVO or the VNFM initiates a container service instance query/update/deletion request to a corresponding CaaS manager.

<NUM>: After receiving the request, a CaaS manager in each CaaS cluster performs a corresponding query/update/deletion operation, and feeds back a result to the NFVO or the VNFM.

<NUM>: The NFVO or the VNFM updates local information based on feedback information, and feeds back updated local information to the request sender.

<FIG> is a flowchart of maintaining a container service instance of a VNF. Specific steps include as follows.

<NUM>: An NFVO or a VNFM periodically queries a status from a CaaS manager in a managed CaaS cluster, or each CaaS manager periodically reports a current container instance status to the NFVO/the VNFM.

<NUM>: The NFVO or the VNFM compares the obtained container service instance status with deployment information, described in a VNFD, of a container service instance.

<NUM>: If the status is consistent with the deployment information, no processing is performed. If the status is inconsistent with the deployment information, the NFVO or the VNFM initiates a corresponding container instance operation request to the corresponding CaaS manager. For example, if a quantity of actually deployed container service instances in a CaaS cluster is less than a quantity specified in the VNFD, the NFVO or the VNFM needs to initiate a container service instance creation request to the CaaS cluster, so that the quantity of actually deployed container service instances is consistent with a requirement.

If the entire CaaS cluster is abnormal, the NFVO or the VNFM cannot communicate with the corresponding CaaS manager. In this case, the NFVO or the VNFM needs to reselect a proper CaaS cluster based on a container service instance deployment requirement in the VNFD and locally stored CaaS cluster information (This process is similar to the process in <FIG>), and deploy a container service instance that needs to be hosted by the faulty cluster to the newly selected CaaS cluster, so that an overall deployment result is consistent with the requirement in the VNFD.

<NUM>: After the CaaS cluster completes creation of the container service instance, the NFVO or the VNFM receives a feedback result from the CaaS cluster.

The foregoing method embodiments are provided for a scenario of one or more CaaS clusters in a MANO architecture. According to the foregoing method procedures, problems of cross-site deployment and management of a container service in an NFV scenario are resolved, so that a container service of a VNF can be deployed in different CaaS clusters, and a MANO system can control and manage one or more CaaS clusters.

The following further describes a related apparatus or device in the foregoing method embodiments. Details are as follows.

<FIG> is a schematic diagram of a virtualized network function VNF instantiation apparatus. The apparatus includes:.

For specific steps and functions of the foregoing units, refer to the descriptions of the method steps shown in <FIG>.

<FIG> is a schematic diagram of a VNF instantiation system. The system includes:.

The virtualized network function VNF service instantiation apparatus is a network functions virtualization orchestrator NFVO or a virtualized network function manager VNFM.

For specific steps and functions of the foregoing apparatuses, refer to the descriptions of the method steps in <FIG>.

<FIG> is a hardware diagram of a VNF instantiation apparatus <NUM> according to an embodiment of the present invention. The apparatus <NUM> may include a processor <NUM>, a communications interface <NUM>, and a memory <NUM>.

The processor <NUM> may include one or more processing units. The processing unit may be a central processing unit (English: central processing unit, CPU), a network processor (English: network processor, NP), or the like.

The communications interface <NUM> is configured to connect to and exchange information with another communications device, including receiving and sending a corresponding message. The network apparatus <NUM> may further include a memory <NUM>, and the processor <NUM> may be connected to the memory <NUM> and the communications interface <NUM> through a bus. The memory <NUM> may be configured to store a software program. The software program may be executed by the processor <NUM>, to implement the method steps performed by the VNFM in the embodiment shown in <FIG>. In addition, the memory <NUM> may further store various types of service data or user data, including status data of various application instances and services in the foregoing method steps, and the like.

Optionally, the apparatus <NUM> may further include an output device <NUM> and an input device <NUM>. The output device <NUM> and the input device <NUM> are connected to the processor <NUM>. The output device <NUM> may be a display configured to display information, a power amplifier device configured to play a sound, a printer, or the like. The output device <NUM> may further include an output controller, configured to provide an output to the display, the power amplifier device, or the printer. The input device <NUM> may be a device such as a mouse, a keyboard, an electronic stylus, or a touch panel that is used by a user to input information. The input device <NUM> may further include an input controller, configured to receive and process an input from a device such as a mouse, a keyboard, an electronic stylus, or a touch panel.

Similarly, the hardware diagram of the foregoing apparatus is also applicable to a CaaS cluster apparatus. A difference lies in that the software program stored in the memory <NUM> is executed by the processor <NUM>, to implement the method steps performed by the CaaS cluster in the embodiment shown in <FIG>. This is not repeated herein.

All or a part of the foregoing embodiments may be implemented by using software, hardware, firmware, or any combination thereof. When software is used to implement the embodiments, the embodiments may be implemented completely or partially in a form of a computer program product. The computer program product includes one or more computer instructions. When the computer instructions are loaded and executed on a computer, the procedure or functions according to the embodiments of this application are completely or partially generated. The computer may be a general-purpose computer, a dedicated computer, a computer network, or another programmable apparatus. The computer instructions may be stored in a computer-readable storage medium or may be transmitted from a computer-readable storage medium to another computer-readable storage medium. For example, the computer instructions may be transmitted from a website, computer, server, or data center to another website, computer, server, or data center in a wired (for example, a coaxial cable, an optical fiber, or a digital subscriber line (Digital Subscriber Line, DSL)) or wireless (for example, infrared, radio, or microwave) manner. The computer-readable storage medium may be any usable medium accessible by a computer, or a data storage device, such as a server or a data center, integrating one or more usable mediums. The usable medium may be a magnetic medium (for example, a floppy disk, a hard disk, or a magnetic tape), an optical medium (for example, a digital versatile disc (Digital Versatile Disc, DVD), a semiconductor medium (for example, a solid-state drive (Solid-State Disk, SSD)), or the like.

A person of ordinary skill in the art may understand that all or a part of the steps in the foregoing embodiments may be implemented by hardware or a program instructing related hardware. The program may be stored in a computer-readable storage medium. The storage medium mentioned above may be a read-only memory, a magnetic disk, an optical disc, or the like.

Claim 1:
A virtualized network function, VNF, instantiation method, wherein the method is performed by a network functions virtualization orchestrator, NFVO, or a virtualized network function manager, VNFM, and comprises:
receiving (<NUM>) a virtualized network function, VNF, instantiation request message;
obtaining (<NUM>) deployment information of a container service instance that needs to be invoked for VNF instantiation; wherein the deployment information of the container service instance comprises a name of a specified container as service sites, CaaS, cluster;
determining (<NUM> the CaaS cluster, based on the deployment information of the container service instance, and sending (<NUM>) a container service instance creation request to a container as service sites, CaaS, manager, in the CaaS cluster;
performing (<NUM>), by the CaaS manager in the CaaS Cluster a container service instantiation operation; and
receiving (<NUM>) a container service instance creation success message from the CaaS manager.