Evaluating connectivity for a distributed, outdoor, or remote deployment usually means running into three unfamiliar acronyms at once: LoRaWAN, NB-IoT, and increasingly, satellite IoT. All three fall under LPWAN — low power wide area network. It’s the category of wireless standards built for devices that send small amounts of data over long distances on a battery that lasts years, not days.
The question isn’t which LPWAN standard is “best.” It’s which one fits the specific building, yard, or site in front of you, because the honest answer changes by environment. This piece breaks down what each option actually does and where it fits. The connectivity layer matters beyond just keeping a sensor online — it’s what determines whether an environment gets captured completely enough to produce usable, AI-ready data downstream.
What Is LPWAN (Low-Power Wide-Area Network)? And How Is It Different From LoRaWAN?
LPWAN is the umbrella category. LoRaWAN is not the same thing as LPWAN — it’s one specific protocol inside that category, alongside NB-IoT, LTE-M, and satellite IoT. Each one makes a different tradeoff between range, power, data rate, and cost:
- LoRaWAN — unlicensed spectrum, self-owned network, best for outdoor and campus deployments
- NB-IoT — licensed cellular spectrum, best for fixed devices that need deep building penetration
- LTE-M — licensed cellular spectrum, best for devices that move
- Satellite IoT — an extension of NB-IoT and LTE-M for sites with no terrestrial coverage at all
The rest of this piece walks through each one, and why the right answer usually depends on where — and what — you’re trying to connect. None of these standards compete for the exact same job. A protocol built for a fixed water meter in a basement isn’t competing with one built for a vehicle crossing a yard; they’re solving different problems that happen to share a category name.
LoRaWAN — Long Range, Low Power, Unlicensed Spectrum
LoRaWAN is built for exactly the kind of deployment that stumps standard Wi-Fi and cellular: outdoor yards, ports, and sprawling campuses. Running cable isn’t practical there, and devices need to run for years on a single battery. In flat, open terrain, a single gateway can cover a multi-kilometer radius. Because it runs on unlicensed spectrum, an organization can own and operate its own private network instead of paying a carrier per connection. That’s usually the most cost-effective option for a dense deployment inside a defined geography.
Thinaer deploys LoRaWAN today as one of the technologies it carries, specifically for outdoor and distributed-campus environments where BLE and Wi-Fi don’t reach.
The tradeoff is duty cycle. In most regions, LoRaWAN operates in unlicensed spectrum under a 1% duty-cycle restriction — roughly 30 messages per hour per device at typical settings. For applications sending occasional readings, that’s not a constraint you’ll ever notice. For applications needing frequent updates, it’s a hard limit, not a tuning problem, and it’s easier to plan around before hardware is deployed than after.
NB-IoT and LTE-M — Cellular-Based LPWAN
Both NB-IoT and LTE-M run over licensed cellular spectrum — the same infrastructure mobile carriers use for phones — which trades the self-owned network model of LoRaWAN for carrier coverage and a SIM-based connection.
NB-IoT is built for devices that stay put. It uses cheaper modules and lower throughput, and it doesn’t support handover between cell towers, so it’s designed for stationary devices: meters, environmental sensors, fixed asset tags.
LTE-M is built for devices that move. It supports higher throughput and lower latency than NB-IoT, and — the real differentiator — it hands off between cell towers the way a phone call does, so the connection survives a device relocating. Thinaer deploys LTE-M today for exactly this reason: tracking vehicles and other assets that move between locations, where a connection that survives handing off from tower to tower is the whole point.
Despite what older comparisons often claim, penetration isn’t a clean win for either standard; real-world testing shows the two perform comparably once you’re outside extreme edge cases. The question that actually matters is simpler: does the device stay in one place, or not?
Satellite IoT — Connectivity Where Cellular and LoRaWAN Gateways Can’t Reach
Some environments don’t have a gateway option at all: remote agricultural land, offshore infrastructure, mining sites, oil and gas fields far from the nearest cell tower. That’s where satellite IoT comes in.
Satellite IoT isn’t a fourth, unrelated protocol. It’s NB-IoT and LTE-M extended to run over satellite instead of a cell tower, via a standard called NTN (non-terrestrial networks). In some cases, an existing NB-IoT or LTE-M module can gain satellite connectivity through a firmware update rather than a hardware swap. That’s a big part of why this has gone from lab curiosity to commercial reality so quickly.
2026 is the year this became commercially practical rather than theoretical: module costs have come down, and low-earth-orbit satellite constellations now provide the coverage density that direct-to-device satellite connectivity needs to work reliably. Satellite pricing is still a premium over terrestrial LPWAN, so it makes the most sense where terrestrial coverage genuinely doesn’t exist, not as a substitute where it does.
LPWAN vs. Cellular vs. Wi-Fi — Where Each One Actually Fits
A quick reference for how these compare against standard cellular and short-range options like Wi-Fi and BLE:
| Technology | Range | Power Draw | Data Rate | Typical Use Case |
|---|---|---|---|---|
| LoRaWAN | Miles (open terrain) | Very low | Low | Outdoor yards, ports, campuses |
| NB-IoT | Cellular coverage area | Low | Low | Fixed meters, static sensors |
| LTE-M | Cellular coverage area | Low–moderate | Moderate | Moving vehicles, in-transit assets |
| Satellite IoT (NTN) | Global (LEO coverage) | Low, varies | Low | Remote sites, no terrestrial coverage |
| Standard Cellular (4G/5G) | Cellular coverage area | Moderate–high | High | High-bandwidth applications, backhaul |
| Wi-Fi / BLE | Tens of meters, indoor | Low (BLE), moderate (Wi-Fi) | Moderate–high | Indoor zones, room-level tracking |
Why the Right Choice Isn’t Universal — Your Environment Decides
A single facility often needs more than one of these, not just one. A shipyard’s classified bay may need BLE, its outdoor yard needs LoRaWAN or GPS, a vehicle moving between sites needs LTE-M, and a remote sensor cluster miles from the nearest gateway might need satellite. Standardizing on one LPWAN protocol, and forcing it everywhere, repeats a familiar mistake. It works until the next building, zone, or use case doesn’t fit.
Thinaer’s approach is the opposite. Every radio and every backhaul, including LoRaWAN, cellular, wired, Wi-Fi, and private 5G, runs through one platform. The environment determines the mix, and it all lands in one Sonar instance, one set of APIs, one partner. That technology underneath can change from building to building; the operator’s view doesn’t.
This flexibility matters beyond convenience. Satellite IoT’s relationship to NB-IoT and LTE-M is a good example. It extends existing cellular investment rather than requiring a whole new stack. The same principle applies whether the change is a new radio or a new site altogether.
What to Ask Before Committing to an LPWAN Standard
Most of the questions below have obvious-sounding answers until you’re standing in the actual facility. Working through them before selecting hardware is what turns “we picked LoRaWAN because it seemed right” into a decision that still holds up once the deployment scales past the first building.
- How many devices, and how densely are they packed into the space?
- Is the deployment mostly indoor, outdoor, or a mix?
- Does reliable cellular coverage already reach the site?
- Do the devices stay in one place, or do they move between zones or locations?
- How often does each device need to report? LoRaWAN’s unlicensed-spectrum duty cycle caps most deployments around 30 messages per hour per device. If your use case needs more frequent updates than that, LoRaWAN alone won’t fit the bill, and that’s worth knowing before you commit to hardware, not after.
- Will the deployment need to scale to new sites with different constraints down the line?
Choosing LPWAN Is a Set of Tradeoffs, Not One Decision
LoRaWAN, NB-IoT, LTE-M, and satellite IoT each solve a different problem, and most real deployments end up using more than one: a private LoRaWAN network in the yard, LTE-M on the vehicles that leave it, satellite on the site that has neither cell coverage nor a gateway. The question worth asking isn’t “which LPWAN standard should we standardize on.” It’s “what does each environment actually need.”
That’s also what makes the resulting data usable for whatever comes next. An environment that’s captured completely and continuously produces the kind of structured, AI-ready data any downstream system, whether a dashboard, an analytics tool, or an AI model, can actually use. Get the connectivity layer right, and everything built on top of it gets easier.