In order to send data from an Arduino, ESP32, TTGO or other development boards via a LoRa module to TTN using LoRaWAN, a corresponding configuration must be created at TTN. This article is about setting up a device or sensor at TTN (The Things Network) in APB mode. Since self-built sensors do not have their own keys pre-installed, all necessary keys are generated by TTN or by user.The configured devices are then compatible with all active gateways that communicate with TTN.

APB Mode

APB stands for "Activation by Personalization". All session keys and the configuration are stored statically in the device. Both OTAA and ABP support bidirectional connections. It is therefore possible for data to be sent to the device via TTN in specific time frames. A major advantage of ABP is its compatibility with any gateway, especially single-channel gateways. In addition, simplex operation is enough to send sensor data to TTN. With OTAA, there is a "join request" where the end device must communicate bidirectionally with the gateway or TTN so that the session keys can be exchanged. The frame counter is also always reset on every new join request. In this case, the gateway must be able to reach the end device. With single-channel and dual-channel gateways, this only works if this is supported by the gateway and, above all, only if the correct frequencies are configured. Therefore, the highest compatibility is only achieved with ABP. There are disadvantages in contrast to OTAA in terms of security, automatic frequency and SF-optimization (ADR), and energy efficiency.

TTN Registration

In order for a device to communicate with TTN, an account is required. Then a new application must be created where the individual devices can be registered. An own gateway is basically not needed, because communication is possible via all active gateways. An own gateway is generally very recommended, because beginners get a lot of additional information, which can be helpful for troubleshooting. For ABP, an inexpensive single-channel or dual-channel gateway such as the Dragino LG-02 is enough.

1. Register Application

In the first step, a new application must be created in TTN. The application is primary necessary for the data preparation and data transfer. The individual devices are located in the respective application. Note: An application has at least one device! However, several devices can also be assigned to an application. Furthermore, it does not matter whether the devices are from one or different manufacturers and whether OTAA or ABP or a mix of both procedures is used. The following parameters are required for registering a new application:

Appliaction ID: The Application ID is the unique identification of the application. It can be freely selected and consists a maximum of 36 characters and only lowercase letters and numbers. Special characters are not allowed!

Description: This is a description of the application. This information is optional.

Application EUI: The Application EUI will be created automatically after a new registration. It can be replaced later by another Application EUI. In addition, multiple App-EUIs can be assigned to one application.

Handler registration:The handler takes care of the forwarding messages. If no own handler is used, the handler "ttn-handler-eu" is usually selected in Europe.

2. Register Device

After the application has been created, the individual devices or sensors can be registered in this application. A click on "register device" opens a new page where the following parameters are required:

Device ID: The Device ID can again be freely selected, but cannot be changed later. The length is limited to 36 characters and only lowercase letters and numbers may be assigned. Special characters are not allowed.

Device EUI: The Device EUI is a unique identifier for the respective device in the network. The Device EUI consists of exactly 8 bytes in hexadecimal format (0-16, A-F). For ready-to-use sensors, this identifier is usually already assigned by the manufacturer. With own boards like the Arduino, ESP32 etc. this identifier must be generated itself.

APP Key: The APP-Key is used to encrypt all data. Depending on the hardware, this may also already be specified. If not or for development boards, leave this field empty. The key will be generated automatically by TTN.

APP EUI: The Application EUI has already been created in step 1. If there are several identifiers, they can be selected in the drop-down menu. It is recommended to use the default.

3. Change to ABP

By default, TTN sets the device to OTAA. Under "Settings" of the respective device the Activation Method must be changed from OTAA to ABP. If the two fields "Network Session Key" and "App Session Key" remain empty, TTN automatically creates both keys during the creation process. Additionally the "Frame Counter Check" can be disabled. More about this at point 5.

4. Copy Keys from TTN

As soon as the ABP mode has been activated, all necessary keys can be copied from TTN and included in the library or in the source code. The following keys are necessary for the connection to TTN in ABP mode:

Network Session Key (NWKSKEY): The Network Session Key is required for communication between sensor and network. In addition, this key is used to check the validity of the message by means of MIC Check (Message Integrity Code Check).

App Session Key (APPSKEY): The app session key is necessary for the encryption and decryption of the payload between the handler and the end device. Together with the NWKSKEY, the whole encryption is formed.

Device Address (DEVADDR): The Device Address is generated automatically by TTN. It is the only address at TTN that cannot be changed or generated by user. The address can be assigned several times worldwide.

5. Frame Counter

The frame counter is a two-sided counter that is incremented by the value one with each message. In the end device, the frame counter is incremented by one before sending. When receiving, TTN expects this frame counter to be one higher than in the last received message. If this is the case, the message is accepted, otherwise rejected. Even if TTN sends to the end device, exactly the same happens in the device. However, if the battery fails in the end device or there is a reset, the counter is also zero. If messages are now sent to TTN, they will be rejected. To avoid this, the frame counter can be deactivated permanently or reset one time. The better solution would be an EEPROM or Flash memory that stores the current frame counter and makes it available to the software again after startup. In general, the frame counter is a component of the security concept, which prevents, for example, that "overheard" data packets can be sent again.