In this post we will be talking about the following topics:
- What is Open RAN?
- Open RAN and 5G.
- Current challenges and its limitations.
- The importance of AI/ML for Open-RAN.
Open RAN vs Legacy network architecture
To start talking about open-RAN we can first have a look of how a traditional network architecture is designed:
As you can see in Figure 1, the radio access network is traditionally fully composed by proprietary technology, which includes closed source hardware, software, and interface. It fundamentally means that when a Mobile Network Operator (MNO) wants to install one radio base station (e.g., eNodeB) at some place, the whole technology infrastructure must be provided by a single vendor. In more practical terms it also means that the full support regarding maintenance, software updates, etc., is also dependent on the same provider.
Open Radio Access Network (RAN) follows exactly the opposite direction. As shown in Figure 2, one of the main ideas is to establish network services as a virtualized function, in which we can control by Commercially Available Off-the-Shelf (COTS) servers and hardware from any vendor (e.g., Software Defined Radio) and using an open interface for that.
We can note that internal network functions can still be proprietary to single vendors, representing, for example, embedded proprietary algorithms, but other parts of the RAN might have flexibility to be designed with different technologies of multiple vendors. The Figure 3 provides an overall idea of the proposed model deployment and its difference with the legacy mobile architecture. Note that we can simultaneously use hardware technology from different vendors using the same open-RAN software and updating this software without affecting the hardware deployment.
Open-RAN and 5G
When it comes 5G, the 3rd Generation Partnership Project (3GPP) recently defined in its technical report TR 38.801 the split of the base band unit (BBU) logical node into Central Unit (CU) and Distributed Unit (DU), in which we can split different layers and network functions, as showed in Figure 4. Essentially, it offers the MNOs flexibility to decide for a more centralized or distributed RAN topology, where we can basically trade-off high performance of centralized coordination for site cost and complexity of a distributed architecture. The Figure 5 provides an intuitive representation of such exchange.
For example, in industry automation use cases, where ultra-low latency (<1 ms) communication is desired, such as robotic motion control, a more centralized architecture is preferred to achieve the strict latency requirements. Hence, DU, CU and RRU can be deployed at the cell site to locally run the applications, as represented in Figure 6. On the other hand, for mobile broadband services, with no strict latency requirements (< 10 ms), the CU and DU can be remotely positioned, while keeping the RRU locally running, as shown in Figure 7.
Current challenges and limitations
The Figure 8 provides a very interesting idea about how the current Mobile Network Operators perceive the challenges regarding Open-RAN.
As we can note, performance and robustness are the main concern of MNOs, thus opening very interesting research opportunities. Fundamentally, we, as researchers, must provide answers to questions such as: “Can Open-RAN indeed achieve URLLC”? Finding the answers must require both analytical and practical research with a very clear goal of solving an industry related problem.
The other challenges, especially protocol compliance and daily maintenance, are more related to automation process, which can also open up many opportunities when it comes development (a part from Research).
The importance of AI/ML for open RAN.
Recently, O-RAN Alliance, the organization behind Open-RAN research and development activities, introduced the so-called RAN Intelligent Controller (RIC), which is an entity of Open-RAN architecture responsible not only for RAN general operation, but also constant optimization with the support of AI/ML models. It is composed by a suite of software apps (xApps) to enable software defined network (SDN) functionalities, while simultaneously gathering data to optimize radio resource management, mobility management, edge services, etc. The Figure 9 provides more details about the RIC. Its operation mode can be essentially divided into two different parts: the near-real time RIC and non-real time RIC.
- At the near-real time RIC we have the Software platform that hosts micro-service-based applications (xApps). So, applications like Mobility management, admission control, and interference coordination are available as apps on the RIC controller. Essentially, data information (from UE and/or Cell) is collected in the E2 interface, where a policy loop or closed loop automation monitor controls those E2 Nodes (e.g., send commands of suspend/stop, handover decision, etc.)
- At the non-real time RIC we have indeed the data analytics process and ML/inference training that optimizes the RAN operation. Basically, collected network information is sent using O1 interface, thus occurring the learning optimization process. The trained policy models are subsequentially sent back to the near-real time RIC by A1 interface for runtime execution.
The RIC in essence looks quite similar to the so called Machine learning DevOps (or MLOps), which encompasses the idea of continuous integration, delivery and continuous training, thus forming an automated pipeline to control the ML development process within the network operation.
Additional Information
A nice example that encompass open RAN and ML is provided by NVIDIA using GPU accelerated 5G cloud RAN: https://youtu.be/AAcw9J5n11k
Do you have questions or interest in Open-RAN topic? Please don’t hesitate to contact me:
