Power management components and methods for virtual network functions

Abstract

According to an embodiment, a power management component is described. The power management component has a memory configured to store, for a virtual network function, a power saving profile for each of a plurality of power states of the virtual network function. For each power state, the power saving profile indicates an amount of physical data processing resources used by the virtual network function in that power state, an amount of a virtualized container provided by the physical resources used by the virtual network function in that power state, and a service capacity of a network function operating on the virtualized container provided in that power state. The power management component has a controller configured to select one of the power states for the virtual network function and to control the virtual network function to operate in accordance with the power saving profile stored for the selected power state.

Description

[Technical Field]

[0001] The present disclosure relates to power management components and methods for virtual network functions. [Background technology]

[0002] In communication systems, as in many technical systems, it is desirable to consume as little power as possible. This is particularly relevant for virtual network functions of communication systems, which include multiple "layers": physical resources, virtual resources (i.e., virtualized containers), and the actual application (i.e., the actual network function). All these layers affect power consumption and, on the one hand, provide many degrees of freedom for power management, but on the other hand, complicate optimal power management for virtual network functions. Therefore, an approach that allows for effective power consumption optimization for virtual network functions is desirable. Summary of the Invention [Means for solving the problem]

[0003] According to an embodiment, a power management component is provided, the power management component comprising: a memory configured to store, for a virtual network function, a power saving profile for each of a plurality of power states of the virtual network function, wherein, for each power state, the power saving profile comprises: the amount of physical data processing resources used by the virtual network function in the power state; The amount of virtualized containers (VMs and OS containers) deployed on the physical resources used by the virtual network function in the power state; and -Indicating the service capacity of the network functions running on the virtualized containers provided in the power state; memory and; a controller, selecting one of the power states for the virtual network function; controlling the virtual network function to switch from a first power state to a second power state; storing operational state information about the virtual network function when controlling the virtual network function to switch from the first power state to the second power state; configuring the virtual network function to take into account the stored operational state information when controlling the virtual network function to switch from the second power state to the selected power state; configured to control the virtual network function to operate in accordance with a stored power saving profile for a selected power state; and a controller.

[0004] In the drawings, like reference numbers generally refer to the same parts throughout the various views. The drawings are not necessarily to scale, emphasis instead generally being placed upon illustrating the principles of the invention. In the following description, various aspects are described with reference to the following drawings: [Brief explanation of the drawings]

[0005] [Figure 1] 1 shows a mobile wireless communication system. [Figure 2] Presents the architecture, including the Network Functions Virtualization Management and Omnibus (NFV-MANO) architecture framework. [Figure 3] 1 illustrates the addition of a VNF power manager to a VNF generic OAM (Operations, Administration, and Maintenance) function according to an embodiment. [Figure 4] Two VNFs running on virtualized containers are shown. [Figure 5] The state diagram of the VNF (power) state machine is shown. [Figure 6] 1 shows VNF operation state information for a VNF in normal operation mode, followed by VNF operation state information for a VNF after entering sleep mode, followed by VNF operation state information for a VNF in normal operation mode. [Figure 7]It shows a VNF deployment with two VNF components belonging to one VNF and deployed in a distributed manner. [Figure 8] A flow diagram of VNF configuration related to power management is shown. [Figure 9] 1 shows a flow diagram illustrating a method for registering a VNF for power management purposes. [Figure 10] 1 shows a flow diagram illustrating how to set a VNF to sleep mode. [Figure 11] 1 shows a flow diagram illustrating how a VNF can be restored from sleep mode to normal operating mode power management. [Figure 12] 1 illustrates a power management component according to an embodiment. [Figure 13] 1 shows a flow diagram illustrating a method for power management of virtual network functions. DETAILED DESCRIPTION OF THE INVENTION

[0006] The following detailed description refers to the accompanying drawings which show, by way of example, specific details and aspects of the present disclosure in which the present invention may be practiced. Other aspects may be utilized and structural, logical, and electrical changes may be made without departing from the scope of the present invention. The various aspects of this disclosure are not necessarily mutually exclusive, and some aspects of this disclosure may be combined with one or more other aspects of this disclosure to form new aspects.

[0007] Various examples corresponding to aspects of this disclosure are provided below.

[0008] Example 1 is a power management component, the power management component comprising: a memory configured to store, for a virtual network function, a power saving profile for each of a plurality of power states of the virtual network function, the power saving profile comprising: the amount of physical data processing resources used by the virtual network function in that power state; the amount of virtualized containers deployed on the physical resource used by the virtual network function in that power state; and Indicating the service capacity of the network functions running on the virtualized container provided in that power state; memory and; a controller, Selecting one of the power states for the virtual network function; controlling the virtual network function to switch from a first power state to a second power state; storing operational state information about the virtual network function when controlling the virtual network function to switch from the first power state to the second power state; configuring the virtual network function to take into account the stored operational state information when controlling the virtual network function to switch from the second power state to a selected power state; configured to control the virtual network function to operate in accordance with a power saving profile stored for the selected power state; a controller; It is a power management component.

[0009] Example 2 is the power management component of example 1 including an input interface configured to receive information indicating that a power state of the virtual network function should be changed, wherein the controller is configured to, in response to receiving the information, select one of the power states and control the virtual network function to operate in accordance with a power saving profile stored for the selected power state.

[0010] A third embodiment is the power management component of the second embodiment, in which the information is a request to change the power state from a current state.

[0011] A fourth embodiment is the power management component of the second or third embodiment, wherein the information includes information about power consumption of the virtual network function.

[0012] Example 5 is the power management component of any one of Examples 1 to 4, wherein each power saving profile indicates power consumption of operation of the virtual network function according to the power saving profile.

[0013] Example 6 is the power management component of any one of Examples 1 to 5, wherein each power saving profile further specifies a number of virtual network function components of the virtual network function that are operated with that power saving profile.

[0014] Example 7 is the power management component of any one of examples 1 to 6, wherein the controller is configured to determine power consumption for each power saving profile based on power consumption measurements.

[0015] Example 8 is the power management component of any one of Examples 1-5, wherein the controller is configured to, for each power saving profile, include the determined power consumption in the power saving profile.

[0016] Example 9 is the power management component of example 7 or 8, wherein the power management component is configured to select the power state taking into account the determined power consumption.

[0017] Example 10 is the power management component of any one of Examples 1 to 9, wherein the controller is configured to control the virtual network function to switch from a first power state to a second power state, and the controller is configured to store operational state information for the virtual network function when controlling the virtual network function to switch from the first power state to the second power state, and to configure the virtual network function taking the stored operational state information into account when controlling the virtual network function to switch from the second power state to the selected power state.

[0018] Example 11 is the power management component of example 10, wherein the controller is configured to configure the virtual network function according to stored operating state information as permitted by a stored power saving profile for a selected power state.

[0019] Example 12 is the power management component of example 11, wherein the memory is configured to store, for each of a plurality of virtual network functions, a separate power saving profile for each of a plurality of power states of the virtual network function.

[0020] Example 13 is a method for power management of a virtual network function, comprising: storing, for a virtual network function, a power saving profile for each of a plurality of power states of the virtual network function, wherein, for each power state, the power saving profile comprises: the amount of physical data processing resources used by the virtual network function in that power state; the amount of virtualized containers (VMs and OS containers) deployed on the physical resource used by the virtual network function in that power state; and Indicating the service capacity of the network functions running on the virtualized container provided in that power state; stages and; selecting one of the power states for the virtual network function; controlling the virtual network function to switch from a first power state to a second power state; storing operational state information about the virtual network function upon controlling the virtual network function to switch from the first power state to the second power state; configuring the virtual network function to take into account the stored operational state information when controlling the virtual network function to switch from the second power state to a selected power state; controlling the virtual network function to operate in accordance with a power saving profile stored for the selected power state.

[0021] It should be noted that one or more features of any of the above examples may be combined with any of the other examples, and in particular, embodiments described in the context of a device are equally valid for a method.

[0022] According to further embodiments, there is provided a computer program and computer readable medium comprising instructions that, when executed by a computer, cause the computer to perform the method of any of the above examples.

[0023] Various examples are described in more detail below.

[0024] FIG. 1 shows a mobile radio communication system 100 configured in accordance with 5G (Fifth Generation) standards, for example as defined by 3GPP (Third Generation Partnership Project).

[0025] The mobile radio communication system 100 includes a mobile radio terminal 102, such as a UE (user equipment). The mobile radio terminal 102, also called a subscriber terminal, forms the terminal side, while the other components of the mobile radio communication system 100 described below are part of the mobile communication network side, i.e., a mobile communication network (e.g., a Public Land Mobile Network, PLMN).

[0026] Furthermore, the mobile wireless communication system 100 includes a Radio Access Network (RAN) 103, which may include multiple radio access network nodes, i.e., base stations configured to provide radio access according to 5G (Fifth Generation) radio access technology (5G New Radio). Note that the mobile wireless communication system 100 may also be configured according to LTE (Long Term Evolution) or other mobile wireless communication standards (e.g., non-3GPP access such as Wi-Fi), but 5G is used here as an example. Each radio access network node may provide radio communication with the mobile wireless terminal 102 over the air interface. It should be noted that the radio access network 103 may include any number of radio access network nodes.

[0027] The mobile radio communication system 100 further includes a core network (5GC) 119 including an Access and Mobility Management Function (AMF) 101 connected to the RAN 103, a Unified Data Management (UDM) 104, and a Network Slice Selection Function (NSSF) 105. Here and in the following examples, the UDM may further comprise an actual UE subscription database, known for example as a Unified Data Repository (UDR). The core network 119 further includes an Authentication Server Function (AUSF) 114, a Policy Control Function (PCF) 115, and an application function (AF) 120.

[0028] The core network 119 may have multiple core network slices 106, 107, and for each core network slice 106, 107, an operator (also referred to as MNO, for Mobile Network Operator) may create multiple core network slice instances 108, 109. For example, the core network 119 includes a first core network slice 106 having three core network slice instances (C-NSIs) 108 for providing Enhanced Mobile Broadband (eMBB) and a second core network slice 107 having three core network slice instances (NSIs) 109 for providing Vehicle-to-Everything (V2X).

[0029] Typically, when a core network slice is deployed (i.e., generated), network functions (NFs) are instantiated or (if already instantiated) referenced to form a core network slice instance, and the network functions belonging to the core network slice instance are configured with a core network slice instance identification information.

[0030] Specifically, in the illustrated example, each instance 108 of the first core network slice 106 includes a first session management function (SMF) 110 and a first user plane function (UPF) 111, and each instance 109 of the second core network slice 107 includes a second session management function (SMF) 112 and a second user plane function (UPF) 113. The SMFs 110, 112 are for handling PDU (Protocol Data Unit) sessions, i.e., for creating, updating, and removing PDU sessions and managing session contexts with the user plane function (UPF).

[0031] The RAN 103 and the core network 119 form the network side of the mobile radio communication system, i.e., form a mobile radio communication network. The mobile radio communication network and the mobile terminals that access the mobile radio communication network together form the mobile radio communication system.

[0032] Similar to the core network 119, the RAN 103 may also be sliced, i.e., may include multiple RAN slices. RAN slices and core network slices 106, 107 may be grouped to form a network slice.

[0033] Hereinafter, "network slice" (or simply "slice") generally refers to a core network slice, but may also include a RAN slice and a transport network slice.

[0034] The mobile wireless communication system 100 may further include an OAM (Operation, Administration, and Maintenance) function (or entity) 116, implemented, for example, by one or more OAM servers connected to the RAN 103 and the core network 119 (connections not shown for simplicity). The OAM 116 may include an MDAS (Management Data Analytics Service). The MDAS may provide, for example, analytical reports on the load of the network slice instance. Various factors may affect the load of the network slice instance, such as the number of UEs accessing the network, the number of QoS flows, and the resource utilization of various NFs associated with the network slice instance.

[0035] Additionally, the core network 118 includes a Network Repository Function (NRF).

[0036] The core network 119 may further include a Network Data Analytics Function (NWDAF) 117. The NWDAF is responsible for providing network analysis and / or forecast information upon request from the network functions.

[0037] Various network functions can be implemented on specialized hardware, i.e., so-called ACTA (Advanced Telecommunications Computing Architecture) devices. This means that the network functions are implemented as physical network functions deployed on specialized hardware. The software for implementing the network functions is tightly coupled to the hardware.

[0038] However, it may also be desirable to implement network functions as software applications running on virtual machines (and / or containers) deployed on non-specialized hardware, i.e., commercial off-the-shelf (COTS) servers (i.e., on general-purpose or open computing platforms, i.e., devices). This is made possible by virtualization technologies (e.g., hypervisors, operating system (OS) containers, etc.). Network functions (e.g., SMF, PCF, etc.) can be deployed in virtual machines (VMs with one or more vCPUs) and / or (operating system (OS)) containers (containers can be considered "lightweight" VMs). These are called virtual network functions (VNFs). VMs and OS containers are referred to herein by the general term "virtualization container."

[0039] Network Function Virtualization Management and orchestration (NFV-MANO) is a key element of the ETSI (European Telecommunications Standards Institute) network functions virtualization (NFV) architecture. MANO is an architectural framework that orchestrates network resources for cloud-based applications and orchestrates the lifecycle management of virtual network functions (VNFs) and network services. As such, it is critical to ensuring rapid and reliable NFV deployment at scale. MANO includes, among other components, an NFV orchestrator (NFVO), a VNF manager (VNFM), and a virtual infrastructure manager (VIM).

[0040] Figure 2 shows a simplified version of the OSS / BSS (operations support system and business support system) 201 and Network Functions Virtualization Management and Orchestration (NFV-MANO) architectural framework, which includes a collection of function blocks and functions, data repositories used by these function blocks, and reference points and interfaces through which these function blocks exchange information to manage and orchestrate NFVs.

[0041] Specifically, MANO includes NFVO 202, VNFM 203, VIM 204, and container Infrastructure Service Management (CISM) 205. In the following, CISM 205 is assumed to be part of VIM 204, and thus only VIM 204 will be referenced (i.e., VIM 204 and CISM 205 are grouped together as indicated by the dashed line and referred to as VIM 204).

[0042] The NFVO 202 manages network services (NSs) 206, which in this example include an AMF 207, an SMF 208, a PCF 209, and an AF 210. A network service (NS) is a mix of network functions and / or services that are defined by their functional and behavior specifications.

[0043] The architecture 200 further includes an NFVI 211 that includes the hardware and software components that create the environment in which the VNFs are deployed.

[0044] In this example, the SMF 208, PCF 209, and AF 210 are implemented as VNFs, i.e., as NFs deployable on an NFVI 211. The PCF 209 is implemented by a container 212 running on a virtual machine, the AF 210 on a virtual machine 213, and the SMF 208 in a container 214, all running on a COTS server 215. In contrast, the AMF 207 is implemented on an ATCA device 216, i.e., it is a physical network function.

[0045] The NFVO 202 manages the NS lifecycle and coordinates the management of the NS lifecycle, the VNF lifecycle (supported by the VNFM 203) and the NFVI resources (supported by the VIM 204) to ensure optimized allocation of required resources and connectivity.

[0046] The VNFM 203 is responsible for the lifecycle management of the VNFs.

[0047] The VIM 204 is the functional block responsible for the control and management of the computing, storage, and network resources of the NFVI, typically within an operator's infrastructure domain.

[0048] It is important to note that the 3GPP Network Function is responsible for the management and configuration of Network Functions (NFs) and the interaction between NFs, but not for managing the virtualized Network Functions aspect. In fact, the 3GPP Function does not even know if a Network Function is virtualized or not. From the ETSI NFV-MANO point of view, it is irrelevant which are the actual NFs "hosted" within the VNF.

[0049] 3GPP Network Functions (element managers communicating with the OSS) manage network functions, and NFV-MANO (also communicating with the OSS) manages the VNFs that implement (i.e., host) them.

[0050] From the NFV-MANO perspective, VNF management (life cycle management (LCM) such as configuration, update, release, etc.) is done by NFV-MANO (specifically the VNFM), and its configuration is done by the element manager.

[0051] To save power, for example, in an O-RAN-based deployment when VNFs are managed by NFV-MANO, power management can be performed as follows: The prerequisite is that the NF (e.g., distributed unit (DU)) is registered with the OSS and radio usage is reported from the RU (radio hardware unit) to the DU every minute. The decision to enter sleep mode is made based on the radio usage (e.g., by the non-RT-RIC (non-real-time RAN intelligent controller) or the MDAF (Management Data Analytics Function) in the MANO, or the VNF power manager VNF generic OAM function, or through their interaction). The network functions to be dropped (i.e., to enter sleep mode) are determined by comparing resource block (RB) usage rates, overlay information, and sleep mode target cells (etc.). Note that in O-RAN, the RIC decides which NFs to turn off and cooperates with the NFV-MANO to turn off power to NFVIs or stop VMs.

[0052] According to various embodiments, an approach for power management of VNFs is provided that takes into account the special characteristics that make up a VNF (i.e., jointly considers physical and virtual resources, application and / or VNF LCM, i.e., jointly considers VNF power management (application and virtual resources) and underlying physical power management). Thus, according to various embodiments, power management is considered from the perspective of the VNF (e.g., rather than purely from the perspective of radio resources (e.g., RBs)). In particular, it includes the definition of various power modes of the VNF (including, in particular, a sleep mode), state transitions between these power modes (e.g., between a VNF operational status and a VNF sleep mode), processes for managing the VNF in terms of power management, and introduces a function to perform VNF power management responsible for restoring the VNF operational state after any power state transition. According to various embodiments, power management interactions are enabled using not only NFV-MANO and OSS, but also all services provided by the VNF generic OAM function framework.

[0053] In particular, according to various embodiments, a VNF power management profile is established to enable power management at the VNF level, taking into account the separation between physical and software introduced by the virtualization layer. The VNF power management profile indicates how VMs, applications (i.e., provided network functions), and physical resources are affected by power state transitions.

[0054] Additionally, various embodiments provide a mechanism for (operational) state restoration that allows for maintaining a VNF's runtime information during sleep mode (and restoring it upon exiting sleep mode). This state information includes, for example, the VNF's identity, configuration information within the VNF / virtualization container, and NFV-MANO managed objects information during the VNF's power state transition. Furthermore, a VNF being restored from a low-power mode is enabled to recover the required compute, storage, and / or network resources and the correct power state without impacting peer entities during the state transition process.

[0055] According to various embodiments, the power management capabilities provided by the infrastructure and the management and governance system are leveraged as the elements subject to power consumption (physical operations). Additionally, according to various embodiments, the management and governance system (e.g., NFV-MANO) is used to help track original managed object information and configurations.

[0056] According to various embodiments, the above mechanisms, processes and functions are provided by a power management component, hereinafter referred to as the VNF Power Manager (VNF-PoMF).

[0057] This power management component may, for example, be deployed in a VNF generic OAM functional framework and can interact with several VNFs (possibly without considering interaction with NFV-MANO), as shown in Figure 3.

[0058] FIG. 3 illustrates the addition of a VNF power manager 300 within a VNF generic OAM function 301 framework according to one embodiment.

[0059] The VNF generic OAM function 301 includes, by way of example, a network configuration manager 302, a VNF upgrade function 303, and a VNF configuration manager 304, connected to a traffic enforcer 305. The VNF generic OAM function 301 further includes a notification manager 306 connected to a metric analyzer 307 and a log analyzer 308, which exchange information with a metric aggregator 309 and a log aggregator 310, respectively. The notification manager 306 is further connected to a time function 311 of the VNF generic OAM function 301. Different interactions between the VNF generic OAM functions are possible.

[0060] The VNF generic OAM function 301 (in particular the VNF power manager 300) is connected to (interconnected) virtualization-related components including the OSS 312, the MANO 313 (i.e., a configuration including, for example, the NFVO, the VNFM, and the VIM) and the NFVI 314, as described with reference to FIG. 2.

[0061] The VNF generic OAM function 301 further communicates with multiple VNFs 315 (only one of which is shown for simplicity). Although reference is made below to the VNF power manager 300, the functions, mechanisms, and processes described with respect thereto may be performed by a power management component or a power management component located elsewhere in the architecture (i.e., not necessarily part of the VNF generic OAM function framework; for example, a virtualization (e.g., NFV) management and governance system may manage and control the power state of a VNF).

[0062] The VNF power manager 300 has one or more of the following functions: Compiling VNF power profiles (these are also provided by NFV-MANO 313. For example, VNF power profiles can be described in descriptors used to deploy and manage VNFs). Collecting VNF-related power information by processing power consumption information obtained from the infrastructure (or its corresponding management system). · Collecting information about the power profile for each VNF 315 and correlating it with the actual VNF composition and usage of compute, storage, and / or network resources (physical and virtual). Manage all states related to VNF power modes (sleep, resume, etc.) and execute related state transitions. Resolve dependencies with other VNFs when performing power management (sleep / resume) on a VNF. Saving the operational and configuration state for a VNF (configuration, operational data, correct power state) and restoring it after a power management operation is performed.

[0063] The VNF power profile relates to application, virtual, and physical resource usage, as described in more detail below with reference to FIG.

[0064] 4 illustrates a first VNF ​​401 and a second VNF 402, which include, for example, respective applications (here, the first VNF ​​401 hosts an AMF 403 and the second VNF hosts an SMF 404, which are connected) and respective virtual resources 405, 406 provided by physical resources (here, the same physical resource 407, but which may be separate, e.g., separate computers).

[0065] Each power state for each VNF 401, 402 is associated with a respective VNF power profile. A VNF power profile considers, by way of example: · The relationship between applications and virtualized and physical resources. · Composition of virtualized resources and their capabilities / capacities. · VNF deployment flavors. VNF power policies provided by the management system.

[0066] Furthermore, the VNF power profile is adjusted by a management and governance system entity to calculate accurate power consumption based on various metrics (e.g., application KPIs, infrastructure resource power, etc.) With the adjusted profile, the entity responsible for power management of the VNFs (e.g., VNF power manager 300) can perform more accurate power consumption calculations.

[0067] Table 1 shows an example VNF power profile (e.g., for the first VNF ​​401). [Table 1]

[0068] Each of the example power condition profiles above may also indicate that the physical infrastructure is unaffected.

[0069] The second VNF 402 may have a different power profile than the first VNF ​​401. In particular, the sleep modes may be different for different VNFs.

[0070] For example, the profiles of the first VNF ​​401 and the second VNF 402 are defined as follows: When the VNF 401 enters sleep mode (for example, from normal operation mode) ■ At the application level, 100 threads are reduced to 10 threads ■ At the virtual resource level, 10 vCPS is reduced to 1 vCPU ■Physical nodes can be shut down at the physical resource level When the VNF 402 enters sleep mode (for example, from normal operation mode) ■ At the application level, 10,000 sessions are reduced to 100 sessions. ■VM is stopped at the virtual resource level ■ At the physical resource level, the CPU clock frequency is reduced from 10GHz to 1GHz.

[0071] Note that even if the allocated virtual resources and allocated physical resources are the same, the actual power consumption may differ between the application level in sleep mode and the application in an operational mode (e.g., serving more sessions or generally providing a higher service capacity).

[0072] The VNF power manager 300 may include, for example: A VNF power profile manager that compiles and updates VNF power profiles A VNF power metric analyzer that analyzes relevant VNF ​​power metrics and derives estimates, etc. A VNF power policy manager that receives and analyzes VNF power policies. A VNF power state controller that manages the VNF power state machine and transitions between states.

[0073] FIG. 5 shows a state diagram for the VNF (power) state machine.

[0074] In this example, the VNF has a sleep mode state 501, a sleeping (i.e., about to go to sleep) state 502, a resuming state 503, a normal operation state 504, a low power consumption mode state 505, and a high power consumption mode state 506.

[0075] Sleeping mode state 502 may be a low power consumption mode that is an intermediate state before sleep mode 501 (this is the "lowest power consumption mode").

[0076] The VNF power manager 300 uses a VNF power profile established for a VNF to determine the VNF power state and supported state transitions for that VNF. The VNF power profile provides information that the VNF power manager 300 can use to determine the power consumption of a VNF and to trigger transitions between states.

[0077] The VNF power manager 300 (eg, a VNF power state controller) may, for example, autonomously determine whether a state change is required.

[0078] Each power state is associated with a level of utilization at the application level, the virtual resource level, and the physical resource level, as explained above with reference to the power state profiles. In particular, the definition of sleep mode 501 takes into account all aspects that can affect the power consumption of the entire VNF. Thus, sleep mode 501 can be seen as combining SW (software) sleep mode and HW (hardware) sleep mode into a single framework. Thus, the interaction between them may be modeled to achieve both goals.

[0079] VNF sleep mode essentially combines SW sleep mode and HW sleep mode: entering SW sleep mode involves modifying the composition of the software modules that make up the VNF application to a minimal subset and / or performing a partial shutdown of certain software components that require less power.

[0080] Entering a HW sleep mode involves modifying the power state of the underlying physical infrastructure resources (e.g., compute) or changing some configuration (e.g., network equipment).

[0081] Additionally, as mentioned above, configuring the VNF sleep mode takes into account how the VNF recovers its associated configuration after returning from the VNF sleep mode 501 to the normal operation mode 504. For example, for a virtualized DU (vDU) or vDU component, the required cell configuration and topology are maintained during the VNF sleep mode 501 in order to recover it upon returning to the normal mode. Examples of VNF operation state information that are maintained and recovered are cell configuration, topology, network configuration, and application data.

[0082] FIG. 6 shows VNF operation state information 601 for a VNF in normal operation mode, followed by VNF operation state information 602 for a VNF after entering sleep mode, followed by VNF operation state information 603 for a VNF in normal operation mode (after exiting sleep mode).

[0083] As can be seen, during sleep mode, the VNF operating state information 602 may be at least partially changed with respect to the VNF operating state information 601 in normal operation mode. Upon re-entering (i.e., returning to) normal operation, the VNF power manager 300 attempts to restore the VNF state (configuration, data, etc.). To do this, various techniques can be used. For example: - Storing configuration and management information in a registry (with timestamps and versioning). ● Maintaining VNF configuration data held by the management and governance system. Creating a VNF or VNFC (VNF component) snapshot that preserves the state and configuration data of one or more associated VNFs or VNFCs and can be used in restoration procedures. ●Performing VNF restoration / resource reservation of virtualized and physical resources that are released by partial termination of a VNF (i.e., of a VNFC) in order to reserve resources when returning to normal operation mode. Tracking and mapping NFVI resources so that affected resources can be determined and their power state can be changed with respect to VNF sleeping modes. VNF restore and (partial) VNF re-instantiation events: VMs are recreated and associated with: ■The restored VNF / MANO managed object inherits the state of the previous MANO managed object. ■ (Optionally) Use reserved NFVI resources.

[0084] The VNF power manager 300 can then check whether VNF operating state information recovery has been achieved. Note that when the VNF power manager 300 sets a VNF to a (selected) power state, it restores the configuration of the VNF only as far as the power profile of the selected power state allows. For example, if a VNF was first in a high power consumption mode and then in a sleep mode and is now to be put into normal operation, it may not be possible to fully restore the VNF's configuration because it may not respect the power profile of normal operation.

[0085] As mentioned above, distributed deployment of VNFs may be taken into consideration in power management, particularly in VNF power state profiles.

[0086] FIG. 7 illustrates a deployment of a VNF 701 in a distributed manner with two VNF components 702, 703, in addition to two VNFs 704, 705, which in contrast are deployed in a non-distributed manner.

[0087] A Virtualized Network Function Component (VNFC) 702, 703 is an internal component of a VNF that provides a defined subset of the functionality of the VNF to the VNF provider, with the main feature that a single instance of this component is mapped, for example, 1:1, to a single virtualized container. The VNF power manager 300 can use (and establish) different VNFC power sub-profiles for the VNFCs of a VNF (as part of the VNF power state profile).

[0088] Thus, according to various embodiments, VNF power management (eg, as implemented by VNF power manager 300) can do one or more of the following: Use virtualized resource reservation to reserve virtualized resources for VNF power restoration. Use VNF snapshots to preserve and restore VNF state and configuration between VNF power management procedures. • Persist the state and configuration of the VNFs using repositories and databases managed by the management and governance system. Use mapping information between the state and configuration of VNF applications and VNF components and the underlying virtual and physical infrastructure resources used as input to determine the affected factors in a VNF power transition. ● Uses its own VNF instance storage component to persist VNF ​​state and configuration. ● Use of VNF deployment flavors (based on VNF descriptors (VNFDs)) and changing VNF flavor behavior as a mechanism to change VNF power modes. Uses virtualization resource management functions, e.g., starting / stopping virtualized resources, changing the power mode of the underlying hosting physical resources to handle VNF power state modifications. Handles power management for single or multiple VNFs as a dedicated or common VNF generic OAM function. Acquire relevant power consumption data from other management and governance systems or from the infrastructure or VNFs. Return information about VNF ​​power consumption and applicable power states to the management and governance systems, allowing these other systems to further interact with other elements (e.g., NFVI) to perform necessary actions (e.g., change the power state of a server, change the configuration of network equipment, etc.). Deciding to change between states (for example, entering VNF sleep mode) either autonomously or based on some event.

[0089] VNF power management may be triggered by a component dedicated to analysis and intelligent control (e.g., RIC in O-RAN, MDAF in NFV-MANO) or a component dedicated to VNF power management function 300 (e.g., function in VNF generic OAM function framework 301).

[0090] FIG. 8 shows a flow diagram 800 for VNF configuration with respect to power management.

[0091] The components described with reference to Figure 3 are involved in this flow: VNF Power Manager 801, OSS / BSS 802, NFV-MANO 803 and NFVI 804, VNF 805, VNF Configuration Manager 806, Metrics Aggregator 808, Metrics Analyzer 807, Log Aggregator 810, Log Analyzer 809 and Notification Manager 811.

[0092] At 812, the OSS / BSS 802 requests provisioning of the new VNF and enables power management for this VNF.

[0093] At 813, the NFV-MANO 803 and NFVI 804 start the VNF 805 (in response to the request) using normal procedures.

[0094] At 814, the NFV-MANO 803 registers the VNF 805 with the VNF power manager 801 and passes a VNF power profile for the VNF 805 (if available) to the VNF power manager 801. If the VNF power profile is not available from the NFV-MANO, the VNF power manager compiles a VNF power profile for the VNF.

[0095] At 815, the VNF power manager 801 aligns the profile with power policies and operational requirements.

[0096] At 816, the VNF power manager 801 collects VNF data.

[0097] At 817, the VNF power manager 801 performs reconfiguration actions (e.g., reallocating vCPUs) for the VNF 805 and any dependent VNFs or VNFCs, if necessary, based on the metric collection and VNF power profile.

[0098] At 818, the VNF power manager 801 applies the reconfiguration action to the VNF 805 through the VNF configuration manager 806.

[0099] At 819, the VNF power manager 801 notifies the NFV-MANO 803.

[0100] At 820, the NFV-MANO 803 and NFVI 804 perform virtualization and / or physical resource power management actions, if necessary.

[0101] FIG. 9 shows a flow diagram 900 illustrating a method for registering a VNF for power management.

[0102] The OSS / BSS 901, NFV-MANO 902, NFVI 903 and VNF power manager 904 (e.g., as in FIG. 3) are involved in the flow.

[0103] At 905, the VNFs requested by the OSS / BSS 901 are instantiated by the NFV-MANO 902 and the NFVI 903.

[0104] At 906, the NFV-MANO 902, NFVI 903, and VNF power manager 904 obtain and / or build a VNF power profile for the VNF. The MANO can indicate the power profile for the VNF, for example, with an associated deployment flavor. If the profile is not provided by the NFV-MANO, the VNF power manager puts together a VNF power profile for this VNF.

[0105] At 907, the NFV-MANO 902 registers the VNF for power management with the VNF power manager for power management.

[0106] At 908, the VNF power manager 904 sets up the necessary metrics for monitoring and VNF configuration in conjunction with other VNF generic OAM functions.

[0107] At 909, the VNF power manager 904 verifies the registration of the VNF.

[0108] While a VNF is instantiated, a loop is executed at 910 that includes exposing metrics related to power management by NFV-MANO 902 and NFVI 903 to the VNF power manager 904 at 911, and calculating the VNF power consumption based on the metrics and the VNF power profile values, and fine-tuning the VNF power profile at 912 (i.e., the VNF power manager 904 can adapt the VNF power profile if its power consumption (indicated by the metric value) does not achieve the target power consumption reduction).

[0109] FIG. 10 shows a flow diagram 1000 illustrating a method for setting a VNF to a sleep mode.

[0110] The OSS / BSS 1001, NFV-MANO 1002, NFVI 1003 and VNF power manager 1004 (for example, as shown in Figure 3) are involved in this flow.

[0111] At 1005, the VNF power manager 1004 is triggered (e.g., by request from the OSS / BSS 1001 or autonomously) to place the VNF in sleep mode.

[0112] At 1006, the VNF power manager 1004 stores the VNF configuration and operational state (i.e., VNF operational state information) in a registry.

[0113] At 1007, the VNF power manager 1004 updates the VNF power state to sleep mode.

[0114] At 1008, the VNF power manager 1004 notifies the NFV-MANO 1002 about the change in the VNF power state.

[0115] At 1009, the NFV-MANO 1002 processes resource management actions according to the power state profile of the sleep mode and manages resources accordingly at 1010.

[0116] At 1011, the NFV-MANO 1002, NFVI 1003 and VNF power manager 1004 perform resource reallocation actions according to resource management and exchange confirmations and / or notifications regarding resource changes at 1012.

[0117] FIG. 11 shows a flow diagram 1100 illustrating a method for restoring a VNF from a sleep mode to a normal operating mode power management.

[0118] The OSS / BSS 1101, NFV-MANO 1102, NFVI 1103 and VNF power manager 1104 (for example, as shown in Figure 3) are involved in this flow.

[0119] At 1105, the VNF power manager 1104 is triggered (e.g., by request from the OSS / BSS 1101 or autonomously) to configure the VNF to be restored to normal operating mode.

[0120] At 1106, the VNF power manager 1104 notifies the NFV-MANO 1102 of the VNF power restoration.

[0121] At 1107, the NFV-MANO 1102 processes the resource management actions requested by the NF power manager according to the power state profile of the normal operation mode and manages the resources accordingly at 1108.

[0122] At 1109, the NFV-MANO 1102, NFVI 1103 and VNF power manager 1104 perform resource actions according to the resource management and at 1110 exchange confirmations and / or notifications regarding the resource changes.

[0123] At 1111, the NFV-MANO 1102 notifies the VNF power manager 1104 about the change in the VNF lifecycle.

[0124] At 1112, the VNF manager 1104 restores the VNF configuration and operational state from the registry (in conjunction with other VNF generic OAM functions).

[0125] At 1113, the VNF manager 1104 updates the VNF power state to normal operation mode and checks whether the updated power state is correct and consistent with the profile.

[0126] At 1114, the VNF power manager 1104 notifies the NFV-MANO 1104 about the change in the VNF power state.

[0127] The above-described approach may interact with other systems such as O-RAN, especially in the architecture of Figure 3. For example, both the virtualization-related components 312, 313, 314 and the VNF power manager 300 may be connected to and interact with the Service Management & Orchestrator (SMO) and O-Cloud in an O-RAN-based deployment.

[0128] In summary, according to various embodiments, a communications power management component is provided as shown in FIG.

[0129] FIG. 12 illustrates a power management component 1200 according to one embodiment.

[0130] The power management component includes a memory 1201 configured to store, for a virtual network function, a power saving profile 1202 for each of a plurality of power states of the virtual network function.

[0131] For each power state, the power saving profile may show the following as examples: the amount of physical data processing resources used by that virtual network function in that power state The amount of virtualized containers (VMs and OS containers) deployed on the physical resources used by that virtual network function in that power state The service capacity of the network functions running on the virtualized containers provided in that power state.

[0132] The power management component 1200 further includes a controller 1203 configured to select one of the power states for the virtual network function and control the virtual network function to operate in accordance with a power saving profile stored for the selected power state.

[0133] In other words, according to various embodiments, a power state profile is established that defines the usage (i.e., rate, ratio, or percentage of usage) of each of all three layers of a virtual network function (physical resources, virtual resources, and applications). In this way, each power state can be fine-tuned with respect to all three layers.

[0134] The approach of Figure 12 can be used to reduce power consumption and improve energy efficiency in virtualized environments. It has many potential use cases related to energy efficiency and energy consumption policy enforcement (e.g., O-RAN driven intelligent control) and can be implemented in many possible embodiments, including extensions through a VNF generic OAM function framework. Generic OAM functions can be easily plugged into such implementations. Furthermore, the approach of Figure 12 can further simplify and optimize VNF power management and enable flexibility in how it can operate across multi-technology VNF environments (VM-based, container-based).

[0135] Furthermore, the approach of FIG. 12, according to various embodiments, enables VNF power management, improving operator governance with methods and / or mechanisms and interfaces that can optimize energy efficiency, e.g., as part of a unified governance plane.

[0136] The power management component 1200 is a component of a communication network (e.g., a core network), for example, a 5G communication system.

[0137] The power management component 1200 performs, for example, a method such as that shown in FIG.

[0138] FIG. 13 shows a flow diagram 1300 illustrating a method for power management of virtual network functions.

[0139] At 1301, for a virtual network function, a power saving profile is stored for each of a plurality of power states of the virtual network function.

[0140] For each power state, the power saving profile indicates the amount of physical data processing resources used by the virtual network function in that power state, the amount of virtualized containers (VMs and OS containers) deployed on the physical resources used by the virtual network function in that power state, and the service capacity of the network functions running on the virtualized containers provided in that power state.

[0141] At 1302, one of the power states is selected for the virtual network function.

[0142] At 1303, the virtual network function is controlled to operate according to the stored power saving profile for the selected power state.

[0143] According to various embodiments, for example, a method for optimizing power management for a VNF is provided, the method including: Receive a request from the management system to enable power management for the VNF Receives, publishes and translates information from VNF / VNFC about: VNF power state, VNF configuration information, associated management and governance and resource configuration, VNF application operational state ■Update the power management state of the VNF ■ Maintain isolation between VNFs regarding power management operations ■Reserve resources to restore VNF power later Receive, publish, and translate management, leadership, and resource configuration information from management systems. Compliance with VNF power-aware policies ■Automate VNF configuration and management operations, with or without interaction with other management and governance systems.

[0144] The components of the power management component (particularly the controller; which can be viewed as implementing any of the various functions of the VNF power manager described above, i.e., as an entity implementing the "logic" of the power management component) may be implemented, for example, by one or more circuits. A "circuit" may be understood as any kind of logic-implementing entity, which may be a special-purpose circuit or a processor executing software stored in memory, firmware, or any combination thereof. Thus, a "circuit" may be a hard-wired logic circuit or a programmable processor, e.g., a programmable logic circuit such as a microprocessor. A "circuit" may also be a processor executing software, e.g., any kind of computer program. Any other kind of implementation of the above functions may also be understood as a "circuit."

[0145] Further examples are described below. [Clause 1] a power management component, a memory configured to store, for a virtual network function, a power saving profile for each of a plurality of power states of the virtual network function, the power saving profile comprising: the amount of physical data processing resources used by the virtual network function in that power state; the amount of virtualized containers deployed on the physical resource used by the virtual network function in that power state; and Indicating the service capacity of the network functions running on the virtualized container provided in that power state; memory and; a controller configured to select one of the power states for the virtual network function and to control the virtual network function to operate in accordance with the power saving profile stored for the selected power state. Power management components. [Clause 2] 10. The power management component of claim 1, having an input interface configured to receive information indicating that a power state of the virtual network function should be changed, wherein the controller is configured to, in response to receiving the information, select one of the power states and control the virtual network function to operate in accordance with the power saving profile stored for the selected power state. [Article 3] 3. The power management component of clause 2, wherein the information is a request to change a power state from a current state. [Article 4] 4. The power management component of clause 2 or 3, wherein the information includes information regarding power consumption of the virtual network function. [Article 5] 5. The power management component of any one of clauses 1 to 4, wherein each power saving profile indicates power consumption of operation of the virtual network function in accordance with that power saving profile. [Article 6] 6. The power management component of any one of clauses 1 to 5, wherein each power saving profile further specifies the number of virtual network function components of the virtual network function that are operated in that power saving profile. [Article 7] 7. The power management component of any one of clauses 1 to 6, wherein the controller is configured to determine power consumption for each power saving profile based on power consumption measurements. [Article 8] 6. The power management component of any one of clauses 1 to 5, wherein the controller is configured to, for each power saving profile, include the determined power consumption in the power saving profile. [Article 9] 9. The power management component of clause 7 or 8, wherein the power management component is configured to select the power state taking into account a determined power consumption. [Article 10] the controller is configured to control the virtual network function to switch from a first power state to a second power state; The power management component of any one of clauses 1 to 9, wherein the controller is configured to store operational state information regarding the virtual network function when controlling the virtual network function to switch from the first power state to the second power state, and to configure the virtual network function taking the stored operational state information into account when controlling the virtual network function to switch from the second power state to the selected power state. [Article 11] 11. The power management component of clause 10, wherein the controller is configured to configure the virtual network function according to stored operating state information as permitted by a stored power saving profile for a selected power state. [Article 12] 12. The power management component of clause 11, wherein the memory is configured to store, for each of a plurality of virtual network functions, a separate power saving profile for each of a plurality of power states of that virtual network function. [Article 13] 1. A method for power management of a virtual network function, comprising: storing, for a virtual network function, a power saving profile for each of a plurality of power states of the virtual network function, wherein, for each power state, the power saving profile comprises: the amount of physical data processing resources used by the virtual network function in that power state; the amount of virtualized containers (VMs and OS containers) deployed on the physical resource used by the virtual network function in that power state; and Indicating the service capacity of the network functions running on the virtualized container provided in that power state; stages and; selecting one of the power states for the virtual network function; and controlling the virtual network function to operate in accordance with a stored power saving profile for a selected power state. method.

[0146] While particular aspects have been described, it should be understood by those skilled in the art that various changes in form and detail can be made therein without departing from the spirit and scope of the aspects of the present disclosure as defined by the appended claims. The scope is accordingly indicated by the appended claims, and all changes that come within the meaning and range of equivalents of the claims are therefore intended to be embraced.

Claims

1. a power management component, a memory configured to store, for a virtual network function, a power saving profile for each of a plurality of power states of the virtual network function, the power saving profile comprising: the amount of physical data processing resources used by the virtual network function in that power state; the amount of virtualized containers deployed on the physical resource used by the virtual network function in that power state; and - indicating the service capacity of the network functions running on the virtualized container provided in that power state; memory and; a controller, selecting a second power state of the plurality of power states for the virtual network function while the virtual network function is in a first power state of the plurality of power states; controlling the virtual network function to switch from the first power state to the second power state; - upon controlling the virtual network function to switch from the first power state to the second power state, storing operational state information about the virtual network function in the first power state; configuring the virtual network function in the second power state taking into account the stored operational state information, the stored operational state information being further taken into account to attempt to restore a virtual network function state upon returning to the first power state for which the operational state information was stored; configured to control the virtual network function to operate in accordance with a power saving profile stored for the second power state; and a controller. Power management components.

2. an input interface configured to receive information indicating that a power state of the virtual network function should be changed; 2. The power management component of claim 1, wherein the controller is configured to, in response to receiving the information, control the virtual network function to operate in accordance with a power saving profile stored for the second power state.

3. The power management component of claim 2 , wherein the information is a request to change a power state from a current power state of the plurality of power states.

4. The power management component of claim 2 or 3, wherein the information includes information about power consumption of the virtual network function.

5. 4. The power management component of claim 1, wherein each power saving profile indicates the power consumption of the virtual network function operating in accordance with the power saving profile.

6. The power management component of claim 1 , wherein each power saving profile further specifies a number of virtual network function components of the virtual network function that are operated in that power saving profile.

7. The power management component of claim 1 , wherein the controller is configured to determine power consumption for each power saving profile based on power consumption measurements.

8. The power management component of claim 7 , wherein the controller is configured to, for each power saving profile, include a determined power consumption in the power saving profile.

9. The power management component of claim 7 , wherein the controller is configured to select the second power state taking into account a determined power consumption.

10. 4. The power management component of claim 1, wherein the controller is configured to configure the virtual network function according to stored operating state information as long as a stored power saving profile for the second power state is satisfied.

11. the memory is further configured to receive, for each of the plurality of power states of the virtual network function, a respective power saving profile from NFV-MANO; the controller is further configured to, if a power saving profile for any one of the plurality of power states does not exist in the memory, prepare a power saving profile for the any one of the plurality of power states. A power management component according to any one of claims 1 to 3.

12. The power management component of claim 11 , wherein the memory is configured to store, for each of a plurality of virtual network functions, a separate power saving profile for each of the plurality of power states of that virtual network function.

13. 1. A method for power management of a virtual network function, comprising: storing, by a memory, for a virtual network function, a power saving profile for each of a plurality of power states of the virtual network function; For each power state of the plurality of power states, the power saving profile comprises: the amount of physical data processing resources used by the virtual network function in that power state; the amount of virtualized containers deployed on the physical resource used by the virtual network function in that power state; and - indicating the service capacity of the network functions running on the virtualized container provided in that power state; Stages and; selecting, by a controller, a second power state of the plurality of power states for the virtual network function while the virtual network function is in a first power state; controlling, by the controller, the virtual network function to switch from the first power state to the second power state; storing, by the controller, operational state information about the virtual network function in the first power state when controlling the virtual network function to switch from the first power state to the second power state; configuring, by the controller, the virtual network function in the second power state taking into account the stored operational state information, the stored operational state information being further taken into account to attempt to restore a virtual network function state upon returning to the first power state for which the operational state information was stored; controlling, by the controller, the virtual network function to operate in accordance with a stored power saving profile for the second power state. method.

Images