Start with the information journey
Connectivity is not a product feature in isolation. It is the path between an event at the device and the person or system that depends on the resulting information. Before comparing radios or data plans, define what travels across that path and why.
Record the message size, expected frequency, acceptable delay, required direction of communication and consequence of a missing update. A small status message every hour creates a different design problem from frequent telemetry, remote configuration or a time-critical alert.
Describe the operating environment
A technology that works in an office may be unsuitable for a moving asset, remote field or metal enclosure. Consider geographic coverage, indoor penetration, mobility, infrastructure ownership, installation, interference and whether the product must work at sites the operator does not control.
- Will the device remain on one managed site or move across wide areas?
- Can the customer provide and maintain local network infrastructure?
- Does the installation sit indoors, underground, inside equipment or in an exposed location?
- How does antenna position change during normal use?
- Which countries, networks or frequency rules apply?
Compare the main connectivity shapes
Cellular
Cellular can support mobile or widely distributed products without requiring customer-managed gateways at every location. Coverage, network availability, power demand, subscription design and radio certification still need to be understood. Multi-network access may improve the opportunity to connect but cannot guarantee uninterrupted service.
Wi-Fi
Wi-Fi can be appropriate where trusted infrastructure, credentials and local support already exist. Provisioning, captive portals, password changes and ownership of the network often matter as much as radio range.
LoRaWAN and other low-power wide-area networks
Low-power wide-area technologies can suit small, infrequent messages and long battery targets. Gateway availability, downlink limits, latency and the network model must fit the use case.
Bluetooth and other short-range links
Short-range communication can work well for commissioning, nearby sensors or a product that deliberately uses a phone or gateway as its onward connection. The operational dependency on that nearby device must be explicit.
Power and connectivity are one design problem
Network searches, connection attempts and transmission consume energy. Poor signal can make that cost unpredictable. Reporting frequency, local processing, retry policy, sleep behaviour and battery capacity therefore need to be considered together rather than optimised independently.
The lowest-power radio on a data sheet is not automatically the lowest-power system in the intended environment.
Design offline behaviour before promising “live”
Every communications path can be interrupted. Decide what the device continues to measure, how much data it retains, how retries are paced and what happens after service returns. The cloud application should expose the age and source of its latest information so a user can distinguish current status from a last-known value.
Offline storage can preserve later history; it cannot give the platform live knowledge during an outage. Alternative escalation or communication routes may still be required where timing is critical.
Prototype the risky part
A connectivity prototype should test representative locations, installation, power behaviour and message patterns. A strong test captures successful and failed attempts, signal context, energy use, latency and recovery, not only whether one message arrived during a demonstration.
The decision may also be a hybrid: one technology for wide-area reporting, another for local commissioning, and local storage to bridge normal interruptions. Choose the simplest architecture that meets the defined operational requirement and can be supported throughout the product lifecycle.