1.1 · The mobile network as four blocks

Every cellular system ever built — AMPS, GSM, UMTS, LTE, NR — decomposes into the same four functional blocks in series: the device, the radio access network, the core network, and the data network it ultimately reaches. This is not an accident of history; it is a deliberate separation of concerns. The radio access network is specialised entirely for one job — moving bits across the air efficiently and reliably — while the core is specialised for a different job — knowing who the subscriber is, where they are, what they are allowed to do, and how to route their traffic. Keeping these two concerns apart lets each evolve on its own clock, lets one core serve many radio technologies at once, and lets operators buy radio and core from different vendors.

Notice where the wireless link sits. The device speaks to the RAN, and only to the RAN, across the air interface called Uu. From the base station inward, every link is fibre or structured cable. This single fact shapes the entire design: the air is the scarce, unreliable, shared resource, so the cleverest engineering in the whole system is concentrated at the radio edge. The core, by contrast, is essentially a very specialised set of routers and databases running in a data centre.

The boundary is also a standards boundary. 3GPP specifies the RAN and the core as separate work areas with separate, well-defined interfaces between them. In 5G that interface is NG (LTE called it S1). Because the interface is open and standardised, an operator can in principle place a vendor-A radio in front of a vendor-B core. The same logic, pushed harder, becomes the O-RAN movement we meet in Chapter 2.

1.2 · The radio problem — why the RAN is hard

To understand why the RAN is structured the way it is, you have to feel the problem it is solving. The radio channel is hostile in four distinct ways, and almost every feature in the stack exists to beat one of them.

1.2.1 · It is shared

Unlike a fibre, where each user gets a dedicated strand, the air is a single broadcast medium. Every transmission is potentially heard by — and interferes with — every receiver in range. If two devices transmit on the same frequency at the same time and place, their signals collide and both are lost. The RAN must therefore schedule access: decide who transmits, when, on what frequency, at what power, so that allocations never overlap. This is why the MAC scheduler (Chapter 4) is the single most important real-time function in the network — it is the traffic controller for a medium everyone wants at once.

1.2.2 · It is finite

Usable spectrum is a regulated, auctioned, scarce resource. An operator might hold 100 MHz at 3.5 GHz and pay billions for it — and that bandwidth is fixed. So the entire game is spectral efficiency: extracting more bits per second per hertz from the allocation you have. Shannon sets the ceiling — capacity rises with bandwidth and (logarithmically) with signal-to-noise ratio — and every NR feature pushes against it: higher-order modulation packs more bits per symbol when the SNR allows, better coding protects them, and MIMO sends several streams in the same Hz. Spectral efficiency is not a nicety; it is the business.

1.2.3 · It fades

A radio wave reaches the receiver by many paths — direct, reflected off buildings, diffracted around edges. These copies arrive with different delays and phases and add up constructively or destructively, so the received power can swing by tens of decibels over the distance of a few centimetres or a few milliseconds. Worse, the cancellation is frequency-selective: the channel can be strong at one frequency and in a deep notch at another, at the same instant. The channel a device sees is never static. OFDM, fast link adaptation, HARQ and channel-quality feedback all exist to ride this constantly changing channel.

1.2.4 · It moves

The device is mobile, and motion attacks the link three ways at once. Its serving cell weakens as it travels while neighbours strengthen, forcing a handover decision. Its Doppler shift changes — motion toward or away from the gNB shifts the received frequency by ±f_D, which the receiver must track. And its propagation delay drifts as the distance changes, so the uplink arrival time slips — corrected continuously by timing advance commands. Mobility forces the network to measure, decide and hand the connection over without dropping it — the machinery of §1.3 and Chapter 4.

1.3 · Cells, sectors, reuse and handover

The cellular idea is to defeat scarcity by reusing the same spectrum in space. Rather than one giant transmitter covering a city, the area is tiled with many small coverage zones — cells — each using a slice of spectrum that is reused again a safe distance away, far enough that the interference has decayed. Shrinking cells is the most powerful lever for capacity: halve the cell radius and you roughly quadruple the sites, and so the total throughput, over the same area. This is why dense urban 5G leans on small cells and millimetre-wave.

A real site rarely radiates a single omnidirectional cell. Instead it is sectorised: typically three directional antenna panels at 120° spacing, each forming its own cell. Three sectors triple a site's capacity for little extra cost. In 5G this idea is taken to its limit by massive-MIMO beamforming, where the "sector" dissolves into dozens of dynamically steered beams (Chapter 2).

Because cells overlap, a moving device is constantly choosing. The network configures it to measure the serving cell and its neighbours (using their reference signals — in NR, the SSB), and to report when a configured condition is met. The canonical condition is Event A3: "a neighbour has become better than my serving cell by an offset, for longer than a time-to-trigger." When that fires, the network executes a handover, moving the radio connection to the neighbour. In NR this is a hard handover — break-before-make at the cell level — but the higher layers (PDCP) preserve the data so the user never perceives a gap. Dual connectivity and conditional handover (Rel-16) soften the edges further.

Handover type	What moves	Notes
Intra-gNB (intra-DU)	Cell within one DU	Lightest; no core signalling
Intra-gNB inter-DU	Cell across DUs of one CU	F1 reconfiguration, PDCP anchored in CU
Xn handover	Between gNBs directly	Source→target over Xn, core path switched after
NG handover	Between gNBs via core	Used when no Xn exists; AMF relays

1.4 · The base station through the generations

The base station is renamed every generation, but the rename always hides a structural shift. In 3G the radio was a NodeB controlled by a separate RNC that held the smarts and mobility. LTE collapsed the RNC's functions into the radio itself, producing the self-contained eNodeB — flatter, lower-latency, all-IP. 5G's gNodeB then does the opposite of collapsing: it splits the base station back apart, but along new lines and for new reasons (Chapter 2). So the arc is RNC+NodeB → integrated eNodeB → disaggregated gNodeB, each step driven by the latency, capacity and deployment economics of its era.

Gen	Radio node	Core	Defining radio trait
3G UMTS	NodeB (+ RNC)	PS/CS core	WCDMA, soft handover
4G LTE	eNodeB	EPC	OFDMA, 15 kHz SCS, flat all-IP
5G NR	gNodeB (CU/DU/RU)	5G Core	Scalable numerology, beams, slicing

2.1 · Why disaggregate at all?

An LTE eNodeB is a single, sealed box at the cell site holding the entire radio stack. It works, so why break it apart? The answer is a stack of pressures that all point the same way. Centralisation gains: if you pull the baseband of many sites into one location, those basebands can cooperate — coordinate interference, share processing pools, perform joint reception — in ways physically separated boxes cannot. Deployment economics: compute is cheaper and easier to cool, secure and upgrade in an edge data centre than in a thousand roadside cabinets. Transport flexibility: different operators have different fibre realities, so the standard must allow the radio to sit close to the antenna while the heavier processing sits wherever fibre and latency allow. And vendor diversity: if the split points are open interfaces, an operator can mix a radio unit from one supplier with a baseband from another — breaking the historic single-vendor lock on each site. This last pressure is the engine behind O-RAN.

2.2 · One box becomes three — CU, DU, RU

2.2.1 · The principle — split by timescale

The gNodeB is split into three logical units. The split is not arbitrary; it follows the natural timescales of the protocol stack. Layers that work at packet timescales and benefit from centralisation go up into the CU. Layers that must run in lockstep with the radio frame go down into the DU. The radio itself — the part that must physically sit at the antenna — is the RU. Read the stack as a thermometer of urgency: the closer a layer is to the air, the tighter its real-time deadline, and so the closer to the antenna it must live.

2.2.2 · The CU — and its CU-CP / CU-UP split

The CU (Central Unit) hosts RRC, SDAP and PDCP — the layers that deal in radio bearers, security and packet ordering, all of which tolerate a few milliseconds of transport latency and gain from being centralised across many cells. The CU is itself split again, along the control/user line, into two further units. The CU-CP holds the control plane — RRC and the signalling part of PDCP — and terminates N2 (NGAP) up to the AMF. The CU-UP holds the user plane — SDAP and the data part of PDCP — and terminates N3 (GTP-U) up to the UPF. The two are joined by the E1 interface (E1AP, control-plane only): the CU-CP configures the CU-UP over E1, telling it which bearers to set up and how. Below the CU, the F1 interface itself splits to match — F1-C from the CU-CP and F1-U from the CU-UP, both reaching the DU.

Why bother splitting the CU? Because control and user planes scale differently. Signalling load (registrations, handovers) and traffic load (throughput) rarely move together, so separating them lets an operator scale CU-UP instances for capacity independently of CU-CP instances for signalling. It also lets the CU-UP be pushed closer to the edge — even co-located with a local UPF for local breakout / MEC, cutting the round-trip for low-latency apps — while the CU-CP stays central where coordination is easiest.

2.2.3 · The DU — and the 1 : N : M topology

The DU (Distributed Unit) hosts RLC, MAC and the High-PHY. These layers run the per-slot machinery — segmentation, the scheduler, HARQ, coding and modulation — and cannot tolerate more than a fraction of a millisecond of latency to the radio, so the DU lives at or very near the cell site (or in a C-RAN hub close to it). The relationship between the units is one-to-many in two stages: one CU controls many DUs, and one DU drives several cells (each typically realised by an RU). This 1 : N : M fan-out is what lets a single centralised CU oversee a whole region's worth of radio.

2.2.4 · The RU

The RU (Radio Unit) holds the Low-PHY — the parts of the physical layer below the functional split: typically the iFFT/FFT, cyclic-prefix handling and (in Category B) the beamforming precoding — plus the RF chain, filters and power amplifiers. It is the one unit that must physically sit at the antenna, because it is, fundamentally, the radio. While the CU and increasingly the DU run as virtualised software on commodity servers, the RU stays purpose-built hardware: amplifiers, converters and filters are physical analog things.

2.2.5 · Where each unit lives

Putting it together, each unit has a characteristic set of layers, a place in the network, a latency budget to the radio, and a hardware style. In O-RAN terminology the three become the O-CU (itself O-CU-CP + O-CU-UP), O-DU and O-RU, and both the O-CU and O-DU can expose an E2 interface to the Near-RT RIC for programmable control.

Unit	Layers	Sits	Latency to radio	Hardware	O-RAN
CU	RRC, SDAP, PDCP	Edge / regional DC	~ milliseconds (midhaul)	COTS server (vRAN)	O-CU-CP / O-CU-UP
DU	RLC, MAC, High-PHY	Cell site or C-RAN hub	~ 100 µs (fronthaul)	Server + accelerator	O-DU
RU	Low-PHY, RF	At the antenna	— (is the radio)	Purpose-built	O-RU

2.3 · Functional splits — the central trade-off

2.3.1 · The eight candidate split points

Where exactly should you cut the stack? 3GPP's study (TR 38.801) catalogued eight candidate split points, numbered from Option 1 (the highest, just below RRC) down to Option 8 (between PHY and RF). Each option is a different bargain between two opposing forces. Split high (e.g. Option 2, between PDCP and RLC) and the interface carries ordinary packets — modest, bursty bandwidth, relaxed latency, cheap transport — but you lose the chance to coordinate the lower layers across sites. Split low (e.g. Option 7 or 8, inside or below the PHY) and you can centralise almost everything and do tight inter-cell coordination — but the interface must now carry a torrent of near-raw signal samples at constant multi-gigabit rates with microsecond timing. There is no free lunch; the split point is the trade-off.

Split	Cut point	Interface bandwidth	Latency budget	Coordination gain
Opt 2	PDCP / RLC	≈ user rate (bursty)	milliseconds	low — packets only
Opt 6	MAC / PHY	moderate, bursty	~hundreds of µs	medium
Opt 7-2x	inside PHY	~10× the user rate, constant	~100 µs	high — joint PHY
Opt 8	PHY / RF (CPRI)	~100× the user rate, constant	tens of µs	maximal — but unaffordable

2.3.2 · The two cuts the industry chose

The industry settled on two cuts, not one. 3GPP standardised the higher-layer split, Option 2 (PDCP/RLC) as the CU↔DU boundary, carried by the F1 interface. It is packet-friendly and bandwidth-light, making it deployable over almost any transport. Separately, the O-RAN Alliance standardised a lower-layer split, 7-2x, inside the physical layer, as the DU↔RU fronthaul boundary, carried by eCPRI. The 7-2x point is chosen to keep the brutally heavy, fully-raw work (Option 8/CPRI) out of the fronthaul while still centralising the High-PHY in the DU — a compromise that cuts fronthaul bandwidth by an order of magnitude versus old CPRI, and crucially makes the interface open so multi-vendor RU/DU becomes possible.

2.3.3 · Inside 7-2x — Category A vs B, and why centralise at all

The 7-2x split itself has two flavours, defined by O-RAN by where the precoding (beamforming weight application) happens. In Category A the precoding is done in the DU, so the RU receives already-precoded streams — a simpler, "dumber" RU but more data on the fronthaul (one stream per layer). In Category B the precoding moves into the RU, which cuts fronthaul bandwidth (carry fewer layers, precode locally) at the cost of a more capable RU. Operators trade RU complexity against fronthaul cost: Category B suits high-order massive-MIMO where carrying every antenna stream uncompressed would be ruinous.

Why centralise the lower layers at all, given the fronthaul pain? Because a centralised baseband can do things separate boxes cannot. When many cells' DUs sit in one pool, they can perform CoMP (Coordinated Multipoint) — joint transmission and reception across cells — and tight inter-cell interference coordination, turning what would be interference at a cell edge into a coordinated, even cooperative, signal. Pooling also lets compute be shared statistically across sites (one site's busy hour is another's quiet hour), improving hardware utilisation. The higher the split, the cheaper the transport but the less of this coordination is possible — which is precisely why the industry kept two cuts: Option 2 for cheap, flexible packet transport up to the CU, and 7-2x to still centralise the High-PHY in the DU where the coordination gains live.

2.4 · Transport tiers and the tyranny of fronthaul

2.4.1 · Three tiers, three budgets

Disaggregation creates three transport segments, and they could not be more different in their demands. The decisive constraint is the fronthaul.

Fronthaul exists because the High-PHY (DU) and Low-PHY (RU) are two halves of one tightly-coupled physical layer that must stay frame-synchronous. Midhaul (F1, Option 2) carries ordinary packets at millisecond latency, and backhaul (NG) is relaxed at tens of milliseconds. Get the fronthaul timing wrong and the cell simply does not work; get the backhaul slightly slow and you only lose a little throughput.

2.4.2 · The fronthaul bandwidth problem — CPRI vs eCPRI

The reason the fronthaul split point matters so much is bandwidth. The old CPRI interface (Option 8) carries fully digitised antenna samples: its rate is proportional to the number of antenna elements × sampling rate × bit depth, completely independent of how much user traffic there actually is. For a 64-element massive-MIMO radio that is a constant firehose of tens of gigabits per second per carrier — utterly unaffordable to backhaul from thousands of sites. The 7-2x split with eCPRI breaks that scaling: by cutting inside the PHY (and, in Category B, precoding in the RU), the fronthaul carries roughly the number of layers/streams rather than antenna elements, and rides packetised over standard Ethernet. The result is roughly an order-of-magnitude bandwidth reduction — the difference between "deployable" and "not."

	CPRI (Option 8)	eCPRI (7-2x)
What's carried	Raw I/Q antenna samples	Frequency-domain symbols / layers
Bandwidth scales with	antenna elements (constant)	layers / users (lower)
Transport	Dedicated, constant-bit-rate	Packetised over Ethernet
Massive-MIMO friendly	No — firehose	Yes — ~10× less
Multi-vendor	Effectively no	Yes (open spec)

2.4.3 · Synchronisation — the timing budget

Fronthaul's hardest demand is not bandwidth but timing. For TDD to work, every RU must agree on where the uplink/downlink boundary is to within a fraction of a microsecond; for beamforming and MIMO across antennas to combine correctly, their phases must align. So the network distributes precise time, phase and frequency from a traceable source. A PRTC (Primary Reference Time Clock, usually GNSS-disciplined) feeds a Telecom Grandmaster (T-GM), which distributes time via PTP (IEEE 1588, profile ITU-T G.8275.1) and syntonises frequency via SyncE, hop by hop, down to the DU and RU. The whole chain must hold the end-to-end Time Alignment Error within roughly ±1.5 µs at the air interface — a budget that every switch in the path eats into, which is why fronthaul networks are engineered switch-by-switch.

2.4.4 · The interfaces

Interface	Connects	Control protocol	User-plane
F1	CU ↔ DU	F1AP / SCTP	GTP-U (F1-U)
E1	CU-CP ↔ CU-UP	E1AP / SCTP	— (control only)
Xn	gNB ↔ gNB	XnAP / SCTP	GTP-U (Xn-U)
NG	gNB ↔ 5GC	NGAP / SCTP (N2)	GTP-U (N3)
Uu	UE ↔ gNB	RRC	SDAP/PDCP…PHY

⚙ TR 38.801⚙ TS 38.401⚙ TS 38.470 (F1)⚙ O-RAN.WG4 7-2x

2.5 · Deployment — NSA, SA and the option family

2.5.1 · Why there is an option family

Standardising a new radio and a new core at once is risky and slow, so 3GPP defined a family of deployment options that let operators introduce 5G in stages. The two that matter most are NSA and SA.

2.5.2 · NSA and SA

NSA (Non-Standalone), Option 3x was the industry's fast on-ramp. It reuses the existing LTE eNodeB and EPC, and bolts a 5G gNodeB on as a secondary node. The LTE eNodeB is the master — it owns the control-plane connection to the EPC and anchors mobility — while the gNodeB adds a high-throughput user-plane leg. The device is connected to both at once; this EN-DC (E-UTRA–NR Dual Connectivity) is a special case of the broader MR-DC (Multi-Radio Dual Connectivity) family. In Option 3x specifically, the user-plane is split at the gNodeB's PDCP so traffic can flow down either the LTE or the NR leg. NSA gets 5G capacity to market without waiting for a 5G core — but it cannot deliver true network slicing, ultra-low latency or the service-based features, because those live in the 5G core it does not use.

SA (Standalone), Option 2 is the destination. The gNodeB connects directly to the 5G Core with no LTE in the path. Only SA unlocks the full 5G feature set — network slicing, URLLC, the service-based architecture, RRC_INACTIVE.

2.5.3 · The MR-DC family

EN-DC is one member of a broader family, MR-DC (Multi-Radio Dual Connectivity), which generalises "a master node plus a secondary node, of possibly different RATs, on one core." The four members are distinguished by which RAT is master, which is secondary, and which core they use:

Config	Master	Secondary	Core	Option
EN-DC	LTE eNB	NR gNB	EPC	3 (NSA)
NGEN-DC	LTE ng-eNB	NR gNB	5GC	7
NE-DC	NR gNB	LTE ng-eNB	5GC	4
NR-DC	NR gNB	NR gNB	5GC	(NR-NR)

Only EN-DC uses the EPC; the other three are 5GC-anchored, which is why they appear later in most networks' migrations. NR-DC is special — both legs are NR, used to combine, say, an FR1 coverage layer with an FR2 capacity layer.

2.5.4 · Option 3 variants and bearer types

Within NSA Option 3, the sub-variant says where the user-plane bearer splits — and that placement decides which node bears the traffic-steering load. The bearer can split at the LTE eNB's PDCP (Option 3, but that demands an upgraded eNB), or the two legs can be entirely separate bearers to the EPC (Option 3a), or — most commonly — the bearer splits at the gNB's PDCP (Option 3x), letting the new 5G node anchor the split and offloading the legacy eNB. This is exactly the MCG/SCG/split-bearer model of dual connectivity:

2.5.5 · The migration path

Put together, the options describe a journey from 4G to full 5G. Most operators began at Option 1 (LTE on the EPC), bolted on 5G capacity via Option 3x (NSA, still EPC-anchored), and are now moving to Option 2 (SA, on the 5G Core) — with Options 4 and 7 as 5GC-anchored dual-connectivity steps along the way.

2.6 · Beam-based coverage and massive MIMO

2.6.1 · Why beams — the link-budget problem

LTE cells broadcast their control and reference signals widely, like a floodlight. 5G NR, especially at higher frequencies, cannot afford to — radio path loss rises steeply with frequency, so a millimetre-wave signal spread evenly over a sector would simply not reach the cell edge. The fix is to stop spreading energy and start aiming it. A massive-MIMO array of dozens to hundreds of antenna elements forms narrow beams and steers energy precisely toward each user, like a spotlight that follows them. This does two things at once. It recovers the link budget: an N-element array concentrates power into a beam with roughly N× the gain of a single element, buying back the path loss. And it raises spatial reuse: because the beams point in different directions, many users can be served on the same time-frequency resource at once (MU-MIMO), multiplying capacity without any extra spectrum.

2.6.2 · How a phased array steers a beam

The steering is pure wave physics, no moving parts. The array's elements are spaced about half a wavelength apart (d ≈ λ/2) and each is fed a copy of the same signal but with a progressively increasing phase shift. Where those copies arrive in step, they add constructively into a strong main lobe; where they cancel, there is a null. By choosing the phase increment Δφ across the elements, the network tilts the combined wavefront — and hence the main lobe — to any angle θ, given by Δφ = (2π·d/λ)·sin θ. More elements make the lobe both stronger (more gain) and narrower (sharper aim, less interference leaking elsewhere). This is beamforming: electronically pointing an antenna by adjusting phases.

2.6.3 · Where the beamforming happens — analog, digital, hybrid

Phases can be applied at three different points in the chain, and the choice is the central cost/capability trade of the radio. In analog beamforming one RF/baseband chain feeds a network of phase shifters driving all the antennas — cheap and power-efficient, but it can form one beam at a time, so it is common at mmWave where chains are expensive. In digital beamforming every antenna has its own RF chain and converter, giving full per-element control and many simultaneous beams — the most powerful, but the most expensive and power-hungry, so it suits FR1 with moderate element counts. Hybrid beamforming is the practical FR2 compromise: a modest number of digital chains, each driving an analog sub-array of many elements, yielding a handful of simultaneous beams at affordable cost.

2.6.4 · SU-MIMO, MU-MIMO and spatial multiplexing

Beamforming and MIMO are two uses of the same array. Spatial multiplexing sends several independent data streams — layers — over a rich multipath channel to one device (single-user MIMO, up to 8 layers to a capable UE). MU-MIMO goes further: it points different beams at different users on the very same time-frequency resource, so a 64-element array might serve a dozen users simultaneously where LTE served one. The catch is that the beams must be spatially separable, which means the gNodeB needs an accurate picture of each user's channel — gathered from SRS sounding in the uplink and CSI feedback in the downlink — and must compute a precoder that maximises each user's signal while nulling it toward the others. Get the channel knowledge right and MU-MIMO is the single biggest capacity multiplier in 5G; get it stale and the users interfere.

2.6.5 · Beam management — P1, P2, P3 and recovery

A beam is useless if it points at where the user was. So the gNodeB and UE continuously pair and refine their beams through three procedures. P1 is initial acquisition: the gNodeB sweeps a set of wide SSB beams across the cell in an SS burst set, the UE measures each and reports the best, establishing a coarse Tx/Rx beam pair. P2 refines the gNodeB's transmit beam: it sweeps a few narrower CSI-RS beams around the chosen direction and the UE picks the best. P3 refines the UE's receive beam: with the gNB beam fixed, the UE sweeps its own receive beams to find the sharpest. The chosen relationship is signalled through TCI states (which tell the UE which reference signal a channel is quasi-co-located with — i.e., which beam to use). And because mmWave beams are fragile — a hand or a passing bus can break one — there is beam-failure detection (the UE watches its serving beam's quality) and beam-failure recovery (a fast RACH-based procedure to switch to a known-good beam) so a blocked beam recovers in milliseconds rather than dropping the call.

2.6.6 · FR1 versus FR2

Everything above is dialled differently in the two frequency ranges. FR1 (sub-7.125 GHz) has gentler propagation, so it leans on moderate massive-MIMO (32T/64T arrays, digital or hybrid) for capacity over relatively wide cells; beams help but the cell still works without razor-sharp ones. FR2 (24.25–52.6 GHz, extended toward 71 GHz in Rel-17) lives or dies by beamforming: raw propagation is poor and blockage-prone, the wavelength is tiny so hundreds of elements fit in a small panel, and analog/hybrid beamforming with constant, aggressive beam management is mandatory just to keep a link alive.

	FR1 (< 7.125 GHz)	FR2 (mmWave 24–71 GHz)
Propagation	Good, wide cells	Poor, blockage-prone, short range
Array	32T/64T, larger elements	Hundreds of tiny elements
Beamforming	Digital / hybrid	Analog / hybrid
Beam management	Helpful	Essential, frequent
Typical SCS	15 / 30 kHz	120 kHz

3.1 · NG-RAN and its three directions

The radio access network in 5G is the NG-RAN, and it contains two kinds of node: the gNodeB (a true NR radio) and the ng-eNodeB (an LTE radio upgraded to speak to the 5G core). Both are first-class NG-RAN nodes. Every NG-RAN node wires up in exactly three directions, and understanding those three directions is most of the architecture.

Up to the core, over the NG interface — and here is a subtlety that defines 5G: NG forks into two streams that go to different core functions. The control stream N2 (carrying NGAP signalling) terminates at the AMF; the user stream N3 (carrying GTP-U tunnelled data) terminates at the UPF. The network's brain and its data path are deliberately separated — Control and User Plane Separation, native to 5G. Down to the device over the air interface Uu. And sideways to neighbour NG-RAN nodes over Xn, used for handovers and dual connectivity without troubling the core.

3.2 · The 5G Core and the Service-Based Architecture

3.2.1 · From fixed boxes to software services

The LTE core (EPC) was a set of dedicated network elements wired together with fixed, point-to-point, protocol-specific interfaces (S11, S5/S8, S6a, each with its own protocol). Adding a feature often meant touching several of those rigid interfaces. The 5G core throws that model out and adopts a Service-Based Architecture (SBA): each control-plane function is a software network function (NF) that exposes its capabilities as services on a common bus, and any authorised NF can invoke any other's service over a uniform, web-native protocol — HTTP/2 with JSON payloads, using a RESTful design. The interfaces are named after the producer (Namf, Nsmf, Nudm…) rather than after a pair of boxes.

This design buys three things that the EPC could not offer. Elasticity: each NF is a microservice that can be scaled out independently — spin up more AMF instances under signalling load without touching the user plane. Modularity: a new capability is a new service consumer, not a new rigid interface. Discovery without configuration: NFs do not need to be statically wired to each other. Instead every NF registers its NF profile (type, address, capabilities, supported slices) with the NRF, and when one NF needs another it queries the NRF — "find me an SMF that serves slice X in this region" — and gets back a concrete instance to call. The NRF is the registry and matchmaker that has no EPC equivalent, and it is what makes the whole bus self-organising.

Only the UPF stays off the service bus, because it is the user-plane workhorse: it forwards packets on the fast data path and is controlled, not invoked. The SMF programs it over the N4 reference point using PFCP, the one place where a control function reaches down and configures the user plane. This is again CUPS — the SMF decides, the UPF forwards.

NF	Role	Key reference / interface
AMF	Registration, connection & mobility management; terminates NAS-MM; the single point of contact for the RAN	N1 (UE), N2 (RAN)
SMF	PDU session lifecycle, IP address allocation, UPF selection & control, QoS & charging rules	N4 (UPF), SBI
UPF	Packet forwarding/routing, QoS enforcement, usage reporting, the PDU-session anchor	N3, N6, N9
AUSF	Authentication server — runs 5G-AKA / EAP-AKA′ with the UE	SBI
UDM / UDR	Subscription data, key material & the data repository behind it	SBI
PCF	Policy & charging control — produces QoS and usage rules	SBI
NSSF	Network Slice Selection — chooses the slice instance for a UE	SBI
NRF	NF registration & discovery — the registry of the whole bus	SBI
NEF	Exposes selected core capabilities securely to outside applications	SBI / API

3.2.2 · The service model — request/response and subscribe/notify

NFs do not just "call each other" loosely; they expose NF services, each a versioned REST API with named operations (for example Nudm_SDM for subscriber data management, Namf_Communication, Nsmf_PDUSession). Two interaction patterns cover everything. In request-response, a consumer invokes an operation and gets a single answer — the SMF asking the UDM "give me this subscriber's session data." In subscribe-notify, a consumer subscribes to an event and the producer pushes notifications when it happens — the AMF subscribing to the UDM so it is told whenever a subscription changes. This is the same producer/consumer, REST-plus-events model used across modern microservice platforms, which is the whole point: the core is now built like cloud software.

3.2.3 · Discovery and security — the NRF handshake

Because nothing is statically wired, every interaction begins with discovery, and the NRF sits at the centre of it. Three steps recur. (1) Register: on start-up each NF registers its NF profile — type, address, served slices, capabilities — with the NRF. (2) Discover: when a consumer needs a producer, it queries the NRF ("an SMF for slice X in this region") and gets back concrete candidate instances. (3) Authorise: the NRF doubles as an OAuth 2.0 authorization server, issuing the consumer an access token scoped to the producer's service; the consumer presents that token when it calls the producer, and the call rides mutual TLS. Across operator boundaries (roaming), the SEPP guards the SBI on the N32 interface. So discovery and security are one fused mechanism — you cannot reach a producer you were not authorised by the NRF to reach.

who exists and who may call whom.

3.2.4 · Direct vs indirect communication — the SCP

Making every consumer discover, select, load-balance and retry against producers itself is a lot of duplicated logic. So 5G adds the SCP (Service Communication Proxy): a routing element that consumers can delegate to, which performs discovery, instance selection, load-balancing and message forwarding on their behalf. 3GPP defines communication "models" from fully direct (consumer does its own discovery and calls the producer) to fully indirect (the consumer hands the request to the SCP, which discovers and routes). The SCP is, in effect, the 5G core's service mesh — the component that lets a large deployment scale to hundreds of NF instances without every NF becoming a routing expert.

3.2.5 · Stateless NFs and the UDSF

The deepest cloud-native idea is to separate compute from state. NFs are designed to be stateless: an instance holds no irreplaceable session state of its own, but stores it in a shared UDSF (Unstructured Data Storage Function). Any instance can then serve any request, instances can be added or removed under load, and a failed instance loses nothing — another picks up its sessions from the UDSF. This is what turns "a box you reboot carefully" into "a pod you can kill and reschedule," and it is the reason the service-based core can run on the same elastic infrastructure as any other cloud workload. The UPF is the one part deliberately left on the fast, stateful data path — programmed by the SMF over N4 with PFCP, the one place a control function reaches down into the user plane (CUPS: the SMF decides, the UPF forwards).

3.3 · A connection coming alive — the two flows

The architecture is easiest to remember as two procedures. Registration attaches the device to the network; PDU session establishment opens its data pipe. Almost everything else is a variation on these.

Registration (attach)

The device sends a NAS Registration Request up over N1, relayed by the gNodeB into N2 to a chosen AMF. The AMF, finding it lacks a security context, triggers authentication: it asks the AUSF/UDM for a challenge and runs 5G-AKA with the device, mutually proving identity and deriving a fresh key tree (§4.3). It then runs NAS Security Mode Control to switch on NAS ciphering and integrity, fetches the subscription from the UDM, and returns a Registration Accept. The device is now known, located (to a registration area) and reachable by paging — but it still has no data path.

PDU session establishment

To get data flowing, the device sends a NAS PDU Session Establishment Request, which the AMF routes to an appropriate SMF (discovered via the NRF, honouring the requested slice). The SMF allocates an IP address, selects a UPF, and programs it over N4 with the forwarding and QoS rules. The SMF returns, via the AMF, the information the gNodeB needs to set up the radio side; the gNodeB establishes the Data Radio Bearer over the air and the N3 GTP-U tunnel to the UPF. Now the path is complete: app → UE → (Uu, DRB) → gNB → (N3 tunnel) → UPF → (N6) → data network. The QoS flows that ride inside this session are what SDAP maps onto DRBs in Chapter 4.

3.4 · Transport and the 5G QoS model

Two protocol towers carry everything across the interfaces. Signalling — NGAP, XnAP, F1AP, E1AP — rides SCTP, a transport built for signalling: message-oriented, multi-streamed (so head-of-line blocking on one procedure doesn't stall others), and multi-homed for resilience. User data rides GTP-U over UDP, where each device's traffic sits in its own tunnel identified by a TEID, so the network can route and meter per session.

5G's quality-of-service model is finer-grained than LTE's. LTE's unit was the EPS bearer, set up end to end and relatively coarse. 5G's finest unit is the QoS flow, identified by a 6-bit QFI. Each flow is characterised by a 5QI — a standardised index into a table (TS 23.501) that fixes its resource type (GBR or non-GBR), priority, packet delay budget and packet error rate. For example 5QI 1 is conversational voice (GBR, ~100 ms budget), 5QI 9 is the default non-GBR "best-effort" bearer, and the 5QI 82–85 range covers delay-critical URLLC. Multiple QoS flows are mapped onto Data Radio Bearers by SDAP — the bridge from the core's QoS model to the radio's bearers, which is exactly where Chapter 4 begins.

⚙ TS 23.501⚙ TS 38.413 (NGAP)⚙ TS 29.281 (GTP-U)

3.5 · Network slicing

3.5.1 · What a slice actually is

Slicing is the feature that most justifies the whole service-based redesign. A network slice is a complete, logically isolated end-to-end network — its own selection of NFs, its own policies, its own performance profile — running over shared physical infrastructure. The word "end-to-end" is the important part: a slice spans all three domains at once — the RAN (slice-aware scheduling), the transport (separated connectivity), and the core (per-slice NFs) — so the guarantee holds the whole way from the device to the data network. One slice might be tuned for massive IoT (huge device counts, tiny packets), another for URLLC (millisecond latency, extreme reliability), another for enhanced mobile broadband. They share the same towers, fibre and servers, yet behave as if each were its own dedicated network.

3.5.2 · Naming a slice — the S-NSSAI

A slice is identified by an S-NSSAI (Single Network Slice Selection Assistance Information). It is at most 32 bits, in two parts. The mandatory SST (Slice/Service Type, 8 bits) says what kind of slice it is, and 3GPP standardises the low values so they mean the same thing everywhere (TS 23.501). The optional SD (Slice Differentiator, 24 bits) distinguishes multiple slices of the same type — for example two separate URLLC slices, one per enterprise tenant. A set of up to eight S-NSSAIs is an NSSAI (note the dropped "S"); a UE can be served by up to eight slices at once.

3.5.3 · Choosing a slice — selection at registration

Slice selection happens as the device registers. The UE includes a Requested NSSAI (drawn from the slices configured in it). The RAN uses it to route the registration to a suitable AMF — and here is a nuance worth holding onto: the AMF is shared across a UE's slices in a registration area (one UE, one AMF), so it is not a per-slice NF. The AMF, helped by the NSSF, checks the UE's subscription (via the UDM) and network policy to compute the Allowed NSSAI — the slices the UE may actually use here — and, if the current AMF cannot serve that set, the NSSF returns a target AMF for reselection. Only once a PDU session is set up for a given slice does the per-slice machinery engage: the NRF performs slice-aware discovery (NF profiles advertise the S-NSSAIs they support) to find that slice's SMF and UPF.

3.5.4 · The NSSAI vocabulary

The word NSSAI appears with many qualifiers, and confusing them is a classic stumble. Each names a different list of slices at a different point in the lifecycle:

Term	What it is · where it lives
Configured NSSAI	Slices provisioned in the UE for a PLMN (its starting knowledge)
Requested NSSAI	What the UE asks for at registration (from its Configured set)
Subscribed S-NSSAIs	What the subscription permits (in the UDM); one or more marked default
Allowed NSSAI	What the network grants for this registration area (from AMF/NSSF)
Rejected NSSAI	Requested slices that were refused (with a cause)
Default S-NSSAI	Used when the UE requests none, or none requested is allowed

3.5.5 · Isolation — from soft to hard

"Isolated" is a dial, not a switch. How strongly two slices are separated is an engineering and commercial choice, traded against cost, and it can differ per domain. At the soft end, slices share everything and are merely prioritised differently. Tighten it and the RAN scheduler reserves PRBs per slice (RRM policy) so one slice's load cannot steal another's airtime. Tighter still, each slice gets a dedicated UPF (separate user-plane, separate breakout, even at the edge). Tighter again, dedicated control-plane NFs (its own SMF, PCF). At the hard end, a slice runs on physically separate infrastructure for a regulator or a critical-service tenant. The further right you go, the stronger the guarantee and the higher the cost — and note that the AMF and the network-wide NFs (NSSF, NRF) stay shared regardless; isolation lives mostly in the RAN scheduler and the SMF/UPF tier.

Finally, why is slicing an SA-only capability? Because everything above — the S-NSSAI in NAS signalling, NSSF-based selection, slice-aware NRF discovery, per-slice SMF/UPF — lives in the 5G Core's service-based machinery. NSA Option 3x runs on the EPC, which has none of it; so the migration to Standalone is, among other things, the migration that unlocks slicing.

4.1 · The stack as a pipeline

The protocol stack is best understood as a pipeline where each layer adds exactly one capability and hands the result down. On transmit you read it top to bottom; on receive the same layers undo their work bottom to top. The user plane runs SDAP → PDCP → RLC → MAC → PHY; the control plane runs RRC → PDCP → RLC → MAC → PHY (RRC sits where SDAP would, since control signalling has no QoS flows to map). And spanning the side of the whole stack is RRC, which carries no user data itself but configures every layer beneath it — what bearers exist, which ciphering algorithm, how big the RLC window, how the scheduler treats each logical channel.

4.2 · SDAP — the QoS bridge

⚙ TS 37.324

SDAP is new in NR and exists for one reason: to bridge the 5G core's fine-grained QoS-flow model (Chapter 3) onto the radio's bearer model. There is exactly one SDAP entity per PDU session, sitting at the very top of the user-plane stack. Its job is to take each downlink packet, recognise which QoS flow it belongs to, and place it on the right Data Radio Bearer — and, in the uplink, to mark each packet with its QFI so the gNodeB and core can keep the QoS treatment consistent. The mapping is N:1: many flows can share a DRB, but any one flow uses exactly one DRB at a time.

SDAP looks deceptively small — one octet of header, one job. But it is the precise seam where the core network's QoS world meets the radio's bearer world, and getting that seam right is what lets 5G honour a latency or reliability promise end to end. The rest of this section takes SDAP apart completely: the mapping hierarchy it lives in, its entity model, every function, the exact bit layout of its headers, its two PDU types, the downlink and uplink procedures, and the reflective-QoS machinery that makes it clever.

4.2.1 · Where SDAP sits — the three-stage QoS mapping

A user packet does not jump straight onto the air. It descends through three successive mappings, and SDAP owns the middle one. First, in the device's NAS layer (or, in the downlink, in the core), a packet is matched against packet filters and bound to a QoS flow, identified by its QFI — this is the finest granularity of QoS the core understands. Second, SDAP maps each QoS flow onto a Data Radio Bearer. Third, each DRB corresponds one-to-one to an RLC entity and a logical channel, which the MAC scheduler then multiplexes into transport blocks via Logical Channel Prioritisation (§4.5). Read top to bottom, the chain is packet → flow → DRB → logical channel → transport block, and SDAP is the flow→DRB hinge.

Two boundaries are worth fixing in memory. The flow→DRB mapping is N:1 and dynamic — several flows can share a DRB and a flow can be re-pointed to a different DRB on the fly. The DRB→logical-channel mapping is 1:1 and static for the life of the bearer. So all the QoS flexibility on the radio side is concentrated in SDAP; everything below it is fixed plumbing.

4.2.2 · The entity model — one SDAP per PDU session

SDAP's structure follows the PDU session. When the device establishes a PDU session (§3.3), exactly one SDAP entity is created for it, and that entity owns all of the session's QoS flows and all of the DRBs those flows are mapped to. A device with three PDU sessions therefore has three independent SDAP entities, each with its own configuration and its own default DRB. Within one SDAP entity, the same logic runs in two directions: a transmitting half for the uplink (add header, choose DRB) and a receiving half for the downlink (read header, perform reflective updates).

4.2.3 · The functions SDAP performs

TS 37.324 gives SDAP a short, sharp function list. There are only four, and every one is about the flow↔DRB relationship:

• Mapping QoS flows to DRBs — the core function, in both directions, using stored mapping rules.
• Marking QFI in both uplink and downlink packets (when the header is configured), so the receiver and the core can identify the flow.
• Reflective QoS-flow-to-DRB mapping for the uplink — updating the UL mapping from observed downlink packets (the RDI mechanism).
• Reflective QoS at the NAS level — flagging packets (the RQI mechanism) so the UE's NAS can derive the uplink QoS rule (the packet-filter→QFI association) without explicit signalling.

Notice what SDAP does not do. It performs no ciphering, no integrity protection, no segmentation, no reordering, no retransmission. Those belong to PDCP and below. SDAP is purely a classifier and a marker — which is exactly why it can be so thin.

4.2.4 · The SDAP header, bit by bit

The header is a single octet, and whether it is present is configured per DRB and per direction by RRC (sdap-HeaderUL, sdap-HeaderDL). The downlink and uplink formats differ because they carry different control bits.

• Downlink Data PDU. Bit 8 = RDI (Reflective DRB-mapping Indication), bit 7 = RQI (Reflective QoS Indication), bits 6–1 = QFI. There is no D/C bit downlink — a downlink SDAP PDU is always data.
• Uplink Data PDU. Bit 8 = D/C set to 1 (this is a Data PDU), bit 7 = R (reserved), bits 6–1 = QFI. The UE marks its own uplink packets with the flow's QFI so the gNodeB and UPF preserve the QoS class.
• Uplink Control PDU (end-marker). Bit 8 = D/C set to 0 (Control), bit 7 = R, bits 6–1 = the QFI being remapped. It has no data payload — the header is the whole PDU.

Because the QFI is six bits, valid values run 0–63. The header, when present, is prepended to the SDAP SDU (the IP packet) to form the SDAP Data PDU, which is then handed to PDCP as a PDCP SDU. Critically, PDCP ciphers and integrity-protects the SDAP header along with the data — SDAP performs no security of its own, so its QFI marking is protected by the layer below it.

4.2.5 · Two PDU types — data and the end-marker

SDAP defines just two kinds of PDU. The Data PDU carries a user packet, optionally prefixed by the header above. The Control PDU has exactly one use: it is the end-marker, sent in the uplink when a QoS flow's mapping moves from one DRB to another. When the UE re-points a flow (because it learned a new mapping reflectively, or RRC reconfigured it), the last packets of that flow may still be in flight on the old DRB while new packets start on the new DRB. The end-marker — a headers-only control PDU carrying the flow's QFI — is sent on the old DRB to tell the gNodeB "this flow has finished here." This lets the receiver release resources and avoid mis-ordering packets that have hopped bearers. The end-marker exists precisely because the flow→DRB mapping is allowed to change at runtime.

4.2.6 · Downlink operation, step by step

A downlink SDAP PDU arrives from PDCP. If the DRB is configured with a DL header, SDAP reads the octet and acts on it in order:

1. Extract the QFI, RDI and RQI bits.
2. If RDI = 1, update the stored uplink QoS-flow-to-DRB mapping for this QFI so that future uplink packets of this flow use the DRB this packet arrived on (AS-level reflective mapping — §4.2.8).
3. If RQI = 1, notify the upper layer (NAS) so it can derive or update the uplink QoS rule — the packet-filter→QFI association (NAS-level reflective QoS — §4.2.8).
4. Strip the header and deliver the SDAP SDU (the IP packet) up to the application.

If the DRB has no DL header configured, SDAP simply delivers the SDU — there is no QFI to read, and reflective QoS is therefore not available on that DRB.

4.2.7 · Uplink operation and the default DRB

In the uplink the device starts from a packet that NAS has already bound to a QoS flow (it knows the QFI). SDAP must choose a DRB for it:

1. Look up the flow's stored QoS-flow-to-DRB mapping rule. This rule may have been configured explicitly by RRC, or learned reflectively from a downlink RDI.
2. If a rule exists, use that DRB. If no rule exists, map the flow to the default DRB — the per-session fallback that guarantees every flow has somewhere to go.
3. If the DRB chosen differs from the one this flow used previously, send an end-marker control PDU on the old DRB (§4.2.5).
4. If the new DRB has an UL header configured, prepend the header (D/C = 1, QFI) to mark the packet; otherwise submit the raw SDU.
5. Submit the resulting SDAP Data PDU to the DRB's PDCP entity.

4.2.8 · Reflective QoS — RDI versus RQI

Reflective QoS is SDAP's cleverest trick, and the single most-confused part of the layer. The idea is to avoid signalling uplink QoS configuration explicitly: instead, the network marks downlink packets, and the device mirrors that treatment in its uplink. But there are two different reflective mechanisms operating at two different layers, and they are easy to conflate.

Bit	Layer	What the UE mirrors
RDI	Access Stratum (SDAP)	The QoS-flow → DRB mapping. "Send uplink packets of this QFI on the DRB I just sent you a downlink packet on."
RQI	Non-Access Stratum (NAS)	The packet-filter → QoS-flow rule. "Derive an uplink QoS rule so packets like this get this QFI."

So a single downlink packet can carry both: RQI teaches the UE's NAS which flow a kind of packet belongs to, and RDI teaches the UE's SDAP which DRB that flow should ride. Together they let the network stand up a fully-specified uplink QoS treatment for a brand-new application flow without sending a single explicit reconfiguration — invaluable for dynamic, bursty, app-driven traffic where pre-provisioning every rule would be hopeless.

4.2.9 · Configuration — the SDAP-Config IE

RRC configures SDAP through the SDAP-Config information element, carried inside the DRB configuration in an RRCReconfiguration. Its fields define exactly the behaviour described above:

SDAP-Config field	Meaning
pdu-Session	The PDU session this SDAP entity / DRB belongs to
sdap-HeaderDL	present / absent — is the downlink SDAP header used on this DRB?
sdap-HeaderUL	present / absent — is the uplink SDAP header used on this DRB?
defaultDRB	true if this is the session's default DRB (at most one)
mappedQoS-FlowsToAdd	List of QFIs whose UL mapping rule points to this DRB
mappedQoS-FlowsToRelease	List of QFIs whose mapping to this DRB is removed

A subtlety the fields expose: header presence is set per direction. It is entirely legal — and common — to run a DRB with the UL header present (so the UE marks QFI for the gNodeB) but the DL header absent, or vice versa, depending on whether reflective QoS is wanted in that direction. And because defaultDRB is a single boolean across the session's DRBs, the network must ensure exactly one carries it.

4.2.10 · A worked example, end to end

Tie it together with a concrete sequence. A device has a PDU session with a default DRB (DRB 1) and a second DRB (DRB 2) configured for a GBR video flow.

1. A new video-call flow starts. The core marks its downlink packets with QFI 7, RQI = 1 (teach NAS the rule) and RDI = 1 (map this flow to DRB 2), sending them down DRB 2.
2. The UE's SDAP reads the header: RQI makes NAS derive the uplink QoS rule for "video-call packets → QFI 7"; RDI makes SDAP store "QFI 7 → DRB 2" for the uplink.
3. The application's uplink video packets are now classified by NAS as QFI 7. SDAP looks up its rule, finds DRB 2, and — because this flow previously had no DRB (or used the default) — sends an end-marker on the old DRB, then starts sending the flow on DRB 2 with an UL header (D/C = 1, QFI = 7).
4. The gNodeB, seeing the QFI marking, applies the GBR scheduling treatment; the UPF, reading the same QFI, enforces the flow's policy toward the data network.
5. A background upload, never explicitly configured, simply rides the default DRB 1 — no rule, no marking needed beyond the default.

That single sequence exercises every SDAP function: mapping, marking, both reflective mechanisms, the default DRB and the end-marker. It is, in miniature, the whole layer.

4.3 · PDCP — security and ordering

⚙ TS 38.323⚙ TS 33.501 (security)

PDCP serves both planes — signalling radio bearers and data radio bearers — and it is where the radio's security lives. On transmit it runs a fixed three-stage chain: optional ROHC header compression (DRBs only — for an IP/UDP/RTP voice packet, ROHC can shrink ~40–60 bytes of header to a handful), then integrity protection (which appends a 32-bit MAC-I), then ciphering. The receiver reverses it: decipher, verify the MAC-I (recomputing an XMAC-I and comparing — a mismatch means tampering and the PDU is discarded), then decompress, then reorder.

Every cipher and integrity operation is keyed by a 32-bit counter, COUNT = HFN ‖ PDCP SN — the PDCP sequence number (12 or 18 bits) in the low part, an internally-maintained Hyper Frame Number in the high part. The iron rule is that COUNT must never repeat for a given key and bearer: the cipher generates a keystream from (key, COUNT, bearer, direction), and reusing a COUNT reuses the keystream, which is catastrophic — XOR two messages enciphered with the same keystream and the keystream cancels. This is also why every handover triggers a key refresh.

The key hierarchy

The keys that feed PDCP are the leaves of a tree rooted in the subscriber's permanent secret. Authentication (§3.3) derives an anchor; from it the network derives, level by level, the NAS keys (in the AMF) and the access-stratum key K_gNB (handed to the gNodeB), and from K_gNB the four radio keys: RRC ciphering, RRC integrity, UP ciphering and UP integrity. Algorithms come in families: NEA0–NEA3 for ciphering and NIA0–NIA3 for integrity (the suffix selects null, SNOW 3G, AES or ZUC).

That intro is the skyline. The rest of this section walks every floor of PDCP: where the entity lives, the exact PDU format, how the sequence number and COUNT really work, header compression, the full security architecture (keys, ciphering inputs, integrity), the ordering machinery and its state variables, duplicate detection and discard, duplication and split bearers, and what happens to all of it at a handover.

4.3.1 · One PDCP entity per radio bearer

Where SDAP has one entity per PDU session, PDCP has one entity per radio bearer — one per SRB, one per DRB. That granularity matters because security and ordering are per-bearer concepts: each bearer has its own keys context, its own sequence-number space, its own reordering window. PDCP serves both planes: on a Signalling Radio Bearer (SRB) it protects RRC and NAS messages; on a Data Radio Bearer (DRB) it protects user traffic handed down by SDAP. The two planes share the same machinery but differ in defaults — most importantly, integrity protection is mandatory on SRBs and optional on DRBs (§4.3.7).

Aspect	SRB (control)	DRB (user)
Carries	RRC / NAS signalling	SDAP SDUs (user IP)
Ciphering	Yes	Yes
Integrity	Mandatory	Optional (per DRB, new in 5G)
Header compression	No	ROHC (optional)
SN length	12 bits	12 or 18 bits

4.3.2 · The PDCP Data PDU format

A PDCP Data PDU is a header (the sequence number, plus a D/C bit on DRBs), the payload, and — when integrity is on — a trailing 32-bit MAC-I. The SN length is RRC-configured as 12 or 18 bits: 12 keeps the header tiny for low-rate bearers, while 18 gives a far larger sequence space (and hence a larger reordering window) needed by high-throughput bearers where many PDUs can be in flight at once. Get the window too small for the data rate and the SN can wrap before old PDUs clear — the classic cause of stalls.

PDCP also defines Control PDUs, distinguished by the D/C bit = 0 on DRBs. There are two: the PDCP Status Report (used after re-establishment/data-recovery to tell the peer exactly which PDUs were received, so only the genuinely missing ones are retransmitted) and ROHC feedback (carrying header-compression feedback between the compressor and decompressor). Control PDUs are never ciphered or integrity-protected.

4.3.3 · Sequence number, HFN and COUNT

The visible PDCP SN in the header is only the bottom of a larger counter. PDCP internally maintains a Hyper Frame Number (HFN) that increments each time the SN wraps, and the security algorithms actually run on the full 32-bit COUNT = HFN ‖ SN (shown in the COUNT diagram above). The SN is sent on the air to keep the header small; the HFN is inferred identically at both ends. The danger is HFN desynchronisation: if the transmitter and receiver ever disagree on how many times the SN has wrapped, their COUNTs diverge, the keystreams diverge, and every subsequent PDU deciphers to garbage. The reordering window and the discard timer are sized precisely to keep both ends' view of COUNT locked together.

4.3.4 · Header compression (ROHC)

For user-plane DRBs only, PDCP can run ROHC (Robust Header Compression, RFC 5795). The motivation is stark: a VoIP packet carries ~40 bytes of IPv6/UDP/RTP header in front of perhaps 32 bytes of voice — more than half the air payload is header that barely changes packet to packet. ROHC exploits that redundancy: the compressor and decompressor build a shared context of the static and slowly-changing fields, after which only a tiny compressed header (sometimes a single byte) need be sent. It is configured per DRB by RRC (which profiles — RTP/UDP/IP, UDP/IP, IP, TCP/IP — are enabled), and it is "robust" because it tolerates packet loss without breaking the context, recovering via periodic refreshes and the ROHC feedback channel. SRBs are not compressed (signalling is not a steady IP header stream), which is why ROHC is a DRB-only function.

4.3.5 · The security architecture — keys

PDCP is where the radio's confidentiality and integrity live, and its keys are the leaves of the tree in the key-hierarchy diagram above (TS 33.501). After authentication, the network derives an anchor key, from which it derives the NAS keys (held in the AMF) and the access-stratum key K_gNB (handed to the serving gNodeB). From K_gNB, the gNodeB derives the four keys PDCP uses: K_RRCenc and K_RRCint for SRB ciphering and integrity, and K_UPenc and K_UPint for DRB ciphering and integrity. At every handover K_gNB is refreshed (horizontally or vertically, via the NCC/NH chain), which is what guarantees the COUNT-reuse rule is never violated across cells.

4.3.6 · Ciphering — how the keystream is built

Ciphering is a stream cipher: the algorithm generates a keystream block and XORs it with the data, and the receiver regenerates the identical keystream to XOR it back. What makes each keystream unique is its five inputs: the key, the COUNT, the bearer identity, the direction (uplink/downlink) and the length. Because COUNT, BEARER and DIRECTION are all in the mix, the same plaintext on two bearers, or in two directions, or in two different PDUs, produces completely different ciphertext — which is exactly the property the cardinal rule protects.

The algorithm family is named NEA0–NEA3: NEA0 is null (no ciphering, for emergency/test), NEA1 is SNOW 3G, NEA2 is AES (in CTR mode), NEA3 is ZUC. An operator typically enables AES (NEA2) as the workhorse, with the others for interoperability or regulatory reasons.

4.3.7 · Integrity — proving the message was not altered

Integrity protection answers a different question from ciphering: not "can an eavesdropper read this?" but "did anyone tamper with this in flight?" The transmitter computes a 32-bit MAC-I (Message Authentication Code for Integrity) over the PDU using the integrity key and the same COUNT/bearer/direction inputs, and appends it. The receiver independently recomputes an XMAC-I and compares: if they differ, the PDU was altered (or replayed with a stale COUNT) and is discarded. The algorithm family is NIA0–NIA3 (null, SNOW 3G, AES-CMAC, ZUC). A genuine 5G addition over LTE is optional user-plane integrity: in LTE only signalling was integrity-protected, but NR can integrity-protect DRBs too (configured per DRB) — important for IoT and control traffic where a forged user packet could be as damaging as a forged signalling message. On SRBs integrity is always on, never optional.

4.3.8 · The processing order — and why it is fixed

The order of operations is not arbitrary; it is what makes the receiver able to undo them. On transmit: assign the SN, ROHC-compress (DRB), integrity-protect to produce the MAC-I, then cipher (the data and, on DRBs, the MAC-I), then prepend the header. On receive the reverse: read the SN, decipher, verify the MAC-I, ROHC-decompress, then hand to reordering. The chain is shown in the transmit-chain diagram above. The reason integrity comes before ciphering on transmit is so the MAC-I covers the compressed-but-unciphered payload and is then itself enciphered — the receiver must decipher before it can check integrity, and that ordering also means a tampered ciphertext is caught at the integrity step rather than silently decompressing into nonsense.

4.3.9 · In-order delivery and reordering

Here is the headline NR change: reordering moved from RLC (LTE) up to PDCP (NR). Lower layers — especially with HARQ retransmissions, multiple carriers, or dual connectivity — can deliver PDUs out of order. PDCP restores order using the SN and a reordering window, governed by three state variables and one timer:

• RX_DELIV — the SN of the oldest PDU not yet delivered to upper layers (the lower edge of the window).
• RX_NEXT — the SN of the next PDU expected to arrive (the upper edge).
• RX_REORD — the SN that, once reached, will stop the reordering timer.
• t-Reordering — the timer that bounds how long PDCP waits for a missing PDU before delivering what it has and moving on.

This is the mechanism behind the interview answer "PDCP reorders in NR." It is also why in-order delivery is now bearer-wide and survives RLC reordering being removed.

4.3.10 · Duplicate detection and SDU discard

Two housekeeping functions keep the buffer honest. Duplicate detection uses the COUNT to drop any PDU already received — essential because retransmissions (HARQ, RLC ARQ, or PDCP duplication) can deliver the same PDU twice. SDU discard uses the discardTimer: every SDU is stamped on arrival, and if it has not been successfully transmitted by the time the timer expires, it is dropped. This stops stale data — a video frame that is now too old to be useful — from clogging the transmit buffer and wasting air resources on data nobody wants any more.

4.3.11 · PDCP duplication for ultra-reliability

For URLLC, one transmission path may not be reliable enough. PDCP duplication sends identical copies of a PDCP PDU down two, three or four parallel RLC legs at once; the receiving PDCP keeps the first copy to arrive and discards the rest via duplicate detection. The legs can be different carriers in Carrier Aggregation (frequency diversity within one node) or different nodes in Dual Connectivity (path and site diversity). Because duplication burns scarce air resources — you are deliberately sending the same data multiple times — it is activated and deactivated dynamically by a MAC control element, not by slow RRC reconfiguration, so the network can switch it on only for the moments reliability demands it.

4.3.12 · Split bearers and PDU routing

In Dual Connectivity a single DRB can be a split bearer: its one PDCP entity sits at the master (or secondary) node but can route PDUs down either the MCG RLC leg or the SCG RLC leg. PDCP performs the routing — in the uplink, it sends on the primary path until the buffered data exceeds ul-DataSplitThreshold, then spreads across both legs to use the aggregate capacity. This is how DC delivers throughput aggregation (as opposed to duplication, which spends the same legs on reliability). Routing and duplication are the two things PDCP does because it is the single anchor point above multiple RLC legs.

4.3.13 · Re-establishment and data recovery at handover

At a handover the radio below PDCP is torn down and rebuilt, but the user's data must survive the seam. PDCP re-establishment handles this. For AM (reliable) bearers, PDCP re-establishes with data recovery: it keeps its SDUs, applies the new security keys (a fresh K_gNB means new K_UPenc/K_UPint), resets ROHC, and retransmits — guided by a PDCP Status Report from the peer — exactly the PDUs the target has not yet received, in order, without duplication. This is the machinery that makes a hard handover (§1.3) feel seamless to the application: the cell-level break-before-make is invisible because PDCP carries the data across it. For UM/non-recoverable bearers, some loss is accepted in exchange for not stalling.

4.3.14 · Configuration — the PDCP-Config IE

RRC drives all of the above through the PDCP-Config IE inside the radio-bearer configuration:

PDCP-Config field	Controls
pdcp-SN-SizeUL / -DL	12 or 18-bit sequence number, per direction
headerCompression	ROHC on/off and which profiles
integrityProtection	Enable UP integrity on this DRB (SRBs always on)
discardTimer	How long an SDU may wait before being dropped
t-Reordering	The reordering wait bound (§4.3.9)
pdcp-Duplication	Configure (and seed activation of) PDU duplication
moreThanOneRLC / ul-DataSplitThreshold	Split-bearer routing parameters (§4.3.12)

4.4 · RLC — modes and ARQ

⚙ TS 38.322

RLC turns the PDCP stream into something the MAC can carry over a fluctuating channel, in one of three modes chosen per bearer by RRC. Transparent Mode (TM) adds nothing — no header, no segmentation, no retransmission — and is used only for fixed-format broadcast traffic (paging, BCCH). Unacknowledged Mode (UM) adds a sequence number and segmentation but never retransmits, suiting delay-sensitive, loss-tolerant flows like voice and video. Acknowledged Mode (AM) adds the full reliability machinery — ARQ — and is mandatory for signalling radio bearers and used for any bearer that must be reliable.

RLC is the quiet middle layer, but it carries the burden of turning PDCP's clean numbered stream into something that survives a fluctuating, lossy channel — and doing so in three flavours of effort. The rest of this section takes RLC apart: its entity model, the PDU formats of each mode, how segmentation and reassembly actually work, the complete AM ARQ loop (polling, status, partial NACK, the retransmission counter), the STATUS PDU on the wire, the two-tier relationship with HARQ, and the configuration that ties it together.

4.4.1 · The entity model — and what RLC no longer does

RLC sits below PDCP and above MAC, and there is one RLC entity per logical channel — which, since DRB↔logical-channel is 1:1, means effectively one RLC entity per bearer leg. TM and UM entities are unidirectional (a transmitting entity and, separately, a receiving one), while an AM entity is a single bidirectional object containing both a transmitting and a receiving side that cooperate to run ARQ. A defining NR change frames everything below: concatenation left RLC for MAC. In LTE, RLC concatenated several SDUs into one PDU sized to the grant — which forced RLC to wait for MAC to announce the size, a serial dependency that hurt latency. NR breaks it: RLC pre-builds its PDUs independently and MAC assembles the transport block, so RLC processing can be pipelined ahead of the grant. RLC therefore now does only three things — transfer, segmentation (when an SDU is too big for one opportunity), and (in AM) ARQ — and notably no reordering, which moved up to PDCP (§4.3.9).

4.4.2 · The three modes, and where each is used

RRC picks a mode per bearer based on what that traffic needs. TM adds literally nothing — no header, no SN, no segmentation, no ARQ — and exists only for fixed-format messages that ride dedicated channels: broadcast (BCCH), paging (PCCH), and the initial common control channel (CCCH). UM adds sequence numbering and segmentation but never retransmits, which suits delay-sensitive, loss-tolerant traffic — voice, real-time video, where a late packet is worse than a lost one. AM adds the full ARQ machinery for anything that must arrive intact: all signalling radio bearers, and any DRB carrying TCP or file-like traffic.

Mode	SN size	Segments?	ARQ?	Typical channels / use
TM	none	no	no	BCCH, PCCH, CCCH (broadcast/paging)
UM	6 or 12 bits	yes	no	DTCH — voice, streaming video
AM	12 or 18 bits	yes	yes	all SRBs; reliable DTCH (TCP, files)

4.4.3 · PDU formats

The header a PDU carries is exactly as heavy as its mode demands. A TMD PDU is the SDU verbatim — zero header. A UMD PDU carries an SI (Segmentation Info) field and, only when segmented, an SN and a segment offset — so an unsegmented UM packet pays almost no header tax. An AMD PDU is the richest: a D/C bit (data vs control), a P (poll) bit, the 2-bit SI, the SN, and a 16-bit SO for non-first segments.

4.4.4 · Segmentation and the SI field

When an RLC SDU is larger than the transmission opportunity MAC offers, RLC segments it: the SDU is cut into pieces, each sent in its own PDU, and each piece's header says where it fits. Two fields do the bookkeeping. The 2-bit SI marks the piece's role — 00 a complete (unsegmented) SDU, 01 the first segment, 11 a middle segment, 10 the last segment. The 16-bit SO (Segment Offset) gives the byte position of this piece within the original SDU, present for every piece except the first (whose offset is zero). All segments of one SDU share the same SN; the SI+SO pair tells the receiver how to stitch them back together.

4.4.5 · Reassembly and t-Reassembly

The receiver collects segments by SN and SO and rebuilds each SDU. Because a segment can be lost, it cannot wait forever — the t-Reassembly timer bounds the wait. When a gap is detected, the timer starts; if the missing segment arrives before it expires, the SDU completes and is delivered up to PDCP; if the timer expires first, the receiver declares the SDU lost. In UM that loss is simply accepted (no retransmission); in AM the same gap detection feeds the ARQ machinery, which will ask for the missing bytes. The receiver tracks its progress with state variables — for AM, RX_Next (lowest SN awaiting completion), RX_Highest_Status and RX_Next_Highest — that define the receive window and what the next STATUS report will say.

4.4.6 · The AM ARQ loop in full

AM reliability is a conversation between the transmitter's TX side and the receiver's RX side, and it has three moving parts: polling, status reporting, and retransmission.

Polling. The transmitter does not want a status report after every PDU (wasteful) nor too rarely (slow recovery). So it polls by setting the P bit when a trigger fires: after pollPDU PDUs, after pollByte bytes, when the buffer empties, or on a retransmission. Having polled, it starts t-PollRetransmit; if no status comes back before it expires, the transmitter re-polls (retransmitting the last PDU with the poll bit) so a lost poll cannot deadlock the loop.

Status reporting. On receiving a poll (or detecting a gap), the RX side builds a STATUS PDU. To avoid flooding the uplink with reports, t-StatusProhibit enforces a minimum gap between consecutive STATUS PDUs. The report names an ACK_SN — everything below it is received except the SNs explicitly listed — plus NACK_SN entries for the gaps, each optionally carrying an SO range (a partial NACK) so only the missing bytes of a half-received SDU are requested, or a NACK range to compactly report a run of consecutive missing SDUs.

Retransmission. The transmitter resends exactly what was NACKed — whole SDUs or just the SO-bounded byte ranges — and crucially it may re-segment on retransmission if the new grant is smaller than the original. Each retransmitted RLC SDU carries a RETX_COUNT; when it reaches maxRetxThreshold, RLC gives up and indicates the failure to RRC, which declares a Radio Link Failure. ARQ is reliable, but deliberately not infinite — a permanently bad link must be detected, not retried forever.

4.4.7 · The STATUS PDU on the wire

The STATUS PDU is an AM control PDU (D/C = 0). It opens with a control-PDU-type field, then the ACK_SN, then a chain of NACK entries each flagged by extension bits: E1 says "another NACK_SN follows," E2 says "an SO start/end pair follows" (this NACK is partial — only those bytes), and E3 says "a NACK range follows" (this NACK covers a run of consecutive SNs). This compact encoding lets one STATUS PDU acknowledge everything up to ACK_SN and precisely describe every hole below it — whole SDUs, byte ranges, or runs — in as few bits as possible.

4.4.8 · Two tiers — RLC ARQ over HARQ

RLC ARQ does not work alone; it sits on top of MAC's HARQ (§4.5) as the second tier of a two-tier error-recovery scheme. HARQ is the fast inner loop — sub-millisecond, soft-combining, handling the common case of a marginal decode. But HARQ has a small residual error rate (a NACK can be misread as an ACK, roughly 1-in-1000), and over millions of blocks that leaves occasional gaps. RLC ARQ is the slower outer loop that mops those up: its status-report timescale is milliseconds, not microseconds, but it is reliable. The division of labour is deliberate — let HARQ catch ~99.9% cheaply and quickly, and let ARQ guarantee the last fraction without burdening every transmission.

4.4.9 · Configuration — RLC-Config

RRC configures the mode and all the AM timers/counters through RLC-Config (inside the RLC-BearerConfig):

Field	Controls
mode (am / um / tm)	Which RLC mode this bearer uses
sn-FieldLength	SN size (UM 6/12, AM 12/18 bits)
t-Reassembly	Wait bound for missing segments before declaring loss
t-PollRetransmit	Re-poll if no STATUS arrives (AM)
pollPDU / pollByte	Poll triggers by PDU count / byte count (AM)
t-StatusProhibit	Minimum gap between STATUS PDUs (AM RX)
maxRetxThreshold	Retransmissions before declaring failure → RLF (AM)

4.5 · MAC — the heartbeat of the RAN

⚙ TS 38.321

4.5.1 · The scheduler's job

If one layer is the heart of the radio, it is MAC, because MAC contains the scheduler. Every slot, the scheduler answers the hardest question in the system: of all the devices wanting to transmit or receive, who gets served, on which resource blocks, with what modulation and coding, at what power? It balances throughput, fairness and latency against the live channel conditions reported by each device. The scheduler is not standardised — it is where vendors differentiate — but the machinery it drives is, and the rest of this section is that machinery: the channels MAC bridges, the transport block and HARQ, random access, the buffer/power reporting that feeds the scheduler, logical-channel prioritisation, and DRX.

4.5.2 · What MAC bridges — logical, transport, physical channels

MAC sits between two different worlds and translates between them. Above it, RLC speaks in logical channels, defined by what the data is — control vs traffic, dedicated vs common. Below it, PHY speaks in transport channels, defined by how data is carried over the air. MAC's mapping job is to multiplex logical channels onto transport channels, which the PHY then carries on physical channels. Knowing this three-tier mapping is what lets you read any NR call flow.

4.5.3 · The transport block, HARQ and multiplexing

MAC's output is the transport block — one per UE per slot per carrier — and the scheduler signals each grant or assignment to the device using DCI (Downlink Control Information) carried on the PDCCH. The DCI names the resource blocks, the MCS, and the HARQ parameters. Inside the transport block, MAC multiplexes: it interleaves SDUs from different logical channels (each tagged by its LCID in a subheader) together with MAC control elements (also LCID-coded) such as BSR or DRX commands.

4.5.4 · HARQ — the fast retransmission loop

HARQ (Hybrid ARQ) is MAC's error-recovery, and it is fast where RLC ARQ is reliable. After a transport block, the receiver attempts to decode and signals ACK or NACK within about a slot. On NACK, the transmitter resends — but crucially the receiver keeps the failed copy and soft-combines it with the retransmission, so each attempt adds energy and (with incremental redundancy) new parity. NR runs up to 16 stop-and-wait HARQ processes in parallel per direction, so while one process awaits feedback the others keep the pipe full. NR HARQ is asynchronous in both directions — there is no fixed timing, so the DCI explicitly carries the HARQ process ID and a New Data Indicator (NDI) that distinguishes a fresh block from a retransmission. HARQ is the first line of defence (sub-millisecond); RLC ARQ is the slower backstop for the residual errors HARQ misses.

4.5.5 · Random access — getting the first foothold

A device with nothing scheduled cannot simply transmit; the uplink is a managed resource. It bootstraps with random access, the one grant-free transmission allowed. In 4-step contention-based RACH the device picks a preamble and sends it (Msg1) on PRACH; the gNodeB replies with a Random Access Response (Msg2) carrying a timing advance, an uplink grant and a temporary identity (TC-RNTI); the device sends its real request on that grant (Msg3); and the gNodeB resolves contention (Msg4). Rel-16 added a 2-step variant (MsgA/MsgB) that collapses the round-trips for lower latency.

The 4-step procedure above is for contention-based access from idle. NR also defines contention-free RACH (the network pre-assigns a dedicated preamble, e.g. for handover, so there is no contention to resolve) and the Rel-16 2-step procedure, where MsgA bundles the preamble and a small payload together and MsgB returns both the response and the contention resolution — halving the round-trips, which matters for latency-critical access and for the long propagation delays of non-terrestrial networks.

4.5.6 · Feeding the scheduler — SR, BSR, PHR and MAC CEs

The scheduler can only allocate well if it knows what each device needs, so MAC carries a stream of reports up to it. The uplink ask is a three-step escalation: a Scheduling Request (SR) is a single bit on a dedicated PUCCH resource — "I have data, give me a grant"; given a small grant the device sends a Buffer Status Report (BSR), a MAC control element reporting how much data is buffered per Logical Channel Group (up to 8 groups) so the next grant is sized correctly; and a Power Headroom Report (PHR) tells the scheduler how much transmit power the device has left, bounding how aggressive an uplink MCS it can assign. These are all MAC control elements — fixed-format MAC-layer messages, identified by reserved LCID values, that ride inside the MAC PDU alongside data:

MAC CE	Direction	Purpose
BSR	UL	Buffered data per logical channel group → grant sizing
PHR	UL	Remaining transmit power headroom → MCS bound
Timing Advance Command	DL	Adjust UL transmit timing as the UE moves
DRX Command	DL	Force the UE into sleep immediately
SCell Activation/Deactivation	DL	Turn aggregated carriers on/off (CA)
Duplication Activation	DL	Toggle PDCP duplication (§4.3.11)
C-RNTI	UL	Identify the UE during contention resolution

4.5.7 · Logical Channel Prioritisation — filling the grant fairly

A grant is a fixed number of bytes, and the device usually has several logical channels with data waiting. LCP decides how to share the grant. Each logical channel has a priority, a Prioritised Bit Rate (PBR) and a bucket-size duration. LCP runs in two rounds: first it serves channels in strict priority order but only up to each one's PBR — a token bucket that guarantees every channel a minimum rate, so a greedy high-priority channel cannot starve the others; then, if grant remains, it distributes the leftover in priority order until the grant or the data is exhausted. The result is "priority, but with a fairness floor."

4.5.8 · DRX — letting a connected device sleep

A device that monitored the PDCCH every slot would never sleep and its battery would drain in hours. C-DRX (Connected-mode Discontinuous Reception) fixes this by giving the device a rhythm of wake and sleep while staying in RRC_CONNECTED. Each DRX cycle opens with an onDuration during which the device monitors PDCCH. If it is scheduled, the drx-InactivityTimer starts and keeps it awake while traffic flows; when that timer expires with no new activity, the device sleeps until the next cycle. Two cycle lengths can be configured — a short cycle for responsiveness right after activity, and a long cycle for deep sleep when idle — and a separate drx-RetransmissionTimer wakes the device precisely when a HARQ retransmission is expected, so sleeping never costs a retransmission. DRX is the single biggest lever on device battery life, and tuning it is a direct trade of power against latency.

4.5.9 · Scheduling strategies and link adaptation

The scheduler's policy is a vendor secret, but its inputs and dials are standard. It chooses per slot using each device's reported CQI (downlink channel quality) and SRS (uplink sounding), and it embodies a fairness policy somewhere on a spectrum from max-throughput (always feed the best channel — highest cell capacity, but edge users starve) through proportional-fair (weight each user's instantaneous rate by their recent average — the practical default) to round-robin (equal turns regardless of channel — fair but inefficient). On top of the who-and-where, link adaptation picks the how: it maps the reported CQI to an MCS (modulation order QPSK→16/64/256-QAM plus a code rate), choosing the highest the channel will currently bear, and adjusts continuously as the channel fades. The scheduler can also use semi-persistent scheduling (DL) and configured grants (UL) to pre-allocate periodic resources for predictable traffic like voice — avoiding a fresh DCI every slot — and can issue dynamic grants for everything else.

4.5.10 · Bandwidth parts and key timers

Finally, MAC operates within a Bandwidth Part (BWP) — a contiguous block of the carrier with its own numerology (§4.6). A UE can be configured with up to four BWPs per direction but has only one active at a time, letting the network shrink a device to a narrow BWP to save power and widen it on demand. Two further MAC timers complete the picture: the Timing Advance Timer, which keeps the UE's uplink time-aligned (when it expires, the UE must redo RACH to re-align), and the BWP inactivity timer, which falls the UE back to a default BWP after a quiet spell.

4.6 · PHY — numerology, frames and channels

⚙ TS 38.211⚙ TS 38.212⚙ TS 38.214

4.6.1 · The OFDM waveform and numerology

The physical layer turns the transport block into a waveform on the antenna. Its biggest break from LTE is flexible numerology. Where LTE fixed the subcarrier spacing at 15 kHz, NR allows 15·2^μ kHz for μ = 0…4 — that is 15, 30, 60, 120 and 240 kHz. Wider spacing means a shorter symbol and a shorter slot, hence lower latency and better tolerance of phase noise and Doppler at high frequencies — which is why FR2 millimetre-wave uses 120 kHz while FR1 mid-band typically uses 30 kHz. The trade is a larger cyclic-prefix overhead and less delay-spread tolerance. One numerology can be chosen per Bandwidth Part, and a UE can be configured with up to four BWPs per direction (one active at a time), letting the network match the device's bandwidth and numerology to its current need and battery.

4.6.2 · The resource grid — RB, RE and bandwidth parts

In frequency, the basic block is the resource block — 12 contiguous subcarriers — and a carrier holds up to 275 of them; a single subcarrier in a single OFDM symbol is a resource element (RE), the atomic unit the scheduler ultimately fills. A slot's worth of one RB is a 12×14 grid of REs, and that grid is shared between control, data and reference signals.

A device does not necessarily use the whole carrier. It operates within a Bandwidth Part (BWP) — a contiguous sub-band with its own numerology — and can be configured with up to four per direction but only one active at a time, so a small IoT device can sit in a narrow BWP and a phone streaming video in a wide one, on the same carrier. The two frequency ranges set the scene: FR1 (sub-7.125 GHz) for coverage and capacity, and FR2 (24.25–52.6 GHz, extended toward 71 GHz in Rel-17) for bandwidth, where everything depends on sharp beams.

4.6.3 · Physical channels and reference signals

The PHY exposes a set of physical channels: downlink, the PBCH (carries the MIB for initial access), PDCCH (DCI/scheduling) and PDSCH (data); uplink, the PUCCH (control — SR, HARQ ACK/NACK, CSI), PUSCH (data) and PRACH (random-access preambles). Note there is no PHICH as in LTE — asynchronous HARQ made it unnecessary. Around the data sit reference signals: DM-RS for coherent demodulation, CSI-RS for channel measurement and beam management, SRS for uplink sounding, PT-RS for phase-noise tracking at mmWave.

Channel / signal	Dir	Carries
PBCH	DL	MIB — minimum info for initial access (inside the SSB)
PDCCH	DL	DCI — scheduling grants/assignments (in a CORESET)
PDSCH	DL	User data, SIBs, paging
PUCCH	UL	UCI — SR, HARQ ACK/NACK, CSI reports
PUSCH	UL	User data and larger UCI
PRACH	UL	Random-access preambles
DM-RS / CSI-RS / SRS / PT-RS	both	Demodulation / channel & beam measurement / UL sounding / phase tracking

There is no PHICH as in LTE — asynchronous HARQ made the dedicated ACK channel unnecessary (HARQ feedback rides PUCCH/PDCCH instead).

4.6.4 · Channel coding and link adaptation

Two more PHY essentials. Link adaptation: the device measures the downlink and reports a CQI; the scheduler maps it to a MCS (modulation QPSK→16/64/256-QAM plus a code rate), choosing the highest rate the channel will currently bear. Channel coding: NR uses LDPC codes for the data channels (PDSCH/PUSCH), efficient at high throughput, and Polar codes for control (PDCCH/PBCH and larger PUCCH payloads), strong at the short block lengths control needs.

4.6.5 · Initial access and the SSB

Before any of the above can happen, a device must find the cell — with no prior timing, no frequency lock, no knowledge the cell exists. The SSB (SS/PBCH Block) is what it searches for. An SSB is a compact 4-symbol × 240-subcarrier block carrying three things: the PSS (Primary Synchronization Signal) for coarse timing and symbol sync, the SSS (Secondary Synchronization Signal) which together with PSS gives the physical cell ID (one of 1008), and the PBCH carrying the MIB — the minimum information needed to go find SIB1. The acquisition order is fixed: detect PSS → detect SSS → decode PBCH/MIB → from MIB locate and decode SIB1 (on PDSCH) → now the device knows how to access the cell.

4.6.6 · From transport block to waveform — the transmit chain

The PHY's processing of a transport block is a fixed pipeline, and each stage has a purpose. A CRC is attached so the receiver can tell decode success from failure (this is what HARQ ACK/NACK reflects). The block is segmented into code blocks and LDPC-encoded, then rate-matched to fit the assigned REs (rate matching is also where HARQ incremental redundancy selects which coded bits to send on each retransmission). The bits are scrambled (with a UE-specific sequence, so neighbouring cells' transmissions look like noise to each other), modulated to QAM symbols, mapped to MIMO layers and precoded, mapped onto resource elements, and finally turned into the time-domain waveform by the iFFT with a cyclic prefix prepended.

4.6.7 · MIMO, layers and beamforming

NR's capacity comes from the spatial domain. Spatial multiplexing sends several independent data streams — layers — on the same time-frequency resource over a multi-antenna channel; a UE can receive up to 8 layers (single-user MIMO), and the cell can serve many UEs on the same resources via different beams (MU-MIMO). The mapping is codewords → layers → antenna ports → physical antennas, via the precoder. Beamforming is the other half: at FR2 especially, energy must be concentrated into narrow beams to overcome path loss. Implementations span analog beamforming (phase shifters, one beam at a time — cheap, used at mmWave), digital (per-element baseband control, many simultaneous beams — powerful, expensive) and hybrid (the practical FR2 compromise). The network tracks the right beam per UE through beam management — P1 establishes a coarse beam from the SSB sweep, P2 refines the gNB-side beam, P3 refines the UE-side beam — and signals the chosen beam through TCI states, recovering automatically on beam failure.

4.6.8 · CSI feedback — closing the loop

For the scheduler to adapt, it must know the channel, and the device tells it through CSI (Channel State Information) reports derived from measuring CSI-RS. A CSI report bundles three quantities: the CQI (how good the channel is → which MCS), the PMI (which precoder the gNB should use → how to beamform/combine), and the RI (rank indicator → how many layers the channel can support). Reports can be periodic (on PUCCH), semi-persistent, or aperiodic (triggered on PUSCH), letting the network trade feedback overhead against tracking speed. CSI on the downlink and SRS sounding on the uplink are the two feedback streams that keep link adaptation and MIMO matched to a channel that never stops changing.

4.7 · RRC — the controller and its states

⚙ TS 38.331

RRC is the control-plane brain of the access stratum. It carries no user data; it configures everything else — broadcasting system information, setting up and tearing down radio bearers, configuring measurements and triggering mobility, and activating security. Its life is organised around three states, and the third is a genuine 5G innovation.

RRC_IDLE is fully detached at the radio: the device holds no RAN context, camps on a cell, reads system information and listens for paging. RRC_CONNECTED is fully attached: a context exists, bearers are configured, data flows. The new middle state, RRC_INACTIVE, keeps the device's context alive in the RAN (anchored at the last serving gNodeB, the device holding an I-RNTI) while letting its radio sleep. The point is speed: a device with bursty traffic — a wearable, a sensor, a chat app — can flip from INACTIVE back to CONNECTED in milliseconds via RRC Resume, skipping the full setup and re-authentication that returning from IDLE would require. It is a small state with an outsized effect on latency and battery, and it is SA-only.

The procedures that move between states and configure the stack are the everyday vocabulary of the RAN engineer:

Procedure	Messages / trigger	Purpose
Connection setup	RRCSetupRequest → RRCSetup → RRCSetupComplete	IDLE → CONNECTED on SRBs
Reconfiguration	RRCReconfiguration (+ Complete)	Bearers, measConfig, handover sync — the workhorse
Security activation	SecurityModeCommand → Complete	Switch on AS ciphering + integrity (from K_gNB)
Resume	RRCResumeRequest (carries I-RNTI)	INACTIVE → CONNECTED in ms
Release	RRCRelease (± suspendConfig)	To IDLE, or to INACTIVE if suspended
System information	MIB (PBCH) + SIB1… (PDSCH)	Broadcast cell access & config

Mobility deserves a closing word, because it ties the whole stack together. RRC configures the device with a measurement configuration — which signals to measure (SSB, CSI-RS), which neighbours, and which reporting events. The event family is precise: A1/A2 compare the serving cell to a threshold, A3 compares a neighbour to the serving cell plus an offset (the classic intra-frequency handover trigger), A4/A5 handle threshold-based and dual-condition cases, and B1/B2 handle inter-RAT. When a configured event fires for longer than its time-to-trigger, the device reports, RRC decides, and a handover (§1.3) executes — measurement, decision and execution closing the loop that the radio problem opened in Chapter 1.