Apparatus and method for implementing C-state changes for O-Cloud nodes

Abstract

A system and method are provided for modifying the C-state of processors in an Open Cloud (O-Cloud) node in an O-Cloud infrastructure of a telecommunications network to reduce power consumption associated with processors in the O-Cloud infrastructure. A method for managing power consumption of one or more open cloud (O-Cloud) nodes in an O-Cloud infrastructure of a telecommunications network, the method being executed by at least one processor and including: obtaining, by a federated O-Cloud orchestration and management module (FOCOM) in a service management orchestration (SMO) framework, a request to modify a C-state of a processor of an O-Cloud node in the O-Cloud infrastructure of the telecommunications network; sending, by the FOCOM, the request to modify the C-state of the processor of the O-Cloud node to an infrastructure management services module (IMS) via an O2 interface; receiving, by the IMS, the request to modify the C-state of the processor of the O-Cloud node via the O2 interface; controlling, by the IMS, implementation of the request to modify 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.

Description

[Technical Field]

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS This application claims priority from Singapore Provisional Patent Application No. 10202250729D, filed with the Singapore Patent Office on August 12, 2022, the disclosure of which is incorporated herein by reference in its entirety.

[0002] An apparatus and method according to an exemplary embodiment of the present disclosure relates to optimizing process power consumption in distributed network devices. [Background technology]

[0003] In the prior art, the radio access network (RAN) is a critical component in telecommunications systems 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.

[0004] Open RAN (O-RAN) technology has emerged to allow multiple vendors to provide hardware and / or software for telecommunications systems. To this end, O-RAN decomposes RAN functions into a centralized unit (CU), a distributed unit (DU), and a radio unit (RU). The 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. The DU is a logical node for hosting the Radio Link Control (RLC), Media Access Control (MAC), and Physical (PHY) sublayers of the RAN. The RU is a physical node that converts radio signals from the antenna into digital signals that can be transmitted to the DU via the Fronthaul. These entities can be developed by different vendors because they have open protocols and interfaces between them.

[0005] FIG. 1 is a diagram of a related art O-RAN architecture, FIG. 2 is a functional diagram of a related art Service Management and Orchestration (SMO) framework with a non-real-time (NRT) RAN Intelligent Controller (RIC) architecture, and FIG. 3 is a service diagram of the related art SMO framework with an NRT RIC. Referring to FIGS. 1 to 3, RAN functions in the O-RAN architecture are controlled and optimized by the RIC. The RIC is a software-defined component that implements modular applications to facilitate multi-vendor operability required in an O-RAN system and to automate and optimize RAN operations. RICs are divided into two types: NRT RICs and near-real-time RICs (nRT RICs).

[0006] The NRT RIC is the control point for non-real-time control loops and operates on timescales greater than one second within the SMO framework. Its functions are implemented through modular applications called rApps (rApp1,..., rAppN in Figures 1-3) and include providing policy-based guidance and enrichment over the A1 interface, which is the interface enabling communication between the NRT RIC and the nRT RIC; performing data analytics; AI / ML (artificial intelligence / machine learning) training and inference for RAN optimization; and / or recommending configuration management actions over the O1 interface, which is the interface connecting the SMO to RAN management elements (e.g., nRT RIC, O-RAN Centralized Unit (O-CU), O-RAN Distributed Unit (O-DU), etc.).

[0007] The nRT RIC operates on a timescale between 10 milliseconds and 1 second and connects to the O-DU, the O-CU (separated into the O-CU control plane (O-CU-CP) and the O-CU user plane (O-CU-UP)), and the 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)) via a near-real-time control loop. The nRT RIC monitors, suspends / stops, overrides, and controls the E2 nodes (O-CU, O-DU, O-eNB) through policies. For example, the nRT sets policy parameters for activated functions of the E2 nodes. Additionally, the nRT RIC hosts xApps to implement functions such as quality of service (QoS) optimization, mobility optimization, slicing optimization, interference mitigation, load balancing, and security. The two types of RICs work together to optimize O-RAN. For example, the NRT-RIC provides policies, data, and artificial intelligence (AI) / machine learning (ML) models over the A1 interface that are implemented and used by the nRT RIC to optimize the RAN, and the nRT returns policy feedback (i.e., how the policies set by the NRT-RIC are performing).

[0008] The SMO framework, in which the NRT RIC is located, manages and orchestrates RAN elements. Specifically, the SMO manages and orchestrates what is referred to as 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 systems and runtime environments), and the SMO itself. In other words, the SMO manages the O-Cloud from within. The O2 interface is the interface between the SMO and the O-Cloud in which it resides. Through the O2 interface, the SMO provides infrastructure management services (IMS) and deployment management services (DMS).

[0009] Each O-Cloud node typically includes one or more processors, or CPUs, each of which consumes a given amount of power. One known method of CPU power management is modifying the processor's C-states and P-states. More specifically, there are generally two ways to manage the power consumed by a CPU: (1) completely powering down a particular subsystem of the CPU (such as one or more cores of memory or a particular cache), thereby eliminating the power consumed by that subsystem (i.e., removing the voltage supply to the associated subsystem of the CPU, thereby reducing or turning off certain functions); or (2) reducing power consumption by reducing the voltage and / or frequency of the CPU (or one or more of its subsystems). Of these two options, the former is achieved by modifying the processor's "C-state" (also known as an "idle state" or "idle power saving state"), and the latter is achieved by modifying the processor's "P-state" (also known as an "execution power saving state").

[0010] Typically, C-states and P-states are numbered starting from zero (e.g., C0, C1... and P0, P1...). By common convention, the higher the number, the more power saved. C0 means no power savings, since all power is on. Similarly, P0 means maximum performance, and therefore the maximum frequency, voltage, and power used. Different CPUs have different C-states and P-states.

[0011] With respect to C-states, each processor typically has its own distinct set of C-states. As an example, the basic C-states defined under the Advanced Configuration and Power Interface (ACPI) power management standard include: C0: Active, CPU / Core is executing instructions. P-states are relevant here, the CPU / Core may be operating at its maximum performance (thus P0) or at a lower performance / power (thus something other than P0). C1: Stopped, nothing is running, but can momentarily return to C0. Since it is not running (but stopped), the P-state is not related to any Cx other than C1 or C0. C2: Clock stopped, similar to C1 but takes longer to return to C0. C3: Sleep. It can go back to C0, but it takes a much longer time.

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

[0013] P-states are only relevant when the CPU core is in the C0 state, because power must be supplied to the CPU to execute code. P-states allow for changes in the voltage and frequency (in other words, the operating point) of the CPU core to reduce power consumption by 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 generally the maximum performance state, which is P0. Similar to C-states, different CPUs have different available P-states.

[0014] Exemplary embodiments of the present disclosure provide methods and systems in which power consumption of an O-Cloud node is managed by adjusting the C-states of one or more processors embedded in the node.

[0015] In related technology, CPUs included in O-Cloud nodes may operate at full capacity and therefore full power even when the amount of traffic occurring on the node does not warrant such operating capacity nor the associated power consumption, resulting in unnecessary and inefficient power consumption. Summary of the Invention

[0016] According to embodiments, systems and methods are provided for modifying the C-state of processors in Open Cloud (O-Cloud) nodes in an O-Cloud infrastructure of a telecommunications network to reduce power consumption associated with the processors in the O-Cloud infrastructure.

[0017] According to an embodiment, there is provided a method for managing power consumption of one or more Open Cloud (O-Cloud) nodes in an O-Cloud infrastructure of a telecommunications network, the method being executed by at least one processor, the method including: obtaining, by a federated O-Cloud orchestration and management module (FOCOM) in a service management orchestration (SMO) framework, a request to modify a C-state of a processor of an O-Cloud node in the O-Cloud infrastructure of the telecommunications network; sending, by FOCOM, the request to modify the C-state of the processor of the O-Cloud node to an Infrastructure Management Services Module (IMS) via an O2 interface; receiving, by the IMS, the request to modify the C-state of the processor of the O-Cloud node via the O2 interface; controlling, by the IMS, implementation (execution) of the request to modify 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.

[0018] The method may further include 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 based on the analysis, identifying an O-Cloud node to be modified within the O-Cloud infrastructure, and sending an O-Cloud node C-state modification request to the FOCOM.

[0019] The method may further include monitoring, by the user, O-Cloud data received via the O2 interface, analyzing the O-Cloud data and, based on the analysis, identifying O-Cloud nodes to be modified within the O-Cloud infrastructure, and sending an O-Cloud node C-state modification request to FOCOM.

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

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

[0022] According to one embodiment, there is provided a system for managing power consumption of one or more Open Cloud (O-Cloud) nodes in an O-Cloud infrastructure of a telecommunications network, the system comprising: 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 instructed by the computer program code, the computer program code causing the at least one processor to implement: (i) a Federated 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. an O-Cloud infrastructure implementation code configured to: acquire a request, by FOCOM, to modify a C-state of a processor of an O-Cloud node in an O-Cloud infrastructure of the telecommunications network; an acquiring code configured to cause the at least one processor to acquire, by FOCOM, a request to modify a C-state of a processor of an O-Cloud node in an O-Cloud infrastructure of the telecommunications network; a transmitting code configured to cause the at least one processor to send, by the IMS from FOCOM, the request to modify the C-state of the processor of the O-Cloud node; a control code configured to cause the at least one processor to implement, by the IMS, the request to modify the C-state of the processor of the O-Cloud node; and a transmitting code configured to cause the at least one processor to send, by the IMS, a confirmation of the C-state modification of the processor of the O-Cloud node from the IMS to FOCOM via the O2 interface.

[0023] The O-Cloud infrastructure implementation code may further include code configured to cause the at least one processor to implement a Non-Real-Time Radio Intelligent Controller (NRT RIC), and the computer program code may also include monitoring code configured to cause the at least one processor to receive O-Cloud data, by the NRT RIC, via an O2 interface; analysis code configured to cause the at least one processor to analyze the O-Cloud data, by the NRT RIC, and to identify O-Cloud nodes to be modified within the O-Cloud infrastructure based on the analysis; and transmission code configured to cause the at least one processor to send, by the NRT RIC, an O-Cloud node C-state modification request to the FOCOM.

[0024] The system may further include a human-machine interface configured to enable a user to receive and analyze O-Cloud data via an O2 interface and further enable the user to send O-Cloud node C-state modification requests to the FOCOM.

[0025] The O-Cloud infrastructure implementation code may further include code configured to cause the at least one processor to implement a Non-Real-Time Radio Intelligent Controller (NRT RIC), and the computer program code further includes transmitting code configured to cause the at least one processor to transmit, by the FOCOM, to at least one of the user and the NRT RIC, a confirmation of the C-state modification of the process of the O-Cloud node.

[0026] According to one embodiment, a non-transitory computer-readable medium is provided having instructions stored thereon that, when executed by a processor, cause the processor to perform a method for managing power consumption of one or more open cloud (O-Cloud) nodes in an O-Cloud infrastructure of a telecommunications network, the method including obtaining, by a Federated O-Cloud Orchestration and Management Module (FOCOM) in a Service Management Orchestration (SMO) framework, a request to modify a C-state of a processor of an O-Cloud node in the O-Cloud infrastructure of the telecommunications network; sending, by the FOCOM, the request to modify the C-state of the processor of the O-Cloud node to an Infrastructure Management Services Module (IMS) via an O2 interface; receiving, by the IMS, the request to modify the C-state of the processor of the O-Cloud node via the O2 interface; controlling, by the IMS, implementation of the request to modify 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.

[0027] The non-transitory computer-readable medium has stored thereon instructions that, when executed by a processor, may cause the processor to monitor O-Cloud data received via an O2 interface by a non-real-time radio intelligent controller (NRT RIC), analyze the O-Cloud data, and based on the analysis, identify an O-Cloud node in the O-Cloud infrastructure to be modified, and send an O-Cloud node C-state modification request to FOCOM.

[0028] The non-transitory computer-readable medium has stored thereon instructions that, when executed by a processor, may cause the processor to perform the following additional operations: monitoring O-Cloud data received by a user via an O2 interface, analyzing the O-Cloud data and, based on the analysis, identifying O-Cloud nodes to be modified in the O-Cloud infrastructure, and sending an O-Cloud node C-state modification request to FOCOM.

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

[0030] Additional aspects will be set forth in part in the description that follows, and in part will be apparent from the description, or may be learned by practice of presented embodiments of the present disclosure. [Brief explanation of the drawings]

[0031] Features, aspects, and advantages of certain exemplary embodiments of the present disclosure are described below with reference to the accompanying drawings, in which like reference numerals refer to like elements.

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

[0033] [Figure 2] FIG. 1 is a functional diagram of a related art service management and orchestration (SMO) framework with a non-real-time (NRT) RAN intelligent controller (RIC) architecture.

[0034] [Figure 3]FIG. 1 is a diagram of a related art SMO framework with an NRT RIC in a service view.

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

[0036] [Figure 5] FIG. 1 is a sequence diagram of a method for modifying the C-state of one or more O-Cloud node processors, according to one embodiment.

[0037] [Figure 6] 1 is a flowchart of a method for power management in an O-RAN, according to one embodiment.

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

[0039] [Figure 8] FIG. 2 is a diagram of exemplary components of a device according to one embodiment. DETAILED DESCRIPTION OF THE INVENTION

[0040] The following detailed description of exemplary embodiments refers to the accompanying drawings. The foregoing disclosure provides illustration and description, but is not intended to be exhaustive or to limit implementations to the precise form disclosed. Modifications and variations are possible in light of the above disclosure or may be acquired from practice of implementation. Furthermore, one or more features or components of one embodiment may be incorporated into or combined with another embodiment (or one or more features of another embodiment). Additionally, in the flowcharts and descriptions of 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 occur (at least partially) concurrently, and the order of one or more operations may be rearranged.

[0041] It will be apparent that the systems and / or methods described herein may be implemented in different forms of hardware, firmware, or a combination of hardware and software. The actual specialized control hardware or software code used to implement these systems and / or methods is not limiting of the implementation. Thus, the operation and behavior of the systems and / or methods have been described herein without reference to specific software code. It should be understood that software and hardware may be designed to implement the systems and / or methods based on the description herein.

[0042] Although particular combinations of features are recited in the claims and / or disclosed herein, these combinations do not limit the disclosure of possible implementations. Indeed, many of these features can be combined in ways not specifically recited in the claims and / or disclosed herein. Although each dependent claim listed below may depend directly on only one claim, the disclosure of possible implementations includes each dependent claim in combination with all other claims in the claims.

[0043] As used herein, no element, act, or instruction should be construed as critical or essential unless explicitly described as such. Also, as used herein, the articles "a" and "an" are intended to include one or more items and may be used synonymously with "one or more." Where only one item is intended, the term "one" or similar language is used. Also, as used herein, the terms "has," "have," "having," "include," "including," and the like are intended to be open-ended terms. Furthermore, the phrase "based on" is intended to mean "based at least in part on" unless otherwise specified. Furthermore, phrases 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.

[0044] Exemplary embodiments provide a system (as well as 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) by obtaining parameters indicative of traffic levels of O-RAN nodes. The parameters indicative of traffic levels may include central processing unit usage of the O-Cloud node, memory usage of the O-Cloud node, disk throughput of the O-Cloud node, etc., and the system may obtain the parameters from an O-Cloud server. The parameters may be collected and analyzed from O2 telemetry by an NRT RIC.

[0045] Based on the obtained parameters, the system may determine whether at least one of the collected parameters of the O-Cloud node satisfies a predetermined modification condition. The predetermined modification condition may include a condition based on CPU usage of the O-Cloud node being less than a CPU usage percentage threshold, memory usage of the O-Cloud node being less than a memory usage percentage threshold, disk throughput of the O-Cloud node being less than a disk throughput usage percentage threshold, and / or a combination of such conditions. Based on determining that at least one of the collected parameters satisfies the predetermined modification condition, the system may change the C-state of a processor in the O-Cloud node.

[0046] The system may include a Federated O-Cloud Orchestration and Management (FOCOM) controller of a Service Management and Orchestration (SMO) framework, where the system may determine that at least one parameter meets a modification condition based on a predefined modification policy configured for the FOCOM controller. Alternatively, or additionally, the system may include a Non-Real-Time (NRT) RAN Intelligent Controller (RIC) for the SMO, where the NRT RIC may be configured to perform the operations described above.

[0047] Before changing the C-state of the O-Cloud node processor based on determining that at least one parameter satisfies a predetermined modification condition, the system may notify the O-Cloud node that the O-Cloud node has been determined to be subject to the processor C-state change. In such an example, the C-state of the O-Cloud node processor may be changed after a predetermined grace period beginning around the time the O-Cloud node is notified. Alternatively, the system may perform a non-graceful modification of the C-state of the O-Cloud node processor and not provide notification that the C-state of the O-Cloud node processor has been determined to be modified. Additionally, the system may terminate at least one application running on the O-Cloud node before the O-Cloud node is deactivated.

[0048] Therefore, by monitoring the O-RAN as disclosed herein, power consumption can be reduced by changing C-state O-Cloud node processors to limited or no use.

[0049] Figure 1 is a diagram of an O-RAN architecture 100 according to one embodiment. The O-RAN architecture 100 may include an SMO framework 102 including 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 Services (IMS) module 120 and a Deployment Management Services (DMS) module 122. As shown in Figure 1, the FOCOM controller 106 may be configured to obtain parameters indicative of traffic performance of O-Cloud nodes from the O-Cloud Server 118. That is, the NRT RIC 104 may push (force, apply) a predetermined shutdown policy to the FOCOM controller 106.

[0050] 4 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 C-state modification actions. Additionally, the O-RAN architecture 400 includes a fronthaul (FH) M-plane 450 including 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 may obtain parameters indicating processor utilization of the O-Cloud node directly from the O-Cloud server 418 and may be configured to determine a modification of the O-Cloud node processor C-state based on the parameters. The NRT RIC 404 may be configured to determine a modification of the O-Cloud node processor C-state without implementing a policy, such as a policy implemented in the FOCOM controller 406. The NRT RIC 404 may be configured to push a C-state modification operation to the IMS module 420.

[0051] 5 shows a sequence diagram of a method for modifying the C-state of one or more O-Cloud node processors according to one embodiment. The key components of the O-RAN architecture of FIG. 5 are similar to those according to FIG. 1.

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

[0053] In FIG. 5, the method for implementing C-state modification of one or more O-Cloud node processors can be initiated by either a manual request by a user to the SMO or by one or more rApps of the NRT-RIC within the SMO.

[0054] 5, Initiation is shown as the O-Cloud Node Analysis Process and indicates the beginning of the O-Cloud node reconfiguration procedure. Initiation by the O-Cloud Node Analysis Process is based on either a user or an NRT-RIC monitoring O-Cloud data received over the O2 interface, analyzing the O-Cloud data, and determining, based on the analysis, at least one O-Cloud node processor to be reconfigured within the O-Cloud infrastructure.

[0055] To this end, when the NRT-RIC in the SMO initiates the method, one or more rApps in the NRT-RIC execute the O-Cloud node analysis process as described above.

[0056] In an example embodiment, the analysis may be based on a comparison between O2 interface telemetric data regarding utilization of 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).

[0057] According to the O-Cloud reconfiguration procedure, in operation 501, in one exemplary embodiment, an 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, among multiple O-Cloud nodes, one or more O-Cloud nodes that satisfy certain predefined criteria for processor C-state modifications, and further identifies appropriate C-state modifications to implement for each identified C-Cloud node. In another exemplary embodiment, operation 501 is performed by a cloud maintainer (e.g., a user).

[0058] In operation 502, in one exemplary embodiment, the SMO (i.e., FOCOM) receives 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 another exemplary embodiment, in operation 502, the FOCOM receives a request from an NRT-RIC to reconfigure at least one O-Cloud node based on the results of the O-Cloud analysis process as described above.

[0059] In operation 503, FOCOM sends a reconfiguration request to the IMS via the O2 interface in response to 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 apply to each such O-Cloud node. Operation 503 may be repeated for each O-Cloud node identified in operation 501.

[0060] 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 O-Cloud node processor C-state change is effected from the O-Cloud node BIOS.

[0061] In operation 505, the IMS notifies the SMO that the O-Cloud node C-state modification is complete for each O-Cloud node. In an exemplary embodiment, the IMS sends a reconfiguration confirmation to the FOCOM over the O2 interface.

[0062] Also, referring to operation 505, in an exemplary embodiment, if the NRT-RIC is subscribed to IMS notifications (is configured to receive notifications from the IMS), the IMS notifies the NRT-RIC about the status of the O-cloud node (i.e., the status of the reconfigured O-cloud node(s)) via the O2 interface. In operation 506, the SMO notifies the cloud maintainer and the NRT RIC that the O-cloud node C-state modification is complete. In another exemplary embodiment, the IMS may notify the FOCOM and the NRT-RIC about the completion of the reconfiguration via the O2 interface.

[0063] Referring to FIG. 5, the method for implementing processor C-state modifications of one or more O-Cloud nodes ends when the C-states of all O-Cloud nodes identified in operation 501 are complete.

[0064] 6 is a flowchart of a method for power management in an 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 place in a low power mode based on an analysis of O2 telemetry such as CPU utilization, memory utilization, etc. In operation 602, either the cloud maintainer or the rApp via an NRT RIC triggers a SOM (e.g., FOCOM) to place the processors of the O-Cloud nodes identified in operation 601 into a desired C-state. In operation 603, FOCOM uses an O2 IMS service to request that the IMS change the C-state of the processors in the O-Cloud nodes identified in operation 601. Operation 603 may 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 processors in the identified O-Cloud nodes 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 complete. 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 complete.

[0065] 7 is a diagram of an example environment 700 in which the systems and / or methods described herein may be implemented. As shown in FIG. 7, environment 700 may include a user device 710, a platform 720, and a network 730. The devices of environment 700 may be interconnected via wired connections, wireless connections, or a combination of wired and wireless connections. In an embodiment, any of the functions and operations described above with reference to FIG. 7 may be performed by any combination of the elements shown in FIG. 7.

[0066] User device 710 includes one or more devices capable of receiving, generating, storing, processing, and / or providing information related to 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 smartphone, a wireless phone, etc.), a wearable device (e.g., smart glasses or a smart watch), or a similar device. In some implementations, user device 710 may receive information from and / or transmit information to platform 720.

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

[0068] In some implementations, as shown, platform 720 may be hosted in a cloud computing environment 722. Notably, although the implementations described herein describe platform 720 as being hosted within cloud computing environment 722, in some implementations platform 720 may not be cloud-based (i.e., may be implemented outside of a cloud computing environment) or may be partially cloud-based.

[0069] Cloud computing environment 722 includes an environment that hosts platform 720. Cloud computing environment 722 can provide services such as computation, software, data access, storage, etc. that do not require end-user (e.g., user device 710) knowledge of the physical location and configuration of the system(s) and / or device(s) that host platform 720. As shown, cloud computing environment 722 can include a group of computing resources 724 (collectively referred to as “computing resources 724” and individually referred to as “computing resource 724”).

[0070] Computing resources 724 include one or more personal computers, clusters of computing devices, workstation computers, server devices, or other types of computing and / or communication devices. In some implementations, computing resources 724 may host platform 720. Cloud resources may include compute instances running within computing resources 724, storage devices provided within computing resources 724, data transfer devices provided by computing resources 724, etc. In some implementations, computing resources 724 may communicate with other computing resources 724 via wired connections, wireless connections, or a combination of wired and wireless connections.

[0071] As further shown in FIG. 7, the computing resources 724 include a group 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, and one or more hypervisors (HYP) 724-4.

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

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

[0074] Virtualized storage 724-3 includes one or more storage systems and / or one or more devices that use virtualization techniques within the storage systems or devices of computing resources 724. In some implementations, within the context of a storage system, types of virtualization can 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 can be accessed regardless of the physical storage or heterogeneous structure. This separation allows storage system administrators flexibility in how they manage storage for end users. File virtualization may eliminate the dependency between data accessed at the file level and where the file is physically stored. This may optimize the performance of storage usage, server consolidation, and / or non-disruptive file migrations.

[0075] The hypervisor 724-4 may provide hardware virtualization technology that allows multiple operating systems (e.g., "guest operating systems") to run simultaneously on a host computer, such as the computing resource 724. The 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 different operating systems may share virtualized hardware resources.

[0076] Network 730 may include one or more wired and / or wireless networks. For example, 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, an optical fiber-based network, etc., and / or a combination of these or other types of networks.

[0077] The number and arrangement of devices and networks shown in Figure 7 are provided as an example. In practice, there may be additional devices and / or networks, fewer devices and / or networks, different devices and / or networks, or devices and / or networks arranged differently than those shown in Figure 7. Furthermore, two or more devices shown in Figure 7 may be implemented within a single device, or a single device shown in Figure 7 may be implemented as multiple distributed devices. Additionally or alternatively, a set of devices (e.g., one or more devices) of environment 700 may perform one or more functions described as performed by another set of devices of environment 700.

[0078] 8 is a diagram of example components of a device 800. The device 800 may correspond to a user device 710 and / or a platform 720. As shown in FIG. 8, the 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.

[0079] Bus 810 includes components that enable communication between components of device 800. Processor 820 may be implemented in hardware, firmware, or a combination of hardware and software. Processor 820 may be a central processing unit (CPU), graphics processing unit (GPU), accelerated processing unit (APU), microprocessor, microcontroller, digital signal processor (DSP), field programmable gate array (FPGA), application-specific integrated circuit (ASIC), or another type of processing component. In some implementations, processor 820 includes one or more processors that can be programmed to perform functions. In some implementations, processor 820 is a single processor with multiple cores. Memory 830 includes random access memory (RAM), 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 processor 820.

[0080] Storage component 840 stores information and / or software related to the operation and use of device 800. For example, storage component 840 may include a hard disk (e.g., magnetic, optical, magneto-optical, and / or solid-state disk), compact disk, floppy disk, cartridge, magnetic, and / or other type of non-transitory computer-readable medium, along with a corresponding drive. Input component 850 includes components that enable device 800 to receive information via user input (e.g., a touchscreen display, a keyboard, a keypad, a mouse, buttons, switches, and / or a microphone), etc. Additionally or alternatively, input component 850 may include sensors for sensing information (e.g., a global positioning system (GPS) component, an accelerometer, a gyroscope, and / or an actuator). Output component 860 includes components that provide output information from device 800 (e.g., a display, a speaker, and / or one or more light-emitting diodes (LEDs)).

[0081] The communication interface 870 includes transceiver-like components (e.g., a transceiver and / or a separate receiver and transmitter) that enable the device 800 to communicate with other devices via a wired connection, a wireless connection, or a combination of wired and wireless connections, etc. The communication interface 870 may enable 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 interface, a Wi-Fi interface, a cellular network interface, etc.

[0082] Device 800 may perform one or more processes described herein. Device 800 can perform these processes in response to processor 820 executing software instructions stored by a non-transitory computer-readable medium, such as memory 830 and / or storage component 840. A computer-readable medium is defined herein as a non-transitory memory device. A memory device includes memory space within a single physical storage device or memory space distributed across multiple physical storage devices.

[0083] The software instructions may be loaded into memory 830 and / or storage component 840 from another computer-readable medium or from another device via communications 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.

[0084] Additionally or alternatively, hardware 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.

[0085] The number and arrangement of components shown in Figure 8 are provided as an example. In practice, device 800 may include more, fewer, different, or differently arranged components than those shown in Figure 8. Additionally or alternatively, a 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.

[0086] In embodiments, any one of the operations or processes of Figures 5-6 may be implemented by or using any one of the elements shown in Figures 1-4 and 7-8. It will be understood that other embodiments are not limited thereto and may be implemented in a variety of different architectures (e.g., a bare metal architecture, any cloud-based architecture or deployment architecture such as Kubernetes, Docker, OpenStack, etc.).

[0087] According to an exemplary embodiment, one or more O-Cloud nodes are identified as candidates for modification to lower power operation based on certain operational factors such as CPU usage, memory usage, etc. Once identified, the O-Cloud control system performs steps to change the C-state of one or more processors (or one or more cores of a single processor) within each identified O-Cloud node, thereby reducing the power consumption of the modified O-Cloud node.

[0088] The foregoing disclosure provides illustration and description, but is not intended to be exhaustive or to limit 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.

[0089] Some embodiments may relate to systems, methods, and / or computer-readable media at any possible level of technical detail. Furthermore, one or more of the above components described above 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). The computer-readable medium may include a computer-readable non-transitory storage medium (or media) having computer-readable program instructions for causing the processor to perform operations.

[0090] A computer-readable storage medium may be a tangible device that can hold and store instructions for use by an instruction execution device. The computer-readable storage medium may be, for example, but is 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 portable computer diskettes, hard disks, random access memories (RAMs), read-only memories (ROMs), erasable programmable read-only memories (EPROMs or flash memories), static random access memories (SRAMs), portable compact disk read-only memories (CDROMs), digital versatile disks (DVDs), memory sticks, floppy disks, mechanically encoded devices such as ridge structures in grooves or punch cards with instructions recorded thereon, and any suitable combination of the above. As used herein, computer-readable storage media should not be construed as being transitory signals per se, such as radio waves or other freely propagating electromagnetic waves, electromagnetic waves propagating through a waveguide or other transmission medium (e.g., light pulses passing through a fiber optic cable), or electrical signals transmitted through wires.

[0091] The computer-readable program instructions described herein can be downloaded from a computer-readable storage medium to each computing / processing device or to an external computer or external storage device via a network, such as the Internet, a local area network, a wide area network, and / or a wireless network. The network can include copper transmission cables, optical fiber transmissions, wireless transmissions, routers, firewalls, switches, gateway computers, and / or edge servers. A 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 for storage in a computer-readable storage medium in the respective computing / processing device.

[0092] The computer-readable program code / instructions for carrying out operations can be either source code or object-oriented programming languages ​​written in any combination of one or more programming languages, including assembler instructions, instruction set architecture (ISA) instructions, machine instructions, machine-dependent instructions, microcode, firmware instructions, state setting data, configuration data for integrated circuits, or object code such as Smalltalk, C++, and procedural programming languages ​​such as the "C" programming language or similar programming languages. The computer-readable program instructions may execute entirely on the user's computer, partially on the user's computer, as a stand-alone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In the latter scenario, the remote computer may be connected to the user's computer via any type of network, including a local area network (LAN) or a wide area network (WAN), or the connection may be to an external computer (e.g., via the Internet using an Internet Service Provider). In some embodiments, an electronic circuit including, for example, a programmable logic circuit, a field programmable gate array (FPGA), or a programmable logic array (PLA) may execute computer-readable program instructions by utilizing state information of the computer-readable program instructions to personalize the electronic circuit to perform an aspect or operation.

[0093] These computer-readable program instructions may be provided to a processor of a general-purpose computer, special-purpose computer, or other programmable data processing apparatus, such that the instructions, which execute on the processor of the computer or other programmable data processing apparatus, create means for implementing the functions / acts specified in one or more blocks of the flowcharts and / or block diagrams, to produce a machine. These computer-readable program instructions may also be stored on a computer-readable storage medium that can direct a computer, programmable data processing apparatus, and / or other device to function in a particular manner, such that a computer-readable storage medium having instructions stored therein includes an article of manufacture containing instructions that implement aspects of the functions / acts specified in one or more blocks of the flowcharts and / or block diagrams.

[0094] The computer-readable program instructions may also be loaded into a computer, other programmable data processing apparatus, or other device and cause the computer, other programmable apparatus, or other device to perform a series of operational steps to create a computer-implemented process, such that the instructions, when executed on the computer, other programmable apparatus, or other device, implement the functions / acts specified in one or more blocks of the flowcharts and / or block diagrams.

[0095] The flowcharts and block diagrams in the figures illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer-readable media according to various embodiments. In this regard, each block in the flowcharts or block diagrams may represent a portion of a microservice(s), module, segment, or instruction set, which includes one or more executable instructions for implementing the specified logical function(s). The methods, computer systems, and computer-readable media may include additional, fewer, different, or differently arranged blocks than depicted in the figures. In some alternative implementations, the functions noted in the blocks may occur out of the order depicted in the figures. For example, two blocks shown in succession may actually be executed concurrently or substantially concurrently, or the blocks may sometimes be executed in the reverse order, depending on the functionality involved. It should also be noted that each block of the block diagrams and / or flowchart diagrams, and combinations of blocks in the block diagrams and / or flowchart diagrams, may be implemented by a special-purpose hardware-based system that performs the specified functions or acts or executes a combination of dedicated hardware and computer instructions.

[0096] It will be apparent that the systems and / or methods described herein may 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 limiting of the implementation. Thus, the operation and behavior of the systems and / or methods are described herein without reference to specific software code, and it will be understood that software and hardware can be designed to implement the systems and / or methods based on the description herein.

Claims

1. 1. A method for managing power consumption of one or more Open Cloud (O-Cloud) nodes in an O-Cloud infrastructure of a telecommunications network, the method being performed by at least one processor, the method comprising: Obtaining, by a Federated O-Cloud Orchestration and Management Module (FOCOM) within a Service Management Orchestration (SMO) framework, a request to modify a C-state of a Central Processing Unit (CPU) of an O-Cloud node within the O-Cloud infrastructure of the telecommunications network; sending, by the FOCOM, a request to modify the C-state of the CPU of the O-Cloud node to an Infrastructure Management Services Module (IMS) via an O2 interface; receiving, by the IMS via the O2 interface, the request to modify the C-state of the CPU of the O-Cloud node; controlling, by the IMS, implementation of the request to modify the C-state of the CPU of the O-Cloud node; sending, by the IMS, to the FOCOM via the O2 interface, a confirmation of the C-state modification of the CPU of the O-Cloud node; A method comprising:

2. monitoring, by a non-real-time radio intelligent controller (NRT RIC), O-Cloud data received via the O2 interface; analyzing the O-Cloud data and, based on the analysis, identifying the O-Cloud nodes to be modified within the O-Cloud infrastructure; sending the O-cloud node C-state modification request to the FOCOM; The method of claim 1 further comprising:

3. monitoring, by a user device, O-Cloud data received via the O2 interface; analyzing, by the user device, the O-Cloud data and, based on the analysis, identifying the O-Cloud nodes to be modified within the O-Cloud infrastructure by the user device; sending, by the user device, the O-Cloud node C-State Modification Request to the FOCOM; The method of claim 1 further comprising:

4. 2. The method of claim 1, further comprising: transmitting, via the FOCOM, a confirmation of the C-state modification of the CPU of the O-Cloud node to at least one of a user device and a non-real-time radio intelligent controller (NRT RIC).

5. The method of claim 2 , wherein the O-Cloud data received via the O2 interface includes at least one of CPU utilization and memory utilization.

6. 3. The method of claim 2, further comprising: transmitting, via the FOCOM, to at least one of a user device and the NRT RIC, a confirmation of the C-state modification of the CPU of the O-Cloud node.

7. The method of claim 6 , wherein the O-Cloud data received via the O2 interface includes at least one of CPU utilization and memory utilization.

8. 1. A system for managing power consumption of one or more Open Cloud (O-Cloud) nodes in an O-Cloud infrastructure of a telecommunications network, the system comprising: at least one memory configured to store computer program code; at least one processor configured to access said at least one memory and to operate as instructed by said computer program code; the computer program code comprising: O-Cloud infrastructure implementation code configured to cause the at least one processor to implement: (i) a Federated 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; an acquisition code configured to cause the at least one processor to acquire, by the FOCOM, a request to modify a C-state of a central processing unit (CPU) of an O-Cloud node in the O-Cloud infrastructure of the telecommunications network; transmit code configured to cause the at least one processor to transmit a request to modify the C-state of the CPU 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, by the IMS, the request to modify the C-state of the CPU of the O-Cloud node; transmit code configured to cause the at least one processor to transmit a confirmation of the C-state modification of the CPU of the O-Cloud node from the IMS to the FOCOM via the O2 interface; A system including:

9. The O-Cloud infrastructure implementation code further includes code configured to cause the at least one processor to implement a Non-Real-Time Radio Intelligent Controller (NRT RIC), the computer program code comprising: monitoring code configured to cause the at least one processor to receive, by the NRT RIC, O-Cloud data via the O2 interface; analysis code configured to cause the at least one processor to analyze, by the NRT RIC, the O-Cloud data and, based on the analysis, identify the O-Cloud nodes to be modified within the O-Cloud infrastructure; transmit code configured to cause the at least one processor to transmit, by the NRT RIC, to the FOCOM, the O-Cloud node C-state modification request; The system of claim 8 further comprising:

10. 10. The system of claim 8, further comprising a human-machine interface configured to enable a user device to receive and analyze O-Cloud data via the O2 interface and further to enable the user device to send the O-Cloud node C-state modification request to the FOCOM.

11. 10. The system of claim 8, wherein the O-Cloud infrastructure implementation code further includes code configured to cause the at least one processor to implement a Non-Real-Time Radio Intelligent Controller (NRT RIC), and the computer program code further includes transmitting code configured to cause the at least one processor to transmit, via the FOCOM, to at least one of a user device and the NRT RIC, a confirmation of the C-state modification of the CPU of the O-Cloud node.

12. The system of claim 9, wherein the O-Cloud data received via the O2 interface includes at least one of CPU utilization and memory utilization.

13. 11. The system of claim 10, wherein the O-Cloud infrastructure implementation code further includes code configured to cause the at least one processor to implement a Non-Real-Time Radio Intelligent Controller (NRT RIC), and the computer program code further includes transmitting code configured to cause the at least one processor to transmit, via the FOCOM, to at least one of the user device and the NRT RIC, a confirmation of the C-state modification of the CPU of the O-Cloud node.

14. The system of claim 13, wherein the O-Cloud data received via the O2 interface includes at least one of CPU utilization and memory utilization.

15. 1. A non-transitory computer-readable medium having stored thereon instructions that, when executed by a processor, cause the processor to perform a method for managing power consumption of one or more Open Cloud (O-Cloud) nodes in 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 to modify a C-state of a Central Processing Unit (CPU) of an O-Cloud node within the O-Cloud infrastructure of the telecommunications network; sending, by the FOCOM, a request to modify the C-state of the CPU of the O-Cloud node to an Infrastructure Management Services Module (IMS) via an O2 interface; receiving, by the IMS via the O2 interface, the request to modify the C-state of the CPU of the O-Cloud node; controlling, by the IMS, implementation of the request to modify the C-state of the CPU of the O-Cloud node; sending, by the IMS, to the FOCOM via the O2 interface, a confirmation of the C-state modification of the CPU of the O-Cloud node; 1. A non-transitory computer-readable medium comprising:

16. The method comprises: monitoring, by a non-real-time radio intelligent controller (NRT RIC), O-Cloud data received via the O2 interface; analyzing the O-Cloud data and, based on the analysis, identifying the O-Cloud nodes to be modified within the O-Cloud infrastructure; sending the O-cloud node C-state modification request to the FOCOM; 16. The non-transitory computer-readable medium of claim 15, further comprising:

17. The method comprises: monitoring, by a user device, O-Cloud data received via the O2 interface; analyzing, by the user device, the O-Cloud data and, based on the analysis, identifying the O-Cloud nodes to be modified within the O-Cloud infrastructure by the user device; sending, by the user device, the O-Cloud node C-State Modification Request to the FOCOM; 16. The non-transitory computer-readable medium of claim 15, further comprising:

18. 16. The non-transitory computer-readable medium of claim 15, wherein the method further includes transmitting, by the FOCOM, to at least one of a user device and a non-real-time radio intelligent controller (NRT RIC) a confirmation of the C-state modification of the CPU of the O-Cloud node.

19. 17. The non-transitory computer-readable medium of claim 16, wherein the O-Cloud data received via the O2 interface includes at least one of CPU utilization and memory utilization.

20. 20. The non-transitory computer-readable medium of claim 17, wherein the O-Cloud data received via the O2 interface includes at least one of CPU utilization and memory utilization.

Images