Real-time RAN Intelligent Controller Architecture

Abstract

The Open Radio Access Network (O-RAN) may include an O-RAN Centralized Unit (O-CU), at least one O-RAN Distributed Unit (O-DU), at least one O-RAN Radio Unit (O-RU), and a Real-Time (RT) RAN Intelligent Controller (RIC) connected to the at least O-DU and configured to host at least one application for controlling the at least one O-DU via a real-time control loop with a latency of less than 10 ms. The O-RAN wireless system may include a Non-RT (Non-RT) RIC configured to manage resources and events with a latency of 1 second or more, and a Near-RT RIC configured to manage resources and events with a latency of 10 ms to 1 second. Further, the O-RAN may include a Service Management and Orchestrator (SMO) platform, and the RT RIC is connected to at least one of the SMO, the Non-RT RIC, the Near-RT RIC, the RAN network elements, and the O-RU.

Description

[Technical field]

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS This application claims priority to U.S. Provisional Patent Application No. 63 / 325886, filed March 31, 2022, and International Application No. PCT / US2022 / 025868, filed April 22, 2022, the entire contents of each of which are fully incorporated by reference herein.

[0002] In certain example embodiments, the subject matter herein relates generally to Radio Access Network (RAN) (O-RAN) wireless communications, and more particularly, to Open Radio Access Networks (O-RAN) and RAN Intelligent Controllers (RIC). [Background technology]

[0003] The RAN is part of a wireless communication system. The RAN implements a radio access technology (RAT) that resides between end users and the core network (CN) of the wireless communication system. The RAN includes a combination of various network elements that connect the end users to the CN. Traditionally, the hardware and software elements of a given RAN are vendor-specific.

[0004] O-RAN technology has emerged to enable open RAN architectures, which are intended to improve competition, network flexibility, and costs. The main objective of O-RAN is to create a multi-vendor solution that separates or disaggregates RAN functions between hardware and software platforms with open interfaces and virtualization.

[0005] Thus, O-RAN decomposes RAN functions into Centralized Units (CU), Distributed Units (DU), and Radio Units (RU). The CU is a logical node for hosting the Radio Resource Control (RRC), Service Data Adaption Protocol (SDAP), and / or Packet Data Convergence Protocol (PDCP) sublayers of the RAN. The DU is a logical node hosting the Radio Link Control (RLC), Medium Access Control (MAC), and Physical (PHY) sublayers of the RAN. The RU is a physical node that converts the radio signals to be transmitted and received into digital signals that are transmitted and received over the fronthaul to the DU. In O-RAN, these RAN functions / elements have open protocols and interfaces and can therefore be provided by different vendors.

[0006] The RAN functions in the O-RAN architecture are controlled by the RAN Intelligent Controller (RIC), which is a software-defined building block of the O-RAN architecture. The RIC enables onboarding of third-party applications that automate and optimize RAN operations at scale while supporting innovative use cases.

[0007] In the current O-RAN architecture, RICs are divided into two types: Non-real-time RICs (Non-RT RICs) and Near-real-time RICs (Near-RT RICs). In general, Non-RT RICs provide policies, data, and artificial intelligence (AI) models that are enforced and used by Near-RT RICs to perform RAN optimization.

[0008] The Non-RT RIC is the control point of a non-real-time control loop and operates on time scales greater than 1 second within the Service Management Orchestration (SMO) framework. The Near-RT RIC operates on time scales between 10 ms and 1 second and connects to the O-DU, O-CU, and Open evolved NodeB (O-eNB). Therefore, the minimum latency between the Near-RT RIC and the connecting node is 10 ms.

[0009] High latency loops, e.g., 10 ms or more, preclude the use of AI models and multi-vendor intelligent management and control for real-time operation. Thus, there is a need for a real-time (RT) RIC to perform O-RAN intelligent management in real time. Summary of the Invention

[0010] In one general aspect, an apparatus is provided that executes a real-time (RT) radio interface controller (RIC). The apparatus that executes the RT RIC may include a memory configured to store a plurality of instructions. The apparatus may also include a processor circuit coupled to the memory and configured to execute the plurality of instructions to host at least one application that connects to at least one O-RAN distributed unit (O-DU) via an interface and controls the at least one O-DU via a real-time control loop with a latency of less than 10 milliseconds (ms) via the interface. Other embodiments of this aspect include corresponding computer systems, apparatus, and computer programs recorded on one or more computer storage devices, each configured to execute the actions of the apparatus that executes the RT RIC.

[0011] Implementations may include one or more of the following features: A device in which the RT RIC is co-located with at least one O-DU. A device in which the RT RIC is external to at least one O-DU. A device in which the RT RIC is connected to a Fronthaul Multiplexer (FHM). A device running a RT RIC, where the RT RIC is connected to a Service Management and Orchestration (SMO) platform via a first interface, to a Non-RT RIC via a second interface, to a Near-RT RIC via a third interface, to network elements via a fourth interface, and to an O-RAN Radio Unit (O-RU) via a fifth interface, where the RT RIC is connected to the SMO, Non-RT, Near-RT, network elements, and O-RU, singly or in any combination. The apparatus may further have a plurality of open application programming interfaces (APIs), each of which hosts at least one application that enables communication with at least one of the plurality of sub-modules of the RT RIC via a messaging infrastructure circuit. The apparatus, in which the plurality of sub-modules of the RT RIC include at least one of a contention management circuit, a subscription management circuit, a security circuit, an artificial intelligence (AI) model, a sensor management circuit, a hardware circuit, a data publishing circuit, and a shared data lake. The apparatus, in which the shared data lake is part of an information architecture (IA) of the AI ​​model. The AI ​​module may be based on machine learning and deep learning techniques. The apparatus, in which the RT RIC is configured to connect with the primary O-DU and the secondary O-DU when performing carrier aggregation. Implementations of the described techniques may include hardware, methods or processes, or computer tangible media.

[0012] In another general aspect, an Open Radio Access Network (O-RAN) wireless communication system is provided. The O-RAN wireless communication system may include an O-RAN centralized unit (O-CU), at least one O-RAN distributed unit (O-DU), at least an O-RAN radio unit (O-RU), and a real-time (RT) RAN intelligent controller (RIC) connected to the at least O-DU via an interface and configured to host at least one application for controlling the at least one O-DU via a real-time control loop with a latency of less than 10 ms. The O-RAN wireless communication system may further include a Non-RT (Non-RT) RIC configured to manage resources and events having a latency of 1 second or more, a Near-RT RIC configured to manage resources and events having a latency of 10 ms to 1 second, and a Service Management and Orchestrator (SMO) platform, where the RT RIC is connected to the SMO via a first interface, the Non-RT RIC via a second interface, the Near-RT RIC via a third interface, the RAN network elements via a fourth interface, and the O-RU fifth interface.

[0013] Implementations of the O-RAN wireless communication system may include one or more of the following features: An O-RAN wireless communication system in which a RT RIC is co-located with at least one O-DU; An O-RAN wireless communication system in which a RT RIC is external to at least one O-DU; An O-RAN wireless communication system in which a RT RIC is connected with a Fronthaul Multiplexer (FHM); An O-RAN wireless communication system in which a RT RIC is configured with a plurality of open Application Programming Interfaces (APIs), each of the plurality of open APIs hosting at least one application enabling communication with at least one of a plurality of sub-modules of the RT RIC via a messaging infrastructure circuit; An O-RAN wireless communication system in which a plurality of sub-modules of the RT RIC include at least one of a contention management circuit, a subscription management circuit, a security circuit, an artificial intelligence (AI) model, a sensor management circuit, a hardware circuit, a data publishing circuit, and a shared data lake; An O-RAN wireless communication system in which a shared data lake is part of an information architecture (IA) of an AI model. An O-RAN wireless communication system, in which a RT RIC is configured to connect with a primary O-DU and a secondary O-DU when performing carrier aggregation. Implementations of the described technologies may include hardware, a method or process, or a computer tangible medium.

[0014] In another general aspect, a method is provided for executing a real-time (RT) radio interface controller (RIC) in an open radio access network (O-RAN). The method can include connecting the RT RIC to at least one O-RAN distributed unit (O-DU) via an interface. The method can also include hosting, by the RT RIC, at least one application that controls the at least one O-DU via a real-time control loop with a latency of less than 10 ms via the interface.

[0015] Implementations of the method may include one or more of the following features: The method may further include communicating with each of the plurality of sub-modules of the RT RIC by at least one of a plurality of open application programming interfaces (APIs), each of the plurality of open APIs hosting at least one application that enables communication with at least one of the plurality of sub-modules of the RT RIC via a messaging infrastructure, and the plurality of sub-modules of the RT RIC including at least one of a contention management circuit, a subscription management circuit, a security circuit, an artificial intelligence (AI) model, a sensor management circuit, a hardware circuit, a data publishing circuit, and a shared data lake.

[0016] The description will be given with reference to the drawings. [Brief description of the drawings]

[0017] [Figure 1] FIG. 2 illustrates a general architecture in which a RT RIC is interfaced with two or more O-DUs according to an exemplary embodiment.

[0018] [Diagram 2] FIG. 2 illustrates a general architecture in which a RT RIC is interfaced with two or more O-DUs according to an exemplary embodiment.

[0019] [Diagram 3] 2 is a block diagram of a RT RIC in accordance with one or more exemplary embodiments.

[0020] [Figure 4] FIG. 1 illustrates an architecture of a RT RIC with RAN microservices according to an exemplary embodiment.

[0021] [Diagram 5] A diagram showing an architecture in which the RT RIC is hosted on the vDU along with other RAN microservices.

[0022] [Figure 6] FIG. 1 illustrates a configuration with a primary O-DU and a secondary O-DU for a carrier aggregation use case.

[0023] [Figure 7] FIG. 1 is a logical diagram of a cell site consisting of multiple O-DUs, O-RUs, cabinets, and sensors. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0024] 1 shows a general architecture of a RT RIC (102) with an interface with two or more physically co-located O-DUs (104), where the RT RIC (102) may be hosted on any one of the O-DUs (104) or on an external unit. The RT RIC (102) may be implemented in the same processor (e.g., CPU, GPU, or any hardware accelerator) as the O-DU (104), or in a different processor in the same motherboard, or on a different motherboard in the same enclosure, or on a separate enclosure in the same rack, or on a separate rack in the same data center, or on a separate unit. The DU (104) may establish communication with one or more RUs (108) via the FHM (106).

[0025] FIG. 2 illustrates a general architecture of a RT RIC (102) that interfaces with two or more physically co-located FHMs (106). Each FHM can be connected to or integrated with one or more DUs (104). In this architecture, the RT RIC may be implemented in the same processor (e.g., CPU, GPU, or any hardware accelerator) as the FHM, or in a different processor in the same motherboard, or in a different motherboard in the same enclosure, or in a separate enclosure in the same rack, or in a separate rack in the same data center. The FHM may be configured to aggregate data or control information (e.g., SRS signals) between one or more O-RUs and the RT RIC.

[0026] 3 is a block diagram of a RT RIC according to one or more exemplary embodiments. The RT RIC 302 may include a first interface (labeled K1 interface, as a non-limiting example) that connects the RT RIC 302 to the SMO 304. The first interface may be an operation and maintenance interface that is performed over a standard or proprietary interface using the Network Configuration Protocol (NETCONF) or any other network management protocol. In one embodiment, the network management protocol is used to provision management services to create managed object instances, delete managed object instances, modify managed object instance attributes, and / or read managed object instance attributes. In another embodiment, the first interface performs at least one of a number of services including fault monitoring management, performance assurance management, trace management, file management, heartbeat management, physical network function (PNF) startup and registration management, and / or PNF software management. In another embodiment, the K1 interface includes reporting performance management (PM) counters or fault management (FM) alarms from the RT RIC 302 to the SMO 304.

[0027] The RT RIC 302 may include a second interface, labeled as a K2 interface as a non-limiting example, that connects the RT RIC 302 to the Non-RT RIC 306. The second interface enables the Non-RT RIC 306 to provide policy-based guidance, machine learning (ML) model management, and enrichment information to the RT RIC 302 to optimize the RAN. In one embodiment, the protocol stack of the second interface includes one or more layers, such as Internet Protocol (IP), Transmission Control Protocol (TCP), Hypertext Transfer Protocol Secure (HTTPS), JavaScript Object Notation (JSON), and / or any other proprietary or standard layers.

[0028] The RT RIC 302 may include a third interface, labeled as a K3 interface, as a non-limiting example, that connects the RT RIC 302 to the Near-RT RIC 308. The third interface allows the Near-RT RIC 308 to provide policy-based guidance, ML model management, and enrichment information to the RT RIC 302 to optimize the RAN. In one embodiment, the protocol stack of the third interface may include at least one of multiple layers, including IP, TCP, HTTPS, JSON, and / or any other proprietary or standard layers. In another embodiment, the K3 interface is modeled as an O-RAN standard-compliant E2 interface (i.e., E2AP over SCTP). The Near-RT RIC 308 connects to the O-CU 314 and the O-DU 310 via the E2 interface, as a non-limiting example.

[0029] Additionally, as a non-limiting example, the Near-RT RIC 308 connects to the SMO 302 via an O1 interface and to the Non-RT RIC 306 via an A1 interface.

[0030] A fourth interface (labeled as a K4 interface, as a non-limiting example) connects the RT RIC 302 to a logical network element 310. Those skilled in the art will appreciate that the logical network element shown in FIG. 3 is an O-DU 310, and that the RT RIC 302 may be logically connected to at least one of multiple network elements including at least one of an O-DU, an O-CU-CP, an O-CU-UP, or an O-eNB.

[0031] The fourth interface enables different services (eg, reporting, insertion, control, and policy) and support functions (eg, interface management, service updates, etc.) of the RT RIC 302.

[0032] The RT RIC 302 may include a fifth interface, labeled as a K5 interface, by way of non-limiting example, that connects to the O-RU 312. The fifth interface is a direct logical channel or interface used to exchange data and / or control information between the RT RIC 302 and at least one of the O-RUs 312 by implementing the control, user, and synchronization planes.

[0033] 4 is a block diagram of an architecture of a RT RIC 302 with RAN microservices, according to an example embodiment. The open API 402 shown in FIG. 4 refers to a set of APIs exposed by the RT RIC 302 platform using zApps 404 that can interact with and obtain services from the RT RIC 302. The zApps 404 can be viewed as similar to rApps that can be implemented in a Non-RT RIC and xApps that can be implemented in a Near-RT RIC, except that a zApp is a RT RIC application.

[0034] Referring to FIG. 3, it can be seen that the RT RIC 302 includes connections terminating at the SMO 304 (K1 termination), the Non-RT RIC (K2 termination), the Near-RT RIC 308 (K3 termination), the network element (K4 termination), and the O-RU 312 (K5 termination).

[0035] The messaging infrastructure 406 is a messaging framework that allows zApps 404 to communicate with internal sub-modules of the RT RIC 302, possibly implemented in multiple ways.

[0036] The conflict management sub-module 408 refers to a component that resolves conflicts caused by different requests initiated by different zApps. The conflicts can be partial or complete. While resolving the conflicts, the conflict management module 408 can contact the z subscription management module 410 and can utilize subscription and priority information while resolving the conflicts.

[0037] The subscription management sub-module 410 stores subscription time information while the zApp 404 is onboarded, and the subscription information may include, but is not limited to, maintaining open API access permissions (application priority).

[0038] The security submodule 412 ensures the security and stability of the RT RIC, and requires that third-party zApps 404 comply with a security framework enabled on the RT RIC, which enables data protection and enables zero-trust provisioning for any onboarded zApps 404;

[0039] The AI / ML 414 engine sub-module processes the data present in the shared data lake 420 and creates policies / configurations much faster. It is understood that the AI ​​engine 414 may include machine learning (ML) and / or deep learning techniques. The shared data lake 420 is part of the information architecture (IA) of the AI ​​models.

[0040] ML can work in two phases: training and inference. In the training phase, data is fed to the model so that it can learn everything it can about the type of data being analyzed. In the inference phase, the model can make predictions based on real-time data and generate actionable results. In deep learning, deep neural networks (DNNs) can analyze a dataset to learn how to make predictions about the data. Deep learning relies on feedback so that the system learns from incorrect conclusions.

[0041] The data publishing sub-module 422, sometimes referred to as a service, controls and ensures the publishing of data to applications, e.g., zAPPs. Some data coming from the O-RU (K5 termination 312) may be published / accessed by a single application or a high priority application, even if the low priority application has access permissions that this data may not be accessible to it until a higher priority application is registered. The data publishing sub-module 422 may control this access. Additionally, the data publishing sub-module 422 may control how long the RT RIC 302 must store a particular data set, and the data publishing sub-module 422 may implement data sharing techniques, e.g., push and pull operations.

[0042] The Sensor Management, sub-module 416 gets input from all the sensors present at the cell site, which can be cabinet temperature, wind load, antenna tilt, clutter imagery, etc.

[0043] The hardware management sub-module 424 can obtain information from the hardware present at the cell site, which may include average / peak CPU / memory utilization of the fronthaul interfaces, average / peak utilization, etc. API extensions may be performed via the API extension module 426.

[0044] Figure 5 shows an architecture in which the RT RIC is hosted on a virtual DU (vDU) 502 along with other RAN microservices 504. The vDU can run in a cloud native architecture. It may run as a K8s node. A K8s node may also be referred to as a Kubernetes node, which provides a logical collection or grouping of nodes that run containerized applications. The functions of the microservices 504 may include control and data plane functions, as well as baseband functions.

[0045] Greenfield 5G networks can be deployed on a 5G network core, referred to as a standalone architecture (SA). However, the transition from 4G to 5G requires overlaying a new 5G RAN on top of an existing 4G LTE network core, referred to as a non-standalone architecture (NSA).

[0046] The network deployed in NSA can be upgraded to a 5G SA network by performing a software upgrade to the 4G O-DU. To perform carrier aggregation from the co-located O-DU, real-time coordination between the O-DUs is required.

[0047] FIG. 6 shows a RT RIC 602 connected to a primary O-DU 606, which is the O-DU responsible for traffic aggregation, and a secondary O-DU 608, which shares secondary carrier data with the primary O-DU for carrier aggregation. The RLC is fixed to one of the DUs, since the UE mobile device is associated with only one RLC. In one embodiment, the RLC of the primary O-DU 606 has real-time communication with the MAC of the secondary O-DU 608. In another embodiment, a shared memory is used to hold the RLC buffer across the two O-DUs. In one embodiment, the two DUs may be on the same compute or non-uniform memory access (NUMA) node and share memory. In another embodiment, the two DUs are on separate machines and use distributed shared memory that synchronizes with sub-transmission time interval (TTI) real-time granularity and avoids memory contention. The RT RIC 602 and / or zApp host the RLC itself. The CU-UP 604 then sends the downlink packets directly to the zApp. The RLC buffer in the zApp then decides which cell's MAC to send the packet to (i.e., primary O-DU vs. secondary O-DU) and which O-DU to activate via the MAC and data path 614. The data path 614 provides connectivity between the O-CU 604, the primary O-DU 606, the secondary O-DU 608, the O-RU 610, and the O-RU 612.

[0048] Carrier aggregation may be performed on any combination of TDD and / or FDD carriers based on currently existing / present technology in the relevant standards. Additionally, the carrier aggregation application hosted on the RT RIC 602 may collect data on delays caused by MAC entities operating on physically separate O-DUs. The zApp hosted on the RT RIC 602 may determine the MAC entity to perform carrier aggregation on, and the decision may be based on observed delays, current configured scheduler policies, channel conditions, buffer status in the RLC of the associated carriers, and bearer priorities.

[0049] The zApp running on the RT RIC 602 can configure the MAC scheduler running on the primary O-DU 606 to minimize the impact of latency due to physical separation of the O-DUs, and this approach includes at least one of the following: a) Scheduling data on the secondary carrier in advance to minimize the impact of delays caused by the physical separation of the O-DUs; b) Optimization of the HARQ configuration to minimize the impact of delay due to physical separation of the O-DUs; and c) predicting HARQ process results on the secondary carrier based on channel conditions and / or delays;

[0050] The above processes can be implemented alone or in any combination according to the zApp. These zApp configurations form the RT-RIC 602 policies of the O-DU (606 and / or 608) and / or O-RU (610 and / or 612). The RT RIC 602 policies for carrier aggregation can be different for different carriers based on the quality of service and network slice configuration.

[0051] The coverage and capacity requirements for each operator can vary significantly, and in a typical NSA deployment, the LTE layer (typically FDD) can act as the coverage layer while the 5G layer provides the capacity, and when upgrading their networks to SA architecture, some operators may want to not compromise the experience even after migrating to SA architecture by performing carrier aggregation, which requires updating schedulers with resource allocation policies, changing fairness attributes, and other configurations.

[0052] In the event of conflicting configurations in the O-DU from the Near RT RIC and the O-DU from the RT RIC, the configuration from the RT RIC 602 may take precedence. Additionally, the RT RIC 602 may store configurations / policies from the Near-RT RIC and / or the Non-RT RIC to reduce conflicts.

[0053] In a carrier aggregation use case where each carrier runs on a physically separate O-DU, the zApp running on the RT RIC 602 can be responsible for at least the following operations: a) In the absence of zApp, carrier aggregation works as described in the prior art; b) The RT RIC 602 can enable the zApp to obtain configuration information from a Near-RT RIC, a Non-RT RIC, an SMO and / or the O-DU itself, which makes the RT RIC 602 aware of the current configuration policy. c) In the event of a configuration conflict at the O-DU (606 and 608) from the configuration received from the RT RIC 602 and the Near-RT RIC, the configuration from the RT RIC 602 takes precedence. In general, the likelihood of this conflict may be low because the RT RIC 602 operates in a real-time loop and may operate primarily with MAC / PHY layer configuration. d) The zApp responsible for carrier aggregation configures the O-DU with policies related to coverage and capacity expansion, taking into account delays that may be caused due to the physically separate O-DUs (606 / 608) in which the primary and secondary carriers operate. The RT RIC 602 can enable configuration to the MAC, MAC scheduler, and other components operating in the O-DU (606 / 608).

[0054] In one embodiment, the zApp manages the RLC buffers, hi another embodiment, the primary O-DU 606 manages the RLD buffers.

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

[0056] After the telephone was transformed into a smartphone, a similar transformation is now being seen on the network side, with improved cell site intelligence, powered by cell site present HW sensors to monitor aspects related to temperature, humidity, wind load, tower load, camera clutter image capture, cabling imagery, etc. Some of this information requires real-time response.

[0057] 7 shows a logical diagram of a cell site. The cell site 704 may consist of multiple O-DUs 706, an O-RU 708, a cabinet 710, multiple sensors 712, a fronthaul (FH) gateway / switch 714, and a GPS 716.

[0058] In one aspect, the RT RIC 702 can measure the current loads faced by the components of the cell site 704, including wind loads. When the current loads faced by various components of the cell site 704 approach the load capacity of the tower or other components of the cell site 704, the zApp hosted on the RT RIC 702 can take preventative measures to avoid damage or reduce temporary distortion faced by the components of the cell site 704. Furthermore, if this phenomenon occurs frequently at any particular site, the RT RIC 702 can pass recommendations to an Operational Support System (OSS) / Business Support System (BSS) module. Scenarios where real-time responses from the RT RIC 704 can be very important are the following: a) Site Load Sudden Increase: i) Solutions include reducing wind loads by changing antenna tilt and / or orientation. Further, in these solutions, the RT RIC 702 / zApp may already have site / tower load capacity information that can be determined at the time of installation of the cell site 704, and the zApp hosted on the RT RIC 702 can calculate the current capacity of the site using AI / ML techniques and the current age of the site; ii) In addition to the above solutions, when the current load of the site approaches the capacity of the cell site 704, the AI / ML algorithm zApp hosted in the RT RIC 702 can calculate effective changes in the tilt and orientation of the antenna / O-RU 708 that will have minimal impact on the user experience while the current load of the site is reduced; and iii) The above thresholds may vary and are based on the antenna panel size and massive MIMO (mMIMO) configuration. b) Cabinet temperature rise: i) The solution involves reducing the CPU processing load to prevent system failure. One of the zApps hosted on the RT RIC 702 can monitor the current state of temperature, CPU configuration, and load on each CPU. ii) The solution further includes an analysis of the reduction in CPU load on decreasing temperature along with the impact of the reduction in CPU load on the system performance including the data. AI / ML algorithms hosted on the RT RIC 702 can help the zApp calculate this correlation, and iii) In addition to the above solutions, zApp can determine a specific action that can result in a specific amount of temperature reduction while minimizing the impact on system performance. This action may include: a) Downsizing of mMIMO configuration, e.g. from 64T64R to 8T8R, b) Reduction in the number of physical sectors, e.g. 3 physical 4T4R sectors are reduced to 2 physical 2T4R sectors. * Changed to 2T2R sector, and c) Reducing the number of spatial layers for mMIMO. c) Backup power: i) In a typical site deployment, there is a main power source and one or more backup power sources are provided to provide continuous power to the site when the main power source is unavailable. However, the cost of the backup power source is usually high and is available for a limited amount of time. The zApp hosted on the RT RIC 702 monitors the pattern of when the main power source is unavailable and the period during which the backup power source is used. AI / ML algorithms in the RT RIC 702 can help the zApp predict the usage of the backup power source. In one aspect, the zApp alerts the SMO when the main power source has failed or is about to fail. In another embodiment, the SMO can instruct the zApp / RT RIC 702 to take energy saving actions or take action to shut down certain RUs / carriers at the site. ii) In addition to the solutions provided above, zApp makes a tradeoff between capacity, coverage, and power consumption that has the least impact on the user. This tradeoff is dynamic in nature and specific to the cell site 704. The RT RIC 702 is deployed to host this application.

[0059] This use case may alternatively be handled by having stronger HW requirements. However, this would exponentially increase costs, and even in the worst case scenario, the increase in wind load during a hurricane may be for a relatively short period of time. Using SW and AI / ML based approaches implemented on the RT RIC702 is efficient and cost effective.

[0060] Applications running on the Non-RT and Near-RT RICs can utilize over 4000 Key Performance Indicators (KPIs) to collect data from the RAN, analyze the data and adjust their algorithms to improve the performance of the wireless access link between the RU and the UE. The industry standard for periodicity for updating KPIs is 15 minutes. This is a large latency number considering that Near-RT RICs operate on time scales between 10 msec and 1 sec. To accommodate the real-time component of the RIC, the KPI periodicity can be reduced. As a non-limiting example, typical periodicity values ​​for different applications and KPIs are: 1. eSON in 4G-LTE Interference Management i.UE throughput: 2sec ii.UE measurement report: 5sec iii.UE SINR report: 2sec b.Load balancing i.Load information (capacity): 10sec 2.5G-NR xApps. a.xApps i.PRB usage rate: 5sec ii. HARQ ACK-NACK: 5sec

[0061] Reducing the periodicity of the KPIs allows for higher granularity which results in higher performance gains, but this comes at the cost of higher overhead over the transport, specifically over the fronthaul and F1, E2, A1, O1 interfaces, especially when the KPI periodicity is less than 1 second. One way to avoid large overhead for transport is to keep all or most of the KPIs used for real-time applications as close as possible to the DU. Since the Non-RT RIC and Near-RT RIC are not implemented close to the DU with a low latency control loop to process all their KPIs, they cannot avoid large overhead for transport.

[0062] Defining a RT RIC as close as possible to the DU / RU is necessary to collect and analyze all KPIs related to wireless access, train AI / ML models based on the KPIs, and perform ML inference. In one embodiment, one or more KPIs are sent to a shared data lake 420 as shown in FIG. 4. In another aspect, the KPIs in the data lake are used to train AI / ML models in the AI / ML engine 414 shown in FIG. 4, which performs the inference. In another aspect, the AI / ML training is performed in the Non-RT RIC 306 by sending the KPIs alone or in combination via the E2, A1, and O1 interfaces as shown in FIG. 3, and the AI / ML inference is performed in the RT RIC.

[0063] Other variations to the disclosed embodiments can be understood and effected by those skilled in the art in practicing the claimed features, from a study of the drawings, the disclosure, and the appended claims.

[0064] In the claims, the word "comprising" does not exclude other elements or steps and the indefinite article "a" or "an" does not exclude a plurality.

[0065] A single processor, device or other unit may fulfill the functions of several items recited in the claims. The mere fact that certain measures are recited in mutually different dependent claims does not indicate that a combination of these measures cannot be used to advantage.

[0066] Operations such as obtaining, accessing, analyzing, capturing, comparing, determining, displaying, inputting, obtaining, outputting, providing, storing or storing, calculating, simulating, receiving, alerting, and stopping may be performed as program code means of a computer program and / or as dedicated hardware.

[0067] The computer program may be stored and / or distributed on a suitable medium, such as an optical storage medium or a solid-state medium, supplied together with or as part of other hardware, but may also be distributed in other forms, such as via the Internet or other wired or wireless telecommunications systems.

Claims

1. 1. An apparatus for implementing a real-time (RT) radio interface controller (RIC) in an open radio access network (O-RAN), comprising: A memory configured to store a plurality of instructions; a processor circuit coupled to the memory; The processor circuit executes the instructions to connecting to at least one O-RAN distribution unit (O-DU) via an interface; hosting at least one application that controls the at least one O-DU via a real-time control loop with a latency of less than 10 milliseconds (ms) via the interface; It is configured as follows: Device.

2. The apparatus of claim 1 , wherein the RT RIC is co-located with the at least one O-DU.

3. The apparatus of claim 1 , wherein the RT RIC is external to the at least one O-DU.

4. The apparatus of claim 1 , wherein the RT RIC is coupled to a Fronthaul Multiplexer (FHM).

5. The RT RIC is via a first interface to a service management and orchestration (SMO) platform; via a second interface to a non-real-time (Non-RT) RIC; via a third interface to a near-real-time (Near-RT) RIC; via a fourth interface to the network element; and 2. The apparatus of claim 1, further comprising: a fifth interface connected to an O-RAN Radio Unit (O-RU); and the RT RIC connected to the SMO, Non-RT, Near-RT, network element, and O-RU, singly or in any combination.

6. 2. The apparatus of claim 1, further comprising a plurality of open application programming interfaces (APIs), each of the plurality of open APIs hosting at least one application enabling communication with at least one of a plurality of sub-modules of the RT RIC via a messaging infrastructure circuit.

7. 7. The apparatus of claim 6, wherein the plurality of sub-modules of the RT RIC include at least one of a contention management circuit, a subscription management circuit, a security circuit, an artificial intelligence (AI) model, a sensor management circuit, a hardware circuit, a data publishing circuit, and a shared data lake.

8. The apparatus of claim 7 , wherein the shared data lake is part of an information architecture (IA) of the AI ​​model.

9. The apparatus of claim 6 , wherein the RT RIC is configured to connect a primary O-DU and a secondary O-DU when performing carrier aggregation.

10. 1. An Open Radio Access Network (O-RAN) wireless communications system, comprising: an O-RAN centralized unit (O-CU); At least one O-RAN Distribution Unit (O-DU); at least an O-RAN Radio Unit (O-RU); a real-time (RT) RAN Intelligent Controller (RIC) connected to the at least one O-DU via an interface and configured to host at least one application for controlling the at least one O-DU via a real-time control loop with a latency of less than 10 ms; a non-real-time (RT) RIC configured to manage resources and events having a latency of 1 second or greater; a Near-RT RIC configured to manage resources and events having a latency between 10 ms and 1 second; Service Management and Orchestrator (SMO) Platform wherein the RT RIC is connected, singly or in any combination, to at least one of the SMO via a first interface, the Non-RT RIC via a second interface, the Near-RT RIC via a third interface, a RAN network element via a fourth interface, or the O-RU via a fifth interface.

11. The O-RAN wireless communications system of claim 10 , wherein the RT RIC is co-located with the at least one O-DU.

12. The O-RAN wireless communication system of claim 10 , wherein the RT RIC is external to the at least one O-DU.

13. The O-RAN wireless communication system of claim 10, wherein the RT RIC is connected to a Fronthaul Multiplexer (FHM).

14. 14. The O-RAN wireless communication system of claim 13, wherein the RT RIC is configured with a plurality of open Application Programming Interfaces (APIs), each of the plurality of open APIs hosting at least one application enabling communication with at least one of a plurality of sub-modules of the RT RIC via a messaging infrastructure circuit.

15. 15. The O-RAN wireless communication system of claim 14, wherein the plurality of sub-modules of the RT RIC include at least one of a contention management circuit, a subscription management circuit, a security circuit, an artificial intelligence (AI) model, a sensor management circuit, a hardware circuit, a data publishing circuit, and a shared data lake.

16. 16. The O-RAN wireless communication system of claim 15, wherein the shared data lake is part of an information architecture (IA) of the AI ​​model.

17. The O-RAN wireless communication system of claim 14, wherein the RT RIC is configured to connect with a primary O-DU and a secondary O-DU when performing carrier aggregation.

18. 1. A method for implementing a real-time (RT) radio interface controller (RIC) in an open radio access network (O-RAN), comprising: connecting the RT RIC to at least one O-RAN Distributed Unit (O-DU) via an interface; hosting at least one application by said RT RIC that controls said at least one O-DU via a real-time control loop with a latency of less than 10 ms via said interface; A method comprising:

19. 20. The method of claim 18, further comprising communicating with each of a plurality of sub-modules of the RT RIC by at least one of a plurality of open application programming interfaces (APIs), each of the plurality of open APIs hosting at least one application that enables communication with at least one of the plurality of sub-modules of the RT RIC via a messaging infrastructure.

20. 20. The method of claim 19, wherein the plurality of sub-modules of the RT RIC include at least one of a contention management circuit, a subscription management circuit, a security circuit, an artificial intelligence (AI) model, a sensor management circuit, a hardware circuit, a data publishing circuit, and a shared data lake.

Images