35 Systematic Protocol Selection

35.1 In 60 Seconds

Imagine choosing how a door sensor will report an alarm. 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.

Start with the communication boundary and the result the system must prove. Write hard limits for power, range, delay, message size, security, and cost. Remove any option that breaks a hard limit. Compare the remaining options with the same evidence. Then test the weakest assumption on the real device and site. Keep the result so a later change reopens the decision.

Use a plain comparison sheet. Give every need a unit. Mark each need as fixed or preferred. Check range at the real site. Measure current on the real board. Count the full message size. Include setup and recovery traffic. State who holds keys. State who updates devices. Record any paid service or shared network. Reject a choice when it misses a fixed need. Do not hide that miss with a score.

For the survivors, test the weakest fact first. A short field trial can end a poor option early. Keep the raw result and the reason for the final choice.

This simple filter does not capture every vendor detail or future condition. It makes the reasons visible; it does not remove the need for testing. The Practitioner section builds the full selection record. Under the Hood examines standards, scoring, and trade-offs.

Systematic protocol selection turns a vague preference into an auditable decision. Define the communication boundary, collect requirements as evidence, eliminate candidates that fail hard constraints, compare only the survivors, and validate the weakest assumptions before rollout.

The mathematical gist. Antenna gain redistributes fixed power: $G=4\pi/\Omega$ concentrates energy into a smaller solid angle. Under the chapter’s $20$ dBm EIRP cap, a $6$ dBi patch reduces conducted power from $17$ to $14$ dBm while doubling on-axis density; the Kraus estimate gives a roughly $102$ degree symmetric beam, so the gain is paid for with an approximately $\pm51$ degree coverage boundary.

Math Bridge · guided foundationsWhy does antenna gain narrow coverage?Phoebe follows the warehouse rack numbers from EIRP to on-axis power and beamwidth. Learn the maths

35.2 Start With the Story

You will turn deployment requirements into elimination gates, compare viable finalists, and plan field validation for the selected protocol. Start by quantifying the limits that every candidate must pass before scoring begins.

Trace the systematic workflow across four beats, from framing the deployment to preserving a reviewable decision.

35.3 Read Standards by Layer, Not by Logo

No single standards body defines the whole IoT path. The source deck separates the work by boundary: 3GPP specifies cellular network families and their IoT variants, including LTE-M and NB-IoT; IEEE defines link and radio families such as IEEE 802.15.4 and the low-power or wide-area Wi-Fi variants 802.11ah and 802.11af; and IETF work covers IP adaptation and routing for constrained networks, end-to-end protocols such as HTTP and CoAP, transport security through DTLS, and firmware-update architecture.

That map prevents a common category error. Choosing an IEEE radio does not choose the routing, application, security, or update contract above it, and choosing an IETF application protocol does not choose the cellular or local-link service below it. A complete protocol decision therefore names the owner and standard at each boundary that matters: radio and medium access, network adaptation and routing, end-to-end communication, security, and software update.

35.4 Ask What the Deployment Must Prove

Systematic protocol selection replaces "Which protocol is best?" with a better question: "What must this deployment prove?" The right protocol is the candidate that survives the hard constraints, has the strongest evidence among the finalists, and passes a validation plan in the real environment.

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.

Think of hiring for a safety-critical role. You first screen out anyone who fails the non-negotiable requirements, then compare the qualified finalists carefully. Scoring the unqualified would only make a bad choice look rigorous.

For example, imagine twenty battery temperature sensors on metal warehouse racks. 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. That boundary changes the shortlist. A phone-dependent link may fail the ownership gate, a Wi-Fi design may need measured current data before it can pass the battery gate, and a private gateway option may survive only if coverage tests reach the coldest rack corners. 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.

Make Ask What the Deployment Must Prove traceable: inspect Figure 35.1 for 1. Decision Boundary. Focus next on 2. Evidence Inputs, the companion label anchoring Five stages, each producing evidence for the next: boundary, requirements, elimination, comparison, validation.

Three labelled stops organise Figure 35.1. 1. Decision Boundary uses 1. Decision Boundary to mark a decision point; moving to 2. Evidence Inputs shows where it uses 2. 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.

The One-Minute View

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 building retrofit should eliminate options that fail site or battery requirements before comparing the survivors.
• A mobile asset tracker needs evidence for mobility, handoff, fallback, cost, and security, plus a plan to validate the chosen service.

Selection Order Knowledge Check

35.5 Standards Ownership Map

Inspect Figure 35.2 to assign a claim to the right standards boundary before selecting a protocol family or conformance route.

Read Figure 35.2 from RADIO + LINK, which places IEEE beside 3GPP, to INTERNET, which assigns IPv6, RPL, and CoAP to IETF work. PROFILE + CONFORMANCE demonstrates why a deployable product claim can cross several bodies and still needs an edition, profile, test, and owner.

If you grasp the order of the method, you can stop here. Continue to Practitioner to build the shortlist step by step.

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

Step 1: Define the Decision Boundary

A protocol decision is only useful when the boundary is clear. "Which protocol should our project use?" invites generic rankings and familiar-protocol bias. A stronger question names the device, link, environment, and ownership model, for example: "Which access network should a battery environmental sensor use to report small payloads from fixed outdoor locations to a managed gateway?" The boundary should identify the device role, the selected link, the environment, the ownership model, and the operations plan (provisioning, monitoring, updates, key rotation, battery replacement, and support).

Step 2: Build the Requirements Ledger

Requirements should be reviewable evidence, not slogans. Each one needs a value or condition, a reason, and a test source.

Step 3: Eliminate Before Scoring

Elimination gates keep the process honest. A candidate that cannot meet a mandatory condition should not remain in the weighted matrix because it scores well somewhere else.

Pause at the figure Figure 35.3 before applying Step 3: Eliminate Before Scoring. Its DEFINE REQUIREMENTS and Capture range, battery, payload, latency, labels show why Systematic protocol selection workflow needs an evidence check for Step 3: Eliminate Before Scoring here.

Read Figure 35.3 downward: define requirements, eliminate non-viable options, compare finalists, and validate the winner. 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.

The important point is never the protocol name; it is the evidence behind each eliminated candidate. A short-range radio may fail the coverage gate for a fixed outdoor sensor unless gateways are placed close enough; a wide-area radio may fail the ownership gate for a body-to-phone sensor because it does not provide a native phone link.

Elimination Gate Knowledge Check

If you can produce a defensible shortlist, you can stop here. Continue to Under the Hood for finalist comparison, lifecycle cost, and validation.

35.7 Under the Hood: Compare Finalists and Validate

Only candidates that pass the elimination gates belong in the finalist comparison. Scoring is allowed here, but it must be disciplined, and the recommendation is not complete until a validation plan could still overturn it.

Step 4: Compare the Finalists

Keep the matrix from becoming theater: lock the criteria before scoring, lock the weights before seeing totals, score from evidence rather than preference, keep a reason beside every score, flag unknowns instead of hiding them in a middle score, and run a sensitivity check when small weight changes flip the winner.

Lifecycle cost is a useful category, but keep it local and assumption-driven. Avoid universal claims such as "Protocol A is always cheaper than Protocol B." Record the categories instead: device hardware, infrastructure (collectors, gateways, antennas, backhaul), installation labor, subscriptions or managed service, battery replacement and field service, monitoring and key management tooling, and the redesign risk if coverage or battery assumptions fail.

Step 5: Validate the Recommendation

A recommendation is not finished until the team knows what could still disprove it. Validation should target the weakest assumptions.

Before Step 5: Validate the Recommendation, inspect the figure Figure 35.4. Compare Decision Question with Hard; their difference reveals The selection summary: question, constraints, eliminated candidates, finalists, recommendation, validation tests, and open risks. This gives Step 5: Validate the Recommendation evidence to revisit.

Three labelled stops organise Figure 35.4. 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.

Good validation checks include a weak-location coverage test, a measured current trace across full reporting, retry, and recovery, a gateway or carrier or building-network handoff test, a downlink and command-path test for actuators, an interference and coexistence test with nearby systems, a trial of provisioning, update, key rotation, monitoring, and replacement, and a small pilot using production-like enclosures, antennas, placement, and support processes.

Override the initial recommendation only with a written reason. Good reasons include an owner who already operates one viable infrastructure path, a regulatory constraint that removes a high-scoring lane, field tests showing unacceptable weak-location coverage, or current measurements that miss the maintenance target. Weak reasons include team familiarity with a failed candidate, a vendor claim that outranks field evidence, a weighted score treated as more important than a hard filter, or a fallback with no trigger condition.

Common Pitfalls

1. Scoring before elimination. Weighted scoring compares finalists; it must not rescue candidates that fail hard constraints.
2. Treating the matrix as objective without evidence. Numbers look rigorous, but unsupported scores are guesses. Keep a reason and a source beside each score.
3. 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.
4. Forgetting the operating model. Who owns gateways, services, updates, keys, diagnostics, and replacement is part of the choice; a technically suitable link can still fail operationally.

Scoring Discipline Knowledge Check

At this depth, systematic selection is a sequence of evidence gates. The goal is not to make the decision look quantitative; it is to make the decision auditable and falsifiable.

35.8 Summary

• Frame the decision around a specific boundary instead of asking which protocol is best in general.
• A requirements ledger turns deployment facts into measurable hard constraints and scored preferences.
• Elimination gates remove impossible candidates before any weighted scoring begins.
• Finalist comparison uses locked criteria, evidence-backed scores, lifecycle categories, and explicit risk notes.
• Validation targets the weakest assumptions, and overrides need a written reason and a fallback trigger.

35.9 Key Takeaway

A systematic framework turns requirements into comparable, testable properties. It makes trade-offs visible across range, bandwidth, power, latency, reliability, security, topology, and operations, and it makes the decision auditable and falsifiable.

35.10 See Also