Network Protocol Compression

Packet headers and payloads

Network data is divided into discrete units called packets. A packet contains part of the user data, called the payload, and control information in a header. Headers support addressing, sequencing, and interpretation of the payload. As data crosses protocol layers, each protocol can add its own header, creating a nested encapsulation structure.

In a connection using the TCP/IP suite, a packet can carry headers from several layers. Their fields depend on the protocols in use. Each header describes a different function, so removing a field without a shared reconstruction rule would change the meaning of the packet. Extension headers, options, and fragmentation can add further fields to the common case. The link layer can also add its own framing and integrity fields outside the IP packet:

• IP header (Internet Protocol): It contains the source and destination addresses, such as $192.168.1.10$. The minimum IPv4 header without options is 20 bytes, and options can increase it to 60 bytes. The IHL field gives the header length, allowing the receiver to locate the payload.
• TCP (Transmission Control Protocol) or UDP (User Datagram Protocol) header: Both contain source and destination ports. TCP also uses sequence numbers, acknowledgments, and control fields, while UDP has a simpler structure with length and checksum fields. The minimum TCP header is 20 bytes, and the UDP header is 8 bytes.
• Application-layer headers: Some protocols, such as RTP (Real-time Transport Protocol), add a header to a stream usually carried over UDP. RTP includes a sequence number and timestamp. The minimum RTP header is 12 bytes, although CSRC fields and extensions can make it longer.

Protocol overhead

The combined control information is called protocol overhead. For a large payload, such as a 5 MB image, 40 bytes of headers per packet are usually a small fraction of the data. With a small payload, the same number of bytes can substantially reduce effective throughput. The 40-byte value refers to the IPv4, UDP, and RTP example and excludes link-layer headers, tunnels, and options.

An example is Voice over IP (VoIP). Depending on the codec and packetization interval, a packet may carry 20 or 30 bytes of audio. For an example packet, the header calculation is:

With a 20-byte payload, the packet is 60 bytes, of which 40 bytes, about 67 percent, is overhead. On low-bandwidth or costly links this increases the required capacity and can limit the number of calls. Header compression reduces this part while retaining the information needed to reconstruct the header. The percentage is measured against the complete packet; relative to the payload alone, the overhead in this example is 200 percent.

Redundancy across packets

Within one communication stream, many header fields remain static or follow a known change rule. This applies to calls, video streams, and successive segments of a file. The compressor can therefore transmit initial values and differences from the preceding packet instead of repeating complete fields.

A VoIP call from User A to User B contains fields of the following types:

• Static fields: Within one flow, IP addresses and port numbers may remain unchanged. Sending them in every packet adds overhead without carrying new information.
• Predictably changing fields: The RTP sequence number increases by one for successive packets. The timestamp advances according to the number of samples and the packetization, so its increment can be predictable for a given stream.

A header compression scheme stores this information in shared compressor and decompressor state called a context. A context can contain static values, reference values, and rules for field changes. If it is damaged, it must be refreshed or initialized again. An example sequence is:

1. Initial packets may contain full headers. The receiver builds a local context with addresses, ports, and other fields.
2. After the context is established, the compressor sends a short header with a Context ID and a description of changes, such as a sequence number increment of one.
3. In selected profiles, the decompressor receives a short header of 1-3 bytes, retrieves the selected context, and updates the changing fields. With a valid context, it reconstructs the full header before passing the packet to the application. If the context is invalid, the short header can be rejected and a refresh packet may be required.

In profiles designed for similar flows, a 40-byte VoIP overhead can be reduced to 1-3 bytes. In this example, that is a reduction of more than 90 percent.

ROHC and context states

ROHC (Robust Header Compression) is a standards-defined framework for header compression on links with loss, errors, or packet reordering. Context management, feedback, and refresh mechanisms limit error propagation. Packets can carry control information and short CRCs that help detect an incorrect context update. Compression operates between defined compression points, while a full IP header may still be needed outside that link. The context is local to the compression channel and is not an Internet-wide replacement for protocol headers. It must be initialized at both endpoints and kept consistent when packets are reordered or lost.

ROHC is stateful. Profiles such as ROHC-RTP and ROHC-TCP define compression for particular header types. A context identifier can distinguish several flows on one channel. The framework uses three main states:

• Initialization and Refresh (IR) state: The compressor sends information needed to establish or refresh the decompressor's context.
• First Order (FO) state: After the context is established, compressed headers carry updates for changing fields or fields that require synchronization.
• Second Order (SO) state: For a stable flow, the compressor can send the smallest headers, describing predictable changes such as a sequence number.

Transitions depend on context validity and the profile. After a packet loss, the decompressor can report the problem through a feedback channel. The compressor can then use a state with more information and refresh the context. Without feedback, a profile can use periodic refresh packets. More frequent updates improve error recovery and reduce the possible byte savings.

6LoWPAN for constrained networks

Header compression is used for IPv6 traffic in the Internet of Things. IPv6 has a fixed base header of 40 bytes. The minimum IPv4 header is 20 bytes, while IPv6 provides 128-bit addresses and a different field layout.

On low-power devices, 40 bytes can be a large part of a packet carrying only a few bytes, such as a temperature reading. 6LoWPAN (IPv6 over Low-Power Wireless Personal Area Networks) defines IPv6 transmission formats for these networks, including header compression:

• Eliding common fields: Selected IPv6 and UDP fields can be omitted and inferred from the link layer or a shared context.
• Shared prefixes: An IPv6 prefix may be known throughout the network or stored in a context. It then does not need to be sent in every packet.
• Address derivation: In some configurations, an interface identifier can be derived from a link-layer address, such as a 48-bit MAC address after mapping or a 64-bit IEEE 802.15.4 identifier.

An IPv6 header and a UDP header total 48 bytes before compression. After LOWPAN_IPHC and UDP compression, the size depends on context, ports, checksum, and routing. The basic IPHC encoding can be 2 bytes in the best case, while a complete IPv6 and UDP representation also needs the remaining fields. With multi-hop routing, a compressed IPv6 header can be 7 bytes, and UDP uses a separate NHC format. There is no single final size for every 6LoWPAN packet. UDP NHC can compress selected port numbers into a short field, while ports outside the supported range are carried explicitly. The base IPHC encoding is 2 bytes and can receive an additional context-identifier byte. Stateless mode uses link-layer address information, while stateful mode stores prefixes in a context table. For ordinary IPv6 UDP traffic, a checksum is required. 6LoWPAN can elide it only when the upper layer authorizes that operation and an additional integrity mechanism is in place. Otherwise the field remains in the packet, and the receiver recomputes it when it has been elided. Fragmentation headers are handled separately when a compressed datagram does not fit into one IEEE 802.15.4 frame.