Introduction to LoRaWAN
LoRaWAN provides long-range wireless connectivity for low-power IoT end-devices operating in unlicensed spectrum worldwide. This technical note provides a high-level overview of LoRaWAN from physical to network layer.
LoRaWAN is a low-power wide-area network (LPWAN) protocol that is optimised for use with mobile or stationary battery-powered end-devices. A key technology in today’s Internet of Things (IoT) landscape, LoRaWAN is maintained by the non-profit and open membership LoRa Alliance.
Since the first LoRaWAN specification was released in 2015, this technology has seen considerable worldwide deployment and increasing adoption by traditional cellular network operators. Being built from the ground up for IoT application has enabled LoRaWAN to disrupt traditional wireless M2M communications through significantly reduced power consumption and operation/hardware cost (both at end-device and base station). At the same time, LoRaWAN has certain characteristics that ensure it will take a significant role in an ecosystem where other IoT players such as Sigfox, Ingenu, Weightless, and LTE Cat-M1/NB1 are all continuing to jostle for market share.
This technical note provides an overview of LoRaWAN at its physical, link, and network layers.
Basic Network Structure
LoRaWAN networks adopt a star-of-stars topology made up of five different logical entity types: End-Devices, Gateways (also known as concentrators, or base stations), and the Network, Application and Join Servers.
End-Devices are the “things” from which data is collected, or to which commands are sent. These units are often (but not necessarily) battery powered and may include various sensors and/or actuators as appropriate for their application. End-Devices communicate wirelessly with one or more in-range Gateways in accordance with the medium access control (MAC) and physical layer (PHY) protocols set forth in the LoRaWAN specification, and as discussed below.
Gateways relay End-Device messages to/from the Network Server, usually by a secure IP-based connection. Like End-Devices, Gateways integrate a LoRaWAN radio, but one with much higher performance and functional requirements (e.g., increased linearity and ability to operate on multiple channels simultaneously). Multiple Gateways may receive an End-Device transmission and forward it to the Network Server. Responses from the Network Server will be sent to the End-Device via a single Gateway (normally the one which has seen strongest signal from the End-Device).
The Network Server, Application Server and Join Server together provide the core network functionality for a LoRaWAN deployment. These three are logically independent, and have standard interfaces defined by the LoRa Alliance, however for simple networks they may be implemented together in a single node.
The Network Server is the primary point of contact for the Gateway. It implements the LoRaWAN link and network layer protocols (including de-duplication of uplink messages from an End-Device that have been received by more than one Gateway), therefore allowing the Gateway nodes to provide a relatively-simple translation of over-the-air packets to/from IP-based messages.
The Join Server is responsible for implementing the server side of the Over-the-Air Activation (OTAA) procedure (discussed later), which allows End-Devices to authenticate and gain access to the network with security credentials. OTAA messages received by a Network Server are relayed to the relevant Join Server which then attempts to progress the join procedure.
Application Servers manage all application layer communication with End-Devices that are active on the network. Application Servers act as proxy for customer-specific end-application infrastructure. When a Network Server receives a message with application payload from an End-Device, it relays this to the applicable Application Server for decryption and onward forwarding as appropriate. Similarly, an Application Server receiving a message for an End-Device will forward to the relevant Network Server, which will then arrange transmission of the message through the appropriate Gateway.
Physical Layer
LoRaWAN allows radio communication between Gateway and End-Device to take place using one of two different modulations: its own LoRa physical layer, and a Gaussian frequency-shift keying (GFSK) scheme.
The preferred LoRa physical layer (PHY) uses a chirp spread spectrum (CSS) modulation with parameterised spreading factor and modulation bandwidth to provide raw data rates of up to 22 kilobits per second (kbps). LoRa’s modulation scheme has a constant envelope (i.e., there is no amplitude modulation), making it easy to implement low-cost and high-efficiency power amplifiers. In addition, the properties of the LoRa signal make it relatively immune to multipath, fading, and Doppler effects.
The LoRaWAN GFSK PHY provides a higher data rate of 50 kbps, at the expense of some of the attractive properties of the LoRa PHY described above.
At the lowest LoRa PHY data rates, communications ranges of up to 15 kilometres are possible with clear line of sight.
LoRaWAN, and both available PHYs, are specified and intended for use in the unlicensed sub-GHz ISM frequency bands at about 433, 868, and 915 MHz as variously available worldwide. Nonetheless, both physical and MAC layers are essentially frequency-agnostic, so deployment in other bands is possible in private networks.
Link Layer
On the uplink from End-Device to Gateway, LoRaWAN employs an “ALOHA” medium access control method – that is, the End-Device simply transmits a new message (on one of a specified set of channels) whenever it wants. Following transmission, the End-Device enters receive mode during two windows – each a specified time after the end of the uplink transmission. In these windows, the Gateway may transmit a message (containing an acknowledgement and/or data) to the End-Device.
This basic medium access control functionality is the minimum set required by the LoRaWAN specification and is referred to as “Class A”. Aside from occasions of uplink transmission and the subsequent receive windows, Class A devices may otherwise enter a low power state by disabling their radio and entering a sleep mode. As such, Class A provides for the lowest power LoRaWAN devices, while still minimising uplink communications latency.
While Class A devices have low power consumption and uplink latency, this is achieved at the expense of downlink performance. Class A devices can only receive downlink communications following uplink transmissions, so suffer either latency or power consumption penalties in downlink-dominated application scenarios.
To address this limitation, LoRaWAN also defines an optional device “Class B”, which builds on the Class A functionality by adding support for network-initiated downlink transmission in windows referred to as “ping slots”.
LoRaWAN devices implementing Class B maintain timing synchronisation with the Gateway(s) by receiving periodic (and synchronised) Gateway transmissions of a “Beacon” message (for example, every 128 seconds). Once the End-Device has achieved timing synchronisation with the Gateway it will then enter receive mode during its ping slots so that it is available to receive any downlink communications from the network.
For devices that do not have significant power constraints (e.g., have mains power available), LoRaWAN defines a third class of functionality – “Class C” – where the End-Device stays in receive mode at all times except when transmitting. This behaviour leads to minimum uplink and downlink latency, but at the expense of power consumption. End-Devices may switch between different classes of operation based on their application requirements, but not all classes of operation may be supported by a given network deployment.
Security
The LoRaWAN security architecture considers two domains: the network, and the application. With AES-128 used as the primary cipher, and packet counters providing replay detection, LoRaWAN provides for dynamic or static establishment of network and application session keys that are used to authenticate and encrypt network management and data communications, respectively.
Before entering service, a LoRaWAN End-Device must be “activated” to establish the relevant session keys. Activation may be achieved by one of two methods: Activation by Personalisation or Over-the-Air Activation.
Activation by Personalisation (ABP) involves the manual installation (either on the production line, or by some out-of-band method in the field) of the relevant keys into both the End-Device and Network/Application Servers. While this method is suitable and simple for private and test LoRaWAN deployments, it can present significant administrative challenges at scale.
In contrast to ABP, Over-the-Air Activation (OTAA) provides a more scalable method for establishing the required security credentials. The LoRaWAN specification provides a protocol that allows an End-Device, provisioned only with suitable Extended Unique Identifiers (EUIs), to communicate with a Network/Join Server and establish session keys over-the-air.
The OTAA exchange involves the End-Device transmitting a message containing its EUIs and a nonce, with the network responding (assuming it wishes to accept the request) with its own nonce and various network configuration information. The information exchanged by these messages is used independently at the two end-points to derive the required session keys and activate the device.
Applications
LoRaWAN has a sufficiently simple design to enable very low cost end devices, but at the same time provides sufficient throughput and low enough latency to support non-trivial IoT applications, and key auxiliary communication scenarios such as over-the-air firmware update.
A particular strength of LoRaWAN, however, lies in the ease with which private network deployments can be made. This presents a significant advantage for applications where coverage may be required in rural or remote areas that public LoRaWAN deployments have not yet reached. It also is a key area where LoRaWAN stands apart from alternative wireless IoT technologies such as cellular M2M (e.g., LTE Cat-M1/NB1) and Sigfox, whose deployment models are not as flexible.
Key applications for LoRaWAN can be found across a range of verticals including smart city, agriculture, industrial control, and metering. From flood and moisture monitoring to street lighting, intelligent bus signage, animal tracking, and electricity meter reading, LoRaWAN is seeing significant deployment in products and services that we rely on every day.
Conclusion
LoRaWAN is a key technology for the Internet of Things. Its simplicity and ability to support low-cost, low-power end devices with bidirectional communications at range, mean that it is well-suited to use in a range of fixed and mobile IoT applications.
With robust and scalable physical layer options, LoRaWAN can provide power-efficient communications over significant distances. The link and network layer protocols provide for scalable and efficient networks, and allow selection and adjustment of key parameters to optimise the power consumption versus uplink/downlink latency trade-off to meet the needs of individual applications.
The properties of the LoRa physical layer and the simplicity of the LoRaWAN make it possible to achieve extremely low unit and operating costs for end-devices, and transceiver silicon and modules are available from an increasing range of vendors. The LoRaWAN specification is freely available and maintained by the non-profit LoRa Alliance.
About Virscient
Virscient is an official Semtech LoRa and LoRaWAN design partner, and helps innovative companies design, develop, and integrate secure wireless connectivity for “things”. Our expertise spans all layers of the network stack from physical to application, and a wide range of technologies including LoRaWAN, Bluetooth, Wi-Fi, IEEE 802.15.4, and many others. We can assist with technology selection/evaluation, system specification, hardware/software design, implementation, optimisation, and verification. We can provide expert advice to close knowledge gaps and train your teams, or can take full responsibility for subsystem development.
For more information on how we can help you accelerate development of secure connected products please review our capabilities, or get in touch. To hear about any new or updated technical notes on wireless technology then follow us on LinkedIn.
Additional Resources
For more information on LoRa and LoRaWAN, check out the following resources available from Semtech and the LoRa Alliance.
