Robust Header Compression

Description

Robust Header Compression (ROHC) is a standardized framework defined initially in IETF RFC 3095 and extensively profiled and adopted by 3GPP for cellular networks from Release 5 onwards. It is a lossless compression protocol designed to compress the headers of IP-based traffic streams (flows) before transmission over the radio interface. The protocol is implemented in the Packet Data Convergence Protocol (PDCP) layer in 3GPP stacks (UTRAN, E-UTRAN, NG-RAN). ROHC identifies fields in protocol headers that are constant, predictable (like sequentially incrementing sequence numbers), or inferable from other layers, and suppresses their transmission after initial synchronization.

The architecture involves a compressor (in the transmitting node, e.g., UE or gNB) and a decompressor (in the receiving node). They maintain synchronized compression contexts, which are sets of information about the header fields of the packet flow. ROHC operates in several states (modes) to trade off efficiency for robustness: Initialization and Refresh (IR) state, where full headers are sent to establish context; First Order (FO) state, where dynamic fields are compressed using patterns; and Second Order (SO) state, where only a small Context Identifier (CID) and cyclic redundancy check (CRC) are sent for very high compression. The protocol uses multiple feedback channels (acknowledged, unacknowledged, and bidirectional optimistic modes) to handle errors and ensure context synchronization even over lossy radio links.

How it works for a typical VoIP (RTP/UDP/IP) packet: The first packet is sent with a full header (IR packet). The decompressor learns the static fields (IP addresses, ports) and the changing pattern of dynamic fields (RTP sequence number, timestamp). For the next packet, the compressor sends a compressed header containing a small CID and encoded differences (deltas) for the dynamic fields. In the most efficient state, it may send only a 1-byte header with a CRC. If the decompressor detects an error via CRC or sequence number gap, it can request a context update via feedback or wait for a periodic refresh. ROHC defines specific profiles for different protocol stacks (e.g., Profile 0x0001 for RTP/UDP/IP, Profile 0x0002 for UDP/IP, Profile 0x0006 for TCP/IP). 3GPP specifications detail how ROHC is integrated into the PDCP layer, including context management during handover and bearer setup.

Purpose & Motivation

ROHC was created to solve the severe inefficiency of transmitting full IP headers over low-bandwidth, high-latency, and error-prone wireless links. In the early 2000s, as 3G networks began carrying IP traffic, it became apparent that the overhead of IPv4 (20 bytes) or IPv6 (40 bytes), plus UDP (8 bytes) and RTP (12 bytes), could be larger than the voice payload itself for VoIP. This wasted scarce radio spectrum and increased packet delay. Pre-ROHC solutions were less robust to packet loss and had limited compression efficiency.

The motivation for standardizing ROHC within 3GPP was to enable efficient support of real-time services like Voice over IP (VoIP) and video streaming over cellular networks. It directly addresses the problem of low spectral efficiency for small-packet, delay-sensitive traffic. By reducing header sizes from 40-60 bytes to as little as 1-4 bytes, ROHC can double or triple the effective capacity for voice calls. Its robustness to packet loss—a key design goal—ensures reliable decompression even when radio link conditions degrade, preventing context desynchronization which would cause catastrophic failure. Its adoption from Release 5 (HSDPA) through to 5G NR demonstrates its enduring value in conserving radio resources and reducing latency, which is critical for network capacity and user experience.

Key Features

• Framework for compressing IP, UDP, RTP, ESP, and TCP headers
• Operates with multiple compression states (IR, FO, SO) for efficiency/robustness trade-off
• Uses compression contexts synchronized between compressor and decompressor
• Supports multiple robustness modes (Unidirectional, Bidirectional Optimistic, Bidirectional Reliable)
• Defines specific profiles for different protocol stack combinations
• Integrated into the 3GPP PDCP layer for operation over Uu and radio interfaces

Evolution Across Releases

Defining Specifications