IoT Fundamentals · Study deck
Why Protocol Choice Is Hard
Picture a farm sensor that must last through winter and report a burst pipe quickly.
Physics Phoebe is your guide for this deck.
After studying this chapter
Learning objectives
You will be able to:
- Explain why range, energy, throughput, latency, coverage, security, scalability, interoperability, and operations compete.
- Rank hard constraints before comparing protocol names.
- Separate physical/link choices from network, transport, and application-layer choices.
- Use a first-pass shortlist before doing weighted scoring or detailed lifecycle-cost work.
Major section
In 60 Seconds
Eliminate Choices With Evidence, Not Habit: Picture a farm sensor that must last through winter and report a burst pipe quickly.
- One familiar network reaches the shed but drains the battery.
- Another saves energy but cannot meet the warning time.
- No single option wins every need.
- A protocol is an agreed set of message and timing rules.
Major section
In 60 Seconds (continued)
A gateway is a device that joins one network to another.
- Latency means the time from sending to a useful result.
- This first screen cannot predict every site condition or future version.
- It only makes the current trade clear.
- A radio that reaches farther often sends less data or needs more energy.
Major section
Start With the Story
You will explain competing protocol constraints and build a shortlist that excludes choices your deployment cannot support.
- The mathematical gist.: Antenna gain adds directly to the link budget, while free-space loss grows as $20\log_{10}d$.
Major section
Why This Is Hard
The challenge is not that the protocol landscape is random.
- The challenge is that every reasonable option is optimized for a different job.
- Its: Range and gateway, tower, labels show why Protocol choice starts by ranking competing constraints before naming winners needs an evidence check for: Why This Is Hard here.
Major section
Selection Dimensions
Site survey, antenna plan, weak-path tests, mobility assumptions.
- Devices install successfully but cannot report reliably.
- The device works in the lab but fails field lifetime targets.
- Payload budget, retry policy, acknowledgment needs, latency contract.
- A high-throughput link is overbuilt, or a low-data-rate link misses timing needs.
Major section
The Constraint Triangle
The common teaching shortcut is a triangle: range, energy, and throughput cannot all be optimized at once.
- The triangle is useful, but it should not be treated as a magic formula.
- The trade-off is usually higher active energy, shorter practical range, or stronger infrastructure requirements.
- A Wi-Fi camera needs airtime, roaming, firmware-update, and mains-power assumptions.
Major section
The Constraint Triangle (continued)
The trade-off is usually lower payload rate, stricter duty behavior, delayed downlink, or site-specific coverage validation.
- Useful for devices that sleep most of the time and are expensive to service.
- The trade-off is usually smaller payloads, limited receive windows, less frequent reporting, or gateway/topology planning.
- A LoRaWAN field sensor needs received-signal margin, duty-cycle, downlink, and battery-life evidence for the real site.
Major section
Layer Boundaries
Many protocol arguments are actually layer mistakes.
- MQTT, CoAP, HTTP, Wi-Fi, BLE, LoRaWAN, IPv6, TCP, and UDP are not all alternatives to each other.
- The left column tracks messages becoming segments, packets, frames, and bits; the right gives a role example at each stage.
- This layer answers how bits reach the next hop.
Major section
First-Pass Shortlisting
A first-pass shortlist is not the final decision.
- That progression connects First-pass shortlisting removes impossible families before detailed scoring to the next: First-Pass Shortlisting check.
Major section
Common Pitfalls
If requirements demand long reach, high throughput, tiny energy use, low latency, low cost, and no infrastructure, the problem is under-ranked.
- The correct next step is constraint negotiation, not protocol shopping.
- "LoRaWAN or MQTT" and "Wi-Fi or CoAP" are layer mistakes.
- The radio part is not the deployment.
Major section
Place Each Candidate In Trade-Off Space
Radio physics ties them together: reaching farther for a given power usually means spending airtime on fewer bits through narrower bandwidth, lower coding rate, spreading, or more conservative modulation.
- Pushing many bits per second usually needs wider bandwidth, cleaner signal conditions, shorter practical range, stronger infrastructure, or more energy.
- So every IoT radio is a point in a trade-off space.
- LoRaWAN may fit, but the accepted cost is low throughput and constrained downlink behavior.
Major section
Place Each Candidate In Trade-Off Space (continued)
A machine-vision camera on the same farm needs steady megabits per second and mains power, so Wi-Fi or Ethernet is more realistic.
- Wi-Fi may fit, but the accepted cost is access-point planning and higher active energy.
- Thread or Zigbee may fit, but the accepted cost is commissioning, router density, route repair, and channel planning.
- Two teams can therefore both need "wireless sensors" and still choose oppositely.
Major section
Place Each Candidate In Trade-Off Space (continued)
Range, rate, and power are the headline axes, but real decisions add more: topology, spectrum regime, cost, scale, latency, mobility, ownership, provisioning, updates, monitoring, and failure recovery.
- A mesh can reduce gateway count, but it can increase route churn, commissioning work, and security-key operations.
- A cellular link can remove local gateways, but it adds SIM lifecycle, coverage contracts, operator outages, and recurring fees.
- Neither decision is automatically wrong; each weights the axes differently.
Deck summary
Key takeaways
Eliminate Choices With Evidence, Not Habit: Picture a farm sensor that must last through winter and report a burst pipe quickly.
- A gateway is a device that joins one network to another.
- You will explain competing protocol constraints and build a shortlist that excludes choices your deployment cannot support.
- The challenge is not that the protocol landscape is random.
- Site survey, antenna plan, weak-path tests, mobility assumptions.
Retrieval practice
Recall check 1 of 2
Physics Phoebe says: answer from memory, then check your reasoning.
Q1In a protocol-selection challenge, what should a strong answer include?
Show answer
Answer: C Protocol-selection challenges test tradeoff reasoning, not recall of one favorite option.
Retrieval practice
Recall check 2 of 2
Physics Phoebe says: answer from memory, then check your reasoning.
Q2Why should protocol selection start with the dominant hard constraint?
Show answer
Answer: D Hard constraints protect the shortlist.
Q3Why is the question 'MQTT or Wi-Fi?' a protocol-selection mistake?
Show answer
Answer: A A complete protocol stack needs choices at multiple layers.
Print reference
Answers
Answer key.
- C · Protocol-selection challenges test tradeoff reasoning, not recall of one favorite option.
- D · Hard constraints protect the shortlist.
- A · A complete protocol stack needs choices at multiple layers.