966 6LoWPAN Common Pitfalls and Troubleshooting

966.1 Learning Objectives

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

Identify Common Mistakes: Recognize the 7 most frequent 6LoWPAN deployment errors
Troubleshoot Scenarios: Diagnose and fix common 6LoWPAN problems
Apply Best Practices: Implement proven patterns to avoid pitfalls
Debug Network Issues: Use systematic approaches to identify root causes

966.2 Prerequisites

Before diving into this chapter, you should be familiar with:

6LoWPAN Overview: Basic understanding of 6LoWPAN
6LoWPAN Header Compression: IPHC compression
6LoWPAN Fragmentation: Fragmentation mechanics

966.3 The 7 Common 6LoWPAN Pitfalls

966.3.1 Pitfall 1: Assuming Fragmentation is “Free”

The Mistake: - Sending large JSON payloads (300+ bytes) and letting fragmentation handle it

Why It’s Bad: - Fragmentation amplifies packet loss (15 fragments x 5% loss each = 55% total failure rate) - Consumes 3-5x more battery due to retransmissions - No selective retransmission—one lost fragment = entire packet lost

The Fix: - Use binary encoding (CBOR instead of JSON) to reduce payload to ~50 bytes - If payload exceeds 60 bytes, use application-layer chunking (CoAP block-wise transfer) - Send chunks with selective retry instead of relying on fragmentation

Rule of Thumb: Stay under 60-byte payload to avoid fragmentation.

966.3.2 Pitfall 2: Ignoring Header Compression Context

The Mistake: - Using random IPv6 addresses that can’t be compressed

Why It’s Bad: - Random addresses can’t use context-based compression - 40-byte header becomes 20-byte compressed (vs. 2-7 bytes with proper addressing) - Wastes 13-18 bytes per packet = 20-30% battery drain

The Fix: - Use link-local addresses (fe80::/10) derived from MAC address - Compresses to 0 bytes (elided, derived from 802.15.4 address) - Use site-local addresses with shared context (e.g., 2001:db8:building3::sensor42) - Compresses to 7 bytes using context

Rule of Thumb: Use link-local (fe80::/10) or network-local addresses with shared context.

966.3.3 Pitfall 3: Forgetting Border Router MTU Handling

The Mistake: - Cloud server sending 1280-byte IPv6 packets directly to 6LoWPAN sensors

Why It’s Bad: - 1280-byte packet becomes 13+ fragments over 802.15.4 - Border router must fragment, but has limited buffer space (8-16 KB typical) - Can cause buffer overflow, dropped packets, or router crash

The Fix: - Server-side: Chunk large messages to 60-byte payloads (single-fragment size) - Border router: Advertise different MTUs to each side - Internet side: 1280 bytes (standard IPv6 minimum) - 6LoWPAN side: 127 bytes (actual 802.15.4 limit) - Use application-layer protocols (CoAP block-wise transfer) for large data

Rule of Thumb: Design application protocols to send small messages bidirectionally.

966.3.4 Pitfall 4: Multicast with Fragmentation

The Mistake: - Multicasting large firmware updates (200+ bytes) to all nodes

Why It’s Bad: - Each receiver loses different fragments - No way to retransmit (multicast has no ACKs) - 100% packet loss with fragmentation + multicast

The Fix: - Multicast only for tiny messages (<60 bytes, no fragmentation) - Use for: Notifications, discovery announcements - Unicast for everything else - Send to each node individually with ACKs and retries - Hybrid approach: Multicast notification (small), unicast data blocks (large) - Example: SUIT firmware update (multicast manifest, unicast chunks)

Rule of Thumb: NEVER fragment multicast. Use multicast only for <60-byte notifications.

966.3.5 Pitfall 5: Not Implementing Reassembly Timeout

The Mistake:

// BAD: No reassembly timeout
void handle_fragment(fragment_t *frag) {
    store_in_buffer(frag);
    if (all_fragments_received()) {
        reassemble_and_deliver();
    }
    // What if fragment never arrives? Memory leak!
}

Why It’s Bad: - Incomplete fragments accumulate in RAM forever - 8 KB RAM x 60-second timeout x 10 incomplete packets = RAM exhausted - System crashes when buffer space runs out

The Fix:

// GOOD: Implement RFC 4944 60-second timeout
void handle_fragment(fragment_t *frag) {
    reassembly_ctx_t *ctx = get_reassembly_context(frag->datagram_tag);
    ctx->last_update = current_time();
    ctx->timeout = 60000;  // 60 seconds (RFC 4944)

    store_in_buffer(frag, ctx);

    if (all_fragments_received(ctx)) {
        reassemble_and_deliver(ctx);
        free_context(ctx);
    }
}

// Periodic cleanup
void cleanup_stale_reassembly() {
    for (ctx in reassembly_contexts) {
        if (current_time() - ctx->last_update > ctx->timeout) {
            free_fragments(ctx);
            free_context(ctx);  // Prevent memory leak
        }
    }
}

Rule of Thumb: Always implement 60-second reassembly timeout per RFC 4944.

966.3.6 Pitfall 6: Incorrect RPL Parent Selection

The Mistake:

// BAD: Selecting parent based only on RSSI
rpl_parent_t *select_parent(candidates[]) {
    return max(candidates, key=rssi);  // Strongest signal
}

Why It’s Bad: - Strongest RSSI does not equal best path to border router - Ignores hop count, ETX, congestion - Creates routing loops or suboptimal paths

The Fix:

// GOOD: Use ETX (Expected Transmission Count) + rank
rpl_parent_t *select_parent(candidates[]) {
    best = NULL;
    min_cost = INFINITY;

    for (candidate in candidates) {
        // ETX = 1 / (PRR_forward x PRR_reverse)
        etx = calculate_etx(candidate);

        // Total path cost = parent_rank + (etx x rank_increase)
        path_cost = candidate.rank + (etx * RANK_INCREASE);

        if (path_cost < min_cost) {
            min_cost = path_cost;
            best = candidate;
        }
    }
    return best;
}

Rule of Thumb: Use ETX-based metrics (RFC 6719) for parent selection, not just RSSI.

966.3.7 Pitfall 7: Forgetting to Enable Header Compression

The Mistake:

// BAD: Using uncompressed IPv6 headers
lowpan_config_t config = {
    .iphc_enabled = false,  // Oops! No compression
    .fragmentation = true
};

Why It’s Bad: - 40-byte IPv6 header + 8-byte UDP = 48 bytes overhead - Only 54 bytes left for payload in 102-byte frame - 47% overhead vs. 7% with IPHC - Battery life reduced by ~40%

The Fix:

// GOOD: Always enable IPHC compression
lowpan_config_t config = {
    .iphc_enabled = true,           // Enable IPHC (RFC 6282)
    .context_compression = true,    // Use context-based addressing
    .nhc_enabled = true,            // Next Header Compression (UDP/TCP)
    .fragmentation = true
};

// Configure compression context for your network
lowpan_context_t ctx = {
    .id = 0,
    .prefix = "2001:db8:building3::/64",
    .lifetime = 65535  // ~18 hours
};
lowpan_add_context(&ctx);

Rule of Thumb: IPHC compression should ALWAYS be enabled—it’s the whole point of 6LoWPAN!

966.4 Quick Reference Card

Mistake	Impact	Fix	Priority
Large payloads with fragmentation	3-5x battery drain	Keep payload <60 bytes	HIGH
Poor address choice	+13-18 bytes/packet	Use link-local/context addresses	MEDIUM
Ignoring MTU at border router	Packet loss, crashes	Chunk large messages	HIGH
Multicast + fragmentation	100% loss	Multicast <60 bytes only	HIGH
No reassembly timeout	Memory leak	60-second timeout (RFC 4944)	MEDIUM
RSSI-based parent selection	Routing loops	Use ETX-based metrics	MEDIUM
Disabled header compression	40% battery waste	Always enable IPHC	HIGH

Golden Rule: 6LoWPAN is designed for small, frequent messages (20-60 bytes). If you need to send large data, rethink your architecture!

966.5 Troubleshooting Scenarios

966.5.1 What If You Send a 1500-Byte Packet?

Scenario: A camera sensor tries to send a 1500-byte thumbnail image over 6LoWPAN.

What Happens:

Fragmentation Explosion: 1500 bytes / 102 bytes = 15 fragments
Reliability Disaster:

Per-Fragment Success	Overall Packet Success
99% (excellent link)	0.99^15 = 86%
95% (good link)	0.95^15 = 46%
90% (typical link)	0.90^15 = 21%
85% (poor link)	0.85^15 = 9%

Battery Drain:

Successful transmission (1 attempt): 15 frames x 5 mA x 4 ms = 0.3 mJ

Failed transmission (avg 4 retries):
  15 frames x 5 retries x 5 mA x 4 ms = 1.5 mJ
  (5x battery drain!)

Solutions:

Application-Layer Segmentation: Break image into 50-byte CoAP blocks with selective retry
Border Router Offload: Sensor sends trigger, border router fetches full image
Different Protocol: Use Wi-Fi for camera sensors

966.5.2 What If Headers Aren’t Compressed?

Impact of Uncompressed 40-byte IPv6 header in 102-byte frame: - Only 62 bytes left for payload - 64% overhead (vs. 7% with compression) - Battery life reduced by 45% - Network capacity reduced by 40%

966.5.3 What If Fragmentation Fails Mid-Transfer?

Scenario: Fragment #8 of 15 is lost due to interference

Result: - Receiver holds fragments 1-7 and 9-15 in buffer for 60 seconds - All 14 fragments discarded when timeout expires - Sender must retransmit all 15 fragments again - No selective retransmission at this layer!

966.6 The 6LoWPAN Translator Analogy

6LoWPAN is Like a Simultaneous Translator at a Conference

Imagine you’re at an international IoT conference where two groups need to communicate:

The Internet Delegation speaks “Big Packet Language”: - Uses long, detailed sentences (1280-byte minimum messages) - Every message starts with a 40-word introduction (IPv6 header) - Expects everyone to understand complex diplomatic protocols

The Sensor Nation speaks “Tiny Radio Language”: - Can only write short notes on index cards (127-byte frames max) - Has limited paper and ink (battery power) - Uses simple, efficient communication

6LoWPAN is the Translator sitting between them: 1. Compression (Internet to Sensor): Takes the 40-word introduction and abbreviates it to just 2-7 words 2. Fragmentation (for long messages): Splits messages across multiple index cards numbered 1/5, 2/5, etc. 3. Reassembly (Sensor to Internet): Collects all cards and reconstructs the full message 4. Address Translation: Converts full postal addresses into short nicknames

Real-world impact: A temperature sensor can say “I’m at 23.5 degrees” using just 15 bytes total instead of needing 70+ bytes for the full Internet-style message!

966.7 Summary

This chapter covered the most common 6LoWPAN deployment pitfalls:

Fragmentation is expensive: Keep payloads under 60 bytes whenever possible
Address design matters: Use link-local or context-based addresses for maximum compression
Border routers need MTU handling: Design for small bidirectional messages
Never fragment multicast: Use multicast only for tiny notifications
Implement timeouts: RFC 4944 specifies 60-second reassembly timeout
Use ETX for routing: RSSI alone is insufficient for parent selection
Always enable IPHC: Header compression is the core value of 6LoWPAN

966.8 What’s Next

Continue to:

6LoWPAN Lab Simulation: Hands-on Wokwi simulation
6LoWPAN Hands-on and Security: Security and implementation