Choosing IoT connectivity: what actually decides it

A decision that is expensive to revisit

Connectivity is often chosen in the first week of a project, on the basis of what the team used last time or what a module supplier recommended. It then constrains almost everything that follows.

The power budget follows from it, because the radio is usually the largest consumer on a battery device. The antenna and therefore the enclosure follow from it, since a sub-gigahertz antenna is physically larger than a 2.4 gigahertz one and both interact with the materials around them. The certification path follows from it. The backend architecture follows from it. And the recurring cost per device, multiplied by the fleet and by the service life, follows from it too.

Changing it after deployment generally means new hardware. That is the reason to spend more than an afternoon on it.

The questions that actually decide it

Rather than comparing specifications, work through the constraints in the order that eliminates options fastest.

• Where exactly will the devices be installed? Not the city. Inside a steel building, in a basement, under a manhole cover, inside a machine, in a field. Coverage at that point is what matters.
• How much data, how often? A few bytes an hour and a continuous stream are entirely different problems.
• What powers it? Mains, battery, or harvested energy. This eliminates more options than anything else.
• Does the device need to receive? And how quickly must it respond? Some low-power technologies make downlink slow or constrained.
• Does it move? Between cells, between sites, across borders. Mobility rules out several options and complicates others.
• How long must it work? A ten-year service life raises questions about whether the network will still exist.
• Who should own the infrastructure? Running your own gateways is a different proposition from depending on a public network.

The options, one at a time

Wired

Worth stating first because it is so often dismissed prematurely. Where a cable can reasonably be run, Ethernet or a serial link remains the most reliable choice available, immune to the interference that plagues radio in industrial environments, and capable of carrying power alongside data.

The objection is always installation cost, and in a working plant with containment to route and permissions to obtain that objection is often valid. But the comparison should be against the total cost of the radio alternative including recurring subscription, coverage remediation and the devices that will need revisiting, not against the cable alone.

Cellular: LTE Cat-1 and newer

Standard cellular data, giving bandwidth well beyond what most sensing applications need, low latency, and coverage wherever the operator reaches. Simplified variants have emerged specifically for IoT that reduce module cost and, in some cases, allow a single antenna rather than two.

It suits mains-powered devices, gateways aggregating many sensors, anything needing meaningful bandwidth, and assets that move. It is a poor fit for small battery devices, where the power draw is difficult to reconcile with a multi-year life, and the recurring subscription is a real ongoing cost at fleet scale.

NB-IoT

A cellular standard designed for low data rates, low power and good building penetration. It reaches into basements and through structures better than conventional cellular, and supports power-saving mechanisms that allow a device to sleep deeply between transmissions while remaining registered.

The trade-offs are meaningful. Data rates are low and latency can be high, which matters if the device must respond promptly to a command. Mobility support is limited, so it is poorly suited to assets that move between cells. And availability varies considerably by country and operator, so it must be confirmed for your specific markets rather than assumed.

LTE-M

The other low-power cellular option, offering higher data rates and lower latency than NB-IoT while supporting mobility properly. It is the better choice where the device moves, where downlink responsiveness matters, or where payloads are larger than NB-IoT comfortably carries.

Like NB-IoT, regional availability differs, and the two are not universally deployed together. Checking what your operators actually support in your markets is a necessary early step.

LoRaWAN

A low-power wide-area technology operating in unlicensed sub-gigahertz bands, capable of impressive range and very long battery life. Devices can run for years on a modest cell while reporting periodically.

Its constraints are strict and frequently understated. Payloads are small, measured in tens of bytes, and the maximum shrinks as range increases because reaching further requires a slower transmission mode. In some regions there are regulatory limits on how much of the time a device may transmit, which caps how often it can report regardless of what the application would like. Downlink is limited by design.

The infrastructure question is interesting: you can use a public network where one covers your sites, or place your own gateways, which removes the subscription and gives you control at the cost of operating them. For a campus or a single large site, private gateways are frequently the better arrangement.

Wi-Fi

Ubiquitous, high bandwidth and already installed nearly everywhere, which makes it tempting. It suits mains-powered devices indoors where the network already reaches, and it carries enough bandwidth for anything a sensing application needs.

Three reservations. It is comparatively power hungry, and battery devices using it need either infrequent duty cycles or frequent battery changes. The network belongs to somebody else, who may change credentials, segment it, or upgrade the infrastructure without consulting you. And provisioning credentials onto a fleet of headless devices, then updating them when they change, is more work than it appears in the prototype.

A sub-gigahertz variant of Wi-Fi exists aimed at longer range and lower power for IoT, which is worth investigating where the ecosystem supports it in your region.

Bluetooth Low Energy

Excellent at what it does: short range, very low power, and a radio present in every phone, which makes it the natural choice for local configuration, commissioning and diagnostics.

It is rarely the primary link for reporting data to a backend, because range is short and it needs something to connect to. Its most common and most useful role in industrial products is as a second link alongside a wide-area one, giving a technician a way to configure and diagnose a device on site without cables or a laptop.

Mesh protocols on 802.15.4

Where many devices sit within a confined area and mains power is available at least for some of them, a mesh allows devices to relay for each other, extending coverage beyond what any single link reaches. It suits building applications and dense installations. The cost is complexity: mesh networks are harder to commission, harder to diagnose when a path degrades, and their behaviour changes as devices are added and removed.

Satellite

Increasingly practical for very low data rates at sites with no terrestrial coverage at all: pipelines, remote agriculture, marine and infrastructure in genuinely empty places. Cost per device and per message remains higher than terrestrial alternatives, which confines it to assets valuable enough to justify it and remote enough to need it.

Compared directly

Power: the arithmetic that decides battery life

On battery devices the radio usually dominates. Understanding roughly why helps make better decisions.

The energy of one transmission is the current drawn multiplied by how long it lasts. Both vary enormously between technologies and, crucially, with signal conditions. A device at the edge of coverage transmits at higher power and for longer than one with a strong signal, so the same hardware in a poor location can consume several times more energy per message. Battery life estimates made under bench conditions routinely fail in the field for exactly this reason.

What follows from that is practical.

• Reporting frequency matters more than technology choice. Halving how often you transmit does more for battery life than most technology substitutions.
• Payload size matters less than you would think, because the fixed overhead of establishing a transmission often exceeds the cost of the data itself. Sending one message with ten readings is usually far cheaper than ten messages with one.
• Reconnection is expensive. A device that loses its network registration and must re-establish it pays a substantial energy cost. Technologies with power-saving modes that preserve registration through long sleeps exist precisely to avoid this.
• Retries are a hidden cost. Estimates that assume every message succeeds first time will be optimistic in the field.

The wider design work is covered in battery and power engineering, and moving decisions onto the device to reduce transmission is covered in edge AI on microcontrollers.

Coverage maps are marketing; measurement is engineering

This is the single most common cause of expensive surprises in connected product projects.

An operator’s coverage map describes outdoor signal at ground level under favourable conditions. Your device will be inside a steel cabinet, in a plant room, three floors below ground, inside a machine, or surrounded by equipment producing interference. The relationship between the map and reality at that point is weak.

The remedy is straightforward and cheap relative to the risk. Place survey devices for each candidate technology at the actual installation points, leave them for a period long enough to see variation, and compare what they report. This costs a small amount of hardware and a few weeks. Discovering the problem after a hardware design has been built around the wrong radio costs a respin and a schedule.

Survey for long enough to catch variation, too. Cellular coverage changes with network load, and an assessment made on a quiet Sunday can flatter conditions considerably.

Cost across the fleet and the lifetime

Comparisons frequently stop at module price, which is the smallest of the numbers that matter.

A useful exercise: take the expected fleet size and service life, and compute total cost of each candidate over that period rather than per unit. The ranking frequently inverts. A more expensive module with no subscription can be substantially cheaper across ten years than a cheap module with a monthly fee.

Will the network still be there?

Network generations get switched off. This has already happened to earlier cellular technologies in a number of countries, stranding devices that were sold with a long expected life and forcing hardware replacement.

For a product expected to run for a decade, this is a real risk that deserves explicit consideration. Ask your module supplier and your operator about the roadmap for the technology you are considering, recognise that answers will be non-committal, and weigh accordingly. Unlicensed-band technologies such as LoRaWAN sidestep operator decisions, though they carry their own dependency on whoever runs the gateways.

One mitigation worth considering for long-life products is designing the radio as a replaceable module rather than integrating it into the main board, so a future migration means changing a component rather than redesigning a product.

One development worth watching is the convergence between terrestrial and satellite networks. Standards work has been extending low-power cellular protocols to operate over satellite, which would in principle allow a single module to use terrestrial coverage where it exists and fall back to satellite where it does not. For assets distributed across both well-covered and remote locations, that removes a genuinely awkward design compromise. Availability and cost are still developing, so it is worth asking about rather than designing around today, but for a product being specified now with a long service life it belongs in the conversation with module suppliers.

The antenna question, which is usually left too late

A radio is only as good as its antenna, and the antenna is only as good as what surrounds it. This is routinely discovered after the mechanical design is finished, at which point options are limited.

• Metal enclosures block radio. If the housing must be metal, an external antenna or a designed aperture is required, and both affect the mechanical design and the ingress rating.
• Plastic affects tuning. An antenna tuned in free air behaves differently once it is inside a housing, near a battery, or next to a circuit board.
• Ground plane matters. Many small antennas depend on the board’s ground plane as part of the radiating structure, so board size and layout are part of the antenna design.
• Lower frequencies need more space. Sub-gigahertz antennas are physically larger than 2.4 gigahertz ones, which can conflict directly with a compact enclosure.
• Placement interacts with mounting. A device bolted to a steel machine has different radio behaviour from the same device on a bench.

The practical conclusion is that antenna, enclosure and connectivity choice should be decided together, early, with measurement on a representative mechanical assembly rather than on a bare board.

Getting devices onto the network, and keeping them there

Connectivity projects are usually specified around the radio and then delayed by provisioning. It is worth thinking about early, because it affects manufacturing, field service and what happens when something goes wrong at scale.

Cellular: identity and the operator relationship

Every cellular device needs an identity on the network. Historically that meant a physical SIM fitted during manufacture, which is simple but ties each unit to one operator from the factory. For a product shipped internationally, that is awkward: coverage and commercial terms differ by country, and a unit destined for one market cannot easily be redirected to another.

Embedded and remotely provisionable SIM technology addresses this by allowing the operator profile to be changed over the air after deployment. For a product sold across multiple markets this is genuinely useful, and for one sold in a single market it is usually unnecessary complexity.

One trap worth knowing about: some countries restrict permanent roaming, meaning a device registered to a foreign operator indefinitely may eventually be disconnected. For products shipped internationally on a single operator’s SIM, this deserves a direct question to your connectivity provider about the markets you are entering, because it surfaces months after deployment rather than during testing.

Wi-Fi: the credential problem

Provisioning credentials onto headless devices is more work than it looks. The device has no keyboard and no screen, so something has to carry the network name and password to it: a Bluetooth session from a phone, a temporary access point the device hosts, a configuration file, or a barcode. Each has trade-offs in security and usability.

Then the credentials change, because networks get updated, and every deployed device needs the new ones. This is the point at which a second radio for local configuration proves its worth, and it is why Wi-Fi is less convenient for fleets than it appears for a single prototype.

LoRaWAN: keys and joining

Devices join a network using keys provisioned at manufacture. Managing those keys, getting them into the network server correctly, and handling devices that fail to join is a defined but real piece of operational work. Where you run private gateways, you also own gateway monitoring: a gateway that has quietly stopped forwarding looks identical, from the backend, to a group of devices that have stopped reporting.

Regional and regulatory differences

Connectivity is one of the few areas where the same product genuinely cannot be sold everywhere without change.

Frequency bands differ by region. Sub-gigahertz unlicensed bands are allocated differently across Europe, North America, India and elsewhere, which means different module variants, different antenna tuning and separate approval for each market. A design that assumes one band will need hardware changes to enter another.

Transmission limits differ. Some regions impose restrictions on how much of the time a device may transmit in unlicensed bands. This directly caps reporting frequency and is a constraint on the application rather than a detail of the radio: a design that reports every minute may be legal in one market and not in another.

Radio approval is per market. Each region has its own regime, and the testing and documentation required differ. Using a pre-approved module reduces this work considerably compared with designing a radio from components, which is one of the strongest practical arguments for modules in low and medium volumes. EMC requirements apply alongside radio approval; see EMC and compliance.

Cellular adds network-level approval. Beyond regulatory type approval, some operators require devices to pass their own testing before they will be admitted to the network. Timescales for this are measured in weeks and should be in the project plan rather than discovered at launch.

Low-power cellular availability varies. NB-IoT and LTE-M are not deployed uniformly. Whether either is available, and on which operators, must be confirmed per country rather than assumed from a global technology description.

Two links, deliberately

Many of the better designs use a wide-area link for reporting and Bluetooth for local interaction. The second radio costs little and solves several problems that are awkward otherwise.

Commissioning becomes straightforward: a technician configures the device from a phone rather than carrying a laptop and a cable. Diagnostics become possible on site when the wide-area link is the thing that is not working, which is precisely when you most need visibility. Credentials and configuration can be provisioned without exposing a general-purpose interface. And field service can read logs and update settings without opening the enclosure, which matters for sealed products.

Who owns the connection, and why it matters commercially

Alongside the technical comparison sits a commercial question that is easy to overlook and difficult to reverse: who is responsible for the connectivity, and who pays for it.

You own it. The product ships with connectivity included and you carry the subscription, recovering it through the purchase price or an ongoing service fee. This gives the cleanest customer experience, since the device simply works, and it keeps you in control of the data path. It also means you carry a recurring cost for every unit in the field, potentially for years, including units whose owners have stopped paying you anything.

The customer owns it. They supply the SIM or the network access. This removes your recurring cost and your exposure, at the price of a harder installation, a dependency on their IT department, and a support burden when something on their side changes. For equipment installed at industrial sites this is common and often unavoidable.

Local infrastructure you both share. Private gateways on a site, whether yours or theirs, remove per-device fees entirely but introduce equipment that somebody must own, monitor and maintain. A gateway that has failed is a silent failure affecting every device behind it.

The reason to settle this early is that it changes the technical answer. A design where you carry the subscription pushes hard toward minimising message volume and toward technologies with low per-device cost. A design where the customer provides a network pushes toward whatever integrates most easily with what they already run. And a design intended to work without any ongoing payment at all effectively rules out cellular.

It also affects what happens at end of life. A device dependent on a subscription becomes inert when payment stops, which customers reasonably object to if they believed they had bought a product rather than rented one. Being explicit about this in the design, and in what you tell buyers, avoids a predictable argument.

Three worked situations

Battery sensors across a large site

Several hundred devices reporting a few readings every fifteen minutes, expected to run for years, spread across a campus including some underground locations. Private LoRaWAN is a strong candidate: payloads are tiny, the duty cycle is low, you control the gateways, and there is no per-device subscription. The work is in gateway placement, confirmed by survey, and in accepting the payload discipline the technology imposes.

Equipment installed at customer premises

A product shipped to hundreds of customer sites where you control nothing about the local network. Cellular is usually right, despite the recurring cost, because it removes any dependency on customer infrastructure and on customer IT departments granting access. NB-IoT or LTE-M if payloads are small and power matters; conventional cellular if the device needs bandwidth or is mains powered. Bluetooth as a second link for installation.

A gateway aggregating machine data in a plant

Mains powered, substantial data volume, fixed location. Wired Ethernet is the default answer and should be argued out of rather than into. Where cable is genuinely impossible, cellular gives independence from plant IT, which is sometimes worth more than the subscription costs. Wi-Fi is viable if the plant network is well run and someone will own the relationship.

Designing for the connection you will actually get

Every wide-area link fails sometimes. Designing as though it will not is the most reliable way to produce a system that works in testing and disappoints in the field.

Buffer, and decide what happens when the buffer fills

A device that discards readings during an outage loses exactly the data most likely to matter, since outages often coincide with the disturbances you are trying to observe. Local storage sized for a realistic worst-case outage is cheap insurance.

The decision people skip is what to do when that storage fills. Discarding the oldest readings keeps a recent picture; discarding the newest preserves the record of when the problem started. Both are defensible, and the wrong one for your application is the one nobody chose deliberately.

Back off, and stagger

When a network returns after an outage, every device in the fleet will try to reconnect at once. On a large fleet this produces a surge that can overwhelm the backend, or the network, and cause a second outage immediately after the first.

The remedy is standard and frequently omitted: exponential backoff on retries, with a random element so devices do not synchronise. Likewise, devices that report on a fixed schedule should have their schedules spread rather than all reporting on the hour, which is what happens by default when they were all commissioned from the same configuration.

Distinguish silence from stability

A device that has not transmitted because nothing changed and a device that has stopped working look identical from the backend. A periodic heartbeat, separate from data reporting, resolves this cheaply and should be present in any system where reporting is event-driven.

Make failure visible on the device

A technician standing in front of a unit should be able to tell whether it has a connection, without a laptop. An indicator, or a status readable over the local Bluetooth link, saves a great deal of diagnostic time across a fleet.

Changing connectivity on an existing product

Sometimes the decision has already been made and has turned out badly, or a network is being retired. Migration is possible but the constraints are worth understanding.

If the radio is a module on a socket or a separate board, substitution may be a component change and a firmware update. If it is integrated, migration means a board respin, which carries new certification, new tooling for any mechanical change, and requalification.

The antenna is frequently the hidden obstacle. Moving between frequency bands changes antenna requirements, and an enclosure designed around one antenna may simply not accommodate another. Migrating from a 2.4 gigahertz technology to sub-gigahertz, in particular, often needs more physical space than exists.

For deployed fleets, the practical question is whether devices can be updated in place or must be visited. If a visit is required, the cost of migration is dominated by field labour rather than by engineering, which changes the calculation entirely and argues for getting the original decision right.

Mistakes worth avoiding

• Choosing before surveying. The most expensive error available in this area.
• Comparing module prices rather than lifetime cost. The ranking usually changes.
• Assuming the datasheet power figure. Real consumption depends on signal conditions, retries and reconnections.
• Designing the enclosure before the antenna. Then discovering the housing blocks the radio.
• Ignoring downlink requirements. Some low-power options make commanding a device slow or awkward.
• Assuming regional availability. Low-power cellular deployment varies considerably between countries and operators.
• Forgetting provisioning. Getting credentials onto a fleet and updating them later is real work.
• No plan for network sunset. For long-life products this is foreseeable rather than unlucky.

How we help

• Requirements analysis. Turning the product’s behaviour into the numbers that decide this: payload size, reporting interval, latency tolerance, fleet size and service life.
• Site survey. Measuring what coverage genuinely exists at real installation points, for each candidate technology.
• Power modelling and measurement. Energy per transmission estimated, then measured on real hardware in real signal conditions.
• Lifetime cost comparison. Across hardware, certification and recurring fees for the whole fleet.
• Antenna and RF design. Selection, placement, matching and the enclosure interactions, verified on a representative assembly. See hardware and PCB design.
• Implementation. Firmware, provisioning, reconnection behaviour, buffering and the backend that receives it. See IoT development.
• Certification preparation. Designing with the relevant radio approvals in view. See EMC and compliance readiness.

The service page for this work is wireless connectivity selection.

Running a survey properly

Since coverage measurement is the step that most reliably prevents expensive mistakes, it is worth setting out what a useful survey involves rather than leaving it as an instruction to go and check.

• Measure at the real mounting point. Not nearby, not at head height in the same room. A device inside a cabinet, behind a machine or below ground has a different radio environment from the same device a metre away.
• Use representative hardware. A survey conducted with a well-specified test unit and a good external antenna will flatter a product that will ship with a compact internal antenna in a plastic case.
• Run it for long enough. Days rather than minutes, to catch variation from network load, production activity, weather and shift patterns. Interference from welding or drives may only appear during certain operations.
• Record signal quality, not just presence. A marginal connection will work during a survey and fail intermittently for years afterwards. Margin is what you are actually measuring.
• Test the worst sites, not the convenient ones. The basement, the far corner, the metal enclosure. If those work, the rest will.
• Test each candidate in parallel. Comparing technologies at the same location and time is far more informative than sequential surveys under different conditions.

The output should be a written record of margin at each location for each candidate, which then supports the decision rather than an opinion about it. Where results are marginal, that is valuable information: it points to an external antenna, a different mounting position, a gateway nearer the device, or a different technology, all of which are cheaper to address before the design is fixed.

A short glossary

If you take one thing away

The comparison tables in this article, and in every other article on this subject, describe technologies in the abstract. Your decision is not abstract. It concerns specific devices, in specific places, with a specific power source, reporting a specific amount of data, for a specific number of years.

Almost every expensive mistake in this area comes from deciding on the general case and discovering the particular one afterwards. A few weeks of measurement at the real installation points, before the hardware design is committed, resolves more than any amount of specification comparison. Connectivity is one layer among five, set out in what industrial IoT actually is.

Questions we are asked about this

Common questions

What clients ask before starting

Which is better, LoRaWAN or NB-IoT?

Neither in the abstract. LoRaWAN suits very small payloads, long battery life and situations where you want to own the infrastructure. NB-IoT suits similar payloads where you would rather not run gateways and where operator coverage is good at your sites. Coverage at the actual installation points usually decides it.

Can we test coverage before committing to hardware?

Yes, and we strongly recommend it. Survey devices for each candidate technology can be placed at real installation points for a period and the results compared. This costs a fraction of discovering at rollout that the coverage map was optimistic.

Why not just use Wi-Fi? It is already there.

Sometimes that is the right answer, particularly on mains-powered devices indoors. The reservations are that Wi-Fi is comparatively power hungry, that the network belongs to someone else who may change it, and that credential management across a fleet is more work than it first appears.

What happens when a network generation is switched off?

Devices stop working, and you replace hardware. This has already happened with earlier cellular generations in several countries. For a product with a ten-year life it is a genuine risk, and worth asking your module supplier and operator about the roadmap for the technology you are considering.

Can one product use more than one connection?

Frequently, and it is often the best design. A low-power link for routine reporting with Bluetooth for local configuration and diagnostics is a common combination that solves commissioning and field service at modest cost.

How much does connectivity actually cost to run?

It depends on the technology and the volume, but the recurring cost per device multiplied across a fleet and across a service life routinely exceeds the hardware difference several times over. It belongs in the comparison from the start rather than being treated as an operational detail.

Does the enclosure affect the radio?

Considerably. A metal enclosure will block or severely degrade a radio signal, and even plastic affects tuning. Antenna type, placement, ground plane and enclosure material need deciding together with the connectivity choice, not after the mechanical design is finished.

What about satellite for remote assets?

It is increasingly practical for very low data rates at sites with no terrestrial coverage, such as pipelines, agriculture and marine assets. Cost per device and per message remains higher than terrestrial options, so it tends to suit assets that are valuable and genuinely unreachable.

Start a conversation

Where will the devices live?

Tell us where they will be installed, how much data they send and how often, whether they run on mains or battery, and how long they need to last.

Leave empty

Your name *

Email address *

Company

Country *

What are you working on? * I agree that iTechGeeks may use these details to respond to my enquiry. Privacy policy. Send enquiry ↗

Prefer email? Write to info@itechgeeks.in