%%{init: {'theme': 'base', 'themeVariables': { 'primaryColor': '#2C3E50', 'primaryTextColor': '#fff', 'primaryBorderColor': '#16A085', 'lineColor': '#E67E22', 'secondaryColor': '#16A085', 'tertiaryColor': '#E8F6F3', 'clusterBkg': '#E8F6F3', 'clusterBorder': '#16A085', 'fontSize': '13px'}}}%%
graph TD
Start["IoT Device Requirements"]
Start --> Power{"Power Source?"}
Power -->|Battery| Range1{"Range Needed?"}
Power -->|Mains| Range2{"Range Needed?"}
Range1 -->|"< 100m"| BLE["Bluetooth LE<br/>+ CoAP/UDP"]
Range1 -->|"100m - 1km"| Zigbee["Zigbee/Thread<br/>+ 6LoWPAN<br/>+ CoAP/UDP"]
Range1 -->|"> 1km"| LPWAN["LoRaWAN/NB-IoT<br/>+ Custom/CoAP"]
Range2 -->|"< 300m"| Wi-Fi["Wi-Fi<br/>+ MQTT/TCP<br/>or CoAP/UDP"]
Range2 -->|"> 300m"| Ethernet["Ethernet<br/>+ MQTT/TCP<br/>or HTTP/REST"]
BLE --> Protocol1{"Data Pattern?"}
Zigbee --> Protocol1
Wi-Fi --> Protocol2{"Data Pattern?"}
Protocol1 -->|Request-Response| UseCoAP["Use CoAP<br/>4-byte header<br/>UDP lightweight"]
Protocol1 -->|Pub-Sub| UseMQTT["Use MQTT-SN<br/>for constrained"]
Protocol2 -->|Request-Response| UseHTTP["Use HTTP/REST<br/>or CoAP"]
Protocol2 -->|Pub-Sub| UseMQTT2["Use MQTT<br/>reliable pub/sub"]
style Start fill:#2C3E50,stroke:#16A085,color:#fff
style BLE fill:#16A085,stroke:#2C3E50,color:#fff
style Zigbee fill:#16A085,stroke:#2C3E50,color:#fff
style Wi-Fi fill:#16A085,stroke:#2C3E50,color:#fff
style LPWAN fill:#E67E22,stroke:#2C3E50,color:#fff
style UseCoAP fill:#2C3E50,stroke:#16A085,color:#fff
style UseMQTT fill:#2C3E50,stroke:#16A085,color:#fff
670 IoT Protocols Lab: Selection Framework
670.1 Learning Objectives
By the end of this chapter, you will be able to:
- Apply protocol selection decision trees: Navigate from requirements to protocol choice systematically
- Evaluate energy efficiency trade-offs: Compare protocols by energy-per-bit and instantaneous power
- Calculate protocol overhead: Determine frame sizes and payload efficiency for different stacks
- Assess battery life impact: Estimate how protocol choice affects device longevity
- Design hybrid protocol architectures: Combine protocols for edge-to-cloud communication
TipFor Beginners: What You’ll Learn
What is this chapter? A systematic framework for selecting IoT protocols based on real-world constraints.
Why it matters: - Wrong protocol choice can reduce battery life from years to weeks - Different deployment scenarios require different protocol combinations - Understanding trade-offs prevents costly redesigns later
Prerequisites: - IoT Protocols Lab: IPv6 and 6LoWPAN - IoT Protocols Lab: CoAP vs MQTT
670.2 Protocol Selection Framework
{fig-alt=“Protocol selection decision tree starting with power source (battery vs mains), then range requirements (short/medium/long), leading to technology choices (BLE, Zigbee, Wi-Fi, LoRaWAN, Ethernet) and finally application protocol selection (CoAP for request-response, MQTT for pub-sub patterns)”}
670.2.1 Protocol Energy Efficiency Comparison
Understanding power consumption and energy-per-bit is critical for battery-powered IoT devices. Higher data rate protocols can be more energy-efficient per bit despite higher instantaneous power.
Wireless Protocol Energy Efficiency: Counter-intuitively, Wi-Fi (210 mW) achieves the best energy efficiency at 5.25 nJ/bit because its 40 Mbps data rate amortizes the power investment. BLE (0.147 mW, 153 nJ/bit) is ~30× less efficient per bit but ~1,400× lower instantaneous power—critical for battery life. Zigbee (186,000 nJ/bit) is extremely inefficient for data transfer but optimized for mesh networking and low duty-cycle operation. The key insight: energy per bit is a strong function of data rate and range.
| Protocol | Power (mW) | Data Rate | Energy/Bit (nJ) | Best For |
|---|---|---|---|---|
| Bluetooth LE | 0.147 | 960 bps | 153 | Wearables, beacons |
| ANT+ | 0.675 | 272 bps | 2,480 | Sports sensors |
| Zigbee | 35.7 | 192 bps | 186,000 | Mesh networks |
| Wi-Fi | 210 | 40 Mbps | 5.25 | High throughput |
TipProtocol Selection Rule of Thumb
- Maximize battery life: Choose lowest instantaneous power (BLE)
- Minimize energy per byte: Choose highest data rate (Wi-Fi)
- Balance both: Duty-cycle high-rate protocols aggressively
Example: Sending 1 KB of sensor data - BLE (153 nJ/bit): 1 KB × 8 bits × 153 nJ = 1.22 mJ, takes 8.5 seconds - Wi-Fi (5.25 nJ/bit): 1 KB × 8 bits × 5.25 nJ = 0.042 mJ, takes 0.2 ms
Wi-Fi uses 30× less energy for the transfer but wakes from sleep with higher startup cost. The optimal choice depends on payload size and transfer frequency.
670.3 Hands-On Lab: Protocol Overhead Analysis
670.4 Lab Activity: Compare Protocol Efficiency
Objective: Calculate and compare overhead for different protocol combinations
Scenario: Temperature sensor (2 bytes) and humidity (2 bytes) = 4 bytes payload
670.4.1 Task 1: Calculate Total Frame Size
Calculate frame size for different protocol stacks:
- Full stack (uncompressed): 802.15.4 + IPv6 + UDP + CoAP
- Compressed stack: 802.15.4 + 6LoWPAN + UDP + CoAP
- MQTT stack: Ethernet + IPv6 + TCP + MQTT
- HTTP stack (for comparison): Ethernet + IPv4 + TCP + HTTP
Click to see solution
1. Full Stack (Uncompressed):
802.15.4 MAC: 25 bytes
IPv6: 40 bytes
UDP: 8 bytes
CoAP: 4 bytes
Payload: 4 bytes
Total: 81 bytes
Overhead: 77 bytes (95% overhead!)
Efficiency: 4.9%2. Compressed Stack (6LoWPAN):
802.15.4 MAC: 25 bytes
6LoWPAN (compressed IPv6 + UDP): 6 bytes
CoAP: 4 bytes
Payload: 4 bytes
Total: 39 bytes
Overhead: 35 bytes (90% overhead)
Efficiency: 10.3%Improvement: 81 → 39 bytes (52% reduction)
3. MQTT Stack (assuming kept-alive TCP):
Ethernet MAC: 18 bytes (header + FCS)
IPv6: 40 bytes
TCP: 20 bytes
MQTT Fixed Header: 2 bytes
MQTT Variable Header: ~10 bytes (topic "home/temp")
Payload: 4 bytes
Total: 94 bytes
Overhead: 90 bytes (96% overhead)
Efficiency: 4.3%4. HTTP Stack (minimum request):
Ethernet MAC: 18 bytes
IPv4: 20 bytes
TCP: 20 bytes
HTTP: ~100 bytes (GET /sensor/temp HTTP/1.1...)
Payload: 4 bytes
Total: 162 bytes
Overhead: 158 bytes (98% overhead)
Efficiency: 2.5%Comparison: - 6LoWPAN + CoAP: 39 bytes (best) - MQTT: 94 bytes (2.4× CoAP) - HTTP: 162 bytes (4.2× CoAP)
Conclusion: For very small payloads, 6LoWPAN + CoAP is most efficient.670.4.2 Task 2: Calculate Transmissions for Battery Life
Sensor transmits every 5 minutes. Battery: 2000 mAh.
Given: - Radio TX: 5 mA - Data rate: 250 kbps (802.15.4) - Sleep: 5 µA
Calculate daily power consumption for: 1. CoAP (39 bytes, UDP) 2. MQTT (94 bytes, TCP with keep-alive)
Estimate battery life.
Click to see solution
Transmissions per day: 24 × 60 / 5 = 288
CoAP (UDP, 39 bytes):
TX time per message:
= 39 bytes × 8 bits / 250,000 bps
= 1.25 ms
Total TX time per day:
= 288 × 1.25 ms = 360 ms
Energy (TX):
= 5 mA × 0.36 s = 1.8 mA·s = 0.5 µA·h
Energy (Sleep):
= 5 µA × (86,400 - 0.36) s / 3600 = 120 µA·h
Total per day: 120.5 µA·h = 0.12 mA·h
Battery life: 2000 / 0.12 = 16,667 days = 45.7 yearsMQTT (TCP keep-alive, 94 bytes + ACKs):
Assuming TCP connection kept open:
- Data: 94 bytes
- ACK: 40 bytes (IPv6 + TCP)
- Total per transmission: 134 bytes
TX+RX time per message:
= 134 bytes × 8 bits / 250,000 bps
= 4.3 ms
Total active time per day:
= 288 × 4.3 ms = 1.24 s
Energy (TX/RX):
= 5 mA × 1.24 s = 6.2 mA·s = 1.7 µA·h
Energy (Sleep):
= 5 µA × (86,400 - 1.24) s / 3600 = 120 µA·h
Total per day: 121.7 µA·h = 0.122 mA·h
Battery life: 2000 / 0.122 = 16,393 days = 44.9 yearsAnalysis: For infrequent transmission (every 5 min), sleep current dominates. Protocol overhead has minimal impact on battery life (both ~45 years, limited by battery self-discharge).
If transmitting every 10 seconds (8,640 times/day): - CoAP: 10.8 s active → 15 µA·h/day → 133 days / 0.4 years - MQTT: 37.2 s active → 51.7 µA·h/day → 38 days / 0.1 years
Conclusion: For frequent transmission, CoAP saves significant power (3.4× longer battery life).670.5 Knowledge Check
670.6 Summary
This chapter provided a systematic framework for IoT protocol selection:
- Start with power source: Battery devices need BLE/Zigbee/LoRaWAN; mains-powered can use Wi-Fi/Ethernet
- Consider range requirements: Short (<100m) favors BLE, medium (100m-1km) uses Zigbee/Thread, long (>1km) needs LPWAN
- Match data patterns to protocols: Request-response suits CoAP, pub-sub suits MQTT
- Energy efficiency is nuanced: Wi-Fi has best energy/bit (5.25 nJ) but highest instantaneous power (210 mW)
- Header compression is critical for small payloads: 6LoWPAN + CoAP achieves 52% reduction over uncompressed IPv6
- Transmission frequency determines impact: Infrequent transmission is sleep-dominated; frequent transmission makes protocol choice critical (3.4× battery life difference)
670.7 What’s Next
Apply these concepts with hands-on Python implementations:
- IoT Protocols Lab: Python Implementations: Build protocol analyzers, battery calculators, and automated selectors
- IoT Protocols Review: Comprehensive protocol comparison matrix
- Design Implications: Network architecture decisions based on protocol selection