The Really Hard Thing About GPS and the IoT

“All things excellent are as difficult as they are rare.”

• Baruch Spinoza

TL;DR:

• The mobile IoT needs GPS
• GPS is traditionally not low power
• Getting GPS right with low power requires a tricky confluence of technologies

This month, I witnessed a “coming out” party of sorts for a new LTE NB-IoT product from Samsung. It’s a “tracker” that you can put on dogs, bikes, kids, or whatever moves. (http://zd.net/2yrMDB9)

At first blush, it is an exciting product:

• It is IP68 water- and dust-proof, has a horizontal/vertical of 4.21cm, and is 1.19cm thick.

• It is optimal for indoor and outdoor use, including pet and children tracking, protecting personal items, and attaching to luggage.

• An attachable ring will enable it to be hung on bags and key chains.

• It also has an on-demand feature, where it will show its location and set times; while its geo-fence feature alerts users when it has left a set virtual zone

• It can also be synced with smart home appliances to turn on the light, TV, or the robot cleaner when close to home.
  Small, versatile, feature rich … what’s not to like, right?

Except this:

"Connect Tag consumes little energy and data, and a full charge will last seven days."

NB-IoT, as most readers of this website probably know, is the cellular industry’s response to Sigfox and LoRa. Another cellular response, LTE CAT M1, has outed itself as a “high power” WAN technology. So, NB-IoT is supposed to be the cellular industry low power savior: long range plus low power and, of course, low cost.

Now, it’s possible that this is just a bad implementation of GPS over NB-IoT, but let’s just assume Samsung knows a thing or two about wireless and location services. So what happened?

There’s something inherent in the NB-IoT stack that isn’t very “low power”, after all, which seems unlikely given what we hear about the uptake of NB-IoT for fixed meter reading; or

NB-IoT can’t easily support “hot start” GPS location acquisition.

GPS, as I’ve written before (http://bit.ly/2pBcYqp), can be a very power hungry component of a mobile IoT endpoint. Historically, we’ve seen mobile GPS endpoints married with cellular, which (usually) promised around 30 days of battery life and often delivered far less. LPWAN’s were supposed to change all that, but in the Samsung case above, battery life, it would appear, got worse.

A GPS receiver needs to locate at least four satellites in the sky in order to compute its location, and the time required to do so can range from a few seconds to many minutes. A “cold start” can force your mobile endpoint into searching for satellites for many minutes … with predictable battery life results. A “hot” start, on the other hand, can enable the endpoint to acquire GPS coordinates in a few seconds.

So to avoid battery meltdown on your GPS-enabled mobile IoT device, hot starts are extremely helpful. Enabling a GPS hot start requires the network to broadcast a kind of “cheat sheet” to the GPS receiver to allow it to acquire location more quickly. For many Assisted GPS or “A-GPS” is the mechanism for doing this. (http://bit.ly/2p1E6hh)

Low Power Wide Area Networking technologies are about battery powered devices that can communicate over long distances and deliver long — as in multi-year — battery life. Today, lots of LPWAN technologies are being deployed in fixed use cases — meter reading, for example — and simply send a message once a day back to a host reporting on the day’s usage. Water meters, for example.

But deploying LPWAN’s for real-time outdoor location is another matter. While there are multiple techniques for deriving location without GPS, most LPWAN protocols at best offer a high-latency, low accuracy form of location that would be hard to characterize as real-time. Adding GPS to these requires the GPS receiver to be active and, in most cases, in a perpetual state of looking for satellite signals. Even invoking GPS based on an event (e.g. movement) is full of risks like false positives that will also deplete a battery. A-GPS mitigates this power draw problem but … supporting it correctly remains elusive for many (but not all) LPWAN protocols. It is unclear whether this is the driver behind the Samsung NB-IoT battery life issue, but I look forward to hearing more detail from those closer to that product.