620  IoT Protocol Layers and Selection

620.1 Learning Objectives

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

• Map IoT protocols to OSI layers and understand their roles
• Select appropriate protocols for different IoT applications using decision trees
• Compare wireless technologies by range, power, and data rate
• Understand protocol overhead and encapsulation at each layer

620.2 Why Networking Matters for IoT

Time: ~5 min | Difficulty: Foundational | Unit: P07.C15.U01

NoteAcademic Resource: Stanford IoT Course - Complete IoT SoC Architecture

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.

620.3 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:

%%{init: {'theme': 'base', 'themeVariables': { 'primaryColor': '#2C3E50', 'primaryTextColor': '#fff', 'primaryBorderColor': '#16A085', 'lineColor': '#E67E22', 'secondaryColor': '#16A085', 'tertiaryColor': '#E8F6F3', 'clusterBkg': '#E8F6F3', 'clusterBorder': '#16A085', 'fontSize': '13px'}}}%%
graph TB
    subgraph L7["Layer 7: Application"]
        APP["MQTT, CoAP, HTTP/HTTPS<br/>AMQP, WebSocket, XMPP"]
    end

    subgraph L6["Layer 6: Presentation"]
        PRES["JSON, CBOR, Protocol Buffers<br/>Data Encoding & Encryption"]
    end

    subgraph L5["Layer 5: Session"]
        SESS["TLS/DTLS Sessions<br/>MQTT Persistent Sessions"]
    end

    subgraph L4["Layer 4: Transport"]
        TRANS["TCP (Reliable)<br/>UDP (Low Latency)"]
    end

    subgraph L3["Layer 3: Network"]
        NET["IPv4, IPv6<br/>RPL, 6LoWPAN<br/>ICMP"]
    end

    subgraph L2["Layer 2: Data Link"]
        LINK["Wi-Fi, BLE, Zigbee<br/>LoRa, NB-IoT, Ethernet"]
    end

    subgraph L1["Layer 1: Physical"]
        PHY["2.4 GHz, 5 GHz, Sub-GHz<br/>Radio Modulation & Signaling"]
    end

    APP --> PRES
    PRES --> SESS
    SESS --> TRANS
    TRANS --> NET
    NET --> LINK
    LINK --> PHY

    style L7 fill:#16A085,stroke:#2C3E50,color:#fff
    style L6 fill:#1ABC9C,stroke:#2C3E50,color:#fff
    style L5 fill:#3498DB,stroke:#2C3E50,color:#fff
    style L4 fill:#9B59B6,stroke:#2C3E50,color:#fff
    style L3 fill:#E67E22,stroke:#2C3E50,color:#fff
    style L2 fill:#E74C3C,stroke:#2C3E50,color:#fff
    style L1 fill:#95A5A6,stroke:#2C3E50,color:#fff
    style APP fill:#16A085,stroke:#2C3E50,color:#fff
    style PRES fill:#1ABC9C,stroke:#2C3E50,color:#fff
    style SESS fill:#3498DB,stroke:#2C3E50,color:#fff
    style TRANS fill:#9B59B6,stroke:#2C3E50,color:#fff
    style NET fill:#E67E22,stroke:#2C3E50,color:#fff
    style LINK fill:#E74C3C,stroke:#2C3E50,color:#fff
    style PHY fill:#95A5A6,stroke:#2C3E50,color:#fff

Figure 620.1: OSI 7-layer model with IoT protocols at each layer from application to physical

{fig-alt=“OSI model stack diagram showing seven layers from Physical (Layer 1) to Application (Layer 7) with common IoT protocols at each layer including MQTT/CoAP at application, TCP/UDP at transport, IPv4/IPv6/RPL at network, and Wi-Fi/BLE/LoRa at data link”}

TipAlternative View: IoT Data Journey Through Protocol Layers

This variant shows how sensor data actually travels through the protocol stack:

%%{init: {'theme': 'base', 'themeVariables': {'primaryColor': '#2C3E50', 'primaryTextColor': '#fff', 'primaryBorderColor': '#16A085', 'lineColor': '#16A085', 'secondaryColor': '#E67E22', 'tertiaryColor': '#7F8C8D'}}}%%
flowchart LR
    subgraph SENSOR["Sensor Side"]
        S1["temp=23.5C"]
        S2["+MQTT header<br/>14 bytes"]
        S3["+TCP header<br/>20 bytes"]
        S4["+IP header<br/>20 bytes"]
        S5["+Wi-Fi frame<br/>28 bytes"]
    end

    S1 -->|"App Layer"| S2
    S2 -->|"Transport"| S3
    S3 -->|"Network"| S4
    S4 -->|"Data Link"| S5

    subgraph CLOUD["Cloud Side"]
        C5["Receive Wi-Fi"]
        C4["Extract IP"]
        C3["Process TCP"]
        C2["Parse MQTT"]
        C1["temp=23.5C"]
    end

    S5 -->|"Physical<br/>Radio TX"| C5
    C5 --> C4
    C4 --> C3
    C3 --> C2
    C2 --> C1

    style S1 fill:#16A085,stroke:#2C3E50,color:#fff
    style C1 fill:#16A085,stroke:#2C3E50,color:#fff
    style S5 fill:#E67E22,stroke:#2C3E50,color:#fff
    style C5 fill:#E67E22,stroke:#2C3E50,color:#fff

Each layer adds headers when sending (encapsulation) and removes them when receiving (decapsulation).

{
  const container = document.getElementById('kc-net-protocols-1');
  if (container && typeof InlineKnowledgeCheck !== 'undefined') {
    container.innerHTML = '';
    container.appendChild(InlineKnowledgeCheck.create({
      question: "A smart factory needs to send temperature sensor data from an ESP32 to a cloud dashboard. The data is encoded as JSON, travels over Wi-Fi using TCP, and the ESP32 has an IPv4 address. At which OSI layer does the JSON encoding occur?",
      options: [
        {text: "Layer 1 - Physical", correct: false, feedback: "Layer 1 handles the actual transmission of bits over the physical medium (radio waves for Wi-Fi). JSON encoding happens much higher in the stack."},
        {text: "Layer 3 - Network", correct: false, feedback: "Layer 3 handles IP addressing and routing. The IPv4 address operates here, but JSON encoding is handled at a higher layer."},
        {text: "Layer 4 - Transport", correct: false, feedback: "Layer 4 (TCP) handles reliable delivery, segmentation, and flow control. JSON encoding occurs above this layer."},
        {text: "Layer 6 - Presentation", correct: true, feedback: "Correct! Layer 6 (Presentation) handles data encoding, serialization, and format conversion. JSON encoding transforms application data into a standard format that can be transmitted and understood by both sender and receiver."}
      ],
      difficulty: "medium",
      topic: "OSI Model"
    }));
  }
}

Each layer serves a specific purpose in enabling end-to-end IoT communication:

620.3.1 Application Layer (Layer 7)

Protocol	Transport	Use Case	Overhead
MQTT	TCP/UDP	General IoT messaging	Low
CoAP	UDP	Constrained devices	Very Low
HTTP/HTTPS	TCP	Web services, REST APIs	High
AMQP	TCP	Enterprise messaging	Medium
WebSocket	TCP	Real-time bidirectional	Medium

620.3.2 Network Layer (Layer 3)

Protocol	Purpose	IoT Application
IPv4	Internet routing	Legacy IoT, NAT required
IPv6	Next-gen routing	Modern IoT, 6LoWPAN
RPL	Routing for LLNs	Sensor networks
ICMP	Error reporting	Ping, traceroute

620.3.3 Data Link Layer (Layer 2)

Protocol	Range	Data Rate	Power	Use Case
Wi-Fi	50-100m	1-1300 Mbps	High	Smart home
Bluetooth LE	10-50m	1-2 Mbps	Very Low	Wearables
Zigbee	10-100m	250 Kbps	Very Low	Home automation
LoRa	2-15 km	0.3-50 Kbps	Ultra Low	Wide area sensors
Ethernet	100m	10-10000 Mbps	N/A	Wired industrial

620.4 Protocol Selection Decision Tree

Choosing the right networking protocol depends on your IoT application requirements. Use this decision tree to narrow down your options:

%%{init: {'theme': 'base', 'themeVariables': { 'primaryColor': '#2C3E50', 'primaryTextColor': '#fff', 'primaryBorderColor': '#16A085', 'lineColor': '#E67E22', 'secondaryColor': '#16A085', 'tertiaryColor': '#E8F6F3', 'clusterBkg': '#E8F6F3', 'clusterBorder': '#16A085', 'fontSize': '12px'}}}%%
graph TD
    START["IoT Device Networking<br/>Protocol Selection"]

    Q1{"Range<br/>Requirement?"}
    Q2{"Power<br/>Available?"}
    Q3{"Data<br/>Rate?"}
    Q4{"Mobility?"}
    Q5{"Coverage?"}
    Q6{"Real-time?"}

    Wi-Fi["Wi-Fi<br/>50-100m, High Power<br/>1-1300 Mbps"]
    BLE["Bluetooth LE<br/>10-50m, Low Power<br/>1-2 Mbps"]
    ZIGBEE["Zigbee<br/>10-100m, Low Power<br/>250 Kbps, Mesh"]
    LORA["LoRaWAN<br/>2-15 km, Ultra-Low Power<br/>0.3-50 Kbps"]
    NBIOT["NB-IoT<br/>1-10 km, Low Power<br/>200 Kbps, Licensed"]
    CELLULAR["Cellular LTE-M<br/>1-10 km, Medium Power<br/>1 Mbps, Mobile"]
    ETHERNET["Ethernet<br/>100m, No Power Constraint<br/>10-10000 Mbps"]

    START --> Q1
    Q1 -->|"<100m"| Q2
    Q1 -->|">1 km"| Q5

    Q2 -->|"Mains Power"| Q3
    Q2 -->|"Battery"| Q6

    Q3 -->|">10 Mbps"| Wi-Fi
    Q3 -->|"<10 Mbps"| Q4

    Q4 -->|"Stationary"| ETHERNET
    Q4 -->|"Mobile"| Wi-Fi

    Q5 -->|"Licensed Spectrum"| NBIOT
    Q5 -->|"Unlicensed"| LORA

    Q6 -->|"Yes (<1s)"| BLE
    Q6 -->|"No (>1min)"| ZIGBEE

    style START fill:#2C3E50,stroke:#16A085,color:#fff
    style Q1 fill:#E67E22,stroke:#2C3E50,color:#fff
    style Q2 fill:#E67E22,stroke:#2C3E50,color:#fff
    style Q3 fill:#E67E22,stroke:#2C3E50,color:#fff
    style Q4 fill:#E67E22,stroke:#2C3E50,color:#fff
    style Q5 fill:#E67E22,stroke:#2C3E50,color:#fff
    style Q6 fill:#E67E22,stroke:#2C3E50,color:#fff
    style Wi-Fi fill:#16A085,stroke:#2C3E50,color:#fff
    style BLE fill:#16A085,stroke:#2C3E50,color:#fff
    style ZIGBEE fill:#16A085,stroke:#2C3E50,color:#fff
    style LORA fill:#16A085,stroke:#2C3E50,color:#fff
    style NBIOT fill:#16A085,stroke:#2C3E50,color:#fff
    style CELLULAR fill:#16A085,stroke:#2C3E50,color:#fff
    style ETHERNET fill:#16A085,stroke:#2C3E50,color:#fff

Figure 620.2: IoT protocol selection decision tree based on range, power, data rate, and mobility

{fig-alt=“Decision tree flowchart for selecting IoT wireless protocols based on range requirements (under 100m or over 1km), power availability (mains or battery), data rate needs (high or low), mobility (stationary or mobile), spectrum licensing, and latency requirements, leading to recommendations for Wi-Fi, Bluetooth LE, Zigbee, LoRaWAN, NB-IoT, LTE-M, or Ethernet”}

This simplified decision tree helps narrow down protocol choices. Real-world selection also considers cost, ecosystem maturity, regulatory requirements, and existing infrastructure.

{
  const container = document.getElementById('kc-net-protocols-2');
  if (container && typeof InlineKnowledgeCheck !== 'undefined') {
    container.innerHTML = '';
    container.appendChild(InlineKnowledgeCheck.create({
      question: "A vineyard owner needs to deploy 200 soil moisture sensors across a 5 km property. Sensors must run on batteries for at least 3 years and send readings every 30 minutes. There is no existing network infrastructure. Which protocol is most appropriate?",
      options: [
        {text: "Wi-Fi - high bandwidth for reliable data delivery", correct: false, feedback: "Wi-Fi requires significant infrastructure (access points every 50-100m) and consumes 150-300 mA during transmission, making 3-year battery life impossible. It would need 50+ access points for 5km coverage."},
        {text: "Bluetooth LE - designed for low power consumption", correct: false, feedback: "BLE range is only 10-50m, requiring relay devices every few meters across 5km. While power-efficient for short range, the mesh complexity would be impractical for agricultural deployment."},
        {text: "LoRaWAN - long range, low power, infrequent data", correct: true, feedback: "Correct! LoRaWAN achieves 2-15km range with a single gateway, uses only 30mA for ~50ms transmissions, and is designed for infrequent small data packets. A single gateway can cover the entire 5km property, and sensors can achieve 5-10 year battery life with 30-minute intervals."},
        {text: "NB-IoT - cellular coverage is reliable", correct: false, feedback: "NB-IoT requires cellular infrastructure (towers) and ongoing subscription fees ($2-15/device/month). While it offers good range, LoRaWAN provides similar capabilities without recurring cellular costs in areas with no existing coverage."}
      ],
      difficulty: "medium",
      topic: "Protocol Selection"
    }));
  }
}

TipAlternative 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.

%%{init: {'theme': 'base', 'themeVariables': { 'primaryColor': '#2C3E50', 'primaryTextColor': '#fff', 'primaryBorderColor': '#16A085', 'lineColor': '#E67E22', 'secondaryColor': '#16A085', 'tertiaryColor': '#E8F6F3', 'fontSize': '11px'}}}%%
flowchart TB
    subgraph HOME["Smart Home"]
        H1["Wi-Fi - Cameras, TVs<br/>High bandwidth, mains power"]
        H2["BLE - Wearables<br/>Low power, phone pairing"]
        H3["Zigbee - Sensors<br/>Mesh network, battery"]
    end

    subgraph INDUSTRY["Industrial IoT"]
        I1["Ethernet - PLCs<br/>Deterministic, reliable"]
        I2["Wi-Fi 6 - AGVs<br/>Mobile, high throughput"]
        I3["Private 5G - Robotics<br/>Ultra-low latency"]
    end

    subgraph AGRI["Agriculture"]
        A1["LoRaWAN - Soil sensors<br/>10km range, 10yr battery"]
        A2["NB-IoT - Livestock GPS<br/>Cellular, mobile"]
        A3["Sigfox - Weather stations<br/>Ultra-simple, low cost"]
    end

    subgraph CITY["Smart City"]
        C1["LoRaWAN - Parking<br/>Long range, sparse data"]
        C2["NB-IoT - Meters<br/>Licensed, reliable"]
        C3["Wi-Fi HaLow - Street lights<br/>1km range, high capacity"]
    end

    style HOME fill:#E8F6F3,stroke:#16A085
    style INDUSTRY fill:#E8F6F3,stroke:#E67E22
    style AGRI fill:#E8F6F3,stroke:#2C3E50
    style CITY fill:#E8F6F3,stroke:#7F8C8D

Figure 620.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).

620.5 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

620.6 What’s Next

Continue to the Address Collisions chapter to learn about the Birthday Problem and how it affects IoT network design.