What are Radio Unit, Distributed Units and Centralised Units in Open RAN functional split?

• Open Radio access networks offer the option of placing network functions in different places along the signal path. 
• RAN functional split allows mobile operators optimise performance and make tradeoffs and it is also the foundation of Open RAN.

Starting with 2G wireless networks, the radio access network (RAN) architectures were based on monolithic building blocks. Those networks – and many 5G networks as well – have contained software functions in proprietary boxes called baseband units (BBUs) at the base of radio towers. 

These functions demodulated the RF signal, converting the output into digital data streams for transport on the backhaul to the core network. That situation is changing and becoming more open.

Since the earliest phases of 5G New Radio (NR), there’s been a push to disaggregate the BBU (Figure 1), breaking off functions beyond the Radio Unit (RU) into Distributed Units (DUs) and Centralised Units (CUs). 

The argument for disaggregation was flexibility, letting network operators decide how to locate these functions and maximise performance while reducing the deployment cost. 

For disaggregation to happen, hardware and software components must be interoperable, letting mobile operators mix and match these pieces from different vendors. Disaggregation also brings tradeoffs in deciding which unit should control certain operations – the RAN functional split.

Open RAN is about horizontal openness – with open interfaces enabling functions of the RAN to connect with other functions, from a radio unit (RU) to a baseband (DU-CU), to the controller to the NMS/orchestrator. 

With flexibility comes a tradeoff. Where should network functions reside? While it’s clear that RF functions need to be in the RU, the rest is a decision.

A split architecture (between central and distributed units) allows for the coordination of performance features such as latency and cost. Network engineers must decide among load management, real-time performance optimisation, and adaptation to various use cases to maintain quality of service (QoS).

Gaming, voice, video, have different latency tolerances. These services depend on different transport and deployment scenarios, like rural versus urban, that have different access to the fibre that transports data.

The functional split concept was introduced for 5G, though it can be applied to 2G, 3G 4G as well. These previous generations, with their lower data rates than 5G, can still benefit from Open RAN, by allowing mobile operators to mix and match RAN components utilising different RAN functional splits.

When the RAN is opened up horizontally, it could bring in a new range of low-cost radio players, hardware and software, and it gives mobile operators a choice to optimize deployment options for specific performance requirements at a much better cost.

RAN functional split

3GPP considered the split concept (DU and CU) for 5G from the beginning of writing its specifications. The DU is responsible for real-time layer 1 (L1, physical layer) and the lower layer 2 (L2) which contains the data link layer and scheduling functions. The CU is responsible for non-real-time, higher L2 and L3 (network layer) functions.

While CUs will maintain BBU-like functionalities such as digital processing, DUs are software-based and could contain some functions related to the Remote Radio Head (RRH) contained in the RU. This is where the Open RAN concept comes in: from COTS-based servers for DU and CU software to RU from any vendor.

• RU: This is the radio hardware unit that converts radio signals sent to and from the antenna into a digital signal for transmission over packet networks. It handles the digital front end (DFE) and the lower PHY layer, as well as the digital beamforming functionality. 5G RU designs are supposed to be “inherently” intelligent, but the key considerations of RU design are size, weight, and power consumption. Deployed on-site.
• DU: The distributed unit software that is deployed on-site on a COTS server. DU software is normally deployed close to the RU on-site and it runs the RLC, MAC, and parts of the PHY layer. This logical node includes a subset of the eNodeB (eNB)/gNodeB (gNB) functions, depending on the functional split option, and its operation is controlled by the CU. 
• CU: The centralised unit software that runs the Radio Resource Control (RRC) and Packet Data Convergence Protocol (PDCP) layers. The gNB consists of a CU and one DU connected to the CU via Fs-C and Fs-U interfaces for CP and UP respectively. A CU with multiple DUs will support multiple gNBs. The split architecture lets a 5G network utilize different distributions of protocol stacks between CU and DUs depending on mid-haul availability and network design. It is a logical node that includes the gNB functions like transfer of user data, mobility control, RAN sharing (MORAN), positioning, session management etc., except for functions that are allocated exclusively to the DU. The CU controls the operation of several DUs over the mid-haul interface. CU software can be co-located with DU software on the same server on site. 

Because the RAN functional split architecture (Figure 2) is fully virtualised, CU and DU functions run as virtual software functions on standard commercial off-the-shelf (COTS) hardware and be deployed in any RAN tiered datacenter. They can be deployed as virtual machines (VMs) or containers.

As the functions are virtual, several independent instances of DU and CU can share the same physical (server) resources. This allows several RAN services to run on the same hardware, each with its requirements and resource needs to be fulfilled.

There are four purposes for separating DU functionality from RU:

• To reduce cost. Less intelligent RUs cost less. 
• Allowing mix and match components reduce vendor lock-in.
• Ability to look at a sector of RUs at once and not just an individual RU. This will help to enable features like CoMP. 
• As processing is done in the DU, resources can be pooled resulting in pooling gains. 

The centralised baseband deployment enables load-balancing among different RUs. In most cases, the DU will be co-located near one or several RUs and conduct intense processing tasks such as Fast Fourier Transform/inverse Fast Fourier Transform (FFT/IFFT) used in OFDMA modulation. 

Edge-centric baseband processing delivers low latency, local breakout, seamless mobility with real-time interference management, and optimal resource optimisation.

The CU’s server and relevant software can be co-located with the DU or hosted in a regional cloud data centre. The actual split between DU and RU (Figure 2) may be different depending on the specific use-case and implementation (the O-RAN Alliance definition is Option-7.2 and Small Cell Forum is Option-6). 

The option number increase as you approach the RU and the physical layer. That’s in opposition to the traditional OSI model where layer 1 is the physical layer.

While the CU/DU split adds flexibility in how RAN services are deployed, RU cost still needs addressing. Today, the interface between the BBU and RU in 4G LTE is proprietary to mobile equipment vendors and is based on the Common Public Radio Interface (CPRI) interface. CPRI is not an open interface. 

It has dependencies in the implementation of BBUs and RRHs that require both to come from the same vendor. Furthermore, it creates a bottleneck; it’s based on the transport of digital radio signals directly over a point-to-point optical fibre. That creates a cost issue when a point-to-point fibre connection needs to be made between multiple microcell RUs to BBUs installed 20km away. 

The CPRI interface requires a constant bit rate no matter the load and there is no possibility for statistical multiplexing.

In 2017, Ericsson, Huawei, NEC, and Nokia introduced an update to this interface called enhanced CPRI (eCPRI). The eCPRI interface uses Ethernet as the L2 interface, which lets existing solutions for control, management and synchronization to be used. Ethernet allows packet-based switching and statistical multiplexing of several RU connections onto a single backhaul fibre, reducing the cost of deploying micro-cells.

The industry is coming to a consensus that the lower-level interface that connects RU and DU (fronthaul) should be eCPRI, which delivers the lowest latency at a lower cost. eCPRI specifies the number of split options in the protocol stack and, as Figure 3 shows, these options align with 3GPP RAN functional and those from the O-RAN Alliance.

As fronthaul latency is constrained to 100 microsec, using eCPRI interface helps with it. As Figure 2 shows, a single DU may serve RUs up to many kilometres away. Using eCPRI becomes cost-effective.

The DU/CU split is hardly impacted by the type of physical infrastructure. The primary new interface is the F1 interface (Figure 4) between the DU and CU. 

Mid-haul connects the CU with the DU. While there can be different splits, the only one being considered de-facto between DU and CU is Option-2. There’s also very little difference in the mid-haul interface between the different splits (1-5). The latency on the link should be around 1msec. A centralised CU can control DUs in an 80km radius.

Backhaul connects the 4G/5G core to the CU. The 5G core may be up to 200km away from the CU.

To summarise, the increase in deployment footprint, fibre and availability of required front hauls can be challenging. By distributing protocol stacks between different components (different splits), network engineers and providers can focus on addressing the tight requirements for a near-perfect FH between RU, DU and CU.

• Eugina Jordan is the Vice-President for Marketing at Parallel Wireless.

Related posts:

• Open RAN Explainer: Why do interfaces need to be open?
• Nine Open RAN predictions for Middle East and North Africa this year
• Legacy players need to grab a surfboard and start surfing or ORAN tidal wave “will swallow them”