What is LoRaWAN?

LoRaWAN (Long Range Wide Area Network) is an open radio standard for the Internet of Things (IoT). It connects battery-powered sensors over several kilometres with very low power consumption and small amounts of data. LoRaWAN belongs to the family of LPWAN technologies (Low Power Wide Area Network) and is maintained by the LoRa Alliance as a vendor-neutral standard. The key distinction is in the terms: LoRa is the radio modulation on the physical layer, while LoRaWAN is the network protocol on top that handles addressing, security and operations.

This makes LoRaWAN ideal for applications where many distributed devices rarely send small readings: sensors in buildings, agriculture, smart metering, environmental monitoring or predictive maintenance on machines.

LoRa vs LoRaWAN: modulation and protocol

LoRa is a modulation technique developed by Semtech, based on Chirp Spread Spectrum (CSS). It transmits data extremely robustly and over long distances, at the price of a low data rate. LoRa only defines how bits go over the air, comparable to the lowest layer of a radio system.

LoRaWAN builds the actual network on top of that. It is the open MAC and network layer from the LoRa Alliance and defines how devices authenticate, how messages are encrypted, how the network server deduplicates packets and how transmission parameters are managed. The current, widely deployed Link Layer specification of the 1.0 line is TS001-1.0.4 (published October 2020); a 1.1 version with extended key management also exists. The regional radio parameters live in a separate document, currently RP002-1.0.5 (October 2025).

Range and power consumption

The two selling points of LoRaWAN are range and battery life:

• Range: In rural areas a single gateway covers 10 to 15 kilometres, and considerably more with clear line of sight. In cities it is closer to 2 to 5 kilometres due to buildings, but the signal penetrates buildings and basements well.
• Power consumption: A Class A sensor transmits only briefly and sleeps the rest of the time. Battery lifetimes of several years on a single cell are therefore common.

The lever for this is the spreading factor (SF7 to SF12). A low SF7 is fast and power-efficient but short-range; a high SF12 increases range and robustness but significantly extends the time on air and the power draw. The network server manages this automatically through Adaptive Data Rate (ADR).

Device classes A, B and C

LoRaWAN defines three device classes that set the trade-off between power consumption and downlink latency:

Class A is the default and must be supported by every LoRaWAN device. Downlinks to the device are only possible immediately after an uplink. If you need fast commands to a device, you use Class C, but you accept the higher power draw.

Frequencies: EU868 and duty cycle

In Europe, LoRaWAN transmits in the EU863-870 MHz band (EU868 for short). It is licence-free ISM spectrum that can be used without a SIM or a mobile contract. In return, ETSI rules apply, above all the duty cycle: on the common sub-band a device may transmit only 1 percent of the time, around 36 seconds per hour. This keeps the network disciplined and matters for sizing, because an SF12 packet quickly costs more than one second of time on air.

The three mandatory join channels are 868.1, 868.3 and 868.5 MHz. Data rates range from about 250 bit/s at SF12 to roughly 5.5 kbit/s at SF7, plus faster steps up to 50 kbit/s (FSK). LoRaWAN is deliberately narrowband, which is part of the range and power-saving concept.

Architecture: from end device to application server

LoRaWAN uses a star-of-stars topology. Four building blocks work together:

1. End device (sensor): Measures and sends small, AES-encrypted packets.
2. Gateway: Receives all LoRa radio signals in range and forwards them as a transparent packet forwarder. Gateways decrypt nothing; they are pure bridges.
3. Network server: The brain of the network. It deduplicates packets (the same device is often heard by several gateways), checks integrity, manages ADR and MAC commands, and administers devices and gateways.
4. Application server: Decrypts the payload and passes it to your application, typically over MQTT.

How these layers fit into a complete IoT stack is shown in our article on IoT architecture in layers. The handover to the application almost always runs over MQTT.

Security: AES, OTAA and ABP

LoRaWAN is encrypted from the ground up. Every message is secured with AES-128, on two levels:

• The NwkSKey (Network Session Key) protects integrity between device and network server via a message integrity code.
• The AppSKey (Application Session Key) encrypts the payload end to end up to the application server. The network server never sees the content.

The root keys (AppKey, plus NwkKey in 1.1) are never sent over the air. There are two activation methods:

• OTAA (Over-the-Air Activation): The device runs a join procedure that dynamically negotiates an address and fresh session keys. This is the recommended, secure method.
• ABP (Activation by Personalization): Address and session keys are hard-coded into the device. Simpler to provision, but less secure because the keys stay static.

Since specification 1.0.4, 32-bit frame counters are mandatory and must not be reset on ABP devices. This makes replay attacks harder.

LoRaWAN vs NB-IoT, cellular and WLAN

LoRaWAN is not the right choice for every case. The decision depends on data rate, power consumption, range and operating model:

Rule of thumb: LoRaWAN is the best choice when many devices send small amounts of data infrequently, should run for years on battery, and you want to control the network yourself. NB-IoT shines at deep indoor penetration over the carrier network but costs a SIM and a subscription per device. Cellular and WLAN are made for high data rates or video, not for years-long battery sensors in the field.

Self-hosted network server with ChirpStack

The network server is the piece you should run sovereignly, instead of handing it to a vendor cloud with per-device billing. This is where ChirpStack comes in: an open-source LoRaWAN network server under the MIT licence. The current major version ChirpStack v4 merges the network server and the former application-server UI into one application and ships with integrations for MQTT, databases and cloud services. It runs on PostgreSQL, Redis and an MQTT broker (Mosquitto) on a standard Ubuntu server.

The advantage: you host the network on your own infrastructure (Proxmox, Hetzner or on-prem), keep full data sovereignty in the EU and pay no per-device licence. This sovereign, open-source-based model is exactly what we build and operate at WZ-IT.

Build a sovereign LoRaWAN network? We plan, build and operate self-hosted LoRaWAN networks with ChirpStack on your infrastructure, without cloud lock-in and without a per-device licence. See our LoRaWAN service - View ChirpStack expertise

If you want to go deeper: our article What is ChirpStack? explains the network server in detail, and our IoT services show how we deliver complete platforms from sensor to dashboard.