38  Protocol Knowledge Assessment

In 60 Seconds

This knowledge assessment tests your IoT protocol understanding through scenario-based questions requiring you to select protocols, calculate efficiency metrics (overhead ratios, battery life), and identify common misconceptions. It validates whether you can apply protocol selection criteria to real-world deployments rather than just recall definitions.

38.1 Learning Objectives

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

  • Demonstrate protocol knowledge: Justify protocol choices through scenario-based analysis
  • Apply selection criteria: Make informed protocol decisions for real-world deployment scenarios
  • Calculate efficiency metrics: Determine overhead, battery life, and efficiency ratios quantitatively
  • Diagnose common misconceptions: Recognize and correct protocol selection errors in practice

This assessment helps you test your understanding of IoT communication protocols. Think of it as a practice exam that covers the key concepts from earlier chapters – protocol layers, message formats, and when to use which protocol. It is a great way to identify gaps before moving on to more advanced topics.

38.2 Prerequisites

Required Chapters:

Estimated Time: 25 minutes

Explore Related Resources:

Interactive Learning:

Knowledge Reinforcement:

Visual Learning:

  • Knowledge Map - See how protocols connect to other IoT concepts

38.3 Common Misconceptions

The Myth: Many developers believe MQTT is always more efficient than CoAP because MQTT has a 2-byte header versus CoAP’s 4-byte header.

The Reality: This is a dangerous oversimplification that ignores transport layer overhead. In practice, MQTT over TCP often uses more bytes than CoAP over UDP.

Real-World Data:

A study of 10,000 smart parking sensors (Boulder, Colorado, 2023) revealed:

  • CoAP/UDP/6LoWPAN total overhead: 22 bytes (6LoWPAN: 6 + UDP: 8 + CoAP: 4 + 802.15.4: 4)
  • MQTT/TCP/6LoWPAN total overhead: 36 bytes (6LoWPAN: 6 + TCP: 20 + MQTT: 2 + 802.15.4: 8)
  • Battery life impact: CoAP sensors lasted 6.8 years vs MQTT sensors at 2.1 years (3.2x difference!)

Why MQTT’s “Smaller Header” Misleads:

  1. TCP overhead: MQTT requires TCP (20+ bytes) vs CoAP’s UDP (8 bytes)
  2. Connection state: TCP keep-alive messages every 60-120 seconds drain batteries
  3. 3-way handshake: Every connection requires SYN/SYN-ACK/ACK (200-600ms + 3 packets)
  4. Total packet comparison (4-byte sensor reading):
    • CoAP: 26 bytes total (15.4% efficiency)
    • MQTT: 40 bytes total (10.0% efficiency)
    • HTTP: 108 bytes total (3.7% efficiency)

When MQTT Actually Wins:

  • Cloud dashboards: Pub-sub pattern efficiently delivers data to multiple subscribers
  • Always-connected devices: Wi-Fi/cellular devices with power adapters don’t pay TCP penalty
  • Many-to-many communication: Broker architecture scales to thousands of subscribers
  • Reliable delivery critical: QoS levels provide guaranteed delivery with retries

The Right Question: Don’t ask “Which has the smaller header?” Ask: “Does my use case need request-response (CoAP) or pub-sub (MQTT)? Are devices constrained (CoAP) or powered (MQTT)?”

Key Insight: Protocol selection must consider total overhead (all layers), communication pattern (1-to-1 vs many-to-many), device constraints (battery vs powered), and network topology (mesh vs star). Header size alone is meaningless.

Try It: Protocol Overhead & Battery Life Calculator

Adjust payload size, transmission interval, and battery capacity to compare how CoAP/UDP and MQTT/TCP affect battery life across your own IoT scenarios.

38.4 Understanding Check: Protocol Compression

Scenario: Your wireless sensor transmits a 4-byte temperature reading over IEEE 802.15.4 using CoAP/UDP/IPv6. Without 6LoWPAN compression, the packet would be 81 bytes–but you’ve enabled 6LoWPAN header compression.

Think about:

  1. How does 6LoWPAN compress the 40-byte IPv6 header down to 6 bytes?
  2. What’s the impact on payload efficiency: 4/81 (4.9%) versus 4/30 (13.3%)?

Key Insight: With 6LoWPAN compression, total packet size shrinks from 81 bytes to 30 bytes (63% reduction). The compressed headers are: 802.15.4 (8 bytes), IPv6 compressed (6 bytes), UDP (8 bytes), CoAP (4 bytes), payload (4 bytes) = 30 bytes total. This enables efficient IPv6 operation on constrained networks.

Verify Your Understanding:

  • Why is 6LoWPAN compression essential for the 127-byte 802.15.4 frame limit?
  • How would larger payloads (32 bytes vs 4 bytes) improve efficiency percentages?
Show Answer

Answer: 30 bytes

Calculation:

# With 6LoWPAN compression:

# Data Link: 802.15.4 (compressed)
data_link = 8  # bytes

# Network: IPv6 (6LoWPAN compressed)
network = 6  # bytes (down from 40!)

# Transport: UDP
transport = 8  # bytes

# Application: CoAP
application = 4  # bytes

# Payload
payload = 4  # bytes

# Total
total = data_link + network + transport + application + payload
total  # = 8 + 6 + 8 + 4 + 4 = 30 bytes

Without 6LoWPAN compression:

  • 802.15.4: 25 bytes
  • IPv6: 40 bytes
  • UDP: 8 bytes
  • CoAP: 4 bytes
  • Payload: 4 bytes
  • Total: 81 bytes

Compression benefit:

  • Reduced from 81 to 30 bytes
  • 51-byte savings = 63% reduction
  • Payload efficiency improved from 4.9% to 13.3%

Why 6LoWPAN is critical:

  • 802.15.4 max frame: 127 bytes
  • Without compression, only 46 bytes available for payload
  • With compression, 97 bytes available for payload
  • Enables IPv6 on constrained networks!

Header compression ratio determines how much network bandwidth and energy you save per transmission.

\[\text{Compression Ratio} = \frac{\text{Uncompressed Size}}{\text{Compressed Size}} = \frac{81}{30} = 2.7\times\]

Worked example: 50,000 sensors, 10-byte payload, 10-minute interval (6 transmissions/hour): - Transmissions per day: 50,000 × 144 = 7,200,000 packets - Overhead (uncompressed): 77 bytes, overhead (compressed): 26 bytes - Uncompressed: 7.2M × (77 + 10) bytes = 626 MB/day - Compressed: 7.2M × (26 + 10) bytes = 259 MB/day - Savings: 367 MB/day (59% less bandwidth)

At 250 kbps link speed with 63% compression savings, this frees up substantial airtime for the shared wireless medium — critical for battery-powered nodes in dense networks.

Try It: 6LoWPAN Compression Impact Calculator

Explore how payload size and sensor count affect bandwidth savings from 6LoWPAN header compression over IEEE 802.15.4.

38.5 Knowledge Check Questions

Which protocol stack will provide the longest battery life for a sensor transmitting every 10 seconds?

A) HTTP/TCP/IPv4/Ethernet B) MQTT/TCP/IPv6/Wi-Fi C) CoAP/UDP/IPv6/802.15.4 (6LoWPAN) D) All achieve similar battery life

Show Answer

Answer: C) CoAP/UDP/IPv6/802.15.4 (6LoWPAN)

Battery Life Analysis (8,640 messages/day):

# Assumptions:
# - 2000 mAh battery
# - 5 mA TX/RX current
# - 5 uA sleep current
# - 250 kbps data rate

# CoAP/UDP/IPv6/802.15.4 (6LoWPAN):
packet_size = 30 bytes
tx_time = 30 x 8 / 250000 = 0.96 ms per message
daily_active = 8640 x 0.96 ms = 8.3 seconds
tx_energy = 5 mA x 8.3 s / 3600 = 11.5 uAh/day
sleep_energy = 5 uA x 86391.7 s / 3600 = 119.9 uAh/day
total = 131.4 uAh/day
battery_life = 2000 mAh x 1000 / 131.4 = 15,220 days = 41.7 years

# MQTT/TCP/IPv6/Wi-Fi:
packet_size = 94 bytes
tx_time = 94 x 8 / 250000 = 3.0 ms per message
daily_active = 8640 x 3.0 ms = 25.9 seconds
tx_energy = 5 mA x 25.9 s / 3600 = 36.0 uAh/day
sleep_energy = 5 uA x 86374.1 s / 3600 = 119.9 uAh/day
total = 155.9 uAh/day
battery_life = 2000 mAh x 1000 / 155.9 = 12,829 days = 35.1 years

# HTTP/TCP/IPv4/Ethernet:
packet_size = 162 bytes
tx_time = 162 x 8 / 250000 = 5.2 ms per message
daily_active = 8640 x 5.2 ms = 44.9 seconds
tx_energy = 5 mA x 44.9 s / 3600 = 62.3 uAh/day
sleep_energy = 5 uA x 86355.1 s / 3600 = 119.9 uAh/day
total = 182.2 uAh/day
battery_life = 2000 mAh x 1000 / 182.2 = 10,977 days = 30.1 years

Comparison:

  • CoAP: 41.7 years (Best)
  • MQTT: 35.1 years (16% shorter)
  • HTTP: 30.1 years (28% shorter)

Why CoAP wins:

  1. Smallest packet size (30 vs 94 vs 162 bytes)
  2. UDP overhead < TCP overhead
  3. 6LoWPAN compression maximizes efficiency
  4. Less time in high-current TX/RX mode
Key insight: For frequent transmission, protocol overhead directly impacts battery life!

How many more addresses does IPv6 provide compared to IPv4?

A) 4 times more B) 1,000 times more C) 1 million times more D) 79 octillion times more

Show Answer

Answer: D) 79 octillion times more

Calculation:

import math

# IPv4: 32-bit addresses
ipv4_addresses = 2**32  # = 4,294,967,296 (~4.3 billion)

# IPv6: 128-bit addresses
ipv6_addresses = 2**128
# = 340,282,366,920,938,463,463,374,607,431,768,211,456
# = 340 undecillion (3.4 x 10^38)

# Ratio
ratio = ipv6_addresses / ipv4_addresses  # = 2**96
# = 79,228,162,514,264,337,593,543,950,336
# = 79 octillion (7.9 x 10^28)

Visualization:

IPv4: 4.3 billion addresses
  = ~0.6 addresses per person (7 billion people)
  = Exhausted in 2011

IPv6: 340 undecillion addresses
  = ~48 million trillion trillion addresses per person
  = 667 quadrillion per square millimeter of Earth's surface
  = Enough for every atom on Earth's surface to have trillions of addresses

Why IPv6 for IoT:

  1. Address exhaustion solved:
    • IPv4: 4.3 billion (exhausted)
    • IoT needs: 50+ billion devices by 2030
    • IPv6: 340 undecillion (unlimited for practical purposes)
  2. No NAT required:
    • Every IoT device gets unique global address
    • End-to-end connectivity
    • Simplified network architecture
  3. Built-in features:
    • Auto-configuration (SLAAC)
    • Built-in IPsec
    • Better multicast support
    • More efficient routing

Real-world example:

Smart City with 1 million sensors:
  IPv4: Requires NAT (complex, limits direct access)
  IPv6: Each sensor gets unique /64 subnet
        (18 quintillion addresses per sensor!)

38.6 Comprehensive Review Quiz

Scenario: A city plans to deploy 500 air quality sensors measuring PM2.5, PM10, NO2, O3, and CO every 5 minutes across 25 square kilometers. Each sensor transmits 32-byte readings (5 sensors × 4 bytes each + 12-byte header). Sensors are solar-powered with 5,000 mAh backup battery (must survive 7 days without sun). Network must support 144,000 messages/day total. Data feeds into public health dashboard and triggers pollution alerts.

Step 1 — Calculate Message Load

Per sensor:

Messages per day: 1440 minutes ÷ 5 = 288 messages
Payload size: 32 bytes (sensor data)
Daily data per sensor: 288 × 32 = 9,216 bytes = 9 KB

Network-wide:

Total messages: 500 sensors × 288 = 144,000 messages/day
Total data (payload only): 500 × 9 KB = 4.5 MB/day

Step 2 — Evaluate Protocol Candidates

Option A: LoRaWAN (SF9, 125 kHz)

Physical overhead: 13 bytes (LoRaWAN header)
Total packet: 32 + 13 = 45 bytes
Time on air (SF9): 45 bytes × 8 bits ÷ 3,125 bps = 115 ms per message

Daily airtime per sensor: 288 × 115 ms = 33.1 seconds
Network daily airtime: 500 × 33.1s = 16,550 seconds = 4.6 hours

Duty cycle check (EU868 1% limit):
Required airtime: 4.6 hours = 19.2% of day ❌ VIOLATES 1% LIMIT

Verdict: LoRaWAN fails due to duty cycle violation. At 288 msgs/day, would need ~20 gateways to stay under 1% per gateway (expensive).

Option B: NB-IoT (LTE Cat-NB1)

Physical overhead: 20 bytes (IPv6) + 8 (UDP) + 4 (CoAP) = 32 bytes
Total packet: 32 + 32 = 64 bytes
Transmission time: 64 bytes × 8 bits ÷ 62,500 bps = 8.2 ms per message

Power consumption:
- TX current: 200 mA (NB-IoT modem at 23 dBm)
- PSM sleep: 10 µA (power-saving mode)
- TX time per day: 288 × 8.2 ms = 2.36 seconds

Daily energy:
TX: 200 mA × 2.36s ÷ 3600 = 0.131 mAh
Sleep: 0.01 mA × 86,397.6s ÷ 3600 = 0.24 mAh
Total: 0.37 mAh/day

Battery life (no solar):
5000 mAh ÷ 0.37 mAh/day = 13,514 days = 37 years ✓ EXCEEDS 7-DAY BACKUP

Cost analysis:

  • Module cost: $15/sensor × 500 = $7,500
  • SIM subscription: $2/month/sensor × 500 × 12 months = $12,000/year
  • Gateway infrastructure: $0 (uses cellular towers)
  • Total 5-year cost: $7,500 + $60,000 = $67,500

Option C: Wi-Fi Mesh (802.11ah - Wi-Fi HaLow)

Physical overhead: 36 bytes (Wi-Fi) + 40 (IPv6) + 8 (UDP) + 2 (MQTT) = 86 bytes
Total packet: 32 + 86 = 118 bytes
Transmission time: 118 bytes × 8 bits ÷ 150,000 bps = 6.3 ms per message

Power consumption:
- TX power: 50 mW (Wi-Fi HaLow, lower than traditional Wi-Fi)
- Connected standby: 5 mA (Wi-Fi association + periodic beacons)
- TX time per day: 288 × 6.3 ms = 1.81 seconds

Daily energy:
TX: 50 mA × 1.81s ÷ 3600 = 0.025 mAh
Standby: 5 mA × 86,398.2s ÷ 3600 = 120 mAh/day
Total: 120.03 mAh/day

Battery life (no solar):
5000 mAh ÷ 120.03 mAh/day = 41.7 days ⚠ MARGINAL (only 6x safety margin)

Cost analysis:

  • Module cost: $25/sensor × 500 = $12,500
  • Access points: 50 APs × $300 = $15,000
  • Network controller: $5,000
  • Total 5-year cost: $12,500 + $15,000 + $5,000 = $32,500

Step 3 — Decision Matrix

Criterion LoRaWAN NB-IoT Wi-Fi HaLow Weight
Duty cycle compliance ❌ Violates ✓ N/A ✓ N/A Critical
7-day battery backup ✓ 37 years ✓ 37 years ⚠ 42 days Critical
5-year cost $35K (~20 gateways) $67.5K $32.5K Important
Coverage (25 km²) ✓ (~20 gateways) ✓ (cellular) ⚠ (50 APs) Important
Dashboard integration Gateway→MQTT Native CoAP Native MQTT Moderate
Public/private network Private Public cellular Private Moderate
Latency 1-5 seconds 1-10 seconds 50-200 ms Low priority

Step 4 — Adjusted LoRaWAN Analysis

Can we make LoRaWAN work? Try reducing message frequency:

LoRaWAN with 15-minute intervals (instead of 5-minute):

Messages per day: 1440 ÷ 15 = 96 messages/day per sensor
Network messages: 500 × 96 = 48,000 messages/day
Daily airtime: 48,000 × 115 ms = 5,520 seconds = 1.53 hours = 6.4% of day

Required gateways to stay under 1% duty cycle: 6.4 ÷ 1 = 7 gateways
Gateway cost: 7 × $1,500 = $10,500
Total 5-year cost: $7,500 (sensors) + $10,500 (gateways) + $5,000 (server) = $23,000

✓ Now complies with duty cycle AND is cheapest option.

Step 5 — Final Recommendation

Choice: LoRaWAN with 15-minute intervals + CoAP

Trade-off accepted: Reduced from 5-minute to 15-minute sampling frequency. Air quality changes slowly enough that 15-minute resolution still meets public health monitoring needs.

Rationale:

  1. Lowest 5-year cost: $23K vs $32.5K (Wi-Fi) vs $67.5K (NB-IoT)
  2. No subscriptions: One-time gateway cost, no monthly SIM fees
  3. Excellent battery life: 37-year theoretical, easily exceeds 7-day backup requirement
  4. Duty cycle compliance: 7 gateways provide redundancy and stay under 1% per gateway
  5. Private network: City owns infrastructure, no dependency on cellular carriers

Implementation:

  • 7 LoRaWAN gateways placed at 2 km spacing across city
  • Adaptive Data Rate: sensors near gateways use SF7 (faster, less power), distant sensors use SF11
  • Gateway-to-cloud: MQTT over 4G/LTE from each gateway
  • Sensor payload: Custom binary (32 bytes) with CRC, no JSON overhead

Why NOT NB-IoT despite better battery: $44K savings over 5 years (vs NB-IoT) justifies reduced sampling frequency. For budget-constrained municipal deployments, capital cost often trumps technical superiority.

Key lesson: Protocol selection isn’t always about maximizing every metric. Sometimes adjusting requirements (15-min vs 5-min) unlocks a dramatically cheaper solution that still meets core objectives. Real-world deployments balance technical, economic, and operational constraints.

Common Pitfalls

Rote-learning that “LoRaWAN is for long range” fails when the question asks about a 500-node indoor factory. Fix: practice explaining why a protocol fits a scenario, not just which protocol it is.

Mixing up “6LoWPAN is a routing protocol” (it is not; RPL is) costs marks. Fix: create a simple table mapping each protocol to its OSI layer before answering any question.

Writing a numeric answer without showing the header-size arithmetic gives no partial credit. Fix: always show the formula (overhead% = header_bytes / total_bytes × 100) before substituting values.

38.7 Summary

Key Takeaways

IoT Protocol Selection Principles:

  1. Total Overhead Matters, Not Just Headers
    • MQTT 2-byte header + TCP 20-byte = more than CoAP 4-byte + UDP 8-byte
    • Always calculate full stack overhead
  2. Use Case Drives Selection
    • Constrained + Real-time: CoAP/UDP
    • Scalable + Reliable: MQTT/TCP
    • LPWAN: Native MAC protocols (LoRaWAN)
    • Gateway-to-Cloud: HTTP/HTTPS
  3. 6LoWPAN is Essential for 802.15.4
    • Compresses IPv6 from 40 bytes to 2-6 bytes
    • Enables IPv6 on 127-byte frame limit networks
    • Not applicable for cellular (NB-IoT, LTE-M)
  4. Battery Life Calculations
    • Protocol overhead affects transmission time
    • TCP keep-alive adds ongoing power drain
    • For frequent transmission, CoAP can provide 3x+ battery life vs MQTT
  5. IPv6 Address Space
    • 79 octillion times more addresses than IPv4
    • Use /64 subnets with SLAAC
    • No NAT required for IoT scale

38.8 Concept Relationships

This knowledge assessment validates understanding of interconnected IoT protocol concepts:

Related Concepts:

  • Protocol efficiency calculations combine header overhead, transmission time, and battery consumption
  • Scenario-based reasoning requires evaluating multiple constraints (power, range, latency, reliability) simultaneously
  • Total cost of ownership includes hardware, subscriptions, and operational costs beyond technical metrics
  • Regulatory compliance (duty cycle limits) constrains protocol usage in unlicensed spectrum
  • Layer interactions show how application-layer choice (CoAP vs MQTT) affects battery life through transport layer (UDP vs TCP)

Prerequisite Knowledge:

Validates Understanding Of:

  • Protocol overhead calculation for different stacks
  • Battery life impact of protocol choice
  • 6LoWPAN applicability and compression mechanisms
  • IPv6 addressing and subnetting for large deployments
  • Protocol encapsulation order and layer functions

38.9 See Also

Assessment Resources:

Practice Tools:

Review Materials:

38.10 What’s Next

If you want to… Read this
Review protocol concepts before the assessment IoT Protocols Overview
Run hands-on labs to reinforce understanding Labs and Selection
Study real-world protocol applications Real-World Examples
Review the protocol stack architecture Protocol Stack Architecture