84 Protocol Selection: Real-World Scenarios

84.1 Learning Objectives

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

Apply Framework to Real Scenarios: Work through complete protocol selection decisions
Calculate TCO: Perform total cost of ownership analysis for 5+ year deployments
Handle Multi-Protocol Systems: Design systems using different protocols for different needs
Consider Edge Cases: Address challenging environments like underground, maritime, and building interiors

Related Chapters

This Chapter Series: - Protocol Selection Framework - Overview and index - The Challenge - Understanding trade-offs - Systematic Selection - Step-by-step framework - Anti-Patterns and Tradeoffs - Common mistakes

Application Domains: - Application Domains - Requirements by domain - IoT Use Cases - Industry examples

84.2 Scenario 1: Smart City Parking System

Scenario Details

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.

Question: Based on the cost assumptions in the worked solution, which protocol has the lowest 5-year per-sensor TCO for the parking deployment?

💡 Explanation: A. The solution estimates LoRaWAN at ~$16.60/sensor over 5 years, lower than Sigfox (~$27.50) and NB-IoT (~$35).

Answer

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:

Protocol	Per-Sensor Cost	Budget Fit?
LoRaWAN	$16.60	✅ Yes
Sigfox	$27.50	✅ Yes
NB-IoT	$35.00	✅ Yes

But cost isn’t everything - feature comparison:

Feature	LoRaWAN	Sigfox	NB-IoT
Underground garage	✅ Good (SF12)	⚠️ Marginal	✅ Excellent
Message frequency	✅ No hard limit	❌ 140/day max	✅ Unlimited
30-sec update	✅ Achievable	⚠️ Barely (queue delay)	✅ Yes
Downlink (config)	✅ 8/day	❌ 4/day	✅ Unlimited
Vendor lock-in	✅ None	⚠️ Sigfox network	⚠️ Carrier
Battery life	✅ 10+ years	✅ 10+ years	⚠️ 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

84.3 Scenario 2: Wearable Health Monitor

Scenario Details

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.

Question: Which protocol is the best fit for an on-body medical sensor that talks directly to a smartphone with low latency and coin-cell power?

💡 Explanation: A. BLE is natively supported by phones, is optimized for low power, and supports low-latency connected alerts.

Answer

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:

Activity	Current	Duration	Frequency	Daily Energy
Sleep	1 µA	23.9 hours	Continuous	23.9 µAh
Wake + Measure	5 mA	50 ms	288/day	0.02 mAh
BLE TX (5 min data)	15 mA	10 ms	288/day	0.04 mAh
BLE TX (alerts)	15 mA	50 ms	~5/day	0.004 mAh
Daily Total				~24 µAh + 0.06 mAh = 0.08 mAh

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

84.4 Scenario 3: Fleet Tracking Across Three Continents

Scenario Details

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.

Question: During ocean transit (30+ days with no cellular coverage), what is the recommended primary connectivity option?

💡 Explanation: C. Satellite is the only option that provides global coverage over ocean routes where terrestrial networks are unavailable.

Answer

Multi-Protocol Architecture:

Scenario	Primary Protocol	Backup Protocol	Justification
Ocean Transit	Satellite (Iridium SBD)	GPS logging only	No cellular at sea
Port/Truck	LTE-M / NB-IoT	Satellite	Best coverage, bidirectional
Warehouse	Wi-Fi	LTE-M	Free, high bandwidth for 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):

Activity	Power	Frequency	3-Year Energy
GPS fix	30 mA × 30s	4/day	2.4 Ah
Iridium TX	1.5A × 20s	4/day (30 days/year)	1.0 Ah
LTE-M TX	0.5A × 5s	4/day (200 days/year)	1.1 Ah
Wi-Fi TX	0.2A × 10s	4/day (135 days/year)	0.3 Ah
Sleep (PSM)	10 µA	99.9% of time	0.3 Ah
Total			~5.1 Ah

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

Cost Analysis (per container, 3 years):

Component	Cost
Hardware	$150
Iridium (90 ocean days/year × 3 years × 4 msgs × $0.10)	$108
LTE-M ($4/month × 12 months × 3 years)	$144
Total 3-year TCO	$402/container

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

84.5 Scenario 4: Smart Building Retrofit

Scenario Details

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?

Question: Given “no new wiring”, “concrete penetration”, and “no corporate Wi-Fi”, which approach best matches the recommended solution?

💡 Explanation: D. Mesh routing helps work around concrete attenuation, and Thread/Matter provides an IP-friendly, future-proof path without relying on corporate Wi-Fi.

Answer

Constraint Analysis:

Constraint	Impact on Selection
No new wiring	Battery-powered only, wireless
Concrete/walls	Need mesh or multiple gateways per floor
No corporate Wi-Fi	Separate network, or non-Wi-Fi protocol
Budget $150K	Must be cost-effective at 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:

Component	Quantity	Unit Cost	Total
Occupancy sensors (Thread)	2,000	$25	$50,000
HVAC sensors (Thread)	500	$35	$17,500
Lighting controllers (Thread)	200	$40	$8,000
Elevator/door sensors	50	$45	$2,250
Thread Border Routers	40	$150	$6,000
Building management server	1	$3,000	$3,000
Installation labor	-	-	$30,000
Contingency (15%)	-	-	$17,513
Total			$134,263

Under budget by $15,737 ✅

Concrete Penetration Strategy:

Mesh density: 135 nodes per floor creates multiple paths through/around walls
Powered routing nodes: 200 lighting controllers (always on) serve as mesh routers
Border router placement: 2 per floor at opposite ends for coverage
Stairwell strategy: Place sensors near stairwells for inter-floor communication
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:

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

84.6 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

84.7 What’s Next

You’ve now completed the Protocol Selection Framework series. Return to the main overview for additional resources, or continue to Sensor to Network Pipeline to learn how data flows through the protocols you’ve selected.

Return to Framework Overview →

Continue to Sensor to Network Pipeline →

84.8 Visual Reference Gallery

The following AI-generated figures provide alternative visual perspectives on protocol selection concepts covered in this chapter series.

Protocol Stack Comparison (Alternative View)

Geometric side-by-side comparison of major IoT protocol stacks including Wi-Fi/TCP/IP, BLE, Zigbee, LoRaWAN, and NB-IoT, showing layers from physical through application with key characteristics like range, power, and data rate for each

IoT Protocol Stack Comparison

Different IoT protocols organize their functionality into distinct layer stacks. This visualization compares the major protocol families side-by-side: Wi-Fi/TCP/IP (high bandwidth, high power), BLE (short range, low power), Zigbee (mesh networking, moderate range), LoRaWAN (long range, very low power), and NB-IoT (cellular infrastructure, wide coverage). Understanding these stacks helps engineers select the right protocol for their application requirements and anticipate interoperability challenges when bridging between protocol domains.

Protocol Trade-off Visualization (Alternative View)

Geometric diagram showing the key trade-offs in protocol selection: range versus power consumption, bandwidth versus latency, infrastructure cost versus subscription fees, with IoT protocols positioned along each axis

Protocol Selection Trade-offs

Protocol selection involves navigating multiple trade-off dimensions simultaneously. This visualization maps common IoT protocols across the key decision axes: Wi-Fi offers high bandwidth but high power consumption, LoRaWAN provides extreme range at the cost of limited data rates, BLE balances power efficiency with short range, and cellular IoT (NB-IoT/LTE-M) trades subscription costs for wide coverage without deploying infrastructure. No protocol excels in all dimensions, making application requirements the primary driver of selection.

Wireless Technology Evolution (Alternative View)

Mermaid diagram showing the evolution of wireless technologies from early 2G cellular through Wi-Fi generations, Bluetooth versions, and the emergence of IoT-specific protocols like LoRaWAN, Sigfox, and NB-IoT, with arrows indicating technology lineages

Wireless Protocol Evolution Timeline

Understanding protocol evolution helps predict future directions and assess technology maturity. This timeline shows how IoT protocols emerged from different technology families: cellular IoT (NB-IoT, LTE-M, 5G RedCap) evolved from mobile networks, LPWAN protocols (LoRaWAN, Sigfox) emerged to fill the long-range/low-power gap, and mesh protocols (Zigbee, Thread, Matter) developed from home automation needs. Recognizing these lineages helps engineers evaluate ecosystem maturity and vendor commitment.