17  Protocol Overhead and Encapsulation

In 60 Seconds

Each protocol layer wraps data with headers, compounding overhead like Russian nesting dolls. Sending 1 byte of sensor data through MQTT/TCP/IP results in 61 bytes on the wire – 98% overhead. BLE achieves 43% payload efficiency while MQTT over IPv6 drops to 14%. For bandwidth-constrained IoT, choosing the right protocol stack and batching payloads can reduce costs by 3-5x.

17.1 Learning Objectives

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

  • Compare protocol overhead: Evaluate header sizes across BLE, LoRaWAN, UDP/IPv4, TCP/IPv4, MQTT/TCP/IPv6, and CoAP stacks
  • Trace encapsulation layers: Diagram the “Russian doll” model showing how each protocol layer wraps data with headers and trailers
  • Calculate payload efficiency: Compute overhead percentages and bandwidth costs for different protocol stacks given a specific payload size
  • Estimate deployment costs: Project annual data volume and backhaul expenses for fleets of IoT sensors under various protocol choices
  • Select transport protocols: Justify choosing TCP vs. UDP for specific IoT scenarios based on latency, reliability, power, and overhead trade-offs

Every time you send a tiny piece of sensor data over a network, extra information (addresses, error checks, sequence numbers) gets wrapped around it – like putting a small gift in a big box with lots of packing material. This “overhead” can be surprisingly large: sending just one byte of temperature data can require 60+ bytes of wrapping. For battery-powered IoT devices that pay per byte transmitted, understanding and minimizing this overhead is critical to keeping costs and power consumption low.

Prerequisites (Read These First):

Companion Chapters (Packet Structure Series):

Networking Foundations:

Protocol-Specific Details:

  • MQTT - MQTT fixed/variable headers
  • CoAP - CoAP 4-byte header
  • LoRaWAN - LoRa MAC header
  • 6LoWPAN - IPv6 header compression

Design & Analysis:

17.2 Protocol Header Comparison

Time: ~12 min | Difficulty: Advanced | Unit: P02.C02.U04

Key Concepts

  • Payload efficiency: The real question is how much of each transmitted packet carries useful application data after headers, trailers, and framing bytes are added.
  • Encapsulation stack: Every layer wraps the payload from the layer above, so overhead compounds as you move from application to transport to network to link layer.
  • Main trade-off: Richer transport features such as reliability, connection state, and global routing usually cost more bytes and more energy per reading.
  • Design checkpoint: Tiny payloads suffer the most, so batching data or choosing a leaner stack can produce order-of-magnitude savings.
  • Deployment metric: Overhead should be translated into bytes per year, battery life, and recurring cost, not left as an abstract header-size table.
  • Protocol pattern: Low-power local links often win on byte efficiency, while internet-facing stacks trade extra overhead for interoperability and reliability.

Different IoT protocols have vastly different header sizes and overhead. Understanding this helps you choose the right protocol for bandwidth-constrained applications.

17.2.1 Interactive Protocol Overhead Calculator

Use this calculator to explore how different protocol stacks affect overhead for your specific payload size:

17.2.2 Real Protocol Headers Compared

Here’s how common IoT protocols stack up when sending a 10-byte sensor payload:

  • LoRaWAN Header size: 13 bytes Trailer/FCS: 4 bytes (MIC) Total overhead: 17 bytes Total packet: 27 bytes Overhead: 63%
  • CoAP/UDP/IPv6 Header size: 4+8+40 bytes Trailer/FCS: - Total overhead: 52 bytes Total packet: 62 bytes Overhead: 84%
  • MQTT/TCP/IPv6 Header size: 2+20+40 bytes Trailer/FCS: - Total overhead: 62 bytes Total packet: 72 bytes Overhead: 86%
  • BLE Header size: 10 bytes Trailer/FCS: 3 bytes (CRC) Total overhead: 13 bytes Total packet: 23 bytes Overhead: 57%
  • Zigbee (802.15.4) Header size: 25 bytes Trailer/FCS: 2 bytes (FCS) Total overhead: 27 bytes Total packet: 37 bytes Overhead: 73%
  • TCP/IPv4 Header size: 20+20 bytes Trailer/FCS: - Total overhead: 40 bytes Total packet: 50 bytes Overhead: 80%
  • UDP/IPv4 Header size: 8+20 bytes Trailer/FCS: - Total overhead: 28 bytes Total packet: 38 bytes Overhead: 74%

Key Insights:

  • MQTT over TCP/IPv6: 86% overhead for a 10-byte payload! (72 bytes total)
  • LoRaWAN: 63% overhead but optimized for long-range, low-power
  • BLE: Best overhead ratio (57%) for short-range applications
  • CoAP/UDP: Better than MQTT but still 84% overhead

17.2.3 Interactive Deployment Cost Calculator

Calculate the real-world impact of protocol overhead on your IoT deployment:

Cost Optimization Insight

The calculator above shows how protocol choice directly impacts operational costs. For the default scenario (1,000 sensors, 10-byte payload, hourly readings), switching from MQTT/TCP/IPv6 to LoRaWAN can save over $200/year in bandwidth costs alone. Battery savings compound this advantage for battery-powered deployments.

17.2.4 Real-World Impact

For 1000 sensors sending 10 bytes every hour for a year:

  • Raw Data Annual data volume: 88 MB Backhaul cost at $0.10/MB: $8.80
  • BLE Annual data volume: 201 MB Backhaul cost at $0.10/MB: $20.10
  • LoRaWAN Annual data volume: 237 MB Backhaul cost at $0.10/MB: $23.70
  • UDP/IPv4 Annual data volume: 333 MB Backhaul cost at $0.10/MB: $33.30
  • TCP/IPv4 Annual data volume: 438 MB Backhaul cost at $0.10/MB: $43.80
  • MQTT/TCP/IPv6 Annual data volume: 631 MB Backhaul cost at $0.10/MB: $63.10

17.3 Concept Relationships

  • Protocol Overhead Builds on: packet anatomy (header/payload/trailer) Leads to: bandwidth optimization and protocol selection Contrasts with: raw data transmission
  • Encapsulation (Protocol Layering) Builds on: OSI model and TCP/IP stack Leads to: gateway design and protocol translation Contrasts with: flat single-layer protocols
  • Header Compression Builds on: binary encoding and entropy reduction Leads to: 6LoWPAN and ROHC Contrasts with: fixed-size headers
  • Payload Efficiency Builds on: data formats (JSON, CBOR) and batching Leads to: protocol stack optimization Contrasts with: header-only control messages
  • MTU Fragmentation Builds on: maximum transmission unit limits Leads to: IP fragmentation and TCP segmentation Contrasts with: single-packet transmission
See Also

Packet Structure Series:

Protocol-Specific Overhead Analysis:

Optimization Techniques:

Network Design:

Comparison chart for a 10-byte payload showing BLE, LoRaWAN, UDP over IPv4, and TCP over IPv4 as stacked packets with payload and overhead portions, efficiency badges, and total transmitted bytes.
Figure 17.1: Comparison chart for a 10-byte payload showing BLE, LoRaWAN, UDP over IPv4, and TCP over IPv4 as stacked packets with payload and overhead portions, efficiency badges, and total transmitted bytes.
Mobile Walkthrough: 10-byte Payload Overhead
  • BLE sends 23 B total with 13 B of overhead, leaving 43% payload efficiency.
  • LoRaWAN sends 27 B total with 17 B of overhead, leaving 37% payload efficiency.
  • UDP/IPv4 sends 38 B total with 28 B of overhead, leaving 26% payload efficiency.
  • TCP/IPv4 sends 50 B total with 40 B of overhead, leaving 20% payload efficiency.
  • MQTT/TCP/IPv6 sends 72 B total with 62 B of overhead, leaving 14% payload efficiency.
Cost-impact view converting byte overhead into yearly traffic and deployment consequences. The figure compares the same sensor workload across BLE, LoRaWAN, UDP over IPv4, TCP over IPv4, and MQTT over IPv6, showing annual megabytes, estimated spend, and qualitative battery impact.
Figure 17.2: Cost-impact view converting byte overhead into yearly traffic and deployment consequences. The figure compares the same sensor workload across BLE, LoRaWAN, UDP over IPv4, TCP over IPv4, and MQTT over IPv6, showing annual megabytes, estimated spend, and qualitative battery impact.
Mobile Walkthrough: Deployment Cost Impact
  • Scenario: 1,000 devices, 1 reading/minute, 10 B payload, 365 days, $0.10/MB.
  • BLE: 23 B/message, 11.5 GB/year, about $1,153, and the best battery outcome.
  • LoRaWAN: 27 B/message, 13.5 GB/year, about $1,352, with excellent range.
  • UDP/IPv4: 38 B/message, 19.0 GB/year, about $1,905, with lower byte cost than TCP.
  • TCP/IPv4: 50 B/message, 25.0 GB/year, about $2,504, paying extra for reliable transport.
  • MQTT/TCP/IPv6: 72 B/message, 36.1 GB/year, about $3,610, making it the most expensive option here.

17.4 Protocol Encapsulation: The Russian Doll Model

Time: ~10 min | Difficulty: Intermediate | Unit: P02.C02.U05

Each protocol layer wraps the data from the layer above, like Russian nesting dolls. Understanding this is key to:

  • Reading packet captures in Wireshark - see how protocols nest inside each other
  • Calculating MTU and overhead - know why large payloads get fragmented
  • Debugging network issues - identify which layer is causing problems
  • Designing efficient IoT protocols - minimize unnecessary wrapping

17.4.1 How Encapsulation Works

When you send data through a network, each layer adds its own header (and sometimes trailer) around the data from the layer above:

  1. Application Layer creates data (e.g., MQTT Publish message)
  2. Transport Layer wraps it with TCP/UDP header
  3. Network Layer wraps that with IP header
  4. Data Link Layer wraps everything with Ethernet header and trailer
Layered encapsulation diagram showing application data being wrapped by transport, network, and data-link layers. The figure tracks a 100-byte application payload as it grows to a 158-byte frame on the wire, with each added header and trailer labeled by size and purpose.
Figure 17.3: Layered encapsulation diagram showing application data being wrapped by transport, network, and data-link layers. The figure tracks a 100-byte application payload as it grows to a 158-byte frame on the wire, with each added header and trailer labeled by size and purpose.
Mobile Walkthrough: Protocol Encapsulation Layers
  • Application data starts as a 100 B payload.
  • Transport adds a 20 B TCP header, growing the packet to 120 B.
  • Network adds a 20 B IP header, growing the packet to 140 B.
  • Data link adds a 14 B Ethernet header and 4 B FCS, reaching 158 B on the wire.
  • Key idea: the payload stays 100 B; only the wrappers around it grow.
End-to-end journey of a temperature reading from sensor to cloud. The figure traces a 2-byte value as it gains MQTT, TCP, IP, and Wi-Fi overhead at the edge, gets reframed at the router, and is finally decapsulated by the cloud service back to the original application data.
Figure 17.4: End-to-end journey of a temperature reading from sensor to cloud. The figure traces a 2-byte value as it gains MQTT, TCP, IP, and Wi-Fi overhead at the edge, gets reframed at the router, and is finally decapsulated by the cloud service back to the original application data.
Mobile Walkthrough: Sensor to Cloud Journey
  • Sensor firmware starts with a 2 B temperature reading and no transport framing yet.
  • Wi-Fi edge device adds Wi-Fi, IP, TCP, and MQTT bytes, reaching about 78 B of overhead around the same 2 B reading.
  • Router/gateway removes the Wi-Fi framing and rewraps the packet with Ethernet, dropping the overhead to about 62 B.
  • Cloud broker strips the transport and network wrappers and recovers the original 2 B application value.
  • Key idea: headers are added, removed, and replaced at each hop.

17.4.2 Overhead Calculation Example: Sending 1 Byte of Sensor Data

What happens when you send just 1 byte of temperature data through a standard network stack?

  • Application (MQTT) Header/trailer size: ~2 bytes header Running total: 3 bytes Purpose: MQTT packet type and flags
  • Transport (TCP) Header/trailer size: 20 bytes header Running total: 23 bytes Purpose: source/destination ports, sequence numbers, checksums
  • Network (IPv4) Header/trailer size: 20 bytes header Running total: 43 bytes Purpose: source/destination IP addresses, TTL, protocol
  • Data Link (Ethernet) Header/trailer size: 14+4 bytes header+FCS Running total: 61 bytes Purpose: MAC addresses, frame type, error detection

Result: 1 byte of actual sensor data requires 61 bytes on the wire = 98% overhead!

This is why IoT protocols like CoAP/UDP and 6LoWPAN header compression matter so much for constrained networks.

Let’s quantify how protocol overhead impacts both bandwidth costs and battery life for a real IoT deployment.

Scenario: 1,000 temperature sensors transmitting 2-byte readings every 10 minutes for one year.

Annual message count: \[N_{\text{messages}} = 1{,}000 \text{ sensors} \times \frac{60 \times 24}{10} \times 365 = 52{,}560{,}000 \text{ messages/year}\]

Protocol stack comparison:

Option A: MQTT over TCP/IPv6 (typical cloud MQTT broker) - Overhead: 62 bytes (MQTT 2B + TCP 20B + IPv6 40B) - Bytes per message: \(2 + 62 = 64\) bytes - Annual data: \(52{,}560{,}000 \times 64 = 3{,}363{,}840{,}000\) bytes \(\approx 3.2\) GB - Bandwidth cost @ $0.10/MB: \(3{,}363.84 \text{ MB} \times \$0.10/\text{MB} = \$336.38/\text{year}\) - Payload efficiency: \(\frac{2}{64} \times 100\% = 3.1\%\)

Option B: CoAP over UDP/IPv4

  • Overhead: 32 bytes (CoAP 4B + UDP 8B + IPv4 20B)
  • Bytes per message: \(2 + 32 = 34\) bytes
  • Annual data: \(52{,}560{,}000 \times 34 = 1{,}787{,}040{,}000\) bytes \(\approx 1.7\) GB
  • Bandwidth cost: \(1{,}787.04 \text{ MB} \times \$0.10/\text{MB} = \$178.70/\text{year}\)
  • Payload efficiency: \(\frac{2}{34} \times 100\% = 5.9\%\)
  • Savings vs MQTT: \(336.38 - 178.70 = \$157.68/\text{year}\) (47% reduction)

Option C: LoRaWAN

  • Overhead: 17 bytes (MAC header 13B + MIC 4B)
  • Bytes per message: \(2 + 17 = 19\) bytes
  • Annual data: \(52{,}560{,}000 \times 19 = 998{,}640{,}000\) bytes \(\approx 0.95\) GB
  • Bandwidth cost: \(\$99.86/\text{year}\)
  • Payload efficiency: \(\frac{2}{19} \times 100\% = 10.5\%\)
  • Savings vs MQTT: \(336.38 - 99.86 = \$236.52/\text{year}\) (70% reduction)

Battery impact:

Assuming 20mW transmit power, 2 seconds TX time per message:

Energy per message: \[E_{\text{message}} = 20 \text{ mW} \times 2 \text{ s} = 40 \text{ mWs} = 0.011 \text{ mWh}\]

Annual energy per sensor:

  • Messages per sensor: \(\frac{60 \times 24}{10} \times 365 = 52{,}560\) messages
  • Energy: \(52{,}560 \times 0.011 = 578 \text{ mWh} = 0.578 \text{ Wh/year}\)

Battery capacity needed (10-year life): \[C_{\text{battery}} = 0.578 \times 10 = 5.78 \text{ Wh} \approx 1{,}560 \text{ mAh at 3.7V}\]

Key insight: Protocol overhead doesn’t significantly affect radio energy (TX time is the same), but batching multiple readings into one packet amortizes overhead. Sending 10 readings per message instead of 1 reduces messages by 10× and bandwidth costs from $336 to $44/year (87% savings).

17.4.3 Practical Encapsulation Example: Wireshark View

When you capture packets with Wireshark, you can literally see the Russian doll unwrapping:

Frame 1: 158 bytes on wire
  Ethernet II, Src: 00:1a:2b:3c:4d:5e, Dst: 00:6f:7e:8d:9c:0b
    - Header: 14 bytes
    - Trailer (FCS): 4 bytes
  Internet Protocol Version 4, Src: 192.168.1.100, Dst: 10.0.0.50
    - Header: 20 bytes
  Transmission Control Protocol, Src Port: 1883, Dst Port: 52341
    - Header: 20 bytes
  MQTT Protocol
    - Fixed Header: 2 bytes
    - Payload: 100 bytes (TEMPERATURE=22.5C)
Mobile Walkthrough: Wireshark Packet Layers
  • Frame 1 is 158 B on the wire.
  • Ethernet II uses source 00:1a:2b:3c:4d:5e, destination 00:6f:7e:8d:9c:0b, plus a 14 B header and 4 B FCS.
  • IPv4 uses source 192.168.1.100, destination 10.0.0.50, plus a 20 B header.
  • TCP uses source port 1883, destination port 52341, plus a 20 B header.
  • MQTT adds a 2 B fixed header and carries a 100 B payload (TEMPERATURE=22.5C).

Reading this capture tells you:

  • Total overhead: 14 + 20 + 20 + 2 = 56 bytes (36% of total packet)
  • MQTT uses TCP port 1883 (standard MQTT port)
  • IP addresses show sensor (192.168.1.100) talking to broker (10.0.0.50)
  • MAC addresses identify physical network adapters
  • Payload is 100 bytes - the actual sensor data

Understanding encapsulation helps you:

  1. Debug connectivity issues - which layer is failing?
  2. Optimize bandwidth - is overhead too high?
  3. Verify security - is encryption applied at the right layer?
  4. Calculate MTU - will your packet fit or get fragmented?

17.5 Knowledge Check: Protocol Overhead

Scenario: You’re deploying 500 soil moisture sensors across a vineyard using LoRaWAN. Each sensor needs to send a 4-byte payload (2 bytes moisture, 2 bytes battery voltage) every 30 minutes. The LoRaWAN protocol adds: - 13-byte header (MHDR, DevAddr, FCtrl, FCnt) - 4-byte trailer (MIC for authentication/integrity)

Your cellular data plan costs $0.10 per MB for the LoRaWAN gateway backhaul.

Think about:

  1. What’s the total packet size for each transmission? (Header + Payload + Trailer)
  2. What percentage of transmitted data is actual sensor data vs. protocol overhead?
  3. How many bytes per sensor per day? How much does backhaul cost per year for 500 sensors?

Key Insights:

  • Total packet size: 13 + 4 + 4 = 21 bytes per transmission
  • Overhead ratio: Only 4 bytes out of 21 (19%) is actual data - 81% is protocol overhead!
  • Daily per sensor: 21 bytes x 48 transmissions/day = 1,008 bytes/day
  • Annual backhaul: 500 sensors x 1008 bytes x 365 days = 184 MB/year = $18.40/year

Real-world impact: Even with high protocol overhead, LoRaWAN can still be cost-effective for low-bandwidth IoT because messages are tiny. In practice, the bigger differentiator vs Wi-Fi is often power: higher duty cycle and active radio time can shorten battery life and increase maintenance cost.

Understanding packet structure helps you estimate bandwidth costs and choose appropriate protocols for your IoT deployment.

17.6 Scenario-Based Practice

Situation: You’re deploying soil moisture sensors using LoRaWAN Class A at SF12 (longest range, 51-byte max payload). Each sensor needs to send: - Moisture reading (1 byte, 0-100%) - Battery voltage (1 byte, 2.0-4.2V mapped to 0-255) - GPS coordinates (8 bytes: 4 for lat, 4 for lng)

The LoRaWAN stack adds: 13-byte header + 4-byte MIC (Message Integrity Code)

Question: Calculate the protocol efficiency. If you have a daily airtime budget of 30 seconds (EU duty cycle limit), how many messages can you send per day?

Packet Size Calculation:

  • LoRaWAN Header Size: 13 bytes Purpose: MHDR, DevAddr, FCtrl, FCnt, FPort
  • Payload (moisture) Size: 1 byte Purpose: sensor data
  • Payload (battery) Size: 1 byte Purpose: sensor data
  • Payload (GPS) Size: 8 bytes Purpose: location
  • LoRaWAN MIC Size: 4 bytes Purpose: authentication
  • Total Size: 27 bytes

Protocol Efficiency:

  • Actual data: 10 bytes (moisture + battery + GPS)
  • Total packet: 27 bytes
  • Efficiency: 10/27 = 37% (63% overhead)

Airtime Calculation at SF12:

SF12 parameters (EU868): - Bit rate: 250 bits/second - Preamble: 8 symbols = 262.14 ms - Symbol time: 32.77 ms

Time on Air formula (simplified): \[ \text{Payload symbols} = \frac{8 \times \text{payload\_bytes} + 28}{4} = \frac{8 \times 27 + 28}{4} = 61 \text{ symbols} \] - Payload time: \(61 \times 32.77 \text{ ms} = 1{,}999 \text{ ms} \approx 2.0 \text{ s}\) - Preamble: \(262 \text{ ms}\) - Total per message: ~2.26 seconds

Messages per day with 30-second budget:

  • 30 seconds / 2.26 seconds = 13 messages/day maximum

Real-world impact:

  • 13 messages/day = 1 message every 1.85 hours
  • With 8-hour GPS sampling: 8 messages/day for GPS, 5 remaining for extra moisture readings
  • Optimization: Don’t send GPS every message! Send moisture hourly (24 msgs needed), GPS once/day

Optimization Strategy:

  1. Message 1 (daily): GPS + moisture + battery = 27 bytes
  2. Messages 2-13: Moisture + battery only = 19 bytes

With smaller payload (2 bytes instead of 10): - Total packet: 19 bytes - Time on air: ~1.6 seconds - Messages possible: 30 / 1.6 = 18 messages with GPS once

Key insight: Payload size directly impacts airtime and duty cycle compliance. Compress data aggressively for LPWAN.

Situation: You’re designing a protocol for a fleet of 500 delivery drones. Each drone needs to: 1. Stream 720p video (2 Mbps) to ground control for navigation 2. Send GPS position every 100ms for collision avoidance 3. Receive emergency “return to base” commands

All communication goes over 4G/LTE cellular with typical 50ms latency and 2% packet loss.

Question: For each data type (video, GPS, commands), would you use TCP or UDP? Consider the impact of packet loss and retransmission on each application.

Analysis by Data Type:

1. Video Stream: UDP

  • Latency tolerance Analysis: low, because the operator needs a real-time view
  • Loss tolerance Analysis: high, because one dropped frame in 30 is imperceptible
  • TCP problem Analysis: head-of-line blocking means one lost packet stalls all subsequent frames
  • UDP solution Analysis: a lost frame is just a minor glitch and the next frame arrives on time

Real calculation:

  • 2% packet loss at 30 fps = 0.6 frames/second lost
  • With TCP retransmission (50ms RTT): each lost packet adds 50-100ms delay
  • 2% x 30 fps x 100ms = 600ms of stutter per second which is unwatchable
  • With UDP: 0.6 frames/second simply missing which is barely noticeable

Recommendation: UDP with application-level FEC (Forward Error Correction)

2. GPS Position: UDP

  • Latency tolerance Analysis: very low, because collision avoidance is real-time
  • Loss tolerance Analysis: moderate, because the next position arrives in 100 ms anyway
  • Data freshness Analysis: critical, because an old position is worse than no position

Real calculation:

  • Position every 100ms = 10 positions/second
  • 2% loss = 0.2 positions/second missing
  • Drone moving at 20 m/s: 100ms = 2m of travel
  • Missing one reading: interpolate from neighbors
  • TCP retransmission: 50ms delay = position is now 1m stale

Recommendation: UDP

  • Include sequence number to detect gaps
  • Include timestamp for staleness detection
  • Application interpolates missing positions

3. Emergency Commands: TCP (or UDP with ACK)

  • Latency tolerance Analysis: moderate, because a 100 ms delay is acceptable for emergency use
  • Loss tolerance Analysis: zero, because the command must be received
  • Duplication Analysis: dangerous if a command like “land now” executes twice

Real calculation:

  • Emergency command is rare (once per flight if ever)
  • 2% packet loss means 2% chance command never arrives
  • TCP guarantees delivery with 50-100ms worst case latency
  • For emergency, 100ms delay is acceptable

Recommendation: TCP for simplicity, or UDP with application-level acknowledgment

Summary Table:

  • Video Protocol: UDP + FEC Reasoning: latency-critical and loss-tolerable
  • GPS Protocol: UDP + Seq# Reasoning: freshness-critical and loss-recoverable
  • Commands Protocol: TCP Reasoning: reliability-critical and latency-tolerable

Real-world note: Many drone systems use QUIC (UDP-based with selective retransmission) which provides the best of both worlds - reliable when needed, low-latency when possible.

17.7 Additional Knowledge Check

Knowledge Check: Packet Structure Quick Check

Concept: Understanding packet components, framing, and error detection.

17.7.1 Match the Protocol to Its Overhead

17.7.2 Order the Encapsulation Steps

Use this framework to decide whether your IoT application should use TCP or UDP at the transport layer.

17.7.3 Step 1: Assess Your Reliability Requirements

  • Sensor readings (continuous stream) Can tolerate loss: yes, because the next reading arrives soon Recommended: UDP
  • Commands (turn on/off) Can tolerate loss: no, they must execute Recommended: TCP or UDP + app-level ACK
  • Firmware updates (files) Can tolerate loss: no, corruption is catastrophic Recommended: TCP
  • Video/audio streams Can tolerate loss: yes, because a lost frame is acceptable Recommended: UDP + FEC
  • Configuration data Can tolerate loss: no, errors cause malfunction Recommended: TCP
  • Telemetry (metrics) Can tolerate loss: moderate, because some loss is acceptable Recommended: UDP with retries

17.7.4 Step 2: Evaluate Your Latency Tolerance

TCP adds latency through:

  • 3-way handshake (150ms on cellular)
  • In-order delivery (head-of-line blocking)
  • Retransmission timeouts (RTT + margin)

Latency comparison (50ms RTT network):

  • Single packet UDP: 50ms TCP: 200ms (150ms handshake + 50ms data) Difference: 4x slower
  • Retransmission needed UDP: 100ms (1 retry) TCP: 250ms (timeout + retry) Difference: 2.5x slower
  • Out-of-order delivery UDP: 50ms (immediate) TCP: 200ms (waits for missing packet) Difference: 4x slower

Decision:

  • Latency-critical (< 100ms): Use UDP
  • Latency-tolerant (> 500ms OK): Either works, prefer TCP for simplicity

17.7.5 Step 3: Calculate Header Overhead

For a 10-byte sensor payload:

  • UDP IPv4: 28 bytes overhead (74% overhead) IPv6: 48 bytes (83% overhead)
  • TCP IPv4: 40 bytes overhead (80% overhead) IPv6: 60 bytes (86% overhead)

Impact on NB-IoT cellular ($0.10/MB):

  • 1,000 sensors × 96 msgs/day × 365 days = 35M msgs/year
  • UDP/IPv4: 35M × 38 bytes = 1.33 GB = $133/year
  • TCP/IPv4: 35M × 50 bytes = 1.75 GB = $175/year
  • Savings with UDP: $42/year per 1,000 sensors

Decision:

  • Bandwidth-constrained: Prefer UDP (20% less overhead)
  • Bandwidth-plentiful: Either works

17.7.6 Step 4: Consider Connection Management

TCP connection overhead:

  • Memory per connection Value: ~4 KB Impact: limits concurrent connections
  • Connection establishment Value: 3-way handshake Impact: adds latency and battery drain
  • Keepalive Value: Periodic packets Impact: battery drain on idle connections
  • Connection recovery Value: Automatic retries Impact: masks network failures

UDP “connection-less” benefits:

  • No per-client state on server
  • No connection setup delay
  • No keepalive traffic
  • Lower memory footprint

Decision:

  • Many short-lived connections (e.g., sensors that transmit once/hour): Use UDP
  • Long-lived connections (e.g., always-on gateway): Either works
  • Server handling 10,000+ devices: Prefer UDP (lower memory)

17.7.7 Step 5: Battery Life Impact

Energy consumption for 100-byte payload over NB-IoT:

  • UDP Handshake energy: 0 mJ Data transmission: 150 mJ Total: 150 mJ Comparison: baseline
  • TCP (new connection) Handshake energy: 80 mJ Data transmission: 150 mJ Total: 230 mJ Comparison: 53% more
  • TCP (existing connection) Handshake energy: 0 mJ Data transmission: 150 mJ Total: 150 mJ Comparison: same as UDP

Battery impact (1 transmission/hour, 2000 mAh battery):

  • UDP: 150 mJ × 24/day × 365 = 1.31 kWh/year → 5+ year battery
  • TCP (new connection each time): 230 mJ × 24/day × 365 = 2.01 kWh/year → 3 year battery

Decision:

  • Battery-powered, infrequent transmission: Use UDP
  • Mains-powered or frequent transmission: Either works

17.7.8 Step 6: Implementation Complexity

  • Client code UDP: Simple (sendto/recvfrom) TCP: Simple (send/recv after connect)
  • Error handling UDP: Manual retries required TCP: Automatic retransmission
  • Packet ordering UDP: Manual sequencing TCP: Automatic
  • Congestion control UDP: None - must implement TCP: Built-in
  • Security UDP: DTLS (more complex) TCP: TLS (mature, widespread)

Decision:

  • Need reliability but want efficiency: UDP + application-level ACK
  • Want simple reliable delivery: TCP
  • Need security: TLS (TCP) is easier than DTLS (UDP)

17.7.9 Final Decision Matrix

  • Sensor telemetry (temp, humidity) every 10 min Recommended protocol: UDP Rationale: loss-tolerant, battery-critical, low overhead
  • Command/control (turn on pump) Recommended protocol: TCP or CoAP (UDP + ACK) Rationale: must be reliable
  • Video streaming from camera Recommended protocol: UDP + RTP Rationale: loss-tolerant and latency-critical
  • Firmware updates Recommended protocol: TCP Rationale: file integrity is critical
  • Smart home gateway (always-on) Recommended protocol: TCP Rationale: connection reuse and TLS are easy
  • Industrial sensor (high-rate data) Recommended protocol: UDP Rationale: minimize overhead and latency
  • Remote configuration Recommended protocol: TCP Rationale: reliability-critical and infrequent

17.7.10 Example Decision Process

Scenario: 5,000 agricultural soil sensors on NB-IoT, sending 6-byte reading every 2 hours, running on 2× AA batteries (target: 5-year life).

  • Reliability Analysis: sensor readings can tolerate loss because the next reading arrives in 2 hours Score UDP: +1 Score TCP: 0
  • Latency Analysis: not latency-sensitive Score UDP: 0 Score TCP: 0
  • Overhead Analysis: UDP has 20% less overhead Score UDP: +1 Score TCP: 0
  • Battery Analysis: UDP saves 53% per transmission Score UDP: +1 Score TCP: 0
  • Complexity Analysis: the design needs sequence numbers anyway Score UDP: 0 Score TCP: 0
  • Security Analysis: TLS and DTLS both work Score UDP: 0 Score TCP: 0

Decision: UDP (3 points vs 0) - overhead and battery savings dominate.

Common Pitfalls

Teams often compare only the application payload and forget that transport, network, link-layer, and security headers all count on the wire. If you ignore even one layer, your bandwidth, airtime, and battery estimates will be wrong before deployment begins.

MQTT, TCP, UDP, BLE, and LoRaWAN are not expensive in the same way. A protocol that looks acceptable for a 500-byte payload may be wasteful for a 2-byte reading sent every minute. Always evaluate overhead at the real payload size and transmission frequency.

Encapsulation is not a one-time event. Routers, gateways, and border devices may strip one link layer and add another. If you assume the original frame survives end to end unchanged, you will misread captures and misunderstand where the bytes are really being spent.

17.8 Summary

Protocol overhead and encapsulation determine IoT system efficiency:

  • Protocol Stacking: Each layer adds headers, compounding overhead
  • Overhead Impact: Small payloads suffer most - 1 byte can become 61 bytes
  • Protocol Choice: BLE/LoRaWAN minimize overhead; TCP/IPv6 maximizes features
  • Encapsulation: Russian doll model wraps data at each layer
  • Cost Implications: Overhead directly impacts bandwidth costs and battery life

Key Takeaways:

  • Protocol overhead is significant for small IoT payloads
  • Choose protocols based on your bandwidth and power constraints
  • Wireshark reveals encapsulation layers for debugging
  • 6LoWPAN and header compression reduce IPv6 overhead for constrained networks

17.9 What’s Next

You have completed the packet structure series. Continue your learning with these related topics:

  • Data Formats for IoT Focus area: payload encoding Why read it: optimize the payload inside your protocol headers with JSON, CBOR, or Protobuf
  • Protocol Selection Framework Focus area: protocol choice Why read it: apply overhead analysis to choose the right protocol for your constraints
  • Network Traffic Analysis Focus area: packet inspection Why read it: use Wireshark to see encapsulation layers and measure real overhead
  • 6LoWPAN Header Compression Focus area: header optimization Why read it: compress IPv6 headers from 40 bytes down to as few as 2 bytes
  • Transport Fundamentals Focus area: TCP vs UDP deep dive Why read it: explore TCP and UDP header structures and reliability trade-offs in detail

Sammy the Sensor wants to send a tiny note to the Cloud: “It’s 23 degrees!”

But Max the Microcontroller says: “Hold on! Before your note can travel, we have to put it in envelopes – lots of them!”

First, Max puts Sammy’s note (just 1 byte!) into an MQTT envelope (2 more bytes for the address). Then that goes into a TCP envelope (20 bytes for tracking numbers). Then THAT goes into an IP envelope (20 more bytes for the street address). And finally into an Ethernet envelope (18 bytes for the neighborhood code).

Lila the LED counts up: “1 + 2 + 20 + 20 + 18 = 61 bytes! Your tiny 1-byte note is now a 61-byte package! That’s like mailing a postcard inside a shoebox inside a moving box inside a shipping crate!”

Bella the Battery groans: “And I have to power the radio to send ALL 61 bytes, not just 1! That’s why picking the right envelopes matters so much. BLE uses thin envelopes (only 13 bytes extra), but MQTT over the internet uses thick ones (60 bytes extra)!”

Max nods: “The trick? Send bigger notes so the envelopes don’t waste as much space. If you send 100 bytes of data, the overhead is only 37% instead of 98%!”

The Squad’s Rule: Every message gets wrapped in envelopes at each layer. Tiny messages waste the most space. Bundle your data to make those envelopes worthwhile!