14  6LoWPAN Review: Performance Analysis

In 60 Seconds

6LoWPAN performance hinges on three quantifiable metrics: IPHC compression can double battery life by shrinking headers from 48 to 6 bytes (cutting total packet size by 52%), fragmentation reliability drops exponentially with fragment count (14 fragments at 95% per-fragment success yields only 49% delivery), and fragmentation tag collisions follow the birthday paradox in networks with many sensors.

14.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
  • Evaluate Protocol Trade-offs: Justify protocol selection among 6LoWPAN, Zigbee, and Thread for specific deployment scenarios

This review examines how 6LoWPAN performs in real-world conditions – throughput, latency, energy consumption, and reliability under different network sizes and traffic patterns. Understanding performance helps you set realistic expectations and optimize your IoT network for the best results.

“Let us crunch some real numbers!” said Max the Microcontroller, grabbing a calculator. “IPHC header compression is not just a nice feature – it can more than double your battery life. Without compression, a 48-byte header on an 8-byte sensor reading means 86 percent of your transmission is overhead. With IPHC, those headers shrink to 6 bytes, cutting your total packet nearly in half.”

Sammy the Sensor asked, “What about fragmentation? My messages are always small.” Max looked serious. “That is exactly the point – keep them small! If a packet needs 14 fragments, and each fragment has a 95 percent success rate, your overall delivery rate drops to just 49 percent. That means half your messages never arrive complete.”

“How is that possible?” asked Bella the Battery in alarm. Lila the LED explained the math. “It is like flipping a coin – one flip is usually heads, but flip 14 times and the chance of ALL heads drops dramatically. Each fragment is an independent gamble. Lose even one, and the whole message fails because the receiver cannot reassemble it.”

“The golden rule,” Max concluded, “is to keep your payloads under 80 bytes so they fit in a single 802.15.4 frame without fragmentation. If you absolutely must send larger data, implement application-level acknowledgment and retry, because link-layer fragmentation alone is not reliable enough for critical sensor data.”

Let’s quantify the compression and energy impact with real IoT numbers:

Frame Overhead Breakdown: \[ \begin{aligned} \text{Uncompressed:} \quad & 40\text{B (IPv6)} + 8\text{B (UDP)} + 8\text{B (payload)} + 25\text{B (802.15.4)} = 81\text{ bytes} \\ \text{Compressed (IPHC):} \quad & 2\text{B (IPHC)} + 4\text{B (NHC-UDP)} + 8\text{B (payload)} + 25\text{B (802.15.4)} = 39\text{ bytes} \\ \text{Compression ratio:} \quad & \frac{81 - 39}{81} \times 100\% = 51.9\% \text{ reduction} \end{aligned} \]

Energy Impact for CR2032 Battery (250 kbps, 20mA TX, 12 msg/hour): \[ \begin{aligned} \text{TX time per message:} \quad & t_{\text{tx}} = \frac{81 \times 8\text{ bits}}{250{,}000\text{ bps}} = 2.592\text{ ms (uncompressed)} \\ & t_{\text{tx}} = \frac{39 \times 8\text{ bits}}{250{,}000\text{ bps}} = 1.248\text{ ms (compressed)} \\ \text{Energy per message:} \quad & E = V \times I \times t = 3\text{V} \times 20\text{mA} \times 2.592\text{ms} = 0.156\text{ mJ (uncomp.)} \\ & E = 3\text{V} \times 20\text{mA} \times 1.248\text{ms} = 0.075\text{ mJ (comp.)} \\ \text{Daily energy:} \quad & E_{\text{day}} = 0.156\text{ mJ} \times 12 \times 24 = 44.93\text{ mJ (uncomp.)} \\ & E_{\text{day}} = 0.075\text{ mJ} \times 12 \times 24 = 21.60\text{ mJ (comp.)} \\ \text{Battery life ratio:} \quad & \frac{\text{Life}_{\text{comp}}}{\text{Life}_{\text{uncomp}}} = \frac{E_{\text{day,uncomp}}}{E_{\text{day,comp}}} = \frac{44.93}{21.60} \approx 2.08\text{x improvement} \\ & \text{Compression more than doubles battery life for this payload size} \end{aligned} \]

Fragmentation Reliability (exponential degradation): \[ P_{\text{delivery}} = p^n = (0.95)^{14} \approx 0.488 \text{ (48.8\% success for 14-fragment message)} \] where \(p = 0.95\) per-fragment success rate and \(n = 14\) fragments. IPHC compression keeps most messages in 1 fragment (\(n=1\), 95% success).

Explore how header compression and fragmentation affect battery life and delivery reliability.

14.2 Prerequisites

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

Key Concepts

  • Throughput Analysis: The process of measuring effective data transfer rate in a 6LoWPAN network accounting for header overhead, fragmentation, retransmissions, and contention.
  • Packet Delivery Ratio (PDR): The fraction of transmitted packets successfully received at the destination; a key performance metric for 6LoWPAN and wireless sensor networks.
  • Convergence Time: The time for RPL routing to stabilize after a topology change (node failure, addition, or movement); important for latency-sensitive applications.
  • Radio Duty Cycle: The fraction of time a radio is active (transmitting or receiving); lower duty cycles extend battery life but increase per-packet latency.
  • Compression Efficiency: The ratio of original to compressed packet size achieved by IPHC; high compression efficiency (>80%) is critical for throughput on 250 kbps 802.15.4 links.

14.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 4.4 years – a 2.1x improvement from TX energy alone!

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:          4.36 years

--- Improvement Summary ---
Bytes saved per message:   42 bytes (51.9%)
TX time reduction:         51.9%
Energy savings:            51.9%
Battery life improvement:  108% longer (2.26 additional 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 more than doubles - 2.1 years to 4.4 years with same battery (TX energy only)
  • Network scalability - 52% bandwidth savings allows more sensors per network
  • Cost savings - Fewer battery replacements (half as many 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
Diagram illustrating 6lowpan Comprehensiv26d83e6
Figure 14.1: IPHC header compression reducing 56 bytes to 14 bytes

14.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)
Diagram illustrating 6lowpan Comprehensiv304edc3
Figure 14.2: 6LoWPAN fragmentation and reassembly with lost fragment scenario

14.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
Step-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.

14.5.1 Knowledge Check: IPHC Address Mode Compression

14.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)
Step-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)

14.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)

14.7.1 Knowledge Check: Battery Life Impact of Compression

14.7.2 Knowledge Check: IPHC Bit-Field Decoding

14.7.3 Knowledge Check: Protocol Selection

Common Pitfalls

6LoWPAN networks may perform adequately at 10% channel utilization but fail badly at 30% due to collisions and retransmissions. Always evaluate performance at the expected peak load plus a safety margin.

Direct device-to-border-router performance numbers are optimistic — each additional hop halves effective throughput due to half-duplex relay constraints and adds latency. Test with the actual hop depth of your deployment.

RPL DODAG structures often create asymmetric routing — downlink paths may be suboptimal, adding extra hops compared to uplink. Measure both directions in performance analysis.

14.8 Summary

This chapter provided detailed performance analysis for 6LoWPAN deployments:

  • Header Compression Impact: IPHC compression more than doubles battery life (2.1 to 4.4 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

14.9 Knowledge Check

::

::

Scenario: After deploying a 6LoWPAN network, you notice border router CPU usage is 10x higher than expected and packet latency has doubled. Wireshark captures show most packets have 42-byte headers instead of the expected 6-byte compressed headers. Diagnose the root cause.

Wireshark Capture Evidence:

Frame 1: 6LoWPAN IPHC (SAM=00, DAM=00)
  Source:      2001:db8:1::212:4b00:1234:5678 (16 bytes inline)
  Destination: 2001:db8:1::1 (16 bytes inline)
  Total header: 2 (IPHC) + 16 (src) + 16 (dst) + 8 (UDP) = 42 bytes

Expected compression (SAM=11, DAM=11):
  Source:      [elided, derived from MAC]
  Destination: [elided, derived from MAC]
  Total header: 2 (IPHC) + 4 (NHC-UDP) = 6 bytes

Root cause identified: Sensor nodes use global addresses (2001:db8:1::/64) but NO compression context is configured. Without a shared context, IPHC cannot elide global prefixes.

The fix: Configure compression contexts in Contiki-NG project-conf.h on all nodes:

#define SICSLOWPAN_CONF_MAX_ADDR_CONTEXTS 1
#define SICSLOWPAN_CONF_ADDR_CONTEXT_0 {  \
    .prefix = {0x20, 0x01, 0x0d, 0xb8, 0x00, 0x01, 0x00, 0x00}, \
    .prefix_len = 64 }

Result: Headers compressed from 42 to 17 bytes (59% reduction). Border router CPU dropped from 85% to 12%, latency improved from 120ms to 60ms.

14.10 What’s Next

Chapter Focus
6LoWPAN Review: Quiz and Assessment Scenario-based questions covering addressing, routing, compression, and deployment decisions
Zigbee Fundamentals and Architecture Protocol stack, network roles (Coordinator, Router, End Device), and mesh formation
Thread Introduction How Thread builds on 6LoWPAN with native IPv6 mesh and Matter integration
Matter Overview The application layer that unifies Thread, Wi-Fi, and Ethernet for smart home interoperability
6LoWPAN Deployment Practical border router configuration, address planning, and production network design