39  Protocol Selection Scenarios

In 60 Seconds

Protocol selection comes alive through real scenarios: smart city parking (5,000 sensors) favors LoRaWAN at $16.60/sensor over 5 years vs. NB-IoT at $35. Wearable health monitors require BLE as the only coin-cell-compatible protocol with native smartphone support. Global fleet tracking demands multi-protocol systems (Satellite + Cellular + Wi-Fi). Building retrofits use Thread/Zigbee mesh to route around concrete walls. Always calculate 5-year TCO before committing.

39.1 Learning Objectives

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

  • Apply the selection framework to real scenarios: Walk through complete protocol selection decisions for smart cities, wearables, logistics, and building retrofits
  • Calculate 5-year Total Cost of Ownership (TCO): Itemize hardware, subscriptions, maintenance, and hidden costs to compare protocols quantitatively
  • Architect multi-protocol systems: Combine satellite, cellular, and local wireless protocols to achieve global coverage in fleet-tracking deployments
  • Evaluate mesh networking strategies for constrained environments: Select Thread, Zigbee, or hybrid topologies to overcome concrete walls, underground garages, and RF-hostile buildings
  • Justify protocol elimination through constraint analysis: Disqualify candidate protocols by mapping power budgets, latency requirements, and form-factor limits against protocol capabilities
  • 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

39.2 For Beginners: Protocol Selection Scenarios

This chapter applies protocol selection to real-world situations, like choosing the best communication technology for a smart parking system or a wearable health monitor. Think of it like choosing between postal mail, text messaging, and a phone call depending on the situation – each has strengths and weaknesses. Walking through these scenarios builds the practical judgment you need to make good decisions for your own IoT projects.

This Chapter Series:

Application Domains:

39.3 How It Works: Protocol Selection via Scenario Analysis

How It Works: Turning Requirements into Protocol Recommendations

The big picture: Real IoT projects have multiple, sometimes conflicting requirements. Scenario-based protocol selection works by mapping requirements to protocol capabilities, calculating total cost of ownership (TCO), and identifying disqualifying constraints.

Step-by-step breakdown:

  1. List all requirements: Range (5 km), power (5 years battery), data rate (50 bytes/30s), device count (5,000), budget ($75/sensor), environment (outdoor/underground) - Real example: Smart parking scenario below lists 6 constraints.

  2. Calculate bandwidth needs: 50 bytes every 30 seconds = 1.33 bytes/second = 10.7 bits/second average. Even the slowest LPWAN protocol (Sigfox at 100 bps) easily handles this. This eliminates bandwidth as a constraint - focus shifts to range and power.

  3. Compute 5-year TCO for each candidate: LoRaWAN ($6,000 gateways + $75,000 sensors = $81,000 total). NB-IoT ($0 infrastructure + $100,000 hardware + $60,000 subscriptions over 5 years = $160,000). Sigfox ($0 infrastructure + $60,000 hardware + $37,500 subscriptions = $97,500). TCO drives final decision when technical capabilities are equivalent.

Why this matters: Premature protocol selection (choosing before full requirements analysis) leads to costly redesigns. The worked examples in this chapter show how small requirement changes (e.g., “must work underground”) can flip the optimal protocol choice from LoRaWAN to NB-IoT, costing an extra $79,000 over 5 years if decided incorrectly.

39.4 Scenario 1: Smart City Parking System

Situation: A city wants to deploy smart parking sensors in 5,000 parking spots across downtown. Requirements: - Detect vehicle presence (simple binary: occupied/vacant) - Update status within 30 seconds of change - Battery life: minimum 5 years (no power infrastructure in streets) - Budget: $75 per sensor (hardware + 5-year connectivity) - Coverage: 2 km² urban area with buildings, underground parking garages

The city is evaluating: LoRaWAN, NB-IoT, and Sigfox.

Question: Which protocol would you recommend? Calculate the 5-year total cost of ownership for each option and justify your choice.

Analysis by Protocol:

LoRaWAN:

  • Infrastructure: 4 gateways × $1,500 = $6,000 (covers 2 km² with building penetration)
  • Gateway installation: $2,000 (poles, power, weatherproofing)
  • Network server: Self-hosted = $0/year, or TTN = $0
  • Sensor module cost: $15/sensor
  • 5-year total: $6,000 + $2,000 + (5,000 × $15) = $83,000
  • Per sensor: $83,000 ÷ 5,000 = $16.60/sensor

NB-IoT:

  • Infrastructure: $0 (uses carrier network)
  • Subscription: $2/sensor/year × 5 years = $10/sensor
  • Activation: $5/sensor
  • Sensor module cost: $20/sensor (cellular modem more expensive)
  • 5-year total: 5,000 × ($20 + $5 + $10) = $175,000
  • Per sensor: $35/sensor

Sigfox:

  • Infrastructure: $0 (uses Sigfox network)
  • Subscription: $1.50/sensor/year × 5 years = $7.50/sensor
  • Activation: $8/sensor
  • Sensor module cost: $12/sensor (simple radio)
  • 5-year total: 5,000 × ($12 + $8 + $7.50) = $137,500
  • Per sensor: $27.50/sensor

Cost Summary:

  • LoRaWAN: $16.60 per sensor. Budget fit: yes.
  • Sigfox: $27.50 per sensor. Budget fit: yes.
  • NB-IoT: $35.00 per sensor. Budget fit: yes.

But cost isn’t everything - feature comparison:

  • LoRaWAN: Good underground support with SF12, no hard message limit, 30-second updates are achievable, 8 downlinks/day, no vendor lock-in, and 10+ year battery life.
  • Sigfox: Underground support is marginal, capped at 140 messages/day, 30-second updates are barely workable, only 4 downlinks/day, vendor-network dependency, but still 10+ year battery life.
  • NB-IoT: Excellent underground support, unlimited messaging and downlinks, 30-second updates are easy, carrier dependency remains, and battery life is typically 5-7 years.

Recommendation: LoRaWAN

Justification:

  1. Lowest cost: $16.60/sensor vs $27.50 (Sigfox) or $35 (NB-IoT)
  2. Best coverage: Can place gateways strategically for underground garages
  3. No message limits: Important during events (high turnover)
  4. Future flexibility: City owns infrastructure, can add more sensors
  5. Battery life: 10+ years exceeds requirement, reduces maintenance

Why not Sigfox?

  • 140 messages/day limit: With 100 car changes/day/spot during peak hours, system might throttle
  • Underground coverage: Less reliable without local gateway control

Why not NB-IoT?

  • 2× the cost of LoRaWAN
  • Battery life shorter (cellular overhead)
  • Carrier dependency for 5-year contract

39.5 Concept Check: Protocol Selection Reasoning

39.6 Scenario 2: Wearable Health Monitor

Situation: A medical device company is designing a continuous glucose monitor (CGM) that: - Measures glucose every 5 minutes - Sends data to smartphone app for display - Alerts phone immediately if glucose is dangerously high/low - Worn on body 24/7 for 14-day sensor life - Small form factor (coin-cell battery, 25mm diameter) - Regulatory requirement: 99.9% data delivery reliability

You’re evaluating: BLE, Zigbee, Wi-Fi, and LoRa.

Question: Which protocol is most suitable? Consider power consumption, range requirements, and the critical nature of health alerts.

Elimination by Requirements:

Wi-Fi ❌ ELIMINATED - Power: 100-300mA during transmission - CR2032 coin cell: 220 mAh capacity - Wi-Fi would drain battery in <24 hours - Form factor: Wi-Fi antennas too large for 25mm device

LoRa ❌ ELIMINATED - Range: 2-15 km (massively overkill for body-to-phone) - Power: Better than Wi-Fi, but still 20-50mA TX - Form factor: LoRa modules typically 15×20mm minimum - Latency: Not designed for real-time alerts (duty cycle limits)

Zigbee ⚠️ POSSIBLE BUT NOT IDEAL - Power: 30mA TX, reasonable sleep modes - Range: 10-100m (adequate for phone proximity) - Problem: Requires Zigbee coordinator - smartphones don’t have Zigbee radios natively - Would need USB dongle or gateway, reducing usability

BLE ✅ RECOMMENDED - Power: 10-15mA TX, excellent sleep modes - Range: 10-50m (perfect for on-body to phone) - Smartphone integration: Native support on iOS/Android - Medical device standard: Bluetooth SIG has GATT profiles for CGM - Low latency: Connection-oriented, alerts delivered in <100ms

Detailed BLE Analysis:

Power Budget Calculation:

  • Sleep: 1 µA for 23.9 hours continuously, about 23.9 µAh/day.
  • Wake + measure: 5 mA for 50 ms, 288 times/day, about 0.02 mAh/day.
  • BLE TX (5-minute data): 15 mA for 10 ms, 288 times/day, about 0.04 mAh/day.
  • BLE TX (alerts): 15 mA for 50 ms, about 5 times/day, about 0.004 mAh/day.
  • Daily total: about 24 µAh + 0.06 mAh = 0.08 mAh/day.

Battery Life:

  • CR2032: 220 mAh
  • Daily consumption: 0.08 mAh
  • Theoretical life: 2,750 days = 7.5 years
  • With 50% safety margin: 3.75 years (far exceeds 14-day sensor life)

Reliability for Alerts:

BLE connection-oriented mode with: - Retransmission: Automatic packet retry on failure - ACK/NACK: Confirmed delivery - Bonded pairing: Phone stays connected 24/7 - GATT notifications: Push alerts without polling

99.9% reliability achievable through: 1. Connection interval: 500ms (phone checks CGM frequently) 2. Retry on disconnect: Auto-reconnect within 5 seconds 3. Store-and-forward: CGM buffers if phone temporarily out of range

Recommendation: BLE (Bluetooth Low Energy)

Specific Implementation:

  • BLE 5.0 for extended range (400m line-of-sight, 50m through body)
  • GATT CGM Profile (standardized glucose measurement characteristic)
  • Bonded pairing for security (AES-128 encryption)
  • Connection interval: 500ms when monitoring, 50ms during alerts

39.7 Scenario 3: Fleet Tracking Across Three Continents

Situation: A logistics company needs to track 10,000 shipping containers across: - Ocean transit (30+ days, no cellular coverage) - Port storage (weeks, good cellular coverage) - Truck transport (hours, mixed coverage) - Warehouse storage (months, indoor Wi-Fi available)

Requirements: - Position update every 6 hours during transit - Real-time alerts if container opened or temperature exceeded - 3-year battery life without charging - Must work globally (US, Europe, Asia)

Question: This is a multi-protocol challenge. Design a system that uses different protocols for different scenarios. Justify each choice.

Multi-Protocol Architecture:

  • Ocean transit: Primary protocol Satellite (Iridium SBD); backup GPS logging only; no cellular coverage exists at sea.
  • Port and truck: Primary protocol LTE-M or NB-IoT; backup Satellite; best balance of coverage and bidirectional connectivity.
  • Warehouse: Primary protocol Wi-Fi; backup LTE-M; warehouse Wi-Fi is free and supports higher-bandwidth diagnostics.

Detailed Protocol Selection:

1. Ocean Transit: Iridium SBD (Short Burst Data)

Why Iridium: - Global coverage: Only satellite network with 100% earth coverage including poles - Message size: 340 bytes (enough for GPS + sensor data) - Power: 1.5W TX for 20 seconds = 0.008 Wh per message - Cost: ~$0.05-0.15 per message × 4/day × 30 days = $6-18 per ocean crossing

Why not other satellites: - Globalstar: Coverage gaps in mid-ocean - Inmarsat: Larger terminals, higher power

2. Port/Truck: LTE-M (with NB-IoT fallback)

Why LTE-M: - Mobility: Designed for moving objects (trucks), handoff between cells - Power: PSM mode for sleep, 100mW TX - Latency: <100ms for real-time alerts - Global roaming: Single SIM works across regions with roaming agreements - Cost: $3-5/month/device with 10MB plan

Why LTE-M over NB-IoT: - Better for moving containers (NB-IoT optimized for stationary) - Lower latency for alerts

3. Warehouse: Wi-Fi (with LTE-M fallback)

Why Wi-Fi: - Free: Uses warehouse’s existing network - Bandwidth: Can upload diagnostic logs, firmware updates - Power: 200mW TX, but sleep modes work when mains-connected

Fallback to LTE-M: - Not all warehouses have Wi-Fi credentials shared - Quick position update if Wi-Fi unavailable

Hybrid Tracker Hardware Design:

┌─────────────────────────────────────────┐
│           MULTI-PROTOCOL TRACKER        │
├─────────────────────────────────────────┤
│ GPS Module: u-blox M8 (72-channel)      │
│ Iridium: 9603 SBD Transceiver           │
│ LTE-M/NB-IoT: Quectel BG96              │
│ Wi-Fi: ESP32 (secondary processor)        │
│ Sensors: Temp/Humidity, Accelerometer   │
│ Battery: 2× 19Ah LiSOCl2 (D-cell)       │
└─────────────────────────────────────────┘

Power Budget (3-year life):

  • GPS fix: 30 mA for 30 s, 4/day, about 2.4 Ah over 3 years.
  • Iridium TX: 1.5 A for 20 s, 4/day during 30 ocean days/year, about 1.0 Ah over 3 years.
  • LTE-M TX: 0.5 A for 5 s, 4/day during 200 days/year, about 1.1 Ah over 3 years.
  • Wi-Fi TX: 0.2 A for 10 s, 4/day during 135 days/year, about 0.3 Ah over 3 years.
  • Sleep (PSM): 10 µA for 99.9% of time, about 0.3 Ah over 3 years.
  • Total: about 5.1 Ah over 3 years.

2× 19Ah batteries = 38 Ah capacity → 7.5 year theoretical life (3+ years with safety margin)

Cost Analysis (per container, 3 years):

  • Hardware: $150.
  • Iridium: $108 for 90 ocean days/year over 3 years with 4 messages/day.
  • LTE-M: $144 for $4/month over 3 years.
  • Total 3-year TCO: $402 per container.

Key insight: Multi-protocol systems are more complex but essential for global logistics where no single technology provides universal coverage.

39.7.1 Concept Check: Multi-Protocol Design

39.8 Scenario 4: Smart Building Retrofit

Situation: A 50-year-old office building (20 floors, 500,000 sq ft) needs IoT sensors for: - 2,000 occupancy sensors (meeting rooms, desks) - 500 HVAC zone sensors (temperature, humidity, CO2) - 200 lighting controllers - 50 elevator/door sensors

Constraints: - No new wiring allowed (historical building) - Must work through concrete floors and walls - IT department won’t allow new equipment on corporate Wi-Fi network - Budget: $150,000 total (sensors + infrastructure)

Question: Which protocol(s) would you choose? How would you handle the concrete penetration challenge?

Constraint Analysis:

  • No new wiring: The deployment must stay battery-powered and wireless.
  • Concrete and walls: The protocol must support mesh routing or require multiple gateways per floor.
  • No corporate Wi-Fi: The system needs a separate network or a non-Wi-Fi protocol.
  • Budget of $150K: The final design must stay cost-effective at building scale.

Protocol Evaluation:

Wi-Fi ❌ ELIMINATED - IT won’t allow on corporate network - Separate Wi-Fi network = interference, complex management - Power consumption too high for 2,000 battery sensors

LoRaWAN ⚠️ POSSIBLE BUT CHALLENGING - Concrete penetration: Poor through multiple floors - Would need gateway on every floor (20 gateways × $500 = $10,000) - Good for some use cases but overkill for indoor

Zigbee ✅ GOOD OPTION - Mesh networking: Sensors relay through each other - Concrete: Mesh routing around obstacles - Power: Low, 2-5 year battery life - Cost: Modules $5-15 each - Challenge: Need coordinators and powered routing nodes

Thread (Matter) ✅ EXCELLENT OPTION - Mesh over 802.15.4 (same radio as Zigbee) - IP-based: Easier cloud integration - Future-proof: Matter ecosystem growing - Border routers: Can use existing Ethernet drops - Interoperability: Mix vendors without compatibility issues

Recommended Solution: Thread/Matter + Zigbee Hybrid

Architecture:

┌─────────────────────────────────────────────────────────┐
│                      CLOUD PLATFORM                      │
│               (HVAC Control, Analytics)                  │
└─────────────────────────────────────────────────────────┘
                            ▲
                            │ Internet (existing building connection)
                            ▼
┌─────────────────────────────────────────────────────────┐
│              BUILDING MANAGEMENT SERVER                  │
│         (Thread Border Routers + Zigbee Hub)            │
└─────────────────────────────────────────────────────────┘
         ▲                    ▲                    ▲
         │                    │                    │
    ┌────┴────┐          ┌────┴────┐          ┌────┴────┐
    │ Floor 1 │          │ Floor 10│          │ Floor 20│
    │ 2× TBR  │          │ 2× TBR  │          │ 2× TBR  │
    └────┬────┘          └────┬────┘          └────┬────┘
         │                    │                    │
    ┌────┴────┐          ┌────┴────┐          ┌────┴────┐
    │Mesh of  │          │Mesh of  │          │Mesh of  │
    │~135 nodes│         │~135 nodes│         │~135 nodes│
    └─────────┘          └─────────┘          └─────────┘

Per-Floor Deployment:

  • 2 Thread Border Routers (TBR) per floor for redundancy = 40 TBRs
  • ~135 sensors per floor (2,750 total ÷ 20 floors)
  • Mesh routing through powered nodes (lighting controllers always powered)

Cost Breakdown:

  • Occupancy sensors (Thread): 2,000 units at $25 each = $50,000.
  • HVAC sensors (Thread): 500 units at $35 each = $17,500.
  • Lighting controllers (Thread): 200 units at $40 each = $8,000.
  • Elevator and door sensors: 50 units at $45 each = $2,250.
  • Thread border routers: 40 units at $150 each = $6,000.
  • Building management server: 1 unit at $3,000 = $3,000.
  • Installation labor: $30,000.
  • Contingency (15%): $17,513.
  • Total: $134,263.

Under budget by $15,737 ✅

Concrete Penetration Strategy:

  1. Mesh density: 135 nodes per floor creates multiple paths through/around walls
  2. Powered routing nodes: 200 lighting controllers (always on) serve as mesh routers
  3. Border router placement: 2 per floor at opposite ends for coverage
  4. Stairwell strategy: Place sensors near stairwells for inter-floor communication
  5. Elevator shafts: Use as vertical communication conduits

Why Thread over Zigbee?

  • IP-native: Direct connection to IT systems without translation
  • No coordinator SPOF: Multiple border routers, no single failure point
  • Matter compatibility: Future-proof for new devices
  • Same power consumption: Both use 802.15.4 radio

Implementation Phases:

  1. Pilot (Month 1-2): Deploy on 2 floors, validate coverage
  2. Rollout (Month 3-6): 3-4 floors per month
  3. Optimization (Month 7): Adjust mesh, add routers if needed

Let’s calculate 5-year Total Cost of Ownership for a 5,000-sensor smart parking deployment, including often-overlooked costs that drastically change protocol selection.

Scenario: 5,000 parking sensors across 2 km² downtown area, 20-byte status every 5 minutes.

Interactive TCO Calculator:

Protocol Comparison: LoRaWAN vs NB-IoT vs Wi-Fi Mesh

LoRaWAN Costs:

  • Hardware: 5,000 sensors × $15 = $75,000.
  • Gateways: 4 units × $1,500 = $6,000.
  • Gateway installation: 4 × $500 = $2,000.
  • Network server: self-hosted ChirpStack VPS at $20/month for 60 months = $1,200.
  • Data transfer: $0 through gateway-to-server fiber.
  • Ongoing subscriptions: $0 per device.
  • Battery replacement: $0 within the 5-year window.
  • Gateway maintenance: 4 gateways × $200/year × 5 = $4,000.
  • Total: $88,200.
  • Per sensor: $17.64.

NB-IoT Costs:

  • Hardware: 5,000 sensors × $20 = $100,000.
  • Carrier activation: 5,000 × $5 = $25,000.
  • Monthly subscription: 5,000 devices × $2/month × 60 months = $600,000.
  • Data overage: $0 on the chosen plan.
  • Battery replacement: 5,000 devices × ($3 labor + $2 battery) = $25,000.
  • SIM management: 5,000 SIMs × $0.10/month × 60 = $30,000.
  • Total: $780,000.
  • Per sensor: $156.

Wi-Fi Mesh Costs:

  • Hardware: 5,000 ESP32 sensors × $12 = $60,000.
  • Mesh access points: 50 units × $200 = $10,000.
  • AP installation: 50 × $300 = $15,000.
  • Fiber backhaul: 20 distribution points × $2,000 = $40,000.
  • Network management: UniFi controller at $50/month for 60 months = $3,000.
  • Battery replacement: 5,000 devices × $5 every 6 months for 10 cycles = $250,000.
  • Electricity for APs: $13,140.
  • Total: $391,140.
  • Per sensor: $78.23.

Hidden Costs Exposed:

  1. Battery Replacement Dominates Wi-Fi: $250K battery costs (64% of total) make Wi-Fi uneconomical despite cheap hardware.

  2. NB-IoT Subscriptions Compound: $600K in subscriptions (77% of total) over 5 years far exceeds initial $100K hardware cost. After 10 years: $1.3M total.

  3. LoRaWAN Upfront Investment Pays Off: $88K upfront seems expensive vs NB-IoT’s $125K year-1 cost, but no recurring fees = $692K savings over 5 years.

  4. Scale Sensitivity:

    • 500 sensors: NB-IoT $78K, LoRaWAN $58K (only $20K difference)
    • 5,000 sensors: NB-IoT $780K, LoRaWAN $88K (10× difference)
    • LoRaWAN infrastructure cost is fixed; subscriptions scale linearly.

Non-Monetary Costs:

  • Vendor lock-in: LoRaWAN uses an open standard; NB-IoT depends on the carrier; Wi-Fi mesh depends on the equipment vendor.
  • Coverage control: LoRaWAN and Wi-Fi mesh stay under your control; NB-IoT depends on carrier coverage.
  • Data sovereignty: LoRaWAN and Wi-Fi mesh keep data on your infrastructure; NB-IoT routes through carrier networks.
  • Scalability: LoRaWAN scales without per-device fees; NB-IoT scales with recurring subscriptions; Wi-Fi mesh scales until AP capacity limits appear.
  • Maintenance windows: LoRaWAN and Wi-Fi mesh follow your schedule; NB-IoT inherits carrier outage windows.

Winner: LoRaWAN at $17.64 per sensor (5-year TCO), 88% cheaper than NB-IoT, 78% cheaper than Wi-Fi Mesh.

Key Lesson: Always calculate 5-year TCO including batteries, subscriptions, maintenance, and hidden costs like SIM management fees. Protocol selection based on hardware cost alone leads to costly surprises.

39.9 Concept Relationships

This chapter demonstrates protocol selection principles through real-world scenarios:

  • Protocol Selection Framework: These scenarios apply the systematic methodology. See Protocol Selection Framework.
  • Anti-Patterns: The worked examples show what happens when constraint-based selection is ignored. See Anti-Patterns.
  • Engineering Trade-offs: The scenarios demonstrate how physics and economics drive protocol choices. See The Challenge.
  • 5-Year TCO Calculation: The smart parking example shows the financial comparison method. See Worked Example: Smart Parking TCO.
  • Multi-Protocol Systems: The fleet example shows when one protocol is not enough. See Scenario 3: Fleet Tracking.
  • LoRaWAN Deployment: Smart city parking and agriculture both rely on long-range owned infrastructure. See LoRaWAN Overview.
  • Cellular IoT: NB-IoT and LTE-M matter most in fleet tracking. See Cellular IoT.
  • BLE for Wearables: The medical monitor scenario depends on phone-native, low-power connectivity. See BLE Fundamentals.
  • Thread/Matter: The retrofit scenario depends on mesh networking around concrete and steel. See Thread Architecture.

Common Pitfalls

Teams often try to force a familiar radio into a new deployment: Wi-Fi for a coin-cell wearable, LoRaWAN for a concrete-filled building, or cellular for a parking network with thousands of recurring subscriptions. Start from the current scenario’s hard constraints every time, because range, power, phone compatibility, and infrastructure ownership change the answer.

The cheapest radio module is not always the cheapest deployment. Smart parking showed why: NB-IoT hardware looked reasonable until subscriptions, SIM operations, and battery replacements were added. Always price infrastructure, recurring service fees, maintenance labor, and replacements across the full deployment life.

The hard failures usually happen where conditions change: containers move from ocean to port, sensors disappear into underground parking bays, or signals hit concrete elevator cores. Validate the ugly parts of the deployment explicitly, and accept when the right answer is a multi-protocol architecture instead of a single “winner.”

39.10 Summary

Key Takeaways:

  • Smart City: LoRaWAN wins for large-scale deployments with infrastructure ownership and no recurring fees
  • Wearables: BLE is the only practical choice for phone-connected, coin-cell-powered medical devices
  • Global Logistics: Multi-protocol (Satellite + Cellular + Wi-Fi) is necessary for true global coverage
  • Building Retrofit: Mesh protocols (Thread/Zigbee) handle RF challenges in dense environments
  • TCO Analysis: Always calculate 5-year costs including infrastructure, subscriptions, and maintenance
  • Edge Cases: Underground, maritime, and concrete buildings require special consideration

39.10.2 Order the Protocol Selection Steps

39.11 See Also

Protocol Selection Series:

Application-Specific Guides:

Protocol Deep Dives:

39.12 What’s Next

You have completed the Protocol Selection Framework series. The table below connects this chapter to related topics you can explore next.