Topology based performance correlation, resource optimization and power saving
The method addresses inefficiencies in cloud-based RAN power consumption by optimizing resource allocation and power saving through topology-based predictions and adjustments, enhancing energy efficiency and reducing costs.
Patent Information
- Application Number
- PCT/CN2024/071060
- Authority / Receiving Office
- WO · WO
- Patent Type
- Applications
- Current Assignee / Owner
- Filing Date
- 2024-01-08
- Publication Date
- 2025-07-17
AI Technical Summary
Cloud-based Radio Access Networks (RAN) face inefficiencies in power consumption due to fixed resource allocation regardless of network traffic fluctuations, leading to high energy costs.
A topology-based method for optimizing resource assignment and power saving in O-RAN compliant networks by predicting low traffic periods and dynamically adjusting O-RAN NFs and O-Cloud resources, including powering off underutilized components and redistributing load.
Reduces power consumption and optimizes resource utilization by dynamically adapting to traffic demands, thereby lowering operational costs and improving energy efficiency.
Smart Images

Figure CN2024071060_17072025_PF_FP_ABST
Abstract
Description
TOPOLOGY BASED PERFORMANCE CORRELATION, RESOURCE OPTIMIZATION AND POWER SAVING
[0001] DESCRIPTION OF THE RELATED TECHNOLOGY
[0002] Field of the Disclosure
[0003] The present disclosure relates to systems and methods for radio access networks.Description of the Related Art
[0004] Cloud-based Radio Access Networks (RAN) , compared to traditional RAN, is more scalable, flexible, and offers easier operation, administration, and management (OAM) . Coud-based RAN is usually virtually deployed on commercial off-the-shelf severs, which are centralized or distributed according to network requirements. RF and real-time functions can be processed in a remote radio unit (RU, ) which is localized.
[0005] Power saving methodologies in a current RAN network is predominantly based on the network’s key performance indicators, which are collected as counters from the RAN network functions. O-Cloud resource optimization is predominantly based on the O-Cloud’s telemetry data.SUMMARY
[0006] Described is a topology-based network performance and infrastructure performance correlation resource optimization and power saving method. O-RAN SMO evaluates and determines O-RAN NFs deployment and O-Cloud resource optimization to achieve network and infrastructure power saving according to a topology of network inventory, infrastructure inventory, and correlation of network performance and infrastructure performance.
[0007] Implementations are configured for O-RAN compliant SMO and O-RAN compliant O-RAN NFs, O-RAN compliant SMO and O-RAN compliant O-Cloud. Implementations also support any existing or future wireless system which is O-RAN compliant.BRIEF DESCRIPTION OF THE DRAWINGS
[0008] FIGS 1A-1B illustrate an O-RAN architecture.
[0009] FIGS. 2A-2G show an O-RAN Deployment architecture.
[0010] FIGS. 3A-3D illustrate a topology-based performance correlation and resource optimization.
[0011] FIGS. 4A-4B illustrate an O-Cloud resource optimization.
[0012] DETAILED DESCRIPTION OF THE IMPLEMENTATIONS
[0013] Introduction
[0014] Network traffic fluctuates as population flows. For example, in the business district, in the daytime is high network traffic, however, at midnight, there is low network traffic.
[0015] Traditional RAN is conventionally an integrated unit and deployed fixedly and locally, and in a power-on state with fixed resources based on high traffic, no matter whether the network traffic is high or low. This costs a lot of power.
[0016] Cloud-based RAN is more scalable, flexible deployed on commercial off-the-shelf severs. When the cloud-based RAN is deployed on the server, no matter the network traffic is high or low, the server is in power-on state and a O-Cloud resource request is based on high traffic. This also costs a lot of power.
[0017] Currently, the network and infrastructure power cost are problems. Since cloud-based RAN is more scalable and flexibly deployed on infrastructure, described herein are implementations to provide optimized resource assignment and a power saving method for cloud-based RAN network and infrastructure.
[0018] Acronyms and Definitions
[0019] Reference is made to Third Generation Partnership Project (3GPP) and the Internet Engineering Task Force (IETF) in accordance with embodiments of the present disclosure. The present disclosure employs abbreviations, terms and technology defined in accord with Third Generation Partnership Project (3GPP) and / or Internet Engineering Task Force (IETF) technology standards and papers that define the related terms and architecture reference models that follow.
[0020] Acronyms
[0021] SMO Service Management and Orchestration
[0022] NFO Network Function Orchestration
[0023] FOCOM Federated O-Cloud Orchestration and Management
[0024] OAM operation, administration, and management
[0025] FM Fault Management
[0026] PM Performance Management
[0027] CM Configuration Management
[0028] NF Network Function
[0029] Non-RT RIC O-RAN Non-Real Time RAN Intelligent Controller
[0030] RAN Radio Access Network
[0031] rApp Non-RT RIC Application
[0032] RF Radio Frequency
[0033] TE&IV Topology Exposure and Inventory management
[0034] Near-RT RIC O-RAN Near Real Time RAN Intelligent Controller
[0035] O-CU O-RAN Central Unit
[0036] O-DU O-RAN Distributed Unit
[0037] O-RU O-RAN Radio Unit
[0038] O-Cloud O-RAN Cloud
[0039] O-RAN Open RAN
[0040] O-RAN NE O-RAN Network Element
[0041] DMS O-Cloud Deployment Management Services
[0042] IMS O-Cloud Infrastructure Management Services
[0043] Open FH M-Plane Open Fronthaul Management-Plane
[0044] KPI Key Performance Indicator
[0045] PDCP Packet Data Convergence Protocol
[0046] RRC Radio Resource Control
[0047] PRB Physical Resource Block
[0048] CPU Central Processing Unit
[0049] NIC Network Interface Card
[0050] AAL Accelerator Abstraction Layer
[0051] FCAPS Fault, Configuration, Accounting, Performance, Security
[0052] PNF Physical Network Function
[0053] Definitions
[0054] O1: Interface between SMO framework and O-RAN managed elements, for operation and management, by which FCAPS management, PNF (Physical Network Function) software management, File management shall be achieved.
[0055] O2: Interface between SMO framework and the O-Cloud for supporting O-RAN virtual network functions.
[0056] A1: A1 is the interface between the Non-RT RIC function in SMO and the Near-RT RIC function.Disclosure
[0057] O-RAN, which is based on disaggregated components and connected through open and standardized interfaces is based on 3GPP NG-RAN. An overview of O-RAN with disaggregated RAN (CU, DU, and RU) , near-real-time RIC and non-real-time RIC is shown in the FIGS. 1A-1B. Here, DU (Distributed Unit) and CU (Centralized Unit) are typically implemented using COTS (Commercial off-the-shelf) hardware.
[0058] FIGS. 1A-1B show an example of an O-RAN architecture. In FIG. 1A, the CU and the DU are connected using the F1 interface (with F1-C for control plane and F1-U for user plane traffic) over the midhaul (MH) path. One DU could host multiple cells (for example, one DU could host 24 cells) and each cell may support many users. For example, one cell may support 600 RRC Connected users and out of these 600, there may be 200 Active users (i.e.: users which have data to send at a given point of time) .
[0059] A cell site could consist of multiple sectors and each sector may support multiple cells. For example, one site could consist of three sectors and each sector could support 8 cells (with 8 cells in each sector on different frequency bands) . One CU-CP could support multiple DUs and thus multiple cells. For example, a CU-CP could support 1000 cells and around 100,000 UEs. Each UE could support multiple DRBs and there could be multiple instances of CU-UP to serve these DRBs. For example, each UE could support 4 DRBs, and 400,000 DRBs (corresponding to 100,000 UEs) may be served by five CU-UP instances (and one CU-CP instance) .
[0060] DU can be located in a private data center or it could be located at a cell-site too. CU can also be located in a private data center or even hosted on a public cloud system. DU and CU could be tens of kilometers away. CU can communicate with 5G core system which could also be hosted in the same public cloud system (or could be hosted by a different cloud provider) . RU (Radio Unit) is located at cell-site and communicated with DU via a fronthaul (FH) interface.
[0061] The E2 nodes (CU and DU) are connected to the near-real-time RIC using the E2 interface. The E2 interface is used to send data (e.g., user, cell, slice KPMs) from the RAN, and deploy control actions and policies to the RAN at near-real-time RIC. The application or service at the near-real-time RIC that deploys the control actions and policies to the RAN are called xApps. The near-real-time RIC is connected to the non-real-time RIC using the A1 interface.
[0062] SMO manages multiple regional networks, and O-RAN NFs (O-CUs, Near-RT RIC, O-DUs) can be deployed in regional data center which is connected to multiple cell sites or in cell site which is close to localized O-RU according to network requirements.
[0063] As shown in FIG. 1B, an O-RAN compliant SMO defines TE&IV, RAN NF OAM, Non-RT RIC, and NFO, FOCOM services. SMO interacts with O-RAN NFs with O1 interface. SMO interacts with O-RU with Open FH M-Plane interface and interacts O-Cloud via the O2 interface. O-RAN NF OAM manages O-RAN NF CM, FM, PM and creates O-RAN NF inventory and topology in TE&IV. FOCOM / NFO manages O-Cloud resources and creates O-Cloud resources inventory and topology in TE&IV. Analytics / rApp in Non-RT RIC can subscribe O-RAN NFs PM / FM, O-Cloud PM / FM data based on O-RAN NF OAM an FOCOM / NFO. Analytics / rApp in Non-RT RIC can retrieve the O-RAN NF and O-Cloud resource inventory and topology.
[0064] A general deployment example is given in FIGS 2A-2G. FIG. 2A is a high level view the deployment example architecture. As shown in FIG. 2A, for an SMO, SMO1 in National Data Center 1 and SMO2 in National Data Center 2 can be deployed for Geo-Redundancy. FIG. 2B is a close-up of the left side of FIG. 2A showing a CU at remote data center 1, regional network A, and regional network B. FIG. 2C is a close up showing a DU at a Regional Data Center A and a coverage network for region A. FIG. 2D is a close up of regional network B showing a DU at a Regional Data Center B and a coverage network for region B. FIG. 2E is a close-up of the right side of FIG. 2A showing a CU at remote data center 2, regional network C and regional network D. FIG. 2F is a close up of regional network C showing a DU at a Regional Cellsite C1, a DU at Regional Cellcite C2, and a coverage network for region C. FIG. 2G is a close up of regional network D showing a DU at a Regional Cellsite D1, a DU at Regional Cellcite D2, and a coverage network for region D.
[0065] As shown in FIGS. 2A-2G, SMO manages multiple regional networks, and O-RAN NFs (O-CUs, Near-RT RIC, O-DUs) are deployed in regional data center which is connected to multiple cell sites or in cell site which is close to localized O-RU according to network requirements.
[0066] Since SMO Functions and O-RAN NFs are micro services and deployment-independent logical functions, SMO Functions and O-RAN NFs can be composed of multiple deployment instances deployed in the same O-Cloud, in a different O-Cloud in regional data center, or in a cell site according to network requirements, if the secure connection among SMO Functions and O-RAN NFs are available.
[0067] Implementations described herein can be deployment-independent and are appropriate for any O-RAN deployment scenario.
[0068] In an O-RAN architecture, TE&IV service can maintain O-RAN NFs inventory and topology, O-Cloud inventory and topology and maintain O-RAN NFs and O-Cloud topology. Analytics / rApp can collect O-RAN NFs and O-Cloud FM (Fault Management) and PM (Performance Management) information.
[0069] In Phase1, Analytics / rApp predicts regional network (typical cells) in low traffic and correlated O-Cloud resources in low utilization associated with the cells in low traffic within an hour based on O-RAN NFs and O-Cloud topology and correlated KPI (Key Performance Indicator) analysis. Analytics / rApp can determine to optimize O-Cloud resources.
[0070] In Phase2, Analytics / rApp predicts regional network (typical cells) in low traffic and correlated O-Cloud resource in low utilization associated with the cells in low traffic after O-Cloud resource optimization continuously in multiple hours based on O-RAN NFs and O-Cloud topology and correlated KPI analysis. Analytics / rApp determines to lock cells in low traffic and power off associated O-RUs, optimize O-Cloud resources and reduce associated O-Cloud Nodes. When O-Cloud Nodes are reduced from an O-Cloud Cluster, the corresponding O-Cloud infrastructure (for example, servers) are transferred to power-off status or maintenance status for power saving.
[0071] Described are implementations of optimized resource assignment and power saving method for O-RAN compliant cloud-based RAN network and O-Cloud infrastructure.
[0072] Preconditions
[0073] O-RAN compliant SMO defines TE&IV, RAN NF OAM, Non-RT RIC, NFO, FOCOM services. SMO interacts O-RAN NFs with O1 interface, interacts with O-RU with Open FH M-Plane interface and interacts O-Cloud with O2 interface as FIG. 1.
[0074] O-RAN NF OAM manages O-RAN NF CM, FM, PM and creates O-RAN NF inventory and topology in TE&IV. FOCOM / NFO manages O-Cloud resources and creates O-Cloud resources inventory and topology in TE&IV.
[0075] Analytics / rApp in Non-RT RIC can subscribe O-RAN NFs PM / FM, O-Cloud PM / FM data based on O-RAN NF OAM and FOCOM / NFO.
[0076] Analytics / rApp in Non-RT RIC can retrieve the O-RAN NF and O-Cloud resource inventory and topology.
[0077] Description of Implementations
[0078] An Analytics / rApp is configured to predict regional network (typical cells) in low traffic within hour based on KPI analysis. For example, the typical network traffic KPI can include:
[0079] ● RRC-Connected UEs number is lower than a defined threshold.
[0080] ● Cell PRB utilization is smaller than a defined threshold.
[0081] ● Cell PDCP volumes are smaller than a defined threshold.
[0082] Analytics / rApp queries to get the list of local cells and neighbor cells, O-RUs, O-CUs and O-DUs associated with the typical cells.
[0083] Analytics / rApp queries to get the list of NF Deployment instances of these O-CUs and O-DUs.
[0084] Analytics / rApp queries to get a list O-Cloud resources associated with O-CUs and O-DUs Deployment instances. For example, the typical O-Cloud resources performance metrics are as below :
[0085] ● O-Cloud Node (s) CPU utilization.
[0086] ● O-Cloud Node (s) Memory utilization.
[0087] ● O-Cloud Node (s) Disk utilization.
[0088] ● NF Deployment instance (s) CPU utilization.
[0089] ● NF Deployment instance (s) Memory utilization.
[0090] ● NF Deployment instance (s) Disk utilization.
[0091] Analytics / rApp obtains PM correlation between Cells, O-RAN NFs, and O-Cloud resources.
[0092] Analytics / rApp predicts O-Cloud resources in low utilization associated with the cells in low traffic within each hour. For example, O-Cloud Node (s) and O-CUs, O-DUs Deployment resource utilization are given below. Specific O-Cloud Node (s) and O-CUs, O-DUs Deployment resource utilization is smaller than a defined threshold according to a configuration policy.
[0093] ● O-Cloud Node (s) CPU utilization.
[0094] ● O-Cloud Node (s) Memory utilization.
[0095] ● O-Cloud Node (s) Disk utilization.
[0096] ● O-CUs, O-DUs Deployment instance (s) CPU utilization.
[0097] ● O-CUs, O-DUs Deployment instance (s) Memory utilization.
[0098] ● O-CUs, O-DUs Deployment instance (s) Disk utilization.
[0099] Analytics / rApp determines to dynamically optimize O-Cloud resource, reducing corresponding O-CUs, O-DUs Deployment CPU request, Memory request, and Disk request associated with the cells in low traffic.
[0100] Analytics / rApp optimizes O-Cloud resource to reduce O-CUs, O-DUs Deployment CPU request, Memory request, and Disk request.
[0101] Analytics / rApp predicts regional network (typical cells) in low traffic and O-Cloud resource in low utilization associated with the cells in low traffic after O-Cloud resource optimization continuously in multiple hours based on KPI analysis. For example, the typical network traffic KPI are described herein and above.
[0102] For further example, O-Cloud resource utilization is as below. Specific O-Cloud Node (s) O-CUs, O-DUs Deployment resource utilization is smaller than defined threshold according to configuration policy as described herein and above.
[0103] Analytics / rApp is configured to determine to lock cells in low traffic and associated O-RUs, optimize O-Cloud resource and reduce associated O-Cloud Node. To lock cells in low traffic and associated O-RUs, Analytics / rApp updates O-RUs, O-DUs, O-CUs configuration to lock cells and lock associated O-RUs. And then cells status and O-RUs status are updated to TE&IV. O-RUs are powered off for power saving.
[0104] To optimize O-Cloud resources, in case of neighbor cells in high traffic, Analytics / rApp is configured to redistribute cells to O-DUs and O-DUs to O-CUs and update cells configuration to O-CUs, O-DUs. And then cells list and associated O-RUs, O-CUs and O-DUs are updated to TE&IV. Cells related to the configuration in Near-RT RIC are also updated.
[0105] If there are no other neighbor cells in high traffic, when all cells of O-DUs are locked and all O-RUs connected to O-DUs are powered off, Analytics / rApp is configured to terminate O-DUs deployment. O-DUs deployment are terminated, and resources assigned to the O-DUs deployment are released. And then corresponding O-Cloud resources are deleted from TE&IV.
[0106] If all cells under O-CUs are locked and O-DUs under O-CUs are terminated due to regional low traffic, Analytics / rApp is configured to terminate O-CUs deployment. O-CUs deployment is terminated, and resources assigned to the O-CUs deployment are released. And then corresponding O-Cloud resources are deleted from TE&IV.
[0107] If all regional O-DUs and O-CUs under SMO are terminated, Analytics / rApp is configured to terminate corresponding regional Management Nodes and Near-RT RIC deployment. Corresponding regional Management Nodes and Near-RT RIC deployment are terminated, and resources assigned to the corresponding regional Management Nodes and Near-RT RIC deployment are released. And then corresponding O-Cloud resources are deleted from TE&IV.
[0108] To reduce an associated O-Cloud Node, if all deployment instances are terminated based on the O-Cloud resource optimization above, and no remaining cells are in service in a specific O-Cloud Node or O-Cloud Cluster, Analytics / rApp is configured to determine to reduce the specific O-Cloud Node and update O-Cloud Node Cluster. And then the corresponding O-Cloud Node is deleted from O-Cloud inventory in TE&IV. The corresponding O-Cloud infrastructure (for example, servers) are transferred to power-off status or maintenance status for power saving.
[0109] Extending the use case and procedure above, an Analytics / rApp in a Non-RT RIC can be configured to subscribe and collect any PM / FM data from O-RAN NFs and O-Cloud and retrieve the O-RAN NFs and O-Cloud resource inventory and topology from TE&IV. Based on a mass of PM / FM data analysis and inventory and topology of O-RAN NFs and O-Cloud resource, the Analytics / rApp can build sufficient correlation of any PM / FM of O-RAN NFs and O-Cloud resource and evaluate the mutual effect between O-RAN NFs and O-Cloud. And then Analytics / rApp can predict network, O-RAN NFs and O-Cloud resource performance and fault based on specific PM / FM and / or PM / FM correlation and quickly and accurately determine to optimize network, O-RAN NFs deployment, and O-Cloud resource assignment.
[0110] In case that the Analytics / rApp detects a fault in a specific O-Cloud Node based on specific PM / FM and / or PM / FM correlation analysis and predicts that faults could happen on applications that run on the specific O-Cloud Node, the Analytics / rApp can be configured to optimize O-Cloud resources for the impacted applications and isolate associated O-Cloud Node with the fault. The corresponding applications and O-Cloud resource topology and O-Cloud Node status are updated to TE&IV.
[0111] In case that the Analytics / rApp detects a persistent fault in the application running on a specific O-Cloud Node based on specific PM / FM and / or PM / FM correlation analysis and predicts that the fault in the application can be avoid to isolate a specific O-Cloud resource in the O-Cloud Node, Analytics / rApp can be configured to optimize the O-Cloud resource for the impacted application and isolate the specific O-Cloud resource (ex. CPU, NIC, AAL cards, and so on) . The corresponding application and O-Cloud resource topology are updated to TE&IV.
[0112] In the case that the Analytics / rApp detects a persistent fault in the application running on a specific O-Cloud Node based on specific PM / FM and / or PM / FM correlation analysis and predicts that the fault in the application can be avoided to isolate a specific O-Cloud Node, the Analytics / rApp can be configured to optimize O-Cloud deployment for the impacted application and isolate specific O-Cloud Node. The corresponding application and O-Cloud resource topology and O-Cloud Node status are updated to TE&IV.
[0113] FIGS. 3A-3D are a flow chart for a call flow.
[0114] O-RAN NF PM Collection
[0115] In an implementation a PM is subscribed from O-CU, O-DU, O-RU. At block 301 Analytics / rApp sends PM Function Subscribe O-RAN NFs PM message. This initiates a create PM Job to O-CU, O-DU, O-RU to subscribe PM from O-CU, O-DU, O-RU
[0116] At block 302, PM Function sends Analytics / rApp O-RAN NFs PM data.
[0117] O-RAN NF FM Collection
[0118] At block 303a, Analytics / rApp sends FM Function a Subscribe O-RAN NFs FM message. At block 303b, the FM is subscribed to O-RAN O-CU, O-DU, and O-RU, and at block 303b, FM Function sends O-RAN NFs FM data to the Analytics / rApp.
[0119] O-Cloud PM Collection
[0120] At block 304, Analytics / rApp sends to the NFO / FOCOM a Subscribe O-Cloud PM message. This initiates a create PM Job to O-Cloud to subscribe PM from O-Cloud. At block 305, NFO / FOCOM sends the Analytics / rApp a message with O-Cloud PM data.
[0121] O-Cloud FM Collection
[0122] At the O-Cloud FM Collection, at block 306, Analytics / rApp sends to the NFO / FOCOM a message to Subscribe O-Cloud FM. This subscribes FM from O-Cloud. At block 307, the NFO / FOCOM sends the Analytics / rApp a message to O-Cloud with FM data.
[0123] Phase1: Regional Network in low traffic
[0124] In Analytics, typical cells in low traffic are predicted based on KPI Analysis within hour (ex. RRC-Connected UEs, PRB utilization, PDCP Data Volume, and so on) .
[0125] At block 308, Analytics / rApp sends to the TE&IV a Query to get local cells and neighbor cells, O-RUs, O-CUs and O-DUs associated with the cells.
[0126] At block 309, TE&IV sends to the Analytics / rApp a message to Return the list of cells, O-RUs, O-CUs and O-DUs.
[0127] At block 310 Analytics / rApp sends to the TE&IV a Query to get the NF Deployment instances of these NFs.
[0128] At block 311, TE&IV sends to the Analytics / rApp a message to Return the list of NF Deployment instances.
[0129] At block 312, Analytics / rApp sends to the TE&IV a Query to get O-Cloud resources associated with NF Deployment instances.
[0130] At block 313, TE&IV sends to the Analytics / rApp a message to Return the list of O-Cloud resources (for example: O-Cloud Node (s) CPU utilization, O-Cloud Node (s) Memory utilization, O-Cloud Node (s) Disk utilization, NF Deployment instances CPU utilization, NF Deployment instances Memory utilization, NF Deployment instances Disk utilization, and so on) .
[0131] The Analytics / rApp obtains PM correlations between cells, O-RAN NFs, and O-Cloud resources. Analytics / rApp also predicts O-Cloud resource in low utilization associated with the cells in low traffic within an hour. Analytics / rApp also makes determinations to dynamically optimize O-Cloud resource (for example, reduce corresponding NF Deployment instances, CPU request, Memory request, Disk request) associated with the cells in low traffic.
[0132] O-Cloud Resources Optimization
[0133] Analytics / rApp sends to the NFO / FOCOM a message to Reduce corresponding O-CUs, O-DUs deployment O-Cloud resource request (for example: CPU request, Memory request, Disk request) .
[0134] At block 314, NFO / FOCOM sends to the DMS / IMS a message to Reduce corresponding O-CUs, O-DUs deployment O-Cloud resource request (ex. CPU request, Memory request, Disk request) . At block 315, the DMS / IMS reduces CPU request, Memory request, Disk request of corresponding O-CUs, O-DUs deployment.
[0135] At block 316, DMS / IMS sends to the NFO / FOCOM a message to Notify the reduction of O-CUs, O-DUs deployment CPU request, Memory request, Disk request.
[0136] At block 317, NFO / FOCOM sends to the Analytics / rApp a message to Notify the successful reduction of O-CUs, O-DUs deployment CPU request, Memory request, Disk request.
[0137] At block 318, NFO / FOCOM sends to the TE&IV a message to Update O-Cloud resources from inventory.
[0138] At block 319, TE&IV sends to the NFO / FOCOM an Update O-Cloud resources success message.
[0139] Phase2: Regional Network in low traffic continuously
[0140] The Analytics / rApp is configured to predict typical cells in low traffic (for example: RRC-Connected UEs, PRB utilization, PDCP Data Volume, and so on) and O-Cloud resource in low utilization (for example: NF Deployment Instances CPU utilization, Memory utilization, Disk utilization, O-Cloud Nodes CPU utilization, Memory utilization, Disk utilization) associated with the cells in low traffic continuously in multiple hours after O-Cloud resource optimization. Analytics / rApp is also configured to determine to lock cells in low traffic, optimize O-Cloud resource, and reduce associated O-Cloud Node.
[0141] O-RAN NFs Configuration Update
[0142] At block 320, Analytics / rApp sends to the CM a message to Request O-RUs, O-CUs and O-DUs configuration update.
[0143] At block 321, CM sends to the O-RAN COMPONENT a message to Lock Cells, whereby the O-RAN COMPONENT, O-RU Locks the cells.
[0144] At block 322, O-RAN COMPONENT sends the CM cells a success message.
[0145] At block 323, CM sends to the TE&IV a message to Update cells to “locked” status.
[0146] At block 324, TE&IV sends to the CM a message to Acknowledge status update.
[0147] At block 325 CM sends to the O-RU a message to Lock O-RUs.
[0148] At block 326, O-RU sends to the CM a Lock O-RUs success message.
[0149] At block 327, O-RU Powers off.
[0150] At block 328, CM sends to the Analytics / rApp a Configuration update success message.
[0151] At block 329, CM sends to the TE&IV a message to Update O-RUs to “locked” status.
[0152] At block 330, TE&IV sends to the CM a message to Acknowledge status update.
[0153] At block 331, Analytics / rApp sends to the Near-RT RIC a Configuration update.
[0154] At block 332, Near-RT RIC sends to the Analytics / rApp a Configuration update success message.
[0155] O-Cloud Resources Optimization
[0156] At the NFO / FOCOM and O-RAN COMPONENT, the O-Cloud Resource Optimization workflow is implemented as described herein.
[0157] O-Cloud Node Cluster Update
[0158] At block 333, Analytics / rApp sends to the NFO / FOCOM a message to Request to reduce O-Cloud Node.
[0159] At block 334, NFO / FOCOM sends to the DMS / IMS a message to Request Update O-Cloud Node Cluster (O-Cloud Node reduction) . The O-Cloud resource removal process configuration and network update is implemented.
[0160] At block 335, DMS / IMS sends to the NFO / FOCOM a Response to Update O-Cloud Node Cluster.
[0161] At block 336, NFO / FOCOM sends to the TE&IV a message to Delete corresponding O-Cloud Node from inventory.
[0162] At block 337, TE&IV sends the NFO / FOCOM a Delete O-Cloud Node success message.
[0163] FIGS. 4A-4B are a flow chart for a call flow as for O-Cloud Resource Optimization and O-Cloud Resource Management Orchestration.
[0164] In an implementation, in case of neighbor cells in high traffic, to redistribute neighbor cells to O-DUs and O-DUs to O-CUs:
[0165] At block 401, Analytics / rApp sends to the CM a Request O-CUs and O-DUs configuration update.
[0166] At block 402, CM sends to the O-RAN COMPONENT a message to Cells configuration update.
[0167] At block 403, O-RAN COMPONENT sends to the CM Cells configuration update success message.
[0168] At block 404, CM sends to the TE&IV a message to Update cells list and associated O-RUs, O-CUs and O-DUs.
[0169] At block 405, TE&IV sends to the CM a message to Acknowledge cells list and associated O-RUs, O-CUs and O-DUs update.
[0170] At block 406, CM sends to the Analytics / rApp a Configuration update success message.
[0171] At block 407, Analytics / rApp sends to the Near-RT RIC a Configuration update.
[0172] At block 408, Near-RT RIC sends to the Analytics / rApp a Configuration update success message.
[0173] In the case where no other neighbor cells in high traffic and all cells under O-DUs are locked due to regional low traffic, to terminate O-DUs deployment:
[0174] At block 409, Analytics / rApp sends to the NFO / FOCOM a message to Terminate corresponding O-DUs deployment.
[0175] At block 410, NFO / FOCOM sends to the DMS / IMS a message to Terminate O-DUs deployment.
[0176] O-DUs deployment termination and deallocate the resource assigned to the O-DUs deployment.
[0177] At block 411, DMS / IMS sends to the NFO / FOCOM a message to Notify termination of O-DUs deployment.
[0178] At block 412, NFO / FOCOM sends to the Analytics / rApp a message to Notify the successful termination of O-DUs deployment.
[0179] At block 413, NFO / FOCOM sends to the TE&IV a message to Delete corresponding O-Cloud resources from inventory.
[0180] At block 414, TE&IV sends to the NFO / FOCOM a Delete O-Cloud resources success message.
[0181] In the case where all cells under O-CUs are locked and O-DUs under O-CUs are terminated due to regional low traffic, terminate O-CUs deployment:
[0182] At block 415, Analytics / rApp sends to the NFO / FOCOM a message to Terminate corresponding O-CUs deployment.
[0183] At block 416, NFO / FOCOM sends to the DMS / IMS a message to Terminate O-CUs deployment. The O-CUs deployment is terminated and the resource assigned to the O-CUs deployment is deallocated.
[0184] At block 417, DMS / IMS sends to the NFO / FOCOM a message to Notify termination of O-CUs deployment.
[0185] At block 418, NFO / FOCOM sends to the Analytics / rApp a message to Notify the successful termination of O-CUs deployment.
[0186] At block 419, NFO / FOCOM sends to the TE&IV a message to Delete corresponding O-Cloud resources from inventory.
[0187] At block 420, TE&IV sends to the NFO / FOCOM a Delete O-Cloud resources success message.
[0188] In case of all regional O-DUs and O-CUs under SMO are terminated, to terminate corresponding regional Management Nodes and Near-RT RIC deployment:
[0189] At block 421, Analytics / rApp sends to the NFO / FOCOM a message to Terminate corresponding regional Management Nodes and Near-RT RIC deployment.
[0190] At block 422, NFO / FOCOM sends to the DMS / IMS a message to Terminate corresponding regional Management Nodes and Near-RT RIC deployment.
[0191] The Near-RT RIC deployment is terminated, and the resources assigned to the corresponding deployment are deallocated.
[0192] Management Nodes deployment is also terminated, and the resources deallocated to the corresponding deployment.
[0193] At block 423, DMS / IMS sends to the NFO / FOCOM a message to Notify termination of corresponding regional Management Nodes and Near-RT RIC deployment.
[0194] At block 424, NFO / FOCOM sends to the Analytics / rApp a message to Notify successful termination of corresponding regional Management Nodes and Near-RT RIC deployment.
[0195] At block 425 NFO / FOCOM sends to the TE&IV a message to Delete corresponding O-Cloud resources from inventory.
[0196] At block 426, TE&IV sends to the NFO / FOCOM a Delete corresponding O-Cloud resources success message.
[0197] It will be understood that implementations and embodiments can be implemented by computer program instructions. These program instructions can be provided to a processor to produce a machine, such that the instructions, which execute on the processor, create means for implementing the actions specified herein. The computer program instructions can be executed by a processor to cause a series of operational steps to be performed by the processor to produce a computer-implemented process such that the instructions, which execute on the processor to provide steps for implementing the actions specified. Moreover, some of the steps can also be performed across more than one processor, such as might arise in a multi-processor computer system or even a group of multiple computer systems. In addition, one or more blocks or combinations of blocks in the flowchart illustration can also be performed concurrently with other blocks or combinations of blocks, or even in a different sequence than illustrated without departing from the scope or spirit of the invention.
Claims
1.An Open Radio Access Network (O-RAN) system comprising:a Non-RT RIC (Non-Real Time RAN Intelligent Controller) Application (rApp) configured to: predict cells for a regional network in low traffic and correlated O-Cloud resources in low utilization associated with the cells in low traffic based on Open RAN Network Functions (O-RAN NFs) and O-Cloud topology and correlated KPI (Key Performance Indicator) analysis; and determine optimal O-Cloud resources.2.The O-RAN system of claim 1, further comprising:the rApp being configured to: continuously predict cells for a regional network in low traffic and correlated O-Cloud resources in low utilization associated with the cells after the O-Cloud resource optimization continuously in multiple hours based on the O-RAN NFs and the O-Cloud topology and correlated KPI analysis; and lock cells in low traffic, power off associated O-RAN Radio Units (O-RUs) , and reduce associated O-Cloud Nodes.3.The O-RAN system of claim 1, further comprising:a number of RRC (Radio Resource Control) -Connected UE; and the KPI analysis is selected from at least one KPI criteria including:the number of RRC-Connected UEs is lower than defined threshold,a Cell Physical Resource Block (PRB) utilization is smaller than defined threshold, anda Cell (Packet Data Convergence Protocol) PDCP volume being smaller than defined threshold.4.The O-RAN system of claim 1, wherein the rApp is configured to query to get a list of local cells and neighbor cells, O-RUs, O-RAN Central Units (O-CUs) and O-RAN Distributed Units (O-DUs) associated with the cells.5.The O-RAN system of claim 4, wherein the rApp is configured to query to get a list of NF Deployment instances of the O-CUs and O-DUs.6.The O-RAN system of claim 5, wherein the rApp is configured to get a list O-Cloud resources associated with the O-CUs and O-DUs Deployment instances.7.The O-RAN system of claim 6, wherein the O-Cloud resources performance metrics include at least one of:O-Cloud Node (s) CPU utilization;O-Cloud Node (s) Memory utilization;O-Cloud Node (s) Disk utilization;NF Deployment instance (s) CPU utilization;NF Deployment instance (s) Memory utilization;NF Deployment instance (s) Disk utilization.8.The O-RAN system of claim 1, wherein the rApp is configured to obtain a PM correlation between the cells, the O-RAN NFs, and the O-Cloud resources.9.The O-RAN system of claim 1, wherein the rApp is configured to lock cells in low traffic and associated O-RUs.10.The O-RAN system of claim 9, wherein the rApp is configured to update the O-RUs, O-DUs, and O-CUs configuration to lock cells.11.The O-RAN system of claim 10, wherein the associated O-RUs are configured to be powered off for power saving when locked.12.The O-RAN system of claim 1, wherein to optimize the O-Cloud resources, when neighbor cells are in high traffic, the rApp is configured to redistribute the cells to O-DUs and the O-DUs to O-CUs and update cells configuration to the O-CUs and the O-DUs.13.The O-RAN system of claim 12, wherein to optimize the O-Cloud resources, when there are no other neighbor cells in high traffic, when all cells of O-DUs are locked and all O-RUs connected to the O-DUs are powered off, the rApp is configured to terminate the O-DUs deployment and release O-Cloud resources assigned to the the O-DUs deployment.14.The O-RAN system of claim 12, wherein to optimize the O-Cloud resources, when all cells under O-CUs are locked and O-DUs under O-CUs are terminated due to regional low traffic , the rApp is configured to terminate the O-CUs deployment and release O-CU deployment resources.15.The O-RAN system of claim 1, wherein to optimize the O-Cloud resources, the rApp is configured to: when regional O-DUs and O-CUs under Service Management and Orchestration (SMO) are terminated; terminate corresponding regional Management Nodes and Near-RT RIC deployment; and release the O-Cloud resources assigned to the corresponding regional Management Nodes and Near-RT RIC deployment.16.The O-RAN system of claim 15, wherein to optimize the O-Cloud resources and to reduce associated O-Cloud Node, if all deployment instances are terminated based on O-Cloud resource optimization and no remaining cells are in service in a specific O-Cloud Node or O-Cloud Cluster, the rApp is configured to determine to reduce the specific O-Cloud Node or an O-Cloud Node Cluster.17.The O-RAN system of claim 1, wherein to optimize the O-Cloud resources, the rApp is configured to at leastsubscribe to and collect Performance Management (PM) / (Fault Management) FM data from O-RAN NFs and the O-Cloud and retrieve the O-RAN NFs and a O-Cloud resource inventory and topology from a Topology Exposure and Inventory management (TE&IV) ;build a correlation of any PM / FM of O-RAN NFs and O-Cloud resources; evaluate a mutual effect between O-RAN NFs and O-Cloud; andpredict a network, O-RAN NFs and O-Cloud resource performance and fault based on a specific PM / FM, a PM / FM correlation, or both.18.The O-RAN system of claim 17, wherein to optimize the O-Cloud resources, when the rApp detects a fault in a specific O-Cloud Node, the rApp is configured to optimize O-Cloud resources for impacted applications and isolate associated O-Cloud Node with the fault.19.The O-RAN system of claim 17, wherein to optimize the O-Cloud resources, when the rApp detects a persistent fault in a specific application , the rApp is configured to optimize O-Cloud resources for the impacted application and isolate the O-Cloud resource in the O-Cloud Node.20.The O-RAN system of claim 17, wherein to optimize the O-Cloud resources, when the rApp detects a persistent fault in the application, the rApp is configured to optimize an O-Cloud deployment for the impacted application and isolate a specific O-Cloud Node.
Citation Information
Patent Citations
Energy-saving calculation unloading system and method based on O-RAN Internet of Things system
CN115134364A
Tenant resource optimization (TRO) in clouds
US20230072358A1
Virtualization base and wireless access network control by wireless access network node
WO2023100385A1
Network aware compute resource management use case for o-ran non-RT ric
WO2023177419A1
System and method for draining of o-cloud node
WO2023235536A1