IoT Fundamentals · Study deck
Systematic Protocol Selection
Imagine choosing how a door sensor will report an alarm.
Physics Phoebe is your guide for this deck.
After studying this chapter
Learning objectives
You will be able to:
- Explain: Decision Question uses: Decision Question to mark a decision point; moving to: Hard shows where it highlights: Hard; ending at: Pass/fail requirements shows where it uses: Pass/fail requirements to state a required condition.
- Explain: If you only need the intuition, this layer is enough: define the decision boundary, collect requirements as evidence, eliminate candidates that fail hard constraints, compare only the survivors, and validate the choice before rollout.
- Explain: Writing only “ITU compliant” hides which authority and document the product depends on, so the review must trace the claim to the relevant sector and publication.
Major section
In 60 Seconds
A protocol is a set of rules for exchanging messages.
- Latency means the delay from the alarm to the response.
- The popular choice is not always the choice that fits the door.
- A short field trial can end a poor option early.
- This simple filter does not capture every vendor detail or future condition.
Major section
Read Standards by Layer, Not by Logo
That map prevents a common category error.
- No single standards body defines the whole IoT path.
- Each organization has a different authority and publication process, and an IoT product usually depends on several of them at once.
- IEEE Project 2413 developed a cross-domain architectural framework for IoT; the published artifact is IEEE 2413-2019.
Major section
Read Standards by Layer, Not by Logo (continued)
A design record should cite the published standard and edition it actually used, while preserving the project number only as provenance.
- The original core IPv6 specification was published as RFC 2460 in December 1998 and was later obsoleted by RFC 8200.
- A timeline claim must therefore name the milestone before attaching a year; “1999” without that qualifier is not reproducible evidence.
- Writing only “ITU compliant” hides which authority and document the product depends on, so the review must trace the claim to the relevant sector and publication.
Major section
Ask What the Deployment Must Prove
The important idea is order.
- Scoring tables and lifecycle-cost comparisons are useful, but only after impossible options have been removed.
- A high score on convenient factors must never rescue a candidate that fails a required constraint.
- The goal is a decision that is auditable and falsifiable, not one that merely looks quantitative.
Major section
Ask What the Deployment Must Prove (continued)
Scoring the unqualified would only make a bad choice look rigorous.
- If you only need the intuition, this layer is enough: define the decision boundary, collect requirements as evidence, eliminate candidates that fail hard constraints, compare only the survivors, and validate the choice before rollout.
- That boundary changes the shortlist.
- Decision Boundary uses 1.
Major section
Ask What the Deployment Must Prove (continued)
You first screen out anyone who fails the non-negotiable requirements, then compare the qualified finalists carefully.
- Each sensor reports a few bytes every five minutes, alarms must arrive within 30 seconds, and the facilities team can mount one managed collector but cannot depend on workers' phones being nearby.
- Evidence Inputs shows where it uses 2.
- A building retrofit should eliminate options that fail site or battery requirements before comparing the survivors.
Major section
Ask What the Deployment Must Prove (continued)
The method does not declare one protocol universally best; it shows which choices are still viable for this deployment and which measurements must be taken before rollout.
- Evidence Inputs to hold review evidence; ending at: Range, energy, payload, latency, operations shows where it uses: Range, energy, payload, latency, operations to assign operational ownership.
- Together they explain why Five stages, each producing evidence for the next: boundary, requirements, elimination, comparison, validation matters to: Ask What the Deployment Must Prove.
- Eliminate before scoring Turn requirements into pass/fail gates and remove candidates that fail any of them before any weighted score is calculated.
Major section
Ask What the Deployment Must Prove (continued)
The One-Minute View Frame the decision Name the link, device class, site, and ownership model so the question has a boundary instead of inviting generic rankings.
- Validate the recommendation Define the field or lab test that could still disprove the choice, and record the assumptions and fallbacks.
- Beginner Examples A classroom sensor's first decision is not a protocol name; it is the boundary, power source, payload size, range, and maintenance expectation.
- A mobile asset tracker needs evidence for mobility, handoff, fallback, cost, and security, plus a plan to validate the chosen service.
Major section
Apply It: From Boundary to Defensible Shortlist
The first three steps turn a vague question into a shortlist you can defend: set the boundary, write the requirements as evidence, then eliminate candidates that fail any hard constraint.
- Each one needs a value or condition, a reason, and a test source.
- Coverage failures are usually expensive after installation.
Major section
Apply It: From Boundary to Defensible Shortlist (continued)
Radio choice can dominate field maintenance work.
- Average throughput is not enough when bursts or alerts matter.
- A link that works in the lab can still be hard to operate.
- Commissioning workflow, monitoring plan, support process.
- Hard constraints are pass/fail; preferences are scored later.
Major section
Apply It: From Boundary to Defensible Shortlist (continued)
A forbidden network dependency, impossible range, unacceptable battery service interval, or missing phone support should eliminate a candidate before any weighted score is calculated.
- Step 3: Eliminate Before Scoring Elimination gates keep the process honest.
- The second stage applies pass/fail filters before scores or ownership costs can influence the ranking.
- The final prototype check tests the real radio environment, so a paper shortlist alone does not finish the decision.
Major section
Under the Hood: Compare Finalists and Validate
Pilot measurements, antenna tests, route or floor survey.
- Weak margin may force more collectors or a split architecture.
- Runbook, ownership map, support workflow, monitoring data.
- Manual exception handling can erase apparent simplicity.
- One-time and recurring categories need explicit assumptions.
Major section
Under the Hood: Compare Finalists and Validate (continued)
Common Pitfalls Scoring before elimination.: Weighted scoring compares finalists; it must not rescue candidates that fail hard constraints.
- Lifecycle cost is a useful category, but keep it local and assumption-driven.
- Validation should target the weakest assumptions.
- Treating the matrix as objective without evidence.: Numbers look rigorous, but unsupported scores are guesses.
Major section
Under the Hood: Compare Finalists and Validate (continued)
Hiding unknowns in middle scores.: Unknown coverage or current draw is not a neutral score; mark it as an open risk and plan the measurement.
- Decision Question uses: Decision Question to mark a decision point; moving to: Hard shows where it highlights: Hard; ending at: Pass/fail requirements shows where it uses: Pass/fail requirements to state a required condition.
- Together they explain why The selection summary: question, constraints, eliminated candidates, finalists, recommendation, validation tests, and open risks matters to: Step 5: Validate the Recommendation.
- At this depth, systematic selection is a sequence of evidence gates.
Deck summary
Key takeaways
A protocol is a set of rules for exchanging messages.
- That map prevents a common category error.
- A design record should cite the published standard and edition it actually used, while preserving the project number only as provenance.
- The important idea is order.
- Scoring the unqualified would only make a bad choice look rigorous.
Retrieval practice
Recall check 1 of 3
Physics Phoebe says: answer from memory, then check your reasoning.
Q1Why does systematic selection remove failed candidates before scoring the finalists?
Show answer
Answer: A Hard constraints are pass/fail; scoring an unviable option only makes a bad choice look rigorous.
Retrieval practice
Recall check 2 of 3
Physics Phoebe says: answer from memory, then check your reasoning.
Q2A candidate scores well on lifecycle cost and ecosystem, but the site survey shows it cannot reach the weakest installation points without forbidden infrastructure. What should happen next?
Show answer
Answer: A A hard constraint is pass/fail; an unreachable candidate should not stay in the matrix on the strength of secondary qualities.
Retrieval practice
Recall check 3 of 3
Physics Phoebe says: answer from memory, then check your reasoning.
Q3During finalist scoring, the team does not yet know a candidate's weak-location coverage. How should that gap be handled?
Show answer
Answer: C A middle score hides the unknown; flagging it as an open risk keeps the decision honest and triggers a real test.
Print reference
Answers
Answer key.
- A · Hard constraints are pass/fail; scoring an unviable option only makes a bad choice look rigorous.
- A · A hard constraint is pass/fail; an unreachable candidate should not stay in the matrix on the strength of secondary qualities.
- C · A middle score hides the unknown; flagging it as an open risk keeps the decision honest and triggers a real test.