how we guarantee message delivery over semtech's lora

How We Guarantee Message Delivery over Semtech’s LoRa

We announced Haystack XR Mode last spring, and recently announced a major improvement — XR2 — just last month. Stunning progress in the world of LPWAN’s and all HayTag Demo Kits will now include XR2.

But forward error correction — the essence of XR — is only part of our error correction capability. The “other half” of Haystack’s error correction — Assured Delivery — is arguably just as important, particularly in mobile asset tracking environments.

What is Assured Delivery?

Messages sent using DASH7 benefit from a fully bi-directional Automatic Repeat Request (ARQ) architecture that also operates in real-time. DASH7 was designed with hyper-low latency — usually less than 2 seconds — and more overall intelligence including variable power levels, configurable timeouts, and dynamic message lengths to ensure maximum probability of message delivery.

In contrast, battery powered LoRaWAN can theoretically employ acknowledgements but doing so typically requires extreme latency (minutes or hours or days) and includes practical cap on the number of messages per day. More importantly, LoRaWAN gateways cannot receive messages on a given channel while transmitting on that channel, therefore sending an ack on LoRaWAN requires abandoning incoming traffic just to send that ack. Multiple channels (found on the more expensive SX1301 chip) ameliorates some of this, but as the number of endpoints or messages grows, this does not scale. And if every endpoint message needs an ack — as is the case in most mobile asset tracking use cases — message traffic can potentially be very high. Also where ISM duty cycles are limited to 1% or less, sending acks is a costly — and impractical — feature particularly where Quality of Service (QoS) is important.

The LoRaWAN “workaround” to this reality boils down to a kind of “spray and pray” model of sending the same message multiple times in order to improve probability of message receipt but — and I’ve written on this beforeLoRaWAN was never meant for anything mission critical or anything mobile. Think of LoRaWAN as a minimally practical solution for non-mission critical fixed applications and you’re on the right track.

Why This Matters

ARQ is an important feature for mobile LPWAN use cases because the opportunities for message failure are exponentially greater than with fixed use cases. If QoS, battery life, or network congestion matter in your mobile application, then ARQ is important for you.

Here’s one example: a fixed gas meter connects a LPWAN endpoint to a LPWAN gateway with a fixed/constant distance between both points. A simple site survey can usually help pre-determine the risks of message failure — distance, terrain, etc. — and once the system is in place messages to the gateway are assumed to be sufficient for that use case. This is oversimplifying since packet loss even in fixed environments can be non-trivial, in fact we hear from developers complaining of 80% packet loss with LoRa even in fixed environments— but a predetermined, fixed distance between an endpoint and gateway reduces a messages risk of failure in a profound way.

Now let’s switch to mobile. And let’s use a mobile asset tracking use case everyone knows a bicycle — outfitted with a LPWAN endpoint:

  1. The distance between the bicycle and a fixed gateway will vary from a few feet to many miles, even tens of miles. Your LPWAN connection might have been perfect when the bike was parked in front of your home, but connections grow more tenuous as distance from the gateway increases, and the risk of packet loss rises.
  2. The terrain between the bicycle and gateway may vary greatly. A bike traveling here in Northern California might dip into a valley, park behind a small mountain, or move through a dense redwood forest or the financial district in downtown San Francisco. “Dead spots” are a fact of life for most mobile LPWAN use cases.
  3. At 915 MHz in North America — an unlicensed ISM band — the mobile LPWAN endpoint transmitting in the tens of milliwatts is among the weaker fighters in the wireless arena. Electricity meters blasting at one full watt (one thousand milliwatts), alarm systems, industrial controls, keyless entry, weather stations, etc.
  4. The bike will encounter a near-endless array of multipath factors. Parking garages, metal walls or containers, office buildings, on a lot with hundreds of other bicycles, etc.
  5. Endpoints that move from outdoors to indoors — think backpacks or pallets of food — create entirely new challenges. The bike might be parked in a deep basement that completely shields the ability to send or receive messages.

Mobile LPWAN applications are akin to combat in an urban war zone. Fixed LPWAN’s, by contrast, are like target practice at a rifle range: with a bit of practice even long distances, the target gets dialed-in and the sender/shooter delivers the shot to the target.

How Haystack Assured Delivery Works

  1. Real-time, coded acks. Not only are messages acknowledged in real-time, the acknowledgements themselves are encoded (and decoded) using Haystack’s XR2 error correction technology. In other words, Haystack supports both real-time uplink and real-time downlink acks. For applications requesting a message from an endpoint
  2. Message re-transmit. Endpoints or gateways that do not receive acknowledgement may retransmit the packet until an acknowledgement is received or exceeds a pre-defined number of transmissions. The number of transmissions is dynamically configurable and can be adjusted on per-message basis.
  3. Dynamic power scaling. Messages sent initially at a lower power level without an ack may be retransmitted at a higher power level in order to maximize probability of message receipt.
  4. Dynamic packet sizing and data rates. Messages sent at higher data rates or using longer packet lengths can by retransmitted at lower data rates and using shorter packet lengths in order to improve probability that the re-transmitted message is received.
  5. Optional: beacon. In certain instances it may be desirable to trigger a constant series of messages from the endpoint. For example a series of accelerometer events may imply a bike being stolen, triggering the endpoint to begin beaconing at an accelerated rate in order to better assist with the recovery of the bike.

Haystack Assured Delivery In The Future

Guaranteed Delivery has the potential to be even more robust using existing DASH7 features:

  • Multi-hop. An endpoint experiencing difficulty in receiving an acknowledgement might instead transmit its message to another endpoint that in turn delivers the message to a gateway. Conversely, a gateway might utilize multi-hop in order to deliver a message to an endpoint that is difficult to reach. Note: we generally don’t advocate for more than one hop in this scenario in order to maximize endpoint battery life.
  • Peer-to-peer. An endpoint that is not near a gateway might instead be queried by a gateway proxy — a endpoint charged with ensuring that other endpoints are within range of the proxy. Cattle ranchers, military units, other fleet management applications.
  • Power scaling. Inherent in acknowledgements are timestamps and signal strength indicators that just help the system adjust power, data rate, message length, and other parameters to improve message delivery and optimize endpoint power consumption.

Haystack offers a complete solution to developers seeking a solution for mobile asset tracking over LoRa. For more info, take a look.


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