LoRaWAN protocol in publishment from things to cloud-based backend
This article will explain how to embed, through The Things Network (TTN), the LoRaWAN protocol in the previous article's architecture. The new artifact will take the place of the MQTT-SN protocol accessing to the gateway, and will directly connect things to a bridge between TTN and the built-in Azure IoT Hub broker. It will be discussed the modality to access TTN from any involved node, the libraries used to set up a connection and publish the data and the deployment of the produced artifacts on real hardware for testing.
Github repository: https://github.com/gabr-iele/DevToAzureTelemetry
What are LoRaWAN and TTN
The LoRaWAN (Long Range Wide Area Network) protocol is designed to allow the wireless connection of battery devices in a big range of distance, focusing on key aspects of IoT communications such as energy consumption, end-to-end security, bi-directional communication.
The communication is established and managed between end nodes and built-in gateways, which receive the messages sent by the first ones and route them. The whole LoRa infrastructure is composed of a star-of-stars network topology, in which each gateway receives messages by the components of its subnetwork and acts as a bridge, adapting packets and forwarding them to a master node composed by a central network server. The picture below emphasizes the difference between the communication from a node to the gateway, based on radio signals, and the one from the gateway to the server, which is over IP.
The protocol belongs to the LPWA (Low Power Wide Area) family of networking protocols, designed to maximize the efficiency based on the tradeoff between battery consumption and range of the signal.
The Things Network is a shared open infrastructure providing the possibility to connect things in a network, making use of the LoRaWAN technology. Actually it is composed of thousands of gateways (LoRa radio devices) running and receiving data from registered devices, identified by a set of parameters generated at registration time. It also ensures confidentiality in end-to-end communication, providing encryption of the data transmitted by the involved nodes. Thanks to it, things can interact over radio communication with the various gateways, which will then convert to communication over the net and interact with central TTN servers. Below a scheme of the TTN stack can be found, showing the various phases of the interaction with the things and the steps which lead the traffic to the application server.
Setup of the application
As mentioned in the introduction, the aim is to allow the virtual environmental stations of the previous article to connect and publish values using TTN and a transparent bridge from TTN to Azure. The full procedure will be covered focusing on three main steps: the preparation of the TTN resources, the code of the nodes and the bridge, and the deployment of the nodes on the IoT-Lab Testbed Facility.
1. TTN registration
To start working with TTN, an account is required; it can be done by registering at this link.
Then access to the Console, by clicking on the profile tab, and create a new application. This will be the scope in which the devices of the application will act. Choose a unique ID, add a description and generate the new application. At the end of the operation, the page will show the APP EUI (an identifier that will be used to access TTN from the related devices) and the access keys of the app.
Once the application is ready, register to it as many devices as needed. For the purpose of this tutorial, two devices, representing two virtual environmental stations, will be created. To do this, go to the tab of devices on the page of the application and start the registration of a new device. Then enter an ID for the new device and set all other required parameters as self-generated. At the end of the process, the page will show the following configuration parameters for the device:
- Device EUI: the unique identifier for the device in the network
- App Key: the key used within the app to secure the communication in both directions
- App EUI: the unique identifier for the application, retrieved at the end of the creation of the application before
These parameters have to be saved for every generated device since they will be used by the various nodes to connect to the gateway. In fact, before that any message is sent, the application requires the setting of these three parameters, which together ensure both confidentiality and authentication, to identify the node attempting to connect with one of the saved devices.
2. Code of node and bridge
The code mentioned below is contained in the RIOT_loramac folder contained in the repository cloned in the previous article.
The code of the RIOT node is based on the "semtech_loramac.h" library provided by RIOT. It contains functions for the setting of the device parameters, sending messages to the gateway, joining the network, etc.
The node can make use of two main commands:
> set <deveui|appeui|appkey> <param>
used to set the three configuration parameters mentioned before, necessary for the communication, and
> start
to begin the routine publishing the random values.
With respect to the previous article, some details have been changed due to the new architecture:
- Since dealing with radio signals, the loramac_semtech library specifies a duty cycle for each node, which applies restriction on the time the node can be active and how much it has to wait after a transmission to start a new one. Due to this new restriction, the stations transmit messages, each containing the measurements of one sensor, at intervals of 10 seconds, to avoid refuse of messages: this means that each sensor virtually sends a value every 50 seconds.
- There are restrictions also on the dimension of the payload, in order to limit the usage of the network to each device and give a fair amount of resources to each user. Due to this, the format of the payload has been changed to a simpler one ({'sensor', 'station', 'value'}) to send as little data as possible; the format will be readapted by the bridge to the one used previously when a message is received by it.
Concerning the bridge, it is implemented by a Python program which makes use of the paho MQTT library by Eclipse. It creates two MQTT clients (one for the TTN side and one for the Azure side) which connect to TTN
client_ttn.connect("eu.thethings.network", 1883, 60)
and to the Hub
client_az.connect(iotHubName, 8883)
The code for the Azure side is the same used in the first article to connect to the Hub broker, using a shared access signature and TLS with a certificate.
The TTN side simply connects using the created application name and key as credentials (similarly for what done with Azure, using the hub name and the generated signature) and starts listening for incoming messages on the default TTN topic for data arriving by the devices ("+/devices/+/up"). The '+' symbol is a wildcard: the first occurrence represents any application, and the second stands for any device.
When a message arrives, the on_message_ttn callback processes the payload, extracting the payload_raw field, which contains the real information we are interested in, encoded in base64 format. It then readapts the message format and publishes it to the Hub broker, which will receive it and save the information in the table storage as usual.
Important: the bridge has to be set with all the specific information of the accounts used to run the application. In particular, the following snippet of code
# event hub compatible name iotHubName = "[HUB_NAME].azure-devices.net" # id of broker device_id = "[DEVICE_ID]" # topic cloud->broker hubTopicSubscribe = "devices/"+device_id+"/messages/devicebound/#" # topic broker->cloud hubTopicPublish = "devices/"+device_id+"/messages/events/" # secret key for auth. broker to hub hubSharedAccessKey = "[HUB_KEY]" # name of the application on TTN ttn_app_name = "[TTN_APP_NAME]" # TTN application key ttn_app_key = "[TTN_APP_KEY]"
needs to be filled with:
- iotHubName: the name of the Azure Hub employed
- device_id: the name with which the broker has been registered within the Hub
- hubSharedAccessKey: the secret key to access the Hub, used to generate the signature
- ttn_app_name: the name given to the application created before on The Things Network
- ttn_app_key: the secret key given for the application at creation time
3. IoT-Lab deployment
Finally, in order to run the application can be deployed on the B-L072Z-LRWAN1 hardware kit provided by IoT-Lab.
Get the firmware by compiling in the RIOT_loramac folder with
$ sudo make all
It will compile for the default board specified in the Makefile (b-l072z-lrwan1). Once the operation terminates, a .elf file will be generated and placed in the bin folder. It can be uploaded on IoT-Lab during the creation of a new experiment (Access the testbed > New experiment > Nodes), on two different nodes with St-Lrwan1 (Sx1276) architecture. Once the experiment is set and running, two nodes carrying the RIOT code will be created on two different b-l072z-lrwan1 boards, ready to test the application.
Run the application
For each node generated for the experiment, a terminal can be open to directly interact with it from the webpage. For both nodes set up the deveui, appeui and appkey parameters through the set command.
> set deveui 00000000000000 > set appeui 00000000000000 > set appkey 0000000000000000000000000000
Then run the TTN-Azure bridge from the RIOT_loramac folder:
$ python ttn_azure_bridge.py
Finally, execute the start command from the two IoT-Lab terminals
and, as the nodes start communicating with TTN, you can see the transparent bridge receiving the relative messages and forwarding them to the Hub
As already done in the previous articles, by opening an Azure CLI by Azure web page, you can execute the command
$ az iot hub monitor-events --device-id <BROKER_ID> --hub-name <HUB_NAME>
to filter incoming messages from the bridge, and actually see the messages published by the two nodes arrive.
Sources
- Duty cycle, The Things Network: https://www.thethingsnetwork.org/docs/lorawan/duty-cycle.html
- semtech_loramac reference: https://riot-os.org/api/semtech__loramac_8h.html
- LoRa Alliance - About LoRaWAN: https://lora-alliance.org/about-lorawan
- Addressing & Activation, The Things Network: https://www.thethingsnetwork.org/docs/lorawan/addressing.html
- LoRaWAN communications using RIOT and The Things Network: https://www.iot-lab.info/tutorials/riot-ttn/