LoRaWAN Communication

This page describes how the LoRaWAN stack operates.

General

The LoRaWAN Interface is in compliance with the LoRa Alliance specifications, and is based on the LoRa transmission standards.

Using the LoRa protocol the device can reliably transmit data over large distances without permanent communication.

The interface constantly adapts to the optimal transmit and receive parameters individually to ensure a stable and reliable link to the LoRaWAN Gateway.

The status of the link to the LoRaWAN network is shown on the device’s display.

  • The LoRaWAN interface is compatible with LoRaWAN V1.0.4.

  • Battery Powered Devices are configured as Class A devices while mains powered devices are configured as Class C device.

  • The required parameters and configuration of the LoRaWAN interface are permanently saved inside the device.

All devices are delivered with OTAA mode enabled, the DevEUI of the device is listed on the package and on the device itself.

Infrastructure

IoT System Components

The Customer is responsible for a working LoRaWAN Infrastructure, a typical LoRaWAN infrastructure consists out of;

  1. Node / Device : a device that is equipped with a wireless communication module which forms the payload to send to a gateway or receive data from a gateway.

  2. Gateway : a device that can be seen as a router, equipped with a LoRa concentrator, that receives the LoRa packets and send them on their way to a network server / platform.

  3. Server Platform : a platform that is usually cloud based where all communication is being prepared and processed. The processing can either be done on the platform where it's being stored, analysed and presented or it can be forwarded to an IoT Platform that handles these actions.

If needed YOBIIQ can support customer with the selection and configuration of the infrastructure, this however is not covered by the normal support coverage.

YOBIIQ also supplies a turn-key LoRaWAN Infrastructure if customer has no experience with the required infrastructure.

Operational Procedure

JOIN Process

Start-up of the product, JOIN process and configuration

The product start the JOIN process within the product start-up process.

As long as the device is not connected to a LoRaWAN network, the interface regularly tries to connect to a LoRaWAN network.

These Join requests occur randomly in a ~10 min time period to counteract bandwidth problems if multiple devices are in the same network

Rejoins

Internal:

As of this version the automatic rejoin mechanism is changed, previously the device would rejoin every 24 hours but this can lead to unexpected battery consumption and data collisions. This new mode also makes it possible to include data retransmission.

If the device detects that it has not received confirmation after 5 consecutive uplink transmissions it will send 3 LinkCheckReq packets to the network server to validate connectivity. In the event that no confirmed uplinks are being used by the device, every 24 hours the device will send 3 LinkCheckReq packets to the network server to validate connectivity.

If there is no response to the LinkCheckReq packets the device will initiate a rejoin to the network.

The LoRa Communication Watchdog alarm will trigger when the LinkCheckReq packets are not responded to.

Network Quality Test

During the JOIN Process, the device will perform a network quality test. When the test is running the device shows this by utilizing the LED on the device.

A device configured in Class C will perform the network test during a Rejoin Request as well.

The result of the test is given by the devices after around 20 seconds following the Join Accept. It is visible by utilizing the LED on the device.

With this information the installer knows the quality of the network and can move the device to a place with a better coverage.

Result
SF

Good

SF7 or SF8

Medium

Other SF factor with a link margin > 6

Bad

Other SF factor with a link margin <=6

Time synchronization

The device performs a time synchronization during normal operation, it performs this at least once every 24 hours.

The device will adjust its internal clock to match with the time returned by the time synchronization.

Sending measurement registers

The device sends all requested measurements directly from its datalogger via LoRaWAN without any changes to the data.

The requested measurements are read from the data logger at the due date of the interval.

Example of a transmission interval of 15 minutes:

  • 10:00:10am: The LoRaWAN communication module reads out the latest data logger entry. The values stored there are from 10:00:00am.

  • 10:00:11am ­ 10:14:59am: The device tries to transmit the data via the LoRaWAN network.

Notes on the transmission of measurements;

  • Be aware that, if you operate multiple devices in the same LoRaWAN network, transmissions by these meters may collide. The device will however adjust its transmit parameters to ensure smooth transmissions.

  • Please make sure that both the device and the LoRaWAN network are configured in such a way that the device can transmit its full package to avoid losing data in failed transmissions.

Data Retransmission

Internal:

Data Retransmission will only be available on devices that have additional SPI Flash.

The device supports the retransmission of data to ensure that all available data is submitted to the network server and overcome downtimes of the LoRaWAN network.

If enabled the data retransmission is triggered by failure of the LinkCheckReq, once triggered the device will record the timestamp of the failure and store the uplinks in a buffer. If the LinkCheckReq packets are getting a response the device will re-transmit all the data that has been logged into the buffer since the failure.

The amount of data you can save into the buffer depends on the type of device, the buffer operates on a FiFo method meaning that once the buffer reaches it's maximum size it will replace the oldest entry in the buffer.

Last updated