A method of managing power consumption in an open radio access network, a cloud platform, a management platform, a controller and a computer program

Abstract

Managing cloud resources, particularly power consumption, in an Open Radio Access Network (Open RAN), comprising a cloud platform, a management platform having a controller, and one or more Network Function deployments: Communicating power consumption metrics from the cloud platform to the management platform; communicating network traffic performance metrics from the cloud platform to the management platform; and communicating a power management policy from the management platform to the controller of the cloud platform. The power management policy being based on the one or more power consumption metrics and the one or more network traffic performance metrics.

Description

Field of the invention

[0001] The present invention relates to management of cloud resources in an Open Radio Access Network. In particular, the invention relates to methods of managing power consumption in an Open Radio Access Network. Glossary RAN - Radio Access Network MNO - Mobile Network Operator O-RAN - Open RAN Alliance O-DU - Open Distributed Unit O-CU - Open Central Unit O-RU - Open Radio Unit PHY - Physical Layer MAC - Medium Access Control RLC - Radio Link Control PDCP - Packet Data Convergence Protocol RRC - Radio Resource Control SDAP - Service Data Adaptation Protocol VM - Virtual Machine OS - Operating System GPU - Graphics Processing Unit API - Application Programming Interface SMO - Service Management and Orchestration DMS - Deployment Management Services NF - Network Function IMS - Infrastructure Management Services KPI - Key Performance Indicator CPU - Central Processing Unit Near-RT RIC - Near Realtime RAN Intelligent Controller Non-RT RIC - Non-Realtime RAN Intelligent Controller OAM - Operations and Maintenance FCAPS - Fault, Configuration, Accounting, Performance, and Security DRAM - Dynamic Random Access Memory PPO - Power Plane 0 PP1 - Power Plane 1 ACPI - Advanced Configuration and Power Interface IPMI - Intelligent Platform Management Interface SOC - System on Chip BPF - Berkeley Packet Filter UE - User Equipment BS - Base Station ABS - Advanced Base Station BTS - Base Transceiver Station BSS - Basic Service Set ESS - Extended Service Set AP - Access Point NB - Node B (Radio Base Station Receiver) eNB - Evolved Node B gNB - Next-Generation Node B TRP - Transmission and Reception Point PS - Processing Server TE - Terminal Equipment MS - Mobile Station MT - Mobile Terminal UT - User Terminal SS - Subscriber Station PDA - Personal Digital Assistant CDMA - Code Division Multiple Access FDMA - Frequency Division Multiple Access TDMA - Time Division Multiple Access OFDMA - Orthogonal Frequency Division Multiple Access SC-FDMA - Single Carrier Frequency Division Multiple Access MC-FDMA - Multicarrier Frequency Division Multiple Access UTRA - Universal Terrestrial Radio Access GSM - Global System for Mobile Communications (2G) GSMA - GSM Association GPRS - General Packet Radio Service EDGE - Enhanced Data Rates for GSM Evolution IEEE - Institute of Electrical and Electronics Engineers E-UTRA-Evolved UTRA UMTS - Universal Mobile Telecommunications System (3G) E-UMTS - Evolved UMTS 3GPP - 3rd Generation Partnership Project DL-Downlink UL- Uplink LTE - Long Term Evolution (4G) LTE-A - LTE-Advanced NR - New Radio (5G) FDD - Frequency Division Duplex TDD - Time Division Duplex CRS - Cell-specific Reference Signal CSI-RS - Channel State Information Reference Signal FPGA - Field-Programmable-Gate-Array ASIC - Application-Specific-lntegrated-Circuit DSP - Digital-Signal-Processor CD-ROM - Compact Disc Read-Only Memory DVD-ROM - Digital Versatile Disc Read-Only Memory ROM - Read-Only Memory RAM - Random-Access Memory EEPROM - Electrically Erasable Programmable Read-Only Memory EPROM - Erasable Programmable Read-Only Memory Background

[0002] Open RAN is a technology architecture concept directed to decoupling the hardware and software components of a Radio Access Network (RAN). It is a RAN that includes open interoperable interfaces and virtualization. In prior art (Non-Open) RANs, the hardware and software components are typically proprietary. Non-Open RAN equipment is generally obtained from a single vendor to ensure seamless functionality, security, and efficiency. In contrast, Open RAN introduces open standards for both hardware and software, enabling interoperability among various network elements. For Mobile Network Operators (MNOs), Open RAN holds strategic importance as it promotes vendor diversity, allowing the integration of new suppliers and enhancing supply chain resilience. It also brings energy efficiency gains by enabling targeted improvements in specific areas of the RAN. Furthermore, Open RAN facilitates innovation and competition by providing a more dynamic and efficient network environment. Additionally, it provides an opportunity for collaboration with specialist suppliers and facilitates resource optimization by allowing upgrades to software, without necessitating hardware replacements. Open RAN is important in the long-term network innovation strategy of MNOs, offering energy efficiency, supply chain diversification, resilience enhancement, and facilitating innovation and competition.

[0003] Fig. 1 illustrates some of the elements of an example Open RAN system 100, which is implemented as a cloud computing platform (O-Cloud). The system 100 may be described with reference to different hardware and software layers of the platform.

[0004] At the O-Cloud Node layer 110, the system comprises one or more physical infrastructure nodes 120A, 120N that meet O-RAN requirements. Each physical infrastructure node 120A comprises computing 121, networking 122, GPU 123, and storage 124 components, alongside acceleration technologies 125 for RAN operations (such as forward error correction and other computationally intensive operations that are offloaded to dedicated hardware). Each physical infrastructure node 120A, 120N is configured to host the relevant O-RAN network functions 150, 160, which are implemented at the Open RAN application layer 140. The network functions 150, 160 implemented at the Open RAN application layer 140 may include O-CU 160, O-DU 150, and O-RU.

[0005] The O-CU, O-DU and O-RU network function deployments comprise functional elements for processing different protocols in the RAN protocol stack. The O-DU 150 comprises: • a High-PHY component 151 to perform the scrambling, modulation, layer mapping, precoding, resource element mapping, and I / O compression elements of the PHY layer; • a MAC component 152; and • a RLC component 153.

[0006] The O-CU comprises: • a PDCP component 161; and • a RRC / SDAP component 162.

[0007] The O-DU 150 may further comprise an Open RAN fronthaul interface to connect the O-DU to one or multiple O-RUs.

[0008] At the O-Cloud hypervisor or containers / OS layer 130, there exists a collection of cloud functions to enable the Open RAN applications 150,160 to run on the one or more O-Cloud hardware nodes 120A. The cloud functions may comprise supporting software components, such as an operating system, Containers (stand-alone executable software packages), a Container Orchestration Platforms (such as Kubernetes), a container runtime, and the like. The cloud functions may also include the corresponding management and orchestration functions.

[0009] The O-Cloud serves as a fundamental component for facilitating cloud computing capabilities within the context of RAN network functions. It comprises both hardware and software elements. In particular, its software exposes open APIs, fostering interoperability and flexibility across various vendor solutions. With a decoupled architecture, the O-Cloud allows for sourcing hardware from different vendors, promoting neutrality and flexibility in hardware selection. It supports Service Management and Orchestration (SMO), enabling homing decisions and selecting Deployment Management Services (DMS) for Network Function (NF) Deployments. The DMS handles workload placement, lifecycle management, and resource allocation within O-Cloud Node Clusters, while Infrastructure Management Services (IMS) ensure the infrastructure's availability, reliability, and performance. Moreover, the O-Cloud offers automation capabilities, enhancing efficiency and reducing manual intervention, ultimately supporting efficient resource utilization and scalability for RAN network functions in a cloud-native environment.

[0010] This document provides methods of managing power consumption in an Open Radio Access Network to facilitate energy-saving within the O-Cloud framework. The proposed methods make use of the architecture and interfaces of O-RAN systems, while also identifying adjustments required. Summary

[0011] A first method of managing power consumption in an Open Radio Access Network, Open RAN, is provided. The Open RAN comprises a cloud platform and a management platform. The method comprises communicating one or more power consumption metrics from the cloud platform to the management platform. The method further comprises communicating one or more network traffic performance metrics from the cloud platform to the management platform. The method further comprises communicating, from the management platform to the cloud platform, power management instructions based on the one or more power consumption metrics and the one or more network traffic performance metrics.

[0012] Advantageously, by providing power consumption metrics to the management platform, the management platform is able to send appropriate power management instructions to the cloud platform. The management platform may therefore respond to feedback from the cloud platform to reduce the power consumption of the cloud platform, whilst maintaining network traffic performance.

[0013] The one or more power consumption metrics may comprise one or more Key Performance Indicators, KPIs (power consumption KPIs).

[0014] The one or more network traffic performance metrics may comprise one or more Key Performance Indicators, KPIs (network traffic KPIs).

[0015] The one or more power consumption metrics may be communicated from the cloud platform to the management platform via an 02 interface.

[0016] The 02 interface may be defined between the management platform (e.g., a NFO of the management platform) and the cloud platform (e.g., an IMS and / or one or more DMS of the cloud platform). The 02 interface may be used to regulate infrastructure management services (e.g., for deploying and managing cloud infrastructure), and deployment management services (e.g., for life cycle management of Network Function deployments).

[0017] The power management instructions may be communicated from the management platform to the cloud platform via the 02 interface.

[0018] The 02 interface may be a standardized interface defined in O-RAN documentation, such as “O-RAN Architecture Description” (O-RAN.WG1 .OAD-R003-v11.00), which is herein incorporated by reference. The 02 interface may be modified for communication of the power consumption metrics from the cloud platform to the management platform.

[0019] The management platform may be a Service Management and Orchestration platform, SMO.

[0020] The SMO may be a standardized element defined in O-RAN documentation. The SMO may be modified for performing the methods described in this document.

[0021] The cloud platform may comprise one or more Deployment Management Services, DMS. The power management instructions may be communicated to the one or more DMS of the cloud platform.

[0022] The power consumption metrics may be communicated from the one or more DMS of the cloud platform to the management platform.

[0023] The management platform may comprise a Network Function and Orchestration framework, NFO.

[0024] The power management instructions may be communicated from the NFO of the management platform.

[0025] The one or more power consumption metrics may be communicated to the NFO of the management platform.

[0026] The NFO may be a standardized element defined in O-RAN documentation. The NFO may be modified for performing the methods described in this document.

[0027] The Open RAN further comprises one or more Network Function deployments, wherein the one or more network traffic performance metrics are communicated via the one or more Network Function deployments.

[0028] The one or more network traffic performance metrics may be communicated from the one or more Network Function deployments to the management platform via an 01 interface.

[0029] The 01 interface may be defined between the management platform (e.g., a FOCOM of the management platform) and the one or more Network Function Deployments. The 01 interface may support one or more management entities within the management platform, such as Operation and Maintenance (OAM) elements, FCAPS (Fault, Configuration, Accounting, Performance management, Security management) elements, and software management elements.

[0030] The Network Function and Orchestration framework of the management platform is not to be confused with the one or more Network Function deployments. The one or more network traffic performance metrics may be communicated from the one or more Network Function deployments to the Network Function and Orchestration framework of the management platform via the 01 interface.

[0031] The method may further comprise dynamically modifying one or more cloud resources by communicating instructions from the one or more Network Function deployments to the cloud platform via an Application Programming Interface, API. The instructions for dynamically modifying the one or more cloud resources may be based on the one or more network traffic performance metrics.

[0032] “Dynamically” modifying one or more cloud resources may comprise modifying one or more cloud resources during runtime.

[0033] Modifying one or more cloud resources may comprise tweaking one or more Sleep States (C-States) and / or one or more Performance States (P-States) of the CPU.

[0034] The API interface between the cloud platform and the one or more Network Functions may be defined in Kubernetes (RTM) and / or Linux (RTM) documentation. The API interface between the cloud platform and the one or more Network Functions may be modified for communicating power management instructions from the one or more Network Function deployments to the cloud platform.

[0035] The cloud platform may comprise one or more node clusters.

[0036] The one or more Network Function deployments may be configured to adjust the resources in the cloud platform by sending instructions to a node cluster of the cloud platform via the API.

[0037] The cloud platform may be an O-Cloud.

[0038] The O-Cloud may be a standardized element defined in O-RAN documentation. The O-Cloud may be modified for performing the methods described in this document.

[0039] The controller may be a near-real time radio access network information controller, Near-RT RIC.

[0040] The Near-RT RIC may be a standardized element defined in O-RAN documentation. The Near-RT RIC may be modified for performing the methods described in this document.

[0041] The management platform may comprise a non-real time radio access network information controller, Non-RT RIC. The Non-RT RIC may be configured to receive the one or more power consumption metrics from the cloud platform (e.g., via the 02 interface). The Non-RT RIC may be further configured to receive the one or more network traffic performance metrics from the cloud platform (e.g., via the 01 interface). The Non-RT RIC may be further configured to determine the power management policy based on the one or more power consumption metrics and the one or more network traffic performance metrics. The Non-RT RIC may be further configured to send the power management policy (and optionally the modified power management policy) to the Near-RT RIC (e.g., via the A1 interface).

[0042] The Non-RT RIC may be further configured to receive the adjusted power management policy from the controller (e.g., via the A1 interface). The Non-RT RIC may be further configured to modify the power management policy based on the one or more power consumption metrics and the one or more network traffic performance metrics.

[0043] A second method of managing power consumption in an Open Radio Access Network, Open RAN, is provided. The Open RAN comprises a cloud platform, a management platform and a controller. The method comprises communicating, from the management platform to the controller, a power management policy. The power management policy is based on one or more power consumption metrics from the cloud platform and one or more network traffic performance metrics from the cloud platform.

[0044] Advantageously, the controller is able to enforce the power management policy directly and respond to network traffic performance feedback with reduced latency. This may improve the network traffic performance by providing a separate controller that is able to react quickly to changes in network traffic performance caused by implementing the power management policy. Moreover, by providing a separate controller to manage power consumption, rather than relying on the management platform to perform this role, as in the first example, the volume of data sent to the management platform for the purposes of power management may be reduced. This may improve performance of other functions of the management platform.

[0045] The method may further comprise communicating one or more network traffic performance metrics from the cloud platform to the controller. The controller may be configured to adjust the power management policy based on the one or more network traffic performance metrics.

[0046] The one or more network traffic performance metrics may relate to the performance of the cloud platform while the power management policy is in force.

[0047] The method may further comprise communicating the adjusted power management policy from the controller to the management platform, wherein the management platform is configured to modify the adjusted power management policy based on the one or more network traffic performance metrics and the one or more power consumption metrics. The method may further comprise communicating the modified power management policy from the management platform to the controller.

[0048] The one or more network traffic performance metrics may relate to the performance of the cloud platform while the adjusted power management policy is in force. In other words, the adjusted power management policy may be modified based on one or more network traffic performance metrics relating to the performance of the cloud platform while the adjusted power management policy is in force.

[0049] The one or more power consumption metrics may relate to the power consumption of the cloud platform while the adjusted power management policy is in force. In other words, the adjusted power management policy may be modified based on one or more power consumption metrics relating to the power consumption of the cloud platform while the adjusted power management policy is in force.

[0050] The method may further comprise communicating the one or more power consumption metrics from the cloud platform to the management platform.

[0051] The method may further comprise communicating the one or more network traffic performance metrics from the cloud platform to the management platform.

[0052] The controller may be a near-real time radio access network information controller, Near-RT RIC.

[0053] The management platform may comprise a non-real time radio access network information controller, Non-RT RIC. The Non-RT RIC may be configured to receive the one or more power consumption metrics from the cloud platform (e.g., via the 02 interface). The Non-RT RIC may be further configured to receive the one or more network traffic performance metrics from the cloud platform (e.g., via the 01 interface). The Non-RT RIC may be further configured to determine the power management policy based on the one or more power consumption metrics and the one or more network traffic performance metrics. The Non-RT RIC may be further configured to send the power management policy to the Near-RT RIC (e.g., via the A1 interface).

[0054] The A1 Interface may be defined between the management platform (e.g., a Non-RT RIC of the management platform) and the controller (e.g., Near-RT RIC). The management platform may provide the controller with operational guidance via the A1 interface, such as policies, to manage applications running on the controller.

[0055] The Non-RT RIC may be further configured to receive the adjusted power management policy from the controller (e.g., via the A1 interface). The Non-RT RIC may be further configured to modify the power management policy based on the one or more power consumption metrics and the one or more network traffic performance metrics.

[0056] The Non-RT RIC may be further configured to send the modified power management policy to the to the Near-RT RIC (e.g., via the A1 interface).

[0057] The controller may be configured to implement the power management policy by communicating power management instructions and / or resource allocation instructions from the controller to the cloud platform.

[0058] The controller may be configured to implement the adjusted power management policy and / or modified power management policy in the same way, depending on which policy is in force.

[0059] The method may further comprise communicating power management instructions and / or resource allocation instructions from the controller to the cloud platform.

[0060] The power management instructions and / or resource allocation instructions may be based on the one or more network traffic performance metrics.

[0061] The one or more network traffic performance metrics may be real time network traffic performance metrics. The power management instructions and / or resource allocation instructions may be communicated from the controller to the cloud platform in real time, based on the power management policy (or adjusted / modified power management policy, if in force).

[0062] Accordingly, the one or more network traffic performance metric may be communicated from the cloud platform to the controller in real time (during runtime).

[0063] The Open RAN may further comprise one or more Network Function deployments. The one or more network traffic performance metrics may be communicated dynamically from the cloud platform to the controller via the one or more Network Function deployments. Communicating power management instructions and / or resource allocation instructions from the controller to the cloud platform may comprise dynamically communicating the power management instructions and / or resource allocation instructions from the controller to the one or more Network Function deployments. Communicating power management instructions and / or resource allocation instructions from the controller to the cloud platform may further comprise dynamically modifying one or more cloud resources by communicating instructions from the one or more Network Function deployments to the cloud platform via an Application Programming Interface, API, based on the power management instructions and / or resource allocation instructions.

[0064] In other words, the one or more Network Function deployments may be configured to adjust resources assigned in the cloud platform during runtime, based on the real-time power management instructions received from the controller.

[0065] Modifying / adjusting one or more cloud resources may comprise tweaking one or more Sleep States (C-States) and / or one or more Performance States (P-States) of the CPU.

[0066] “Dynamically” communicating one or more network traffic performance metrics from the cloud platform to the controller via the one or more Network Function deployments may comprise communicating one or more network traffic performance metrics from the cloud platform to the controller via the one or more Network Function deployments during runtime. “Dynamically” communicating the power management instructions and / or resource allocation instructions from the controller to the one or more Network Function deployments may comprise communicating the power management instructions and / or resource allocation instructions from the controller to the one or more Network Function deployments during runtime. “Dynamically” modifying one or more cloud resources may comprise modifying one or more cloud resources during runtime.

[0067] The one or more network traffic performance metrics may be communicated to the management platform via the one or more Network Function deployments. The latency between the cloud platform and the management platform may be greater than the latency between the cloud platform and the controller (and / or the Network Function deployments). Therefore, the controller may be able to respond more quickly to the one or more network traffic performance metrics than the management platform can. The management platform may be configured to modify the power management policy based on the one or more network traffic performance metrics, albeit not necessarily in real time.

[0068] The cloud platform may comprise one or more node clusters.

[0069] The one or more Network Function deployments may be configured to adjust the resources in the cloud platform by sending instructions to a node cluster of the cloud platform via the API.

[0070] The controller may be a separate entity logically and / or physically distinct from the cloud platform.

[0071] The one or more power consumption metrics may comprise one or more Key Performance Indicators, KPIs (power consumption KPIs).

[0072] The one or more network traffic performance metrics may comprise one or more Key Performance Indicators, KPIs (network traffic KPIs).

[0073] The one or more power consumption metrics may be communicated from the cloud platform to the management platform via an 02 interface.

[0074] The 02 interface may be a standardized interface defined in O-RAN documentation. The 02 interface may be modified for communication of the power consumption metrics from the cloud platform to the management platform.

[0075] The power management policy may be communicated from the management platform to the controller via an A1 interface.

[0076] The A1 interface may be a standardized interface defined in O-RAN documentation. The A1 interface may be modified for communication of the power management policy from the cloud platform to the controller.

[0077] The one or more network traffic performance metrics may be communicated from the one or more Network Function deployments to the management platform via an 01 interface.

[0078] The 01 interface may be a standardized interface defined in O-RAN documentation. The 01 interface may be modified for communication of the one or more network traffic performance metrics from the one or more Network Function deployments to the management platform.

[0079] The one or more network traffic performance metrics may be communicated from the one or more Network Function deployments to the controller via an E2 interface.

[0080] The E2 interface may be defined between the controller (e.g., Near-RT RIC) and the one or more Network Function deployments. The E2 interface may be used for forwarding measurements from the one or more Network Function deployments (e.g., O-RUs, O-Dlls, O-CUs, and O-RAN compliant LTE eNBs and / or NR gNBs, which are sometimes referred to as “E2-nodes”), to the controller. The E2 interface may be further used for communicating configuration commands from the controller to the one or more Network Function deployments. This may enable the controller to maintain the RAN infrastructure, such as base stations, using standardized messages (such as monitor, suspend, control and override messages). The E2 interface may also be used to run commands sent by applications running on the controller, and to receive data and metrics from the one or more Network Function deployments.

[0081] The power management instructions and / or resource allocation instructions may be communicated from the controller to the one or more Network Function deployments via the E2 interface.

[0082] The E2 interface may be a standardized interface defined in O-RAN documentation. The E2 interface may be modified for communication of the one or more network traffic performance metrics from the one or more Network Function deployments to the controller and the power management instructions and / or resource allocation instructions from the controller to the one or more Network Function deployments.

[0083] The management platform may be a Service Management and Orchestration platform, SMO.

[0084] The SMO may be a standardized element defined in O-RAN documentation. The SMO may be modified for performing the methods described in this document.

[0085] The management platform may comprise a Network Function and Orchestration framework, NFO.

[0086] The one or more power consumption metrics may be communicated to the NFO of the management platform.

[0087] The one or more power consumption metrics may be communicated from the NFO to the Non-RT RIC of the management platform.

[0088] The NFO may be a standardized element defined in O-RAN documentation. The NFO may be modified for performing the methods described in this document.

[0089] The management platform may comprise a Federated O-Cloud Orchestration and Management framework, FOCOM.

[0090] The one or more network traffic performance metrics may be communicated to the FOCOM of the management platform.

[0091] The one or more network traffic performance metrics may be communicated from the FOCOM of the management platform to the Non-RT RIC of the management platform.

[0092] The FOCOM may be a standardized element defined in O-RAN documentation. The FOCOM may be modified for performing the methods described in this document.

[0093] A third method of managing power consumption in an Open Radio Access Network, Open RAN, is provided. The Open RAN comprises a cloud platform, a management platform and one or more Network Function deployments. The cloud platform comprises a controller. The method comprises communicating one or more power consumption metrics from the cloud platform to the management platform. The method further comprises communicating one or more network traffic performance metrics from the cloud platform to the management platform. The method further comprises communicating a power management policy from the management platform to the controller of the cloud platform. The power management policy is based on the one or more power consumption metrics and the one or more network traffic performance metrics.

[0094] Advantageously, by integrating the controller with the cloud platform, the power management policy may be enforced directly within the cloud platform in real time. This may further improve the network traffic performance by reacting quickly to changes in network traffic performance caused by implementing the power management policy. Moreover, by managing power consumption at a controller within the cloud platform, the volume of data sent externally of the cloud platform for the purposes of power management may be reduced. This may reduce the data traffic on external interfaces, such as the 02 interface, and may improve performance of other functions of the system that rely on these interfaces.

[0095] The method may further comprise dynamically communicating power management instructions and / or resource allocation instructions from the controller to the one or more Network Function deployments. The method may further comprise dynamically modifying one or more cloud resources by communicating instructions from the one or more Network Function deployments to the cloud platform (e.g., to a node cluster of the cloud platform) via an Application Programming Interface, API, based on the power management instructions and / or resource allocation instructions.

[0096] In other words, the controller of the cloud platform may be configured to implement the power management policy by dynamically communicating the power management instructions and / or resource allocation instructions to the one or more Network Function deployments.

[0097] In other words, the one or more Network Function deployments may be configured to adjust resources assigned in the cloud platform during runtime, based on the real-time power management instructions received from the controller (e.g., Near-RT RIC).

[0098] Modifying / adjusting one or more cloud resources may comprise tweaking one or more Sleep States (C-States) and / or one or more Performance States (P-States) of the CPU.

[0099] “Dynamically” communicating the power management instructions and / or resource allocation instructions from the controller to the one or more Network Function deployments may comprise communicating the power management instructions and / or resource allocation instructions from the controller to the one or more Network Function deployments during runtime. “Dynamically” modifying one or more cloud resources may comprise modifying one or more cloud resources during runtime.

[0100] The cloud platform may comprise one or more node clusters. The one or more Network Function deployments may be configured to adjust the resources in the cloud platform by sending instructions to a node cluster of the cloud platform via the API.

[0101] The method may further comprise communicating one or more real time network traffic performance metrics from a node cluster of the cloud platform to the controller of the cloud platform. The power management instructions and / or resource allocation instructions may be based on the one or more real time network traffic performance metrics.

[0102] The controller of the cloud platform may be configured to adjust the power management policy based on the one or more real time network traffic performance metrics.

[0103] The controller of the cloud platform may be further configured to implement the adjusted power management policy (by dynamically communicating the power management instructions and / or resource allocation instructions to the one or more Network Function deployments).

[0104] The one or more real time network traffic performance metrics may be communicated from the cloud platform to the controller in real time. The power management instructions and / or resource allocation instructions may be communicated from the controller to the cloud platform in real time, based on the power management policy (or modified / adjusted power management policy, if in force).

[0105] The one or more real time network traffic performance metrics may relate to the performance of the cloud platform while the power management policy is in force.

[0106] The method may further comprise communicating the adjusted power management policy from the controller to the management platform. The management platform may be configured to modify the adjusted power management policy based on the one or more network traffic performance metrics and the one or more power consumption metrics. The method may further comprise communicating the modified power management policy from the management platform to the controller.

[0107] The controller may be configured to implement the modified power management policy (by dynamically communicating the power management instructions and / or resource allocation instructions to the one or more Network Function deployments).

[0108] The one or more network traffic performance metrics may relate to the performance of the cloud platform while the adjusted power management policy is in force. In other words, the adjusted power management policy may be modified based on one or more network traffic performance metrics relating to the performance of the cloud platform while the adjusted power management policy is in force.

[0109] The one or more power consumption metrics may relate to the power consumption of the cloud platform while the adjusted power management policy is in force. In other words, the adjusted power management policy may be modified based on one or more power consumption metrics relating to the power consumption of the cloud platform while the adjusted power management policy is in force.

[0110] The one or more network traffic performance metrics may be communicated from the cloud platform to the management platform via the one or more Network Function deployments.

[0111] The one or more real time network traffic performance metrics may be communicated from the node cluster of the cloud platform to the controller of the cloud platform via the one or more Network Function deployments.

[0112] The one or more power consumption metrics may comprise one or more Key Performance Indicators, KPIs (power consumption KPIs).

[0113] The one or more network traffic performance metrics may comprise one or more Key Performance Indicators, KPIs (network traffic KPIs).

[0114] The one or more real time network traffic performance metrics may comprise one or more Key Performance Indicators, KPIs (real time network traffic KPIs).

[0115] The one or more power consumption metrics may be communicated from the cloud platform to the management platform via the 02 interface.

[0116] The one or more network traffic performance metrics may be communicated from the node cluster of the cloud platform to the one or more Network Function deployments via the API.

[0117] The one or more network traffic performance metrics may be communicated from the one or more Network Function deployments to the management platform via the 01 interface.

[0118] The power management policy may be communicated from the management platform to the controller of the cloud platform via the A1 interface.

[0119] The power management instructions and / or resource allocation instructions may be communicated from the controller to the one or more Network Function deployments via the E2 interface.

[0120] The one or more real time network traffic performance metrics may be communicated from the node cluster of the cloud platform to the one or more Network Function deployments via the API.

[0121] The one or more real time network traffic performance metrics may be communicated from the one or more Network Function deployments to the controller of the cloud platform via the E2 interface.

[0122] The management platform may be a Service Management and Orchestration platform, SMO.

[0123] The controller may be a near-real time radio access network information controller, Near-RT RIC.

[0124] The management platform may comprise a non-real time radio access network information controller, Non-RT RIC. The Non-RT RIC may be configured to receive the one or more power consumption metrics from the cloud platform (e.g., via the 02 interface). The Non-RT RIC may be further configured to receive the one or more network traffic performance metrics from the cloud platform (e.g., via the 01 interface). The Non-RT RIC may be further configured to determine the power management policy based on the one or more power consumption metrics and the one or more network traffic performance metrics. The Non-RT RIC may be further configured to send the power management policy (and modified power management policy) to the Near-RT RIC (e.g., via the A1 interface).

[0125] The Non-RT RIC may be further configured to receive the adjusted power management policy from the controller (e.g., via the A1 interface). The Non-RT RIC may be further configured to modify the power management policy based on the one or more power consumption metrics and the one or more network traffic performance metrics.

[0126] The management platform may further comprise a Network Function and Orchestration framework, NFO. The one or more power consumption metrics may be communicated from the cloud platform to the NFO of the management platform. The one or more power consumption metrics may be communicated from the NFO of the management platform to the Non-RT RIC of the management platform.

[0127] The management platform may further comprise a Federated O-Cloud Orchestration and Management framework, FOCOM. The one or more network traffic performance metrics may be communicated to the FOCOM of the management platform. The one or more network traffic performance metrics may be communicated from the FOCOM of the management platform to the Non-RT RIC of the management platform.

[0128] The one or more network traffic performance metrics may be communicated to the FOCOM of the management platform from the one or more Network Function Deployments.

[0129] The one or more network traffic performance metrics may be communicated to the FOCOM of the management platform from the cloud platform via the one or more Network Function Deployments.

[0130] A management platform configured to perform the methods described above (in relation to any of the first, second or third examples) is also provided.

[0131] A cloud platform configured to perform the methods described above (in relation to any of the first, second or third examples) is also provided.

[0132] A controller configured to perform the methods described above (in relation to any of the first, second or third examples) is also provided.

[0133] A computer program comprising instructions that, when executed on a processor, cause the processor to perform the methods described above (in relation to any of the first, second or third examples) is also provided. Brief description of the drawings

[0134] Fig. 1 illustrates an example cloud platform.

[0135] The invention will be described with reference to the non-limiting examples illustrated in the following Figures.

[0136] Fig. 2 illustrates an Open RAN system according to a first example.

[0137] Fig. 3 illustrates an Open RAN system according to a second example.

[0138] Fig. 4 illustrates an Open RAN system according to a third example. Detailed description

[0139] As described above, the Open RAN system decouples hardware and software in the RAN network and allows hardware and software components to be provisioned separately. In order to do so, new standards for interactions between the hardware and software components of the Open RAN system have been provided by the Open RAN Alliance (the term “O-RAN” generally refers to standards specified by the Open RAN Alliance).

[0140] Open RAN enables interoperability for hardware and software elements provided by different suppliers. By doing so, Open RAN also provides resilience for the MNO by promoting supplier diversity in the network. If elements from a specific supplier cease to function correctly or need to be removed permanently or temporarily (e.g., due to security or performance requirements), elements from another supplier may be relied upon instead, without major disruption to the network.

[0141] Open RAN also offers potential energy efficiency improvement, for example through flexible provisioning of hardware to meet network requirements.

[0142] The cloud platform, which is sometimes referred to as the “O-Cloud”, serves as a fundamental component of the Open RAN system. The cloud platform comprises hardware and software components. The hardware components of the cloud platform include physical infrastructure nodes arranged in one or more node clusters. These provide the hardware resources that are needed to support the network function deployments (e.g., O-Rll, O-DU and O-CU), which are implemented in software applications running on the cloud platform hardware.

[0143] The network function deployments are sometimes referred to as “managed elements” or “logical nodes” in related literature. “Logical nodes” are not to be confused with the physical infrastructure nodes of the cloud platform. The physical infrastructure nodes of the cloud platform comprise the physical hardware resources required to support the network function deployments. Where this document refers to a “node”, this is to be understood as referring to a physical infrastructure node of the cloud platform. An network function deployment is always referred to as a “network function” or “network function deployment” in this document. Neither of these are to be confused with a 3GPP base station, which is referred to as a “Node B”.

[0144] The cloud platform may comprise an Infrastructure Management Service (IMS) and one or more Deployment Management Services (DMS). Each DMS may manage leased resources from multiple resource pools and span multiple locations. There may be a single IMS for O-Cloud that manages all resources of DMS, as well as resources that are not allocated to any DMS in the O-Cloud.

[0145] The Open RAN system may also provide mechanisms for managing components within the cloud platform. For example, the system may include a management platform, such as a service management and orchestration (SMO) platform, which is responsible for the activities and management of the network functions, as well as management of the different cloud platform node clusters. The management platform may be used to improve overall network performance and enhance customer experience.

[0146] The management platform may be used for allocation and optimization of computing, storage, and networking resources across the RAN. The management platform may be used to ensure that resources are dynamically allocated based on service demands and network conditions, enhancing overall network efficiency and scalability. The management platform may handle the orchestration and management of NF deployments. This may involve NF lifecycle management, resource allocation, scaling, and monitoring to ensure seamless operation and efficient resource utilization.

[0147] The management platform may assign cloud platform resources to resource pools and the one or more DMS. During runtime the management platform may communicate with the IMS and one or more DMS via the 02 interface to manage the infrastructure resources of the cloud platform (creation, deletion and lease of infrastructure resources), manage the abstract resources and DMS, and orchestrate network function deployments. For example, the management platform may perform resource discovery and administration, adding or removing servers or systems to a cluster (so called “Scale-In, Scale-Out”), cloud platform software management, network function software management, and network function Fault, Configuration, Accounting, Performance, and Security (FCAPS), which is explained briefly below.

[0148] Fault management involves detecting and diagnosing issues within the infrastructure and resolving issues to avoid downtime and disruptions. Configuration management involves managing infrastructure configuration to ensure users’ requirements are met. Accounting management involves tracking resource usage and allocating costs to users based on their usage. Performance management involves monitoring the performance of the infrastructure and adjusting resources to meet performance targets. Security management involves implementing and monitoring security measures to protect the infrastructure and its users from potential security threats.

[0149] The 02 interface may be used for managing cloud platform resources and workload within the Open RAN system. The 02 interface connects the management platform to the cloud platform. Through the 02 interface, the management platform can allocate resources, manage the lifecycle of Network Function deployments, scale resources up or down based on demand, and monitor resource utilization, ensuring efficient operation and optimal performance of network functions.

[0150] The management platform may comprise a Federated O-Cloud Orchestration and Management (FOCOM) entity for communicating with the IMS of the cloud platform (via the 02 interface). The management platform may further comprise a Network Function Orchestrator (NFO) for communicating with the one or more network function deployments.

[0151] The IMS may be responsible for physical resource tracking, management and allocation, based on requests from the management platform. The IMS may generate reports on the physical and logical resources and send these to the management platform. The management platform may instruct the IMS to allocate resources, based on the reports received form the IMS. The IMS may also provision infrastructure resources to flexibly match resource demands of the Open RAN network functions. Dynamic resource provisioning may permit the Open RAN system to operate in an agile and scalable manner.

[0152] The DMS may perform network function deployment lifecycle management. The DMS deploys Open RAN network functions using infrastructure resources assigned to the DMS. The DMS may also scale up and down according to the demand of the network function. The DMS may also monitor the status of network functions, and perform recovery operations if a network function becomes out of service.

[0153] In prior art systems, the cloud platform does not expose energy management KPIs, such as CPU utilisation, that could be used to optimise settings provided to the underlying hardware to control CPU states, features, and ultimately energy consumption. Therefore, power consumption of Open RAN systems is currently no better than RAN systems that are not cloud based (and is worse in some cases).

[0154] In contrast to the prior art, the proposed methods involve communicating power consumption metrics (KPIs) from the cloud platform to the management platform (e.g., via the 02 interface). These power consumption metrics may be used by the management platform to select (or generate / modify) a power management policy, which may be implemented to adjust settings provided to the underlying hardware to control CPU states and features, in order to reduce energy consumption.

[0155] In a first example, illustrated in Fig. 2, the management platform may be configured to implement the energy savings policy directly, by sending power management instructions to the cloud platform (e.g., to the one or more DMS).

[0156] The resources of a cloud platform node, such as computing power, network, and storage, utilized by a network function (NF) deployment, can be adjusted to reduce power consumption of the node, considering both present and anticipated resource usage. Prior art methods utilise the management platform to manage resources in the cloud platform but do not manage power consumption of the cloud platform.

[0157] In some examples, the existing hardware and software measurement and telemetry of the cloud platform may be standardized in order to improve the energy efficiency of the cloud platform. The cloud platform may be modified to provide new measurements and telemetry data in the form of power consumption metrics that may be collected from the cloud platform, which may in turn be used to bring about cloud platform energy savings.

[0158] In a second example, illustrated in Fig. 3, the management platform may provide an energy saving policy to a controller, which implements the policy on the network functions and cloud platform resources. The energy saving policy, when applied by the controller, facilitates targeted power management within the Open RAN system. This energy saving policy, accessible to the management platform, outlines specific power management guidelines for individual NF Deployments. Initially, the management platform may request the implementation of the energy savings policy via the 02 DMS interface. Subsequently, the NF deployment may utilise the energy saving policy obtained from the DMS to enact power management measures on its designated node resources (e.g., by using the node cluster resource API to enact adjustments). This approach establishes a closed-loop system between the NF deployment and the cloud platform, enabling swift adjustments with minimal latency. Additionally, this approach supports the application of energy-saving techniques requiring rapid adaptation of node cluster resources.

[0159] This approach may also decrease the traffic on the 02 interface compared to the first example, in which the power consumption metrics and power management instructions are communicated via the 02 interface at an increased rate.

[0160] In some examples, the controller may be provided by a Near-Real Time RAN Intelligent Controller, Near-RT RIC. The Near-RT RIC may manage RAN resources based on metrics received from the cloud platform in near real-time. The Near-RT RIC may be defined in O-RAN documentation and may be adapted to perform the methods described in this document. The Near-RT RIC may be aligned with 3GPP standards (particularly, Release 15 and beyond). The Near-RT RIC may support network slicing, mobile broadband, mission critical communications, and the like.

[0161] The Near-RT RIC may enable MNOs to improve existing services and launch new services by monitoring using of network resources. It may also be used to alleviate network congestion.

[0162] The Near-RT RIC is a logical function that may be used for near-real-time control and adjustment of Open RAN elements and resources. The Near-RT RIC may be used for fine-grained data collection and actions. The Near-RT RIC may send resource allocation instructions to the Network Function deployments via the E2 interface.

[0163] The Near-RT RIC may report back to the management platform how the energy saving policy is affecting the traffic in real time. The Near-RT RIC may receive network traffic performance metrics via the E2 interface. The management platform may make more informed decisions, based on the information from the Near-RT RIC.

[0164] In the second example, the cloud platform may provide the same power consumption KPIs to the management platform as in the first example. However, in the second example, the cloud platform may only need to provide a subset of the information, because part of the management role of the management platform is offloaded to the Near-RT RIC. As a result, the traffic that flows from the cloud platform to the management platform via the 02 interface may be reduced. This may improve performance of other functions using the 02 interface and allow improved resource management to facilitate energy savings, without compromising end to end traffic performance. Moreover, the data processing previously performed by the management platform may be partially offloaded to the Near-RT RIC, which may improve the performance of other functions of the management platform.

[0165] The controller may adjust the energy saving policy during runtime and send the adjusted energy saving policy to the management platform. The management platform may consider the adjustments made to the energy saving policy in real time by the controller and determine whether long-term modifications to the energy saving policy should be made, based on the data received from the cloud platform (the network traffic performance metrics and the power consumption metrics).

[0166] In a third example, illustrated in Fig. 4, additional cloud platform functionalities are introduced to improve the effectiveness of the closed-loop energy adaptation techniques described in relation to the second example. This may improve the overall end-to-end Open RAN reaction to traffic changes. In the third example, the cloud platform architecture is modified so that the controller (e.g., Near-Real Time RIC) is part of the cloud platform, and a closed-loop for adjusting the energy savings policies during runtime is created between the management platform, the Network Function deployments and the cloud platform. This arrangement may decrease the latency of the energy savings policy adjustment, which may reduce the impact on the network traffic. This may also further decrease the traffic on the 02 interface compared to the first and second examples.

[0167] As described above, the cloud platform may expose specific power consumption metrics (KPIs) to the management platform through the 02 interface. The NF may report network traffic performance metrics to the management platform using the 01 interface. For example, the NF may report latency, cell throughput, Block Error Rate (BLER), quality of service (QoS), packet processing time, and the like.

[0168] The management platform may comprise a Non-Real Time RIC. The Non-Real Time RIC may be used for non-real-time control and adjustment of RAN elements and resources. The Non-Real Time RIC may manage RAN resources based on metrics received from the cloud platform that are subject to latency (not in real-time). The Non-RT RIC may be defined in O-RAN documentation and may be adapted to perform the methods described in this document.

[0169] The Non-Real Time RIC may send a policy to the Near-Real Time RIC for the NearReal Time RIC to enforce. The policy may comprise guidance for how the Near-Real Time RIC may manage resources, applications and features. The Non-Real Time RIC may apply Artificial Intelligence and Machine Learning methods to the metrics received from the cloud platform. Data collected at the Non-Real Time RIC may be used for model training and updates. Based on the data collected, the Non-Real Time RIC may modify the policies enforced by the Near-Real Time RIC.

[0170] In some examples, the management platform (in particular, the Non-Real Time RIC component of the management platform) gathers performance-related KPIs reported by the Network Function through the 01 interface, collects the specific energy consumption KPIs provided by the cloud platform via the 02 interface and processes them together. It then chooses a particular energy-saving policy and sends it to the Near-Real Time RIC via the A1 interface.

[0171] The Near-Real Time RIC may enforce the Energy Saving Policy to the NF deployments via the E2 interface. The NF deployments may then apply the energy saving policy. The Energy Saving Policy, when applied by NF Deployment, facilitates targeted power management within the Open RAN network. This policy outlines specific power management guidelines for individual NF Deployments. The NF Deployment enforces the required cloud resource adjustment in accordance with the selected Energy Saving Policy via the “O-Cloud Platform API” that enables the NF Deployment to dynamically modify its allocated cloud platform resources while running, such as tweaking the Sleep States (C-States) and Performance States (P-States) of the CPU. Subsequently, this helps the cloud platform to enact power management measures on its designated node resources, leveraging the node cluster resource API for dynamic and fast adjustments.

[0172] By incorporating the Near-Real Time RIC into the cloud platform, a closed-loop system is created between the management platform, the one or more NF deployments and the cloud platform, enabling seamless adjustments with minimal latency. By integrating the Near-Real Time RIC into the cloud platform, the overhead traffic associated with exposing cloud platform energy consumption KPIs to the management platform through the 02 interface may be reduced. This reduces unnecessary traffic flow between the cloud platform and the management platform, thereby reducing latency. Additionally, by decreasing the latency of the response of the Near-Real Time RIC to performance impacts from implementing power management policies, rapid and seamless adjustments may be achieved, without compromising dynamic traffic requirements. This provides excellent end-to-end quality of service.

[0173] In some examples described above, the one or more NF deployments are used to support dynamic modification of the cloud platform resources. Moreover, standardized APIs may be provided between the one or more NF deployments and the node cluster resources in the cloud platform, in order to ensure seamless integration and interoperability.

[0174] The “O-Cloud resource API”, which is also referred to as the “node cluster resource API”, allows the NF deployments to adjust assigned resources during runtime.

[0175] Assessing the energy usage of cloud platform resources is helpful for gaining insights into the effects of potential energy-saving enhancements on these resources. These cloud platform hardware and software measurement and telemetry data not only aid in measuring the efficacy of energy efficiency policies but also facilitate the identification of areas for improvement or updates to existing policies. By monitoring energy consumption, MNOs can make informed decisions regarding the optimization of energy usage within the cloud platform infrastructure, ensuring that efforts align with desired outcomes and sustainability goals. Measurement and KPI Definitions

[0176] Examples of energy consumption measurements are provided below. Different granularity levels are provided, which include Pod- (or container-) level energy consumption measurements and Node-level energy consumption measurements.

[0177] Container Energy Consumption: • Total container energy consumption (KPI measurement): This KPI measurement offers a comprehensive assessment of energy usage encompassing CPU, DRAM, GPUs, and other host components within a designated container. It provides a precise view on energy consumption by merging individual metrics for each of the aforementioned components. • Total container core energy consumption (KPI measurement): This KPI measurement provides detailed insights into the total energy used by a container's CPU cores. • Total_container_DRAM_energy_consumption (KPI measurement): This KPI measurement provides detailed information about container’s memory-related energy footprint including the cumulative energy consumption of a container in DRAM. • Total container u^ (KPI measurement): Offers the total energy consumption of particular uncore components, comprising the last-level cache, integrated graphics processing unit, and memory controller. • Total_container_package_energy_consumption (KPI measurement): This KPI measurement offers a comprehensive view of the energy utilized by the complete CPU socket, including all core and non-core elements such as the last-level cache, integrated GPU, and memory controller. Typically, Package Energy is assumed to be the sum of Power Plane 0 (PPO) and Power Plane 1 (PP1) energy counters. Nonetheless, PP1 might not fully encompass all non-core energy consumption, possibly resulting in Package Energy surpassing the combined core and non-core usage. • Total_container_peripheral_energy_consumption (KPI measurement): This metric provides detailed insights into the energy usage of peripheral components other than the CPU and DRAM. It typically merges data from two origins: a system-wide sensor accessible via kernel interfaces such as Advanced Configuration and Power Interface (ACPI) or Intelligent Platform Management Interface (IPMI), and data on power consumption by the System on a Chip (SOC). To determine the energy consumption of individual components, this overall figure is usually adjusted by subtracting the measured power of the CPU and DRAM. • Total container G (KPI measurement): This metric provides an assessment of the overall power consumption of the GPU designated for a specific container.

[0178] Container resource utilization: • TotaI BPF container CPU usage: This metric provides detailed information about container's total CPU usage, and it is measured through BPF tracing, which is a software engineering tracing method to collect container's data for profiling and debugging.

[0179] Hardware counters • Total_container_CPU_cycles: This metric provides detailed information about container's CPU usage in raw cycles, and is measured at hardware level directly using hardware counters. These counters provide remarkable accuracy and granularity for analyzing performance and resource utilization. CPU cycles are closely associated with the processor's clock speed. In systems with constant clock speeds, CPU cycles and total CPU time are essentially interchangeable. • Total_container_executed_CPU_instructions: This metric records the total CPU instructions executed within the container, tracked by hardware performance counters. Counting CPU instructions is a recognized method for gauging CPU utilization. • Total_miss_container_cache: This metric offers a precise view of the aggregate cache misses encountered by a specified container by utilizing specific hardware counters.

[0180] Node-level Energy Consumption: • Total node CPU c (KPI counter): This counter provides detailed information about the collective energy usage of every CPU core on the node, encompassing both containers and the operating system. • Total_node_uncore_energy_consumption (KPI counter): This counter provides detailed information about the overall energy consumption of non-core elements (such as caches and memory controllers) on the node, including both containers and the operating system. • Total_node_DRAM_energy_consumption (KPI counter): This counter provides detailed information about the overall energy usage of DRAM on the node, inclusive of both containers and the operating system. • Total_node_package_energy_consumption (KPI counter): This counter provides a comprehensive energy consumption of the CPU package on the node, encompassing both containers and the operating system. • Total_node_peripheral_host_elements_energy_consumption (KPI counter): This counter provides a detailed view on the overall energy consumption of the additional host components, such as network interfaces and storage devices, on the node, including both containers and the operating system. • Total node GPU energy consumption (KPI counter): This counter provides precise information about the cumulative energy usage of GPUs on the node, encompassing both containers and the operating system. • Total_node_energy_consumption (KPI counter): This counter provides precise information about the overall energy consumption of the entire host system.

[0181] Although specific embodiments have been described above, the skilled person will understand that various modifications and variations are possible. For example, whilst the disclosure is described in relation to existing network architecture, it will be understood that changes to the architecture (and / or nomenclature) are possible, but the present disclosure may still be applicable in this case. Also, combinations of any specific features shown with reference to one embodiment or with reference to multiple embodiments are also provided, even if that combination has not been explicitly detailed herein.

[0182] Where this application refers to a server, for instance, this may actually be a pair of servers (primary and failover), for redundancy.

[0183] Where this application refers to a “network entity”, the skilled person would understand that the network entity may actually be provided by a plurality of servers that are geographically distributed.

[0184] An Open Radio Access Network as described above may be used to provide a cellular network serving one or more User Equipments, UEs. Examples of the UE include various fixed and mobile devices that transmit and receive user data and / or various kinds of control information to and from a base station. The UE may be referred to as a terminal equipment (TE), a mobile station (MS), a mobile terminal (MT), a user terminal (UT), a subscriber station (SS), a wireless device, a personal digital assistant (PDA), a wireless modem, a handheld device, etc.

[0185] Whilst the above examples are described in relation to specific radio access networks (e.g., 4G and 5G radio access networks), these methods, techniques, apparatuses, and systems may be applied to a variety of wireless multiple access systems. Examples of multiple access systems include CDMA, FDMA, TDMA, OFDMA, SC-FDMA, and MC-FDMA. CDMA may be embodied through radio technology such as UTRA or CDMA2000. TDMA may be embodied through radio technology such as GSM, GPRS, or EDGE. OFDMA may be embodied through radio technology such as IEEE 802.11 (Wi-Fi), IEEE 802.16 (WiMAX), IEEE 802.20, or E-UTRA. UTRA is a part of a UMTS. 3GPP LTE is a part of E-UMTS using E-UTRA. 3GPP LTE employs OFDMA in DL and SC-FDMA in UL. LTE-A is an evolved version of 3GPP LTE. 3GPP NR employs OFDMA for both downlink and uplink and can operate in both FDD and TDD. For convenience of description, it is assumed that the present invention is applied to 3GPP NR. However, the technical features of the present invention are not limited thereto. For example, although the following detailed description is given based on a mobile communication system corresponding to a 3GPP NR system, aspects of the present invention that are not specific to 3GPP NR are applicable to other mobile communication systems. Moreover, the technical features of the present invention may be applied to future iterations of multiple access systems defined in 3GPP standards, such as (but not limited to) 6G.

[0186] The examples may be carried out on any suitable data processing device, such as a personal computer, laptop, mobile telephone, server, virtual machine, and the like. The above description of the systems and methods has been simplified for purposes of discussion, and is intended to provide a specific example to illustrate the invention. Different types of systems and methods may be used, as will be appreciated by the skilled person. It will be appreciated that the boundaries between logic blocks are merely illustrative and that alternative embodiments may merge logic blocks or elements, or may impose an alternate decomposition of functionality upon various logic blocks or elements.

[0187] It will be appreciated that the above-mentioned functionality may be implemented as one or more corresponding modules as hardware and / or software. For example, the above-mentioned functionality may be implemented as one or more software components for execution by a processor of the system. Alternatively, the above-mentioned functionality may be implemented as hardware, such as on one or more FPGAs, and / or one or more ASICs, and / or one or more DSPs, and / or other hardware arrangements. Method steps implemented in flowcharts contained herein, or as described above, may each be implemented by corresponding respective modules. Moreover, multiple method steps implemented in flowcharts contained herein, or as described above, may be implemented together by a single module.

[0188] Any of the methods described herein may be implemented as computer software or a “computer program”. The computer program may be configured to control a network entity (e.g., a server or group of servers) to perform any method according to the disclosure. A network entity (e.g., a server or group of servers) within a cellular network may also be provided, configured to operate in accordance with certain methods disclosed herein. For example, the network entity may include a processor and at least one communication interface, particularly comprising one or both of a transmitter and receiver.

[0189] A storage medium and a transmission medium carrying the computer program are also provided. The computer program may comprise one or more instructions, or code, that, when executed by a computer, causes the methods described to be performed. A computer program may be a sequence of instructions designed for execution on a computer system, and may include a subroutine, a function, a procedure, a module, an object method, an object implementation, an executable application, an applet, a servlet, source code, object code, a shared library, a dynamic linked library, and / or other sequences of instructions designed for execution on a computer system. The storage medium may be a magnetic disc (such as a hard drive or a floppy disc), an optical disc (such as a CD-ROM, a DVD-ROM, or a Blu-ray disc), or a memory (such as a ROM, a RAM, EPROM, EEPROM, Flash memory or a portable / removable memory device), etc. The transmission medium may be a communications signal, a data broadcast, a communications link between two or more computers, etc.

[0190] Each feature disclosed in this specification, unless stated otherwise, may be replaced by alternative features serving the same, equivalent, or similar purpose. Thus, unless stated otherwise, each feature disclosed is one example only of a generic series of equivalent or similar features.

[0191] As used herein, including in the claims, unless the context indicates otherwise, singular forms of the terms herein are to be construed as including the plural form and vice versa. For instance, unless the context indicates otherwise, a singular reference herein including in the claims, such as "a" or "an" (such as a UE, a network entity, a server or a cell) means "one or more” (for instance one or more UEs, one or more network entities, one or more servers, or one or more cells). Throughout the description and claims of this disclosure, the words "comprise", "including", "having" and "contain" and variations of the words, for example "comprising" and "comprises" or similar, mean "including", and are not intended to (and do not) exclude other components.

[0192] The use of any and all examples, or exemplary language ("for instance", "such as", "for example" and like language) provided herein, is intended merely to better illustrate the invention, and does not indicate a limitation on the scope of the invention unless otherwise claimed. No language in the specification should be construed as indicating any nonclaimed element as essential to the practice of the invention.

[0193] Any steps described in this specification may be performed in any order or simultaneously unless stated or the context requires otherwise. Moreover, where a step is described as being performed after a step, this does not preclude intervening steps being performed.

[0194] All of the aspects and / or features disclosed in this specification may be combined in any combination, except combinations where at least some of such features and / or steps are mutually exclusive. As described herein, there may be particular combinations of aspects that are of further benefit, such the aspects of determining a set of compensation parameters and applying a set of compensation parameters to measurements. In particular, the preferred features of the invention are applicable to all aspects of the invention and may be used in any combination. Likewise, features described in non-essential combinations may be used separately (not in combination).

[0195] A method of manufacturing and / or operating any of the devices disclosed herein is also provided. The method may comprise steps of providing each of the features disclosed and / or configuring or using the respective feature for its stated function.

Claims

:

1. A method of managing power consumption in an Open Radio Access Network, Open RAN, wherein the Open RAN comprises a cloud platform, a management platform5 and one or more Network Function deployments, wherein the cloud platform comprises a controller, the method comprising:communicating one or more power consumption metrics from the cloud platform to the management platform;communicating one or more network traffic performance metrics from the cloud10 platform to the management platform; andcommunicating a power management policy from the management platform to the controller of the cloud platform, wherein the power management policy is based on the one or more power consumption metrics and the one or more network traffic performance metrics.

152. The method of claim 1, further comprising:dynamically communicating power management instructions and / or resource allocation instructions from the controller to the one or more Network Function deployments; and20 dynamically modifying one or more cloud resources by communicating instructionsfrom the one or more Network Function deployments to the cloud platform via an Application Programming Interface, API, based on the power management instructions and / or resource allocation instructions.25 3. The method of claim 2, further comprising communicating one or more real timenetwork traffic performance metrics from a node cluster of the cloud platform to the controller of the cloud platform, wherein the power management instructions and / or resource allocation instructions are based on the one or more real time network traffic performance metrics.

304. The method of claim 3, wherein the controller of the cloud platform is configured to adjust the power management policy based on the one or more real time network traffic performance metrics.15 08 25communicating the adjusted power management policy from the controller to the management platform, wherein the management platform is configured to modify the adjusted power management policy based on the one or more network traffic performance metrics and the one or more power consumption metrics; and5 communicating the modified power management policy from the managementplatform to the controller.

6. The method of any preceding claim, wherein the one or more network traffic performance metrics are communicated from the cloud platform to the management10 platform via the one or more Network Function deployments.

7. The method of any preceding claim, wherein the one or more real time network traffic performance metrics are communicated from the node cluster of the cloud platform to the controller of the cloud platform via the one or more Network Function deployments.

158. The method of any preceding claim, wherein the one or more power consumption metrics and / or the one or more network traffic performance metrics comprise one or more Key Performance Indicators, KPIs.20 9. The method of any preceding claim, wherein the one or more power consumptionmetrics are communicated from the cloud platform to the management platform via an 02 interface.

10. The method of any preceding claim, wherein the one or more network traffic25 performance metrics are communicated from the node cluster of the cloud platform to the one or more Network Function deployments via the API.

11. The method of any preceding claim, wherein the one or more network traffic performance metrics are communicated from the one or more Network Function30 deployments to the management platform via an 01 interface.

12. The method of any preceding claim, wherein the power management policy is communicated from the management platform to the controller of the cloud platform via an A1 interface.3515 08 2513. The method of any preceding claim, wherein the power management instructions and / or resource allocation instructions are communicated from the controller to the one or more Network Function deployments via an E2 interface.5 14. The method of any preceding claim, wherein the one or more real time networktraffic performance metrics are communicated from the node cluster of the cloud platform to the one or more Network Function deployments via the API.

15. The method of any preceding claim, wherein the one or more real time network10 traffic performance metrics are communicated from the one or more Network Function deployments to the controller of the cloud platform via an E2 interface.

16. The method of any preceding claim, wherein the management platform is a Service Management and Orchestration platform, SMO.1517. The method of any preceding claim, wherein the controller is a near-real time radio access network information controller, Near-RT RIC.

18. The method of claim 17, wherein the management platform comprises a non-real20 time radio access network information controller, Non-RT RIC, configured to: receive the one or more power consumption metrics from the cloud platform; receive the one or more network traffic performance metrics from the cloud platform;determine the power management policy based on the one or more power25 consumption metrics and the one or more network traffic performance metrics; and send the power management policy to the Near-RT RIC.

19. The method of claim 18, wherein the management platform further comprises: A) a Network Function and Orchestration framework, NFO, wherein the one or30 more power consumption metrics are communicated from the cloud platform to the NFO of the management platform, wherein the one or more power consumption metrics are communicated from the NFO of the management platform to the Non-RT RIC of the management platform; and / orB) a Federated O-Cloud Orchestration and Management framework, FOCOM, 35 wherein the one or more network traffic performance metrics are communicated to the FOCOM of the management platform, wherein the one or more network traffic performancemetrics are communicated from the FOCOM of the management platform to the Non-RT RIC of the management platform.

20. A management platform configured to perform the steps of the management 5 platform of the method of any of claims 1 to 19.

21. A cloud platform configured to perform the steps of the cloud platform of the method of any of claims 1 to 19.10 22. A computer program comprising instructions that, when executed on a processor,cause the processor to perform the steps of the cloud platform or management platform of the method of any of claims 1 to 19.

Images