3GPP considered the split concept (DU and CU) from the beginning for 5G. In a 5G cloud 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 physical layer and software layer are hosted in an Edge cloud data center or central office, and the CU physical layer and software can be collocated with the DU or hosted in a regional cloud data center. While CUs will maintain BBU-like functionalities, DUs are software based and will be better than RRHs in terms of processing capacities. And 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 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.
Source: Xilinx
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 RUs cost 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.
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.
And though the functional split concept was introduced for 5G, to get full interoperability and cost benefits, it must be applied to RAN for 2G, 3G and 4G as well.
When the RAN is opened up horizontally, it could bring in a new range of low-cost radio players, and it gives mobile operators a choice to optimize deployment options for specific performance requirements at much better cost.
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).
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 interoperable 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?
To summarize, 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.
