Since the last few years, a rise of connected objects has taken place. It is even predicted that the world will have 30 billion connected devices by 2020.
Developing a connected device is not easy, many smart device manufacturers face a shared technical challenge: How to make devices communicate? There are today a multitude of technological solutions, among which LoRaWan, trying to tackle this technical challenge. Among these technological choices, some solutions match specific usage cases such as:
- Do we need the devices to communicate quickly?
- Is energy saving mandatory?
- Are the devices moving or motionless?
- Do we need wireless connection?
In this article, we will focus on the LoRaWan network and present in which condition it can be used.
Let’s focus on LoRa and LoRaWan
LoRa is a proprietary, chirp spread spectrum (CSS) radio modulation technology for LPWAN (Low Power Wider Area Network). It is a patented technology developed by Cycleo (Grenoble, France) and was acquired by Semtech in 2012.
LoRa uses license-free sub Gigahertz radio frequency bands like 169 MHz, 433 MHz, 868 MHz (Europe) and 915 MHz (North America).
LoRaWan for Long Range Wide Area Network, is a communication protocol between a Gateway and a device that would communicate using the LoRa technology. It is maintained by the LoRa Alliance which released the 1.0 version in June 2015.
To summarize, LoRa is the physical layer when LoRaWan is the protocol that uses it.
LoRa Application Layers
LoRaWan network
For communication, this network network uses a star network[1]. For this kind of network, all the devices communicate to a Gateway using the LoRa technology. The Gateway, which has an internet connection (4G/Ethernet/Wifi/…), will forward the data received from the devices to the server and from the server to the devices through a “Packet Forwarder[2]”.
[1] A star network is a topology where a central device (here the Gateway) act as conduit to transmit messages
[2] A program running on Gateway that interacts with the LoRa chip, to receive and transmits LoRa packets, and with the network to transmit them
A LoRaWan network includes the following system
- One or many Devices
- At least one Gateway
- A Server
LoRa Application Layers
LoRaWan Specifications
The specifications can be sent on demand by Semtech or found on the internet. Since the LoRaWan protocol is very well explained, we will focus here on the LoRaWan specificities.
1- LoRaWan Classes specifications
First, the specifications define 3 different modes that can be used within a LoRaWan network:
- Classe A: The communication can be initiated only by the end device. When the end device has a message to send, it will send it and listen for a response during a short time. To do that, it will listen on the same frequency it used to send the message (Rx1) and then it will listen on a specific frequency known by the devices and gateways (Rx2).
- Class B: This mode is like the Class A but the device will also open short regularly reception windows (Rx2).
- Class C: In this mode, the device can send a message whenever it wants, and it will listen for an incoming message at all time (Rx2).
Only the Class A mode is mandatory but allows sending only a message to the device after it sent one first.
The Class B adds the possibility to not wait for the device to start communicating by defining communication slots. This requires a time synchronization between the device and the gateway.
Finally, with the Class C we can send a message to our device at any moment. The device will never go to sleep mode to check if a message comes. As a result, Class C is the mode using the most of resources.
LoRaWan Class
2- Channels and Duty Cycle
Other main key features of the LoRaWan network are the channels and duty cycles. It uses license-free sub Gigahertz frequencies which are supervised in Europe by the European Telecommunications Standards Institute (ETSI).
ETSI Regulation
The allocated frequencies are ranging from 863MHz to 870MHz and are divided into bands, each one with different limitations (power, band width and duty cycle). For example, on the g2 band, the maximum power is 14dbm with a duty cycle of 1%. The device can communicate on the g2 band for 1% of the time (14.4 minutes in 24h).
In Europe, a LoRaWan device can have up to 8 channels with 3 mandatory (868.1MHz, 868.3MHz and 868.5MHz).
3- LoRaWan Spreading Factor
Another feature very specific to this network is the Spreading Factor.
The principle is simple, when a device is close by a Gateway, the risk of radio signal perturbation is low, allowing to have less redundancy and gain speed. Inversely, when a device is far from the Gateway, radio signal perturbations may occur. So, we can transmit further but the speed is slower.
There are 7 different spreading factors call FSK (Frequency-shift keying). These spreading factors are used to adjust the radio signal speed depending on the distance.
LoRaWan Spreading Factor
4-Data Encryption
The last important feature is data encryption. The LoRaWan specifications uses 2 session keys, unique to each LoRa device, to secure the data at both network and application level:
- The first key is the AppSKey (Application Session Key) that is shared between the application owner and the LoRa device. This key is used to encrypt the message payload and is unique per Application.
- The second key is the NwkSKey (Network Session Key) shared between the LoRaWan network provider and the LoRa device. This key is used to calculate a message integrity code from the previous encrypted payload and a network header added to the message. It is unique per Network.
The message composed with a header, the payload and the Message Integrity Code (MIC) is then sent to the LoRaWan network provider that will verify the message integrity to the MIC and NwkSKey. Whether the MIC is good, the LoRaWan network provider will then send the message to the application that will be able to read the payload to the AppSKey.
It is important to separate these 2 keys as in a LoRaWan network, because the provider is not always the application owner.
In fact, some companies like Objenious create their own LoRaWan network to sell the access to user applications. With these 2 keys, Objenious can only verify the message integrity but can’t read the message payload.
LoRaWan Encryptions
These 2 keys can be saved in the LoRaWan device memory or follow an “Over The Air Activation” (OTAA) procedure. In this case, the LoRaWan device will hold:
- An Application Key (AES-128 AppKey) assigned by the application owner for each device (unique)
- A device UUID (EUI64 DevEUI) assigned by the LoRa chip manufacturer (unique)
- An Application Identifier (EUI64 AppEUI) assigned by the network provider to the application (non-unique)
When the application starts, the device will send a specific message to the network with the AppEUI, the DevEUI and a MIC calculated with the AppKey.
The network that also recognizes the AppKey will get the AppEUI and DevEUI and will verify that the device can join the network or not (the DevEUI should exist for the AppEUI in the network provider settings).
Finally, when the device can join the network, a message is sent back to it with data to derive the AppSKey, the NwkSKey and a Device Address (DevAddr) used by the device to communicate.
Smart City scenario, an IoT LoRaWan application
To showcase this technology, we develop a real IoT scenario to demonstrate the usage of LoRa for specific technical requirements. This project called the Smart City Project aims at controlling and monitoring streetlamps by relying both LoRa and Bluetooth Low Energy (BLE) technologies. The Street Light have the following capacities:
- Day/Night detection and light brightness adjustment
- Calendar programming
- Power Consumption reporting
- Remote management through LoRa
- Maintenance operations through BLE
To achieve this, the devices were composed as follows:
- A microcontroller (STM32L476RG from STMicroelectronics)
- A Bluetooth Low Energy shield (BlueNRG-MS from STMicroelectronics)
- A LoRaWan class C module (mDot from Multitech)
- A Light sensor
Street Light Prototype
The Gateway has been developed around the “LoRa Lite Gateway” from IMST based on a Raspberry pi 2 and the IMST LoRaWan Concentrator chipset (IC880A-SPI). The selected LoRaWan module allows reception of LoRa packets from different end devices sent with different spreading factors on up to 8 channels in parallel.
LoRa Lite Gateway (IMST)
1- Packet Forwarder set-up
As explained earlier in this article, the aim of the Gateway is to forward packets from/to devices to/from server thanks to a “Packet Forwarder”. The “LoRa Lite Gateway” has a pre-installed Packet Forwarder made by Semtech[3]. With a minimal configuration of a file named “global_conf.json” (server IP, port, LoRa frequencies, …), it is possible to have in a short time the Gateway ready to forward packets.
[3] https://github.com/Lora-net/packet_forwarder
2- Server set-up
After bringing up the “Packet Forwarder”, you need a server that receives the packets to process them. This can be hosted on the cloud or private server, but it can also run on the Gateway. There are already existing open source projects available that implement the LoRaWan server functionality. For this project we used the lorawan-server project from “gotthardp” available on github[4].
The first thing to do is the configuration of the Gateway from the user interface, by adding its MAC address to identify it. More configurations parameters are available, like specify the Gateway location. Then, on the devices settings of the LoRaWan server, it requires to add end-devices to the network by providing for each device an AppEUI, AppKey and DevEUI for a successful Over The Air Activation.
[4] https://github.com/gotthardp/lorawan-server
With all those keys the server will be able to receive packets and automatically proceed them for integrity verification and read the information stored in the packets header and then extract the payload.
The payload can be processed by a custom developed internal application (hosted within the server) or by forwarding it to an external application through WebSocket or MQTT. The project uses the MQTT option and payload data are processed by a remote node red server.
The LoRaWan-server project comes with a riche documentation[5], helpful to fine tune the configuration options for a better integration into your scenario.
[5] https://github.com/gotthardp/lorawan-server
LoRaWan Server Components
3- Node Red Server
To process data, you can use a Node Red server with a simple node that send and receive data. By adding an MQTT input connection with the IP and topic of the LoRaWan server to receive messages. Then we linked the input node to some other nodes to process data.
4- Firmware set-up
From a device perspective, we created a firmware able to send and receive LoRa messages. We do have choosed the mBed OS 5 for this firmware to provide more flexibility in our development, opening the addition of functionalities in a more simple way.
The mDot we used for LoRaWan communication can be controlled with serial communication and AT command. The first thing to do, is enable the serial communication with the mDot that can be done very easily with mBed.
Once the mDot is reachable, we began the LoRaWan communication by making an “Over The Air Activation” with the correct AT command, available on the Multitech mDot documentation and the DevEUI and AppEUI identifier.
The server should answer the device with a join accept message, allowing the mDot to communicate with the LoRaWan server to send and receive data. All of this can be done very easily by following the mDot documentation and example that can be found on the mBed website.
After developing all these parts, the project was ended and all a fancy demonstration package including both the devices and the Gateway Here is the result:
Final Demonstration Box
LoRaWan is a Long Range Wide area network energy saver, it is one of the most suitable technology for objects using batteries.
Its transmission distance and penetration make it very suitable for smart city usage (street light, parking place detector, …). However, it has low data rate, it is limited payload and duty cycle regulation may not meet application requiring real-time communication.
Pros : |
Cons: |
|
|
References
- LoRaWan server github project: https://github.com/gotthardp/lorawan-server
- LoRaWan server documentation: https://github.com/gotthardp/lorawan-server/tree/master/doc
- The Things Network: https://www.thethingsnetwork.org/
- Semtech Packet Forwarder: https://github.com/Lora-net/packet_forwarder
- LoRa alliance:
https://www.lora-alliance.org/ - LoRaWan specifications: https://www.rs-online.com/designspark/rel-assets/ds-assets/uploads/knowledge-items/application-notes-for-the-internet-of-things/LoRaWAN%20Specification%201R0.pdf
- Multitech mDot: https://www.multitech.com/brands/multiconnect-mdot