How To Improve LoRa In The EU With Better Error Correction

Some quick notes on how Haystack helps in the 868 MHz band in many EU countries:

• Forward error correction is about more than getting a message to its destination intact. It also allows for faster data rates than would otherwise be practical for unencoded (non-error corrected) data. This is useful not only for extending battery life, but it can play a role in ensuring compliance in challenging regulatory environments.
• Most EU-based LoRaWAN deployments we see are tuned to 868 MHz, where regulators impose a 1% duty cycle per 24 hour period, or a limit of 36 seconds of transmit time per hour. This might work for the occasional gas meter use update, but for mobile applications it can create huge challenges.
• The reality of mobile environments — and I’ll illustrate with mobile asset tracking as the dominant use case — is that you often don’t care where the endpoint is — until you do. And when you do, finding it can often becomes an urgent endeavor. The owner of the asset may want to query constantly to find the missing asset or command the endpoint to move into beacon (non-stop, regular messaging) mode. Missing briefcase full of trade secrets? Missing carbon fiber bicycle? Missing champion golden retriever? Missing mother-in-law? All of these or at least most of these are scenarios where the beneficial owner would be hyperactively hitting the “query” button in order to locate. But unlike fixed LPWAN use cases, mobile use cases experience all manner of “dead spots” and other multi-path interference that is largely absent from fixed use cases. The probability then that a message will be sent successfully from an endpoint to a gateway tends to vary almost constantly as an endpoint moves.
• One way of measuring the probability of message transmission is through the use of acknowlegements. Among other things, downlink message acknowledgements or “acks” are usually discouraged in LoRaWAN since sending them requires shutting down a gateway’s receive feature on at least one channel. Multiply this by hundreds or thousands of mobile endpoints and as collisions occur, packet error rates only increase and your network slows to a crawl.
• Regrettably, one way LoRaWAN developers avoid the use of acks is to retransmit the same message multiple times in the hopes that at least one of the copies arrives at the gateway without corruption. But these “blind retransmits” accrue directly to data rate limits: for example, a 24 byte message using spreading factor 12 (the slowest bitrate, theoretically used by mobile LoRaWAN devices in order to minimize packet loss/extend range) and 125khz bandwidth requires nearly two seconds (1,974.3 ms) to transmit. Multiply this by, say, four or five blind retransmits and the risk for mobile applications using LoRaWAN is obvious: too many blind retransmits in a given period and your endpoint could be blocked from sending more even while the asset itself remains lost. If resiliency for your mobile asset tracking app in the EU relies on blind retransmits, at best it might be acceptable for non-critical, low value assets where the known variability of multi-path factors is consistently low and location updates are expected infrequently.
• Haystack’s approach on deploying mobile LoRa apps at 868 MHz:

1. XR2 Error Correction. The most advanced LPWAN forward error correction available today reduces packet error and massively improves the odds your message will get there the first time with no need to retransmit. Our own internal results continue to improve, even above these achievements. You can order a demo kit to test XR2 for yourself.
2. Listen-before-talk endpoints. Haystack endpoints don’t blindly re-transmit unless configured to do so. Our default approach is for gateways to query endpoints and within that query is information that helps the endpoint dynamically adjust message parameters (length, data rate, power, etc.) before replying. This feature is an important part of Haystack Assured Delivery.
3. Message acknowledgements. Sending an acknowledgement with Haystack does not involve disabling the receive capabilities of any radio. Like listen-before-talk endpoints, acks are dynamically configurable and can be sent even following multicast or broadcast communications. And even acks are encoded with XR2!
4. Intelligent re-transmit. Using signal strength, data rate, and other data from the gateway, with Assured Delivery Haystack endpoints may intelligently execute Automated Repeat Requests (ARQ’s) and re-transmit packets in order to maximize the probability of successful receipt. Haystack’s use of DASH7 advertising packets and other techniques will usually minimize the need to retransmit, however, since an endpoint in listen-before-talk mode may not “talk” until it receives either a query or an advertising packet indicating an available gateway.

Deploying LoRa for mobile use cases like asset tracking requires flexibility and adaptability to ever-changing surroundings that can hinder or block a connection with a mobile endpoint. Deploying mobile LPWAN endpoints in strict regulatory environments where duty cycle is strict means utilizing the most advanced networking stack available, which you can learn more about here on our website.

===============

Get the latest about Haystack by signing up for our newsletter here.