5G NR Numerology & Frame Structure

networks subcarrier spacing · slots · the 2⁻ᵘ ms clock Round 4 ✓ math ✓ visual ✓

5G's one big idea over LTE: make the air interface's time and frequency grid a tunable parameter. A single family of "numerologies" scaled by powers of two lets one standard serve a 1 ms IoT trickle and a sub-ms URLLC control loop on the same hardware — and it sets the fundamental clock every scheduler and ML control loop must respect.

What · How · Why

What it is

Numerology is the choice of subcarrier spacing (SCS) for 5G NR's OFDM waveform. Where LTE fixed SCS at 15 kHz, NR defines a scalable family: \(\Delta f = 2^\mu \times 15\) kHz for \(\mu = 0,1,2,3,4\). Because the time grid is tied to the frequency grid by OFDM, changing SCS also scales slot duration — so numerology jointly sets frequency resolution and the scheduling time step.

How it works

A 10 ms radio frame is split into 10 subframes of 1 ms. Each subframe holds \(2^\mu\) slots, and every slot carries 14 OFDM symbols. So slot length is \(2^{-\mu}\) ms: \(\mu{=}0\) → 1 ms slots, \(\mu{=}1\) → 0.5 ms, \(\mu{=}3\) → 0.125 ms. Higher SCS means shorter symbols, shorter slots, faster scheduling — at the cost of more overhead (cyclic prefix) and larger bandwidth per subcarrier.

Why it matters

One waveform family covers wildly different services: wide SCS + short slots for low-latency URLLC and mmWave (which needs wide spacing to fight phase noise), narrow SCS for coverage and mMTC. It is also the master clock of the RAN: the slot duration \(2^{-\mu}\) ms is the deadline every MAC scheduler — and any near-RT ML control loop — must hit. Miss the slot boundary and the decision is wasted.

Round 1 — Mental Model

Think of the air interface as sheet music. LTE printed everything in one fixed time signature — every note the same length. 5G NR keeps the same page but lets you pick the tempo from a menu of doublings: play at 1×, 2×, 4×, 8×, or 16× speed. Play slowly (narrow subcarriers, long slots) and each note is robust and reaches far — good for coverage and slow IoT sensors. Play fast (wide subcarriers, short slots) and you can react in a fraction of a millisecond — good for a factory robot's control loop or the twitchy mmWave band. The genius is it's one instrument: the same radio plays any tempo, and different users can even be on different tempos in different slices of the band.

The trade is fixed by physics. Wider subcarriers (faster tempo) resist Doppler and phase noise but need a proportionally larger guard interval (cyclic prefix) against echoes, so you "spend" more overhead. Narrow subcarriers are efficient and far-reaching but sluggish and fragile to frequency errors. Numerology is the knob that picks your point on that curve.

The one idea to hold: in OFDM, time and frequency resolution are inverses — symbol duration \(\approx 1/\Delta f\). So you cannot independently choose "fine frequency" and "fast time." NR's numerology is the single \(\mu\) knob that slides both at once, in powers of two, so the grids of different numerologies always nest cleanly.

Architecture diagram: the fixed 10 ms frame / 1 ms subframe, subdivided into 2^μ slots. Higher numerology packs more, shorter slots into the same subframe — the scheduling clock speeds up.

Round 2 — Internal Mechanics & Mathematical Model

The numerology family

Subcarrier spacing scales in powers of two from a 15 kHz base:

\[ \Delta f = 2^{\mu}\cdot 15\ \text{kHz},\qquad \mu\in\{0,1,2,3,4\} \]

OFDM ties symbol time to spacing: the useful symbol duration is \(T_u = 1/\Delta f\), so \(T_u = \frac{1}{2^\mu\cdot 15\,\text{kHz}}\). A slot always holds 14 symbols (normal cyclic prefix), giving slot duration:

\[ T_{\text{slot}} = 2^{-\mu}\ \text{ms},\qquad N_{\text{slot}}^{\text{subframe}} = 2^{\mu} \]

μ	SCS (kHz)	Slot (ms)	Slots/frame	Symbol ≈ (µs)	Typical use
0	15	1.0	10	66.7	<3 GHz, coverage, mMTC
1	30	0.5	20	33.3	sub-6 GHz mid-band (C-band)
2	60	0.25	40	16.7	URLLC, both FR1/FR2
3	120	0.125	80	8.3	mmWave (FR2)
4	240	0.0625	160	4.2	mmWave SSB only

The cyclic-prefix trade (derivation of the cost)

OFDM prepends a cyclic prefix (CP) of duration \(T_{\text{CP}}\) to absorb multipath delay spread \(\tau_{\max}\); correct reception needs \(T_{\text{CP}}\ge\tau_{\max}\). The CP is a fixed fraction (~7%) of the symbol, so its absolute length shrinks with the symbol:

\[ T_{\text{CP}} \approx 0.07\,T_u = \frac{0.07}{2^\mu\cdot 15\,\text{kHz}} \]

Doubling \(\mu\) halves \(T_{\text{CP}}\). So high numerology (short slots, low latency) tolerates less delay spread — which is fine at mmWave (small cells, short echoes) but breaks in large rural cells. This inequality is exactly why numerology is band-dependent: you cannot use \(\mu{=}3\) in a cell whose delay spread exceeds ~0.5 µs.

Resource grid & capacity

The atomic unit is the resource element (1 subcarrier × 1 symbol). A resource block (RB) is 12 subcarriers, so an RB occupies \(12\Delta f\) Hz — wider at higher \(\mu\). Peak rate scales as \(\propto\) (RBs) × (bits/symbol) × (symbols/s), and symbols/s \(= 14\cdot 2^\mu/\text{ms}\), so throughput per Hz is roughly numerology-invariant — the choice trades latency and robustness, not raw capacity.

Invariants & limiting cases

Invariants: (1) the 10 ms frame / 1 ms subframe boundaries are fixed for all \(\mu\) — numerologies always align at subframe edges, enabling mixed-numerology multiplexing in one carrier; (2) 14 symbols/slot (normal CP) regardless of \(\mu\); (3) total time-frequency area per RB-symbol is conserved (\(\Delta f\cdot T_u=1\)). Limiting cases: \(\mu\to\infty\) → vanishing slots and CP, latency → 0 but only survivable with near-zero delay spread (tiny cells); \(\mu=0\) → LTE-like 1 ms slots, max coverage/robustness, worst latency. URLLC additionally uses mini-slots (2/4/7 symbols) to cut latency below a full slot without raising \(\mu\).

Round 3 — Where It Breaks & Expert Debates

Mixed numerology creates inter-subcarrier interference. OFDM subcarriers are only orthogonal when they share the same spacing. Putting \(\mu{=}0\) and \(\mu{=}1\) users side by side in one band breaks orthogonality at the boundary, leaking power between them. Guard bands and filtered/windowed OFDM mitigate it but cost spectrum. How much guard is "enough" is an implementation trade with no universal answer.

Short slots amplify control overhead. Every slot needs control-channel (PDCCH) and reference-signal overhead. As slots shrink at high \(\mu\), that per-slot overhead repeats more often, eating into the efficiency the extra speed was supposed to buy. There's a real debate about whether ultra-low-latency configs are worth their overhead versus mini-slots on a lower numerology.

The latency floor isn't just the slot. Slot duration is only one term; processing time, HARQ round-trips, and scheduling-request delay all add up. Shrinking \(\mu\) buys diminishing returns once these dominate — a common misconception is that \(\mu{=}3\) alone delivers URLLC's 1 ms budget. It doesn't without the full low-latency toolbox (mini-slots, pre-emption, grant-free).

Phase noise vs power efficiency at mmWave. High \(\mu\) is chosen at mmWave partly to outrun oscillator phase noise, but wide SCS raises PAPR sensitivity and power-amplifier demands. The "right" numerology at 28/39 GHz is genuinely contested and hardware-dependent.

Failure mode to remember: choosing numerology by latency alone. If \(T_{\text{CP}}\) drops below the channel's delay spread, you get inter-symbol interference that no amount of coding fully fixes — the link degrades in a way that looks like mysterious coverage loss. Numerology must be chosen against the deployment's delay spread, not just its latency target.

Round 4 — AI × Networks Connection

Numerology sets the hard real-time deadline that every ML control loop in the RAN must beat. The near-RT RIC operates on a 10 ms–1 s loop, but the MAC scheduler it advises runs every slot — \(2^{-\mu}\) ms, i.e. as fast as 125 µs at \(\mu{=}3\). This is precisely why a learned controller cannot be the scheduler: the slot clock is far below the RIC's inference latency floor. The numerology literally quantifies the timescale-separation invariant that makes O-RAN's control model work.

It also shapes what ML sees: the resource grid at a given \(\mu\) fixes the dimensionality and cadence of the KPI time-series a Transformer forecaster ingests — higher numerology means more, finer-grained samples per second, changing both the sequence length and the memory footprint of any sequence model. And mixed-numerology scheduling (which \(\mu\) to assign which slice) is itself a decision an RL agent could optimize — a discrete action tied directly to the SCS-vs-delay-spread trade above.

Cross-links

Networks · O-RAN architecture → the slot clock \(2^{-\mu}\) ms is the deadline that defines the near-RT vs DU timescale separation.

Networks · RAN scheduling algorithms → the scheduler runs once per slot — numerology sets how often it must decide.

AI · Transformer attention internals → numerology sets the sampling cadence and sequence length of the KPI series a forecaster consumes.

Pending intersection nodes this unblocks: Transformer models for traffic prediction (sampling cadence), RL for network slicing (numerology assignment), inference at the edge (loop-budget grounding).

Intersection diagram: the numerology-derived slot clock is the RAN's fastest deadline. It sits below every ML control loop, which is why learned controllers advise the scheduler rather than run at slot rate.

Open questions this raises

Should numerology assignment per slice be a learned decision (RL over a discrete \(\mu\) action), and how would it trade latency SLAs against the delay-spread robustness constraint?
Does a traffic forecaster's accuracy depend on the KPI sampling cadence set by \(\mu\), and is there an optimal aggregation window that's numerology-aware?
How far can mini-slots and grant-free access push latency down without raising \(\mu\), and where does that leave the case for very high numerologies outside mmWave?
Can any useful learned control be distilled cheaply enough to run at slot rate in the DU, or is the slot clock a permanent hard floor for ML in the RAN?

← Back to Networks · Home