Bluetooth roaming with Golioth Connectivity

Golioth Connectivity enables Bluetooth devices to ‘roam’ between gateways out of the box, something that many IoT Bluetooth networks couldn’t dream of. Roaming¹ has value in asset tracking applications, sensor nodes that aren’t fixed in place, and honestly…it’s just cool. What’s more, roaming just works because of how Pouch is architected with end-to-end (E2E) encryption². Let’s look at the counter-example first and then dig into the architecture a bit more.

How roaming between Gateways has traditionally worked

For most models of Bluetooth devices talking through Gateways³ up to the Cloud, the Gateway is a trusted source. When a Gateway talks to a Bluetooth node, it needs to first determine if/when/how it’s going to connect to a device over the Bluetooth link. Often this is based on the UUID, something in the advertising packet, or a specific GATT profile being transmitted. Next the pairing process must complete so the Gateway (normally Central) and the Node⁴ (normally Peripheral) can communicate.

Next, the Gateway needs to determine if that device is allowed to transmit data up to the Cloud. This can be done with a Gateway connection to a Cloud backend that validates a newly connected Node at the application level and determines whether the device is allowed to transmit. If it is allowed, the data starts flowing through the Gateway up to the Cloud. For this example, lets say this is Bluetooth Node 123 talking through Gateway ABC.

If the Node moves to a different location, now what?

First, Node 123 ‘sees’ a new Gateway, we’ll call the new one Gateway XYZ. Once again, the gateway needs to determine if/when/how to connect over Bluetooth to the Node. If this requires that the link is encrypted, once again there would need to be some kind of manual intervention to enable the pairing to happen. If there is no such requirement, then it’s likely the Gateway will validate at the application level, though this might mean that the Bluetooth link and the data contained within is visible to bad actors peeping into Bluetooth traffic with a sniffer. In order to validate Node 123, the new Gateway XYZ either needs to talk to the Cloud or directly to Gateway ABC (much less likely). If the new Gateway XYZ validates the Node then it will be able to ‘Roam’ and pass data through the new Gateway.

The gateways themselves can have a variety of methods to block/allow Nodes to pass data, but the infrastructure and security requirements ramp rapidly for this setup if you want to have a seamless handoff between Gateways. For instance, if you want to have asymmetric (cert based) validation of the Nodes, you need to have a root CA on every Gateway for every class of cert that might be presented. This can quickly overwhelm an IT group and require that the Gateway be complicated enough that the device move into the ‘Linux class’ (MPU based), in order to handle the computing and Cloud interaction elements. If you have 1000 Gateways and 20 different root CA certs that are valid at any given time, all 1000 Gateways need to synchronize with the master list of certs so that a Node can talk through any of the 1000 Gateways. Of course, there are tradeoffs that allow an embedded (MCU based) gateway to also act in this manner, but for sufficiently large fleets, the storage capabilities of the MCU may start to limit the number of devices that can be connected.

What about when the Gateway is an app?

The most common use case for Bluetooth devices is directly interacting with a mobile phone app. The idea of ‘roaming’ hardly ever enters the conversation. In this case, the idea of “Node communicating with the Cloud” is often skipped entirely and the App talks directly with a Bluetooth device and takes over all transmission of data up to the Cloud (when/if needed).

How it’s different with Golioth Connectivity and Pouch

Golioth Bluetooth Connectivity is built upon Pouch, our innovation that enables indirectly connected devices to talk to the Cloud and introduces end-to-end encryption of data from a Node to the Cloud. This also includes the associated Cloud-side tooling that makes it seamless to have those packets decrypted and assigned to the proper device record in Golioth. The Node device needs to be running the Pouch SDK; the packets sent from that device transit through Gateways that are also running a portion of the Pouch SDK and the Golioth Firmware SDK. We have precompiled binaries of our reference Gateway implementation on a board like the FRDM-RW612, which makes it very easy to create a group of Nodes and Gateways and see roaming in action.

Let’s talk about the same Node 123 (such as the Tikk board) talking through a Gateway ABC (FRDM-RW612). The device advertises that it has uplink data available, the Gateway (central) connects to the Node (peripheral), and the device certificate is presented through the Gateway up to the Cloud. After the device is authenticated onto the Cloud, the certificate is cached (on the Cloud), and the uplink/downlink data is able to flow. If you look at the hex dump of the uplink data on the Gateway, you’ll see…well nonsense! That’s because Node 123 is end-to-end encrypted with the Cloud, not with the Gateway. The Gateway has no way of decrypting the data passing through it.

Now Node 123 moves to a different location and it is again advertising that it’s ready for uplink. Gateway XYZ (thingy91x) is also running the Golioth Gateway reference implementation and connects to the Node. Once again the certificate is passed through the gateway up to the Cloud and validated. No allowlist or credential passing down to the Gateway is required because the Cloud is the ultimate arbiter, having the root CA that generated each device certificate. Want to learn more about certificates? Read our post about how certificate based security works or go use our brand new certificate generator on the Console to quickly try out the newly optimized workflow.

In the Golioth use case, a mobile phone app can also be a gateway, and one that still enables roaming. If the application is authenticated to talk to Golioth and also has access to the Bluetooth radio, the app can shuttle packets along in the same way that an MCU or MPU class device does. The difference is that the phone will not directly interact with data from the Bluetooth device, instead relying on accessing data from the Cloud or via an alternative channel, such as a separate GATT profile.

Roaming unlocked and simplified

Now that Node 123 can validate between Gateways ABC and XYZ, it’s easy to imagine how this could be expanded to more and more gateways, as happens in an asset tracker scenario. For super high value asset tracker scenarios, it’s conceivable that there are even more gateways to track movement than there are the nodes themselves!

Golioth’s Pouch SDK and reference gateway implementations make it easy to spool up a new application that hops between gateways and still sends data up and down to the Cloud, while still taking advantage of the low cost and low power nature of Bluetooth connectivity. Head over to the Golioth forum to ask more questions about how the technology works or to let us know what you’re building next.

Glossary

Let’s make sure we have a good definition of the terms we’re discussing here

1. Roaming – The ability for a device to send data through multiple points back to the Cloud
2. End-to-end encryption – An encryption scheme between Node and Cloud that no intermediary can ‘peer into’
3. Gateway – An embedded (MCU), Linux based (MPU), or app based (mobile) device that is allowed to bidirectionally shuttle data to and from the Cloud. Needs to have multiple radios in order to communicate with both Bluetooth devices and the Cloud (usually over Wi-Fi, Cellular, or Ethernet)
4. Node – A Bluetooth based device that has data to send to/from the Cloud