From Monolithic eNB to Disaggregated gNB

In LTE, the eNB is a monolithic entity: all RAN protocol layers -- RRC, PDCP, RLC, MAC, and PHY -- run on a single platform at the cell site. This tight integration simplifies deployment but limits flexibility. You cannot independently scale baseband processing, move control-plane functions to a centralized location, or mix vendors across the protocol stack.

5G NR introduces a disaggregated gNB architecture defined in 3GPP TS 38.401 clause 6, splitting the monolithic gNB into three functional units: the Centralized Unit (CU), the Distributed Unit (DU), and the Radio Unit (RU). The CU is further divided into CU-CP (Control Plane) and CU-UP (User Plane) per 3GPP TS 38.401 clause 6.1.1. This article maps the full set of functional split options, details the F1 and E1 interfaces, compares CU-CP and CU-UP functions, and provides fronthaul bandwidth calculations.

The Three-Tier Architecture

CU (Centralized Unit): Hosts RRC and PDCP layers. Can be located at a regional data center or central office, serving multiple DUs. Split into:

• CU-CP: RRC + PDCP-C (control-plane PDCP). Handles connection management, mobility, security, and RRC signaling.
• CU-UP: PDCP-U (user-plane PDCP) + SDAP. Handles user data ciphering, header compression, and QoS flow mapping.

DU (Distributed Unit): Hosts RLC, MAC, and the upper part of the PHY layer (High-PHY). Located at or near the cell site. Responsible for scheduling, HARQ processing, and real-time MAC operations. RU (Radio Unit): Hosts the lower PHY (Low-PHY) and RF front-end. Located at the antenna site. Performs OFDM processing (FFT/IFFT), beamforming, digital-to-analog conversion, and power amplification.

CU-CP vs CU-UP Function Comparison

The CU-CP to CU-UP interface is the E1 interface, defined in 3GPP TS 38.460 (E1AP) and 3GPP TS 38.463 (E1 signaling transport). E1 carries bearer context setup, modification, and release messages. A single CU-CP can control multiple CU-UPs, enabling independent scaling of control and user planes.

F1 Interface: Connecting CU and DU

The F1 interface connects the CU to the DU, defined in 3GPP TS 38.470 (F1 general aspects) and 3GPP TS 38.473 (F1AP).

F1AP procedures include UE Context Setup (CU-CP -> DU), UE Context Modification, UE Context Release, and Paging. RRC messages from the UE are transparently tunneled over F1-C: the DU extracts the RRC PDU from the MAC/RLC stack and forwards it to the CU-CP in an UL RRC Message Transfer message. The CU-CP processes the RRC message and sends any response back via DL RRC Message Transfer.

Functional Split Options: The Full Spectrum

3GPP and the Small Cell Forum defined eight split options, numbered from the core-side (Option 1) to the antenna-side (Option 8). The 3GPP high-layer split (HLS) at Option 2 and the low-layer split (LLS) between Options 6 and 7 are the most commercially relevant.

Option 2 is the 3GPP-standardized CU-DU split, used by virtually all operators. The F1 interface operates at this split point. PDCP processing (ciphering, header compression, reordering) runs at the CU, while time-critical functions (scheduling, HARQ, channel coding) run at the DU. Option 7-2x is the O-RAN Alliance-defined DU-RU split (specified in the O-RAN Fronthaul specification). The DU performs channel coding, rate matching, layer mapping, and precoding. The RU performs iFFT/FFT, CP insertion/removal, and beamforming. This split dramatically reduces fronthaul bandwidth compared to Option 8 (CPRI) while keeping the RU relatively simple.

Worked Example 1: Option 8 (CPRI) Fronthaul Bandwidth

CPRI transports time-domain IQ samples between the baseband unit and the radio head. Calculate the fronthaul bandwidth for a single 100 MHz NR carrier, 4T4R antenna configuration, 30-bit IQ samples (15-bit I + 15-bit Q).

Step 1: Sample rate.

For 100 MHz bandwidth at SCS 30 kHz with 273 PRBs: FFT size = 4096, sample rate = 4096 x 30 kHz = 122.88 Msps.

Step 2: IQ data rate per antenna.

122.88 Msps x 30 bits/sample = 3,686.4 Mbps per antenna port.

Step 3: Total for 4T4R.

4 x 3,686.4 = 14,745.6 Mbps DL + 4 x 3,686.4 = 14,745.6 Mbps UL = 29.49 Gbps bidirectional.

Step 4: Add CPRI overhead (line coding, control words).

CPRI uses 8B/10B or 64B/66B encoding. With 8B/10B: 29.49 x 1.25 = 36.86 Gbps. With control words (~2%): total approximately 37.6 Gbps for a single 100 MHz carrier.

For a 64T64R Massive MIMO configuration: 64 x 3,686.4 x 1.25 x 1.02 = approximately 301 Gbps bidirectional -- clearly impractical for standard fronthaul links. This is precisely why Option 7-2x was developed.

Worked Example 2: Option 7-2x Fronthaul Bandwidth

In Option 7-2x, the DU performs precoding/beamforming, so the fronthaul carries frequency-domain IQ samples for the number of spatial layers (not antenna ports).

Step 1: Data after precoding.

For 4 MIMO layers, 273 PRBs x 12 subcarriers = 3,276 subcarriers per symbol.

Step 2: IQ per symbol.

3,276 subcarriers x 30 bits (15-bit I + 15-bit Q) = 98,280 bits per symbol per layer.

Step 3: Symbols per second.

SCS 30 kHz: 14 symbols x 2,000 slots/sec = 28,000 symbols/sec.

Step 4: Data rate per layer.

98,280 x 28,000 = 2,751.84 Mbps per layer.

Step 5: Total for 4 layers (DL).

4 x 2,751.84 = 11,007 Mbps = ~11 Gbps DL.

Step 6: Add control overhead (~20% for section headers, C-plane).

11 x 1.2 = ~13.2 Gbps DL. UL is similar.

Total bidirectional: approximately 25 Gbps. Compare this to the 301 Gbps for Option 8 with 64T64R -- a 12x reduction. The key difference is that Option 7-2x carries layer-domain samples (4 layers) while Option 8 carries antenna-domain samples (64 ports).

Note: When beamforming is performed at the RU (Option 7-2 without the "x"), the fronthaul bandwidth scales with the number of beams rather than layers, resulting in intermediate bandwidth requirements.

Protocol Stack Summary

The NG interface connects the gNB (specifically the CU-CP) to the 5GC AMF (N2, control plane) and the CU-UP to the UPF (N3, user plane). The Xn interface enables direct gNB-to-gNB communication for handover and dual connectivity.

Deployment Scenarios

Scenario 1: Distributed RAN (D-RAN).

All three units (CU, DU, RU) are co-located at the cell site. This is functionally similar to a monolithic gNB but preserves the logical interfaces for future disaggregation. Common in rural deployments where centralization offers no advantage.

Scenario 2: Centralized RAN (C-RAN).

The CU is deployed at a regional data center. Multiple DUs (each co-located with RUs at cell sites) connect to the CU via F1 over MPLS/IP backhaul. Advantages: centralized mobility management, pooling gains for RRC processing, easier coordination for inter-cell scheduling. T-Mobile US uses this model with CUs in regional edge data centers serving 40--100 DUs each.

Scenario 3: Cloud RAN / vRAN.

DU functions are virtualized and run on COTS servers at edge sites (e.g., a street cabinet or hub site). The RU connects to the DU via eCPRI over 25 Gbps Ethernet fronthaul. This is the model promoted by the O-RAN Alliance and adopted by operators including Dish Network (EchoStar), Rakuten Mobile, and Vodafone. Rakuten deployed the world's first fully virtualized nationwide network, running CU and DU as containerized workloads on commodity hardware.

Scenario 4: Small-cell disaggregation.

For indoor enterprise deployments, a single DU serves multiple low-power RUs over switched Ethernet. Nokia and Ericsson offer indoor small-cell solutions where 16--32 RUs connect to a single DU, reducing per-cell costs. Deutsche Telekom deploys this model in enterprise private 5G networks, with the CU running in their regional cloud.

Fronthaul Transport Requirements

The stringent latency and jitter requirements of Options 7 and 8 mandate high-quality fiber connections between DU and RU. For Option 2 (F1), standard enterprise-grade IP transport is sufficient, making it the preferred split for operators with limited fiber density.

Impact on Vendor Diversity and O-RAN

The disaggregated architecture enables multi-vendor RAN. With standardized interfaces (F1, E1, eCPRI), an operator can source the CU from vendor A, the DU from vendor B, and the RU from vendor C. The O-RAN Alliance has further specified open fronthaul (7-2x) and defined the RAN Intelligent Controller (RIC) for programmable RAN optimization.

Dish Network (EchoStar) built the first greenfield O-RAN network in the USA with:

• CU: Mavenir (virtualized, on AWS Outposts)
• DU: Mavenir (on Dell servers)
• RU: Fujitsu (64T64R Massive MIMO, n41/n71)

This multi-vendor approach reduces lock-in but introduces integration complexity. Interoperability testing via O-RAN TIFG (Testing and Integration Focus Group) plug-fests is essential for production-grade deployments.

Summary

The 5G RAN functional split transforms the radio access network from a monolithic box into a flexible, cloud-native platform. The CU-DU split at Option 2 (F1 interface) separates real-time and non-real-time processing, enabling centralization and pooling gains. The DU-RU split at Option 7-2x provides the optimal balance between fronthaul bandwidth efficiency and RU simplicity. Understanding the protocol stacks (F1-C, F1-U, E1, eCPRI), the CU-CP/CU-UP separation, and the bandwidth calculations for each split option is fundamental knowledge for 5G RAN engineers, O-RAN practitioners, and certification candidates.