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;
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.
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.
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
Join Process
The Join Process follows the LoRa Join Cycle after the first join request, initially the device will perform a join request on the lowest SF for Class A devices and the highest SF for Class C devices.
Automatic connection on power-up
When the device is turned on, the device will perform a join request to the network as part of the start-up cycle.
If the connection is successful, the device will send the basic information uplink.
If the connection is unsuccessful, the device will resend join requests following the Join duty cycle from the LoRaWAN Standard.
A Class A device will suspend the join cycle 120 minutes after it started.
Rejoins
If the device detects that it has not received a response after 5 uplink transmissions it will send 3 LinkCheckReq packets on different datarates (SF7, SF9, SF12) to the network server to validate connectivity.
In the event that no confirmed uplinks are being used by the device, every 96 hours the device will send 3 LinkCheckReq packets on different datarates (SF7, SF9, SF12) to the network server to validate connectivity.
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.
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.
The network quality test can be requested by downlink command if customer should want to perform the network quality test.
Good
link margin >= 1 6
Medium
link margin > 6 and < 16
Bad
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.
Carrier Sense Multiple Access (CSMA) for LoRaWAN
The stack supports the CSMA (Carrier Sense Multiple Access) feature designed to prevent collisions in LoRa packet transmissions. This is based on LoRa Alliance Technical Recommendations TR0013.
CSMA is enabled by default on all devices, it can be disabled.
LoRaWAN Lifecycle Monitoring
It’s desirable to monitor the LoRaWAN lifecycle on end-devices in order to get an understanding of possible issues when end-devices are deployed ‘in the field’.
The iQ stack monitors different information provided by the modem and network and logs them on the device.
The following information will be retrieved.
Duty cycle limitation status
Maximum size of the next uplink
Available datarates
Number of consecutive uplinks without downlink
The lifecycle monitoring will not perform any LoRaWAN mac procedures, the retrieved data is taken from the normal LoRaWAN operations of the device.
Please propose how to save this information and a desired uplink dataformat.
Confirmed Uplinks
If an uplink is sent as a confirmed message, the device expects an acknowledgment (ACK) from the LoRaWAN network. When no ACK is received, the iQ Stack will try to retransmit the message again, up to the configured number of tries (NbRetrans). If still no ACK is received, the uplink is discarded.
ADR ACK Request
To be implemented? Is there a practical reason?
Communication Watchdog
The Communication Watchdog functionality forces the device to reset, so it can rejoin the network.
The communication watchdog can be invoked from several functions within the iQ Stack.
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
