Embedded and IoT

LoRa vs LoRaWAN

LoRa is a radio modulation, the physical layer that turns bits into a long-range, low-power signal. LoRaWAN is a network protocol defined by the LoRa Alliance at the layer above, which sets out how devices join a network, how traffic is secured, when devices listen and how data rates are managed. LoRaWAN uses LoRa, but LoRa can also carry other protocols, such as Amazon Sidewalk or Meshtastic's mesh.

Learning objectives

After reading this article you will be able to:

  • Distinguish LoRa the physical layer from LoRaWAN the network protocol
  • List what LoRaWAN adds, from activation and session keys to device classes
  • Explain what designs such as Meshtastic gain and lose by running LoRa without LoRaWAN

Two layers with two owners

The names are close, but they describe different layers of a radio system.

LoRa is the physical layer. Semtech describes it as a spread spectrum modulation derived from chirp spread spectrum, and says plainly that LoRa is the silicon Semtech develops. It defines how bits become a radio signal and nothing more. How LoRa modulation works covers chirps, spreading factors and bandwidth.

LoRaWAN sits above it. The LoRa Alliance defines it as the network standard and system architecture at the MAC (medium access control) layer: how devices communicate with the network server, how data rates and battery life are managed, and how security and data integrity work. Semtech describes LoRaWAN as a standard for interoperability managed by the LoRa Alliance, a non-profit of which Semtech is a founding member. The Alliance also notes that LoRaWAN has been approved as an international standard by the ITU.

What LoRa alone gives you

On its own, LoRa moves a frame from one radio to another. Ghanaatian and colleagues describe the LoRa PHY frame: a preamble of chirps for synchronisation, an optional header, the payload and an optional CRC to detect errors. The frame they describe has no field saying who a message is for, no keys and no rule about when a device may transmit or listen. Everything of that kind is left to whatever protocol runs on top.

That makes LoRa flexible. Two LoRa radios with matching settings can talk directly, and a designer can build any addressing, routing or security scheme they like above the modulation.

What LoRaWAN adds

LoRaWAN fills in those gaps for one particular shape of network. The LoRa Alliance describes it as a star-of-stars: end devices make single-hop radio links to gateways, which relay packets over IP to a central network server. Mesh networking vs LoRaWAN compares that architecture with a mesh. On top of the architecture, the specification defines:

  • Activation. Semtech’s application note describes two ways onto a network: over-the-air activation (OTAA), which it marks as preferred, and activation by personalisation (ABP), where keys are set in advance.
  • Security. The Things Network explains that each session uses two 128-bit AES keys. The network session key checks the integrity of every message between device and network server; the application session key encrypts the payload between device and application server. Frame counters let either side reject replayed messages.
  • Device classes. Semtech describes three. Class A devices sleep, send an uplink, then open two short receive windows. Class B devices add scheduled receive slots timed by beacons from the gateways. Class C devices listen almost all the time and suit mains-powered equipment.
  • Adaptive data rate. Semtech describes how the network server adjusts each device’s data rate and transmit power, so devices near a gateway use low spreading factors and spend less airtime, while distant devices use higher ones.
  • Regional channel plans. Semtech notes that the LoRa modulation characteristics for each region are defined in the LoRaWAN Regional Parameters document.

The LoRa Alliance publishes the link-layer rules as a numbered specification, TS001, alongside regional parameters and companion documents for features such as relays and device certification.

LoRa without LoRaWAN

Semtech notes that some customers run the LoRa physical layer with a proprietary network on top, and gives Amazon Sidewalk as the example. Meshtastic is another: it uses LoRa radios with its own firmware, and its documentation describes a managed flood in which nodes rebroadcast the packets they receive, up to a hop limit, so messages travel from radio to radio.

These designs keep the radio and change everything above it. They give up LoRaWAN’s certified interoperability, its gateway and network server infrastructure and its standard security model, and in exchange can do things LoRaWAN’s architecture does not, such as letting devices message each other directly.

Side by side

LoRaLoRaWAN
LayerPhysical (modulation)MAC and network architecture
Defined bySemtechLoRa Alliance specification
SpecifiesChirps, spreading factor, bandwidth, coding rateActivation, keys, device classes, data rate control, channel plans
TopologyAny, or noneStar of stars: devices, gateways, network server
SecurityNone of its ownAES-128 session keys, integrity checks, frame counters
Used without the otherYes, for example Amazon Sidewalk and MeshtasticNo, it runs over LoRa modulation

The practical question is which layer you are choosing. Picking LoRa means picking a radio and its trade-offs between range, data rate and airtime. Picking LoRaWAN means also picking a network model: gateways, a server, and the rules for joining, securing and scheduling traffic that come with it.

Frequently asked questions

Do I need LoRaWAN to use a LoRa radio?

No. A LoRa transceiver can send frames to another LoRa transceiver directly, and projects such as Meshtastic build their own mesh on LoRa radios. LoRaWAN is the choice when you want gateways, a network server and certified interoperability with other LoRaWAN equipment.

Is LoRaWAN traffic encrypted?

Yes. LoRaWAN uses two 128-bit AES session keys per device. The network session key protects message integrity between the device and the network server, and the application session key encrypts the payload between the device and the application server, so gateways and the network server cannot read application data.

Sources

Build it with Offline Protocol

The Rust and constrained devices page describes offline-protocol-leaf, which runs over whatever radio link the firmware supplies, and lists what that firmware must provide, from radio I/O and entropy to durable storage.

Read the Rust and constrained devices docs