30  Transport Overhead Analysis

In 60 Seconds

For a 10-byte IoT payload, UDP achieves 42% payload efficiency (24 bytes total), TCP drops to 4% efficiency (244 bytes with handshake/teardown), and DTLS over UDP reaches 19% (53 bytes plus amortized handshake). At 250 kbps, radio on-time is 1.3 ms (UDP), 13.3 ms (TCP), or 2.8 ms (DTLS)—translating to battery life differences of ~40 years (UDP) vs ~20 years (TCP) for sensors transmitting every 10 seconds with a 2000 mAh battery at 5 mA TX and 5 µA sleep current.

Key Concepts

• Protocol Overhead Analysis Formula: Total overhead = transport_headers + TLS_record_header + auth_tag + application_protocol_headers; efficiency = payload / (payload + overhead)
• UDP + CoAP + DTLS Overhead: UDP 8B + DTLS record 13B + auth tag 16B + CoAP 4B = 41 bytes overhead; 50-byte payload → 45% overhead; 500-byte payload → 9% overhead
• TCP + MQTT + TLS Overhead: TCP 20B + TLS record 5B + auth tag 16B + MQTT fixed 2B + MQTT variable 5-20B = 43–53 bytes overhead; typically lower percentage overhead for larger MQTT payloads
• IP Header Overhead: IPv4: 20 bytes; IPv6: 40 bytes; IPv6 overhead 20 bytes higher than IPv4 per packet; significant for NB-IoT with tiny 10-byte payloads
• HTTP/REST Overhead: HTTP/1.1 header: 200–800 bytes (method, host, content-type, auth headers); HTTP/2 with HPACK header compression: 20–50 bytes; HTTP is not suitable for constrained IoT
• MQTT Packet Size: PUBLISH header: 2 bytes fixed + 2-4 bytes remaining length + 2 bytes topic length + N bytes topic + 2 bytes message ID (QoS 1/2) + payload; minimum PUBLISH overhead: ~7 bytes for short topic
• Data Plan Cost Calculator: bytes_per_message × messages_per_day × 30 × overhead_factor = monthly_bytes; NB-IoT overhead factor for UDP: 1.3; for TCP+TLS: 1.6; for HTTP: 2.5
• Compression for IoT: CBOR (Concise Binary Object Representation) vs JSON: CBOR encodes 5× more compact; LZ4/zlib compression adds CPU overhead but reduces 100–400 byte JSON to 30–80 bytes; use for large infrequent uploads

30.1 Learning Objectives

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

• Calculate protocol overhead: Analyze header sizes and total packet costs
• Compare efficiency: Evaluate UDP, TCP, and DTLS for small IoT payloads
• Estimate battery life: Calculate radio on-time and energy consumption
• Apply overhead analysis: Make data-driven protocol selection decisions

For Beginners: Transport Overhead Analysis

Every transport protocol adds extra bytes to your data for headers, checksums, and control information. This review examines how much overhead each protocol adds and why it matters for IoT devices that send tiny messages on limited batteries. By analyzing overhead, you can select the most efficient protocol for your deployment needs.

Sensor Squad: The Numbers Do Not Lie!

“Let us do the math for a 10-byte sensor reading,” said Max the Microcontroller. “With UDP, the total packet is 24 bytes—42 percent payload efficiency. With TCP including handshake and teardown, it balloons to 244 bytes—only 4 percent efficiency! That is 10 times more overhead.”

“Radio on-time tells the battery story,” explained Bella the Battery. “At 250 kbps, UDP takes 1.3 milliseconds of radio time per reading. TCP takes 13.3 milliseconds. With a 2000 mAh battery and 5 µA sleep current, that difference translates to UDP lasting around 40 years versus TCP lasting around 20 years for sensors transmitting every 10 seconds.”

“DTLS sits in the middle at 53 bytes total—19 percent efficiency,” added Sammy the Sensor. “That is much better than TCP and you get encryption. The handshake adds initial overhead, but it amortizes over thousands of messages.”

“These numbers should drive every protocol decision,” concluded Lila the LED. “When someone says ‘just use TCP for everything,’ show them this analysis. For tiny IoT payloads, the overhead difference between TCP and UDP is not a minor optimization—it is the difference between a 20-year and a 40-year deployment.”

30.2 Prerequisites

Required Chapters:

• Transport Review: Protocol Selection - Protocol trade-offs
• Transport Fundamentals - TCP/UDP basics

Estimated Time: 25 minutes

30.3 Protocol Overhead Visualization

Figure 30.1: IoT Protocol Overhead Comparison for 10-Byte Payload

Protocol overhead comparison for 10-byte IoT payload showing packet structure and efficiency. UDP achieves 42% payload efficiency (24 bytes total: 6B compressed IPv6, 8B UDP header, 10B payload) with 58% overhead. TCP full connection consumes 244 bytes (96% overhead) including 78B handshake, 36B data packet, 26B ACK, and 104B teardown—delivering only 4% payload efficiency. DTLS over UDP adds 53 bytes total (81% overhead) with 13B record header, 16B GCM authentication tag, plus amortized 620B initial handshake. Radio on-time at 250 kbps: UDP 1.3ms, TCP 13.3ms (10× worse), DTLS 2.8ms (2× worse). For battery-powered sensors transmitting every 10 seconds at 5 mA TX and 5 µA sleep, TCP consumes roughly 2× more energy than UDP, translating to ~20 years (TCP) versus ~40 years (UDP) for a 2000 mAh battery.

30.4 Overhead Comparison Table

Protocol	Total Bytes	Payload Efficiency	Radio Time (250kbps)	Energy Ratio
UDP	24 bytes	42%	1.3 ms	1× baseline
TCP (full)	244 bytes	4%	13.3 ms	10× worse
DTLS	53 bytes	19%	2.8 ms	2× worse

Try It: Protocol Overhead Calculator

viewof payloadBytes = Inputs.range([1, 100], {
  value: 10,
  step: 1,
  label: "Payload size (bytes)"
})
viewof protocol = Inputs.select(["UDP (6LoWPAN)", "TCP full connection", "DTLS over UDP"], {
  label: "Protocol"
})

{
  const payload = payloadBytes;

  const configs = {
    "UDP (6LoWPAN)": {
      ipv6: 6, transport: 8, extra: 0, authTag: 0,
      handshake: 0, teardown: 0,
      radioExtra: 0.5,
      label: "UDP"
    },
    "TCP full connection": {
      ipv6: 6, transport: 20, extra: 0, authTag: 0,
      handshake: 78, teardown: 104,
      radioExtra: 5.5,
      label: "TCP"
    },
    "DTLS over UDP": {
      ipv6: 6, transport: 8, extra: 13, authTag: 16,
      handshake: 0, teardown: 0,
      radioExtra: 1.0,
      label: "DTLS"
    }
  };

  const cfg = configs[protocol];
  const perRecord = cfg.ipv6 + cfg.transport + cfg.extra + payload + cfg.authTag;
  const total = cfg.handshake + perRecord + cfg.teardown;
  const efficiency = (payload / total * 100).toFixed(1);
  const overhead = (100 - efficiency).toFixed(1);
  const txBytes = total;
  const radioTimeMs = (txBytes / 31250 * 1000 + cfg.radioExtra).toFixed(2);

  const color = protocol.startsWith("UDP") ? "#16A085" :
                protocol.startsWith("TCP") ? "#E74C3C" : "#E67E22";

  return html`<div style="border-left: 4px solid ${color}; padding: 12px 16px; background: #f8f9fa; border-radius: 4px; font-family: Arial, sans-serif;">
    <strong style="color: ${color}; font-size: 1.05em;">${cfg.label} — ${payload}-byte payload</strong>
    <div style="display: grid; grid-template-columns: 1fr 1fr; gap: 8px; margin-top: 10px;">
      <div>
        <div style="font-size: 0.85em; color: #7F8C8D;">Total bytes on wire</div>
        <div style="font-size: 1.4em; font-weight: bold; color: #2C3E50;">${total} B</div>
      </div>
      <div>
        <div style="font-size: 0.85em; color: #7F8C8D;">Payload efficiency</div>
        <div style="font-size: 1.4em; font-weight: bold; color: ${color};">${efficiency}%</div>
      </div>
      <div>
        <div style="font-size: 0.85em; color: #7F8C8D;">Overhead</div>
        <div style="font-size: 1.4em; font-weight: bold; color: #2C3E50;">${overhead}%</div>
      </div>
      <div>
        <div style="font-size: 0.85em; color: #7F8C8D;">Radio on-time (250 kbps)</div>
        <div style="font-size: 1.4em; font-weight: bold; color: #2C3E50;">${radioTimeMs} ms</div>
      </div>
    </div>
    <div style="margin-top: 10px; font-size: 0.88em; color: #555;">
      Per-record bytes: ${perRecord} B header+payload
      ${cfg.handshake > 0 ? ` + ${cfg.handshake} B handshake + ${cfg.teardown} B teardown` : ""}
    </div>
  </div>`;
}

Putting Numbers to It

Protocol overhead directly determines how much of your transmission is useful payload versus header bytes. For a 10-byte sensor reading:

UDP efficiency: \[\eta_{\text{UDP}} = \frac{10\text{ B payload}}{6\text{ B IPv6} + 8\text{ B UDP} + 10\text{ B payload}} = \frac{10}{24} = 41.7\%\]

TCP full connection efficiency: \[\begin{align} \text{Total} &= 78\text{ B handshake} + 36\text{ B data packet} + 26\text{ B ACK} + 104\text{ B teardown} = 244\text{ B} \\ \eta_{\text{TCP}} &= \frac{10}{244} = 4.1\% \end{align}\]

DTLS over UDP efficiency: \[\begin{align} \text{Per record} &= 6\text{ B IPv6} + 8\text{ B UDP} + 13\text{ B DTLS header} + 10\text{ B payload} + 16\text{ B auth tag} = 53\text{ B} \\ \eta_{\text{DTLS}} &= \frac{10}{53} = 18.9\% \end{align}\]

Radio on-time at 250 kbps: \[\begin{align} T_{\text{UDP}} &= \frac{24\text{ B}}{31{,}250\text{ B/s}} = 0.77\text{ ms} \approx 1.3\text{ ms (with overhead)} \\ T_{\text{TCP}} &= \frac{244\text{ B}}{31{,}250\text{ B/s}} = 7.8\text{ ms} + 5\text{ ms RX} = 13.3\text{ ms} \\ T_{\text{DTLS}} &= \frac{53\text{ B}}{31{,}250\text{ B/s}} = 1.7\text{ ms} + 1\text{ ms} = 2.8\text{ ms} \end{align}\]

With 50 mA TX current and 2,880 daily readings (every 30 seconds, representative of higher-power radios), the active-only energy consumption is: - UDP: \(1.3\text{ ms} \times 2{,}880 \times 50\text{ mA} = 0.052\text{ mAh/day}\) - TCP: \(13.3\text{ ms} \times 2{,}880 \times 50\text{ mA} = 0.532\text{ mAh/day}\) (10× worse) - DTLS: \(2.8\text{ ms} \times 2{,}880 \times 50\text{ mA} = 0.112\text{ mAh/day}\) (2× worse)

This demonstrates that payload efficiency directly translates to battery life—TCP’s 4% efficiency vs UDP’s 42% creates a 10× energy penalty.

Key Insight: For a 10-byte sensor payload, TCP transmits 24× more data than the actual payload when including connection setup/teardown.

30.5 Battery Life Impact Comparison

Figure 30.2: Transport Protocol Battery Life Comparison for IoT Sensors

Battery life comparison for transport protocols in environmental sensor deployment. Scenario: 10-byte temperature/humidity readings transmitted every 10 seconds over 250 kbps radio (5 mA TX current, 5 µA sleep current) from 2000 mAh battery, targeting 5-year minimum operation. UDP fire-and-forget delivers ~40-year battery life: 24-byte packets require 1.3ms radio time per transmission (11.2 seconds daily active), consuming 0.136 mAh/day and comfortably exceeding the 5-year target. TCP full connection achieves ~20 years: 244-byte packets (including handshake/teardown) require 13.3ms radio time (115 seconds daily active), consuming 0.280 mAh/day—the 2× energy penalty versus UDP results from 96% protocol overhead. DTLS with session resumption provides ~34-year life: 53-byte packets plus negligible amortized resumption overhead require 2.8ms radio time (24 seconds daily active), consuming ~0.160 mAh/day—an acceptable security compromise at roughly 2× UDP overhead. Protocol selection decision: use UDP for non-critical telemetry, choose DTLS when security is required, consider TCP only for infrequent transmissions where connection state is maintained.

30.6 Detailed Power Budget Calculation

Scenario Parameters:

• Payload: 10 bytes temperature/humidity
• Interval: Every 10 seconds (8,640 transmissions/day)
• Radio: 250 kbps, 5 mA TX current
• Battery: 2000 mAh
• Target: 5 years minimum

30.6.1 UDP Calculation

Packet size: 24 bytes
TX time: 24 bytes / 31,250 bytes/s = 0.77 ms + 0.5 ms processing = 1.3 ms
Daily active: 8,640 × 1.3 ms = 11.2 seconds
Active energy: 5 mA × (11.2 / 3600) hours = 0.0156 mAh
Sleep energy: 5 µA × (86,389 / 3600) hours = 0.1200 mAh
Total daily: 0.136 mAh
Battery life: 2000 mAh / 0.136 mAh/day = 14,706 days = 40.3 years

30.6.2 TCP Calculation

Packet size: 244 bytes (including handshake/teardown)
TX time: 7.8 ms + 5 ms RX (ACKs) + 0.5 ms = 13.3 ms
Daily active: 8,640 × 13.3 ms = 115 seconds
Active energy: 5 mA × (115 / 3600) hours = 0.160 mAh
Sleep energy: 5 µA × (86,285 / 3600) hours = 0.120 mAh
Total daily: 0.280 mAh
Battery life: 2000 mAh / 0.280 mAh/day = 7,143 days = 19.6 years

30.6.3 DTLS Calculation (with Session Resumption)

Packet size: 53 bytes per record + amortized resumption handshake
TX time: ~2.8 ms average
Daily active: 8,640 × 2.8 ms = 24 seconds
Active energy: 5 mA × (24 / 3600) hours = 0.033 mAh
Sleep energy: 5 µA × (86,376 / 3600) hours = 0.120 mAh
Resumption overhead: negligible (~0.000028 mAh/day amortized over 8,640 transmissions)
DTLS record-layer crypto adds ~3 ms additional processing overhead per message:
  Processing energy: 5 mA × (8,640 × 0.003 / 3600) = 0.036 mAh/day (estimated)
Total daily: ~0.153 mAh (crypto) + ~0.007 mAh (margin) ≈ 0.160 mAh
Battery life: 2000 mAh / 0.160 mAh/day = 12,500 days = 34.2 years

30.7 Impact of Transmission Frequency

Interval	UDP Life	TCP Life	Recommendation
10 sec	~40 years	~20 years	UDP strongly preferred
1 min	~40 years	~38 years	UDP preferred
5 min	~40 years	~40 years	Either works
1 hour	~40 years	~40 years	TCP acceptable

Key Insight: At infrequent transmission intervals (>5 min), sleep current dominates and protocol overhead becomes negligible. At frequent intervals (<1 min), protocol overhead dominates and UDP is essential.

Try It: Battery Life Calculator

viewof batteryMah = Inputs.range([100, 5000], {
  value: 2000,
  step: 100,
  label: "Battery capacity (mAh)"
})
viewof txCurrentMa = Inputs.range([1, 100], {
  value: 5,
  step: 1,
  label: "TX current (mA)"
})
viewof sleepCurrentUa = Inputs.range([1, 100], {
  value: 5,
  step: 1,
  label: "Sleep current (µA)"
})
viewof intervalSec = Inputs.range([5, 3600], {
  value: 10,
  step: 5,
  label: "Transmission interval (seconds)"
})

{
  const battery = batteryMah;
  const txMa = txCurrentMa;
  const sleepUa = sleepCurrentUa;
  const interval = intervalSec;

  const protocols = [
    { name: "UDP",  txMs: 1.3,  color: "#16A085" },
    { name: "DTLS", txMs: 2.8,  color: "#E67E22" },
    { name: "TCP",  txMs: 13.3, color: "#E74C3C" }
  ];

  const txPerDay = 86400 / interval;

  const rows = protocols.map(p => {
    const activeS = txPerDay * p.txMs / 1000;
    const sleepS  = 86400 - activeS;
    const activeE = txMa * (activeS / 3600);
    const sleepE  = (sleepUa / 1000) * (sleepS / 3600);
    const totalE  = activeE + sleepE;
    const years   = (battery / totalE / 365).toFixed(1);
    return { ...p, activeS: activeS.toFixed(2), totalE: totalE.toFixed(4), years };
  });

  return html`<div style="border-left: 4px solid #3498DB; padding: 12px 16px; background: #f8f9fa; border-radius: 4px; font-family: Arial, sans-serif;">
    <strong style="color: #2C3E50;">Battery Life Estimate — ${(txPerDay).toFixed(0)} transmissions/day</strong>
    <table style="width: 100%; border-collapse: collapse; margin-top: 10px; font-size: 0.92em;">
      <thead>
        <tr style="background: #2C3E50; color: white;">
          <th style="padding: 6px 10px; text-align: left;">Protocol</th>
          <th style="padding: 6px 10px; text-align: right;">Active time/day</th>
          <th style="padding: 6px 10px; text-align: right;">Daily energy</th>
          <th style="padding: 6px 10px; text-align: right;">Battery life</th>
        </tr>
      </thead>
      <tbody>
        ${rows.map((r, i) => html`<tr style="background: ${i % 2 === 0 ? '#fff' : '#f0f0f0'}">
          <td style="padding: 6px 10px; font-weight: bold; color: ${r.color};">${r.name}</td>
          <td style="padding: 6px 10px; text-align: right;">${r.activeS} s</td>
          <td style="padding: 6px 10px; text-align: right;">${r.totalE} mAh</td>
          <td style="padding: 6px 10px; text-align: right; font-weight: bold; color: ${r.color};">${r.years} years</td>
        </tr>`)}
      </tbody>
    </table>
    <div style="margin-top: 8px; font-size: 0.82em; color: #7F8C8D;">
      Assumes 250 kbps radio. Actual lifetime also limited by battery self-discharge (~10 years for lithium cells).
    </div>
  </div>`;
}

Interactive: Message Serialization Comparator

Worked Example: Calculating Protocol Overhead for Multi-Sensor Gateway

Scenario: Smart home gateway aggregating data from 50 sensors, each sending 8-byte readings every 5 minutes.

System Parameters:

• Sensors: 50 devices
• Payload per sensor: 8 bytes (sensor ID: 2 bytes, reading: 4 bytes, checksum: 2 bytes)
• Frequency: Every 5 minutes (288 readings/day) per sensor
• Network: 802.15.4 with 6LoWPAN header compression
• Data rate: 250 kbps
• Gateway uplink: Ethernet to cloud

Step 1: Calculate Per-Sensor Overhead

UDP with 6LoWPAN compression:

Compressed IPv6 header: 6 bytes (vs 40 uncompressed)
Compressed UDP header: 4 bytes (vs 8 uncompressed)
Payload: 8 bytes
Total: 18 bytes per message

Overhead: 10/18 = 56%
Payload efficiency: 8/18 = 44%

TCP with 6LoWPAN compression (full connection):

Handshake:
- SYN: 6 (IPv6) + 12 (TCP compressed) = 18 bytes
- SYN-ACK: 18 bytes
- ACK: 18 bytes
Handshake total: 54 bytes

Data:
- Data packet: 6 + 12 + 8 = 26 bytes
- ACK: 18 bytes
Data total: 44 bytes

Teardown:
- FIN: 18 bytes
- ACK: 18 bytes
- FIN: 18 bytes
- ACK: 18 bytes
Teardown total: 72 bytes

Grand total: 54 + 44 + 72 = 170 bytes

Overhead: 162/170 = 95%
Payload efficiency: 8/170 = 5%

Step 2: Calculate Gateway Aggregation Benefit

Option A: Each sensor connects directly to cloud (distributed)

50 sensors × 18 bytes UDP = 900 bytes every 5 minutes (288 times/day)
Total upload: 900 × 288 = 259,200 bytes/day = 3 bytes/sec = 24 bps

With TCP:
50 sensors × 170 bytes = 8,500 bytes every 5 minutes (288 times/day)
Total upload: 8,500 × 288 = 2,448,000 bytes/day = 28.3 bytes/sec = 227 bps

Bandwidth cost (at $0.10/GB cellular):
- UDP: 259,200 bytes/day × 365 days/year / 1e9 = 0.095 GB/year ≈ $0.01/year
- TCP: 2,448,000 bytes/day × 365 days/year / 1e9 = 0.893 GB/year ≈ $0.09/year

Option B: Gateway aggregates, single connection to cloud (centralized)

Gateway buffers 50 sensor readings, sends one batch every 5 minutes:
- Aggregated payload: 50 × 8 bytes = 400 bytes
- UDP overhead (single packet): 6 (IPv6) + 8 (UDP) = 14 bytes
- Total per batch: 414 bytes

Per-sensor effective cost: 414 bytes / 50 sensors = 8.28 bytes/sensor/cycle
Overhead per sensor: 0.28 bytes of 8.28 = 3.4% overhead (vs 56% direct)
Payload efficiency: 96.6%

Total upload: 414 bytes × 288 batches/day = 119,232 bytes/day
Per-sensor amortized: 119,232 / 50 = 2,385 bytes/sensor/day

Bandwidth cost: 119,232 bytes/day × 365 / 1e9 = 0.044 GB/year ≈ $0.004/year

Step 3: Calculate Battery Impact (for battery sensors)

Direct UDP transmission (Option A):

Radio time per transmission: 18 bytes / (250 kbps / 8) = 0.58 ms
Transmissions per day: 288 (every 5 minutes)
Daily active radio time: 288 × 0.58 ms = 0.167 seconds/day
Sleep time: 86,400 - 0.167 = 86,399.8 seconds/day

With 5 mA TX current, 5 µA sleep current, 2000 mAh battery:
Active energy: 5 mA × (0.167 / 3600) = 0.00023 mAh/day
Sleep energy: 0.005 mA × (86,399.8 / 3600) = 0.120 mAh/day
Total daily: ~0.120 mAh/day (sleep-dominated)
Battery life: 2000 / 0.120 / 365 ≈ 45 years
(Also limited by electrochemical self-discharge, typically ~10 years)

Via gateway aggregation (Option B):

Sensor transmits to local gateway only (short range, lower power):
- Lower TX power: 1 mA vs 5 mA to cloud
- Same 18 bytes, same 5-minute frequency
Active energy: 1 mA × (0.167 / 3600) = 0.000046 mAh/day
Sleep energy: 0.005 mA × (86,399.8 / 3600) = 0.120 mAh/day (unchanged)
Total daily: ~0.120 mAh/day (negligible TX contribution)

At 5-minute intervals, TX energy is so small (sleep dominates) that
the gateway power benefit is minimal for battery life.
Key benefit of gateway aggregation is WAN bandwidth and cloud cost reduction.

Step 4: Total System Cost Comparison

Metric	Direct UDP	Direct TCP	Gateway UDP Agg	Advantage
Bytes/sensor/day	5,184	48,960	2,385	2.2× reduction vs direct UDP
Bandwidth cost/year	$0.01	$0.09	$0.004	~22× savings vs direct TCP
Battery life	~45 years*	~45 years*	~45 years*	Sleep-dominated; TX negligible
Cloud connections	50	50	1	50× reduction
Per-sensor overhead	56%	95%	3.4%	16× overhead reduction

*At 5-minute intervals, sleep current dominates and protocol choice has negligible battery impact.

Key Insights:

1. Gateway aggregation reduces per-sensor protocol overhead from 56% to 3.4% by amortizing packet headers across 50 readings in one frame
2. TCP is ~9.4× more expensive than UDP per byte for small frequent messages due to handshake/teardown — 48,960 vs 5,184 bytes/sensor/day
3. At infrequent intervals (5 min), sleep current dominates and battery life is similar regardless of protocol — protocol choice matters more at intervals under 1 minute
4. Annual WAN bandwidth cost drops from $0.09 (direct TCP) to $0.004 (gateway aggregation) — a 22× saving from amortizing the 14-byte packet header across 50 sensors

Lesson Learned: For multi-sensor IoT systems, gateway aggregation dramatically reduces per-sensor protocol overhead (56% → 3.4%) and cloud connection count (50 → 1), but battery life improvement depends on transmission frequency. At frequent intervals (<1 min), aggregation also extends battery life by reducing active radio time.

🏷️ Label the Diagram

💻 Code Challenge

30.8 Summary

Protocol overhead is not an abstraction—it directly determines radio-on time, energy consumption, and battery life. For a 10-byte sensor payload over 6LoWPAN at 250 kbps:

Protocol	Total Bytes	Efficiency	Radio Time	Battery Life
UDP	24 bytes	42%	1.3 ms	~40 years (baseline)
DTLS	53 bytes	19%	2.8 ms	~34 years (2.2× radio time)
TCP (full)	244 bytes	4%	13.3 ms	~20 years (10× radio time, 2× energy penalty)

Three design rules emerge from this analysis:

1. Frequent transmissions amplify overhead: at 10-second intervals, sleep current alone does not dominate; every millisecond of extra radio time costs energy. Use UDP or DTLS, not TCP.
2. Gateway aggregation collapses per-sensor overhead: amortizing one 14-byte header across 50 sensor payloads drops effective overhead from 56% to 3.4%.
3. At intervals greater than 5 minutes, protocol choice becomes secondary: sleep current dominates and all three protocols yield similar battery life. Focus instead on connection count and cloud architecture.

30.9 Concept Relationships

How Overhead Analysis Connects

Builds on:

• Transport Review: Protocol Selection - Choosing protocols to analyze
• Transport Fundamentals - Header structure understanding

Quantifies Trade-offs From:

• Transport Protocols Selection - Decision criteria validation
• TCP Optimizations - Measuring optimization benefits

Impacts System Design:

• Energy Management - Battery life calculations
• Network Planning - Bandwidth requirements
• Cost Modeling - Cellular data budgets

Related Calculations:

• LoRaWAN Architecture - Physical layer link budget and overhead
• 6LoWPAN Header Compression - Network layer overhead reduction
• CoAP vs MQTT Overhead - Application layer overhead

Common Misconceptions:

• “Overhead only matters for battery devices” - Wrong: Cellular data costs matter for mains-powered devices too
• “TCP is always 10× worse than UDP” - Wrong: With persistent connections or low frequency, the difference shrinks significantly
• “Bigger packets are always worse” - Wrong: Fewer large packets can be more efficient than many small packets due to PHY framing overhead

30.10 See Also

Related Reviews:

• Transport Review: DTLS Security - Security overhead analysis
• Transport Review: Protocol Selection - Selection criteria including overhead

Calculation Tools:

• IoT Energy Calculator - Interactive power budget tool
• LoRa Airtime Calculator - LoRaWAN overhead calculator

Deep Dives:

• Battery Life Estimation - Complete energy modeling
• Cellular IoT Data Plans - Cost impact of overhead

Specifications:

• RFC 791: IPv4 Header - 20 bytes minimum
• RFC 8200: IPv6 Header - 40 bytes (before compression)
• RFC 6282: 6LoWPAN Header Compression - Reduces to 2-6 bytes

Implementation Guides:

• Protocol Overhead Measurement Lab - Hands-on Wireshark analysis
• ESP32 Power Profiling - Measuring real energy consumption

External Resources:

• nRF Connect Power Profiler - Hardware power measurement
• Cellular IoT Overhead Study - Academic analysis of NB-IoT/LTE-M overhead

Common Pitfalls

1. Analyzing Overhead Only for the Happy Path

Protocol overhead analysis based on a single successful exchange misses: TLS handshake data (3–8 KB per new connection), MQTT CONNACK/PINGREQ/PINGRESP overhead (adds ~50 bytes/hour for keepalive), retransmission overhead on packet loss (1–5% of total data), and MQTT subscription confirmation overhead. A complete overhead analysis sums all protocol data across an entire day: telemetry + control messages + keepalive + connection establishment + error recovery.

2. Not Accounting for ACK Traffic in Overhead Calculations

TCP ACK traffic (pure ACK segments, 40–60 bytes each) is not part of the application data but consumes network bandwidth. Delayed ACK sends one ACK per 2 data segments, but at 100 messages/second, TCP generates 50 pure ACKs/second at 40 bytes each = 2 KB/s of ACK traffic. For full-duplex IoT communications, double all overhead estimates to account for reverse-direction ACK traffic. This is particularly relevant for NB-IoT where uplink and downlink capacity are both limited.

3. Calculating Overhead for Maximum Payload Only

Overhead analysis for a 1000-byte payload shows 5% overhead (acceptable). But if 80% of IoT messages are 20–50 bytes (typical sensor readings), the per-message overhead for those messages is 40–100%, completely dominating total overhead. Weight overhead calculations by message frequency distribution: overhead_total = Σ(overhead_bytes × messages_per_day × probability_per_size_class). The size class with highest message frequency dominates the total, not the maximum payload size.

4. Ignoring Keep-Alive Traffic in Annual Data Budget

MQTT keepalive at 60 seconds sends PINGREQ (2 bytes) and receives PINGRESP (2 bytes) every 60 seconds = 172,800 bytes/year = 168 KB/year. On a 1 MB/month (12 MB/year) NB-IoT plan, MQTT keepalive alone consumes 1.4% of the budget from a device that may only have 10 KB/month of real data. Increase keepalive to 600 seconds (reduces to 17 KB/year) or use PSM (device disconnects and reconnects per session, eliminating keepalive entirely) for ultra-low-bandwidth applications.

30.11 What’s Next

Continue exploring transport protocol analysis with these recommended chapters:

Chapter	Focus	Why It Follows
Transport Review: DTLS Security	DTLS architecture, handshake, and session resumption	Apply overhead knowledge to evaluate DTLS security costs
Transport Comprehensive Review	End-to-end synthesis of all transport protocol concepts	Consolidate and assess the full transport layer picture
DTLS and Security	DTLS implementation and IoT threat mitigation	Implement security with measured overhead trade-offs
Battery Life Estimation	Complete energy modeling methodology	Extend overhead calculations to full power budgets
Transport Review: Protocol Selection	Decision framework for protocol selection	Apply overhead data to justify and document protocol choices