5G5G Fundamentals

The gNB Explained: CU/DU Split, Interfaces, and What Changed from the eNB

What a gNB actually is: the CU/DU functional split, the F1, E1, Xn and NG interfaces, how it differs from an LTE eNB, and the deployment models operators actually use.

By Manas·8 min read·Updated 2026-08-25

An LTE eNB is a thing. You can point at it — one box at the base of a tower running the whole protocol stack.

A gNB is better understood as a logical node. It might be one box, or it might be a central unit in a data centre thirty kilometres away, several distributed units at aggregation sites, and radio units on the mast — all cooperating to present themselves to the 5G Core as a single entity.

That shift from physical box to logical function is the most consequential difference between the two, and nearly everything else follows from it.

A gNB terminating the NR air interface toward the UE and connecting to the 5G Core over the NG interface.

Formally: a gNB is the 3GPP node providing NR user-plane and control-plane termination toward the UE, connected to the 5G Core over NG. It's specified in TS 38.401.


The functional split

3GPP defines an optional split of the gNB into two logical units — and where the cut lands is the important part.

The gNB split into a gNB-CU hosting RRC, SDAP and PDCP, connected over F1 to gNB-DUs hosting RLC, MAC and PHY.

The gNB-CU (Central Unit) hosts RRC, SDAP, and PDCP. The gNB-DU (Distributed Unit) hosts RLC, MAC, and the physical layer.

The cut sits between PDCP and RLC — 3GPP's split option 2, chosen after a long study of eight candidate options. The reasoning is about timing. Everything below the split is hard real-time: MAC scheduling runs per slot, HARQ has a fixed budget measured in microseconds. Everything above it operates on packet timescales and tolerates milliseconds of transport delay.

Put the split there and the CU can sit tens of kilometres away over ordinary IP transport. Put it lower and you need fronthaul with microsecond-class latency and gigabits of constant bandwidth.

One CU can control many DUs — a common ratio is one CU serving tens of them. Each DU belongs to exactly one CU, and one DU can host multiple cells.

The CU splits again

The CU can be divided further, by plane rather than by layer:

The gNB-CU divided into CU-CP hosting RRC and PDCP-C, and CU-UP hosting SDAP and PDCP-U, connected over E1.

gNB-CU-CP holds RRC and the control-plane part of PDCP. gNB-CU-UP holds SDAP and user-plane PDCP. They coordinate over E1.

The practical value is independent scaling. Control-plane load tracks the number of connected devices and their mobility; user-plane load tracks traffic volume. Those grow at different rates, and separating them means you can add user-plane capacity without touching signalling capacity.

One CU-CP can control multiple CU-UPs — useful for placing user-plane processing near an edge site while keeping control centralised.


The interfaces

gNB interfaces: NG to the 5G Core, Xn between gNBs, F1 between CU and DU, and E1 within the CU.

InterfaceConnectsCarries
NG-C (N2)gNB ↔ AMFControl plane, NGAP
NG-U (N3)gNB ↔ UPFUser plane, GTP-U
Xn-CgNB ↔ gNBHandover, dual connectivity, context transfer
Xn-UgNB ↔ gNBUser-plane forwarding during handover
F1-CCU-CP ↔ DUF1AP: UE context, RRC transport, cell management
F1-UCU-UP ↔ DUGTP-U with flow control
E1CU-CP ↔ CU-UPBearer context management
X2en-gNB ↔ eNBEN-DC in NSA deployments

Two details worth knowing.

F1-U carries flow control, which F1's LTE equivalent didn't need. Because PDCP sits in the CU and RLC in the DU, the CU has to know how much data the DU's buffers are holding — otherwise it either starves the scheduler or overflows the buffer. The DU sends downlink data delivery status messages upstream; the CU paces accordingly. It's a small mechanism that causes real problems when it's tuned badly.

Xn is not just handover. It carries UE context retrieval for RRC_INACTIVE resume, which is what lets a UE resume at a gNB that isn't its anchor.


Two node types that trip people up

The 5G RAN has more node types than "gNB," and the naming is unforgiving:

en-gNB — an NR node connected to the EPC, acting as secondary node in EN-DC. This is what the NR side of an NSA network actually is. It uses X2, not Xn, and has no NG interface. When someone says "our 5G network," in NSA it's en-gNBs.

ng-eNB — an LTE node connected to the 5G Core. LTE radio, 5G core. Used in deployment options 5 and 7.

The rule: the prefix tells you which core it's attached to. en- means EPC, ng- means 5GC. A network can contain gNBs, en-gNBs, and ng-eNBs simultaneously, which is exactly as much fun to operate as it sounds.


gNB vs eNB

eNB (LTE)gNB (5G NR)
Protocol stackPDCP, RLC, MAC, PHYSDAP, PDCP, RLC, MAC, PHY
QoS handlingEPS bearersQoS Flows via SDAP
ArchitectureMonolithicOptional CU/DU split
Core interfaceS1 (to EPC)NG (to 5GC)
Inter-nodeX2Xn
RRC statesIDLE, CONNECTEDIDLE, CONNECTED, INACTIVE
BeamformingOptionalFundamental, mandatory in FR2
Numerology15 kHz fixedScalable 15–240 kHz
Always-on signalsCRS across carrierLean carrier, minimal

Three of these matter more than the rest.

SDAP is genuinely new. LTE had no equivalent because LTE's QoS was bearer-based end to end — a bearer had one QoS treatment and that was that. NR receives QoS Flows from the core and has to map them onto radio bearers, and SDAP is the layer that does it.

RRC_INACTIVE changes the signalling profile substantially. A gNB retains UE context for suspended devices, which means it holds state that an eNB simply discarded.

Lean carrier design removes LTE's always-on cell-specific reference signals. An idle NR cell transmits far less than an idle LTE cell — better for energy and for inter-cell interference.


Deployment models

The specification allows the split. It doesn't require it, and operators pick based on transport economics.

Three gNB deployment models: integrated all-in-one, CU/DU split with midhaul, and centralised RAN with pooled CUs.

Integrated gNB. Everything in one unit at the site. Simplest to deploy and operate, no midhaul required. Standard for macro sites without fibre aggregation, and still the most common deployment worldwide.

CU/DU split. DUs at aggregation sites, CU centralised. Needs midhaul transport with roughly sub-10 ms latency — ordinary IP, not exotic. Benefits are centralised RRC (making mobility decisions across many cells easier), pooled processing, and simpler software upgrades.

Centralised RAN. CUs and often DUs pooled in an edge data centre, with radio units connected over fronthaul. Maximum coordination gain, but the fronthaul requirement is severe: microsecond-class latency, tight synchronisation, and constant high bandwidth regardless of traffic.

The transport naming follows the split points: fronthaul is DU-to-RU, midhaul is CU-to-DU, backhaul is CU-to-core. Getting these mixed up in a planning discussion causes expensive misunderstandings, because their requirements differ by orders of magnitude.

Where O-RAN comes in

3GPP's split option 2 divides CU from DU. It deliberately left the DU-to-radio boundary unspecified — which is the gap O-RAN filled with Split 7-2x and the Open Fronthaul specification.

So an O-RAN deployment uses both: 3GPP's split for CU/DU, O-RAN's for DU/RU. The naming maps cleanly — O-CU, O-DU, O-RU are the O-RAN profiles of these same functions. (O-RAN architecture in detail.)


What a gNB actually does

Stripped to essentials:

Radio resource management — scheduling, link adaptation, power control, HARQ. The per-slot decisions.

Mobility — measurement configuration, handover decisions, beam management within cells.

Connection management — RRC state transitions, including maintaining context for RRC_INACTIVE devices.

QoS enforcement — mapping QoS Flows to radio bearers via SDAP, then honouring the profiles in the scheduler.

Security — PDCP ciphering and integrity protection over the air.

Core interaction — NGAP signalling toward the AMF, GTP-U tunnelling toward the UPF.

The scheduler is where most of these converge, and it's the part 3GPP deliberately doesn't specify — which is why two conformant gNBs can behave quite differently under identical conditions.


The mental model

A gNB is a logical node, not necessarily one box.

CU = RRC/SDAP/PDCP. DU = RLC/MAC/PHY. The split sits between PDCP and RLC because that's where hard real-time ends.

CU-CP and CU-UP split by plane over E1, so control and user capacity scale independently.

F1 is CU↔DU, E1 is within the CU, Xn is gNB↔gNB, NG is gNB↔core.

en-gNB attaches to the EPC. ng-eNB attaches to the 5GC. The prefix names the core.

Fronthaul is DU↔RU. Midhaul is CU↔DU. Backhaul is CU↔core. Very different requirements.

The gNB is where 5G's flexibility becomes concrete — and also where most of the operational complexity lives, because a node that can be deployed six different ways is a node with six different failure profiles.


Further reading

  • 3GPP TS 38.401 — NG-RAN architecture description
  • 3GPP TS 38.470 — F1 general aspects and principles
  • 3GPP TS 37.483 — E1 application protocol
  • 3GPP TS 38.300 — NR and NG-RAN overall description
  • O-RAN architecture explained
5GRANgNB