VoNR with ROHC in 5G NR

Introduction

Robust Header Compression is a PDCP function (TS 38.323) that runs inside the PDCP entity of a radio bearer, replacing the bulky RTP/UDP/IP header of each packet with a compressed header of a few bytes. It is a transmit-side compressor talking to a receive-side decompressor, both keeping a shared context that remembers the field values so the header need not be re-sent in full every packet.

Where does it sit in the UE/network lifecycle? ROHC is switched on per DRB by RRC, in the PDCP-Config delivered inside RRCReconfiguration, and it comes to life the moment the voice bearer is set up — typically when the IMS session establishes the GBR 5QI=1 voice flow. From then on it runs continuously for the whole call, compressing 50 packets a second, and it must survive handovers, radio loss, and codec-rate changes without corrupting the media.

Why it matters: for VoNR the header is comparable to or larger than the speech it wraps, so uncompressed voice would burn a large fraction of the air interface on near-constant fields. ROHC is what makes VoNR spectrally viable — roughly doubling the useful-payload ratio and multiplying the number of concurrent calls a cell can carry. Because the compression runs as a small state machine per flow, most VoNR "voice quality" or "capacity" investigations end up examining the ROHC state, its context, and how it behaves across mobility.

Why ROHC is needed

Concretely, three facts force header compression on the voice bearer. First, the header-to-payload ratio is inverted: unlike bulk data where a 40-byte header rides a 1500-byte payload, a VoNR header of 40–60 bytes wraps a 30–60 byte codec frame. Second, the packet rate is relentless: one frame every 20 ms, 50 per second, for the whole call, per user. Third, the fields are almost entirely predictable: addresses, ports and SSRC are constant, and the RTP sequence number and timestamp move by a fixed step each frame. That combination — huge relative overhead, high rate, near-total predictability — is exactly the case header compression was invented for, and it is why ROHC is universally enabled on the 5QI=1 voice DRB.

The Problem: Header Bigger Than the Voice

VoNR carries voice as media over IMS: the codec frame (typically AMR or AMR-WB) rides inside RTP, which rides inside UDP, which rides inside IP. Each layer adds a fixed header. The trouble is the sheer imbalance between that header and the speech it wraps. For bulk data the header is a rounding error against a 1500-byte payload; for VoNR the header is the packet.

Walk the layers from the outside in. The IP header carries addresses, traffic class, flow label and hop limit — 40 bytes for IPv6 (the VoNR norm), 20 for IPv4. UDP adds 8 bytes (ports, length, checksum), and RTP adds 12 (the V/P/X/CC and marker/payload-type octets, a 16-bit sequence number, a 32-bit timestamp and a 32-bit SSRC). That is 60 bytes of framing before a single sample of speech.

So a single voice packet might be 60 bytes of header wrapped around 32 bytes of speech — the overhead is nearly two-thirds of the packet. A voice call fires one of these every 20 ms, i.e. 50 packets per second per user, for as long as the call lasts. Multiply that overhead by every active voice user in a cell and you are burning a large fraction of the air interface on header fields that are, packet after packet, almost identical. The addresses never change, the ports never change, the SSRC never changes; only the RTP sequence number and timestamp move, and they move by a fixed step each frame.

What ROHC Does

ROHC exploits a simple observation: across the thousands of packets in one voice call, most header fields never change and the rest change in a completely predictable way. The source/destination IP addresses, the UDP ports and the RTP SSRC are constant for the whole call. The RTP sequence number increments by one each packet, and the timestamp jumps by a fixed sample count every 20 ms. Once both ends agree on those starting values and steps, almost nothing needs to be sent.

The deep mechanics — how each profile encodes fields, W-LSB (window-based least-significant-bit) sequence-number encoding, the compressed packet formats (IR, IR-DYN, UO-0, UO-1, UOR-2) and the full state machine — are covered on the general ROHC Header Compression page. This page does not repeat that state machine in full; the focus here is what ROHC buys the voice bearer specifically, how it is switched on, and how it survives the radio channel.

Where ROHC Lives — PDCP on the Voice DRB

ROHC is a PDCP function (TS 38.323). It runs inside the PDCP entity of a specific radio bearer, on the transmit side as the compressor and on the receive side as the decompressor, and it is turned on per DRB by RRC. For VoNR the bearer in question is the GBR voice DRB carrying the 5QI=1 QoS flow — the standardised 5QI for conversational voice, with a 100 ms packet delay budget and a 10^-2 error rate target.

RRC configures ROHC through the PDCP-Config of that DRB, sent in RRCReconfiguration. The headerCompression choice is set to rohc (as opposed to notUsed), and that structure carries three things: the set of enabled profiles (each a boolean like profile0x0001), the maximum context identifier maxCID, and the drb-ContinueROHC flag used at handover. For voice, the profile that matters is profile 0x0001 (RTP/UDP/IP) — the RTP-aware profile that understands the sequence-number/timestamp relationship and delivers the biggest saving.

Representative 5G SA config snippet (PDCP-Config of the voice DRB) — illustrative, values vary by vendor/build:

ROHC sits at a precise point in the PDCP transmit chain. On transmit the order is: receive the SDU, perform header compression, then ciphering, then add the PDCP header and integrity protection where configured; on receive the order reverses — deciphering first, then decompression. Compression must precede ciphering because ROHC needs to read the plaintext RTP/UDP/IP fields it is compressing; once ciphered they are opaque.

Compressor States & Context

The compressor cannot emit tiny headers from the very first packet, because the decompressor has no context yet. So it works through three states, sending less as it gains confidence the far end is in sync. (For the full state machine, transitions and packet formats see the general ROHC page; this is the short version for the voice case.)

For a steady voice stream the SO state is where the win lives. A voice call is exactly the kind of long, regular flow ROHC was designed for: after the first handful of packets the compressor settles into SO state and stays there for the rest of the call, sending 1–3 byte headers 50 times a second. In SO state the compressor typically sends a UO-0 format — a single octet carrying a few LSBs of the RTP sequence number plus a CRC — and the decompressor reconstructs the full 60-byte header by adding the known static fields and extrapolating the timestamp from the stride it learned in FO state.

The CID (context identifier) tags which flow a compressed header belongs to, so a PDCP entity can track several contexts at once up to maxCID. A single voice call needs only one context; a device with several simultaneous media streams uses several CIDs on the same entity.

Reading the ROHC state machine in the logs

The single most useful thing to watch is the compressor/decompressor state over time: it should climb IR→FO→SO in the first few packets and then stay in SO. Repeated drops back to IR/FO signal a problem — loss of sync, a handover context reset, or a jittery flow.

Representative PDCP/ROHC log — illustrative, values vary by vendor/build:

The AMR / AMR-WB Codec and 20 ms Packetization

To see why the payload is so small — and why the timing is so regular that ROHC can extrapolate it — you have to look at the codec. VoNR uses the 3GPP AMR (narrowband, 8 kHz sampling) and AMR-WB (wideband, 16 kHz sampling) speech codecs, negotiated over IMS SDP per TS 26.114. Both are multi-rate: the encoder can switch its bit rate frame-by-frame in response to a Codec Mode Request (CMR), trading speech quality against bandwidth without renegotiating the session.

The key regularity is timing. Both codecs produce one frame every 20 ms — 50 frames per second. Each 20 ms frame corresponds to a fixed number of audio samples (160 samples at 8 kHz for AMR, 320 at 16 kHz for AMR-WB), which is exactly why the RTP timestamp advances by a constant stride every packet. That fixed stride is the property ROHC profile 0x0001 exploits: once it has seen the stride it never needs to send the timestamp again.

Packetization follows RFC 4867 (the AMR/AMR-WB RTP payload format) as profiled by TS 26.114: one 20 ms speech frame per RTP packet in bandwidth-efficient or octet-aligned mode, prefixed by a small payload header (a CMR field and table-of-contents byte). During silence the codec uses Discontinuous Transmission (DTX), sending only occasional Silence Insertion Descriptor (SID) frames for comfort noise. DTX cuts the packet rate further, but the sequence number and timestamp then jump at talk-spurt boundaries — which the compressor absorbs with a brief return to FO state before settling back into SO state.

Why It Matters for VoNR Capacity

Put the numbers side by side. Take an AMR-WB frame of 32 bytes at codec mode 12.65 kbit/s over IPv6, and add a small RTP payload header so the on-air voice block is roughly 35 bytes of media:

That saving turns directly into VoNR gains on the 5QI=1 GBR voice DRB:

• Cell voice capacity. Far fewer air-interface bytes per packet means many more simultaneous voice users share the same spectrum — the single biggest reason ROHC is universally deployed for VoNR. Halving the on-air packet roughly doubles the number of calls a fixed resource budget can carry.
• Coverage and robustness. A smaller transport block can be sent at a lower code rate / lower MCS, or fits in fewer PRBs, so it is more likely to be decoded at the cell edge — better voice coverage where SINR is poor.
• Efficiency with SPS / configured grant. Voice already uses semi-persistent scheduling to avoid per-packet signalling; shrinking the packet lets that periodic grant be smaller too, freeing PRBs for other users. Fewer transmitted bits, 50 frames a second over a multi-minute call, also lowers UE transmit energy.

Modes, Feedback and Radio Robustness

ROHC can run in three modes, which differ in how the decompressor confirms the context to the compressor. The choice trades feedback traffic against resilience:

The “R” in ROHC — robust — is the point that matters for the radio link. The air interface loses packets; a scheme that broke every time a compressed header went missing would be useless for voice. ROHC tolerates loss two ways. First, it encodes the sequence number with W-LSB (window-based least-significant-bit) encoding, sending only the low-order bits within a sliding window, so a few lost packets do not desynchronise the context — the decompressor can still resolve the true sequence number as long as it stays within the window. Second, the compressor periodically drops back to the IR state to refresh the full context, so a decompressor that lost sync recovers on the next refresh. In the bidirectional modes the decompressor can also send feedback (a NACK or STATIC-NACK) to pull the compressor back to FO state or IR state immediately.

Each compressed packet also carries a small CRC over the reconstructed header, so the decompressor verifies it rebuilt the header correctly before delivering the packet; on a CRC failure the packet is discarded rather than delivered corrupt. Robust does not mean it never loses sync — it means one lost packet cannot poison the whole flow, and recovery is bounded to a few frames (tens of milliseconds), well within what voice can tolerate.

Summary

ROHC is what makes the VoNR voice bearer economical. The chain is short and worth carrying: a VoNR packet is a 30–60 byte codec frame under a 40–60 byte RTP/UDP/IP header sent 50 times a second, so the header dominates. ROHC exploits the fact that the static fields never change and the sequence-number/timestamp move in fixed steps, collapsing the header to 1–3 bytes once the compressor reaches SO state.

When you debug VoNR capacity or voice-quality issues, walk the same path every time: confirm ROHC is actually enabled with profile 0x0001 on the DRB the 5QI=1 flow maps to; confirm the compressor reaches and stays in SO state (mostly UO-0 packets, 1–3 B headers); confirm the learned timestamp stride matches the codec; and watch for CRC_FAIL/IR bursts around radio loss and handovers. The first of those that does not line up is usually your root cause — a config that left compression off, a profile that ignored the RTP stride, a context that keeps resetting, or a mobility event that dropped the context because drb-ContinueROHC was not honoured.

Quick Q&A