LoRa (“long range”) is an excellent wireless communication solution without network capabilities. It is a reliable, low-power, cryptographically protected, low-cost wireless connectivity technology. And as its name suggests, it offers an extremely long range.
LoRa operates at the physical layer of an OSI model and is implemented at the chip level – excluding the network management protocol. This has become an advantage as system engineers can implement data link and network layer protocols over LoRa modulation and according to the requirements of a specific application.
In Europe, most LoRa networks are in do-it-yourself setups. In addition to custom networks, the ideal networking solution for a LoRa network is LoRaWAN.
LoRaWAN is an open LPWAN protocol designed to operate on LoRa modulation, adding data links and network layer protocols. The protocol is responsible for configuring end devices and managing point-to-point data communication.
This article will discuss how devices are configured in a LoRa network and how LoRaWAN connects them to the Internet. For an introduction to these technologies, first read What is LoRa and LoRaWAN? .
LoRaWAN network elements
There are five building blocks of a LoRaWAN network that are connected in a star of stars topology:
1. End devices are sensors, actuators, or both. They contain a chip for LoRa RF modulation and communicate wirelessly using LoRa technology. Most run on battery power as part of an IoT network, connecting to the LoRaWAN network via gateways. End devices follow a random access protocol, ALOHA, and can access the network through one or more nearby gateways within range.
2. Inputs are devices responsible for forwarding messages to and from end devices to a network server. The gateway has an IP backbone that is cellular (3G/4G/5G), fiber optic, Ethernet, Wi-Fi or 2.4 GHz radio link, which connects to the server. Each gateway is registered with a LoRaWAN network server.
When an end device transmits an uplink message, it is received by all nearby gateways within its range. The message is forwarded to the network server, where it is isolated by deduplication. This network architecture of end devices and gateways ensures uplink packet accuracy and serves as low-cost localization. When the gateway receives a downlink packet for delivery to an end device, the payload is transmitted without interruption.
Gateways operate at the physical layer of the OSI model and serve as forwarders of LoRa RF messages. Gateways are broadly classified into internal and external gateways. Eight- or 16-channel internal gateways do not have an antenna and therefore have lower receiver sensitivity and range than external gateways. Indoor gateways are ideal for multi-story buildings and deep indoor locations.
The 64-channel outdoor gateways have high receiver sensitivity and long range. They are typically connected to an antenna with a coaxial cable, so they are ideal for outdoor cell towers or tall buildings.
3. Network server is the server-side software for LoRa network management, managing data communication between end devices (connected to the network server via gateways) and the application server. This server authenticates end devices, deduplicates uplink messages, encrypts uplink and downlink messages between end devices and application servers, and confirms uplink messages.
Additionally, it is responsible for addressing devices in the LoRa network through ADR commands, routing downlink messages to end devices through appropriate gateways. The network server is the only server that forwards membership request and membership acceptance messages between end devices and the membership server.
4. Application server is the server-side software responsible for running the main application and providing a cloud-based business solution. There can be multiple application servers connected to a network server, each running a specific server-side application. Application servers receive application-specific uplink data messages from end devices through the network server, process application data, and return results as application layer downlink payloads.
5. Connect to Server is the server-side software responsible for processing membership request and membership acceptance messages between end devices and the application server. Junction Servers were introduced with LoRaWAN v.1.1 for the LoRa architecture to enable OTAA. End devices require activation via network and application session keys. The junction server processes join request messages, generates application session keys, transfers network and application keys to the network server and application server, and enables end device activation.
End devices connected to a LoRa network are activated in two ways, Activation by Personalization (ABP) and Over-The-Air Activation (OTAA). ABP provides end devices encoded with keys to configure and join a LoRa network. However, it has security issues and does not have features for online updates.
LoRaWAN device classes
End devices have three types of LoRaWAN implementations (Class A, B, and C), called device classes. All LoRaWAN end devices have Class A implementation. They may or may not have Class B or Class C implementations.
The three LoRaWAN implementations differ in how the device receives downlink payloads and how long it remains active.
Class A is implemented on all LoRaWAN end devices. Class A-only devices are mostly in sleep mode and only communicate with the application server intermittently.
The device can send an uplink data message to the application server at any time. After each uplink transmission, the device opens two short receive windows for the application server's downlink payloads. The application server can transfer the downlink payload in either the first or second end device receive window, but not both.
If the device cannot receive a downlink payload after an uplink transmission, another downlink will start after the next uplink. LoRaWAN Class A end devices are typically sensors for alarms, environmental monitoring, or location tracking.
Class B devices have a scheduled receive window for periodic downlink loads from the application server. Devices are configured to open reception windows in response to time-synchronized beacons from the network server. They also have Class A implementation and open two short reception windows after each uplink transmission.
Class B devices are intermittently active, so they have shorter battery life and lower latency than Class A devices. They are often used for logging or reporting sensor data.
Class C devices have a continuously active receive window, allowing them to receive downlink payloads without any latency. LoRaWAN devices have half-duplex bidirectional data communication, so they cannot receive downlink payloads when transmitting uplink messages. They are powered by the mains and remain in active mode. Utility meters operating shut-off valves are an example of device usage.
End device activation
There are two end device activations in a LoRaWAN network, Activation by Personalization (ABP) and Over-The-Air Activation (OTAA). With LoRaWAN v1.1, OTAA is the preferred method of device activation. Device activation is a step-by-step procedure and is fully managed by a junction server in a LoRa network.
Types of messages
Messages communicated between end devices and the application server in a LoRa network contain application data and/or MAC commands. LoraWAN features bidirectional half-duplex data communication between the network server and end devices. Messages are classified based on the direction of the data.
In terms of direction, they are classified as follows.
- Uplink messages are transmitted by end devices to the junction or application server. Messages sent to a junction server typically contain MAC commands. Those communicated to the application server generally contain MAC commands and/or application data. Messages are received by the network server through multiple gateways and routed to a junction or application server based on the MAC message type.
- Downlink messages are sent by the network server to end devices. The message is relayed through a single gateway by the network server to render it to an end device.
MAC Message Types
Messages in a LoRa network are routed through the network server according to the MAC message type. The following MAC message types are available in the LoRaWAN 1.1 and LoRaWAN 1.0 specifications.
- Join Request: An uplink message from an end device for OTAA activation.
- Join accept: A downlink message from a join server for OTAA activation of an end device.
- Rejoin Request: An uplink message to rejoin the LoRA network from an end device. This message type is reserved in LoRaWAN v1.0, but available in LoRaWAN v1.1.
- Uncommitted Data: An uplink data frame in which acknowledgment is not required.
- Unacknowledged Data Disabled: A downlink data frame in which confirmation is not required.
- Acknowledged Data: An end device uplink data frame by which acknowledgment (i.e., network server acknowledgment) is requested.
- Confirmed data: A network server downlink data frame where confirmation is requested.
- Owner: A non-standard proprietary message.
LoRaWAN Security
The LoraWAN radio link is reliable due to chirp modulation. In addition to FSK-type modulation, the LoRaWAN architecture is designed to ensure that messages are delivered with maximum accuracy.
Uplink messages are communicated to multiple gateways and deduplicated on the network server, leaving no chance of data corruption. Network communication is protected with 128-bit security keys, including NwkSKey, AppSKey, and AppKey. The AES-128 algorithm is used to encrypt messages, which is similar to the encryption in the IEEE 802.15.4 WiFi standard. With OTAA enabled, there is essentially no possibility of device hacking or man-in-the-middle attacks.
For unique identification of end devices by the application server, an AppKey application key is shared only between the application server and end devices. There may also be a standard application key used for multi-device activation or custom application keys generated per end device. This key is used to generate the network and application session keys.
Once an end device joins the LoRa network, the network server generates two security keys: the network session key (NwkSKey) and the application session key (AppSKey). These session keys are only applicable during a single session.
The network session key is shared and used to authenticate the end device to the network server. The key maps non-unique device addresses to DevEUI and AppEUI 64-bit extended unique identifiers. Only the authorized end device can join the LoRa network due to the network session key. The Message Integrity Code (MIC) uses the same key, which serves as a checksum to validate the integrity of the message.
The application session key encrypts and decrypts downlink payloads between end devices and the application server. This key is private and never shared across the network, so only the authorized end device can transmit or receive messages with the application server.
On OTAA activation, both session keys generate a unique session per device. In ABP activation, keys are regenerated only when explicitly changed.
Data security is further diversified with the use of frame counters. There are frame counters for uplink and downlink messages. When an end device is activated, both frame counters are set to 0. When an uplink message is transmitted, its frame counter is updated.
Likewise, the downlink frame counter is updated immediately when an end device receives a downlink payload. The end devices and application server ignore any message that contains a frame counter value that is lower than the updated frame counters.