You've built something that needs to report back every few hours from wherever it lives. A temperature sensor in a shipping container. A tracker for farm equipment. A moisture probe in a field three kilometres from the nearest building. The device needs to run on batteries for months, send small bursts of data, and work reliably. You start researching your options and quickly hit two acronyms: LoRaWAN and NB-IoT.
Both are low-power wide-area network technologies built for exactly this kind of problem. Both can send small amounts of data over long distances from devices running on coin cells or small solar panels for months at a stretch. They just take completely different approaches to getting that data from A to B.
The LoRaWAN vs NB-IoT choice comes down to one fundamental difference: who owns and operates the network you rely on. Everything else, cost, coverage, power, data rate, follows from that.
What LoRaWAN actually is
LoRaWAN uses a radio technology called LoRa, which sends data by spreading a signal across a wide slice of the frequency spectrum at very low power. This makes it highly resistant to interference and capable of punching through walls and foliage in ways that conventional radio cannot at the same power level.
The WAN part, LoRaWAN, is the open protocol that runs on top of LoRa. It defines how devices communicate with gateways, how data is forwarded to a network server, and how security works. Anyone can run a LoRaWAN network. You can deploy your own gateway for a few hundred pounds, connect it to a free community network like The Things Network, and start receiving sensor data within an afternoon.
That openness is both the appeal and the catch. Coverage only exists where someone has deployed a gateway. In cities and towns, community networks have decent reach. In rural areas, you may be on your own, which can either be a problem or exactly what you want.
What NB-IoT actually is
NB-IoT, short for Narrowband IoT, is a cellular standard developed alongside 4G. Mobile operators broadcast it from their existing tower infrastructure, often in the same frequency bands as LTE. Your device needs a SIM card and a subscription, but in return, you get coverage wherever that operator has a signal.
Because it uses licensed spectrum and established cellular infrastructure, NB-IoT is inherently more predictable than community-based LoRaWAN. The operator runs the network. You don't manage gateways. You don't need to worry whether the volunteer gateway in your town is still online. You pay a monthly fee per device and get on with things.
Coverage: it depends on where you are
In a dense urban environment with solid mobile coverage, NB-IoT is hard to beat. If your operator supports it (and most major European and Asian operators do), you get coverage from day one, including good indoor penetration. NB-IoT devices can use relatively higher power during initial cell connection, which helps them reach basements and thick-walled buildings that LoRaWAN would struggle to reach.
In rural areas or places with poor cellular infrastructure, LoRaWAN can actually come out ahead. If there is no NB-IoT coverage, there is no NB-IoT. But you can deploy a LoRaWAN gateway yourself, connect it to a community network server, and have working coverage in hours. For agriculture, environmental monitoring, or any application in an area the mobile operators haven't bothered with, this matters.
The other scenario that firmly favours LoRaWAN is private deployments. A factory floor, a port, a university campus: if you want all your data to stay on your own infrastructure without going through a mobile operator at all, you run your own LoRaWAN network server and your own gateways. NB-IoT has no real equivalent for fully private networks.
What it costs, and when you pay
LoRaWAN hardware is cheap. A good end-node module costs a few pounds. Gateways start around £70 for basic indoor units and rise to a few hundred for outdoor-rated ones. If you use The Things Network, there are no ongoing network fees. Running fifty sensors costs roughly the same per month as running one.
NB-IoT charges per device per month. Rates vary by operator and volume, but are typically between a few pence and a few tens of pence per device. At ten devices, that's negligible. At ten thousand devices, it becomes a meaningful line item. The counter-argument is that you're paying for a managed, reliable network with a service agreement behind it, not a community gateway someone runs from their spare room.
For small-scale projects and private networks, LoRaWAN is almost always cheaper. For large commercial deployments where reliability guarantees matter more than unit cost, the NB-IoT model starts making sense.
Data rates, duty cycles, and what you can actually send
Neither technology is designed for heavy data. But they differ in how much you can push through, and how often.
LoRaWAN data rates range from around 250 bits per second up to roughly 50 kbps, depending on the spreading factor and channel settings. In practice, most LoRaWAN packets are tiny: a GPS coordinate, a temperature reading, a handful of sensor values. Regulatory duty-cycle limits in Europe also restrict how often a device can transmit, so you can typically send a handful of short messages per hour, not hundreds.
NB-IoT offers higher throughput, up to around 200 kbps in good conditions, and handles more frequent transmissions with more predictable latency. If your application needs to send larger payloads, receive firmware updates over the air, or respond quickly to commands from the cloud, NB-IoT is considerably easier to work with.
Mobility and roaming
NB-IoT handles moving devices well. It builds on decades of cellular roaming infrastructure. A tracker in a vehicle crossing operator coverage areas connects to the available cell, roams if needed, and carries on. Solved the problem.
LoRaWAN was not designed with the same kind of mobility in mind. A device moving between regions may pass through gaps where no community gateway has coverage. Roaming agreements exist between some LoRaWAN network providers, but patchy is the honest description. For any application that follows an asset across a large geographic area, NB-IoT is the more reliable choice.
The honest trade-offs
LoRaWAN's community network model means your coverage depends, at least partially, on someone else's hardware staying online. A gateway going dark in your area, or a network operator restructuring its service, can silently break a deployment you thought was solid. Running your own gateways solves this, but adds operational work you may not have budgeted for.
NB-IoT binds you to a mobile operator. If that operator discontinues NB-IoT support (as it has in some markets), you will face a migration. You have no control over the underlying network. If the operator changes something at the radio or protocol level, you adapt. For most deployments, this is fine, but it's worth knowing the dependency exists before you design a ten-year product around it.
Both technologies have real weaknesses in deep indoor environments: reinforced-concrete basements, underground infrastructure, and dense metal enclosures. NB-IoT generally performs better here than LoRaWAN, but neither is a substitute for an RF site survey if your application operates in challenging conditions.
Matching the technology to the project
LoRaWAN makes sense when you want to run your own network, when you are working in a region with good community coverage, when data volumes are small and infrequent, or when your application needs to stay completely on your own infrastructure. It is the natural choice for agricultural monitoring, environmental sensing, prototyping, and anything where cellular coverage is absent or unreliable.
NB-IoT makes sense when you need coverage from day one across a wide area, when your devices move or roam, when your data throughput or latency requirements stretch beyond what LoRaWAN can comfortably manage, or when the operational simplicity of a managed network is worth the per-device cost.
For many real-world IoT applications, you could successfully build on either. The deciding question is usually who runs the network and who pays for it. Answer that clearly at the start of the project, and the rest of the decision tends to sort itself out.
