History
Functional splits are nothing new. They were initially outlined in 3GPP Release 14 and defined in 3GPP release 15 and where new terminology, interfaces and functional modules were introduced. But why is this RU, DU, CU functional split concept becoming so fundamental in Open RAN?
Let us start with some basics.
Why
Previous RAN architectures (2G, 3G and 4G) were based on a “monolithic” building blocks, where few interactions happened between logical nodes. Since the earliest phases of the New Radio (NR) study, however, it was felt that splitting up the gNB (the NR logical node) between Central Units (CUs) and Distributed Units (DUs) would bring flexibility. Flexible hardware and software implementations allow scalable, cost-effective network deployments – but only if hardware and software components are interoperable and can be mixed and matched from different vendors. A split architecture (between central and distributed units) allows for coordination for performance features, load management, real-time performance optimization and enables adaptation to various use cases and the QoS that needs to be supported (i.e. gaming, voice, video), which have variable latency tolerance and dependency on transport and different deployment scenarios, like rural or urban, that have different access to transport like fiber.
But what makes any split architecture open and suited for Open RAN? A mobile operator can deploy a fully compliant functional split architecture, but unless the interfaces between RU, DU and CU are open, the RAN itself will not be open – see a diagram below that shows current industry thinking. Based on their experience, Nokia believes that the only valid split is between RU and DU. Time will tell if integration of one vendor’s DU with another vendor’s CU will deliver flexibility and savings.
Source: Nokia
The main takeaway: Functional splits will bring cost savings if interfaces between hardware and software components are open.
What
In a 5G RAN architecture, the BBU functionality is split into two functional units: a distributed unit (DU), responsible for real time L1 and L2 scheduling functions, and a centralized unit (CU) responsible for non-real time, higher L2 and L3. In a 5G cloud RAN, the DU’s server and relevant software could be hosted on a site itself or can be hosted in an edge cloud (datacenter or central office) depending on transport availability and fronthaul interface. The CU’s server and relevant software can be co-located with the DU or hosted in a regional cloud data center. The actual split between DU and RU may be different depending on the specific use-case and implementation (although the O-RAN Alliance definition is Option-7.2 and Small Cell Forum is Option-6).
Source: Xilinx
RU: this is the radio unit that handles the digital front end (DFE) and the parts of the 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.
DU: this is the distributed unit that sits close to the RU and runs the RLC, MAC, and parts of the PHY layer. This logical node includes a subset of the eNB/gNB functions, depending on the functional split option, and its operation is controlled by the CU.
CU: this is the centralized unit that runs the RRC and 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 enables a 5G network to utilize different distribution of protocol stacks between CU and DUs depending on midhaul 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., with the exception of functions that are allocated exclusively to the DU. The CU controls the operation of several DUs over the midhaul interface.
The centralized baseband deployment allows load-balancing between different RUs. That is why, in most cases, the DU will be collocated with RUs on-site to conduct all intense processing tasks such as fast Fourier transform/inverse fast Fourier transform (FFT/IFFT). Edge-centric baseband processing delivers low latency, local breakout, seamless mobility with real-time interference management, and optimal resource optimization. There are three purposes of separating DU from RU: 1. To reduce cost – less intelligent RU costs less, 2. Ability to look at a sector of RUs at once and not just an individual RU – this will help to enable features like CoMP, and 3. As processing is done in the DU, resources can be pooled resulting in pooling gains.
The industry is coming to a consensus that the lower level interface that connects RU and DU (fronthaul) should be eCPRI to deliver the lowest latency. Fronthaul latency is constrained to 100 microseconds. A single DU may be serving RUs up to many kilometers away.
It is important to note that the DU/CU split is hardly impacted by the type of infrastructure. The primary new interface is the F1 interface between the DU and CU, and they need to be interopearble across different vendors to deliver the true promise of Open RAN. Midhaul connects the CU with the DU. And while in theory 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 on the midhaul interface between the different splits (1-5). The latency on the link should be around 1 millisecond. A centralized CU can control DUs in an 80 km radius.
Backhaul connects the 4G/5G core to the CU. The 5G core may be up to 200 km away from the CU.
Source: Altran (Aricent)
RAN vendors that started with CPRI and now are trying to sell the solution of converting CPRI to eCPRI in their architecture, should not try to justify this approach as it creates unnecessary complexity and latency. Perhaps they should be reminded of what happened to ATM when they tried to invent ATM over IP?
The main takeaway: With the increase in deployment footprint, fiber and availability of required fronthauls (FHs) can be challenging. By distributing protocol stacks between different components (different splits), solution providers can focus on addressing the tight requirements for a near-perfect FH between RU, DU and CU.
How
In case of requirements for more delay-sensitive service, based on appropriate fronthaul availability, the MAC-PHY split will be the preferred solution. Option 7 Split architecture is where the DU handles the RRC/PDCP/RLC/MAC and higher PHY functions, whereas the RU handles the lower PHY and RF functions. CU functionality may be embedded with the DU on the same server, or it can be pushed up the network as a virtualized aggregation entity, along with an OpenRAN Controller or aggregator. Option 7 allows operators to take advantage of sharing or pooling gains while maintaining the lowest processing utilizations on both the DU and RU – leading to a very cost-effective solution with a low TCO and an ideal option for a distributed RAN deployment, including Massive MIMOs.
Source: Parallel Wireless
For 5G, this is still being discussed as a potentially valid option in some use cases. Higher splits, as in 7.x, will be the best approach going forward for deploying future mobile networks in different deployment scenarios. It is ideal for 4G and 5G and can support traffic in dense urban areas.
Split 8 is based on the industry standard CPRI interface and has been around for a while. With traffic split 8, all functions (from PHY to RRC layers) except for RF are handled by the DU, while the RF layer is located in the radio. But why is this split gaining attention now?
This split is highly effective in 2G and 3G, where traffic rates are much lower (and therefore processing itself is lower, to a certain extent) and can be easily done on an x86 server, while allowing operators to use cost-optimized RUs with minimal logic and processing. The DU and RU should be interoperable with other third party DUs and RUs. The enhancement over the legacy Split-8, is that in order for RUs to run multiple technologies over the same FH interface, they now need to utilize eCPRI instead of the legacy CPRI interface between the RU and DU.
This approach allows for centralized traffic aggregation from the RUs, which in turn enables a seamless migration path from the traditional LTE ecosystem to the NR ecosystem.
Source: Parallel Wireless
The RAN DU sits between the RU and CU and performs real-time L2 functions, baseband processing. In the O-RAN Alliance working group, the DU is proposed to support multiple layers of RUs. To properly handle the digital signal processing and accelerate network traffic, FPGA can be used. But what is important to understand is that hardware acceleration is considered a requirement for 5G but less so in previous technologies like 2G, 3G, and even 4G.
Source: Supermicro
There has also been a focus around hardware accelerators – FPGA and GPU – to accelerate real-time sensitive processing for the lowest layers of the radio baseband for 5G. Ericsson and Nokia are looking at GPU-based acceleration for some vRAN workloads, especially for 5G M-MIMO and for AI. So, there is definitely the need to invest more in different chip technologies to ensure Open RAN can have access to the best DUs available on the market.
Reducing overall TCO will be a priority, and a solution around GP processor architectures to deliver the most efficient and cost-effective compute, storage and network elements will drive the innovation.
The main takeaway: Different splits work for different use cases. One split might not fit it all. A solution that can support many of technologies including not just 4G and 5G, but also 2G and 3G, is the most attractive to MNOs as it will simplify network management and the overall TCO.
When
The choice of how to split New Radio (NR) functions in the architecture depends on some factors related to radio network deployment scenarios, constraints and intended supported use cases. Three key ones are: 1. A need to support specific QoS per offered services (e.g. low latency, high throughput for urban areas) and real/non-real time applications. 2. Support of specific user density and load demand per given geographical area. 3. Available transport networks with different performance levels, from ideal to non-ideal.
Mobile operators need the flexibility to pick and choose different splits based on the same COTS-based hardware and network components by using different software implementations. Different protocol layers will reside in different components based on fronthaul availability and deployment scenarios. This approach will reduce the cost of operations and TCO for mobile operators.
Higher functional splits are more desirable for capacity use cases in dense urban areas while lower functional splits will be the optimum solutions for coverage use cases. So, while lower functional splits utilize less than perfect fronthauls, there is a greater dependence on fronthaul performance for higher functional splits.
Source: Parallel Wireless
To take full benefit of split architecture that can deliver interoperability, ability to select best-of-breed components and scalability, any solution needs support 2G, 3G, 4G, 5G baseband functions. For the best latency support requirement, baseband functions decoupled from hardware should be deployed on NFVI or as containers. An MNO can use any VM requirements and/or any orchestration to enable these functional splits.
The future evolution of RAN will be toward dynamic functional splits. While the OpenRAN Controller (aggregator) acts as a mediator between the RAN and core network, the functionality of the RAN will be distributed between DUs and CUs as it is defined in 5G, and this software can be co-located with the aggregator. In different scenarios, these elements can collapse together and create a single physical entity with different virtual functionalities. We will cover Open RAN Controller, Near-real-time Radio Intelligent Controller (Near-RT RIC) and Non-real-time RIC (Non-RT RIC) in our upcoming installments.
Please share any questions or comments – would love to hear from you.
