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
A sound protocol choice starts with deployment constraints and remains tied to measured evidence.
- Hard requirements filter the candidates.Passing gates keeps the candidate in review.
- Test surviving protocol families.Measure the operating conditions that matter at the site.
- Record owners and revisit triggers.The decision record explains when the choice must be reopened.
Major section
In 60 Seconds · Start With the Story
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
Minimum Viable Understanding · How to Use: How It Works: Use The Selection Series
If those boundaries are missing, the recommendation is not ready.
- Frame the challenge: Start with the competing constraints so the team understands why no protocol is best everywhere.
- A learner who only knows one wireless name should begin with the challenge chapter, then use the framework to ask what the deployment must prove.
- A project team choosing between short-range and wide-area lanes should move from boundary definition to hard constraints, then document which options were eliminated and why.
Major section
Protocol Framework Anti-Patterns · How This Series Fits Together
Protocol Framework Anti-Patterns helps catch unsupported rankings and hidden assumptions.
- The series is organized as a progression from problem framing to scenario practice.
- You need to understand why range, energy, payload, latency, security, and operations compete.
- You need a repeatable workflow for a real protocol decision.
Major section
The Decision Flow · Protocol Families as Design Lanes
This overview uses the same decision flow as the rest of the series.
- The decision flow in starts by naming the link, device class, site, and owner.
- Those details bound the deployment that a protocol must serve.
- Protocol families are useful starting points, not fixed answers.
- Phone support, pairing behavior, reconnect tests, current trace.
Major section
Decision Records · How to Use: What This Overview Removes
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.
- Boundary fit names the radio, gateway, broker, address, and safety needs that a score may hide.
- The matrix is not a universal ranking.
Major section
Common Pitfalls
A successful link resolves only one technical choice; gateway operation, service plans, access points, device keys, monitoring, updates, replacement, and incident response still need accountable owners.
- The correction frames the pitfalls that follow: protocol layers, switching rules, field evidence, and maintenance duties must remain visible in the decision record.
- This page gives the map.
Major section
Common Pitfalls (continued)
"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.
- 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.
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.
- If those boundaries are missing, the recommendation is not ready.
- Protocol Framework Anti-Patterns helps catch unsupported rankings and hidden assumptions.
- This overview uses the same decision flow as the rest of the series.
- The most useful artifact from this series is a protocol decision record.
Retrieval practice
Recall questions 1 and 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.
Q2A field meter sends small readings, must sleep for long periods, and is far from the site network. Which family is the best first lane to test?
Show answer
Answer: A Sparse payloads, long sleep, and wide reach make this family a useful first test, subject to field evidence.
Retrieval practice
Recall question 3
Physics Phoebe says: answer from memory, then check your reasoning.
Q3What turns broad protocol needs into limits that candidates must satisfy?
Show answer
Answer: B Constraints turn broad needs into limits a candidate protocol must satisfy.
Retrieval practice
Recall question 4
Physics Phoebe says: answer from memory, then check your reasoning.
Q4A 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 · Sparse payloads, long sleep, and wide reach make this family a useful first test, subject to field evidence.
- B · Constraints turn broad needs into limits a candidate protocol must satisfy.
- A · The framework separates hard constraints from comparison preferences.