972  6LoWPAN Review: Performance Analysis

972.1 Learning Objectives

By the end of this chapter, you will be able to:

  • Quantify Compression Impact: Calculate battery life improvements from IPHC header compression
  • Analyze Fragmentation Reliability: Determine success rates for multi-fragment transmissions
  • Decode IPHC Headers: Parse compression bit-fields for debugging
  • Calculate Tag Collision Risk: Assess fragmentation tag exhaustion in large networks
  • Select Appropriate Protocols: Compare 6LoWPAN vs Zigbee vs Thread for deployment scenarios

972.2 Prerequisites

Before working through this chapter, you should be familiar with:

972.3 Understanding Check: Header Compression Impact

Scenario: You’re designing a smart agriculture system with 100 soil moisture sensors spread across a 50-acre farm. Each sensor transmits an 8-byte reading (temperature value + timestamp) every 5 minutes using 6LoWPAN over IEEE 802.15.4. The sensors are battery-powered (CR2032 coin cells, 220mAh, 3V) and use UDP over IPv6 at 250 kbps with 20mA TX current.

Your manager asks: “Should we use standard IPv6/UDP or enable 6LoWPAN IPHC compression?”

  1. How much overhead do IPv6 (40 bytes) and UDP (8 bytes) headers add to each 8-byte payload?
  2. With IPHC compression, how small can these headers become (2 bytes IPv6 + 4 bytes UDP)?
  3. What’s the impact on bandwidth usage across all 100 sensors over a month?
  4. Most importantly: How does reduced TX time affect battery life?

Key Insight: For small payloads like sensor readings, header overhead dominates. A 48-byte header on an 8-byte payload means 86% overhead! IPHC compression reduces this to just 6 bytes (42% overhead), cutting transmission time in half. Less TX time = dramatically longer battery life because the radio is the biggest power consumer.

Without 6LoWPAN compression, the sensor battery lasts 2.1 years. With IPHC compression, it lasts 6.3 years - a 3x improvement!

Calculation Results:

======================================================================
6LoWPAN HEADER COMPRESSION - BATTERY LIFE ANALYSIS
======================================================================

Scenario:
  Payload: 8 bytes (temperature reading)
  Frequency: 12 messages/hour (every 5 minutes)
  Radio: 250 kbps, 20.0mA TX
  Battery: 220.0mAh CR2032

--- Without 6LoWPAN Compression ---
Packet structure:
  IPv6 header:       40 bytes
  UDP header:         8 bytes
  Payload:            8 bytes
  802.15.4 overhead: 25 bytes
  Total:             81 bytes
  Header overhead:   59.3%

Energy consumption:
  TX time per message:   2.592 ms
  Energy per message:    0.156 mJ
  Daily energy:          44.93 mJ
  Battery life:          2.10 years

--- With 6LoWPAN IPHC Compression ---
Packet structure:
  IPHC header:        2 bytes (compressed IPv6)
  NHC UDP header:     4 bytes (compressed UDP)
  Payload:            8 bytes
  802.15.4 overhead: 25 bytes
  Total:             39 bytes
  Header overhead:   15.4%

Energy consumption:
  TX time per message:   1.248 ms
  Energy per message:    0.075 mJ
  Daily energy:          21.63 mJ
  Battery life:          6.31 years

--- Improvement Summary ---
Bytes saved per message:   42 bytes (51.9%)
TX time reduction:         51.9%
Energy savings:            51.9%
Battery life improvement:  201% longer (4.2 years)

--- Network-Wide Impact (100 sensors) ---
Daily messages:            28,800
Without compression:       186.6 kilobits/day
With compression:          89.9 kilobits/day
Bandwidth saved:           96.8 kilobits/day
======================================================================

Key Insights:

  • Header compression is critical - 48 bytes of headers reduced to 6 bytes
  • Battery life triples - 2.1 years to 6.3 years with same battery
  • Network scalability - 52% bandwidth savings allows more sensors per network
  • Cost savings - Fewer battery replacements (3x fewer maintenance visits)

Why such dramatic improvement? - Small payload (8 bytes) makes header overhead dominate - 6LoWPAN IPHC compression reduces headers by 87.5% - Less TX time = less energy = longer battery life - Effect amplifies with frequent transmissions

%%{init: {'theme': 'base', 'themeVariables': { 'primaryColor': '#2C3E50', 'primaryTextColor': '#fff', 'primaryBorderColor': '#16A085', 'lineColor': '#16A085', 'secondaryColor': '#E67E22', 'tertiaryColor': '#7F8C8D', 'fontSize': '13px'}}}%%
flowchart LR
    subgraph BEFORE["Before IPHC (56 bytes)"]
        B1["IPv6 Header<br/>40 bytes<br/>(Version, TC, FL,<br/>Hop Limit, Src, Dst)"]
        B2["UDP Header<br/>8 bytes<br/>(Src Port, Dst Port,<br/>Length, Checksum)"]
        B3["Payload<br/>8 bytes"]
    end

    COMPRESS["IPHC Compression"]

    subgraph AFTER["After IPHC (14 bytes)"]
        A1["IPHC Header<br/>2 bytes<br/>(TF=3, HLIM=2,<br/>SAM=3, DAM=3)"]
        A2["NHC UDP<br/>4 bytes<br/>(Ports compressed<br/>to nibbles)"]
        A3["Payload<br/>8 bytes<br/>(unchanged)"]
    end

    BEFORE --> COMPRESS --> AFTER

    NOTE1["Compression Ratios:<br/>IPv6: 40->2 bytes (95%)<br/>UDP: 8->4 bytes (50%)<br/>Total: 56->14 bytes (75%)"]
    NOTE2["How?<br/>Addresses from MAC<br/>Port 5683->nibble<br/>Hop limit=64 (2 bits)<br/>Zero TC & FL elided"]

    AFTER -.-> NOTE1
    COMPRESS -.-> NOTE2

    style BEFORE fill:#E67E22,stroke:#2C3E50,stroke-width:2px,color:#fff
    style COMPRESS fill:#16A085,stroke:#2C3E50,stroke-width:3px,color:#fff
    style AFTER fill:#2C3E50,stroke:#16A085,stroke-width:2px,color:#fff
    style B1 fill:#fff3cd,stroke:#E67E22,stroke-width:1px,color:#000
    style B2 fill:#fff3cd,stroke:#E67E22,stroke-width:1px,color:#000
    style B3 fill:#fff3cd,stroke:#E67E22,stroke-width:1px,color:#000
    style A1 fill:#d4edda,stroke:#2C3E50,stroke-width:1px,color:#fff
    style A2 fill:#d4edda,stroke:#2C3E50,stroke-width:1px,color:#fff
    style A3 fill:#d4edda,stroke:#2C3E50,stroke-width:1px,color:#fff
    style NOTE1 fill:#e2e3e5,stroke:#16A085,stroke-width:1px,color:#000
    style NOTE2 fill:#e2e3e5,stroke:#16A085,stroke-width:1px,color:#000

Figure 972.1: IPHC header compression reducing 56 bytes to 14 bytes

972.4 Understanding Check: Fragmentation and Reliability

Scenario: You’re deploying an industrial monitoring system where 6LoWPAN sensors send diagnostic logs (1280-byte JSON documents) to a cloud server every hour. The wireless channel has 5% packet loss due to factory interference from heavy machinery. Your network engineer is concerned about reliability.

The physics: IEEE 802.15.4 frames max out at 127 bytes (102 bytes usable), so your 1280-byte packet requires 14 fragments.

  1. If each fragment has a 5% loss rate, what happens if ANY fragment is lost?
  2. With 14 fragments, what’s the probability ALL arrive successfully? (Hint: 0.95^14)
  3. Why is a single-frame packet (95% success) so much more reliable?
  4. What alternatives avoid fragmentation entirely?

Key Insight: Fragmentation amplifies packet loss. With 14 fragments at 95% per-fragment success, overall delivery drops to just 49% - you lose MORE packets than you deliver! This is because losing ANY fragment means the ENTIRE packet must be retransmitted after a 60-second timeout.

With fragmentation (14 fragments), success probability drops to 49%. Keeping packets under MTU (single frame) maintains 95% success rate - a 1.9x improvement!

================================================================================
6LoWPAN FRAGMENTATION RELIABILITY ANALYSIS
================================================================================

Channel Characteristics:
  Packet loss rate:   5.0%
  Frame success rate: 95.0%
  MTU (802.15.4):     102 bytes

Packet Size     Fragments    Success Rate    Retrans (99%)
--------------------------------------------------------------------------------
60              1            95.00%          0
100             2            90.25%          0
256             4            81.45%          0
512             7            69.83%          1
1280            14           48.77%          1

================================================================================
DETAILED ANALYSIS: 1280-byte IPv6 Packet
================================================================================

Fragmentation:
  Packet size:        1280 bytes (IPv6 minimum MTU)
  Fragments needed:   14
  Success probability: 48.77%
  Failure probability: 51.23%

Per-fragment analysis:
  Each fragment must succeed: 95.0%
  Probability all 14 succeed: (0.95)^14 = 0.4877

Expected transmission attempts: 2.05
  (On average, need 2.1 attempts for one success)

================================================================================
COMPARISON: Fragmented vs Single-Frame
================================================================================

Fragmented (1280 bytes):
  Fragments:          14
  Success rate:       48.77%
  Effective throughput: 624 bytes (accounting for failures)

Single-frame (96 bytes):
  Fragments:          1
  Success rate:       95.0%
  Effective throughput: 91 bytes

Single-frame is 1.9x more reliable!
Recommendation: Keep payloads under 96 bytes to avoid fragmentation

================================================================================
MITIGATION STRATEGIES
================================================================================

1. Avoid Fragmentation
  Method: Keep packets under 102 bytes
  Benefit: 1.9x better reliability
  Cost: Smaller payload per message

2. Application-Layer Segmentation
  Method: Split data at application layer, send separate CoAP messages
  Benefit: Each message independent, partial data still useful
  Cost: Application complexity

3. Reliable Transport (CoAP Confirmable)
  Method: Use CoAP CON messages with ACKs and retransmission
  Benefit: Automatic retry for failed messages
  Cost: Increased latency, energy consumption

4. Forward Error Correction (FEC)
  Method: Add redundant fragments (e.g., 14->16 fragments with 2 redundant)
  Benefit: Can recover from some lost fragments
  Cost: 14% bandwidth overhead

5. Improve Channel Quality
  Method: Add routers, change 802.15.4 channel, reduce interference
  Benefit: Reduces packet loss rate fundamentally
  Cost: Infrastructure changes
================================================================================

Key Takeaways:

  • Fragmentation compounds packet loss - 14 fragments at 95% success each = 49% overall
  • Single-frame is 1.9x more reliable - One loss point vs fourteen
  • Best strategy: Avoid fragmentation - Design protocols with small payloads
  • CoAP is ideal - Designed for small messages that fit in single frames
  • When fragmentation unavoidable - Use application-layer retransmission (CoAP CON)

Real-World Example: - Bad: Send 1KB JSON document in one message (requires 11 fragments, 52% success) - Good: Send individual sensor readings as separate CoAP messages (95% success each)

%%{init: {'theme': 'base', 'themeVariables': { 'primaryColor': '#2C3E50', 'primaryTextColor': '#fff', 'primaryBorderColor': '#16A085', 'lineColor': '#16A085', 'secondaryColor': '#E67E22', 'tertiaryColor': '#7F8C8D', 'fontSize': '13px'}}}%%
sequenceDiagram
    participant S as Sender
    participant N as Network
    participant R as Receiver

    Note over S,R: IPv6 Packet: 307 bytes (7-byte header + 300 payload)
    Note over S,R: 802.15.4 MTU: 102 bytes - Need 4 fragments

    S->>N: FRAG1 [Tag=0x1234, Size=307]<br/>Header (7) + Payload (91) = 102 bytes
    N->>R: Fragment 1
    Note over R: Buffer: 91 bytes

    S->>N: FRAGN [Tag=0x1234, Offset=91]<br/>Payload (97) = 102 bytes
    N->>R: Fragment 2
    Note over R: Buffer: 188 bytes

    S->>N: FRAGN [Tag=0x1234, Offset=188]<br/>Payload (97) = 102 bytes
    N--xR: Fragment 3 LOST
    Note over R: Waiting... timeout in 60s

    S->>N: FRAGN [Tag=0x1234, Offset=285]<br/>Payload (22) = 27 bytes
    N->>R: Fragment 4
    Note over R: Can't reassemble - missing Frag 3

    Note over R: Timeout! Discard all fragments
    Note over S: Must retransmit ENTIRE packet

    Note over S,R: Success Rate Analysis:<br/>Single frame: 95%<br/>4 fragments: (0.95)^4 = 81.5%<br/>14 fragments: (0.95)^14 = 49%

Figure 972.2: 6LoWPAN fragmentation and reassembly with lost fragment scenario

972.5 Worked Example: IPHC Compression Bit-Field Encoding

Scenario: You are debugging 6LoWPAN traffic in Wireshark and see a compressed packet with IPHC dispatch bytes 0x7A 0x33. Decode the compression settings and determine what address information is inline.

Given: - IPHC dispatch bytes: 0x7A 0x33 (hexadecimal) - Following inline bytes: 0x40 0x12 0x4B 0x00 0x0A 0xBC 0xDE 0xF1 - Destination 802.15.4 short address in MAC header: 0x0001

NoteStep-by-Step Solution

Step 1: Convert dispatch bytes to binary

0x7A = 0111 1010
0x33 = 0011 0011

Combined: 0111 1010 0011 0011

Step 2: Parse IPHC dispatch (first byte 0x7A)

Bits 7-5: 011 = IPHC dispatch identifier (required prefix)
Bits 4-3: 11 = TF (Traffic Class / Flow Label)
          11 = Both TC and FL elided (0 bytes inline)
Bit 2:    1  = NH (Next Header)
          1  = Next header compressed using NHC
Bits 1-0: 10 = HLIM (Hop Limit)
          10 = Hop Limit = 64 (common default, 0 bytes inline)

Step 3: Parse IPHC context/address byte (second byte 0x33)

Bit 7:    0  = CID (Context Identifier Extension)
          0  = No context extension byte follows
Bit 6:    0  = SAC (Source Address Compression)
          0  = Stateless compression (no context)
Bits 5-4: 11 = SAM (Source Address Mode)
          11 = 0 bytes inline (derived from encapsulating header)
Bit 3:    0  = M (Multicast)
          0  = Destination is unicast
Bit 2:    0  = DAC (Destination Address Compression)
          0  = Stateless compression
Bits 1-0: 11 = DAM (Destination Address Mode)
          11 = 0 bytes inline (derived from encapsulating header)

Step 4: Interpret compression results

Traffic Class: Elided (assumed 0)
Flow Label:    Elided (assumed 0)
Next Header:   Compressed via NHC (not inline)
Hop Limit:     64 (encoded in TF bits)
Source Addr:   Derived from 802.15.4 source MAC (fe80::0212:4bff:fe0a:bcde)
Dest Addr:     Derived from 802.15.4 dest short addr (fe80::ff:fe00:0001)

Result Summary:

Field Compression Inline Bytes Reconstructed Value
Version Implicit 0 6 (IPv6)
Traffic Class Elided 0 0x00
Flow Label Elided 0 0x00000
Payload Length From link 0 (calculated)
Next Header NHC 0 17 (UDP)
Hop Limit Encoded 0 64
Source Address IID inline 8 fe80::0212:4bff:fe0a:bcde
Dest Address From MAC 0 fe80::ff:fe00:1
Total IPHC 10 (vs 40 bytes uncompressed)

Key Insight: IPHC encoding uses a 2-byte base dispatch where each bit field controls whether data is inline or elided. The SAM/DAM fields (Source/Destination Address Mode) are the most impactful: mode 11 completely elides the address (derived from link layer), mode 01 includes only the 64-bit IID, and mode 00 includes the full 128-bit address.

972.6 Worked Example: Fragmentation Tag Collision Analysis

Scenario: A 6LoWPAN border router is receiving fragmented packets from 50 sensors. You observe intermittent packet corruption and need to diagnose whether fragmentation tag collision is the cause.

Given: - Active sensors: 50 nodes - Transmission rate: 1 fragmented packet every 5 minutes per sensor - Average fragments per packet: 3 (300-byte payloads) - Reassembly timeout: 60 seconds (default) - Datagram tag space: 16 bits (0-65535)

NoteStep-by-Step Solution

Step 1: Calculate concurrent active fragments

Transmission interval: 5 minutes = 300 seconds
Reassembly window: 60 seconds
Overlap ratio: 60 / 300 = 0.2 (20% of transmissions overlap)

Concurrent transmitting nodes: 50 * 0.2 = 10 nodes
Active fragment sets: 10 (each with unique datagram tag needed)

Step 2: Apply birthday paradox for collision probability

Birthday paradox formula: P(collision) = 1 - e^(-n^2 / 2m)

Where:
n = number of concurrent datagram tags = 10
m = tag space = 65,536

P(collision) = 1 - e^(-100 / 131,072)
P(collision) = 1 - e^(-0.000763)
P(collision) = 0.000763 = 0.076%

Step 3: Calculate collision probability over time

Transmissions per day: 50 nodes * (1440 min / 5 min) = 14,400
Tag assignments per day: 14,400

Daily collision windows: 14,400 * 0.2 = 2,880 overlapping periods
Per-window collision: 0.076%

P(at least one collision/day) = 1 - (1 - 0.00076)^2880
P(collision/day) = 1 - 0.111 = 88.9%

Step 4: Solution - MAC-seeded tags

// Contiki-NG: Use node ID + counter for unique tags
static uint16_t generate_unique_tag(void) {
    static uint8_t counter = 0;
    // Use last byte of link-layer address as high byte
    uint8_t node_id = linkaddr_node_addr.u8[LINKADDR_SIZE - 1];
    // Counter as low byte (wraps every 256 packets)
    return (node_id << 8) | (counter++);
}

// Result: 50 nodes * 256 tags = 12,800 unique combinations
// No collision possible within counter wrap period

Result Summary:

Configuration Collision/Day Corruption Risk
Default (60s timeout, random tags) 88.9% High
Reduced timeout (15s) 12.9% Medium
MAC-seeded tags 0% None
MAC-seeded + 15s timeout 0% None (fastest recovery)

972.7 Protocol Selection: Smart Building Scenario

Scenario: You’re the IoT architect for a new 20-story smart office building with 200 sensors (temperature, occupancy, lighting control) and 50 actuators (HVAC dampers, window blinds). The building owner has specific requirements:

Requirements: - IP connectivity for cloud integration (Azure IoT Hub) - Low power operation (5+ year battery life for sensors) - Mesh networking (multi-floor coverage, no single point of failure) - Secure communication (data encryption, device authentication) - Future-proof (should work with future smart home platforms) - Budget: $50,000 for initial deployment

Factor 6LoWPAN Zigbee Thread Winner
Native IPv6 Yes No (gateway) Yes 6LoWPAN/Thread
Cloud Integration Direct Via gateway Direct 6LoWPAN/Thread
Mesh Reliability Good Excellent Excellent Zigbee/Thread
Ecosystem Maturity 3/5 (2007+) 5/5 (2003+) 4/5 (2014+) Zigbee
Future-Proof 3/5 3/5 5/5 (Matter) Thread
Cost (200 nodes) $10K-15K $15K-20K $15K-25K 6LoWPAN
Interoperability 3/5 3/5 5/5 Thread

Recommendation: Thread with Matter

Why Thread wins for this scenario: - Native IPv6 (6LoWPAN-based) for direct cloud connectivity - Matter ecosystem (Google, Apple, Amazon) ensures future compatibility - Proven mesh reliability (learned from Zigbee’s 20+ years) - Simplified commissioning (QR code joining vs complex pairing) - Best long-term investment for new smart building deployments

When to choose alternatives: - Choose pure 6LoWPAN if building custom industrial system with CoAP - Choose Zigbee if using legacy building management systems (BACnet/Modbus gateways available) - Choose Bluetooth LE if budget is tight and star topology acceptable (but won’t scale to 200+ nodes)

972.8 Summary

This chapter provided detailed performance analysis for 6LoWPAN deployments:

  • Header Compression Impact: IPHC compression triples battery life (2.1 to 6.3 years) for small sensor payloads by reducing 48-byte headers to 6 bytes
  • Fragmentation Reliability: Success rate drops exponentially with fragment count - 14 fragments at 95% per-fragment = only 49% overall delivery
  • IPHC Bit-Field Decoding: The 2-byte dispatch encodes compression flags where SAM/DAM fields determine address handling
  • Tag Collision Analysis: Birthday paradox creates 88.9% daily collision probability with default settings; MAC-seeded tags eliminate risk
  • Protocol Selection: Thread with Matter provides best balance of IP connectivity, ecosystem support, and future-proofing for new deployments

Key Takeaways:

  • Compression benefits amplify with small payloads and frequent transmissions
  • Avoid fragmentation by keeping payloads under 80 bytes
  • Implement MAC-seeded tags for collision-free fragmentation in large networks
  • Choose Thread for new smart building deployments requiring IP connectivity

972.9 What’s Next

Continue to 6LoWPAN Review: Quiz and Assessment to test your understanding of 6LoWPAN concepts through scenario-based questions covering addressing, routing, compression, and deployment decisions.