34 Why Protocol Choice Is Hard
Competing Constraints, Layer Boundaries, and Evidence-First Shortlisting
34.1 In 60 Seconds
IoT protocol selection is difficult because the strongest requirements usually compete. A radio that reaches farther often sends less data or needs more energy. A high-throughput link may need mains power or short range. A protocol that looks simple at the device may require gateway, service, update, and monitoring work. Start with hard constraints, separate protocol layers, and keep evidence for every eliminated option.
34.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 Why Protocol Choice Is Hard 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 Explains why IoT protocol choices are hard and how range, energy, latency, throughput, security, scale, interoperability, and operations shape shortlists. 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.
Phoebe’s Why
“Range” in the constraint triangle is not one fixed number a protocol carries around – it is what is left over after a link budget, and gain is one of the few line items in that budget an installer can change without touching the radio chip at all. An antenna with gain over isotropic does not create power; it reshapes where the existing power goes, trading coverage angle for concentration along a preferred direction. That reshaping raises the effective isotropic radiated power the far end sees, which plugs straight into the same free-space path-loss relationship that sets range for every protocol in this chapter’s comparison table – LPWAN, cellular, Wi-Fi, or BLE alike.
The Derivation
Effective isotropic radiated power combines transmit power and antenna gain:
\[\mathrm{EIRP\,(dBm)} = P_t\,\mathrm{(dBm)} + G\,\mathrm{(dBi)}\]
Free-space path loss grows with distance and frequency:
\[\mathrm{FSPL\,(dB)} = 20\log_{10}d + 20\log_{10}f - 147.55 \quad (d\text{ in m}, f\text{ in Hz})\]
A link closes while received power clears the receiver’s sensitivity floor:
\[P_{rx} = \mathrm{EIRP} - \mathrm{FSPL} + G_{rx} \geq P_{sensitivity}\]
so the maximum tolerable path loss, and therefore the maximum range, rises exactly with any added gain:
\[\mathrm{FSPL}_{max} = \mathrm{EIRP} + G_{rx} - P_{sensitivity}\]
Worked Numbers: A LoRaWAN Uplink Budget
The chapter names LoRaWAN as a long-range LPWAN candidate but does not fix a link budget, so take standard values: a 14 dBm (25 mW) end node at 868 MHz, a \(-130\) dBm gateway sensitivity, and a 0 dBi node antenna.
- With a 0 dBi gateway antenna: \(\mathrm{FSPL}_{max} = 14 + 0 - (-130) = 144\) dB, which solves to \(d \approx 435\) km of free-space ceiling
- Swap in a 6 dBi gateway antenna: \(\mathrm{FSPL}_{max} = 14 + 6 - (-130) = 150\) dB, solving to \(d \approx 869\) km – a \(10^{6/20} = 1.995\times\) range increase from 6 dB of gain alone, matching the textbook “6 dB doubles range” rule almost exactly
- Aperture view of the same result: \(A_e = G\lambda^2/4\pi\) grows from \(0.00951\ \mathrm{m}^2\) at 0 dBi to \(0.0378\ \mathrm{m}^2\) at 6 dBi – about 3.98x the collecting area, matching \(10^{6/10} = 3.98\)
- These are free-space ceilings, not promised coverage – terrain, foliage, and Earth curvature cut real deployments far below either number, but the gain still doubles whatever the achievable range turns out to be
34.3 Protocol Selection: The Challenge
Protocol selection is not a popularity contest. It is a constraint-ranking problem. The hard part is that an IoT deployment asks for several things at once:
- reach the device;
- fit the energy source;
- carry the payload at the required freshness;
- respond within the latency budget;
- scale to the device count;
- protect the data and control path;
- interoperate with the rest of the stack;
- remain operable after installation.
No single protocol wins every dimension. The goal is to identify which constraint is non-negotiable, then find the smallest set of protocol candidates that can survive it.
34.4 Learning Objectives
By the end of this chapter, 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.
- Avoid layer-confusion questions such as “MQTT or Wi-Fi?”
- Use a first-pass shortlist before doing weighted scoring or detailed lifecycle-cost work.
- Record what evidence is still missing before a protocol can be selected.
Quick Check: Challenge Reasoning
Protocol selection starts with the dominant constraint. A camera, a wearable, a buried meter, an indoor light switch, and a mobile asset do not belong to the same connectivity class because their payload, range, power source, latency, and operations assumptions differ.
34.5 Why This Is Hard
Most failed protocol decisions begin with one of three shortcuts:
- choosing a familiar protocol before checking power and coverage;
- comparing protocol names that operate at different layers;
- optimizing one dimension while ignoring the deployment system around it.
The challenge is not that the protocol landscape is random. The challenge is that every reasonable option is optimized for a different job.
34.6 Selection Dimensions
Use these dimensions as a review checklist before naming a winner.
34.7 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.
34.7.1 High Throughput
Useful for images, audio, firmware transfer, dense local backhaul, dashboards, and user-facing interactions. The trade-off is usually higher active energy, shorter practical range, or stronger infrastructure requirements.
34.7.2 Long Reach
Useful for sparse outdoor sensing, utility metering, agriculture, remote assets, and hard-to-wire sites. The trade-off is usually lower payload rate, stricter duty behavior, delayed downlink, or site-specific coverage validation.
34.7.3 Low Energy
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.
The safest reading is: the dominant constraint chooses the first candidate family. Secondary constraints then decide which member of that family survives.
Turn the triangle into measurements before it becomes a debate. A LoRaWAN field sensor needs received-signal margin, duty-cycle, downlink, and battery-life evidence for the real site. A BLE wearable needs phone-reconnect behavior, advertising interval, current trace, and privacy evidence. A Wi-Fi camera needs airtime, roaming, firmware-update, and mains-power assumptions. A Thread or Zigbee control network needs router density, commissioning success, route repair, channel planning, and local-failure behavior. The challenge answer is stronger when it names the test that would eliminate each tempting family.
34.8 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.
34.8.1 Layer Review
34.8.2 Physical And Link
Examples: Ethernet, Wi-Fi, BLE, IEEE 802.15.4, LoRa radio, cellular radio.
This layer answers how bits reach the next hop.
34.8.3 Network And Adaptation
Examples: IPv4, IPv6, 6LoWPAN, RPL, LoRaWAN network behavior.
This layer answers how packets are addressed, adapted, or routed.
34.8.4 Transport
Examples: TCP, UDP, QUIC, DTLS context.
This layer answers how endpoints exchange streams, datagrams, sessions, or protected transport.
34.8.5 Application
Examples: MQTT, CoAP, HTTP, AMQP, custom payload contracts.
This layer answers how application data is named, encoded, requested, published, or acknowledged.
“Should we use MQTT or Wi-Fi?” compares an application protocol with a link-layer technology. A complete stack might use both: Wi-Fi for local connectivity, IP and TCP for transport, and MQTT for application messaging.
34.9 First-Pass Shortlisting
A first-pass shortlist is not the final decision. It prevents impossible options from wasting design time.
Use this sequence:
- Define the communication job. Is it telemetry, control, configuration, bulk transfer, discovery, local automation, tracking, or backhaul?
- Rank hard constraints. Identify what must not fail: power source, reach, latency, payload, security boundary, mobility, or operations.
- Eliminate impossible families. Remove options that cannot satisfy the hard constraint without redesigning the system.
- Keep a shortlist. Compare only the candidates that remain viable.
- Record missing evidence. Note field tests, current traces, payload measurements, standards profiles, or operations checks still required.
34.10 Example Challenge Reviews
These examples show the shape of the reasoning without pretending that one protocol is always correct.
34.10.1 Remote Telemetry
Dominant constraint: reach and energy.
Likely first-pass direction: LPWAN or cellular IoT candidates, depending on coverage evidence, payload freshness, operations, and ownership model.
Do not decide from: nominal maximum data rate alone.
34.10.2 Local Control
Dominant constraint: latency, reliability, and local coverage.
Likely first-pass direction: local star or mesh candidates, depending on power source, room geometry, gateway placement, and maintenance access.
Do not decide from: radio module price alone.
34.10.3 High-Data Device
Dominant constraint: throughput and user experience.
Likely first-pass direction: Wi-Fi, Ethernet, or cellular broadband candidates, depending on power source, mobility, coverage, and backhaul.
Do not decide from: sensor-node energy assumptions.
34.10.4 Moving Asset
Dominant constraint: coverage across changing locations.
Likely first-pass direction: carrier, gateway, or hybrid designs depending on routes, handoff, dead zones, and reporting criticality.
Do not decide from: one static site test.
34.11 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. First identify the connectivity layer, then complete network, transport, security, and application decisions around it.
The radio part is not the deployment. Gateways, subscriptions, antenna work, commissioning, monitoring, replacement, and field service can dominate the real decision.
Advertised range, data rate, and power numbers are starting points. Real sites need antenna placement, interference, payload, retries, receive behavior, and operations evidence.
34.12 Check Your Understanding
Knowledge Check: Dominant Constraint
Knowledge Check: Protocol Layers
Matching Check
Ordering Check
34.13 Place Each Candidate In Trade-Off Space
Protocol choice is hard because the things teams usually want, long range, high data rate, and low power, pull against one another. 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. The honest question is not “which protocol is best?” but “which compromise fits this job?” A battery soil sensor that reports moisture every 30 minutes can tolerate tiny payloads and seconds of delay, so LoRaWAN or NB-IoT may be reasonable after coverage checks. A machine-vision camera on the same farm needs steady megabits per second and mains power, so Wi-Fi or Ethernet is more realistic. Same site, different communication job, different shortlist.
| Technology | Typical reach class | Typical data-rate class | Power posture |
|---|---|---|---|
| BLE | Room to nearby-phone range | About 1-2 Mbit/s at the PHY, less at the application | Low when duty-cycled |
| Zigbee or IEEE 802.15.4 | Room/building range, often extended by mesh | 250 kbit/s PHY for 2.4 GHz 802.15.4 | Low with careful sleep and routing design |
| Wi-Fi | Local access-point range | Tens to hundreds of Mbit/s depending on generation and link quality | Higher active energy; often mains or rechargeable |
| LoRaWAN | Long-range LPWAN class | Small, infrequent payloads at low data rates | Very low for sparse uplinks |
| NB-IoT | Cellular wide-area class | Small telemetry payloads, operator and coverage dependent | Low power with cellular power-saving modes |
Use the table as a placement aid, not as a winner list. Want long reach and years on a battery? LoRaWAN may fit, but the accepted cost is low throughput and constrained downlink behavior. Want to move a firmware image quickly? Wi-Fi may fit, but the accepted cost is access-point planning and higher active energy. Want a dense building control network? Thread or Zigbee may fit, but the accepted cost is commissioning, router density, route repair, and channel planning.
34.14 Summary
Protocol selection is difficult because useful requirements compete. The first task is not to choose the most familiar protocol; it is to rank hard constraints, understand which layer each technology belongs to, and remove options that cannot meet the deployment evidence. Once the shortlist is real, later chapters can compare candidates systematically.
34.15 See Also
34.16 What’s Next
34.16.1 Avoid Mistakes
Protocol Anti-Patterns shows what happens when teams skip the constraint checks in this chapter.
34.16.2 Apply A Process
Systematic Selection turns this challenge review into a repeatable elimination and scoring workflow.
34.16.3 Test Scenarios
Selection Scenarios applies the constraints to realistic deployment situations.
34.16.4 Use the Selector
Protocol Selector Wizard provides the wider shortlist helper for review.
34.17 Key Takeaway
A protocol recommendation should survive challenge. Defend it against latency, power, range, payload, reliability, security, cost, gateway, and lifecycle constraints.