664 Introduction to IoT Protocols

Why IoT Needs Specialized Protocols and Stack Architecture

Learning Objectives

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

Explain why traditional internet protocols are unsuitable for IoT devices
Identify the key constraints that drive IoT protocol design
Describe each layer of the IoT protocol stack
Map common IoT protocols to their respective layers
Understand the relationship between device classes and protocol selection

664.1 Why IoT Needs Specialized Protocols

Traditional internet protocols like HTTP over TCP/IP were designed for desktop computers and servers with abundant resources. IoT devices operate under fundamentally different constraints that require specialized protocol designs.

664.1.1 The Resource Constraint Challenge

%%{init: {'theme': 'base', 'themeVariables': { 'primaryColor': '#2C3E50', 'primaryTextColor': '#fff', 'primaryBorderColor': '#16A085', 'lineColor': '#E67E22', 'secondaryColor': '#16A085', 'tertiaryColor': '#E8F6F3'}}}%%
graph LR
    subgraph "Traditional Internet"
        PC["Desktop PC<br/>8GB RAM<br/>3GHz CPU<br/>Wall power"]
        Server["Server<br/>64GB RAM<br/>Multi-core<br/>Always on"]
    end

    subgraph "IoT Devices"
        Sensor["Sensor Node<br/>32KB RAM<br/>16MHz<br/>Battery years"]
        Constrained["Constrained MCU<br/>10KB RAM<br/>8MHz<br/>Coin cell"]
    end

    PC -->|"HTTP/TLS<br/>TCP/IPv4"| Server
    Sensor -->|"CoAP/DTLS<br/>UDP/6LoWPAN"| Gateway["Gateway"]
    Constrained -->|"Custom binary<br/>over LoRa"| Gateway

    style PC fill:#7F8C8D,stroke:#2C3E50
    style Server fill:#7F8C8D,stroke:#2C3E50
    style Sensor fill:#16A085,stroke:#2C3E50,color:#fff
    style Constrained fill:#E67E22,stroke:#2C3E50
    style Gateway fill:#2C3E50,stroke:#16A085,color:#fff

Figure 664.1: Resource comparison between traditional internet devices and IoT devices

{fig-alt=“Comparison diagram showing traditional internet devices (desktop PC with 8GB RAM, server with 64GB RAM) using HTTP/TCP versus IoT devices (sensor node with 32KB RAM, constrained MCU with 10KB RAM) using lightweight protocols like CoAP and custom binary over LoRa”}

Consider the dramatic differences between a web browser and a soil moisture sensor:

Resource	Web Browser	IoT Sensor	Ratio
RAM	8 GB	32 KB	250,000×
CPU	3 GHz	16 MHz	187×
Storage	500 GB SSD	256 KB Flash	2,000,000×
Power	150W (continuous)	50 mW (intermittent)	3,000×
Network	1 Gbps Ethernet	250 kbps wireless	4,000×
Expected lifetime	3-5 years	10-15 years	3-5×
Unit cost target	$500-2000	$1-20	25-2000×

For Beginners: Why Can’t IoT Devices Just Use HTTP?

Think about it this way: HTTP is like shipping a package in a big truck. The truck (HTTP header) is over 200 bytes, but your package (temperature reading) is only 4 bytes. You’re shipping 98% truck and 2% cargo!

HTTP overhead example:

GET /sensors/temp123/reading HTTP/1.1
Host: api.example.com
User-Agent: Mozilla/5.0
Accept: application/json
Connection: keep-alive
Content-Length: 4

25.5

That’s ~200 bytes of headers for a 4-byte temperature reading. On a 250 kbps wireless link, the headers alone take 6.4 milliseconds to transmit, consuming precious battery power.

CoAP equivalent:

[4 bytes header][4 bytes payload] = 8 bytes total

Same information, 25× smaller packet, 25× less energy to transmit!

664.1.2 RFC 7228: Constrained Node Classes

The IETF standardized device classification in RFC 7228 to help protocol designers understand target platforms:

Class	Data (RAM)	Code (Flash)	Example Devices
Class 0	<< 10 KB	<< 100 KB	RFID tags, simple sensors
Class 1	~10 KB	~100 KB	8-bit MCUs (ATmega328, STM32L0)
Class 2	~50 KB	~250 KB	32-bit MCUs (ESP32, nRF52840)
Full	> 250 KB	> 1 MB	Raspberry Pi, smartphones

Design Implications: - Class 0: Too constrained for IP; use raw protocols or proprietary - Class 1: Minimal IP stack (6LoWPAN + CoAP); no TLS, limited features - Class 2: Full IP stack possible; can run MQTT, TLS with constraints - Full: Standard protocols work; focus on power optimization

664.1.3 Key IoT Protocol Requirements

IoT protocols must address these fundamental challenges:

Minimal Overhead
- Small header sizes (4 bytes vs 40+ bytes)
- Efficient encoding (binary vs text)
- Compressed addresses and identifiers
Power Efficiency
- Connectionless operation (no keep-alives)
- Short transmissions (minimize radio-on time)
- Sleep-friendly design (no polling)
Unreliable Link Tolerance
- Graceful degradation under packet loss
- Simple retransmission mechanisms
- No complex state machines
Scalability
- Support for millions of devices
- Efficient addressing (IPv6)
- Hierarchical network architectures

664.2 The IoT Protocol Stack

IoT systems use a layered protocol architecture similar to the traditional TCP/IP model, but with adaptations for constrained environments:

%%{init: {'theme': 'base', 'themeVariables': { 'primaryColor': '#2C3E50', 'primaryTextColor': '#fff', 'primaryBorderColor': '#16A085', 'lineColor': '#16A085', 'secondaryColor': '#E67E22', 'tertiaryColor': '#E8F6F3', 'clusterBkg': '#E8F6F3', 'clusterBorder': '#16A085', 'fontSize': '12px'}}}%%
graph TB
    subgraph "Application Layer (7)"
        App["<b>Application Protocols</b><br/>CoAP • MQTT • HTTP • AMQP<br/><i>Message semantics & data exchange</i>"]
    end

    subgraph "Transport Layer (4)"
        Trans["<b>Transport Protocols</b><br/>UDP • TCP • DTLS • TLS<br/><i>End-to-end delivery & security</i>"]
    end

    subgraph "Network Layer (3)"
        Net["<b>Network Protocols</b><br/>IPv6 • IPv4 • RPL • 6LoWPAN*<br/><i>Addressing & routing</i>"]
    end

    subgraph "Data Link Layer (2)"
        Link["<b>Link Protocols</b><br/>IEEE 802.15.4 • Bluetooth LE • Wi-Fi<br/>LoRaWAN • NB-IoT • Ethernet<br/><i>Framing & local addressing</i>"]
    end

    subgraph "Physical Layer (1)"
        Phys["<b>Physical Specifications</b><br/>2.4 GHz • Sub-GHz • LTE bands<br/><i>Radio characteristics</i>"]
    end

    App --> Trans --> Net --> Link --> Phys

    style App fill:#2C3E50,stroke:#16A085,stroke-width:3px,color:#fff
    style Trans fill:#16A085,stroke:#2C3E50,stroke-width:2px,color:#fff
    style Net fill:#E67E22,stroke:#2C3E50,stroke-width:2px
    style Link fill:#7F8C8D,stroke:#2C3E50,stroke-width:2px,color:#fff
    style Phys fill:#34495E,stroke:#2C3E50,stroke-width:2px,color:#fff

Figure 664.2: IoT protocol stack layers with representative protocols

{fig-alt=“Layered IoT protocol stack diagram showing Application layer (CoAP, MQTT, HTTP, AMQP), Transport layer (UDP, TCP, DTLS, TLS), Network layer (IPv6, IPv4, RPL, 6LoWPAN), Data Link layer (802.15.4, BLE, Wi-Fi, LoRaWAN, NB-IoT), and Physical layer (2.4GHz, Sub-GHz, LTE bands)”}

*Note: 6LoWPAN is technically an adaptation layer between Network and Data Link, providing header compression and fragmentation.

664.2.1 Layer-by-Layer Protocol Mapping

Layer	Traditional Internet	IoT Protocols	Key Difference
Application	HTTP, SMTP, FTP	CoAP, MQTT, AMQP	Smaller headers, binary encoding
Transport	TCP, TLS	UDP, DTLS	Connectionless for power saving
Network	IPv4	IPv6, 6LoWPAN	Compressed headers, larger address space
Data Link	Ethernet, Wi-Fi	802.15.4, BLE, LoRa	Low-power radio technologies
Physical	Cat5/6, 802.11	Sub-GHz, 2.4 GHz	Optimized for range/power trade-offs

664.2.2 Protocol Stack Interaction

Understanding how protocols interact across layers is essential for IoT system design:

%%{init: {'theme': 'base', 'themeVariables': { 'primaryColor': '#2C3E50', 'primaryTextColor': '#fff', 'primaryBorderColor': '#16A085', 'lineColor': '#16A085', 'secondaryColor': '#E67E22', 'tertiaryColor': '#E8F6F3'}}}%%
sequenceDiagram
    participant App as Application<br/>(CoAP)
    participant Trans as Transport<br/>(UDP)
    participant Net as Network<br/>(IPv6)
    participant Adapt as Adaptation<br/>(6LoWPAN)
    participant Link as Data Link<br/>(802.15.4)

    Note over App: Sensor reading: 4 bytes
    App->>Trans: CoAP message (8 bytes)
    Trans->>Net: UDP datagram (16 bytes)
    Net->>Adapt: IPv6 packet (56 bytes)
    Adapt->>Link: 6LoWPAN frame (18 bytes compressed!)
    Link->>Link: 802.15.4 frame (43 bytes total)

    Note over Link: Transmitted over radio

Figure 664.3: Protocol encapsulation showing how 6LoWPAN compression reduces packet size

{fig-alt=“Sequence diagram showing protocol encapsulation from CoAP application layer through UDP, IPv6, 6LoWPAN adaptation, and 802.15.4 data link, illustrating how 6LoWPAN compression dramatically reduces the 56-byte IPv6 packet to 18 bytes compressed”}

Key Insight: Without 6LoWPAN compression, the IPv6 header alone (40 bytes) would exceed the usable payload of an 802.15.4 frame (102 bytes), leaving only 62 bytes for actual data. With compression, we save 38 bytes, dramatically improving efficiency.

664.3 Common IoT Protocol Stacks

Different deployment scenarios call for different protocol combinations. Here are the most common IoT protocol stacks:

664.3.1 Stack 1: Constrained Sensor Network (802.15.4)

Use Case: Indoor sensor mesh (temperature, humidity, occupancy)

┌─────────────────────────────────────┐
│ Application: CoAP (4 bytes)         │
├─────────────────────────────────────┤
│ Transport: UDP (8 bytes)            │
├─────────────────────────────────────┤
│ Network: IPv6 (40→6 bytes via       │
│         6LoWPAN compression)        │
├─────────────────────────────────────┤
│ Adaptation: 6LoWPAN                 │
├─────────────────────────────────────┤
│ Data Link: IEEE 802.15.4            │
│ (25 bytes MAC header)               │
├─────────────────────────────────────┤
│ Physical: 2.4 GHz, 250 kbps         │
└─────────────────────────────────────┘

Total overhead: ~39 bytes (with compression)
Payload efficiency: ~10% for 4-byte readings

664.3.2 Stack 2: Wi-Fi Connected Device

Use Case: Smart home device (thermostat, camera)

┌─────────────────────────────────────┐
│ Application: MQTT (2-4 bytes)       │
├─────────────────────────────────────┤
│ Transport: TCP (20 bytes)           │
│            + TLS (5-40 bytes)       │
├─────────────────────────────────────┤
│ Network: IPv4 (20 bytes)            │
│          or IPv6 (40 bytes)         │
├─────────────────────────────────────┤
│ Data Link: IEEE 802.11 (Wi-Fi)      │
│ (34 bytes MAC header)               │
├─────────────────────────────────────┤
│ Physical: 2.4/5 GHz, 54-600 Mbps    │
└─────────────────────────────────────┘

Total overhead: ~80-140 bytes
Best for: mains-powered, high-bandwidth

664.3.3 Stack 3: LPWAN Remote Sensor

Use Case: Agricultural monitoring, asset tracking

┌─────────────────────────────────────┐
│ Application: Custom binary or CoAP  │
├─────────────────────────────────────┤
│ (No IP layer - LoRaWAN provides     │
│  addressing and security)           │
├─────────────────────────────────────┤
│ Data Link: LoRaWAN MAC (13 bytes)   │
├─────────────────────────────────────┤
│ Physical: Sub-GHz (868/915 MHz)     │
│           0.3-50 kbps               │
└─────────────────────────────────────┘

Total overhead: ~13 bytes
Range: 2-15 km
Battery life: 5-15 years

664.4 Protocol Categories by Function

IoT protocols can be grouped by their primary function in the communication system:

664.4.1 Communication Pattern Protocols

Pattern	Protocol	Description	Best For
Request-Response	CoAP, HTTP	Client requests, server responds	Device configuration, data retrieval
Publish-Subscribe	MQTT, AMQP	Publishers send to topics, subscribers receive	Telemetry, event-driven systems
Push Notifications	WebSocket, CoAP Observe	Server pushes updates to clients	Real-time alerts, dashboards

664.4.2 Transport Protocols

Protocol	Connection	Reliability	Overhead	Power	Security
UDP	Connectionless	Best-effort	8 bytes	Low	None (add DTLS)
TCP	Connection-oriented	Guaranteed	20+ bytes	High	None (add TLS)
QUIC	Connection-oriented	Guaranteed	Variable	Medium	Built-in

664.4.3 Network Protocols

Protocol	Addresses	Header Size	Compression	IoT Suitability
IPv4	4.3 billion	20 bytes	No	Limited (NAT required)
IPv6	340 undecillion	40 bytes	Via 6LoWPAN	Excellent
6LoWPAN	IPv6 (compressed)	2-6 bytes	Yes	Essential for 802.15.4

664.5 Deployment Scenarios

Understanding where each protocol stack fits helps in system design:

%%{init: {'theme': 'base', 'themeVariables': { 'primaryColor': '#2C3E50', 'primaryTextColor': '#fff', 'primaryBorderColor': '#16A085', 'lineColor': '#E67E22', 'secondaryColor': '#16A085', 'tertiaryColor': '#E8F6F3', 'clusterBkg': '#E8F6F3', 'clusterBorder': '#16A085', 'fontSize': '11px'}}}%%
graph TB
    subgraph "Smart Home"
        SH_Sensor["Zigbee Sensor<br/>802.15.4 + 6LoWPAN + CoAP"]
        SH_Hub["Hub/Gateway<br/>Wi-Fi + MQTT"]
        SH_Cloud["Cloud<br/>HTTP/MQTT"]
    end

    subgraph "Smart Agriculture"
        SA_Sensor["LoRa Sensor<br/>LoRaWAN MAC"]
        SA_GW["LoRa Gateway<br/>IP backhaul"]
        SA_Server["Network Server<br/>MQTT"]
    end

    subgraph "Fleet Tracking"
        FT_Tracker["GPS Tracker<br/>NB-IoT + MQTT"]
        FT_Cell["Cellular Tower<br/>LTE infrastructure"]
        FT_Cloud["Fleet Cloud<br/>HTTPS API"]
    end

    SH_Sensor -->|"Mesh"| SH_Hub
    SH_Hub -->|"Internet"| SH_Cloud

    SA_Sensor -->|"LoRa 2-15km"| SA_GW
    SA_GW -->|"Internet"| SA_Server

    FT_Tracker -->|"Cellular"| FT_Cell
    FT_Cell -->|"Internet"| FT_Cloud

    style SH_Sensor fill:#16A085,stroke:#2C3E50,color:#fff
    style SA_Sensor fill:#E67E22,stroke:#2C3E50
    style FT_Tracker fill:#7F8C8D,stroke:#2C3E50,color:#fff

Figure 664.4: IoT deployment scenarios showing protocol selection by use case

{fig-alt=“Three IoT deployment scenarios: Smart Home using Zigbee sensors with 6LoWPAN to hub with MQTT to cloud, Smart Agriculture using LoRa sensors to gateway to MQTT server, and Fleet Tracking using NB-IoT GPS trackers through cellular to cloud API”}

Knowledge Check: Protocol Stack

Question: A Class 1 IoT device (10KB RAM, 100KB Flash) needs to send temperature readings. Which protocol stack is most appropriate?

Explanation: Class 1 devices have ~10KB RAM, which limits protocol stack choices. CoAP/DTLS over UDP/6LoWPAN is specifically designed for constrained devices: CoAP has a 4-byte header (vs HTTP’s 200+ bytes), UDP is connectionless (no TCP state), and 6LoWPAN compresses IPv6 headers. A full TLS stack typically requires 20-40KB RAM alone, making options A and C unsuitable. While option D would work, it doesn’t provide IP connectivity for internet integration.

664.6 Common IoT Acronyms Reference

Acronym	Full Name	Layer	Purpose
6LoWPAN	IPv6 over Low-power WPAN	Adaptation	IPv6 header compression
AMQP	Advanced Message Queuing Protocol	Application	Enterprise messaging
CoAP	Constrained Application Protocol	Application	RESTful for constrained devices
DTLS	Datagram Transport Layer Security	Transport	Secure UDP
HTTP	Hypertext Transfer Protocol	Application	Web protocol
ICMPv6	Internet Control Message Protocol v6	Network	Network diagnostics
IPv6	Internet Protocol version 6	Network	128-bit addressing
LLN	Low-Power and Lossy Network	-	Constrained network type
LoRaWAN	Long Range WAN	Data Link	LPWAN protocol
LPWAN	Low-Power Wide Area Network	-	Network category
MQTT	Message Queue Telemetry Transport	Application	Pub/sub messaging
NB-IoT	Narrowband IoT	Data Link	Cellular LPWAN
RPL	IPv6 Routing Protocol for LLN	Network	IoT routing
TLS	Transport Layer Security	Transport	Secure TCP
UDP	User Datagram Protocol	Transport	Connectionless transport
WPAN	Wireless Personal Area Network	-	Network category

664.7 Summary

IoT protocols are specifically designed for resource-constrained devices and lossy networks:

Key Takeaways

Why IoT-Specific Protocols: - Traditional protocols (HTTP, IPv4) designed for desktop computers with GB of RAM - IoT devices have KB of RAM, MHz CPUs, and battery constraints - Need: Lightweight, power-efficient protocols with small overhead

Protocol Stack Layers: - Application: CoAP (RESTful), MQTT (pub-sub), AMQP (queuing) - Transport: UDP (connectionless, low power), TCP (reliable, higher power) - Network: IPv6 with 6LoWPAN compression for constrained networks - Data Link: 802.15.4, BLE, LoRaWAN, Wi-Fi depending on range/power needs

Device Classification (RFC 7228): - Class 0 (~10KB): Too constrained for IP, use raw protocols - Class 1 (~100KB): Minimal IP stack, CoAP/UDP/6LoWPAN - Class 2 (~250KB): Full IP stack possible, can run MQTT/TLS - Full (>1MB): Standard protocols, focus on optimization

For Kids: Meet the Sensor Squad!

Protocols are like special languages that help IoT devices talk to each other!

664.7.1 The Sensor Squad Adventure: The Great Message Relay Race

One day, Signal Sam the Communication Expert had an important message to deliver: “The garden is too dry - please turn on the sprinklers!” The message came from Thermo the Temperature Sensor and Sunny the Light Sensor in the backyard.

But here’s the problem - Signal Sam couldn’t just shout the message! The message had to travel through the air, across the neighborhood, through the internet, and all the way to the cloud computer. That’s like trying to talk to someone on the other side of the world!

“Don’t worry,” said Signal Sam. “I know special languages called PROTOCOLS that help me talk to different helpers along the way!”

First, Signal Sam used Zigbee language to talk to the nearby router (like whispering to your neighbor). Then the router used Wi-Fi language to talk to the home gateway (like talking normally in your house). Finally, the gateway used Internet language to send the message to the cloud (like mailing a letter to someone far away).

Power Pete the Battery Manager was watching carefully. “Great job, Signal Sam! You used the smallest, lightest messages possible so you didn’t waste my battery energy. That’s why we use special IoT protocols instead of regular computer messages - they’re designed to save power!”

The cloud computer got the message and told the sprinklers to turn on. Mission accomplished!

664.7.2 Key Words for Kids

Word	What It Means
Protocol	A special language that devices use to talk to each other - like how you might speak English to friends and Spanish to grandma!
Wi-Fi	An invisible signal that carries messages through the air in your house, like magic mail floating around
The Cloud	Really big computers far away that store information and help your devices work together, like a super-smart helper in the sky
Packet	A tiny digital envelope that carries your message from one place to another

664.7.3 Try This at Home!

Play the Telephone Game with Rules! This shows how protocols work.

Get 4-5 family members to stand in a line
The first person whispers a message to the second person
But here’s the protocol (rule): Each person must say “Message received!” before passing it on
See if the message arrives correctly at the end!

What you learned: The “Message received!” rule is like a protocol - it makes sure each person got the message correctly before passing it on. IoT devices use similar rules to make sure messages don’t get lost!

Bonus Challenge: Try the game without the “Message received!” rule. Does the message get mixed up more often? That’s why protocols matter!

664.8 What’s Next?

Continue to IoT Protocols: Stack Architecture for a detailed layer-by-layer breakdown of the IoT protocol stack, protocol categories, and real-world understanding checks.

For hands-on implementation, see IoT Protocols: Labs and Selection.