What Are the Open RAN Standards? A high-level overview of Open RAN Architecture
Hello folks, welcome back to Learnizo Global. In our previous article on Open RAN, we introduced Open RAN and discussed the benefits and challenges of deploying an Open RAN. In this article, we will understand the standards for Network controllers, management and orchestration, and major interfaces of an Open RAN. These standards allow any organization to create RAN products that can interoperate using standard interfaces. Understanding these standards gives you a high-level overview of the Open RAN architecture.
There have been many contributors to the open RAN standards movement. As discussed in our previous article, there are two dominant open RAN standardization bodies: the O-RAN Alliance and the Telecom Infra Project (TIP).
Open RAN Standards Bodies
The O-RAN Alliance was founded by five telecoms from around the world: AT&T, China Mobile, Deutsche Telekom, NTT DOCOMO, and Orange. Other organizations have joined as members; however, none are among the top RAN vendors.
The O-RAN Alliance’s primary goal is to help create a supply chain that opens up the RAN market for new vendors. The organization’s work is founded on the principles of openness and intelligence. Openness is what gives new vendors access to the market because having standard interfaces that anyone can use allows different vendors’ products to interoperate without close cooperation. Intelligence is required for future networks that grow in complexity, including 5G networks.
Unlike the O-RAN Alliance, TIP’s member organizations include Nokia and Samsung Research America, Inc. Both are among the top RAN vendors. The core activities of TIP are to create high-level technical requirements for significant use cases; test and validate the network elements, products, and configurations; and finally to share best practices for commercial deployments of the tested technologies.
The goals shared by any open RAN standardization body is to create a space for new vendors and offer alternatives to single-vendor solutions where an organization is tied to one vendor for their network infrastructure or at least the infrastructure in a geographic market. New vendors also bring the potential for innovation in the field and market competition that brings prices down.
Open Standards for Network Controllers
The network controller is an important element of a virtualized network. The second version of “O-RAN Architecture Description” from July 2020 of O-RAN Alliance’s documentation describes RAN intelligent controllers (RICs) as a crucial component to a RAN based on open standards RICs enforce policies and automate the network.
The O-RAN Alliance’s RIC has two forms, a non real-time RIC and a near real-time RIC. The two get their names from their response times. The non real-time RIC takes one second or more to execute its functions and the near real-time RIC executes functions between 10 milliseconds and one second. Because of the discrepancy, the two controllers are responsible for different types of functions.
The non real-time RIC is a logical function, meaning it is software and not hardware. It exists in the service management and orchestration (SMO) system. This RIC houses the policies that are referenced by the near real-time RIC for enforcement. The non real-time RIC manages Machine Learning (ML) models that the near real-time RIC then uses to make decisions based on the network’s current context. It only connects to the near real-time RIC, providing the policies, data, and machine learning models necessary for RAN optimization.
The near real-time RIC is a logical function as well. It communicates between the application layer, which exists within it, and the non real-time RIC, and the infrastructure layer, which includes the open central unit (O-CU) and the open distributed unit (O-DU). In this model, the O-CU had disaggregated control and user planes to add flexibility to the architecture. This RIC more directly controls and optimizes the lower levels of the RAN. It uses AI(Artificial Intelligence) and Machine Learning (ML) for automation purposes and to decide when to enforce policies that control routing and quality of service (QoS), among other policies.
Standardized Management and Orchestration
As mentioned, the non real-time RIC exists within the SMO (service management and orchestration) framework, which is a combination of several management services. It is capable of going beyond supporting a RAN and can conduct network core management, transport management, and network slicing management.
Outside of the non real-time RIC, the key aspects of the SMO include managing and orchestrating the open cloud (O-Cloud) as well as containing the FCAPS services for the O-RAN network elements. FCAPS stands for fault, configuration, accounting, performance, security; which are various management categories for maintaining and securing the O-RAN virtual network functions (VNFs).
The O-Cloud is a collection of physical RAN nodes that host the RICs, CUs, and DUs; the software components such as the operating systems and runtime environments; and the SMO. To be clear, the SMO is managing and orchestrating the O-Cloud from within.
Open Standards for Interfaces
There are several interfaces at work within an open RAN architecture. They include:
- Open Front haul interface
- A1
- O1
- O2
- X2
- Xn
- NG
- E1
- E2
- F1
This image depicts the interfaces standardized by the O-RAN Alliance for its open RAN architecture.
Open Front Haul Interface
The open front haul interface connects the O-DU and open radio unit (O-RU). It breaks down into the management plane (M-Plane) and the control user synchronization plane (CUS-Plane). The M-Plane connects the O-RU to the O-DU, and only optionally connects the O-RU to the SMO. The O-DU uses the M-Plane to manage the O-RU, while the SMO can provide FCAPS services to the O-RU.
The CUS-Plane is multi-functional. The control and user aspects transfer control signals and user data respectively. The remaining aspect synchronizes activities between multiple RAN devices.
A1 Interface
The A1 interface enables the communication between the two RICs and supports policy management, data transfer, and machine learning management. The data, actually called enrichment information, is specifically for assisting the model training for the AI and machine learning in the near real-time RIC.
O1 and O2 Interfaces
The O1 interface connects the SMO to the RAN managed elements. These include the near real-time RIC, O-CU, O-DU, O-RU, and the open evolved NodeB (O-eNB). The O-eNB is the hardware aspect of a 4G RAN. The management and orchestration functions are received by the managed elements via the O1 interface. The SMO in turn receives data from the managed elements via the O1 interface for AI model training.
The O2 interface is how the SMO communicates with the O-Cloud it resides in. Network operators that are connected to the O-Cloud can then operate and maintain the network with the O1 or O2 interfaces by reconfiguring network elements, updating the system, or upgrading the system.
X2 and Xn Interface
The X2 interface is broken up into the X2-c and X2-u interfaces, where the former is for the control plane and the latter is for the user plane. Both are originally designed by 3GPP for sending information between a 4G network’s eNBs, or between an eNB and a 5G network’s en-gNB. In the O-RAN Alliance’s documentation, the interface has the same principles and protocols. In the above image, both of the X2 interfaces enter from outside the architecture, showing that they are incoming to another deployment. The Xn, NG, F1, and E1 interfaces are all also adopted from 3GPP standards.
The Xn interface is also broken into control and user subtypes — Xn-c and Xn-u. They transfer control and user plane information between next-generation NodeBs (gNBs), between ng-eNBs (4G nodes capable of connecting to a 5G core), or between the two different types.
NG Interface
The NG control and user plane interfaces connect an O-CU control plane (O-CU-CP) and O-CU user plane (O-CU-UP) to the 5G core. The control plane information goes to the 5G access and mobility management function (AMF), which receives connection and session information from the user equipment. The user plane information goes to the 5G user plane function (UPF), which handles many aspects of routing, forwarding, and tunneling.
F1 Interface
The F1 interface, again broken into control and user plane subtypes, connects the O-CU-CP and O-CU-UP to the O-DU. It exchanges data about the frequency of resource sharing and other network statuses. One O-CU can communicate with multiple O-DU via F1 interfaces.
E1 and E2 Interfaces
The last of the 3GPP-based interfaces is the E1 interface. It connects the two disaggregated O-CU user and control planes. It transfers configuration data and capacity information between the two O-CU planes. The configuration data ensures the two planes can interoperate. The capacity information is sent from the user plane to the control plane and includes the status of the user plane.
The near real-time RIC in the open RAN architecture connects to the O-CU, O-DU, and O-eNB with the E2 interface. These elements combined make the E2 node. An E2 node can only connect to one near real-time RIC, but one of those RICs can connect to multiple E2 nodes. The protocols that go over the E2 interface only control plane protocols. The protocols are for controlling and optimizing the E2 node elements and the resources they use. Again, the data collected is returned to the RIC over the interface.