Method for managing power in a communication system

Abstract

According to an embodiment, a method for power management of a communication system is described, the method including providing a network service by one or more functional components, determining one or more power weights each specifying a dependency between power states, determining to modify a power state of at least one of the network service and the one or more functional components, and updating the power states of the network service and the one or more functional components in response to the determined modification, taking into account the dependency of the power states of the network service and / or the one or more functional components specified by the power weights.

Description

[Technical Field]

[0001] The present disclosure relates to a method for power management in a communication system. [Background technology]

[0002] A communication system includes multiple functional components that cooperate to provide a network service. Thus, the power consumption of a network service may depend on the power consumption of multiple functional components. Power management is further complicated by the fact that functional components, such as virtual network functions, physical network functions, and nested network services, may be shared among multiple network services. Therefore, an approach for power management of a communication system that allows for efficiently handling such types of scenarios is desirable. Summary of the Invention [Means for solving the problem]

[0003] According to one embodiment, there is provided a method for power management in a communication system, the method comprising the steps of providing network services by one or more functional components and determining one or more power weights, each power weight being between a power state of the network service and a power state of each functional component of the one or more functional components; between the power states of two respective functional components of said one or more functional components; or Between the power state of each of the one or more functional components and another network service. determining to change the power state of at least one of the network service and the one or more functional components; and updating the power states of the network service and the one or more functional components in response to the determined change, taking into account the dependency of the power states of the network service and / or the one or more functional components specified by the power weights (in particular, from the power states for which the change was determined). [Brief explanation of the drawings]

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

[0005] [Figure 1] 1 shows a mobile wireless communication system. [Figure 2] It presents a simplified version of the OSS / BSS (operations support system and business support system) and Network Functions Virtualisation Management and Orchestration (NFV-MANO) architectural framework. [Figure 3] Indicates the dependency of NS power state on VNF (virtual network function) power state. [Figure 4] Shown are three network services with shared VNFs. [Figure 5] Shows three network services, one of which is shared. [Figure 6]1 illustrates an NFV architecture including an NS power manager function (NSPoMF) according to an embodiment. [Figure 7] Shows a network service (NS) transitioning from an active power state to a standby power state and from a standby power state back to an active power state. [Figure 8] 1 shows a flow diagram illustrating a procedure for autonomously updating NS power state. [Figure 9] 1 shows a flow diagram illustrating a procedure for autonomously updating NS power weights. [Figure 10] 1 shows a flow diagram illustrating a procedure for autonomously updating the NS power state of shared VNFs. [Figure 11] A flow diagram 1100 illustrating a method for power management in a communication system is shown. 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. Various aspects of the present disclosure are not necessarily mutually exclusive, as some aspects of the present disclosure may be combined with one or more other aspects of the present disclosure to form new aspects.

[0007] Various examples corresponding to aspects of the present disclosure are described below.

[0008] A first embodiment is a method for power management in a communication system, providing network services by one or more functional components; determining one or more power weights, each power weight being ○ Between the power state of the network service and the power state of each functional component between the power states of two respective functional components of said one or more functional components; or ○ Between the power state of each functional component and different network services Specify dependencies between stages; determining to change a power state of at least one of the network service and the one or more functional components; and updating the power states of the network service and the one or more functional components in response to the determined change, taking into account the power state dependencies of the network service and / or the one or more functional components as specified by the power weights.

[0009] Example 2 is the method of example 1, wherein the one or more functional components are one or more virtual network functions, one or more cloudified network functions, one or more physical network functions, and / or one or more nested network services.

[0010] Example 3 is the method of example 1 or 2, wherein for each power weight, the magnitude of each power weight specifies a degree of each dependency, and the updating takes into account the specified degree of each dependency.

[0011] Example 4 is the method of any one of Examples 1 to 3, wherein the updating step resolves conflicts by comparing dependency degrees and respecting the dependency relationships between the functional components.

[0012] Example 5 is the method of any one of Examples 1 to 4, wherein at least one of the one or more power weights specifies that a respective first functional component must not be in a first power state when a respective dependent second functional component is in a second power state.

[0013] Example 6 is the method of any one of Examples 1 to 5, wherein the determined change is a change to a power state of the network service, and at least one of the one or more power weights specifies that a power state of a respective functional component is to remain unchanged when the power state of the network service is changed in response to the determined change.

[0014] Example 7 is the method of any one of Examples 1-5, wherein the determined change is a change in a power state of one of the functional components, and at least one of the one or more power weights specifies that a power state of the network service is to remain unchanged when the power state of the one of the functional components is changed in response to the determined change.

[0015] Example 8 is the method of any one of Examples 1 to 7, wherein at least one of the one or more power weights specifies that when updating a power state of each functional component shared with the other network service, the power state of the respective functional component must respect the power state of the other network service.

[0016] Example 9 is the method of any one of Examples 1 to 8, wherein the determined change is a return from a second power state to a first power state, and a previous change was changing the power state from the first power state to the second power state.

[0017] Example 10 is the method of example 9, including saving power weights when changing power states from the first power state to the second power state.

[0018] Example 11 is the method of example 10, including considering dependencies of power states of the network service and / or the one or more functional components as specified by stored power weights.

[0019] Example 12 is the method of any one of Examples 1 to 11, wherein determining the one or more power weights includes receiving a network service descriptor for the network service and reading the power weights from the network service descriptor.

[0020] Example 13 is the method of any one of Examples 1 to 12, including updating the power weights in response to operational information related to the communication system; and storing the updated power weights.

[0021] A fourteenth embodiment is a power management system for a communication system configured to execute any one of the methods of the first to thirteenth embodiments.

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

[0023] 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 one of the above examples.

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

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

[0026] 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. part of a mobile communication network (e.g. a public land mobile network PLMN).

[0027] Furthermore, the mobile wireless communication system 100 includes a radio access network (RAN) 103, where the RAN 102 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 be configured according to LTE (Long Term Evolution) or another mobile wireless communication standard (e.g., non-3GPP access such as Wi-Fi), although 5G is used herein as an example. Each radio access network node is capable of providing radio communication with a mobile wireless terminal device 102 over an air interface. Note that the radio access network 103 may include any number of radio access network nodes.

[0028] The mobile radio communication system 100 further comprises 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 comprises an Authentication Server Function (AUSF) 114, a Policy Control Function (PCF) 115, and an Application Function (AF) 120.

[0029] 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 with three core network slice instances (C-NSIs) 108 for providing enhanced mobile broadband (eMBB) and a second core network slice 107 with three core network slice instances (NSIs) 109 for providing vehicle-to-everything (V2X).

[0030] Typically, when a core network slice is deployed (i.e., created), 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.

[0031] 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 for managing session contexts with the user plane function (UPF).

[0032] The RAN 103 and the core network 119 form the network side of a mobile radio communication system, or in other words, form a mobile radio communication network. The mobile radio communication network and the mobile terminals accessing the mobile radio communication network together form the mobile radio communication system.

[0033] Like 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 network slices.

[0034] In the following, "network slice" (or simply "slice") generally refers to a core network slice, but can also include a RAN slice or even a transport network slice.

[0035] The mobile wireless communication system 100 may further include an Operation, Administration, and Maintenance (OAM) 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 a Management Data Analytics Service (MDAS). The MDAS may provide, for example, analytical reports on network slice instance load. Various factors, such as the number of UEs accessing the network, the number of QoS flows, and resource utilization of different NFs associated with the network slice instance, may affect the network slice instance load.

[0036] The core network 118 also includes a Network Repository Function (NRF).

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

[0038] 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 that realizes the network functions is tightly coupled to the hardware.

[0039] However, it may be desirable to implement network functions as software applications running on virtual machines (and / or containers) deployed on non-specialized hardware, i.e., on commercial off-the-shelf (COTS) servers (i.e., on general-purpose or open computing platforms, i.e., devices). This is made possible by using virtualization technologies (e.g., hypervisors, operating system (OS) containers, etc.), where network functions (e.g., SMFs, PCFs, etc.) can be deployed in virtual machines (VMs with one or more vCPUs) and / or (operating system (OS)) containers (a container can be considered a type of “lightweight” VM that runs directly on an OS). They are called virtual network functions (VNFs). VMs and OS containers are referred to herein by the general term “virtualized containers.”

[0040] Network Functions Virtualization Management and Governance (NFV-MANO) is a key element of the ETSI (European Telecommunications Standards Institute) Network Functions Virtualization (NFV) architecture. NFV-MANO is an architectural framework that coordinates network resources for cloud-based applications and the lifecycle management of virtual network functions (VNFs) and network services. It is therefore crucial for ensuring rapid and reliable NFV deployment at scale. NFV-MANO includes, among other components, an NFV Orchestrator (NFVO), a VNF Manager (VNFM), and a Virtual Infrastructure Manager (VIM). Network services, as managed objects by NFV-MANO, can be used to deploy and perform lifecycle management of network slices. A network slice N:1 network service relationship exists; that is, one network service can be mapped to one or multiple network slices. In this case, a network slice is considered to provide the "application view" of the network, while a network service considers its "resource view."

[0041] Figure 2 shows an operations support system and business support system (OSS / BSS) 201 and a simplified version of the NFV-MANO architectural framework, which includes a collection of function blocks and functions, data repositories used by these function blocks, and the reference points and interfaces through which these function blocks exchange information for the purpose of managing and governing NFVs.

[0042] Specifically, NFV-MANO includes NFVO 202, VNFM 203, VIM 204, and CISM (Container Infrastructure Services Management) 205. In the following, due to the similar management scope of the two functions (VIM on virtualized resources such as VMs, and CISM on OS containers), CISM 205 is assumed to be part of VIM 204, and thus only VIM 204 will be referred to (i.e., VIM 204 and CISM 205 are joined together as indicated by the dashed line and referred to as VIM 204).

[0043] The NFVO 202 manages Network Services (NS) 206, which in this example includes the AMF 207, SMF 208, PCF 209, and AF 210. A Network Service (NS) is a composition of network functions and / or services defined by its functional and behavioral specifications and can be mapped to network slices, as previously shown.

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

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

[0046] 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 the required resources and connectivity.

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

[0048] The VIM 204 is the functional block responsible for controlling and managing NFVI compute, storage, and network resources, typically within one operator's infrastructure domain.

[0049] Note that Network Functions according to 3GPP are responsible for managing and configuring Network Functions (NFs) and the interaction between NFs, but are not responsible for managing the virtualized network function aspects. From the NFV-MANO point of view, it is irrelevant which are the actual NFs "hosted" within the VNF.

[0050] 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.

[0051] From the NFV-MANO perspective, VNF management (lifecycle management (LCM) such as instantiation, update, and termination of VNF instances) is done by NFV-MANO (specifically the VNFM), and its application configuration is driven by the element manager or OSS.

[0052] According to various embodiments, techniques are provided for power management at the network service (NS) level that respect the separation between physical network functions (such as AMF 207 in the example of FIG. 2) and software deployed by virtualization layers (such as SMF 208, PCF 209, and AF 210 in the example of FIG. 2). In particular, techniques are provided for managing NS power management profiles as they relate to VNF power profiles in a dynamic manner rather than in a fixed association, as well as for maintaining NS runtime information (e.g., VNF identification and configuration information inside VNFs / VMs) and NFV-MANO managed object information during network service power state transitions.

[0053] Figure 3 shows the dependency of NS power states on VNF power states.

[0054] In this example, the network service 300 includes three VNFs 301, 302, and 303. The power states of each VNF 301, 302, and 303, and the transitions between the possible power states, are given by respective VNF (power) state machines 304, 305, and 306.

[0055] In this example, each VNF 301, 302, 303 has a VNF standby mode state 307, a VNF sleep (i.e., transition to standby) state 308, a VNF resume state 309, a VNF normal operation state 310, a VNF low power consumption mode state 311, and a VNF high power consumption mode state 312.

[0056] Sleep mode state 308 may be a low power consumption mode that is an intermediate state before standby mode 307 (which is the "lowest power consumption mode").

[0057] Depending on the power state of each VNF 301, 302, 303, the network service has certain power states within the NS (power) state machine 313, which in this example has NS standby mode 314, NS resume mode 315, NS normal operation mode 316, NS sleep mode 317, and NS high power consumption mode 318. The power states for the NS and the power states for the VNFs may also be different.

[0058] It should be noted that the more general terms “high power state” and “low power state” are used herein. The high power state may be, for example, an active state, and the low power state may be, for example, a standby state. However, there may be finer granularity, and the high power state and the low power state may differ (e.g., they are high and low power consumption modes) in that the power consumption of the high power state is higher than the power consumption of the low power state, for example, because a resource (or resources) is used more in the high power state than in the low power state (e.g., CPU power, network (e.g., wireless) resources, memory, etc.). The high power state may also be referred to as a “first power state” and the low power state as a “second power state,” or vice versa.

[0059] According to an embodiment, an approach is provided for power management at the NS level (and from the perspective of the NS 300) taking into account the impact on the VNFs 301, 302, 303.

[0060] The same approach can be applied to the case of Containerized Network Functions (CNFs) and Physical Network Functions (PNFs) that are part of a network service. For each VNF, CNF, and PNF that is part of a network service, there is a power state machine. At each point in time, every VNF, CNF, and PNF is in a specific power state. In the following description, VNFs are used as an example, but the same principles apply to the case of CNFs and PNFs.

[0061] Specifically, according to various embodiments, a method for managing NS power states is provided, wherein at least one or more of the following is true: ● Power weights are used for: ○Specify the significance of the power state of VNFs 301, 302, 303 for the power state of NS power state. - Resolve dependencies between VNFs when performing power management at the NS level. When performing the power management at the NS level, resolve dependencies between the NS and one or more other NSs. ● Power weights may be updated on demand (eg, by a user or operator) or autonomously. Power management (application and virtual resources) and the underlying physical power management are considered together. - The power management capabilities provided by said management and governance system of infrastructure and power consuming elements are utilized. After a power management operation is performed on the NS, the entire NS can be successfully restored to its original power state. Any number of network services (and VNFs, CNFs, PNFs) power states can be managed.

[0062] Note that there may be multiple instances of a network service, and each instance of a network service may have its own power state. Thus, hereinafter, reference to a network service (particularly with respect to its power state) may be understood to refer to each instance of the network service.

[0063] According to various embodiments, the power state of a network service is designated by an "energy aware state" (EAS). Similarly, the power state of a VNF (as well as of a CNF and a PNF) is designated by an EAS. To distinguish between the two, we refer to the EAS of a NS as an EAS.NS and the EAS of the VNF is written as EAS VNF VNF EAS VNF Note that the power state of a VNF component may depend on the power state of that component, which may be specified by the EAS. VNFC The EAS can be thought of as an operational power profile mode. In the following, "power state" and "operational power profile mode" or simply "power mode" are used interchangeably.

[0064] EAS NS It contains VNF EAS VNF , it contains CNF EAS CNF , and it contains PNF EAS PNF Dependency on EAS VNF , EAS CNF , and EAS PNF For example, for NS #x containing VNFs #1 to #n, EAS NS#x ={EAS VNF#1 ,EAS VNF#2 ,…,EAS VNF#n}

[0065] As mentioned above, each EAS VNF is itself an EAS of its components. VNFC Therefore, in the above expression, each EAS VNF#i is itself an EAS VNFC For example, EAS NS#x may be written in column form such that is represented in the form of a matrix with a set of columns, where each column corresponds to a VNF of the NS and an EAS of the VNFC of the VNF VNFC is a set of, for example,

number

[0066] According to various embodiments, the above representation of an NS power state as a set of power states of its VNFs is extended to allow for adjusting how a VNF's power state (e.g., standby state) is used to determine the power state of the NS that contains that VNF. Furthermore, according to embodiments, a mechanism is provided for considering inter-VNF relationships. Similarly, for the case of a CNF and a PNF, we consider the relationships between the VNF and the CNF, the CNF and the PNF, and the VNF and the PNF.

[0067] According to various embodiments, this is achieved by using weighted power states, i.e., by weighting the power states in the above representation.

[0068] For example, one or more EAS weighting factors may be introduced: ●Type 1: EAS NS Power weights used to specify the "importance" of a VNF (or CNF or PNF) for Type 2: Power weights used to specify the "importance" of dependencies between states of VNFs and / or PNFs and / or CNFs. Type 3: Power weights used to specify the "importance" of shared VNFs or CNFs or PNFs between different NSs (e.g., for network slicing). ● Type 4: Power weight used to specify the "importance" of a shared NS between different NSs (e.g., for network slicing).

[0069] According to various embodiments, any EAS VNF But also EAS CNF and EAS PNF can be tested and evaluated on different platforms, regardless of which NSs use them or how they use them.

[0070] These types are described in more detail below.

[0071] Type 1 is the power weight of the VNF (or alternatively a CNF or PNF, but VNFs are used as an example below) in relation to the "importance" of the VNF within the respective NS.

[0072] Therefore, for VNF#i, the power weight

number

number

[0073] Power weight ￣w i (t) can be a numeric value (e.g., varying between 0 and 1), but EAS VNF Other schemes are possible depending on the form of . For example, w1(t) = 0 means that VNF#1 is part of each NS but is not important when considering the NS power state, i.e., the NS power state, i.e., EAS NS indicates that the EAS is not taken into account when calculating VNF Depending on the form of , the weighting operation may be a logical operator (still written as multiplication "*" below).

[0074] Power weight ￣w i(t) can be changed on demand, for example, by the operator of the communication system using the respective NS power management function, or automatically due to LCM (Life Cycle Management Operations). In the second case, the power weights may be updated from the SMO after interaction with a non-RT-RIC or near-RT-RIC, for example, by the NFV-MANO management entity (for example, the NFVO or VNFM triggers the power weight update through a call to the NS power management function), or in case of other management systems like O-RAN, the power weights may be updated from the SMO after interaction with a non-RT-RIC or near-RT-RIC, for example, ●The operator should check the EAS for NS#1. VNF#1 request to change the power weight of EAS from 0 to 1. VNF#1 EAS NS#1 This means that, for, ... Intent-based requests from communication system components are parsed and the intent handler function is responsible for handling requests from a specific VNF of a specific network service (i.e., EAS VNF It was decided to change the value of the power weight (for During runtime, the Management Data Analytics function (MDAF) monitors and processes data related to the VNF to generate a report of the specific VNF for a specific network service (i.e., EAS) VNF The power weights (for ) are then determined to be different.

[0075] Power weight ￣w i Using (t), the above EAS NS#1 The expression changes to:

number

number

[0076] EAS of each VNF, i.e., each EAS VNF#i is expressed in watts, for example. For example, if the consumption of the respective VNF is more than 50 watts, the state is considered "active", if it is less than 50 watts, the state is "standby", etc.

[0077] For example, using power weights, VNF#2 NS#1 should be ignored initially (t=0), and VNF#3 is twice as important as VNF#1.

number

[0078] EAS VNF#1 is equal to 5 watts, EAS VNF#3 is equal to 10 watts,

number

number

[0079] Thus, Type 1 power weights allow configuring how important the VNF power state is to the NS power state.

[0080] EAS NS#1 is, for example, the total consumption of VNFs (and similarly of CNFs and PNFs), so that, for example, EAS NS#1 = 5 watts + 20 watts + 30 watts = 55 watts.

[0081] EASNS More complex schemes than addition may also be considered for how the power weights are used by the system to derive {tilde over (k)}.

[0082] Type 2 power weights allow taking into account dependencies between VNFs, CNFs, and PNFs. For example, if VNF#1 goes into standby state, it may not make sense to keep CNF#2 in active state for the same NS, since CNF#2 depends on the results provided by VNF#1.

[0083] Therefore, according to various embodiments, a dependency matrix W(t) is defined to NS The power state of the NS may be determined by the VNF, CNF, and PNF.

[0084] In particular, considering the case of VNF as an example (similarly for CNF and PNF), the EAS of VNF VNF The relationship between, for example, the power weight w ij (t), where w ij (t) indicates the dependency level of the power states of VNF#i (or generally, network function #i, which may be a PNF or a CNF) and VNF#j (or generally, network function #j), for example, for the example of FIG. 3 having three VNFs 301, 302, and 303.

number

[0085] Note that this scheme assumes a symmetric dependency. In the case of an asymmetric dependency, W(t) may be defined as a non-triangular matrix.

[0086] for example

number

[0087] In all cases, it is up to the controller (residing within NS-PoMF) to decide how to interpret this information into specific actions.

[0088] For example, NS is in standby mode, but one of the VNFs (e.g., VNF#1) is a critical VNF and should not go into standby mode (e.g., because it is a stateful data VNF that exposes database functionality). In that case, a high dependency of VNF#2 on VNF#1 may mean that, for example, VNF#2 should not go into standby mode either.

[0089] Type 3 power weights handle the case where a VNF is shared between two network services, which is shown in Figure 4.

[0090] 4 shows three network services 401, 402, and 403, each including a respective VNF (which may be an instance of the same VNF) 404, 405, 406, 407, and 408, where the first network service 401 and the second network service 402 share a first shared VNF 409, and all three network services 401, 402, and 403 share a second shared VNF 410.

[0091] In this case, whether the VNF is shared between network services such as NS-PoMF, and if so, between which network services, and optionally the significance of the sharing (with respect to the power state of each network service) is signaled to an entity (i.e., the communication system component that determines the NS power state(s)).

[0092] This means that for network service #x, the vector E x (t)=[e xi (t)]. The i-th component of the vector e xi (t) indicates whether VNF#i is shared with another network service. In the example of Figure 4, these vectors are, for example, as follows:

number

[0093] In this example, the values ​​are 0 (no sharing) and 1 (sharing), but the values ​​may be in the range [0;1] or other schemes, and their magnitude may indicate the importance of sharing for the power state of network service #x (this may be taken into account when resolving conflicts between dependencies; i.e., dependencies with higher importance (e.g., represented by a power weight with a larger magnitude) take precedence over those with lower importance).

[0094] In the above method, the matrix E for NS i is i (t) is a one-dimensional matrix that simply describes whether a VNF is shared or not. Multi-dimensional schemes are also possible that describe the dependencies of shared VNFs and the importance of this sharing with other NSs at a more granular level.

[0095] Type 4 power weights handle the case where an entire network service is shared between two network services, which is shown in Figure 5.

[0096] FIG. 5 shows two network services 501, 503, each having at least one respective VNF (or VNF instance) 504, 505, 506, 507, and sharing network service 502 (i.e., both network services 501, 503 include network service 502 as a nested sub-service).

[0097] This is a common use case under network slicing, for example, NS#1 belongs to NSSI#1 (NSSI: Network Slice Subnet Instance) and NS#2 belongs to NSSI#2.

[0098] In this case, whether a network nested (sub)service is shared between network services is signaled to the entity (i.e., the communication system component that determines the NS power state(s)).

[0099] This means that for network service #x, there is a vector N x (t)=[n j (t)], the jth component n j (t) indicates whether the network service j (i.e., the jth subnetwork service of network service x) it contains is shared with another network service. For the example in Figure 5, these vectors are, for example, as follows:

number

[0100] In this example, the indicated values ​​of 0 (no sharing) and 1 (sharing) may be in the range [0;1], and their magnitude may indicate the importance of that sharing for the power state of network service #i, i.e., the interdependence between network services that share the respective network service.

[0101] In the above method, N for NS i i (t) is a one-dimensional matrix that simply describes whether a nested NS is shared or not. Multi-dimensional schemes can also be envisaged that describe at a more granular level the dependencies of shared NSs and the importance of this sharing with other NSs.

[0102] The power weights of Type 3 (importance of sharing VNF / CNF / PNF with other NFs) and Type 4 (importance of sharing NS with other NSs) are calculated by multiplying the power weights of Type 1 (NSs) (￣W x (t): Importance of VNF / CNF / PNF in NS#x) and Type 2 power weight (W x (t): The importance of the relationship between VNF / CNF / PNF in NS#x, together with the various power weights and EAS of NS#x VNF (and / or EAS CNF and / or EAS PNF ) as input x may be used with:

number

[0103] Depending on the power weights, the function f x EAS NS#x About EAS VNF , EAS CNF , EAS PNF Decide on all practical importance. Various options for modeling input parameters and outputs are possible. In all cases, f xIt is up to the controller (residing in NS-PoMF) to decide how to interpret this information and turn it into a specific action according to

[0104] For example, EAS VNF , EAS CNF , and EAS PNF is expressed in watts and f x Consider the sum of all weighted values. Then the sum can give a value of xxx watts. Based on the policy, if this value is above a threshold, EAS NS#x is in the active state by NS-PoMF, and if this value is below the threshold, EAS NS#x is in standby mode. VNF , EAS CNF , and EAS PNF is calculated and mapped to the actual power consumption. NS#x When a request to change the state comes to NS-PoMF, the corresponding EAS VNF , EAS CNF , and EAS PNF The corresponding action that affects f is the opposite x The action is taken by NS-PoMF according to:

[0105] Function f x (W x (t),￣W x (t),E x (t),￣N x (t),EAS VNF ,EAS CNF ,EAS PNF ) may be used, among other things, to dynamically update the power state relationships between network services and their constituent VNFs, CNFs, and PNFs.

[0106] Function f x may be evaluated in the NS power manager function (NS-PoMF), for example, as shown in FIG.

[0107] FIG. 6 illustrates an NFV architecture including an NS Power Manager Function (NS-PoMF) according to one embodiment.

[0108] As described with reference to Figure 2, the NFV-MANO system 602 is connected to an OSS / BSS 601 and an NFVI 604. These components are connected to further VNF (e.g., "generic") OAM functions 603, which in this example include an NS-PoMF 600 (but may also be included in the NFV-MANO 602 itself, e.g., as part of the NFVO). The NS-PoMF 600 may be viewed as implementing (at least in part) the power management system of the respective communications system (e.g., communications system 100 of Figure 1).

[0109] NS-PoMF 600 offers different f x f x The choice is made by the operator and x No constraints are placed on the output (e.g., units). x Regarding inputs, besides the VNF / CNF / PNF power states and corresponding power weights, additional inputs can also be considered, such as logging information, management data analysis related to VNF performance, status, etc.

[0110] NS Power Management Function (NS-PoMF) 600 is, for example, Responsible for NS power state management. Interact with OSS / BSS and / or other NFV-MANO system components, etc. ·Having global knowledge of NS power management status. Triggering power state updates at the NS level on demand or dynamically based on different inputs. · Investigate the impact of transitions between states (e.g., the entire NS going into standby mode). Perform optimized NS LCM coordination with NFV-MANO system components. Responsible for allocating, monitoring and fine-tuning power weights. · Consider both VNF, CNF and PNF as part of the NS using a common identity.

[0111] From a management perspective, the following operations are supported (eg, by the NS Power Management Function (NS-PoMF) 600): Monitoring power consumption related to VNF / CNF and PNF Managing the entire NS state using a simple, vendor-independent API (e.g., NS i can enter a standby state) EAS VNF / CNF / PNF Exams and EAS NS Separation from testing EAS NS Performing system recovery actions after the transition.

[0112] Furthermore, different power weights allow for example to realize the following scenarios: When a network service is requested to enter a standby state, all VNFs and / or CNFs and / or PNFs should not be affected (e.g., the power state of one or more of the VNFs of the network service should be kept active). This can be achieved, for example, by appropriate configuration of Type 1 power weights. When a particular VNF / CNF / PNF of a network service enters a standby power state, the power state of the network service should be kept unchanged (to avoid high configuration costs), for example achieved by appropriate setting of Type 1 power weights. When a VNF (or CNF or PNF) goes into standby, tightly-coupled VNFs and / or CNFs and / or PNFs can also go into standby (or automatically go into standby), without the need to keep them active. This can be achieved, for example, by appropriate setting of Type 2 power weights. When a VNF (or CNF or PNF) is shared between network services and one of the network services goes into standby state, this does not affect the power state of other network services that use the shared VNF. Shared VNFs are, for example, inventory or database services. This is achieved, for example, by appropriate setting of Type 3 power weights. If a network service is shared between network services and one of the network services goes into standby mode, this does not affect the power state of other network services that use the shared network service. This can be achieved, for example, by setting the Type 4 power weight appropriately.

[0113] Weights are EAS VNF , EAS CNF , EAS PNF , and EAS NS The information may be updated by the operator from time to time to change the relationship between the

[0114] The NS-PoMF 600 is a logical function and can be implemented as part of the NFV-MANO 602 or external to the NFV-MANO 602. The NS-PoMF 600 exposes an NS power state management interface for management of the NS power state.

[0115] The NS-PoMF is a logical function and can also be part of other management systems such as SMO or IMS in the O-Cloud within the framework of O-RAN.

[0116] Function f x The inputs, in particular the power weight vector, may be updated in a timely manner (e.g., by the OSS / BSS 601 or generally by a "user", e.g., an operator), for example, through a management interface exposed by the NS-PoMF 600, or directly by the NFVO 202 (which is part of the NFV-MANO 602) when considering the NS-PoMF as part of the NFVO.

[0117] f i (W i (t),￣w i (t),E i (t),N i The various power weights that form the input of (t) may be defined, for example, in the Network Service Descriptor (NSD) of NS#x.

[0118] For this purpose, for example an attribute denoted nsdEnergyAwareStateWeights may be introduced into the NSD. [Table 1]

[0119] This attribute is the power weight W i (t), ￣W i (t), E i (t), N i It may host (t) as a key-value pair. [Table 2]

[0120] These attributes are set, for example, during each NS instantiation. When processing an NSD for the first time, the NFVO 202 informs the NS-PoMF 600, for example, about the power weight allocation.

[0121] The attribute nsdEnergyAwareStateWeights may also be updated during system operation, for example, when considering an Update NSD info operation or other NS LCM or VNF LCM operation that performs runtime configuration of the NS / VNF. Additionally, a trigger to update the power weights may be made by the OSS / BSS 601 to the NS-PoMF 600 based on real-time performance and / or interaction with other functions, such as a Management Data Analysis Function (MDAF) 605 and / or an Intent Handler 606 connected to the NS-PoMF 600.

[0122] NS-PoMF 600 is an EAS NS#x It is used to monitor all parameters relevant to the EAS and to evaluate the correct action to be taken. NS#x Depending on real-time information about the power weights, as well as other inputs such as from the MDA 605 and / or the Intent Handler 606 (i.e., Intent Management), the NS-PoMF 600 can autonomously decide to update the power weights and can also autonomously determine the power state of the entire network service.

[0123] According to various embodiments, the NS-PoMF 600 is also responsible for network service state management and restoration. The NS-PoMF 600 can manage EASs for the VNFs, CNFs, and PNFs that make up each network service.

[0124] Additionally, the NS-PoMF 600 controls and monitors the transitions between NS energy states.

[0125] For example, real-time power status EAS NS#x The trigger for updating may be done by the NS-PoMF 600 based on real-time performance and / or interaction with the MDAF 605 and / or the intent handler 606.

[0126] The NS-PoMF 600 may maintain an NS power state registry (PSR) 607 in which configuration information (including power weights) for all network services that have an EAS managed by the NS-PoMF 600 is stored. The configuration information includes information that allows the NS-PoMF 600, when updating an NS EAS to a different EAS, to use the stored configuration information to restore the NS to its pre-update operating state (which may also depend on the power weights that were set before the update). This is described in more detail below with reference to FIG. 7.

[0127] FIG. 7 shows a network service transitioning (703) from an active power state 701 to a standby power state 702 and from the standby power state 702 back to the active power state 701 (704).

[0128] To set the NS 701 to the standby power state 702, for example, the following is performed (e.g., by the NS-PoMF 600 through interactions with the NFVI 604, NFV-MANO 602, etc.): · Store NS configuration (including power weights) and management information in a registry (with timestamp and versioning), e.g., PSR 607. Maintaining NS status data held by management and governance systems. Creating an NS configuration snapshot to preserve the state and configuration data of the NS (e.g., IP address information, interface identification information, gateway identification information and configuration, etc.) and associated VNFs / VNFCs that configure the NS and can be used in the restore procedure. Tracks NFVI resources and maintains a map of them so that affected resources can be determined and their power state can be changed with respect to VNF / CNF / PNF standby mode. ·Resolve conflicts regarding power weight allocation for shared VNFs and shared NSs.

[0129] An exemplary flow is as follows: 1) The EAS is “active” (ie, the NS is in the active state 701 ) and the NS-PoMF 600 decides to transition it to the standby power state 702 . 2) The NS-PoMF 600 stores the NS power profile configuration (ie, configuration information). a) The NS-PoMF 600 stores the network configuration for all VNFs / CNFs / PNFs in the PSR 607. b) The NS-PoMF 600 stores the power weight assignment in the PSR 607 . c) The NS-PoMF 600 stores information about any other relevant configurations in the PSR 607. 3) The NS-PoMF 600 triggers a transition 703 to the standby power state 702. 4) The NS-PoMF 600 saves configuration information for the standby power state 702 (similar to stage 2 for the active power state 701). 5) The NS-PoMF 600 triggers a transition 704 to the active power state 701 (ie, active EAS). 6) The NS-PoMF 600 uses the configuration information stored in the PSR 607 to restore the configuration of the network service prior to the transition to the standby power state 703 (e.g., the same virtual deployment unit (VDU), same host machine(s), same IP address, etc.) that was used by the network service prior to the transition to the standby power state 703) and transitions back to the active power state 701.

[0130] FIG. 8 shows a flow diagram 800 illustrating a procedure for autonomously updating NS power state through the NS-PoMF 600 .

[0131] As described with reference to Figure 6, the flow involves OSS / BSS 801, NS-PoMF 802, NFV-MANO 803, and NFVI 804. In this description, NS-PoMF is considered as a management entity external to NFV-MANO.

[0132] At 805, the OSS / BSS 801 sends a request for NSD onboarding to the NFV-MANO 803. At 806, NFV-MANO 803 and NFVI 804 are used to onboard the NSD and create an NS instance according to the usual procedure. The power weights that are part of the NSD are used to determine the EAS of the VNFs of the respective network services. VNF It is used to describe different relationships between (similarly for CNF and PNF). At 807, the NFV-MANO 803 sends a request to the NS-PoMF 802 for NS EAS registration and monitoring. At 808, the NS-PoMF 802 registers the NS and continuously monitors the EAS of the NS. At 809, the NS-PoMF 802 decides to change the NS EAS, for example based on statistical information. At 810, the NFV-MANO 803, together with the NS-PoMF 802 and NFVI 804 services, adjusts the EAS by tuning relevant parameters (e.g., reducing the vCPUs allocated to the VDUs). NS Based on the power weights, specific VNFs, CNFs, and PNFs are affected.

[0133] FIG. 9 shows a flow diagram 900 illustrating a procedure for autonomously updating NS power weights through the NS-PoMF 600 .

[0134] As described with reference to FIG. 6, the OSS / BSS 901, NS-PoMF 902, NFV-MANO 903, and NFVI 904 are involved in the flow.

[0135] At 905, the OSS / BSS 901 sends a request for NSD onboarding to the NFV-MANO 903. At 906, NFV-MANO 903 and NFVI 904 are used to onboard the NSD and create an NS instance according to the usual procedure. The power weights that are part of the NSD are used to determine the EAS of the VNFs of the respective network services. VNF It is used to describe different relationships between CNF and PNF, as well as CNF and PNF. At 907, the NFV-MANO 903 sends a request to the NS-PoMF 902 for NS EAS monitoring. At 908, the NS-PoMF 902 registers the NS and continuously monitors the EAS of the NS. At 909, the NS-PoMF 902 autonomously decides to update the NS EAS power weights, for example, based on statistical information. In 910, the NS-PoMF 902 calculates a function f x Updated EAS in NS Using power weights, EAS NS Calculate.

[0136] FIG. 10 shows a flow diagram 1000 illustrating a procedure for autonomously updating NS power state through the NS-PoMF 600 of a shared VNF.

[0137] As described with reference to Figure 6, the OSS / BSS 1001, NS-PoMF 1002, NFV-MANO 1003, and NFVI 1004 are involved in the flow.

[0138] At 1005, the OSS / BSS 1001 sends a request for NSD onboarding of the two NSDs to the NFV-MANO 1003. At 1006, the NFV-MANO 1003 and NFVI 1004 NFV-MANO onboard their NSDs and create NS instances for the respective network services according to the usual procedure. The power weights that are part of the NSDs are used to determine the EAS of the VNFs of the respective network services. VNF It is used to describe different relationships between VNFs. Suppose one VNF ("VNFx") is shared by two NSs. The power weight value can be set by the OSS or the NS-PoMF. At 1007, the NFV-MANO 1003 sends a request for NS EAS monitoring to the NS-PoMF 802 for both network services. At 1008, the NS-PoMF 1002 registers both NSs and continuously monitors the EAS of the NSs. At 1009, the NS-PoMF 1002 is aware of the VNF sharing between the two NSs and monitors the system for potential events that may affect the relationship. At 1010, OSS / BSS 1002 requests NS-PoMF 1003 to change the EAS of NS#1. In 1011, the NS-PoMF 1003 based on the power weight is calculated by the function f x Before the change, it resolves conflicts and performs power weight allocation. NS Save this to PSR 607. At 1012, the NFV-MANO 1003 updates the EAS of NS#1 by adjusting the relevant parameters (e.g., lowering the vCPUs allocated to the VDUs) along with the NFVI services. Based on the power weights, specific VNFs are affected. At 1013, the NS-PoMF 1003 responds (eg, acknowledges) the EAS change request of 1011.

[0139] In summary, according to various embodiments, a method for power management in a communication system is provided as shown in FIG.

[0140] FIG. 11 shows a flow diagram 1100 illustrating a method for power management in a communication system.

[0141] In 1101, network services are provided by one or more functional components.

[0142] At 1102, one or more power weights are determined, each power weight being a dependency between the power state of the network service and the power state of each functional component (of the one or more functional components); a dependency between the power states of two respective functional components (of said one or more functional components); or The power state of each functional component of the network service and the dependencies between the different network services. Specify.

[0143] At 1103, it is determined to change a power state of at least one of the network service and the one or more functional components.

[0144] At 1104, in response to the determined change (e.g., receiving the determination), the power states of the network service and the one or more functional components take into account dependencies of the power states of the network service and / or the one or more functional components (particularly on the power state for which the change was determined) specified by power weights.

[0145] In other words, according to an embodiment of the present invention, the NSs are managed in terms of "power management" in a dynamic manner taking into account the power weights.

[0146] The approach of Figure 11 allows for power management of the NS containing the VNF (as well as the CNF and PNF) to take into account the special characteristics of configuring the VNF in a dynamic way (taking into account physical and virtual resources, applications, and VNF LCM together).

[0147] According to various embodiments, NS state restoration after exiting sleep / standby mode is provided, i.e., a mechanism is provided for restoring the NS operating state after any power state transition.

[0148] It should be noted that the approach of Figure 11 allows interaction not only with frameworks like NFV-MANO and OSS, but also with, for example, the generic OAM function framework and all services provided by O-RAN SMO and / or O-RAN O-Cloud IMS.

[0149] According to various embodiments, the approach of Figure 11 is used to control power consumption and increase energy efficiency in virtualized and / or cloudified environments. It has many potential use cases related to energy efficiency, energy consumption policy enforcement, etc. (e.g., O-RAN driven intelligent control), and there are many possible embodiments including NS power management for: Nested NS ·NS under sharing / slicing NS based on CNF, PNF and VNF NS in O-RAN

[0150] The approach in Figure 11 further simplifies and optimizes NS power management, enabling flexibility in how it can be operated across multi-technology VNF / CNF environments (VM-based, container-based, or mixed).

[0151] Thus, according to various embodiments, the telecommunications carrier governance structure can be enhanced with new methods / mechanisms and interfaces that enable NS power management and can optimize energy efficiency. This enables the concept of NS standby mode, which combines SW and HW sleep mode techniques. This type of management can be utilized as part of a unified governance plane.

[0152] The method of FIG. 11 may be performed by a power management system having one or more components. These components may be implemented, for example, by one or more circuits. A "circuit" may be understood as any type of logic implementation entity, such as a dedicated circuit or a processor executing software, firmware, or any combination thereof stored in memory. Thus, a "circuit" may be a hard-wired logic circuit or a programmable processor, such as a microprocessor. A "circuit" may also be a processor executing software, such as any type of computer program. Any other type of implementation of each of the above-mentioned functions may also be understood as a "circuit."

[0153] 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 therefore 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. 1. A method for power management in a communication system, comprising: providing a network service by one or more functional components; determining one or more power weights, each power weight being Between the power state of the network service and the power state of each functional component between the power states of two respective functional components of the one or more functional components; or Between the power states of each functional component and different network services Specify the dependencies of,stages and; determining to change a power state of at least one of the network service and the one or more functional components; updating the power states of the network service and the one or more functional components in response to the determined changes, taking into account power state dependencies of the network service and / or the one or more functional components as specified by the power weights; updating the power weights in response to operational information about the communication system and storing the updated power weights; The step of determining one or more power weights comprises: - receiving a network service descriptor for the network service; - reading the power weights from the network service descriptor; method.

2. 10. The method of claim 1, wherein the one or more functional components are one or more virtual network functions, one or more cloudified network functions, one or more physical network functions, and / or one or more nested network services.

3. The method of claim 1 , wherein for each power weight, a magnitude of the respective power weight specifies a degree of the respective dependency, and the updating takes into account the specified degree of the respective dependency.

4. The method of claim 1 , wherein the updating step resolves conflicts by comparing dependency degrees and respecting dependencies between functional components.

5. 2. The method of claim 1, wherein at least one of the one or more power weights specifies that a respective first functional component must not be in a first power state when a respective dependent second functional component is in a second power state.

6. 2. The method of claim 1, wherein the determined change is a change to a power state of the network service, and wherein at least one of the one or more power weights specifies that a power state of a respective functional component is to remain unchanged when the power state of the network service is changed in response to the determined change.

7. 2. The method of claim 1, wherein the determined change is a change in a power state of one of the functional components, and at least one of the one or more power weights specifies that a power state of the network service is to remain unchanged when the power state of the one of the functional components is changed in response to the determined change.

8. 2. The method of claim 1, wherein at least one of the one or more power weights specifies that when updating a power state of each functional component shared with the other network service, the power state of the respective functional component must respect a power state of the other network service.

9. 2. The method of claim 1, wherein the determined change is a reversion from a second power state to a first power state, and a previous change changed the power state from the first power state to the second power state.

10. 10. The method of claim 9, comprising preserving the power weights when changing power states from the first power state to the second power state.

11. The method of claim 10 , comprising taking into account power state dependencies of the network service and / or the one or more functional components as specified by stored power weights.

12. A power management system for a communication system configured to carry out a method according to any one of claims 1 to 11.

13. A computer program comprising instructions which, when executed by a computer, cause the computer to carry out a method according to any one of claims 1 to 11.

Images