IoT Fundamentals · Study deck
Protocol Selection: Series Map
Picture a team choosing a link for a parking sensor.
Physics Phoebe is your guide for this deck.
After studying this chapter
Learning objectives
You will be able to:
- Describe the protocol-selection series and when to use each chapter.
- Explain why connectivity decisions begin with deployment evidence rather than protocol names.
- Identify the difference between hard constraints, comparison criteria, and validation evidence.
- Map common protocol families to the types of requirements they are usually asked to satisfy.
Major section
In 60 Seconds
One option reaches far but sends little.
- Another sends more but drains the battery.
- A familiar choice may still fail the site.
- A protocol is a shared set of communication rules.
- A score table can help, but a high total must not hide one failed safety or service need.
Major section
In 60 Seconds (continued)
No protocol is best for every device, and a paper claim is not field proof.
- Protocol selection is a decision process, not a protocol ranking.
- This series teaches learners to define the communication boundary, collect deployment evidence, eliminate candidates that fail hard constraints, compare only viable finalists, and validate the recommendation before rollout.
- This overview explains how the chapters fit together and how to use them without treating any protocol family as a universal answer.
Major section
How This Series Fits Together
The series is organized as a progression from problem framing to scenario practice.
- That progression connects Protocol-selection series map showing the challenge chapter, systematic selection workflow, scenario practice, anti-pattern review, and related protocol-family deep dives to the next: How This Series Fits Together check.
- You need a repeatable workflow for a real protocol decision.
Major section
The Decision Flow
This overview uses the same decision flow as the rest of the series.
- The first highlights: Deployment Boundary, the second uses: Evidence Inputs to hold review evidence, and the last uses: Site, power, payload, latency, security, operations to assign operational ownership.
Major section
Protocol Families as Design Lanes
Protocol families are useful starting points, not fixed answers.
- The same family can be a good fit in one deployment and a poor fit in another when ownership, power, mobility, payload, or validation evidence changes.
- Phone support, pairing behavior, reconnect tests, current trace.
- Assuming a nearby user device is always present.
Major section
Decision Records
The most useful artifact from this series is a protocol decision record.
- It should be short enough to read, but specific enough that another engineer can audit the reasoning.
- The matrix is not a universal ranking.
- It also gives future maintainers a way to understand what evidence was available when the decision was made.
Major section
Common Pitfalls
"Which is better: an application message protocol or a wireless access technology?" is usually the wrong question.
- Heterogeneous-network designs often have more than one usable radio access technology.
- Game-style RAT-selection examples are useful as warnings, not as rollout rules.
- This page gives the map.
Major section
Common Pitfalls (continued)
A local improvement for one client can make the shared system worse or create endless switching when every client chases the same apparent best path.
- Prior team experience is useful, but it is not a substitute for range tests, current traces, payload budgets, operations plans, and integration checks.
- Protocol choice includes who owns gateways, service plans, access points, device keys, monitoring, firmware updates, replacements, and incident response.
- If the device is allowed to switch, the decision record should name the switching authority, the measured utility signal, the hysteresis or hold-down rule, and the evidence that prevents route flapping.
Major section
Requirements Become Protocol Gates
A building sensor may use Thread or Zigbee for a local mesh and MQTT between the gateway and broker.
- A protocol choice is a claim about a bounded communication problem: which device class, which link, which site conditions, which owner, which payload, which failure mode, and which operating life.
- This overview separates the radio or device link from the network path and from application messaging.
- The tiny hourly payload makes LPWAN's low data rate acceptable.
Major section
Requirements Become Protocol Gates (continued)
The practitioner move is to preserve why alternatives were rejected.
- When those boundaries are explicit, BLE, Thread, Zigbee, Wi-Fi, LoRaWAN, NB-IoT, LTE-M, MQTT, CoAP, and AMQP stop looking like a ranked list and start looking like tools for different jobs.
- A wearable may use BLE to reach a phone, HTTPS or MQTT from the phone to a cloud API, and a different provisioning flow for updates.
- A vendor roadmap cannot replace a field trace.
Major section
Requirements Become Protocol Gates (continued)
Total cost of ownership is part of that constraint analysis.
- A remote meter may use LoRaWAN through an owned gateway fleet or NB-IoT through a carrier network.
- None of those answers is meaningful until the deployment boundary and evidence are stated.
- A high ecosystem score cannot rescue a radio that fails measured coverage.
Major section
Requirements Become Protocol Gates (continued)
Two LPWANs can both satisfy technical filters for a metering project.
- In practice, the selection meeting should begin with a short evidence worksheet, not with a protocol table.
- Gates are pass/fail constraints; comparison scores are used only after a candidate survives the gates.
- The correct record says which risk the organization is prepared to own.
Major section
Requirements Become Protocol Gates (continued)
For LoRaWAN, that may be a packet-delivery and SNR trace at edge locations with the intended spreading-factor policy.
- For NB-IoT or LTE-M, it may be attach time, coverage, power-save mode behavior, and provider support.
- For Wi-Fi, it may be reconnect behavior, access-point roaming, credential rotation, and current draw during association.
- For Thread or Zigbee, it may be router density, commissioning, channel coexistence, and behavior after a powered router disappears.
Major section
Requirements Become Protocol Gates (continued)
A good selection recognizes that one requirement is usually the binding constraint: the demand that eliminates the most options or creates the largest operating risk.
- If 5-year battery life is non-negotiable, resolve the power axis before arguing about dashboard integrations.
- If the device must roam nationally, resolve carrier coverage, SIM/eSIM operations, and support ownership before optimizing protocol elegance.
- A low module price cannot rescue a design that requires truck rolls every few months.
Major section
Requirements Become Protocol Gates (continued)
If the payload is video or frequent firmware images, resolve throughput and power source before comparing low-power radios.
- Leading with the binding constraint prevents a team from falling for a protocol that is excellent on a dimension the deployment does not actually need.
- LoRaWAN may avoid per-device carrier subscriptions, but someone must place gateways, maintain backhaul, monitor packet loss, handle network-server upgrades, protect keys, and manage duty-cycle expectations.
- NB-IoT or LTE-M may remove gateway operations, but the fleet inherits carrier coverage, contract, module-certification, roaming, service-plan, and support risks.
Major section
Requirements Become Protocol Gates (continued)
Wi-Fi may reuse building infrastructure, but access-point ownership, credential rotation, captive portals, and power draw become operating assumptions.
- BLE may be cheap and low power, but it often depends on a nearby phone, gateway, or commissioning workflow.
- After hard gates, a weighted score can help compare finalists, but the weight choices must be documented.
- NB-IoT has no gateway fleet to build, but charges per device and depends on carrier coverage and support.
Deck summary
Key takeaways
One option reaches far but sends little.
- No protocol is best for every device, and a paper claim is not field proof.
- The series is organized as a progression from problem framing to scenario practice.
- This overview uses the same decision flow as the rest of the series.
- Protocol families are useful starting points, not fixed answers.
Retrieval practice
Recall check 1 of 2
Physics Phoebe says: answer from memory, then check your reasoning.
Q1What should come before choosing an IoT communication protocol?
Show answer
Answer: D Protocol selection starts with requirements and constraints, then compares candidates.
Q2Place each protocol-selection activity where it lives so you can move from deployment constraints to a reviewable choice instead of choosing by habit.
Show answer
Answer: A Frame the challenge, compare protocol families against scenarios, then record trade-offs and revisit triggers so you can defend and update the selection.
Retrieval practice
Recall check 2 of 2
Physics Phoebe says: answer from memory, then check your reasoning.
Q3A candidate protocol is familiar to the team and easy to integrate, but the deployment evidence shows it cannot meet the required maintenance interval without frequent field visits. What should the framework do?
Show answer
Answer: A The framework separates hard constraints from comparison preferences.
Print reference
Answers
Answer key.
- D · Protocol selection starts with requirements and constraints, then compares candidates.
- A · Frame the challenge, compare protocol families against scenarios, then record trade-offs and revisit triggers so you can defend and update the selection.
- A · The framework separates hard constraints from comparison preferences.