Systems and methods for dynamically managing virtual network function descriptors

Abstract

Virtual Network Function Descriptor (VNFD) parameters may include sub-fields that enable a management entity to determine whether the VNFD parameters can be updated. The sub-fields may include a writeability sub-field that indicates whether the VNFD parameter is a dynamic / configurable VNFD parameter or a fixed / static VNFD parameter. The VNFD parameter may also include an access permission sub-field that indicates which entities are authorized to modify / update the VNFD parameter. The VNFD parameter may also include a management priority sub-field that indicates the priority of the entity setting the attribute of the VNFD parameter. The VNFD parameter may also include a constraint sub-field that indicates one or more conditions that need to occur in order to update the VNFD parameter.

Description

[0001] This application is a divisional of a Chinese patent application filed with the Chinese Patent Office on May 9, 2016, with application number 201680024053.4 and invention title "System and Method for Dynamically Managing Virtual Network Function Descriptors". Technical Field

[0002] The present invention relates to systems and methods for network virtualization, and in particular embodiments, to systems and methods for dynamically managing virtual network function virtualization. Background Art

[0003] Network function virtualization (NFV) is an industry effort to virtualize network devices by using a common off-the-shelf hardware platform, with the aim of reducing costs and enabling efficient / flexible network operation and performance. Conceptually, NFV is the principle of separating network functions from the hardware on which they run by using virtual hardware abstractions, and seeking to virtualize all classes of network node functions into building blocks that can be connected or chained together to create communication services. Summary of the Invention

[0004] The technical advantages are generally achieved through embodiments of the system and method for dynamically managing virtual network function descriptors described in the present disclosure.

[0005] According to one embodiment, a method for dynamically configuring virtual network function (VNF) parameters is provided. In this example, the method includes: receiving, at a management entity, a VNF descriptor (VNFD) associated with a VNF or a VNF instance. The VNFD lists a set of parameters that describe the characteristics of the VNF or the VNF instance. The method further includes: determining whether the VNFD parameters in the VNFD can be dynamically updated based on one or more sub-fields of the VNFD parameters or based on information elements that list dynamically configurable VNFD parameters; and dynamically updating the VNFD parameters in the case where it is determined that the VNFD parameters can be dynamically updated. An apparatus for performing the method is also provided.

[0006] According to another embodiment, a method for managing virtual network function (VNF) resource allocation is provided. In this example, the method includes: receiving, at a VNF manager (VNFM), a quota information notification from a network function virtualization operator (NFVO). The quota information notification corresponds to the quota allocated to the VNFM or to one or more VNF instances managed by the VNFM. The method further includes: sending a quota management request to the NFVO to update the quota initially set by the NFVO or to request information related to the quota initially set by the NFVO; and receiving a response to the quota management request from the NFVO. A device for performing this method is also provided. BRIEF DESCRIPTION OF THE DRAWINGS

[0007] To more fully understand the present invention and its advantages, reference is now made to the following description taken in conjunction with the accompanying drawings, in which:

[0008] Figure 1 A block diagram of a virtual network function descriptor (VNFD) of one embodiment is shown;

[0009] Figure 2 A block diagram of a virtual network function descriptor (VNFD) of another embodiment is shown;

[0010] Figure 3 A protocol diagram of a communication sequence for activating a VNF package of one embodiment is shown;

[0011] Figure 4 A protocol diagram of a communication sequence for retrieving configuration parameters from an OAM system of one embodiment is shown;

[0012] Figure 5 A protocol diagram of a communication sequence for establishing a quota for a VNF instance is shown;

[0013] Figure 6 A protocol diagram of a communication sequence for allocating resources to a VNF instance based on a quota is shown;

[0014] Figure 7 A protocol diagram of a communication sequence for increasing the size of a quota is shown;

[0015] Figure 8 A protocol diagram of a communication sequence for decreasing the size of a quota is shown;

[0016] Figure 9A flowchart of a method for dynamically updating VNF descriptor (VNFD) parameters in one embodiment is shown;

[0017] Figure 10 A flowchart of a method for managing quotas in one embodiment is shown;

[0018] Figure 11 A block diagram of a processing system is shown;

[0019] Figure 12 A diagram of a wireless communication system in one embodiment is shown;

[0020] Figure 13 A diagram of a user equipment (UE) in one embodiment is shown;

[0021] Figure 14 A diagram of a base station in one embodiment is shown. Detailed Embodiments

[0022] The structure, implementation, and use of the currently preferred embodiments are discussed in detail below. However, it should be understood that the present invention provides many applicable inventive concepts that can be embodied in various specific contexts. The specific embodiments discussed merely illustrate the specific ways of implementing and using the present invention and do not limit the scope of the present invention.

[0023] A virtual network function (VNF) is a virtualized task that has been transferred from dedicated hardware to software. A VNF descriptor (VNFD) can include a set of parameters that describe the characteristics and / or attributes of a VNF instance. The VNFD can be used by a network function virtualization orchestrator (NFVO) to instantiate a virtual machine corresponding to the VNF instance on a host device. The NFVO is a software package that acts as an arbiter for resource provisioning between VNFs. The NFVO can trigger the instantiation of VMs corresponding to VNF instances on different host devices.

[0024] In traditional NFV systems, the parameters of the VNFD are statically defined. However, in some cases, it may be desirable to update the VNFD to reflect new or changed characteristics and / or attributes of the VNF instance, for example, this may occur when the VNF instance is updated by a vendor or an operator. Therefore, techniques for updating the VNFD are needed.

[0025] Embodiments of the present disclosure provide a VNFD parameter format that includes sub-fields that enable a management entity to determine whether VNFD parameters can be updated. The sub-fields may include a writeability sub-field, an access permission sub-field, a management priority sub-field, and / or a constraint sub-field. The parameter sub-field indicates the name of the VNFD parameter. The writeability sub-field indicates whether the VNFD parameter is a dynamic / configurable VNFD parameter or a fixed / static VNFD parameter. A dynamic / configurable VNFD parameter is writable, which means it can be updated dynamically. A static VNFD parameter is read-only. The management priority sub-field indicates the priority of the entity that last updated the sub-field. The constraint sub-field indicates one or more conditions that must occur in order to update the VNFD parameter. For example, the constraint field may require that VNF instantiation and lifecycle management (LCM) events, or loading events, occur within a threshold period.

[0026] The management entity may determine whether a VNFD parameter can be updated dynamically based on one or more sub-fields of the VNFD parameter and / or based on an information element listing the dynamically configurable VNFD parameters. In one embodiment, the management entity determines whether a VNFD parameter is a configurable VNFD parameter or a fixed VNFD parameter based on a sub-field of the VNFD parameter that indicates whether the VNFD parameter can be reconfigured.

[0027] In another embodiment, the management entity determines whether a VNFD parameter is a configurable VNFD parameter based on whether the VNFD parameter is listed in an information element listing the dynamically configurable VNFD parameters. The information element may be a VnfConfigurableProperties information element that defines the configurable attributes of a VNF or VNF instance. In another embodiment, the management entity determines whether the management entity is authorized to update the VNFD parameter based on the access permission sub-field of the VNFD parameter. The access permission sub-field may identify which entities are permitted to update the VNFD parameter.

[0028] In another embodiment, the management entity determines whether the attributes of a VNFD parameter can be modified by the management entity based on the management priority sub-field of the VNFD parameter. The management priority sub-field may indicate the management priority of the entity that set the attributes of the VNFD parameter. When the management entity has a higher management priority than the entity that previously set the attributes of the VNFD parameter, the management entity may be permitted to modify the attributes. In yet another embodiment, the management entity determines whether a VNFD parameter can be updated dynamically when one or more conditions specified by the constraint sub-field of the VNFD parameter occur within a threshold period.

[0029] VNFD parameters can be updated / modified to reflect modifications to the characteristics of the VNF or VNF instance. For example, VNFD parameters can be updated to reflect an increase or decrease in the number of virtual deployment units (VDUs), the number of virtual links, or the number of attachment points in the VNF or VNF instance. As another example, VNFD parameters can be updated to reflect an increase or decrease in the resource quota of the VNF or VNF instance, where the resource quota specifies the maximum amount of resources that can be allocated to the VNF or VNF instance. The management entity can be: a network function virtualization operator (NFVO), an Operational Support System (OSS) function, an Authentication, Authorization and Accounting (AAA) function, or a VNF manager (VNFM).

[0030] Embodiments of the present disclosure also provide techniques for managing quotas. In one embodiment, a VNF manager (VNFM) can receive a quota information notification from a network function virtualization operator (NFVO). The quota information notification can correspond to the quota allocated to the VNFM or to one or more VNF instances managed by the VNFM. Then, the VNFM can send a quota management request to the NFVO. The quota management request can request an update to the quota initially set by the NFVO. Alternatively, the quota management request can request information related to the quota.

[0031] In one embodiment, the quota management request queries updated quota information that indicates whether there are any changes to the quota allocated to the VNFM or to one or more VNF instances managed by the VNFM. In another embodiment, the quota management request requests an increase or decrease in the quota. In yet another embodiment, the quota management request requests deletion of the quota.

[0032] Quota notification information from the NFVO can indicate whether there is quota available for the VNFM or one or more VNF instances managed by the VNFM. The quota can specify the maximum amount of computing resources that are allowed to be allocated to the VNFM or to one or more VNF instances managed by the VNFM. For example, the quota can specify the maximum number of virtual machines (VMs) or CPU processes that are allowed to be instantiated by the VNFM or the maximum number of virtual machines (VMs) or CPU processes that are allowed to be instantiated for one or more VNF instances managed by the VNFM. As another example, the quota can specify the maximum storage capacity that is allowed to be allocated to the VNFM or to one or more VNF instances managed by the VNFM.

[0033] Alternatively, the quota can specify the maximum network resource capacity that is allowed to be allocated to the VNFM or to one or more VNF instances managed by the VNFM. As another alternative, the quota can specify the resource type, category, or level that is allowed to be allocated to the VNFM or to one or more VNF instances managed by the VNFM. For example, the quota can specify that only gold-level resources can be allocated to the VNFM or to one or more VNF instances managed by the VNFM. Quota information notifications, quota management requests, and / or responses can be exchanged through the Virtualized Resources Quota management Interface.

[0034] In some embodiments, the NFVO may dynamically update the dynamically configurable VNFD parameters when receiving a request to dynamically update the dynamically configurable VNFD parameters from another entity, such as an Authentication, Authorization and Accounting (AAA) function entity, an Operational Support System (OSS) function entity, or a VNF Manager (VNFM) function entity. In some embodiments, the NFVO may update the VNFD only when one or more constraints specified by the VNFD parameters are met. For example, the NFVO may update the VNFD parameters only when the sender of the update request has the permission to modify the VNFD parameters. Entities with the permission to modify the VNFD parameters may be listed in the management entity field of the VNFD parameters. In some other embodiments, the NFVO may update the VNFD only when the sender of the request has a higher management priority than the entity that most recently requested to modify the corresponding parameters. The priority category of the entity that most recently updated the parameters may be listed in the priority management entity field of the VNFD parameters. In yet another embodiment, the NFVO may update the VNFD only when one or more constraints / conditions specified by the VNFD occur within a threshold period from the time when the request is received by the NFVO. These constraints / conditions may be specified in the constraint field of the VNFD parameters. The dynamically configurable VNFD parameters may include, for example, the number of Virtual Deployment Units (VDUs) in the VNF instance (configurable within a value range or between a maximum and a minimum number), the number of virtual links in the VNF instance, the number of connection points in the VNF instance, the quota number of virtual resources, or the tenant ID of the virtual resources.

[0035] In various embodiments, the system is capable of using a single file to store the dynamically changing VNFD. For example, a collection of multiple files containing VNF parameters may be set as part of the VNF package by the VNF vendor. The system may also be capable of extracting parameters from each of the multiple files and combining the extracted parameters together to form a single unified VNFD file, which can subsequently be used to configure the instantiation of the VNF. For example, the NFVO may be a centralized control point for authorizing access to the dynamic VNFD parameters to ensure that multiple entities can configure the VNF parameters in a single file.

[0036] In the VNFD, there is also an indication of the following items: whether the parameter is static (read-only access) or dynamically configurable (read-write access), which entities have read-write access, the access priority in the case where multiple entities have read-write access, and any conditions or constraints that limit the range of the parameter. An example of such a constraint is to apply a specific parameter only when the target device is in a specific geographical location (as in geographical licensing, for example). Another example of a parameter constraint is to apply a specific parameter only when the VNF has a specific state, such as when the VNF is in a suspended state or an overloaded state. In some embodiments, the write qualifier field of the VNFD parameter may indicate whether the VNFD parameter is dynamically configurable.

[0037] In various embodiments, the system further includes a VNFM as an entity separate from the NFVO logic, and the VNFM may or may not be in the same physical node as the NFVO. In one example, the NFVO may arbitrate M2M management resources for an M2M service, where the M2M service may use different VNFs to form the service, for example, in a layer architecture.

[0038] In the first NFV quota scheme, the NFVO knows the quota and enforces the quota, while the VNFM only follows the instructions and is not involved in quota operations. However, in some implementations, the VNFM performs resource management, and the VNFM is more intelligent than the NFVO in terms of how to manage the resources for its VNFs. In such a case, the NFVO centralized quota scheme limits the possibility of having better resource management.

[0039] Alternatively, in an embodiment of the second scheme, the virtualized infrastructure manager (VIM) issues quotas for its lessees and thus does not know who the lessees are. Therefore, the VNFM can perform quota management because the VNF is a lessee of the network function virtualized implementation (NFVI). The VNFM receives quota information from the NFVO through an authorization operation or a dedicated resource notification or query interface, and then the VNFM requests resources from the VIM according to the quota.

[0040] In such an embodiment, a quota negotiation and notification mechanism can be set up between the VNFM and the NFVO. When the VIM notifies of a resource change or some resource policies are triggered, the NFVO will send a notification to the VNFM to change the quota. For both the reservation-based scheme and the quota-based scheme, this resource notification interface can be used to transfer resource allocation information. The VNFM also has the additional ability to request an increase / decrease in quota or negotiate with the NFVO. In some embodiments, there can be different levels or types of quotas for the VNFM to use, such as quota level 1 with 10 virtual machines (VMs), quota level 2 with 20 VMs, etc. The additional VMs can be, for example, VNF replicas added to handle increased traffic.

[0041] In some embodiments, reaching a quota threshold triggers the VNFM to send an authorization / quota change request to the NFVO instead of sending a request to the VIM to request additional resource allocation. In some embodiments where the NFVO uses quotas for resource management and allocation, a quota query interface is set up in the NFVO (producer). Through this quota query interface, the VNFM can query quota information to configure VNFCs in a more optimized manner before instantiation, such as instantiating different VNFCs based on quota resources. In some embodiments, a quota usage notification interface for the VNFM or the VIM is set up to notify the NFVO of the quota consumption status.

[0042] Figure 1 FIG. 102 is a block diagram showing an embodiment of a VNFD 102, where the VNFD 102 is a deployment template that describes the VNF in terms of deployment and operation behavior requirements. The VNFD 102 is mainly used by the VNFM during the VNF instantiation and lifecycle management (LCM) of the VNF instance. The information in the VNFD 102 is also used by the NFVO to manage and orchestrate network services (NS) and virtualized resources on the Network Function Virtualized Implementation (NFVI).

[0043] VNFD 102 also includes connectivity, interface, and key performance indicator (KPI) requirements that can be used by the NFV-management and orchestration (NFV-MANO) functional block to establish appropriate virtual links 104 within the NFV infrastructure (NFVI) between its VNF component (VNFC) instances 106 or within the NFV infrastructure (NFVI) between a VNFC instance 106 and an endpoint interface to other network services.

[0044] In some examples, VNFD parameters describe a VNF in terms of its deployment and operational behavior. Exemplary VNFD parameters can include: static (pre-configured in the VNFD) metrics, VNFD ID, vendor identifier, VNFD version, virtualized deployment unit (VDU), virtual link, connection point, lifecycle event, dependency, monitoring parameter, deployment style, autoscaling policy, manifest file, and manifest security file.

[0045] It should be understood that additional or alternative VNFD components can be envisioned and are within the scope of this specification and the claims.

[0046] Figure 2 is a block diagram of a VNFD 204 showing one implementation, where VNFD 204 provides an apparatus for an operator to customize the VNFD 204 in different scenarios for VNF lifecycle management by using dynamic parameters in the VNFD 204 instead of only static parameters. Static parameters are read-only. Static parameters are typically pre-configured by an operator or VNF provider during the VNFD design phase and are never updated during the VNF LCM process and can only be changed with a VNFD update. Each dynamic parameter is configured with a default value or value range during the VNFD design phase and can be updated to a working value during subsequent VNF instantiation or other LCM processes. Dynamic parameters are readable and writable.

[0047] Through the access to VNFD 204 mediated by NFVO 202, OSS 206, VNFM 208, and AAA 210 dynamically provide parameter inputs during VNF operation so that the inputs fill the parameter values in VNFD 204. Examples of dynamic parameters in VNFD 204 include the number of VDUs in a VNF instance (within a value range or maximum / minimum number), the number of virtual links in a VNF instance, the number of connection points in a VNF instance, the quota number of virtual resources, and the renter ID of virtual resources.

[0048] According to one embodiment, for each parameter in VNFD 204, some attributes are added to the parameter. The readability attribute is read-only for static parameters and read-write for dynamic parameters. The attributes can be set by the operator, or similar parameters can indicate whether the parameter is statically configured in the design phase or can be dynamically changed during VNF operation.

[0049] When processing each dynamic parameter (read-write), VNFM 208 can determine the operation management (Operations, Administration and Management, OAM) entity (e.g., NFVO / specific VNFM (S-VNFM) / generic VNFM (G-VNFM) / element manager (EM) of the VNF) or a list of OAM entities that have the ability to modify the dynamic parameter.

[0050] For each dynamic parameter, if multiple entities can modify the dynamic parameter, in case of a conflict in parameter modification, VNFM can determine the entity with the highest priority to modify the dynamic parameter.

[0051] One embodiment provides conditions or constraints that can allow modification of dynamic parameters.

[0052] Figure 3 A protocol diagram of a communication sequence for activating a VNF package in one embodiment is shown. In this example, as part of the loading (i.e., loading) process, NFVO 302 receives or activates the VNF package. The VNF package is provided to NFVO 302 to configure a network virtualization session or instance. NFVO 302 communicates with VNFD 306 to access VNFD parameters 310. NFVO 302 determines which VNFD parameters in VNFD parameters 310 are dynamic VNFD parameters. Then, NFVO 302 interacts with the OAM system 304 to obtain configuration information 320 for the dynamic VNFD parameters.

[0053] Figure 4 A protocol diagram of a communication sequence for retrieving configuration parameters from an OAM system in one implementation is shown. A network virtualization system or service with a more flexible customized VNFD template can execute complex VNF LCM applications. A request for performing VNF LCM is provided to the VNFM 402 to configure a network virtualization session or instance. The VNFM 402 communicates with the VNFD 406 to access the VNFD parameters 410. The VNFM 402 determines which of the VNFD parameters 410 are dynamic VNFD parameters. Then, the VNFM 402 interacts with the OAM system 404 to obtain configuration information 420 for the dynamic VNFD parameters.

[0054] Figure 5 A protocol diagram of a communication sequence for establishing quotas for VNF instances is shown. As shown, the communication sequence begins when the NFVO sends a quota request 510 to the VIM 506. The quota request 510 can request quota information for one or more VNF instances. The VIM 506 can return a quota response 520 including the requested quota information to the NFVO 502. Then, the NFVO 502 can allocate quotas to one or more VNF instances using the quota information. When the quota response 520 is transmitted from the VIM 506 to the NFVO 502, there can be various ways to allocate quotas to a given VNF instance. In one implementation, the VNFM 504 sends a VNF lifecycle management (LCM) authorization request 530 to the NFVO 502. In such an implementation, the NFVO 502 can return an authorization 540 including the quota for the given VNF instance to the VNFM 504.

[0055] In another implementation, the VNFM 504 sends a quota query request 550 to the NFVO 502. In such an implementation, the NFVO 502 can return a response 560 that includes the quota for the given VNF instance. In another implementation, the NFVO 502 sends a resource notification message 570 specifying the quota for the given VNF instance to the VNFM 504. Then, the VNFM 504 returns a response 580 to the NFVO.

[0056] Figure 6A protocol diagram of communication sequence 600 for allocating resources to a VNF instance based on a quota is shown. As shown, communication sequence 600 starts when the VNFM 604 begins a VNF LCM operation, at which time the VNFM 604 determines that the amount of resources required by the VNF instance is less than or equal to the maximum amount of resources specified by the corresponding quota. Thereafter, the VNFM 605 sends a resource allocation request 610 to the VIM 606 to request the allocation of a certain amount of resources to the VNF instance. The amount of resources requested by the resource allocation request 610 is less than or equal to the maximum amount of resources specified by the corresponding quota. After verifying that the amount of resources requested by the resource allocation request 610 is less than or equal to the maximum amount of resources specified by the quota, the VIM 606 sends a resource allocation response 620 to the VNFM to indicate that the resource request has been approved. Then, the VNFM 604 and the VIM 606 send quota usage notifications 630, 640 to the NFVO 602 to notify the NFVO 602 of how many resources have been allocated to the corresponding VNF instance.

[0057] Figure 7 A protocol diagram of communication sequence 700 for increasing the size of a quota is shown. As shown, communication sequence 700 starts when the VNFM 704 begins a VNF LCM operation, at which time the VNFM 704 determines that the amount of resources required by the corresponding VNF instance exceeds the maximum amount of resources specified by the corresponding quota. Then, the VNFM 704 requests an increase in the quota. There are various ways to accomplish this. In one embodiment, the VNFM 704 sends a VNF LCM authorization request 710 to the NFVO 702 to request an increase in the quota size. Then, the NFVO 702 and the VIM 706 exchange request / response messages 720 to update the quota, after which the NFVO 702 sends an authorization 730 to the VNFM 704. The authorization 730 includes information about the updated / enlarged quota.

[0058] In another embodiment, the VNFM 704 sends a request quota enlargement message 740 to the NFVO 702 to request an increase in the quota size. Then, the NFVO 702 and the VIM 706 exchange request / response messages 750 to update the quota, after which the NFVO 702 sends a quota enlargement response message 760 to the VNFM 704. The quota enlargement response message 760 includes information about the updated / enlarged quota. After the quota is increased, the VNFM 704 and the VIM 706 exchange resource request / response messages 770 to allocate resources to the VNF instance.

[0059] Figure 8A protocol diagram of communication sequence 800 for reducing the size of a quota as can be triggered by a policy related to the quota is shown. As shown, the VNFM 804 sends a request 810 to the NFVO 802. The request 810 requests to reduce the quota associated with the VNF instance. Thereafter, the NFVO 802 exchanges request / response messages 820 with the VIM 806 to reduce the size of the quota, and thereafter, the NFVO 802 sends a quota reduction response 830 to the VNFM 804.

[0060] Figure 9 A flowchart of a method 900 for dynamically updating VNF descriptor (VNFD) parameters as can be executed by a management entity in one embodiment is shown. At step 910, the management entity receives the VNFD associated with the VNF or VNF instance. At step 920, the management entity determines whether the VNFD parameters in the VNFD can be dynamically updated based on one or more sub-fields of the VNFD parameters. In one embodiment, the VNFD parameters include a parameter sub-field, a writeability sub-field, an access permission sub-field, a management priority sub-field, and / or a constraint sub-field. The parameter sub-field indicates the name of the VNFD parameter. The writeability sub-field indicates whether the VNFD parameter is a dynamic / configurable VNFD parameter or a fixed / static VNFD parameter. A dynamic / configurable VNFD parameter is writable, which means it can be dynamically updated. A static VNFD parameter is read-only. The access permission sub-field identifies which entities are allowed to update the VNFD parameter. The management priority sub-field indicates the priority of the entity that last updated the sub-field. The constraint sub-field indicates one or more conditions that need to occur in order to update the VNFD parameter. At step 930, the management entity updates the VNFD parameter.

[0061] Figure 10 A flowchart of a method 1000 for managing a quota as can be executed by the VNFM in one embodiment is shown. At step 1010, the VNFM receives a quota information notification from a network function virtualization operator (NFVO). The quota information notification corresponds to the quota allocated to the VNFM or to one or more VNF instances managed by the VNFM. At step 1020, the VNFM sends a quota management request to the NFVO to update the quota initially set by the NFVO or to request information related to the quota initially set by the NFVO. At step 1030, the NFVM receives a response to the quota management request from the NFVO.

[0062] In some embodiments, the VnfConfigurableProperties information element defines the configurable properties of a VNF or a VNF instance. For a VNF instance, the values of these properties can be modified by the VNFM. Table 1 includes some of the properties of the VnfConfigurableProperties information element.

[0063] Table 1

[0064]

[0065] Figure 11 is a block diagram of a processing system 1100 that can be used to implement the apparatus and methods disclosed herein. A particular apparatus may utilize all of the components shown or only a subset of the components, and the level of integration may vary from apparatus to apparatus. Additionally, the apparatus may include multiple instances of components, such as multiple processing units, multiple processors, multiple memories, multiple transmitters, multiple receivers, etc. The processing system 1100 may include a processing unit equipped with one or more input / output devices such as speakers, microphones, touchscreens, keypads, mouse / keyboard / printer 1107, display 1108, etc. The processing unit may include a central processing unit (CPU) 1110, a memory 1115, a mass storage device 1120, a video adapter 1125, and an I / O interface 1130 connected to a bus 1135.

[0066] The bus 1135 can be one or more of any type of several bus architectures, including a memory bus or a memory controller, a peripheral bus, a video bus, and so on. The CPU 1110 can include any type of electronic data processor. The memory 1115 can include any type of non-transitory system memory, such as static random access memory (SRAM), dynamic random access memory (DRAM), synchronous DRAM (SDRAM), read-only memory (ROM), and combinations thereof, and so on. In one embodiment, the memory 1115 can include ROM used at power-on and DRAM used for storing programs and data when executing programs.

[0067] The mass storage device 1120 can include any type of non-transitory storage device configured to store data, programs, and other information and to enable access to such data, programs, and other information via the bus 1135. The mass storage device 1120 can include, for example, one or more of the following: solid state drives, hard disk drives, disk drives, optical disc drives, and the like.

[0068] The video adapter 1125 and the I / O interface 1130 provide interfaces for coupling external input and output devices to the processing unit. As illustrated, examples of input and output devices include a display 1107 coupled to the video adapter 1125 and a mouse / keyboard / printer 1105 coupled to the I / O interface 1130. Other devices can be coupled to the processing unit, and additional or fewer interface devices can be utilized. For example, a serial interface such as a Universal Serial Bus (USB) (not shown) can be used to provide an interface for a printer.

[0069] The processing system 1100 also includes one or more network interfaces 1150, which can include wired links such as Ethernet cables and / or wireless links to access nodes or different networks 1155. The network interface 1150 enables the processing system 1100 to communicate with remote units via the network 1155. For example, the network interface 1150 can provide wireless communication via one or more transmitters / transmitting antennas and one or more receivers / receiving antennas. In one implementation, the processing system 1100 is coupled to a local area network or a wide area network 1155 for data processing and communication with remote devices, such as other processing units, the Internet, remote storage facilities, and the like.

[0070] Figure 12 An exemplary communication system 1200 that can be used to implement the apparatus and methods disclosed herein is shown. Generally, the system 1200 enables multiple wireless users to send and receive data and other content. The system 1200 can implement one or more channel access methods, such as code division multiple access (CDMA), time division multiple access (TDMA), frequency division multiple access (FDMA), orthogonal FDMA (OFDMA), or single-carrier FDMA (SC-FDMA).

[0071] In this example, the communication system 1200 includes user equipment (UE) 1210a - 1210c, radio access network (RAN) 1220a - 1220b, core network 1230, public switched telephone network (PSTN) 1240, Internet 1250, and other networks 1260. Although a specific number of these components or elements are shown in Figure 12 , any number of these components or elements may be included in system 1200.

[0072] UEs 1210a - 1210c are configured to operate and / or communicate in system 1200. For example, UEs 1210a - 1210c are configured to send and / or receive wireless or wired signals. Each of UEs 1210a - 1210c represents any suitable end - user device and may include a device (or may be referred to as): user equipment / device (UE), wireless transmit / receive unit (WTRU), mobile station, fixed or mobile subscriber unit, pager, cellular phone, personal digital assistant (PDA), smart phone, laptop computer, computer, touchpad, wireless sensor, or consumer electronic device.

[0073] Here, RAN 1220a and RAN 1220b respectively include base stations 1270a and 1270b. Each of base stations 1270a - 1270b is configured to wirelessly connect to one or more of UEs 1210a - 1210c to enable access to core network 1230, PSTN 1240, Internet 1250, and / or other networks 1260. For example, base stations 1270a - 1270b may include one or more of several well - known devices, such as base transceiver station (BTS), Node - B, evolved NodeB (eNodeB), home NodeB, home eNodeB, small / femto / pico or similar cells, site controller, access point (AP), or wireless router or server, router, switch, or other processing entity with a wired or wireless network.

[0074] In Figure 12In the illustrated embodiment, base station 1270a forms part of RAN 1220a, which may include other base stations, elements, and / or devices. Additionally, base station 1270b forms part of RAN 1220b, which may include other base stations, elements, and / or devices. Each of base stations 1270a - 1270b operates to transmit and / or receive wireless signals within a specific geographic area or range, sometimes referred to as a "cell". In some embodiments, multiple-input multiple-output (MIMO) techniques with multiple transceivers for each cell may be employed.

[0075] Base stations 1270a - 1270b communicate with one or more of UEs 1210a - 1210c using a wireless communication link via one or more air interfaces 1290. The air interface 1290 may utilize any suitable radio access technology.

[0076] It is envisioned that system 1200 may use multi-channel access functionality, including the scenarios described above. In a particular embodiment, the base stations and UEs are configured to implement the Long Term Evolution wireless communication standard (LTE), LTE Advanced (LTE-A), and / or LTE Broadcast (LTE-B). In some other embodiments, the base stations and UEs are configured to implement UMTS, HSPA, or HSPA+ standards and protocols. Of course, other multiple access schemes and wireless protocols may also be used.

[0077] RANs 1220a - 1220b communicate with core network 1230 to provide voice, data, applications, Voice over Internet Protocol (VoIP), or other services to UEs 1210a - 1210c. It should be understood that RANs 1220a - 1220b and / or core network 1230 may communicate directly or indirectly with one or more other RANs (not shown). Core network 1230 may also serve as a gateway access to other networks such as the Public Switched Telephone Network (PSTN) 1240, the Internet 1250, and other networks 1260. Additionally, some or all of UEs 1210a - 1210c may include functionality for communicating with different wireless networks using different wireless technologies and / or protocols via different wireless links.

[0078] Although Figure 12 an example of a communication system is shown, Figure 12Make various modifications. For example, the communication system 1200 may include any number of UEs, base stations, networks, or other components in any suitable configuration.

[0079] Figure 13 and Figure 14 illustrates exemplary apparatuses that may implement the methods and teachings according to the present disclosure. Specifically, Figure 13 illustrates an exemplary UE 1310, Figure 14 illustrates an exemplary base station 1420.

[0080] As Figure 13 shown, the UE 1310 includes at least one processing unit 1301, a transceiver 1302, an antenna 1304, an input / output 1306, and a memory 1308. The antenna 1304 is configured to transmit wireless signals 1390. The processing unit 1301 implements various processing operations of the UE 1310. For example, the processing unit 1301 may perform signal encoding, data processing, power control, input / output processing, or any other function that enables the UE 1310 to operate in the system. The processing unit 1301 also supports the methods and teachings described in detail above. Each processing unit 1301 includes any suitable processing device or computing device configured to perform one or more operations. Each processing unit 1301 may include, for example, a microprocessor, a microcontroller, a digital signal processor, a field programmable gate array, or an application specific integrated circuit.

[0081] The UE 1310 also includes at least one transceiver 1302. The transceiver 1302 is configured to modulate data or other content transmitted by at least one antenna 1304. The transceiver 1302 is also configured to demodulate data or other content received by at least one antenna 1304. Each transceiver 1302 includes any suitable structure for generating signals for wireless transmission and / or processing wirelessly received signals. Each antenna 1304 includes any suitable structure for transmitting and / or receiving wireless signals. One or more transceivers 1302 may be used in the UE 1310, and one or more antennas 1304 may be used in the UE 1310. Although the transceiver 1302 is shown as a single functional unit, the transceiver 1302 may also be implemented using at least one transmitter and at least one separate receiver.

[0082] The UE 1310 also includes one or more input / outputs 1306. The input / output 1306 facilitates interaction with the user. Each input / output 1306 includes any suitable structure for providing information to the user or receiving information from the user, such as a speaker, a microphone, an auxiliary keyboard, a keyboard, a display, or a touch screen.

[0083] In addition, UE 1310 includes at least one memory 1308. The memory 1308 stores instructions and data used, generated, or collected by UE 1310. For example, the memory 1308 may store software or firmware instructions executed by the processing unit 1301 and may store data for reducing or eliminating interference in the input signal. The at least one memory 1308 may include one or more storage devices and may include any suitable volatile and / or non-volatile storage and retrieval means. Any suitable type of memory such as random access memory (RAM), read only memory (ROM), hard disk, optical disk, subscriber identity module (SIM) card, memory stick, secure digital (SD) memory card, etc. may be used. In some examples, UE 1310 may be implemented by Figure 11 processing system 1100.

[0084] As Figure 14 shown, base station 1420 includes at least one processing unit 1450, at least one transmitter (TX) 1452, at least one receiver (RX) 1454, one or more antennas 1456, and at least one memory 1458. The processing unit 1450 implements various processing operations of base station 1420 such as signal encoding, data processing, power control, input / output processing, or any other function. The processing unit 1450 may also support the methods and teachings described in detail above. Each processing unit 1450 includes any suitable processing means or computing device configured to perform one or more operations. Each processing unit 1450 may include, for example, a microprocessor, a microcontroller, a digital signal processor, a field programmable gate array, or an application specific integrated circuit.

[0085] Each transmitter 1452 includes any suitable structure for generating signals for wireless transmission to one or more UEs or other devices. Each receiver 1454 includes any suitable structure for processing signals wirelessly received from one or more UEs or other devices. Although the transmitter 1452 and the receiver 1454 are shown as separate components, at least one transmitter 1452 and at least one receiver 1454 can be combined into a transceiver (TX / RX). Each antenna 1456 includes any suitable structure for transmitting and / or receiving wireless signals. Although the common antenna 1456 is shown here as being coupled to both the transmitter 1452 and the receiver 1454, one or more antennas 1456 can be coupled to the transmitter 1452 and one or more separate antennas 1456 can be coupled to the receiver 1454. Each memory 1458 includes any suitable volatile and / or non-volatile storage and retrieval means. In some examples, the base station 1420 can be implemented by Figure 11 the processing system 1100.

[0086] Although the present invention has been described with reference to illustrative embodiments, the description is not intended to be construed in a limiting sense. After reviewing this description, various modifications and combinations of the illustrative embodiments, as well as other embodiments of the present invention, will be apparent to those skilled in the art. Accordingly, it is intended that the appended claims cover any such modifications or embodiments.

Claims

1. A method for dynamically configuring virtual network function (VNF) parameters, characterized in that, the method includes: A virtual network function manager (VNFM) obtains virtual network function descriptor (VNFD) parameters; The VNFM determines whether the VNFD parameters are dynamically configurable VNFD parameters according to the VnfConfigurableProperties information element, wherein the VnfConfigurableProperties information element indicates whether the VNFD parameters are dynamically configurable VNFD parameters, and the VNFD parameters include the autoHealable attribute; When the VNFD parameters are dynamically configurable VNFD parameters, the VNFM configures the dynamically configurable VNFD parameters.

2. The method according to claim 1, characterized in that, the VnfConfigurableProperties information element also indicates whether the autoScalable attribute is dynamically configurable.

3. The method according to claim 1 or 2, characterized in that, the VNFM determines whether the VNFD parameters are dynamically configurable VNFD parameters according to the VnfConfigurableProperties information element, including: Determining whether the VNFD parameters are listed in the VnfConfigurableProperties information element.

4. The method according to any one of claims 1-2, characterized in that, the method further includes: Determining that the VNFM is authorized to reconfigure the autoScalable function of the VNF or VNF instance according to the access permission subfield of the VnfConfigurableProperties information element.

5. The method according to any one of claims 1-2, characterized in that, the method further includes: Determining that the VNFM has a higher management priority than the entity that previously configured the autoScalable function of the VNF or VNF instance according to the management priority subfield of the VnfConfigurableProperties information element.

6. The method according to any one of claims 1-2, characterized in that, the VnfConfigurableProperties information element is received from a network function virtualization operator (NFVO).

7. The method according to any one of claims 1-2, characterized in that, the method further includes: The VNFM determines that the autoHealable function of the VNF or VNF instance is dynamically configurable according to the autoHealable attribute indicated by the VnfConfigurableProperties information element; The VNFM modifies the autoHealable function of the VNF or VNF instance in response to the autoHealable function being dynamically configurable.

8. The method according to claim 7, wherein, the method further comprises: before the VNFM modifies the autoHealable function of the VNF or VNF instance, disabling the autoHealable function of the VNF or VNF instance, and the VNFM enables the autoHealable function of the VNF or VNF instance by modifying the autoHealable function of the VNF or VNF instance.

9. The method according to claim 7, wherein, the method further comprises: before the VNFM modifies the autoHealable function of the VNF or VNF instance, enabling the autoHealable function of the VNF or VNF instance, and the VNFM disables the autoHealable function of the VNF or VNF instance by modifying the autoHealable function of the VNF or VNF instance.

10. The method according to any one of claims 1-2, wherein, the method further comprises: the VNFM modifies the attributes of the VNFD parameters to reflect the modification of the characteristics of the VNF or VNF instance.

11. The method according to claim 10, wherein, the VNFM modifies the attributes of the VNFD parameters to reflect the modification of the characteristics of the VNF or VNF instance includes: modifying the attributes of the VNFD parameters to reflect an increase or decrease in the number of virtual deployment units (VDUs), the number of virtual links, or the number of connection points in the VNF or VNF instance.

12. The method according to claim 10, wherein, the VNFM modifies the attributes of the VNFD parameters to reflect the modification of the characteristics of the VNF or VNF instance includes: modifying the attributes of the VNFD parameters to reflect an increase or decrease in the resource quota of the VNF or VNF instance, where the resource quota specifies the maximum amount of resources that can be allocated to the VNF or VNF instance.

13. A device for dynamically configuring virtual network function (VNF) parameters, wherein, comprises: a processor; and a non-transitory computer-readable storage medium storing a program for execution by the processor, the program including instructions for performing the following operations: a virtual network function manager (VNFM) obtains virtual network function descriptor (VNFD) parameters; The VNFM determines whether the VNFD parameter is a dynamically configurable VNFD parameter according to the VnfConfigurableProperties information element, where the VnfConfigurableProperties information element indicates whether the VNFD parameter is a dynamically configurable VNFD parameter, and the VNFD parameter includes the autoHealable attribute; When the VNFD parameter is a dynamically configurable VNFD parameter, the VNFM configures the dynamically configurable VNFD parameter.

14. The device according to claim 13, wherein, the VnfConfigurableProperties information element also indicates whether the autoScalable attribute is dynamically configurable.

15. The device according to claim 13 or 14, wherein, the VNFM determines whether the VNFD parameter is a dynamically configurable VNFD parameter according to the VnfConfigurableProperties information element, including: determining whether the VNFD parameter is listed in the VnfConfigurableProperties information element.

16. The device according to any one of claims 13-14, wherein, it is determined that the VNFM is authorized to reconfigure the autoScalable function of the VNF or VNF instance according to the access permission subfield of the VnfConfigurableProperties information element.

17. The device according to any one of claims 13-14, wherein, it is determined that the VNFM has a higher management priority than the entity that previously configured the autoScalable function of the VNF or VNF instance according to the management priority subfield of the VnfConfigurableProperties information element.

18. The device according to any one of claims 13-14, wherein, the VnfConfigurableProperties information element is received from a network function virtualization operator NFVO.

19. The device according to any one of claims 13-14, wherein, it is determined by the VNFM that the autoHealable function of the VNF or VNF instance is dynamically configurable according to the autoHealable attribute indicated by the VnfConfigurableProperties information element; the VNFM modifies the autoHealable function of the VNF or VNF instance in response to the autoHealable function being dynamically configurable.

20. The device according to claim 19, wherein, Before the VNFM modifies the autoHealable function of the VNF or VNF instance, disable the autoHealable function of the VNF or VNF instance, and the VNFM enables the autoHealable function of the VNF or VNF instance by modifying the autoHealable function of the VNF or VNF instance.

21. The apparatus according to claim 19, wherein, before the VNFM modifies the autoHealable function of the VNF or VNF instance, enable the autoHealable function of the VNF or VNF instance, and wherein the VNFM disables the autoHealable function of the VNF or VNF instance by modifying the autoHealable function of the VNF or VNF instance.

22. The apparatus according to any one of claims 13-14, wherein, the VNFM modifies the attributes of the VNFD parameters to reflect the modification of the characteristics of the VNF or VNF instance.

23. The apparatus according to claim 22, wherein, the VNFM modifies the attributes of the VNFD parameters to reflect the modification of the characteristics of the VNF or VNF instance, including: modifying the attributes of the VNFD parameters to reflect an increase or decrease in the number of virtual deployment units (VDUs), the number of virtual links, or the number of connection points in the VNF or VNF instance.

24. The apparatus according to claim 22, wherein, the VNFM modifies the attributes of the VNFD parameters to reflect the modification of the characteristics of the VNF or VNF instance, including: modifying the attributes of the VNFD parameters to reflect an increase or decrease in the resource quota of the VNF or VNF instance, where the resource quota specifies the maximum amount of resources that can be allocated to the VNF or VNF instance.

25. An apparatus for dynamically configuring virtual network function (VNF) parameters, wherein, comprises units or modules for performing the method according to any one of claims 1-12.

26. A computer-readable storage medium, wherein, the computer-readable storage medium is used to store a program, which when executed by a processor, implements the method performed by a virtual network function manager (VNFM) according to any one of claims 1-12.

Images