22  IoT Protocols: Fundamentals

In 60 Seconds

IoT devices have too little memory, power, and bandwidth for standard internet protocols. The IoT protocol stack uses lightweight alternatives at each layer: CoAP (REST over UDP, 4-byte header), MQTT (publish-subscribe via broker), 6LoWPAN (compresses 40-byte IPv6 headers to 2–7 bytes), and low-power radios like 802.15.4 and BLE. This chapter is a roadmap to three sub-chapters covering introduction, stack architecture, and real-world scenarios.

MVU – Minimum Viable Understanding

IoT devices are too resource-constrained (kilobytes of RAM, milliwatts of power) to use standard internet protocols like HTTP/TCP, so the IoT ecosystem has developed a specialized protocol stack: CoAP (lightweight REST over UDP), MQTT (publish-subscribe messaging), 6LoWPAN (IPv6 header compression from 40 bytes to 2-7 bytes), and IPv6 (unique addressing for billions of devices). Choosing the right protocol at each layer – application, transport, network, and link – is the single most impactful architectural decision in any IoT system design.

Learning Objectives

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

• Explain why traditional internet protocols require adaptation for IoT
• Identify protocols at each layer of the IoT protocol stack
• Compare IPv4 and IPv6 addressing for IoT applications
• Describe the role of 6LoWPAN in constrained IoT networks
• Differentiate CoAP and MQTT application protocol architectures
• Map IoT protocols to the TCP/IP layer model
• Select appropriate protocols for different IoT deployment scenarios

Sensor Squad: How Do IoT Devices Talk to Each Other?

Sammy the Sensor wants to send a temperature reading to the cloud, but there is a problem – Sammy has tiny batteries and almost no memory! Think of it like this: if a big computer sends messages using a huge moving truck (HTTP), Sammy needs to use a tiny bicycle (CoAP) because the truck would use up all of Sammy’s energy in one trip.

Lila the Light Sensor explains: “We IoT devices have our own special language called a protocol stack. It is like layers of a sandwich – the bottom bread is the radio signal, the lettuce is the network address, the cheese is making sure the message arrives safely, and the top bread is the actual data like my light reading. Each layer has a job!”

Max the Motion Detector adds: “And the best part? With IPv6, every single one of us billions of sensors gets our own unique address – like every grain of sand on the beach having its own phone number!”

For Beginners: What Are IoT Protocols and Why Should I Care?

A protocol is simply a set of rules for how devices communicate – like how humans agree to speak the same language in a conversation. The internet already has protocols (HTTP for web pages, TCP for reliable delivery), but IoT devices are so small and power-limited that they need lighter-weight alternatives.

Real-world analogy: Imagine you need to send a one-sentence message. You could write it in a formal business letter with letterhead, envelope, and registered mail (this is HTTP) – or you could send a text message (this is CoAP). Both deliver the message, but the text message uses far less “resources” (paper, postage, time). IoT protocols are the “text message” equivalent for devices.

The IoT protocol stack organizes these rules into layers, each responsible for one part of the communication:

1. Application layer – What the message says (CoAP, MQTT)
2. Transport layer – How it gets delivered reliably (UDP, TCP)
3. Network layer – How to find the destination address (IPv6, 6LoWPAN)
4. Link layer – How bits travel over the air (Bluetooth, Zigbee, LoRa)

If you are new to this topic, start with the Introduction chapter below and work your way up.

22.1 Chapter Overview

This chapter provides a comprehensive guide to IoT protocol fundamentals. The content has been organized into three focused chapters for easier learning:

22.1.1 Chapter Guide

Chapter	Topic	Key Content	Time
1	IoT Protocols: Introduction	Why IoT needs specialized protocols, device constraints, beginner content	15 min
2	IoT Protocols: Stack Architecture	Complete protocol stack, layer-by-layer breakdown, protocol categories, understanding checks	25 min
3	IoT Protocols: Scenarios and Interview Prep	System design, MQTT QoS, 6LoWPAN compression, troubleshooting, technical interviews	30 min

22.1.2 Quick Reference: Protocol Stack

Figure 22.1: Protocol Stack Overview

22.1.3 IoT Protocol Stack Layers

The following diagram illustrates how IoT-specific protocols map to each layer of the communication stack, with the key responsibilities and tradeoffs at each level:

22.1.4 Protocol Selection Decision Flow

Use this decision tree to select the right application protocol based on your IoT deployment requirements:

22.1.5 Key Concepts at a Glance

Concept	What It Does	Why It Matters
6LoWPAN	Compresses IPv6 headers from 40 to 2-7 bytes	Enables IPv6 on constrained 802.15.4 networks
CoAP	RESTful protocol over UDP with 4-byte header	10x more efficient than HTTP for IoT
MQTT	Publish-subscribe messaging over TCP	Scales to millions of devices via broker
IPv6	340 undecillion addresses	Every IoT device gets unique global address
RPL	Routing protocol for low-power lossy networks	Builds efficient multi-hop topologies
DTLS	TLS-equivalent security over UDP	Secures CoAP without TCP overhead

22.1.6 Learning Path Recommendations

For Beginners: Start with IoT Protocols: Introduction to understand why specialized protocols matter, including beginner-friendly explanations and the Sensor Squad section for kids.

For Practitioners: Jump to IoT Protocols: Stack Architecture for protocol selection decision trees and understanding checks with real-world scenarios.

For Interview Prep: Work through IoT Protocols: Scenarios and Interview Prep for technical deep-dives on MQTT QoS, 6LoWPAN compression, and system design questions.

Try It: Protocol Overhead Calculator

Adjust the payload size to see how header overhead differs across IoT protocols.

viewof payloadSize = Inputs.range([1, 256], {value: 4, step: 1, label: "Payload size (bytes)"})
viewof radioRate = Inputs.range([20, 1000], {value: 250, step: 10, label: "Radio bit rate (kbps)"})

{
  const protocols = [
    {name: "HTTP/REST", header: 200, transport: "TCP", transportHeader: 20, networkHeader: 40, color: "#E74C3C"},
    {name: "CoAP", header: 4, transport: "UDP", transportHeader: 8, networkHeader: 40, color: "#16A085"},
    {name: "MQTT (QoS 0)", header: 2, transport: "TCP", transportHeader: 20, networkHeader: 40, color: "#3498DB"},
    {name: "MQTT (QoS 1)", header: 4, transport: "TCP", transportHeader: 20, networkHeader: 40, color: "#E67E22"}
  ];

  const rows = protocols.map(p => {
    const totalPacket = p.header + p.transportHeader + p.networkHeader + payloadSize;
    const overhead = totalPacket - payloadSize;
    const efficiency = ((payloadSize / totalPacket) * 100).toFixed(1);
    const txTimeMs = ((totalPacket * 8) / (radioRate * 1000) * 1000).toFixed(3);
    return `<tr>
      <td style="color:${p.color};font-weight:bold">${p.name}</td>
      <td>${p.header} B</td>
      <td>${p.transport} (${p.transportHeader} B) + IP (${p.networkHeader} B)</td>
      <td><strong>${totalPacket} B</strong></td>
      <td>${efficiency}%</td>
      <td>${txTimeMs} ms</td>
    </tr>`;
  });

  const bestProtocol = protocols.reduce((a, b) => {
    const totalA = a.header + a.transportHeader + a.networkHeader + payloadSize;
    const totalB = b.header + b.transportHeader + b.networkHeader + payloadSize;
    return totalA < totalB ? a : b;
  });
  const bestTotal = bestProtocol.header + bestProtocol.transportHeader + bestProtocol.networkHeader + payloadSize;
  const httpTotal = 200 + 20 + 40 + payloadSize;
  const savings = ((1 - bestTotal / httpTotal) * 100).toFixed(0);

  return html`<table style="width:100%;border-collapse:collapse;font-size:0.9em">
    <thead><tr style="background:#2C3E50;color:white">
      <th style="padding:8px">Protocol</th>
      <th style="padding:8px">App Header</th>
      <th style="padding:8px">Lower Layers</th>
      <th style="padding:8px">Total Packet</th>
      <th style="padding:8px">Payload Efficiency</th>
      <th style="padding:8px">TX Time</th>
    </tr></thead>
    <tbody>${rows.join("")}</tbody>
  </table>
  <p style="margin-top:12px;padding:10px;background:#f0f9f4;border-left:4px solid #16A085;border-radius:4px">
    <strong>Result:</strong> For a ${payloadSize}-byte payload at ${radioRate} kbps, <strong style="color:#16A085">${bestProtocol.name}</strong> is the most efficient (${bestTotal} B total), saving <strong>${savings}%</strong> packet size vs HTTP.
  </p>`;
}

Try It: IoT Battery Life Estimator

Estimate how long a coin-cell battery lasts under different protocol and transmission scenarios.

viewof batteryCapacity = Inputs.range([100, 5000], {value: 2000, step: 100, label: "Battery capacity (mAh)"})
viewof txInterval = Inputs.range([1, 1440], {value: 15, step: 1, label: "TX interval (minutes)"})
viewof txCurrent = Inputs.range([5, 100], {value: 30, step: 1, label: "TX current (mA)"})
viewof sleepCurrent = Inputs.range([1, 100], {value: 5, step: 1, label: "Sleep current (\u00B5A)"})
viewof radioOverhead = Inputs.range([10, 500], {value: 100, step: 10, label: "Radio cycle overhead (ms)"})

{
  const txPerDay = Math.floor(1440 / txInterval);
  const protocols = [
    {name: "CoAP/UDP", packetBytes: 52, color: "#16A085"},
    {name: "MQTT QoS 0", packetBytes: 62, color: "#3498DB"},
    {name: "MQTT QoS 1", packetBytes: 64, color: "#E67E22"},
    {name: "HTTP/TCP", packetBytes: 260, color: "#E74C3C"}
  ];

  const results = protocols.map(p => {
    const txTimeMs = (p.packetBytes * 8) / 250 + radioOverhead;
    const txTimeSec = txTimeMs / 1000;
    const dailyTxSec = txPerDay * txTimeSec;
    const dailySleepSec = 86400 - dailyTxSec;
    const dailyTxMah = (txCurrent * dailyTxSec) / 3600;
    const dailySleepMah = (sleepCurrent / 1000 * dailySleepSec) / 3600;
    const dailyTotal = dailyTxMah + dailySleepMah;
    const lifeDays = batteryCapacity / dailyTotal;
    const lifeYears = (lifeDays / 365).toFixed(2);
    return {name: p.name, color: p.color, dailyTotal: dailyTotal.toFixed(4),
            lifeDays: Math.floor(lifeDays), lifeYears, txTimeMs: txTimeMs.toFixed(1)};
  });

  const maxLife = Math.max(...results.map(r => r.lifeDays));

  const bars = results.map(r => {
    const pct = Math.min((r.lifeDays / maxLife) * 100, 100);
    return `<div style="margin:6px 0">
      <div style="display:flex;align-items:center;gap:8px">
        <span style="width:120px;font-weight:bold;color:${r.color}">${r.name}</span>
        <div style="flex:1;background:#eee;border-radius:4px;height:24px">
          <div style="width:${pct}%;background:${r.color};border-radius:4px;height:24px;display:flex;align-items:center;padding-left:8px">
            <span style="color:white;font-size:0.85em;font-weight:bold">${r.lifeYears} years (${r.lifeDays} days)</span>
          </div>
        </div>
      </div>
    </div>`;
  });

  return html`<div style="padding:12px;background:#fafafa;border-radius:8px;border:1px solid #ddd">
    <p style="margin:0 0 8px"><strong>Transmissions per day:</strong> ${txPerDay} | <strong>Battery:</strong> ${batteryCapacity} mAh</p>
    ${bars.join("")}
    <p style="margin-top:12px;font-size:0.85em;color:#7F8C8D">
      Assumes 250 kbps radio, ${radioOverhead} ms radio cycle overhead, ${sleepCurrent} \u00B5A sleep current.
      Real battery life also depends on self-discharge, temperature, and duty cycle variability.
    </p>
  </div>`;
}

22.2 Knowledge Checks

Test your understanding of IoT protocol fundamentals before diving into the sub-chapters.

Common Pitfalls in IoT Protocol Selection

1. Using HTTP directly on constrained devices HTTP headers alone can exceed 200 bytes, which is larger than the entire payload capacity of an 802.15.4 frame (127 bytes). Always use CoAP or MQTT for devices with limited RAM and bandwidth.

2. Choosing TCP when UDP would suffice TCP’s three-way handshake, congestion control, and retransmission add significant overhead. For periodic sensor readings where occasional packet loss is acceptable, UDP-based CoAP is far more efficient. Reserve TCP (and MQTT) for scenarios where guaranteed delivery truly matters.

3. Ignoring 6LoWPAN when deploying IPv6 on 802.15.4 Without 6LoWPAN header compression, a single IPv6 header consumes 40 bytes of the 127-byte 802.15.4 frame – leaving almost no room for payload. Always deploy 6LoWPAN as the adaptation layer.

4. Confusing CoAP and MQTT use cases CoAP is request-response (like HTTP) and best for one-to-one device queries. MQTT is publish-subscribe and best for one-to-many data distribution. Using the wrong pattern leads to inefficient architectures.

5. Overlooking protocol security layers CoAP uses DTLS (over UDP), while MQTT uses TLS (over TCP). Forgetting to include the security layer in your protocol stack leaves devices vulnerable to eavesdropping and spoofing.

22.3 Videos

Protocol Stack Overview

Protocol Stack Overview

Lesson 4 — foundational networking concepts used across IoT protocols.

Application Protocols in Context

Application Protocols in Context

Lesson 4 — MQTT vs CoAP vs HTTP vs AMQP and when to use each.

Putting Numbers to It

When we say IoT devices are “constrained,” what does that mean quantitatively? Let’s calculate the impact of protocol overhead on a real sensor deployment:

Scenario: A temperature sensor with 32 KB RAM sends a 4-byte reading every 15 minutes over a 2000 mAh coin cell battery.

Memory footprint calculation: \[ \begin{aligned} \text{HTTP stack} &= 40\text{-}60\text{ KB (libcurl + TLS)} \\ \text{MQTT stack} &= 20\text{-}30\text{ KB (Paho + TLS)} \\ \text{CoAP stack} &= 10\text{-}15\text{ KB (uCoAP + DTLS)} \\[0.5em] \text{Available for app logic:} \\ \text{With HTTP} &= 32 - 60 = \text{negative (won't fit!)} \\ \text{With MQTT} &= 32 - 30 = 2\text{ KB} \\ \text{With CoAP} &= 32 - 15 = 17\text{ KB} \end{aligned} \]

Energy impact over 1 year (96 transmissions/day, 250 kbps radio, 30 mA TX current):

Note: Real-world radio cycles include wake-up, synchronization, and RX windows (~100 ms total per cycle). Here we calculate TX-only energy to isolate the protocol overhead difference.

\[ \begin{aligned} \text{HTTP packet} &= 200\text{B header} + 4\text{B data} = 204\text{ bytes} \\ \text{TX time} &= \frac{204 \times 8}{250{,}000} = 6.528\text{ ms} \\ \text{Charge/TX} &= 30\text{ mA} \times 6.528\text{ ms} = 195.8\text{ }\mu\text{As} \\ \text{Daily charge} &= 96 \times 195.8\text{ }\mu\text{As} = 18{,}800\text{ }\mu\text{As} = 5.22\text{ }\mu\text{Ah} \\[1em] \text{CoAP packet} &= 4\text{B header} + 4\text{B data} = 8\text{ bytes} \\ \text{TX time} &= \frac{8 \times 8}{250{,}000} = 0.256\text{ ms} \\ \text{Charge/TX} &= 30\text{ mA} \times 0.256\text{ ms} = 7.68\text{ }\mu\text{As} \\ \text{Daily charge} &= 96 \times 7.68\text{ }\mu\text{As} = 737\text{ }\mu\text{As} = 0.205\text{ }\mu\text{Ah} \end{aligned} \]

Result: CoAP uses ~25x less TX energy than HTTP for the same payload. In practice, total radio-on time (wake-up, sync, RX windows) dominates – typically 50–200 ms per cycle at 10–30 mA. Using a conservative 100 ms total radio cycle:

\[ \begin{aligned} \text{HTTP daily energy} &= 96 \times 30\text{ mA} \times 107\text{ ms} = 308\text{ mAs} = 0.086\text{ mAh} \\ \text{CoAP daily energy} &= 96 \times 30\text{ mA} \times 100.3\text{ ms} = 289\text{ mAs} = 0.080\text{ mAh} \end{aligned} \]

The radio overhead dominates, but for high-frequency transmissions or large payloads, the protocol overhead compounds significantly. The key takeaway: minimizing packet size extends battery life, and CoAP’s 4-byte header vs HTTP’s 200+ byte header is a major advantage for constrained devices.

Common Mistake: Using TCP When Packet Loss Is Acceptable

The Problem: Many developers default to TCP because “reliability is always good,” not realizing TCP’s retransmission mechanism wastes energy when occasional loss is acceptable.

Real Scenario: A weather station sends temperature, humidity, and barometric pressure every 60 seconds. The developer uses TCP for “guaranteed delivery.”

Why This Fails:

TCP Connection Lifecycle for Each Reading:

1. SYN → 52 bytes (3-way handshake start)
2. SYN-ACK ← 52 bytes
3. ACK → 40 bytes (handshake complete)
4. Data (12 bytes payload) → 52 bytes (IP+TCP headers)
5. ACK ← 40 bytes
6. FIN → 40 bytes (connection teardown)
7. FIN-ACK ← 40 bytes
8. ACK → 40 bytes

Total: 356 bytes transmitted for 12 bytes of payload
Overhead: 344 bytes (96.6% waste)
Radio-on time: ~11 ms at 250 kbps

Alternative with UDP:

1. Data (12 bytes payload) → 40 bytes (IP+UDP headers)

Total: 52 bytes transmitted
Overhead: 40 bytes (76.9% of packet, but absolute savings massive)
Radio-on time: ~1.7 ms at 250 kbps
Energy savings: 11 / 1.7 = 6.5× less radio time

Real-World Impact:

• Battery-powered weather station with 2000 mAh battery
• Radio draw: 30 mA TX, 25 mA RX
• TCP: 356 bytes x 8 / 250,000 = 11.4 ms radio time per reading (TX+RX)
• UDP: 52 bytes x 8 / 250,000 = 1.66 ms radio time per reading (TX only)

Readings per day: 1,440
TCP radio time/day: 1,440 × 11.4 ms = 16.4 sec → ~0.12 mAh (TX+RX)
UDP radio time/day: 1,440 × 1.66 ms = 2.4 sec → ~0.02 mAh (TX only)

Radio overhead ratio: TCP uses ~6.9× more radio time than UDP

In practice, total per-reading energy includes wake-up and sync overhead (~100 ms), so the absolute battery drain is higher. But the relative savings of UDP over TCP compound over millions of readings.

When Loss Is Actually Fine:

A weather station sends 1,440 readings/day. If 3% are lost (43 readings): - Still have 1,397 readings (one every 61.7 seconds instead of 60) - Any cloud charting system interpolates missing points - Next reading arrives in <2 minutes anyway

When TCP Is Necessary:

• Firmware updates (every byte must arrive)
• Device configuration changes (commands can’t be lost)
• Historical data retrieval (query-response needs all data)

The Fix: Use UDP + application-level sequence numbers. If consumer notices gaps, it can request retransmission of specific missing packets.

import struct, socket

# Simple UDP with sequence tracking
SERVER, PORT = "192.168.1.100", 5683
sock = socket.socket(socket.AF_INET, socket.SOCK_DGRAM)

class UDPWithSequence:
    def __init__(self):
        self.seq = 0

    def send_reading(self, temp, humidity, pressure):
        self.seq += 1
        # Pack: sequence (uint32) + 3 floats = 16 bytes total
        packet = struct.pack('!Ifff', self.seq, temp, humidity, pressure)
        sock.sendto(packet, (SERVER, PORT))
        # No waiting for ACK = instant return, ~6× less radio time

Lesson: TCP is a transport layer solution to network layer unreliability. If your application layer tolerates loss, using TCP wastes energy solving a problem you don’t have.

Matching Exercise: IoT Protocol Stack Layers

Ordering Exercise: Protocol Selection by Device Constraint

Label the Diagram

Code Challenge

22.4 Summary

IoT protocol selection is a foundational architectural decision that cascades through every aspect of system design – from device hardware requirements to cloud integration patterns. The key takeaways from this chapter are:

Principle	Details
Constrained devices need constrained protocols	Devices with kilobytes of RAM cannot run HTTP/TCP stacks designed for servers with gigabytes of memory
Each layer has IoT-optimized alternatives	CoAP replaces HTTP, UDP replaces TCP (where possible), 6LoWPAN adapts IPv6, and low-power radios replace Ethernet/Wi-Fi
Protocol choice depends on communication pattern	Request-response (CoAP) vs. publish-subscribe (MQTT) vs. enterprise messaging (AMQP)
Header compression is essential	6LoWPAN compresses IPv6’s 40-byte header to 2-7 bytes, making IPv6 viable on 802.15.4 networks
Security must be built into the stack	DTLS for CoAP/UDP, TLS for MQTT/TCP – never deploy IoT without encrypted transport

22.5 Concept Relationships

Understanding how IoT protocol fundamentals interconnect:

• Device constraints (32KB RAM, battery power) eliminate certain protocol stacks — HTTP/TCP too heavy, forces CoAP/UDP alternatives
• Layer dependencies flow bottom-up: Physical layer range determines data link technology, which constrains network layer MTU, affecting transport and application choices
• Header compression (6LoWPAN) enables network layer (IPv6) on constrained links (802.15.4) — without compression, 40-byte header exceeds frame capacity
• Communication patterns (request-response vs pub-sub) span application and transport layers — CoAP/UDP for one-to-one, MQTT/TCP for many-to-many
• Protocol selection is not independent per-layer — choices cascade: battery constraint → UDP → CoAP → 6LoWPAN → 802.15.4 forms coherent stack

22.6 What’s Next?

Direction	Chapter	Description
Start	IoT Protocols: Introduction	Why IoT needs specialised protocols
Then	IoT Protocols: Stack Architecture	Layer-by-layer protocol breakdown
Then	IoT Protocols: Scenarios and Interview Prep	System design and technical deep-dives

Related Chapters

Sub-Chapters:

• IoT Protocols: Introduction - Why IoT needs specialized protocols
• IoT Protocols: Stack Architecture - Layer-by-layer breakdown
• IoT Protocols: Scenarios and Interview Prep - System design questions

Deep Dives:

• Application Layer Protocols - CoAP vs MQTT comparison
• IoT Protocols Labs and Selection - Hands-on protocol implementation and selection frameworks
• IoT Protocols Review - Comprehensive protocol comparison and assessment

Application Protocols:

• MQTT Fundamentals - Lightweight pub/sub messaging for IoT
• CoAP Fundamentals and Architecture - RESTful protocol for constrained devices
• Application Protocols - HTTP, MQTT, CoAP, AMQP comparison

Network Layer:

• 6LoWPAN Fundamentals and Architecture - IPv6 header compression for 802.15.4
• IPv6 for IoT - IPv6 addressing and deployment

Link Layer Technologies:

• 802.15.4 Fundamentals - Low-power wireless MAC and PHY
• Wi-Fi Fundamentals and Standards - Wi-Fi for IoT applications
• Bluetooth Fundamentals - BLE for personal area networks

Foundational Concepts:

• Layered Models Fundamentals - OSI and TCP/IP model foundations
• Networking Basics - Core networking principles
• LPWAN Fundamentals - Wide-area connectivity

Learning Resources:

• Simulations Hub - Interactive protocol demonstrations
• Videos Hub - Protocol stack video tutorials