ROHC Header Compression in 5G NR

Introduction

ROHC (RObust Header Compression) is a PDCP user-plane function: it lives inside the PDCP entity of a DRB and runs on the transmit side (the compressor) and receive side (the decompressor). NR does not define the compression algorithm itself — that belongs to the IETF (RFC 5795 and the per-stack profile RFCs). TS 38.323 defines only how PDCP invokes ROHC, which profiles it may use, and how the compressed output is carried as a PDCP SDU.

It is configured when the network sets up or reconfigures a DRB, via the headerCompression choice inside pdcp-Config, and it runs continuously for the life of that bearer. Because ROHC context is state held per PDCP entity, it is also touched at every handover and PDCP re-establishment — normally reset, optionally preserved.

It matters most for small, frequent, real-time flows — above all VoNR — where the header genuinely dwarfs the payload. On such flows ROHC roughly doubles the useful payload ratio, which translates almost directly into how many simultaneous voice users a cell can carry, and it saves UE battery by putting fewer bits on the air.

Why Header Compression Exists

The problem ROHC solves is structural, not incidental. A real-time media flow such as VoNR emits a small speech frame every 20 ms, but each frame is wrapped in three protocol headers before it hits the radio stack: RTP (12 bytes) inside UDP (8 bytes) inside IP (20 bytes for IPv4, 40 bytes for IPv6). That is 40 bytes over IPv4 and 60 bytes over IPv6 of pure header on top of a payload that may itself be only 20–40 bytes. On the air interface, where every resource element is scarce and shared, sending 60 bytes of header to protect 30 bytes of speech is a direct waste of capacity and battery.

The reason this works is redundancy. Across the thousands of packets in a single call, the source and destination IP addresses never change, the UDP ports never change, and the IP version, protocol byte and RTP SSRC are all fixed. After the first packet those fields are pure repetition — the receiver already holds them. The fields that do change usually change by the same amount every packet: a speech frame every 20 ms means the RTP timestamp jumps by a constant sample count and the sequence number increments by one. If both ends agree on the starting value and the step, the compressor need not send these fields at all; the decompressor extrapolates them. Only when something breaks the pattern — a lost packet, a silence-suppression gap, a marker bit — does the compressor transmit a correction.

Profiles — One Compressor per Protocol Stack

ROHC does not squeeze bytes blindly; it understands specific protocol stacks. Each stack has a profile, identified by a 16-bit profile number, and both ends must agree on which profiles are permitted for a bearer. A profile encodes the field-classification rules and the compressed-header formats for exactly that combination of protocols. The set of profiles PDCP is allowed to use is signalled to the UE inside pdcp-Config at bearer setup.

The pairing is deliberate: 0x0001 is where the value lives for operators, because it targets RTP media, and RTP is where the constant-stride timestamp and sequence number make near-total compression possible. The ESP profile (0x0003) handles the case where the payload is an IPsec-encrypted tunnel, and the TCP profile (0x0006) adds machinery for TCP's sliding window and options that the simpler UDP-family profiles do not need. The 0x0101–0x0104 range is the ROHCv2 revision of the same four stacks, redesigned so that recovery from context damage is simpler and more uniform. Every profile always coexists with 0x0000, which is the guaranteed escape hatch when a flow simply is not compressible.

How Fields Are Classified

Before it can compress anything, ROHC sorts every header field into a class, because the class decides whether the field is sent once, sent as a delta, or never sent at all. The classification is what turns "60 bytes of header" into "a few bits of genuinely new information."

The changing class is where the cleverness sits. ROHC further splits it by behaviour — some fields are effectively static, some change rarely, some alternate, and a few are genuinely irregular and must be sent verbatim each time (an occasional RTP marker bit, for example). The workhorse encoding is window-based least-significant-bits (W-LSB): rather than send a whole sequence number, the compressor sends only the low-order bits needed to disambiguate it within a window of recently acknowledged values. The RTP timestamp gets an additional trick, scaled timestamp encoding, which divides out the constant per-packet stride so only the multiplier — often unchanged — needs representing. Between static suppression, inference, and W-LSB deltas, a steady-state packet ends up carrying little more than a truncated sequence number.

Compressor States — IR, FO, SO

The compressor cannot begin sending tiny headers immediately, because the decompressor starts with no context. So it works through three states, sending progressively less as its confidence grows that the far end is synchronised.

The compressor climbs upward — IR to FO to SO — as it becomes confident the decompressor's context matches its own. It gains that confidence in one of two ways: through explicit feedback in the bidirectional modes, or optimistically in the unidirectional mode, by repeating the same information several times on the assumption that at least one copy arrives. When something changes that the decompressor may have missed, the compressor drops back down — to FO if only a dynamic field jumped, or all the way to IR if a static field changed. Independently of all this, it periodically emits an IR packet as a refresh, so a decompressor that quietly lost sync can recover without any signalling.

Decompressor States — NC, SC, FC

The decompressor runs its own, mirror-image state machine with three states, and the two machines are not the same: the compressor's states describe what it sends, while the decompressor's describe what it can currently rebuild.

A fresh decompressor starts in NC and jumps straight to FC the first time it successfully decompresses an IR packet whose CRC verifies. It stays in FC as long as headers keep passing their CRC checks. If they start failing — because the context has drifted — it does not collapse all the way at once: it degrades from FC to SC, attempting context repair using the static part it still trusts, and only falls to NC if repair also fails. Every compressed header carries a small CRC computed over the original uncompressed header precisely so the decompressor can tell whether its reconstruction was correct before passing the packet up the stack.

Operating Modes — U, O and R

The same state machines behave differently depending on whether a feedback channel is available and how aggressively it is used. ROHC defines three operating modes, and a session can transition between them as conditions change. Compression always begins in U-mode and may be moved to O-mode or R-mode by feedback.

The distinction is really about how the compressor earns confidence to climb its state machine. In U-mode it can only guess — it sends an update several times and assumes at least one got through — which is why it leans on periodic refresh to self-heal. In O-mode the decompressor sends a short feedback element (piggybacked on reverse-direction packets or sent standalone) carrying an ACK when context is good or a NACK/STATIC-NACK when it needs the compressor to refresh dynamic or static state. In R-mode that feedback becomes mandatory for advancement, so the two ends are tightly locked and a single loss can never silently desynchronise them — at the cost of the extra reverse traffic. Feedback also carries the mode-transition requests themselves, so the network can migrate a flow from U to O to R without any RRC involvement.

CID, maxCID and Configuration in PDCP

A single PDCP entity can compress several flows at once — imagine voice plus a signalling flow on the same bearer. ROHC keeps them apart with a Context Identifier, the CID, prefixed to each compressed packet so the decompressor knows which context to apply. The highest usable value is maxCID, and it is configured, because it directly sizes how many parallel contexts each end must maintain (contexts run 0 through maxCID).

ROHC is a per-bearer decision. When the network sets up or reconfigures a DRB, the RRC pdcp-Config for that bearer carries the header-compression choice: headerCompression is either notUsed, or rohc with a list of permitted profiles, the maxCID, and the drb-ContinueROHC flag. A DRB carrying VoNR would enable profile 0x0001; a DRB carrying bulk TCP data would typically leave header compression off, because large payloads gain little and the context overhead is not worth it. QoS flows land on a DRB through the SDAP mapping, so the voice 5QI flow inherits ROHC because its DRB was configured for it.

NR adds a second, simpler compression scheme alongside ROHC: Ethernet Header Compression (EHC), introduced for the Ethernet PDU session type used in TSN and industrial deployments. Where ROHC targets IP/UDP/RTP, EHC compresses the Ethernet MAC header — destination and source MAC addresses, EtherType and any VLAN tags — which are static for the life of a flow. The full header is sent once to establish a context identified by an EHC context ID, and every packet thereafter carries only that short ID. It is configured independently of ROHC by ehc-DL and ehc-UL inside pdcp-Config, and the two can be enabled together on the same bearer.

Summary

ROHC is a PDCP transmit-side, per-DRB function that collapses the redundant IP/UDP/RTP header of small, frequent flows — above all VoNR — from 40–60 bytes to roughly 1–3 once a shared context is built. It works by classifying every header field as static (sent once), changing (sent as W-LSB or scaled-timestamp deltas) or inferred (never sent), so a steady-state packet carries little more than a truncated sequence number. It always runs before ciphering.

Each protocol stack has a numbered profile (0x0001 RTP/UDP/IP is the VoNR workhorse; 0x0000 is the always-present passthrough). The compressor climbs IR→FO→SO as confidence grows and drops back when fields change or a refresh is due; the decompressor mirrors this with NC→SC→FC, using per-header CRCs and staged degradation to stay "robust." The three operating modes (U/O/R) trade feedback overhead for recovery speed. Everything is configured in headerCompression inside pdcp-Config — permitted profiles, maxCID, and drb-ContinueROHC — with NR's EHC available alongside for Ethernet flows.

Quick Q&A