82  Protocol Selection: Systematic Framework

82.1 Learning Objectives

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

  • Apply Systematic Selection: Use a structured three-step framework to choose appropriate IoT protocols
  • Define Requirements: Create a comprehensive requirements matrix for your IoT project
  • Eliminate Non-Viable Options: Use decision trees to quickly narrow down protocol candidates
  • Compare Finalists: Evaluate remaining protocols using weighted criteria

This Chapter Series: - Protocol Selection Framework - Overview and index - The Challenge - Understanding trade-offs - Anti-Patterns and Tradeoffs - Common mistakes - Selection Scenarios - Real-world examples

Networking Protocols: - LPWAN Fundamentals - Low-power wide-area - LoRaWAN Overview - LoRa selection criteria - LPWAN Comparison - Technology trade-offs - Bluetooth Overview - BLE selection - Zigbee - Mesh networking

82.2 Step 1: Define Application Requirements

Create a requirements matrix:

Requirement Constraint Rationale
Range Indoor 30m OR Outdoor 5km Deployment area
Update Interval Every 5 min, 15 min, 1 hour Data freshness needs
Payload Size 10 bytes, 100 bytes, 1 KB Sensor data volume
Battery Life 3 months, 1 year, 5 years Maintenance budget
Device Count 10, 100, 10,000 Scalability needs
Budget $10/device, $50/device Cost constraints
Latency <100ms, <1s, >1min acceptable Real-time requirements

82.3 Step 2: Eliminate Non-Viable Protocols

Use this systematic decision tree to narrow down protocol options:

Flowchart decision tree starting with Range Requirement branching into four paths (Indoor <100m, Campus 100m-1km, Urban 1-10km, Rural >10km). Each path flows through Battery Constraint decisions (Mains/1-2 Years/5+ Years), then Data Rate Needs (>1 Mbps/10-500 kbps/<10 kbps), culminating in protocol recommendations (Wi-Fi, BLE, Zigbee, LoRa, LoRaWAN, NB-IoT, Sigfox). Final step checks Existing Infrastructure (Yes/No) to determine reuse vs build cost.

Flowchart decision tree starting with Range Requirement branching into four paths (Indoor <100m, Campus 100m-1km, Urban 1-10km, Rural >10km). Each path flows through Battery Constraint decisions (Mains/1-2 Years/5+ Years), then Data Rate Needs (>1 Mbps/10-500 kbps/<10 kbps), culminating in protocol recommendations (Wi-Fi, BLE, Zigbee, LoRa, LoRaWAN, NB-IoT, Sigfox). Final step checks Existing Infrastructure (Yes/No) to determine reuse vs build cost.
Figure 82.1: Four-question decision tree for protocol elimination: (1) Range determines indoor/campus/urban/rural categories, (2) Battery constraint filters by power consumption, (3) Data rate narrows to specific protocols, (4) Infrastructure preference finalizes selection between owned gateways vs carrier networks. 

%%{init: {'theme': 'base', 'themeVariables': {'primaryColor': '#2C3E50', 'primaryTextColor': '#fff', 'primaryBorderColor': '#16A085', 'lineColor': '#16A085', 'secondaryColor': '#E67E22', 'tertiaryColor': '#7F8C8D'}}}%%
graph LR
    subgraph MAIL["Postal Service Analogy"]
        direction TB
        M1["How far?"]
        M2["How heavy?"]
        M3["How fast?"]
        M4["Who delivers?"]
    end

    subgraph IOT["IoT Protocol Selection"]
        direction TB
        I1["Range needed?"]
        I2["Battery life?"]
        I3["Data rate?"]
        I4["Infrastructure?"]
    end

    subgraph EXAMPLES["Matching Examples"]
        direction TB
        E1["Local letter β†’ BLE<br/>Same neighborhood"]
        E2["Express parcel β†’ Wi-Fi<br/>Fast but expensive"]
        E3["Overseas economy β†’ LoRa<br/>Slow but cheap, long distance"]
        E4["Priority mail β†’ NB-IoT<br/>Reliable, tracked"]
    end

    M1 -.-> I1
    M2 -.-> I2
    M3 -.-> I3
    M4 -.-> I4

    I1 --> E1
    I2 --> E2
    I3 --> E3
    I4 --> E4

    style MAIL fill:#E67E22,stroke:#2C3E50,stroke-width:2px,color:#fff
    style IOT fill:#16A085,stroke:#2C3E50,stroke-width:2px,color:#fff
    style EXAMPLES fill:#2C3E50,stroke:#16A085,stroke-width:2px,color:#fff
    style M1 fill:#fff,stroke:#E67E22,stroke-width:1px,color:#2C3E50
    style M2 fill:#fff,stroke:#E67E22,stroke-width:1px,color:#2C3E50
    style M3 fill:#fff,stroke:#E67E22,stroke-width:1px,color:#2C3E50
    style M4 fill:#fff,stroke:#E67E22,stroke-width:1px,color:#2C3E50
    style I1 fill:#fff,stroke:#16A085,stroke-width:1px,color:#2C3E50
    style I2 fill:#fff,stroke:#16A085,stroke-width:1px,color:#2C3E50
    style I3 fill:#fff,stroke:#16A085,stroke-width:1px,color:#2C3E50
    style I4 fill:#fff,stroke:#16A085,stroke-width:1px,color:#2C3E50
    style E1 fill:#fff,stroke:#2C3E50,stroke-width:1px,color:#2C3E50
    style E2 fill:#fff,stroke:#2C3E50,stroke-width:1px,color:#2C3E50
    style E3 fill:#fff,stroke:#2C3E50,stroke-width:1px,color:#2C3E50
    style E4 fill:#fff,stroke:#2C3E50,stroke-width:1px,color:#2C3E50

Figure 82.2: Alternative view: Postal Service Analogy - Protocol selection mirrors choosing a delivery service. Just as you ask β€œHow far? How heavy? How fast? Who delivers?” when mailing a package, IoT engineers ask β€œRange? Battery? Data rate? Infrastructure?” Local hand delivery (BLE) works for nearby recipients. Express shipping (Wi-Fi) is fast but power-hungry. Economy international (LoRaWAN) is slow but reaches far at low cost. Priority mail (NB-IoT) uses existing postal networks with reliability guarantees. This analogy helps beginners map familiar concepts to technical decisions. {fig-alt=β€œThree-column analogy diagram connecting postal service concepts to IoT protocol selection. Left column (orange, Postal Service): How far, How heavy, How fast, Who delivers. Middle column (teal, IoT Selection): Range needed, Battery life, Data rate, Infrastructure. Right column (navy, Examples): Local letter maps to BLE for same neighborhood, Express parcel maps to Wi-Fi for fast but expensive, Overseas economy maps to LoRa for slow but cheap long distance, Priority mail maps to NB-IoT for reliable tracked delivery. Dotted lines show concept mappings.”}

Decision Tree Logic:

Question 1: What’s the required range? - <100m indoors: Wi-Fi, BLE, Zigbee, Thread - 100m-1km: LoRa (private gateway), Wi-Fi (mesh) - >1km: LoRaWAN, NB-IoT, Sigfox, cellular

Question 2: What’s the power budget? - Mains powered: Any protocol works - Battery, 1-2 years: BLE, Zigbee, Thread, LoRa - Battery, 5+ years: LoRaWAN, NB-IoT, Sigfox

Question 3: What’s the data rate? - >1 Mbps (video/audio): Wi-Fi, LTE - 10-500 kbps (frequent sensor data): BLE, NB-IoT, Wi-Fi - <10 kbps (periodic sensor data): LoRa, Sigfox, NB-IoT

Question 4: Infrastructure preference? - No infrastructure (peer-to-peer): BLE, Zigbee - Local gateway: LoRa (private), Wi-Fi - Carrier network (no gateway): NB-IoT, Sigfox, LTE-M

NoteReal-World Example: Smart Agriculture Protocol Selection

Let’s walk through a complete decision process for vineyard monitoring.

Initial Requirements: - Coverage Area: 50 hectares (500,000 mΒ²) hilly terrain with elevation changes up to 100m - Node Count: 200 soil moisture/temperature sensors distributed across vineyard blocks - Power Source: Solar panel (5W) + battery, target 5-year maintenance-free operation - Data Volume: 4 readings per hour, 20 bytes each (moisture %, temperature, battery voltage) - Latency Tolerance: Data freshness within 1 hour is acceptable - Budget: €50 per sensor node, total infrastructure budget €5,000 - Environment: Outdoor, weather-exposed, temperature -10Β°C to +45Β°C

Step 1: Elimination by Range

Question: Can protocol reach 50 hectares from central point?

  • Wi-Fi ❌ (Outdoor range ~100m, would need 20+ access points = €3,000+)
  • Bluetooth ❌ (Range 10-50m, would need 100+ gateways, not feasible)
  • Zigbee ❌ (Mesh helps but 100m hop limit Γ— terrain = poor reliability)
  • NB-IoT βœ… (1-10km range covers entire farm from single cell tower)
  • LoRaWAN βœ… (2-15km range, 1-2 gateways cover 50 hectares even with hills)
  • Sigfox βœ… (3-50km range, excellent coverage but check network availability)

Remaining candidates: NB-IoT, LoRaWAN, Sigfox

Step 2: Elimination by Battery Life

Calculate yearly energy consumption for 4 readings/hour:

NB-IoT calculation: - Active transmit: 200mW Γ— 5 seconds = 1,000 mWs = 0.28 mWh per message - Messages per year: 4/hour Γ— 24 Γ— 365 = 35,040 messages - Yearly consumption: 35,040 Γ— 0.28 mWh = 9,811 mWh = 9.8 Wh/year - 5-year total: 49 Wh - Battery required: ~10,000 mAh at 3.7V = 37 Wh (insufficient, needs solar top-up)

LoRaWAN calculation: - Active transmit: 20mW Γ— 2 seconds = 40 mWs = 0.011 mWh per message - Messages per year: 35,040 (same frequency) - Yearly consumption: 35,040 Γ— 0.011 mWh = 385 mWh = 0.385 Wh/year - 5-year total: 1.9 Wh - Battery required: 2,000 mAh at 3.7V = 7.4 Wh (comfortable 5+ year life with solar backup)

Sigfox calculation: - Active transmit: 10mW Γ— 2 seconds = 20 mWs = 0.006 mWh per message - Message limit: 140 messages/day max = 51,100/year - Our need: 35,040/year (within limits) - Yearly consumption: 35,040 Γ— 0.006 mWh = 210 mWh = 0.21 Wh/year - 5-year total: 1.05 Wh (excellent battery life)

Battery verdict: - NB-IoT ⚠️ (Marginal, needs larger battery or more solar capacity) - LoRaWAN βœ… (Excellent 5+ year life) - Sigfox βœ… (Best battery life)

Remaining candidates: LoRaWAN, Sigfox (NB-IoT possible but power-constrained)

Step 3: Cost Analysis (5-year TCO)

LoRaWAN costs: - Infrastructure: 2 gateways Γ— €1,250 = €2,500 (one-time) - Gateway installation: €500 (mast, power, weatherproofing) - Network server: Self-hosted open source (ChirpStack) = €0 ongoing - 5-year total: €3,000 (€15 per sensor over 5 years)

Sigfox costs: - Infrastructure: €0 (uses existing Sigfox network) - Subscription: €1.50 per device per year Γ— 200 devices Γ— 5 years = €1,500 - Activation: €10 per device Γ— 200 = €2,000 (one-time) - 5-year total: €3,500 (€17.50 per sensor over 5 years)

NB-IoT costs (if pursued): - Infrastructure: €0 (uses cellular network) - Subscription: €3 per device per year Γ— 200 devices Γ— 5 years = €3,000 - Activation: €5 per device Γ— 200 = €1,000 - 5-year total: €4,000 (€20 per sensor over 5 years)

Step 4: Feature Comparison

Feature LoRaWAN Sigfox NB-IoT
Bidirectional Yes (8 downlinks/day) Limited (4/day) Yes (unlimited)
Message size 51-242 bytes 12 bytes 1,600 bytes
Our need 20 bytes βœ… 20 bytes ⚠️ (needs optimization) 20 bytes βœ…
Firmware updates Possible (slow) No Yes
Network ownership You own it Vendor dependency Carrier dependency
Coverage guarantee Self-controlled Check Sigfox map Check carrier
Duty cycle limits 1% (enough for 4/hr) 140 msgs/day (enough) Unlimited

Final Decision: LoRaWAN βœ…

Justification: 1. Cost: Lowest 5-year TCO (€15/sensor vs €17.50 Sigfox vs €20 NB-IoT) 2. Battery: Excellent 5+ year life with modest solar backup 3. Range: 1-2 gateways cover 50 hectares with terrain 4. Flexibility: Owns infrastructure, no vendor lock-in 5. Message size: 20 bytes fits easily in 51-byte minimum 6. Bidirectional: Allows remote configuration and firmware updates 7. Scalability: Can add sensors without per-device fees

Implementation: - Gateway 1: Placed at highest point (vineyard hilltop), 10 dBi antenna - Gateway 2: Redundancy gateway at winery building, 5 dBi antenna - Sensor nodes: LoRa modules (SX1276), solar 5W + 2,500 mAh LiPo battery - Network server: ChirpStack on Raspberry Pi at winery - Data flow: Sensors β†’ Gateways β†’ ChirpStack β†’ MQTT β†’ Farm management system

Key Success Factors: - Site survey confirmed coverage before full deployment - Testing showed 7+ year battery life in practice (better than calculated) - Zero ongoing costs after infrastructure investment - Farmer owns and controls the entire system

82.4 Step 3: Compare Finalists

Example Comparison: Smart Parking Sensor

Protocol Range Power Data Rate Infra Cost Verdict
Wi-Fi ❌ Too short ❌ Too high βœ… Plenty ❌ Gateway per 20 spots NO
BLE ❌ Too short βœ… Low βœ… Adequate ❌ Gateway needed NO
LoRaWAN βœ… 2km+ βœ… 10-year battery βœ… 5 kbps enough βœ… 1 gateway/city block YES
NB-IoT βœ… 10km+ βœ… 5-year battery βœ… 200 kbps ⚠️ $2/device/year Maybe (cost)

Winner: LoRaWAN for cost and battery life

82.5 Visual Protocol Comparison

For typical IoT scenarios, here’s how major protocols compare across key dimensions:

Four-quadrant diagram organizing IoT protocols by range and power characteristics. LPWAN quadrant (navy) contains LoRaWAN (2-15km, 20mW, 0.3-50 kbps), NB-IoT (1-10km, 50-200mW, 200 kbps), and Sigfox (3-50km, 10mW, 100 bps). Mesh quadrant (teal) contains BLE (10-50m, 10-50mW, 1 Mbps), Zigbee (10-100m, 30mW, 250 kbps), and Thread (10-100m, 30mW, 250 kbps). Wi-Fi quadrant (orange) contains Wi-Fi (50-100m, 100-500mW, 1-100 Mbps). Cellular quadrant (gray) contains LTE-M (1-10km, 100-500mW, 1 Mbps).

Four-quadrant diagram organizing IoT protocols by range and power characteristics. LPWAN quadrant (navy) contains LoRaWAN (2-15km, 20mW, 0.3-50 kbps), NB-IoT (1-10km, 50-200mW, 200 kbps), and Sigfox (3-50km, 10mW, 100 bps). Mesh quadrant (teal) contains BLE (10-50m, 10-50mW, 1 Mbps), Zigbee (10-100m, 30mW, 250 kbps), and Thread (10-100m, 30mW, 250 kbps). Wi-Fi quadrant (orange) contains Wi-Fi (50-100m, 100-500mW, 1-100 Mbps). Cellular quadrant (gray) contains LTE-M (1-10km, 100-500mW, 1 Mbps).
Figure 82.3: Protocol categorization by range and power characteristics: LPWAN (long-range, low-power) for sparse deployments, Mesh (short-range, low-power) for dense indoor networks, Wi-Fi (short-range, high-power) for high-bandwidth applications, Cellular (long-range, high-power) for mobile/critical applications. Each protocol shows range, power consumption, and data rate specifications. 

%%{init: {'theme': 'base', 'themeVariables': {'primaryColor': '#2C3E50', 'primaryTextColor': '#fff', 'primaryBorderColor': '#16A085', 'lineColor': '#16A085', 'secondaryColor': '#E67E22', 'tertiaryColor': '#7F8C8D'}}}%%
graph TB
    subgraph WEARABLE["Wearables & Personal"]
        W1["Fitness tracker β†’ BLE"]
        W2["Smartwatch β†’ BLE + Wi-Fi"]
        W3["Medical patch β†’ BLE"]
    end

    subgraph HOME["Smart Home"]
        H1["Light bulbs β†’ Zigbee/Thread"]
        H2["Security camera β†’ Wi-Fi"]
        H3["Door lock β†’ Zigbee/BLE"]
        H4["Thermostat β†’ Wi-Fi/Thread"]
    end

    subgraph INDUSTRIAL["Industrial & Agriculture"]
        I1["Soil sensor β†’ LoRaWAN"]
        I2["Factory machine β†’ Wi-Fi"]
        I3["Asset tracker β†’ NB-IoT"]
        I4["Pipeline monitor β†’ Sigfox"]
    end

    subgraph CITY["Smart City & Fleet"]
        C1["Parking sensor β†’ LoRaWAN"]
        C2["Street light β†’ LoRaWAN/NB-IoT"]
        C3["Delivery truck β†’ LTE-M"]
        C4["Water meter β†’ NB-IoT"]
    end

    style WEARABLE fill:#E67E22,stroke:#2C3E50,stroke-width:2px,color:#fff
    style HOME fill:#16A085,stroke:#2C3E50,stroke-width:2px,color:#fff
    style INDUSTRIAL fill:#2C3E50,stroke:#16A085,stroke-width:2px,color:#fff
    style CITY fill:#7F8C8D,stroke:#2C3E50,stroke-width:2px,color:#fff
    style W1 fill:#fff,stroke:#E67E22,stroke-width:1px,color:#2C3E50
    style W2 fill:#fff,stroke:#E67E22,stroke-width:1px,color:#2C3E50
    style W3 fill:#fff,stroke:#E67E22,stroke-width:1px,color:#2C3E50
    style H1 fill:#fff,stroke:#16A085,stroke-width:1px,color:#2C3E50
    style H2 fill:#fff,stroke:#16A085,stroke-width:1px,color:#2C3E50
    style H3 fill:#fff,stroke:#16A085,stroke-width:1px,color:#2C3E50
    style H4 fill:#fff,stroke:#16A085,stroke-width:1px,color:#2C3E50
    style I1 fill:#fff,stroke:#2C3E50,stroke-width:1px,color:#2C3E50
    style I2 fill:#fff,stroke:#2C3E50,stroke-width:1px,color:#2C3E50
    style I3 fill:#fff,stroke:#2C3E50,stroke-width:1px,color:#2C3E50
    style I4 fill:#fff,stroke:#2C3E50,stroke-width:1px,color:#2C3E50
    style C1 fill:#fff,stroke:#7F8C8D,stroke-width:1px,color:#2C3E50
    style C2 fill:#fff,stroke:#7F8C8D,stroke-width:1px,color:#2C3E50
    style C3 fill:#fff,stroke:#7F8C8D,stroke-width:1px,color:#2C3E50
    style C4 fill:#fff,stroke:#7F8C8D,stroke-width:1px,color:#2C3E50

Figure 82.4: Alternative view: Protocol Selection by Application Domain - Instead of organizing by technical characteristics (range/power), this view groups protocols by their dominant application areas. Wearables (orange) rely on BLE for phone connectivity. Smart homes (teal) mix Zigbee, Thread, and Wi-Fi based on device type. Industrial deployments (navy) favor LPWAN for remote sensors. Smart city applications (gray) use cellular IoT for coverage without infrastructure. This helps students match their project type directly to proven protocol choices. {fig-alt=β€œFour-quadrant diagram organizing protocols by application domain rather than technical specs. Wearables quadrant (orange): Fitness tracker uses BLE, Smartwatch uses BLE plus Wi-Fi, Medical patch uses BLE. Smart Home quadrant (teal): Light bulbs use Zigbee or Thread, Security camera uses Wi-Fi, Door lock uses Zigbee or BLE, Thermostat uses Wi-Fi or Thread. Industrial quadrant (navy): Soil sensor uses LoRaWAN, Factory machine uses Wi-Fi, Asset tracker uses NB-IoT, Pipeline monitor uses Sigfox. Smart City quadrant (gray): Parking sensor uses LoRaWAN, Street light uses LoRaWAN or NB-IoT, Delivery truck uses LTE-M, Water meter uses NB-IoT.”} 

%%{init: {'theme': 'base', 'themeVariables': {'primaryColor': '#2C3E50', 'primaryTextColor': '#fff', 'primaryBorderColor': '#16A085', 'lineColor': '#16A085', 'secondaryColor': '#E67E22', 'tertiaryColor': '#7F8C8D'}}}%%
graph TB
    subgraph CRITERIA["Weighted Scoring Criteria"]
        direction LR
        CR1["Range (25%)"]
        CR2["Battery Life (30%)"]
        CR3["Data Rate (15%)"]
        CR4["Cost (20%)"]
        CR5["Ecosystem (10%)"]
    end

    subgraph SCORES["Example: Agriculture Sensor Scoring"]
        direction TB
        subgraph LORA["LoRaWAN"]
            L1["Range: 9/10 Γ— 0.25 = 2.25"]
            L2["Battery: 10/10 Γ— 0.30 = 3.00"]
            L3["Data: 4/10 Γ— 0.15 = 0.60"]
            L4["Cost: 9/10 Γ— 0.20 = 1.80"]
            L5["Eco: 7/10 Γ— 0.10 = 0.70"]
            LTOT["TOTAL: 8.35"]
        end

        subgraph NBIOT["NB-IoT"]
            N1["Range: 10/10 Γ— 0.25 = 2.50"]
            N2["Battery: 7/10 Γ— 0.30 = 2.10"]
            N3["Data: 6/10 Γ— 0.15 = 0.90"]
            N4["Cost: 5/10 Γ— 0.20 = 1.00"]
            N5["Eco: 8/10 Γ— 0.10 = 0.80"]
            NTOT["TOTAL: 7.30"]
        end
    end

    CRITERIA --> SCORES
    LORA --> WINNER["Winner: LoRaWAN<br/>8.35 > 7.30"]

    style CR1 fill:#16A085,stroke:#2C3E50,stroke-width:1px,color:#fff
    style CR2 fill:#16A085,stroke:#2C3E50,stroke-width:2px,color:#fff
    style CR3 fill:#7F8C8D,stroke:#2C3E50,stroke-width:1px,color:#fff
    style CR4 fill:#E67E22,stroke:#2C3E50,stroke-width:2px,color:#fff
    style CR5 fill:#7F8C8D,stroke:#2C3E50,stroke-width:1px,color:#fff
    style LTOT fill:#16A085,stroke:#2C3E50,stroke-width:2px,color:#fff
    style NTOT fill:#E67E22,stroke:#2C3E50,stroke-width:2px,color:#fff
    style WINNER fill:#2C3E50,stroke:#16A085,stroke-width:3px,color:#fff

Figure 82.5: Alternative view: Weighted Scoring Matrix for Protocol Selection - This diagram demonstrates a systematic approach to protocol selection using weighted scoring. First, define your criteria and assign weights based on project priorities (Battery Life gets 30% in this agriculture example because sensors must last 5+ years). Then score each protocol candidate 1-10 on each criterion and multiply by weight. The protocol with the highest total score wins. This quantitative approach helps justify decisions to stakeholders and reveals which criteria are driving the choice. Note: weights should be determined BEFORE scoring to avoid bias. {fig-alt=β€œWeighted scoring matrix for protocol selection. Top section shows weighted criteria: Range 25%, Battery Life 30% (highest priority), Data Rate 15%, Cost 20%, Ecosystem 10%. Middle section shows scoring for two protocols. LoRaWAN scores: Range 9 of 10 times 0.25 equals 2.25, Battery 10 of 10 times 0.30 equals 3.00, Data 4 of 10 times 0.15 equals 0.60, Cost 9 of 10 times 0.20 equals 1.80, Ecosystem 7 of 10 times 0.10 equals 0.70, Total 8.35. NB-IoT scores: Range 10 of 10 times 0.25 equals 2.50, Battery 7 of 10 times 0.30 equals 2.10, Data 6 of 10 times 0.15 equals 0.90, Cost 5 of 10 times 0.20 equals 1.00, Ecosystem 8 of 10 times 0.10 equals 0.80, Total 7.30. Winner: LoRaWAN 8.35 greater than 7.30.”}

Protocol Trade-off Matrix:

Protocol Range Power Data Rate Infrastructure Best For
Wi-Fi 50-100m High (100-500mW) High (1-100 Mbps) Existing infra High-bandwidth, mains-powered
BLE 10-50m Low (10-50mW) Medium (1 Mbps) Smartphone gateway Wearables, beacons, proximity
Zigbee 10-100m Low (30mW) Medium (250 kbps) Coordinator + mesh Home automation, sensors
Thread 10-100m Low (30mW) Medium (250 kbps) Border router Matter/IP-based smart home
LoRaWAN 2-15km Very Low (20mW) Low (0.3-50 kbps) Gateway ($500) Long-range sensors, rural
NB-IoT 1-10km Low (50-200mW) Low (200 kbps) Carrier network Urban tracking, metering
Sigfox 3-50km Very Low (10mW) Very Low (100 bps) Carrier network Simple sensors, global
LTE-M 1-10km Medium (100-500mW) Medium (1 Mbps) Carrier network Mobile, voice, moderate data

Scenario: You’re designing an irrigation control system for a 200-hectare farm. Requirements: - 50 soil moisture sensors scattered across fields (200-800m from central building) - 10 irrigation valve controllers (200-1000m from building) - Sensors transmit: 12 bytes every 30 minutes (moisture, temperature, battery) - Valves receive: Commands occasionally (<10/day), respond with status (8 bytes) - Battery-powered sensors: Must last 3+ years without replacement - Budget: $150/device maximum (sensor + connectivity for 5 years)

You’re considering: Wi-Fi mesh, LoRaWAN, or NB-IoT.

Think about: 1. Can Wi-Fi reliably reach 800m outdoors? What’s the infrastructure cost for mesh repeaters? 2. How does LoRaWAN handle bidirectional valve control vs. sensor monitoring? 3. What’s the 5-year operational cost difference between LoRaWAN (gateway: $500 one-time) and NB-IoT ($3/device/year)?

Key Insights: - Wi-Fi: ❌ Range maxes at ~100m outdoors, would need 8+ mesh repeaters ($150 each) = $1,200 infrastructure - LoRaWAN: βœ… 800m easily covered by 1-2 gateways ($500-1000), bidirectional works (Class C for valves), $1,000 total - NB-IoT: βœ… Range excellent, bidirectional easy, BUT operational cost = 60 devices Γ— $3/year Γ— 5 years = $900 ongoing

Best Choice: LoRaWAN - One-time $1,000 infrastructure (2 gateways for redundancy) - Zero recurring costs (no subscriptions) - 10-year battery life on sensors - Class A for sensors (low power), Class C for valves (receive any time) - Total 5-year cost: $1,000 infrastructure + $0 ongoing = $1,000

Compare to NB-IoT: $900 + higher battery replacement (5 years vs 10) = $1,400+

Real-world lesson: Infrastructure costs seem high upfront, but subscription costs compound over time. For large deployments with stable locations, owned infrastructure (LoRa, Wi-Fi) often beats carrier networks (NB-IoT, LTE-M) on 5+ year TCO.

Use this checklist when designing your IoT system. Fill in your specific values to systematically narrow down protocol choices.

Step 1: Physical Requirements - [ ] Coverage area: _____ meters (indoor) OR _____ kilometers (outdoor) - [ ] Number of devices: Current: _____, Planned in 2 years: _____ - [ ] Device locations: Fixed / Mobile / Mixed - [ ] Environment: Indoor / Outdoor / Underground / Mixed - [ ] Physical obstacles: Walls / Buildings / Terrain / Water

Step 2: Power Requirements - [ ] Power source: Battery / Mains / Solar + Battery / Energy Harvesting - [ ] Battery life target: _____ months/years - [ ] Battery replacement acceptable?: Yes / No - [ ] Battery size constraint: _____ mAh maximum - [ ] Sleep mode possible?: Yes / No (duty cycle: _____%)

Step 3: Data Requirements - [ ] Payload size: _____ bytes per message - [ ] Message frequency: Every _____ seconds/minutes/hours - [ ] Daily data volume: _____ bytes per device per day - [ ] Bidirectional needed?: Yes (downlink frequency: _____) / No - [ ] Latency tolerance: Real-time (<100ms) / Interactive (<1s) / Delayed (>1min OK)

Step 4: Budget Constraints - [ ] Device hardware budget: €_____ per device - [ ] Infrastructure budget (gateways, installation): €_____ - [ ] Operational budget: €_____ per device per year (subscriptions, maintenance) - [ ] 5-year total cost of ownership: €_____ maximum - [ ] Development/integration budget: €_____

Step 5: Technical Constraints - [ ] Existing infrastructure: Wi-Fi / Cellular coverage / None - [ ] Integration requirements: Cloud platform: _____, Protocols: _____ - [ ] Security requirements: Encryption level: _____, Compliance: _____ - [ ] Reliability target: _____ % uptime required - [ ] Scalability needs: Can add devices without redesign? Yes / No

Step 6: Decision Worksheet

Based on your answers above, eliminate protocols:

Protocol Range OK? Power OK? Data Rate OK? Cost OK? Final?
Wi-Fi ☐ Yes ☐ No ☐ Yes ☐ No ☐ Yes ☐ No ☐ Yes ☐ No ☐ Candidate
Bluetooth ☐ Yes ☐ No ☐ Yes ☐ No ☐ Yes ☐ No ☐ Yes ☐ No ☐ Candidate
Zigbee ☐ Yes ☐ No ☐ Yes ☐ No ☐ Yes ☐ No ☐ Yes ☐ No ☐ Candidate
Thread ☐ Yes ☐ No ☐ Yes ☐ No ☐ Yes ☐ No ☐ Yes ☐ No ☐ Candidate
LoRaWAN ☐ Yes ☐ No ☐ Yes ☐ No ☐ Yes ☐ No ☐ Yes ☐ No ☐ Candidate
NB-IoT ☐ Yes ☐ No ☐ Yes ☐ No ☐ Yes ☐ No ☐ Yes ☐ No ☐ Candidate
Sigfox ☐ Yes ☐ No ☐ Yes ☐ No ☐ Yes ☐ No ☐ Yes ☐ No ☐ Candidate
LTE-M ☐ Yes ☐ No ☐ Yes ☐ No ☐ Yes ☐ No ☐ Yes ☐ No ☐ Candidate

Step 7: Prototype Validation

Before committing to large-scale deployment: - [ ] Coverage test: Verify range in actual environment (not just spec sheets) - [ ] Battery test: Measure actual power consumption over 1+ week - [ ] Interference test: Check performance with other devices nearby - [ ] Cost validation: Get real quotes for gateways, subscriptions, modules - [ ] Integration test: Confirm compatibility with your cloud/backend - [ ] Reliability test: Monitor uplink success rate over extended period - [ ] Scalability test: Test with 10+ devices to identify bottlenecks

Common Red Flags: - ⚠️ No real-world testing before committing to 1,000+ device order - ⚠️ Relying solely on coverage maps without site survey - ⚠️ Ignoring total cost of ownership (TCO) beyond first year - ⚠️ Choosing newest protocol without checking ecosystem maturity - ⚠️ Single point of failure (one gateway, one carrier)

82.6 Summary

Key Takeaways:

  • Three-Step Framework: Define requirements β†’ Eliminate non-viable β†’ Compare finalists
  • Requirements Matrix: Document range, power, bandwidth, latency, cost, and scalability needs
  • Decision Tree: Use four key questions (range, power, data rate, infrastructure) to eliminate protocols quickly
  • Weighted Scoring: Quantify comparisons by assigning weights to criteria based on project priorities
  • TCO Analysis: Always calculate 5-year total cost including hardware, infrastructure, and subscriptions
  • Prototype First: Real-world testing reveals issues that specifications hide

82.7 What’s Next

In the next chapter, Anti-Patterns and Tradeoffs, you’ll learn common mistakes to avoid in protocol selection and understand the key engineering tradeoffs between different protocol families.

Continue to Anti-Patterns and Tradeoffs β†’