Introduction
LoRaWAN devices are designed to last over a decade. While connection losses are rare, it’s crucial to understand why they happen and how to resolve them. One aspect of LoRaWAN® end device firmware development frequently forgotten is the ability to detect and repair connection loss. End devices may become stuck in the stranded state, where they don’t receive any downlink messages from the network, for several reasons, including;
- The device roves to another network provider’s territory (Unless there is a roaming agreement in place between two providers)
- There is a discrepancy between the device and the LoRaWAN network server in the reception settings for RX1 and RX2.
- The device seamlessly switched between two gateways that used non-overlapping channel maps.
These events are rare but essential since some LoRaWAN devices are meant to last for many years.
Two Major Types of LoRaWAN Network Connectivity Issues
LoRaWAN end devices face two sorts of network connection problems:
1). Temporary loss of network connectivity
A break in the network connection may occur in the following scenarios;
- A mobile device’s present location is outside the network’s service area.
- The location of a permanently installed device is experiencing a brief interruption in network service. (For instance, Device backhaul communication can be lost because the LoRaWAN Gateway cannot communicate with the device).
Detecting lost network connectivity
The device offers two techniques to detect temporary network link loss:
- If the Alternative Dispute Resolution (ADR) system is active: After ADR-ACK-LIMIT uplinks without downlinks, it changes the ADRACKReq bit of its uplink frames to 1, to notify the network that it expects a downlink frame within the subsequent ADR-ACK-DELAY frames.
- In any case: The client device may issue a MAC command known as LinkCheckRequest, which will then need a response from the network in the form of a LinkCheckAns MAC command.
The device should attempt transmitting uplink messages first if it senses (in any way) that the network is down. For instance, LinkCheckReq messages) using the lowest likely data rate that will maximize the connection budget. If the connection issue persists, the device should exponentially reduce uplink messages. In reality, the end devices are more likely to send out JoinRequest messages than standard UL ones.
2). Lost session context
The network server loses the Lora cellular gateway’s AppSkey and NwkSkey session context.
This is possible if;
- After deleting the device from the network server, the owner provisioned it again.
Or
- The network server experienced a non-recoverable database failure, or a replacement server took over the previous one’s duties, without ensuring session continuation.
If the network server in a LoRaWAN 1.0 network loses the session context, the only option to rejoin a device is to force it to issue a fresh join request. In the event of a persistent connection issue (which can’t be remedied by reducing the data rate), the device sends fresh Join Request messages, prompting the Network Server to initiate a new session context and reset the frame counter.
LoRaWAN 1.1 networks provide a considerably more effective solution for handling the “lost session” issue. LoRaWAN 1.1 features Rejoin-Request. When an end device sends a Rejoin-Request Type 1 message, the Network Server can initiate a new device session by replying with a Join Accept message. Nevertheless, The Network Server silently drops these messages if it has a valid session. This solution avoids connectivity issues from resetting valid device sessions and boosts security.
Reasons Why LoRaWAN device isn’t connecting while other devices are
Open network architecture is the foundation of the LoRaWAN devices and device network. LoRaWAN is an open network architecture that supports various devices and networks. In contrast to WiFi and other wireless mesh technologies, devices in this setup do not establish connections with the gateways. Here are more reasons why LoRaWAN device may fail to connect;
1. Dissimilar Gateways for data transmission
There is no guarantee that your device will always use the same gateway to send data to your LoRa server. It’s possible that the amount of wireless data traffic will exceed the capacity of most inexpensive 8-channel gateways. To lessen the likelihood of communication breakdowns, it’s recommended to set up a network with many overlapping gateways.
Learn more about LoRa WAN gateways.
2. Excessive Traffic
If a gateway receives excessive traffic, it will refuse all incoming connection attempts from new devices. This is because the gateway is required to comply with stringent government restrictions regarding transmission bandwidth and broadcasting frequency cycles.
3. Gateways are only Data forwarders
Gateways don’t do any processing themselves; instead, they only transmit data to LoRa servers that they have verified as secure.
4. LoRaWAN only accepts broadcasting from the appropriate frequency
Your gateway can accept transmissions from any device so long as it broadcasts on the right LoRaWAN frequency.
5. No security credentials
Your gateway will ignore any communication that doesn’t include the appropriate security credentials. Your gateway will not process any incoming communication without the correct authentication information.
6. Private LoRaWAN networks require Server credentials
The above also applies to LoRa private network. Private network gateways are only equipped with security credentials from a private LoRa server. Gateways may still receive data from third-party devices operating on the same LoRaWAN frequency. However, they will trash it rather than transfer it to the internal LoRa system for further processing.
7. Third-party devices aren’t matching third-party applications
The gateway will transmit data from third-party LoRaWAN devices, which can also connect with third-party apps on TTN, Loriot, Loraserver.io, and other open IoT providers. You will find these devices on the TTN, Loriot, and Loraserver.io networks.
Ways of detecting LoraWAN connection loss
The LoRaWAN specification provides a few techniques to detect connection loss; nevertheless, it doesn’t specify when a device should consider itself stranded or what to do. The application layer is responsible for making these sorts of choices. There are several ways to identify connection loss:
Link check Request/Response
When you issue this MAC command, you will get a link check response. In addition to the number of gateways that picked up the upstream request, the response will also provide a margin of reception (in dB).
However, sending a link-check request command adds a byte to the upstream frame, making this option inexpedient. Furthermore, the connection status is only identified for frames containing the link check request, which is the case if, for example, this link check frame is transmitted every 10 messages. In contrast, the ADRACKReq bit would be included in all upstream messages (after a delay) without any change to the payload.
Each upstream frame from an end device may contain a request to check for a working connection, but at that point, it would be more efficient to switch to confirmed upstream broadcasts and avoid the extra payload weight altogether.
Unverified Transmission
Unverified upstream transmissions usually go unanswered. This transmission method saves the most incredible downstream capacity and reduces upstream packet loss while employing a half-duplex gateway that cannot accept messages while broadcasting downstream. Devices that rely on unconfirmed messages may sometimes get a downstream MAC message. This lets the device know it is still connected to the network even if the downstream message didn’t explicitly grant any upstream communication.
However, the LoRaWAN 1.0.2 standard (section 4.3.1.1) gives an innovative approach to assess connection loss after several upstream broadcasts without downstream directives. By default, the frame header’s ADRACKReq bit is set after 64 transmissions. As a result, it triggers a downstream acknowledgment from the network server; however, it may not happen quickly.
The network server may ignore the initial request if the gateway(s) that received a frame from the end device does not have downstream capacity. Also, it helps stops the destination device from anticipating an acknowledgment, so it doesn’t lower its data rate or retransmit. In its place, the end device keeps activating the ADRACKReq set in all upstream broadcasts for a total of 32 additional messages (by default). If the downstream endpoint still has not received a message after this time, it will reduce its data rate to the minimal level if it is not already at this level.
After this procedure, the end device will send and receive data at the least rate possible. Also, it will have sought acknowledgment for several uplinks and will be unplugged from the network if it still hasn’t received a downlink.
Verified Transmissions
The simplest way to identify a connection loss is when an end device sends a confirmed message upstream that the network does not accept. In LoRaWAN1.0.2’s Section 18.4, a table shows when an end device should drop its data rate if it doesn’t get an acknowledgment. When two admissions are missed, the end device lowers its data rate by one step.
MachineQ advises against concluding that a connection has been lost until the destination device attempts retransmission 7 times without receiving an acknowledgment. One possible explanation is that the gateway’s backhaul briefly failed or that the end device can only communicate with a single gateway. Since joining a network might take a few minutes and involve many transmissions, you can utilize a longer timescale to detect connection loss.
Connecting LoRaWAN Device and How To Verify its Status
If you’re adding your wireless device for the first time, I would recommend using the console. On the AWS IoT Core for LoRaWAN Intro page, pick Get started and then Add device. Choose View device to view the gateway you added. Select Add device to add more devices.
After you have added your device, consult the user manual that came with it to find out how to get your LoRaWAN device to start transmitting uplink messages.
Use the console to verify the device connection
Go to the Devices page of the AWS IoT console and select the device you added to check the connection status. The Wireless devices information page shows the last uplink date and time.
Use the API to check device connectivity
Use the GetWirelessDeviceStatistics API to check the connection status. This API’s response body indicates the latest uplink received and has no request body.
Now, you have connected your device and confirmed the connection status.
How to retrieve lost data
Most LoRaWAN applications use Class A mode, which involves the end device transmitting sensor data rarely but at regular intervals using an ALOHA-like protocol. We say that the sensor’s reading time equals the time it takes to send its data, or “data unit.” The Internet of Things relies on this information. Since losing frames means losing data, We need to avoid losing as many frames as possible.
Acknowledgment systems allow for frame retransmission via LoRaWAN. Nevertheless, this can’t be implemented for every frame due to various reasons;
- It is more costly in terms of energy for the end devices to utilize an acknowledgment and ARQ mechanism if one uses such mechanisms at the end devices.
- Retransmissions are not scalable since the number of collisions increases with the number of devices, even after employing additional channels.
- Since gateways must comply with the ISM-band switching frequency restriction, they can only serve a limited amount of acknowledgments. Thus, LoRaWAN acknowledgments are unscalable.
Because of this, finding a solution that prevents the use of acknowledgments while minimizing data loss due to the loss of frames is necessary. A solution must meet numerous criteria, including;
- The transmitting side solution must be simple since the end device is an integrated unit with restricted computing and energy capabilities.
- No LoRaWAN specifications or network modifications are required for the solution to function with current applications.
- Keeping the number of transmissions minimal is crucial for the system’s scalability and efficiency.
Therefore, we suggest a coding method, dubbed DaRe (Data Recovery), that operates at the application layer and takes inspiration from the fountain and conventional programming methods. Consequently, you can use DaRe for any application without requiring modifications to the LoRaWAN protocol.
Wrapping it up
There are numerous possible causes that might trigger a LoRaWAN device to momentarily lose connection with the network. Since some disconnections are unavoidable, it is essential to always have a solid understanding of what causes them and how to fix them. In the event that there is a problem with the LoRaWAN network, the specification expressly advises users not to do a systematic rejoin. If it intends to be power-cycled, it should permanently store activation results. Several obstacles may get in the way of your LoraWAN range, and you’ll need to be acquainted with them so you can find the best ways to solve them.
You can inquire about the best LoRaWAN gateway via the side form or chat.
