Protocol Suite: A complete set of protocols that work together across multiple layers to provide end-to-end communication (e.g., TCP/IP suite, Zigbee protocol suite)
Interoperability: The ability of devices from different manufacturers to communicate using the same protocol; enabled by standards bodies (IETF, IEEE, Zigbee Alliance)
RFC (Request for Comments): The document series published by the IETF that defines internet standards; numbered sequentially (e.g., RFC 7252 defines CoAP)
IEEE Standard: A standard published by the Institute of Electrical and Electronics Engineers; IEEE 802.11 (Wi-Fi), IEEE 802.15.4 (ZigBee/Thread PHY/MAC)
Protocol Versioning: The use of version numbers to distinguish incompatible revisions of a protocol; version mismatches cause interoperability failures
State Machine: A formal model describing a protocol’s behaviour as a set of states and transitions triggered by events (packet arrival, timeout)
Protocol Overhead: The bytes consumed by headers, trailers, ACKs, and control messages beyond the application payload
15.1 In 60 Seconds
IoT protocols organize into OSI layers: MQTT and CoAP at the application layer for device messaging, TCP/UDP at transport for reliability vs. speed, IPv4/IPv6 at network for addressing, and technologies like Wi-Fi, Bluetooth, Zigbee, and LoRa at the physical/data link layers. Selecting the right protocol stack depends on range, power budget, data rate, and device constraints.
15.2 Learning Objectives
By the end of this chapter, you will be able to:
Map IoT protocols to OSI layers and explain their roles at each layer
Select appropriate protocols for different IoT applications using decision trees
Compare wireless technologies by range, power, and data rate
Calculate protocol overhead and analyze encapsulation cost at each layer
For Beginners: IoT Protocol Layers
A protocol is a set of rules that devices follow to communicate, like a language two people agree to speak. IoT devices use different protocols at different levels—one protocol handles the radio signal, another handles addressing, and another handles the actual sensor data. Choosing the right combination is key to building a working IoT system.
Sensor Squad: Choosing Our Protocol Stack!
“I need to send temperature data to the cloud, but there are so many protocol choices!” Sammy the Sensor said, overwhelmed. Max the Microcontroller pulled out a decision tree. “Let’s work through it layer by layer. First, what is your range and power budget?”
“I run on a tiny battery and need to reach a gateway 500 meters away,” said Sammy. “Then LoRa at the physical layer,” said Max. “It gives you long range with very low power. At the network layer, we use 6LoWPAN to compress IPv6 headers. At transport, UDP because you do not need guaranteed delivery for periodic readings. And at the application layer, CoAP—it is designed for constrained devices like you.”
Lila the LED compared her own needs. “I am in a smart lightbulb connected to Wi-Fi, so I use 802.11 at the physical layer, regular IP at network, TCP at transport for reliable commands, and MQTT at application so I can subscribe to ‘turn on’ and ‘turn off’ messages.”
“See the pattern?” said Bella the Battery. “Same layered framework, different protocol choices. A security camera with lots of bandwidth uses HTTP over TCP over Wi-Fi. A tiny soil sensor uses CoAP over UDP over LoRa. Match each layer’s protocol to your device’s specific needs—range, power, data rate, and reliability!”
15.3 Why Networking Matters for IoT
Time: ~5 min | Difficulty: Foundational | Unit: P07.C15.U01
The Stanford IoT course presents a complete IoT System-on-Chip (SoC) architecture that integrates all subsystems for battery-powered wireless IoT nodes in a single 3.57mm x 3.78mm chip:
Key integrated components:
Subsystem
Components
Function
Sensing
4-channel AFE, 8-bit SAR ADC
Analog signal acquisition
Processing
MSP430 MCU, 2KB memory
Data processing and control
Accelerators
CORDIC, MAC, 16-point FFT, FIR filter
Signal processing offload
Power
DC-DC converter, MPPT solar harvesting
Energy-efficient operation
Wireless
UWB TX (400MHz-2.4GHz), Wake-up receiver (1GHz)
Multi-band communication
Clocking
ADPLL, 31.25kHz crystal oscillator
Timing and synchronization
This architecture demonstrates how modern IoT nodes integrate sensing, processing, power management, and wireless communication on a single chip, enabling ultra-low-power operation for battery-powered deployments.
Source: Stanford University IoT Course
IoT networking enables devices to exchange data, receive commands, and coordinate actions across distributed systems. Without networking, IoT devices would be isolated sensors with no ability to share insights or respond to centralized control. Modern IoT deployments require understanding how protocols work at different layers, how to manage limited bandwidth and power budgets, and how to ensure reliable communication in challenging wireless environments.
15.4 Common IoT Protocols by Layer
Time: ~15 min | Difficulty: Intermediate | Unit: P07.C15.U02
The following diagram shows how IoT protocols map to the OSI model layers, from physical transmission to application-level messaging:
Figure 15.1: OSI 7-layer model with IoT protocols at each layer from application to physical
Alternative View: IoT Data Journey Through Protocol Layers
This variant shows how sensor data actually travels through the protocol stack:
Each layer adds headers when sending (encapsulation) and removes them when receiving (decapsulation).
Each layer serves a specific purpose in enabling end-to-end IoT communication:
Request/response (REST-like); confirmable (CON) and non-confirmable (NON) messages
Constrained devices
Very Low
HTTP/HTTPS
TCP
Request/response (REST); stateless
Web services, REST APIs
High
AMQP
TCP
Message queue with exchanges and routing keys; supports publish/subscribe and point-to-point
Enterprise messaging
Medium
WebSocket
TCP
Full-duplex bidirectional over persistent TCP connection
Real-time bidirectional
Medium
Putting Numbers to It
Protocol Overhead and Goodput Calculation
Every protocol layer adds headers that reduce available bandwidth for application data. Let’s quantify this:
Header sizes for a Zigbee/6LoWPAN/CoAP stack: - 802.15.4 MAC: 25 bytes (addresses + frame control + FCS) - 6LoWPAN: 6 bytes (compressed IPv6 header) - UDP: 8 bytes - CoAP: 4-8 bytes (average 6) - Total overhead: ~45 bytes per packet
Goodput (actual application data rate) for 250 kbps Zigbee link with 127-byte max frame: \[\text{Payload} = 127 - 45 = 82 \text{ bytes usable}\]\[\text{Efficiency} = \frac{82}{127} = 64.6\%\]\[\text{Goodput} = 250 \times 0.646 = 162 \text{ kbps}\]
Comparison: Same sensor using HTTP over TCP over IPv4: - TCP: 20 bytes, IPv4: 20 bytes, HTTP GET: ~100 bytes → 140 bytes overhead - No room for data in single 127-byte frame → requires fragmentation - Goodput: <50 kbps (due to ACK overhead, 2× round trips)
For battery-powered IoT: CoAP/UDP/6LoWPAN saves ~120 bytes of overhead per message vs HTTP/TCP/IPv4 (45 vs 140 bytes). At 10 messages/day for 10 years, this saves 4.4 MB of transmitted data—reducing radio time significantly and extending battery life by months.
Try It: Protocol Stack Overhead Calculator
Adjust the protocol selections below to see how header overhead affects the usable payload in a 127-byte Zigbee/802.15.4 frame.
Choosing the right networking protocol depends on your IoT application requirements. Use this decision tree to narrow down your options:
Figure 15.2: IoT protocol selection decision tree based on range, power, data rate, and mobility
This simplified decision tree helps narrow down protocol choices. Real-world selection also considers cost, ecosystem maturity, regulatory requirements, and existing infrastructure.
Alternative View: Protocol Selection by Use Case
This variant presents the same protocol selection logic but organized by common IoT application scenarios rather than technical requirements.
Figure 15.3: Protocol Selection by IoT Application Domain - Shows which protocols are typically used for different industry verticals
Key Insight: The “best” protocol depends on your use case context, not just technical specs. A protocol that’s perfect for agriculture (LoRaWAN) would be terrible for industrial robotics (needs Ethernet/5G).
Worked Example: Choosing a Protocol Stack for a Smart Agriculture System
Scenario: A farm deploys 300 soil moisture sensors across 80 hectares. Sensors report every 30 minutes. The nearest gateway is 2 km away. No existing network infrastructure. Battery must last 5 years.
Layer-by-layer decision process:
Layer
Requirement
Options Considered
Decision
Rationale
Physical/Link
2 km range, 5-year battery, outdoor
Wi-Fi, BLE, Zigbee, LoRa
LoRa (868/915 MHz)
Only option with 2+ km range AND multi-year battery life
Network
No IP needed (gateway handles translation)
IPv6/6LoWPAN, LoRaWAN native
LoRaWAN MAC
LoRaWAN handles addressing natively; no IP overhead saves 40+ bytes per message
Transport
Infrequent, small payloads; loss tolerable
TCP, UDP, none
None (LoRaWAN handles ACK)
Class A confirmed uplinks provide per-message ACK; no TCP/UDP overhead needed
Application
8-byte payload (sensor ID + moisture %)
MQTT, CoAP, HTTP, raw binary
Raw binary
8 bytes vs 12+ bytes (CoAP) vs 30+ bytes (MQTT). Every byte costs battery at SF12
Total overhead comparison:
Option A: Raw binary over LoRaWAN
Payload: 8 bytes
LoRaWAN MAC: 13 bytes
PHY: ~12 bytes
Total: 33 bytes (76% overhead)
Option B: CoAP/UDP/6LoWPAN over LoRaWAN (if IP needed)
Payload: 8 bytes
CoAP: 8 bytes
UDP: 8 bytes
6LoWPAN: 6 bytes
LoRaWAN MAC: 13 bytes
PHY: ~12 bytes
Total: 55 bytes (85% overhead, +67% more bytes than Option A)
Option C: MQTT/TCP/IP over Wi-Fi (mismatched choice)
Payload: 8 bytes
MQTT: 12 bytes
TCP: 20 bytes
IPv4: 20 bytes
802.11: 36 bytes
Total: 96 bytes (92% overhead, 3x more bytes than Option A)
Battery: ~6 months (Wi-Fi TX current 150-300 mA vs LoRa 40 mA)
Decision: Option A (raw binary over LoRaWAN) is optimal. The 33-byte total at SF7 transmits in 36 ms, consuming 4.8 mJ per message. At 48 messages/day, battery lasts 10+ years.
When would Option B or C be better? If the sensors needed direct cloud connectivity without a gateway (use NB-IoT + CoAP), or if sensors were indoors within 50 m of an access point with mains power (use Wi-Fi + MQTT).
Try It: LoRaWAN Battery Life Estimator
Adjust the parameters below to see how payload size, transmission interval, and spreading factor affect projected battery life for a LoRaWAN sensor.
-20 dB signal attenuation through cast iron covers
BLE (10m range insufficient), Zigbee (no penetration)
500m to 2 km to nearest gateway
Urban density varies
BLE, Zigbee (range too short without mesh)
32-byte payload
Meter ID + volume + tamper flag + battery level
All protocols viable for this size
Bi-monthly firmware updates
2 KB OTA fragments
LoRaWAN Class A multicast capable
Chosen stack: Raw binary payload over LoRaWAN Class A (EU868), SF10 for underground penetration.
Results after 4 years:
Data delivery rate: 98.7% (1.3% lost to deep underground locations)
Battery life: 13.2 years projected (approaching 15-year target at 1.8 readings/day average)
Gateway density: 1 gateway per 2.1 km radius in urban areas, 347 gateways total
Cost per reading: 0.003 GBP (vs. 3.20 GBP for manual van-based reading)
Annual savings: 8.4 million GBP in operational costs
Key lesson: The protocol stack choice saved Thames Water 97% on per-reading costs. NB-IoT was rejected despite better coverage because the 0.50 GBP/device/month cellular subscription over 15 years exceeded the entire LoRaWAN infrastructure cost.
Case Study: Bosch Connected Industry (Stuttgart, 2019-2023)
Bosch’s Stuttgart factory connected 12,000 industrial sensors across 14 production lines using a hybrid Wi-Fi + MQTT protocol stack, replacing legacy Modbus/RS-485 wiring.
Why Wi-Fi + MQTT instead of industrial Ethernet:
Factor
Wi-Fi + MQTT
PROFINET
Decision Rationale
Installation cost per node
45 EUR (wireless sensor + gateway share)
280 EUR (cable + switch port + commissioning)
84% lower per-node cost
Latency requirement
500 ms acceptable (monitoring, not control)
<1 ms (motion control)
Wi-Fi meets monitoring SLA
Retrofit difficulty
Zero cable runs in existing building
14 km of new Cat6 cable needed
3 months vs. 14 months deployment
Payload
200-byte JSON every 10 seconds
Cyclic 50-byte frames at 1 ms
MQTT handles variable payloads natively
MQTT broker sizing:
Broker: EMQX cluster (3 nodes)
Connections: 12,000 persistent MQTT 5.0 sessions
Message rate: 72,000 messages/minute (12,000 sensors x 6/minute)
QoS: Level 1 for vibration alerts, Level 0 for temperature telemetry
Outcome: 42% reduction in unplanned downtime through predictive maintenance alerts. The MQTT topic hierarchy enabled dashboards to subscribe to bosch/stuttgart/line-07/# for line-level views or bosch/stuttgart/+/+/vibration for cross-factory vibration monitoring.
Common Pitfalls
1. Assuming “Same Protocol Name” Means Full Interoperability
Zigbee 3.0 and Zigbee 2012 devices may not interoperate despite sharing the Zigbee brand. MQTT 3.1.1 and MQTT 5.0 have different feature sets. Fix: check the exact version number and profile compatibility between all devices in a deployment.
2. Confusing a Protocol With a Product
“Zigbee” is a protocol specification; “Hue” is a Philips product that uses Zigbee. The product may implement only a subset of the protocol. Fix: when evaluating IoT products, check which protocol profile and features are actually implemented, not just the protocol family name.
3. Not Reading the RFC or Standard Before Implementing
Tutorial blog posts about MQTT or CoAP may omit edge cases that the actual RFC specifies. Fix: read the relevant RFC sections (especially error handling and edge cases) before implementing any protocol, even if a library handles most of it.
🏷️ Label the Diagram
Code Challenge
15.7 Summary
IoT protocols map to OSI layers with application protocols (MQTT, CoAP) at Layer 7, transport (TCP/UDP) at Layer 4, and wireless technologies (Wi-Fi, LoRa) at Layers 1-2
Protocol selection depends on requirements including range, power, data rate, and latency
Data encapsulation adds overhead at each layer (MQTT + TCP + IP + Wi-Fi = 80+ bytes of headers for small payloads)
Use case context matters—the best protocol varies by industry and application scenario
Real deployments balance cost, battery, and coverage—Thames Water saved 97% per reading with LoRaWAN; Bosch saved 84% per node with Wi-Fi + MQTT
