The Complete Guide to IoT Connectivity: Choosing the Right Technology

The right IoT connectivity technology is the one that meets the product’s real operating constraints for its full life. Start with data volume, power, coverage, mobility and ownership. Then test the shortlist against security, regulation, supplier support and total cost.

There is no single best IoT network. A battery-powered soil sensor, a moving asset tracker, a smart lock and an industrial camera have very different needs. A technology that works well for one can make another product expensive, unreliable or difficult to support.

This guide is for engineers, solution architects, product teams and technical decision-makers who need to choose a practical connectivity approach. It covers the main wired, short-range, local-area, low-power wide-area, cellular and satellite options. It also explains the questions that matter more than headline range or data-rate figures.

Quick answer: If a cable is practical, start by considering Ethernet. For high-throughput wireless on a managed site, compare Wi-Fi and private cellular. For mobile or widely distributed devices, compare LTE-M, NB-IoT and other cellular options. For small, infrequent messages on a private long-range network, consider LoRaWAN. For low-power local networks, compare Bluetooth LE, Thread and Zigbee. Where terrestrial coverage is unavailable, add satellite or 3GPP non-terrestrial networking to the shortlist.

Choose the operating model before the radio

Many connectivity decisions start with a list of radio technologies. That is usually too early. First decide who will own and operate the network.

There are three common models:

Use infrastructure that already exists. A product connects to the customer’s Ethernet or Wi-Fi network. Hardware and airtime costs can be low, but installation depends on the customer’s network, credentials and security policy.
Build or manage a private network. You deploy gateways, access points or private cellular infrastructure. This gives you more control, but your organisation becomes responsible for coverage, capacity, resilience, security and maintenance.
Buy connectivity as a service. A mobile, satellite or managed LPWAN provider operates the wide-area network. Deployment is simpler in covered areas, but the product inherits supplier, roaming, tariff and contract dependencies.

This decision affects far more than the radio module. It changes installation, support, security ownership, recurring cost and what happens when the commercial relationship ends.

The eight questions that narrow the choice

1. How much data must the device send?

Be specific. Record the normal message size, frequency, daily total, peak burst and largest software update. A sensor that sends 20 bytes every hour has different needs from a camera, even if both are described as “low data” during an early product discussion.

Do not size only for telemetry. Allow for device commissioning, acknowledgements, diagnostics, certificate renewal and firmware updates. A link that handles normal readings but cannot deliver a security update is not a complete design.

2. What latency and reliability does the application need?

Ask how quickly a message must arrive and what happens if it does not. Environmental monitoring may tolerate minutes of delay and occasional retries. Access control, safety alarms or closed-loop automation may require a much tighter and more predictable response.

No wireless technology guarantees reliability by itself. Performance depends on link budget, interference, network capacity, antenna design, installation, protocol settings and the retry behaviour of the application.

3. What is the power source and service interval?

Mains-powered devices can use technologies and connection patterns that are unsuitable for a small battery. For battery designs, model the complete energy budget:

sleep current;
wake-up and network-registration energy;
transmit and receive time;
failed connection attempts;
temperature and battery ageing;
firmware downloads;
expected coverage at the worst installation point.

Battery-life claims based on ideal coverage and successful first-time transmissions can be badly misleading.

4. Where must the device work?

“Nationwide coverage” is not the same as coverage inside a plant room, underground meter box or steel enclosure. Check every intended market and installation type.

For unlicensed spectrum, frequency, transmit-power and duty-cycle rules vary by region. Ofcom notes that UK short-range devices normally operate on a licence-exempt, low-power, non-protected basis. They must accept that other lawful users can share the band. Other markets have their own rules and band plans. (Ofcom)

5. Is the device fixed or moving?

Mobility can change the shortlist. A fixed utility meter and an asset tracker crossing operator and national borders may both need a wide-area connection, but they place different demands on handover, roaming, location services and profile management.

If a device will move globally, confirm where the supplier can lawfully and technically provide service. Check permanent-roaming restrictions, local breakout, traffic routing, eSIM or iSIM support and how profiles can be changed during the product’s life. See eSIM Explained: What It Changes for IoT Deployments for the provisioning standards behind this decision.

6. Can you install gateways or access points?

A private network can be an excellent fit for a factory, farm, building or campus. It can also create an operational burden that was missed in the product business case.

Count the gateways, their backhaul links, power supplies, mounting work, spares, monitoring, software maintenance and site visits. Decide who owns each task. A low-cost end-device radio does not automatically produce a low-cost system.

7. What is the expected product life?

Connected products often outlast mobile contracts, cloud services and individual module families. Check:

the expected life of the network technology;
operator support in every target market;
module and chipset roadmaps;
certification and regulatory maintenance;
whether credentials or network profiles can be changed;
the exit process if a supplier closes or the contract ends.

The GSMA’s February 2026 Mobile IoT Deployment Guide says LTE-M and NB-IoT are part of the global 5G standard and are expected to remain in service into the 2030s and beyond. It also makes clear that feature availability and deployment remain operator-dependent. (GSMA Mobile IoT Deployment Guide)

8. What does the whole system cost?

Compare total cost over the planned service life, not only the module or monthly tariff.

Include:

radio module, antenna and SIM or eSIM hardware;
certification and testing;
gateways, backhaul and installation;
network, platform and profile-management charges;
power supply or battery replacement;
support and field visits;
cloud traffic and data retention;
migration or supplier-exit costs.

The cheapest radio can become the most expensive option if it adds gateways, truck rolls or product variants.

IoT connectivity technologies compared

The descriptions below are practical starting points. Actual range, power, data rate and capacity depend on the implementation and operating environment.

Technology	Typical strength	Main limitation	Infrastructure model	Often suits
Ethernet	High reliability, capacity and predictable operation	Requires cabling and usually fixed installation	Private or customer-owned	Industrial equipment, gateways, controllers, cameras
Conventional Wi-Fi	High throughput and widespread infrastructure	Higher power, shared spectrum and customer-network dependency	Customer or site-owned	Cameras, appliances, displays, powered sensors
Wi-Fi HaLow	Longer-range, sub-1 GHz Wi-Fi aimed at IoT	Device ecosystem and regional support need checking	Private or managed	Buildings, farms, campuses and industrial sites
Bluetooth LE	Low power and direct smartphone support	Local range and phone or gateway dependency	Personal or private	Wearables, commissioning, accessories, beacons
Thread	Low-power IPv6 mesh	Needs a Thread Border Router and an application layer	Private	Smart home and building sensors, controls and Matter devices
Zigbee	Mature low-power mesh ecosystem	Usually needs a coordinator or gateway and non-IP translation	Private	Lighting, building automation, smart-home devices
LoRaWAN	Long-range, low-power communication for small messages	Low throughput, duty-cycle constraints and gateway planning	Private, community or managed	Metering, agriculture, environment and campus monitoring
NB-IoT	Low-power cellular with strong coverage characteristics	Throughput, mobility and roaming support vary	Operator-managed	Fixed meters, utilities and low-rate monitoring
LTE-M	Cellular IoT with mobility and more data capability than NB-IoT	Module, tariff and coverage availability vary	Operator-managed	Trackers, alarms, wearables and mobile equipment
LTE Cat 1 bis	Mid-rate LTE using existing 4G infrastructure and a single receive antenna	More power than LPWA and tied to the LTE network lifecycle	Operator-managed	Trackers, payment terminals, alarms and mid-rate devices
4G/5G broadband	High throughput, mobility and public coverage	Higher power, module cost and tariff use	Operator-managed or private	Video, routers, vehicles and complex equipment
5G RedCap	Reduced-complexity 5G for mid-tier devices	Commercial coverage and module choice remain market-dependent	Operator-managed or private	Industrial devices, wearables, video and mid-rate equipment
Satellite or 3GPP NTN	Coverage beyond terrestrial networks	Sky view, latency, power, cost and maturity vary	Provider-managed	Maritime, remote infrastructure, agriculture and global tracking

Wired Ethernet: the option that is too often skipped

If the device is fixed, powered and close to network infrastructure, Ethernet deserves to be the baseline. It avoids radio-coverage uncertainty, supports high data rates and can provide power through Power over Ethernet in suitable designs.

Its drawbacks are physical. Cable routes, connectors and installation labour cost money. Mobile or frequently repositioned products may rule it out. Industrial environments may also require rugged connectors, electrical isolation, redundancy or time-sensitive networking features.

Shortlist Ethernet when: reliability and capacity matter, cabling is practical and the device is fixed.

Be careful when: installers cannot control the cable route, electrical conditions are harsh or the product must be moved regularly.

Wi-Fi: high throughput using local infrastructure

Conventional Wi-Fi is a strong fit for powered devices that need more data than low-power networks can sensibly carry. It is widely available in homes and businesses, and it gives devices native IP connectivity.

The main product challenge is not usually radio availability. It is dependence on a network that the product maker may not control. Credentials change. Enterprise networks use different authentication and segmentation policies. Access points are replaced. Some customers will not allow unmanaged IoT devices onto the main network.

Plan for onboarding, credential rotation, captive-portal avoidance, network diagnostics and recovery when the access point disappears.

Wi-Fi HaLow

Wi-Fi HaLow is based on IEEE 802.11ah and uses sub-1 GHz spectrum. It is intended to extend Wi-Fi towards longer-range, lower-power IoT applications. The Wireless Broadband Alliance describes the technology as offering better penetration and outdoor range beyond one kilometre in suitable conditions, while stressing that real performance depends on deployment. (Wireless Broadband Alliance)

HaLow can be attractive where ordinary Wi-Fi lacks reach but an IP-based private network is still useful. Check regional spectrum support, certified device availability and the maturity of the module and access-point ecosystem before committing.

Shortlist Wi-Fi when: the device is powered, needs medium or high throughput and can use a known local network.

Shortlist HaLow when: you control a site and want longer-range IP connectivity with more throughput than small-payload LPWAN technologies.

Bluetooth LE: low power with direct phone support

Bluetooth Low Energy operates in the 2.4 GHz band and supports point-to-point, broadcast and mesh topologies. It is particularly useful when a smartphone, tablet or local gateway can be part of the design.

The Bluetooth SIG defines several physical-layer modes. They trade speed for range, from 2 Mbit/s down to coded 125 kbit/s modes. Real range can vary from less than a metre to well beyond typical room-scale use, depending on power, antenna, receiver sensitivity, environment and selected PHY. (Bluetooth LE Primer, Understanding Bluetooth Range)

Bluetooth LE works well for commissioning even when it is not the main operational link. A phone can pass Wi-Fi credentials or claim a device, after which the product uses another network.

Shortlist Bluetooth LE when: direct phone interaction, very low power, local sensing, beacons or commissioning matters.

Be careful when: the product needs independent wide-area connectivity or predictable operation beyond the local gateway.

Thread and Zigbee: low-power mesh for homes and buildings

Thread and Zigbee both commonly use IEEE 802.15.4 radios, but they solve different parts of the stack.

Thread is an IPv6-based low-power mesh networking protocol. It connects a Thread network to the wider IP network through a Border Router. Thread Group describes it as a secure, low-energy, IPv6-based protocol designed for connected homes and buildings. (Thread overview)

Zigbee is a mature full-stack technology with a large installed ecosystem in smart homes, commercial buildings and energy applications. The Connectivity Standards Alliance highlights its power efficiency, mesh networking and support for large networks. (Connectivity Standards Alliance)

Matter is often confused with the network itself. Matter is an application-layer protocol that can run over Wi-Fi, Thread and Ethernet, while Bluetooth LE is used during setup. Choosing Matter does not remove the need to choose an underlying connection. (Matter FAQ)

Shortlist Thread when: you want an IP-based low-power mesh, particularly for Matter, connected-home or building products.

Shortlist Zigbee when: compatibility with an established Zigbee ecosystem, profile or deployment is important.

Be careful when: battery-powered routers are expected to relay constantly, radio coexistence is poor or a gateway dependency has not been included in the support model.

LoRaWAN: long range for small, infrequent messages

LoRaWAN is designed for low-power wide-area networks using unlicensed spectrum. The LoRaWAN specification is optimised for battery-powered end devices and supports multiple device classes that trade receive availability against energy use. (LoRa Alliance specification)

It can be a strong fit for agriculture, utilities, environmental monitoring and private campus networks. You can operate your own gateways or use a community or commercial network where available.

The trade-off is throughput. LoRaWAN is not intended for video, large frequent transfers or chatty protocols. Capacity planning must consider message size, spreading factor, channel use, acknowledgements and local duty-cycle rules. Downlink capacity deserves special attention if the product needs frequent commands or large updates.

Shortlist LoRaWAN when: devices send small messages, need long battery life and can use a private or managed gateway footprint.

Be careful when: the application needs large downlinks, tight latency, high message frequency or continuous mobility across many networks.

Cellular IoT: public coverage without owning gateways

Cellular connectivity is often the cleanest operational model for widely distributed products. The device connects directly to an operator network, so the product maker does not have to install a local gateway at every site.

That convenience introduces dependencies on coverage, roaming, tariffs, SIM provisioning, radio certification and operator feature support.

NB-IoT

NB-IoT is aimed at low-power, low-data-rate applications with extended coverage. It is often considered for meters, utility equipment and fixed monitoring devices.

It is not simply a slower version of ordinary mobile broadband. Power-saving features, mobility behaviour, roaming and protocol support must be validated against the selected operator and module. The GSMA deployment guide treats NB-IoT and LTE-M as complementary, not interchangeable. (GSMA Mobile IoT Deployment Guide)

LTE-M

LTE-M supports low-power IoT while providing more data capability and stronger mobility support than NB-IoT in many deployments. It is often a better starting point for trackers, mobile assets, alarms and products that need more regular two-way communication.

Do not assume coverage follows ordinary 4G coverage. Ask for LTE-M coverage, roaming and feature support by country and operator.

LTE Cat 1 and Cat 1 bis

LTE Cat 1 is a 4G category used by many mid-rate IoT products. Cat 1 bis reduces the hardware requirement to one receive antenna, which can simplify small and cost-conscious designs. It uses standard LTE infrastructure rather than requiring an operator to activate LTE-M or NB-IoT features.

It is not classed as an LPWA technology, and its power and coverage characteristics differ from LTE-M and NB-IoT. The GSMA also notes that Cat 1 and Cat 1 bis remain tied to the lifetime of LTE networks rather than carrying the same 5G longevity position as LTE-M and NB-IoT. (GSMA, Mobile IoT in a 5G Future)

4G and full 5G

Conventional 4G and 5G modules suit products that need higher throughput, low latency, mobility or direct internet access. They also tend to require more power, more capable hardware and a larger data budget.

Use them when the application needs the capability. Do not select full 5G only because it sounds more future-proof.

5G RedCap

5G Reduced Capability, or RedCap, was introduced in 3GPP Release 17. It sits between low-power massive IoT technologies and full 5G broadband. The design reduces device complexity while retaining more throughput than traditional LPWA options. Enhanced RedCap was added in Release 18. (3GPP)

RedCap is relevant to industrial devices, wearables, video and other mid-tier applications, but availability remains a practical constraint. Check operator deployment, bands, roaming, module maturity and certification in each target market.

Shortlist cellular when: products are distributed, mobile or difficult to reach, and buying public coverage is preferable to installing gateways.

Be careful when: the business case assumes global coverage from one contract without country-level validation.

Satellite and 3GPP non-terrestrial networks

Satellite connectivity can cover maritime, rural and remote locations that terrestrial networks do not reach. Traditional satellite IoT services use provider-specific radios and protocols. The market is also moving towards 3GPP non-terrestrial networks, or NTN, which extend cellular standards to satellite and other non-terrestrial infrastructure.

3GPP Release 17 includes IoT over NTN for NB-IoT and LTE-M. The GSMA advises product and network teams to monitor real product and operator support because several NTN features are still moving from specifications into deployable services. (GSMA Mobile IoT Deployment Guide, GSMA Hybrid Cellular/NTN Guide)

Sky view, antenna orientation, message timing, latency, energy use and commercial availability all need testing. Some services use store-and-forward operation rather than continuous real-time coverage.

Shortlist satellite or NTN when: terrestrial coverage gaps are a real product requirement, not an occasional edge case.

Be careful when: the specification assumes indoor operation, low latency, continuous visibility or terrestrial-like power use without field evidence.

Other specialist options

The main shortlist covers many connected-product decisions, but some sectors use more specialised technologies.

Wi-SUN FAN is an IPv6 field-area mesh used in large outdoor utility and smart-city networks. It can be a strong option where a dense, privately operated mesh and an established utility ecosystem are required. (Wi-SUN Alliance)
Z-Wave is a sub-1 GHz mesh technology focused on residential and light-commercial control, monitoring and status applications. Its regional frequencies and ecosystem should be checked early. (Z-Wave Alliance)
DECT-2020 NR supports local wireless and mesh deployments for IoT and professional applications in a dedicated spectrum framework. Product and regional ecosystem fit will be a deciding factor. (ETSI)
Ultra-wideband is often chosen for precise ranging and location rather than general telemetry backhaul.
Proprietary sub-GHz radio can be justified where a product needs tight control over the protocol, but it places more interoperability, gateway and long-term support responsibility on the product owner.

These technologies deserve a place when the use case or installed ecosystem points to them. They should not be added merely to make the design look comprehensive.

Hybrid connectivity is often the practical answer

One technology does not have to carry every function.

Common hybrid designs include:

Bluetooth LE for commissioning, then Wi-Fi for normal operation;
Thread or Zigbee sensors feeding an Ethernet or cellular gateway;
LoRaWAN end devices using gateways with cellular backhaul;
LTE-M or NB-IoT as the main link with satellite for coverage gaps;
Ethernet as the primary path with cellular failover;
Wi-Fi for bulk firmware downloads and LPWAN for routine telemetry.

Hybrid designs can improve resilience and user experience, but they add hardware, software, certification and support complexity. Define exactly when the product switches links, how credentials are managed and whether a failure can leave the device stranded.

A practical connectivity shortlist

A decision framework for shortlisting IoT connectivity using cabling, throughput, public coverage, private long-range coverage and local low-power requirements. — The framework creates a shortlist only. Validate the candidates against real coverage, energy use, data patterns, regional regulation, supplier support and cost.

Worked examples

A battery-powered utility meter

The device sends small readings, is fixed for many years and may sit deep inside a building.

Likely shortlist: NB-IoT where operator and roaming support are suitable; LoRaWAN where the utility can provide gateway coverage.

Deciding factors: installation coverage, power-saving behaviour, downlink requirements, service life, profile management and the cost of a site visit.

A global mobile asset tracker

The device crosses regions and operator networks, needs position updates and may spend time outside terrestrial coverage.

Likely shortlist: LTE-M for terrestrial mobility, with NTN or another satellite service if coverage gaps are part of the requirement.

Deciding factors: country coverage, roaming restrictions, eSIM provisioning, power during weak coverage, antenna design and the acceptable delay when the asset has no sky view.

Smart-building room sensors

Hundreds of low-power devices report temperature, occupancy and air quality inside a managed building.

Likely shortlist: Thread or Zigbee for a local mesh; Bluetooth LE for commissioning; LoRaWAN where small messages and building-wide private coverage suit the application.

Deciding factors: existing building platform, gateway or Border Router placement, interference, battery service interval, IT integration and installer skills.

An industrial inspection camera

The product sends images or video and is installed on a powered industrial site.

Likely shortlist: Ethernet first, then managed Wi-Fi, private cellular or public 4G/5G where wiring is impractical.

Deciding factors: throughput, latency, radio environment, cybersecurity policy, network ownership and failover.

Agricultural soil and water monitoring

Sensors are spread over a large outdoor area and send small readings infrequently.

Likely shortlist: private LoRaWAN, NB-IoT or LTE-M where public coverage is strong, and satellite for genuinely remote sites.

Deciding factors: gateway mounting and backhaul, seasonal foliage, terrain, battery replacement, local spectrum rules and service availability.

Common mistakes that cause expensive redesigns

Choosing by maximum range

Published range is not a property of the protocol alone. Antenna, frequency, transmit power, receiver sensitivity, data rate, interference, terrain and enclosure all affect it. Test the final hardware in the real installation.

Treating network coverage maps as acceptance tests

Coverage maps are useful for planning, but they rarely describe every basement, metal cabinet or moving route. Define a field-testing method and the pass criteria before pilot deployment.

Ignoring downlink and firmware updates

Some low-power networks are strongest when devices mainly transmit small uplink messages. Frequent commands and large updates can change capacity and battery life. Model both directions.

Assuming unlicensed means unrestricted

Licence-exempt spectrum still has regional rules, power limits, band plans and sometimes duty-cycle restrictions. It is also shared and generally not protected from interference.

Leaving the antenna until the end

The enclosure, ground plane, cable, mounting position, nearby metal and human interaction can change performance. Radio and antenna design must be part of the product, not an accessory added after the mechanical design is frozen.

Focusing only on the module price

A cheaper radio can require more gateways, more engineering, more batteries or more support. Compare the system over its whole life.

Treating connectivity security as the whole security model

Network encryption does not remove the need for secure device identity, configuration, data protection, access control, authorised software updates and security-state reporting. These are part of the NIST IoT device cybersecurity capability baseline. (NISTIR 8259 series)

Procurement and design checklist

Before selecting a module, operator or network platform, record the answers to these questions.

Application

What is the normal and worst-case payload in each direction?
What latency is required, and what happens when a message is late?
Does the product need voice, video, positioning or multicast?
How large are software and certificate updates?

Device

Is power mains, rechargeable or primary-cell battery?
What is the required service interval?
What antenna volume and placement are available?
Will the enclosure, installer or mounting surface affect the radio?

Coverage and mobility

Which countries and installation environments must work?
Is the device fixed, nomadic or continuously mobile?
Can gateways, access points or Border Routers be installed?
Is satellite coverage required or only desirable?

Operations

Who owns network monitoring and incident response?
How are credentials and network profiles changed?
How does the device recover after a long outage?
Can diagnostics distinguish radio, network, SIM, cloud and application failures?

Commercial and lifecycle

What is the total cost over the planned product life?
Which costs are fixed, usage-based or subject to minimum commitments?
What happens if the provider, tariff or product is withdrawn?
Can devices move to another network without physical access?
Are coverage, roaming and support commitments written into the contract?

Security and compliance

Is device identity unique and protected?
Are data protected in transit and at rest where required?
Can software be updated securely by authorised parties?
Are unused interfaces and services disabled?
Have radio, carrier, product and regional approvals been budgeted?

How to make the final decision

Use a staged process rather than selecting from a slide deck.

Write measurable requirements. Include data, latency, power, coverage, mobility, lifetime, security and cost.
Create a shortlist of two or three architectures. Include the network ownership and support model, not only the radio.
Build a realistic energy and cost model. Include poor coverage, retries, firmware updates, gateways and field service.
Test representative modules and providers. Use the intended antenna, enclosure and protocol stack.
Pilot in the worst expected environments. Good lab results are not enough.
Test failure and recovery. Remove coverage, change credentials, exhaust a tariff, interrupt power and simulate provider outages.
Check the exit route. Confirm how devices can move to another provider or network during their service life.
Record the decision and assumptions. Connectivity conditions change. A written decision record makes future review much easier.

The bottom line

Choose IoT connectivity by working from the product’s constraints, not from the newest radio or the largest coverage claim.

Start with the simplest connection that can meet the requirement. Use wired Ethernet where it is practical. Use local wireless when you can control the site. Use cellular when distributed coverage and mobility justify buying a managed service. Use LoRaWAN for small, low-power messages where its private or managed network model fits. Use satellite when terrestrial coverage gaps are a real requirement.

Most importantly, test the complete product in the real environment. The winning design is the one that can still connect, update, recover and be supported at an acceptable cost years after launch.

About this guide

Written by Mark Searle, founder of IoT Heart and an IoT connectivity professional with more than 20 years of experience across network engineering, solution architecture and commercial connected services.

This guide is based on standards-body publications and current industry documentation. It is a desk-research and professional-analysis article, not a laboratory comparison. Network coverage, module support, roaming, regulation and commercial services change over time. Verify current details with the relevant operator, module supplier, standards body and regulator before committing a product design.

Commercial disclosure: No supplier has paid for placement in this article, and no affiliate links are included. Future commercial relationships will not determine IoT Heart’s editorial conclusions.

Sources

Discover more from IoT Heart

Subscribe to get the latest posts sent to your email.