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:

Protocol Header Size Trailer/FCS Total Overhead Total Packet Overhead %
LoRaWAN 13 bytes 4 bytes (MIC) 17 bytes 27 bytes 63%
CoAP/UDP/IPv6 4+8+40 bytes - 52 bytes 62 bytes 84%
MQTT/TCP/IPv6 2+20+40 bytes - 62 bytes 72 bytes 86%
BLE 10 bytes 3 bytes (CRC) 13 bytes 23 bytes 57%
Zigbee (802.15.4) 25 bytes 2 bytes (FCS) 27 bytes 37 bytes 73%
TCP/IPv4 20+20 bytes - 40 bytes 50 bytes 80%
UDP/IPv4 8+20 bytes - 28 bytes 38 bytes 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:

Protocol Annual Data Volume @ $0.10/MB Backhaul Cost
Raw Data 88 MB $8.80
BLE 201 MB $20.10
LoRaWAN 237 MB $23.70
UDP/IPv4 333 MB $33.30
TCP/IPv4 438 MB $43.80
MQTT/TCP/IPv6 631 MB $63.10

17.3 Concept Relationships

This Concept Builds On Leads To Contrasts With
Protocol Overhead Packet anatomy (header/payload/trailer) Bandwidth optimization, protocol selection Raw data transmission
Encapsulation (Protocol Layering) OSI model, TCP/IP stack Gateway design, protocol translation Flat single-layer protocols
Header Compression Binary encoding, entropy reduction 6LoWPAN, ROHC (RObust Header Compression) Fixed-size headers
Payload Efficiency Data formats (JSON, CBOR), batching Protocol stack optimization Header-only control messages
MTU Fragmentation Maximum Transmission Unit limits IP fragmentation, TCP segmentation 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, TCP over IPv4, and MQTT over TCP over IPv6. Each protocol is drawn as a stacked packet with payload and overhead portions, plus efficiency percentages and total transmitted bytes so the byte-cost difference is immediately visible.
Figure 17.1: Comparison chart for a 10-byte payload showing BLE, LoRaWAN, UDP over IPv4, TCP over IPv4, and MQTT over TCP over IPv6. Each protocol is drawn as a stacked packet with payload and overhead portions, plus efficiency percentages and total transmitted bytes so the byte-cost difference is immediately visible.
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.

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.
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.

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?

Layer Header/Trailer Size Running Total Purpose
Application (MQTT) ~2 bytes header 3 bytes MQTT packet type and flags
Transport (TCP) 20 bytes header 23 bytes Source/dest ports, sequence numbers, checksums
Network (IPv4) 20 bytes header 43 bytes Source/dest IP addresses, TTL, protocol
Data Link (Ethernet) 14+4 bytes header+FCS 61 bytes 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)

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:

Component Size Purpose
LoRaWAN Header 13 bytes MHDR, DevAddr, FCtrl, FCnt, FPort
Payload (moisture) 1 byte Sensor data
Payload (battery) 1 byte Sensor data
Payload (GPS) 8 bytes Location
LoRaWAN MIC 4 bytes Authentication
Total 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

Factor Analysis
Latency tolerance Low - operator needs real-time view
Loss tolerance High - one dropped frame in 30 is imperceptible
TCP problem Head-of-line blocking: one lost packet stalls ALL subsequent frames
UDP solution Lost frame = minor glitch, 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

Factor Analysis
Latency tolerance Very low - collision avoidance is real-time
Loss tolerance Moderate - next position arrives in 100ms anyway
Data freshness Critical - 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)

Factor Analysis
Latency tolerance Moderate - 100ms delay acceptable for emergency
Loss tolerance Zero - command MUST be received
Duplication Dangerous if command is “land now” and executed 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:

Data Type Protocol Reasoning
Video UDP + FEC Latency critical, loss tolerable
GPS UDP + Seq# Freshness critical, loss recoverable
Commands TCP Reliability critical, 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

Data Type Can Tolerate Loss? Recommended
Sensor readings (continuous stream) Yes - next reading arrives soon UDP
Commands (turn on/off) No - must execute TCP or UDP + app-level ACK
Firmware updates (files) No - corruption catastrophic TCP
Video/audio streams Yes - lost frame acceptable UDP + FEC
Configuration data No - errors cause malfunction TCP
Telemetry (metrics) Moderate - some loss OK 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):

Scenario UDP TCP Difference
Single packet 50ms 200ms (150ms handshake + 50ms data) 4x slower
Retransmission needed 100ms (1 retry) 250ms (timeout + retry) 2.5x slower
Out-of-order delivery 50ms (immediate) 200ms (waits for missing packet) 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:

Protocol IPv4 IPv6
UDP 28 bytes overhead (74% overhead) 48 bytes (83% overhead)
TCP 40 bytes overhead (80% overhead) 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:

Metric Value Impact
Memory per connection ~4 KB Limits concurrent connections
Connection establishment 3-way handshake Adds latency and battery drain
Keepalive Periodic packets Battery drain on idle connections
Connection recovery Automatic retries 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:

Protocol Handshake Energy Data Transmission Total Comparison
UDP 0 mJ 150 mJ 150 mJ Baseline
TCP (new connection) 80 mJ 150 mJ 230 mJ 53% more
TCP (existing connection) 0 mJ 150 mJ 150 mJ 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

Aspect UDP TCP
Client code Simple (sendto/recvfrom) Simple (send/recv after connect)
Error handling Manual retries required Automatic retransmission
Packet ordering Manual sequencing Automatic
Congestion control None - must implement Built-in
Security DTLS (more complex) 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

Your Scenario Recommended Protocol Rationale
Sensor telemetry (temp, humidity) every 10 min UDP Loss-tolerant, battery-critical, low overhead
Command/control (turn on pump) TCP or CoAP (UDP + ACK) Must be reliable
Video streaming from camera UDP + RTP Loss-tolerant, latency-critical
Firmware updates TCP File integrity critical
Smart home gateway (always-on) TCP Connection reuse, TLS easy
Industrial sensor (high-rate data) UDP Minimize overhead and latency
Remote configuration TCP Reliability critical, 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).

Factor Analysis Score UDP Score TCP
Reliability Sensor readings - loss acceptable (next reading in 2h) +1 0
Latency Not latency-sensitive 0 0
Overhead 20% less overhead with UDP +1 0
Battery UDP saves 53% per transmission +1 0
Complexity Need sequence numbers anyway 0 0
Security TLS/DTLS both work 0 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:

Chapter Focus Area Why Read It
Data Formats for IoT Payload encoding Optimize the payload inside your protocol headers (JSON, CBOR, Protobuf)
Protocol Selection Framework Protocol choice Apply overhead analysis to choose the right protocol for your constraints
Network Traffic Analysis Packet inspection Use Wireshark to see encapsulation layers and measure real overhead
6LoWPAN Header Compression Header optimization Compress IPv6 headers from 40 bytes down to as few as 2 bytes
Transport Fundamentals TCP vs UDP deep dive 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!