By the end of this section, you will be able to:
A protocol stack is like a layer cake where each layer has a specific job. The bottom layer handles the physical radio signal, the middle layers handle addressing and routing, and the top layer handles your actual application data. Understanding how these layers fit together helps you see why IoT systems are built the way they are.
“Let me walk you through my entire protocol stack,” said Sammy the Sensor. “At the very bottom, my radio operates at 2.4 GHz – that is the Physical layer. Above that, I use IEEE 802.15.4 for my Data Link layer, which handles how I share the radio channel.”
“Then comes the Network layer,” continued Max the Microcontroller. “Sammy uses IPv6 with 6LoWPAN compression to squeeze those big 40-byte headers into just 6 bytes. RPL routing helps his messages hop through the mesh to reach the gateway.”
Lila the LED pointed to the Transport layer. “UDP keeps things lightweight – only 8 bytes of overhead. TCP would add 20+ bytes and need a handshake first. For a battery sensor sending 4 bytes of data, UDP is the obvious choice.”
“And at the top, the Application layer,” said Bella the Battery. “CoAP for constrained devices like Sammy, MQTT for always-on devices like Lila. Each layer in the stack was designed with IoT constraints in mind – limited power, limited memory, limited bandwidth. The whole stack works together to get tiny sensor readings from the field to the cloud as efficiently as possible!”
Before diving into this chapter, you should be familiar with:
Think of the IoT protocol stack like building a house from foundation to roof:
Physical Layer (Foundation): The radio waves carrying bits through the air. Like the ground your house sits on, it determines what frequencies you use (2.4 GHz Wi-Fi or Sub-GHz LoRa) and how fast bits flow (250 kbps 802.15.4 vs 1 Gbps Wi-Fi).
Data Link Layer (Framing): Organizes bits into frames with addresses. Like the walls dividing rooms, this layer uses MAC addresses to identify devices and handles collision avoidance (CSMA/CA for 802.15.4, time-slotting for BLE).
Network Layer (Routing): Gets packets from source to destination across multiple hops. Like roads connecting houses in a neighborhood, IPv6 provides global addressing and RPL routing finds paths through mesh networks.
Transport Layer (Reliability): Ensures data arrives correctly. Like delivery confirmation for packages, UDP provides fast unreliable delivery while TCP guarantees ordered arrival at the cost of overhead.
Application Layer (User Services): The protocols your IoT application actually uses. Like the furniture and appliances in your house, this is where CoAP provides REST-like sensor access and MQTT handles telemetry pub/sub.
Key Insight: Each layer adds a header (overhead). A 4-byte sensor reading can require 56 bytes total with IPv6/UDP/CoAP, or just 14 bytes with 6LoWPAN compression – that is why layer-by-layer optimization matters for battery life.
Protocol overhead accumulates across all layers of the stack.
For a 4-byte sensor payload without compression: - IPv6 header: 40 bytes - UDP header: 8 bytes - CoAP header: 4 bytes - Total overhead: \(40 + 8 + 4 = 52\) bytes - Total packet: \(52 + 4 = 56\) bytes - Efficiency: \(\frac{4}{56} = 7.1\%\) (93% is overhead!)
With 6LoWPAN compression: - 6LoWPAN compressed IPv6: 2 bytes (inline context) - UDP compressed: 4 bytes (port compression) - CoAP header: 4 bytes - Total overhead: \(2 + 4 + 4 = 10\) bytes - Total packet: \(10 + 4 = 14\) bytes - Efficiency: \(\frac{4}{14} = 28.6\%\) (4× better)
For a battery sensor transmitting 1,000 messages/day, 6LoWPAN saves \((56 - 14) \times 1{,}000 = 42{,}000\) bytes/day. Over a year, that is \(42{,}000 \times 365 \approx 15.3\) MB saved per sensor. At 250 kbps (802.15.4), this reduces radio-on time by roughly 8 minutes per year – a modest saving per transmission that compounds significantly across thousands of devices and multi-year deployments.
This variant helps you select protocols based on your deployment scenario:
This decision tree guides you through common IoT deployment scenarios to recommended protocol stacks.
Application Layer (What applications use): - CoAP: RESTful for constrained devices (UDP-based) - MQTT: Publish-subscribe messaging (TCP-based) - HTTP: Web APIs (via gateways, not directly on sensors) - AMQP: Enterprise messaging - XMPP: Extensible messaging (less common for IoT)
Transport Layer (How data is transported): - UDP: Connectionless, lightweight, unreliable - TCP: Connection-oriented, reliable, higher overhead - DTLS: Secure UDP (TLS for datagrams)
Network Layer (How packets are routed): - IPv6: 128-bit addresses (IoT standard) - IPv4: 32-bit addresses (legacy, exhausted) - ICMPv6: Network diagnostics - RPL: Routing for low-power lossy networks
Adaptation Layer (How protocols adapt to constraints): - 6LoWPAN: IPv6 header compression for 802.15.4 - Thread: IPv6-based mesh (uses 6LoWPAN)
Data Link Layer (How devices access medium): - IEEE 802.15.4: Low-power wireless (Zigbee, Thread) - Bluetooth LE: Short-range personal area network - LoRaWAN: Long-range, low-power WAN - Wi-Fi (802.11): Local area network - Cellular (NB-IoT, LTE-M): Wide area network
Physical Layer (How bits are transmitted): - Radio: 2.4 GHz (Wi-Fi, BLE, Zigbee), Sub-GHz (LoRa, Z-Wave) - Wired: Ethernet, I2C, SPI, RS-232
| Protocol | Header Size | Transport | Pattern | Best For |
|---|---|---|---|---|
| CoAP | 4 bytes | UDP | Request-Response | Battery devices, M2M |
| MQTT | 2 bytes | TCP | Publish-Subscribe | Telemetry, dashboards |
| HTTP | 200+ bytes | TCP | Request-Response | Web APIs, gateways |
| AMQP | Variable | TCP | Queue-based | Enterprise messaging |
| 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) |
| DTLS | Connectionless | Best-effort | 13+ bytes | Medium | Built-in |
| TLS | Connection-oriented | Guaranteed | 5-40 bytes | High | Built-in |
| Protocol | Address Size | Header Size | Compression | IoT Suitability |
|---|---|---|---|---|
| IPv4 | 32 bits | 20 bytes | None | Limited (NAT) |
| IPv6 | 128 bits | 40 bytes | Via 6LoWPAN | Excellent |
| 6LoWPAN | 128 bits | 2-7 bytes | Yes | Essential for 802.15.4 |
| Protocol | Range | Data Rate | Power | Topology |
|---|---|---|---|---|
| 802.15.4 | 10-100m | 250 kbps | Very Low | Star, Mesh |
| BLE | 10-100m | 1-2 Mbps | Low | Star, Mesh |
| Wi-Fi | 50-100m | 10-1000 Mbps | High | Star |
| LoRaWAN | 2-15 km | 0.3-50 kbps | Very Low | Star |
| NB-IoT | Cellular | 20-250 kbps | Low | Star |
Scenario: You’re deploying 500 battery-powered soil moisture sensors across a 200-acre farm. Each sensor uses an IEEE 802.15.4 radio and has 32KB RAM. Sensors must transmit 50-byte readings every 30 minutes to a cloud server for 5+ years without battery replacement.
Think about:
Key Insight: CoAP/UDP/6LoWPAN compression reduces the protocol overhead from 48 bytes (IPv6 40 bytes + UDP 8 bytes) to just 6 bytes (6LoWPAN compressed). This means:
Why CoAP Stack Wins:
Why 6LoWPAN is essential:
Why CoAP over MQTT:
For 50-byte sensor reading:
CoAP (UDP):
- 4-byte header + 50-byte payload = 54 bytes
- No connection setup (UDP)
- Confirmable mode for reliability
- Perfect for infrequent readings
MQTT (TCP):
- Requires TCP connection (3-way handshake = 3 packets)
- TCP header per packet (20 bytes)
- MQTT CONNECT sequence (multiple packets)
- Keep-alive overhead
- Better for continuous streaming, not periodic readingsRAM Comparison:
Protocol RAM Required 32KB Fit?
CoAP 2-10 KB Yes
MQTT 10-30 KB Tight
HTTP 50-100 KB No
AMQP 100+ KB NoWhy other options fail:
A - HTTP/TCP/IPv4:
C - MQTT/TCP/IPv6:
D - AMQP/TCP/IPv4:
Scenario: A steel mill deploys 500 temperature sensors monitoring blast furnaces. Each sensor transmits 4-byte readings every second (43.2 million readings/day total). A central control room needs to display data on multiple dashboards, log all readings, and trigger alarms when temperatures exceed thresholds—all with <2 second latency.
Think about:
Key Insight: MQTT’s persistent connections reduce network overhead by 75% compared to per-request protocols:
MQTT Wins Because:
1. Persistent TCP Connection:
CoAP/HTTP (per-message overhead):
Each message: DNS lookup + TCP handshake + Request + Response
500 sensors x 4 packets = 2,000 packets/second overhead!
MQTT (persistent connection):
Initial: Connect once per sensor (500 connections)
Ongoing: PUBLISH packet only (2-byte header + payload)
500 sensors x 1 packet = 500 packets/second (75% reduction)2. Pub/Sub Pattern:
Topics:
sensors/temp/line1/machine001sensors/temp/line1/machine002Subscribers can use wildcards:
sensors/temp/# (all temperatures)sensors/temp/line1/+ (line1 only)3. QoS Levels:
QoS 0 (At most once): Fire-and-forget (lowest overhead)
- Perfect for high-frequency sensor data
- Missing one reading out of 86,400/day is acceptable
QoS 1 (At least once): Acknowledged delivery
- For critical alerts
- Slightly more overheadPerformance Comparison:
Verify Your Understanding:
sensors/temp/#) eliminate the need for application-level filtering that HTTP would require?Scenario: A city IT department deploys 10,000 parking sensors across downtown. Each sensor reports status changes (occupied/vacant) ~5 times/day plus monthly battery level. Sensors use NB-IoT cellular ($0.50/MB data). The city already has REST API infrastructure for their web portal and mobile app, but needs to minimize cellular data costs for 5-year sensor deployment.
Think about:
Key Insight: CoAP with HTTP proxy reduces cellular data costs by $900,000 over 5 years while maintaining REST API compatibility:
Why CoAP + Proxy Architecture Wins:
Architecture:
Benefits:
1. Sensor Side (CoAP):
- Minimal code footprint (~10KB vs ~50KB for HTTP)
- Low power (UDP, no TCP handshake)
- Small messages (4-byte header vs 300+ for HTTP)
- Perfect for NB-IoT's bursty nature
2. Backend Side (Proxy):
- Translates CoAP to HTTP seamlessly
- Existing REST APIs unchanged
- Single point of protocol translation
- Can add caching, aggregationCost Analysis (10,000 sensors, 5 years):
CoAP+Proxy HTTP Direct MQTT
Sensor RAM 16 KB 64 KB 32 KB
Sensor cost $15 $25 $20
Data/msg ~50 bytes ~500 bytes ~60 bytes
Monthly data 1 MB 10 MB 1.2 MB
NB-IoT cost/month $0.50 $2.00 $0.60
Backend change Proxy ($500) None Broker ($2K)
5-Year TCO:
Sensors: $150,000 $250,000 $200,000
Connectivity: $300,000 $1,200,000 $360,000
Backend: $500 $0 $2,000
------------------------------------------------------------
TOTAL: $450,500 $1,450,000 $562,000The following AI-generated diagrams provide additional perspectives on IoT protocol concepts.
When selecting a protocol stack, engineers often focus on individual protocol features but overlook the cumulative cost across all five layers. This worked example compares the total cost of ownership for three common IoT protocol stacks deployed at scale.
Scenario: A utility company deploys 10,000 smart water meters across a metropolitan area. Each meter transmits a 16-byte consumption reading every hour (24 readings/day). Meters must operate for 10 years on a single battery and survive outdoor conditions (-20 to 55 C).
Physical: LoRa radio (SX1276, $3.50/unit)
Data Link: LoRaWAN Class A (free spectrum)
Network: IPv6/6LoWPAN (no per-device cost)
Transport: UDP (8-byte header)
Application: CoAP (4-byte header)
Per-message overhead: 8 + 4 = 12 bytes + 16 payload = 28 bytes
Daily data: 28 bytes x 24 = 672 bytes/device
Monthly data: 20 KB/device
Gateway cost: 25 gateways x $1,500 = $37,500
Spectrum cost: $0 (unlicensed ISM band)
Battery life: 12+ years (Class A sleep mode)Physical: NB-IoT modem (BC95, $5.50/unit)
Data Link: NB-IoT (licensed spectrum)
Network: IPv6 (carrier-managed)
Transport: UDP (8-byte header)
Application: CoAP (4-byte header)
Per-message overhead: 12 bytes + 16 payload = 28 bytes
Daily data: 672 bytes/device (same as Stack A)
Monthly data: 20 KB/device
Gateway cost: $0 (uses existing cellular infrastructure)
Spectrum cost: $0.30/device/month (carrier plan)
Battery life: 10+ years (eDRX + PSM)Physical: Wi-Fi radio (ESP32, $2.50/unit)
Data Link: 802.11n (2.4 GHz)
Network: IPv4 (NAT, DHCP)
Transport: TCP (20-byte header + handshake)
Application: MQTT (2-byte header + CONNECT overhead)
Per-message overhead: 20 + 2 + TCP keep-alive = ~60 bytes + 16 payload = 76 bytes
Daily data: 76 bytes x 24 + TCP overhead = ~2.5 KB/device
Monthly data: 75 KB/device
Gateway cost: 500 APs x $200 = $100,000 (outdoor-rated)
Spectrum cost: $0 (unlicensed)
Battery life: 6-12 months (no sleep mode for outdoor meters)| Cost Category | Stack A (LoRaWAN) | Stack B (NB-IoT) | Stack C (Wi-Fi) |
|---|---|---|---|
| Radio modules (10K units) | $35,000 | $55,000 | $25,000 |
| Gateway/infrastructure | $37,500 | $0 | $100,000 |
| Spectrum/connectivity (10yr) | $0 | $360,000 | $0 |
| Battery replacement (10yr) | $0 | $0 | $900,000 (9 replacements) |
| Server/broker | $5,000 | $5,000 | $12,000 |
| 10-Year Total | $77,500 | $420,000 | $1,037,000 |
| Cost per device per year | $0.78 | $4.20 | $10.37 |
Key Insight: The protocol stack selection for this scenario is dominated by battery cost (Stack C) and connectivity fees (Stack B), not radio module cost. LoRaWAN’s free spectrum and ultra-low power consumption produce a 10-year TCO that is 5.4x cheaper than NB-IoT and 13.4x cheaper than Wi-Fi. However, NB-IoT wins if the deployment area lacks LoRaWAN gateway coverage and the utility prefers outsourcing network infrastructure to a carrier. Stack selection is ultimately a business decision, not just a technical one.
Quick self-test (answers at the end):
Builds Upon:
Enables:
Related Concepts:
Protocol Deep Dives:
Link Layer Technologies:
Hands-On:
Hands-on exercise to explore protocol layers:
httpWhat to notice: Each layer adds its own header. A simple HTTP GET request might have 14 + 20 + 20 + 100 = 154 bytes of headers before any actual web page data.
Challenge: Filter for IoT protocols on your home network if you have smart devices: - mdns - device discovery traffic - mqtt - if you have MQTT devices - coap - if you have CoAP devices
Zigbee spans PHY, MAC, network, and application layers in one specification. LoRaWAN defines PHY and MAC but leaves the application layer open. Fix: always check which layers a protocol covers before comparing it to another protocol.
TCP’s retransmission and flow control are designed for wired networks. On lossy wireless links, TCP’s congestion control misinterprets packet loss as network congestion and throttles throughput unnecessarily. Fix: use UDP with application-layer retransmission (e.g., CoAP) for constrained IoT links.
Encoding sensor calibration offsets in the MAC header or embedding routing decisions in application payloads creates brittle, hard-to-maintain systems. Fix: assign each responsibility to the correct layer and resist the temptation to shortcut across layer boundaries.
The MAC layer controls radio sleep schedules. A misconfigured MAC that wakes the radio too frequently can drain a battery in days instead of years. Fix: profile radio active time at the MAC layer separately from application-layer activity.
This chapter explored the IoT protocol stack architecture in detail:
| Direction | Chapter | Focus |
|---|---|---|
| Next | Protocol Scenarios & Interview | System design scenarios, technical interview questions, and troubleshooting |
| Previous | IoT Protocols: Introduction | Why IoT needs specialized protocols |
| Hands-On | IoT Protocols: Labs and Selection | Hands-on protocol implementation and selection frameworks |
Deep Dives:
Application Protocols:
Network Layer:
Link Layer Technologies:
Foundational Concepts:
Learning: