By the end of this section, you will be able to:
Before diving into this chapter, you should be familiar with:
Every IoT message is a datagram. Whether your temperature sensor sends a 10-byte reading or your security camera streams video, all data travels as packets with headers and payloads. Understanding this structure helps you debug network issues, optimize bandwidth usage, and choose appropriate protocols for constrained devices.
Imagine sending a book page-by-page through the mail instead of as one heavy package. Each page (packet) gets its own envelope with: - Sender’s address (who sent it) - Recipient’s address (who receives it) - Page number (sequence for reassembly) - The actual content (one page of the book)
Networks work the same way – large files are broken into small packets, each labeled with addressing and ordering information. At the destination, packets are reassembled into the original file, even if they arrived out of order or took different routes.
“Every message I send has two parts,” explained Sammy the Sensor, holding up an envelope. “The header is the outside of the envelope – it has the sender address, destination address, a sequence number, and an error-checking code. The payload is the letter inside – my actual sensor data.”
“And here is the cool part about encapsulation,” said Max the Microcontroller. “At each layer, the ENTIRE packet from the layer above becomes the payload of the new layer. It is like putting an envelope inside a bigger envelope inside an even bigger envelope. Each layer adds its own header with its own information.”
Lila the LED brought up an important point. “But what happens when your message is too big for the network? A Zigbee radio can only handle 127 bytes per packet! If your message is 500 bytes, it has to be broken into fragments – smaller pieces that each fit in one packet.”
“Fragmentation is tricky for IoT,” said Bella the Battery. “Each fragment needs its own header, so you lose efficiency. A 50-byte sensor reading might only need one packet, but a 500-byte config update needs multiple fragments. That is why IoT protocols keep messages small – less fragmentation means less overhead and less of my energy wasted on headers!”
The key to data communications: The data stream is broken into small pieces.
Each datagram consists of:
Why use datagrams?
The first figure above illustrates a generic datagram with labelled header fields, while the second provides an alternative view emphasizing the header-payload separation. Both reinforce the same core concept: every packet carries metadata (header) alongside the actual information (payload).
As data passes through protocol layers, each layer adds its own header. This process is called encapsulation.
This variant shows how a datagram is built as it passes through protocol layers (encapsulation):
Each layer adds its own header (encapsulation), growing the datagram from a simple 5-byte sensor value to a 51+ byte frame on the wire.
When your IoT sensor sends “Temperature: 23.5C” (about 5 bytes of data):
| Layer | Header Added | Running Total |
|---|---|---|
| Application | None (raw data) | 5 bytes |
| Transport (UDP) | 8-byte UDP header | 13 bytes |
| Network (IPv4) | 20-byte IP header | 33 bytes |
| Data Link (Ethernet) | 18-byte Ethernet header + FCS | 51 bytes |
Your 5-byte sensor reading becomes a 51-byte frame – only 9.8% of the frame is useful data (90.2% overhead).
This is why IoT protocols like CoAP use UDP (8-byte header) instead of TCP (20-byte header), and why binary encoding (2-4 bytes for temperature) is preferred over JSON (~20 bytes for {"temp":23.5}).
Understanding datagrams requires contrasting them with the older approach – circuit switching.
This variant compares the old telephone network model (circuit switching) with the modern Internet model (packet switching):
IoT devices send data in bursts (a sensor reading every minute). Packet switching only uses network resources during actual transmission, making it ideal for IoT.
| Aspect | Circuit Switching | Packet Switching |
|---|---|---|
| Resource Usage | Reserved entire duration | Only during transmission |
| Efficiency | Low for bursty traffic | High for bursty traffic |
| Failure Handling | Call drops if path fails | Packets reroute automatically |
| Example | Traditional phone calls | Internet, IoT networks |
For IoT: A temperature sensor that sends 100 bytes every 60 seconds would waste 99.99% of a dedicated circuit. Packet switching lets thousands of such devices share the same network efficiently.
The Maximum Transmission Unit (MTU) defines the largest packet a network can handle:
| Network Type | Typical MTU | IoT Relevance |
|---|---|---|
| Ethernet | 1,500 bytes | Standard for gateways |
| Wi-Fi | 2,304 bytes | Smart home devices |
| IPv6 minimum | 1,280 bytes | Guaranteed minimum for IPv6 |
| LoRaWAN | 51–242 bytes | Long-range sensors (varies by data rate) |
| IEEE 802.15.4 | 127 bytes | Zigbee, Thread, 6LoWPAN mesh sensors |
When data exceeds the MTU, it must be fragmented into smaller packets. Fragmentation adds overhead and complexity, so IoT protocols are designed around constrained MTUs.
Constrained IoT networks have tiny MTUs. Here is the fragmentation penalty for a 200-byte message over IEEE 802.15.4:
802.15.4 frame budget (127-byte MTU):
Fragmentation headers:
Number of fragments for 200-byte message:
\[\text{Fragment 1: } 91 \text{ bytes of data}\] \[\text{Fragment 2: } 90 \text{ bytes of data}\] \[\text{Fragment 3: } 19 \text{ bytes of data (remaining)}\] \[\text{Total: } 3 \text{ fragments}\]
Overhead penalty:
Comparison: Same 200 bytes over Ethernet (1,500-byte MTU):
For battery-powered IoT devices, 3 fragments means 3x more radio transmissions and roughly 3x more energy. This is why CoAP requests are designed to fit in a single 6LoWPAN frame (under 90 bytes) – avoiding fragmentation can save over 50% energy.
Scenario: A Thread-based smart home sensor needs to send a 200-byte CoAP response (firmware version + diagnostic data) over an IEEE 802.15.4 radio with 127-byte MTU.
IEEE 802.15.4 frame structure:
- MAC header: 23 bytes (with security)
- MAC footer (FCS): 2 bytes
- 6LoWPAN header (compressed): 7 bytes
-----------------------------------------
Available payload per frame: 127 - 23 - 2 - 7 = 95 bytesTotal application data: 200 bytes
Available payload per frame: 95 bytes
First fragment includes 6LoWPAN FRAG1 header: 4 bytes
-> First fragment payload: 95 - 4 = 91 bytes
Subsequent fragments include FRAGN header: 5 bytes
-> Subsequent fragment payload: 95 - 5 = 90 bytes
Remaining after first: 200 - 91 = 109 bytes
Additional fragments needed: ceil(109 / 90) = 2
Total fragments: 3Without fragmentation (hypothetical single frame):
200 bytes data + 32 bytes overhead = 232 bytes total
Overhead ratio: 32/232 = 13.8%
With fragmentation (3 fragments):
Fragment 1: 91 data + 36 overhead = 127 bytes (full frame)
Fragment 2: 90 data + 37 overhead = 127 bytes (full frame)
Fragment 3: 19 data + 37 overhead = 56 bytes (partial frame)
Total transmitted: 127 + 127 + 56 = 310 bytes for 200 bytes of data
Overhead ratio: 110/310 = 35.5%
Fragmentation penalty: 35.5% vs 13.8% = 2.6x more overheadEach fragment must arrive successfully. If per-frame loss rate is 2%:
P(all 3 fragments arrive) = (1 - 0.02)^3 = 0.98^3 = 0.9412 = 94.1%
P(single frame arrives, no fragmentation) = 0.98 = 98%
With fragmentation: 5.9% failure rate (vs 2% without)
Result: ~3x higher retransmission rateDesign Lesson: Keep IoT messages under 95 bytes to avoid fragmentation on IEEE 802.15.4 networks. For the diagnostic scenario above, split the response into two separate 100-byte requests rather than one 200-byte response. This eliminates fragmentation, reduces overhead from 35.5% to 13.8%, and improves reliability from 94.1% to 98%.
A building automation company deployed 500 Zigbee sensors sending 150-byte status reports (occupancy, temperature, light level, battery, and diagnostic counters).
Problem: Each report required 2 fragments over IEEE 802.15.4, causing:
Solution: Restructured the payload into two categories:
Results:
Key Insight: The MTU is not just a protocol detail – it is a system design constraint. Fragmentation creates a multiplicative penalty on overhead, reliability, and latency. Design payloads to fit within a single frame whenever possible.
Scenario: A Thread mesh network needs to deliver a 50 KB firmware update to a smart thermostat over 6LoWPAN (127-byte MTU). Compare naive fragmentation versus CoAP block-wise transfer (RFC 7959).
Given:
Approach 1: Naive IP Fragmentation
Fragments needed: ceil(50,000 / 91) = 550 fragments
(91 = 95 payload - 4 bytes fragmentation header)
Transmission overhead:
550 fragments x 127 bytes/frame = 69,850 bytes on the wire
Protocol efficiency: 50,000 / 69,850 = 71.6%
Reliability with 3% per-frame loss:
P(all 550 arrive) = (0.97)^550 = 0.0000006 = 0.00006%
Expected successful transfers: essentially zero!
Each failure requires retransmitting ALL 550 fragments
Estimated attempts to complete: 1 / 0.97^550 ~ 1.7 million attempts
This approach is completely infeasible.Approach 2: CoAP Block-Wise Transfer (Block2 option)
Block size: 64 bytes (SZX=2 in CoAP block option, where size = 2^(SZX+4))
Chosen to fit in single 6LoWPAN frame:
64 data + 12 (CoAP headers) + 4 (block option) = 80 bytes
Remaining in frame: 95 - 80 = 15 bytes margin (no fragmentation needed)
Blocks needed: ceil(50,000 / 64) = 782 blocks
Each block transfer:
Client: GET /firmware (Block2: NUM/0/64) = 1 frame
Server: 2.05 Content (Block2: NUM/1/64) + 64 bytes data = 1 frame
Total per block: 2 frames (request + response)
Transmission overhead:
782 blocks x 2 frames x 95 bytes = 148,580 bytes on wire
Protocol efficiency: 50,000 / 148,580 = 33.6%
Reliability with 3% per-frame loss:
Per-block success: (0.97)^2 = 94.09%
Per-block failure: 5.91% (retry that specific block only)
Expected retransmissions: 782 x 0.0591 = 46 extra blocks
Total blocks transmitted: 782 + 46 = 828
Total time (at 250 kbps, with 100ms RTT per block):
828 blocks x 100ms = 82.8 secondsComparison:
| Metric | IP Fragmentation | CoAP Block-Wise |
|---|---|---|
| Frames per attempt | 550 | 1,656 (828 x 2) |
| Successful delivery | ~0% | 99.9%+ |
| Wire efficiency | 71.6% | 33.6% |
| Recovery from loss | Retransmit ALL 550 | Retransmit 1 block |
| Transfer time | Infinite (never completes) | ~83 seconds |
Key Insight: IP fragmentation is a trap for constrained networks. Although it appears more efficient (71.6% vs 33.6%), the all-or-nothing recovery model makes it unusable at realistic error rates. CoAP block-wise transfer trades bandwidth efficiency for per-block recovery, making firmware updates practical over lossy mesh networks. This is why Thread, Zigbee, and other 6LoWPAN-based protocols mandate application-layer chunking for large transfers.
Scenario: Your IoT temperature sensor needs to transmit 1,000 bytes of sensor data over a 100 Mbps Ethernet network. The networking stack adds 78 bytes of protocol overhead to each packet: preamble (8 bytes), MAC header (14 bytes), IP header (20 bytes), TCP header (20 bytes), CRC checksum (4 bytes), and inter-frame gap (12 bytes).
Transmission details: Total packet = 1,000 bytes payload + 78 bytes overhead = 1,078 bytes = 8,624 bits
Think about:
Key Insight: Protocol efficiency = (Payload / Total packet size) x 100 = (1,000 / 1,078) x 100 = 92.8%. Transmission time = Total bits / Bandwidth = 8,624 bits / (100 x 10^6 bps) = 86.24 microseconds. This means your goodput (usable data rate) is 92.8 Mbps of the 100 Mbps bandwidth – 7.2% is consumed by protocol overhead.
The critical takeaway: overhead is fixed per packet, regardless of payload size. A 1,000-byte payload achieves 92.8% efficiency, but a 100-byte payload achieves only 56.2% efficiency (100 / 178), and a 50-byte payload drops to 39.1% efficiency (50 / 128). This demonstrates why packet aggregation – combining multiple small sensor readings into larger packets – dramatically improves network efficiency for IoT deployments.
UDP is connectionless and does not guarantee ordering. Two UDP packets sent in sequence may arrive reversed if they take different paths. Fix: add a sequence number to UDP payloads and reorder at the receiver if order matters.
A 1500-byte UDP datagram sent over a link with a 576-byte MTU will be fragmented by IP. If any fragment is lost, the entire datagram is discarded at the receiver. Fix: keep UDP payload sizes under 512 bytes on constrained networks, or implement PMTUD before sending large datagrams.
IP fragmentation is transparent to the application but costly (all fragments must arrive for reassembly). Application-level chunking sends smaller independent messages, each of which is independently useful. Fix: prefer application-level message splitting over relying on IP fragmentation for large data transfers.
Now that you can analyze how data is packaged into datagrams and calculate fragmentation overhead, the next section explores how these packets are switched and routed through networks. You will learn about multiplexing, network resilience, and how routers make forwarding decisions.
| Topic | Chapter | Description |
|---|---|---|
| Packet Switching and Network Performance | network-mech-packet-switching.html | How routers forward datagrams, multiplexing strategies, and performance metrics for IoT networks |
| Data Representation in Networks | network-mech-data-representation.html | Bits, bytes, encoding schemes, and binary data formats that form the payload of datagrams |
| Error Detection and Correction | network-mech-error-detection.html | Checksums, CRC, and how header error fields protect datagram integrity in transit |
| IPv6 and 6LoWPAN for IoT | network-mech-ipv6-6lowpan.html | IPv6 header structure, 6LoWPAN compression techniques, and fragmentation in constrained networks |
| Transport Protocols: UDP and TCP | transport-udp-tcp.html | Comparing the 8-byte UDP and 20-byte TCP transport headers and when to choose each for IoT |
| CoAP: Constrained Application Protocol | app-protocols-coap.html | How CoAP block-wise transfer and binary encoding minimize datagram overhead on IoT devices |