Reference Architectures · Study deck

Choosing IoT Communication Tech

Firmware is the code that runs inside a device.

Blueprint Bina is your guide for this deck.

enablerscommunicationstechnology

Blueprint Bina, the module guide, in a scene from this chapter.

After studying this chapter

Learning objectives

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.

Major section

Start With the Message Journey

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.
The message is small, but it must arrive soon, wake the right person, and still work during a busy shift.

Major section

Start With the Message Journey (continued)

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.
Under the Hood explains why good links can fail later as the site, traffic, or hardware changes.
A battery unit may need long rest.

Major section

Start With the Message Journey (continued)

A path is not complete if no one owns one of its steps.

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.

Major section

Start With the Message Journey (continued)

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.
A link that cannot be kept safe and healthy is not ready.
A new wall, gateway, radio setting, fleet size, or service owner can all end the life of old proof.

Major section

Start With the Message Journey (continued)

Long range may reduce gateway count but limit data or replies.

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

Major section

Minimum Viable Understanding

Establish range and site conditions first, then match payload rhythm and topology, check the complete power behavior, and preserve field and support evidence for the accepted path.

The principles below belong together: none of range, data rate, or nominal energy is a sufficient answer when installation, interference, retry, and ownership remain unknown.
That evidence explains why the selected topology fits while keeping rejected alternatives and retest conditions visible.
Range is only one constraint.: Coverage must be checked with capacity, building materials, antennas, mobility, duty cycle, and interference.
Payload behavior drives fit.: Small periodic measurements, bursty alarms, firmware updates, video streams, and command traffic need different communication patterns.

Major section

Phoebe's Field Notes: Why A Room Sensor And A Vehicle Gateway Want Opposite Antennas

A 3 dBi near-omni antenna is 1.995× linear gain and ideally covers $1/1.995=50.1\%$ of a sphere.

A 9 dBi vehicle antenna is 7.94× and covers 12.6%.
That extra reach exists only inside the narrower direction.

Major section

Communication as Architecture

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.
Selection rule:: A communication technology is not approved by category name.

An IoT communication technology decision surface balances payload behavior, power budget, coverage, capacity, topology, interference, security boundary, and service proof.

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

This supports network scale starts decisions.
Typical proof includes pairing behavior, local interference, battery behavior, privacy boundary, and what happens when the companion device is absent.

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.

Major section

Network Scale Starts Decisions (continued)

The visual summarizes: 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.

Typical proof includes access-point placement, cabling options, handoff behavior, channel planning, congestion during alarms, and local maintenance workflow.
Typical proof includes gateway placement, antenna mounting, reporting interval, retry behavior, weather exposure, and maintenance access.
Typical proof includes roaming behavior, outage handling, data buffering, power draw, identity management, and support responsibility.
Typical proof includes voltage level, pin map, baud or clock settings, signal capture, recovery behavior, and debug access control.

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

They fit local pairing, commissioning, tags, wearables, nearby controls, and low-power accessory links.
They fit cameras, gateways, dashboards, controllers, and devices with local power or cabling.

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.

Major section

Coverage, Capacity, And Reliability

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.

Major section

Topology And Ownership

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.
Study Communication Topology Choices and routing, power, and support cost.

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.

Major section

Topology And Ownership (continued)

Proof must include gateway placement, device registration, capacity during bursts, backup behavior, and operational monitoring.

The three labels prevent a one-box topology and ownership reading.
Proof must include pinout, signal settings, framing, and safe service access.
Proof must include buffering, identity, coverage variation, antenna placement, link-state reporting, and how delayed messages are handled.

Major section

Topology And Ownership (continued)

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.

Proof must include route stability, relay power budget, self-healing behavior, firmware compatibility, and what happens when relay nodes move or fail.
Proof must include boundary ownership and a data path that support staff can trace.
A roaming wide-area design can reduce local infrastructure, but it needs strong buffering and diagnostics when service is intermittent.

Major section

Communication Decision Record

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.

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.

Deck summary

Key takeaways

Firmware is the code that runs inside a device.

High speed may cost more power.
A path is not complete if no one owns one of its steps.
Some units send at once after power returns.
Long range may reduce gateway count but limit data or replies.

Retrieval practice

Recall check 1 of 3

Blueprint Bina says: answer from memory, then check your reasoning.

Q1A cold-chain project needs room temperature sensors, loading-dock tags, vehicle gateways, supervisor dashboards, and a service path. Which first check keeps the communication technology choice traceable?

AApprove the longest advertised range and treat it as proof of capacity, power, security, and support.

BUse one bench connection to approve room sensors, dock tags, vehicle gateways, dashboards, and service tools.

CWrite per-link records for payload, latency, power, coverage, capacity, topology, security, tests, installers, monitoring, and support.

DPostpone gateway placement, identity handoff, buffering, installer checks, retry policy, and support ownership until rollout.

Show answer

Answer: C A traceable communication technology decision proves each link's payload, latency, power, coverage, capacity, topology, security, install, monitoring, and support behavior before the technology choice becomes a rollout dependency.

Retrieval practice

Recall check 2 of 3

Blueprint Bina says: answer from memory, then check your reasoning.

Q2A battery-powered field sensor sends small environmental readings and can tolerate delayed delivery. What proof should be checked before approving the communication technology?

ACheck only the maximum advertised data rate of the selected technology family.

BCheck coverage, capacity, payload timing, power, retries, security boundary, and site results.

CCheck only whether the link is classified as PAN, LAN, MAN, or WAN.

DCheck only whether the device connects during a short bench test.

Show answer

Answer: B Communication field proof must connect the technology family to the real deployment conditions: payload, latency, power, coverage, capacity, topology, interference, retries, and support workflow.

Retrieval practice

Recall check 3 of 3

Blueprint Bina says: answer from memory, then check your reasoning.

Q3A cold-chain team tests one temperature sensor on a bench, then wants to approve the same communication technology for room sensors, dock tags, vehicle gateways, and dashboards. What should block approval?

AApprove it because one bench connection proves every cold-chain link uses the same constraints.

BCheck only dashboard traffic because powered links always create the highest communication risk.

CCheck only advertised range because range includes capacity, power, security, and serviceability.

DBlock approval until each link has site, payload, burst, power, antenna, security, and support proof.

Show answer

Answer: D Each communication job has different physical, traffic, power, and operational constraints.

Print reference

Answers

Answer key.

C · A traceable communication technology decision proves each link's payload, latency, power, coverage, capacity, topology, security, install, monitoring, and support behavior before the technology choice becomes a rollout dependency.
B · Communication field proof must connect the technology family to the real deployment conditions: payload, latency, power, coverage, capacity, topology, interference, retries, and support workflow.
D · Each communication job has different physical, traffic, power, and operational constraints.