34 Why Protocol Choice Is Hard

34.1 In 60 Seconds

This section: In 60 Seconds — Picture a farm sensor that must last through winter and report a burst pipe quickly.

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. A gateway is a device that joins one network to another. Latency means the time from sending to a useful result. Write the hard limits for range, energy, message size, warning time, safety, and upkeep before naming a favourite.

Build a short list, then change one condition at a time. Add a wall, lose the gateway link, increase message size, delay a reply, and restart a device. Record which option fails each limit, what evidence supports the rejection, and what extra service or field work a surviving choice requires.

This first screen cannot predict every site condition or future version. It only makes the current trade clear. The deeper sections separate the radio, network, transport, and application duties so the final choice is a stack of bounded decisions rather than one product label.

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

This section: Start With the Story — You will explain competing protocol constraints and build a shortlist that excludes choices your deployment cannot support.

You will explain competing protocol constraints and build a shortlist that excludes choices your deployment cannot support. Start by separating hard limits from preferences and identifying which network layer each candidate serves.

Follow the difficult choice across four beats to see why familiarity cannot replace deployment evidence.

Read the story panels from the familiar radio to the bounded field result. The opening preference becomes unreliable once parking, wearable, logistics, and building deployments reveal conflicting range, power, timing, security, and operational constraints. Hard-stop gates remove candidates that cannot satisfy the deployment. Measurements then validate the surviving choice at the real site, making the conclusion defensible for that context without claiming a universally best protocol.

The mathematical gist. Antenna gain adds directly to the link budget, while free-space loss grows as $20\log_{10}d$. For this chapter’s 14 dBm, 868 MHz LoRaWAN example with −130 dBm sensitivity, 0 dBi gateway gain permits 144 dB of free-space loss or about 435 km; 6 dBi permits 150 dB or about 869 km. The factor is $10^{6/20}=1.995$, so 6 dB nearly doubles the free-space ceiling without promising real-world coverage.

Math Bridge · guided foundationsWhy does 6 dB of antenna gain nearly double range?Let Phoebe unpack the logarithm, the link budget, and the chapter's 435 km to 869 km free-space example. Learn the maths

34.3 Protocol Selection: The Challenge

This section: Protocol Selection: The Challenge — Protocol selection is not a popularity contest.

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

This section: 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

34.5 Why This Is Hard

This section: Why This Is Hard — The challenge is not that the protocol landscape is random.

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.

The map in Figure 34.1 ranks link needs; check reach, power, speed, delay, safety, and upkeep.

+

Read Figure 34.1 from range and energy down through throughput, latency, security, and operations. The paired boxes expose different questions, from reaching infrastructure to maintaining devices after installation. Only candidates that satisfy the hard constraints reach the shortlist at the bottom, before any preference scoring begins.

34.6 Selection Dimensions

This section: Selection Dimensions — Use these dimensions as a review checklist before naming a winner.

Use these dimensions as a review checklist before naming a winner.

34.7 The Constraint Triangle

This section: The Constraint Triangle — The common teaching shortcut is a triangle: range, energy, and throughput cannot all be optimized at once.

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

This section: Layer Boundaries — Many protocol arguments are actually layer mistakes.

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.

Inspect Figure 34.2 and look for the distinct job each boundary performs before a message reaches the medium.

+

Descend Figure 34.2 from application meaning to physical transmission. CoAP, MQTT, HTTP, or AMQP define what the message means. UDP, TCP, DTLS, TLS, or QUIC carry it with particular ports, ordering, acknowledgement, and protection behavior. IPv6 and 6LoWPAN supply addressing, routing, compression, and fragmentation across services and constrained links. Wi-Fi, Ethernet, or IEEE 802.15.4 share one local medium through frame and retry rules, while the physical layer moves bits over a band or wire. This order supports the framework challenge: protocol selection is a set of compatible boundary contracts, so a familiar application protocol cannot repair an unsuitable route, frame budget, or radio path.

34.9 First-Pass Shortlisting

This section: First-Pass Shortlisting — A first-pass shortlist is not the final decision.

A first-pass shortlist is not the final decision. It prevents impossible options from wasting design time.

The list in Figure 34.3 starts with the link job; drop choices that fail a hard limit.

+

The route in Figure 34.3 cuts poor link choices first; keep proof for each one left.

Use this sequence:

1. Define the communication job. Is it telemetry, control, configuration, bulk transfer, discovery, local automation, tracking, or backhaul?
2. Rank hard constraints. Identify what must not fail: power source, reach, latency, payload, security boundary, mobility, or operations.
3. Eliminate impossible families. Remove options that cannot satisfy the hard constraint without redesigning the system.
4. Keep a shortlist. Compare only the candidates that remain viable.
5. Record missing evidence. Note field tests, current traces, payload measurements, standards profiles, or operations checks still required.

34.10 Example Challenge Reviews

This section: Example Challenge Reviews — These examples show the shape of the reasoning without pretending that one protocol is always correct.

These examples show the shape of the reasoning without pretending that one protocol is always correct.

34.11 Common Pitfalls

This section: Common Pitfalls

34.12 Knowledge Check

This section: Knowledge Check

Knowledge Check: Dominant Constraint

Knowledge Check: Protocol Layers

Matching Check

Ordering Check

34.13 Place Each Candidate In Trade-Off Space

This section: 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.

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.

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

This section: Summary — Protocol selection is difficult because useful requirements compete.

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

This section: See Also

34.16 What’s Next

This section: What’s Next

34.17 Key Takeaway

This section: Key Takeaway — A protocol recommendation should survive challenge.

A protocol recommendation should survive challenge. Defend it against latency, power, range, payload, reliability, security, cost, gateway, and lifecycle constraints.