2 Choosing a Wireless Technology
mobile wireless technologies basics, IoT wireless technology selection, Wi-Fi Bluetooth LPWAN cellular comparison, wireless evidence review, bounded wireless recommendation
2.1 Start With the Wireless Story
Begin with the device job, not the radio label. A tracker, meter, gateway, or handheld each needs a different mix of range, bandwidth, ownership, battery life, and approval evidence, so the wireless choice starts by naming what the device must prove in the field.
2.2 Begin With the Device Job
Mobile wireless technology selection is not a popularity contest between Wi-Fi, Bluetooth LE, IEEE 802.15.4 networks, LPWAN, cellular, RFID, NFC, UWB, ANT/ANT+, Zigbee, or Thread. A defensible choice starts with the device job, then checks the radio environment, network ownership, power and reachability needs, validation evidence, and retest triggers.
The strongest early question is not “which radio is best?” It is “what must this device class prove before the wireless path can be approved?” That framing keeps a technology label from hiding weak coverage, unclear operations ownership, unsuitable power behavior, or missing maintenance evidence.
The first split is about operating shape. A tap or inventory workflow usually needs proof of reader placement, tag orientation, and data scope. A wearable or nearby sensor needs proof of commissioning, pairing or joining, interference behavior, sleep timing, and replacement process. A local IP device needs proof of coverage, credentials, updates, roaming or reconnect behavior, and the owner of the access network. A wide-area device needs proof of installed coverage, service lifecycle, downlink expectations, and who responds when the public or private service path changes.
ANT and ANT+ belong in this comparison as narrow personal-area choices, not as generic low-power replacements. They can fit sport, fitness, and equipment telemetry when the device profile, hub or phone support, pairing policy, coexistence with BLE or Wi-Fi, and battery evidence are known. If the receiving ecosystem is uncertain, choose a more widely supported family or prove the bridge path before approving the radio label.
Write that evidence before naming the winner. “Use BLE” is not a decision until the reviewer knows range, body placement, phone or gateway availability, bonding or provisioning rules, and battery budget. “Use cellular” is not a decision until the reviewer knows operator support, profile lifecycle, antenna/enclosure state, traffic pattern, downlink timing, and support ownership. A good shortlist states which family is plausible, what must be measured next, and what would make the family unacceptable.
If you only need the intuition, this layer is enough: write the deployment claim so it can be tested, collect device and site evidence, shortlist candidate families, and approve only the conditions that were actually validated.
2.2.1 The First Review Split
2.2.2 Device Class
Name the role, payload, update interval, command need, mobility pattern, power source, enclosure, and expected lifetime.
2.2.3 Installed Path
Check coverage, interference, antenna position, network policy, gateway or service ownership, and recovery behavior in representative locations.
2.2.4 Bounded Decision
Approve the family, approve it with limits, request more evidence, or redesign with explicit exclusions and retest triggers.
2.2.5 Useful Family Intuition
- Close interaction: NFC and many RFID designs fit intentional tap, badge, inventory, and reader-style workflows when placement and data scope are clear.
- Personal and local networks: Bluetooth LE, ANT/ANT+ device profiles, plus Zigbee, Thread, and other IEEE 802.15.4-based designs, can fit nearby sensors, wearables, controls, and building devices when commissioning, sleepy behavior, interference, and maintenance are proven.
- Local-area networks: Wi-Fi can fit devices that benefit from IP connectivity, local services, richer traffic, diagnostics, or updates when power, coverage, security, and support ownership are validated.
- Wide-area services: LPWAN and cellular families can fit wider reachability needs, but coverage maps, service plans, gateway placement, downlink behavior, SIM lifecycle, and support ownership still need evidence.
2.2.6 Telephony Goes Wireless
The older question “why would anyone walk around with a phone?” is a useful requirements test. A cordless phone proved the first mobility job at room or home scale: the handset could leave the wall jack, but the base station still anchored the service. Early consumer cordless designs used separated allocations such as 27 MHz, 49 MHz, and later 900 MHz, so the review problem was local interference, handset range, battery, and whether the base could reach the wired telephone line. That is a very different claim from mobile service across a city.
Cellular networks changed the proof. Mobility became a coverage and handoff problem built from many base stations, not one loud transmitter. Hexagon diagrams are planning shorthand for cells, frequency reuse, and neighboring coverage; the real site may be a tower, rooftop, or camouflaged pole, and the approved design still depends on measured signal, capacity, mobility, and service ownership. The AT&T lesson for IoT is to treat wireless as a new operating model, not merely a cordless version of an older wired product.
2.2.7 Overview Knowledge Check
2.3 Build the Wireless Fit Record
A practical review record turns “use this wireless technology” into evidence that another reviewer can inspect. It should show what the device must do, where it operates, who owns the network path, what validation was run, and what change would invalidate the approval.
Use the same record for early design, pilot review, and failure diagnosis. Early design may list assumptions and required tests. A pilot should replace assumptions with installed measurements, join or reconnect observations, coverage notes, power traces, support procedures, and fault records.
2.3.1 Worked Review: Building Sensor Retrofit
A building team wants every new sensor to use the same Wi-Fi network used by laptops. Some devices are powered, some are battery powered, and several are mounted inside metal equipment rooms and riser cabinets. The correct response is not automatic approval or automatic rejection. The reviewer should split the device classes, check installed coverage and policy, and validate commissioning, segmentation, power, replacement, and fault response in representative spaces.
2.3.2 Worked Review: Moving Service Asset
A city maintenance tool sends small messages and moves through depots, streets, and service vehicles. Reusing the low-power network that worked for stationary sensors is not proven until route coverage, reconnect behavior, charging workflow, command reachability, storage state, and service ownership are tested for the moving device class.
2.3.3 Practitioner Knowledge Check
2.4 Why Technology Labels Mislead
Wireless labels hide several different layers of evidence. A device can have a suitable radio family and still fail because the antenna is shadowed by the enclosure, the network owner cannot rotate credentials safely, downlink behavior is too constrained for updates, the gateway backhaul is unreliable, or the power budget ignores reconnect and support states.
The under-the-hood review separates physical path, link behavior, network service, application workflow, and operational ownership. That separation keeps a failure report from collapsing into a vague statement such as “the wireless network is bad.”
2.4.1 Diagnosis Pattern
- Preserve the symptom. Record device state, location, enclosure, owner, firmware, traffic, power state, and recent changes.
- Name the first unproven boundary. Do not jump from a failed message directly to a new wireless family.
- Change one variable at a time. Mixing antenna, firmware, gateway, credentials, and server changes makes evidence hard to trust.
- Update the decision record. Mark what is approved, what is excluded, and which future change requires retest.
2.4.2 Under-the-Hood Knowledge Check
2.5 Summary
- Mobile wireless selection starts with the device class and deployment claim, not with a favorite technology family.
- A defensible recommendation records application needs, installed radio conditions, network ownership, validation evidence, and retest triggers.
- Family intuition is useful only when it is tied to proof: close interaction, local networking, LAN integration, LPWAN, and cellular each need different evidence.
- Telephony’s move from cordless handsets to cellular service shows why mobility changes the evidence from local range to coverage, handoff, frequency reuse, and service ownership.
- Mixed deployments often need multiple wireless paths under shared security, monitoring, ownership, and maintenance governance.
- Troubleshooting is faster when failures are routed to a boundary: physical path, link behavior, network service, application workflow, or operations ownership.
Approve a mobile wireless technology only for the device class, location, owner model, firmware, enclosure, traffic pattern, and recovery behavior that were actually validated.
2.6 See Also
Mobile Wireless Design Considerations
Turn the technology fit record into a validation plan for coverage, traffic, ownership, and maintenance.
Electromagnetic Waves and Spectrum
Connect frequency, wavelength, antenna placement, obstacles, and propagation behavior to the installed path.
IoT Wireless Frequency Bands
Review band choice, coexistence, regional constraints, and placement evidence before approving a radio path.
Propagation and Licensing
Check how licensed, unlicensed, and managed service assumptions shape coverage, operations, and retest scope.
