Real-time RAN intelligent controller architecture

Abstract

An 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 an O-RAN radio unit (O-RU), and a real-time (RT) RAN Intelligent Controller (RIC) coupled to the at least O-DU and configured to host at least one application, the at least one application controls the at least one O-DU on a real-time control loop with a delay of less than 10 ms. An O-RAN wireless system may include a non-RT (non-RT) RIC configured to manage resources and events having a delay equal to or greater than 1 second, and may include a near RT RIC configured to manage resources and events having a delay of 10 ms to 1 second. Further, the O-RAN may include a service management and orchestrator (SMO) platform in which the RT RIC is connected to at least one of the SMO, the non-RT RIC, the near RT RIC, the RAN network element, and the O-RU.

Description

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS

[0002] This application claims priority to U.S. Provisional Patent Application No. 63 / 325,886, filed on March 31, 2022, and International Application No. PCT / US2022 / 025868, filed on April 22, 2022, the entire contents of both applications are incorporated herein by reference. Technical Field

[0003] In some example embodiments, the subject matter herein relates generally to Radio Access Network (RAN) (O-RAN) wireless communications, and more particularly to an Open Radio Access Network and a RAN Intelligent Controller (RIC). Background Art

[0004] The RAN is part of a wireless communication system. The RAN implements the Radio Access Technology (RAT) that resides between the end-user and the Core Network (CN) of the wireless communication system. The RAN comprises a combination of various network elements that connect the end-user to the CN. Traditionally, the hardware and software elements of a given RAN are vendor-specific.

[0005] O-RAN technology has emerged to enable open RAN architecture. The O-RAN architecture aims to improve competitiveness, network flexibility, and cost. The main goal of O-RAN is to create a multi-vendor solution that separates or disaggregates RAN functions between hardware and software platforms through open interfaces and virtualization.

[0006] Therefore, O-RAN decomposes RAN functions into centralized units (CU), distributed units (DU), and radio units (RU). CU is a logical node for hosting the radio resource control (RRC), service data adaptation protocol (SDAP), and / or packet data convergence protocol (PDCP) sublayers of the RAN. DU is a logical node for hosting the radio link control (RLC), media access control (MAC), and physical (PHY) sublayers of the RAN. RU is a physical node that converts the transmitted / received radio signal into a digital signal, which is sent / received to the DU through the fronthaul. In O-RAN, these RAN functions / elements have open protocols and interfaces and can therefore be provided by different vendors.

[0007] The RAN functions in the O-RAN architecture are controlled by the RAN Intelligent Controller (RIC). RIC is a software-defined component of the O-RAN architecture. RIC enables the onboarding of third-party applications that enable large-scale automation and optimization of RAN operations while supporting innovative use cases.

[0008] In the current O-RAN architecture, RIC is divided into two types, non-real-time RIC (non-RT RIC) and near real-time RIC (near RT RIC). Typically, non-RT RIC provides policies, data, and artificial intelligence (AI) models implemented and used by near RT RIC to perform RAN optimization.

[0009] The non-RT RIC is the control point of the non-real-time control loop and operates on a time scale greater than 1 second within the Service Management Orchestration (SMO) framework. The near-RT RIC operates on a time scale of 10ms to 1 second and is connected to the O-DU, O-CU, and Open Evolved NodeB (O-eNB). Therefore, the minimum delay between the near-RT RIC and the connected node is 10ms.

[0010] High latency loops (e.g., equal to or greater than 10ms) hinder the use of AI models and multi-vendor intelligent management and control for real-time operations. Therefore, real-time (RT) RIC is required to perform O-RAN intelligent management in real time. Summary of the invention

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

[0012] Implementation may include one or more of the following features. In the device, the RT RIC is collocated with at least one O-DU. In the device, the RT RIC is outside at least one O-DU. In the device, the RT RIC is coupled to a fronthaul multiplexer (FHM). In the device implementing the RT RIC, 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, to an O-RAN radio unit (O-RU) via a fifth interface, wherein the RT RIC is connected to the following items alone or to any combination of the following items: SMO, non-RT, near RT, network element, and O-RU. The device may also include a plurality of open application programming interfaces (APIs), each of the plurality of open APIs hosting at least one application, the at least one application enabling communication with at least one of the plurality of submodules of the RT RIC via a messaging infrastructure circuit system. In the device, multiple submodules of the RT RIC include at least one of the following: a conflict management circuit system, a subscription management circuit system, a security circuit system, an artificial intelligence (AI) model, a sensor management circuit system, a hardware circuit system, a data exposure circuit system, and a shared data lake. In the device, the shared data lake is part of the information architecture (IA) of the AI ​​model. The AI ​​module can be based on machine learning and deep learning techniques. In the device, the RT RIC is configured to connect to the primary O-DU and the secondary O-DU when performing carrier aggregation. The implementation of the described technology may include hardware, methods or processes, or computer tangible media.

[0013] 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), a real-time (RT) RAN intelligent controller (RIC), the RIC is coupled to at least the O-DU via an interface, and is configured to host at least one application, the at least one application controlling at least one O-DU on a real-time control loop with a delay of less than 10ms. The O-RAN wireless communication system may also include a non-RT (non-RT) RIC configured to manage resources and events with a delay equal to or greater than 1 second, a near-RT RIC configured to manage resources and events with a delay of 10ms to 1 second, a service management and orchestration (SMO) platform, wherein the RT RIC is connected to the SMO via a first interface, to the non-RT RIC via a second interface, to the near-RT RIC via a third interface, to the RAN network element via a fourth interface, and to the O-RU via a fifth interface.

[0014] The implementation of the O-RAN wireless communication system may include one or more of the following features. In the O-RAN wireless communication system, the RT RIC is collocated with at least one O-DU. In the O-RAN wireless communication system, the RT RIC is outside at least one O-DU. In the O-RAN wireless communication system, the RT RIC is coupled to a forward multiplexer (FHM). In the O-RAN wireless communication system, 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, the at least one application enabling communication with at least one of the plurality of sub-modules of the RT RIC via a messaging infrastructure circuit system. In the O-RAN wireless communication system, the plurality of sub-modules of the RTRIC include at least one of the following: a conflict management circuit system, a subscription management circuit system, a security circuit system, an artificial intelligence (AI) model, a sensor management circuit system, a hardware circuit system, a data exposure circuit system, and a shared data lake. In the O-RAN wireless communication system, the shared data lake is part of the information architecture (IA) of the AI ​​model. In the O-RAN wireless communication system, 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.

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

[0016] The implementation of the method may include one or more of the following features. The method may also include: communicating with each of the multiple sub-modules of the RT RIC through at least one open API in a plurality of open application programming interfaces (APIs), each of the multiple open APIs hosting at least one application, the at least one application enabling communication with at least one of the multiple sub-modules of the RT RIC via a messaging infrastructure, wherein the multiple sub-modules of the RTRIC include at least one of the following: conflict management circuitry, subscription management circuitry, security circuitry, artificial intelligence (AI) models, sensor management circuitry, hardware circuitry, data exposure circuitry, and a shared data lake. BRIEF DESCRIPTION OF THE DRAWINGS

[0017] In the following figures:

[0018] Figure 1 illustrates a general architecture in which an RT RIC interfaces with more than one O-DU according to an example embodiment;

[0019] Figure 2 illustrates a general architecture in which an RT RIC interfaces with more than one O-DU according to an example embodiment;

[0020] Figure 3 is a block diagram of an RT RIC according to one or more example embodiments;

[0021] Figure 4 illustrates the architecture of RT RIC with RAN microservices according to an example embodiment;

[0022] Figure 5 illustrates an architecture where the RT RIC is hosted at the vDU along with other RAN microservices;

[0023] Figure 6 illustrates a configuration with a primary O-DU and a secondary O-DU for a carrier aggregation use case; and

[0024] Figure 7Depicts the logical view of a cell site consisting of multiple O-DUs, O-RUs, cabinets, and sensors. DETAILED DESCRIPTION

[0025] Figure 1 The general architecture of an RT RIC (102) is illustrated, which has an interface with more than one physically collocated O-DU (104); in this architecture, the RT RIC (102) can be hosted in any of the O-DUs (104) or on an external unit. The RT RIC (102) can 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 housing, or on a separate housing in the same rack, or on a separate rack in the same data center, or on a separate unit. The DU (104) can establish communication with one or more RUs (108) through the FHM (106).

[0026] Figure 2 The general architecture of an RT RIC (102) is illustrated, which has an interface with more than one physically collocated FHM (106). Each FHM can be connected to or integrated with one or more DUs (104). In this architecture, the RT RIC can be implemented within the same processor (e.g., CPU, GPU, or any hardware accelerator) as the FHM, or within a different processor within the same motherboard, or within a different motherboard within the same housing, or within a separate housing within the same rack, or within a separate rack within the same data center. The FHM can be configured to aggregate data or control information (e.g., SRS signals) between one or more O-RUs and the RT RIC.

[0027] Figure 3is a block diagram of an RT RIC according to one or more example embodiments. RT RIC 302 may include a first interface (labeled as K1 interface as a non-limiting example) that connects RT RIC 302 to SMO 304. The first interface may be an operation and maintenance interface implemented using a network configuration protocol (NETCONF), or any other network management protocol through a standard or proprietary interface. 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 implements at least one of a plurality of services, including: fault supervision management, performance assurance management, tracking 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 RT RIC 302 to SMO 304.

[0028] 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 enriched 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 layer.

[0029] 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 enables the near-RT RIC 308 to provide policy-based guidance, ML model management, and enriched 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 a plurality of layers including IP, TCP, HTTPS, JSON, and / or any other proprietary or standard layer. In another embodiment, the K3 interface is modeled as an E2 interface compliant with the O-RAN standard (i.e., E2AP over SCTP). As a non-limiting example, the near-RT RIC 308 is connected to the O-CU 314 and the O-DU 310 via the E2 interface.

[0030] Furthermore, as a non-limiting example, near-RT RIC 308 is connected to SMO 302 via an O1 interface and is connected to non-RT RIC 306 via an A1 interface.

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

[0032] 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 RIC 302.

[0033] The RT RIC 302 may include a fifth interface (labeled as a K5 interface as a non-limiting example) connected to the O-RU 312. The fifth interface is a direct logical channel or interface for exchanging data and / or control information between the RT RIC 302 and at least one O-RU in the plurality of O-RUs 312 by implementing control, user, and synchronization planes.

[0034] Figure 4 is a block diagram of the architecture of the RT RIC 302 with RAN microservices according to an example embodiment. Figure 4 The open API 402 shown in refers to a set of APIs exposed by the RT RIC 302 platform using zApp 404, which can interact with and obtain services from RTRIC 302. ZApp 404 can be considered similar to rApps that can be implemented in non-RT RICs and xApps that can be implemented in near-RT RICs, however, zApps are RT RIC applications.

[0035] refer to Figure 3 It can be understood that the RT RIC 302 includes a connection terminated at the SMO 304 (K1 termination), a connection terminated at a non-RTRIC (K2 termination), a connection terminated at a near-RT RIC 308 (K3 termination), a connection terminated at a network element (K4 termination), and a connection terminated at the O-RU 312 (K5 termination).

[0036] Messaging infrastructure 406 is a messaging framework that enables zApp 404 to communicate with internal submodules of RT RIC 302 and can be implemented in a variety of ways.

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

[0038] The subscription management submodule 410 stores subscription time information when the zApp 404 logs in. The subscription information may include but is not limited to the access rights (application priority) of holding the open API.

[0039] The security submodule 412 ensures the security and stability of the RT RIC. Third-party zApps 404 need to comply with the security framework enabled in the RT RIC. The security framework enables data protection and zero-trust provisioning for any installed zApps 404.

[0040] The AI / ML 414 engine submodule processes the data in the shared data lake 420 and creates policies / configurations faster. It should be understood that the AI ​​engine 414 may include machine learning (ML) and / or deep learning technology. The shared data lake 420 is part of the information architecture (IA) of the AI ​​model.

[0041] ML can be divided into two phases, training and inference. In the training phase, data is fed into the model so it can learn everything about the type of data being analyzed. In the inference phase, the model can make predictions based on real-time data to produce actionable results. In deep learning, a deep neural network (DNN) can learn how to analyze a set of data and make predictions about the data. Deep learning relies on feedback so that the system learns from incorrect conclusions.

[0042] The data exposure submodule 422 (which may be referred to as a service) controls and ensures that data is exposed to applications, such as zAPPs. Some data from the O-RU (K5 termination 312) may be exposed / accessed by a single application or high priority applications, which may not be able to access it until the higher priority application is registered, even if the low priority application has access rights. The data exposure submodule 422 may control this access. In addition, the data exposure submodule 422 may control the time when the RT RIC 302 must store a specific set of data, and the data exposure submodule 422 may implement data sharing techniques, such as push and pull operations.

[0043] The sensor management submodule 416 takes input from all sensors at the cell site, which may include cabinet temperature, wind load, antenna tilt, clutter image, etc.

[0044] The hardware management submodule 424 may obtain information from the hardware present at the cell site, which may include average / peak CPU / memory utilization, average / peak utilization of the fronthaul interface, etc. API enhancement may be implemented via the API enhancement module 426 .

[0045] Figure 5 An architecture is illustrated in which the RT RIC is hosted at a virtual DU (vDU) 502 along with other RAN microservices 504. The vDU can be implemented in a cloud native architecture. This can be implemented as a K8s node. The K8s node can 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 microservice 504 may include control and data plane functions, as well as baseband functions.

[0046] Greenfield 5G networks can be deployed on a 5G network core known as a standalone architecture (SA). However, migration from 4G to 5G requires overlaying a new 5G RAN on the existing 4G LTE network core. This is known as a non-standalone architecture (NSA).

[0047] NSA deployed networks can be upgraded to 5G SA networks by implementing software upgrades on 4G O-DUs. Carrier aggregation from collocated O-DUs requires real-time coordination between O-DUs.

[0048] Figure 6The RT RIC 602 is illustrated, which is connected to the main O-DU 606 and the auxiliary O-DU 608, the main O-DU is the O-DU responsible for the aggregation service, and the auxiliary O-DU shares the auxiliary carrier data with the main O-DU for carrier aggregation. The RLC is anchored on one of the DUs because the mobile device of the UE is associated with only one RLC. In one embodiment, the RLC of the main O-DU 606 communicates with the MAC of the auxiliary O-DU 608 in real time. In another embodiment, a shared memory is used to maintain the RLC buffer across the two O-DUs. In one embodiment, the two DUs can be on the same computing 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, which is synchronized at a sub-transmission time interval (TTI) real-time granularity and avoids memory contention. The RT RIC 602 and / or zApp hosts the RLC itself. Then, the CU-UP 604 sends the downlink packet directly to the zApp. The RLC buffer in the zApp then decides which cell's MAC (i.e., primary O-DU vs. secondary O-DU) to send the packet to, and which O-DU to activate, via the MAC and data path 614. The data path 614 provides connectivity between the O-CU 604, primary O-DU 606, secondary O-DU 608, O-RU 610, and O-RU 612.

[0049] Based on the current existing technology in the relevant standards, any combination of TDD and / or FDD carriers can be used to perform carrier aggregation. In addition, the carrier aggregation application hosted at the RT RIC 602 can collect data about the delays caused by MAC entities running on physically independent O-DUs. The zApp hosted at the RT RIC 602 can decide which MAC entity to perform carrier aggregation, and the decision can be based on the observed delays, the configured current scheduling policy, the channel conditions, the buffer status at the RLC of the involved carriers, and the bearer priority.

[0050] The zApp running on the RT RIC 602 may configure the MAC scheduler running on the primary O-DU 606 to minimize the impact of delays due to the physical separation of the O-DUs, by at least one of:

[0051] a) Schedule data on the secondary carrier in advance to minimize the impact of delays due to physical separation of the O-DUs;

[0052] b) optimizing the HARQ configuration to minimize the delay impact due to the physical separation of the O-DUs; and

[0053] c) predicting the HARQ process results on the secondary carrier based on channel conditions and / or delays,

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

[0055] The coverage and capacity requirements of each carrier may vary significantly. In a typical NSA deployment, the LTE layer (usually FDD) can serve as the coverage layer, while the 5G layer provides capacity. In the case of upgrading the network to the SA architecture, some carriers may want to keep the experience intact even after moving to the SA architecture through carrier aggregation. This requires updating the schedule with resource allocation strategies, changes in fairness attributes, and other configurations.

[0056] In case of conflicting configurations with near-RT RIC and RT RIC at the O-DU, the configuration from RT RIC 602 may take precedence. In addition, RT RIC 602 may store configurations / policies from near-RT RIC and / or non-RT RIC to reduce conflicts.

[0057] For the carrier aggregation use case where each carrier operates on physically separate O-DUs, the zApp running on the RT RIC 602 may handle at least the following operations:

[0058] a) For the case where zApp does not exist, carrier aggregation works as described in the prior art;

[0059] b) The RT RIC 602 may enable the zApp to obtain configuration information from the near RT RIC, non-RT RIC, SMO, and / or the O-DU itself, which makes the RT RIC 602 aware of the current configuration policy.

[0060] c) In the event of a configuration conflict at the O-DU (606 and 608) with the configuration received from the RT RIC 602 and the near-RT RIC, the configuration from the RT RIC 602 takes precedence. Typically, the likelihood of such a conflict may be low because the RT RIC 602 operates on a real-time loop and may work primarily with MAC / PHY layer configurations.

[0061] d) The zApp responsible for carrier aggregation, when configuring the O-DU and policies related to coverage and capacity enhancement, takes into account the delays that may be caused in this case due to the physically separated O-DUs (606 / 608) on which the primary and secondary carriers operate. The RT RIC 602 may enable configuration of the MAC, MAC scheduler, and other components operating at the O-DU (606 / 608).

[0062] In one embodiment, the zApp manages the RLC buffers. In another embodiment, the master O-DU 606 manages the RLD buffers.

[0063] It is apparent that the systems and / or methods described herein may be implemented in various 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 does not limit these 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 can be designed to implement these systems and / or methods based on the description herein.

[0064] After the transformation of mobile phones to smartphones, a similar transformation has occurred on the network side where intelligence at the cell site is increasing and it is powered by HW sensors present at the cell site to monitor aspects related to temperature, humidity, wind load, tower load, camera capture of clutter images, cabling images. Some of this information requires real-time response.

[0065] Figure 7 A logical view of a cell site is illustrated. A cell site 704 may be composed of a plurality of O-DUs 706, an O-RU 708, a cabinet 710, a plurality of sensors 712, a fronthaul (FH) gateway / switch 714, and a GPS 716.

[0066] In one aspect, the RT RIC 702 can measure the current loads, including wind loads, faced by the components of the cell site 704. If the current loads faced by the various components of the cell site 704 are close to the load capacity of the tower or other components of the cell site 704, the zApp hosted at the RT RIC 702 can take preventive measures to avoid any damage or reduce the temporary strain faced by the components of the cell site 704. In addition, if this phenomenon occurs frequently at any particular site, the RT RIC 702 can pass recommendations to the Operation Support System (OSS) / Business Support System (BSS) module. Some scenarios where real-time response from the RTRIC 704 may be very critical are as follows.

[0067] a) Sudden increase in site load:

[0068] i) Solutions include reducing wind loads by changing the tilt and / or orientation of the antenna. In addition, in these solutions, the RT RIC 702 / zApp may already have site / tower load capacity information that can be determined when the cell site 704 is installed, and the zApp hosted at the RT RIC 702 can calculate the current capacity of the site by using AI / ML techniques and the current age of the site;

[0069] ii) In addition to the above solutions, when the current load at the site becomes close to the cell site 704 capacity, the AI / ML algorithm zApp hosted at the RT RIC 702 can calculate the effective change of antenna / O-RU 708 tilt and direction, which has the least impact on the user experience while reducing the load at the site; and

[0070] iii) The above thresholds can be different and are based on antenna panel size and large scale

[0071] MIMO (mMIMO) configuration.

[0072] b) Rise of cabinet temperature:

[0073] i) The solution includes reducing the CPU processing load to prevent the system from crashing. One of the zApps hosted at the RT RIC 702 can monitor the current state of the temperature, the configuration of the CPU, and the load on each CPU;

[0074] ii) The solution also includes analyzing the reduction in CPU load during the temperature reduction and the impact of the CPU load reduction on system performance including data. The AI / ML algorithm hosted at the RT RIC 702 can help zApp calculate this correlation

[0075] Sex; and

[0076] iii) In addition to the above solutions, zApp can also determine specific actions that can cause the temperature to drop by a specific amount with minimal impact on system performance.

[0077] This action may include:

[0078] a) Reduce the mMIMO configuration, for example, from 64T64R to 8T8R;

[0079] b) reducing the number of physical sectors, for example, changing three physical 4T4R sectors to two physical 2*2T2R sectors; and

[0080] c) Reduce the number of spatial layers of mMIMO.

[0081] c) Backup power supply:

[0082] i) In a typical site deployment, there is a primary power source and one or more backup power sources are provided to provide continuous power to the site in the event that the primary power source is unavailable. However, the cost of backup power sources is typically high and they are available for a limited time. The zApp hosted at the RT RIC 702 monitors the pattern of when the primary power source is unavailable and the duration of the use of the backup power source. The AI / ML algorithms at the RT RIC 702 can help the zApp predict the usage of the backup power sources. In one aspect, the zApp sends an alert to the SMO when the primary power source fails or is about to fail. In another embodiment, the SMO can instruct the zApp / RT RIC 702 to take energy-saving actions or take actions to shut down certain RUs / carriers at the site.

[0083] ii) In addition to the above solutions, zApp also makes trade-offs between capacity, coverage, and power consumption to minimize impact on users. This trade-off is dynamic in nature and specific to the cell site 704. The RT RIC 702 is located to host the application.

[0084] This use case could also be handled with stricter HW requirements. However, this would increase costs exponentially and would only last for a relatively short time even in the worst case scenario, such as the increase in wind loads during a hurricane. Using a SW and AI / ML based approach implemented with the RT RIC702 is efficient and economical.

[0085] Applications running on non-RT and near-RT RICs can collect data from the RAN using over 4000 key performance indicators (KPIs) and analyze the data to adjust their algorithms to improve the performance of the radio access link between the RU and the UE. The industry standard for the period for updating the KPIs is 15 minutes. This is a large latency figure considering that near-RT RICs operate in a time range of 10 milliseconds to 1 second. To accommodate the real-time component of the RIC, the KPI period can be shortened. As a non-limiting example, some of the typical period values ​​for different applications and KPIs are as follows.

[0086] eSON in 1.4G-LTE

[0087] a. Interference Management

[0088] i.UE throughput: 2 seconds

[0089] ii.UE measurement report: 5 seconds

[0090] iii.UE SINR report: 2 seconds

[0091] b. Load balancing

[0092] i. Load information (capacity): 10 seconds

[0093] xApps in 2.5G-NR.

[0094] a.xApp

[0095] i.PRB utilization: 5 seconds

[0096] ii.HARQ ACK-NACK: 5 seconds

[0097] Although shortening the KPI period can achieve higher granularity and thus higher performance gain, this comes at the expense of higher transmission overhead, especially on the fronthaul and F1, E2, A1, O1 interfaces, especially when the KPI period is below 1 second. One way to avoid large transmission overhead is to place all or most of the KPIs for real-time applications as close to the DU as possible. Since non-RTRIC and near-RT RIC are not implemented close to the DU and there is no low-latency control loop to handle all these KPIs, it may not be possible to avoid huge transmission overhead.

[0098] The RT RIC needs to be defined as close as possible to the DU / RU to collect and analyze all KPIs related to wireless access, train AI / ML models based on the KPIs, and perform ML reasoning. Figure 4 As shown in , one or more KPIs are sent to the shared data lake 420. In another aspect, the KPIs at the data lake are used to Figure 4 The AI / ML model is trained in the AI / ML engine 414 shown in FIG, and the AI / ML engine 412 performs reasoning. Figure 3 KPIs are sent over the E2, A1, and O1 interfaces shown in to perform AI / ML training at the non-RT RIC 306 and AI / ML inference at the RT RIC.

[0099] 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.

[0100] 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.

[0101] 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.

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

[0103] The computer program may be stored and / or distributed on suitable media (such as optical storage media or solid-state media) provided 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. An apparatus implementing a real-time (RT) radio interface controller (RIC) in an open radio access network (O-RAN), the apparatus comprising: a memory configured to store a plurality of instructions; a processor circuit system coupled to the memory and configured to execute the plurality of instructions to: connected to at least one O-RAN distributed unit (O-DU) via an interface; as well as At least one application is hosted, the at least one application controlling the at least one O-DU via the interface in a real-time control loop having a latency of less than 10 milliseconds (ms).

2. The apparatus of claim 1, wherein the RT RIC is collocated with the at least one O-DU. 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 forward haul multiplexer (FHM).

5. The apparatus of claim 1, wherein the RT RIC: being connected to a service management and orchestration (SMO) platform via a first interface; connected to a non-real-time (non-RT) RIC via a second interface; connected to a near real-time (near RT) RIC via a third interface; connected to the network component via a fourth interface; as well as is connected to an O-RAN radio unit (O-RU) via a fifth interface, wherein the RT RIC is connected to the following items alone or to any combination of the following items: the SMO, the non-RT, the near RT, the network element, and the O-RU.

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

7. The apparatus of claim 6, wherein the plurality of sub-modules of the RT RIC include at least one of: a conflict management circuit system, a subscription management circuit system, a security circuit system, an artificial intelligence (AI) model, a sensor management circuit system, a hardware circuit system, a data exposure circuit system, 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 be connected 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, comprising: O-RAN Centralized Unit (O-CU); at least one O-RAN distributed unit (O-DU); At least an O-RAN Radio Unit (O-RU); a real-time (RT) RAN intelligent controller (RIC) coupled to the at least O-DU via an interface and configured to host at least one application, the at least one application controlling the at least one O-DU on a real-time control loop with a latency of less than 10 ms; Non-RT (non-RT) RIC, configured to manage resources and events with latency equal to or greater than 1 second; Near-RT RICs, configured to manage resources and events with latencies of 10ms to 1 second; as well as A service management and orchestrator (SMO) platform, wherein the RT RIC performs at least one of the following alone or in any combination: is connected to the SMO via a first interface, is connected to the non-RTRIC via a second interface, is connected to the near-RT RIC via a third interface, is connected to a RAN network element via a fourth interface, or is connected to the O-RU via a fifth interface.

11. The O-RAN wireless communication system according to claim 10, wherein the RT RIC is collocated with the at least one O-DU.

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

13. The O-RAN wireless communication system of claim 10, wherein the RT RIC is coupled to a fronthaul multiplexer (FHM).

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, the 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 system.

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

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 according to claim 14 , wherein the RT RIC is configured to be connected with a primary O-DU and a secondary O-DU when carrier aggregation is performed.

18. A method for implementing a real-time (RT) radio interface controller (RIC) in an open radio access network (O-RAN), the method comprising: connecting the RT RIC to at least one O-RAN distributed unit (O-DU) via an interface; as well as At least one application is hosted by the RT RIC, and the at least one application controls the at least one O-DU via the interface in a real-time control loop with a latency of less than 10 ms.

19. The method according to claim 18, further comprising: Communicate with each of the multiple sub-modules of the RT RIC via at least one open API among a plurality of open application programming interfaces (APIs), each of the plurality of open APIs hosting at least one application, the at least one application enabling communication with at least one of the multiple sub-modules of the RT RIC via a messaging infrastructure.

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

Images