Controller - LoRa TTN - RN2483/RN2903

Controller for the LoRaWAN/TTN network supporting RN2483 (434/868 MHz) and RN2903 (915 MHz)

Controller details

Type: Controller

Name: LoRa TTN - RN2483/RN2903

Status: COLLECTION

GitHub: C018.cpp

Maintainer: TD-er

Change log

Added in version 2.0: …

added 2019/08/13 First occurrence in the source.

Description

The Things Network (TTN) is a global open LoRaWAN network. LoRaWAN allows low power communication over distances of several km.

A typical use case is a sensor “in the field” which only has to send a few sample values every few minutes. Such a sensor node does broadcast its message and hopefully one or more gateways may hear the message and route it over the connected network to a server.

The data packets for this kind of cummunication have to be very short (max. 50 bytes) and a sender is only allowed to send for a limited amount of time. On most frequencies used for the LoRa networks there is a limit of 1% of the time allowed to send.

Such a time limit does also apply for a gateway. This implies that most traffic will be “uplink” data from a node to a gateway. The analogy here is that the gateway is often mounted as high as possible while the node is at ground level (“in the field”)

There is “downlink” traffic possible, for example to notify some change of settings to a node, or simply to help the node to join the network.

In order to communicate with the gateways in the TTN network, you need a LoRa/LoRaWAN radio module.

The radio module does communicate via the LoRa protocol. On top of that you also need a layer for authentication, encryption and routing of data packets. This layer is called LoRaWAN.

There are several modules available:

  • RFM95 & SX127x. These are LoRa modules which needs to have the LoRaWAN stack implemented in software

  • Microchip RN2483/RN2903. These are the modules supported in this controller. They have the full LoRaWAN stack present in the module.

Nodes, Gateways, Application

A typical flow of data on The Things Network (TTN) is to have multiple nodes collecting data for a specific use case.

Such a use case is called an “Application” on The Things Network. For example, a farmer likes to keep track of the feeding machines for his cattle.

So let us call this application “farmer-john-cattle”.

For this application, a number of nodes is needed to keep track of the feeding machines in the field. These nodes are called “Devices” in TTH terms. For example a device is needed to measure the amount of water in the water tank and one for the food supply.

Such a device must be defined on the TTN console page.

There are two means of authenticating a device to the network (this is called “Join” in TTN terms): - OTAA - Over-The-Air Authentication - ABP - activation by personalization

With OTAA, a device broadcasts a join request and one of the gateways in the neighborhood that received this request, will return a reply with the appropriate application- and network- session keys to handle further communication.

This means the device can only continue if there is a gateway in range at the moment of joining. It may happen that a gateway does receive the join request, but the device is unable to receive the reply. When that’s happening, the device will not be able to send data to the network since it cannot complete the join. Another disadvantage of OTAA authenticating is the extra time needed to wait for the reply. Especially on battery powered devices the extra energy needed may shorten the battery life significantly.

With OTAA, the device is given 3 keys to perform the join:

  • Device EUI - An unique 64 bit key on the network.

  • Application EUI - An unique 64 bit key generated for the application.

  • App Key - A 128 bit key needed to exchange keys with the application.

The result of such an OTAA join is again a set of 3 keys:

  • Device Address - An almost unique 32 bit address of your device.

  • Network Session Key - 128 bit key to access the network.

  • Application Session Key - 128 bit key to encrypt the data for your application.

The other method of authenticating a device is via ABP. ABP is nothing other than storing the last 3 keys directly on the device itself and thus skipping the OTAA join request. This means you don’t need to receive data on the device and can start sending immediately, and even more important, let your device sleep immediately after sending.

A disadvantage is the deployment of the device. Every device does need to have an unique set of ABP keys generated and stored on the device.

Updating session keys may also be a bit hard to do, since it does need to ask for an update and must also be able to receive that update.

Hybrid OTAA/ABP

TODO TD-er.

Configure LoRaWAN node for TTN

A LoRaWAN device must join the network in order to be able to route the packets to the right user account.

Prerequisites:

  • An user account on the TTN network.

  • A TTN gateway in range to send data to (and receive data from)

  • Microchip RN2483 or RN2903 LoRaWAN module connected to a node running ESPeasy. (UART connection)

On the TTN network: - Create an application - Add a device to the application, either using OTAA or ABP.

In order to create a new device using OTAA, one must either copy the hardware Device EUI key from the device to the TTN console page, or generate one and enter it into the controller setup page in ESPeasy. The Application EUI and App Key must be copied from the TTN console page to the ESPeasy controller configuration page.

Using these steps, a device address is generated. Such an address looks like this: “26 01 20 47” Also the Network Session Key and Application Session Key can be retrieved from this page and can even be used as if the device is using ABP to join the network. But keep in mind, these 3 keys will be changed as soon as an OTAA join is performed.

Device configuration with solely an ABP setup are more persistent.

Decoding Data

Controller Settings

Since there are legal limitations on the amount of time you are allowed to send, it is even more important to understand what effect the Controller Queue parameters may have on the reliability of data transmission.

You are allowed to send only 1% of the time. Meaning if your message takes 100 msec to send, you can only send a message every 10 seconds.

As a rule of thumb, the time needed to send a message of N bytes doubles for every step up in the Spreading Factor.

For example, a message sent at SF7 may take 100 msec to send. The same message sent at SF8, will take 200 msec. At SF9 takes 400 msec, etc. The slowest is SF12.

The RN2483 module does keep track of the used air time, per channel. Meaning it is possible to send a burst of upto 8 messages (since we have 8 channels) after which we have to wait for a free channel to send out a new one.

As with any other ESPEasy controller, there is a queue mechanism to manage the messages ready to be sent and also allow for a number of retries.

This number of retries is even more important on this LoRaWAN TTN controller. If sending a message fails due to no free channels, the minimum send interval will be dynamically increased, based on the air time of the message to be sent. The dynamic adjustment is 10x the expected air time. So by setting the number of retries to 10, it is almost guaranteed the message will eventually be sent. 10 retries with 10x the expected air time equals a maximum of 100x the expected air time, which eventually will be as low as 1% of the time sending.

N.B. This expected air time is dependant on the set Spread Factor and the length of the message.

In practice the messages will be sent in bursts, and thus the extra wait time is often 2 - 3x the expected air time of the message. So on setups with a large variation in message sizes, it makes sense to send the large ones at the start of a message burst.

Setting the number of retries high (e.g. 10x), may be useful to make sure a sequence of messages in a burst will all get sent. But it may also lead to a large number of messages to be lost as the queue is full. So it depends on the use case what will be the best strategy here.

At least the Minimum Send Interval can be kept low (e.g. the default 100 msec) to allow for quickly sending out a burst of upto 8 messages.