Power management methods for communication systems

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] This disclosure relates to a method for power management of a communication system. [Background technology]

[0002] Communication systems include numerous functional components that work together to provide network services. Therefore, the power consumption of network services can depend on the power consumption of multiple functional components. The fact that functional components such as virtual network functions, physical network functions, and nested network services can be shared among multiple network services further complicates power management. Therefore, a method for power management of communication systems that efficiently handles such scenarios is desirable. [Overview of the project] [Means for solving the problem]

[0003] According to one embodiment, a method for power management of a communication system is provided, the method comprising the steps of providing network services by one or more functional components, and determining one or more power weights, wherein each power weight - Between the power state of the network service and the power state of each of the one or more functional components, - Between the power states of each of the two functional components among the one or more functional components, - Between the power state of each of the one or more functional components and another network service The process includes: specifying dependencies; deciding to change the power state of the network service and at least one of the one or more functional components; and updating the power states of the network service and / or the one or more functional components in response to the decided change, taking into account the dependencies of the power states of the network service and / or the one or more functional components (in particular, from the power state in which the change was decided) as specified by the power weights. [Brief explanation of the drawing]

[0004] In the drawings, similar reference numerals generally refer to the same parts through different drawings. The drawings are not necessarily to a fixed scale, but rather are focused on illustrating the principles of the invention. Various aspects in the following description will be explained with reference to the following drawings.

[0005] [Figure 1] This shows a mobile radio communication system. [Figure 2] This document describes OSS / BSS (Operations Support System and Business Support System) and a simplified version of the Network Functions Virtualisation Management and Orchestration (NFV-MANO) architecture framework. [Figure 3] This shows the dependency of the NS power state on the VNF (virtual network function) power state. [Figure 4] This shows three network services that share a VNF. [Figure 5] Three network services are shown, and one network service is shared. [Figure 6]This document describes an NFV architecture that includes an NS power manager function (NSPoMF) according to one embodiment. [Figure 7] This refers to a network service (NS) that transitions from an active power state to a standby power state and then returns from the standby power state to an active power state. [Figure 8] A flowchart illustrating the procedure for autonomously updating the NS power state is shown. [Figure 9] A flowchart illustrating the procedure for autonomously updating the NS power weights is shown. [Figure 10] This flowchart shows the procedure for autonomously updating the NS power state of a shared VNF. [Figure 11] Flowchart 1100 shows a method for power management of a communication system. [Modes for carrying out the invention]

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

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

[0008] Example 1 is a method for power management of a communication system. The stage of providing network services through one or more functional components; • A step in determining one or more power weights, where each power weight is ○ Between the power state of the aforementioned network service and the power state of each functional component ○ Between the power states of each of the two functional components among the one or more functional components, ○ Between the power state of each functional component and other network services Specify the dependencies, in stages; The step of deciding to change the power state of the network service and at least one of the one or more functional components; The process includes the step of updating the power states of the network service and / or one or more functional components in response to the determined changes, taking into account the power state dependencies of the network service and / or 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 cloud-based 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 the degree of each dependency, and the update takes into account the specified degree of each dependency.

[0011] Example 4 is one of the methods from Examples 1 to 3, wherein the updating step resolves conflicts by comparing the degree of dependencies and respecting the dependencies between functional components.

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

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

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

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

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

[0017] Example 10 is the method of Example 9, and includes a step of saving the power weight when changing the power state from the first power state to the second power state.

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

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

[0020] Example 13 is one of the methods from Examples 1 to 12, and includes the steps of updating the power weight in response to operational information relating to the communication system, and storing the updated power weight.

[0021] Example 14 is a power management system for a communication system configured to perform one of the methods from Examples 1 to 13.

[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. In particular, embodiments described in the context of apparatus are equally valid for methods.

[0023] According to a further embodiment, a computer program and computer-readable medium are provided that, when executed by a computer, include instructions causing the computer to perform any one of the methods of the above embodiments.

[0024] The following provides a more detailed explanation of various examples.

[0025] Figure 1 shows a mobile radio communication system 100 configured according to 5G (fifth generation) as defined by, for example, 3GPP (Third Generation Partnership Project).

[0026] The mobile radio communication system 100 includes mobile radio terminal devices 102, such as UE (user equipment). The mobile radio terminal devices 102, also called subscriber terminals, form 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 the mobile communication network (for example, the public land mobile network PLMN).

[0027] Furthermore, the mobile radio communication system 100 includes a radio access network (RAN) 103, and the RAN 102 may include multiple radio access network nodes, i.e., base stations configured to provide radio access in accordance with 5G (fifth-generation) radio access technology (5G New Radio). Note that the mobile radio communication system 100 may be configured in accordance with LTE (Long Term Evolution) or another mobile radio communication standard (e.g., non-3GPP access such as Wi-Fi), but 5G is used here as an example. Each radio access network node can provide radio communication with the mobile radio terminal device 102 through 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 includes a core network (5GC) 119, which includes an Access and Mobility Management Function (AMF) 101, a Unified Data Management (UDM) 104, and a Network Slice Selection Function (NSSF) 105 connected to the RAN 103. Here, and in the following example, the UDM may further consist of 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.

[0029] The core network 119 may have multiple core network slices 106, 107, and for each core network slice 106, 107, the operator (also known as an MNO from 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-NSI) 108 for providing improved mobile broadband (eMBB), and a second core network slice 107 having three core network slice instances (NSI) 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 referenced (if already instantiated) to form core network slice instances, and the network functions belonging to the core network slice instances are configured with core network slice instance identifiers.

[0031] Specifically, in the example shown, 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 and 112 are for handling PDU (protocol data unit) sessions, i.e., for creating, updating, and deleting PDU sessions, and for managing session contexts using the user plane function (UPF).

[0032] RAN 103 and 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 that access the mobile radio communication network together form a mobile radio communication system.

[0033] Similar to the core network 119, the RAN 103 may also be sliced, i.e., it may contain multiple RAN slices. The RAN slices and core network slices 106, 107 may be grouped together to form a network slice.

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

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

[0036] Furthermore, the core network 118 includes the NRF (Network Repository Function).

[0037] The core network 119 may further include a Network Data Analytics Function (NWDAF) 117. The NWDAF is responsible for providing network analytics and / or predictive information in response to requests from the network function.

[0038] Various network functions can be implemented on special hardware, namely, so-called ACTA (Advanced Telecommunications Computing Architecture) devices. This means that network functions are implemented as physical network functions deployed on special hardware. The software that implements the network functions is tightly coupled with the hardware.

[0039] However, it may be desirable to implement networking functionality as a software application running on non-specialized hardware, i.e., on a COTS (Commercial Off-the-Shelf) server (i.e., on a general-purpose or open computing platform, i.e., on a device). This is made possible by using virtualization technologies (e.g., hypervisors, operating system (OS) containers, etc.), and networking functionality (e.g., SMF, PCF, etc.) can be deployed in a virtual machine (a VM with one or more vCPUs) and / or an (operating system (OS)) container (a container can be considered a kind of "lightweight" VM that runs directly on the OS). These are called virtual networking functions (VNFs). VMs and OS containers are referred to herein by the general term "virtualized containers."

[0040] Network Function Virtualization Management and Command (NFV-MANO) is a key component of the ETSI (European Telecommunications Standards Institute) Network Function Virtualization (NFV) architecture. NFV-MANO is an architectural framework that coordinates the lifecycle management of network resources for cloud-based applications with virtual network functions (VNFs) and network services. Therefore, it is crucial for ensuring rapid and reliable NFV deployments at scale. NFV-MANO includes, among other things, the NFV Orchestrator (NFVO), the VNF Manager (VNFM), and the 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, meaning that one network service can be mapped to one or more network slices. In this case, the network slice is considered to provide an "application view" of the network, while the network service considers its "resource view."

[0041] Figure 2 shows OSS / BSS (Operations Support System and Business Support System) 201 and a simplified version of the NFV-MANO architecture framework. This includes functional blocks and sets of functions, data repositories used by these functional blocks, and reference points and interfaces through which these functional blocks exchange information for the purpose of managing and governing NFV.

[0042] Specifically, NFV-MANO includes NFVO 202, VNFM 203, VIM 204, and CISM (Container Infrastructure Services Management) 205. Below, 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 therefore only VIM 204 will be mentioned (i.e., VIM 204 and CISM 205 will be grouped together as VIM 204, as indicated by the dashed line).

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

[0044] Architecture 200 further includes NFVI 211, which includes hardware and software components that build the environment in which the VNF is deployed.

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

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

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

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

[0049] It should be noted that 3GPP's network functionality is responsible for managing and configuring network functions (NFs) and their interactions, but not for managing the virtual network functionality. From an NFV-MANO perspective, it is irrelevant which NF is the actual one "hosted" within the VNF.

[0050] The 3GPP network function (an element manager that communicates with OSS) manages the network function, and NFV-MANO (which also communicates with OSS) manages the VNFs that implement (i.e., host) them.

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

[0052] According to various embodiments, techniques for power management at the network service (NS) level are provided, taking into account the separation between physical network functions (such as AMF 207 in the example in Figure 2) and software introduced by the virtualization layer (such as SMF 208, PCF 209, and AF 210 in the example in Figure 2). In particular, techniques are provided for managing NS power management profiles in relation to VNF power profiles in a dynamic rather than fixed manner, as well as for maintaining NS runtime information (e.g., VNF identification and configuration information within the VNF / VM) and NFV-MANO management object information during power state transitions of network services.

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

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

[0055] In this example, each VNF 301, 302, and 303 has a VNF standby mode state 307, a VNF sleep (i.e., transition to standby) state 308, a VNF restart 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] The sleep mode state 308 may also be a low power consumption mode, which is an intermediate state before the standby mode 307 (which is the "minimum power consumption mode").

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

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

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

[0060] The same method is applicable to containerized network functions (CNFs) and physical network functions (PNFs), which are part of network services. For each VNF, CNF, and PNF that is part of a network service, there exists a power state machine. At any given time, all VNFs, CNFs, and PNFs are in a specific power state. In the following explanation, VNFs are used as an example, but the same principle applies to CNFs and PNFs as well.

[0061] Specifically, various embodiments provide methods for managing the NS power state. (At least one or more of the following conditions are met.) ●Power weights are used as follows: Regarding the power states of the NS power state, the importance of power states VNF 301, 302, and 303 is defined. ○ Resolve inter-VNF dependencies when performing power management at the NS level. ○When performing the power management at the NS level, resolve the dependencies between the NS and one or more other NSs. ● Power weights may be updated in response to (for example, user or operator) demands or autonomously. ● Power management (for applications and virtual resources) and the underlying physical power management are considered together. ●The power management capabilities provided by the aforementioned management and control systems for infrastructure and power-consuming elements are utilized. ●After power management operations are performed on the NS, the entire NS can be restored to its original power state. ● Any number of network services (and VNFs, CNFs, PNFs) power states can be managed.

[0062] It should be noted that there may be multiple instances of a network service, and each instance of a network service may have its own power state. Therefore, when referring to a network service (particularly with respect to its power state) below, this can be understood as referring to each instance of the network service.

[0063] According to various embodiments, the power state of network services is specified by an "energy-aware state" (EAS). Similarly, the power state of VNFs (and likewise CNFs and PNFs) is specified by the EAS. To distinguish between the two, the EAS of NS is specified as EAS , , NS#x , , VNFC , , is denoted as EAS of the VNF as EAS VNF is denoted. The EAS of the VNF VNF should be noted that it may depend on the power state of the component that may be specified by the EAS. The EAS of the VNF component is the EAS VNFC is described by. The EAS can be considered as an operational power profile mode. Hereinafter, "power state" and "operational power profile mode" or simply "power mode" are used interchangeably.

[0064] EAS NS of the VNF it contains, its EAS VNF of the CNF it contains, CNF and its EAS of the PNF it contains PNF The dependencies to are represented by a set including EAS VNF EAS, CNF EAS, PNF For example, for NS #x including VNF #1 to #n EAS NS#x ={EAS VNF#1 , EAS[2]] VNF#2 , …, EAS VNF#n}

[0065] As described above, each EAS VNF itself may depend on the EAS of its components VNFC Therefore, in the above expression, each EAS VNF#i itself may be represented as a set of EAS VNFC For example, EAS NS#x may be written in column form so as to be represented in the form of a matrix having a set of columns, and each column corresponds to the VNF of the NS and is a set of EAS of the VNFC of the VNF VNFC For example

Number

[0066] According to various embodiments, the above representation of the NS power state as a set of power states of its respective VNFs is extended to allow for adjustment of the way in which the power states of a VNF (e.g., standby state) are used to determine the power state of the NS containing the VNF. Furthermore, according to embodiments, a mechanism is provided for considering inter-VNF relationships. Similarly, for the case of CNFs and PNFs, relationships between VNFs and CNFs, CNFs and PNFs, and VNFs and PNFs are considered.

[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 are introduced: ●Type 1: EAS NS Power weights used to specify the "importance" of VNF (or CNF or PNF) ●Type 2: Power weights used to specify the "importance" of the dependencies between states in VNF and / or PNF and / or CNF. ●Type 3: Power weights used to specify the "importance" of a VNF, CNF, or PNF shared between different NSs (for example, for network slicing). ●Type 4: Power weights used to specify the "importance" of shared NSs between different NSs (for example, for network slicing).

[0069] According to various embodiments, every EAS VNF However, EAS CNF and EAS PNF However, regardless of which NS uses them or how they are used, they can be tested and evaluated on different platforms.

[0070] These types will be explained in more detail below.

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

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

number

number

[0073] Power weight ￣w i (t) can take on a numerical value (for example, it can vary between 0 and 1), but EAS VNF Other methods are possible depending on the form. For example, ￣w1(t)=0 means that VNF#1 is part of each NS, but it is not important when considering the NS power state, i.e., the NS power state, i.e., EAS NS This indicates that it is not considered when calculating EAS. VNF Depending on the form, the weighting operation may also be a logical operator (though it will still be written as multiplication "*" below).

[0074] Power weight ￣w i(t) may be modified on demand by the operator of the communication system using the respective NS power management function, or may change automatically due to LCM (Lifecycle Management Operation). In the second case, in the case of an NFV-MANO management entity (for example, an NFVO or VNFM triggering a power weight update through a call to the NS power management function), or other management systems such as O-RAN, the power weights may be updated from the SMO after interaction with a non-RT-RIC or near-RT-RIC. ● The business operator will use EAS for NS#1. VNF#1 This requests to change the power weight from 0 to 1. VNF#1 EAS NS#1 This means that something that was initially ignored (for example, did not affect the NS power state transition of NS#1) is now taken into consideration (for example, it has the highest importance if 1 is the maximum power weight). ● Intent-based requests from components of the communication system are parsed, and the intent handler function is assigned to a specific VNF (i.e., EAS) for a specific network service. VNF We decided to change the power weight values ​​(for this). ●During runtime, when MDAF (Management Data Analytics function) monitors and processes data related to a VNF, it processes data for a specific VNF for a specific network service (i.e., EAS). VNF We decide to change the power weights (for this).

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

number

number

[0076] Each VNF's EAS, i.e., each EAS VNF#i This is expressed in watts, for example. For instance, if the consumption of each VNF exceeds 50 watts, the state is considered "active," and if it is less than 50 watts, the state is "standby," and so on.

[0077] For example, using power weights, VNF#2 is EAS NS#1 Initially (t=0), this should be ignored, and the importance of VNF#3 is twice that of VNF#1. This is because

number

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

number

number

[0079] Therefore, Type 1 power weights allow for the determination of how important the VNF power state is to the NS power state.

[0080] EAS NS#1 This is, for example, the sum of VNF (and similarly CNF and PNF) consumption, and therefore, for example, EAS NS#1 = 5 watts + 20 watts + 30 watts = 55 watts.

[0081] EASNS Regarding how power weights are used by the system to derive this, more complex methods than simple addition may be considered.

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

[0083] Therefore, according to various embodiments, the dependency matrix W(t) is defined, and EAS NS It may be used to determine the level of dependency between the power states of the VNF, CNF, and PNF that provide the power states of the NS. The converse is also true.

[0084] In particular, considering the case of VNF as an example (the same applies to CNF and PNF), the EAS of VNF VNF The relationship between them is, for example, power weight w ij It is represented by an upper triangular matrix W(t) containing (t). Here, w ij (t) shows the power state dependency levels of VNF#i (or generally network function #i which may also be a PNF or CNF) and VNF#j (or generally network function #j) for example, in the case of the example in Figure 3 which has three VNFs 301, 302, and 303.

number

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

[0086] for example

number

[0087] In all cases, it is up to the controller (which resides within NS-PoMF) to decide how to interpret this information for a particular action.

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

[0089] Type 3 power weighting handles the case where the VNF is shared between two network services. This is shown in Figure 4.

[0090] Figure 4 shows three network services 401, 402, and 403. Each of these includes its own VNF (which may be an instance of the same VNF) 404, 405, 406, 407, and 408, the first network service 401 and the second network service 402 share the first shared VNF 409, and all three network services 401, 402, and 403 share the 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 importance of the sharing (regarding the power state of each network service), is signaled to the entity (i.e., the communication system component that determines the NS power state(s)).

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

number

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

[0094] In the above method, the matrix E for NS i i (t) is simply a one-dimensional matrix describing whether the VNF is shared or not. A multidimensional approach is also conceivable to describe the dependencies of the shared VNF and the importance of this sharing with other NSs at a finer granularity.

[0095] Type 4 power weighting handles the case where the entire network service is shared between two network services. This is shown in Figure 5.

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

[0097] This is a common use case under network slicing, where, 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 network-nested (sub)services are shared among network services is signaled to the entity (i.e., the communication system component that determines the NS power state(s)(single or multiple).

[0099] This is about network service #x, vector N x (t)=[n j (t) may be done by its j-th component n j (t) indicates whether the network service #j (i.e., the j-th 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 values ​​shown, 0 (no sharing) and 1 (shared), may be within the range [0;1], and their magnitudes may indicate the importance of their sharing for the power state of network service #i, i.e., the interdependence between network services that share each other's network services.

[0101] In the above method, N for NS i i (t) is simply a one-dimensional matrix describing whether nested NSs are shared. A multidimensional approach is also conceivable to describe the dependencies of shared NSs and the importance of this sharing with other NSs at a finer granularity.

[0102] The power weights for Type 3 (the importance of sharing VNF / CNF / PNF with other NFs) and Type 4 (the importance of sharing NS with other NSs) are the same as the power weights for Type 1 (NS) (￣W x (t): Importance of VNF / CNF / PNF in NS#x and power weight of type 2 (W) x (t): The importance of the relationship between VNF / CNF / PNF in NS#x, along with the various power weights and the EAS of NS#x VNF (and / or EAS CNF and / or EAS PNF Each function f that takes ) as input x It may be used as follows:

number

[0103] The function f depends on the power weights. x EAS NS#x EAS VNF EAS CNF EAS PNF Determine all actual importance. Various options are possible for modeling input parameters and outputs. In all cases, f xIt is up to the controller (present in the NS-PoMF) to determine how to interpret this information and take specific actions accordingly.

[0104] For example, EAS VNF 、EAS CNF 、and EAS PNF are expressed in watts, and assuming that f <gro00074>takes into account the sum of all weighted values. Then, the sum can give a value of xxx watts. Based on the policy, if this value exceeds the threshold, EAS NS#x is in an active state by the NS-PoMF, and if this value is below the threshold, EAS NS#x is in a standby state. EAS VNF 、EAS CNF 、and EAS PNF are calculated and mapped to the actual power consumption. If a request to change the EAS NS#x state comes to the NS-PoMF, the corresponding actions that affect the corresponding EAS VNF 、EAS CNF 、and EAS PNF are taken by the NS-PoMF according to the reverse f x operation.

[0105] The function f x (W x (t),￣W x (t),E x ​​​​​​​​​​​​​​​​​​Figure 6 shows an NFV architecture including an NS Power Manager Function (NS-PoMF) according to an embodiment.

[0108] As described with reference to FIG. 2, the NFV-MANO system 602 is connected to the OSS / BSS 601 and the NFVI 604. These components are connected to additional VNF (e.g., “general-purpose”) OAM functions 603 that include the NS-PoMF 600 in this example (but may be included in the NFV-MANO 602 itself, for example, as part of the NFVO). The NS-PoMF 600 may be viewed as (at least partially) implementing the power management system of each communication system (e.g., the communication system 100 of FIG. 1).

[0109] The NS-PoMF 600 may consider different f x depending on the use case. f x The selection is determined by the operator, and f x no constraints are imposed on the output (e.g., units). f x Regarding the input, in addition to the VNF / CNF / PNF power state and the corresponding power weights, additional inputs can also be considered. For example, management data analysis related to logging information, VNF performance, status, etc.

[0110] [[ID=二十]]The NS Power Management Function (NS-PoMF) 600, for example ·Is responsible for NS power state management. ·Interacts with the OSS / BSS and / or other NFV-MANO system components, etc., ·Has global knowledge of the NS power management status. ·Triggers updates of the power state at the NS level on demand or dynamically based on different inputs. ·Investigates the impact of transitions between states (e.g., when the entire NS transitions to the standby mode, etc.). ·Performs optimized NS LCM coordination with NFV-MANO system components. • Responsible for allocating, monitoring, and fine-tuning power weights. • Use common identification information to consider both VNF, CNF, and PNF as part of NS.

[0111] From a management perspective, the following operations are supported (for example, by the NS Power Management Function (NS-PoMF) 600): • Monitor power consumption related to VNF / CNF and PNF. • Managing the state of the entire NS using a simple vendor-independent API (for example, NS i (It can enter a standby state.) ·EAS VNF / CNF / PNF The exam and EAS NS Separating the test from the exam ·EAS NS Perform a system recovery action after the transition.

[0112] Furthermore, various power weights allow for scenarios such as the following: When a request is made for a network service to enter a standby state, not all VNFs and / or CNFs and / or PNFs should be affected (for example, one or more power states of the network service's VNFs should remain active). This can be achieved, for example, by properly setting the power weights of type 1. When a specific VNF / CNF / PNF of a network service enters a standby power state, the power state of the network service should be kept immutable (to avoid high configuration costs), which can be achieved, for example, by appropriately setting the power weights of type 1. If a VNF (or CNF or PNF) enters standby mode, tightly-coupled VNFs and / or CNFs and / or PNFs can also enter standby mode (or automatically enter standby mode). It is not necessary to keep them active. This can be achieved, for example, by properly setting the power weights for type 2. • When a VNF (or CNF or PNF) is shared among network services, and one of the network services enters a standby state, this does not affect the power state of other network services using the shared VNF. Examples of shared VNFs include inventory or database services. This is achieved, for example, by properly configuring Type 3 power weights. • When a network service is shared among network services, and one of the network services enters a standby state, this does not affect the power state of the other network services using the shared network service. This can be achieved, for example, by appropriately setting the power weights of type 4.

[0113] The weights are EAS VNF EAS CNF EAS PNF , and EAS NS This may be updated by the operator in a timely manner to change the relationship between them.

[0114] NS-PoMF 600 is a logic function that can be implemented as part of NFV-MANO 602 or externally. NS-PoMF 600 exposes an NS power state management interface for managing NS power states.

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

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

[0117] f i (W i (t),￣w i (t),E i (t)N i The various power weights that make up the input of (t)) may be defined, for example, in the network service descriptor (NSD) of NS#x.

[0118] For this purpose, an attribute such as nsdEnergyAwareStateWeights may be introduced to the NSD. [Table 1]

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

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

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

[0122] NS-PoMF 600 is EAS NS#x All relevant parameters are monitored and used to evaluate the correct behavior that should be performed. EAS NS#x Based on real-time information regarding this, as well as other inputs such as those from the MDA 605 and / or intent handler 606 (i.e., intent management), the NS-PoMF 600 can autonomously decide to update power weights. It can also autonomously determine the power state of the entire network service.

[0123] According to various embodiments, the NS-PoMF 600 also handles network service state management and restoration. The NS-PoMF 600 can manage EAS for VNFs, CNFs, and PNFs that constitute each network service.

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

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

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

[0127] Figure 7 shows that the network service transitions from an active power state 701 to a standby power state 702 (703), and then returns from the standby power state 702 to an active power state 701 (704).

[0128] To set NS 701 to standby power state 702, for example, the following is performed (for example, by NS-PoMF 600 through interaction with NFVI 604, NFV-MANO 602, etc.): • Store NS configuration (including power weights) and management information in a registry (with timestamps and versioning), for example, in PSR 607. • Maintain NS status data held by the management and control system. • Create an NS configuration snapshot to retain the NS state and configuration data (e.g., IP address information, interface identification information, gateway identification information and configuration, etc.), as well as the associated VNF / VNFC which can be used in the NS configuration and restoration procedures. • Track NFVI resources and maintain a map of them. This allows you to determine which resources are affected and change their power state in relation to VNF / CNF / PNF standby mode. • Resolve conflicts regarding power weight assignment for shared VNFs and shared NSs.

[0129] An example flow is shown below. 1) The EAS is "active" (i.e., 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 (i.e., 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 assignments 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 stores configuration information for the standby power state 702 (similar to step 2 for the active power state 701). 5) The NS-PoMF 600 triggers a transition 704 to the active power state 701 (i.e., active EAS). 6) The NS-PoMF 600 uses the configuration information stored in the PSR 607 to restore the network service configuration prior to the transition to the standby power state 703 (for example, the same VDU (virtual deployment unit), the same host machine(s), the same IP address, etc.) that was used by the network service prior to the transition to the standby power state 703, and then transitions back to the active power state 701.

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

[0131] As explained with reference to Figure 6, OSS / BSS 801, NS-PoMF 802, NFV-MANO 803, and NFVI 804 are involved in the flow. In this explanation, NS-PoMF is considered an external management entity of NFV-MANO.

[0132] In 805, the OSS / BSS 801 sends an NSD onboard request to the NFV-MANO 803. In the 806, NFV-MANO 803 and NFVI 804 are used to onboard the NSD and create NS instances following the normal procedure. Power weights, which are part of the NSD, are used in the EAS of the VNF for each network service. VNF It is used to describe different relationships between them (the same applies to CNF and PNF). In 807, NFV-MANO 803 sends a request for NS EAS registration and monitoring to NS-PoMF 802. In 808, NS-PoMF 802 registers the NS and continuously monitors the NS's EAS. In 809, NS-PoMF 802 decides to modify NS EAS, for example, based on statistical information. In 810, NFV-MANO 803, along with NS-PoMF 802 and NFVI 804 services, tunes the relevant parameters (for example, by reducing the number of vCPUs allocated to the VDU) to enable EAS. NS Update the data. Based on power weights, specific VNFs, CNFs, and PNFs will be affected.

[0133] Figure 9 shows a flowchart 900 illustrating the procedure for autonomously updating NS power weights via NS-PoMF 600.

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

[0135] In 905, OSS / BSS 901 sends an NSD onboard request to NFV-MANO 903. In version 906, NFV-MANO 903 and NFVI 904 are used to onboard the NSD and create NS instances following the normal procedure. Power weights, which are part of the NSD, are used in the EAS of the VNF for each network service. VNF It is used to describe different relationships between them, and the same applies to CNF and PNF. In 907, NFV-MANO 903 sends a request for NS EAS monitoring to NS-PoMF 902. In 908, NS-PoMF 902 registers the NS and continuously monitors the NS's EAS. In 909, NS-PoMF 902 autonomously decides to update the NS EAS power weights, for example, based on statistical information. In 910, NS-PoMF 902 is function f x Updated EAS NS Using power weights, EAS NS Calculate.

[0136] Figure 10 shows a flowchart 1000 illustrating the procedure for autonomously updating the NS power state through the shared VNF's NS-PoMF 600.

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

[0138] In step 1005, OSS / BSS 1001 sends a request for NSD onboarding of the two NSDs to NFV-MANO 1003. In NFV-MANO 1003 and NFVI 1004, the NFV-MANO onboards its NSDs and creates NS instances for each network service following the usual procedure. Power weights, which are part of the NSD, are the EAS of the VNF for each network service. VNF It is used to describe different relationships between them. Assume one VNF ("VNFx") is shared by two NSs. Power weight values ​​can be set by OSS or NS-PoMF. In step 1007, the NFV-MANO 1003 sends a request for NS EAS monitoring to the NS-PoMF 802 for both network services. In 1008, NS-PoMF 1002 registers both NSs and continuously monitors the EAS of the NSs. In 1009, the NS-PoMF 1002 recognizes the VNF sharing between the two NSs and monitors the system for potential events that may affect the relationship. In 1010, OSS / BSS 1002 requests NS-PoMF 1003 to modify the EAS of NS#1. In 1011, the NS-PoMF 1003 based on power weighting is function f x When calling, it recognizes the shared VNF between the two network services. Prior to the aforementioned change, it resolved the conflict and included EAS, including power weighting. NS Save it to PSR 607. In 1012, NFV-MANO 1003 updates the EAS of NS#1 by adjusting relevant parameters (e.g., reducing the number of vCPUs allocated to the VDU) along with the NFVI service. Based on power weights, specific VNFs are affected. In 1013, NS-PoMF 1003 responds to the EAS change request in 1011 (for example, by issuing an acknowledgment).

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

[0140] Figure 11 shows a flowchart 1100 illustrating a method for power management of a communication system.

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

[0142] In 1102, one or more power weights are determined, and each power weight is • Dependency between the power state of the network service and the power state of each functional component (among the one or more functional components). • The dependency between the power states of each of the two functional components (of the one or more functional components mentioned above), or • Dependencies between the power state of each functional component (of the aforementioned network service) and other network services. Specify.

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

[0144] In 1104, in response to a determined change (e.g., the receipt of the determination), the power states of the network service and the one or more functional components take into account the dependencies of the power states of the network service and / or the one or more functional components (in particular, to the power state to which the change was determined), as specified by power weights.

[0145] According to embodiments of the present invention, in other words, NS is managed in a dynamic manner with respect to "power management" taking power weights into consideration.

[0146] The method in Figure 11 allows for the consideration of special characteristics that dynamically constitute the VNF (considering physical and virtual resources, applications, and the VNF LCM together) for power management of NSs that include VNFs (and similarly for CNFs and PNFs).

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

[0148] It should be noted that the method in Figure 11 enables interaction not only with frameworks such as NFV-MANO and OSS, but also with all services provided by, for example, the General Purpose OAM Functionality Framework, as well as O-RAN SMO and / or O-RAN O-Cloud IMS.

[0149] According to various embodiments, the method shown in Figure 11 is used to control power consumption and improve energy efficiency in virtualized and / or cloud-based environments. It has many potential use cases related to energy efficiency, application of energy consumption policies, etc. (e.g., O-RAN-driven intelligent control), and there are many possible embodiments, including NS power management for the following: • Nested NS NS under Sharing / Slicing • NS based on CNF, PNF, and VNF NS in O-RAN

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

[0151] Therefore, according to various embodiments, telecommunications carrier control systems can be improved using novel methods / mechanisms and interfaces that enable NS power management and 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 an integrated control plane.

[0152] The method in Figure 11 may be implemented 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 kind of logic implementation entity, and may be a processor that runs dedicated circuitry or software, firmware, or any combination thereof stored in memory. Thus, a “circuit” may be a fixed-wiring logic circuit or a programmable processor, such as a microprocessor or other programmable logic circuit. A “circuit” may be software, such as a processor that runs any kind of computer program. Any other kind of implementation of each of the functions described above may also be understood as a “circuit”.

[0153] While individual aspects have been described, it should be understood by those skilled in the art that various modifications of form and detail are possible without departing from the intent and scope of the aspects of this disclosure as defined by the attached claims. Therefore, the scope is indicated by the attached claims, and is thus intended to encompass all modifications that fall within the meaning and scope of the equivalents of the claims.

Claims

1. A method for power management of a communication system: The steps include: providing network services through two or more functional components using the network function virtualization infrastructure of the aforementioned communication system; The network service power manager function sets one or more power weights, where each power weight is Between the power state of the network service and the power state of each of the two or more functional components During the power state of each of the two or more functional components mentioned above, or Between the power state of each of the two or more functional components and another network service Specify the dependencies, in stages; The steps include: determining, using the network service power manager function, the power state of the network service and at least one of the two or more functional components; In response to the determined change, the network service power manager function updates the power state of the network service and / or the two or more functional components, taking into account the power state dependencies of the network service and / or the two or more functional components as specified by the power weights; The network service power manager function includes the steps of updating the power weights in response to operational information about the communication system and storing the updated power weights, The preceding step of setting one or more power weights is: - Receive the network service descriptor for the aforementioned network service; - Including extracting the power weights from the network service descriptor, method.

2. The method according to claim 1, wherein the two or more functional components are two or more virtual network functions, two or more cloud-based network functions, two or more physical network functions, and / or two or more nested network services.

3. The method according to claim 1, wherein for each power weight, the magnitude of each power weight specifies the degree of each dependency, and the step of updating the power state of the network service and the two or more functional components in response to the determined change takes into account the specified degree of each dependency.

4. The method according to claim 1, wherein the step of updating the power state of the network service and the two or more functional components in response to a determined change resolves a conflict with a dependency on another functional component of the two or more functional components with respect to a request to update the power state by comparing the degree of dependency and considering the dependency between functional components of the two or more functional components.

5. The method according to claim 1, wherein at least one of the one or more power weights specifies that when each of the two or more functional components on which a second functional component depends is in a second power state, each of the two or more functional components on which a first functional component must not be in a first power state.

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

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

8. The method according to claim 1, wherein at least one of the one or more power weights specifies that when the power state of each of the two or more functional components shared with the other network service updates the power state of the respective functional component, the power state of the other network service must be taken into consideration.

9. The method according to claim 1, wherein deciding to make a change comprises the decided change being a return from a second power state to a first power state, wherein the previous change was changing the power state from the first power state to the second power state.

10. The method according to claim 9, further comprising the step of saving the power weight when changing the power state from the first power state to the second power state.

11. The method according to claim 10, comprising considering the power state dependencies of the network service and / or the two or more functional components as specified by the stored power weights.

12. A power management system for a communication system configured to perform the method described in any one of claims 1 to 11.

13. A computer program having instructions that, when executed by a computer, cause the computer to perform the method described in any one of claims 1 to 11.

Images