IoT Fundamentals · Study deck

Protocol Selector Wizard

A field monitor must report a water level for two years on one battery.

Physics Phoebe is your guide for this deck.

protocolselectorwizard

Physics Phoebe, the module guide, in a scene from this chapter.

After studying this chapter

Learning objectives

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

Major section

In 60 Seconds

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.

Use the wizard flow as an evidence checklist, not just a scoring form.

Major section

In 60 Seconds (continued)

The wizard narrows a choice; it cannot certify coverage or battery life from catalogue values.

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

Major section

Start With the Story · Protocol Selector Wizard

You will use the wizard to narrow protocol options and record the assumptions that still need field testing.

The mathematical gist.: The chapter's $2000$ mAh assumption becomes $2.000\times3.7=7.40$ Wh only after a named 3.7 V chemistry assumption.
The score supports the decision; it does not replace field validation.

Major section

Key Concepts · For Beginners: What is Protocol Selection?

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.
Reliability = More overhead: Like insurance - costs more but protects you.

Major section

Put Numbers to the Decision · Worked Example: Use the Decision Guide for a Real Project

where $r_i$ is a normalized rating (0 to 1) for each criterion (range, power, bandwidth, latency, cost).

The 0.26 score gap quantifies why LoRaWAN is favored for long-life telemetry even though Wi-Fi wins on raw bandwidth.
Latency sensitivity: No, hourly data is fine.

Major section

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.
The reasons are more useful than the names of the winners.

Major section

Scenario Requirements Move the Protocol Answer (continued)

The exercise is to hold the method fixed and change the scenario.

A responsible wizard uses two passes.
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.
For the meter it is range without local infrastructure.

Major section

Scenario Requirements Move the Protocol Answer (continued)

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 wearable and the meter show why one shared requirement is not enough.
Practitioners should record the first rejecting constraint for each discarded protocol.

Major section

Scenario Requirements Move the Protocol Answer (continued)

The cautionary pattern is a requirement that quietly rules out the obvious pick.

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.
Good selection means finding the constraint that breaks the tempting but wrong option.

Major section

Scenario Requirements Move the Protocol Answer (continued)

The scenario turned on one dominant constraint, and recognizing it is the whole skill.

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.
The final decision should preserve rejected options, not only the winner.

Major section

Scenario Requirements Move the Protocol Answer (continued)

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.
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 mesh it is node count and self-healing coverage, which favors a mesh-native IEEE 802.15.4 stack over point-to-point links.

Major section

Scenario Requirements Move the Protocol Answer (continued)

Under the hood, the selector should keep hard constraints separate from preference weights.

The wizard's real job is to surface that deciding requirement and not be distracted by the others.
A team might default to Wi-Fi for a 300-node building sensor deployment because it is familiar.
That record is also what turns the wizard from a classroom picker into an engineering tool.

Major section

Summary · Match the Scenario to the Protocol

No "best" protocol exists - only best fit for your requirements.

Trade-offs are inevitable - long range usually means lower bandwidth.
Temperature Terry needed to send a message to the cloud, but couldn't figure out which delivery service to use!
He walks slowly but delivers across the whole city!".

Deck summary

Key takeaways

A field monitor must report a water level for two years on one battery.

The wizard narrows a choice; it cannot certify coverage or battery life from catalogue values.
You will use the wizard to narrow protocol options and record the assumptions that still need field testing.
Rationale matters: A strong selection rationale explains why finalists were chosen and why others were rejected.
where $r_i$ is a normalized rating (0 to 1) for each criterion (range, power, bandwidth, latency, cost).

Retrieval practice

Recall check 1 of 5

Physics Phoebe says: answer from memory, then check your reasoning.

Q1How should a learner use the protocol selector wizard responsibly?

AKeep every default weight even when coverage, battery life, or fees dominate the project

BUse it to shortlist candidates, then validate range, power, cost, and risk on the real site

CTreat the highest score as final proof that the protocol will survive deployment

DPick the newest radio family and use the wizard only to justify that prior decision

Show answer

Answer: B A wizard is a decision aid; the engineering assumptions still need validation.

Retrieval practice

Recall check 2 of 5

Physics Phoebe says: answer from memory, then check your reasoning.

Q2A 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?

AWi-Fi, because it has high bandwidth and farm routers are easy to extend across open fields

BBluetooth LE, because it is low power and many small sensor boards already support it

CLPWAN such as LoRaWAN, because it provides long range, low power, and low data rate

D5G cellular, because it has wide-area coverage and strong throughput for modern devices

Show answer

Answer: C The requirements -- long range, battery-powered devices, and infrequent small readings -- match the Quick Decision Guide row for long range plus battery life.

Retrieval practice

Recall check 3 of 5

Physics Phoebe says: answer from memory, then check your reasoning.

Q3Place each protocol-selection step where it lives so you can reject infeasible choices early and defend the finalist with measured evidence.

ADefine Constraints

BFilter Must-Haves

CScore Finalists

DValidate Choice

Show answer

Answer: A Move from a non-negotiable contract through hard filtering and transparent scoring to a measured prototype so you can explain both why losers were rejected and why the winner remains provisional.

Retrieval practice

Recall check 4 of 5

Physics Phoebe says: answer from memory, then check your reasoning.

Q4A livestock tracker on a 50km² ranch sends a 20-byte GPS update every 10 minutes, must last 2+ years on an AA battery, and cannot rely on cellular. Which protocol family should you evaluate first?

ABluetooth 5 mesh or long-range links

BWi-Fi HaLow for sub-GHz IP coverage

CLoRaWAN for multi-km, low-power telemetry

DZigbee mesh for low-power local networking

Show answer

Answer: C The first filters are range and battery life, and both point to LPWAN.

Retrieval practice

Recall check 5 of 5

Physics Phoebe says: answer from memory, then check your reasoning.

Q5Why is there no single best IoT protocol?

AManufacturers have not yet agreed on one global standard that every IoT product must use

BDifferent applications have conflicting requirements for range, power, bandwidth, and cost

COnly expensive protocols can meet field requirements for range, power, bandwidth, and cost

DIoT is too new for mature protocols to cover real deployments across industries

Show answer

Answer: B No protocol optimizes every dimension at once.

Q6A smart building needs real-time occupancy video analytics from 20 cameras across 3 floors, all connected to mains power. Which protocol is most suitable?

ALoRaWAN

BNFC

CWi-Fi

DZigbee

Show answer

Answer: C Video analytics makes throughput the dominant constraint, and mains power makes Wi-Fi a reasonable first candidate.

Print reference

Answers 1 of 2

Answer key.

B · A wizard is a decision aid; the engineering assumptions still need validation.
C · The requirements -- long range, battery-powered devices, and infrequent small readings -- match the Quick Decision Guide row for long range plus battery life.
A · Move from a non-negotiable contract through hard filtering and transparent scoring to a measured prototype so you can explain both why losers were rejected and why the winner remains provisional.
C · The first filters are range and battery life, and both point to LPWAN.

Print reference

Answers 2 of 2

Answer key.

B · No protocol optimizes every dimension at once.
C · Video analytics makes throughput the dominant constraint, and mains power makes Wi-Fi a reasonable first candidate.