Expanding Golioth Location with Gateway-Based Positioning

We recently announced the general availability of Golioth Location, a comprehensive device positioning service. Less than two weeks later, we have expanded the service to support gateway-based positioning, making it possible to obtain the location of devices that do not have GNSS, cellular, or Wi-Fi capabilities. This is accomplished by resolving the location of an indirectly connected device by the known location of the gateway that delivered data to Golioth on its behalf.

Gateways and Devices

We previously defined the distinction between devices and gateways in The Taxonomy of Connected Device Networks. Gateways deliver data to Golioth, typically over cellular, Wi-Fi, or Ethernet, on behalf of other devices. This is enabled by pouch, a custom protocol we developed that enables devices that can’t communicate directly with cloud services to deliver data via an intermediary (i.e. gateway). One of the most common use cases is Bluetooth Low Energy (BLE) devices, which can deliver encrypted “pouches” to a gateway, such as a mobile application on a user’s smartphone or an embedded Linux-based single-board computer (SBC), which can then be forwarded along to Golioth over Wi-Fi or cellular. Golioth customers in our Bluetooth-to-Cloud private access program are using this functionality today.

Gateways can leverage Golioth Location’s network-based positioning to resolve their location from scanned Wi-Fi access points or nearby cell towers, or, if they are equipped with GNSS capabilities, can obtain their own position and deliver it to Golioth Location for tracking. Because edge devices must be in relatively close proximity to a gateway in order to communicate through it, Golioth Location is able to approximate the location of the device over time based on the gateways that deliver data on its behalf, regardless of how the gateway obtained its own location.

Making Use of Pipelines

The same location transformer that is used for network-based positioning in Pipelines can also be used for gateway-based positioning. If network information is provided in the message payload, it will first attempt to resolve using network-based positioning. If it is unsuccessful, or no network information is provided, the transformer will fallback to gateway-based positioning if the message was delivered via a gateway. If the position of the gateway is known, it will be returned as the position of the device.

For example, in the following Pipeline, an empty message sent from a device on the /.s/loc path and delivered via a gateway could be routed to the location transformer. The information about the gateway will be automatically passed from the Pipeline context to the transformer. Because no network information is provided, the transformer will look up the location of the gateway, and if known, will return it such that it can be passed along to the location and lightdb-stream destinations.

filter:
  path: "/loc"
steps:
  - name: resolve-position
    transformer:
      type: location
      version: v1
  - name: store-location
    destination:
      type: location
      version: v1
  - name: stream-location
    destination:
      type: lightdb-stream
      version: v1

Because multiple Pipelines can process the same data, location resolution can be triggered as a side-effect to streaming any data, such as sensor readings or other application data. The content of the message will be discarded by the location transformer if it does not contain network information. This effectively enables location tracking with zero-byte overhead, just by knowing what gateway a device communicated through.

Getting Started

Gateway-based positioning is available to all users in Pipelines today, but in order to start using gateways you must enroll in the Bluetooth-to-Cloud private access program. After doing so, you’ll be able to start tracking the location of your BLE devices without changing a single line of firmware. If you have any questions or feedback, feel free to reach out to us on the forum!

Dan Mangum
Dan Mangum
Dan is an experienced engineering leader, having built products and teams at both large companies and small startups. He has a history of leadership in open source communities, and has worked across many layers of the technical stack, giving him unique insight into the constraints faced by Golioth’s customers and the requirements of a platform that enables their success.

Post Comments

No comments yet! Start the discussion at forum.golioth.io

More from this author

Related posts

spot_img

Latest posts

How to Use Golioth Blockwise Stream to Upload Large IoT Data Payloads

Golioth allows large data uploads using the Firmware SDK and via blockwise stream calls. This post shows how to modify the Stream sample to try uploading large amounts of arbitrary data and route that data through Golioth Pipelines.

Golioth Joins STMicroelectronics Partner Program

Golioth and STMicroelectronics are officially partners. Golioth will enhance ST offerings and make devices more secure, more capable, and easier to manage from afar.

Bluetooth Gateways in the Field: The Globalscale GTI-RW612

Golioth Connectivity enables developers to connect Bluetooth devices to the cloud using Gateways, including microcontroller based gateways. Today we're discussing the Globalscale GTI-RW612 gateway....

Want to stay up to date with the latest news?

Subscribe to our newsletter and get updates every 2 weeks. Follow the latest blogs and industry trends.