30  IoT Protocols: Labs and Selection

Key Concepts
  • Lab Progression: A sequenced series of hands-on exercises that build practical skills incrementally from basic connectivity to complex protocol comparison
  • Protocol Benchmark: A standardised test measuring latency, throughput, and packet loss for a protocol under defined conditions
  • Simulation vs Physical Lab: Simulation (Cooja, NS-3) is faster and reproducible; physical labs reveal real-world RF and timing behaviour
  • Assessment Rubric: A scoring guide that evaluates lab reports on accuracy, analysis depth, and adherence to the experimental procedure
  • Protocol Decision Record: A written artefact documenting which protocol was chosen, why, and what alternatives were considered and rejected
  • Cross-Protocol Comparison: Running identical workloads on MQTT and CoAP to measure their relative overhead and suitability
  • Lab Safety: Ensuring RF transmissions comply with power limits and that test equipment is properly grounded

30.1 In 60 Seconds

This index chapter guides you through hands-on labs covering IPv6/6LoWPAN addressing, CoAP vs. MQTT comparison, protocol selection frameworks, and Python implementation tools. Use it as a roadmap for practical protocol evaluation – from understanding address space requirements through designing complete communication stacks and testing protocol performance.

30.2 Learning Objectives

By the end of this chapter series, you will be able to:

  • Differentiate IPv4 and IPv6: Evaluate address space requirements and transition strategies for IoT
  • Apply protocol selection criteria: Choose protocols based on power, bandwidth, latency, and reliability constraints
  • Architect protocol stacks: Plan complete communication stacks from physical to application layers
  • Construct protocol labs: Build hands-on projects demonstrating protocol operations
  • Evaluate trade-offs: Balance competing requirements when selecting communication technologies
  • Measure protocol performance: Quantify throughput, latency, and reliability in IoT deployments

What is this chapter? An index to hands-on labs and protocol selection guidance for IoT projects.

When to use:

  • After studying IoT protocols overview
  • When choosing protocols for your project
  • For practical implementation exercises

Key Decision Factors:

Factor Consideration
Power Budget Battery vs mains powered
Data Rate Sensor telemetry vs video
Range Indoor vs outdoor deployment
Latency Real-time vs batch processing

Prerequisites:

  • Understanding of IoT protocol landscape
  • Basic networking knowledge
  • Familiarity with protocol trade-offs

Recommended Path:

  1. Review IoT Protocols Overview
  2. Complete labs in this chapter series
  3. Reference during project planning

30.3 Chapter Overview

This chapter series provides comprehensive hands-on coverage of IoT protocol selection and implementation. The content is organized into focused modules:

30.3.1 IPv6 and 6LoWPAN

Deep dive into network layer technologies essential for scalable IoT:

  • IPv6 addressing for unlimited device connectivity
  • 6LoWPAN header compression enabling IPv6 on constrained 802.15.4 networks
  • Thread protocol stack as a real-world 6LoWPAN implementation
  • Smart city deployment analysis for million-device scenarios

30.3.2 CoAP vs MQTT

Comprehensive comparison of the two dominant IoT application protocols:

  • CoAP characteristics: RESTful design, UDP transport, 4-byte headers
  • MQTT characteristics: Publish-subscribe, QoS levels, broker architecture
  • Selection criteria: When to use each protocol based on device constraints
  • Hybrid architectures: Combining CoAP and MQTT for edge-to-cloud communication

30.3.3 Selection Framework

Systematic approach to protocol selection with hands-on calculations:

  • Decision tree navigation: From power source to application protocol
  • Energy efficiency analysis: Compare protocols by energy-per-bit and instantaneous power
  • Protocol overhead labs: Calculate frame sizes for different stacks
  • Battery life impact: Quantify how protocol choice affects device longevity

30.3.4 Python Implementations

Practical tools and comprehensive worked examples:

  • Protocol stack analyzer: Calculate overhead and efficiency programmatically
  • Battery life calculator: Estimate device longevity from transmission patterns
  • Protocol selector engine: Automate recommendations based on requirements
  • Building management worked example: Complete 250-sensor deployment design

30.4 Quick Reference: Protocol Selection

Requirement Recommended Stack
Battery + Short Range (<100m) BLE + CoAP/UDP
Battery + Medium Range (100m-1km) Zigbee/Thread + 6LoWPAN + CoAP
Battery + Long Range (>1km) LoRaWAN/NB-IoT + Custom
Mains Power + Pub-Sub Wi-Fi + MQTT/TCP
Mains Power + REST API Ethernet + HTTP/REST
Real-time Control UDP-based (CoAP)
Reliable Telemetry TCP-based (MQTT with QoS)
Try It: IoT Protocol Stack Selector

Select your deployment requirements to get a recommended protocol stack.

Try It: Battery Lifetime Estimator

Estimate IoT device battery life based on transmission patterns and sleep current.

30.5 Prerequisites

Before diving into these chapters, you should be familiar with:

  • Networking Basics for IoT: Understanding of fundamental networking concepts, OSI model, and TCP/IP stack provides the foundation for protocol analysis and selection
  • IoT Protocols: Fundamentals: Familiarity with IoT-specific protocol constraints, resource limitations, and the basic IoT protocol stack helps contextualize why specialized protocols like 6LoWPAN are needed
  • Layered Models: Fundamentals: Knowledge of layered networking models and encapsulation is essential for understanding how protocols at different layers (IPv6, UDP/TCP, CoAP/MQTT) work together
  • IoT Protocols Overview: Overview of the complete IoT protocol landscape provides context for comparing specific protocols like CoAP vs MQTT and understanding their positions in the stack

30.6 Knowledge Check

Scenario: A city deploys 5,000 magnetic parking sensors across downtown. Each sensor detects vehicle presence (occupied/vacant) and must report status changes within 30 seconds. Battery life target: 5 years. Budget: $500K total (hardware + infrastructure).

Step 1: Define requirements

Requirement Value Impact
Number of devices 5,000 Rules out high per-device cost solutions
Coverage area 2 km × 2 km downtown Rules out short-range protocols
Update frequency On-change + 30-sec heartbeat Low data volume but frequent
Battery life 5 years Rules out high-power protocols
Latency <30 seconds Rules out store-and-forward batch systems
Payload 1 byte (0=vacant, 1=occupied) Tiny payload favors low-overhead protocols

Step 2: Evaluate protocol options

Option A: Cellular NB-IoT

Pros: No infrastructure (uses cell towers)
Cons:
  - $3/month per sensor = $15K/month = $900K over 5 years (exceeds entire budget)
  - Verdict: Too expensive at scale

Option B: Wi-Fi

Pros: High bandwidth, ubiquitous
Cons:
  - Power: 150 mA TX = battery life ~6 months (far short of 5-year target)
  - Infrastructure: Need ~100 APs at $300 each = $30K + installation
  - Verdict: Power consumption eliminates it

Option C: Zigbee/Thread

Pros: Low power, mesh networking
Cons:
  - Range: 100m per hop → need ~40 border routers at $400 each = $16K
  - Complexity: Mesh routing adds latency (multi-hop to border router)
  - Verdict: Viable but expensive infrastructure

Option D: LoRaWAN

Pros:
  - Range: 2-5 km per gateway → need only 2-4 gateways = $3.2K
  - Power: 10-year battery life achievable with 30-sec reporting
  - Cost: $15/sensor × 5,000 = $75K + $3.2K infra = $78.2K (well under budget)
Cons:
  - Data rate: ~5.5 kbps at SF7/125 kHz (but we only need 1 byte = 8 bits per message)
  - Duty cycle limits: 1% in EU, 30 sec is fine
  - Verdict: **Best fit**

Decision: LoRaWAN (Option D)

Step 3: Design complete protocol stack

Physical Layer: LoRa modulation at 915 MHz (US) / 868 MHz (EU)
  - SF7 (spreading factor) for minimum airtime
  - 125 kHz bandwidth
  - TX power: 14 dBm (25 mW)

Data Link Layer: LoRaWAN MAC
  - Class A (sensor-initiated, lowest power)
  - Unconfirmed uplinks (QoS not critical for parking)
  - No downlinks (saves power)

Network Layer: None (LoRaWAN provides addressing)
  - Each sensor has unique DevEUI
  - Gateway forwards to network server via IP

Application Layer: Custom binary protocol
  Payload structure (3 bytes total):
    - Byte 0: Sensor ID (lower 8 bits, full ID in LoRaWAN header)
    - Byte 1: Status (0=vacant, 1=occupied)
    - Byte 2: Battery voltage (0-255 = 0-5V)

Gateway Layer: LoRaWAN gateway → MQTT bridge
  - Gateways forward LoRa packets to network server via MQTT
  - Network server decrypts and publishes to application MQTT topic
  - Cloud server subscribes to MQTT topic

Step 4: Validate energy budget

LoRaWAN Transmission Energy:

Airtime for 3-byte payload at SF7:
  Time-on-air = 41.2 ms (from LoRa calculator)

Energy per transmission:
  TX: 41.2 ms × 25 mW = 1.03 mJ

Transmissions per day:
  On-change: Average 4 per day (2 arrivals + 2 departures)
  Heartbeat: 1 per 30 sec = 2,880 per day
  Total: 2,884 transmissions/day

Daily energy (TX only):
  2,884 × 1.03 mJ = 2.97 J/day

Add sleep current:
  Sleep: 5 μA × 3.3V × 86,400 sec = 1.43 J/day

Total daily energy: 4.4 J/day

Battery capacity:
  2× AA lithium batteries in series = 3,000 mAh at 3.0V
  Energy = 3.0 Ah × 3.0V = 9.0 Wh = 32,400 J

Battery life:
  32,400 J / 4.4 J/day = 7,364 days ≈ 20 years

Verdict: Exceeds 5-year target with huge margin (20 years theoretical)

Battery lifetime depends on total energy capacity divided by daily consumption across all modes (sleep, transmit, receive).

\[\text{Lifetime (days)} = \frac{\text{Battery Capacity (mAh)}}{\text{Daily Energy (mAh/day)}}\]

Worked example: 2,000 mAh battery with daily consumption breakdown: - Sleep: 0.005 mA × 24h = 0.12 mAh/day - TX (10 msgs × 2s × 20mA): 0.11 mAh/day - RX (10 acks × 0.5s × 15mA): 0.02 mAh/day - Total: 0.25 mAh/day

Lifetime = 2,000 ÷ 0.25 = 8,000 days ≈ 22 years

This shows why optimizing sleep current (99.9% duty cycle) has far more impact than reducing transmission power.

Step 5: Cost breakdown

Component Unit Cost Quantity Total
Magnetic sensor module $12 5,000 $60,000
LoRa radio module (SX1276) $3 5,000 $15,000
LoRaWAN gateway $800 4 $3,200
Cloud MQTT broker $200/month 60 months $12,000
Installation labor $8/sensor 5,000 $40,000
Total 5-year TCO $130,200

Budget remaining: $500K - $130K = $369.8K (26% of budget used)

Step 6: Deployment verification

Link budget check:

TX power: +14 dBm
Gateway sensitivity (SF7): -123 dBm
Required SNR: -7.5 dB

Path loss budget: 14 - (-123) = 137 dB

First Fresnel zone radius at midpoint (2 km, 868 MHz):
  λ = c/f = 0.346 m; r₁ = √(λ×d/4) = √(0.346×2000/4) ≈ 13 m

Urban path loss (COST231-Hata):
  PL = 137 dB at 2.5 km (verified with RF planning tool)

Margin: 137 dB available - 137 dB required = 0 dB (marginal)

Solution: Add 2 extra gateways for redundancy (total 4 → 6 gateways)

Final Recommendation:

Layer Protocol Justification
Physical LoRa 915 MHz SF7 2-5 km range, 20-year battery life
Data Link LoRaWAN Class A Ultra-low power, unconfirmed uplinks sufficient
Network LoRaWAN addressing No IP needed, DevEUI provides unique IDs
Application 3-byte binary Minimal overhead (3 bytes payload vs 40+ for IP)
Gateway Bridge MQTT Standard cloud integration

Result: $130K deployment (26% of budget), 20-year battery life (4× target), 30-second latency met.

30.7 Concept Relationships

This index chapter connects protocol fundamentals to hands-on practice:

Related Concepts:

  • Protocol layering from networking basics applies directly to lab exercises on overhead calculation
  • Battery life optimization connects protocol selection decisions to energy consumption measurements
  • Frame size constraints (127-byte 802.15.4 limit) drive the need for 6LoWPAN compression explored in labs
  • Transport layer choice (TCP vs UDP) impacts reliability, latency, and power consumption measured in labs

Builds on: Prerequisites listed above

Builds Foundation For:

30.8 See Also

Related Labs:

Protocol Resources:

Verification Tools:

Common Pitfalls

Students run commands, see “it works,” and move on without capturing packet traces or timing measurements. Fix: require a structured observation sheet for every lab step, recorded before moving to the next step.

Retained MQTT messages or stale CoAP resources from one exercise interfere with the next. Fix: include explicit teardown steps (broker restart, resource deletion) in the lab procedure.

Cooja simulations use simplified radio models that ignore multipath and interference. Fix: always note simulation assumptions in the lab report and flag how real-world conditions might differ.

Writing “I chose MQTT because it seemed easier” earns no marks. Fix: use the weighted scoring matrix from the selection framework lab and cite specific measured results to justify the recommendation.

30.9 What’s Next

If you want to… Read this
Run the CoAP and MQTT hands-on lab CoAP and MQTT Lab
Run the IPv6/6LoWPAN lab IPv6 and 6LoWPAN Lab
Run Python implementations lab Python Implementations Lab
Use the structured selection framework Protocol Selection Framework
Review real-world deployment examples Real-World Examples