Device and method for realizing C state change of O-cloud node

Abstract

A system and method are provided for modifying a C-state of a processor in an open cloud (O-cloud) node within an O-cloud infrastructure of a telecommunications network in order to reduce power consumption associated with the processor within the O-cloud infrastructure, sending, by the FOCOM, a request to modify the C state of the processor of the O-cloud node to an infrastructure management service module IMS via the O2 interface; receiving, by the IMS via the O2 interface, a request to modify a C-state of a processor of the O-cloud node; controlling, by the IMS, implementation of a request to modify the C-state of the processor of the O-cloud node; an acknowledgement of the C-state modification of the processor of the O-cloud node is sent by the IMS to the FOCOM via the O2 interface.

Description

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS

[0002] This application is based on and claims the priority of Singapore Provisional Patent Application No. 10202250729D filed in the Singapore Patent Office on August 12, 2022, the disclosure of which is incorporated herein by reference in its entirety. Technical Field

[0003] Apparatus and methods consistent with example embodiments of the present disclosure relate to methods of optimizing process power consumption in a distributed network device. Background Art

[0004] In the related art, the radio access network (RAN) is an important component in a telecommunication system because it connects end-user devices (or user equipment) to the rest of the network. The RAN includes a combination of various network elements (NEs) that connect end-user devices to the core network. Traditionally, the hardware and / or software of a particular RAN is vendor-specific.

[0005] Open RAN (O-RAN) technology has emerged to enable multiple vendors to provide hardware and / or software to telecommunication systems. To this end, O-RAN decomposes RAN functions into centralized units (CU), distributed units (DU), and radio units (RU). CU is a logical node for hosting the radio resource control (RRC), service data adaptation protocol (SDAP), and / or packet data convergence protocol (PDCP) sublayers of the RAN. DU is a logical node for hosting the radio link control (RLC), media access control (MAC), and physical (PHY) sublayers of the RAN. RU is a physical node that converts the radio signal from the antenna into a digital signal that can be transmitted to the DU via the FrontHaul. Because these entities have open protocols and interfaces between them, they can be developed by different vendors.

[0006] Figure 1 is a diagram of the prior art O-RAN architecture. Figure 2 is a diagram of a prior art service management and orchestration (SMO) architecture with a non-real-time (NRT) RAN intelligent controller (RIC) architecture in a functional view, and Figure 3 is a diagram of a prior art SMO architecture with NRT RIC in a service view. Figures 1 to 3 , RAN functions in the O-RAN architecture are controlled and optimized by RIC. RIC is a software-defined component that implements modular applications to facilitate the multi-vendor operability required in O-RAN systems, as well as to automate and optimize RAN operations. RIC is divided into two types: NRT RIC and near real-time RIC (nRTRIC).

[0007] The NRT RIC is the control point of a non-real-time control loop and operates on a time scale greater than 1 second within the SMO framework. Its functionality is provided by a function called rApp ( Figure 1-Figure 3 It is implemented by modular applications of rApp1, rApp N) in the RAN, and includes: providing policy-based guidance and enrichment across the A1 interface, which is an interface that enables communication between NRT RIC and nRT RIC; performing data analysis; artificial intelligence / machine learning (AI / ML) training and reasoning for RAN optimization; and / or recommending configuration management actions through the O1 interface, which is an interface that connects the SMO to RAN management elements (e.g., nRT RIC, O-RAN centralized unit (O-CU), O-RAN distributed unit (O-DU), etc.).

[0008] The nRT RIC operates on a time scale between 10 milliseconds and 1 second and is connected to the O-DU, O-CU (decomposed into O-CU control plane (O-CU-CP) and O-CU user plane (O-CU-UP)) and open evolved NodeB (O-eNB) via the E2 interface. The nRT RIC uses the E2 interface to control the underlying RAN elements (E2 nodes / network functions (NFs)) through a near real-time control loop. The nRT RIC monitors, pauses / stops, covers and controls E2 nodes (O-CU, O-DU and O-eNB) through policies. For example, nRT sets policy parameters on the activation function of the E2 node. In addition, the nRT RIC hosts xApps to implement functions such as quality of service (QoS) optimization, mobility optimization, slice optimization, interference mitigation, load balancing, security, etc. The two types of RICs work together to optimize O-RAN. For example, NRT RIC provides policies, data, and artificial intelligence (AI) / machine learning (ML) models enforced by nRT RIC and used for RAN optimization through the A1 interface, and nRT returns policy feedback (i.e., how the policies set by NRT RIC are working).

[0009] The SMO framework in which the NRT RIC is located manages and orchestrates the RAN elements. Specifically, the SMO manages and orchestrates what is called the O-RAN cloud (O-cloud). The O-cloud is a collection of physical RAN nodes that host the RIC, O-CU and O-DU, supporting software components (e.g., operating system and runtime environment), and the SMO itself. In other words, the SMO manages the O-cloud from the inside. The O2 interface is the interface between the SMO and the O-cloud where it resides. Through the O2 interface, the SMO provides infrastructure management services (IMS) and deployment management services (DMS).

[0010] Each O-cloud node typically includes one or more processors or CPUs, and each such processor consumes a given amount of power. A known method of CPU power management is to modify the C-state and P-state of the processor. More specifically, there are generally two ways to manage the power consumed by the CPU: (1) by completely powering off certain subsystems of the CPU (such as one or more cores of memory or specific caches) to eliminate the power consumed by the subsystem (i.e., by eliminating the voltage supply to the associated subsystems of the CPU to reduce or shut down certain functions); or, (2) by reducing the voltage and / or frequency of the CPU (or one or more of its subsystems) to reduce power consumption. Of these two options, the former is achieved by modifying the processor's "C-state" (also known as the "idle state" or "idle power saving state"), while the latter is achieved by modifying the "P-state" (also known as the "execution power saving state").

[0011] Typically, C-states and P-states are numbered starting from zero (e.g., C0, C1 and P0, P1). The general convention is that the higher the number, the more power is saved. C0 means no power savings because everything is powered on. Likewise, P0 means maximum performance, and therefore the maximum frequency, voltage, and power used. Different CPUs have different C-states and P-states.

[0012] With respect to C-states, each processor typically has its own separate set of C-states. As an example, the basic C-states defined under the Advanced Configuration and Power Interface (ACPI) power management specification include:

[0013] C0: Active, the CPU / core is executing instructions. P-states are relevant here, the CPU / core can be operating at its maximum performance (thus at P0) or at lower performance / power (thus at anything but P0).

[0014] C1: Stop, no operation is performed, but it can return to C0 instantly. Since it is not working (but stopped), the P state is not related to C1 or any Cx except C0.

[0015] C2: Stops the clock, similar to C1, but takes longer to return to C0.

[0016] C3: Sleep. It can return to C0, but it will take quite a long time.

[0017] Additionally, most modern CPUs have multiple cores in a single package. Therefore, C-states can also be divided into core C-states (CC-states) and package C-states (PC-states). The reason for the PC-states is that there are other (shared) components in the processor that can also be powered off after all cores using them are powered off (e.g., shared caches). However, users or programmers generally cannot manipulate the PC-states because users and programmers do not interact directly with the package, but with individual cores. Therefore, users and programmers can only directly affect the CC-states, while the PC-states are indirectly affected based on the CC-states of the cores.

[0018] P-states are only relevant for a CPU core to be in C0 state, since the CPU must be powered on to execute code. P-states allow the voltage and frequency (in other words, the operating point) of the CPU core to be changed to reduce the power consumption of the CPU. There is a set of P-states corresponding to different operating points (voltage-frequency pairs), and a given P-state refers to one such operating point. The highest (frequency and voltage) operating point is usually the maximum performance state, i.e., P0. Just like C-states, different CPUs have different available P-states.

[0019] Example embodiments of the present disclosure provide a method and system in which power consumption of an O-cloud node is managed by adjusting the C-state of one or more processors incorporated into the node.

[0020] In the related art, a CPU included in an O-cloud node may operate at full capacity, and therefore at full power, even if the volume of traffic occurring on the node does not warrant such operating capacity nor the associated power consumption, thereby resulting in unnecessary and inefficient power consumption. Summary of the invention

[0021] According to an embodiment, systems and methods are provided for modifying C-states of processors in an open cloud (O-Cloud) node within an O-Cloud infrastructure of a telecommunications network in order to reduce power consumption associated with the processors within the O-Cloud infrastructure.

[0022] According to an embodiment, a method for managing power consumption of one or more open cloud (O-cloud) nodes within an O-cloud infrastructure of a telecommunications network, the method being performed by at least one processor, the method comprising: obtaining, by a joint O-cloud orchestration and management module (FOCOM) within a service management orchestration (SMO) framework, a request for modifying the C-state of a processor of an O-cloud node within the O-cloud infrastructure of the telecommunications network; sending, by FOCOM, a request for modifying the C-state of the processor of the O-cloud node to an infrastructure management service module IMS via an O2 interface; receiving, by IMS, a request for modifying the C-state of the processor of the O-cloud node via the O2 interface; controlling, by the IMS, implementation of the request for modifying the C-state of the processor of the O-cloud node; and sending, by the IMS, a confirmation of the C-state modification of the processor of the O-cloud node to FOCOM via the O2 interface.

[0023] The method may also include: monitoring, by a non-real-time radio intelligent controller (NRT RIC), O-cloud data received through the O2 interface; analyzing the O-cloud data and identifying, based on the analysis, O-cloud nodes to be modified within the O-cloud infrastructure; and sending an O-cloud node C-state modification request to the FOCOM.

[0024] The method may also include: monitoring, by a user, O-cloud data received through the O2 interface; analyzing the O-cloud data and identifying an O-cloud node to be modified within the O-cloud infrastructure based on the analysis; and sending an O-cloud node C-state modification request to FOCOM.

[0025] The method may also include sending, by the FOCOM, a confirmation of the C-state modification of the process of the O-cloud node to at least one of the user and a non-real-time radio intelligent controller (NRT RIC).

[0026] The O-Cloud data received through the O2 interface may include at least one of processor utilization and memory utilization.

[0027] According to one embodiment, a system for managing power consumption of one or more open cloud (O-cloud) nodes within an O-cloud infrastructure of a telecommunications network includes: at least one memory configured to store computer program code; and at least one processor configured to access the at least one memory and operate as directed by the computer program code, the computer program code including: O-cloud infrastructure implementation code configured to cause the at least one processor to implement: (i) a joint O-cloud orchestration and management module (FOCOM) within a service management orchestration (SMO) framework, (ii) an infrastructure management service module (IMS), and (iii) an SM An O2 interface between O and IMS; an obtaining code configured to cause at least one processor to obtain, through FOCOM, a request for modifying the C-state of a processor of an O-cloud node within an O-cloud infrastructure of a telecommunications network; a sending code configured to cause at least one processor to send a request from FOCOM to IMS via the O2 interface to modify the C-state of the processor of the O-cloud node; a control code configured to cause at least one processor to implement, through IMS, a request for modifying the C-state of the processor of the O-cloud node; and a sending code configured to cause at least one processor to send a confirmation of the C-state modification of the processor of the O-cloud node from IMS to FOCOM via the O2 interface.

[0028] The O-cloud infrastructure implementation code may also include: code configured to cause at least one processor to implement a non-real-time radio intelligent controller (NRT RIC), and wherein the computer program code may also include: monitoring code configured to cause at least one processor to receive O-cloud data through the NRT RIC via the O2 interface; analysis code configured to cause at least one processor to analyze the O-cloud data through the NRT RIC, and based on the analysis, identify the O-cloud nodes to be modified within the O-cloud infrastructure; and sending code configured to cause at least one processor to send an O-cloud node C-state modification request to FOCOM through the NRT RIC.

[0029] The system may also include a human-machine interface configured to allow a user to receive and analyze O-cloud data via the O2 interface, and also to allow a user to send an O-cloud node C-state modification request to the FOCOM.

[0030] The O-cloud infrastructure implementation code may also include code configured to cause at least one processor to implement a non-real-time radio intelligent controller (NRT RIC), and wherein the computer program code also includes sending code configured to cause at least one processor to send a confirmation of the C-state modification of the process of the O-cloud node to at least one of the user and the NRT RIC via FOCOM.

[0031] According to one embodiment, a non-transitory computer-readable medium having instructions stored therein is provided, which, when executed by a processor, causes the processor to perform a method for managing power consumption of one or more open cloud (O-cloud) nodes within an O-cloud infrastructure of a telecommunications network, the method comprising: obtaining, by a joint O-cloud orchestration and management module (FOCOM) within a service management orchestration (SMO) framework, a request for modifying the C-state of a processor of an O-cloud node within the O-cloud infrastructure of the telecommunications network; sending, by the FOCOM, a request for modifying the C-state of the processor of the O-cloud node to an infrastructure management service module IMS via an O2 interface; receiving, by the IMS, a request for modifying the C-state of the processor of the O-cloud node via the O2 interface; controlling, by the IMS, implementation of the request for modifying the C-state of the processor of the O-cloud node; and sending, by the IMS, a confirmation of the C-state modification of the processor of the O-cloud node to the FOCOM via the O2 interface.

[0032] A non-transitory computer-readable medium having instructions stored therein, which when executed by a processor may cause the processor to perform the following additional operations: monitoring, by a non-real-time radio intelligent controller (NRT RIC), O-cloud data received via an O2 interface; analyzing the O-cloud data and identifying, based on the analysis, O-cloud nodes to be modified within the O-cloud infrastructure; and sending an O-cloud node C-state modification request to the FOCOM.

[0033] A non-transitory computer-readable medium having instructions stored therein, which when executed by a processor can cause the processor to perform the following additional operations: monitoring O-cloud data received through the O2 interface by a user; analyzing the O-cloud data and identifying O-cloud nodes to be changed within the O-cloud infrastructure based on the analysis; and sending an O-cloud node C-state modification request to FOCOM.

[0034] A non-transitory computer-readable medium having instructions stored therein, which when executed by a processor may cause the processor to perform the following additional operations: sending, by the FOCOM, a confirmation of the C-state modification of the process of the O-cloud node to at least one of a user and a non-real-time radio intelligent controller (NRT RIC).

[0035] Additional aspects will be set forth in part in the description which follows and, in part, will be obvious from the description, or may be achieved by practice of the presented embodiments of the disclosure. BRIEF DESCRIPTION OF THE DRAWINGS

[0036] Features, aspects, and advantages of certain exemplary embodiments of the present disclosure will be described below with reference to the accompanying drawings, in which like reference numerals represent like elements, and in which:

[0037] Figure 1 is a diagram of an O-RAN architecture according to one embodiment.

[0038] Figure 2 is a diagram of a prior art service management and orchestration (SMO) framework with a non-real-time (NRT) RAN intelligent controller (RIC) architecture in a functional view.

[0039] Figure 3 is a diagram of a prior art SMO framework with NRT RIC in a service view.

[0040] Figure 4 is a diagram of an O-RAN architecture according to one embodiment.

[0041] Figure 5 is a sequence diagram of a method for modifying the C-state of one or more O-cloud node processors according to one embodiment.

[0042] Figure 6 is a flow chart of a method for power management in O-RAN according to one embodiment.

[0043] Figure 7 is a diagram of an example environment in which the systems and / or methods described herein may be implemented;

[0044] Figure 8 is a diagram of example components of a device according to one embodiment. DETAILED DESCRIPTION

[0046] The following detailed description of exemplary embodiments refers to the accompanying drawings. The above disclosure provides illustrations and descriptions, but is not intended to be exhaustive or to limit the implementation to the precise form disclosed. Modifications and variations are possible based on the above disclosure, or modifications and variations can be obtained from the practice of implementation. In addition, one or more features or components of an embodiment may be incorporated into another embodiment (or one or more features of another embodiment) or combined with another embodiment (or one or more features of another embodiment). Additionally, in the flowcharts and descriptions of the operations provided below, it should be understood that one or more operations may be omitted, one or more operations may be added, one or more operations may be performed simultaneously (at least partially), and the order of one or more operations may be switched.

[0047] Obviously, the systems and / or methods described herein can be implemented in different forms of hardware, firmware, or a combination of hardware and software. The actual dedicated control hardware or software code used to implement these systems and / or methods is not a limitation to the implementation. Therefore, the operation and behavior of the systems and / or methods are not described herein with reference to specific software codes. It should be understood that software and hardware can be designed to implement the systems and / or methods based on the description herein.

[0048] Even though particular combinations of features are recited in the claims and / or disclosed in the specification, these combinations are not intended to limit the disclosure of possible implementations. In fact, many of these features may be combined in ways not specifically recited in the claims and / or disclosed in the specification. Although each dependent claim listed below may directly depend on only one claim, the disclosure of possible implementations includes each dependent claim in combination with every other claim in the claim set.

[0049] The elements, actions or instructions used herein should not be interpreted as critical or necessary unless explicitly described as such. In addition, as used herein, the articles "one" and "an" are intended to include one or more items and can be used interchangeably with "one or more". In the case of only one item, the term "one" or similar language is used. In addition, as used herein, the terms "have", "have", "have", "include", "include with" etc. are intended to be open terms. In addition, the phrase "based on" is intended to mean "based at least in part", unless otherwise explicitly stated. In addition, statements such as "at least one of [A] and [B]" or "at least one of [A] or [B]" should be understood to include only A, only B, or both A and B.

[0050] Example embodiments provide systems (and methods, devices, networks, etc.) for power management in an open radio access network (O-RAN). In particular, the system can monitor an O-RAN cloud (O-cloud) node by obtaining parameters indicating a service level of the O-RAN. The parameters indicating the service level can include central processing unit (CPU) usage of the O-cloud node, memory usage of the O-cloud node, disk throughput of the O-cloud node, etc. The system can obtain the parameters from the O-cloud server. The parameters can be collected and analyzed by the NRTRIC from O2 telemetry.

[0051] Based on the obtained parameters, the system can determine whether at least one of the collected parameters of the O-cloud node satisfies a predetermined modification condition. The predetermined modification condition can include a condition based on: the CPU usage of the O-cloud node is lower than a CPU usage percentage threshold, the memory usage of the O-cloud node is lower than a memory usage percentage threshold, the disk throughput of the O-cloud node is lower than a disk throughput usage percentage threshold, and / or a combination of these conditions. Based on determining that at least one of the collected parameters satisfies the predetermined modification condition, the system can change the C-state of the processor within the O-cloud node.

[0052] The system may include a federated O-cloud orchestration and management (FOCOM) controller of a service management and orchestration (SMO) framework, and the system may determine that at least one parameter satisfies a modification condition based on a predefined modification policy configured for the FOCOM controller. The system may alternatively or additionally include a non-real-time (NRT) RAN intelligent controller (RIC) for the SMO, and the NRT RIC may be configured to perform the above operations.

[0053] Based on determining that at least one parameter satisfies a predetermined modification condition and before changing the C-state of the O-cloud node processor, the system can notify the O-cloud node that the O-cloud node is determined to be subject to a processor C-state change. In this case, the C-state of the O-cloud node processor can be changed after a predetermined grace period, which begins approximately when the O-cloud node is notified. Alternatively, the system can perform a non-graceful modification of the C-state of the O-cloud node processor without providing a notification that the C-state of the O-cloud node processor is determined to be modified. In addition, the system can terminate at least one application running on the O-cloud node before the O-cloud node is deactivated.

[0054] Therefore, by monitoring the O-RAN as disclosed herein, power consumption can be reduced by changing the C-state O-cloud node processor when it is in limited or no use.

[0055] Figure 1 1 is a diagram of an O-RAN architecture 100 according to one embodiment. The O-RAN architecture 100 may include a SMO framework 102, which includes an NRT RIC 104 and a FOCOM controller 106. The O-RAN architecture 100 may include a near real-time (nRT) RIC 108, an O-RAN centralized unit (O-CU) control plane (O-CU-CP) 110, an O-CU user plane (O-CU-UP) 112, an O-RAN distributed unit (O-DU) 114, an O-RAN radio unit (O-RU) 116, and an O-RAN cloud (O-cloud) server 118. The O-cloud server 118 may include an infrastructure management service (IMS) module 120 and a deployment management service (DMS) module 122. As shown in FIG. Figure 1 As shown, the FOCOM controller 106 may be configured to obtain parameters indicating the service performance of the O-cloud node from the O-cloud server 118. That is, the NRT RIC 104 may push a predefined shutdown policy to the FOCOM controller 106.

[0056] Figure 44 is a diagram of an O-RAN architecture 400 according to one embodiment. The O-RAN architecture 400 is similar to the O-RAN architecture 100, except that the NRT RIC 404 is configured to push the C-state modification action. In addition, the O-RAN architecture 400 includes a fronthaul (FH) M plane 450, which includes an O-CU 410 and an O-DU 414, and an O-RU 416 connected to the FH M plane 450. In such an embodiment, the NRT RIC 404 can obtain parameters indicating the processor utilization of the O-cloud node directly from the O-cloud server 418, and can be configured to determine the modification of the O-cloud node processor C-state based on these parameters. The NRT RIC 404 can be configured to determine the modification of the O-cloud node processor C-state without implementing a policy such as a policy implemented with the FOCOM controller 406. The NRT RIC 404 can be configured to push the C-state modification operation to the IMS module 420.

[0057] Figure 5 A sequence diagram of a method for modifying the C-state of a processor of one or more O-cloud nodes according to one embodiment is shown. Figure 5 The key components of the O-RAN architecture in Figure 1 components.

[0058] refer to Figure 5 , a method for implementing modification of the C-state of one or more O-cloud node processors can be triggered by an event such as telemetry indicating that one or more O-cloud node processors are being used at a level below a predetermined threshold, or input from a non-RAN source (e.g., O1 interface and / or O2 interface data).

[0059] exist Figure 5 In the method for implementing modification of the C-state of one or more O-cloud node processors can be initiated by a manual request of a user to the SMO or by one or more rApps of an NRT-RIC within the SMO.

[0060] refer to Figure 5 , which is shown as an O-Cloud Node Analysis Process and marks the beginning of the O-Cloud Node Reconfiguration Procedure. The initiation of the O-Cloud Node Analysis Process is based on monitoring O-Cloud data received through the O2 interface by a user or NRT-RIC, analyzing the O-Cloud data, and based on the analysis, determining at least one O-Cloud Node processor to be reconfigured within the O-Cloud infrastructure.

[0061] To this end, when the NRT-RIC within the SMO initiates the method, one or more rApps in the NRT-RIC perform the O-cloud node analysis process as described above.

[0062] In an example embodiment, the analysis may be based on a comparison between O2 interface telemetry data related to usage of the at least one O-cloud node (e.g., O-cloud data such as processor load, memory usage, etc.). Based on the analysis, the NRT-RIC (e.g., one or more rApps of the NRT-RIC) determines to reconfigure at least one O-cloud node of the plurality of O-cloud nodes (i.e., the NRT-RIC initiates an O-cloud reconfiguration procedure for the at least one O-cloud node).

[0063] According to the O-cloud reconfiguration procedure, in operation 501, in one example embodiment, the NRT-RIC (e.g., one or more rApps of the NRT-RIC) collects and analyzes O2 telemetry (e.g., O-cloud data such as processor load, memory usage, etc.), and identifies one or more O-cloud nodes among a plurality of O-cloud nodes that meet certain predefined criteria for processor C-state modification, and further identifies appropriate C-state modifications to implement for each identified C-cloud node. In another example embodiment, operation 501 is performed by a cloud maintainer (e.g., a user).

[0064] In operation 502, in one example embodiment, the SMO (i.e., FOCOM) obtains a request from a cloud maintainer (e.g., a user) to apply a desired C-state to a processor associated with the O-cloud node identified in operation 501. In operation 502, in another example embodiment, the FOCOM obtains a request from the NRT-RIC to reconfigure at least one O-cloud node based on the results of the O-cloud analysis process as described above.

[0065] In operation 503, FOCOM sends a reconfiguration request to IMS via the O2 interface based on the determination or specification as described above. The reconfiguration request includes, for each O-cloud node to be reconfigured, an identification of each O-cloud node to be reconfigured and a processor C-state to be applied to each such O-cloud node. Operation 503 may be repeated for each O-cloud node identified in operation 501.

[0066] In operation 504, upon receiving the FOCOM reconfiguration request via the O2 interface, the IMS changes the processor C-state to the desired C-state for each O-cloud node to be reconfigured. The change of the O-cloud node processor C-state is enabled from the O-cloud node BIOS.

[0067] In operation 505, for each corresponding O-cloud node, the IMS notifies the SMO that the O-cloud node C-state modification is completed. In an example embodiment, the IMS sends a reconfiguration confirmation to the FOCOM via the O2 interface.

[0068] Referring also to operation 505, in one example embodiment, in the case where NRT-RIC has subscribed to IMS notifications, IMS notifies NRT-RIC via the O2 interface of the state of the O-cloud node (i.e., the state of the reconfigured (multiple) O-cloud nodes). In operation 506, SMO notifies the cloud maintainer and NRT RIC that the O-cloud node C state modification is completed. In another example embodiment, IMS may notify FOCOM and NRT-RIC via the O2 interface of the completion of the reconfiguration.

[0069] Reference Figure 5 , when the C-states of all O-cloud nodes identified in operation 501 are completed, the method for implementing modification of the processor C-state of one or more O-cloud nodes ends.

[0070] Figure 6 6 is a flow chart of a method for power management in O-RAN according to one embodiment. In operation 601, a cloud maintainer (e.g., a user) or an rApp via an NRT RIC identifies a set of O-cloud nodes to be placed in low power mode based on analysis of O2 telemetry such as CPU utilization, memory utilization, etc. In operation 602, the cloud maintainer or the rApp via the NRTRIC triggers the SOM (e.g., FOCOM) to place the processor of the O-cloud node identified in operation 601 in a desired C-state. In operation 603, FOCOM uses the O2 IMS service to request the IMS to change the C-state of the processor in the O-cloud node identified in operation 601. Operation 603 can be repeated for each identified O-cloud node. In an alternative embodiment, the FOCOM request is sent to the IMS as a batch. In operation 604, the IMS changes the C-state of the processor in the identified O-cloud node to the desired C-state. In operation 605, the IMS notifies the SMO that the O-cloud node C-state change requested in operation 603 is completed. In operation 606 , the SMO notifies the cloud maintainer and / or NRT RIC that the O-cloud node C state change triggered in operation 602 is completed.

[0071] Figure 7 7 is a diagram of an example environment 700 in which the systems and / or methods described herein may be implemented. Figure 7 As shown, environment 700 may include user device 710, platform 720, and network 730. The devices of environment 700 may be interconnected via wired connections, wireless connections, or a combination of wired and wireless connections. Figure 7 Any functions and operations described can be performed by Figure 7 The invention may be performed by any combination of the elements shown.

[0072] User device 710 includes one or more devices capable of receiving, generating, storing, processing, and / or providing information associated with platform 720. For example, user device 710 may include a computing device (e.g., a desktop computer, a laptop computer, a tablet computer, a handheld computer, a smart speaker, a server, etc.), a mobile phone (e.g., a smart phone, a wireless phone, etc.), a wearable device (e.g., a pair of smart glasses or a smart watch), or a similar device. In some implementations, user device 710 can receive information from platform 720 and / or send information to platform 720.

[0073] The platform 720 includes one or more devices capable of receiving, generating, storing, processing and / or providing information. In some implementations, the platform 720 may include a cloud server or a group of cloud servers. In some implementations, the platform 720 may be designed to be modular so that certain software components may be swapped in or out according to specific needs. In this way, the platform 720 may be easily and / or quickly reconfigured for different uses.

[0074] In some implementations, as shown, the platform 720 can be hosted in a cloud computing environment 722. It is worth noting that while the implementations described herein describe the platform 720 as being hosted in a cloud computing environment 722, in some implementations, the platform 720 may not be cloud-based (i.e., may be implemented outside of a cloud computing environment) or may be partially cloud-based.

[0075] Cloud computing environment 722 includes an environment that hosts platform 720. Cloud computing environment 722 can provide computing, software, data access, storage, etc. services that do not require end users (e.g., user devices 710) to be aware of the physical location and configuration of the system(s) and / or device(s) hosting platform 720. As shown, cloud computing environment 722 can include a set of computing resources 724 (collectively, “computing resources 724” and individually, “computing resource 724”).

[0076] The computing resources 724 include one or more personal computers, computing device clusters, workstation computers, server devices, or other types of computing and / or communication devices. In some implementations, the computing resources 724 can host the platform 720. Cloud resources can include computing instances executed in the computing resources 724, storage devices provided in the computing resources 724, data transmission devices provided by the computing resources 724, etc. In some implementations, the computing resources 724 can communicate with other computing resources 724 via wired connections, wireless connections, or a combination of wired and wireless connections.

[0077] like Figure 7As further shown in FIG. 7 , the computing resources 724 include a set of cloud resources, such as one or more applications (“APP”) 724 - 1, one or more virtual machines (“VM”) 724 - 2, virtualized storage (“VS”) 724 - 3, one or more hypervisors (“HYP”) 724 - 4, and the like.

[0078] The applications 724-1 include one or more software applications that may be provided to or accessed by the user device 710. The applications 724-1 may eliminate the need to install and execute software applications on the user device 710. For example, the applications 724-1 may include software associated with the platform 720 and / or any other software that may be provided via the cloud computing environment 722. In some implementations, one application 724-1 may send / receive information to / from one or more other applications 724-1 via the virtual machine 724-2.

[0079] Virtual machine 724-2 includes a software implementation of a machine (e.g., a computer) that executes programs similar to physical machines. Virtual machine 724-2 can be a system virtual machine or a process virtual machine, depending on the use and correspondence of virtual machine 724-2 to any real machine. System virtual machines can provide a complete system platform that supports the execution of a complete operating system ("OS"). Process virtual machines can execute a single program and can support a single process. In some implementations, virtual machine 724-2 can execute on behalf of a user (e.g., user device 710) and can manage the infrastructure of cloud computing environment 722, such as data management, synchronization, or long-duration data transfer.

[0080] Virtualized storage 724-3 includes one or more storage systems and / or one or more devices using virtualization technology within the storage system or device of computing resource 724. In some implementations, in the context of a storage system, the types of virtualization may include block virtualization and file virtualization. Block virtualization may refer to the abstraction (or separation) of logical storage from physical storage, so that the storage system may be accessed without regard to physical storage or heterogeneous structures. Separation may allow administrators of storage systems to have flexibility in how administrators manage storage for end users. File virtualization may eliminate the dependency between data accessed at the file level and the location where the file is physically stored. This may enable optimization of the performance of storage usage, server consolidation, and / or non-destructive file migration.

[0081] Hypervisor 724-4 may provide hardware virtualization technology that allows multiple operating systems (e.g., "guest operating systems") to execute concurrently on a host computer such as computing resource 724. Hypervisor 724-4 may present a virtual operating platform to the guest operating systems and may manage the execution of the guest operating systems. Multiple instances of various operating systems may share virtualized hardware resources.

[0082] The network 730 includes one or more wired and / or wireless networks. For example, the network 730 may include a cellular network (e.g., a fifth generation (5G) network, a long term evolution (LTE) network, a third generation (3G) network, a code division multiple access (CDMA) network, etc.), a public land mobile network (PLMN), a local area network (LAN), a wide area network (WAN), a metropolitan area network (MAN), a telephone network (e.g., a public switched telephone network (PSTN)), a private network, an ad hoc network, an intranet, the Internet, a fiber-based network, etc. and / or a combination of these or other types of networks.

[0083] Figure 7 The number and arrangement of devices and networks shown in FIG. 1 are provided as an example. In practice, Figure 7 There may be more devices and / or networks, fewer devices and / or networks, different devices and / or networks, or differently arranged devices and / or networks than those shown. Figure 7 Two or more of the devices shown may be implemented in a single device, or Figure 7 The single device shown may be implemented as multiple distributed devices. Additionally or alternatively, one set of devices (eg, one or more devices) of environment 700 may perform one or more functions described as being performed by another set of devices of environment 700.

[0084] Figure 8 8 is a diagram of example components of a device 800. The device 800 may correspond to the user device 710 and / or the platform 720. Figure 8 As shown, device 800 may include a bus 810 , a processor 820 , a memory 830 , a storage component 840 , an input component 850 , an output component 860 , and a communication interface 870 .

[0085] The bus 810 includes components that allow communication between components of the device 800. The processor 820 can be implemented in hardware, firmware, or a combination of hardware and software. The processor 820 can be a central processing unit (CPU), a graphics processing unit (GPU), an accelerated processing unit (APU), a microprocessor, a microcontroller, a digital signal processor (DSP), a field programmable gate array (FPGA), an application-specific integrated circuit (ASIC), or another type of processing component. In some implementations, the processor 820 includes one or more processors that can be programmed to perform functions. In some implementations, the processor 820 is a single processor with multiple cores. The memory 830 includes a random access memory (RAM), a read-only memory (ROM), and / or another type of dynamic or static storage device (e.g., flash memory, magnetic memory, and / or optical memory) that stores information and / or instructions for use by the processor 820.

[0086] The storage component 840 stores information and / or software related to the operation and use of the device 800. For example, the storage component 840 may include a hard disk (e.g., a magnetic disk, an optical disk, a magneto-optical disk, and / or a solid-state disk), a compact disk (CD), a digital versatile disk (DVD), a floppy disk, a cassette, a magnetic tape, and / or other types of non-transitory computer-readable media and corresponding drives. The input component 850 includes components that allow the device 800 to receive information, such as via user input (e.g., a touch screen display, a keyboard, a keypad, a mouse, buttons, switches, and / or a microphone). Additionally or alternatively, the input component 850 may include a sensor for sensing information (e.g., a global positioning system (GPS) component, an accelerometer, a gyroscope, and / or an actuator). The output component 860 includes components that provide output information from the device 800 (e.g., a display, a speaker, and / or one or more light emitting diodes (LEDs)).

[0087] The communication interface 870 includes a transceiver-like component (e.g., a transceiver and / or a separate receiver and transmitter) that enables the device 800 to communicate with other devices, such as via a wired connection, a wireless connection, or a combination of a wired and wireless connection. The communication interface 870 can allow the device 800 to receive information from another device and / or provide information to another device. For example, the communication interface 870 may include an Ethernet interface, an optical interface, a coaxial interface, an infrared interface, a radio frequency (RF) interface, a universal serial bus (USB) interface, a Wi-Fi interface, a cellular network interface, etc.

[0088] Device 800 can perform one or more processes described herein. Device 800 can perform these processes in response to processor 820 executing software instructions stored by non-transitory computer-readable media (such as memory 830 and / or storage component 840, etc.). Computer-readable media is defined herein as non-transitory memory devices. Memory devices include memory space within a single physical storage device or memory space distributed on multiple physical storage devices.

[0089] The software instructions may be read into memory 830 and / or storage component 840 from another computer-readable medium or from another device via communication interface 870. When executed, the software instructions stored in memory 830 and / or storage component 840 may cause processor 820 to perform one or more processes described herein.

[0090] Additionally or alternatively, hardwired circuitry may be used in place of or in combination with software instructions to perform one or more processes described herein.Thus, implementations described herein are not limited to any specific combination of hardware circuitry and software.

[0091] Figure 8 The number and arrangement of components shown in FIG. 8 are provided as an example. In practice, device 800 may include Figure 8 More components, fewer components, different components, or differently arranged components than those shown. Additionally or alternatively, one set of components (e.g., one or more components) of device 800 may perform one or more functions described as being performed by another set of components of device 800.

[0092] In an embodiment, Figures 5 and 6 Any operation or process can be carried out by or using Figures 1 to 4 and Figures 7 and 8 It should be understood that other embodiments are not limited thereto and can be implemented in a variety of different architectures (e.g., bare metal architecture, any cloud-based architecture or deployment architecture, such as Kubernetes, Docker, openstack, etc.).

[0093] According to an example embodiment, one or more O-cloud nodes are identified as candidates for modification to low power operation based on certain operational factors such as CPU usage, memory usage, etc. Once identified, the O-cloud control system takes steps to change the C-state of one or more processors (or one or more cores of a single processor) in each of the identified O-cloud nodes, and in doing so, reduces the power consumption of the identified O-cloud nodes.

[0094] The above disclosure provides illustration and description, but is not intended to be exhaustive or to limit the implementations to the precise forms disclosed. Modifications and variations are possible in light of the above disclosure or may be acquired from practice of the implementations.

[0095] Some embodiments may be directed to systems, methods, and / or computer-readable media at any possible level of integrated technical detail. In addition, one or more of the above components may be implemented as instructions stored on a computer-readable medium and executable by at least one processor (and / or may include at least one processor). A computer-readable medium may include a computer-readable non-transitory storage medium (or medium) having computer-readable program instructions thereon for causing a processor to perform operations.

[0096] A computer-readable storage medium may be a tangible device that can retain and store instructions for use by an instruction execution device. A computer-readable storage medium may be, for example but not limited to, an electronic storage device, a magnetic storage device, an optical storage device, an electromagnetic storage device, a semiconductor storage device, or any suitable combination of the foregoing. A non-exhaustive list of more specific examples of computer-readable storage media includes the following: a portable computer disk, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), a static random access memory (SRAM), a portable compact disc read-only memory (CD-ROM), a digital versatile disk (DVD), a memory stick, a floppy disk, a mechanically encoded device (such as a punched card or a raised structure in a groove on which instructions are recorded) and any suitable combination of the foregoing. The computer-readable storage medium used herein cannot be interpreted as a transient signal itself, such as a radio wave or other freely propagating electromagnetic wave, an electromagnetic wave propagated by a waveguide or other transmission medium (e.g., a light pulse by a fiber optic cable), or an electrical signal transmitted by a wire.

[0097] The computer-readable program instructions described herein can be downloaded from a computer-readable storage medium to a corresponding computing / processing device, or downloaded to an external computer or external storage device via a network (e.g., the Internet, a local area network, a wide area network, and / or a wireless network). The network can include copper transmission cables, optical transmission fibers, wireless transmissions, routers, firewalls, switches, gateway computers, and / or edge servers. The network adapter card or network interface in each computing / processing device receives the computer-readable program instructions from the network and forwards the computer-readable program instructions to be stored in a computer-readable storage medium in the corresponding computing / processing device.

[0098] The computer readable program code / instruction for performing the operation can be an assembly instruction, an instruction set architecture (ISA) instruction, a machine instruction, a machine-related instruction, a microcode, a firmware instruction, a state setting data, a configuration data for an integrated circuit, or a source code or object code written in any combination of one or more programming languages, including object-oriented programming languages ​​such as Smalltalk, C++, etc., and a process programming language such as "C" programming language or a similar programming language. The computer readable program instruction can be executed completely on the user's computer, partially on the user's computer, as an independent software package, partially on the user's computer and partially on a remote computer, or completely on a remote computer or server. In the latter case, the remote computer can be connected to the user's computer through any type of network, including a local area network (LAN) or a wide area network (WAN), or connected to an external computer (for example, by using the Internet of an Internet service provider). In some embodiments, the electronic circuit system including, for example, a programmable logic circuit system, a field programmable gate array (FPGA) or a programmable logic array (PLA) can be personalized by utilizing the state information of the computer readable program instruction to perform various aspects or operations to execute the computer readable program instruction.

[0099] These computer-readable program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, or other programmable data processing device to produce a machine, so that the instructions executed by the processor of the computer or other programmable data processing device create a device for implementing the functions / actions specified in one or more boxes of the flowchart and / or block diagram. These computer-readable program instructions can also be stored in a computer-readable storage medium, which can instruct the computer, programmable data processing device, and / or other device to function in a specific manner, so that the computer-readable storage medium having the instructions stored therein includes an article of manufacture, which includes instructions for implementing various aspects of the functions / actions specified in one or more boxes of the flowchart and / or block diagram.

[0100] Computer-readable program instructions may also be loaded onto a computer, other programmable data processing apparatus, or other device to cause a series of operating steps to be performed on the computer, other programmable apparatus, or other device, thereby producing a computer-implemented process, so that the instructions executed on the computer, other programmable apparatus, or other device implement the functions / actions specified in one or more boxes of the flowchart and / or block diagram.

[0101] The flowcharts and block diagrams in the accompanying drawings illustrate the possible implementation architectures, functions, and operations of the systems, methods, and computer-readable media according to various embodiments. In this regard, each box in the flowchart or block diagram may represent a microservice, module, segment, or instruction portion, which includes one or more executable instructions for implementing a specified logical function. The method, computer system, and computer-readable medium may include additional boxes, fewer boxes, different boxes, or boxes arranged differently from those depicted in the figure. In some alternative implementations, the functions indicated in the box may not occur in the order indicated in the figure. For example, depending on the functions involved, the two boxes shown in succession may actually be executed simultaneously or substantially simultaneously, or the boxes may sometimes be executed in the opposite order. It will also be noted that each box in the block diagram and / or flowchart illustration and the combination of boxes in the block diagram and / or flowchart illustration can be implemented by a system based on dedicated hardware that performs a specified function or action or performs a combination of dedicated hardware and computer instructions.

[0102] It is apparent that the systems and / or methods described herein may be implemented in various forms of hardware, firmware, or a combination of hardware and software. The actual dedicated control hardware or software code used to implement these systems and / or methods is not a limitation of the implementation. Therefore, the operation and behavior of the systems and / or methods are described herein without reference to specific software code, and it should be understood that software and hardware can be designed to implement the systems and / or methods based on the description herein.

Claims

1. A method of managing power consumption of one or more Open Cloud (O-Cloud) nodes within an O-Cloud infrastructure of a telecommunications network, the method being performed by at least one processor and comprising: obtaining, by a federated O-Cloud orchestration and management module FOCOM within a service management orchestration SMO framework, a request for modifying a C-state of a processor of an O-Cloud node within said O-Cloud infrastructure of said telecommunication network; The FOCOM sends a request for modifying the C-state of the processor of the O-cloud node to an infrastructure management service module IMS via an O2 interface; Receiving, by the IMS via the O2 interface, the request for modifying the C-state of the processor of the O-cloud node; controlling, by the IMS, implementation of the request to modify the C-state of the processor of the O-cloud node; as well as The IMS sends a confirmation of the C-state modification of the processor of the O-cloud node to the FOCOM via the O2 interface.

2. The method according to claim 1, further comprising: Monitoring, by a non-real-time radio intelligent controller NRT RIC, the O-cloud data received through the O2 interface; analyzing the O-Cloud data and identifying the O-Cloud nodes within the O-Cloud infrastructure that require modification based on the analysis; Send the O-cloud node C state modification request to the FOCOM.

3. The method according to claim 1, further comprising: Monitoring, by a user, O-Cloud data received via the O2 interface; analyzing the O-Cloud data and determining the O-Cloud nodes within the O-Cloud infrastructure that require changes based on the analysis; Send the O-cloud node C-state modification request to the FOCOM.

4. The method according to claim 1, further comprising: A confirmation of the C-state modification of the process of the O-cloud node is sent by the FOCOM to at least one of a user and a non-real-time wireless intelligent controller NRT RIC.

5. The method of claim 2, wherein the O-cloud data received through the O2 interface comprises: At least one of processor utilization and memory utilization.

6. The method according to claim 2, further comprising: A confirmation of the C-state modification of the process of the O-cloud node is sent by the FOCOM to at least one of a user and the NRT RIC.

7. The method of claim 6, wherein the O-cloud data received through the O2 interface comprises: At least one of processor utilization and memory utilization.

8. A system for managing power consumption of one or more Open Cloud (O-Cloud) nodes within an O-Cloud infrastructure of a telecommunications network, the system comprising: at least one memory configured to store computer program code; as well as At least one processor is configured to access the at least one memory and operate according to the instructions of the computer program code, wherein the computer program code comprises: O-Cloud infrastructure implementation code configured to cause the at least one processor to implement: (i) a joint O-Cloud orchestration and management module FOCOM within a service management orchestration SMO framework, (ii) an infrastructure management service module IMS, and (iii) an O2 interface between the SMO and the IMS; acquiring code configured to cause the at least one processor to acquire, through the FOCOM, a request for modifying a C-state of a processor of an O-cloud node within the O-cloud infrastructure of the telecommunications network; sending code configured to cause the at least one processor to send a request for modifying the C-state of the processor of the O-cloud node from the FOCOM to the IMS via the O2 interface; control code configured to cause the at least one processor to implement, through the IMS, the request for modifying the C-state of the processor of the O-cloud node; and The sending code is configured to cause the at least one processor to send a confirmation of the C-state modification of the processor of the O-cloud node from the IMS to the FOCOM via the O2 interface.

9. The system of claim 8, wherein the O-Cloud infrastructure implementation code further comprises: The computer program code is configured to cause the at least one processor to implement a non-real time radio intelligent controller NRT RIC, and wherein the computer program code further comprises: monitoring code configured to cause the at least one processor to receive O-cloud data via the O2 interface through the NRT RIC; analysis code configured to cause the at least one processor to analyze the O-cloud data via the NRT RIC and identify the O-cloud nodes within the O-cloud infrastructure to be modified based on the analysis; and The sending code is configured to enable the at least one processor to send the O-cloud node C-state modification request to the FOCOM through the NRT RIC.

10. The system according to claim 8, further comprising a human-machine interface, the human-machine interface being configured to allow a user to receive and analyze O-cloud data via the O2 interface, and also to allow the user to send the O-cloud node C-state modification request to the FOCOM.

11. The system of claim 8, wherein the O-Cloud infrastructure implementation code further comprises: The computer program code further comprises a sending code configured to cause the at least one processor to send a confirmation of the C-state modification of the process of the O-cloud node to at least one of a user and the NRT RIC via the FOCOM.

12. The system of claim 9, wherein the O-Cloud data received through the O2 interface comprises: At least one of processor utilization and memory utilization.

13. The system of claim 10, wherein the O-Cloud infrastructure implementation code further comprises: The computer program code further comprises a sending code configured to cause the at least one processor to send, by the FOCOM, a confirmation of the C-state modification of the process of the O-cloud node to at least one of the user and the NRT RIC.

14. The method of claim 13, wherein the O-Cloud data received through the O2 interface comprises: At least one of processor utilization and memory utilization.

15. A non-transitory computer readable medium having instructions stored therein, which, when executed by a processor, cause the processor to perform a method of managing power consumption of one or more Open Cloud (O-Cloud) nodes within an O-Cloud infrastructure of a telecommunications network, the method comprising: obtaining, by a federated O-Cloud orchestration and management module FOCOM within a service management orchestration SMO framework, a request for modifying a C-state of a processor of an O-Cloud node within said O-Cloud infrastructure of said telecommunication network; The FOCOM sends a request for modifying the C-state of the processor of the O-cloud node to an infrastructure management service module IMS via an O2 interface; Receiving, by the IMS via the O2 interface, the request for modifying the C-state of the processor of the O-cloud node; controlling, by the IMS, implementation of the request to modify the C-state of the processor of the O-cloud node; as well as The IMS sends a confirmation of the C-state modification of the processor of the O-cloud node to the FOCOM via the O2 interface.

16. The non-transitory computer readable medium of claim 15, wherein the method further comprises: Monitoring, by a non-real-time radio intelligent controller NRT RIC, the O-cloud data received through the O2 interface; analyzing the O-Cloud data and identifying the O-Cloud nodes within the O-Cloud infrastructure that require modification based on the analysis; Send the O-cloud node C-state modification request to the FOCOM.

17. The non-transitory computer readable medium of claim 15, wherein the method further comprises: Monitoring, by a user, O-Cloud data received via the O2 interface; analyzing the O-Cloud data and identifying the O-Cloud nodes within the O-Cloud infrastructure that require changes based on the analysis; Send the O-cloud node C-state modification request to the FOCOM.

18. The non-transitory computer readable medium of claim 15, wherein the method further comprises: A confirmation of the C-state modification of the process of the O-cloud node is sent by the FOCOM to at least one of a user and a non-real-time wireless intelligent controller NRT RIC.

19. The non-transitory computer readable medium of claim 16, wherein the O-Cloud data received via the O2 interface comprises: At least one of processor utilization and memory utilization.

20. The non-transitory computer readable medium of claim 17, wherein the O-Cloud data received through the O2 interface comprises: At least one of processor utilization and memory utilization.

Images