Test your understanding of 6LoWPAN concepts through these scenario-based questions.
NoteQuiz 1: Header Compression and Fragmentation
Question 1: A smart building project needs to connect 500 temperature sensors to the internet. Without 6LoWPAN header compression, what percentage of each 102-byte IEEE 802.15.4 payload would be consumed by IPv6 (40 bytes) and UDP (8 bytes) headers?
Explanation: Without compression, IPv6 header (40 bytes) + UDP header (8 bytes) = 48 bytes overhead. IEEE 802.15.4 max payload is 102 bytes. This leaves only 54 bytes for sensor data (temperature reading). The overhead ratio is 48/102 = 47%! With 6LoWPAN compression (6-11 bytes), overhead drops to just 6-11%, allowing 91-96 bytes for data - nearly doubling usable payload. This is why 6LoWPAN is essential for constrained IoT devices.
Question 2: An industrial IoT deployment uses 6LoWPAN with link-local IPv6 addresses (fe80::/64 prefix) where addresses are derived from IEEE 802.15.4 MAC addresses. How many bytes can be saved per packet when both source and destination use stateless address compression with fully elided addresses (SAM=3, DAM=3)?
Explanation: Each IPv6 address is 128 bits (16 bytes). When using link-local addresses derived from MAC addresses, 6LoWPAN can fully elide both source and destination addresses since they can be reconstructed from the IEEE 802.15.4 MAC frame. This saves 16 + 16 = 32 bytes. The IPHC header uses just 2 bytes to encode the compression flags, resulting in a compressed header of ~6-7 bytes instead of 40 bytes - an 85% reduction!
Question 3: A sensor needs to send a 300-byte CoAP message over 6LoWPAN. IEEE 802.15.4 max payload is 102 bytes. After 6LoWPAN header compression reduces the IPv6/UDP header to 7 bytes, how many IEEE 802.15.4 frames are needed?
Explanation: Total packet = 7 (compressed header) + 300 (payload) = 307 bytes. Frame 1 gets 102-4 (FRAG1) = 98 bytes, which includes the 7-byte header + 91 bytes data. Frames 2-4 each get 102-5 (FRAGN) = 97 bytes data. Total data: 91 + 97 + 97 + 22 = 307 bytes across 4 frames. Overhead: 4+5+5+5 = 19 bytes fragmentation headers.
Question 4: A 6LoWPAN network uses RPL (Routing Protocol for Low-power networks) with a DODAG structure. A leaf node 4 hops from the root wants to send data to another leaf node 3 hops from the root (different branches). What is the most likely routing path?
Explanation: In RPL storing mode (most common for constrained networks), nodes maintain downward routes but not peer routes. Traffic from leaf A to leaf B must flow: (1) UP the DODAG to root via parent links (4 hops), then (2) DOWN via the optimized path to destination (3 hops) = 7 total hops. While inefficient, this trade-off minimizes routing table size on constrained devices.
Question 5: A 6LoWPAN border router connects a building’s sensor network (fe80::/64 link-local) to the corporate IPv6 network (2001:db8::/32). What is the border router’s primary function?
Explanation: The 6LoWPAN Border Router (6LBR) is the gateway between the low-power wireless network and standard IPv6 networks. Key functions: (1) Header transformation: Receives compressed 6LoWPAN packets, decompresses to full IPv6, and vice versa. (2) Routing: Forwards packets between the 6LoWPAN network and the Internet. (3) Prefix advertisement: Sends Router Advertisement (RA) messages to distribute the global prefix so sensors can configure globally routable addresses.
Question 6: An engineer measures a 6LoWPAN packet with these compressed header fields: tf=3, nh=1, hlim=2, sam=3, dam=3. What is the resulting compressed header size?
Explanation: Decoding the flags: tf=3 means Traffic Class and Flow Label are both elided (both zero). nh=1 means Next Header is compressed (UDP, encoded in IPHC). hlim=2 means Hop Limit is 64 (common default), encoded in 2 bits. sam=3 means source address fully elided (derived from MAC). dam=3 means destination address fully elided. With ALL optional fields elided, only the 2-byte IPHC base header remains! This is the best-case compression: 40 bytes to 2 bytes = 95% reduction.
Question 7: A battery-powered soil moisture sensor using 6LoWPAN wakes every 15 minutes to send a 20-byte reading. Which IPv6 feature helps the sensor maintain connectivity while sleeping most of the time?
Explanation: SLAAC (RFC 4862) is perfect for sleepy sensors because: (1) Stateless: No server dependency - sensors derive their IPv6 address from Router Advertisements (RA) + their MAC address. (2) No lease renewals: Unlike DHCP which requires periodic renewals, SLAAC addresses are valid as long as the prefix is advertised. (3) Fast wake-up: Sensor wakes, sends data using its pre-configured address, sleeps - no handshake needed.
Question 8: A factory deploys 6LoWPAN sensors using Context-based Address Compression with context 0 = 2001:db8:1234:5678::/64. What is stored in each sensor to enable address compression?
Explanation: Context-based compression works by having nodes share a common prefix mapping. The 6LoWPAN Border Router distributes a context table via RA (Router Advertisement) options: “Context 0 = 2001:db8:1234:5678::/64”. Sensors store this small table (16 bytes per context, max 16 contexts). When compressing: Source address 2001:db8:1234:5678::1234 is matched to Context 0, prefix is elided, and only ::1234 (2 bytes) is sent in packet.
Question 9: A 6LoWPAN network has 50 sensors reporting to a border router. The network uses mesh-under forwarding with 3-hop average path length. If you switch to route-over forwarding with RPL, what is the primary trade-off?
Explanation: Mesh-under vs Route-over is a fundamental 6LoWPAN design choice:
Mesh-under (Layer 2 forwarding): - Packets forwarded using 802.15.4 addresses at Data Link layer - Each intermediate node: Receive frame, Check destination MAC, Rebroadcast if not for me - No IP header inspection at intermediate hops - Lower per-hop overhead: ~50-100 microseconds processing per hop
Route-over (Layer 3 forwarding): - Packets forwarded using IPv6 addresses at Network layer - Each intermediate node: Decompress IPv6 header, Consult routing table, Recompress, Forward - Uses RPL (standard IETF routing protocol) for routing decisions - Higher per-hop overhead: ~200-500 microseconds per hop - Seamless integration with IP tools (ping, traceroute work), SNMP management, firewall rules
973.4 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
973.5 Visual Reference Gallery
NoteVisual: 6LoWPAN Protocol Architecture
6LoWPAN adaptation layer enabling IPv6 over IEEE 802.15.4 networks
This diagram illustrates how 6LoWPAN enables IPv6 connectivity on constrained wireless networks through header compression and fragmentation.
NoteVisual: IPHC Header Compression
6LoWPAN IPHC header compression mechanism
IPHC compression achieves 83-95% reduction in IPv6 header size, critical for maximizing payload capacity in 127-byte 802.15.4 frames.
NoteVisual: 6LoWPAN Fragmentation
6LoWPAN fragmentation for large IPv6 packets
Fragmentation enables transmission of IPv6’s minimum 1280-byte MTU across 102-byte IEEE 802.15.4 payloads.
NoteVisual: 6LoWPAN Mesh-Under Routing
6LoWPAN mesh-under forwarding architecture
Mesh-under routing provides multi-hop connectivity at Layer 2, enabling the entire 6LoWPAN network to appear as a single IPv6 subnet.
NoteVisual: 6LoWPAN Packet Structure
6LoWPAN packet structure and encapsulation
The packet structure shows how 6LoWPAN headers identify compression and fragmentation modes for efficient IPv6 encapsulation.
NoteVisual: 6LoWPAN Routing Considerations
6LoWPAN routing considerations and design choices
Routing design choices between mesh-under (Layer 2) and route-over (Layer 3 with RPL) impact scalability, latency, and memory requirements.
973.6 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
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
973.8 What’s Next
Continue to Zigbee Fundamentals and Architecture to explore a higher-level network protocol built on IEEE 802.15.4 that provides application-level interoperability through the Zigbee Cluster Library, proven smart home profiles, and a mature ecosystem with certification programs for multi-vendor deployments.
