Unlike cellular IoT standards such as NB-IoT and LTE-M, LoRaWAN does not run on mobile operator networks. It typically runs on unlicensed spectrum through gateways the deploying business owns or shares, which is exactly what makes it powerful in certain deployments and a real constraint in others. This guide explains how LoRaWAN's network architecture and radio technology actually work, how it compares technically to cellular IoT, and how to decide which one fits a given deployment.
Key takeaways:
- LoRaWAN uses Chirp Spread Spectrum (CSS) modulation to trade data rate for range and power efficiency, letting devices transmit several kilometers on a small battery that can last years.
- A LoRaWAN network consists of end devices, gateways, a network server, a join server, and an application server, with gateways forwarding raw radio traffic rather than processing it locally.
- LoRaWAN defines three device classes, A, B, and C, each trading power efficiency against how quickly a device can receive downlink messages.
- In Europe, LoRaWAN typically operates in the EU868 MHz band under a 1% duty cycle limit, which caps how often a device can transmit.
- The core tradeoff versus cellular IoT is infrastructure ownership: LoRaWAN requires deploying and maintaining your own gateways, while NB-IoT and LTE-M run on existing, operator-managed cellular networks.
- Com4 provisions cellular IoT connectivity across NB-IoT, LTE-M, 4G, and 5G, and helps businesses evaluate whether LoRaWAN, cellular, or a hybrid of both actually fits their deployment.
What does LoRaWAN actually stand for, and what problem does it solve?
LoRaWAN stands for Long Range Wide Area Network, and it is the networking protocol layer built on top of LoRa (Long Range), the physical radio modulation technology that gives it its name. The problem LoRaWAN was built to solve is specific: connecting large numbers of simple, battery-powered devices that each need to send only small, infrequent messages, such as a temperature reading or a status ping, across distances a typical short-range protocol like Wi-Fi or Bluetooth cannot reach. It is maintained and standardized by the LoRa Alliance, an industry group that governs the LoRaWAN specification and regional frequency plans.
How does LoRaWAN's radio technology actually work?
LoRaWAN's physical layer, LoRa, uses a modulation technique called Chirp Spread Spectrum (CSS). Instead of transmitting on a fixed, narrow frequency, CSS spreads a signal across a wider bandwidth using chirps, signals that sweep up or down in frequency over time. This spreading is what gives LoRa its defining tradeoff: it sacrifices data throughput in exchange for the ability to recover a very weak, long-range signal out of background noise, which is why a single LoRaWAN gateway can cover several kilometers in open terrain, well beyond what a typical cellular cell or Wi-Fi access point covers.
A key parameter in this tradeoff is the spreading factor, which can be set anywhere from 7 to 12. A higher spreading factor extends range and improves reliability but reduces data rate and increases how long the radio needs to stay on, which drains battery faster. LoRaWAN networks manage this automatically through Adaptive Data Rate (ADR), a mechanism where the network server adjusts each device's spreading factor and transmit power individually, aiming to use the minimum power and airtime needed for a reliable connection, which directly extends battery life across a deployment.
What does a LoRaWAN network architecture actually look like?
A LoRaWAN deployment is built from five components:
- End devices. The sensors, trackers, or meters actually collecting and sending data.
- Gateways. Physical radio receivers that pick up LoRa transmissions from any end device within range and forward them, unprocessed, to the network server over a backhaul connection such as Ethernet, Wi-Fi, or a cellular SIM.
- Network server. The central system that de-duplicates messages received by multiple gateways, manages device sessions, runs the ADR algorithm, and schedules downlink traffic.
- Join server. Handles device authentication and key management when an end device joins the network, typically using Over-The-Air Activation (OTAA), the recommended and more secure method, rather than the older Activation By Personalization (ABP) approach.
- Application server. Where decrypted application data ultimately lands, ready for the business logic and dashboards that actually use it.
The important architectural detail here is that gateways in LoRaWAN do not process or make decisions about the data they receive; they simply forward raw radio packets upstream. This is different from cellular base stations, which handle authentication and traffic management locally at the tower. It is also why LoRaWAN coverage planning is entirely the deploying business's responsibility: every gateway has to be purchased, installed, and maintained, with no equivalent to an operator's existing national radio network doing that work automatically.
What are LoRaWAN's device classes, and why do they matter?
LoRaWAN defines three device classes, each representing a different tradeoff between power efficiency and downlink responsiveness:
|
Class |
How it works |
Power efficiency |
Best for |
|
Class A |
Device only opens brief receive windows after it transmits |
Best, the default for battery-powered devices |
Sensors that mostly send data and rarely need to receive commands |
|
Class B |
Adds scheduled receive windows synced to periodic beacons from the gateway |
Good, more predictable downlink than Class A |
Devices needing scheduled, low-latency downlink alongside long battery life |
|
Class C |
Device listens continuously except while transmitting |
Lowest, effectively requires mains power |
Devices that must receive commands with minimal delay, such as actuators |
Every LoRaWAN device supports Class A as a baseline, since it is the specification's power-efficiency floor. Class B and Class C add responsiveness at a direct cost to battery life, which is why most large-scale, battery-powered sensor deployments default to Class A unless a specific use case genuinely needs faster downlink.
What frequency band does LoRaWAN use in Europe, and what limits apply?
In Europe, including Norway and the wider Nordic region, LoRaWAN operates in the EU868 MHz band, using unlicensed ISM spectrum around channels at 868.1, 868.3, and 868.5 MHz. Because this spectrum is unlicensed and shared, European regulations impose a duty cycle limit, typically 1% in the primary EU868 channels, meaning a device can only transmit for a small fraction of any given time window. This limit is a deliberate design constraint to prevent any single network from monopolizing the shared spectrum, and it reinforces LoRaWAN's core positioning: infrequent, small messages, not continuous or high-frequency data.
LoRaWAN vs. cellular IoT (NB-IoT, LTE-M): what's actually different?
|
|
LoRaWAN |
NB-IoT |
LTE-M |
|
Network ownership |
Private or shared, unlicensed spectrum |
Mobile operator network |
Mobile operator network |
|
Range |
Very long in open/rural terrain, shorter in dense urban areas |
Long, operator-dependent |
Long, operator-dependent |
|
Power efficiency |
Excellent |
Excellent |
Good |
|
Mobility support |
Limited, no native handover between gateways |
Limited, designed for stationary devices |
Full, handover between cells like a phone |
|
Infrastructure |
Requires deploying and maintaining your own gateways |
Uses existing operator network |
Uses existing operator network |
|
Data rate |
Very low (bytes to tens of bytes typically) |
Low |
Moderate |
|
Best for |
Private sites, campuses, agriculture, dense sensor networks |
Stationary sensors, metering |
Mobile assets, moderate data needs |
The decisive architectural difference is infrastructure ownership. NB-IoT and LTE-M ride on network operators' existing cellular infrastructure, so a business gets working, nationwide coverage the moment a SIM is activated. LoRaWAN generally means deploying your own gateways, or subscribing to a shared regional network where one exists, which gives more control over the network and can be cheaper at scale on a single, fixed site, but shifts the entire burden of coverage planning, gateway maintenance, and backhaul connectivity onto the business running the deployment.
When does LoRaWAN make sense?
LoRaWAN tends to be the right fit when several of these are true at once:
- You control the deployment site, such as a factory campus, farm, port, or building, and can install and maintain your own gateways.
- Devices are numerous, low-cost, and send very small, infrequent payloads, such as soil moisture readings, asset tags, or environmental monitoring data.
- Long battery life, measured in years rather than months, is a hard requirement.
- Devices do not need to roam beyond a fixed, known coverage area.
- The cost of deploying gateways is justified by the number of devices they will serve over the site's lifetime.
When is cellular IoT the better choice?
If devices need to work anywhere there is mobile coverage, without a business deploying and maintaining its own radio infrastructure, cellular IoT is generally the stronger fit. This applies clearly to mobile assets that move between and beyond fixed sites, distributed deployments spread across many separate locations where installing gateways everywhere would be impractical, and any deployment where nationwide or cross-border coverage matters more than the marginal cost savings LoRaWAN can offer on a single, high-density site.
Can LoRaWAN and cellular IoT work together?
Yes, and for many businesses the real answer is not LoRaWAN or cellular but a combination of both. A common hybrid pattern uses LoRaWAN for dense, low-cost sensor coverage within a fixed site, then backhauls the gateway itself to the internet over a cellular SIM rather than fixed-line infrastructure, combining LoRaWAN's low per-device cost with cellular's ubiquitous, infrastructure-free connectivity at the gateway level. Com4's guide to scaling IoT beyond LoRaWAN with cellular and hybrid connectivity covers this hybrid approach in more depth.
