35 ::: {style=“overflow-x: auto;”}
title: “IoT Protocols: Review” difficulty: intermediate —
35.1 Learning Objectives
By the end of this review, you will be able to:
- Synthesize Protocol Knowledge: Consolidate understanding of the full IoT protocol stack from application to link layer
- Apply Selection Frameworks: Select the correct protocol stack for any given IoT scenario based on constraints
- Calculate Protocol Efficiency: Compute overhead ratios, battery impact, and payload efficiency for different protocol stacks
- Diagnose Protocol Issues: Troubleshoot common IoT protocol misconfigurations and performance problems
- Evaluate Protocol Tradeoffs: Justify MQTT vs CoAP vs HTTP and TCP vs UDP choices for specific deployment requirements
Minimum Viable Understanding
- Protocol selection is driven by constraints, not preferences: the right protocol stack depends on device resources (RAM, power), network conditions (bandwidth, loss rate), and application requirements (latency, reliability). A constrained sensor on a lossy mesh network needs CoAP/UDP/6LoWPAN, while a gateway pushing data to the cloud can use MQTT/TCP/TLS.
- Protocol overhead dominates small payloads: the smaller the payload, the more protocol headers matter. For tiny sensor readings, the choice of protocol stack can mean the difference between months and days of battery life.
- The IoT protocol stack has four key decision points: Application (CoAP vs MQTT vs HTTP), Transport (UDP vs TCP), Network (6LoWPAN vs IPv6), and Link (802.15.4/BLE vs Wi-Fi/LoRa). Each decision involves trading overhead for features.
Sensor Squad: The Protocol Puzzle Party
Sammy the Sensor wants to send a tiny temperature reading to the cloud. But there are SO many ways to deliver a message!
Lila the Lightbulb says: “It’s like choosing how to send a birthday party invitation! You could write a short text message (that’s CoAP – quick and small), mail a fancy letter in a big envelope (that’s HTTP – lots of wrapping for a small card), or pin a note on a shared bulletin board for everyone to see (that’s MQTT – you post it once and everyone who cares can read it).”
Max the Microcontroller adds: “And I have to think about my energy! If I use the fancy envelope (HTTP), I spend most of my battery on wrapping paper instead of the actual message. If I use the text message (CoAP), I save lots of energy but I can’t be 100% sure it arrives. So I pick based on what matters most!”
Bella the Battery warns: “Here’s the thing – if Sammy picks the WRONG protocol, I run out of power in days instead of months! Imagine carrying a tiny marble in a huge shipping container versus a small pouch. The marble is the same, but one delivery truck uses way more fuel. That’s why protocol selection matters so much for battery life!”
The lesson? There is no single “best” protocol. The best one depends on what you are sending, how far it needs to go, how reliable the delivery must be, and how much energy you can spend. Protocol selection is all about trade-offs!
For Beginners: Why Review IoT Protocols?
Think of the IoT protocol stack as layers of packaging for your data.
When you send a package through a delivery service, the item goes into a box, the box gets a shipping label, the labeled box goes on a truck, and the truck follows roads. Each “layer” adds something: protection, addressing, transport, and physical delivery.
IoT protocols work the same way, with four layers:
- Application Layer (what to say): MQTT, CoAP, or HTTP format your sensor data for the recipient
- Transport Layer (reliable or fast?): TCP guarantees delivery but is heavy; UDP is lightweight but “best effort”
- Network Layer (where to send): IPv6 provides addresses, and 6LoWPAN compresses them for tiny devices
- Link Layer (how to transmit): 802.15.4, BLE, or LoRa handle the actual wireless transmission
Why does this matter? Choosing the wrong combination wastes battery, bandwidth, and money. A temperature sensor sending 4 bytes of data wrapped in HTTP/TCP/IPv4 uses 108 total bytes – that is 96% overhead! Switching to CoAP/UDP/6LoWPAN cuts that to 26 bytes (a 76% reduction in total packet size).
The goal of this review: make sure you can confidently choose the right protocol stack for any IoT scenario and explain why.
35.2 Overview
This review series consolidates IoT protocol concepts from the fundamentals chapters, providing visual summaries, hands-on labs, and comprehensive assessments to validate your understanding.
Chapter Series
This review is organized into three focused chapters:
Visual Summaries and Decision Framework - Protocol stack architecture, selection decision trees, efficiency comparisons, and common acronyms reference
Hands-On Labs - ESP32 packet analyzer, Python overhead calculator, battery life calculations, and practical debugging tools
Knowledge Assessment - Comprehensive quiz with 15+ scenario-based questions, common misconceptions, and detailed explanations
35.3 Prerequisites
Required Chapters:
- IoT Protocols Overview - Protocol landscape
- IoT Protocols Fundamentals - Core concepts
- Application Protocols - Selection criteria
35.4 IoT Protocol Stack Architecture
The IoT protocol stack adapts the traditional TCP/IP model for constrained devices. Understanding how protocols map to each layer – and which options suit which constraints – is the foundation for everything else in this review.
IoT Protocol Stack Summary:
| Layer | Constrained Option | Traditional Option | Key Difference |
|---|---|---|---|
| Application | CoAP (4B header), MQTT (2B min) | HTTP (~200B header) | 50-100x header size difference |
| Transport | UDP (8B header) | TCP (20B+ header) | TCP adds connection setup + ACKs |
| Network | 6LoWPAN (2-7B compressed) | IPv6 (40B header) | 85-95% header compression |
| Link | 802.15.4 (127B MTU), BLE | Wi-Fi (2304B MTU) | Power vs throughput tradeoff |
35.5 Protocol Selection Decision Framework
Selecting the right protocol stack requires systematically evaluating your constraints. The following decision tree guides you through the key questions.
35.6 Protocol Efficiency Comparison
Protocol efficiency becomes critical with small payloads, which are common in IoT. The following chart visualizes the overhead for a 4-byte sensor reading across different protocol stacks.
35.6.1 Protocol Efficiency Table (4-byte payload)
| Stack | Total Bytes | Overhead Bytes | Efficiency | Battery Impact |
|---|---|---|---|---|
| LoRaWAN MAC | 17 | 13 | 23.5% | Best – months to years |
| CoAP/UDP/6LoWPAN | 26 | 22 | 15.4% | Good – weeks to months |
| MQTT/TCP/6LoWPAN | 40 | 36 | 10.0% | Moderate – days to weeks |
| HTTP/TCP/IPv4 | 108 | 104 | 3.7% | Poor – hours to days |
:::
35.6.2 Selection Guidelines
- Constrained + Real-time: CoAP/UDP – minimal overhead, fast delivery
- Scalable + Reliable: MQTT/TCP – broker handles fan-out, QoS levels
- LPWAN (LoRaWAN, Sigfox): Native MAC protocols – purpose-built for long range
- Gateway-to-Cloud: HTTP/HTTPS – universal, well-tooled, acceptable overhead
35.7 Key Protocol Concepts Review
35.7.1 6LoWPAN Header Compression
6LoWPAN compresses IPv6 headers from 40 bytes to as few as 2 bytes using context-based compression. This is essential for 802.15.4 networks where the maximum frame size is only 127 bytes.
35.7.2 TCP vs UDP for IoT
| Feature | TCP | UDP |
|---|---|---|
| Header Size | 20+ bytes | 8 bytes |
| Connection Setup | 3-way handshake (1.5 RTT) | None (immediate send) |
| Reliability | Guaranteed delivery + ordering | Best effort |
| Congestion Control | Built-in (slow start, AIMD) | None |
| Best For | Cloud connections, MQTT broker | Constrained devices, CoAP |
| IoT Tradeoff | More reliable but heavier | Lighter but app must handle loss |
35.7.3 Battery Impact of Protocol Choice
Protocol choice can mean a 3-4x difference in battery life. The primary drivers are:
- Overhead bytes: More bytes = more radio-on time = more energy
- Connection setup: TCP 3-way handshake costs extra round trips
- Keep-alive traffic: MQTT/TCP needs periodic pings to maintain connection
- Retransmission cost: TCP retransmissions on lossy links waste significant energy
Common Mistake: Using IPv4 for New IoT Deployments “Because It’s Simpler”
The Error: A startup building smart water meters defaults to IPv4 because “IPv6 is complicated and our team doesn’t know it well.”
Why It’s Wrong:
- Address exhaustion: IPv4 provides 4.3 billion addresses, already exhausted. With 50+ billion IoT devices projected by 2030, IPv4 requires complex NAT workarounds
- NAT complexity: Home routers with 100+ smart devices hit NAT table limits (typically 4,096 entries). Devices fail to connect intermittently
- End-to-end breaks: NAT breaks end-to-end connectivity needed for peer-to-peer IoT (smart speakers controlling lights)
- Future-proofing: IPv6 is mandatory for cellular IoT (NB-IoT, LTE-M) - your IPv4-only design can’t use these networks
Real Impact:
- Home deployment: Customer with 150 IoT devices experiences random disconnections as router NAT table overflows
- Industrial scale: Factory with 5,000 sensors requires complex NAT64 gateways ($15,000+ cost)
- Cloud integration: AWS IoT Core native IPv6 support means IPv4 requires translation layer (added latency + cost)
- Migration cost: Retrofitting IPv6 into deployed IPv4 fleet requires firmware updates to 10,000+ devices (estimated $500K project cost)
IPv6 Advantages for IoT:
- Unique addressing: 340 undecillion addresses - every device gets global unique address
- No NAT: Direct device-to-device communication without complex NAT traversal
- 6LoWPAN: Header compression designed for IPv6 (not available for IPv4)
- Cellular ready: All cellular IoT standards (NB-IoT, LTE-M) are IPv6-native
Real-world data (Smart Home Study, 2023): - IPv4 home network: 127 devices max before stability issues - IPv6 home network: 500+ devices, no issues (tested with ULA addressing) - NAT-related support tickets: 43% of all IoT connectivity issues
The Fix: Design IPv6-first from day one. Use: - 6LoWPAN for 802.15.4 networks - Unique Local Addresses (ULA) for local communication - IPv6 border router for cloud connectivity - Dual-stack only if legacy integration absolutely required
When IPv4 is OK: Legacy system integration where all devices are on the same local network with no cloud connectivity and device count stays under 100. Even then, plan IPv6 migration path.
Cost of doing it right: Learning IPv6 takes your team 2-4 weeks. Retrofitting IPv6 after IPv4 deployment takes 6-12 months and costs 10-50× more. Choose wisely.
35.8 Worked Example: Choosing a Protocol Stack for a Smart Agriculture Sensor
Scenario: You are designing a soil moisture monitoring system for a vineyard. Each sensor node measures soil moisture, temperature, and electrical conductivity every 15 minutes and sends the data to a cloud dashboard. The vineyard is 200 hectares with 500 sensor nodes.
Constraints:
| Parameter | Value | Implication |
|---|---|---|
| Payload size | 12 bytes (3 x 4-byte floats) | Small payload – overhead matters |
| Transmit interval | Every 15 minutes | 96 transmissions per day |
| Battery | 2x AA (3000 mAh) | Must last 2+ years |
| Range | Up to 2 km from gateway | Needs long range |
| Nodes | 500 sensors | Scalability matters |
| Reliability | Occasional loss acceptable | Not safety-critical |
Step 1 – Link Layer Selection:
Range requirement (2 km) eliminates 802.15.4 (~100 m) and BLE (~50 m). Candidates: LoRa (up to 15 km), NB-IoT (up to 10 km). No existing cellular coverage in the vineyard, so LoRa with a private gateway is the best fit.
Step 2 – Network/Transport Layer:
LoRaWAN provides its own MAC layer with built-in addressing and acknowledgment. No need for a separate 6LoWPAN or TCP/UDP layer – LoRaWAN handles this natively.
Step 3 – Application Layer:
LoRaWAN uses a simple binary payload format (no CoAP/MQTT needed at the device level). The gateway decodes payloads and forwards to the cloud using MQTT or HTTP.
Step 4 – Efficiency Calculation:
| Component | Bytes |
|---|---|
| Payload (3 floats) | 12 |
| LoRaWAN MAC header | 13 |
| Total per transmission | 25 |
| Efficiency | 48% |
Step 5 – Battery Life Estimate:
- LoRa transmit current: ~40 mA for ~100 ms per packet
- Energy per transmission: 40 mA x 0.1 s = 4 mAs = 0.0011 mAh
- Daily energy: 96 transmissions x 0.0011 mAh = 0.106 mAh
- Sleep current: ~2 uA x 24 h = 0.048 mAh/day
- Total daily consumption: ~0.154 mAh/day
- Battery life: 3000 mAh / 0.154 mAh/day = 19,480 days (~53 years theoretical)
In practice, battery self-discharge and component aging reduce this to 5-10 years, which comfortably meets the 2-year requirement.
Decision: LoRaWAN is the optimal choice for this scenario – long range, low power, small payloads, and occasional loss is acceptable.
What if the requirement changed? If the sensor needed to send data every 5 seconds (real-time irrigation control), LoRaWAN would violate duty cycle regulations (~1% in EU). You would need NB-IoT or a mesh network with a wired backhaul instead.
Putting Numbers to It
Let’s quantify protocol overhead efficiency for different stack choices with a 4-byte sensor reading:
Stack comparison (upper-layer headers only, excluding link-layer MAC): \[ \begin{aligned} \textbf{LoRaWAN:} \\ \text{Overhead} &= 13\text{ bytes (MAC header)} \\ \text{Total packet} &= 13 + 4 = 17\text{ bytes} \\ \text{Efficiency} &= \frac{4}{17} \times 100 = 23.5\% \\[0.5em] \textbf{CoAP/UDP/6LoWPAN:} \\ \text{Overhead} &= 4\text{ (CoAP)} + 8\text{ (UDP)} + 7\text{ (6LoWPAN)} + 3\text{ (dispatch)} = 22\text{ bytes} \\ \text{Total packet} &= 22 + 4 = 26\text{ bytes} \\ \text{Efficiency} &= \frac{4}{26} \times 100 = 15.4\% \\[0.5em] \textbf{MQTT/TCP/6LoWPAN:} \\ \text{Overhead} &= 2\text{ (MQTT min)} + 20\text{ (TCP)} + 7\text{ (6LoWPAN)} + 7\text{ (other)} = 36\text{ bytes} \\ \text{Total packet} &= 36 + 4 = 40\text{ bytes} \\ \text{Efficiency} &= \frac{4}{40} \times 100 = 10.0\% \\[0.5em] \textbf{HTTP/TCP/IPv4:} \\ \text{Overhead} &= 200\text{ (HTTP headers)} + 20\text{ (TCP)} + 20\text{ (IPv4)} = 240\text{ bytes} \\ \text{Total packet} &= 240 + 4 = 244\text{ bytes} \\ \text{Efficiency} &= \frac{4}{244} \times 100 = 1.6\% \end{aligned} \]
Note: The efficiency table in the previous section uses simplified overhead estimates (e.g., 104 bytes for HTTP/TCP/IPv4) that assume minimal HTTP headers. The expanded calculation above uses a more realistic ~200-byte HTTP header estimate. Both illustrate the same principle: protocol overhead dominates small payloads.
Battery impact (96 transmissions/day, 2000 mAh battery): \[ \begin{aligned} \textbf{LoRaWAN (SF7, 5.5 kbps, 40 mA TX):} \\ \text{Time-on-air per packet} &= \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} &= 96 \times 0.000274 = 0.026\text{ mAh/day} \\ \text{Battery life (TX only)} &= \frac{2000}{0.026} \approx 76{,}923\text{ days} \approx \textbf{210 years (theoretical)} \\[0.5em] \textbf{CoAP/UDP/802.15.4 (250 kbps, 20 mA TX):} \\ \text{Time-on-air per packet} &= \frac{26 \times 8}{250{,}000} = 0.83\text{ ms} \\ \text{Energy per TX} &= 20\text{ mA} \times 0.00083\text{ s} = 0.0166\text{ mAs} = 0.0000046\text{ mAh} \\ \text{Daily TX energy} &= 96 \times 0.0000046 = 0.000442\text{ mAh/day} \\ \text{Battery life (TX only)} &= \frac{2000}{0.000442} \approx \textbf{12{,}400 years (theoretical)} \\[0.5em] \textbf{HTTP/TCP/Wi-Fi (1 Mbps, 200 mA TX):} \\ \text{Data TX time} &= \frac{244 \times 8}{1{,}000{,}000} = 1.95\text{ ms} \\ \text{+ TCP handshake (3 round trips)} &\approx 30\text{ ms} \\ \text{Total active time per TX} &\approx 32\text{ ms} \\ \text{Energy per TX} &= 200\text{ mA} \times 0.032\text{ s} = 6.4\text{ mAs} = 0.00178\text{ mAh} \\ \text{Daily TX energy} &= 96 \times 0.00178 = 0.171\text{ mAh/day} \\ \text{Battery life (TX only)} &= \frac{2000}{0.171} \approx 11{,}696\text{ days} \approx \textbf{32 years (theoretical)} \end{aligned} \]
These theoretical numbers assume TX energy is the only drain. In practice, sleep current (1–10 µA), receiver listening windows, and battery self-discharge reduce actual life to 5–10 years for LoRaWAN and weeks to months for Wi-Fi/HTTP. The key insight is that protocol overhead amplifies energy cost, and the combination of larger packets and higher TX power for Wi-Fi creates a significant cumulative penalty over thousands of transmissions.
35.9 Common Pitfalls
Common Protocol Selection Pitfalls
Using HTTP for constrained devices: HTTP headers alone can be 200+ bytes. For a 4-byte sensor reading, that is 98% overhead. Use CoAP (4-byte header) or MQTT (2-byte minimum header) instead. HTTP is fine only for gateways and cloud-side APIs.
Running TCP over lossy wireless links: TCP interprets packet loss as congestion and reduces throughput (congestion window halving). On a lossy 802.15.4 link with 10% packet loss, TCP throughput collapses. Use UDP with application-level reliability (CoAP CON messages) for lossy mesh networks.
Ignoring protocol overhead for small payloads: Developers often choose “familiar” protocols without calculating overhead. A 4-byte reading sent via HTTP/TCP/IPv4 costs 108 bytes total. Sent via CoAP/UDP/6LoWPAN, it costs only 26 bytes – a 4x reduction that directly extends battery life.
Forgetting connection setup costs: TCP’s 3-way handshake requires 1.5 round trips before any data is sent. For a sensor that wakes up, sends one reading, and sleeps, the handshake may cost more energy than the data itself. UDP-based protocols like CoAP avoid this entirely.
Overlooking duty cycle regulations for LPWAN: LoRaWAN in Europe (EU868) has a 1% duty cycle limit. A 50-byte packet at SF12 takes ~1.5 seconds to transmit, meaning the total duty cycle period is 150 seconds (1.5s / 0.01), so you must wait at least 148.5 seconds before the next transmission. Failing to account for this leads to regulatory violations and delayed messages.
Choosing MQTT when you need request-response: MQTT is publish-subscribe and excels at one-to-many data distribution. But if you need to query a specific device (e.g., “what is the current temperature?”), CoAP’s GET/PUT/POST model is a better fit. Use the right messaging pattern for the interaction type.
35.10 Knowledge Check
Test your understanding of IoT protocol concepts before proceeding to the detailed review chapters.
35.11 Summary
This review chapter has consolidated the key concepts from the IoT protocols fundamentals series. The following table summarizes the essential takeaways:
| Concept | Key Takeaway | Why It Matters |
|---|---|---|
| Protocol Stack | Four layers: Application, Transport, Network, Link – each with constrained and traditional options | Systematic approach to protocol selection |
| Overhead Efficiency | Small payloads amplify overhead differences: 3.7% (HTTP) vs 23.5% (LoRaWAN) for 4 bytes | Directly impacts battery life and bandwidth |
| 6LoWPAN | Compresses IPv6 from 40 bytes to 2-7 bytes using context-based elision | Enables IPv6 on 127-byte 802.15.4 frames |
| TCP vs UDP | TCP: reliable but heavy (20B + handshake). UDP: light but best-effort (8B) | TCP fails on lossy wireless; use UDP + app-level reliability |
| Protocol Selection | Driven by constraints: power, range, payload size, reliability, latency | No universal “best” protocol – context determines choice |
| Duty Cycle | LPWAN bands have regulatory limits (1% in EU868) | Limits transmission frequency; must plan message schedules |
| Battery Impact | Protocol choice creates 3-4x battery life difference | Wrong choice turns years of battery life into days |
35.11.1 Decision Quick Reference
| Scenario | Recommended Stack | Reason |
|---|---|---|
| Constrained sensor on 802.15.4 mesh | CoAP/UDP/6LoWPAN | Minimal overhead, fits 127B MTU |
| Gateway to cloud (many devices) | MQTT/TCP/TLS | Scalable pub-sub, reliable, secure |
| Long-range rural deployment | LoRaWAN native MAC | Purpose-built for LPWAN, lowest overhead |
| Low-latency actuator control | CoAP/UDP | No connection setup delay |
| Enterprise cloud API integration | HTTP/TLS | Universal compatibility, rich tooling |
| Few devices, simple cloud push | HTTP/TCP/TLS | Simple REST API, easy debugging |
35.12 Concept Relationships
The IoT protocol review synthesizes concepts across multiple layers and domains:
- Cross-layer optimization appears in protocol selection: application choice (CoAP vs MQTT) affects battery life through transport layer (UDP vs TCP)
- Constraint-driven design unifies all protocol decisions: limited RAM, power, and bandwidth drive every architectural choice
- Efficiency metrics interconnect: payload efficiency, energy-per-bit, battery life, and total cost of ownership all stem from protocol overhead
- Scalability patterns differ by protocol: MQTT broker architecture vs CoAP direct addressing vs LoRaWAN star topology
- Hybrid architectures demonstrate layered thinking: CoAP for sensor-to-gateway, MQTT for gateway-to-cloud combines benefits
35.13 See Also
Related Chapters and Resources
Review Series:
- Visual Summaries - Protocol diagrams and decision trees
- Hands-On Labs - ESP32 packet analysis and Python tools
- Knowledge Assessment - Comprehensive quiz validation
Fundamentals:
- IoT Protocols Overview - Protocol landscape and comparison
- IoT Protocols Fundamentals - Core protocol concepts
- Networking Fundamentals - Network basics
- Transport Fundamentals - TCP vs UDP
- Layered Models Review - OSI and TCP/IP models
- IPv6 and IoT - IPv6 addressing
Protocol Deep Dives:
- MQTT Fundamentals - Publish-subscribe messaging
- CoAP Architecture - RESTful protocol for IoT
- AMQP Fundamentals - Enterprise messaging
- 6LoWPAN Fundamentals - IPv6 compression
- 6LoWPAN Compression - Header compression mechanisms
Learning Tools:
- Protocol Comparison Simulator - Interactive selection tool
- Knowledge Map - Visualize protocol relationships
- Quizzes Hub - Test your knowledge
- Videos Hub - Protocol video tutorials
35.14 What’s Next
| If you want to… | Read this |
|---|---|
| Attempt the protocol assessment | Protocol Assessment |
| Review lab exercises | Labs Review |
| Study real-world examples | Real-World Examples |
| Revisit protocol selection | Protocol Selection Guide |