IoT connectivity explained

Ranges cannot be reduced to one universal number: frequency, antenna, obstructions, output power, network design and regulation all matter. Compare technologies through field tests, not maximum figures from a data sheet.

Cellular is useful for distributed or moving devices that cannot depend on site-owned infrastructure. A Subscriber Identity Module (SIM) authenticates the device to a mobile network operator. LTE-M and Narrowband IoT (NB-IoT) serve low-power applications; LTE Cat-1 and Cat-1 bis support moderate throughput; higher LTE and 5G categories serve routers and video.

Tradeoffs include recurring service cost, operator-specific coverage, radio certification and greater transmission energy than many short-range radios. Low-Power Wide-Area (LPWA) availability differs by country and operator. See cellular IoT and verify exact radio bands and features for every market.

Wi-Fi works well when a device is on controlled premises with managed access points, mains power and a reliable onboarding process. Consumer credentials and changing routers can create support work. Enterprise Wi-Fi can offer stronger management, but the product owner may not control it.

Bluetooth Low Energy (BLE) is appropriate for nearby sensors, accessories and commissioning through a phone or gateway. It is not itself a wide-area backhaul. Wired Ethernet and industrial buses provide predictable local performance and avoid radio propagation issues, but installation cost and lack of mobility can dominate.

These options are often combined: BLE to a phone, sensors to an industrial gateway, or Wi-Fi with cellular backup. Map ownership of every link and define behavior when the gateway or upstream service fails.

LoRaWAN is an open LPWA networking protocol designed for small messages over long radio links in unlicensed spectrum. It can be deployed with privately owned gateways or a network service. It favors low duty cycle and long battery life rather than high throughput or continuous control. Capacity, regional frequency plans and gateway placement require engineering.

Satellite can reach assets beyond terrestrial service, but a device may need a suitable antenna orientation or view of the sky. Message size, session timing, energy and service capability vary by provider and constellation. Satellite is therefore frequently used for remote telemetry or as a secondary path, not assumed to behave like terrestrial broadband.

3GPP also standardizes Non-Terrestrial Networks (NTN). Support in a standard does not establish availability on a particular module, operator or country; verify the complete commercial chain.

Create a requirements matrix before talking to suppliers:

1. Geography: exact countries, indoor depths, rural routes and restricted environments.
2. Traffic: payload, frequency, downlink, update size and worst-case retries.
3. Power: source, battery chemistry, temperature and target service interval.
4. Mobility: speed, border crossing and tolerance for interrupted sessions.
5. Performance: latency, throughput, availability and recovery objectives.
6. Control: who owns gateways, credentials, addressing and configuration.
7. Lifecycle: certifications, technology roadmap, updates and replacement access.
8. Economics: hardware, installation, service, support and truck rolls.

Weight these criteria by consequence. A lower-cost link that causes one additional site visit may be uneconomic. Conversely, a local gateway can be sensible for hundreds of nearby low-data sensors.

The access network is only one layer. Message Queuing Telemetry Transport (MQTT), Constrained Application Protocol (CoAP), Hypertext Transfer Protocol (HTTP) and vendor protocols add different headers, connection behavior and security handshakes. Transmission Control Protocol (TCP) retransmits lost segments, while User Datagram Protocol (UDP) leaves reliability to the application.

Measure billable bytes and energy on the production protocol. Include Domain Name System lookups, keepalives, Transport Layer Security handshakes, acknowledgements, roaming signaling and failed attempts. Batch readings where latency allows, compress carefully, and avoid frequent reconnects. Use the IoT data usage calculator for an initial model, then replace assumptions with pilot measurements.

Treat published specifications and supplier documentation as a starting point, not proof that a design will work in every target location. Build a representative test set covering the countries, operators, radio conditions, device firmware, antennas, power sources and backend routes that production devices will encounter.

Start with a written traffic and operating profile. Record payload sizes, message frequency, acceptable latency, mobility, expected device life, firmware-update size and behavior after an outage. Test normal operation as well as weak signal, loss of service, exhausted data allowance, expired credentials, a network change and a backend that is temporarily unavailable. Long retry loops can consume more energy and data than the normal application.

Use a pilot large enough to reveal variation between buildings, regions and networks. Capture attach success, time to first data, session failures, round-trip latency, retransmissions, radio measurements, energy use and data counted by both device and provider. The recommendation is to define acceptance thresholds before the pilot, then retain the evidence used to approve the production design.

Commercial and technical validation should happen together. Confirm which networks, countries, features and support functions are included in writing. Check how subscriptions are activated, suspended, exported and terminated; how alerts work; what happens at contractual limits; and whether the device can be moved to another provider if circumstances change. A low headline rate does not compensate for an unsuitable radio, inaccessible diagnostics or a design that requires field replacement.

Connectivity is a lifecycle responsibility rather than a one-time component purchase. Assign owners for provisioning, inventory, usage monitoring, incident response, security updates and retirement. Keep the device identifier, subscription identifier, hardware revision, firmware version, deployment location and responsible customer or business unit linked in an inventory system.

Set alerts for unexpected activation, prolonged silence, unusual usage and repeated network sessions. The right threshold depends on the application: silence from a monthly meter is different from silence from a safety alarm. Document who investigates each alert and which evidence is available from the device, connectivity platform and application.

Plan controlled firmware updates, including staged rollout, rollback and recovery from interrupted downloads. Budget for protocol overhead and retries rather than payload bytes alone. Review operator technology roadmaps and regulatory requirements during the service life, especially for products sold into multiple countries. For a structured launch review, use the IoT deployment checklist.

Finally, design an exit path. Record whether hardware supports another profile, SIM or radio technology; how data and identifiers can be exported; and how credentials are revoked at end of life. This is a recommendation for resilience, not a claim that every deployment needs multiple providers.