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 / 325,886, filed Mar. 31, 2022, and International Application PCT / US2022 / 025868, filed Apr. 22, 2022, the entire contents of each of which are hereby incorporated by reference in their entirety.

[0002] In one exemplary embodiment, the subject matter of this specification generally relates to Open Radio Access Network (O - RAN) wireless communications, and more particularly, to Open Radio Access Network (O - RAN) and Radio Access Network Intelligent Controller (RIC).

Background Art

[0003] RAN is part of a wireless communication system. RAN implements a Radio Access Technology (RAT) that exists between end - users and the Core Network (CN) of a wireless communication system. RAN includes a combination of various network elements that connect end - users to the CN. Conventionally, the hardware and software elements of a given RAN are vendor - specific.

[0004] O - RAN technology has emerged to enable an open RAN architecture. The O - RAN architecture is intended to improve competition, network flexibility, and cost. The main objective of O - RAN is to create a multi - vendor solution that separates or decomposes RAN functions between hardware platforms and software platforms using open interfaces and virtualization.

[0005] Therefore, O-RAN decomposes RAN functions into centralized units (CUs), distributed units (DUs), and radio units (RUs). CUs are logical nodes for hosting the RAN's Radio Resource Control (RRC), Service Data Adaptation Protocol (SDAP), and / or Packet Data Convergence Protocol (PDCP) sublayers. DUs are logical nodes for hosting the RAN's Radio Link Control (RLC), Media Access Control (MAC), and Physical (PHY) sublayers. RUs are physical nodes that convert transmitted and received radio signals into digital signals transmitted and received to the DUs via fronthaul. In O-RAN, these RAN functions / elements have open protocols and interfaces and can therefore be provided by different vendors.

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

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

[0008] Non-RT RICs are the control points of the non-real-time control loop and operate on timescales exceeding 1 second within the Service Management Orchestration (SMO) framework. Near-RT RICs operate on timescales between 10ms and 1 second and connect to O-DUs, O-CUs, and Open evolved NodeBs (O-eNBs). Therefore, the minimum latency between a Near-RT RIC and a connected node is 10ms.

[0009] For example, high latency loops of 10ms or more hinder the use of AI models and multi-vendor intelligent management and control for real-time operation. Therefore, there is a need for a real-time (RT) RIC that performs O-RAN intelligent management in real time. [Overview of the project]

[0010] In one common form, real-time (RT) RAN Intelligent Controller A device is provided that performs RT RIC. The device performing RT RIC may include memory configured to store multiple instructions. The device may also include processor circuitry connected to the memory and configured to host at least one application that executes multiple instructions, connects to at least one O-RAN distributed unit (O-DU) via an interface, and controls at least one O-DU via a real-time control loop with latency of less than 10 milliseconds (ms) via the interface. Other embodiments of this aspect include corresponding computer systems, devices, and computer programs recorded on one or more computer storage devices, each configured to perform the actions of the device performing RT RIC.

[0011] The implementation may include one or more of the following features: an apparatus in which the RT RIC is located in the same location as at least one O-DU; an apparatus in which the RT RIC is located outside of at least one O-DU; an apparatus in which the RT RIC is connected to a fronthaul multiplexer (FHM); an apparatus in which the RT RIC is connected to a service management and orchestration (SMO) platform via a first interface, to a non-real-time RIC (Non-RT RIC) via a second interface, to a near-real-time RIC (Near-RT RIC) via a third interface, to a network component via a fourth interface, and to an O-RAN radio unit (O-RU) via a fifth interface, and the RT RIC is connected to the SMO platform Non-RT RIC Near-RT RIC A device running RT RIC, connected to network elements and O-RUs, either alone or in combination. The device may further have multiple open application programming interfaces (APIs), each of which hosts at least one application enabling communication with at least one of multiple submodules of RT RIC via messaging infrastructure circuits. A device in which multiple submodules of 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 exposure circuit, and a shared data lake. A device in which the shared data lake is part of the information architecture (IA) of the AI ​​model. The AI ​​module may be based on machine learning and deep learning techniques. A device in which RT RIC is configured to connect with primary and secondary O-DUs when performing carrier aggregation. Implementations of the described technologies may include hardware, methods or processes, or computer media.

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

[0013] An implementation of an O-RAN wireless communication system may include one or more of the following characteristics: an O-RAN wireless communication system in which the RT RIC is located in the same location as at least one O-DU; an O-RAN wireless communication system in which the RT RIC is located outside of at least one O-DU; an O-RAN wireless communication system in which the RT RIC is connected to a fronthaul multiplexer (FHM); an O-RAN wireless communication system in which the RT RIC is configured to have multiple open application programming interfaces (APIs), each of which hosts at least one application that enables communication with at least one of multiple submodules of the RT RIC via a messaging infrastructure circuit; an O-RAN wireless communication system in which multiple submodules of the RT RIC include at least one of the following: 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 exposure circuit, and a shared data lake; or an O-RAN wireless communication system in which the shared data lake is part of the information architecture (IA) of the AI ​​model. An O-RAN wireless communication system in which the RT RIC is configured to connect with primary and secondary O-DUs when performing carrier aggregation. Implementations of the described technology may include hardware, methods or processes, or computer media.

[0014] In another common context, real-time (RT) in an open radio access network (O-RAN) RAN Intelligent Controller A method for performing an RT RIC is provided. This method may involve connecting the RT RIC to at least one O-RAN distributed unit (O-DU) via an interface. This method may also involve the RT RIC hosting at least one application that controls at least one O-DU via a real-time control loop with latency of less than 10ms via the interface.

[0015] The implementation form of this method may include one or more of the following features. This method may further include communicating with each of a plurality of sub-modules of the RT RIC by means of 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 disclosure circuit, and a shared data lake.

[0016] The description will be made with reference to the drawings.

Brief Description of the Drawings

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

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

[0019] [Figure 3] FIG. is a block diagram of an RT RIC according to one or more exemplary embodiments.

[0020] [Figure 4] FIG. shows an architecture of an RT RIC having RAN microservices according to an exemplary embodiment.

[0021] [Figure 5] FIG. shows an architecture in which an RT RIC is hosted in a vDU together with other RAN microservices.

[0022] [Figure 6] FIG. is a diagram showing a configuration including a primary O-DU and a secondary O-DU for a use case of carrier aggregation.

[0023] [Figure 7] FIG. is a logical diagram of a cell site including a plurality of O-DUs, O-RUs, cabinets, and sensors.

BEST MODE FOR CARRYING OUT THE INVENTION

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

[0025] Figure 2 shows a typical architecture of an RT RIC (102) that interfaces with two or more FHMs (106) located in the same physical location. Each FHM can be connected to or integrated with one or more DUs (104). In this architecture, the RT RIC may be implemented with the same processor as the FHM (e.g., CPU, GPU, or any hardware accelerator), or with different processors on the same motherboard, or with different motherboards in the same enclosure, or in separate enclosures in the same rack, or in separate racks 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] Figure 3 is a block diagram of an RT RIC according to one or more exemplary embodiments. The RT RIC 302 may include a first interface (labeled, in a non-limiting example, the K1 interface) connecting the RT RIC 302 to the SMO 304. The first interface may be an operation and maintenance interface performed via 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 for creating, deleting, modifying, and / or reading management object instance attributes. In another embodiment, the first interface performs at least one of several 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 RIC302 may include a second interface, labeled as the K2 interface in a non-exclusive example, which connects the RT RIC302 to the Non-RT RIC306. The second interface enables the Non-RT RIC306 to provide the RT RIC302 with policy-based guidance, machine learning (ML) model management, and augmentation information 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 layer.

[0028] The RT RIC302 may include a third interface, labeled as the K3 interface in a non-limiting example, which connects the RT RIC302 to the Near-RT RIC308. The third interface enables the Near-RT RIC308 to provide the RT RIC302 with policy-based guidance, ML model management, and hardening information to optimize the RAN. In one embodiment, the protocol stack of the third interface may include at least one of several layers, including IP, TCP, HTTPS, JSON, and / or any other proprietary or standard layer. In another embodiment, the K3 interface is modeled as an O-RAN standard-compliant E2 interface (i.e., E2AP over SCTP). The Near-RT RIC308 connects to the O-CU314 and O-DU310 via the E2 interface in a non-limiting example.

[0029] In addition, as a non-limiting example, the Near-RT RIC308 connects to the SMO302 via the O1 interface and to the Non-RT RIC306 via the A1 interface.

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

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

[0032] The RT RIC302 may include a fifth interface, labeled as the K5 interface in a non-limiting example, which connects to the O-RU312. The fifth interface is a direct logic channel or interface used to exchange data and / or control information between the RT RIC302 and at least one of the multiple O-RU312s by implementing control, user, and synchronization planes.

[0033] Figure 4 is a block diagram of the architecture of RT RIC302 with RAN microservices, according to an exemplary embodiment. The open API 402 shown in Figure 4 refers to a set of APIs exposed by the RT RIC302 platform using zApp 404, which can interact with RT RIC302 and retrieve services from RT RIC302. zApp 404 can be seen as similar to rApp, which can be implemented in Non-RT RIC, and xApp, which can be implemented in Near-RT RIC; however, zApp is an RT RIC application.

[0034] Referring to Figure 3, it is understood that RT RIC302 includes connections terminated by SMO304 (K1 termination), Non-RT RIC (K2 termination), Near-RT RIC308 (K3 termination), network element (K4 termination), and O-RU312 (K5 termination).

[0035] The messaging infrastructure 406 is a messaging framework that enables zApp404 to communicate with internal submodules of RT RIC302, and may be implemented in multiple ways.

[0036] The conflict management submodule 408 refers to the component that resolves conflicts caused by different requests initiated by different zApps. Conflicts can be partial or complete. While resolving conflicts, the conflict management module 408 may contact the z subscription management module 410 and utilize subscription and priority information during the conflict resolution process.

[0037] The subscription management submodule 410 stores subscription time information while zApp 404 is onboard, and the subscription information may, but is not limited to, hold open API access permissions (application priority).

[0038] The security submodule 412 ensures the security and stability of the RT RIC, and third-party zApp404s must comply with the security framework enabled in the RT RIC, which enables data protection and zero-trust provisioning for any onboard zApp404s. 。

[0039] AI / ML workman Engine submodule 414It processes data residing in the shared data lake 420 and creates policies / configurations much faster. It should be 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 ​​model.

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

[0041] The data publishing submodule 422, sometimes referred to as a service, controls and guarantees the publication of data to applications, such as zAPP. Certain data coming from the O-RU (K5 termination 312) may be published / accessed by a single application or a high-priority application, even if a low-priority application has permission to access it, meaning that this data may not be accessible until a higher-priority application is registered. The data publishing submodule 422 can control this access. Furthermore, the data publishing submodule 422 can control how long the RT RIC 302 must store a particular dataset, and the data publishing submodule 422 can implement data sharing techniques, such as push and pull operations.

[0042] Sensor management sa Module 416 acquires input from all sensors present at the cell site, and the sensors capture cabinet temperature, wind load, antenna tilt, clutter images, etc. measurement It is possible.

[0043] The hardware management submodule 424 can obtain information from the hardware present at the cell site, which may include average / peak CPU / memory utilization and average / peak utilization of the fronthaul interface. 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 on a cloud-native architecture, which may run as a K8s node. A K8s node may also be called a Kubernetes node, providing 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 known 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. This is known as a non-standalone architecture (NSA).

[0046] Networks deployed with NSA can be upgraded to 5G SA networks by performing a software upgrade to 4G O-DU. Real-time coordination between O-DUs is required to perform carrier aggregation from O-DUs located in the same location.

[0047] Figure 6 shows RT RIC602 connected to a primary O-DU606, which is an O-DU responsible for traffic aggregation, and a secondary O-DU608, which shares secondary carrier data with the primary O-DU for carrier aggregation. Since the UE's mobile devices are associated with only one RLC, the RLC is fixed to one of the DUs. In one embodiment, the RLC of the primary O-DU606 has real-time communication with the MAC of the secondary O-DU608. In another embodiment, 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 on shared memory. In another embodiment, the two DUs are on separate machines and use distributed shared memory to synchronize at subtransmission time interval (TTI) real-time granularity and avoid memory contention. RT RIC602 and / or zApp host the RLC itself. CU-UP604 then sends downlink packets directly to the zApp. Next, the RLC buffer within the zApp determines 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 connections between O-CU604, primary O-DU606, secondary O-DU608, O-RU610, and O-RU612.

[0048] Carrier aggregation can be performed using either a combination of TDD carriers and / or FDD carriers, based on technologies currently existing in the relevant standards. Furthermore, carrier aggregation applications hosted on RT RIC602 can collect data on delays caused by MAC entities operating on physically separate O-DUs. A zApp hosted on RT RIC602 can determine which MAC entities to perform carrier aggregation on, and this determination can be based on observed delays, configured current scheduler policies, channel conditions, buffer states in the RLC of the relevant carriers, and bearer priorities.

[0049] A zApp running on RT RIC602 can be configured with a MAC scheduler running on the primary O-DU606 to minimize the impact of latency caused by the physical isolation of the O-DUs, and this approach includes at least one of the following: a) To minimize the impact of delays caused by the physical separation of O-DU, schedule data on the secondary carrier in advance. b) Optimization of the HARQ configuration to minimize the impact of delays caused by the physical isolation of the O-DU, and c) Predict the HARQ process results on the secondary carrier based on channel conditions and / or delay. 。

[0050] The above processes can be carried out individually or in any combination according to the zApp. These zApp configurations are O-DU (606 and / or 608) and / Alternatively, an RT-RIC602 policy of O-RU (610 and / or 612) is formed. The RT-RIC602 policy for carrier aggregation may differ for each carrier based on quality of service and network slice configuration.

[0051] Operator-specific coverage and capacity requirements can vary significantly. In a typical NSA deployment, the LTE layer (typically FDD) can function as the coverage layer, while the 5G layer provides capacity. When upgrading the network to an SA architecture, some operators may prefer to maintain a consistent user experience even after migrating to the SA architecture by implementing carrier aggregation. This requires updating the scheduler with resource allocation policies, changes to fairness attributes, and other configurations.

[0052] If configuration conflicts arise between O-DUs from a Near RT RIC and O-DUs from an RT RIC, the configuration from RT RIC602 may take precedence. Furthermore, RT RIC602 can remember configurations / policies from Near-RT RICs and / or Non-RT RICs to reduce conflicts.

[0053] In carrier aggregation use cases where each carrier operates on a physically separate O-DU, the zApp running on the RT RIC602 can perform at least the following operations: a) If zApp does not exist, carrier aggregation will function as described in the prior art. 。 b) The RT RIC602 can enable the zApp to retrieve configuration information from the Near-RT RIC, Non-RT RIC, SMO, and / or O-DU itself, which allows the RT RIC602 to recognize the current configuration policy. c) If there is a configuration conflict in the O-DU (606 and 608) from the configurations received from RT RIC602 and Near-RT RIC, the configuration from RT RIC602 takes precedence. Generally, the likelihood of this conflict is low because RT RIC602 operates in a real-time loop and can primarily operate in a MAC / PHY layer configuration. d) The zApp responsible for carrier aggregation configures the O-DU along with policies related to coverage and capacity expansion, taking into account the delays that may be caused by the physically separate O-DUs (606 / 608) on which the primary and secondary carriers are operating. RT RIC602 can be configured to include MACs, MAC schedulers, and other components operating on the O-DUs (606 / 608).

[0054] In one embodiment, zApp manages the RLC buffer. In another embodiment, the primary O-DU606 manages the RLD buffer.

[0055] It will be apparent that the systems and / or methods described herein may be implemented with different forms of hardware, firmware, or combinations of hardware and software. The actual dedicated control hardware or software code used to implement these systems and / or methods is not limited to specific implementations. Therefore, the operation and behavior of the systems and / or methods are described herein without reference to specific software code, and it is understood that software and hardware may be designed to implement the systems and / or methods based on the descriptions herein.

[0056] After phones were converted to smartphones, similar conversions are now being seen on the network side, and cell site intelligence is improving, cell site to Powered by existing hardware sensors, it monitors aspects related to temperature, humidity, wind load, tower load, camera clutter image acquisition, and cable routing images. Some of this information requires real-time response.

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

[0058] In one embodiment, RT RIC702 can measure the current loads facing the components of cell site 704, including wind loads. When the current loads facing various components of cell site 704 approach the load capacity of the tower or other components of cell site 704, the zApp hosted on RT RIC702 can take preventative measures to avoid damage to the components facing cell site 704 or to reduce transient strain. Furthermore, if this phenomenon occurs frequently at any particular site, RT RIC702 can pass recommendations to the Operational Support System (OSS) / Business Support System (BSS) module. Scenarios in which a real-time response from RT RIC704 may be critical include: a) A sudden surge in site load: i) The solution includes reducing the wind load by changing the tilt and / or direction of the antenna. Furthermore, in these solutions, RT RIC702 / 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 RT RIC702 can calculate the current capacity of the site using AI / ML technology and the current age of the site. ii) In addition to the above solutions, when the current load on the site approaches the capacity of cell site 704, the AI / ML algorithm zApp hosted on RT RIC702 can calculate effective changes in the tilt and orientation of antenna / O-RU708 that minimize the impact on the user experience while the current load on the site is reduced, and iii) The above thresholds may differ and are based on the antenna panel size and large-scale MIMO (mMIMO) configuration. b) Cabinet temperature rise: i) The solution includes reducing the CPU processing load to prevent system failure. One of the zApps hosted on the RT RIC702 can monitor the current temperature status, CPU configuration, and load on each CPU. ii) The solution further includes an analysis of the reduction in CPU load with temperature reduction, along with the impact of the reduction in CPU load on system performance, including the data. AI / ML algorithms hosted on RT RIC702 can help zApp compute this correlation, as well as iii) In addition to the above solutions, zApp can determine specific actions that can result in a certain amount of temperature reduction while minimizing the impact on system performance. This action may include: a) For example, reducing the mMIMO configuration from 64T64R to 8T8R, b) Reduction in the number of physical sectors, for example, from 3 physical 4T4R sectors to 2 physical 2 * The sector will be changed to 2T2R, and c) Reduction of the number of spatial layers for mMIMO. c) Backup power supply: i) In a typical site deployment, there is a main power supply, and one or more backup power supplies are provided to supply continuous power to the site in the event that the main power supply becomes unavailable. However, backup power supplies are typically expensive and available for limited periods of time. A zApp hosted on RT RIC702 monitors patterns of main power supply unavailability and the duration for which backup power supplies are used. AI / ML algorithms in RT RIC702 can help the zApp predict backup power supply usage. In one embodiment, the zApp alerts the SMO when the main power supply fails or is about to fail. In another embodiment, the SMO can instruct the zApp / RT RIC702 to take energy-saving actions or to shut down specific RUs / carriers at the site. ii) In addition to the solutions provided above, zApp makes trade-offs between capacity, coverage, and power consumption that have the least impact on the user. These trade-offs are inherently dynamic and specific to cell site 704. RT RIC702 is positioned to host this application.

[0059] This use case may be handled alternatively by having stronger hardware requirements. However, this would exponentially increase costs, and in the worst case scenario, the scenario may be for relatively short periods, such as increased wind load during a hurricane. Using the SW and AI / ML-based approach implemented in RT RIC702 is efficient and cost-effective.

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

[0061] Reducing the periodicity of KPIs allows for higher granularity, resulting in greater performance improvements. However, this comes at the cost of higher overhead via transport, specifically through the fronthaul and F1, E2, A1, and O1 interfaces, especially when the KPI periodicity is less than 1 second. One way to avoid significant overhead for transport is to keep all or most of the KPIs used in real-time applications as close to the DU as possible. Non-RT RICs and Near-RT RICs cannot avoid significant overhead for transport because they are not implemented near the DU in a low-latency control loop to handle all of their KPIs.

[0062] Defining the RT RIC as close to the DU / RU as possible is necessary for collecting and analyzing all KPIs related to wireless access, training AI / ML models based on those KPIs, and performing ML inference. In one embodiment, one or more KPIs are sent to the shared data lake 420, as shown in Figure 4. In another embodiment, the KPIs in the data lake are used to train an AI / ML model in the AI / ML engine 414, as shown in Figure 4, and the AI / ML engine 414 performs inference. In yet another embodiment, AI / ML training is performed in the Non-RT RIC 306 by sending KPIs individually or in combination via the E2, A1, and O1 interfaces, as shown in Figure 3, and AI / ML inference is performed in the RT RIC.

[0063] Other variations of the disclosed embodiments can be understood and achieved by those skilled in the art in carrying out the claimed features, based on the study of the drawings, disclosures, and appended claims.

[0064] In the claims, the phrase "comprising" does not preclude other elements or steps, and the indefinite article "a" or "an" does not preclude the plural.

[0065] A single processor, device, or other unit may perform the functions of several of the items enumerated in the claims. The mere fact that certain means are enumerated in different dependent claims does not imply that combinations of these means cannot be used advantageously.

[0066] Operations such as acquisition, access, analysis, capture, comparison, decision, display, input, retrieve, output, provide, store or store, calculate, simulate, receive, warn, and stop can be performed as program code means of a computer program and / or as dedicated hardware.

[0067] Computer programs may be stored and / or distributed on suitable media such as optical storage media or solid-state media supplied together with or as part of other hardware, but they may also be distributed in other forms, such as via the Internet or other wired or wireless telecommunication systems.

Claims

1. A device that operates a real-time (RT) radio interface controller (RIC) in an open radio access network (O-RAN), Connects to at least one O-RAN distributed 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 latency of less than 10 milliseconds (ms) through the interface. It is configured in such a way, The RT RIC is connected to the Near-RT RIC via a third interface that terminates at the Near-RT RIC, and the third interface is different from the E2 interface. Device.

2. The apparatus according to claim 1, wherein the RT RIC is located in the same location as the at least one O-DU.

3. The apparatus according to claim 1, wherein the RT RIC is located outside the at least one O-DU.

4. The apparatus according to claim 1, wherein the RT RIC is connected to a front haul multiplexer (FHM).

5. The aforementioned RT RIC, Through the first interface to the Service Management and Orchestration (SMO) platform, To a non-real-time (Non-RT) RIC via a second interface, To the network components via the fourth interface, and The apparatus according to claim 1, wherein the RT RIC is connected to an O-RAN radio unit (O-RU) via a fifth interface, and the RT RIC is connected to the SMO platform, Non-RT RIC, Near-RT RIC, network elements, and O-RU, either individually or in any combination.

6. The apparatus according to claim 1, further comprising a plurality of open application programming interfaces (APIs), each of which hosts at least one application that enables communication with at least one of a plurality of submodules of the RT RIC via a messaging infrastructure circuit.

7. The apparatus according to claim 6, wherein the plurality of submodules of the RT RIC include at least one of a competition management circuit, a subscription management circuit, a security circuit, an artificial intelligence (AI) model, a sensor management circuit, a hardware circuit, a data exposure circuit, and a shared data lake.

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

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

10. An open radio access network (O-RAN) wireless communication system, O-RAN Central Unit (O-CU) and At least one O-RAN distributed unit (O-DU), At least one O-RAN radio unit (O-RU), 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, A non-real-time (Non-RT) RIC configured to manage resources and events with latency of 1 second or more, A Near-RT RIC configured to manage resources and events with latency of 10ms to 1 second, Service management and orchestrator (SMO) platform and Equipped with, An open radio access network (O-RAN) wireless communication system in which the RT RIC is connected, individually or in any combination, to at least one of the following via a first interface terminating at the RT RIC: the SMO platform, the Non-RT RIC via a second interface terminating at the RT RIC, the Near-RT RIC via a third interface terminating at the RT RIC, a RAN network element via a fourth interface terminating at the RT RIC, or the O-RU via a fifth interface terminating at the RT RIC.

11. The O-RAN wireless communication system according to claim 10, wherein the RT RIC is located in the same location as the at least one O-DU.

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

13. The O-RAN wireless communication system according to claim 10, wherein the RT RIC is connected to a front haul multiplexer (FHM).

14. The O-RAN wireless communication system according to claim 13, wherein the RT RIC is configured to have a plurality of open application programming interfaces (APIs), and each of the plurality of open APIs hosts at least one application that enables communication with at least one of a plurality of submodules of the RT RIC via a messaging infrastructure circuit.

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

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

17. The O-RAN wireless communication system according to 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. A method for running a real-time (RT) radio interface controller (RIC) in an open radio access network (O-RAN), Connecting the RT RIC to at least one O-RAN distributed unit (O-DU) via an interface, The RT RIC hosts 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. Includes, The RT RIC is connected to the Near-RT RIC via a third interface that terminates at the Near-RT RIC, and the third interface is different from the E2 interface. method.

19. The method according to claim 18, further comprising communicating with each of a plurality of submodules 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 submodules of the RT RIC via a messaging infrastructure.

20. The method according to claim 19, wherein the plurality of submodules of the RT RIC include at least one of a competition management circuit, a subscription management circuit, a security circuit, an artificial intelligence (AI) model, a sensor management circuit, a hardware circuit, a data exposure circuit, and a shared data lake.

Images