LoRaWAN back-ends
LoRaWAN network architecture is typically laid out in a star-of-stars topology in which a gateway is a transparent bridge relaying messages between end-devices and a central network server in the back-end.
Waspmote recommended configuration
Before using a LoRaWAN module with the back-ends explained below or any other back-end, it is strongly recommended to know the configuration that the LoRaWAN gateway is using so we can configure Waspmote the same way.
We will need to pay attention to some of these parameters:
Number of channels supported
Receiving windows configurations
Gateway's firmware version
Depending on the LoRaWAN module version we work with, it will be necessary to configure different parameters.
Make sure that the gateway's firmware is always up to date. If there is no certain about it, contact the gateway provider or the back-end provider.
LoRaWAN EU
As we can see in the section “Channel parameters”, the LoRaWAN EU module supports up to 16 channels to transmit information. According to the LoRa Alliance: LoRaWAN Specification document, it has 3 channels configured by default with fixed frequencies.
Depending on the gateway manufacturer, the number of supported channels may vary. To get the best performance it is recommended to configure the module to use as many channels as the gateway may support.
There is a set of functions to configure these channels parameters, and to turn on channels so the module can use them. Before turning on channels we must configure them, otherwise the module will not allow the user to activate them.
So set frequencies for every channel according to the gateway's configuration. Set the data rate (max range depends on that) as desired. Keep in mind that the duty cycle must be set and modified for the existence of other channels so it complies with the applicable regulations in the country as shown in the “Channel Duty Cycle” section.
Once the configuration has been correctly done, channels can be activated.
Window reception parameters may also vary from a gateway to another. They should be configured according to the parameters given by the back-end provider.
You can see an example of configuration in this code:
LoRaWAN US
As we can see in the section “Channel parameters”, LoRaWAN US module supports up to 64 channels to transmit uplink messages. By default, the whole set of channels is activated when the module starts working.
Depending on the gateway manufacturer, the number of supported channels may vary. To get the best performance it is recommended to configure the module to use as many channels as gateway may support.It is strongly recommended to deactivate channels that are not supported by the gateway so the module does not try to send information on these channels.
Before setting on any channel, it is necessary to configure the data rate (max range depends on that) as desired.
Window reception parameters may also vary from a gateway to another. They should be configured according to the parameters given by the back-end provider.
You can see an example of configuration in this code:
LoRaWAN AU
As we can see in the section “Channel parameters”, LoRaWAN AU module supports up to 64 channels to transmit uplink messages. By default, the whole set of channels is activated when the module starts working.
Depending on the gateway manufacturer, the number of supported channels may vary. To get the best performance it is recommended to configure the module to use as many channels as gateway may support.It is strongly recommended to deactivate channels that are not supported by the gateway so the module does not try to send information on these channels.
Before setting on any channel, it is necessary to configure the data rate (max range depends on that) as desired.
Window reception parameters may also vary from a gateway to another. They should be configured according to the parameters given by the back-end provider.
You can see an example of configuration in this code:
LoRaWAN IN
As we can see in the section “Channel parameters”, the LoRaWAN IN module supports up to 16 channels to transmit information. According to the LoRa Alliance: LoRaWAN Specification document, it has 3 channels configured by default with fixed frequencies.
Depending on the gateway manufacturer, the number of supported channels may vary. To get the best performance it is recommended to configure the module to use as many channels as the gateway may support.
There is a set of functions to configure these channels parameters, and to turn on channels so the module can use them. Before turning on channels we must configure them, otherwise the module will not allow the user to activate them.
So set frequencies for every channel according to the gateway's configuration. Set the data rate (max range depends on that) as desired. Keep in mind that the duty cycle must be set and modified for the existence of other channels so it complies with the applicable regulations in the country as shown in the “Channel Duty Cycle” section.
Once the configuration has been correctly done, channels can be activated.
Window reception parameters may also vary from a gateway to another. They should be configured according to the parameters given by the back-end provider.
You can see an example of configuration in this code:
LoRaWAN ASIA-PAC / LATAM
As we can see in the section “Channel parameters”, the LoRaWAN ASIA-PAC / LATAM module supports up to 16 channels to transmit information. According to the LoRa Alliance: LoRaWAN Specification document, it has 2 channels configured by default with fixed frequencies.
Depending on the gateway manufacturer, the number of supported channels may vary. To get the best performance it is recommended to configure the module to use as many channels as the gateway may support.
There is a set of functions to configure these channels parameters, and to turn on channels so the module can use them. Before turning on channels we must configure them, otherwise the module will not allow the user to activate them.
So set frequencies for every channel according to the gateway's configuration. Set the data rate (max range depends on that) as desired. Keep in mind that the duty cycle must be set and modified for the existence of other channels so it complies with the applicable regulations in the country as shown in the “Channel Duty Cycle” section.
Once the configuration has been correctly done, channels can be activated.
Window reception parameters may also vary from a gateway to another. They should be configured according to the parameters given by the back-end provider.
You can see an example of configuration in this code:
LoRaWAN Global
Since the LoRaWAN Global module support several LoRaWAN regions, it must be taken in account they all have different channel configurations defined by the LoRa Alliance.
Depending on the gateway manufacturer, the number of supported channels may vary. To get the best performance it is recommended to configure the module to use as many channels as the gateway may support.
There is a set of functions to configure these channels parameters, and to turn on channels so the module can use them. Before turning on channels we must configure them, otherwise the module will not allow the user to activate them.
So set frequencies for every channel according to the gateway's configuration. Set the data rate (max range depends on that) as desired. Keep in mind that the duty cycle must be set and modified for the existence of other channels so it complies with the applicable regulations in the country as shown in the “Channel Duty Cycle” section.
Once the configuration has been correctly done, channels will be automatically activated by the module.
Window reception parameters may also vary from one gateway to another. They should be configured according to the parameters given by the back-end provider.
You can see an example of configuration in this code:
Actility
JARL The ThingPark Wireless Device Manager is the back-end User Interface (UI) which allows you to manage all of your LoRaWAN devices.
This Guide will provide the guidelines on the entire GUI, the device provisioning, device configuration and management, alarm and routing profile management and connectivity plan association.
The Device Manager can be fully integrated into a third party customer UI, through all the ThingPark Wireless OSS REST API.
Device registration
The device provisioning is the process that allows users to create devices and register them on the network. There are two ways to register a new device: Activation By Personalization (ABP) and Over The Air Activation (OTAA).
Activation By Personalization:
Information required to create a new device:
Device Address (DevAddr)
Network Session Key (NwkSKey)
Application Session Key (AppSKey)
These parameters match with the ones which must be configured in the ThingPark Actility Portal (back-end).
Over The Air Activation:
Information required to create a new device:
Device EUI (DevEUI)
Application EUI (AppEUI)
Application key (AppKey)
These parameters match with the ones used by the server and defined by user. They will be used to negotiate necessary keys for the module to send data.
Waspmote programming
Actility Portal lets the user configure all parameters needed to connect into a network. NwkSKey and AppSKey are 128-bit keys specific for the end-device, used to calculate and verify an application-level MIC (message integrity code) and also used by both network server and end-device to encrypt and decrypt the payload field of application-specific data messages.
Both NwkSKey and AppSKey will be configured by the user in the Actility Portal and set into the end-device.These keys are not shown in the ThingPark Wireless Device Manager once they have been configured so it is strongly recommended to set them into the end-device before configuring the end-device creation in the Actility Portal.
About DevEUI and DevAddr, there are two ways to configure it into the module with Waspmote.
On one hand they may be set by user manually. When using this method always keep in mind they must be unique for every module.
On the other and they can be configured automatically by Waspmote. This method uses the preprogrammed by manufacturer module's identifier, that matches DevEUI length, ensuring it will be unique. DevAddr will be extracted from this manufacturer module's identifier taking its last 32 bit. E.g., Microchip Module: EUI: 0004A30B001A836D, DevEUI: 0004A30B001A836D, DevAddr: 001A836D.
Examples of setting configuration necessary to connect into a network and send packets:
https://development.libelium.com/waspmote/lorawan-06-join-abp-send-unconfirmed
LORIOT
LORIOT.io is a provider of a LoRaWAN Network Server and Application Server software, which is commercially offered through a set of business models.
They provide:
Software for the supported LoRa gateways
Cloud-based LoRaWAN Network Server
Programming interface (APIs) for Internet of Things applications to access the end node data
Output of end node data to number of 3rd party services
As a gateway owner, users can use LORIOT.io software on gateways to connect them to their cloud. From then on, all data received by the gateways will be relayed to the user through the LORIOT.io APIs or 3rd party services.
The network server components fulfills to role of protocol processor. It is a TLS connection end-point for the gateways and the customer applications. It is responsible for processing the incoming end node data according to the LoRaWAN protocol.
The specific roles of LORIOT.io Network Server are:
Gateway population management
Application population management
Device population management
Collection of billing records
Security management
Data distribution
Device registration
Some parameters must be set into the module so it can join to a network.
Device EUI (DevEUI)
Application EUI (AppEUI)
Application ket (AppKey)
When a new device is generated in the LORIOT.io portal these parameters can be automatically generated by Loriot or can be set by the user. The user will have to configure the module according to these parameters.
Once the device is created you can access to its configuration and data clicking over the Device EUI field with the mouse. Data messages can be seen there.
Data downlink
Data sent to the back-end can be found inside every device page. Data could also be found in the “WebSocket Applications” section.
To perform data downlinks click on the “Send data” button and the “Send to device” section will be displayed.In this section, Device EUI, port number and data payload to send must be filled. Finally, the “Send to device”button will enqueue the data to be downloaded. Data will be received by the module after the next data uplink. It does not matter if the next uplink process is confirmed or unconfirmed, the downlink will be performed.
This feature might not be available for free accounts
Waspmote programming
The LORIOT.io portal provides by default the whole configuration required by the module to connect to a network.
The mandatory field to field are the ones which where mentioned in the previous section. They can be copiedas is to the code so module is configured the same way it was created in the portal.
Inside the device description in the LORIOT.io portal they warn to copy EUI and Address in little endian format, but it won't be necessary for the Waspmote code, it can be copied big endian format.
Examples of setting configuration necessary to connect into a network and send packets:
https://development.libelium.com/waspmote/lorawan-06-join-abp-send-unconfirmed
The Things Stack
The Things Stack is an open source LoRaWAN Network Server suitable for global, geo-distributed public and private deployments as well as for small, local networks. The architecture follows the LoRaWAN Network Reference Model for standards compliancy and interoperability. This project is actively maintained by The Things Industries.
Through robust end-to-end encryption, a secure and collaborative Internet of Things network is built that spans across many countries around the globe. Now operating thousands of gateways providing coverage tomillions of people. Thanks to a large developer community, The Things Stack is continuously being improved.
In the The Things Stack website you can find the documentation to configure end-devices and gateways to connect to their cloud, including also how to manage the network and 3rd party applications to receive datafrom the end-devices.
Check this web site to find the documentation: https://www.thethingsindustries.com/docs/
Last updated
