Skip to content

LoRaWAN

Introduction

The ioTracker is compatable with the LoRaWAN 1.0.3 specification. Therefor the ioTracker can be used on every LoRaWAN network which complies to the LoRaWAN standard.

Clases

Class A (lowest power)

This is the most used class for operating LoRaWAN sensors, because it's the most power efficient class. The ioTracker will send an uplink message on a preconfigured interval. The device can receive a downlink message right after the uplink is send. Therefor you need to queue a downlink in the network server.

In addition to class A, you can configure extra downlink slots. The ioTracker shortly awakes on a pre-configured interval to make it possible to receive a downlink message.

Class C (Lowest latency, not supported yet)

With class C the ioTracker is constantly able to send uplink and receive downlink messages. This ensures the lowest latency, but the LoRaWAN radio will be constantly active, so this mode will draw the most power.

Spreading Factor (SF) and Adaptive Data Rate (ADR)

The spreading factor tells you something about the performance of the LoRa connection. The spreading factor varies between SF 7 and SF 12. SF 7 is the lowest spreading factor, this gives you the fastest connection and therefor the energy consumption will be the lowest. When the LoRa reception is worse, you need a higher spreading factor to communicate with the LoRa gateway.

You can configure the ioTracker with a static minimum, maximum and moving Spreading Factor. This gives you control between coverage and power usage / responsiveness. By default Adaptive Data Rate is enabled, the ioTracker will negotiate with the LoRAWAN network to configure the best possible Spreading Factor. By default the ioTracker has all Spreading Factors and ADR enabled. When the ioTracker moves and the Spreading Factor is below SF 10, the Spreading Factor will be set on SF 10.

Duty cycle

Because LoRaWAN operates in non-licensed radio frequencies, the airtime (time which the radio sends and receives signals) is limited, so there will be room for all kinds of devices to use the same radio frequencies without disturbing eachother. Therefor a dutycyle is implemented in the LoRaWAN specification, which the ioTracker complies to.

In general you can say that a lower Spreading Factor and smaller data payload will give you the shortest duty cycle.

An uplink message defines a message from the ioTracker to the LoRaWAN network and contains the sensordata. Uplink messages can be send on a pre-configured interval, but can also be triggered by an event (reaching a certain temperature for instance). The uplink messages are "encoded" in a hex value with a maximum packet size of 55 bytes.

The uplink message needs to be decoded to readable data, we have an example javascript decoder available on GitHub which helps you with this process.

An downlink message defines a message from the LoRaWAN network to the ioTracker. The downlink needs to be queued by the LoRaWAN network and will be received and processed by the ioTracker right after an uplink message. With a downlink message you can make configuration changes to the ioTracker. For instance you can change the uplink interval of enable the GPS.

You need to send the downlink message to the correct FPort in order for the ioTracker to receive and process a downlink message. The ioTracker uses FPort 1 for downlink communications purposes.

Lossy network

LoRaWAN is a lossy network, this means that there is by default no confirmation if a message is received by the LoRaWAN gateway or the device. In some situations (emergency button for instance), it's important that you know that a message came through. Therefor you can send a confirmed uplink or downlink message. After the ioTracker sends a confirmed uplink an acknowledge downlink message will be send from the LoRaWAN network to the device. When the device didn't receive the acknowledge message, it keeps trying to deliver the same uplink message again till the acknowledge from the LoRaWAN network is received. By default the ioTracker is configurated with 8 retries, but you can also configure this to indefinitely.

Keys

The ioTracker supports activations via the OTAA (Over-the-Air Activation) and ABP (Activation By Personalisation) process. OTAA is the most used and secure method because during the join procedure unique encryption keys will be exchanged between the device and network.

By default the ioTracker is configured in OTAA mode and the LoRaWAN keys will be distributed during the order fulfillment process.

OTAA (Over The Air Activation)

  • DevEUI (Device Indentifier): 64-bit unique ID
  • AppEUI / JoinEUI (Application Indentifier): 64-bit application ID
  • AppKey (Applicaton Key): 128-bit AES key

ABP (Activation By Personalisation)

  • DevAddr (Device Address): 32-bit unique ID
  • NwkSKey (Network Session Key): 128-bit AES key
  • AppSKey (Application Session Key): 128-bit AES key