%%{init: {'theme': 'base', 'themeVariables': {'primaryColor': '#2C3E50', 'primaryTextColor': '#fff', 'primaryBorderColor': '#16A085', 'lineColor': '#16A085', 'secondaryColor': '#E67E22', 'tertiaryColor': '#7F8C8D'}}}%%
flowchart TB
subgraph Byte1["Byte 1 (Bits 0-15)"]
direction LR
TF["TF<br/>Bits 0-2<br/>Traffic/Flow"]
NH["NH<br/>Bits 3-4<br/>Next Header"]
HLIM["HLIM<br/>Bit 5<br/>Hop Limit"]
CID["CID<br/>Bits 6-7<br/>Context ID"]
SAC["SAC<br/>Bits 8-9<br/>Src Addr Ctx"]
SAM["SAM<br/>Bits 10-11<br/>Src Addr Mode"]
M["M<br/>Bits 12-13<br/>Multicast"]
DAC["DAC<br/>Bits 14-15<br/>Dst Addr Ctx"]
end
subgraph Byte2["Byte 2+ (Bits 16-31, optional)"]
direction LR
DAM2["DAM<br/>Bits 16-17<br/>Dst Addr Mode"]
Rsvd["Rsvd<br/>Bits 18-19<br/>Reserved"]
CtxIDs["Context IDs<br/>Bits 20-31<br/>(optional)"]
end
Byte1 --> Byte2
style TF fill:#2C3E50,stroke:#16A085,color:#fff
style NH fill:#16A085,stroke:#2C3E50,color:#fff
style HLIM fill:#E67E22,stroke:#2C3E50,color:#fff
style CID fill:#7F8C8D,stroke:#2C3E50,color:#fff
style SAC fill:#2C3E50,stroke:#16A085,color:#fff
style SAM fill:#16A085,stroke:#2C3E50,color:#fff
style M fill:#E67E22,stroke:#2C3E50,color:#fff
style DAC fill:#7F8C8D,stroke:#2C3E50,color:#fff
style DAM2 fill:#2C3E50,stroke:#16A085,color:#fff
style Rsvd fill:#7F8C8D,stroke:#2C3E50,color:#fff
style CtxIDs fill:#16A085,stroke:#2C3E50,color:#fff
963 6LoWPAN Header Compression (IPHC)
963.1 Learning Objectives
By the end of this chapter, you will be able to:
- Explain IPHC Mechanics: Describe how IP Header Compression reduces IPv6 headers from 40 bytes to 2-7 bytes
- Analyze Compression Fields: Understand each IPHC field and when fields can be elided
- Calculate Compression Savings: Compute bandwidth and battery savings from header compression
- Implement Context-Based Compression: Configure compression contexts for optimal efficiency
- Apply NHC for UDP: Compress UDP headers using Next Header Compression
963.2 Prerequisites
Before diving into this chapter, you should be familiar with:
- 6LoWPAN Overview: Basic understanding of 6LoWPAN’s purpose
- IPv6 Fundamentals: IPv6 header structure and addressing
- IEEE 802.15.4 Fundamentals: Understanding frame size constraints
963.3 The IPHC Compression Algorithm
The IP Header Compression (IPHC) mechanism is the heart of 6LoWPAN efficiency. Here’s how it works at the bit level.
963.3.1 IPHC Base Header Format
The IPHC header is a minimum of 2 bytes that encodes which IPv6 fields are compressed:
963.3.2 IPHC Field Definitions
| Field | Values | Meaning | Bytes Saved |
|---|---|---|---|
| TF (Traffic Class/Flow) | 00=inline, 11=elided | Traffic Class and Flow Label handling | 0-4 bytes |
| NH (Next Header) | 0=inline, 1=compressed | UDP/TCP port compression using NHC | 0-1 byte |
| HLIM (Hop Limit) | 00=inline, 01=1, 10=64, 11=255 | Common hop limit values | 0-1 byte |
| SAM (Source Address Mode) | 00=128-bit inline, 11=fully elided | Source address compression level | 0-16 bytes |
| DAM (Dest Address Mode) | 00=128-bit inline, 11=fully elided | Destination address compression level | 0-16 bytes |
963.3.3 Best-Case Compression Example
Original IPv6 Header (40 bytes):
Version: 6 (4 bits)
Traffic Class: 0 (8 bits) -> ELIDED (TF=11)
Flow Label: 0 (20 bits) -> ELIDED (TF=11)
Payload Length: Derived from 802.15.4 frame -> ELIDED
Next Header: UDP (17) -> COMPRESSED via NHC (NH=1)
Hop Limit: 64 -> COMPRESSED to 2 bits (HLIM=10)
Source: fe80::0200:1234:5678:9abc -> ELIDED (derived from MAC, SAM=11)
Destination: fe80::0200:1234:5678:def0 -> ELIDED (derived from MAC, DAM=11)Resulting IPHC Header (2 bytes):
IPHC Dispatch: 01100000 00000000 (TF=11, NH=1, HLIM=10, SAM=11, DAM=11)
Total: 2 bytes instead of 40 bytes = 95% compression!963.4 Address Compression: The Biggest Win
The majority of compression savings come from address elision:
963.4.1 Link-Local Address Compression
Link-local addresses (fe80::/10) can be fully derived from the IEEE 802.15.4 MAC address:
Full address: fe80::0200:1234:5678:9abc (16 bytes)
With IPHC: 0 bytes elided! (derived from link-layer address)How it works: - Prefix fe80::/64 is well-known (link-local) - Interface ID (IID) is derived from the 802.15.4 extended address using EUI-64 mapping - Both sender and receiver can reconstruct the full address
963.4.2 Context-Based Compression
For global addresses, networks share compression contexts:
Context 0: 2001:db8:1234:5678::/64 (distributed by border router)
Full Address: 2001:db8:1234:5678::200:1234:5678:9abc
With Context 0:
- Prefix (64 bits) -> ELIDED (context lookup)
- IID (64 bits) -> 2 bytes (if matches MAC pattern)
Total: 2 bytes instead of 16 bytes
NoteWorked Example: Context-Based Address Compression
Scenario: A smart building has 50 temperature sensors on subnet 2001:db8:building3:floor2::/64. The border router distributes this prefix as Context 0.
Sensor IPv6 Address: 2001:db8:building3:floor2::sensor42
Without Context Compression:
Source: 2001:db8:building3:floor2::sensor42 (full 16 bytes inline)
Destination: 2001:db8:building3::server (full 16 bytes inline)
Total addresses: 32 bytesWith Context Compression:
Context 0 (shared): 2001:db8:building3::/48
Source: Context 0 + floor2::sensor42
- Context ID: 1 byte (index into shared context table)
- Suffix: ::sensor42 = 8 bytes (IID)
- Total: 9 bytes (vs 16 bytes)
Destination: Context 0 + ::server
- Context ID: 1 byte
- Suffix: ::server = 8 bytes
- Total: 9 bytes
Total addresses: 18 bytes (vs 32 bytes)
Savings: 14 bytes per packet (44% reduction on addresses alone)In a high-traffic scenario (100 sensors, 1 packet/minute, 24 hours):
Packets per day: 100 sensors x 1440 minutes = 144,000 packets
Bytes saved: 144,000 x 14 bytes = 2,016,000 bytes/day = 1.9 MB/day963.5 Next Header Compression (NHC) for UDP
Standard UDP header (8 bytes):
Source Port: 16 bits
Dest Port: 16 bits
Length: 16 bits -> ELIDED (derived)
Checksum: 16 bits -> ELIDED or inlineNHC UDP (4 bytes typical):
11110CPP (1 byte NHC dispatch)
C=1: Checksum inline
PP=11: Both ports compressed to 4 bits each
Source Port: 0xF0 + 4 bits (for ports 61616-61631, CoAP 5683 = 0xF0B3)
Dest Port: 0xF0 + 4 bits
Checksum: 16 bits
Total: 4 bytes963.5.1 Port Compression Modes
| Mode | Source Port | Dest Port | Bytes |
|---|---|---|---|
| PP=00 | 16 bits inline | 16 bits inline | 4 bytes |
| PP=01 | 0xF0 + 8 bits | 16 bits inline | 3 bytes |
| PP=10 | 16 bits inline | 0xF0 + 8 bits | 3 bytes |
| PP=11 | 0xF0B + 4 bits | 0xF0B + 4 bits | 1 byte |
CoAP ports (5683, 5684) compress well because they’re in the 0xF0Bx range.
963.6 Compression Effectiveness by Traffic Type
| Traffic Type | Typical Compression | Bytes Saved |
|---|---|---|
| Link-local to link-local | 40 -> 2 bytes | 38 bytes (95%) |
| Link-local to global (context) | 40 -> 9 bytes | 31 bytes (78%) |
| Global to global (no context) | 40 -> 18 bytes | 22 bytes (55%) |
| With UDP ports compressed | +8 -> +4 bytes | +4 bytes (50% of UDP header) |
| Best case (LL + UDP) | 48 -> 6 bytes | 42 bytes (88%) |
ImportantPitfall: Assuming IPHC Always Achieves Maximum Compression
The Trap: Assuming all 6LoWPAN traffic gets 95% header compression like the best-case examples.
Reality: Compression effectiveness varies dramatically based on addressing:
| Scenario | IPv6 Header Size | IPHC Result | Compression |
|---|---|---|---|
| Link-local to link-local | 40 bytes | 2 bytes | 95% |
| Global with context | 40 bytes | 7-10 bytes | 75-82% |
| Global without context | 40 bytes | 18-20 bytes | 50-55% |
| Multicast destination | 40 bytes | 10-14 bytes | 65-75% |
When Maximum Compression Fails: - Communicating with external servers (no shared context) - Using multicast addresses (can’t derive from L2) - Non-standard hop limits (not 1, 64, or 255) - Non-zero traffic class or flow labels (QoS marking)
The Fix: 1. Design for link-local when possible (sensor-to-gateway) 2. Configure compression contexts on border router for external prefixes 3. Use short-form addresses (::1, ::2) within the local subnet 4. Accept reduced compression for internet-bound traffic
963.7 Interactive Demo: Header Compression
963.8 Knowledge Check: IPHC Compression
963.9 Common Misconception: Compression Adds Latency
WarningCommon Misconception: “Header Compression Adds Processing Latency”
The Myth: “IPHC compression/decompression adds significant latency because the microcontroller must process each header field.”
The Reality: IPHC overhead is negligible compared to radio transmission time:
| Operation | Time | Comparison |
|---|---|---|
| IPHC compression | ~50-100 us | 0.1 ms |
| IPHC decompression | ~30-80 us | 0.08 ms |
| Radio TX (93 bytes) | 2.98 ms | 30x longer than compression |
| Radio TX (53 bytes) | 1.70 ms | Saves 1.28 ms per packet |
Net Effect: Compression saves 1.28 ms TX time while adding only 0.18 ms processing = 1.1 ms net savings per packet.
Why This Matters: 1. Radio TX consumes 27 mA vs 8 mA for CPU processing 2. Shorter packets mean less collision probability 3. Reduced airtime = more capacity for other nodes
Code Verification (Contiki-NG profiling):
// Measured on CC2538 @ 32 MHz
clock_time_t start = RTIMER_NOW();
sicslowpan_compress(&ipv6_hdr, &compressed_hdr);
clock_time_t elapsed = RTIMER_NOW() - start;
// Result: elapsed = 2-3 RTIMER ticks = 61-92 usConclusion: Always enable IPHC compression. The processing overhead is insignificant; the bandwidth and energy savings are substantial.
963.10 Summary
This chapter explored 6LoWPAN’s IP Header Compression (IPHC) mechanism:
- IPHC reduces IPv6 headers from 40 bytes to as little as 2 bytes by eliding predictable fields
- Address compression provides the biggest savings: link-local addresses can be fully derived from MAC addresses
- Context-based compression enables global address compression using shared prefix information
- NHC for UDP compresses transport headers from 8 bytes to 4 bytes
- Compression effectiveness varies from 95% (link-local) to 55% (global without context)
- Processing overhead is negligible compared to radio transmission time savings
963.11 What’s Next
Continue to:
- 6LoWPAN Fragmentation: How large packets are split across 802.15.4 frames
- 6LoWPAN Routing with RPL: Mesh networking and route optimization