38  Protocol Selection Framework

In 60 Seconds

A three-step framework systematically selects IoT protocols: (1) Define requirements across range, power, bandwidth, latency, cost, and scalability. (2) Eliminate non-viable options using four key questions: range needed, power budget, data rate, and infrastructure preference. (3) Compare finalists with weighted scoring and 5-year TCO analysis. For example, a vineyard monitoring system eliminates Wi-Fi (range), then compares LoRaWAN vs NB-IoT vs Sigfox, finding LoRaWAN wins on cost and battery life.

38.1 Learning Objectives

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

• Construct a Requirements Matrix: Build a comprehensive requirements matrix that captures range, power, bandwidth, latency, cost, and scalability constraints for an IoT deployment
• Apply a Decision Tree: Use four elimination questions (range, power budget, data rate, infrastructure) to systematically disqualify non-viable protocols from a candidate list
• Calculate Total Cost of Ownership: Compute 5-year TCO for competing protocols by combining infrastructure, subscription, and maintenance costs
• Evaluate Finalists with Weighted Scoring: Assign priority weights to selection criteria and score shortlisted protocols to produce a quantitative recommendation
• Justify a Protocol Decision: Defend a final protocol choice by mapping it back to documented requirements, elimination rationale, and cost analysis

Key Concepts

• Protocol Selection Criteria: Device constraints (RAM/CPU), network type (cellular/LoRa/WiFi), QoS requirements, and cloud ecosystem
• MQTT: Best for telemetry from constrained devices — minimal overhead, native pub/sub, widely supported
• CoAP: Best for request/response with constrained devices over UDP — REST-compatible with 4-byte headers
• AMQP: Best for enterprise routing with complex delivery guarantees — exchanges, queues, dead-letter handling
• HTTP/REST: Best for cloud APIs and dashboard integration — universal support but 100× overhead versus MQTT
• DDS: Best for real-time control (robotics, autonomous vehicles) — sub-millisecond latency, no broker
• WebSocket: Best for real-time browser dashboards — bidirectional persistent connection over HTTP upgrade

38.2 For Beginners: Systematic Protocol Selection

Choosing the right communication protocol for your IoT project does not have to be guesswork. This chapter gives you a simple three-step process: first, write down what your project needs (range, battery life, data speed); second, use those needs to cross off protocols that cannot work; third, compare the remaining options with a scoring system. It is like shopping for a phone by first setting a budget and must-have features, then comparing the shortlisted models side by side.

Related Chapters

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

38.3 Step 1: Define Application Requirements

How It Works: Requirements-Driven Protocol Selection

The big picture: Protocol selection starts with documenting constraints, then systematically eliminating protocols that fail mandatory requirements.

Step-by-step breakdown:

1. Document constraints: List range, power, bandwidth, latency, cost as hard requirements – Real example: “5km range” immediately eliminates Wi-Fi, BLE, Zigbee (max 100m).
2. Apply elimination filters: Use decision tree to remove non-viable protocols – Real example: “5-year battery” eliminates Wi-Fi (high power), leaving LoRaWAN, NB-IoT, Sigfox.
3. Score finalists: Weight remaining protocols by priority criteria – Real example: If infrastructure ownership is critical, LoRaWAN (self-hosted) scores higher than NB-IoT (carrier-dependent).

Why this matters: Skipping requirements documentation leads to late redesigns – discovering your 10-year battery requirement after choosing Wi-Fi costs months.

Create a requirements matrix:

• Range: Indoor 30m or outdoor 5km. Rationale: deployment area.
• Update interval: Every 5 min, 15 min, or 1 hour. Rationale: data freshness needs.
• Payload size: 10 bytes, 100 bytes, or 1 KB. Rationale: sensor data volume.
• Battery life: 3 months, 1 year, or 5 years. Rationale: maintenance budget.
• Device count: 10, 100, or 10,000 devices. Rationale: scalability needs.
• Budget: $10/device or $50/device. Rationale: cost constraints.
• Latency: <100ms, <1s, or >1 min acceptable. Rationale: real-time requirements.

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

Figure 38.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.

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.

Figure 38.2

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

Real-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: fails (Outdoor range ~100m, would need 20+ access points = €3,000+)
• Bluetooth: fails (Range 10-50m, would need 100+ gateways, not feasible)
• Zigbee: fails (Mesh helps but 100m hop limit × terrain = poor reliability)
• NB-IoT: passes (1-10km range covers entire farm from single cell tower)
• LoRaWAN: passes (2-15km range, 1-2 gateways cover 50 hectares even with hills)
• Sigfox: passes (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:

Putting Numbers to It

Battery life depends on energy per transmission and message frequency:

\[\text{Battery Life (hours)} = \frac{\text{Battery Capacity (mAh)} \times \text{Voltage (V)}}{\text{Energy per Message (mWh)} \times \text{Messages per Hour}}\]

Worked example: NB-IoT with 200mW × 5s = 1,000 mWs = 0.28 mWh per message, 4 messages/hour:

\[\frac{10{,}000 \times 3.7}{0.28 \times 4} = 33{,}214\,\text{hours} = 3.8\,\text{years}\]

LoRaWAN at 0.011 mWh/message:

\[\frac{10{,}000 \times 3.7}{0.011 \times 4} = 840{,}909\,\text{hours} = 96\,\text{years}\]

Protocol choice multiplies battery life by 25×.

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: caution (Marginal, needs larger battery or more solar capacity)
• LoRaWAN: pass (Excellent 5+ year life)
• Sigfox: pass (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 comparison snapshot:

• LoRaWAN: Bidirectional yes (8 downlinks/day); message size 51-242 bytes; our 20-byte payload fits cleanly; firmware updates possible but slow; network ownership stays with the deployer; coverage is self-controlled; 1% duty cycle is enough for four uplinks per hour.
• Sigfox: Bidirectional support is limited (4 downlinks/day); message size capped at 12 bytes, so a 20-byte payload needs optimization; firmware updates are not practical; coverage depends on Sigfox network availability; 140 messages/day limit is still enough for this use case.
• NB-IoT: Bidirectional support is effectively unlimited; message size up to 1,600 bytes; our 20-byte payload fits easily; firmware updates are supported; coverage depends on carrier footprint; subscriptions and carrier dependency remain the main trade-offs.

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

Concept Check: Systematic Selection

Concept Relationships: Systematic Selection

• Range requirement → Power budget: Long-range protocols such as LoRa often deliver better battery life than mid-range choices like Wi-Fi.
• Elimination step → Anti-patterns: Avoiding “Wi-Fi because we already have it” means applying the range and power filters rigorously.
• TCO calculation → Infrastructure vs. subscription: LoRaWAN’s upfront gateway spend breaks even with NB-IoT subscriptions at roughly 200 devices.

Cross-module connection: See Protocol Anti-Patterns for common mistakes that bypass systematic elimination.

38.5 See Also

• The Challenge — Understanding fundamental protocol trade-offs before selection
• Anti-Patterns — Common protocol selection mistakes to avoid
• Selection Scenarios — Apply framework to smart city, fleet tracking, wearables

38.6 Step 3: Compare Finalists

Example Comparison: Smart Parking Sensor

• Wi-Fi: Range fails, power fails, and gateway density makes infrastructure cost unacceptable. Verdict: no.
• BLE: Power is fine, but range fails and gateways would still be needed. Verdict: no.
• LoRaWAN: Passes range, battery life, data rate, and infrastructure cost. Verdict: yes.
• NB-IoT: Passes range, battery life, and data rate, but recurring per-device cost remains a caution. Verdict: maybe.

Winner: LoRaWAN for cost and battery life

Concept Check: When Finalists Are Too Close to Call

38.6.1 Interactive TCO Calculator

Compare 5-year total cost of ownership between LoRaWAN (infrastructure) and NB-IoT (subscription):

ieeeColors = ({
  navy: "#2C3E50",
  teal: "#16A085",
  orange: "#E67E22",
  blue: "#3498DB",
  gray: "#7F8C8D",
  purple: "#9B59B6",
  red: "#E74C3C"
})

// User inputs
viewof deviceCount = Inputs.range([10, 5000], {
  value: 200,
  step: 10,
  label: "Number of Devices"
})

viewof loraGatewayCount = Inputs.range([1, 10], {
  value: 2,
  step: 1,
  label: "LoRaWAN Gateways"
})

viewof loraGatewayCost = Inputs.range([500, 3000], {
  value: 1500,
  step: 100,
  label: "Cost per Gateway ($)"
})

viewof nbiotSubscription = Inputs.range([1, 10], {
  value: 2,
  step: 0.5,
  label: "NB-IoT Fee ($/month)"
})

// Calculate costs
loraInfra = loraGatewayCount * loraGatewayCost
loraPerDevice = 15
loraTotalCost = loraInfra + (deviceCount * loraPerDevice)

nbiotYearlyCost = nbiotSubscription * 12
nbiot5YearCost = nbiotYearlyCost * 5
nbiotTotalCost = deviceCount * nbiot5YearCost

savings = nbiotTotalCost - loraTotalCost
breakEvenDevices = Math.ceil(loraInfra / nbiot5YearCost)

// Visualization
{
  const width = 640;
  const height = 400;
  const marginTop = 20;
  const marginRight = 30;
  const marginBottom = 40;
  const marginLeft = 60;

  const svg = d3.create("svg")
    .attr("width", width)
    .attr("height", height)
    .attr("viewBox", [0, 0, width, height])
    .attr("style", "max-width: 100%; height: auto;");

  // Scales
  const x = d3.scaleLinear()
    .domain([0, Math.max(loraTotalCost, nbiotTotalCost)])
    .range([marginLeft, width - marginRight]);

  const y = d3.scaleBand()
    .domain(["LoRaWAN", "NB-IoT"])
    .range([marginTop, height - marginBottom])
    .padding(0.3);

  // Bars
  svg.append("rect")
    .attr("x", marginLeft)
    .attr("y", y("LoRaWAN"))
    .attr("width", x(loraTotalCost) - marginLeft)
    .attr("height", y.bandwidth())
    .attr("fill", ieeeColors.teal)
    .attr("rx", 4);

  svg.append("rect")
    .attr("x", marginLeft)
    .attr("y", y("NB-IoT"))
    .attr("width", x(nbiotTotalCost) - marginLeft)
    .attr("height", y.bandwidth())
    .attr("fill", ieeeColors.orange)
    .attr("rx", 4);

  // Labels
  svg.append("text")
    .attr("x", x(loraTotalCost) + 5)
    .attr("y", y("LoRaWAN") + y.bandwidth() / 2)
    .attr("dy", "0.35em")
    .attr("fill", ieeeColors.navy)
    .attr("font-family", "Arial, sans-serif")
    .attr("font-size", "14px")
    .attr("font-weight", "bold")
    .text(`$${loraTotalCost.toLocaleString()}`);

  svg.append("text")
    .attr("x", x(nbiotTotalCost) + 5)
    .attr("y", y("NB-IoT") + y.bandwidth() / 2)
    .attr("dy", "0.35em")
    .attr("fill", ieeeColors.navy)
    .attr("font-family", "Arial, sans-serif")
    .attr("font-size", "14px")
    .attr("font-weight", "bold")
    .text(`$${nbiotTotalCost.toLocaleString()}`);

  // Y-axis labels
  svg.append("g")
    .selectAll("text")
    .data(["LoRaWAN", "NB-IoT"])
    .join("text")
    .attr("x", marginLeft - 10)
    .attr("y", d => y(d) + y.bandwidth() / 2)
    .attr("dy", "0.35em")
    .attr("text-anchor", "end")
    .attr("font-family", "Arial, sans-serif")
    .attr("font-size", "14px")
    .attr("fill", ieeeColors.navy)
    .text(d => d);

  // X-axis
  svg.append("g")
    .attr("transform", `translate(0,${height - marginBottom})`)
    .call(d3.axisBottom(x).ticks(5).tickFormat(d => `$${d / 1000}k`))
    .call(g => g.select(".domain").attr("stroke", ieeeColors.gray))
    .call(g => g.selectAll(".tick line").attr("stroke", ieeeColors.gray))
    .call(g => g.selectAll(".tick text")
      .attr("font-family", "Arial, sans-serif")
      .attr("font-size", "12px")
      .attr("fill", ieeeColors.navy));

  return svg.node();
}

md`**Cost Comparison Summary**

- **LoRaWAN Total (5 years)**: $${loraTotalCost.toLocaleString()} (Infrastructure: $${loraInfra.toLocaleString()} + Devices: $${(deviceCount * loraPerDevice).toLocaleString()})
- **NB-IoT Total (5 years)**: $${nbiotTotalCost.toLocaleString()} (${deviceCount} devices × $${nbiot5YearCost}/device)
- **Savings**: ${savings >= 0 ? `LoRaWAN saves $${savings.toLocaleString()}` : `NB-IoT saves $${Math.abs(savings).toLocaleString()}`}
- **Break-even Point**: ${breakEvenDevices} devices

${savings >= 0
  ? `Recommendation: LoRaWAN is more cost-effective for ${deviceCount} devices`
  : `Recommendation: NB-IoT is more cost-effective for ${deviceCount} devices`}
`

38.7 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).

Figure 38.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.

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.

Figure 38.4

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.

Figure 38.5

Protocol Trade-off Matrix:

• Wi-Fi: 50-100m range, high power draw (100-500mW), high throughput (1-100 Mbps), works best when existing infrastructure and mains power are available.
• BLE: 10-50m range, low power draw (10-50mW), medium throughput (1 Mbps), strongest for wearables, beacons, and proximity use cases.
• Zigbee: 10-100m range, low power draw (30mW), medium throughput (250 kbps), fits coordinator-plus-mesh sensor deployments.
• Thread: 10-100m range, low power draw (30mW), medium throughput (250 kbps), fits Matter/IP-based smart-home meshes.
• LoRaWAN: 2-15km range, very low power draw (20mW), low throughput (0.3-50 kbps), gateway-based and strongest for long-range rural sensing.
• NB-IoT: 1-10km range, low power draw (50-200mW), low throughput (200 kbps), carrier-managed and strongest for urban tracking and metering.
• Sigfox: 3-50km range, very low power draw (10mW), ultra-low throughput (100 bps), carrier-managed and strongest for tiny-payload global sensing.
• LTE-M: 1-10km range, medium power draw (100-500mW), medium throughput (1 Mbps), strongest for mobile deployments and moderate-data applications.

---

Quiz 1: Protocol Selection for Smart Agriculture

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: fails (Range maxes at ~100m outdoors, would need 8+ mesh repeaters ($150 each) = $1,200 infrastructure)
• LoRaWAN: passes (800m easily covered by 1-2 gateways ($500-1000), bidirectional works (Class C for valves), $1,000 total)
• NB-IoT: passes (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.

---

Protocol Selection Checklist for Your Projects

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:

• Wi-Fi: Range yes/no, power yes/no, data rate yes/no, cost yes/no, final decision.
• Bluetooth: Range yes/no, power yes/no, data rate yes/no, cost yes/no, final decision.
• Zigbee: Range yes/no, power yes/no, data rate yes/no, cost yes/no, final decision.
• Thread: Range yes/no, power yes/no, data rate yes/no, cost yes/no, final decision.
• LoRaWAN: Range yes/no, power yes/no, data rate yes/no, cost yes/no, final decision.
• NB-IoT: Range yes/no, power yes/no, data rate yes/no, cost yes/no, final decision.
• Sigfox: Range yes/no, power yes/no, data rate yes/no, cost yes/no, final decision.
• LTE-M: Range yes/no, power yes/no, data rate yes/no, cost yes/no, final decision.

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:

• Warning: no real-world testing before committing to 1,000+ device order
• Warning: relying solely on coverage maps without site survey
• Warning: ignoring total cost of ownership (TCO) beyond first year
• Warning: choosing newest protocol without checking ecosystem maturity
• Warning: single point of failure (one gateway, one carrier)

---

Common Pitfalls

1. Turning the Scoring Matrix into Step 1

Teams often jump straight to weighted scoring because it feels quantitative, but scoring should happen only after mandatory constraints are documented and non-viable protocols are eliminated. If a protocol cannot reach the site, cannot meet battery targets, or requires forbidden infrastructure, no score can rescue it.

2. Choosing Weights After Seeing the Results

Weights should reflect project priorities before candidate protocols are scored. Changing the weights after one protocol comes out ahead turns the framework into a justification exercise instead of a decision method. Lock the criteria, lock the weights, then compare the finalists.

3. Treating TCO and Prototype Validation as Optional

Specification tables do not reveal carrier fees, installation effort, gateway maintenance, terrain shadows, or interference from nearby systems. A framework-driven decision is incomplete until 5-year operating cost is calculated and the winning protocol is tested in the real deployment environment.

🏷️ Label the Diagram

Code Challenge

38.8 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

---

38.9 Knowledge Check

Quiz: Protocol Selection Framework

38.10 What’s Next

• Anti-Patterns and Tradeoffs — Common protocol selection mistakes and the engineering tradeoffs that cause them.
• Selection Scenarios — Apply the three-step framework to smart city, fleet tracking, and wearable use cases.
• LPWAN Comparison — Side-by-side comparison of LoRaWAN, NB-IoT, Sigfox, and LTE-M on range, power, and cost.
• LoRaWAN Overview — Deep dive into LoRaWAN architecture, device classes, and deployment considerations.
• Bluetooth Overview — BLE protocol stack, connection modes, and short-range IoT selection criteria.

For Kids: Meet the Sensor Squad!

The Sensor Squad is helping Farmer Fred pick the right communication for his vineyard sensors. Max the Microcontroller pulls out a checklist:

“Let’s play the Elimination Game! We’ll ask four questions and cross out any protocol that fails.”

Question 1: How far? Max asks: “The sensors are spread across 50 hectares of hilly fields. That’s almost a kilometer away!” Lila the LED draws big X marks: “Bluetooth? TOO SHORT. Wi-Fi? TOO SHORT. Only LoRa, NB-IoT, and Sigfox can reach that far!”

Question 2: How long must the battery last? Bella the Battery says: “Farmer Fred wants 5 years! NB-IoT uses more power because it talks to cell towers, so it only lasts about 5 years – cutting it close. LoRa and Sigfox can last 10+ years!”

Question 3: How much data? Sammy the Sensor reports: “Just 20 bytes every 30 minutes – moisture, temperature, and my battery level.” Max checks: “All three can handle that. No eliminations!”

Question 4: How much does it cost? Max tallies up: “LoRa needs two gateways ($1,000 total, but then FREE forever). NB-IoT charges $3 per sensor per YEAR – that adds up to $3,000 over 5 years for 200 sensors!”

The winner: “LoRa wins!” cheers the Squad. “It reaches far enough, the battery lasts forever, and after buying the gateways, it’s FREE!”

The Squad’s Rule: Don’t guess – use a checklist! Ask about range, battery, data, and cost, and cross out anything that doesn’t fit. The answer becomes obvious!