Interactive Decision Support Tool for IoT Protocol Selection
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).
By using this interactive tool, you will be able to:
Before using this wizard, you should understand:
Simple Analogy: Choosing a Vehicle
Selecting an IoT protocol is like choosing transportation for a journey:
| Journey Need | Vehicle Choice | IoT Equivalent |
|---|---|---|
| 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:
This Protocol Selector Wizard suite includes three specialized tools to help you make the best protocol choice for your IoT project:
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.
Launch Protocol Selection Wizard
Explore visual decision trees and reference matrices to quickly narrow down protocol options based on key constraints like range, power, and bandwidth.
Test and reinforce your protocol knowledge through an interactive game matching real-world IoT scenarios to the best protocols.
| 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 |
A farmer needs soil moisture data from sensors spread across 50 acres, sending one reading every 30 minutes on battery. Which protocol family is most appropriate?
C) LPWAN (LoRaWAN). The requirements – long range (50 acres), battery-powered, infrequent small readings – perfectly match LPWAN protocols. Wi-Fi lacks the range needed across 50 acres. BLE is limited to roughly 10-50 metres and cannot cover the farm. 5G would drain battery power far too quickly for simple periodic telemetry. Use the Quick Decision Guide row “Long range (km) + Battery (years)” to arrive at LoRaWAN/Sigfox/NB-IoT.
A practical protocol decision model uses weighted scoring:
\[ S = \sum_{i=1}^{n} w_i \cdot r_i,\quad \sum w_i = 1 \]
where \(r_i\) 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: \(w_{\text{range}}=0.30,\; w_{\text{power}}=0.30,\; w_{\text{bandwidth}}=0.15,\; w_{\text{latency}}=0.15,\; w_{\text{cost}}=0.10\).
Using representative ratings (normalized 0-1): - LoRaWAN: \((1.0,\;0.95,\;0.20,\;0.40,\;0.80)\) gives \(S_{\text{LoRaWAN}} = 0.30(1.0) + 0.30(0.95) + 0.15(0.20) + 0.15(0.40) + 0.10(0.80) = 0.755\) - Wi-Fi: \((0.30,\;0.20,\;1.0,\;0.90,\;0.60)\) gives \(S_{\text{Wi-Fi}} = 0.30(0.30) + 0.30(0.20) + 0.15(1.0) + 0.15(0.90) + 0.10(0.60) = 0.495\)
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:
viewof weight_range = Inputs.range([0, 1], {value: 0.30, step: 0.05, label: "Range weight"})
viewof weight_power = Inputs.range([0, 1], {value: 0.30, step: 0.05, label: "Power weight"})
viewof weight_bandwidth = Inputs.range([0, 1], {value: 0.15, step: 0.05, label: "Bandwidth weight"})
viewof weight_latency = Inputs.range([0, 1], {value: 0.15, step: 0.05, label: "Latency weight"})
viewof weight_cost = Inputs.range([0, 1], {value: 0.10, step: 0.05, label: "Cost weight"})protocols = [
{name: "LoRaWAN", range: 1.0, power: 0.95, bandwidth: 0.20, latency: 0.40, cost: 0.80},
{name: "Wi-Fi", range: 0.30, power: 0.20, bandwidth: 1.0, latency: 0.90, cost: 0.60},
{name: "BLE", range: 0.10, power: 0.85, bandwidth: 0.40, latency: 0.70, cost: 0.90},
{name: "Zigbee", range: 0.25, power: 0.80, bandwidth: 0.35, latency: 0.60, cost: 0.85},
{name: "NB-IoT", range: 1.0, power: 0.70, bandwidth: 0.25, latency: 0.50, cost: 0.50},
{name: "LTE-M", range: 1.0, power: 0.50, bandwidth: 0.60, latency: 0.85, cost: 0.40}
]
protocol_scores = protocols.map(p => ({
name: p.name,
score: (
weights_normalized.range * p.range +
weights_normalized.power * p.power +
weights_normalized.bandwidth * p.bandwidth +
weights_normalized.latency * p.latency +
weights_normalized.cost * p.cost
)
})).sort((a, b) => b.score - a.score)html`<div style="background: var(--bs-light, #f8f9fa); padding: 1rem; border-radius: 8px; border-left: 4px solid #2C3E50; margin-top: 0.5rem;">
<p><strong>Weight sum:</strong> ${weight_sum.toFixed(2)} ${weight_sum !== 1.0 ? '(auto-normalized to 1.0)' : '✓'}</p>
<p><strong>Normalized weights:</strong> Range=${weights_normalized.range.toFixed(2)}, Power=${weights_normalized.power.toFixed(2)}, BW=${weights_normalized.bandwidth.toFixed(2)}, Latency=${weights_normalized.latency.toFixed(2)}, Cost=${weights_normalized.cost.toFixed(2)}</p>
<hr style="margin: 0.5rem 0;">
<p><strong>Protocol Rankings:</strong></p>
<ol style="margin: 0.5rem 0; padding-left: 1.5rem;">
${protocol_scores.map(p => `<li><strong>${p.name}</strong>: ${p.score.toFixed(3)}</li>`).join('')}
</ol>
<p style="margin-top: 0.5rem;"><strong>Recommendation:</strong> ${protocol_scores[0].name} (score ${protocol_scores[0].score.toFixed(3)})</p>
</div>`Let’s apply the quick decision guide to a concrete scenario: smart beehive monitoring.
Project Requirements:
Step 1: Use Quick Decision Guide
| Question | Answer | Implications |
|---|---|---|
| Range needed? | 200m max from collection point | Short-to-medium range (not km-scale) |
| Power source? | Solar + battery | Need low power, but not ultra-low (solar recharges) |
| Data volume? | 12 bytes/hour (temp, humidity, battery) | Very low bandwidth requirement |
| Latency sensitivity? | No (hourly data is fine) | Not real-time critical |
| Infrastructure? | Farm has Wi-Fi in barn (100m away) | Could leverage existing Wi-Fi |
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
Option B: LoRaWAN
Option C: Zigbee Mesh
Decision: Zigbee Mesh
Justification:
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:
viewof battery_capacity = Inputs.range([500, 5000], {value: 2000, step: 100, label: "Battery capacity (mAh)"})
viewof readings_per_day = Inputs.range([1, 96], {value: 24, step: 1, label: "Reads per day"})
viewof tx_time_wifi = Inputs.range([1, 30], {value: 10, step: 1, label: "Wi-Fi TX time (s/read)"})
viewof tx_time_lora = Inputs.range([0.5, 10], {value: 2, step: 0.5, label: "LoRaWAN TX time (s/read)"})
viewof tx_time_zigbee = Inputs.range([0.05, 5], {value: 0.1, step: 0.05, label: "Zigbee TX time (s/read)"})battery_results = {
// Wi-Fi: 5mA TX, 0.15mA sleep
const wifi_tx_mah = (5 * tx_time_wifi / 3600) * readings_per_day;
const wifi_sleep_mah = 0.15 * 24;
const wifi_total = wifi_tx_mah + wifi_sleep_mah;
const wifi_days = battery_capacity / wifi_total;
// LoRaWAN: 20mW @ 3.3V = 6mA TX, 0.0015mA sleep
const lora_tx_mah = (6 * tx_time_lora / 3600) * readings_per_day;
const lora_sleep_mah = 0.0015 * 24;
const lora_total = lora_tx_mah + lora_sleep_mah;
const lora_days = battery_capacity / lora_total;
// Zigbee: 30mW @ 3.3V = 9mA TX, 0.003mA sleep, plus relay overhead
const zigbee_tx_mah = (9 * tx_time_zigbee / 3600) * readings_per_day;
const zigbee_relay_mah = (9 * tx_time_zigbee / 3600) * readings_per_day * 4; // 4 relays on average
const zigbee_sleep_mah = 0.003 * 24;
const zigbee_total = zigbee_tx_mah + zigbee_relay_mah + zigbee_sleep_mah;
const zigbee_days = battery_capacity / zigbee_total;
return {
wifi: {tx: wifi_tx_mah, sleep: wifi_sleep_mah, total: wifi_total, days: wifi_days},
lora: {tx: lora_tx_mah, sleep: lora_sleep_mah, total: lora_total, days: lora_days},
zigbee: {tx: zigbee_tx_mah, relay: zigbee_relay_mah, sleep: zigbee_sleep_mah, total: zigbee_total, days: zigbee_days}
};
}html`<div style="background: var(--bs-light, #f8f9fa); padding: 1rem; border-radius: 8px; border-left: 4px solid #16A085; margin-top: 0.5rem;">
<h4 style="margin-top: 0;">Battery Life Comparison (${battery_capacity} mAh battery)</h4>
<table style="width:100%; border-collapse:collapse; margin-top:0.5rem;">
<tr style="background: #2C3E50; color: white;">
<th style="padding:8px; border:1px solid #ddd;">Protocol</th>
<th style="padding:8px; border:1px solid #ddd;">Daily Consumption</th>
<th style="padding:8px; border:1px solid #ddd;">Battery Life</th>
</tr>
<tr>
<td style="padding:8px; border:1px solid #ddd;"><strong>Wi-Fi</strong></td>
<td style="padding:8px; border:1px solid #ddd;">${battery_results.wifi.total.toFixed(2)} mAh/day<br>(TX: ${battery_results.wifi.tx.toFixed(2)}, Sleep: ${battery_results.wifi.sleep.toFixed(2)})</td>
<td style="padding:8px; border:1px solid #ddd;"><strong>${battery_results.wifi.days.toFixed(0)} days</strong> (${(battery_results.wifi.days/365).toFixed(1)} years)</td>
</tr>
<tr style="background: #f0f0f0;">
<td style="padding:8px; border:1px solid #ddd;"><strong>LoRaWAN</strong></td>
<td style="padding:8px; border:1px solid #ddd;">${battery_results.lora.total.toFixed(2)} mAh/day<br>(TX: ${battery_results.lora.tx.toFixed(2)}, Sleep: ${battery_results.lora.sleep.toFixed(2)})</td>
<td style="padding:8px; border:1px solid #ddd;"><strong>${battery_results.lora.days.toFixed(0)} days</strong> (${(battery_results.lora.days/365).toFixed(1)} years)</td>
</tr>
<tr>
<td style="padding:8px; border:1px solid #ddd;"><strong>Zigbee Mesh</strong></td>
<td style="padding:8px; border:1px solid #ddd;">${battery_results.zigbee.total.toFixed(2)} mAh/day<br>(TX: ${battery_results.zigbee.tx.toFixed(2)}, Relay: ${battery_results.zigbee.relay.toFixed(2)}, Sleep: ${battery_results.zigbee.sleep.toFixed(2)})</td>
<td style="padding:8px; border:1px solid #ddd;"><strong>${battery_results.zigbee.days.toFixed(0)} days</strong> (${(battery_results.zigbee.days/365).toFixed(1)} years)</td>
</tr>
</table>
<p style="margin-top: 0.5rem; margin-bottom: 0;"><strong>Best choice:</strong> ${battery_results.lora.days > battery_results.wifi.days && battery_results.lora.days > battery_results.zigbee.days ? 'LoRaWAN' : battery_results.zigbee.days > battery_results.wifi.days ? 'Zigbee Mesh' : 'Wi-Fi'} (longest battery life)</p>
</div>`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.
The Protocol Selector Wizard suite helps you systematically evaluate IoT connectivity options:
Sammy the Sensor 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.
Lila the LED blinked excitedly. “What about LoRa Larry? He walks slowly but delivers across the whole city!”
Max 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!”
Bella 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!
Q1: Why is there no single “best” IoT protocol?
Q2: A smart building needs real-time occupancy video analytics from 20 cameras across 3 floors, all connected to mains power. Which protocol is most suitable?
Drag each IoT deployment scenario to the protocol family that best fits its constraints.
Arrange the steps of the weighted-scoring protocol selection method in the correct sequence.
| 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.