Is 5G Really 1 ms? A URLLC Latency Reality Check

The 1 ms that never was

If you have spent any time in 5G, you have seen the slide: a stopwatch, a "1 ms" callout, and a self-driving car or a remote surgeon. The number is real. What it measures is not what the slide implies.

ITU-R Report M.2410-0 — the document that actually sets the IMT-2020 targets — defines user-plane latency as "the contribution of the radio network" to one-way delay: the time from a layer-2/3 SDU entering the radio interface to it leaving the other side. And it qualifies that figure precisely: "in unloaded conditions (i.e. a single user) for small IP packets (e.g. 0 byte payload + IP header)." The minimum requirement is 1 ms for URLLC and 4 ms for eMBB (M.2410-0 §4.7.1).

Read that again. One user. No load. A bare packet. The radio interface only — nothing past the gNB. Transport, the UPF, the core's own processing, the application server: all of it was always extra, sitting outside the number. The 1 ms was never an end-to-end promise. It was a radio-layer floor, measured under the most favourable conditions a lab can construct.

There is a second number on that ITU page that gets quoted far less, and it is the one that actually bites. The reliability requirement is a 1−10⁻⁵ success probability of delivering a 32-byte layer-2 PDU within 1 ms at the coverage edge of the Urban Macro-URLLC test environment (§4.10). The "UR" in URLLC — ultra-reliable — is the hard half. Hitting 1 ms occasionally is an engineering inconvenience. Hitting it on 99.999% of packets, at the cell edge, is the wall most deployments never get over.

This article is the spec-and-measurement walk-through behind the marketing. We will trace where the milliseconds actually go, show that 3GPP itself never standardized a 1 ms QoS class, price the URLLC toolbox feature by feature, and look at what operators are genuinely selling in 2026. The companion references explain the mechanics — what 5QI actually is, the slot and mini-slot math of NR numerology, how a PDU session and its QoS flows are set up. This piece assumes you know those and asks the harder question: does the promise hold end to end?

Where the milliseconds go

The radio interface is one term in a sum. To understand latency you have to budget the whole one-way path, and the uplink path is the instructive one because it carries the part the downlink gets for free: the scheduling request.

Walk a packet up the stack. A uplink-heavy transmission with grant-based scheduling looks like this:

1. UE application and processing — the packet is generated and pushed down the stack.
2. Frame alignment — the UE cannot transmit whenever it likes; it waits for the next uplink opportunity in the TDD pattern. Modelled classically as a uniform 0–1 TTI wait.
3. Scheduling request + grant — with grant-based UL, the UE sends an SR, the gNB schedules a grant (the scheduler runs once per slot), and the grant is transmitted back. In a TDD frame this costs a full TDD period before the UE can send data. This is the single biggest avoidable chunk, and it is why configured/grant-free UL exists.
4. Transmission — at least one slot of actual data.
5. HARQ retransmission margin — if the first attempt is NACKed, you pay a round trip. The classic analytical budget puts the HARQ RTT at roughly 4 TTIs.
6. gNB processing — small but real.
7. CN packet delay budget — the static slice of delay 3GPP reserves for the core (more on this in the next section): 1, 2, or 5 ms for delay-critical flows.
8. Transport + application server — everything between the UPF's N6 interface and wherever the logic actually runs.

How big are these in practice? The most useful recent data is Maghsoudnia et al. (EPFL/RWTH, HotNets '24), who instrumented an srsRAN testbed on n78 with 0.5 ms slots and decomposed the gNB layer processing: SDAP 4.65 µs, PDCP 8.29 µs, RLC 4.12 µs, MAC 55.21 µs, PHY 41.55 µs — tidy microsecond-scale numbers. And then the line that should be printed on every URLLC business case: RLC queueing alone measured 484 µs. The protocol layers are cheap; waiting in a queue is not. On top of that, their SDR radio head added roughly 500 µs, and grant-based UL added a full TDD period versus grant-free.

The waterfall in Figure 1 makes the point visually. The ITU 1 ms line covers — by definition — only the radio-network terms. Stack the SR/grant handshake, a single retransmission, and the static CN PDB on top, and you are well past it before the packet ever reaches transport. The radio engineers can hit their budget and the end-to-end number can still be 10× larger, with nobody having made a mistake.

The HotNets authors performed a worst-case analysis of which TDD configurations can even meet 3GPP's 0.5 ms one-way design target. The widely-repeated headline — "only a DM pattern with grant-free UL works" — needs a careful caveat: that is a worst-case result restricted to the minimal TDD common configurations that carry both DL and UL. Their own Table 1 shows that FDD and a 0.25 ms mini-slot configuration also meet 0.5 ms in FR1. So the honest statement is narrower and more useful: in constrained TDD, grant-based UL essentially cannot make a half-millisecond budget because the SR/grant handshake alone burns a TDD period — and their measured DDDU testbed missed the target. Latency, reliability, capacity: you are choosing two.

3GPP never standardized a 1 ms QoS class

Here is the irony that survives every fact-check. If you go to the table where 3GPP defines its delay targets — the 5QI characteristics table, TS 23.501 Table 5.7.4-1 — there is no 1 ms entry. The tightest standardized packet delay budget is 5 ms.

Two things matter about that 5 ms. First, the PDB is defined UE ↔ N6 termination at the UPF (§5.7.3.4) — not air interface only. It already includes the core's path. Second, from each PDB a static CN PDB is subtracted to derive the radio budget: 1 ms (NOTE 4), 2 ms (NOTE 5), or 5 ms (NOTE 6) for the delay-critical classes, and 20 ms (NOTE 13) for non-critical ones. (The notes are not uniform — Mission Critical 5QIs use 10 ms per NOTE 7, for instance — so treat 20 ms as the common, not universal, value.) A dynamic per-path CN PDB is also permitted for delay-critical GBR.

The delay-critical GBR rows are worth knowing by name, because they are what people mean when they say "URLLC 5QI":

A point that the adversarial fact-check flagged and that I want to be explicit about: 5QI 82 is not "1 ms air interface." Its PDB is 10 ms, measured UE↔UPF, with the CN PDB baked in. There is no row in this table that delivers a 1 ms air-interface guarantee, because there is no 1 ms row at all. If you want 1 ms end-to-end, you are operating outside the standardized QoS table entirely. The companion 5QI reference covers the GBR/non-GBR mechanics; the load-bearing fact for this argument is simply that the floor is 5 ms and a chunk of that belongs to the core.

Figure 2 plots these against the XR/interactive classes added in Rel-17/18 — 5QI 87 (5 ms, motion tracking), 88 (10 ms), 89 (15 ms, 17 kB MDBV, split rendering), 90 (20 ms, 63 kB MDBV). 3GPP's own growth area for low latency sits at 5–20 ms. The 1 ms ITU line floats below the entire standardized table, where no QoS class lives.

The deployment toolbox and its price

URLLC is not a switch you flip; it is a set of Rel-15/16 features, each of which buys latency or reliability by spending something else.

Grant-free / configured-grant UL. Pre-allocate uplink resources so the UE skips the SR/grant handshake — the cheapest large latency win available, and the only realistic way to approach a half-millisecond UL in constrained TDD. The price: those resources are reserved whether or not the UE has data, so the scheme does not scale past a handful of UEs. Rel-16 allows up to 12 configured-grant configurations per BWP (TR 21.916 §5.2). PDCP duplication. Send the same PDCP PDUs over up to 4 logical channels (CA- and/or DC-based, dynamically activated by a MAC CE), so a loss on one leg is covered by another. This is a reliability tool, and it costs capacity in direct proportion to the number of legs (TR 21.916 §5.3). Redundant PDU sessions and N3 redundancy. Two independent paths through the network plus per-QoS-flow N3 tunnel redundancy — reliability bought with duplicated transport. DL pre-emption / UL cancellation. When a URLLC packet arrives mid-slot, the gNB can puncture an in-flight eMBB transmission. Rel-15 signals this to eMBB UEs with DCI format 2_1 (INT-RNTI), a 14-bit per-cell indication (TS 38.213 §11.2); Rel-16 adds UL cancellation via DCI 2_4 so a URLLC UL can stomp on a scheduled eMBB UL. The cost lands on the eMBB users whose throughput you just sacrificed. Compact DCI and faster monitoring. Rel-16 added DCI formats 0_2/1_2 (~24 bits) for more robust control, span-based PDCCH monitoring down to 2-symbol spans, sub-slot HARQ-ACK (multiple PUCCHs per slot), and PUSCH repetition Type B (back-to-back mini-slot repetitions across slot boundaries). These shave the deadlines but effectively demand hardware-accelerated processing to meet sub-slot timelines. Mini-slots. FR1's minimum slot is 0.25 ms (µ=2, 60 kHz SCS); FR2 allows much shorter durations. The slot/symbol arithmetic is exactly what the NR numerology reference works through — this article does not re-derive it. What matters here is that shorter slots reduce frame-alignment and transmission terms but do nothing for queueing, the SR/grant handshake, or the CN PDB.

Every entry in this toolbox is a trade. None of them is free, and stacking them — grant-free + duplication + pre-emption — is exactly how you end up with a network that serves a dozen URLLC UEs beautifully and falls over at scale. That is not a defect; it is the physics, honestly accounted for. Start a free 7-day trial — no card — if you want to work the latency budgets and 5QI mappings hands-on rather than just read about them.

Determinism, not raw speed

Here is the conceptual turn that makes industrial 5G actually work, and it is the most under-reported part of the whole stack: the goal is not raw speed, it is bounded, deterministic delivery — and the framework for engineering it lives partly outside the 5QI table.

TSN bridge integration. TS 23.501 §5.27/5.28 integrate the 5G system into IEEE 802.1 TSN as a logical TSN bridge, with DS-TT (device-side) and NW-TT (network-side) translators implementing a hold-and-forward buffer — 802.1Qbv-style de-jittering that trades a little latency for tight bounds. Time synchronization models the 5GS as an 802.1AS time-aware system (or an IEEE 1588 boundary/transparent clock), with UE, gNB and UPF all syncing to the 5G internal grandmaster. (Restrictions apply: always-on PDU session, SSC mode 1 only, no home-routed roaming.) Survival time. This is the unsung hero. TS 22.104 introduces survival time as the number of consecutive messages — or the span of time — an application can survive losing before the service is considered failed. Crucially, survival time is not in the 5QI table. It lives in the TS 22.104 requirements and is carried to the scheduler via TSCAI (TSC Assistance Information), alongside burst arrival time, periodicity, and direction (TS 23.501 §5.27.2). The scheduler can then boost robustness only after a burst is lost, instead of over-provisioning every packet.

Why does this matter so much? Because it converts an impossible per-packet target into an engineerable one. With survival time equal to the transfer interval, 99.9% packet reliability yields 99.9999% communication service availability (TS 22.104 Table 5.1-1). You do not need five-nines per packet if the application can ride out one loss. That is how "six nines availability" stops being marketing and becomes a schedulable quantity.

The concrete requirements are demanding but bounded. TS 22.104 Table 5.2-1 motion-control rows specify, for example: 50 B at a 500 µs transfer interval with 500 µs survival time, ≤20 UEs in a 50×10×10 m area; 40 B at 1 ms / 1 ms, ≤50 UEs; 20 B at 2 ms / 2 ms, ≤100 UEs — with availability targets running from 99.999% up to 99.999999%. The clock-sync budget across the 5GS is ≤900 ns for the global time domain and ≤700 ns for the working clock (§5.6). Small areas, few devices, tight time sync. That is the real shape of deterministic 5G, and it is nothing like a public macro network.

Reality check: what is actually sold in 2026

So where does the market land? The peer-reviewed verdict is blunt. The HotNets '24 authors write that "four years since the initial commercial deployments of 5G, real-world implementations of URLLC satisfying the specified requirements remain elusive" — URLLC is "theoretically achievable but under very specific circumstances with stringent hardware and software conditions."

The published measurements they compile (all 2020–2023 vintage, so read as historical, not a 2026 snapshot) tell the same story: campus-network RTTs of 6–40 ms and one-way 2–8 ms; a Qualcomm mmWave URLLC demo at 1.9 ms DL / 4.0 ms UL; an Ericsson industrial-robot demo at 5 ms; and the best single-UE lab result — a Nokia + Sennheiser hardware-accelerated audio link — at 0.8 ms DL minimum, with each retransmission adding ~0.5 ms. And the reliability point in one statistic: on commercial mmWave, sub-millisecond latency was achieved only 4.4% of the time (Fezeu et al., PAM 2023, via the HotNets compilation). It is not that mmWave cannot go fast; it is that it cannot go fast reliably. The hard "R" again.

Figure 3 lines these up against the 1 ms target. The historical framing comes from Dean Bubley (Disruptive Analysis, Sep 2020), who argued that on 3.4–3.8 GHz TDD "1 ms is off the table" and that public 5G would realistically land at "perhaps 10–20 ms." Treat that as durable structural reasoning from 2020 — it follows from the TDD frame structure, which has not changed — rather than a current measurement.

What operators actually ship is not 1 ms. They ship consistency. The industry quietly rebranded:

• Ericsson markets "time-critical communication" with a ~20 ms one-way RAN budget within a 20–40 ms end-to-end budget at 99% reliability — explicitly the service requirement it studies, framed honestly, and a world away from 1 ms / five-nines.
• T-Mobile US deployed L4S nationwide on 5G Advanced (announced July 2025, the first US carrier to do so), selling consistent low latency for cloud gaming, XR, and remote driving (Vay) — with no millisecond SLA published.
• Operators sell slices — Deutsche Telekom's 5G+ Gaming slice, Vodafone Germany's "Campus Flex" — that guarantee priority and bit rate, not deterministic milliseconds. Slicing is the mechanism operators reach for instead of 1 ms; the network slicing primer covers how S-NSSAI and the NSSF actually work.

The honest summary: the product that exists is bounded jitter at tens of milliseconds. Useful, real, sold today — and not URLLC as ITU defined it.

One careful claim, flagged as such: across operator press, analyst notes, and trade press searched through mid-2026, we found no documented commercial public-network service delivering 1 ms at 99.999%. That is a negative claim — absence of evidence, not evidence of absence — and the most likely unverified counterexamples are Chinese deployments (China Mobile's deterministic-networking work and power-grid differential-protection pilots), which appear in promotional material we could not independently verify this pass. It is worth noting, too, that such "six-nines reliability" figures (e.g. China Mobile remote-surgery claims) describe dedicated/private deployments, not a public-network 1 ms SLA — the two should not be conflated. If you have a verifiable counterexample, it would sharpen this section.

The pragmatic middle ground

The low-latency market did not vanish — it relocated. The place it actually settled is Rel-18 XR, and it is worth understanding as the realistic destination rather than a consolation prize.

Rel-18's XR media work ("XRM") introduced PDU Sets — the group of packets that make up one video frame or slice, handled as a unit — with a PDU Set Delay Budget (PSDB) and PDU Set Error Rate (PSER), plus data-burst signalling and ECN marking for L4S in TS 23.501. The RAN gains XR awareness through extended UE Assistance Information (arrival time, periodicity, jitter), studied in TR 38.835. (The PDU Set QoS mechanics and L4S/ECN details here rest on 3GPP feature pages and a peer-reviewed overview, since the 3gpp.org technology pages were unreachable during research; treat those specifics as reported. The XR 5QIs themselves are primary-confirmed in TS 23.501.)

Those XR 5QIs — 87 through 90, at 5/10/15/20 ms with large MDBVs — are the standardized expression of the middle ground. This is the slice of Rel-18 the low-latency story actually lives in; the broader 5G-Advanced survey covers the rest of the release. It is also why the operator use-case catalogues and private 5G deployment guides read optimistically: the use cases are shipping — at 5–20 ms, with bounded jitter, in small private deployments where grant-free UL and a handful of UEs make the numbers work. Private networks are exactly where URLLC realistically lands: single-digit-millisecond targets, single-digit UE counts, and pre-allocated resources that do not have to scale. The honest figure there is 5–10 ms, not 1 ms.

What to take away

• 1 ms is a radio-only, single-user, unloaded, 32-byte figure (ITU-R M.2410-0 §4.7.1). It was never an end-to-end guarantee. The reliability half — 1−10⁻⁵ at the cell edge — is the harder requirement.
• 3GPP never standardized a 1 ms QoS class. The tightest 5QI PDB is 5 ms, measured UE↔UPF, with a 1/2/5 ms CN PDB subtracted to derive the radio budget (TS 23.501 Table 5.7.4-1).
• The URLLC toolbox is a set of trades. Grant-free UL, PDCP duplication, pre-emption, and mini-slots each buy latency or reliability by spending capacity or scalability.
• Determinism beats raw speed. TSN bridging, ≤900 ns sync, and survival time (TS 22.104, carried via TSCAI — not in the 5QI table) turn impossible per-packet five-nines into engineerable availability.
• What ships in 2026 is consistency, not 1 ms — Ericsson's ~20 ms TCC budget, T-Mobile's nationwide L4S (Jul 2025), and slices. We found no documented public-network 1 ms / 99.999% service.
• The realistic home for low latency is Rel-18 XR (5QIs 87–90, 5–20 ms) and private 5G at 5–10 ms.

The 1 ms number is not a lie. It is a precisely-scoped lab measurement that was lifted out of its footnotes and put on a marketing slide. Knowing the scope is the difference between an engineer who can budget a real deployment and one who promises a customer something the standard never offered.