15 6LoWPAN Review: Quiz and Assessment
Quiz mastery targets are easiest to plan with threshold math:
\[ C_{\text{target}} = \left\lceil 0.8 \times N_{\text{questions}} \right\rceil \]
Worked example: For a 15-question quiz, target correct answers are \(\lceil 0.8 \times 15 \rceil = 12\). If a learner moves from 8/15 to 12/15, score rises from 53.3% to 80%, crossing mastery with four additional correct answers.
15.1 Learning Objectives
By the end of this chapter, you will be able to:
- Calculate Header Overhead: Compute IPHC compression ratios and determine compressed header sizes for various addressing modes
- Diagnose Fragmentation Trade-offs: Evaluate when 6LoWPAN fragmentation degrades reliability and justify payload size decisions
- Compare Forwarding Strategies: Contrast mesh-under and route-over forwarding in terms of per-hop processing, memory, and IP integration
- Design Border Router Architectures: Specify 6LBR placement and prefix advertisement strategies for multi-floor sensor deployments
This quiz tests your understanding of 6LoWPAN concepts – header compression, fragmentation, routing, and deployment. Each question includes explanations to help you learn from any mistakes. Use it as a study tool to confirm your knowledge before moving on to more advanced wireless topics.
“Quiz time!” announced Max the Microcontroller, shuffling a stack of cards. “We have covered the three pillars of 6LoWPAN: header compression, fragmentation, and RPL routing. Let us see if you really understand how they work together.”
Sammy the Sensor was nervous. “What is the most important thing to remember?” Max held up one finger. “The 80-byte rule. Keep your application payloads under 80 bytes and you avoid fragmentation entirely. That one rule solves more 6LoWPAN reliability problems than anything else.”
“And remember the compression math!” added Lila the LED. “Without IPHC, IPv6 plus UDP headers eat 48 bytes of your 102-byte payload – that is 47 percent overhead. With full IPHC compression, those same headers shrink to just 6 bytes. That is the difference between a sensor that lasts 2 years and one that lasts 6 years on the same battery.”
Bella the Battery shared her study tip. “When answering questions, think about the trade-offs. More compression means less overhead but more processing. Fragmentation means larger payloads but lower reliability. Mesh routing means more coverage but more latency. Every 6LoWPAN design decision is a balance between competing goals.”
15.2 Prerequisites
Before taking this assessment, you should have completed:
- 6LoWPAN Review: Architecture: Protocol stack and border router design
- 6LoWPAN Review: Labs: Hands-on network setup
- 6LoWPAN Review: Analysis: Performance calculations and protocol selection
15.3 Knowledge Check
Test your understanding of 6LoWPAN concepts through these scenario-based questions.
15.4 Knowledge Check: Fragmentation Reliability
15.4.1 Worked Example: Smart Building 6LoWPAN Network Design
Scenario: You’re deploying 800 temperature/humidity sensors across a 10-story office building (80 sensors per floor). Each sensor sends a 12-byte reading every 5 minutes. Design the 6LoWPAN network and calculate header overhead, fragmentation requirements, and battery life.
Given:
- Sensor payload: 12 bytes (temperature + humidity + timestamp)
- Transmission interval: 5 minutes (300 seconds)
- Network: Link-local IPv6, UDP transport
- 802.15.4 constraints: 127-byte max frame, 102-byte max payload
- Battery: CR2032 (220 mAh), sensor MCU draws 5 µA sleep, 15 mA active (20 ms per transmission)
Step 1: Calculate IPHC compression savings
Without compression: - IPv6 header: 40 bytes - UDP header: 8 bytes - Application payload: 12 bytes - Total: 60 bytes
With IPHC compression (link-local, addresses from MAC): - IPHC base (tf=3, nh=1, hlim=2): 2 bytes - UDP NHC header: 4 bytes (ports compressed) - Application payload: 12 bytes - Total: 18 bytes
Compression ratio: (60-18)/60 = 70% overhead reduction
Step 2: Check fragmentation requirement
Total packet size: 18 bytes < 102-byte 802.15.4 payload → No fragmentation needed
This is critical: adding fragmentation would require 4-5 bytes per fragment plus reliability overhead. By keeping the compressed packet under 80 bytes, we avoid multi-frame transmission entirely.
Step 3: Calculate battery life
Per transmission energy: - Active time: 20 ms - Current: 15 mA - Energy: 15 mA × 20 ms = 0.3 mAh/transmission (simplified)
Sleep energy (5 minutes between transmissions): - Sleep time: 300 seconds - Current: 5 µA - Energy: 5 µA × 300 s = 0.417 µAh = 0.000417 mAh
Transmissions per day: (24 × 60) / 5 = 288 transmissions Daily energy: (288 × 0.3 mAh) + (daily sleep) ≈ 86.4 mAh + negligible sleep
Battery capacity: 220 mAh Battery life: 220 / 86.4 = 2.5 years
Step 4: Network architecture
With 80 sensors per floor: - Border router per floor (10 total) to avoid mesh scaling issues - Routers: 8-10 mains-powered devices per floor (light switches, powered sensors) - Mesh depth: Maximum 4 hops from sensor to border router - Total network: 800 sensors + 100 routers + 10 border routers
Key Design Decision: Using IPHC compression to keep packets under 80 bytes avoids fragmentation, which would: - Increase latency by 50-200 ms per fragment - Reduce reliability (each fragment must succeed) - Consume 2-3× more battery power - Add 19 bytes of fragmentation headers for a 300-byte packet
Result: Proper 6LoWPAN header compression extends battery life from months to years, avoids fragmentation overhead, and enables scalable multi-floor deployment with reliable mesh routing.
15.5 Knowledge Check: IPHC Best-Case Compression
15.5.1 Knowledge Check: Route-Over vs Mesh-Under
15.6 Key Concepts Reference
- 6LoWPAN Adaptation Layer: Protocol enabling IPv6 on 802.15.4 networks through header compression and fragmentation
- IPHC (IP Header Compression): Reduces IPv6 header from 40 bytes to 2-7 bytes
- Fragmentation: Handles IPv6’s 1280-byte MTU over 127-byte 802.15.4 frames
- Link-Local Addresses: Automatic address assignment without DHCP
- Global IPv6 Addressing: Each sensor gets unique internet address
- RPL (Routing Protocol for Low-Power Networks): Optimized mesh routing for constrained devices
- Neighbor Discovery Optimization: Simplified NDP for low-power operation
15.7 Visual Reference Gallery
This diagram illustrates how 6LoWPAN enables IPv6 connectivity on constrained wireless networks through header compression and fragmentation.
IPHC compression achieves 83-95% reduction in IPv6 header size, critical for maximizing payload capacity in 127-byte 802.15.4 frames.
Fragmentation enables transmission of IPv6’s minimum 1280-byte MTU across 102-byte IEEE 802.15.4 payloads.
Mesh-under routing provides multi-hop connectivity at Layer 2, enabling the entire 6LoWPAN network to appear as a single IPv6 subnet.
The packet structure shows how 6LoWPAN headers identify compression and fragmentation modes for efficient IPv6 encapsulation.
Routing design choices between mesh-under (Layer 2) and route-over (Layer 3 with RPL) impact scalability, latency, and memory requirements.
15.8 Additional Resources
Books:
- “6LoWPAN: The Wireless Embedded Internet” by Zach Shelby & Carsten Bormann
- “Building Wireless Sensor Networks” by Robert Faludi
Videos:
- See the course-wide Video Gallery: Video Hub
Tools:
- Contiki-NG: Modern IoT OS with full 6LoWPAN stack
- RIOT OS: Real-time OS for IoT with 6LoWPAN support
- Wireshark: Protocol analyzer with 6LoWPAN dissector
- Cooja: Network simulator for 6LoWPAN
Standards:
- RFC 4944 - 6LoWPAN Format
- RFC 6282 - IPHC Compression
- RFC 6775 - Neighbor Discovery
- RFC 6550 - RPL Routing
Hardware:
- Zolertia RE-Mote: Industrial-grade 6LoWPAN development board
- OpenMote: Research platform for 802.15.4
- nRF52840: Nordic Semiconductor (Thread/6LoWPAN capable)
- CC2650: Texas Instruments (802.15.4 radio)
Deep Dives:
- 6LoWPAN Fundamentals - Core concepts and architecture
- 6LoWPAN Hands-on - Implementation and security
Related Protocols:
- RPL Routing - Mesh routing for 6LoWPAN
- CoAP Protocol - Application protocol over 6LoWPAN
- Thread Fundamentals - Commercial 6LoWPAN stack
Comparisons:
- IoT Protocols Review - Cross-protocol comparison
- Zigbee vs Thread - IEEE 802.15.4 alternatives
Learning:
- Quizzes Hub - Test your knowledge
- Simulations Hub - Network simulation tools
15.9 Summary
This comprehensive review consolidated practical 6LoWPAN implementation knowledge:
- Lab-based learning demonstrated complete 6LoWPAN network setup using Contiki-NG, including border router configuration with tunslip6, CoAP sensor implementation, and Python client applications
- Header compression analysis showed that link-local UDP traffic achieves 95% compression (40 bytes to 2 bytes IPv6 header), while battery life improves 3x from 2.1 to 6.3 years when using IPHC compression on small 8-byte payloads
- Fragmentation reliability calculations revealed that 14 fragments at 95% per-fragment success equals only 49% overall delivery, making single-frame transmission 1.9x more reliable
- Protocol comparison framework evaluated 6LoWPAN vs Zigbee vs Thread, with Thread+Matter emerging as the best choice for new smart home deployments
- Quiz validation covered critical concepts including addressing modes, tree addressing, MAC-layer retransmission probability, and duty cycle impacts
Key Takeaways:
- Enables IPv6 on IEEE 802.15.4 low-power wireless
- Compresses IPv6 headers from 40 bytes to 2-7 bytes (95% reduction)
- Fragments large IPv6 packets across small 802.15.4 frames
- Uses RPL for efficient mesh routing
- Foundation for Thread and other IP-based IoT protocols
- Enables end-to-end IP connectivity (sensors have global IPv6 addresses)
- Standard protocols: CoAP, MQTT, HTTP work directly
15.10 What’s Next
| Chapter | Focus |
|---|---|
| Zigbee Fundamentals and Architecture | Higher-level IEEE 802.15.4 protocol with application profiles and Zigbee Cluster Library |
| Thread Network Architecture | Commercial 6LoWPAN stack with mesh networking, border routers, and Matter integration |
| 6LoWPAN Deployment | Real-world deployment planning, border router placement, and scaling strategies |
| 6LoWPAN Common Pitfalls | Avoiding fragmentation, compression misconfigurations, and routing table overflow |
| Thread Protocol Comparison | Side-by-side evaluation of Thread, Zigbee, and other 802.15.4 protocols |