666 IoT Protocols: Scenarios and Interview Prep

Learning Objectives

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

Answer common technical interview questions about IoT protocols
Design protocol stacks for real-world IoT deployment scenarios
Explain MQTT QoS levels and when to use each
Walk through 6LoWPAN header compression with examples
Debug IoT connectivity issues using a layer-by-layer approach
Calculate maximum application payload for constrained networks

666.1 Prerequisites

Before diving into this chapter, you should be familiar with:

IoT Protocols: Introduction: Understanding of why IoT needs specialized protocols
IoT Protocols: Stack Architecture: Knowledge of the complete IoT protocol stack and protocol categories

666.2 Interview Prep: Common Questions on IoT Protocols

This section prepares you for technical interviews by covering frequently asked questions about IoT protocols, architectures, and design decisions.

666.2.1 Conceptual Questions

Q1: Explain the difference between MQTT and CoAP. When would you choose one over the other?

Key Points to Cover: - Architecture Pattern: MQTT uses publish-subscribe with a broker; CoAP uses request-response (RESTful) pattern - Transport Layer: MQTT runs over TCP (reliable, stateful); CoAP uses UDP (lightweight, stateless) - Overhead: MQTT has 2-byte fixed header; CoAP has 4-byte header - Use Cases: - Choose MQTT for: Continuous telemetry streams, dashboard updates, many subscribers, reliable delivery - Choose CoAP for: Battery-constrained devices, infrequent updates, direct device-to-device, request-response patterns

Example Answer: “MQTT and CoAP serve different IoT communication needs. MQTT is a publish-subscribe protocol over TCP, ideal for scenarios like smart home sensors streaming data to dashboards where multiple applications subscribe to topics. CoAP is a RESTful protocol over UDP, better for battery-powered parking sensors that report status changes infrequently—its UDP transport avoids TCP’s connection overhead, and direct request-response is simpler than broker-based pub/sub when you don’t need multiple subscribers.”

Q2: Why would you choose LoRaWAN over Wi-Fi for an IoT deployment?

Key Points to Cover: - Range vs Bandwidth Trade-off: LoRaWAN (10-15 km) vs Wi-Fi (50-100m) - Power Consumption: LoRaWAN devices last 5-10 years on battery; Wi-Fi drains batteries in weeks - Data Rate: LoRaWAN (0.3-50 kbps) vs Wi-Fi (10-1000 Mbps) - Use Cases: Agricultural sensors, smart parking, water meters (LoRaWAN) vs video surveillance, high-throughput sensors (Wi-Fi)

Example Answer: “The choice depends on application requirements. For a smart agriculture deployment monitoring soil moisture across a 100-acre farm, LoRaWAN wins: sensors send 50-byte readings hourly, battery life needs to exceed 5 years, and cellular coverage is spotty. LoRaWAN’s 15km range covers the entire farm from one gateway, and its ultra-low power consumption meets battery requirements. Conversely, for warehouse inventory management with fixed power and high data rates, Wi-Fi makes more sense despite its shorter range.”

Q3: What is 6LoWPAN and why is it essential for IEEE 802.15.4 networks?

Key Points to Cover: - Problem Statement: IPv6 header (40 bytes) doesn’t fit well in 802.15.4 frame (127 bytes max) - Solution: 6LoWPAN compresses IPv6 headers to 2-8 bytes using stateless header compression (IPHC) - Benefits: Enables IP connectivity for constrained devices, more payload space for application data - Context Compression: Uses context information (link-local addresses, known prefixes) to omit redundant header fields

Example Answer: “6LoWPAN is the adaptation layer that makes IPv6 viable on 802.15.4 radios. Without it, a 40-byte IPv6 header plus 8-byte UDP header consumes 48 of the 127-byte frame, leaving only 79 bytes for application data—unacceptable overhead. 6LoWPAN’s IPHC compression reduces the IPv6 header to as little as 2 bytes by omitting predictable fields and using link-local context. This gives Zigbee and Thread networks full IP connectivity while preserving precious frame space for sensor data.”

666.2.2 Scenario-Based Questions

Q4: Design a protocol stack for a smart parking system with 1000 sensors reporting occupancy status in real-time. Consider power, cost, and reliability.

Approach to Demonstrate:

Step 1 - Analyze Requirements:

- 1000 sensors (city-wide deployment)
- Payload: Occupancy status (1 bit) + sensor ID + timestamp = ~10 bytes
- Update frequency: On status change (event-driven) + hourly heartbeat
- Battery life: 5+ years
- Reliability: High (parking revenue depends on it)
- Range: City-wide coverage

Step 3 - Justify Choice: - Application (CoAP): Event-driven updates fit request-response better than pub/sub; 4-byte header minimal - Transport (UDP): No connection state = battery savings; CoAP adds reliability at application layer - Network (IPv6): Future-proof addressing; no NAT complexity - Link (NB-IoT): Cellular coverage city-wide; power-saving modes (PSM, eDRX); better reliability than LoRaWAN for revenue-critical application

Example Answer: “I’d use CoAP over UDP with IPv6 on NB-IoT. NB-IoT provides city-wide cellular coverage with PSM power-saving modes for 5+ year battery life. CoAP’s request-response pattern is simpler than MQTT for ‘sensor reports status, server acknowledges’ workflows. UDP avoids TCP’s connection overhead. IPv6 with NB-IoT’s built-in IP support (no 6LoWPAN needed) gives each sensor a unique address. The stack’s total overhead is ~50 bytes (NB-IoT headers + IPv6 + UDP + CoAP), leaving plenty of bandwidth for the 10-byte payload on NB-IoT’s ~20 kbps uplink.”

Q5: Your smart home system uses Zigbee for sensors but needs to integrate with a cloud dashboard. Design the network architecture.

Approach to Demonstrate:

Design Decisions: 1. Sensor to Hub (Zigbee): Low power mesh network, 802.15.4 radio, 6LoWPAN for IPv6 2. Hub to Cloud (MQTT over Wi-Fi): Gateway translates Zigbee to MQTT, Wi-Fi has bandwidth for multiple sensors 3. Protocol Bridge: Hub acts as protocol translator (Zigbee Application Layer to MQTT topics) 4. Security: Zigbee link keys + TLS for MQTT connection 5. Topic Structure: home/room/device/sensor (e.g., home/livingroom/temp/reading)

Example Answer: “The gateway hub is the critical component. It runs a Zigbee coordinator to form the mesh network where sensors communicate using 802.15.4/6LoWPAN. The hub translates Zigbee application data into MQTT messages—for example, a temperature sensor’s Zigbee packet becomes an MQTT PUBLISH to topic ‘home/livingroom/temp’. The hub connects to the cloud MQTT broker over Wi-Fi with TLS encryption. This architecture leverages Zigbee’s strengths (low power, mesh, short-range) locally while using Wi-Fi/MQTT (higher bandwidth, internet connectivity) for cloud integration.”

666.2.3 Technical Deep-Dives

Q6: Walk me through MQTT QoS levels. When would you use each?

QoS 0 - At Most Once (Fire and Forget):

Client -> PUBLISH -> Broker -> PUBLISH -> Subscriber
         (no ACK)              (no ACK)

Use When:
- Data loss acceptable (temperature readings every second)
- Lowest latency critical
- Minimal bandwidth/power consumption needed
Example: Weather station sending updates every 10 seconds

QoS 1 - At Least Once (Acknowledged Delivery):

Client -> PUBLISH -> Broker -> PUBACK -> Client
                   |
         PUBLISH -> Subscriber -> PUBACK -> Broker

Use When:
- Data loss unacceptable but duplicates OK
- Balance reliability vs overhead
Example: Security alarm sensor reporting intrusion

QoS 2 - Exactly Once (Four-way Handshake):

Client -> PUBLISH -> Broker -> PUBREC -> Client
Client -> PUBREL -> Broker -> PUBCOMP -> Client
                   |
         PUBLISH -> Subscriber -> [same 4-way handshake]

Use When:
- Critical data, no loss or duplication tolerated
- Billing, financial transactions, control commands
Example: Medical device dosage control

Trade-off Analysis: | QoS | Messages | Bandwidth | Latency | Battery | Use Case | |—–|———-|———–|———|———|———-| | 0 | 1 | Lowest | 10ms | Best | Telemetry streams | | 1 | 2-4 | Medium | 50ms | Good | Alerts, events | | 2 | 6-8 | Highest | 200ms | Worst | Financial, control |

Example Answer: “QoS selection depends on application tolerance for loss and duplicates. For a factory temperature sensor sending readings every second, QoS 0 is ideal—missing one reading out of thousands is acceptable, and the overhead of acknowledgments wastes bandwidth. For a fire alarm system, QoS 1 ensures the alarm reaches the monitoring station—a duplicate alarm is harmless, but missing one is catastrophic. For a chemical plant valve control system, QoS 2 guarantees exactly-once delivery—duplicate ‘close valve’ commands could cause equipment damage, and missed commands risk safety incidents.”

Q7: Explain how 6LoWPAN header compression works. Walk through a compression example.

Uncompressed IPv6 Packet (127-byte 802.15.4 frame):

%%{init: {'theme': 'base', 'themeVariables': {'primaryColor': '#2C3E50', 'primaryTextColor': '#fff', 'primaryBorderColor': '#16A085', 'lineColor': '#16A085', 'secondaryColor': '#E67E22', 'tertiaryColor': '#7F8C8D'}}}%%
flowchart TD
    subgraph FRAME["802.15.4 Frame (127 bytes max)"]
        A["802.15.4 Header<br/>(25 bytes)"]
        B["IPv6 Header (40 bytes)<br/>TOO BIG!<br/>Version, Traffic Class, Flow Label<br/>Payload Length, Next Header, Hop Limit<br/>Source Address (16 bytes)<br/>Dest Address (16 bytes)"]
        C["UDP Header<br/>(8 bytes)"]
        D["Payload<br/>(54 bytes left)<br/>Not enough!"]
    end
    A --> B --> C --> D

    style A fill:#7F8C8D,stroke:#2C3E50,color:#fff
    style B fill:#E67E22,stroke:#2C3E50,color:#fff
    style C fill:#16A085,stroke:#2C3E50,color:#fff
    style D fill:#2C3E50,stroke:#16A085,color:#fff

Figure 666.2

6LoWPAN IPHC Compressed Packet:

%%{init: {'theme': 'base', 'themeVariables': {'primaryColor': '#2C3E50', 'primaryTextColor': '#fff', 'primaryBorderColor': '#16A085', 'lineColor': '#16A085', 'secondaryColor': '#E67E22', 'tertiaryColor': '#7F8C8D'}}}%%
flowchart TD
    subgraph FRAME["802.15.4 Frame (127 bytes max)"]
        A["802.15.4 Header<br/>(25 bytes)"]
        B["6LoWPAN IPHC Header (2-7 bytes)<br/>Dispatch (2 bits: 01)<br/>IPHC encoding (13 bits)<br/>Inline fields only (2-5 bytes)"]
        C["UDP Header Compressed<br/>(4 bytes)<br/>Port compression (4 bits each)"]
        D["Payload<br/>(91-96 bytes)<br/>70% more space!"]
    end
    A --> B --> C --> D

    style A fill:#7F8C8D,stroke:#2C3E50,color:#fff
    style B fill:#16A085,stroke:#2C3E50,color:#fff
    style C fill:#16A085,stroke:#2C3E50,color:#fff
    style D fill:#2C3E50,stroke:#16A085,color:#fff

Figure 666.3

Compression Techniques: 1. Context-based compression: Link-local addresses derived from MAC addresses (omit 14 of 16 bytes) 2. Well-known values: Version (always 6), Traffic Class (usually 0) = 0 bits 3. Next Header compression: UDP = common, single bit instead of 8 4. Hop Limit: Fixed values (1, 64, 255) = 2 bits instead of 8 5. Address elision: Both addresses link-local = 2 bytes total instead of 32

Example Answer: “6LoWPAN’s IPHC looks at an IPv6 packet and asks: what can we omit or compress? For link-local addresses like fe80::0200:5aff:fe00:1234, the first 64 bits (fe80::/64 prefix) are predictable—omitted. The bottom 64 bits derive from the 802.15.4 MAC address already in the frame—also omitted. Result: 16-byte address becomes 0 bytes in IPHC header. Similar compression applies to well-known fields (version, traffic class), common values (UDP next header), and fixed hop limits. A 40-byte IPv6 header compresses to 2-7 bytes, freeing 33-38 bytes for payload—critical for 127-byte 802.15.4 frames.”

Q8: You’re debugging an IoT system where sensors can’t reach the cloud. Walk through your troubleshooting approach layer by layer.

Systematic Debugging Approach:

Layer 1 - Physical/Link Layer:

# Check sensor radio is working
$ iwconfig  # Check radio interface
$ iw dev wlan0 scan  # Scan for networks
$ ping -I wlan0 192.168.1.1  # Test link-local connectivity

Questions to Ask:
- Is the radio powered on? (LED indicators, battery voltage)
- Is the antenna connected? (RSSI readings)
- Are we in range of the gateway? (check distance, obstacles)
- Channel interference? (spectrum analyzer, channel scan)

Layer 2 - Network/6LoWPAN Layer:

# Check IPv6 addressing and routing
$ ip -6 addr show  # Verify IPv6 address assigned
$ ip -6 route show  # Check routing table
$ ping6 fe80::1%wpan0  # Ping gateway link-local

Questions to Ask:
- Does the device have an IPv6 address? (DHCPv6, SLAAC)
- Is 6LoWPAN header compression working? (packet capture)
- Can we reach the 6LoWPAN border router? (ping6 test)
- Fragmentation issues? (packet too large for MTU)

Layer 3 - Transport Layer:

# Check UDP/TCP connectivity
$ nc -u 2001:db8::1 5683  # Test UDP to CoAP server
$ ss -u  # Show UDP sockets
$ tcpdump -i wpan0 -vvv udp  # Capture UDP traffic

Questions to Ask:
- Are UDP ports open? (firewall rules)
- Packet loss rate? (ICMP statistics, retransmission counters)
- NAT64 gateway working? (if translating IPv6 to IPv4)

Layer 4 - Application Layer:

# Check CoAP/MQTT connectivity
$ coap-client -m get coap://[2001:db8::1]/temp
$ mosquitto_pub -h broker.mqtt.com -t "test" -m "hello"

Questions to Ask:
- Is the CoAP/MQTT server reachable? (endpoint URL correct)
- Authentication working? (credentials, TLS certificates)
- Protocol version mismatch? (MQTT 3.1 vs 5.0)
- Application-level errors? (check server logs)

Example Debugging Session:

Problem: Zigbee temperature sensor not sending to cloud

1. Physical Check:
   - Sensor LED blinking -> radio active
   - RSSI -75 dBm -> adequate signal

2. Network Check:
   - `ip -6 addr` -> no IPv6 address!
   - Root Cause: Gateway DHCPv6 server down

3. Fix: Restart gateway DHCPv6 daemon
   - `systemctl restart radvd`
   - Sensor gets address: fe80::0200:5aff:fe00:1234

4. Verify:
   - `ping6 fe80::1%wpan0` -> 0% loss
   - `coap-client -m get coap://[fe80::1]/sensor` -> 200 OK
   - Data flowing to cloud

Example Answer: “I use bottom-up troubleshooting. First, verify Layer 1/2—is the radio on, are we in range, do we have an IPv6 address? Tools: iwconfig, ip addr, ping6. Second, check Layer 3—is UDP traffic flowing? tcpdump on the gateway shows if packets arrive. Third, Layer 4—does the application protocol handshake work? For MQTT, try mosquitto_pub directly; for CoAP, use coap-client. This approach isolated a recent issue where sensors had connectivity but MQTT CONNECT was timing out—turned out the broker’s certificate expired, and TLS handshake failed silently at the application layer.”

666.2.4 System Design Questions

Q9: Design a battery-powered environmental monitoring network for a 500-acre farm. Sensors measure soil moisture, temperature, and rainfall.

Requirements Analysis:

Scope: 500 acres (2 km x 1 km)
Sensors: 100 nodes (soil moisture + temp every 5 acres)
Data: 20 bytes/reading, 1 reading/hour
Battery Life: 5 years minimum
Environment: Outdoor, no power, unreliable cellular

Architecture Design:

Technology Stack:

Layer	Technology	Justification
Application	Custom payload (20 bytes)	Minimal overhead for battery life
Network	LoRaWAN (Class A)	Long-range (2+ km), ultra-low power, license-free
Physical	LoRa modulation (SF7-SF12)	Adaptive data rate for range vs power trade-off
Gateway	Single LoRaWAN gateway, solar-powered	Covers 2 km radius, 4G backhaul to cloud
Cloud	MQTT to InfluxDB to Grafana	Standard time-series stack for ag monitoring

Battery Life Calculation:

Power Budget per Node:
- Sleep mode: 5 uA x 23.9 hours/day = 119.5 uAh
- Sensing (1/hour): 10 mA x 5 sec x 24 = 333 uAh
- LoRa TX (1/hour, SF9): 100 mA x 2 sec x 24 = 1,333 uAh
- Daily total: 1,785 uAh = 1.79 mAh/day

Battery capacity: 2x AA lithium (3.6V, 3000 mAh) = 6000 mAh
Lifetime: 6000 mAh / 1.79 mAh/day = 3,352 days = 9.2 years

Key Design Decisions: 1. LoRaWAN over NB-IoT: No cellular coverage; LoRaWAN’s 2+ km range covers farm from one gateway 2. Class A not Class C: Downlink rarely needed; Class A’s RX-only-after-TX saves power 3. Adaptive Data Rate: SF7 near gateway (faster, less power), SF12 at edges (longer range) 4. Gateway Placement: Central location with solar panel, 4G modem for cloud backhaul 5. Data Format: Custom 20-byte payload (no JSON overhead): [sensor_id:4][moisture:2][temp:2][battery:2][timestamp:4][crc:2]

Example Answer: “LoRaWAN is ideal for this scenario. One solar-powered gateway covers the entire 500 acres with 2 km range. Sensors use LoRa’s adaptive data rate—nodes near the gateway transmit at SF7 (faster, 5.5 kbps, lower power), while distant nodes use SF12 (slower, 250 bps, better range). Class A operation minimizes power—sensors sleep 59 minutes, wake, measure soil moisture/temperature (5 seconds), transmit via LoRa (2 seconds at ~100 mA), then sleep again. With 6000 mAh lithium batteries, this yields 9+ years of operation. The gateway forwards data via 4G/MQTT to a cloud InfluxDB instance where farmers visualize trends in Grafana.”

666.2.5 Coding/Analysis Questions

Q10: Calculate the maximum application payload for a Zigbee (802.15.4) packet using 6LoWPAN compression. Show your work.

Given: - 802.15.4 MAC frame: 127 bytes max - Addresses: 16-bit short addresses (4 bytes total in frame) - Security: AES-CCM-128 (21 bytes overhead)

Calculation:

%%{init: {'theme': 'base', 'themeVariables': {'primaryColor': '#2C3E50', 'primaryTextColor': '#fff', 'primaryBorderColor': '#16A085', 'lineColor': '#16A085', 'secondaryColor': '#E67E22', 'tertiaryColor': '#7F8C8D'}}}%%
flowchart TD
    subgraph FRAME["802.15.4 Frame Structure (127 bytes max)"]
        subgraph MAC["802.15.4 Header (14 bytes)"]
            M1["Frame Control: 2 bytes"]
            M2["Sequence Number: 1 byte"]
            M3["Dest PAN ID: 2 bytes"]
            M4["Dest Address: 2 bytes (short)"]
            M5["Source Address: 2 bytes (short)"]
            M6["Security Header: 5 bytes (AES-CCM)"]
        end
        subgraph NET["6LoWPAN IPHC Header (2 bytes best case)"]
            N1["Dispatch + IPHC encoding"]
            N2["Link-local addresses: 0 bytes inline"]
            N3["Traffic Class/Flow: 0 bytes (defaults)"]
        end
        subgraph TRANS["UDP Header Compressed (4 bytes)"]
            T1["6LoWPAN NHC compression"]
            T2["Ports in 0xF0B0-0xF0BF range"]
        end
        subgraph SEC["Security & Check (18 bytes)"]
            S1["AES-CCM MIC: 16 bytes"]
            S2["FCS: 2 bytes"]
        end
        PAYLOAD["Available Payload: 89 bytes"]
    end

    MAC --> NET --> TRANS --> SEC --> PAYLOAD

    style M1 fill:#7F8C8D,stroke:#2C3E50,color:#fff
    style M2 fill:#7F8C8D,stroke:#2C3E50,color:#fff
    style M3 fill:#7F8C8D,stroke:#2C3E50,color:#fff
    style M4 fill:#7F8C8D,stroke:#2C3E50,color:#fff
    style M5 fill:#7F8C8D,stroke:#2C3E50,color:#fff
    style M6 fill:#7F8C8D,stroke:#2C3E50,color:#fff
    style N1 fill:#16A085,stroke:#2C3E50,color:#fff
    style N2 fill:#16A085,stroke:#2C3E50,color:#fff
    style N3 fill:#16A085,stroke:#2C3E50,color:#fff
    style T1 fill:#16A085,stroke:#2C3E50,color:#fff
    style T2 fill:#16A085,stroke:#2C3E50,color:#fff
    style S1 fill:#E67E22,stroke:#2C3E50,color:#fff
    style S2 fill:#E67E22,stroke:#2C3E50,color:#fff
    style PAYLOAD fill:#2C3E50,stroke:#16A085,color:#fff

Figure 666.5

Maximum Application Payload: 89 bytes (Total Overhead: 38 bytes)

Worst Case (No Compression):

If 6LoWPAN compression fails (non-compressible addresses):
- 802.15.4 Header: 14 bytes
- Full IPv6 Header: 40 bytes (no compression)
- Full UDP Header: 8 bytes
- AES-CCM MIC: 16 bytes
- FCS: 2 bytes
Total Overhead: 80 bytes
Available Payload: 47 bytes (47% reduction!)

Example Answer: “With optimal 6LoWPAN compression and 802.15.4 security enabled, the maximum payload is 89 bytes. Here’s the breakdown: 14 bytes for the 802.15.4 header with short addresses and security, 2 bytes for the compressed 6LoWPAN IPHC header (link-local addresses omitted), 4 bytes for compressed UDP header (port range 0xF0B0-0xF0BF allows 4-bit encoding), 16 bytes for the AES-CCM authentication tag, and 2 bytes for the frame check sequence. That’s 38 bytes of overhead, leaving 89 bytes for your CoAP or application data. This shows why header compression is critical—without 6LoWPAN, the uncompressed IPv6 header alone consumes 40 bytes, reducing payload to just 47 bytes.”

666.3 Summary

This chapter covered practical scenarios and interview preparation for IoT protocols:

MQTT vs CoAP selection depends on communication pattern (pub/sub vs request-response), transport requirements (TCP vs UDP), and device constraints
Protocol stack design requires analyzing requirements (power, range, reliability, cost) and matching protocols at each layer
MQTT QoS levels offer trade-offs: QoS 0 for high-frequency telemetry, QoS 1 for alerts, QoS 2 for critical control
6LoWPAN compression is essential for 802.15.4 networks, reducing 40-byte IPv6 headers to 2-7 bytes
Layer-by-layer debugging systematically isolates IoT connectivity issues from physical radio to application protocol
System design for IoT requires calculating power budgets, choosing appropriate protocols for each layer, and optimizing for deployment constraints

666.4 What’s Next

Having mastered protocol fundamentals, stack architecture, and real-world scenarios, continue to:

IoT Protocols: Labs and Selection: Hands-on protocol implementation, Python tools, and selection frameworks
IoT Protocols Review: Comprehensive protocol comparison and assessment

Related Chapters

Deep Dives: - IoT Protocols Labs and Selection - Hands-on protocol implementation and selection frameworks - IoT Protocols Review - Comprehensive protocol comparison and assessment

Application Protocols: - MQTT Fundamentals - Lightweight pub/sub messaging for IoT - CoAP Fundamentals and Architecture - RESTful protocol for constrained devices - Application Protocols - HTTP, MQTT, CoAP, AMQP comparison

Network Layer: - 6LoWPAN Fundamentals and Architecture - IPv6 header compression for 802.15.4 - IPv6 for IoT - IPv6 addressing and deployment

Foundational Concepts: - Layered Models Fundamentals - OSI and TCP/IP model foundations - Networking Basics - Core networking principles

Learning: - Simulations Hub - Interactive protocol demonstrations - Videos Hub - Protocol stack video tutorials