38 Protocol Selector Wizard
38.1 In 60 Seconds
38.1.1 Eliminate Bad Fits Before Ranking
A field monitor must report a water level for two years on one battery. It sits behind a stone wall and has no nearby mains power. The project meeting begins with a favourite technology, but the site has already set the real rules. A choice that fails range or energy cannot be rescued by a high score elsewhere.
Write the hard limits first. State the distance, wall and ground conditions, message size, acceptable delay, update rate, power source, local equipment, service cost, and who will maintain the link. Mark each limit as fixed or negotiable. Reject any option that misses a fixed limit before giving points for convenience or team experience.
Test the two best survivors at the real site. Try the basement, field edge, wet weather, busy hour, and a dead zone. Measure delivery delay and energy at the device. Remove local equipment and restore it. Check how missed and repeated readings appear to the operator. Keep the losing result and its reason in the decision record.
The wizard narrows a choice; it cannot certify coverage or battery life from catalogue values. The deeper sections compare range, power, capacity, cost, and security, then show weighted scoring and field checks. A future reviewer should be able to repeat the assumptions and reopen the choice when the site changes.
Selecting the right IoT protocol means matching your project’s range, power, bandwidth, latency, and cost requirements to one of 14+ wireless technologies. No single protocol is “best” — the optimal choice depends on your specific constraints, and the most important first filter is usually range (short vs. long) followed by power budget (battery years vs. mains-powered).
38.2 Start With the Story
You will use the wizard to narrow protocol options and record the assumptions that still need field testing. Start with your deployment’s range, power, payload, and operating constraints.
Follow the wizard across four beats to see how it structures evidence without replacing engineering validation.
-
Bex: “Start the wizard with the deployment, not the protocol name.”
-
Test Tessa: “Every constraint makes the recommendation more specific and auditable.”
-
Packet Pete: “The wizard filters; the evidence still decides between survivors.”
-
The team: “A recommendation becomes a decision only after the field check.”
The mathematical gist. The chapter’s mAh assumption becomes Wh only after a named 3.7 V chemistry assumption. Its mA burst causes just mV sag in the stated model, but a catalog-typical monthly self-discharge averages mAh/day—about the chapter’s mAh/day radio load—so the solar path must cover more than radio use.
38.3 Protocol Selector Wizard
Treat the Protocol Selector Wizard as an ordered review rather than a scoring shortcut. Begin by writing the non-negotiable constraints: required range, power source, payload, latency, infrastructure, and operating cost. Eliminate candidates that cannot satisfy those boundaries before assigning weights to the remaining trade-offs. Then compare the finalists with measured battery, coverage, capacity, and fee evidence, and record why the preferred option and fallback survived. The score supports the decision; it does not replace field validation. That sequence keeps the wizard connected to the chapter’s running argument: a protocol choice is defensible only when another reviewer can reproduce its assumptions, evidence, rejected alternatives, and recheck triggers.
By using this interactive tool, you will be able to:
- Systematically evaluate IoT protocol options against your project requirements using weighted scoring criteria
- Analyse trade-offs between range, power, bandwidth, latency, and cost for competing protocol families
- Select and justify a connectivity stack for a given IoT deployment scenario with quantitative reasoning
- Compare protocols side-by-side by mapping detailed technical specifications to application constraints
- Apply decision frameworks (flowcharts, constraint elimination, multi-factor scoring) to narrow 14+ candidates to 2-3 finalists
- Calculate battery-life projections for candidate protocols to validate power-budget feasibility
38.4 Key Concepts
- Constraint-first filtering: Start with hard limits such as range, power source, latency ceiling, payload size, and whether any infrastructure already exists
- Elimination before scoring: Remove protocols that fail must-have requirements before comparing finer trade-offs
- Weighted scoring: Rank the remaining candidates by assigning importance to range, power, bandwidth, latency, and cost
- Numbers beat intuition: Battery budget, gateway count, and recurring fees often overturn a protocol that only sounds right in theory
- Rationale matters: A strong selection rationale explains why finalists were chosen and why others were rejected
- No universal winner: The best protocol is the one that fits this deployment, not the one with the strongest headline specification
Quick Check: Wizard Limits
38.5 Prerequisites
Before using this wizard, you should understand:
- Protocol Selection Framework: Basic understanding of protocol categories and selection constraints
- Networking Basics: Fundamental networking concepts
Simple Analogy: Choosing a Vehicle
Selecting an IoT protocol is like choosing transportation for a journey:
- Cross the room: Walk -> NFC (< 10cm)
- Across town: Bicycle/Car -> Bluetooth/Wi-Fi
- Cross country: Airplane -> LoRaWAN/Cellular
- Move furniture: Truck -> Wi-Fi (high bandwidth)
- Save fuel: Hybrid/Electric -> LPWAN (low power)
Key Trade-offs to Understand:
- Long range = Lower speed: Like a marathon runner vs. sprinter
- Low power = Limited features: Like economy vs. luxury car
- High bandwidth = More power: Like sports car fuel consumption
- Reliability = More overhead: Like insurance - costs more but protects you
38.6 Tool Components
This Protocol Selector Wizard suite includes three specialized tools to help you make the best protocol choice for your IoT project:
Evidence for Tool Components starts at Figure 38.1 with Input Record. Contrast Capture deployment, device, payload, and ops against it to make Use the wizard flow as an evidence checklist, not just a scoring form reviewable rather than assumed.
Read Figure 38.1 downward from the boundary and input record to the hard filters, which remove options lacking required evidence. Compare the surviving lanes, then plan validation before recording the recommendation and fallback.
Use the wizard flow as an evidence checklist, not just a scoring form. The boundary and input record define the decision; hard filters remove protocols that cannot meet required evidence; the validation plan turns close finalists into site tests; and the recommendation record preserves the primary choice, fallback, risks, and review triggers.
38.6.1 Interactive Selection Wizard
Use the step-by-step wizard to input your requirements and receive personalized protocol recommendations based on 14 protocols across short-range, LPWAN, cellular, and wired categories.
Use the protocol selection workbench
- 5-step requirements gathering
- Multi-factor scoring algorithm
- Side-by-side protocol comparison
- Detailed recommendations with explanations
38.6.2 Decision Framework Reference
Explore visual decision trees and reference matrices to quickly narrow down protocol options based on key constraints like range, power, and bandwidth.
- Interactive flowcharts
- Scenario-to-protocol mapping
- Power/range matrix views
- Quick reference tables
38.6.3 Protocol Matching Game
Test and reinforce your protocol knowledge through an interactive game matching real-world IoT scenarios to the best protocols.
- 24 real-world scenarios
- Three difficulty levels
- Detailed explanations
- Performance tracking
38.7 Quick Decision Guide
| If you need… | And also need… | Consider… |
|---|---|---|
| Long range (km) | Battery (years) | LoRaWAN, Sigfox, NB-IoT |
| Long range (km) | Low latency | LTE-M, 5G |
| Short range (m) | High bandwidth | Wi-Fi |
| Short range (m) | Battery life | BLE, Zigbee, Thread |
| Mesh networking | Low power | Zigbee, Thread |
| Mesh networking | IP-native | Thread |
| Touch range | Instant | NFC |
| No battery | Tracking | UHF RFID |
Quick Check: Apply the Decision Guide
38.8 Put Numbers to the Decision
A practical protocol decision model uses weighted scoring:
where is a normalized rating (0 to 1) for each criterion (range, power, bandwidth, latency, cost).
Worked example: For a battery-first outdoor project, use weights:
- Range = 0.30
- Power = 0.30
- Bandwidth = 0.15
- Latency = 0.15
- Cost = 0.10
Using representative ratings (normalized 0-1):
- LoRaWAN ratings: Range 1.0, Power 0.95, Bandwidth 0.20, Latency 0.40, Cost 0.80
- Wi-Fi ratings: Range 0.30, Power 0.20, Bandwidth 1.0, Latency 0.90, Cost 0.60
The 0.26 score gap quantifies why LoRaWAN is favored for long-life telemetry even though Wi-Fi wins on raw bandwidth.
Interactive Protocol Scoring Calculator:
38.9 Worked Example: Use the Decision Guide for a Real Project
-
List the hive range, power, traffic, cost, and wooden-box limits.
-
Remove choices that fail a real project limit.
-
Pilot the survivors across the farm before choosing one.
Let’s apply the quick decision guide to a concrete scenario: smart beehive monitoring.
Project Requirements:
- Monitor temperature + humidity inside 50 beehives
- Hives spread across 2-hectare farm (200m max distance)
- Solar panel + battery (no mains power)
- 1 reading per hour (24 readings/day)
- Low cost (<$30 per hive sensor)
- Must work through wooden hive boxes
Step 1: Use Quick Decision Guide
- Range needed: 200m max from collection point. Implication: short-to-medium range (not km-scale).
- Power source: Solar + battery. Implication: need low power, but not ultra-low because solar recharges the battery.
- Data volume: 12 bytes/hour (temperature, humidity, battery). Implication: very low bandwidth requirement.
- Latency sensitivity: No, hourly data is fine. Implication: not real-time critical.
- Infrastructure: Farm has Wi-Fi in the barn (100m away). Implication: existing Wi-Fi could help, but only near the barn.
Step 2: Apply Quick Guide Rules
From table: “Short range (m) + Battery life” → Consider: BLE, Zigbee, Thread
But wait — 200m exceeds BLE range (10-50m) and typical Zigbee/Thread range (10-100m). Let’s reconsider.
Alternative from table: “Long range (km) + Battery (years)” → Consider: LoRaWAN, Sigfox, NB-IoT
But 200m is overkill for LPWAN. We’re in the awkward middle ground.
Step 3: Consider Hybrid / Mesh Solutions
Option A: Wi-Fi with Sleep Modes
- Barn Wi-Fi reaches ~50m
- Need 4 Wi-Fi repeaters to cover 200m = $160 + installation
- ESP32 with deep sleep: ~5mA TX current × 10s per hour = 0.014 mAh/transmission × 24 = 0.33 mAh/day (active), plus 0.15mA × 24h deep sleep = 3.6 mAh/day (sleep) = 3.93 mAh/day total
- 2000 mAh battery + 1W solar = works even in winter
- Cost: $15 ESP32 + $10 solar/battery = $25/hive (within budget)
Option B: LoRaWAN
- 1 gateway at barn covers entire 2-hectare farm easily
- LoRa module $12 + MCU $3 = $15 hardware
- Gateway $500 (one-time) ÷ 50 hives = $10/hive amortized
- Battery: ~6mA TX current (20mW @ 3.3V) × 2s per hour = 0.0033 mAh/transmission × 24 = 0.08 mAh/day (TX), plus 0.0015mA × 24h sleep = 0.036 mAh/day (sleep) = ~0.12 mAh/day total (10+ year battery life)
- Cost: $15 hardware + $10 gateway share + $10 solar/battery = $35/hive (over budget)
Option C: Zigbee Mesh
- Mesh routing: each hive relays for others
- Avg 4 hops to reach barn (50m per hop × 4 = 200m)
- Zigbee module $8 + MCU $3 = $11 hardware
- Mesh coordinator at barn $25 (one-time) ÷ 50 hives = $0.50/hive amortized
- Battery: Own TX ~9mA (30mW @ 3.3V) × 100 ms × 24/day = 0.006 mAh/day, plus relay for ~4 neighbours × 24/day × 100 ms = 0.024 mAh/day, plus sleep 0.003mA × 24h = 0.072 mAh/day = ~0.10 mAh/day total (5+ year life with solar)
- Cost: $11 hardware + $0.50 coordinator share + $8 solar/battery = $19.50/hive (within budget)
Decision: Zigbee Mesh
Justification:
- Under $30 budget
- 200m covered via 4-hop mesh
- Wooden hive boxes allow signal penetration better than concrete
- Solar + battery handles ~0.10 mAh/day consumption (compared to 3.93 mAh/day for Wi-Fi)
- Mesh provides redundancy (if one hive fails, others route around it)
- No recurring costs (unlike NB-IoT)
Key Lesson: The “quick decision guide” gives you starting points, but real projects require working through the numbers. 200m is an awkward “tweener” distance — too far for simple BLE/Zigbee, overkill for LPWAN. Mesh networking solved the challenge by turning short-range radios into long-range systems through multi-hop routing.
Interactive Battery Life Comparison:
38.10 Common Pitfalls
Relying on theoretical models without profiling actual behavior leads to designs that miss performance targets by 2-10×. Always measure the dominant bottleneck in your specific deployment environment — hardware variability, interference, and load patterns routinely differ from textbook assumptions.
Optimizing one parameter in isolation (latency, throughput, energy) without considering impact on others creates systems that excel on benchmarks but fail in production. Document the top three trade-offs before finalizing any design decision and verify with realistic workloads.
Most field failures come from edge cases that work in the lab: intermittent connectivity, partial node failure, clock drift, and buffer overflow under peak load. Explicitly design and test failure handling before deployment — retrofitting error recovery after deployment costs 5-10× more than building it in.
38.11 Practice the Selection Workflow
Label the Diagram
Code Challenge
Knowledge Check
38.12 Scenario Requirements Move the Protocol Answer
The best way to internalize protocol selection is to run the same method on concrete scenarios and watch the answer change with the requirements. A selector wizard asks about range, payload, power, latency, topology, mobility, and operations, then steers toward the technology whose compromises fit.
Four everyday IoT scenarios - a utility meter, a fitness wearable, a security camera, and a building sensor mesh - land on four different radios. The reasons are more useful than the names of the winners.
A responsible wizard uses two passes. First it applies hard filters: a 10 km meter route rules out BLE, while a video camera rules out very-low-rate LPWAN links. Then it scores the survivors on softer trade-offs such as gateway cost, operator skill, certification burden, roaming support, and security operations. This ordering matters because weighted scoring can hide a fatal constraint if a failed candidate keeps competing.
For example, a school asset tag, a cold-chain pallet tracker, and a pump-room vibration sensor may all send small payloads, but the deployment evidence differs. The school tag can assume phones or readers nearby, the pallet may cross carrier coverage zones, and the pump-room sensor may sit behind concrete and electrical noise. The wizard is useful when it makes those assumptions visible before anyone argues about a favorite protocol.
The exercise is to hold the method fixed and change the scenario. The requirements move the answer: meter, wearable, camera, and mesh each pick a different protocol for good reasons.
38.12.1 Four Scenarios, Four Answers
| Scenario | Dominant needs | Fitting protocol |
|---|---|---|
| City utility meter | Kilometre range, years of battery life, tiny hourly reads, no site build | NB-IoT or LoRaWAN |
| Fitness wearable | Short range to a phone, low power, modest data | BLE |
| Security camera | High data rate for video, mains power, in-building coverage | Wi-Fi |
| Building sensor mesh | Many nodes, low power, self-healing coverage | Zigbee or Thread over IEEE 802.15.4 |
The wearable and the meter show why one shared requirement is not enough. Both want low power, yet they diverge. The wearable talks a few metres to a nearby phone and syncs modest data, so BLE is ideal: low power, phone-native, and intentionally short range. The meter must reach a distant tower with no local phone or gateway, so it needs an LPWAN; BLE would be useless there. Same low-power pressure, opposite range requirement, opposite answer.
Practitioners should record the first rejecting constraint for each discarded protocol. For the city meter, Wi-Fi might fail on coverage and mains dependence before cost is even scored; BLE fails on range; LTE-M may remain a finalist if the utility accepts subscription cost and coverage checks. For the wearable, those same cellular subscription and kilometre-range strengths are liabilities because the device can use the phone as its gateway and must preserve a very small battery.
When the top two choices are close, the wizard output should become a test plan rather than a vote. A team comparing Thread and Zigbee for a building mesh can prototype join time, route repair after a powered-off router, packet delivery through stairwells, and commissioning support in the target mobile app. The protocol with the best field evidence should win even if the spreadsheet score was almost tied. Record the test result beside the score so reviewers can see whether the recommendation came from measured behavior or unchecked preference.
38.12.2 Record the Deciding Requirement
Across the four scenarios, a single requirement usually forces the answer. For the camera it is data rate: video needs Mbit/s throughput, which Wi-Fi or cellular can supply, so mains power is accepted. For the meter it is range without local infrastructure. For the mesh it is node count and self-healing coverage, which favors a mesh-native IEEE 802.15.4 stack over point-to-point links. The wizard’s real job is to surface that deciding requirement and not be distracted by the others.
The cautionary pattern is a requirement that quietly rules out the obvious pick. A building sensor mesh could use Wi-Fi until you count hundreds of battery nodes needing self-healing coverage through walls, at which point Wi-Fi’s power draw and star topology make Zigbee or Thread the better fit. Good selection means finding the constraint that breaks the tempting but wrong option.
A team might default to Wi-Fi for a 300-node building sensor deployment because it is familiar. The deciding requirements - multi-year batteries and reliable coverage through interior walls with hundreds of nodes - expose the mismatch: Wi-Fi’s high power and star topology fail both. A Thread or Zigbee mesh, where nodes relay for each other at low power, meets them. The scenario turned on one dominant constraint, and recognizing it is the whole skill.
Under the hood, the selector should keep hard constraints separate from preference weights. A protocol that cannot meet the range, payload, duty-cycle, roaming, or battery requirement should be removed before scoring; otherwise a high score in cost or developer familiarity can mask a non-deployable design. After filtering, the remaining candidates can be ranked with weights, sensitivity checks, and documented assumptions such as gateway density, firmware-update path, certificate handling, and operator monitoring.
The final decision should preserve rejected options, not only the winner. A record saying “Thread selected; Wi-Fi rejected for battery and topology; LoRaWAN rejected for local gateway ownership and latency” gives future maintainers a way to revisit the choice when the deployment changes. That record is also what turns the wizard from a classroom picker into an engineering tool.
38.13 Summary
The Protocol Selector Wizard suite helps you systematically evaluate IoT connectivity options:
- 14 protocols analyzed across short-range, LPWAN, cellular, and wired categories
- Multi-factor scoring considers range, power, bandwidth, latency, cost, and security
- Personalized recommendations based on your specific requirements
- Interactive learning through decision frameworks and matching games
- Deep dive links to detailed protocol chapters
- No “best” protocol exists - only best fit for your requirements
- Trade-offs are inevitable - long range usually means lower bandwidth
- Start with constraints - power and range typically narrow options quickly
- Consider total cost - include infrastructure, recurring fees, and maintenance
- Plan for scale - choose protocols that grow with your deployment
Temperature Terry needed to send a message to the cloud, but couldn’t figure out which delivery service to use!
“I could use Bluetooth Buddy — he’s super fast but only delivers next door,” Sammy said.
the LED blinked excitedly. “What about LoRa Larry? He walks slowly but delivers across the whole city!”
the microcontroller scratched his head. “It depends on what you’re sending! A tiny temperature reading? LoRa Larry is perfect. A video? You need Wi-Fi Wanda — she carries big packages but needs lots of energy!”
the battery groaned. “Don’t pick Wi-Fi Wanda too often — she drains my energy fast! For small messages sent once an hour, LoRa Larry barely sips any power.”
The lesson: Picking the right protocol is like choosing the right delivery service — you match the distance, package size, and energy budget to find the perfect fit!
38.14 Knowledge Check
Knowledge Check: Protocol Selection Reasoning
38.14.1 Match the Scenario to the Protocol
Drag each IoT deployment scenario to the protocol family that best fits its constraints.
38.14.2 Order the Protocol Selection Process
Arrange the steps of the weighted-scoring protocol selection method in the correct sequence.
38.15 Concept Relationships: Protocol Selection Wizard
| Concept | Relates To | Relationship |
|---|---|---|
| Protocol Selection Wizard | Requirements Matrix | The wizard automates the systematic requirements-to-protocol matching process |
| Decision Framework | Protocol Comparison | Frameworks reduce 14+ candidate protocols to 2-3 finalists via constraint elimination |
| Trade-offs | Range/Power/Bandwidth | Every protocol optimizes for specific dimensions at the expense of others |
Cross-module connection: This connects to System Architecture Design via protocol capabilities determining architecture options. See IoT Reference Models.
38.16 See Also
- Protocol Selection Framework — Systematic three-step process for protocol selection
- LPWAN Fundamentals — Compare LPWAN protocol specifications
- Core Topology Shapes — How protocol choices constrain topology options
38.17 What’s Next
- Selection Workbench: IoT Protocol Selection Workbench - Try the scenario flowchart and record a defensible shortlist.
- Decision Frameworks: Systematic Selection - Study constraint-elimination matrices used by professional IoT architects.
- Scenario Practice: Selection Scenarios - Reinforce protocol-to-scenario mapping through worked cases.
- Architecture Planner: Architecture Planner - Translate your protocol choice into a complete system architecture.
- LPWAN Deep Dive: LPWAN Fundamentals - Compare LoRaWAN, Sigfox, and NB-IoT specifications side-by-side.
- Network Topologies: Core Topology Shapes - Discover how your protocol choice constrains star, mesh, and tree topologies.