13 Choosing IoT Communication Tech

13.1 Start With the Message Journey

This section: Start With the Message Journey — Firmware is the code that runs inside a device.

Firmware is the code that runs inside a device. A gateway is a point that joins two parts of a system. Telemetry is data sent from a device so its state can be checked.

Picture a freezer alarm that must cross a metal warehouse and reach the night team. The message is small, but it must arrive soon, wake the right person, and still work during a busy shift.

Start with the message job. Write its size, travel distance, time limit, send rate, power limit, and receiver. Mark every gateway and its owner. Then test the final site with closed doors, moving stock, a weak battery, busy traffic, and a lost outside link.

Compare choices with the same evidence. Long range may reduce gateway count but limit data or replies. High speed may cost more power. A good bench link does not prove the installed path, and a radio name does not prove that support teams can find or fix a fault.

Go deeper in two steps. The Practitioner section builds a field Link Record and a choice workflow. Under the Hood explains why good links can fail later as the site, traffic, or hardware changes.

Use a message card for the first review. Give the message a plain name. State who sends it and who needs it. State its size and send rate. Add the longest useful delay. Add the longest gap the job can bear. Add the safe action when the message does not arrive.

Next, draw the path. Mark each room, wall, floor, vehicle, wire, radio, and gateway. Put an owner beside every part. Mark where power comes from. Mark where data changes form. A path is not complete if no one owns one of its steps.

Now make a short list of hard limits. A battery unit may need long rest. An alarm may need a fast reply. A camera may need far more data than a heat probe. A moving unit may leave one site and join another. These facts remove poor choices before a score is used.

Test one normal path. Then close a door. Fill a shelf. Add more senders. Move the unit. Turn off a gateway. Stop the outside service. Use a weak battery. Keep loss, delay, retry count, and energy for every case. Do not hide the bad case in one mean value.

Check the whole day, not one packet. Some units send at once after power returns. Alarms may arrive in a burst. An update can use more data than months of normal reports. Add these rare jobs to the same path and check that they do not block the main service.

Compare the short list with one shared score card. Keep each hard fail as a fail. Do not let a low price or high peak speed erase it. For each choice, write the site proof still needed. Write who will run it and who will read the result.

Make support part of the choice. Ask how a team finds a missing unit. Ask which logs show the last good step. Ask how a key, setting, or firmware build is changed. Ask how an old unit is removed. A link that cannot be kept safe and healthy is not ready.

End with a narrow claim. Name the tested device, site, path, load, message, and pass rule. Add the change that makes the team test again. A new wall, gateway, radio setting, fleet size, or service owner can all end the life of old proof.

Communication technology choices make sense when you follow one message from source to destination. A telemetry sample, alarm, command, firmware update, or discovery packet has a distance, timing need, power cost, reliability target, and security context.

Start with that journey before naming a protocol. The right communication enabler is the one whose range, bandwidth, latency, energy, addressing, and operations evidence match the job the architecture needs the message to do.

Math Bridge · guided foundationsWhen does gain help a room sensor or a vehicle?Let Phoebe turn dBi into sphere coverage and on-axis range for the chapter's two jobs. Learn the maths

13.2 Learning Objectives

This section: Learning Objectives

By the end of this chapter, you will be able to:

• Classify communication technology by network scale, payload behavior, topology, and lifecycle records.
• Explain the difference between coverage, capacity, and reliability in an IoT communication design.
• Match common technology families to IoT situations without relying on brittle range or price shortcuts.
• Identify the field proof needed before approving a communication technology for a deployment.
• Build a communication decision record that supports installation, debugging, updates, and service handoff.

13.3 Communication as Architecture

This section: Communication as Architecture — Communication technology connects physical events to software decisions.

Communication technology connects physical events to software decisions. It determines whether telemetry reaches a gateway, whether commands arrive on time, whether a device can sleep, whether diagnostics are available, and whether the system still works after installation conditions change.

At communication as architecture, Communication makes the architecture testable. In Figure 13.1, density and bursts frames this claim: An IoT communication technology decision surface balances payload behavior, power budget, coverage, capacity, topology, interference, security boundary, and service proof. Read it against Communication.

+

The freezer alarm in Figure 13.1 turns a technology choice into linked constraints. Payload size and burst rate set traffic, while sleep and receive windows set the energy cost. Metal warehouse placement, antennas, and enclosures shape coverage; device density and alarm bursts shape capacity. Topology chooses the gateway and backhaul path, and site interference can weaken it. Identity, encryption, and key changes mark the security boundary. Installers and support staff need a way to verify and diagnose the link after mounting. The figure does not select a protocol by name; it lists the field proof needed to approve one for this site and message.

Start with these fit questions:

• Payload: How large is each message, how often is it sent, and does traffic arrive as steady reports or bursts?
• Latency: Which messages are time-sensitive, and which can tolerate delay or scheduled upload?
• Power: Is the device mains powered, rechargeable, energy harvested, or expected to run unattended for long periods?
• Coverage: Where must the link work: body area, room, building, campus, field, vehicle route, or remote site?
• Capacity: How many devices may talk at once during normal operation, alarms, recovery, or maintenance?
• Topology: Is the design point-to-point, star, mesh, gateway based, roaming, or a hybrid?
• Environment: What materials, enclosures, antennas, mounting positions, and nearby transmitters affect the link?
• Security: Where does identity, encryption, key rotation, and access control change hands?
• Service: How will installers verify the link and how will support staff diagnose later failures?

13.4 Network Scale Starts Decisions

This section: Network Scale Starts Decisions — Network labels such as PAN, LAN, MAN, and WAN are useful vocabulary, but they are too broad to make the decision alone.

Network labels such as PAN, LAN, MAN, and WAN are useful vocabulary, but they are too broad to make the decision alone. Use them to frame the scale of the problem, then test the actual link behavior and operational responsibilities.

Make the network scale starts decisions premise visible in the diagram Figure 13.2: The network scale map pairs each scale, personal area, building area, field or campus area, wide area, and device-side serial links, with the field proof that scale needs. Begin by distinguishing Network Scale Map from Field or Campus.

+

The columns in Figure 13.2 pair network scale with a different field test. A personal-area link needs pairing, battery, interference, and absent-companion behavior. A building link needs access-point placement, channel planning, alarm congestion, and maintenance access. Field or campus links put gateway placement, antenna mounting, weather, and retries in view. Wide-area links add roaming, buffering, power, identity, and support. Device-side serial links need voltage, pin, timing, capture, and debug-access checks. PAN, LAN, MAN, and WAN labels help frame distance, but they do not prove a path. Use the column for the chosen link to plan installation and recovery evidence.

13.5 Technology Families And Fit Signals

This section: Technology Families And Fit Signals — The same communication family can be a good or poor fit depending on payload, power, installation, and support context.

The same communication family can be a good or poor fit depending on payload, power, installation, and support context. Treat these as fit signals, not as permanent rankings.

Treat technology families and fit signals as a system decision around Technology family fit signals. The visual in Figure 13.3 places Small reports from low-power devices within this relationship: Communication technology families map to fit signals: short-range personal links, building networks, low-power wide-area links, wide-area service links, and device-side serial links.

+

The map in Figure 13.3 links link types to site needs; check device pins and network reach.

13.6 Coverage, Capacity, And Reliability

This section: Coverage, Capacity, And Reliability — A link can cover the site and still fail the design.

A link can cover the site and still fail the design. Coverage asks whether a signal reaches the device. Capacity asks whether the network can handle the number and timing of messages. Reliability asks whether messages arrive with enough consistency for the application and whether failures can be detected, retried, buffered, or escalated.

Use a three-part field check:

• Coverage proof: measured link quality at representative locations, orientations, enclosures, and mounting heights.
• Capacity proof: normal traffic, alarm bursts, startup storms, firmware maintenance, and gateway or access-point limits.
• Reliability proof: retry behavior, duplicate handling, message ordering, offline buffering, time synchronization, and alerting when the link degrades.

13.8 Topology And Ownership

This section: Topology And Ownership — Topology determines who owns the failure.

Topology determines who owns the failure. A point-to-point serial link may be easy to trace, but it gives no routing redundancy. A star network may simplify gateway management, but gateway placement becomes critical. A mesh can extend local reach, but each relay adds planning and support complexity. A roaming wide-area design can reduce local infrastructure, but it needs strong buffering and diagnostics when service is intermittent.

One relationship governs topology and ownership. The diagram Figure 13.4 states it as: Six communication topologies, point-to-point, star, mesh, gateway, roaming, and hybrid, each drawn as a small node-and-link diagram beside the responsibility the pattern creates. Study Communication Topology Choices and routing, power, and support cost.

+

Locate Communication Topology Choices in the diagram Figure 13.4, then compare routing, power, and support cost with data path support staff can trace. The three labels prevent a one-box topology and ownership reading. Their relevance to routing, power, and support cost is: Six communication topologies, point-to-point, star, mesh, gateway, roaming, and hybrid, each drawn as a small node-and-link diagram beside the responsibility the pattern creates.

13.9 Cold-Chain Link Choice

This section: Cold-Chain Link Choice — A cold-chain monitoring project needs temperature sensors in storage rooms, pallet tags at loading docks, vehicle gateways, and supervisor dashboards.

A cold-chain monitoring project needs temperature sensors in storage rooms, pallet tags at loading docks, vehicle gateways, and supervisor dashboards. A single communication technology would create weak points because the assets have different power, mobility, and payload patterns.

The decision separates the communication work:

• Room sensors: Low-rate telemetry, battery awareness, local obstruction checks, and alarm burst behavior.
• Loading dock tags: Short-range identification, high local density during loading, and fast association with the dock gateway.
• Vehicle gateway: Wide-area backhaul, offline buffering, identity management, antenna placement, and delivery-route coverage variation.
• Dashboard link: Building network reliability, segmentation, access control, and operational monitoring.
• Service path: Installer checklist, link-quality record, debug access, and escalation path when data stops arriving.

This is a hybrid architecture. The important proof is not a single protocol comparison table; it is a traceable record showing why each link exists, what it carries, where it can fail, and how the team will know.

13.10 Communication Decision Workflow

This section: Communication Decision Workflow — The route in Figure 13.5 starts with a message and ends with release proof; check each step.

The route in Figure 13.5 starts with a message and ends with release proof; check each step.

+

The spine in Figure 13.5 starts with the message: size, rate, direction, priority, and tolerance for delay or duplicates. The site then adds enclosure, antenna, obstruction, interference, and movement. Power limits the wake and downlink pattern, while topology names endpoints, gateways, relays, backhaul, and owners. A prototype must test representative payloads and positions. Failure capture records retries, buffering, disconnect detection, and recovery time before release proof is approved. The final record keeps firmware settings, install checks, monitoring, and support ownership together. Following each step for one link prevents a good bench radio result from becoming an unsupported site claim.

Follow this workflow for each communication link:

1. Describe the message. Record payload size, frequency, direction, priority, and whether delayed or duplicated messages are acceptable.
2. Describe the site. Record location, enclosure, mounting, antenna, obstruction, interference, and mobility assumptions.
3. Describe the power boundary. Record whether the device can stay awake, wake on schedule, recharge, or receive downlink commands.
4. Describe the topology. Record endpoint, gateway, relay, backhaul, route, and responsibility for each boundary.
5. Prototype the link. Test representative devices, payloads, positions, and traffic timing.
6. Capture failure behavior. Record retries, buffering, disconnect detection, recovery time, and alerting.
7. Approve release proof. Keep the link record, firmware settings, installation checklist, monitoring signals, and support owner together.

13.11 Communication Decision Record

This section: Communication Decision Record — A durable communication decision should leave a compact record that another engineer can reuse during deployment and incident analysis.

A durable communication decision should leave a compact record that another engineer can reuse during deployment and incident analysis.

At communication decision record, Communication Decision Record makes the architecture testable. In Figure 13.6, assumptions, and measured weak spots frames this claim: A communication decision record with eight fields: link name, payload and timing, power state, coverage and capacity, topology, security boundary, prototype result, and install and support. Read it against Communication Decision Record.

+

The diagram Figure 13.6 first names Communication Decision Record, then separates assumptions, and measured weak spots from owner, and the next review condition. Carry checkpoints assumptions, and measured weak spots and owner, and the next review condition into communication decision record with Communication Decision Record. Their combined proposition is: A communication decision record with eight fields: link name, payload and timing, power state, coverage and capacity, topology, security boundary, prototype result, and install and support.

Record these fields:

• Link name: Device-to-sensor, device-to-gateway, gateway-to-dashboard, or service-console path.
• Payload and timing: Message size, direction, reporting interval, burst behavior, and latency tolerance.
• Power state: Sleep pattern, wake trigger, receive window, charging or replacement plan.
• Coverage and capacity: Representative locations, traffic load, burst assumptions, and measured weak spots.
• Topology: Point-to-point, star, mesh, roaming, gateway, or hybrid boundary.
• Security boundary: Device identity, credential storage, encryption boundary, access role, and key rotation plan.
• Prototype result: Link-quality proof, retry proof, failure recovery, and unresolved risks.
• Install and support: Installer checks, monitoring signals, escalation owner, and next review condition.

13.12 Interaction: Choose The Field Proof

This section: Interaction: Choose The Field Proof

13.13 Match Tech Family to Fit Signals

This section: Match Tech Family to Fit Signals

13.14 Order Communication Decisions

This section: Order Communication Decisions

13.15 Common Pitfalls

This section: Common Pitfalls

13.16 Overview: Choose By Communication Job

This section: Overview: Choose By Communication Job — If you only need the shortcut, this layer is enough: do not ask which radio is best in general.

If you only need the shortcut, this layer is enough: do not ask which radio is best in general. Ask what the link must carry, how often it must carry it, where it must work, and how the device is powered.

For a cold-chain system, the answer will not be one technology name. A room temperature sensor may send a small reading every few minutes and need low sleep current, local gateway coverage, and an alarm path when a freezer warms. A dock tag may need nearby identification during a loading burst, where Bluetooth LE, NFC, or IEEE 802.15.4-style local links could be considered only after density and pairing behavior are tested. A vehicle gateway may need LTE-M, NB-IoT, cellular data, satellite, or another backhaul with route coverage, buffering, and antenna placement evidence. A supervisor dashboard may simply need Ethernet or Wi-Fi with segmentation and monitoring.

The practical beginner move is to name the communication job before naming the technology. Write one row per link: device-to-sensor, device-to-gateway, gateway-to-cloud, dashboard-to-service, and service-console-to-device. For each row, record payload size, direction, timing, acceptable delay, power state, coverage area, site obstruction, expected device count, burst case, security boundary, and who will diagnose it after installation. A technology family is a candidate only after it fits that row.

When two rows look similar, keep them separate until the tests prove they share the same failure behavior. A freezer alarm, firmware update, and periodic reading can use the same gateway but still need different approval evidence.

13.17 Practitioner: Prove The Link In Context

This section: Practitioner: Prove The Link In Context — A communication choice is ready when the team can point to representative tests, not only to a technology label.

A communication choice is ready when the team can point to representative tests, not only to a technology label. The cold-chain example needs different proof for a room sensor, dock tag, vehicle gateway, and dashboard link.

Make the link record measurable. For a radio link, capture location, antenna orientation, enclosure state, RSSI or signal-quality reading when the stack exposes it, packet delivery, retry count, duplicate handling, and time to recover after gateway restart. For a low-power device, add sleep current, wake interval, receive window, expected battery capacity, temperature effect, and the cost of an alarm burst. For Wi-Fi or Ethernet, add access-point or switch placement, VLAN or network segment, expected concurrent devices, firmware-update traffic, and what operators see when the link is degraded.

Run at least one test that resembles the worst real operating case. Put the temperature sensor in its actual enclosure, behind the expected door or wall, near compressors or pallet racks, and send the real payload on the planned interval. Exercise a loading-dock burst with many tags arriving together. Drive the gateway route or emulate the route with coverage records and offline buffering. Then hand the record to an installer or support engineer and check whether they can answer three questions: where the link should work, what failure looks like, and what action is safe.

If a record lacks units, thresholds, and sample conditions, it is not ready. A note such as "good signal" should become a measured location, device count, payload, firmware version, retry limit, and pass/fail rule.

13.18 Why Good Links Fail Later

This section: Why Good Links Fail Later — A communication link that works on the bench can fail after installation because the physical layer, traffic pattern, and support workflow have changed.

A communication link that works on the bench can fail after installation because the physical layer, traffic pattern, and support workflow have changed. The architecture decision must account for those moving parts.

Inspect Figure 13.6 before judging why good links fail later; it depicts: Keep the link record close to the failure model so later changes do not erase why the technology was approved. Focus first on Communication Decision Record, then on assumptions, and measured weak spots.

The diagram Figure 13.6 first names Communication Decision Record, then separates assumptions, and measured weak spots from owner, and the next review condition. Carry checkpoints assumptions, and measured weak spots and owner, and the next review condition into why good links fail later with Communication Decision Record. Their combined proposition is: Keep the link record close to the failure model so later changes do not erase why the technology was approved.

Most late failures are cross-layer failures. A UART service console may look reliable until a voltage-level mismatch, baud-rate assumption, missing ground reference, or exposed bootloader turns it into a support and security issue. A Wi-Fi sensor may pass a desk test but fail when roaming, metal shelving, channel congestion, or power-save behavior changes. An LPWAN-style meter may pass sparse reporting but fail when downlinks, acknowledgements, or alarm bursts exceed the duty-cycle and battery assumptions. A cellular gateway may pass a parking-lot test but lose its route when antenna placement, carrier coverage, SIM identity, or offline queue limits change.

That is why the architecture record needs both engineering and operations evidence. The engineering side names the protocol settings, timing assumptions, retry limits, buffering behavior, and credential boundary. The operations side names the installer check, monitoring signal, alert threshold, reset path, firmware-update path, and owner who can act. When any of those facts changes, the communication technology has to be reviewed again rather than treated as an invisible transport detail.

A small version table helps: record the device firmware, gateway image, antenna part, SIM profile, broker topic, and installer checklist revision used for the approval test.

• Capacity collapse: alarm bursts, reconnect storms, or firmware maintenance can overload a gateway that handled normal telemetry.
• Power mismatch: a protocol that works while plugged into a laptop may drain a sealed battery device in the field.
• Placement drift: antenna orientation, enclosure material, pallet loading, or vehicle routing can change received signal quality.
• Service blind spot: support teams cannot fix a link they cannot observe, identify, reset, or update safely.

13.19 Summary

This section: Summary — Communication technology selection is an architecture decision, not a shopping list.

Communication technology selection is an architecture decision, not a shopping list. The right choice depends on payload behavior, latency tolerance, power budget, coverage, capacity, topology, environment, security boundary, and support workflow. PAN, LAN, field-area, wide-area, and serial categories help organize the discussion, but approval requires proof from representative tests and a record that installers and support teams can reuse.

13.20 Key Takeaway

This section: Key Takeaway — Communication technology is an architectural enabler only when range, payload, latency, power, security, spectrum, and operations fit the deployment.

Communication technology is an architectural enabler only when range, payload, latency, power, security, spectrum, and operations fit the deployment.

13.21 What’s Next

This section: What’s Next — Use the next chapter to deepen the weakest part of the current communication record.

Use the next chapter to deepen the weakest part of the current communication record. The evolution overview supplies historical and architectural context, selection and energy turns constraints into a power-aware choice, and the lab route tests whether that choice survives real behavior. These are successive views of the same evidence problem, so carry the scenario, limits, and owner forward.

• IoT Evolution and Enablers Overview for the broader history and convergence of IoT enabling technologies.
• Technology Selection and Energy for energy-aware selection tradeoffs and battery-sensitive architecture checks.
• Labs and Assessment for practice applying communication, energy, and architecture field proof.