Real-time RIC Architecture for Open RAN Networks

Abstract

A system for providing real-time services and capabilities in an Open Radio Access Network (O-RAN) architecture comprises a first physical node comprising at least one first processor configured to execute instructions to implement an O-RAN Centralized Unit (O-CU); at least one second physical node comprising at least one second processor configured to execute instructions to implement an O-RAN Distributed Unit (O-DU) and a real-time (RT) RAN Intelligent Controller (RIC) connected to the O-DU via an interface terminating in a RT RIC and having a latency of less than 10 ms; an O-RAN Radio Unit (O-RU); at least one third physical node comprising at least one third processor configured to execute instructions to implement a Non-Real-Time (Non-RT) RIC operating on a time scale greater than 1 second; and at least one fourth physical node comprising at least one fourth processor configured to execute instructions to implement a Near-Real-Time (Near-RT) RIC operating on a time scale between 10 ms and 1 second. The RT RIC is a software platform configured to host applications for controlling at least an O-DU via a real-time control loop with a latency of less than 10 ms.

Description

[Background technology]

[0001] The Radio Access Network (RAN) is a critical component in telecommunications systems because it connects end-user devices (or user equipment) to the rest of the network. The RAN includes a combination of various Network Elements (NEs) that connect end-user devices to the core network. Traditionally, the hardware and / or software of a particular RAN is vendor specific.

[0002] Open RAN (O-RAN) technology has emerged to enable multiple vendors to provide hardware and / or software for telecommunication systems. To this end, O-RAN decomposes RAN functions into a centralized unit (CU), a distributed unit (DU), and a radio unit (RU). The 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. The DU is a logical node for hosting the Radio Link Control (RLC), Media Access Control (MAC), and Physical (PHY) sublayers of the RAN. The RU is a physical node that converts radio signals from the antenna into digital signals that can be transmitted to the DU via the fronthaul. These entities can be developed by different vendors because they have open protocols and interfaces between them.

[0003] Figure 1 shows the O-RAN architecture of the related art. Referring to Figure 1, RAN functions in the O-RAN architecture are controlled and optimized by a RAN Intelligent Controller (RIC). The RIC is a software-defined component that implements modular applications to facilitate (support) the multi-vendor operability required in an O-RAN system and to automate and optimize RAN operations. RICs are divided into two types: non-real-time RICs (Non-RT RICs) and near-real-time RICs (Near-RT RICs).

[0004] The Non-RT RIC is the control point for non-real-time control loops and operates on sub-second timescales within a Service Management and Orchestration (SMO) framework. Its functionality is implemented via modular applications called rApps and includes providing policy-based guidance and reinforcement over the A1 interface, which is the interface that enables communication between the Non-RT RIC and the Near-RT RIC; performing data analytics, i.e., artificial intelligence / machine learning (AI / ML) training and inference for RAN optimization; and / or recommending configuration management actions over the O1 interface, which is the interface that connects the SMO to RAN managed elements (e.g., Near-RT RIC, O-RAN Centralized Unit (O-CU), O-RAN Distributed Unit (O-DU), etc.).

[0005] The Near-RT RIC operates on a timescale between 10 milliseconds and 1 second and connects to the O-DU, the O-CU (separated into the O-CU control plane (O-CU-CP) and the O-CU user plane (O-CU-UP)), and the Open evolved NodeB (O-eNB) via the E2 interface. The Near-RT RIC uses the E2 interface to control the underlying RAN elements (E2 nodes) via a near-real-time control loop. The Near-RT RIC implements four services for the E2 nodes (O-CU, O-DU, and O-eNB): reporting (requesting nodes to report function-specific value settings), insertion (commanding nodes to activate user plane functions), control (commanding nodes to activate control plane functions), and policy (setting policy parameters for one of the activated functions). Additionally, the Near-RT RIC hosts xApps to implement functions such as interference mitigation, load balancing, and security. The two types of RICs work together to optimize O-RAN, for example, the Non-RT RIC provides policies, data, and AI / ML models that are implemented and used by the Near-RT RIC for RAN optimization.

[0006] The SMO framework, in which the Non-RT RIC is located, manages and orchestrates RAN elements. Specifically, the SMO manages and orchestrates what is called the O-Ran Cloud (O-Cloud). The O-Cloud is a collection of physical RAN nodes that host the RIC, O-CU, and O-DU, supporting software components (e.g., operating systems and runtime environments), and the SMO itself. In other words, the SMO manages the O-Cloud from within.

[0007] As described above, intelligent management of O-RAN functions in related art can only be performed for events and resources with a response time of 1 second or more for non-RT RICs and 10 milliseconds (ms) for Near-RT RICs. That is, in related art, the minimum latency between the E2 node and the Near-RT RIC exceeds 10 ms. Such high-latency loops preclude the use of AI / ML and other multi-vendor intelligent management and control for real-time operation and control, such as within the O-DU control loop shown in Figure 1. Summary of the Invention

[0008] An aspect of one or more embodiments provides a novel Real-Time RIC (RT RIC) for performing O-RAN intelligent management in real time.

[0009] Aspects of one or more embodiments utilize the capabilities of Artificial Intelligence / Machine Learning (AI / ML) via the RT RIC to enable close integration of Radio Resource Management (RRM) in the Distributed Unit (DU) with AI models and reasoning.

[0010] According to an example embodiment, a system for providing real-time services and capabilities in an Open Radio Access Network (O-RAN) architecture includes a first physical node having at least one first processor configured to execute instructions to implement an O-RAN Centralized Unit (O-CU). The system also includes at least one second physical node having at least one second processor configured to execute instructions to implement an O-RAN Distributed Unit (O-DU) and a Real-Time (RT) RAN Intelligent Controller (RIC) connected to the O-DU via an interface terminating in the RT RIC and having a latency of less than 10 ms. The system also includes at least one third physical node having at least one third processor configured to execute instructions to implement an O-RAN Radio Unit (O-RU) and a Non-Real-Time (Non-RT) RIC operating on a time scale greater than 1 second. The system also includes at least one fourth physical node having at least one fourth processor configured to execute instructions to implement a Near-Real-Time (Near-RT) RIC operating on a time scale between 10 ms and 1 second. The RT RIC is a software platform configured to host applications for controlling at least an O-DU via a real-time control loop with a latency of less than 10 ms.

[0011] The RT RIC may be provided within the O-DU.

[0012] The RT RIC may be external to the O-DU.

[0013] The system may further include a service management and orchestration (SMO) framework in which the Non-RT RIC is located and configured to manage and orchestrate RAN elements, and a first interface connecting the RT RIC to the SMO to implement at least one management service.

[0014] The system may further include a second interface connecting the RT RIC to the Non-RT RIC, wherein via the second interface, the Non-RT RIC is configured to provide at least one of policy-based guidance, machine learning (ML) management, and enrichment information to the RT RIC to optimize the RAN.

[0015] The system may further include a third interface connecting the RT RIC to the Near-RT RIC, wherein via the third interface, the Near-RT RIC is configured to provide at least one of policy-based guidance, machine learning (ML) management, and enrichment information to the RT RIC to optimize the RAN.

[0016] The RT RIC may be configured to perform at least one of reporting, inserting, controlling, and policy services to the O-DU via the interface.

[0017] The RT RIC may be configured to perform at least one of interface management and service update functions for the O-DU via the interface.

[0018] The RT RIC may be configured to host at least one application for integrating at least one artificial intelligence (AI) / machine learning (ML) model into the radio resource management (RRM) functions of the O-DU to make decisions and / or inferences in real time.

[0019] The RT RIC may be configured to host at least one application for implementing cell-free massive MIMO functionality in real time.

[0020] The RT RIC may be configured to host at least one application for utilizing the MAC scheduler of the O-DU in real time.

[0021] The RT RIC may be configured to host at least one application for implementing a zero trust security framework in real time.

[0022] According to an example embodiment, an apparatus for implementing a real-time (RT) Radio Access Network (RAN) Intelligent Controller (RT RIC) in an Open RAN (O-RAN) system may include: a memory that stores instructions; and at least one processor configured to execute the instructions to host one or more applications for connecting to an O-RAN distributed unit (O-DU) via an interface and controlling at least the O-DU via the interface via a real-time control loop having a latency of less than 10 ms.

[0023] The at least one processor may be further configured to execute instructions to connect, via the first interface, to a service management and orchestration (SMO) framework for managing and orchestrating the RAN elements to implement at least one management service.

[0024] The at least one processor may be further configured to execute instructions to connect to the Non-RT RIC via a second interface and obtain at least one of policy-based guidance, machine learning (ML) management, and enrichment information from the Non-RT RIC via the second interface to optimize the O-RAN system.

[0025] The at least one processor may be further configured to execute instructions to connect to the Near-RT RIC via a third interface and obtain at least one of policy-based guidance, machine learning (ML) management, and enrichment information from the Near-RT RIC via the third interface to optimize the O-RAN system.

[0026] The at least one processor may be further configured to execute instructions to perform at least one of reporting, insertion, control, and policy services to the O-DU via the interface.

[0027] The at least one processor may be further configured to execute instructions to perform at least one of an interface management function and a service update function for the O-DU via the interface.

[0028] The at least one processor may be further configured to execute instructions and host at least one application for integrating at least one artificial intelligence (AI) / machine learning (ML) model into radio resource management (RRM) functionality of the O-DU to make decisions and / or inferences in real time.

[0029] The at least one processor may be further configured to execute instructions to host at least one application that utilizes the MAC scheduler of the O-DU in real time.

[0030] The features, advantages, and significance of exemplary embodiments of the present disclosure will now be described with reference to the accompanying drawings, in which like reference numerals refer to like elements. [Brief explanation of the drawings]

[0031] [Figure 1] FIG. 1 illustrates a related art O-RAN architecture.

[0032] [Figure 2A] FIG. 1 illustrates a general architecture of a real-time RIC (RT RIC) according to some exemplary embodiments. [Figure 2B] FIG. 1 illustrates a general architecture of a real-time RIC (RT RIC) according to some exemplary embodiments.

[0033] [Figure 3A] FIG. 1 illustrates a general architecture of a RT RIC in a shared cell configuration with a fronthaul distribution unit (FHM) according to some demonstrative embodiments. [Figure 3B] FIG. 1 illustrates a general architecture of a RT RIC in a shared cell configuration with a fronthaul distribution unit (FHM) according to some demonstrative embodiments. [Figure 3C] FIG. 1 illustrates a general architecture of a RT RIC in a shared cell configuration with a fronthaul distribution unit (FHM) according to some demonstrative embodiments. [Figure 3D] FIG. 1 illustrates a general architecture of a RT RIC in a shared cell configuration with a fronthaul distribution unit (FHM) according to some demonstrative embodiments.

[0034] [Figure 4] FIG. 1 illustrates an O-RAN architecture, according to one or more exemplary embodiments.

[0035] [Figure 5] FIG. 2 illustrates a block diagram of an RT RIC in accordance with one or more exemplary embodiments.

[0036] [Figure 6] FIG. 1 illustrates a split 7.2 O-RAN system.

[0037] [Figure 7] FIG. 1 illustrates a MAC scheduler architecture for a wireless access network.

[0038] [Figure 8] FIG. 1 illustrates a frame structure for a Time Division Duplex (TDD) system.

[0039] [Figure 9] FIG. 1 illustrates an O-CU, O-DU, and O-RU architecture in an O-RAN system.

[0040] [Figure 10] 1 is a flowchart of a method for implementing a RT RIC in an O-RAN system according to one or more exemplary embodiments.

[0041] [Figure 11] 1 is a flowchart of a method for providing services by an RT RIC according to an example embodiment.

[0042] [Figure 12] FIG. 1 is a diagram of components of one or more devices in accordance with an exemplary embodiment. DETAILED DESCRIPTION OF THE INVENTION

[0043] The following detailed description of the exemplary embodiments refers to the accompanying drawings, in which the same reference numbers in different drawings may refer to the same or similar elements.

[0044] The foregoing disclosure provides illustration and description, but is not intended to be exhaustive or to limit implementations to the precise form disclosed. Modifications and variations are possible in light of the above disclosure or may be acquired from practice of the implementations. Moreover, one or more features or components of one embodiment may be incorporated into or combined with another embodiment (or one or more features of another embodiment). Furthermore, in the flowcharts and descriptions of operations provided below, it is understood that one or more operations may be omitted, one or more operations may be added, one or more operations may be performed (at least partially) concurrently, and the order of one or more operations may be permuted.

[0045] It will be 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 specialized 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. It will be understood that software and hardware can be designed to implement the systems and / or methods based on the description herein.

[0046] Although particular combinations of features are recited in the claims and / or disclosed herein, these combinations are not intended to limit the disclosure of possible implementations. Indeed, many of these features may be combined in ways not specifically recited in the claims and / or disclosed herein. Although each dependent claim listed below may depend directly on only one claim, the disclosure of possible implementations includes each dependent claim in combination with every other claim recited in the claims.

[0047] No element, act, or instruction used herein should be construed as critical or essential unless explicitly described as such. Additionally, as used herein, the articles "a" and "an" are intended to include one or more items and may be used interchangeably with "one or more." Where only one item is intended, the term "one" or similar language is used. Additionally, as used herein, terms such as "has," "have," "having," "include," and "including" are intended to be open-ended terms. Furthermore, the phrase "based on" is intended to mean "based at least in part on," unless expressly stated otherwise. Furthermore, phrases such as "at least one of [A] and [B]" and "at least one of [A] or [B]" should be understood to include A only, B only, or both A and B.

[0048] As described above, related art RICs are implemented as part of near-real-time control loops (10 ms to 1 sec) and non-real-time control loops (greater than 1 sec). Due to their distance from the radio units and their specific protocol stack implementations, related art RICs cannot accommodate real-time events or functions, such as the 1 ms control loop required for a MAC scheduler operating in an O-DU, which must be located close to the O-RU it manages. As a result, any implementation of real-time services or control requires direct integration into the vendor-specific or proprietary software stack of the baseband receiver / transmitter or O-DU, which is blocked and inaccessible to other vendors.

[0049] An exemplary embodiment provides a Real Time RIC (RT RIC), which resides near or within the DU (or near the physical and / or MAC layers of the DU) and is therefore part of the DU-RU real-time control loop to respond to real-time functions and events in the radio access network. Additionally, the RT RIC is connected to other O-RAN network elements using open or standardized interfaces, thereby enabling multi-vendor applications or microservices to be hosted therein to provide real-time intelligent control and services.

[0050] Real-time RIC Architecture for Open RAN Networks The following describes a real-time RIC architecture for an O-RAN network according to example embodiments. Figures 2A and 2B illustrate a general architecture of a real-time RIC (RT RIC) according to some example embodiments. Referring to Figure 2A, according to one embodiment, the RT RIC is external to the O-DU and connected to it via an interface or API. Referring to Figure 2B, according to another embodiment, the RT RIC is within the O-DU and directly connected to one or more units within the O-DU via an interface, where the interface is either a standards-based interface (e.g., 3GPP, O-RAN, ITU, CNCF, TMF standard) or a proprietary interface.

[0051] According to example embodiments, the RT RIC is integrated into or adjacent to the physical and MAC layers of the O-DU so that it can provide real-time services and features with a latency of less than 10 ms. Furthermore, according to one or more example embodiments, the RT RIC, unlike the RICs of the related art, connects to only one O-DU.

[0052] It will be appreciated that one or more embodiments are not limited to the above configurations. For example, according to another embodiment, the RT RIC may be directly connected to a fronthaul distribution unit (FHM) in a shared cell configuration (i.e., multiple RUs are connected to the same DU through the FHM), or may be directly connected to both the O-DU and the FHM.

[0053] 3A-3D are diagrams illustrating a general architecture of an RT RIC in a shared cell configuration with FHM according to some exemplary embodiments. That is, an RT RIC according to exemplary embodiments may be integrated into an O-RAN system operating in a shared cell configuration with FHM mode. Referring to FIG. 3A, according to one embodiment, the RT RIC is connected to the O-DU via a standard or proprietary interface. Referring to FIG. 3B, according to another embodiment, the RT RIC is integrated into the same unit as the O-DU. In this case, the RT RIC may be implemented in the same processor (e.g., CPU, GPU, or any hardware accelerator) as the O-DU, or in a different processor on 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.

[0054] As mentioned above, in some exemplary embodiments, the RT RIC may be connected to or integrated with the FHM. Referring to FIG. 3C, according to one embodiment, the RT RIC is connected to the FHM via a standard or proprietary interface. Referring to FIG. 3D, according to another embodiment, the RT RIC is integrated within the same unit as the FHM. As with the embodiment of FIG. 3B, in this case, the RT RIC may 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 enclosure, or within a separate enclosure within the same rack, or within a separate rack within the same data center. According to one or more exemplary embodiments, 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.

[0055] 4 illustrates an O-RAN architecture according to one or more embodiments. In comparison to FIG. 1, the O-RAN architecture of this exemplary embodiment includes a RT RIC and multiple interfaces for interconnecting the RT RIC to other units in the O-RAN architecture.

[0056] Referring to FIG. 4, a first interface (labeled the P1 interface, but as a non-limiting example) connects the RT RIC to the SMO. The first interface may be an operations and maintenance interface implemented 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 for Provisioning 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 one or more services such as fault supervision 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 first interface is the O1 interface for the Near-RT RIC, as specified in "O-RAN.WG1.O1-Interface.0-v04.00" and shown in FIG. 1.

[0057] A second interface (labeled P2 interface, but is a non-limiting example) connects the RT RIC to the Non-RT RIC. The second interface allows the Non-RT RIC to provide policy-based guidance, ML model management, and enrichment information to the RT RIC 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. In another embodiment, the second interface is the A1 interface defined between the Non-RT RIC and the Near-RT RIC as specified in "O-RAN.WG2.A1GAP-v02.02" and shown in FIG. 1.

[0058] A third interface (labeled P3 interface, but is a non-limiting example) connects the RT RIC to the Near-RT RIC. The third interface allows the Near-RT RIC to provide policy-based guidance, ML model management, and enrichment information to the RT RIC to optimize the RAN. In one embodiment, the protocol stack of the third interface includes one or more layers, such as IP, TCP, HTTPS, JSON, and / or any other proprietary or standard layers. In another embodiment, the third interface is the A1 interface defined between the Non-RT and Near-RT RICs specified in "O-RAN.WG2.A1GAP-v02.02" and shown in FIG. 1.

[0059] A fourth interface (labeled P4 interface, by way of non-limiting example) connects the RT RIC to at least one of the network elements, e.g., the O-DU, the O-CU-CP, the O-CU-UP, or the O-eNB. The fourth interface enables different RT RIC services (e.g., reporting, insertion, control, and policy) and support functions (e.g., interface management, service updates, etc.). In another embodiment, the fourth interface may be the E2 interface defined for the Near-RT RIC, as specified in "O-RAN.WG3.E2GAP-v01.01" and shown in FIG. 1.

[0060] A fifth interface (labeled the P5 interface, but is a non-limiting example) connects the RT RIC to the O-RU. The fifth interface is a direct logical channel or interface used to exchange data and / or control information between the RT RIC and one or more O-RUs by implementing the control, user plane, and synchronization plane. In one embodiment, the P5 interface may be the open fronthaul interface specified in "O-RAN.WG4.CUS.0-v07.00" and shown in Figure 1.

[0061] It will be understood that one or more other embodiments are not limited to the O-RAN architecture described above with reference to Figure 4. For example, it will be understood that one or more of the interfaces described above may be omitted and / or one or more additional or different interfaces may be included (e.g., the interface between the RT RIC and the FHM described above with reference to Figures 3C and 3D).

[0062] FIG. 5 is a block diagram of an RT RIC according to one or more exemplary embodiments. Referring to FIG. 5, the RT RIC includes first (P2), second (P3), and third (P4) interface terminations for the P2, P3, and P4 interfaces, respectively. The RT RIC is a software-defined component that hosts one or more microservices or applications (referred to herein as zApps, by way of non-limiting example). A zApp implements methods or techniques for providing services, automation, control, optimization, etc. on a real-time basis (or with less than 10 ms latency). A zApp communicates with Near-RT RICs, Non-RT RICs, and other network components (e.g., O-DU, O-CU-CP, O-CU-UP, O-eNB) via the RT RIC's aforementioned interfaces. A zApp is implemented via a proprietary or alternatively standard-defined multi-vendor interface. According to example embodiments, zApps communicate through open interfaces, allowing them to be developed by multiple vendors and integrated into the O-RAN without opening the source code or proprietary software or requiring access to the application's source code by the O-RAN operator (e.g., carrier) or O-Cloud operator (e.g., carrier or third-party data center) to integrate into the network.

[0063] A zApp implements one or more of the use cases described below, or methods or techniques for any proprietary application or any third-party vendor application.

[0064] Exemplary Use Case 1: AI / ML-based Physical Layer Enhancement An RT RIC according to example embodiments may host one or more zApps to effectively integrate AI / ML models into the DU's real-time radio resource management (RRM) functions. Because the RT RIC according to example embodiments provides an open platform for hosting applications or microservices, such AI / ML models and corresponding applications can be developed by any of multiple vendors and providers and integrated into the network without opening / sharing any source code and without relying on a telco or O-RAN operator solution.

[0065] More specifically, the RIC, as described above, provides a standard framework for introducing the intelligence required to achieve automation and autonomy into the RAN using standard open interfaces and leveraging AI / ML in the development of intelligent applications for network engineering, optimization, and operation.

[0066] In related technologies of the O-RAN framework, the minimum latency between the DU and the Near-RT RIC exceeds 10 ms. Such high-latency loops preclude the use of AI / ML for actual channel estimation via low-level measurements and other RRM functions such as scheduling, because AI / ML-based channel estimation requires tight coupling with low-level RF measurements.

[0067] Leveraging AI / ML capabilities via the RT RIC (e.g., latency <10 ms) according to example embodiments enables tight integration of RRM in the DU with AI / ML models and inference. As examples, the following use cases are possible with RT RIC integration of AI / ML in O-DU RRM via AI / ML models or inference: Enhanced channel estimation and CSI feedback, including reduced overhead, increased accuracy, and prediction. Improved beam management including in-time beam prediction, improved beam selection accuracy. · Improved RRM with low level measurements. Enhanced user positioning accuracy for various scenarios, including non-line-of-sight (NLOS) conditions. Advanced digital modulation techniques that use AI / ML to improve demodulation and error rates. For example, bit error rates can be reduced by training-based blind channel estimation.

[0068] Exemplary Use Case 2: Cell-Free Massive MIMO An RT RIC according to an example embodiment can host one or more zApps to effectively implement cell-free massive multiple-input multiple-output (MIMO).

[0069] Due to the growing popularity of applications requiring high-definition video streaming and low-latency Internet of Things (IoT) connectivity, the demand for wireless data is growing at a very rapid pace year after year. This demand can be met by increasing the capacity of cellular networks operating in the sub-6 GHz spectrum, for example, through cell densification to increase spectral efficiency per unit area. However, communications theory and actual field tests have shown that there are physical limits to cell densification, as increased inter-cell interference significantly degrades signal integrity within each cell, resulting in reduced total capacity. This effect is particularly exacerbated in indoor environments and large venues, especially with steel structures that generate numerous multipath reflections and therefore high levels of inter-cell interference.

[0070] One approach to addressing the physical limitations of cell densification is to completely eliminate inter-cell interference by using cell-free massive MIMO technology. Cell-free massive MIMO technology involves a large number of access points distributed over a wide area to coherently serve a large number of user terminals in the same time / frequency band. These technologies have the potential to increase cellular network capacity by more than ten times. As background, the first-ever practical testbed for this class of technology was originally called distributed-input distributed-output technology. The same technology was later implemented in the first-ever LTE vRAN cellular infrastructure product and named personal cell (pCell) technology. This technology was subsequently widely adopted by academia and renamed cell-free massive MIMO. Currently, cell-free massive MIMO, under the name of multiple transmit / receive points (multi-TRP), is considered by the wireless industry as one of the core technologies for 5G and 5G-Advanced from 3GPP Rel. 17 onwards, and for the next generation 6G standards.

[0071] Cell-free massive MIMO is very different from related-art massive MIMO technologies that have centralized antenna arrays. By distributing antennas over a wide area, wireless channels at different antennas experience uncorrelated long-term channel statistics, which can be exploited to achieve "macro-diversity" gains. In contrast, in related-art massive MIMO systems, all antennas from the same array experience the same path loss and shadowing, resulting in degraded performance. Furthermore, unlike cell-free massive MIMO systems, which eliminate inter-cell interference (ICI) throughout the coverage area, related-art massive MIMO systems, like traditional cellular technologies, are degraded by ICI at the cell edge.

[0072] Related art massive MIMO systems use digital or analog beamforming with local processing in the radio units (RUs) of split 7.2 systems, as shown in Figure 6, because beamforming weights are calculated only for antennas connected to the same RU. Therefore, there is no need for any RIC implementation in related art massive MIMO systems, as all processing for one antenna array is implemented in the RU. In contrast, cell-free massive MIMO systems precode waveforms across multiple RUs (each RU is coupled with one or more antennas). Therefore, precoding must be implemented on the DU side.

[0073] 6, in a related art O-RAN system, each DU protocol stack generates in-band and quadrature (IQ) samples for only one RU, even in a shared cell configuration with multiple RUs connected to the same DU via FHM. In contrast, cell-free massive MIMO precoding methods are applied to multiple or all IQ data streams transmitted from one DU to multiple RUs.

[0074] The two types of RICs defined in related art O-RAN systems operate on timescales exceeding one second for non-RT RICs, or on timescales of 10 ms to one second for near-RT RICs, as shown in Figure 1. These are not sufficient to address the strict real-time constraints required by cell-free massive MIMO technology. However, practical implementation of cell-free massive MIMO requires stable calibration of RF components for channel reciprocity, strict synchronization of RUs, and timing accuracy on much shorter timescales to ensure real-time implementation of signal processing algorithms, in order to adapt waveforms transmitted and received via RUs to changing channel conditions using precoding techniques.

[0075] Because the RT RIC according to the exemplary embodiment operates on sub-10 ms timescales, it is capable of hosting zApps that implement new features for cell-free massive MIMO.

[0076] Exemplary Use Case 3: Advanced Scheduling One of the key functions of the Medium Access Control (MAC) layer in LTE, 5G-NR, or any wireless system is the scheduler. The MAC scheduler implements different functions, as shown in Figure 7, including: Allocating downlink (DL) or uplink (UL) bandwidth by allocating channel resources in the time, frequency or spatial domain to different UEs based on information such as Channel Quality Indicators (CQI) from the User Equipment (UE) or RU, or buffer status reports from the Radio Link Control (RLC) layer. Enforcing Quality of Service (QoS) rules from Policy and Changing Rules Functions (PCRF) in the core network based on information such as packet loss rate, maximum guaranteed / allowed bandwidth, and relative user priority.

[0077] Dynamic bandwidth assignment to UEs is typically achieved by assigning specific resource blocks (RBs) to the UE based on their channel conditions. This channel assignment must occur within a very short time frame. For example, in a time division duplex (TDD) system with the frame structure shown in Figure 8, an O-RAN DU (O-DU) may have only 5 ms between receiving a channel quality indicator (CQI) from the UE via the uplink (UL) and the next CQI set becoming available via the next UL transmission. Furthermore, the UE's RF channel may change very rapidly within that 5 ms, depending on their mobility, causing the current set of CQIs to become outdated by the next UL transmission. Therefore, to operate effectively, the MAC scheduler must operate on a timescale of less than 10 ms. This issue is even more relevant to 5G-NR frames, where UL / DL switching can occur on a sub-millisecond scale, depending on the frame configuration.

[0078] Furthermore, PCRF rules in the core network may vary by operator and use case, which may require different QoS KPIs, such as enhanced mobile broadband (eMBB), ultra-reliable low latency communications (URLLC), or massive machine-type communications (mMTC). Depending on the specific application, different operators may implement their QoS rules and upgrade their MAC schedulers or design their own scheduling techniques to meet their specific KPIs. If the MAC scheduler is implemented within the O-DU as shown in Figure 9, updating the MAC scheduler requires a complete update of the entire O-DU, which may disrupt network operation.

[0079] An RT RIC according to example embodiments can operate or utilize a MAC scheduler on a timescale of less than 10 ms, while allowing operators to upgrade and customize their own MAC scheduler via applications and microservices without disrupting network operation. Additionally, an RT RIC according to example embodiments can run the MAC scheduler externally, thereby enabling customization of O-DU functionality via other real-time applications such as advanced massive MIMO or radio resource management (RRM) methods. For example, a zApp hosted by the RT RIC can implement different energy-saving algorithms designed to turn antennas in a massive MIMO array on and off based on user CQI and scheduler decisions that occur on a timescale of less than 10 ms.

[0080] As another example, an RT RIC according to an exemplary embodiment can host a zApp that uses the MAC scheduler of the DU to select UEs at the cell edge versus the cell center, providing an advanced energy conservation method for massive MIMO systems. That is, a zApp hosted on an RT RIC according to one embodiment can turn on / off antennas in an array based on groups of UEs at the cell edge versus the cell center. Such dynamic antenna switching occurs on a sub-5 ms scale in LTE and 5G-NR and therefore cannot be implemented using the non-real-time or quasi-real-time control loops of related art RICs.

[0081] Exemplary Use Case 4: Real-time observability and security at the edge The related art O-RAN architecture does not allow for dynamic injection of security controls into the O-RU based on up-to-date metadata derived from control or user plane packets. In particular, the related art architecture lacks the programmable ability at the O-RU or O-DU to a) digest data received from an observability platform on the O-RU or O-DU, b) cooperate with other parameters potentially available via other sources, and c) implement new security actions by introducing new security controls / policies with real-time latency.

[0082] In the era of zero trust, attacks are detected and handled at the point of occurrence, avoiding the risk of lateral movement within the affected platform or the spread of the threat to other parts of the network via external interfaces. Due to its real-time timescale, an RT RIC according to an example embodiment can host zApps to enable a zero-trust security framework. For example, an RT RIC can host one or more zApps to facilitate the real-time implementation of: a) A real-time observability platform for critical assets such as O-RUs and O-DUs that collects and / or reports information on the current state of assets, network infrastructure, and communications. b) Continuously analyze the reported data and impose necessary security controls in real time to improve the security posture of affected assets. c) Dynamically push security policies to detect and mitigate zero-day attacks that are not detected by existing tools. d) Pushing security-centric information to upstream devices for later analysis, which can be used to refine policies and / or alert on potential attacks against critical / exposed assets (such as O-RU).

[0083] Exemplary Use Case 5: Upgrading AI / ML Models and Inference via zApp In a related art implementation of the O-DU protocol stack within O-RAN, the O-DU is a monolithic Virtualized Network Function (VNF) with all software (SW) components from a single vendor. This SW architecture can only be useful if the O-DU performs pre-programmed functions.

[0084] However, when machine learning models and inferences that need to be dynamically updated based on the latest training data are placed in the O-DU SW stack, the SW architecture must enable upgrades of the AI / ML models. The RT RIC according to an example embodiment can host zApps to facilitate the upgrade or upgrade of AI / ML models or inferences within the O-DU. In this regard, the RT RIC according to an example embodiment may implement several policies to avoid conflicts between various zApps and the functionality of the O-DU itself. For example, lifecycle management of AI / ML models and inferences within the O-DU may be standardized or controlled by policies defined or implemented via the RT RIC.

[0085] As a further example, an RT RIC may implement policies according to an exemplary embodiment that restrict zApps running thereon (on the RT RIC) to only be able to install, update, delete, or suspend AI / ML models or inferences for which they have rights assigned by the framework (e.g., the RT RIC) that controls the zApp. Other processes such as model training (including input / output, online / offline), model validation, model testing, inference operations, training datasets, validation, and testing may also be defined and implemented according to policies for conflict management between zApps and O-DU functions.

[0086] 10 is a flowchart of a method for implementing an RT RIC in an O-RAN system according to one or more exemplary embodiments. Referring to FIG. 10, in operation S100, an RT RIC according to an exemplary embodiment is connected to an O-DU via an interface to enable real-time (i.e., less than 10 ms) management and control. For example, the RT RIC may be integrated within and / or near the O-DU to connect to the physical layer and / or MAC layer with a latency of less than 10 ms.

[0087] In operation S200, a zApp hosted on the RT RIC is executed to provide real-time services and / or functions for the O-RAN system.

[0088] 11 is a flowchart of a method for providing services by an RT RIC according to an exemplary embodiment. Referring to FIG. 11, in operation S1100, the RT RIC performs a reporting operation to a node (at least one of an O-DU, an O-CU, an O-RU, or an O-eNB) over a real-time control loop. For example, in operation S1100, the RT RIC may request the node to report function-specific value settings.

[0089] In operation S1110, the RT RIC performs an insertion operation on a node (at least one of an O-DU, an O-CU, an O-RU, or an O-eNB) over a real-time control loop. For example, in operation S1110, the RT RIC may instruct the node to activate a user plane function.

[0090] In operation S1120, the RT RIC performs a control operation on a node (at least one of an O-DU, an O-CU, an O-RU, or an O-eNB) over a real-time control loop. For example, in operation S1120, the RT RIC may instruct the node to activate a control plane function.

[0091] In operation S1130, the RT RIC implements a policy operation for a node (at least one of an O-DU, an O-CU, an O-RU, or an O-eNB) over a real-time control loop. For example, in operation S1130, the RT RIC may set policy parameters for one of the activated functions.

[0092] According to an exemplary embodiment, the RT RIC hosts one or more zApps that can subscribe to one or more of the above-mentioned services (reporting, insertion, control, and policy).

[0093] It will be understood that one or more of the operations in Figure 11 may be omitted and / or one or more additional or different operations may be added. Furthermore, it will be understood that the operations shown in Figure 11 may be performed in any order.

[0094] FIG. 12 is a diagram of components of one or more devices according to an example embodiment.

[0095] The device 1100 may correspond to any of the devices described above (eg, a device hosting an RT RIC).

[0096] 11, device 1100 may include a bus 1110, a processor 1120, a memory 1130, a storage component 1140, and a communication interface 1150. It will be understood that one or more of the above components may be omitted and / or one or more additional components may be included.

[0097] The bus 1110 includes components that enable communication between the components of the device 1100. The processor 1120 is implemented in hardware, firmware, or a combination of hardware and software. The processor 1120 may be a central processing unit (CPU), a graphics processing unit (GPU), an accelerated processing unit (APU), a microprocessor, a microcontroller, a digital signal processor (DSP), a field programmable gate array (FPGA), an application specific integrated circuit (ASIC), or another type of processing component. The processor 1120 includes one or more processors that can be programmed to perform functions.

[0098] Memory 1130 may include random access memory (RAM), read-only memory (ROM), and / or another type of dynamic or static storage device (e.g., flash memory, magnetic memory, and / or optical memory) that stores information and / or instructions for use by processor 1120.

[0099] Storage component 1140 stores information and / or software related to the operation and use of device 1100. For example, storage component 1140 may include a hard disk (e.g., a magnetic disk, optical disk, magneto-optical disk, and / or solid-state disk), a compact disk (CD), a digital versatile disk (DVD), a floppy disk, a cartridge, a magnetic tape, and / or another type of non-transitory computer-readable medium along with a corresponding drive.

[0100] The communication interface 1150 includes transceiver-like components (e.g., a transceiver and / or a separate receiver and transmitter) that enable the device 900 to communicate with other devices via a wired connection, a wireless connection, or a combination of wired and wireless connections, etc. The communication interface 1150 may enable the device 1100 to receive information from another device and / or provide information to another device. For example, the communication interface 1150 may include an Ethernet interface, an optical interface, a coaxial interface, an infrared interface, a radio frequency (RF) interface, a universal serial bus (USB) interface, a Wi-Fi interface, a cellular network interface, etc.

[0101] Device 1100 may perform one or more processes or functions described herein. Device 1100 may perform operations based on processor 1120 executing software instructions stored by a non-transitory computer-readable medium, such as memory 1130 and / or storage component 1140. A computer-readable medium is defined herein as a non-transitory memory device. A memory device includes memory space within a single physical storage device or memory space across multiple physical storage devices.

[0102] The software instructions may be loaded into memory 1130 and / or storage component 1140 from another computer-readable medium or from another device via communications interface 1150. When executed, the software instructions stored in memory 1130 and / or storage component 1140 may cause processor 1120 to perform one or more processes described herein.

[0103] Additionally, or instead, hardwired circuitry may be used in place of or in combination with software instructions to implement one or more of the processes described herein. Thus, the embodiments described herein are not limited to any specific combination of hardware circuitry and software.

[0104] The foregoing disclosure provides illustration and description, but is not intended to be exhaustive or to limit the implementation to the precise form disclosed. Modifications and variations are possible in light of the above disclosure or may be acquired from practice of the implementations.

[0105] Some embodiments may relate to systems, methods, and / or computer-readable media at any possible level of technical detail of integration. Furthermore, one or more of the components described above may be implemented as instructions stored on a computer-readable medium and executable by at least one processor (and / or may include at least one processor). The computer-readable medium may include one or more computer-readable non-transitory storage media having computer-readable program instructions for causing a processor to perform operations.

[0106] A computer-readable storage medium may be a tangible device that can hold and store instructions for use by an instruction-execution device. A computer-readable storage medium may be, for example, but not limited to, an electronic storage device, a magnetic storage device, an optical storage device, an electromagnetic storage device, a semiconductor storage device, or any suitable combination thereof. A non-exhaustive list of more specific examples of computer-readable storage media includes the following: portable computer diskettes, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), static random access memory (SRAM), portable compact disc read-only memory (CD-ROM), digital versatile disc (DVD), memory sticks, floppy disks, mechanically encoded devices such as punch cards or ridge structures in grooves with instructions recorded thereon, and any suitable combination thereof. As used herein, computer-readable storage media should not be construed as being transitory signals themselves, such as radio waves or other freely propagating electromagnetic waves, electromagnetic waves propagating through a waveguide or other transmission medium (e.g., light pulses passing through a fiber optic cable), or electrical signals transmitted through wires.

[0107] The computer-readable program instructions described herein can be downloaded from a computer-readable storage medium to each computing / processing device or to an external computer or external storage device via a network, such as the Internet, a local area network, a wide area network, and / or a wireless network. The network may include copper transmission cables, optical transmission fiber, wireless transmission, routers, firewalls, switches, gateway computers, and / or edge servers. A network adapter card or network interface in each computing / processing device receives the computer-readable program instructions from the network and forwards the computer-readable program instructions for storage in a computer-readable storage medium in the respective computing / processing device.

[0108] The computer-readable program code / instructions for carrying out operations may be either source code or object code written in any combination of one or more programming languages, including assembler instructions, instruction set architecture (ISA) instructions, machine instructions, machine-dependent instructions, microcode, firmware instructions, state setting data, configuration data for integrated circuits, or object-oriented programming languages ​​such as Smalltalk, C++, and procedural programming languages ​​such as the "C" programming language or similar programming languages. The computer-readable program instructions may execute entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In the latter scenario, the remote computer may be connected to the user's computer through any type of network, including a local area network (LAN) or a wide area network (WAN), or may be connected to an external computer (e.g., through the Internet using an Internet Service Provider). In some embodiments, electronic circuitry including, for example, programmable logic circuitry, a field programmable gate array (FPGA), or a programmable logic array (PLA) can execute computer-readable program instructions by utilizing state information of the computer-readable program instructions to personalize the electronic circuitry to perform aspects or operations.

[0109] These computer-readable program instructions may be provided to a processor of a general-purpose computer, a special-purpose computer, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute on the processor of the computer or other programmable data processing apparatus, create means for implementing the functions / acts specified in one or more blocks of the flowcharts and / or block diagrams. These computer-readable program instructions may also be stored on a computer-readable storage medium that can direct a computer, programmable data processing apparatus, and / or other device to function in a particular manner, such that the computer-readable storage medium on which the instructions are stored comprises a product including instructions that implement aspects of the functions / acts specified in one or more blocks of the flowcharts and / or block diagrams.

[0110] The computer-readable program instructions may also be loaded onto a computer, other programmable data processing apparatus, or other device to cause the computer, other programmable apparatus, or other device to perform a series of operational steps to generate a computer-implemented process, such that the instructions executing on the computer, other programmable apparatus, or other device implement the functions / acts specified in one or more blocks of the flowcharts and / or block diagrams.

[0111] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer-readable media according to various embodiments. In this regard, each block in the flowcharts or block diagrams may represent a module, segment, or portion of instructions, which includes one or more executable instructions for implementing the specified logical function(s). The methods, computer systems, and computer-readable media may include additional, fewer, different, or differently arranged blocks than those shown in the figures. In some alternative implementations, the functions noted in the blocks may occur in a different order than noted in the figures. For example, two blocks shown in succession may actually be executed concurrently or substantially concurrently, or the blocks may sometimes be executed in the reverse order, depending on the functionality involved. It should also be noted that each block of the block diagrams and / or flowchart diagrams, and combinations of blocks in the block diagrams and / or flowchart diagrams, can be implemented by a dedicated hardware-based system that performs the specified functions or operations or executes a combination of dedicated hardware and computer instructions.

[0112] It will be apparent that the systems and / or methods described herein may be implemented in various forms of hardware, firmware, or combinations of hardware and software. The actual specialized 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.

Claims

1. 1. A system for providing real-time services and capabilities in an Open Radio Access Network (O-RAN) architecture, comprising: a first physical node comprising at least one first processor configured to execute instructions to implement an O-RAN Centralization Unit (O-CU); Execute the command, an O-RAN distribution unit (O-DU); at least one second physical node comprising at least one second processor configured to implement a real-time (RT) RAN intelligent controller (RIC) terminated in the RT RIC and connected to the O-DU via an interface having a latency of less than 10 ms; an O-RAN radio unit (O-RU); and at least one third physical node comprising at least one third processor configured to execute instructions to implement a non-real-time (Non-RT) RIC operating on a time scale greater than one second; at least one fourth physical node comprising at least one fourth processor configured to execute instructions to implement a near real-time (Near-RT) RIC operating on a time scale of 10 ms to 1 second; a Service Management and Orchestration (SMO) framework for managing and orchestrating RAN elements; a first interface connecting the RT RIC to the SMO framework and terminating at the RT RIC and the SMO framework; a second interface connecting the RT RIC to the non-RT RIC and terminating at the RT RIC and the non-RT RIC; a third interface connecting the RT RIC to the Near-RT RIC and terminating at the RT RIC and the Near-RT RIC; the RT RIC is a software platform configured to host an application for controlling at least the O-DU via a real-time control loop with a latency of less than 10 ms, and configured to perform at least one of interface management and service update functions for the O-DU via the interface; The Near-RT RIC and the Non-RT RIC are separate, The system, wherein the first interface, the second interface, and the third interface are each separate from an E2 interface.

2. The system of claim 1 , wherein the RT RIC is provided within the O-DU.

3. The system of claim 1 , wherein the RT RIC is external to the O-DU.

4. The Non-RT RIC is placed within the SMO framework; the first interface connects the RT RIC to the SMO framework to implement at least one management service; The system of claim 1 .

5. 2. The system of claim 1, wherein, via the second interface, the Non-RT RIC is configured to provide at least one of policy-based guidance, machine learning (ML) management, and enrichment information to the RT RIC to optimize the RAN.

6. 10. The system of claim 1, wherein, via the third interface, the Near-RT RIC is configured to provide at least one of policy-based guidance, machine learning (ML) management, and enrichment information to the RT RIC to optimize the RAN.

7. The system of claim 1 , wherein the RT RIC is configured to perform at least one of reporting, user plane function activation, control, and policy services to the O-DU via the interface.

8. 2. The system of claim 1, wherein the RT RIC is configured to host at least one application for integrating at least one artificial intelligence (AI) / machine learning (ML) model into a radio resource management (RRM) function of the O-DU for making decisions and / or inferences in real time.

9. The system of claim 1 , wherein the RT RIC is configured to host at least one application for implementing functionality for cell-free massive MIMO in real time.

10. The system of claim 1 , wherein the RT RIC is configured to host at least one application for utilizing the MAC scheduler of the O-DU in real time.

11. 10. The system of claim 1, wherein the RT RIC is configured to host at least one application for implementing a zero trust security framework in real time.

12. 1. An apparatus for implementing a real-time (RT) radio access network (RAN) intelligent controller (RT RIC) in an open RAN (O-RAN) system, comprising: a memory for storing instructions; Execute the instructions, connecting to an O-RAN distribution unit (O-DU) via an interface; at least one processor configured to host one or more applications for controlling at least the O-DU via a real-time control loop having a latency of less than 10 ms via the interface, and configured to perform at least one of an interface management function and a service update function for the O-DU via the interface; Equipped with The at least one processor further executes the instructions to: connecting to a service management and orchestration (SMO) framework that manages and orchestrates RAN elements via a first interface that terminates at the RT RIC and the SMO framework; connecting to a non-RT RIC via a second interface terminating at the RT RIC and the non-RT RIC; to a Near-RT RIC via a third interface terminating at the RT RIC and the Near-RT RIC; The Near-RT RIC and the Non-RT RIC are separate, The device, wherein the first interface, the second interface, and the third interface are each separate from an E2 interface.

13. 13. The apparatus of claim 12, wherein the at least one processor is configured to execute the instructions to connect to the service management and orchestration (SMO) framework for managing and orchestrating RAN elements via the first interface to implement at least one management service.

14. 13. The apparatus of claim 12, wherein the at least one processor is further configured to execute the instructions to obtain at least one of policy-based guidance, machine learning (ML) management, and enrichment information from the Non-RT RIC via the second interface to optimize the O-RAN system.

15. 13. The apparatus of claim 12, wherein the at least one processor is further configured to execute the instructions to obtain at least one of policy-based guidance, machine learning (ML) management, and enrichment information from the Near-RT RIC via the third interface to optimize the O-RAN system.

16. 13. The apparatus of claim 12, wherein the at least one processor is further configured to execute the instructions to perform at least one of reporting, user plane function activation, control, and policy services to the O-DU via the interface.

17. 13. The apparatus of claim 12, wherein the at least one processor is further configured to execute the instructions to host at least one application for integrating at least one artificial intelligence (AI) / machine learning (ML) model into a radio resource management (RRM) function of the O-DU to make decisions and / or inferences in real time.

18. 13. The apparatus of claim 12, wherein the at least one processor is further configured to execute the instructions to host at least one application for utilizing the MAC scheduler of the O-DU in real time.

Images