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!