LoRaWAN
For using a LoRaWAN device connector either a connectivity account needs to be linked (see Connectivity Management) or an akenza provided connector can be used. In both cases, the necessary configurations are already done on the connectivity provider's platform and do not require any further setup in order to use it.
When a LoRaWAN Connector receives an uplink message, it extracts the hex payload from the request, alongside some uplink metric information which is then passed on to the Device Type for further processing. If the creation of a Custom Device Type is enabled in the subscription, the scripting guidelines can be followed to access the hex payload and meta information in the scripts (see Scripting).
Device Connectors that have LoRaWAN Connectivity cannot be created, edited, or deleted. They are bound to their respective integrations and will be removed if the integration is deleted.
Activation
Over-the-Air Activation (OTAA) is the preferred and most secure way to activate LoRaWAN devices. With OTAA the device performs a join-procedure with the network, during which a dynamic DevAddr is assigned and security keys are negotiated.
In some cases the DevAddr as well as the security keys need to be hardcoded in the device, which requires activation by personalization (ABP). ABP end-devices are not provisioned with the root keys, instead, they are provisioned with a set of session keys. The session keys remain the same throughout the lifetime of an ABP end device.
Find out more about TTN Addressing & Activation.
Security Keys
LoRaWAN 1.0 specifies a number of security keys: NwkSKey, AppSKey and AppKey. All keys have a length of 128 bits (16 bytes).
The Network Session Key (NwkSKey) is used for interaction between the Node and the Network Server. This key is used to validate the integrity of each message by its Message Integrity Code (MIC check). This MIC is similar to a checksum, except that it prevents intentional tampering with a message. For this, LoRaWAN uses AES-CMAC.
The Application Session Key (AppSKey) is used for encryption and decryption of the payload. The payload is fully encrypted between the Node and the Application Server component.
Dynamically activated devices (OTAA) use the Application Key (AppKey) to derive the two session keys during the activation procedure.
Devices using ABP require both the Network Session Key (NwkSKey) and the Application Session Key (AppSKey) to be provided.
Find out more about TTN LoRaWAN Security.
Supported versions per carrier
| LoRa 1.0.x | LoRa 1.1.x | |
|---|---|---|
Swisscom / Generic Actility | ||
TTN | ||
Loriot | ||
Everynet |
Classes
The LoRaWAN specification defines three device types. All LoRaWAN devices must implement Class A, whereas Class B and Class C are extensions to the specification of Class A devices.
Class A devices support bi-directional communication between a device and a gateway. Uplink messages (from the device to the server) can be sent at any time (randomly). The device then opens two receive windows at specified times (1s and 2s) after an uplink transmission. If the server does not respond in either of these receive windows, the next opportunity will be after the next uplink transmission from the device. The server can respond either in the first receive window, or in the second receive window, but should not use both windows.
Class B devices extend Class A by adding scheduled receive windows for downlink messages from the server. Using time-synchronized beacons transmitted by the gateway, the devices periodically open receive windows.
Class C devices extend Class A by keeping the receive windows open unless they are transmitting. This allows for low-latency communication but is many times more energy-consuming than Class A devices.
Find out more about TTN LoRaWAN Classes.
Last updated