LoRaWAN Overview
Home > LoRaWAN Overview
This section provides a high level overview of LoRaWAN networks, focussing on the component network elements and architecture of an IoT network solution.
LoRaWAN is one type of Low Power WAN (LPWAN). LPWANs are wireless wide area networks designed to allow long-range communications at a low bit rates, with the aim of enabling end devices to operate for extended periods of time (years) using battery power.
In general, a LPWAN connects devices - typically low power embedded systems or microcontrollers - that are equipped with a wireless network interface. These devices communicate via wireless protocols to a fixed, powered gateway, which in turn connects to an IP internetwork, or the Internet.
LoRaWAN is a LPWAN technology standard developed and maintained by the LoRa Alliance, an industry-based association consisting of telecommunication companies, manufacturers, system integrators and others. The technology platform can be segmented into two broad components:
- LoRa: the proprietary radio modulation technology used by LoRaWAN for wireless communication between devices and gateways.
- LoRaWAN: a media access control (MAC) layer protocol for transferring management and application messages between a Network Server and Application Server, respectively.
The diagram below shows the end-to-end architecture of a LoRaWAN IoT network.
The four major network elements shown are:
- Devices: IoT endpoints that send and receive messages over a LoRa wireless network.
- Gateways: Act as relays that send messages from devices to the network server, and vice versa.
- Network Server: Sends and receives LoRaWAN messages to and from devices, and communicates with upstream application servers.
- Application Server: The destination for device application data sent as payload in LoRaWAN messages.
As shown, the topology is organised as a "star of stars", with the network server connecting to multiple gateways, which in turn connect to multiple devices over a LoRa wireless network. Communication is bi-directional, although upstream communication is the expected predominant IoT traffic type.
In the diagram we have shown two LoRaWAN messages sent by two wireless devices, denoted orange and green. In the upper LoRa wireless coverage area, a device sends LoRaWAN messages using the LoRa wireless network; this message is received by a gateway and sent to the network server. In the lower coverage areas, a device sends a similar LoRaWAN message which is received by two gateways, with both messages being forwarded to the network server.
We have shown the two devices associated with two different application servers: i.e. In LoRaWAN, an application defines how devices are associated with a specific application server back-end, and all devices associated with a particular application share the same security context.
The gateways send the LoRaWAN messages received from the wireless interface using the Gateway Message Protocol (GWMP) defined as per the LoRaWAN Gateway to Server Interface specification. The LoRaWAN message and associated control data are sent as a JSON-encoded message over a UDP/IP. Note the gateway can send and receive from one or more network servers.
The LoRaWAN specification does not define how the network server communicates with application servers. Rather, this is defined by the application server interfaces, which will typically use common IOT application messaging standards such as MQTT, AMPQ, HTTP, etc.
The diagram below summarises the protocols used between each of the LoRaWAN network elements.
End-devices send and receive LoRaWAN messages with gateways on different frequency channels and data rates as defined by the LoRaWAN Regional Parameters document, a compliment to the LoRaWAN specification. The following bands are currently supported:
- EU 863-870 MHz
- US 902-928 MHz
- China 779-787 MHz
- EU 433 MHz
- Australia 915-928 MHz
- China 470-510 MHz
- AS 923 Mhz
The LoRa physical layer allows selection of specific data rates, defined by the relevant band specification. Each data rate allows the trade-off between communication range and the message duration. Note that communications using different data rates do not interfere with each other.
Each data rate is defined by the use of different modulation levels, or spreading factors, in combination with a channel bandwidth. Together, these parameters influence the physical bit rate and time on air. For example, the US915 supported data rates are detailed below, which span from 980 through to 21900 bps.
| Data Rate (DR) | Spreading Factor (SF) | Bandwidth (kHz) | Bit Rate (bps) |
|---|---|---|---|
| 0 | SF10 | 125 | 980 |
| 1 | SF9 | 125 | 1760 |
| 2 | SF8 | 125 | 3125 |
| 3 | SF7 | 125 | 5470 |
| 4 | SF8 | 500 | 12500 |
| 8 | SF12 | 500 | 980 |
| 9 | SF11 | 500 | 1760 |
| 10 | SF10 | 500 | 3900 |
| 11 | SF9 | 500 | 7000 |
| 12 | SF8 | 500 | 12500 |
| 13 | SF7 | 500 | 21900 |
To maximize device battery life and overall capacity, LoRa network infrastructures use an Adaptive Data Rate (ADR) scheme to manage the individual data rates of each connected device. End-devices may transmit on any channel available at any time, using any available data rate, as long as the following rules are respected:
- The device changes channel in a pseudo-random fashion for every transmission, providing frequency diversity.
- The end-device must respect any transmit duty cycle limitations as defined by the band specification.
A device can operate according to three different communication profiles - known as Class A, B and C. Each class optimises different aspects of battery life and latency requirements. Each profiles is outlined in the table below.
| Class | Profile Description |
|---|---|
| A | Battery powered devices, where each end-device‘s uplink transmission is followed by two short downlink receive windows, minimising time required to listen. Must be supported by all devices. |
| B | Latency controlled downlink using slotted time-synchronised communications, allowing for more frequent downlink transmissions. |
| C | Powered devices that continuously listen to downlink messages. Will use more power to operate than Class A or Class B but offer the lowest latency for downlink transmission. |
LoRa gateways act as a bridge between the LoRa wireless network and the IP internetwork. Gateways acts as wireless base stations for multiple devices, with wireless coverage spanning small areas (e.g. buildings) through to larger outdoor areas. Deployment of multiple gateways enables very large urban and rural networks to be developed.
As a gateway has LoRa wireless interface(s), it must also comply with the communications requirements, channel allocations and data rates defined by the relevant band specification. In addition, gateways implement the GWMP interface, enabling communication with the upstream Network Server. Gateways also typically perform downlink scheduling for Class A and B devices.
The network server peers with all device endpoints (via LoRaWAN) that are configured to be members of applications defined by the server, and are connected via gateways within their coverage area. There is no given standard for how a network server is located within the LoRaWAN network topology. It may be embedded within a LoRa gateway, or it could be co-located with application servers in a data centre.
The network server provides three key functions:
- Authentication and authorisation of devices
- Management and optimisation of the network
- Interfacing with upstream application servers
The network server receives messages from devices, managing device authentication, application message routing, and management of gateways and devices. It will dynamically select the best gateway for device data routing, as well as de-duplicating packets and optimising radio resources via the ADR function.
A LoRaWAN network server supports two authentication and activation methods described in the specification: Activation by Personalisation (ABP) and Over-The-Air Activation (OTAA).
Activation by Personalisation
ABP involves pre-provisioning devices to operate on a given LoRaWAN network, defined by its Network ID. Devices are configured with network and application session keys, along with a pre-allocated 32-bits device network device address. The IP analogy of this scheme is a static address allocation.
Over the Air Activation
OTAA requires devices to send a JOIN request to a network server, and if authenticated, will allocate a device address and a token to derive session keys. The network and application session keys are derived during the Join procedure, from a shared AppKey pre-provisioned in the device. OTA Activation provides a high level of security, and addressing is analogous to allocation of an IP address via DHCP.
If supported by an end-device, the network server can perform Adaptive Data Rate (ADR) adjustments, based on the received SNR of each device. In effect, the use of ADR results in devices spending less time on air, improving radio resource efficiency, whilst also managing the reliability of messages.
As illustrated in the network architecture, duplicated messages can be received at the network server from one device transmission that is received and forwarded by multiple gateways. The network server should de-duplicate these messages and respond to, or forward the message once.
Devices will utilise the fport parameter within LoRaWAN messages to distinguish MAC control messages from application messages. When sending a control message, fport will be set to zero.
Ultimately, the aim of any IoT network implementation is to enable the exchange of messages from sensor or actuation devices and the corresponding IoT application. There is a wide range of IoT platforms that can be utilised, including large cloud providers, device management and connectivity platforms, and industry-specific solutions.
Some of the more popular cloud-based platforms include:
- Amazon Web Services (AWS) IoT
- Microsoft Azure IoT
- Google Cloud Platform
- ThingWorx IoT
- IBM Watson
Each platform defines the relevant protocols, message semantics and APIs to enable authentication and communication of device message data, upstream and downstream. In order to support a specific platform the network server must provide the relevant interfaces to enable mediation between devices and its applicaiton platform instance.