Apparatus and method for optimizing radio access network by extending near RT and non-RT RIC functionality to enable O-cloud optimization and management, and apparatus therefor

Abstract

Techniques are disclosed for implementing near real-time O-cloud optimization requirements by extending O-cloud near RT and non-RT functionality. In one example, a method includes receiving a policy for O-cloud workload optimization via an interface between an O-cloud orchestrator and a near real-time RAN intelligent controller. The method also includes determining that one or more policy scenarios have occurred. Instructions of one or more corrective actions are then transmitted from the near real-time RAN smart controller to the O-cloud. The method also includes performing one or more corrective actions consistent with the received instruction via one or more XApp (s) on the O-cloud. Finally, an acknowledgement of the performance of the one or more corrective actions is transmitted from the one or more Xapps on the O-cloud.

Description

[0001] Related Applications

[0002] This application claims priority to U.S. application No. 18 / 375,145, filed on September 29, 2023, and U.S. Provisional Application No. 63 / 411,733, filed on September 30, 2022, and entitled APPARATUS AND METHODS FOR RADIO ACCESS NETWORK OPTIMIZATION BY EXTENDING NEAR-RT AND NON-RT RIC FUNCTIONALITY FOR O-CLOUD OPTIMIZATION AND MANAGEMENT AND DEVICES THEREOF, which are incorporated herein by reference in their entirety. Technical Field

[0003] Embodiments described herein generally relate to the field of wireless communication systems, and more particularly to management of radio access networks of wireless communication systems. More specifically, embodiments herein relate to an open RAN (O-RAN) architecture, and more specifically, techniques and methods for non-real-time and real-time optimization in an O-RAN architecture. Background Art

[0004] The use of 3GPP LTE systems has increased with the increase in different types of devices communicating with various network devices. The penetration of mobile devices in modern society continues to drive the demand for a wide variety of networked devices. As mobile traffic increases, mobile networks and the equipment they run must become more software-driven, virtualized, flexible, intelligent and energy-efficient. Through the use of radio access network (RAN) technology, the throughput, coverage and robustness of 5G networks are improved while latency and operating and capital expenditures are reduced.

[0005] RAN virtualization and the move toward more container-based and cloud-native RAN implementations have led to the development of industry-wide standards for open RAN interfaces. These standards, driven by O-RAN and 3GPP, support interoperability of RAN equipment regardless of vendor.

[0006] As further described herein, the O-RAN architecture introduces two important control and management functions relative to the existing LTE / 5G RAN architecture proposed by 3GPP. The first is the RAN Intelligent Controller (RIC), which decouples RAN-related control plane radio resource management (RRM) and optimization functions from vendor-supplied RAN functions via open interfaces, in contrast to today's closed SON optimization functions that are provided by vendors and are primarily associated with specific vendor implementations. The second is the Service Management and Orchestration (SMO) function, which also manages the FCAPS and O-cloud infrastructure of the RAN via open interfaces.

[0007] RIC has two architectural components: Near RT RIC and Non-RT RIC. RIC is a platform that hosts RRM optimization applications for L1 / L2 / L3 applicable to the RAN stack. Near RT RIC hosts optimization functions with control loop latency of 10ms to 1s. Near RT RIC is hosted at far edge or edge cloud deployment to manage mission critical applications. Non-RT RIC hosts optimization functions with control loop latency >1s. Non-RT RIC is centralized and co-located with the SMO. It is recommended that the RIC platform manage the strict SLAs of end-to-end 5G services by subscribing to near real-time data from the RAN, which is used by the XApp to infer whether the RAN system is operating within the desired limits, and if not, apply changes to the RAN protocol stack to achieve the desired operating point.

[0008] O-Cloud is another component of the O-RAN architecture, which hosts the physical infrastructure and virtualized RAN workloads. These are implemented via COTS platforms equipped with appropriate OS / core, I / O, accelerators to offload some of the processing required for real-time DU and CU workloads. O-Cloud forms a larger part of the paradigm shift to decouple RAN hardware and software to allow flexible RAN deployments to meet the needs of private enterprises, (sub) cities, rural areas, allowing CUs and DUs to be placed in a hierarchical cloud deployment based on the specific traffic characteristics and services provided in that specific deployment scenario.

[0009] O-RAN currently focuses on near real-time RAN stack optimization via RIC, this patent addresses another key missing piece, which is non-real-time and near real-time O-cloud optimization, because if the underlying platform cannot adapt to the dynamic requirements of the RAN workload, the overall goal of preserving SLAs in a non-real-time or near real-time manner may fail. DETAILED DESCRIPTION

[0010] The following detailed description refers to the accompanying drawings. The same reference numerals may be used in different figures to indicate the same or similar elements. In the following description, specific details, such as specific structures, architectures, interfaces, technologies, etc., are set forth for the purpose of explanation rather than limitation, so as to provide a thorough understanding of various aspects of the present disclosure. However, it will be apparent to those skilled in the art who benefit from the present disclosure that various aspects of the claims can be practiced in other examples that deviate from these specific details. In some examples, descriptions of well-known devices, circuits, and methods are omitted to avoid obscuring the description of the present disclosure with unnecessary details.

[0011] refer to Figure 1 , an exemplary computing infrastructure supporting a network-accessible client-server software application 100 may include various interconnected computing devices (e.g., network traffic devices) to potentially improve the scalability, availability, security, and / or performance of the illustrated client-server architecture. As an example, an intermediate server computer such as a network traffic management device 106 or appliance may be logically positioned between a client device 102a to 102n attempting to access a client-server software application and a server computer 110a to 110n on the server side executing the client-server software application. For example, the intermediate server computer may perform various proxy and other services such as load balancing, rate monitoring, caching, encryption / decryption, session management (including key generation), address translation, and / or access control. This technology provides many advantages, including providing a method for application deployment across multiple locally connected computing subdomains (including intelligent network interface cards), a non-transitory computer-readable medium, a network traffic management system, and a network traffic management device.

[0012] In this particular example, Figure 1106, server devices 110a to 110n, and client devices 102a to 102n are disclosed as dedicated hardware devices. However, one or more of the network traffic management device 106, server devices 110a to 110n, and client devices 102a to 102n may also be implemented in software in one or more other devices in the network traffic management system. As used herein, the term "module" refers to an implementation as a dedicated hardware device or device, or a software implementation hosted by another hardware device or device that can host one or more other software components or implementations. As an example, the network traffic management device 106 and any of its components, models, or applications may be a module implemented as software executed on one of the server devices, while in other examples, many other arrangements and types of implementations may also be used. In addition, any or all of the network traffic management device 106, server devices 110a to 110n, and client devices 102a to 102n may be implemented and may be referred to as a module herein.

[0013] Figure 2 A conventional O-RAN architecture is depicted. The O-RAN architecture includes four O-RAN defined interfaces: an A1 interface 202, an O1 interface 204, an O2 interface 206, and an open fronthaul management (M) plane interface 208, which connects a service management and orchestration framework (SMO) framework 210 to an O-RAN network function (NF) 212 and an O cloud 220. The SMO 210 may also be connected to an external device or system, which may provide configuration data to the SMO 210. As further illustrated, the A1 interface 202 connects an O-RAN non-real-time (RT) RAN intelligent controller (RIC) 214 in or at the SMO 210 and an O-RAN near-RTRIC 216 in or at the O-RAN NF 212. As will be appreciated, the O-RAN NF 212 may be a virtualized network function, such as a virtual machine (VM) or container located on top of the O cloud 220 and / or a physical network function utilizing customized hardware. The open fronthaul M-plane interface 208 between the SMO 210 and the O-RAN radio unit (O-RU) 218 ​​supports O-RU management in the O-RAN hybrid model.

[0014] Figure 3 Display corresponds to Figure 5306 )), supporting software components (e.g., OS, VMM, container runtime engine, ML engine, etc.), and appropriate management and orchestration functions. The radio part / side of the logical architecture includes the Near RT RIC 308, O-RAN Distributed Unit (O-DU) 314, O-RU 316, O-RAN Central Unit - Control Plane (O-CU-CP) 310, and O-RAN Central Unit - User Plane (O-CU-UP) 312 functions. The radio part / side of the logical architecture may also include O-eNB 318.

[0015] O-DU 314 is a logical node that hosts RLC, MAC, and higher PHY layer entities / elements (high PHY layer) based on lower layer functional division. O-RU 314 is a logical node that hosts lower PHY layer entities / elements (low PHY layer) (e.g., FFT / iFFT, PRACH extraction, etc.) and RF processing elements based on lower layer functional division. Virtualization of O-RU 316 is FFS. O-CU-CP 310 is a logical node that hosts the RRC and control plane (CP) parts of the PDCP protocol. O O-CU-UP 312 is a logical node that hosts the user plane parts of the PDCP protocol and SDAP protocol.

[0016] The E2 interface 320 terminates at multiple E2 nodes. The E2 node is a logical node / entity that terminates the E2 interface. For NR / 5G access, the E2 node includes O-CU-CP 310, O-CU-UP 312, and O-DU 314. For E-UTRA access, the E2 node includes Oe / gNB 318. Figure 3As shown, the E2 interface also connects the Oe / gNB 318 to the Near RT RIC 304. The protocols on the E2 interface are completely based on the control plane (CP) protocol. The E2 functions are grouped into the following categories: (a) Near RT RIC 304 services (REPORT, INSERT, CONTROL, and POLICY); and (b) Near RT RIC 304 support functions, which include E2 interface management (E2 settings, E2 resets, general error status reporting, etc.) and Near RT RIC 304 service updates (e.g., capability exchanges related to the list of E2 node functions exposed via E2).

[0017] O-eNB 318 is an LTE eNB, 5G gNB or ng-eNB supporting the E2 interface. O-eNB 318 can be the same or similar to other RAN nodes discussed previously. There can be multiple Oe / gNBs 318, each of which can be connected to each other via a corresponding interface.

[0018] The open fronthaul (OF) interface 324a, 324b is between the O-DU function 314 and the O-RU function 316. The OF interface 324a, 324b includes a control user synchronization (CUS) plane and a management (M) plane. Figures 2 to 3 The O-RU 316 is also shown terminating an OFM plane interface 324b to the O-DU 314 and optionally to the SMO 302. The O-RU 316 terminates an OFCUS plane interface 324a to the O-DU 314 and the SMO 302.

[0019] The F1-c interface 326 connects the O-CU-CP 310 with the O-DU 314. As defined by 3GPP, the F1-c 326 interface is between the gNB-CU-CP node

[007] and the gNB-DU node

[010] . However, for O-RAN purposes, the F1-c interface is employed between the O-CU-CP function 310 and the O-DU function 314, while reusing the principles and definitions of the protocol stack and interoperability profile specifications defined by 3GPP.

[0020] The F1-u interface 328 connects the O-CU-UP 312 with the O-DU 314. As defined by 3GPP, the F1-u interface 328 is between the gNB-CU-UP node and the gNB-DU node. However, for O-RAN purposes, the F1-u interface 328 is employed between the O-CU-UP function 312 and the O-DU function 314, while reusing the principles and definitions of the protocol stack and interoperability profile specifications defined by 3GPP.

[0021] The NG-c interface 330 is defined by 3GPP as the interface between the gNB-CU-CP and the AMF in the 5GC. The NG-c 330 is also referred to as the N2 interface. The NG-u interface is defined by 3GPP as the interface between the gNB-CU-UP 310 and the UPF in the 5GC. The NG-u interface 330 is referred to as the N3 interface. In O-RAN, the NG-c and NG-u protocol stacks defined by 3GPP are reused and can be adapted for O-RAN purposes.

[0022] The X2-c interface 332 is defined in 3GPP for transporting control plane information between eNBs or between eNB and en-gNB in ​​EN-DC. The X2-u interface is defined in 3GPP for transporting user plane information between eNBs or between eNB and en-gNB in ​​EN-DC. In O-RAN, the 3GPP-defined X2-c and X2-u protocol stacks are reused and can be adapted for O-RAN purposes.

[0023] The Xn-c interface 334 is defined in 3GPP for transporting control plane information between gNBs, between ng-eNBs, or between ng-eNB and gNB. The Xn-u interface is defined in 3GPP for transporting user plane information between gNBs, between ng-eNBs, or between ng-eNB and gNB. In O-RAN, the 3GPP-defined Xn-c and Xn-u protocol stacks are reused and can be adapted for O-RAN purposes.

[0024] The E1 interface 331 is defined by 3GPP as the interface between the gNB-CU-CP and the gNB-CU-UP. In O-RAN, the E1 protocol stack defined by 3GPP is reused and adapted as the interface between the O-CU-CP function 310 and the O-CU-UP function 312.

[0025] The O-RAN Non-Real-Time (RT) RAN Intelligent Controller (RIC) is a logical function within the SMO framework that implements non-real-time control and optimization of RAN elements and resources; AI / machine learning (ML) workflows including model training, inference, and updates; and policy-based guidance of applications / features in the near-RT RIC.

[0026] In some embodiments, the non-RT RIC is a function within the SMO platform (or SMO framework) located in the O-RAN architecture. The main goal of the non-RT RIC is to support intelligent radio resource management for non-real-time intervals (i.e., greater than 500ms), policy optimization in the RAN, and inserting AI / ML models into the near-RT RIC and other RAN functions. The non-RT RIC terminates to the A1 interface of the near-RT RIC. The non-RT RIC also collects OAM data from the O-RAN nodes via the O1 interface.

[0027] The O-RAN Near RT RIC is a logical function that enables near real-time control and optimization of RAN elements and resources via fine-grained data collection and actions over the E2 interface. The Near RT RIC may include one or more AI / ML workflows including model training, inference, and updates.

[0028] A non-RT RIC may be an ML training host that hosts the training of one or more ML models. ML training may be performed offline using data collected from the RIC, O-DU, and O-RU. For supervised learning, the non-RT RIC is part of the SMO, and the ML training host and / or ML model host / participant may be part of the non-RT RIC and / or near-RT RIC. For unsupervised learning, the ML training host and ML model host / participant may be part of the non-RT RIC and / or near-RT RIC. For reinforcement learning, the ML training host and ML model host / participant may be co-located as part of the non-RT RIC and / or near-RT RIC. In some implementations, the non-RT RIC may request or trigger ML model training in the training host, regardless of where the model is deployed and executed. An ML model may have been trained but is not currently deployed.

[0029] In some embodiments, the non-RT RIC provides a queryable directory for ML designers / developers to publish / install trained ML models (e.g., executable software components). In these implementations, the non-RT RIC can provide a discovery mechanism when a specific ML model can be executed in a target ML reasoning host (MF), as well as the number and type of ML models that can be executed in the MF. For example, the non-RT RIC can discover three types of ML directories: design time directories (e.g., residing outside the non-RT RIC and hosted by some other ML platform), training / deployment time directories (e.g., residing in the non-RT RIC), and runtime directories (e.g., residing in the non-RT RIC). The non-RT RIC supports the necessary capabilities for ML model reasoning to support ML-assisted solutions running in the non-RT RIC or some other ML reasoning host. These capabilities enable the installation of executable software, such as VMs, containers, etc. The non-RT RIC may also include and / or operate one or more ML engines, which are packaged software executable libraries that provide methods, routines, data types, etc. for running ML models. Non-RT RICs can also implement strategies to switch and launch ML model instances under different operating conditions.

[0030] The non-RT RIC can access feedback data about the performance of the ML model (e.g., FM and PM statistics) via the O1 interface and perform necessary evaluations. If the ML model fails during runtime, an alarm can be generated as feedback to the non-RTRIC. The performance of the ML model in terms of prediction accuracy or other operational statistics it generates can also be sent to the non-RT RIC via O1. The non-RT RIC can also scale the ML model instances running in the target MF via the O1 interface by observing the resource utilization in the MF. The environment (e.g., MF) running the ML model instance monitors the resource utilization of the running ML model. This can be done, for example, using an ORAN-SC component called a ResourceMonitor in the near-RT RIC and / or non-RT RIC that continuously monitors resource utilization. If the resources are less or below a certain threshold, the runtime environment in the near-RTRIC and / or non-RT RIC provides a scaling mechanism to add more ML instances. The scaling mechanism may include a scaling factor, such as a number, percentage, and / or other similar data for enlarging / reducing the number of ML instances. By observing the resource utilization in MF, it is possible to automatically scale the ML model instances running in the target ML inference host. For example, (K8s) runtime environments usually provide autoscaling features.

[0031] The A1 interface is between the non-RT RIC (inside or outside the SMO) and the near-RT RIC. The A1 interface supports three types of services, including policy management services, rich information services, and ML model management services. Compared with persistent configuration, A1 policy has the following characteristics: A1 policy is non-critical to traffic; A1 policy is temporarily valid; A1 policy can handle individual UEs or dynamically defined UE groups; A1 policy operates within the configuration and takes precedence over the configuration; and A1 policy is non-persistent, that is, it will not survive a restart of the near-RT RIC.

[0032] like Figure 2 and Figure 3 As shown, the following O-RAN interfaces can be configured:

[0033] (a) The A1 interface is between non-RT-RIC functions and near-RT-RIC functions; A1 is associated with policy guidance for control plane functions and user plane functions; the affected O-RAN elements associated with A1 include O-RAN nodes;

[0034] (b) The O1 interface is between O-RAN managed elements and management entities; O1 is associated with management plane functions, configuration and threshold setting, mainly OAM and FCAPS functions to O-RAN network functions; the affected O-RAN elements associated with O1 mainly include O-RAN nodes;

[0035] (c) The O2 interface is between the SMO and the infrastructure management framework; O2 is associated with the cloud infrastructure and the management of the cloud resources allocated to O-RAN and the FCAPS of the O-cloud; the affected O-RAN elements associated with O2 include the O-cloud;

[0036] (d) The E2 interface is between the Near RT RIC and the E2 node; E2 is associated with the control plane and user plane control functions; the affected O-RAN elements associated with E2 include the E2 node; E2-cp is between the Near RT RIC and the O-CU-CP function. E2-up is between the Near RT RIC and the O-CU-UP function; E2-du is between the Near RT RIC and the O-DU function. E2-en is between the Near RT RIC and the O-eNB function; and

[0037] (g) The open fronthaul interface is between the O-DU function and the O-RU function; this interface is associated with the CUS (Control User Synchronization) plane and the management plane function and FCAPS to O-RU; the affected O-RAN elements associated with the open fronthaul interface include the O-DU function and the O-RU function.

[0038] The O cloud is a key part of the distributed infrastructure that hosts RAN functions, which includes CU-UP, CU-CP, DU and RIC. During operation, the O cloud is expected to generate a large amount of health and performance related data at the physical layer, virtual layer and workload layer. The physical layer data is related to the physical device (NIC, processor, OS, accelerator, switch or storage node), and this data includes power or energy metrics, operating status, physical parameters such as temperature or fan speed, etc. The data can be workload or non-workload related metrics, such as operating status, total utilization, temperature, etc. The virtual layer (cluster level) data is related to the health of the functions that manage virtualization functions (such as CRI, Kubelet, workload, CNI plug-in and device driver), and is also related to performance metrics, such as the overall utilization of each virtualized resource (such as accelerator, CPU, memory, etc.), or the power / energy consumption of each of these virtual resources dedicated to the workload. Workload related data is related to the available and utilized VF resources associated with a specific workload. This critical data can be used to drive AI / ML functions hosted in near-RT or non-RT RICs to predict any anomalies in the cloud infrastructure (planned or reactive), or serve energy optimization goals and take remedial actions such as seamless workload migration to another host, thereby avoiding any service interruption.

[0039] Current approaches to address near real-time O-cloud optimization rely primarily on using non-RAN-agnostic functions implemented as part of site- or cluster-wide O-cloud virtualization platform software (e.g., K8S controller), or via long-term optimization intelligence in SMO and leveraging O2-ims and O2-dms interfaces between centralized SMO and distributed O-cloud instances. As will be appreciated, there may be on the order of thousands of O-cloud distributed sites, thus also raising scalability issues. So far, these solutions have not been able to meet near-RT optimization requirements.

[0040] Figures 4 to 9 Various embodiments of the presently disclosed technology are illustrated. As further shown and described below, the disclosed technology is intended to address near real-time O-cloud optimization requirements that impact CU / DU performance due to dynamic changes in workload, fault performance, or timing / synchronization degradation of the O-cloud platform. These dynamic changes require dynamic adaptation of underlying O-cloud resources such as compute, memory, accelerators, or I / O resources to meet the near real-time requirements of the DU or CU. In addition, the system may require near real-time notification service exposure of RAN workloads from the underlying physical and virtualized platforms to allow corrective actions to be taken.

[0041] Examples of this technology require optimization functions to operate at a near-RT scale similar to the RRM XApp in order to meet the near-RT requirements from an O-cloud programmability perspective. This requires RAN-like functions (i.e., the O-cloud center XApp) to operate as part of the near-RT RIC and non-RTRIC platform so that the O-cloud / R-App can set policies in the distributed O-cloud / X-App, and the O-cloud X-App can subscribe to relevant data from the IMS and DMS subsystems of the O-cloud and perform control functions to meet policy requirements. Figures 3 to 9 As illustrated in , examples of the described techniques extend near RT and non-RT RICs to host virtualized resources, recovery, infrastructure troubleshooting, energy saving, and optimization functions related to the O cloud. In addition, the proposed solution can predict or respond to any anomalies in hardware, virtualization, or workload, and take remedial measures to mitigate any interference with RAN services. In addition, the RRM / XApp can also communicate with the O cloud platform to subscribe to data related to physical, virtual, or workload specific functions, and request any additional resources to meet the expected future demand for a specific DU or CU set.

[0042] Figure 4 An updated O-RAN logical architecture with an A1 interface 402 and an E2 interface 404 is depicted. As depicted, the architecture includes extensions to the current A1 interface 402 and E2 interface 404. As further described below, the extensions allow lifecycle management of O cloud Xapps, policy management of Xapps, and data subscription / control of O cloud instances using IMS and DMS functions. Specifically, the A1-O2* extension 406 allows policies to be set in the O cloud-related XApps in operation to optimize physical and virtual workload resources. The E2-O2* extension 408 extends the semantics and APIs proposed for the CU and DU, and acts on near-RT data from the O cloud and takes actions to achieve specific policy goals. As will be appreciated, this allows third-party O cloud XApps to request and apply standardized methods of physical hardware tuning and optimization or control in the virtualization layer.

[0043] The O cloud XApp can be an independent service for managing O cloud resources in a cluster, or can supplement the RAN / X-App to maintain the policy objectives of RAN services and functions. For example, the RAN / X-App can be used to expand resources vertically or horizontally outward or inward. The purpose of such an O cloud X-App can be similar to RRM, that is, to monitor, control and adapt the behavior of the O cloud instance according to the changing needs of the RAN workload. For example, the traffic manipulation X-App / R-App can be interfaced with the O cloud X-App / R-App to expand resources that are dynamically responsive to user traffic in the cell while monitoring the utilization of the cell associated with the DU, and the resources include CPU cores, large pages, I / O, accelerator resources, etc., or establish new instances of network functions. As another example, an independent O cloud X-App / R-App that monitors a host or virtualized resource can initiate workload migration if any abnormality is found in the health or performance metrics related to the host or virtualized resource. In another example, the O cloud Xapp can be used to monitor the time synchronization of each host that hosts the DU function. Any detected loss of synchronization may invoke steps such as checking the PTP connection to the PTRC / GM or boundary clock switch.

[0044] As you will understand, Figure 4 The architecture depicted in can allow the use of O1 / O2 interfaces to complete automatic lifecycle management (LCM) of O cloud Xapps. In addition, the SMO / non-RT RIC interface functionality can be extended to train AI / ML models using data from O2. These ML models can then be managed by non-RT RIC via A1-O2 to achieve near-RT optimization goals.

[0045] Figure 5 The drawings are incorporated into the above Figure 4 A more detailed system architecture diagram of the newly added interface described in . Figure 5As shown in , the disclosed technology includes a set of new O cloud RApps in non-RT RICs, labeled O cloud / RApps. Like the RRM functions, these applications are use case specific. For example, RApps can be designed to set resource goals for distributed O cloud / XApps, focusing on optimization aspects of O cloud infrastructure and network functions, including resource, recovery, infrastructure troubleshooting, and energy-saving optimization functions. As further shown, the disclosed technology also includes a set of applications located in near-RT RIC instances, labeled O cloud / XApps. As shown, O cloud / XApps receive policy goals from RApps and interface with local IMS / DMS functions to obtain near-RT data, and react in a programmatic manner to set configuration parameters to meet O cloud service goals. In addition, O cloud / RApps can be configured to interface with RRM / RApps in non-RT platforms, and O cloud / XApps can be configured to interface with RRM / XApps in near-RT platforms via APIs to affect changes in O cloud resources associated with RAN workloads or subscribe to data required for reliable operation of RAN workloads.

[0046] As will be appreciated, the O Cloud / RApp and O Cloud / XApp functions can utilize non-RT RIC and near RT platforms for data access, inter-XApp communications and utilize protocol termination functions such as O2 / A1 / E2 to achieve their own goals. In addition to RRM data, the database can also be configured to manage data from O Cloud physical, virtual or workload functions.

[0047] Figure 6 The drawings are incorporated into the above Figure 4 In the example of the present disclosure, the A1 interface is extended to identify a set of new APIs to set policies specific to the O cloud Xapp 610. For example, Figure 6As shown in , the A1-O2* interface 406 can allow interaction between the O cloud / RApp 612 and the O cloud / Xapp 610. As will be appreciated, the O cloud / XApp 610 exposes APIs to set localized O cloud center intentions that target a specific set of RAN workloads (DU and CU). These intentions or declarative rules can include threshold limits for parameters related to energy utilization or policy, CPU, memory, I / O or accelerator usage, timing / synchronization tolerable errors. As will be appreciated, the APIs are application specific. Therefore, depending on the O cloud optimization goals, they can include all or a subset of the previously mentioned policy goals for physical infrastructure, cluster services, virtual management systems, or specific RAN workloads. The O cloud / RApp uses these APIs to set policy goals in the O cloud / Xapp. Policy feedback (success or failure, or any intermediate state) via A1-O2*406 can be correlated with PM data via O2 616 to measure the success of the policy. A1-O2* 406 may also be provided with o-Cloud / X-App 610 enriched information, ie, external sources beyond what is available from the o-Cloud IMS / DMS sources.

[0048] In addition, the A1 / O2* interface 406 can also be used for ML model management executed as part of the O cloud / XApp. Data from the O cloud instance can be used by SMO and non-RT. For example, the RRM / Rapp function can coordinate with the corresponding O cloud / Rapp to achieve intent policy management, consistency or finalization.

[0049] like Figure 6 As further illustrated in FIG. 4 , the E2-O2* interface 408 can be configured to terminate at the O cloud 604 rather than at the RAN function (CU / DU). The IMS system 606 and the DMS system 608 expose service models that identify the PM / FM or control APIs exposed by the physical infrastructure, cluster, and network function management layers for both virtualized resources and managed workloads. These service models allow the O cloud / XApp 610 to subscribe to specific metrics, set triggers for notifications in the event of violations of certain thresholds, set policies for taking certain actions or waiting for the O cloud / Xapp 610 to trigger actions in the event of violations of certain conditions. The additional APIs previously described also apply to the newly described E2-O2* interface 408. For example, a new E2-SM interface can be implemented to handle O cloud function-specific use cases. Specific E2SM APIs (e.g., data, policy, control, etc. specific) can be configured based on specific use cases. As depicted, RRM Xapp 612 may interface with associated O-cloud Xapp 610 to coordinate O-cloud resource management functions, performance management (data subscriptions), alarm / fault notifications, and other related functions.

[0050] Figure 7 A subset of the O-RAN logical architecture is shown, where updates have been made to the O1 and O2 interfaces. As shown, the O1* interface 702 has been updated to manage the configuration and data subscription of the O-cloud Xapps, and the O2* interface 704 has been updated to manage the LCM of the O-cloud XApps. For example, the O1* interface 702 can manage the configuration and data subscription of the O-cloud / XApps and their service-centric lifecycle management, and the O2* interface 704 can manage the upload, deployment, startup, lifecycle and resource management of the O-cloud / XApps, taking into account that these XApps will also include ML reasoning O-cloud models that may require GPU resources. As will be appreciated, this configuration allows the O2 / O1 interface with the O-cloud Xapps to provide functionality similar to that of the RRM Xapp. As previously mentioned, this improvement will ensure high availability of RAN services.

[0051] Figure 8 A subset of the O-RAN logical architecture is depicted, with updates to the O1 and O2 interfaces. As will be appreciated, FOCOM 802 is the portion of SMO that manages the O-cloud physical and virtual infrastructure, and NFO 804 is the portion of SMO that manages the lifecycle of NF deployments. In the disclosed technology, O-cloud / RApp 806 can subscribe to data from FOCOM 802 and NFO 804 and apply policies and control actions via FOCOM 802 and NFO 804 over the O2 interface. FOCOM 802 in SMO manages the LCM of the O-cloud infrastructure and cluster instances, while NFO 804 manages the LCM of virtual network functions (VNFs) or containerized network functions (CNFs).

[0052] As an example, O cloud / RApp 806 manages policies and also includes logic for enforcing policies. In this case, depending on the policy requirements of the O cloud application, Rapp 806 will subscribe to relevant data via FOCOM 802 and NFO 804 through O2-ip interface 808 / o2-im interface 810, and perform control actions through the interfaces in the event of a violation of the policy requirements. Depending on whether the actions are actions on physical infrastructure or actions related to NF management actions, these actions are notified to FOCOM 802 and NFO 804. In this case, the control applications in FOCOM 802 and NFO 804 map these actions via the O2 interface.

[0053] As another example, FOCOM 802 and NFO 804 may also include logic for managing policies and invoking control actions. In this scenario, the policy management application in O cloud / Rapp 806 will transmit policy requirements to FOCOM 802 and NFO 804 via O2-ip interface 808 / o2-im interface 810. The control application in FOCOM 802 and NFO 804 will subscribe to relevant data from O cloud and invoke control actions via O2 interface when any policy is violated. Policy management in FOCOM 802 / NFO 804 can then notify O cloud / Rapp 806 of the status (success or failure) of the requested policy.

[0054] The disclosed technology can be used to solve various use case scenarios. For example, a typical use case may be a transient congestion scenario that occurs in a stadium, airport, shopping mall, or dense urban environment. During a transient congestion scenario, a specific geographic location will experience a significant increase in network traffic, resulting in congestion in a group of adjacent RAN cell sites managed by the same DU. In addition, typically the relevant CU will eventually notice the traffic surge. In a traditional system, the RAN XApp will react to this via traffic manipulation, which involves balancing the traffic load between cells. As will be appreciated, this may not work in this scenario because the adjacent cells are also highly loaded.

[0055] The disclosed technology can be used to instantiate O cloud / X-App with necessary policy goals a priori to monitor DU and CU resource requirements, and make O cloud / X-App request to increase the computing, memory or accelerator resources of the DMS system to provide more resources for DUs and CUs handling additional loads, or reduce computing, memory or accelerator resources to save energy at each O cloud site. This request can be triggered via an API exposed by O cloud / X-App to request in / out scaling of resources to RRM / XApp that can be called at a near RT time scale. Fig. 9 A data flow diagram 900 is shown for this example scenario. As shown, the transactions shown in red represent interactions implemented by the described technology. As will be appreciated, while the overall flow is the same for most use case scenarios, the details of the policy sets, data subscriptions, and control call APIs in O Cloud / RApp and O Cloud / XApp will be different.

[0056] As shown, in step (1), SMO 902 uses the O2-ims interface to provision the O cloud instance on which the RAN workload will be hosted. In step (2), SMO 902 provisions the RAN workload, namely DU, CU-UP 910 and CU-CP. In step (3), SMO 902 provisions O cloud / Rapp 904 and RRM / RApp for controlling and managing the RAN workload. In step (4), SMO 902 also provisions O cloud / XApp 904 and RRM / Xapp 908 for near-RT optimization and control of the services hosted in the RAN workload. In step (5), O cloud / Xapp 906 registers with O cloud / Rapp 904 so that it can be discovered in the FE or edge.

[0057] As further illustrated, in step (6), O cloud / RApp 904 sets policies in O cloud / XApp 906 to monitor O cloud resources dedicated to RAN workloads. In this scenario, it must identify the O cloud ID and, for each O cloud instance, uniquely identify the set of DU and CU-UP 910 instances in the context of the DMS instance. For each virtualized workload, O cloud / RApp 904 sets thresholds for parameters related to the RAN workload (such as power / energy, compute, memory, I / O or accelerator resources). The thresholds can be statistical metrics such as averages, maximum / minimum values, variances of a particular PM measured for a particular workload or for the host itself from an overall perspective. In addition, in steps (7) and (8), based on policy requirements, O cloud / Xapp 906 subscribes to PM / FM metrics via the IMS function 914 / DMS function 916 that manages the O cloud and RAN workloads. In addition, it is assumed that RRM / XApp 908 has been configured with policies and subscribes to PM / FM data from the RAN workload.

[0058] In step (9), there is a notification from DU / CU 910 to RRM / Xapp 908 with metrics indicating this situation. As will be appreciated, such notification occurs during an ongoing transient congestion scenario in a cell served by a group of DUs or CUs under an O cloud instance managed by O cloud / Xapp 906. In step (10), RRM / XApp 908 and O cloud / Xapp 906 under the same near RT instance use the API exposed by O cloud / XApp 906 to increase the underlying O cloud resources to these RAN workloads. In step (11), O cloud / XApp 906 then calls the appropriate control API of the DMS to increase the computing, memory, I / O or accelerator resources for those RAN workloads that manage a group of cells where transient congestion is observed. In step (12), O cloud / XApp 906 confirms that the request to RRM / Xapp 908 was successfully completed. Finally, in step (13), the RRM / Xapp 908 then configures the CU / DU 910 / RU 912 to operate with more spectrum resources, thereby taking advantage of the additional O-cloud resources now available to the vRAN workload.

[0059] Each of the server devices of the network traffic management system in this example includes (multiple) processors, memory, and communication interfaces coupled together by a bus or other communication link, but other numbers or types of components may also be used. The server devices in this example may include, for example, application servers, database servers, access control servers, or encryption servers, which exchange communications along communication paths expected based on application logic to facilitate interaction between users of client devices and applications.

[0060] Although the server devices are shown as a single device, one or more actions of each of the server devices may be distributed across one or more different network computing devices that together constitute one or more of the server devices. Furthermore, the server devices are not limited to a particular configuration. Thus, the server devices may contain network computing devices that operate using a master / slave approach, whereby one of the network computing devices of the server device operates to manage or otherwise coordinate the operations of the other network computing devices. The server devices may operate as multiple network computing devices within, for example, a cluster architecture, a peer-to-peer architecture, within a virtual machine, or within a cloud architecture.

[0061] Therefore, the techniques disclosed herein should not be construed as limited to a single environment, and other configurations and architectures are also contemplated. For example, one or more of the server devices may operate within the network traffic management device itself, rather than as a separate server device that communicates with the network traffic management device via a communications network. In this example, one or more of the server devices operate within the memory of the network traffic management device.

[0062] The client devices of the network traffic management system in this example include any type of computing device that can exchange network data, such as a mobile, desktop, laptop or tablet computing device, a virtual machine (including a cloud-based computer), or the like. Each of the client devices in this example includes a processor, a memory, and a communication interface, which are coupled together by a bus or other communication link (not shown), but other numbers or types of components may also be used.

[0063] The client device may run an interface application, such as a standard web browser or a stand-alone client application, which may provide an interface for making requests to one or more of the server devices via a communication network and receiving content stored on one or more of the server devices. The client device may also include a display device, such as a display screen or a touch screen, or an input device, such as a keyboard (not shown). In addition, one or more of the client devices may be configured to execute software code (e.g., JavaScript code within a web browser) to record client-side data and provide the recorded data to the network traffic management device, as will be described and shown in more detail later.

[0064] Although an exemplary network traffic management system having a network traffic management device, a server device, a client device, and a communication network is described and shown herein, other types or numbers of systems, devices, components, or elements in other topologies may be used. It will be understood that the example systems described herein are for exemplary purposes, as many variations of the specific hardware and software used to implement the examples are possible, as will be appreciated by those skilled in the relevant art.

[0065] One or more of the components depicted in the network security system (such as a network traffic management device, a server device, or a client device) can be configured to operate as a virtual instance on the same physical machine. In other words, one or more of the network traffic management device, the server device, or the client device can operate on the same physical device rather than as separate devices communicating via a communication network. In addition, there may be more than one physical device. Figure 1 More or fewer network traffic management devices, client devices, or server devices are shown.

[0066] In addition, two or more computing systems or devices may replace any one of the systems or devices in any example. Therefore, the principles and advantages of distributed processing, such as redundancy and replication, may also be implemented as needed to improve the robustness and performance of the devices and systems of the examples. The examples may also be implemented on a computer system that extends across any suitable network using any suitable interface mechanism and traffic technology, including, by way of example only, wireless traffic networks, cellular traffic networks, packet data networks (PDNs), the Internet, internal networks, and combinations thereof.

[0067] For one or more aspects of the present technology, the examples may also be embodied as one or more non-transitory computer-readable media having instructions stored thereon (e.g., in a memory), as described and illustrated herein by way of example. The instructions in some examples include executable code that, when executed by one or more processors such as a processor, causes the processor to perform the steps necessary to implement the methods of the examples of the present technology described and illustrated herein.

[0068] Having thus described the basic concepts of the present invention, it will be apparent to those skilled in the art that the foregoing detailed disclosure is intended to be presented only by way of example and is not restrictive. It will be appreciated and anticipated by those skilled in the art that various changes, improvements and modifications may be made, although not expressly stated herein. These changes, improvements and modifications are intended to be hereby proposed, and are within the spirit and scope of the present invention. In addition, except as may be specified in the claims, the enumerated order of processing elements or sequences, or the use of numbers, letters or other designations thereof, is not intended to limit the claimed program to any order. Therefore, the present invention is limited only by the appended claims and their equivalents.

Claims

1. An O-RAN optimization method implemented in cooperation with a network system including one or more network infrastructure devices, server devices or client devices, the method comprising: receiving, via an interface between the O-cloud orchestrator and a near real-time RAN intelligent controller ("near-RT RIC"), policies regarding O-cloud workload optimization; Determine that one or more strategic scenarios have occurred; subscribing, via one or more XApps on the near-RT RIC, to data associated with the policy regarding O-cloud workload optimization; transmitting one or more corrective action instructions from the near-RT RIC to the O-cloud; executing, via the control application on the O-cloud, one or more corrective actions consistent with the received instructions; and A confirmation of the execution of the one or more corrective actions is transmitted from one or more Xapps on the O cloud.

2. The method of claim 1, wherein the Xapp on the near-RT RIC is configured to receive data from the O-cloud and from external sources.

3. The method of claim 1, wherein a Xapp of the one or more XApps is configured to monitor utilization of a cell associated with a DU and interface with other O-cloud resources to dynamically scale resources in response to detected traffic.

4. The method of claim 1, wherein the one or more XApps comprise a plurality of XApps operably linked to perform coordinated operations.

5. The method of claim 4, wherein the one or more XApps are configured to interface with the IMS and DMS of the O cloud to perform resource management functions.

6. A Near Real-Time RAN Intelligent Controller ("Near RT RIC") device configured for use in an Open Radio Access Network ("ORAN"), the Near RT RIC device comprising: a memory including programmed instructions stored thereon; and one or more processors configured to be capable of executing the stored programmed instructions to: receiving a policy regarding O-cloud workload optimization via an interface between a non-real-time RAN intelligent controller ("non-RT RIC") in the O-cloud orchestrator and the near-RT RIC; Determine that one or more strategic scenarios have occurred; subscribing, via one or more XApps on the near-RT RIC, to data associated with the policy regarding O-cloud workload optimization; transmitting one or more corrective action instructions from the near-RT RIC to the O-cloud; Receiving confirmation of execution of the one or more corrective actions from one or more Xapps on the O-cloud; as well as Data received from the O-cloud is analyzed to verify that corrective action has occurred.

7. The near-RT RIC device of claim 6, wherein the Xapp on the O cloud is configured to receive data from the O cloud and from external sources.

8. The near-RT RIC device of claim 6, wherein a Xapp of the one or more XApps is configured to monitor utilization of a cell associated with a DU and interface with other O-cloud resources to dynamically scale resources in response to detected traffic.

9. The near-RT RIC device of claim 6, wherein the one or more XApps comprise a plurality of XApps operably linked to perform coordinated operations.

10. The near-RT RIC device of claim 9, wherein the one or more XApps are configured to interface with the IMS and DMS of the O cloud to perform resource management functions.

11. A non-transitory computer readable medium having stored thereon instructions comprising executable code which, when executed by one or more processors, causes the processors to: receiving, via an interface between the O-cloud orchestrator and a near real-time RAN intelligent controller ("near-RT RIC"), policies regarding O-cloud workload optimization; Determine that one or more strategic scenarios have occurred; subscribing, via one or more XApps on the near-RT RIC, to data associated with the policy regarding O-cloud workload optimization; transmitting one or more corrective action instructions from the near-RT RIC to the O-cloud; executing, via the control application on the O-cloud, one or more corrective actions consistent with the received instructions; and A confirmation of the execution of the one or more corrective actions is transmitted from one or more Xapps on the O cloud.

12. The non-transitory computer-readable medium of claim 11, wherein the Xapp on the O cloud is configured to receive data from the O cloud and from external sources.

13. The non-transitory computer-readable medium of claim 12, wherein an Xapp of the one or more XApps is configured to monitor utilization of a cell associated with a DU and interface with other O-cloud resources to dynamically scale resources in response to detected traffic.

14. The non-transitory computer-readable medium of claim 11, wherein the one or more XApps comprise a plurality of XApps operably linked to perform coordinated operations.

15. The non-transitory computer-readable medium of claim 14, wherein the one or more XApps are configured to interface with an IMS and a DMS of the O cloud to perform resource management functions.

16. A radio access network system, the radio access network system comprising one or more network management devices, a server device or a client device, a memory and one or more processors, the memory comprising program control instructions stored thereon, the one or more processors being configured to be able to execute the stored program control instructions to: receiving a policy regarding O-cloud workload optimization via an interface between the O-cloud orchestrator and the near real-time RAN intelligent controller; Determine that one or more strategic scenarios have occurred; transmitting one or more corrective action instructions from the near real-time RAN intelligent controller to the O cloud; executing, via one or more XApps on the O cloud, one or more corrective actions consistent with the received instructions; and A confirmation of the execution of the one or more corrective actions is transmitted from the one or more Xapps on the O cloud. Creates a bridge between multiple hypervisors that locally connect compute subdomains.

17. The radio access network system of claim 16, wherein the Xapp on the O cloud is configured to receive data from the O cloud and from an external source.

18. The radio access network system of claim 16, wherein a Xapp of the one or more XApps is configured to monitor utilization of a cell associated with a DU and interface with other O-cloud resources to dynamically scale resources in response to detected traffic.

19. The radio access network system of claim 16, wherein the one or more XApps include a plurality of XApps operably linked to perform coordinated operations.

20. The radio access network system of claim 16, wherein the one or more XApps are configured to interface with an IMS and a DMS of the O cloud to perform a resource management function.

Images