What is the difference between LoRa and LoRaWAN?
LoRa is Semtech's long-range radio modulation; LoRaWAN is the LoRa Alliance network protocol on top. What each layer does and when you need both.
Photo: C Cai / Unsplash
After reading this article you will be able to:
- Separate what the LoRa physical layer does from what the LoRaWAN protocol adds on top
- Explain how regional rules and the LoRaWAN regional parameters shape both layers
- Decide when raw LoRa, a LoRa mesh such as Meshtastic, or LoRaWAN fits a project
On this page
LoRa is a radio modulation: the physical layer that turns bits into a signal on the air. Semtech, which owns the technology, describes it as a spread spectrum modulation derived from chirp spread spectrum. LoRaWAN is a network protocol that the LoRa Alliance specifies at the MAC layer: it decides how devices join a network, how frames are addressed and secured, and how gateways and servers cooperate. Almost every LoRaWAN device transmits with LoRa, but many LoRa devices never speak LoRaWAN.
The short answer. Use LoRaWAN when many sensors report to an application, when you want devices, gateways and network servers from different vendors to work together, and when you would rather adopt a finished security and device management model than write one. Use LoRa on its own when a few radios talk directly to each other, when nodes must relay messages for one another as in Meshtastic, or when you control both ends and accept writing your own protocol, compliance logic and security.
The confusion is understandable, because the two names are often used as if they were the same thing. This guide separates the layers, shows where regional radio rules apply to each, and describes the projects that use LoRa without LoRaWAN.
| LoRa | LoRaWAN | |
|---|---|---|
| What it is | Radio modulation (physical layer) | Network protocol and system architecture (MAC layer and up) |
| Who defines it | Semtech, proprietary | LoRa Alliance, published specifications |
| What it covers | Chirps, spreading factor, bandwidth, coding rate | Joining, addressing, encryption, data rate control, device classes |
| Topology | None by itself | Star of stars: devices, gateways, network server |
| Security | None | AES-128 session keys and frame counters |
| Typical use | Point-to-point links, LoRa mesh projects, proprietary stacks | Metering, agriculture, buildings, asset tracking |
What does the LoRa physical layer do?
LoRa encodes data as chirps, signals whose frequency sweeps across the channel. A receiver that knows the chirp pattern can pick it out of the noise, which is what gives LoRa its long range at very low transmit power. Three settings shape a LoRa link: the channel bandwidth, the coding rate (how much error correction is added) and the spreading factor, which sets how long each symbol lasts. A higher spreading factor reaches farther and resists interference better, at the cost of more airtime, lower throughput and more energy per message.
Semtech quotes links of up to 30 miles in rural areas. Real links depend on antenna height, terrain, obstacles and the spreading factor, so that figure is a best case, not a planning number.
What LoRa does not do is just as important. A LoRa frame carries a preamble, an optional header, the payload and a checksum. There is no device address, no acknowledgment, no retry, no encryption and no rule about who may transmit when. Two LoRa radios set to the same frequency, bandwidth and spreading factor will hear each other, and that is all the physical layer promises.
What does LoRaWAN add on top?
LoRaWAN fills that gap with a complete network design. The LoRa Alliance describes it as a star-of-stars topology in which gateways relay messages between end devices and a central network server over ordinary IP connections. The LoRaWAN L2 1.0.4 specification defines the rest:
- Activation. A device joins over the air with a root key and a join handshake, or is personalized with fixed session keys.
- Security. Separate AES-128 session keys authenticate frames toward the network server and encrypt the payload end to end toward the application server, and frame counters stop replays.
- Radio management. Adaptive data rate lets the network server move a stationary device to a faster spreading factor when its signal allows, which saves airtime and battery.
- Downlink behavior. Device classes A, B and C set when a device listens, from two short windows after each uplink to an almost always open receiver.
LoRaWAN is also not tied to LoRa alone. The LoRaWAN regional parameters define FSK and LR-FHSS physical layers next to LoRa, so the same network can carry devices that use a different modulation.
The practical result is interoperability. A certified sensor from one maker can join a network built from another maker’s gateways and a third company’s network server, and the LoRa Alliance notes that LoRaWAN is an international standard approved by the ITU. The LoRaWAN guide covers the device classes, keys and network roles in detail.
How do regional rules apply to each layer?
Radio regulation does not care which protocol you run. In Europe, ERC Recommendation 70-03 allows non-specific short-range devices in the 868.0 to 868.6 MHz band at 25 mW e.r.p. with a duty cycle of at most 1 percent (or listen-before-talk with adaptive frequency agility), and in the 869.4 to 869.65 MHz band at 500 mW e.r.p. with at most 10 percent. A raw LoRa link, a mesh node and a LoRaWAN sensor all have to respect the same limits. The duty cycle is what keeps a shared ISM band usable for everyone.
LoRaWAN turns these rules into a ready-made channel plan. The regional parameters fix the default channels, data rates, payload sizes and transmit power for each region, and for Europe they state that LoRaWAN uses duty-cycle limited transmissions to comply with the ETSI rules. In the United States, the same document notes that FCC rules impose a maximum dwell time of 400 ms on uplinks for frequency-hopping systems below 500 kHz bandwidth. A LoRaWAN stack enforces this for you.
With raw LoRa, compliance is your firmware’s job. You pick the frequencies, track airtime, enforce the duty cycle and respect power limits. Mature projects do this explicitly: Meshtastic limits its EU_868 setting to a 10 percent duty cycle in the 869.4 to 869.65 MHz band and pauses transmission when a node reaches it.
When do you use LoRa without LoRaWAN?
Three patterns are common.
Point-to-point links. A tank level sensor two kilometers from a farmhouse, a gate opener or a remote pump switch only needs one transmitter and one receiver. Two LoRa modules and a few hundred lines of firmware avoid gateways and a network server entirely. You then own addressing, acknowledgments, retries, encryption and duty-cycle accounting.
Mesh messaging. Meshtastic is an open-source project that uses inexpensive LoRa radios to build an off-grid mesh in which nodes rebroadcast what they hear, so text messages and positions travel across several hops with no infrastructure. MeshCore, an MIT-licensed C++ library for multi-hop packet routing, takes a similar idea with dedicated repeaters. Neither needs a gateway or a server, which is exactly what LoRaWAN requires.
Proprietary networks. A company can build its own stack on the LoRa physical layer. Semtech itself cites Amazon Sidewalk as a network that runs LoRa with a proprietary protocol above it.
The trade-off is the same in all three: you gain freedom and lose interoperability. A Meshtastic node cannot join a LoRaWAN network, a LoRaWAN sensor cannot relay Meshtastic traffic, and a custom point-to-point protocol works only with radios running your firmware.
When is LoRaWAN the better choice?
LoRaWAN pays off once you have more than a handful of devices or need data to reach an application reliably. Off-the-shelf sensors for temperature, water meters, parking, doors and soil moisture already speak it, so you do not write radio firmware at all. Security, key management, adaptive data rate and network roaming are specified, tested and certified rather than improvised. And you can choose how to get coverage: install your own gateways and run a network server, rent capacity from an operator, or use a community network.
The cost is infrastructure and constraints. You need at least one gateway with an IP backhaul and a network server somewhere, and LoRaWAN’s design favors small, infrequent uplinks with scarce downlinks. For devices that need frequent commands or larger payloads, the NB-IoT and LTE-M guide covers the cellular alternatives.
Where to go next
- LoRaWAN explained walks through gateways, network servers, device classes and security.
- IoT connectivity overview places LoRa and LoRaWAN among the other radio options.
- NB-IoT and LTE-M explained covers the licensed-spectrum alternatives for the same devices.
- Meshtastic in the glossary summarizes the best-known LoRa mesh project.
Topics: LoRa, LoRaWAN, LPWAN, protocols, comparison