5 6LoWPAN Fragmentation and Reassembly

In 60 Seconds

6LoWPAN fragmentation splits large IPv6 packets into numbered fragments (FRAG1 + FRAGN) to fit within 802.15.4’s 102-byte payload limit, but reliability drops exponentially with each fragment – at 5% loss per frame, 12 fragments yield only 54% delivery. The best strategy is to avoid fragmentation entirely by keeping payloads under 60-100 bytes.

Minimum Viable Understanding

If you take away only three things from this chapter:

Fragmentation exists because IPv6 packets are too big for 802.15.4 frames – IPv6 requires a 1280-byte minimum MTU, but IEEE 802.15.4 frames carry only ~102 usable bytes, so 6LoWPAN splits large packets into numbered fragments (FRAG1 + FRAGN) that the receiver reassembles using datagram tags and offset fields.
Reliability drops exponentially with fragment count – if ANY single fragment is lost, the entire datagram is discarded. At a 5% per-frame loss rate, a 12-fragment packet has only a 54% chance of successful delivery, making fragmentation the biggest reliability risk in 6LoWPAN networks.
The best strategy is to avoid fragmentation entirely – keep application payloads under 60-100 bytes so they fit in a single compressed frame. For unavoidably large transfers, use CoAP block-wise transfer instead of relying on 6LoWPAN fragmentation.

5.1 Learning Objectives

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

Explain Fragmentation Need: Justify why IPv6’s 1280-byte MTU requires fragmentation over 802.15.4’s 127-byte frame limit
Analyze Fragment Headers: Distinguish FRAG1 and FRAGN header fields and their roles in reassembly
Calculate Reliability Impact: Compute end-to-end delivery probability as a function of fragment count and per-frame loss rate
Design Reassembly Buffers: Implement buffer management strategies for fragment collection on constrained devices
Evaluate Fragmentation Alternatives: Compare 6LoWPAN fragmentation with CoAP block-wise transfer and assess trade-offs for different payload sizes

For Beginners: 6LoWPAN Fragmentation

IPv6 packets are too large for the small radio frames used by IoT devices, so 6LoWPAN breaks them into smaller pieces (fragments) for transmission and reassembles them on the other end. Think of it like moving a large piece of furniture through a narrow doorway – you take it apart, carry it through, and put it back together.

Sensor Squad: The Jigsaw Puzzle Problem

“Imagine you have a beautiful poster, but the door is too narrow to carry it through,” said Max the Microcontroller. “So you cut it into strips, carry each strip through, and tape them back together on the other side. That is fragmentation!”

Sammy the Sensor looked worried. “But what if one strip gets lost?” Max sighed. “That is the big problem! If even one piece is missing, the whole poster is ruined. You have to throw everything away and start over. With a 5% chance of losing each strip, a poster cut into 12 strips only has a 54% chance of making it through intact.”

“That sounds terrible!” gasped Bella the Battery. “And every lost poster means I waste energy sending it all over again!” Lila the LED nodded wisely. “That is why the golden rule of 6LoWPAN is: keep your messages small enough to fit through the door in one piece – under 60 to 100 bytes. No cutting, no taping, no lost pieces!”

“Think of it like texting versus emailing,” Max concluded. “Short text messages always get delivered. But try sending a huge email attachment over a flaky connection, and you will be hitting resend all day.”

5.2 Prerequisites

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

6LoWPAN Overview: Basic understanding of 6LoWPAN’s purpose
6LoWPAN Header Compression: IPHC compression mechanics
IEEE 802.15.4 Fundamentals: Frame size constraints (127 bytes max)

5.3 The Fragmentation Problem

Problem: IPv6 requires a 1280-byte minimum MTU, but 802.15.4 frames are only 127 bytes.

Solution: 6LoWPAN fragments large IPv6 packets across multiple 802.15.4 frames.

Artistic visualization of 6LoWPAN fragmentation showing IPv6 packet decomposition into multiple 802.15.4 frame fragments with dispatch headers, datagram tags, and offset fields for reassembly at destination node — 6LoWPAN Fragmentation Process

5.3.1 Fragmentation Thresholds

802.15.4 Max Frame Size: 127 bytes (PHY payload)
MAC Overhead: ~25 bytes (frame control, sequence, PAN IDs, addresses, FCS)
Usable Payload (no security): ~102 bytes
Security Overhead (AES-128-CCM): ~21 bytes (security header + MIC)
Usable Payload (with AES-128): ~81 bytes

Putting Numbers to It

When an 802.15.4 frame is configured with AES-128 link-layer security, the usable payload shrinks due to overhead. The calculation is straightforward:

\[\text{Usable Payload} = \text{Frame Size} - \text{MAC Header} - \text{Security Header}\]

Worked example: With 127-byte maximum PHY payload, ~25-byte MAC overhead (frame control, sequence number, PAN IDs, addresses, and 2-byte FCS), and ~21-byte AES-128-CCM security overhead (auxiliary security header plus Message Integrity Code):

\[127 - 25 - 21 = 81 \text{ bytes}\]

This means a compressed 6-byte IPv6/UDP header (via IPHC + NHC) plus a ~75-byte application payload fits in a single secured frame without fragmentation. Anything larger triggers 6LoWPAN’s FRAG1/FRAGN mechanism. Without link-layer security, the available payload is approximately 102 bytes (\(127 - 25 = 102\)).

When Fragmentation Triggers:

Compressed IPv6/UDP header (6 bytes) + Application payload > 102 bytes
Example: 6-byte header + 97-byte CoAP payload = 103 bytes -> REQUIRES FRAGMENTATION

5.4 Fragment Header Formats

5.4.1 First Fragment (FRAG1)

Bit-level diagram of the 6LoWPAN FRAG1 header showing 5-bit dispatch field with value 11000, 11-bit datagram size field specifying total IPv6 packet length, and 16-bit datagram tag for uniquely identifying fragments belonging to the same original packet. — FRAG1 Header Format

FRAG1 header format: 5-bit dispatch (11000), 11-bit datagram size, 16-bit unique tag, followed by compressed headers and first payload chunk.

5.4.2 Subsequent Fragments (FRAGN)

Bit-level diagram of the 6LoWPAN FRAGN header showing 5-bit dispatch field with value 11100, 11-bit datagram size matching the FRAG1 value, 16-bit datagram tag for fragment matching, and 8-bit offset field indicating the position of this fragment's payload in the original packet measured in 8-byte units. — FRAGN Header Format

FRAGN header format: 5-bit dispatch (11100), 11-bit size, 16-bit tag matching FRAG1, 8-bit offset (position/8, max 255 x 8 = 2040 bytes), followed by payload chunk.

5.5 Fragmentation Example

Scenario: Fragmenting a 307-byte packet

Original packet: 7-byte compressed header + 300-byte payload = 307 bytes
802.15.4 payload available: 102 bytes

Fragment 1:
  FRAG1 header: 4 bytes (11000 + size=307 + tag=0x5A3C)
  Compressed headers: 7 bytes (IPHC + NHC)
  Payload chunk 1: 91 bytes
  Total: 4 + 7 + 91 = 102 bytes

Fragment 2:
  FRAGN header: 5 bytes (11100 + size=307 + tag=0x5A3C + offset=91/8=11)
  Payload chunk 2: 97 bytes
  Total: 5 + 97 = 102 bytes

Fragment 3:
  FRAGN header: 5 bytes (offset=188/8=23)
  Payload chunk 3: 97 bytes
  Total: 102 bytes

Fragment 4:
  FRAGN header: 5 bytes (offset=285/8=35)
  Payload chunk 4: 22 bytes (final chunk)
  Total: 27 bytes

Total: 91 + 97 + 97 + 22 = 307 bytes
Overhead: 4 + 5 + 5 + 5 = 19 bytes (6.2% overhead)

5.6 Fragmentation Overhead Summary

Packet Size	Fragments	Header Overhead	Overhead %
102 bytes	1	0 bytes	0%
307 bytes	4	19 bytes	6.2%
512 bytes	6	29 bytes	5.7%
1280 bytes	14	69 bytes	5.4%

5.6.1 Quick Check: FRAG1 vs FRAGN Headers

5.7 Reliability Impact: The Fragment Loss Problem

Critical Challenge: If ANY fragment is lost, the ENTIRE IPv6 packet must be discarded and retransmitted.

5.7.1 Reliability Calculation

With 5% per-fragment loss rate:

1 fragment:  (0.95)^1  = 95.0% success
4 fragments: (0.95)^4  = 81.5% success
12 fragments: (0.95)^12 = 54.0% success
20 fragments: (0.95)^20 = 35.8% success

Best practice: Keep packets under 102 bytes to avoid fragmentation!

Pitfall: Ignoring MTU Mismatch Between IPv6 and 802.15.4

The Trap: Sending standard IPv6 packets (1280+ bytes) to 6LoWPAN devices without considering fragmentation overhead.

The Math That Hurts:

Standard IPv6 MTU: 1280 bytes
6LoWPAN fragment payload: ~97 bytes (after FRAGN header)
Fragments needed: ceiling(1280 / 97) = 14 fragments

Per-fragment loss rate: 5% (typical wireless)
All 14 must succeed: 0.95^14 = 48.8%

More than half of all packets FAIL to deliver!

Real-World Impact:

CoAP block-wise transfer degrades to single-fragment blocks
DTLS handshakes (typically 1000+ bytes) require 10+ fragments
Firmware updates become extremely unreliable

The Fix:

Application layer: Use CoAP block-wise transfer with 64-byte blocks
Transport layer: Keep DTLS records small (disable extensions)
Network layer: Configure IPv6 path MTU discovery
Border router: Fragment toward 6LoWPAN, reassemble toward internet

5.8 Knowledge Check: Fragmentation Reliability

Quiz: Fragmentation Reliability

Key Concepts

IEEE 802.15.4 Frame Size: Maximum 127-byte frame payload on 802.15.4 links, which cannot accommodate full 1280-byte IPv6 minimum MTU packets without fragmentation.
FRAG1 Header: The first fragment header in 6LoWPAN fragmentation, containing the datagram tag and total size to allow reassembly identification.
FRAGN Header: Subsequent fragment headers containing the datagram offset indicating where this fragment fits in the complete datagram.
Datagram Tag: A unique 16-bit identifier assigned to each fragmented IPv6 packet so the receiver can group all fragments belonging to the same datagram.
Reassembly Timeout: The time a receiver waits for all fragments of a datagram before discarding partial reassembly; typically 60 seconds per RFC 4944.
Fragment Interleaving: A technique allowing fragments from multiple datagrams to be transmitted concurrently, improving throughput but requiring per-datagram buffer management.

5.9 Reassembly Process

5.9.1 Reassembly Steps

Receive FRAG1: Allocate reassembly buffer (full datagram size), start 60-second timer
Store fragments: Place payload at correct offset (derived from offset field x 8)
Track completion: Mark which bytes have been received using bitmap
Receive final fragment: When all bytes filled, pass complete packet to IPv6 layer
Timeout handling: If timer expires before completion, discard all fragments

5.9.2 Memory Requirements

Per concurrent fragmented packet:
  - Reassembly buffer: Up to 2047 bytes (11-bit size limit)
  - Fragment bitmap: 256 bits (track which 8-byte chunks received)
  - Metadata: Tag, size, timer, source address
  - Total: ~2.3 KB per concurrent reassembly

Typical device (4 KB RAM):
  - Can handle 1-2 concurrent fragmentations
  - Important: Limit application payload sizes!

5.9.3 Code Example: Reassembly Implementation

// Contiki-NG: 6LoWPAN fragmentation buffer management
#include "net/ipv6/sicslowpan.h"

#define SICSLOWPAN_REASS_CONTEXTS  3   // Concurrent reassembly contexts
#define SICSLOWPAN_FRAGMENT_TIMEOUT 60  // Seconds

// Reassembly context structure
struct sicslowpan_frag_buf {
  uint16_t datagram_size;      // Total IPv6 packet size (e.g., 1200 bytes)
  uint16_t datagram_tag;       // Fragment group identifier
  uint8_t *reassembly_buffer;  // Buffer holding fragments as they arrive
  uint8_t *bitmap;             // Track which fragments received
  clock_time_t timeout;        // When to discard incomplete datagram
};

static struct sicslowpan_frag_buf frag_contexts[SICSLOWPAN_REASS_CONTEXTS];

// Allocate buffer for new fragmented datagram
int sicslowpan_fragment_alloc(uint16_t datagram_size, uint16_t datagram_tag) {
  int i;

  // Find free reassembly context
  for(i = 0; i < SICSLOWPAN_REASS_CONTEXTS; i++) {
    if(frag_contexts[i].datagram_size == 0) {
      // Allocate buffer for full IPv6 packet
      frag_contexts[i].reassembly_buffer = malloc(datagram_size);
      if(frag_contexts[i].reassembly_buffer == NULL) {
        printf("ERROR: Out of memory for reassembly (need %u bytes)\n", datagram_size);
        return -1;  // Out of memory!
      }

      frag_contexts[i].datagram_size = datagram_size;
      frag_contexts[i].datagram_tag = datagram_tag;
      frag_contexts[i].timeout = clock_time() + SICSLOWPAN_FRAGMENT_TIMEOUT * CLOCK_SECOND;

      return i;
    }
  }

  printf("ERROR: No free reassembly context (all %d in use)\n", SICSLOWPAN_REASS_CONTEXTS);
  return -1;  // All contexts in use
}

// Timeout handler - discard incomplete datagrams
void sicslowpan_fragment_timeout_check(void) {
  int i;
  for(i = 0; i < SICSLOWPAN_REASS_CONTEXTS; i++) {
    if(frag_contexts[i].datagram_size > 0 &&
       clock_time() > frag_contexts[i].timeout) {
      printf("Timeout: Discarding incomplete datagram tag=%u\n",
             frag_contexts[i].datagram_tag);

      // Free resources
      free(frag_contexts[i].reassembly_buffer);
      free(frag_contexts[i].bitmap);
      frag_contexts[i].datagram_size = 0;
    }
  }
}

5.10 Avoiding Fragmentation: Best Practices

5.10.1 Payload Size Guidelines

Payload Size	Fragments	Reliability	Recommendation
0-60 bytes	1	95%+	Sweet spot
60-100 bytes	1-2	90%+	Acceptable
100-200 bytes	2-3	80-90%	Caution
200-500 bytes	3-6	60-80%	Avoid if possible
500+ bytes	6+	<60%	Use different approach

5.10.2 Alternative Approaches

1. Application-Layer Segmentation (CoAP Block-Wise Transfer)

Split large data into 64-byte CoAP blocks:
- Each block fits in single 802.15.4 frame
- CoAP handles acknowledgment per block
- Selective retransmission (only failed blocks)
- Much more reliable than fragmentation

2. Border Router Handling

Sensor -> [Small packets] -> Border Router
Border Router -> [Reassemble/Fragment] -> Internet

Keep 6LoWPAN side small, let border router handle
internet-size packets on the Ethernet side.

3. Use Different Protocol for Large Data

- Wi-Fi for camera sensors (if power permits)
- NB-IoT/LTE-M for occasional large uploads
- 6LoWPAN only for small telemetry

Never Fragment Multicast Traffic

Multicast + Fragmentation = Disaster:

Each receiver has different fragment loss patterns
Sender can’t retransmit (no ACKs in multicast)
If 10 receivers all miss different fragments, 100% packet loss

Rule: NEVER use fragmentation with multicast! Keep multicast payloads under 60 bytes.

5.11 Knowledge Check

5.11.1 Knowledge Check: Fragment Count Calculation

5.11.2 Knowledge Check: Reassembly Buffer Management

5.11.3 Knowledge Check: Avoiding Fragmentation

Match the 6LoWPAN Fragmentation Concept

Order the 6LoWPAN Fragmentation and Reassembly Steps

How It Works: 6LoWPAN Fragmentation and Reassembly

When an IPv6 packet exceeds 102 bytes, 6LoWPAN fragments it into multiple 802.15.4 frames. The sender creates a FRAG1 frame (4-byte header with dispatch, datagram size, and unique tag) containing the first payload chunk. Subsequent FRAGN frames (5-byte headers with offset fields) carry remaining data. The receiver matches fragments by tag, buffers them, and reassembles using offset positions. A 60-second timeout discards incomplete datagrams if any fragment is lost.

5.12 Worked Example: Smart Building Firmware Update — Fragmentation Impact Analysis

Scenario: BuildNet Systems manages 2,400 Thread-based sensors across a 30-floor office building. A critical security patch (480 bytes after CoAP block-wise encoding) must be delivered to all nodes over the 6LoWPAN mesh. The network operations team needs to estimate delivery time and plan for the fragmentation overhead.

Step 1 — Fragment count calculation:

Security patch CoAP block: 480 bytes (after IPHC + NHC compression)
802.15.4 usable payload: 81 bytes (with AES-128 link-layer security enabled)

Fragment 1 (FRAG1):
  FRAG1 header: 4 bytes
  Compressed headers (IPHC + NHC + CoAP): 11 bytes
  Payload: 81 - 4 - 11 = 66 bytes

Fragments 2-7 (FRAGN):
  FRAGN header: 5 bytes each
  Payload per fragment: 81 - 5 = 76 bytes each
  Remaining after Fragment 1: 480 - 66 = 414 bytes
  Fragments needed: ceiling(414 / 76) = 6

Total fragments: 1 + 6 = 7 per CoAP block
Header overhead: 4 + (6 x 5) = 34 bytes (7.1% overhead)

Step 2 — Reliability analysis at observed loss rates:

The building’s 802.15.4 mesh has been measured at different per-frame loss rates depending on floor density:

Floor Type	Per-Frame Loss	7-Fragment Success	Expected Retries per Block
Open office (low interference)	2%	(0.98)^7 = 86.8%	1.15
Dense office (microwaves, Wi-Fi)	5%	(0.95)^7 = 69.8%	1.43
Basement plant room (motors)	10%	(0.90)^7 = 47.8%	2.09

Step 3 — Delivery time estimation:

Per-fragment airtime: 81 bytes x 8 bits / 250 kbps = 2.6 ms
Inter-fragment gap (CSMA/CA backoff): ~5-15 ms average
Time per 7-fragment block: 7 x (2.6 + 10) ms = 88.2 ms

Dense office scenario (5% loss, 1.43 attempts average):
  Time per successful block: 88.2 ms x 1.43 = 126.1 ms
  Full patch (480 bytes in 1 CoAP block): 126.1 ms per node

Multi-hop consideration (average 3.2 hops in the mesh):
  Each hop re-fragments: 126.1 ms x 3.2 = 403.5 ms per node

Sequential unicast to 2,400 nodes: 403.5 ms x 2,400 = 968.4 s = ~16.1 min
With CoAP congestion control (1 outstanding block): add 30% = ~21 min total

Step 4 — Comparison: what if the patch were smaller?

The team evaluates whether a delta-update approach (sending only changed bytes) would help:

Patch Size	Fragments (AES-128)	Success at 5% Loss	Time for 2,400 Nodes
60 bytes (fits in 1 frame)	1	95.0%	2.8 min
120 bytes	2	90.3%	5.9 min
480 bytes (full block)	7	69.8%	21 min
1,024 bytes	14	48.8%	67 min
1,280 bytes (IPv6 MTU)	17	41.8%	89 min

Decision: The team implements delta firmware updates. The security patch modifies only 48 bytes of executable code. With a delta encoder, the patch payload shrinks from 480 bytes to 52 bytes — fitting in a single 802.15.4 frame. This eliminates fragmentation entirely, improving delivery reliability from 69.8% to 95.0% and reducing update time from 21 minutes to under 3 minutes.

Key lesson: In 6LoWPAN networks, fragmentation is not just an overhead problem — it is an exponential reliability degradation. Every design decision should aim to keep payloads below the single-frame threshold (81 bytes with AES-128, or 102 bytes without). When fragmentation cannot be avoided, CoAP block-wise transfer with application-level retransmission is far more reliable than depending on 6LoWPAN’s all-or-nothing reassembly.

5.13 Concept Relationships

Concept	Depends On	Enables	Conflicts With
Fragmentation	802.15.4 MTU limits, IPHC compression	Large packet support, IPv6 MTU compliance	Single-frame reliability, battery efficiency
Reassembly Timeout	Fragment buffering	Memory recovery	Real-time delivery guarantees
Datagram Tags	FRAG1/FRAGN headers	Fragment matching	Tag collision avoidance needed

5.14 See Also

6LoWPAN Header Compression - How compression reduces payload before fragmentation
CoAP Block-wise Transfer - Application-layer alternative to 6LoWPAN fragmentation
RPL Routing with 6LoWPAN - Multi-hop forwarding of fragmented packets

Try It Yourself: Fragmentation Calculation

Scenario: You need to send a 300-byte JSON diagnostic message from a sensor to a cloud server over 6LoWPAN.

Tasks:

Calculate fragments needed (assuming 102-byte 802.15.4 payload, 7-byte compressed header, FRAG1=4 bytes, FRAGN=5 bytes)
With 5% per-fragment loss, what’s the packet success rate?
Design an alternative using 60-byte CoAP blocks - how does reliability improve?

Expected Results:

Fragments: 4 (first 91 bytes data, then 97+97+22)
Success: 0.95^4 = 81.5%
CoAP blocks: 5 blocks × 95% each = much higher with selective retry

Common Pitfalls

1. Fragment Loss Causing Full Retransmission

Loss of even one fragment requires the entire datagram to be retransmitted from the application layer since 6LoWPAN has no fragment-level retransmission. Minimize fragmentation by keeping application payloads small enough to fit in one or two fragments.

2. Insufficient Reassembly Buffers

Constrained devices with limited RAM can hold only a few partial datagrams simultaneously. Concurrent fragmented transmissions from multiple senders can exhaust reassembly buffers. Size buffers based on expected concurrent sender count.

3. Not Considering Fragmentation in Latency Budgets

Sending a 1200-byte payload over 127-byte frames requires 10+ frames. On a lossy channel, the probability of completing all fragments is (1-PER)^10 where PER is frame error rate. A 10% PER gives only 35% success rate.

🏷️ Label the Diagram

Code Challenge

5.15 Summary

This chapter explored 6LoWPAN’s fragmentation and reassembly mechanism:

Fragmentation is necessary because IPv6 requires 1280-byte MTU but 802.15.4 frames are only 127 bytes
FRAG1 and FRAGN headers carry size, tag, and offset for reassembly tracking
Reliability drops exponentially with fragment count: 12 fragments at 85.7% per-fragment success yields only 54% overall
Memory requirements are significant: each concurrent reassembly needs full datagram buffer allocation
Best practice: Keep payloads under 60-100 bytes to avoid fragmentation entirely
Alternatives: CoAP block-wise transfer, border router handling, or different protocols for large data

5.16 What’s Next

Chapter	Description
6LoWPAN Routing with RPL	How RPL builds mesh routes and forwards fragmented packets across multiple hops
6LoWPAN Deployment	Real-world deployment scenarios and practical considerations for 6LoWPAN networks
6LoWPAN Pitfalls	Common mistakes and anti-patterns when deploying 6LoWPAN, including fragmentation traps
6LoWPAN Hands-On and Security	Practical labs and security implications for 6LoWPAN networks
6LoWPAN Comprehensive Review	End-to-end review of 6LoWPAN concepts including fragmentation, compression, and routing