As the producer behind software conference QCon, C4Media regularly collects feedback from attendees to improve the quality of conference content. They came to ThoughtWorks with an exciting challenge: How could they use custom hardware to collect more meaningful feedback in real-time?
Our solution: a large number of interactive wearable devices, connected via a self-healing Bluetooth mesh network. Using Bluetooth gave us fast, flexible, and reliable collection of data in a complex conference environment.
Since the typical use case of Bluetooth involves one-to-one device pairing—such as an external audio speaker paired with your phone—the groundwork for building a stable mesh containing multiple devices has not been standardized across the industry. This led our team to experiment with various mesh algorithms and Bluetooth connectivity protocols during this project.
This series of articles details what we learned while developing our mesh product for C4Media. This first article focuses on the basics of Bluetooth. How exactly does it work? What do we mean by a “mesh network”, and how can we use the built-in features and connection protocols of Bluetooth to create a mesh?
The basics of Bluetooth connections
One key component of the Bluetooth protocol stack is GAP, or the Generic Access Profile. GAP governs how Bluetooth devices scan, advertise, and connect to their peers. It also defines specific roles that devices perform during this process. A single GAP connection is comprised of a central device and a peripheral device. The role of the central device is to scan for compatible peripherals and to initiate a connection with a chosen target; the role of the peripheral device is to advertise itself to any nearby centrals and to accept incoming connection requests.
This dynamic resembles a “parent-child” relationship; the central device acts as the parent, determining which child (peripheral) to connect to. This extra responsibility means that central devices typically require slightly more processing power than peripherals, which is why you will usually encounter smartphones and laptops playing the central role in a connection, and simple sensors or beacons playing the peripheral role. Every device must play one of these two roles when connecting to a peer, and every peer-to-peer connection must include one central and one peripheral. In other words, there is no such thing as a central-to-central or peripheral-to-peripheral connection.
The GAP protocol also defines some additional roles (“broadcaster” and “observer”), which are utilized when no direct connection is desired between devices. Due to various requirements of our application—data security and privacy, real-time tracking of device states, etc.—we chose to use the connectable “central” and “peripheral” roles, and will be concentrating on their features and usage for the rest of this article series.
The first release of Bluetooth Low Energy (also known as BLE, or Bluetooth 4.0) imposed the restriction that an individual device could perform only one GAP role at any given time. A device may act as either a central or a peripheral, but not both. Despite this restriction, multiple connections are still possible because a central device may connect to as many as 7 peripherals at once.
The peripherals can communicate with each other through the central if desired, forming a small network of responsive devices. Still, this cluster of devices is isolated. Aside from adding more peripherals until the maximum is reached, no additional connection branches are possible and clusters are unable to connect to one another. This severely limits the possible complexity of connection topographies.
What is a mesh?
Starting with Bluetooth 4.1, however, devices gained the ability to act as both a central and a peripheral simultaneously. For example, a single device could perform the central GAP role and connect to a wireless speaker, while also performing the peripheral GAP role and accepting an incoming connection from a smartphone. A side benefit of the above example is that the wireless speaker and smartphone can now communicate with each other through the intermediary device, despite not sharing a direct connection with each other.
The ability to directly or indirectly connect any number of Bluetooth-capable devices enables the construction of much more elaborate networks, such as mesh networks. A mesh network, for our purposes, consists of two or more Bluetooth-connected devices such that there exists a connection pathway between any two devices in the network. A specific device in the network may or may not have a direct connection to another networked device, but is able to successfully send targeted data via the other members of the network.
One primary benefit of mesh networks, particularly for Bluetooth, is that they significantly extend the physical range over which devices can communicate with one another. The normal range of a Bluetooth connection (using Class 2 devices, which applies to the majority of consumer applications) is around 10 meters. A device must be at least this close to one of its peers in order to maintain a connection and share data.
Meshes, however, can easily bypass this range limitation and facilitate communication over potentially unlimited distances. As long as every device in the network is within physical range of one or more peers, machines that are miles apart can still exchange information via the mesh.
Another advantage of using Bluetooth mesh networks is the ability to share data among a much larger group of devices. We are no longer limited to the single-cluster configuration of one central and seven peripherals; every device in the cluster is able to create its own additional cluster(s) with other devices, bringing them into the mesh. Ultimately a potentially infinite number of Bluetooth devices connected via mesh topology could be monitored by a single central device, like your smartphone.
How to mesh
Now that we know what a mesh is, how do we create one? One of the simplest and most obvious ways to generate a mesh is to allow every device to simultaneously scan as a central and advertise as a peripheral.
We call the result of this particular algorithm a conforming mesh, because each member is interchangeable. This strategy is ideal if you are working with a collection of similar or identical devices, each with enough processing power to act as centrals.
When a device receives an advertisement and responds to it with a connection attempt, it will perform the central role for that connection. When it receives an incoming connection request from another device, it will perform the peripheral role for that connection. Any device that performs these two roles simultaneously can act as a bridge between clusters. When each device is capable of (a) joining a cluster of peers and (b) participating in multiple clusters at once, all devices within range are easily able to construct a mesh.
Conforming meshes have several benefits over other mesh algorithms: they are incredibly flexible, relatively easy to code, and can result in a variety of topologies. However, you can still construct a mesh that includes devices that are restricted to single GAP roles.
The next article will explore some of the pain points we discovered with the conforming mesh structure, and the various iterations and improvements we made to our mesh algorithm as a result. And if you've had enough theory and want to see the code, our mesh framework is now open source! Visit our repo here.