O-RAN Fronthaul 7.2x Split: How CU/DU/RU Communication Actually Works

The 7.2x split is the central architectural choice of O-RAN. Get it right and you have multi-vendor fronthaul. Get it wrong and you spend a year debugging timing.

This is what is actually on the wire.

Where 7.2x sits among the splits

3GPP defined 8 functional splits between CU and RU. O-RAN settled on 7.2x — a low-layer split where most of L1 stays in the DU, but the lowest L1 functions (precoding, beamforming weight application, cyclic prefix, FFT/iFFT) move to the RU.

7.2x is the sweet spot: enough sits in the RU to make fronthaul bandwidth tractable for massive MIMO, but the RU stays simple enough to be a commodity. eCPRI is the transport.

eCPRI as the transport

CPRI was a constant-bit-rate protocol over fiber. Bandwidth scaled linearly with antennas; 64T64R needed huge pipes. eCPRI moved this onto Ethernet (or IP) and made the rate variable based on actual user load.

For a 100 MHz 5G NR cell with 64T64R massive MIMO at 7.2x, fronthaul bandwidth is roughly 25 Gbps in each direction at peak. Compare to ~150 Gbps for the same cell at split 8 (CPRI). That is why 7.2x exists.

eCPRI runs over either:

• Layer 2 (Ethernet) — typical for short-reach fronthaul, point-to-point or via fronthaul switches with strict latency SLAs.
• Layer 3 (UDP/IP) — used when fronthaul crosses an IP transport network. Adds overhead and jitter; needs careful QoS.

The four planes

O-RAN WG4 defines four planes between the O-DU and O-RU:

U-plane: IQ data

U-plane carries frequency-domain IQ samples per PRB per antenna layer. Compression is mandatory in practice — 9-bit or 12-bit μ-law / block floating-point compression cuts bandwidth roughly in half versus uncompressed 16-bit IQ.

The eCPRI message type is 0 (IQ Data). Each message contains a section header identifying the symbol, slot, frame, antenna port, and the IQ payload itself.

U-plane messages must arrive at the RU in time for the symbol they describe to be transmitted. Miss the deadline and the symbol is dropped — visible as throughput loss and BLER spikes.

C-plane: scheduling and beamforming

C-plane tells the RU what to do with the U-plane data: which PRBs are allocated, which beamforming weights to apply, which antenna ports to use, modulation order if the RU does any precoding.

eCPRI message type 2 (Real-Time Control Data). Sent ahead of the corresponding U-plane data so the RU is ready when IQ arrives.

C-plane and U-plane share fronthaul bandwidth and timing budgets but C-plane is much smaller — kilobytes versus gigabits.

S-plane: timing

This is where most O-RAN deployments stumble. The RU must be time-synced to the DU within ~100 ns for TDD 5G. The chain:

1. GPS/GNSS at the operator's grandmaster clock, OR a PRTC (Primary Reference Time Clock) traced to UTC.
2. PTP (IEEE 1588v2) carries time over the fronthaul transport network. O-RAN profiles G.8275.1 (full timing support) and G.8275.2 (partial timing support) are both allowed; G.8275.1 is preferred for fronthaul because every node is a Boundary Clock or Transparent Clock.
3. SyncE carries frequency separately. Time and frequency syntonization combined.
4. The RU locks its local oscillator to the recovered clock and uses it for over-the-air timing.

If one switch in the fronthaul path is not PTP-aware, timing fails. "PTP-unaware" switches introduce packet delay variation that wrecks the time recovery. Every switch in the fronthaul path must be a Boundary Clock or, at minimum, a Transparent Clock.

For TDD with 30 kHz subcarrier spacing, the symbol duration is ~33 μs. Timing error >130 ns starts causing inter-cell interference at TDD slot boundaries. Field-tested operator data in 2026 puts most working deployments at <50 ns end-to-end TAE (Time Alignment Error) at the antenna.

M-plane: configuration

M-plane is the slow path. NETCONF over SSH (mandatory) or TLS (allowed), with O-RAN-defined YANG models. The DU (or SMO) configures the RU: cell parameters, transmit power, antenna calibration, alarm thresholds.

Two M-plane modes:

• Hierarchical — only the DU talks to the RU. SMO talks to DU, DU translates to RU.
• Hybrid — both DU and SMO can talk to the RU. SMO handles FCAPS directly; DU handles call-affecting config.

Hybrid is more common in 2026. SMO software-upgrades RUs in a maintenance window without DU involvement.

Key YANG models: o-ran-uplane-conf, o-ran-module-cap, o-ran-performance-management, o-ran-fault-management, o-ran-supervision.

Latency budgets

For URLLC and just for working 5G, the fronthaul one-way latency budget is tight:

• DU to RU one-way: typically <100 μs for short-reach fronthaul. O-RAN Cat A RUs accept slightly more relaxed budgets; Cat B (with precoding in the RU) needs tighter.
• The transport network must add no more than that. Fiber adds ~5 μs/km. So 20 km of fiber alone consumes a quarter of the budget before any switch hop.
• Each switch hop with cut-through forwarding adds ~1-2 μs. Store-and-forward switches add far more — avoid them in fronthaul.

For longer-reach fronthaul (10+ km), you need to be careful about HARQ timing. The DU must receive UL data and send back ACK/NACK within the HARQ deadline. Long fronthaul eats into that.

What goes wrong in real deployments

1. PTP profile mismatch between DU and RU vendors. Both must agree on G.8275.1 vs G.8275.2 and on the announce/sync intervals.
2. Fronthaul switch not PTP-aware. Common when reusing existing transport gear.
3. Compression mismatch — DU sends 9-bit BFP, RU expects 12-bit. M-plane should configure this; sometimes does not.
4. VLAN tagging — U-plane and C-plane often share a VLAN, M-plane on another, S-plane on another. Trunking misconfiguration causes intermittent failures.
5. MTU — eCPRI frames can be >1500 bytes with multiple sections. Fronthaul switches must support jumbo frames; 9000 MTU is standard.

What an O-RAN-compliant RU actually has to support

• eCPRI U-plane and C-plane per O-RAN WG4 CUS-plane spec
• Two M-plane modes (hierarchical, hybrid)
• PTP G.8275.1 or G.8275.2
• SyncE
• O-RAN Conformance Test Specification compliance, validated at PlugFest events
• Self-discovery — RU broadcasts its capabilities so the DU can configure it

The O-RAN ALLIANCE conformance program is where vendors prove this works. PlugFest results, while imperfect, are the best public signal of multi-vendor maturity.

> 7.2x is not just a split — it is a contract between the DU vendor, the RU vendor, the fronthaul switch vendor, and the timing source. Every link in the chain follows the same spec or the cell does not work.

When O-RAN fronthaul fails, it is almost always timing — start there before suspecting U-plane or C-plane.