Chapters

3 6LoWPAN Architecture: Compression and Fragmentation

zigbee-thread
6lowpan
architecture

6LoWPAN is the adaptation architecture that lets IPv6 packets cross IEEE 802.15.4 radio links. It does not replace IPv6, and it does not make constrained radios behave like Ethernet. It gives a constrained network a disciplined way to compress headers, decide when a packet must be fragmented, carry neighbor-discovery evidence, and hand packets between low-power devices and ordinary IPv6 networks.

This chapter treats the fundamentals as an architecture review. A good 6LoWPAN explanation names the layer boundary, shows which fields can be reconstructed, keeps fragmentation as an exception path, identifies the router roles, and records the evidence a later reviewer would need before calling the design ready.

3.1 Start With the Decision

An IPv6 packet is larger than one low-power radio frame. The adaptation layer must compress headers and control fragment loss.

3.2 Route Overview

This is part 1 of 2. Continue with 6LoWPAN Architecture: Addressing and Forwarding Decisions.

3.3 Part Objectives

  • Explain 6LoWPAN header compression and adaptation.
  • Assess fragmentation cost on constrained radio links.

3.4 Chapter Roadmap

  • Start With the IPv6 Packet That Must Fit
  • In 60 Seconds
  • Quick Check: 6LoWPAN Architecture
  • Prerequisites
  • Architecture Claim
  • Why An Adaptation Layer Exists
  • Frame Budget Arithmetic
  • Interactive: 6LoWPAN Encapsulation Budget
  • Interactive: Out-of-order 6LoWPAN Reassembly
  • Stack Boundary
  • Layer Responsibilities
  • Header Compression Context
  • Interactive: 6LoWPAN IPHC Header Compression
  • Fragmentation Boundary
  • Addressing And Neighbor Discovery

3.5 Start With the IPv6 Packet That Must Fit

Follow One Small Packet Across the Radio Link

Picture a field sensor sending a frost warning through a radio that can carry only a small frame. The full network packet may not fit. A useful design must shrink or split the message without losing its source, time, or final result.

A protocol means shared rules for an exchange. Internet Protocol means the addressing rules used to move network packets. IPv6 means version 6 of those rules. IEEE 802.15.4 means a low-power radio and link standard. 6LoWPAN means a way to carry IPv6 over that small radio. User Datagram Protocol (UDP) means sending separate messages without a lasting connection. A payload means the useful data inside one message. A gateway means the bridge between the small-radio network and a wider network.

Send one warning, then enlarge it, drop a piece, repeat it, and restart the gateway. The receiver should report one clear outcome. Old data must not look new, and a missing piece must not become a false warning.

This runway does not prove range, battery life, or security. The deeper sections show where headers shrink, packets split, addresses cross the gateway, and failures become test evidence.

Start with one sleepy constrained node that still needs IPv6 behavior. 6LoWPAN Adaptation Architecture is the place to ask how a packet is compressed, fragmented, routed, and handed to the border router without losing the design claim.

The start-simple move is to write the evidence record first: original packet, adapted frames, route or parent state, reassembly outcome, and the retest trigger when the link or payload changes.

3.6 In 60 Seconds

  • 6LoWPAN sits between IPv6 and IEEE 802.15.4. It adapts packet shape; it is not an application protocol or a gateway-only translation trick.
  • Header compression works when both sides share enough context to reconstruct omitted IPv6 and UDP fields.
  • Fragmentation exists because IPv6 packets can be larger than a constrained radio frame, but fragmented traffic must be justified and tested.
  • Architecture roles matter: 6LoWPAN nodes, routers, and border routers have different custody, routing, and monitoring duties.
  • Thread builds on these ideas but adds its own commissioning, mesh management, security, and product ecosystem rules.

3.7 Learning Objectives

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

  • Explain the packet-size mismatch that makes a 6LoWPAN adaptation layer necessary.
  • Describe how IPHC, fragmentation, neighbor discovery, and forwarding roles fit into one architecture.
  • Distinguish a 6LoWPAN node, 6LoWPAN router, and 6LoWPAN border router by evidence and responsibility.
  • Review whether a design has enough context, routing, security, and operations evidence to support native IPv6 over constrained radio links.
  • Place this fundamentals chapter in the 6LoWPAN, RPL, Thread, and Zigbee learning path without mixing protocol boundaries.

3.8 Quick Check: 6LoWPAN Architecture

3.9 Prerequisites

This chapter assumes you have already reviewed:

3.10 Architecture Claim

Use a claim that can be tested:

Architecture claim: This 6LoWPAN design can carry the named IPv6 traffic over IEEE 802.15.4 because compression context, fragmentation boundaries, neighbor discovery, routing roles, border-router custody, security assumptions, and operating evidence are documented and retestable.

The claim prevents a common shortcut: “it uses IPv6, so it is interoperable.” IPv6 compatibility is only useful if the constrained side can prove packet fit, context reconstruction, route behavior, and recovery. The chapter should make those proof points visible.

Traffic evidence Name the packet classes: telemetry, command, discovery, commissioning, diagnostics, security handshake, update, or support traffic.
Context evidence Show what the sender may omit and how the receiver reconstructs it from link-layer addresses, shared prefixes, hop-limit rules, or configured context.
Operating evidence Record where routes, neighbor state, fragment state, retries, timeouts, and border-router health can be inspected.

3.11 Why An Adaptation Layer Exists

IPv6 was designed with a much larger link model than an IEEE 802.15.4 radio frame. The radio frame must carry MAC information, security overhead when enabled, adaptation dispatch, IPv6 or compressed IPv6 information, transport information, and the application payload. If the design simply sends ordinary IPv6 headers into the constrained frame, the useful payload becomes small and many messages need fragmentation.

6LoWPAN is the layer that makes this mismatch manageable. It does three architectural jobs:

Compact what is repeated IPHC omits or shortens fields that the receiver can reconstruct safely.
Split what still cannot fit Fragmentation carries a larger IPv6 datagram across several constrained frames, with reassembly state at the receiver.
Expose IPv6 behavior Neighbor discovery, routing, addressing, and border-router duties remain reviewable instead of being hidden behind a proprietary gateway.

The goal is not to push every ordinary internet packet into a tiny radio mesh. The goal is to carry the right IPv6 traffic, with enough evidence to know when the constrained link is healthy and when the design should change.

3.12 Frame Budget Arithmetic

The size mismatch becomes concrete when the review counts one frame. An IEEE 802.15.4 frame is at most 127 bytes before MAC addressing, link control, link security, 6LoWPAN dispatch bytes, compressed or uncompressed IP information, transport information, and application data all compete for space.

Start with 127 bytes. Reserve roughly 25 bytes for MAC addressing and control, and reserve additional bytes when link-layer security is enabled. A practical payload budget may be around 80 bytes before network and transport headers. Uncompressed IPv6 plus UDP consumes 40 + 8 = 48 bytes, leaving roughly 32 bytes for application data. If IPHC and context compression shrink the network and transport headers to about 8 bytes for a local exchange, the same frame can carry roughly 72 bytes of useful application data.

That difference is the boundary between ordinary telemetry and avoidable fragmentation. A 24-byte sensor update should fit after compression and should be monitored as a single-frame path. A 180-byte diagnostic response may need fragmentation and therefore needs separate timeout, retry, memory, and operator-status evidence. Firmware, certificate, or log transfer should usually use application-layer chunking or another bearer rather than treating 6LoWPAN fragmentation as an unlimited pipe.

The frame-budget walk-through below makes that boundary inspectable byte by byte. Start with Encapsulation budget: its 80-byte application message, 15-byte context profile, and short compressed addressing fit with 21 bytes left. Then load Security crosses boundary and change only Link security. The visible AuxSec and MIC owners consume nine bytes, reversing the conclusion from one frame to two even though the application still carries a modest 100 bytes.

Use the preset walk-through before changing address widths or forwarding mode. Step through Encapsulate, Compress, Fragment, and Transmit; then compare the fragment offsets, airtime multiplier, and whole-datagram probability readout.

The sender’s fragment count is only half the story. At the receiver, FRAGN offsets place byte ranges independently of arrival order. Start the walk-through below with arrivals 1, 3, 2, 5, 4: the strip looks shuffled, but the buffer fills bytes 0 through 419 in their original positions. Then reset, drop fragment 3, dispatch the others, and advance the receiver clock to 60 seconds; the missing [176, 264) range forces the whole incomplete buffer to be discarded.

Use Play or Step to dispatch the deterministic out-of-order preset. Compare the arrival strip with the byte-offset buffer, duplicate the last arrival to prove coverage is idempotent, then use Drop selected and Advance time to expose the timeout boundary.

3.13 Stack Boundary

Use Figure 3.1 to keep the layer responsibilities clear.

Before stack Boundary, inspect Figure 3.1 to compare “HTTP” with “6LoWPAN”. Their juxtaposition makes 6LoWPAN protocol stack comparison visible.

CoAP, UDP and IPv6 sit above 6LoWPAN and IEEE 802.15.4. Header compression and fragmentation adapt packet shape, not application meaning.
Figure 3.1: 6LoWPAN protocol stack comparison.

Read Figure 3.1 from “HTTP” to “6LoWPAN”. Taken together, “HTTP” and “6LoWPAN” express 6LoWPAN protocol stack comparison. For stack Boundary, the observed relationship between “HTTP” and “6LoWPAN” is evidence that “HTTP” carries into the next decision.

The adaptation layer is narrow but important. It does not decide the application meaning of a sensor value. It does not replace transport semantics. It does not make a lossy mesh into a high-capacity network. It defines how IPv6 packets are represented on the constrained link and how the receiving side reconstructs them.

3.14 Layer Responsibilities

Review 6LoWPAN by asking what each layer is responsible for and what it must not silently absorb.

Application layer Defines the message meaning, cadence, payload shape, and retry policy. CoAP is common, but the architecture review should still inspect payload size and failure behavior.
Transport and ICMPv6 UDP, CoAP, and ICMPv6 traffic need compressed or carried headers. The review should name which traffic classes exist and which are allowed during normal operation.
IPv6 layer Keeps addressing, hop limit, routing, and neighbor behavior visible. A 6LoWPAN design is still an IPv6 design with constrained-link rules.
6LoWPAN adaptation Compresses headers, fragments oversized packets, dispatches packet types, and supports constrained neighbor-discovery behavior.
IEEE 802.15.4 link Provides the radio MAC and PHY frame. Link behavior, security overhead, retries, and loss patterns influence packet fit and reliability.
Operations layer Not a protocol layer, but essential evidence: route state, fragment drops, neighbor churn, border-router health, and retest triggers.

3.15 Header Compression Context

IPHC works because the compressed packet is not decoded in isolation. The receiver uses context from the radio frame, shared IPv6 prefix assumptions, known hop-limit patterns, and agreed compression rules to rebuild the IPv6 header. That is the core architectural idea: remove information only when the receiving side can reconstruct it deterministically.

Evidence for IPHC should answer these questions:

Address source Can source and destination interface identifiers be derived from link-layer addresses, or must address bytes remain in the packet?
Prefix context Is the prefix link-local, configured by a border router, or carried explicitly because context is not safe to assume?
Transport context Are UDP ports compressible for this traffic, or are full fields needed for diagnostics, gateways, or compatibility?
Change control What happens when prefixes, commissioning state, security mode, or border-router ownership changes?

Do not treat a best-case compression example as a deployment result. A real design should capture packets from the actual traffic path and show the compressed form for normal and edge cases.

3.16 Fragmentation Boundary

Fragmentation is part of 6LoWPAN, but it should not become a hidden default. Once a datagram is split, the receiver must retain reassembly state, match fragment tags, track offsets, wait for missing pieces, and discard incomplete work. That is acceptable for named traffic paths with evidence. It is weak architecture when every large message silently depends on it.

Use this review boundary:

Single-frame target Normal telemetry and common commands should usually fit after compression and security overhead are included.
Fragmented exception Diagnostics, discovery responses, commissioning exchanges, or maintenance payloads may fragment, but they need explicit release rules.
Alternative path Large updates, bulk logs, and support downloads should be reviewed for application chunking, a different radio path, or a wired/backhaul path.

The fragmentation chapter goes deeper into FRAG1, FRAGN, reassembly timeout, loss exposure, and release checks. This fundamentals chapter only establishes why fragmentation belongs behind an architecture gate.

3.17 Addressing And Neighbor Discovery

6LoWPAN keeps IPv6 addressing visible, but ordinary IPv6 Neighbor Discovery is too chatty for a low-power mesh. A useful architecture review should explain how constrained neighbor discovery is handled, how prefixes are learned, how duplicate address assumptions are checked, and how sleepy devices keep state without forcing the network to carry excessive multicast traffic.

Autoconfiguration should be described as a constrained IPv6 behavior, not as a hidden gateway trick. A node can form a link-local address such as FE80::IID from an interface identifier derived from its IEEE 802.15.4 identity, then learn an on-link prefix from router advertisement evidence when the border router owns that prefix. Router solicitation, router advertisement, neighbor solicitation, and duplicate-address checks still matter, but the design should scope or proxy them so one address check does not become an expensive multicast storm on a sleepy low-rate mesh.

Address formation Document whether addresses are link-local, prefix-based, manually assigned, or commissioned by a higher-level system.
Neighbor state Show how the node learns next hops, keeps reachability evidence, and avoids stale neighbor records after movement or power loss.
Multicast boundary Record which multicast behavior is required and which is suppressed, proxied, or replaced by more constrained discovery.

This is where many weak explanations drift. “IPv6 addressing works” is not enough. The review must also show how the constrained network limits discovery traffic and how the border router represents the mesh to the rest of the IPv6 network.

3.18 Continue to the Next Part

Carry this evidence into 6LoWPAN Architecture: Addressing and Forwarding Decisions, which begins with Stateless Address Reconstruction.