How To Solve For Geofencing In The Low Power IoT
One feature that is under-discussed when discussing mobile asset tracking is the ability to generate an alert when an asset moves into or out of a pre-defined geographic area, commonly referred to as geofencing. In the low power/LPWAN space, geofencing is rarely discussed because … it’s just hard to do for most LPWAN technologies. Some LPWAN vendors may talk of geolocation, but references to geofencing may be scarce or non-existent for reasons I’ll touch on below.
Defining Geofencing
First and before getting into the low power IoT part of this post, maybe it’s worth clarifying what we are talking about:
So, it’s a virtual geographic boundary. Graphically, it is usually configured using a map, perhaps like this:
Or a more complex shape like this:
Then, as an endpoint enters or leaves the geofence, it triggers an alert and sent to someone who cares. Like this:
You probably have your own experiences with geofences as a consumer — certain location-based advertising is effectively implementing a geofence when a cellular or in-store wireless network “detects” you entering a certain geography and enables an advertiser to put an offer in front of you. (I drove with Waze over the holidays to visit relatives and experienced the annoyance firsthand …)
For the IoT, however, geofencing experiences are different. Primarily, geofencing is about managing mobile assets: tracking them, securing them, and monetizing them. In my experience, geofencing is something we talk about for IoT use cases that are based outdoors. Indoor location and geofences are another topic and but first I am focusing on outdoor.
In the annals of mobile asset tracking history, the “dominant” wireless technologies have been cellular and satcom. True, their tracking products are becoming less expensive and smaller, but short battery life and high cost remain as significant barriers to penetrating the mobile asset tracking market. Here’s a look at how AT&T does it with cellular:
Despite efforts by Bluetooth tracking companies to pretend their devices can be found over large geographic areas, Bluetooth is too short range for most commercial or industrial asset tracking, so the subject of geofences there is moot. And passive RFID (EPC Gen 2) is not typically used for mobile asset tracking, either.
But with newer LPWAN technologies and better networking software, mobile asset tracking is about to become much more interesting and geofences will play an important role.
Implementing Real-Time Geofencing With LPWAN’s
For mobile asset owners who are exploring adding wireless connectivity, geofences are an essential tool — perhaps the essential tool — for managing the custody of an asset and especially useful when an asset moves in or out of a geofenced zone and triggers an alert or alarm: the air compressor just exited the lot unauthorized — notify the police. The rental scooter was just returned — stop charging the customer. The bull just wandered off our property — send a ranch hand to get it back to the herd, etc.
But unlike geofences for high powered cellular devices, where short battery life is the norm, implementing a geofence with an LPWAN is tricky, mainly due to the “LP” (low power) in LPWAN. The conventional approach to geofencing — let’s take cellular’s method — is to maintain a real-time, “always-on” approach to monitoring an endpoint’s location while using some combination of GPS and trilateration to determine precise location. Using this conventional approach on an LPWAN would drain the battery within days, so real-time geofencing using a LPWAN will just require a different approach if you want to keep the “LP” in your LPWAN.
So to implement a geofence on an LPWAN we need:
- Low power/multi-year battery life, even when executing a geofence.
- Long/Sufficient Range. This is self-evident.
- High-Precision Location. This is hard to do with LPWAN’s without draining the battery, but some of us have figured it out.
- Real-Time Alerts. The system is aware at any time when the endpoint strays in or out of a geofenced zone/virtual boundary. Without real-time alerts, your geofence is probably pointless.
Now: on to how to accomplish #3 and #4 …
Implementing LPWAN Geofences Using the DASH7 Advertising Protocol
At Haystack we are implementing the DASH7 networking stack over one LPWAN — Semtech’s LoRa — with good results. (More on this here and here.) DASH7 provides a fully bi-directional and feature rich firmware stack that overcomes the many limitations of LoRaWAN while exploiting the strengths of the LoRa radio.
To execute geofencing on a LoRa-based LPWAN network, DASH7 contributes at least two unique and essential features.
- High-precision location using DASH7’s multicast feature, as outlined here. Without high-precision location, a geofence is just hard to reliably execute and subject to false-positive events. Haystack’s innovative approach to implementing GNSS/GPS over low power radios — using multicasted A-GPS datagrams to shorten the GPS location acquisition sequence to just seconds — while preserving multi-year battery life solves for this.
- Real-time geofence alerts via the DASH7 advertising protocol.
DASH7 Advertising Protocol Basics
A defining feature of DASH7 — and the path to solving for high-precision LPWAN location and real-time geofence alerts — is its low power wakeup, also referred to as “instant-on.” Instant-on allows DASH7 endpoints to remain in a low power “listen” mode and avoid the kind of power-intensive synchronization and other overhead that is standard in more high-powered wireless protocols.
You can download the DASH7 specification here, but the following is an illustration of how a host (let’s say, a LoRa gateway) sends “background frames” to an endpoint causing the endpoint to “wake up” and prepare for a location query or other data transmission like an Assisted GPS datagram:
In our case, an endpoint briefly samples a channel for activity, checks for signs that there is a background frame within the activity, and if true, receives the background frame. Again, there is more on this in the DASH7 specification but basically the DASH7 Advertising Protocol is the foundation for many features in DASH7 including real-time queries, group synchronization, and more. But in the case of geofencing, it has a more intriguing use: measuring signal strength.
Step 1: Signal Strength As A Proxy For Location
A conventional approach to the use of signal strength in implementing geofencing would be a simple received signal strength indicator (RSSI) that, when it breaches a given value, triggers an alert. For example, suppose you configure the perimeter of your geofence to correspond with some RSSI value received from a gateway, e.g. a 200 meter radius from the gateway = an RSSI value of X. RSSI values above X are assumed to indicate an endpoint that is within the 200 meter radius, values below X are assumed to indicate an endpoint beyond 200 meters.
Here is a picture showing a circular geofence perimeter:
And here’s another showing the mobile asset that moved outside the geofence:
One issue (among others) with this type of geofencing approach is: what happens if either the gateway or the endpoint are measuring an RSSI value that is corrupted or otherwise “false?” All things being equal, this will trigger an alert to the business user, also known as a false positive. For example, a 40-foot intermodal shipping container parked temporarily between a gateway and an endpoint will — due to the sturdy steel construction of the container and the stubbornness of wireless signals that won’t propagate very easily through or around steel — result in a weak (or non-existent) RSSI value that is <X, triggering a false-positive geofence alert.
Or think of a construction site with large metal vehicles, metal girders, and other RF-unfriendly objects:
So to avoid false positives in our LPWAN geofencing application, we need a method to confirm — with high precision — the actual location of the endpoint. But before we trigger the logic that would derive high precision location, it’s better from the standpoint of preserving battery life if we don’t needlessly trigger it. How?
One answer is to utilize signal strength not as a final determinant of location, but as a proxy for location that may trigger an additional process for establishing more precise location. And what better way to implement that proxy than using messaging/packets that are already being transmitted between devices — DASH7 advertising packets!
In other words, a gateway already transmitting DASH7 advertising packets can embed a signal strength indicator into any packet allowing an endpoint to not only “wake up”, but also know whether there is a need to invoke GPS. It’s as if the gateway is continually transmitting “You still there?” and the endpoint only responds when the strength of that transmission decreases past a pre-determined threshold.
For example, a bicycle parked in the garage just 20 meters from a residential gateway receives a strong RSSI value embedded in DASH7 advertising packets sent from the gateway and the endpoint may be programmed to do … nothing. But an endpoint receiving advertising packets with decreasing RSSI values can be assumed to be moving away from the gateway and could be programmed to invoke GPS.
In case it isn’t clear, the reason this use of DASH7 and RSSI is so important is that it massively reduces power consumption compared to other high powered/always-on protocols. If you want the “LP” in LPWAN and want a real-time geofence without false positives, this is the best approach available today.
There are alternative versions of this approach, e.g. the endpoint transmits advertising packets to the gateway, effecting the same outcome after a gateway responds with a command to invoke GPS. Similarly, environmental sensors may trigger the endpoint to transmit advertising packets to the gateway, i.e. accelerometer. Diving even deeper, it’s even possible to utilize other endpoints as a means for establishing a signal strength proxy, i.e. an endpoint peer with exact (GPS) knowledge of its location can help another endpoint learn its relative location using DASH7’s peer-to-peer and multi-hop messaging capability. (More on that here.)
In sum, there are many ways that DASH7 helps skin the RSSI cat in support of geofencing, and the fact that a geofence can be implemented without heavy ongoing messaging traffic (and battery drain) is again, especially relative to cellular, a really big deal.
Step 2: Confirming Location
OK so we’ve established how to execute a proxy for location using RSSI and DASH7 advertising packets. Now: let’s explore happens when an RSSI measurement falls below a pre-determined level and triggers a sequence to acquire more precise GPS location.
Confirming the RSSI Alert via GNSS/GPS
An endpoint that measures an RSSI value that is less than X may invoke high-precision GPS (or other GNSS satellite constellation) using the DASH7 multicast feature. This sends a GPS “cheat sheet” or Assisted GPS datagram from the gateway to the endpoint, enabling the endpoint to acquire its GPS coordinates via a “warm start” that takes only seconds. More on this here, but if you are serious about implementing geofencing over LPWAN’s, I recommend GPS as the way to go given its ease of implementation and, if you really want to avoid false positives, for ease of use. GPS allows for more precise measurements of the location of the mobile asset and avoids potentially large errors possible with RSSI. Over the next 24–36 months, I expect the pricing of GNSS/GPS receivers for low power devices to decrease significantly.
GPS allows for greater flexibility in the shape of the geofence. For example, a single gateway implementing an RSSI-based geofence would most likely default to a simple circular geofence like this:
With GPS, the high precision allows us the flexibility to create geofences that match the contours of a physical boundary like this:
Or this:
A side note on GPS: the normalization of “GPS” is also something that many in the IoT overlook: buyers in both enterprise and consumer markets are familiar with the paradigm of GPS and expect GPS-like levels of precision in their mobile asset tracking deployments. It is certainly possible to utilize non-GPS approaches to outdoor location, but give the falling costs of GPS components, the availability of networking stacks like Haystack’s DASH7, combined with the additional costs of implementing a non-GPS location solution, the list of reasons to withhold GPS from end users is growing shorter. Adding GPS/GNSS to your LPWAN feature set is something your customers can relate to way, way better than some of the other nerd-speak in your product specification sheet.
Confirming the RSSI Alert Without GNSS/GPS
While GPS implemented on a LPWAN using Haystack is very low power, for some applications the added cost of the GPS receiver may drive developers to look for alternatives. A non-GPS alternative is also necessary for indoor location use cases as well as a means for a “back up” to GPS or for use cases requiring both indoor and outdoor geofencing (e.g. certain warehouse/supply chain use cases).
Trilateration Using Fixed Gateways
The use of trilateration is one method where while not as accurate as GPS, we have still observed relatively high levels of accuracy. The location granularity is highly correlated with the number of gateways within range of a given endpoint: a single fixed gateway receiving a message from an endpoint will help us infer location in a far less precise manner than five fixed gateways doing the same thing.
The use of trilateration requires the use of a location engine at the gateway or potentially in the cloud, as well as a site survey to help calibrate RSSI values with the
Trilateration Using Mobile Gateways or Mobile Endpoints
Also, a moving gateway or moving endpoint will result in measurements that are comparable to multiple gateways, providing another potential path with superior location granularity to a single fixed gateway and single non-moving endpoint.
We have observed high levels of accuracy (not as accurate as GPS, however) using both this method as well as using a single, fixed gateway measuring a moving endpoint. Both have the effect of generating multiple vectors between gateway(s) and endpoint to provide a higher resolution location than with a single fixed gateway and single non-moving endpoint. Still, these approaches may be less reliable and more costly to implement and still vulnerable to false positives as illustrated above.
This method of trilateration also applies to moving gateways locating a fixed endpoint.
One more thought on mobile gateways: developers considering “lost and found” use cases may be considering mobile gateways for scenarios where fixed gateway infrastructure is limited and endpoints have the potential to travel over long distances.
Time Difference of Arrival (TDOA)
TDOA is an additional approach to non-GPS-based location that we explored in some detail in a recent post. For LoRa, we find RSSI to be a more convenient and reliable method of performing relative location, but as new permission-less use cases utilizing blockchain emerge, the need for a more secure (non-spoofable) terrestrial alternative to GPS is a hot topic on Telegram now. Exciting new territory.
We are not actively supporting TDOA commercially (yet) but expect to do so later this year in conjunction with these efforts around blockchain.
Other Considerations
Using the DASH7 Advertising Protocol is not the only path to implementing a real-time geofence with DASH7. For example, environmental sensor triggers may initiate a geolocation process or heuristics about the underlying asset may cause intelligent interrogation of the endpoint which, in combination with a geofence, creates additional paths
Implement LPWAN Geofences Without Haystack/DASH7?
If you want to implement an LPWAN geofence using a unidirectional protocol, you might as well call it a “dumb geofence,” since your endpoint is effectively clueless about its location and will likely either “under-transmit” to the gateway — making the geofence useless — or, if the regulatory authorities will allow it, to over-transmit, which in an attempt to emulate a real-time geofence, will burn precious battery life.
One or two companies are pursuing the “dumb” LPWAN geofence route using a hack of LoRaWAN’s one-way only capabilities to provide some level of location visibility for battery powered LoRaWAN devices. But since these utilize a unidirectional, uplink-only protocol, their mentions of geofencing are usually scarce or non-existent.
Drawbacks of “Dumb” Geofences
The drawbacks of attempting a geofence with a unidirectional protocol should be obvious:
- An endpoint programmed to transmit or “beacon” at some regular interval — say, every 30 minutes — loses any claim to being “real-time” and really should be part of no serious geofencing architecture as your mobile asset may be long gone by the time you receive your first geofence-driven alert.
- An endpoint that uses movement, via an accelerometer, as a trigger for a message from an endpoint is basically of little value for assets that move frequently or in environments where vibration or other environmental factors trigger a false positive. An endpoint that moves constantly — let’s say an animal — would be transmitting continually throughout the day, whether inside a geofence or outside, since there is no way to command the endpoint to stop transmitting or “stay quiet” when it is inside the geofence.
- An uplink-only endpoint that has traveled out of range of fixed gateway infrastructure, has no way to “know” when or how to beacon its existence or respond to a wakeup call from a mobile gateway. An uplink-only endpoint, programmed to beacon every 30 minutes, and has traveled out of range at a rate of 60 mph for 29 minutes could be nearly 30 miles away from the gateway before it is potentially flagged as missing. And given the high rate of packet loss and lack of error correction in battery powered LoRaWAN, there is a strong chance that the missing endpoint will be mistaken for a false negative. Moreover, the antenna array requirements to implement a LoRaWAN uplink-only TDOA system are a non-trivial systems integration effort.
- The lack of error correction in a unidirectional protocol does not provide the gateway with an opportunity to request that the endpoint re-transmit the last message in order to confirm the RSSI value it just received. For example, assume a gateway receives Packet A with RSSI value = 1.0 and then receives Packet B with RSSI value = 0.75 just ten seconds later and then … nothing. If it were your gateway you want to a) confirm that Packet B is legitimate and b) tell the endpoint to send some more packets. But with unidirectional protocol this isn’t possible.
Note: I have seen one company that claims to deploy GPS on LoRaWAN though the battery life — four days! — obviates the need for a LPWAN in the first place and the lack of real-time alerts for a geofence perimeter breach render these useless for geofencing applications.
Conclusion
Geofencing is an exciting opportunity for mobile asset tracking over LPWAN systems, but the importance of the right networking stack cannot be overstated. A unidirectional protocol is a poor choice for most LPWAN implementations but in particular those seeking to implement geofencing. A bi-directional protocol that supports multicasting/broadcasting as well as low power wakeup is, for the LPWAN world, essential.
