34 Why Protocol Choice Is Hard

34.1 In 60 Seconds

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

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.

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

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

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.

Pause at the figure Figure 34.1 before applying Why This Is Hard. Its Range and gateway, tower, labels show why Protocol choice starts by ranking competing constraints before naming winners needs an evidence check for Why This Is Hard here.

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

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.

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.

Follow the layers in Figure 34.2 to see how a sensor message reaches the physical link. Compare candidates within the role they perform, because an application protocol and a radio technology answer different questions.

Read down Figure 34.2 from the application layer through transport, network, data link, and physical transmission. The left column tracks messages becoming segments, packets, frames, and bits; the right gives a role example at each stage. Build a compatible stack from these responsibilities rather than selecting one name to cover every layer.

34.9 First-Pass Shortlisting

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

Inspect the figure Figure 34.3 before carrying First-Pass Shortlisting forward. Communication job and Rank hard constraints identify the evidence boundary implicit in First-pass shortlisting removes impossible families before detailed scoring.

For First-Pass Shortlisting, the visual sequence in Figure 34.3 opens with Communication job, where it highlights Communication job. Rank hard constraints follows to show how it highlights Rank hard constraints; reach, energy, payload, latency, security then uses reach, energy, payload, latency, security to show the next hand-off. That progression connects First-pass shortlisting removes impossible families before detailed scoring to the next First-Pass Shortlisting check.

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

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

34.11 Common Pitfalls

34.12 Knowledge Check

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.

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.17 Key Takeaway

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