31 Systematic Protocol Selection
Requirements, Elimination Gates, Finalist Comparison, and Validation
31.1 In 60 Seconds
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.
Phoebe’s Why
An antenna does not create power; it redistributes a fixed amount of it in space. An isotropic reference radiates that power equally over the whole sphere. A directional antenna squeezes the same power into a narrower lobe, so anywhere inside that lobe sees more power than the isotropic baseline would deliver – that concentration is “gain.” Because the sphere’s surface area is fixed by geometry, gain in one direction is always paid for by less coverage somewhere else. That is exactly why the “coverage gate” in this chapter’s elimination step needs a measured number, not a protocol name: a beam aimed at the near corner of a warehouse rack can leave the far corner outside the lobe entirely, and a battery-powered sensor there pays for that gap with a weaker, retry-heavy link.
The Derivation
Isotropic power density at distance \(d\):
\[S_{iso} = \frac{P_t}{4\pi d^2}\]
Gain \(G\) redirects that same \(P_t\) into an effective solid angle \(\Omega\) (steradians):
\[G = \frac{4\pi}{\Omega}, \qquad S_{dir} = G\,S_{iso}\]
In decibels, \(G(\mathrm{dBi}) = 10\log_{10}G\), and the regulator-facing figure is EIRP:
\[\mathrm{EIRP(dBm)} = P_t(\mathrm{dBm}) + G(\mathrm{dBi})\]
A common engineering estimate (Kraus) relates gain to the two half-power beamwidths \(\theta_E, \theta_H\) in degrees:
\[G \approx \frac{41253}{\theta_E\,\theta_H}\]
so solving for beamwidth shows the trade directly: more \(G\) forces a smaller \(\theta_E\theta_H\) product – a narrower patch of sky.
Worked Numbers: The Warehouse Rack Sensors
For the chapter’s own twenty battery temperature sensors reporting to one collector:
- Regulatory EIRP cap used for a 2.4 GHz ISM design (as established in the Frequency Bands chapter): 20 dBm
- Isotropic-like collector antenna (0 dBi) with a 17 dBm module: EIRP \(= 17 + 0 = 17\) dBm, 3 dB of headroom under the cap
- Swap to a 6 dBi directional patch aimed down the rack aisle: to stay \(\le 20\) dBm EIRP, conducted power must drop to \(20 - 6 = 14\) dBm – a \(17 - 14 = 3\) dB, or \(10^{-3/10} = 0.501\times\), cut in transmit current for every packet the sensors send toward that collector
- On-axis power density still rises: EIRP goes from 17 dBm (isotropic) to the capped 20 dBm (directional), \(10^{(20-17)/10} = 2.00\times\) more power density on axis, even though conducted current roughly halved
- Beamwidth cost, from the Kraus estimate at \(G = 10^{0.6} = 3.98\): \(\theta_E\theta_H \approx 41253/3.98 = 10362\ \text{deg}^2\); for a symmetric patch, \(\theta \approx \sqrt{10362} = 102\) degrees – so any sensor more than about 51 degrees off boresight falls outside the lobe entirely
The 2 dB range win and the halved transmit current are the “battery gate” payoff; the 102-degree cone is the “coverage gate” bill. A scoring matrix that only asks “does gain help range” without asking “which sensors fall outside the lobe” would pass a candidate this chapter’s elimination gates should catch.
31.2 Start With the Story
Start with a product meeting where someone says just use the protocol we know, while the deployment quietly needs different range, power, latency, security, and operations evidence. The core idea in Systematic Protocol Selection is simple: protocol choice is a constraint problem, not a popularity contest, and the defensible answer comes from eliminating bad fits before scoring good candidates. This page focuses that idea on Systematic protocol selection: frame the decision, turn requirements into hard constraints, eliminate before scoring, compare finalists, and validate. In everyday IoT, parking sensors, wearables, logistics tags, and building retrofits need different proof even when they all send small messages. Start simple: state the hard constraints, reject impossible options, compare the finalists, and then validate the chosen protocol in the field.
31.3 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.
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. The goal is a decision that is auditable and falsifiable, not one that merely looks quantitative.
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.
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.
Eliminate before scoring
Turn requirements into pass/fail gates and remove candidates that fail any of them before any weighted score is calculated.
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 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
If you grasp the order of the method, you can stop here. Continue to Practitioner to build the shortlist step by step.
31.4 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.
Hard constraints are pass/fail; preferences are scored later. 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. A candidate that cannot meet a mandatory condition should not remain in the weighted matrix because it scores well somewhere else.
Coverage gate
Can the device reach the collector from weak locations, through expected obstacles, and across expected movement?
Energy gate
Can the device complete its sleep, wake, transmit, retry, and recovery cycle within the maintenance interval?
Payload gate
Can the link carry the payload, retries, downlink needs, and freshness contract without abusing the medium?
Ownership gate
Does the deployment allow the required gateway, phone, access point, carrier service, or building-network dependency?
Security gate
Does the candidate support the pairing, key management, update, privacy, and control-path protections the product requires?
Operations gate
Can the team provision, monitor, troubleshoot, update, and replace the system without hidden manual work?
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.
31.5 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.
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
- Scoring before elimination. Weighted scoring compares finalists; it must not rescue candidates that fail hard constraints.
- Treating the matrix as objective without evidence. Numbers look rigorous, but unsupported scores are guesses. Keep a reason and a source beside each score.
- 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.
- 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.
31.6 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.
31.7 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.
31.8 See Also
Protocol Selection Scenarios
Apply this workflow to fixed sensors, body-to-phone links, mobile assets, and building retrofits.
Protocol Framework Anti-Patterns
Review the shortcuts that pull protocol decisions away from evidence.
Protocol Selection Framework
Return to the larger protocol-selection series and its reference chapters.