What is LoRa and LoRaWAN

If you have spent any time around IoT hardware, mesh networks, or amateur radio communities, you have encountered LoRa. You have probably also encountered LoRaWAN. And you have probably encountered people using both terms to mean the same thing, which they do not, and which causes genuine confusion when you are trying to understand how any of this actually works.

So. Let us be clear about what these things are.

LoRa: a radio modulation technique

LoRa is a proprietary radio modulation technique developed by a French company called Cycleo and acquired by Semtech in 2012. The name is short for Long Range. It is a way of encoding digital data onto a radio signal in a manner that is resistant to interference and capable of travelling long distances at very low power.

The technical mechanism is called Chirp Spread Spectrum. A chirp is a signal that sweeps through a range of frequencies rather than sitting on a single fixed frequency. Spreading the signal across multiple frequencies in this way makes it significantly harder for noise and interference to corrupt the transmission. The receiver can decode the signal even when it is weaker than the noise floor, which is a property conventional narrowband radio does not have.

The practical result: LoRa signals can travel several kilometres in open terrain, or several hundred metres in dense urban environments, using a transmitter drawing milliwatts of power. A sensor on a coin cell battery can transmit reliably for years. This is not a property of the network architecture or the protocol. It is a property of the radio modulation itself.

LoRa is not a network. It is a way of making radio transmissions.

The physical layer trade-offs

Nothing is free. LoRa’s long range and low power come at a cost, and understanding the cost is important for understanding when LoRa is and is not the right tool.

Bandwidth is low. LoRa data rates range from around 250 bits per second at the most conservative settings to around 50 kilobits per second at the most aggressive. Compare this to WiFi at hundreds of megabits per second or 4G at tens of megabits. LoRa is designed for small packets of data sent infrequently. Transmitting a photograph is not a sensible use of LoRa. Transmitting a temperature reading every ten minutes is.

Duty cycle limits apply. In the UK, LoRa operates on licence-exempt spectrum in the 868MHz band. The regulations that permit this require devices to observe a duty cycle limit: typically 1% in most sub-bands, meaning a device can transmit for a maximum of 36 seconds per hour. This is not a LoRa limitation per se, it is a regulatory limitation on licence-exempt spectrum use, but it shapes how LoRa networks are designed.

Latency is high and throughput is asymmetric. Sending a packet takes a while by WiFi standards. Receiving a downlink response to an uplink transmission involves deliberate receive windows that add further latency. LoRa is not suitable for anything requiring real-time bidirectional communication.

These constraints are the point, not a flaw. They are what makes LoRa viable for sensors that need to run for years on batteries and transmit from locations where cellular coverage is unavailable or expensive.

LoRaWAN: a network protocol built on top of LoRa

LoRaWAN is a network architecture and communication protocol that uses LoRa as its radio layer. It is specified and maintained by the LoRa Alliance, an industry body with hundreds of member companies.

Where LoRa is just a way of sending radio signals, LoRaWAN specifies everything else: how devices authenticate to a network, how messages are routed, how gateways connect to network servers, how the data reaches an application, how downlink messages are sent back to devices, and how the whole thing is secured.

The architecture is a star-of-stars topology:

End devices are the sensors and trackers. They transmit LoRa packets and optionally receive downlinks. They have no knowledge of which gateway received their transmission or how many gateways heard it. They just send.

Gateways are the radio infrastructure. They listen for LoRa transmissions on multiple channels simultaneously, receive all packets from all end devices in range regardless of which network they belong to, and forward those packets over an IP network (the internet or a private network) to a network server. A gateway is not a router in the traditional sense: it does not decide who receives what. It just listens and forwards.

Network servers are the intelligence layer. They receive forwarded packets from all gateways, deduplicate them (the same packet may be received by multiple gateways), perform authentication, manage join procedures, handle adaptive data rate, and route decrypted payloads to the correct application server. The network server also handles downlink scheduling.

Application servers are where your data lands. The network server delivers device payloads to the application server via MQTT or HTTP. The application server is where you integrate LoRaWAN data with your actual application: a database, a dashboard, a home automation system, an alert.

LoRa is the radio. LoRaWAN is the network. A LoRaWAN gateway uses LoRa to listen for devices. The network server uses the internet to connect to the gateway. Your application uses MQTT to get the data from the network server. Each layer is distinct.

Security

LoRaWAN uses two layers of AES-128 encryption. The network session key encrypts the MAC layer, which the network server can decrypt to handle routing and protocol functions. The application session key encrypts the payload, which only the application server can decrypt. The network server sees that a packet arrived from a device and where to route it, but cannot read the contents.

This two-layer model is a deliberate design choice for networks where the infrastructure operator and the application operator are different entities. On a public LoRaWAN network like The Things Network, the infrastructure is operated communally, but your sensor data remains encrypted to the network operator.

For a private self-hosted LoRaWAN deployment where you operate both the gateway and the network server (ChirpStack being the standard open source option), this separation is less important but the encryption is still present.

How this differs from LoRa mesh protocols

Meshtastic and MeshCore both use LoRa as their radio layer. They are not LoRaWAN. This is a source of considerable confusion and worth being explicit about.

LoRaWAN is a star-of-stars network: devices talk to gateways, gateways talk to servers. End devices do not talk to each other. They do not relay each other’s messages. The gateways are fixed infrastructure with internet connectivity.

Meshtastic and MeshCore are peer-to-peer mesh networks. Devices talk directly to each other. Messages hop between devices to extend range. No internet connectivity is required. There is no network server. No application server. No structured topology.

Both use LoRa radio signals. The network architecture is completely different.

This matters practically because they are suited to different problems. LoRaWAN is the right choice for sensor deployments where you have fixed gateway infrastructure and want data to reach a server: environmental monitoring, asset tracking, smart building applications. Meshtastic and MeshCore are the right choice for off-grid communication between people: text messaging without internet, emergency communication, community mesh networks.

You can have both. They run on the same physical hardware (the same LoRa chips, different firmware) and on the same radio frequencies, though running them simultaneously on the same device is not possible.

Frequencies in the UK

LoRaWAN in the UK operates on the EU868 frequency plan, using channels in the 868MHz band. The specific channels and power limits are:

• Default uplink channels: 868.1, 868.3, 868.5 MHz (125kHz bandwidth)
• Additional channels: 867.1, 867.3, 867.5, 867.7, 867.9 MHz
• Join request channel: 868.5 MHz
• Maximum transmit power: 25mW ERP (14 dBm)
• Duty cycle: 1% on most channels

These are licence-exempt frequencies under Ofcom’s Short Range Device regulations, specifically Interface Requirement IR 2030. No licence is required to operate LoRa devices or LoRaWAN gateways in the UK on these frequencies within these limits.

Spreading factors and the speed/range trade-off

One concept worth understanding if you are going to do anything practical with LoRaWAN is the spreading factor.

LoRa transmissions use a spreading factor (SF) from 7 to 12. Higher spreading factors mean the signal takes longer to transmit (more chirps per bit) but can be decoded at lower signal strengths, which means greater range. Lower spreading factors are faster but require a stronger signal.

LoRaWAN’s Adaptive Data Rate feature adjusts the spreading factor automatically based on signal quality. Devices close to a gateway use lower spreading factors (faster, more capacity). Devices at the edge of coverage use higher spreading factors (slower, but they can still communicate).

This is not a setting you typically configure manually in a well-designed LoRaWAN deployment. The network manages it.

Where the pieces fit together

LoRa is the physical radio technology. LoRaWAN is the network protocol. The Things Network and Helium are public LoRaWAN networks that use LoRa. ChirpStack is an open source LoRaWAN network server for private deployments. MQTT is how the data gets from the network server to your application. Grafana is where you might visualise it.

Each layer is distinct. Each layer can be replaced. That is what makes the stack interesting.