Introducing Project Golden Gate

An open-source framework to connect wearables and other IoT devices to mobile phones, tablets and PCs with an IP-based protocol stack over Bluetooth Low Energy

TL;DR

If you wished your wearable or IoT devices and mobile applications could communicate over Bluetooth Low Energy as seamlessly, securely, and reliably as if they were on an IP network, using familiar internet protocols rather than low level APIs, this open-source cross platform project is the missing link that can get you there.

Ubiquitous Bluetooth Low Energy

At Fitbit, we have been transferring data back and forth between wearable devices and mobile phones for years leveraging Bluetooth Low Energy (a.k.a. BLE). BLE is a great base technology for our purposes. It allows low-power, short distance, bi-directional communication with a reasonable throughput. But that’s not what we like the most about it. Its best asset, bar none, is that it is essentially ubiquitous. You’d be hard-pressed to find a mobile phone, tablet or laptop today that doesn’t come with built-in BLE support. That means that we can ship our devices with a BLE radio and communication stack and know that they will be able to connect to our mobile app running on any mobile phone, tablet or laptop sold in the past few years. However, support for BLE, and our usage of it, looks very different now from what it did when we started working with it.

Our First Generation Stack

Supporting BLE in mobile apps isn’t always a walk in the park. In aprevious blog post, we’ve talked about some of the issues we’ve faced, the work we’ve done to work around them, and why we released an open-source library to help others facing the same issues. That was just the start. The challenge of using and supporting BLE connections between devices and mobile apps at scale, across many different models, is much broader in scope. In our early days, all we needed to exchange between our trackers and our mobile app was limited to not much more than some steps counts, device logs, configuration data and the occasional firmware update. That’s something we could reasonably support with a simple ad-hoc exchange protocol. By the time we shipped our first smart watch, the Fitbit Ionic, in the fall of 2017, things had evolved a lot. By then, the complexity of our communication needs had grown considerably, with dozens of data types, messages, payloads, both realtime and bulk, that needed to be shuttled between our mobile app and our devices. Between on-device sensor and activity data, application data, WiFi configuration, bi-directional file transfers, GPS data and more, we found ourselves clearly at the end of what we could achieve with our first generation protocol, and with a vision of where we wanted to go next. We knew we needed to add support for messaging for apps that were being developed for our platform, had plans to add voice features for future devices, as well as many more new features and functionality in the works. So we took some time and looked for a model that would get us there.

What We Needed Next

At a high level, our requirements were reasonably easy to articulate: we needed a protocol that would support security (data encryption and signing for privacy and integrity), multiplexing (many subsystems communicating at the same time without interrupting each other), reliability (our devices strive to be constantly connected when in range), with a programming model that would feel familiar to both embedded and mobile developers. The protocol would need to be robust enough that we could support tens of millions of users with very different environments, yet simple enough that we could implement it on very small footprint embedded systems (we’re talking about a few kilobytes of RAM and flash here on low power MCUs). Well, as it turns out, we didn’t need to reinvent the wheel. Those are more or less the same requirements that every internet-connected system has today. Protocol stacks with HTTP, WebSockets, CoAP, TLS, TCP/IP are what billions of connected devices use today to talk to each other and communicate with the cloud in this same manner. So it became clear to us that if we could find a way to embrace that model, rather than create a parallel proprietary solution, we’d have a strong solution. Our work, then, was to pick the right subset and profiles from the available “internet standards” and figure out how to make them work within the constraints of our ecosystem. That meant that we needed to create and maintain an implementation of those standards that we could run on various RTOS (Real Time Operating Systems) as well as mobile and desktop operating systems, including iOS, macOS, Android and Windows. Furthermore, we needed to be able to transport all that protocol data over BLE (while BLE isn’t the only link we support, it is clearly a must-have for us).

BLE’s Additional Challenge

As we just mentioned, IoT devices communicating over low power radios with an IP-based stack isn’t anything new. For example, Nest thermostats and smoke alarms use a similar approach to networking, using the IP-based Thread protocol over 802.15.4 radio networks . The additional challenge here is that we want our systems to work with BLE, because it is supported by almost all mobile phones. Technologies like WiFi are also supported, but are too power-hungry for an always-on connection on a battery-powered wearable device. And while 802.15.4 is also a low-power technology, it isn’t natively supported by mobile phones.

The Bluetooth standard does, in theory, support IP communication, with the IPSP profile . But, when you write a mobile application for iOS or Android, the only thing that really counts is whether the operating system on which you run implements the features that you need, and what APIs are available to access those features. IPSP isn’t offered on iOS or Android, so, unfortunately, we can’t use it. What is available across the board to communicate over BLE is GATT ( Generic Attributes Generic Attribute Profile ). In a nutshell, GATT gives you the ability to read/write/notify small values (up to 512 bytes) across a connection. And the reliability of communicating over GATT is a mixed bag, especially when considering the realities of how different Bluetooth stacks behave across radio chipsets, RTOS and mobile operating systems. So we needed to come up with some way to bridge that gap. What we ended up with is a simple, reliable, windowed, streaming protocol that is optimized to run well over GATT. We simply call it “Gattlink.” That link layer is what completes our network stack.

Introducing Golden Gate

Golden Gate is the name we choose for this project, our second generation communications framework. It includes a complete networking stack, starting with CoAP (Constrained Application Protocol) at the application layer, to DTLS, UDP/IP in the middle layers, to Gattlink and BLE GATT at the bottom layers. The implementation is entirely cross-platform; it runs on several flavors of RTOS, iOS, Android, macOS, Windows and Linux. It has been our standard framework since September 2019 when we launched Versa 2, which runs Fitbit OS 4. Now that we’re confident that it works great in the field, we decided it was time to share what we’ve implemented. While our products are packed with unique innovations that are tailored to our requirements, focused on health and fitness, the underlying communications stack is, by design, generic in nature. We think that our design and implementation can be used for a large number of IoT and mobile use cases, where reliable, secure, IP-based protocols offer a familiar model for developers to use, allowing them to focus on the features of their own devices and apps, rather than the underlying protocol stack. We hope that many of you, whether engineers building commercial products, hobbyists or students, will find what we’re sharing useful, and that some of you may even choose to contribute back to the project and help improve it as it evolves. We’d love to see our code adopted and used in ways we haven’t yet dreamed of, ported to other platforms, chipsets and operating systems.

We chose the name Golden Gate, because it is the name of the famous International Orange ( #F04A00 ) colored bridge in our beloved city of San Francisco, where Fitbit’s headquarters are located, and naming the project after a bridge seemed befitting a framework whose goal is to connect things. We hope you’ll like the name too.

How To Get Started

To find out more, and maybe start experimenting and developing with the code, visit our GitHub project . Please let us know what you think, and help us make it better with any feedback you may have, or even contributions.

About the Author

Gilles Boccon-Gibod – Engineering Fellow

Gilles has been with Fitbit engineering for over 3 years where he has worked on various projects, including music services and the Fitbit Developer Platform. Most recently, he worked with the cross-functional team that has developed and integrated our new comms stack. When he’s not busy with his day job, he enjoys cooking international cuisine and sailing his Hobie Cat in the San Francisco bay.