VoLTE with ROHC

Introduction

Robust Header Compression (ROHC) is the PDCP-layer function that makes VoLTE spectrally affordable. Voice over LTE is IMS media — small AMR/AMR-WB speech frames wrapped in RTP/UDP/IP — and on that traffic the protocol header is as large as, or larger than, the payload it carries. ROHC collapses that header to a couple of bytes on the dedicated voice radio bearer, and it is one of the handful of features that separates "voice as an afterthought" from "hundreds of concurrent calls per cell."

It runs inside the PDCP entity (TS 36.323), turned on per radio bearer by RRC, and it works because a voice flow is extraordinarily regular: the addresses and ports never change, and the RTP counters advance by a fixed step every 20 ms — the cadence set by the AMR codec (TS 26.114). ROHC learns that pattern, then stops sending everything it can predict.

From an operations point of view ROHC is a live, stateful process on each bearer: a compressor and decompressor keep a synchronised context, move through initialization/refresh states, and must recover from packet loss and from mobility events that wipe the context. When VoLTE quality degrades — robotic audio, silent gaps after a handover, poor cell-edge voice — the ROHC context and its state machine are among the first things to check. This page keeps that practical, debuggable lens.

Why ROHC is needed

The concrete purpose is capacity and coverage on the voice bearer. For a bulk download the header is a rounding error against a 1500-byte payload; for conversational voice the header is the packet, and it repeats 50 times a second per user for the entire call. Multiply that by every active caller in a cell and a large fraction of the LTE air interface is spent on header fields that barely change. Compressing them is not a nice-to-have — it is what lets an LTE cell carry hundreds of simultaneous VoLTE calls instead of a handful, and what lets a shrunken voice packet survive at the cell edge.

The Problem: Header Bigger Than the Voice

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

Look at the numbers layer by layer. The IP header is 20 bytes for IPv4 or 40 bytes for IPv6; UDP adds a fixed 8 bytes; RTP adds 12 bytes. That is a 40-byte transport stack over IPv4 and a 60-byte stack over IPv6 — and IMS deployments increasingly run IPv6, so the 60-byte case is the one that hurts most. Around it sits an AMR/AMR-WB frame of roughly 32 bytes.

So a single voice packet might be 40–60 bytes of header around 32 bytes of speech — the overhead is half to two-thirds of the packet. A call fires one of these every 20 ms — 50 packets per second per user — for its whole duration. Multiply that overhead by every active caller in a cell and you are burning a large fraction of the LTE air interface on header fields that are, packet after packet, almost identical. The IP addresses never change during the call, the UDP ports never change, and the RTP stream identifier never changes; only a couple of counters tick predictably. That is a compression opportunity begging to be taken.

What ROHC Does

ROHC exploits a simple observation: across the thousands of packets in one call, most header fields never change and the rest change predictably. 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 on the wire.

The deep mechanics — exactly how each profile encodes individual fields, the W-LSB (windowed least-significant-bits) sequence-number encoding, the CRC verification of each reconstructed header, and the full compressor and decompressor state machines — are covered on the general ROHC Header Compression page. This page does not repeat that machinery. Here the focus is narrower and concrete: what ROHC buys the VoLTE voice bearer, how it is switched on, how it interacts with the AMR codec, and why it is the linchpin of LTE voice capacity. Read the two pages together — this one for the VoLTE application, that one for the algorithm.

Where ROHC Lives — PDCP on the QCI 1 Voice DRB

ROHC is a PDCP function (TS 36.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. In the PDCP transmit chain the ordering is fixed: header compression happens first, then ciphering, then the PDCP header is prepended. On receive the mirror applies — deciphering first, then decompression — because the compressor must see the original clear-text IP header, not encrypted bytes.

For VoLTE the bearer in question is the dedicated GBR voice DRB mapped to the QCI=1 EPS bearer — the standardised QCI for conversational voice, with a guaranteed bit rate sized for the codec. RRC configures header compression through the PDCP-Config of that DRB. The headerCompression field is a CHOICE: either notUsed, or rohc. When set to rohc it carries the list of enabled profiles plus the maximum context identifier maxCID — how many parallel contexts (flows) the entity may track at once. A voice bearer needs only a couple of contexts (one per media direction/flow), so maxCID is small; the field exists mainly for bearers multiplexing many IP flows.

For voice, the profile that matters is profile 0x0001 (RTP/UDP/IP) — the only profile that is aware of RTP timing. Because it knows the timestamp advances by a fixed stride every packet and the sequence number increments by one, it can extrapolate almost the entire header from a single small sequence-number field. The UDP/IP and IP-only profiles still help, but they leave the RTP layer uncompressed and so give a much smaller win — useless for the voice media path.

Reading the ROHC bearer setup in the logs

Header compression either got negotiated onto the voice bearer or it did not — and that decision is visible in the RRCConnectionReconfiguration that establishes the QCI=1 DRB. If headerCompression comes back notUsed, or profile 0x0001 is absent from the list, the voice bearer will carry full 40/60-byte headers and cell voice capacity collapses.

Representative UE RRC log — illustrative, values vary by vendor/build:

Compressor States, Context and Learning the Fields

The compressor cannot emit tiny headers from the very first packet, because the decompressor has no context yet — it does not know the IP addresses, the ports, or the SSRC of this new flow. So it works through three states, sending progressively less as it gains confidence the far end is in sync. (For the full state machine, the transition triggers and the decompressor side, see the general ROHC page; this is the short version for the VoLTE case.)

How does the compressor “learn” the pattern? It classifies each header field as static, static-known, or changing. Static fields (addresses, ports, SSRC, IP version) are sent once in the IR state and never again. Semi-static fields that change by a constant delta — the RTP sequence number (+1) and timestamp (+ a fixed stride) — are established in the FO state; once the decompressor knows the stride, the compressor stops sending the timestamp at all and lets the decompressor derive it from the sequence number. From then on the only thing that genuinely needs transmitting each packet is a few low-order bits of the sequence number, protected by a small CRC. That is the SO state.

For a steady VoLTE 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. 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. The compressor also periodically drops back to IR state for a single packet to refresh the context — cheap insurance so that a decompressor which somehow lost sync recovers within a bounded time.

Reading the ROHC context in the logs

PDCP ROHC statistics show whether the compressor reached and stayed in the SO state and whether the decompressor is rebuilding headers cleanly. A high compressed-header size, frequent IR refreshes, or rising decompression CRC failures all mean the context is not holding — the audible symptom is robotic or dropped audio.

Representative UE PDCP/ROHC statistics 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 so steady — you have to look at the codec. VoLTE uses the AMR family: narrowband AMR (8 kHz sampling, 8 bit-rate modes from 4.75 to 12.2 kbit/s) and wideband AMR-WB (16 kHz sampling, 9 modes from 6.60 to 23.85 kbit/s). TS 26.114 defines how these are carried over RTP for IMS telephony. Both codecs produce one compressed speech frame per 20 ms of audio, and that fixed 20 ms cadence is precisely what makes the RTP timestamp advance by a constant stride — the regularity ROHC feeds on.

The codec can switch modes packet-to-packet (adaptive multi-rate: the network can request a lower rate under congestion or poor radio), so the speech payload size varies a little across the call — but the header structure does not, which is all ROHC cares about. Two related features also shape the traffic. Discontinuous transmission (DTX) stops sending full speech frames during silence and instead sends tiny SID (silence descriptor) comfort-noise frames roughly every 160 ms, cutting the packet rate during pauses. And the RTP payload can carry more than one 20 ms frame per packet (frame bundling), trading a little latency for fewer packets — though standard VoLTE keeps one frame per packet for lowest delay.

The key point for this page: a 20 ms frame at a typical wideband mode is about 32 bytes. That is the number the RTP/UDP/IP header must be measured against — and against 32 bytes, a 60-byte IPv6 header is catastrophic overhead. ROHC exists to make that ratio sane.

Robustness Modes and the LTE Voice Bearer

ROHC can run in three modes, which differ in how the decompressor confirms the context back to the compressor:

The “R” in ROHC is the point that matters for the radio link. The LTE air interface loses packets, and a scheme that broke every time a compressed header went missing would be useless for voice. ROHC tolerates loss in two ways: it encodes the sequence number in a window (W-LSB) so a few lost packets do not desynchronise the context, and the compressor periodically refreshes the full context via the IR state so a decompressor that lost sync recovers on the next refresh. In the bidirectional modes the decompressor can also NACK to pull the compressor back immediately. Robust does not mean it never loses sync — it means one lost packet cannot poison the whole flow, and recovery is bounded.

Two lower-layer choices work alongside ROHC to make the shrunken voice packet survive the radio. First, VoLTE maps its DRB to RLC Unacknowledged Mode (RLC-UM) rather than Acknowledged Mode. Voice is delay-sensitive and self-obsoleting — a retransmitted speech frame that arrives late is useless — so RLC does not retransmit; it just delivers in order and drops what is lost, which is exactly what a codec with error concealment wants. Second, at the cell edge the network can enable TTI bundling, where the same transport block is transmitted across several consecutive subframes (typically 4) to accumulate energy and improve the chance of decoding without waiting for HARQ round trips. TTI bundling is only worthwhile because ROHC has already made the transport block small — a compact block is what fits into a bundled, low-MCS grant at the edge of coverage.

Why It Matters for VoLTE Capacity and Coverage

Put the numbers side by side. Take an AMR-WB frame of 32 bytes at codec mode 12.65 kbit/s over IPv6:

That saving turns directly into VoLTE gains on the QCI=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 used in practice for VoLTE. Halving the transport block size roughly doubles the number of concurrent calls a scheduler can fit.
• 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, and it is what makes TTI bundling and RLC-UM effective.
• Efficiency with SPS. VoLTE uses semi-persistent scheduling to avoid per-packet PDCCH signalling; shrinking the packet lets that periodic grant be smaller too, freeing control and data resources for other users.

Summary

ROHC exists because the RTP/UDP/IP header on a VoLTE packet (40 B IPv4, 60 B IPv6) is as big as or bigger than the ~32-byte AMR/AMR-WB speech frame, and it repeats 50 times a second. As a PDCP function (TS 36.323) it runs a compressor/decompressor pair with a synchronised context, enabled per DRB by RRC via headerCompression: rohc with profile 0x0001 on the QCI=1 voice bearer, and after a short IR/FO warm-up it settles into the SO state where headers collapse to 1–3 bytes. That is what multiplies VoLTE cell capacity and improves cell-edge coverage.

To debug it, follow the state, not just the packet. First confirm ROHC was even negotiated onto the voice DRB (profile 0x0001, not notUsed). Then confirm the compressor reached SO state with a ~1–3 B average header and the decompressor is in FULL_CONTEXT. Robotic audio, gaps after handover, and rising decomp_crc_fail/context_invalidations all point at context desync — usually radio loss, a mobility event that reset the context without drb-ContinueROHC, or a broken feedback path. ROHC works hand in hand with RLC-UM, TTI bundling, and SPS to make the shrunken voice packet survive and scale on the air interface.