OpenRAN (O-RAN) for 5G explained:

What is a 5G Open Radio Access Network (O-RAN)?

An Open Radio Access Network (O-RAN) is a disaggregated approach to deploying mobile fronthaul and midhaul networks built entirely on cloud native principles. O-RAN underscores streamlined 5G RAN performance objectives through the common attributes of efficiency, intelligence and versatility. Open RAN deployed at the network edge will benefit 5G applications such as autonomous vehicles and the IoT, support network slicing use cases effectively, and enable secure and efficient over-the-air firmware upgrades.

O-RAN is an evolution of the Next Generation RAN (NG-RAN) architecture, first introduced by the GSMA’s 3GPP in their release 15 (5G version 1) technical specification TS 38.401. The O-RAN Alliance formed to undertake the advancement of NG-RAN philosophies, expanding on the scope of what was originally outlined by the 3GPP. Comprising over 1601 member companies, the O-RAN alliance issues specifications and releases open source software under the auspices of the Linux Foundation.

O-Ran (OpenRAN) 5G Radio Network Architecture
O-RAN Logical Architecture Diagram. Picture courtesy Metaswitch

TS 38.401 decomposed the existing Baseband Unit (BBU) into two functional components, a Distributed Unit (DU) and Central Unit (CU). Conforming to modern control user plane separation (CUPS) constructs, the Central Unit can be further decoupled into distinct control plane (CU-CP) and user plane (CU-UP) functions. Replacing the monolithic BBU with the CU/DU allows for new deployment models which feature centralized packet processing functions, while laying the groundwork for separating baseband functions from the (remote) radio unit (RRU/RU).

CableFree OpenRAN (O-Ran) disaggregated Radio Access Network
for 5G and 4G and beyond
ORAN explained: Picture courtesy VIAVI solutions

O-Ran Benefits

Operational efficiencies have been realized through past RAN innovations such as cloud RAN (cRAN), but previous advancements did not free operators from vendor lock-in. By enabling an open, multi-vendor RAN ecosystem, O-RAN introduces cloud-scale economies and competition to the RAN. Marketplace factors, combined with a more elastic and flexible RAN architecture that is already taking shape through virtualization, can enable much faster time to market (TTM) than was previously possible.

Moving away from the vendor-specific RAN paradigm not only enables more flexibility for operators, it also minimizes the “secret sauce” that leaves them reliant on a single vendor for all aspects of RAN implementation and optimization.

Competition and proliferation resulting from of new entrants can potentially drive down O-RAN equipment costs. The inter-carrier, interoperability aspects of Open RAN can also be used to increase efficiencies for existing LTE networks as they continue to incorporate the virtualization and disaggregation that are prerequisite 5G RAN deployment.

A CableFree Remote Radio Head (RRH) used for O-RAN network
A CableFree Remote Radio Head (RRH) used for O-RAN networks

This affords numerous technical and operational advantages, regardless of whether the RRU, DU and CU remain co-located within a 5GNodeB (gNB), like existing NodeB RRU/BBU implementations, or the CU is physically deployed to a more centralized location. The centralization of the CU in an aggregation site reduces costs and accelerates the implementation of dynamic and highly automated multiaccess edge compute (MEC) clouds for the RAN (aka C-RAN). This functional decoupling will also enable the adoption of modern transport protocols which can also align with the 5G core user plane (i.e. SRv6) while easing the addition of new latency, high-bandwidth, AI/ML-driven applications.

The deployment of NG-RAN components is defined as being with or between the fronthaul, midhaul and backbone network. Open interfaces are described as either lower-layer splits (LLS), in the case of the RU to DU connection, or higher-layer splits (HLS) as with the link between the DU and CU. This nomenclature is descriptive of the OSI layer (i.e. L1/L2/L3) exposed by the interface and handled by the NG-RAN function. Where components are instantiated will depend on the requirements of the service slice. A low latency service might demand a CU be co-located with the DU in the access layer while a slice supporting a simple machine to machine communications application would scale more cost effectively with a CU within the network core.

NG-RAN clearly defines the DU and CU plus the F1, E1, Xn and NG between them and the core network but stops short of outlining the service management framework and interfaces required for the RAN to operate within an orchestrated and automated cloud environment. TS 38.401 also fails to address the RU-DU interface. Without further definition, it would be logical to adopt the exiting Common Public Radio Interface (CPRI) defined between the RRU-BBU. Although theoretically a standard, this interface has been heavily modified by individual vendors, effectively locking their RRU to their BBU.

While CPRI is a high-speed serial interface, the bandwidth demands of 5G will stretch the limits of local fiber and increase the need for more radio units. Current implementations do not allow for the DU to reduce this burden by offloading some of its functionality to the RU. While the enhanced CPRI (eCPRI) interface was originally proposed as an alternative, this specification was also developed by just four2 large vendors. The O-RAN Alliance has therefore taking on the task of defining new Open Fronthaul user and management plane interfaces between the DU and RU.

To ensure openness, O-RAN decouples hardware and software into 3 layers: The commercial off the shelf (COTS) merchant silicon (including x86), a hardware abstraction layer and an application layer, where the RAN functions reside. Ensuring each layer is vendor agnostic, the O-RAN alliance has specified a list of requirements for a cloud platform which supports the execution of O-RAN network functions. This is referred to as the O-RAN Cloud Platform, or O-Cloud. Deploying O-RAN functions on x86 hardware in cloud native environments using lightweight (OS virtualization) containers demands a strong emphasis on data plane acceleration. This must be achieved at the application level, as these functions will not have access to the Kernel. As such, solutions may be specific to each O-RAN CNF but leverage standard techniques such as DPDK and FD.io or employ more advanced techniques.

O-RAN challenges

Creating seamless interoperability in a multi-vendor, open ecosystem introduces new test, management and integration challenges that require diligence and cooperation to overcome. In the single-vendor model, accountability is a foregone conclusion and problem isolation and troubleshooting are managed through an established command structure.

Dispersion of vendors could potentially lead to finger pointing when root cause identification is inconclusive. These same complications could plague on-time launch schedules and revenue growth by diluting management and orchestration responsibilities across an array of new O-RAN players.

The enticing Open RAN concept of flexible interoperability also brings challenges for test and integration. To fulfill the O-RAN promise of reduced OPEX and total cost of ownership (TCO), operators must take responsibility for multi-vendor, disaggregated elements and make sure they perform together to maintain QoE standards.

With Open RAN reducing the barrier to entry for dozens of new players, interoperability is a paramount concern for both the O-RAN ALLIANCE and OpenRAN group. An Open Test and Integration Center (OTIC) has been established as a collaborative hub for commercial Open RAN development and interoperability testing. The operator led initiative benefits from the support of global telecom organizations with a shared commitment to verification, integration testing, and validation of disaggregated RAN components. 

Summary

Traditional RAN designs and architectures will still persist in being used. Some operators will prefer Open RAN designs and architecture. Many operators will allow for both options in their network evolution and planning.

For Further Information

Please Contact Us