The Arduino Guide to LoRa® and LPWAN Technologies
Learn the basics of LoRa® technology and how to use it with Arduino hardware and software.
The Internet of Things (IoT) is often referred to as a collection of objects connected to the Internet using wireless networks; these connected objects aim to collect and exchange information from their surroundings. IoT enables a connection between the physical and the digital worlds; that connection produces a massive amount of data that can be used for the optimization of resources and to improve the efficiency of existing systems.
By 2025, there will be more than 25 billion IoT devices connected to the Internet.
Many of the existing IoT devices will be connected to the Internet using short-range wireless networks such as Wi-Fi®, Bluetooth®, ZigBee, Z-Wave®, etc. Cellular connections using networks such as 2G, 3G, and 4G will also connect IoT devices to the Internet. Still, these short and medium-range wireless networks are not always suitable for IoT devices since they were developed for applications where power consumption and battery life are not significant issues. IoT devices usually have low-power consumption and send and receive low amounts of data.
Low-Power Wide Area Networks (LPWANs)
Low-Power Wide Area Networks (LPWANs) is a group of wireless network technologies well suited to the specific needs of IoT devices: low-bandwidth and low-power devices, usually battery-powered. These types of networks provide low-bit rates over long ranges with low-power consumption. LPWANs can accommodate data packet sizes from 10 bytes to 1 kB at uplink speeds up to 200 kbps; long-range connectivity varies from 2 to 1,000 km depending on the network technology. Most LPWAN technologies have a star topology; this means that each device connects directly to a central access point.
Some of the important use cases for LPWAN's include the following applications:
- Smart cities: smart parking, intelligent street lighting.
- Supply chain management: asset tracking, condition monitoring.
- Smart grids: electricity, water, and gas metering.
- Smart agriculture: land condition monitoring, animal tracking, geofencing.
If you want to read more about LPWANs, check out this article from the Learn section.
Several LPWAN technologies use licensed or unlicensed frequencies and proprietary or open specifications. LoRa® and its Media Access Control (MAC) layer protocol implementation is one of the LPWAN technologies gaining traction to support IoT devices and services.
LoRa® Technology
What is LoRa® Technology?
LoRa® Technology is a wireless modulation technique derived from Chirp Spread Spectrum (CSS) technology. CSS uses wideband linear frequency modulated chirp pulses to encode information. It can operate on the following license-free sub-gigahertz ISM (Industrial, Scientific, and Medical) bands: 433 MHz, 868 MHz and 915 MHz. ISM bands are internationally reserved for industrial, scientific and medical uses.
The Long Range modulation technique was invented in 2010 by the French startup Cycleo and was later acquired in 2012 by Semtech.
LoRa® technology is widely used in LPWAN deployments for applications requiring long-distance connectivity with minimal power consumption.
LoRa® Network Architecture
A typical network using LoRa® technology consists of the following essential parts: end devices (usually sensors), a base station or gateway, a network server and an operations support system (OSS) for provisioning and managing the network.
From the image above, notice there is a fundamental difference between a network server and a gateway. The network server manages message routing, while gateways function as relays that forward data between end devices and the server. LoRa®-based networks can be public or private, depending on the deployment needs.
The Things Network (TTN) is a crowdsourced, open, and decentralized LoRa®-based network server. This network is a great way to start testing devices, applications, integrations and get familiar with LoRa. To connect to TTN, you will need to be in the range of a gateway. Check the world map to see if your local community already has a gateway installed; if not, consider installing one!
LoRa®-based networks are usually deployed in a star-of-stars topology; this means that gateways manage data between end-devices and a network server. Gateways are connected to the central network server via the Internet, while end-devices use LoRa to send and receive data to and from the gateways; end-devices are not exclusively tied to a single gateway, end-devices broadcast information to all the gateways in range. Communication in LoRa-based networks is natively bi-directional, although uplink communication between end-devices and the central network server is expected to be predominant in the network.
Star networks topologies provide the best relationship between long-range communications, the number of gateways or base stations in the network, end-devices power consumption, and battery life.
Star networks present several advantages compared to other network topologies:
- Gateways can be added to the network anywhere and anytime without prior planning.
- Message delivery is more robust since multiple gateways receive the same data packets during each uplink.
Data Rates
Communication between end-devices and gateways in LoRa®-based networks is spread out on different frequency channels and data rates (communications using different data rates do not interfere with each other).
LoRa® technology supports data rates ranging from 300 bps to 5 kbps for a 125 kHz bandwidth.
To maximize the battery life of each end-device and the overall capacity available through the network, LoRa® technology uses an Adaptive Data Rate (ADR) mechanism for optimizing data rates, airtime, and power consumption. ADR controls the following transmission parameters on end-devices:
- Spreading factor: the speed of data transmission. Lower spreading factors mean a higher data transmission rate.
- Bandwidth: the amount of data that can be transmitted from one point to another within the network.
- Transmission power: the energy that the end-device transmitter produces at its output.
The table below shows compares spreading factor, data rate, and time on-air at a bandwidth of 125 kHz (range is an indicative value, it will depend on the propagation conditions):
Spreading Factor | Data Rate | Range | Time on-Air |
---|---|---|---|
SF7 | 5470 bps | 2 km | 56 ms |
SF8 | 3125 bps | 4 km | 100 ms |
SF9 | 1760 bps | 6 km | 200 ms |
SF10 | 980 bps | 8 km | 370 ms |
SF11 | 440 bps | 11 km | 40 ms |
SF12 | 290 bps | 14 km | 1400 ms |
End-devices may transmit on any channel available at any time, using any available data rate, as long as the following rule is respected:
- The end-device changes channel in a pseudo-random fashion for every transmission. The resulting frequency diversity makes the system more robust against interference.
Also, local regulations must be respected, for example:
- In the EU868 band, the end-device must respect the maximum transmit duty cycle relative to the sub-band used and local regulations (1% for end-devices).
- In the US915 band, the end-device must respect the maximum transmit duration (or dwell time) relative to the sub-band used and local regulations (400ms).
Regional Parameters
The LoRa® technology Regional Parameters specification is a companion to the LoRa-based network layer specification. While the LoRa-based network layer specification defines the air interface between a compliant end-device (sensor, actuator, tracker, etc.) and a compliant network core, the LoRa technology Regional Parameters specification defines the adaptation of the LoRa-based network layer specification to comply with the various regulations enforced throughout the world on the use of various frequency bands of the unlicensed spectrum which are available.
Also, the LoRa® technology Regional Parameters specification documents the physical layer configurations required for the compliant operation of LoRa technology Link Layer radios using various radio frequency modulation techniques.
The idea behind the LoRa® technology Regional Parameters specification is to create the smallest number of regional channel plans covering the largest possible number of regulatory regions. With this, complexity is decreased to implementers as well as the certification cost (end-device certification is enumerated by network layer, Regional Parameters and channel plan revision).
LoRa® technology Regional Parameters specifications do not specify everything. They only cover a region by specifying the common denominator. For example, the LoRa technology Regional Parameters for Asia only specify a common subset of channels, but there are variations between regulations in Asian countries. Furthermore, each network server, for example TTN, is free to select additional parameters, such as additional emission channels.
For more information, you can read the RP002-1.0.2 LoRa® technology Regional Parameters document here, we also have a more detailed tutorial about LoRa technology Regional Parameters and Arduino hardware; the tutorial can be found here here
Classes
The LoRa® technology specification has three different communication profiles between devices and applications: Class A, Class B, and Class C. Each class serves different application needs and has optimized requirements for specific purposes. The main difference between the three classes is latency and power consumption; end-devices can always send uplinks when needed, but its class will determine when to receive downlinks.
All network devices using LoRa® technology must implement Class A; Class B, and Class C are extensions of Class A profile.
Class A: "Aloha"
Class A devices implement a bi-directional communication profile where two short downlinks follow the end-device uplink transmission receive windows, usually referred to as RX1 and RX2. If the server does not respond in either RX1 or RX2 windows, the next opportunity will be after the next uplink transmission. Class A devices are often battery-powered and spend most of the time in sleep mode; therefore, they have the lowest energy consumption, keep long intervals between uplinks, and have high downlink latency.
Class B: The "Beaconing" Class
Class B devices extend Class A devices by adding scheduled receive windows for downlinks, and, therefore, they emulate a continuously receiving device by opening receive windows at fixed time intervals. This class should be implemented when low latency of downlink communication while keeping the power consumption as low as possible is required.
Class C: Continuous Reception
Class C communication profile is used in applications with enough power available, so there is no need to minimize the time of the reception windows; this is the case of most actuators (e.g., smart plugs, street lights, electrical meters, etc.) Class C devices always listen for downlinks messages unless they transmit an uplink message. This behavior results in the lowest latency between the server and the end-device.
Authentication and Security
Authentication and security are also important in LoRa®-based networks. Any LoRa-based network has a baseline authentication and security framework based on the AES 128 encryption scheme. Compared to other LPWAN's, which rely on a single key for authentication and encryption, the LoRa technology framework separates both. Authentication and integrity control use a network session key (NwkSKey) while user data encryption uses an application session key (AppSKey).
NwkSKey and AppSKey are AES-128 root keys specific to the end-device, end-devices manufacturers, or application owners assigned them.
LoRa® technology supports two authentication and activation methods: Over-The-Air-Activation (OTAA) and Activation by Personalization (ABP).
- Over-The-Air Activation (OTAA): In this method, end-devices are not initialized for any particular network; they send a JOIN request to a specific LoRa®-based network and then receive a device address and an authorization token from which session keys are derived; NwkSKey and AppSKey are derived during this procedure from a root AppKey pre-provisioned in the end-devices by its manufacturer.
- Activation by Personalization (ABP): In this method, end-devices are personalized to work with a given LoRa®-based network. End-devices are pre-provisioned with the NwkSKey and AppSKey and the 32-bits device network address.
The recommended authentication and activation method is OTAA since it provides a high level of security; ABP method should be used only for specific situations.
Arduino® and LoRa® Technology
Arduino® brings LoRa® connectivity to your projects with several boards, addons and libraries.
Arduino® Boards with LoRa® Connectivity
The MKR WAN 1300 and 1310 boards provide you with a practical and cost-effective solution to applications that require LoRa® connectivity and low-power consumption. The MKR WAN 1300 and 1310 boards are based on a SAMD21 microcontroller from Microchip®; they also features a CMWX1ZZABZ module from Murata® for LoRa connectivity, the ATECC508 cryptoauthentication device for security, and a 2MB SPI Flash memory for onboard storage.
PRO hardware also has LoRa® connectivity. The Arduino® Portenta H7 board can have LoRa connectivity with the Portenta Vision Shield with LoRa® technology; this addon board also features a CMWX1ZZABZ module from Murata® for LoRa connectivity, the same module present in the MKR 1300 and 1310 boards.
The Arduino® Edge Control, a remote monitoring and control solution optimized for outdoor environments, can expand its wireless connectivity capabilities by adding an MKR WAN 1300 or 1310 board. Edge Control can be positioned anywhere and is well suited for smart agriculture and other applications that require intelligent control in remote locations.
Arduino® Libraries for LoRa® Connectivity
You can use several Arduino libraries with the CMWX1ZZABZ LoRa® module from Murata®; we recommend two: The MKRWAN library, developed by Arduino, and the
library, developed by Sandeep Mistry. The MKRWAN and the Arduino Arduino LoRa
LoRa
libraries provide you the APIs to communicate with networks that support LoRa technology.You can use both libraries in the Arduino IDE, online and offline. If you are using the online IDE, you don't need to do anything, both libraries are already installed and ready to be used. If you are using the offline IDE, you must install the libraries manually. Installing libraries can be done easily by navigating to Tools > Manage Libraries... and then look for MKRWAN library by Arduino and LoRa by Sandeep Mistry; remember to install the latest version of the libraries.
Currently, there are two versions of the MKRWAN library; MKRWAN_v2 library is still in beta.
Example: Sending and Receiving Data to a Network Server
Using Arduino hardware and software to communicate with LoRa®-based networks is simple; let's check out an example. This example uses an MKR WAN 1310 board and the MKRWAN library to send data to a LoRa-based networks, in this case, TTN. The circuit for this example is shown in the image below:
Before sending and receiving messages from TTN, you need to register your board first to the network. For this, you need to know your board's
Device EUI
. You can get your board's Device EUI
by running the FirstConfiguration
example from the MKRWAN library. With your Device EUI, you can register your board in TTN by creating an account in TTN, adding an application, and registering your board. This tutorial from TTN explains the process. Once your device is registered on TTN, you can start sending and receiving data with the following code:
1/*2 Send and receive data from a LoRa®-based network3 This sketch demonstrates how to send and receive data with the MKR WAN 1300/1310 board.4 This example code is in the public domain.5*/6
7#include <MKRWAN.h>8#include "arduino_secrets.h"9
10LoRaModem modem;11
12void setup() {13 // Serial port initialization14 Serial.begin(115200);15 while (!Serial);16 17 // LoRa module initialization18 // Initialize the modem with your regional band (eg. US915, AS923,...)19 if (!modem.begin(EU868)) {20 Serial.println("- Failed to start module");21 while (1) {}22 };23
24 // With the module initialized, we can get its version and device EUI25 // Your network server provider requires device EUI information to connect to their network26 Serial.print("- Your module version is: ");27 Serial.println(modem.version());28 Serial.print("- Your device EUI is: ");29 Serial.println(modem.deviceEUI());30
31 // Join procedure to the network server32 // OTAA method need appEUI and appKey, this information is provided by the network server33 int connected = modem.joinOTAA(appEui, appKey);34 if (!connected) {35 Serial.println("- Something went wrong; are you indoor? Move near a window and retry...");36 while (1) {}37 }38
39 // Set poll interval to 60 secs.40 modem.minPollInterval(60);41
42 // NOTE: independent of this setting, the modem will not allow sending more than one message every 2 minutes43 // This is enforced by firmware and can not be changed.44}45
46void loop() {47 Serial.println();48 Serial.println("- Enter a message to send to network");49 Serial.println("(make sure that end-of-line 'NL' is enabled)");50
51 // Get message from Serial Monitor52 while (!Serial.available());53 String msg = Serial.readStringUntil('\n');54
55 // Show the sent message to the network in HEX format56 Serial.println();57 Serial.print("- Sending: " + msg + " - ");58 for (unsigned int i = 0; i < msg.length(); i++) {59 Serial.print(msg[i] >> 4, HEX);60 Serial.print(msg[i] & 0xF, HEX);61 Serial.print(" ");62 }63 Serial.println();64
65 // Check if the message was sent correctly or if there was an error66 int err;67 modem.beginPacket();68 modem.print(msg);69 err = modem.endPacket(true);70 if (err > 0) {71 Serial.println("- Message sent correctly!");72 } else {73 Serial.println("- Error sending message :(");74 Serial.println("(- You may send a limited amount of messages per minute, depending on the signal strength");75 Serial.println("- It may vary from one message every couple of seconds to one message every minute)");76 }77
78 // Wait and check if there's a message sent from the network79 delay(1000);80 if (!modem.available()) {81 Serial.println("- No downlink message received at this time");82 return;83 }84
85 // If there's a message available, store it86 char rcv[64];87 int i = 0;88 while (modem.available()) {89 rcv[i++] = (char)modem.read();90 }91
92 // Decode and show the received message from the network93 Serial.print("- Received: ");94 for (unsigned int j = 0; j < i; j++) {95 Serial.print(rcv[j] >> 4, HEX);96 Serial.print(rcv[j] & 0xF, HEX);97 Serial.print(" ");98 }99 Serial.println();100}
Check out more detailed tutorials we have about sending data between a MKR WAN board to TTN and between two MKR WAN boards; the tutorials can be found here.
Further Reading and Resources
LoRa® technology is pretty extensive but exciting topic to study. If you want to learn more about these technologies, check out the following links:
- LoRa Developer Portal from Semtech. Here you can find technical papers and user guides as well as specifications and datasheets from Semtech.
- The Things Network documentation. Here you can learn all about LoRa® technology and The Things Network!
- The Things Academy online course in Udemy. A free online course where you'll learn all about LoRa® technology, and get ready to start building your own Low Power Wide Area Network applications.
Trademark Acknowledgments
- LoRa® is a registered trademark of Semtech Corporation.
Suggest changes
The content on docs.arduino.cc is facilitated through a public GitHub repository. If you see anything wrong, you can edit this page here.
License
The Arduino documentation is licensed under the Creative Commons Attribution-Share Alike 4.0 license.