By the end of this chapter, you will be able to:
Required Chapters:
Estimated Time: 15 minutes
What is a protocol stack? A protocol stack is like a layered cake where each layer has a specific job. Data travels down through layers when sending (adding “wrapping” at each layer) and up through layers when receiving (removing “wrapping” at each layer).
Why does layer structure matter for IoT? Each layer adds overhead (extra bytes). For tiny IoT sensors sending small readings, this overhead can dominate the total packet size. Understanding the stack helps you choose efficient protocol combinations.
Key Insight: For a 4-byte temperature reading, protocol headers can add 60+ bytes of overhead - making header efficiency crucial for battery-powered devices.
“Choosing protocols is like building a layer cake,” said Max the Microcontroller. “You pick one protocol for each layer, and your choices at the bottom affect what works at the top.”
“Start at the Physical layer,” said Sammy the Sensor. “Do you need long range? Pick LoRa. Short range with mesh? Pick 802.15.4. High bandwidth? Pick Wi-Fi. This choice is the foundation that everything else sits on.”
“Then move up,” continued Lila the LED. “Network layer: IPv6 with 6LoWPAN compression for constrained devices, or regular IPv6 for powerful ones. Transport: UDP if you want speed and low overhead, TCP if you need guaranteed delivery. Application: CoAP for request-response, MQTT for publish-subscribe.”
“Here is the key insight,” said Bella the Battery. “Each layer’s headers ADD UP. If you pick 802.15.4 (25 bytes) plus IPv6 (40 bytes) plus TCP (20 bytes) plus MQTT (variable) for a 4-byte sensor reading, most of your packet is headers! But with 802.15.4 (25 bytes) plus 6LoWPAN compression (6 bytes) plus UDP (8 bytes) plus CoAP (4 bytes), the overhead drops from 85+ bytes to 43 bytes. Visualizing the complete stack helps you see where the waste is.”
Understanding the layered structure of IoT protocols is essential for protocol selection and troubleshooting. The following diagram shows how protocols work together from the physical radio layer up to the application.
Choosing the right protocol stack depends on device constraints, network topology, power budget, and application requirements. This decision tree guides protocol selection based on key system characteristics.
This quadrant chart visualization shows protocol selection based on two key trade-off dimensions: power consumption (vertical) and data throughput requirements (horizontal). Each quadrant represents a different protocol family best suited to those constraints.
Understanding protocol overhead is critical for battery-powered IoT devices. This comparison shows total packet size and payload efficiency for different protocol stacks when transmitting a 4-byte sensor reading.
Let’s calculate how protocol overhead affects actual battery life for a temperature sensor transmitting once per hour:
Common scenario: 4-byte temperature reading, 2000 mAh battery, hourly transmissions (24/day).
Stack-by-stack analysis (all calculations include sleep current for fair comparison): \[ \begin{aligned} \textbf{LoRaWAN (SF7, 5.5 kbps, TX 40 mA):} \\ \text{Packet size} &= 17\text{ bytes (13 header + 4 data)} \\ \text{Time-on-air} &= \frac{17 \times 8}{5500} = 24.7\text{ ms} \\ \text{Energy per TX} &= 40\text{ mA} \times 0.0247\text{ s} = 0.988\text{ mAs} = 0.000274\text{ mAh} \\ \text{Daily TX energy} &= 24 \times 0.000274 = 0.0066\text{ mAh} \\ \text{+ sleep @ 1 µA} &= 0.024\text{ mAh/day} \\ \text{Battery life} &= \frac{2000}{0.031} = 64,516\text{ days} \approx 177\text{ years (limited by battery self-discharge to } {\sim}10\text{ years)} \\[0.5em] \textbf{CoAP/UDP/6LoWPAN over 802.15.4 (250 kbps, TX 20 mA):} \\ \text{Packet size} &= 47\text{ bytes (43 overhead + 4 data)} \\ \text{Time-on-air} &= \frac{47 \times 8}{250000} = 1.504\text{ ms} \\ \text{Energy per TX} &= 20\text{ mA} \times 0.001504\text{ s} = 0.03\text{ mAs} = 0.0000084\text{ mAh} \\ \text{Daily TX energy} &= 24 \times 0.0000084 = 0.0002\text{ mAh} \\ \text{+ sleep @ 5 µA} &= 0.12\text{ mAh/day} \\ \text{Battery life} &= \frac{2000}{0.12} = 16,667\text{ days} = 45.7\text{ years} \\[0.5em] \textbf{MQTT/TCP/6LoWPAN over 802.15.4 (250 kbps, TX 20 mA):} \\ \text{Packet size} &= 61\text{ bytes (57 overhead + 4 data)} \\ \text{+ keep-alive} &= 12\text{ bytes every 60 sec} \\ \text{Time-on-air (data)} &= \frac{61 \times 8}{250000} = 1.95\text{ ms} \\ \text{Time-on-air (keep-alive)} &= \frac{12 \times 8}{250000} = 0.384\text{ ms} \\ \text{Daily TX energy} &= (24 \times 1.95 + 1440 \times 0.384)\text{ ms} \times 20\text{ mA} \\ &= 12.0\text{ mAs} = 0.0033\text{ mAh} \\ \text{+ connection overhead} &= 0.02\text{ mAh/day (handshakes)} \\ \text{+ sleep @ 10 µA} &= 0.24\text{ mAh/day} \\ \text{Battery life} &= \frac{2000}{0.264} = 7,576\text{ days} = 20.8\text{ years} \end{aligned} \]
Result: With consistent sleep-current accounting, LoRaWAN achieves ~10 years practical battery life (limited by self-discharge), CoAP/6LoWPAN achieves ~45 years theoretical (also self-discharge limited to ~10 years), and MQTT achieves ~21 years. The real-world difference comes from sleep current: LoRa modules sleep at 1 µA vs. 802.15.4 at 5-10 µA. For more frequent transmissions (every 5 minutes), TX energy becomes significant and protocol overhead creates a 3-5x battery life difference between CoAP and MQTT.
The following table provides a quick reference for acronyms used throughout this chapter and the broader IoT networking modules.
| 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 | PHY/MAC | 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 |
Scenario: A logistics company operates a 50,000 m² warehouse with 2,000 pallet-tracking sensors. Each sensor reports location updates (12-byte GPS + 8-byte metadata) every 60 seconds. Sensors are battery-powered (2× AA, 3,000 mAh) and must last 2+ years. The warehouse has existing Wi-Fi coverage (50 access points). Current system uses HTTP/TCP, but battery life is only 6 months. Engineering investigates alternatives.
Step 1 — Current System Analysis (HTTP/TCP over Wi-Fi)
Message breakdown:
HTTP POST /api/location HTTP/1.1
Host: warehouse.local
Content-Type: application/json
Content-Length: 45
{"sensor_id": "PAL-1234", "lat": 37.7749, "lon": -122.4194, "battery": 3.2}
Headers: ~150 bytes (HTTP request line + headers)
JSON payload: 45 bytes (inefficient text encoding)
TCP header: 20 bytes
IPv6 header: 40 bytes
Wi-Fi header: 36 bytes
Total: 291 bytes per messageBattery calculation:
Messages per day: 1440 minutes ÷ 1 = 1440 messages
Daily data: 1440 × 291 = 419,040 bytes
TX time at 54 Mbps: 419,040 × 8 ÷ 54,000,000 = 62 ms
Power consumption:
- Wi-Fi TX: 200 mW
- Wi-Fi idle (connected): 10 mW
- TX energy: 200 mW × 0.062s = 12.4 mJ = 0.0034 mAh
- Idle energy (23h 59m): 10 mW × 86,337.9s = 863.4 J = 240 mAh
- Total: 240 mAh/day
Battery life: 3000 mAh ÷ 240 mAh/day = 12.5 daysWait—calculations show 12.5 days but reality is 6 months? What’s missing?
The original analysis assumed continuous Wi-Fi connection. Real implementation uses Wi-Fi sleep mode: - Sleep mode: 1 mA (not 0.01 mW — power-saving mode still polls beacon) - Wake, connect, transmit, disconnect cycle adds overhead
Corrected calculation:
Wi-Fi wake cycle per message:
1. Wake from sleep: 200 mW × 0.5s = 100 mJ
2. Association: 150 mW × 1.0s = 150 mJ
3. DHCP (if needed): 150 mW × 0.5s = 75 mJ
4. HTTP POST: 200 mW × 0.1s = 20 mJ
5. Disconnect: 100 mW × 0.2s = 20 mJ
Total per message: 365 mJ = 0.101 mAh
Daily Wi-Fi energy: 1440 × 0.101 = 145.4 mAh
Daily sleep energy: 1.0 mA × 24h = 24 mAh
Total: 169.4 mAh/day
Battery life: 3000 ÷ 169.4 = 17.7 days
Still wrong! What else?Real-world factors:
Final realistic calculation:
With keep-alive (5-min windows):
- 5-min window has 5 messages
- Connect once: 325 mJ
- 5× HTTP POST: 5 × 20 = 100 mJ
- Total: 425 mJ for 5 messages = 85 mJ/message = 0.024 mAh/message
Daily energy: 1440 × 0.024 = 34.6 mAh (TX) + 24 mAh (sleep) = 58.6 mAh/day
Effective capacity: 3000 × 0.80 = 2400 mAh
Battery life: 2400 ÷ 58.6 = 41 days ≈ 1.4 months
Closer to observed 6 months with aggressive connection reuse...Step 2 — Proposed Solution: CoAP/UDP with Keep-Alive Alternative
Instead of TCP keep-alive, use CoAP Observe pattern:
New message format:
CoAP CON message (binary):
- CoAP header: 4 bytes
- Token: 2 bytes
- URI-Path: 8 bytes (/loc)
- Binary payload: 12 bytes (3 floats: lat, lon, battery)
Total application: 26 bytes
UDP header: 8 bytes
IPv6 header: 40 bytes
Wi-Fi header: 36 bytes
Total: 110 bytes (62% reduction from 291 bytes!)Power advantage:
CoAP uses UDP = no TCP connection state
Sensors send UDP packet and immediately sleep
No keep-alive windows needed
Per-message energy:
1. Wake: 200 mW × 0.5s = 100 mJ
2. DNS lookup (cached): 0 mJ
3. CoAP CON: 200 mW × 0.05s = 10 mJ (faster, smaller packet)
4. Sleep: immediate
Total: 110 mJ = 0.031 mAh/message
Daily energy: 1440 × 0.031 = 44.6 mAh (TX) + 24 mAh (sleep) = 68.6 mAh/day
Battery life: 2400 ÷ 68.6 = 35 days ≈ 1.2 months
Still not 2 years! Need a different approach...Step 3 — Alternative: Zigbee Mesh + Gateway Bridge
Replace Wi-Fi with 802.15.4/Zigbee mesh:
Hardware change: Zigbee module instead of Wi-Fi
Message format:
- 802.15.4 header: 8 bytes (compressed)
- 6LoWPAN header: 6 bytes
- UDP (compressed): 4 bytes
- CoAP: 4 bytes
- Payload: 12 bytes (binary)
Total: 34 bytes
Zigbee power profile:
- TX: 20 mA at 3V = 60 mW
- Sleep: 3 µA at 3V = 0.009 mW
Per-message energy:
TX time: 34 bytes × 8 bits ÷ 250,000 bps = 1.088 ms
TX energy: 60 mW × 0.001088s = 0.065 mJ = 0.000018 mAh
Daily energy:
TX: 1440 × 0.000018 = 0.026 mAh
Sleep: 0.003 mA × 24h = 0.072 mAh
Total: 0.098 mAh/day
Battery life: 2400 ÷ 0.098 = 24,490 days = 67 years!
(Limited by battery self-discharge to ~10 years)Step 4 — Cost-Benefit Analysis
| Factor | HTTP/Wi-Fi (current) | CoAP/Wi-Fi | Zigbee + Gateway |
|---|---|---|---|
| Battery life | 6 months | 1.2 months | 10 years |
| Hardware cost/sensor | $8 (Wi-Fi) | $8 (Wi-Fi) | $12 (Zigbee) |
| Infrastructure | 50 APs (existing) | 50 APs (existing) | 20 gateways ($300 ea) |
| Development effort | Done | 2 weeks | 6 weeks |
| Battery replacements (5yr) | 10× @ $2 = $20/sensor | 50× @ $2 = $100/sensor | 0× |
| Total 5-year cost (2000 sensors) | $56K | $216K | $30K |
Winner: Zigbee mesh despite higher upfront cost and development effort.
Why CoAP/Wi-Fi failed: Wi-Fi’s idle listening power (1-10 mA) dominates energy consumption even with CoAP’s efficiency gains. The protocol optimization (HTTP→CoAP) only improved TX energy, which was already <1% of total consumption.
Key insight: For battery-powered IoT, radio technology choice (Wi-Fi vs Zigbee) matters 100× more than application protocol choice (HTTP vs CoAP) when sleep current differs by 3 orders of magnitude (1 mA vs 3 µA). Protocol optimization is meaningless if you chose the wrong wireless technology.
Implementation: Zigbee sensors → Border routers (every 100m) → Ethernet gateway → CoAP-to-HTTP proxy → Warehouse management system. The gateway handles protocol translation, preserving existing cloud integration.
Students naturally spend more revision time on familiar protocols. Fix: identify the two protocols you understand least and spend proportionally more revision time on them.
Remembering “LoRa = Long Range” without knowing why (spread-spectrum chirp modulation trades data rate for link budget) fails on application questions. Fix: for each mnemonic, write one sentence explaining the technical reason behind it.
Revision scenarios that mirror lecture examples give false confidence. Fix: find or create novel scenarios (different device types, different environments) and apply the selection framework to them.
Protocol Stack Structure:
Selection Framework:
Efficiency Comparison (4-byte payload, including MAC headers):
Decision Factors:
Builds Upon:
Enables:
Related Concepts:
Protocol Deep Dives:
| If you want to… | Read this |
|---|---|
| Review lab exercises before assessment | Labs Review |
| Attempt the module assessment | Protocol Assessment |
| Deep-dive into protocol stack architecture | Protocol Stack Architecture |
| Study real-world deployment examples | Real-World Examples |