You may not fully understand the ins and outs of Bluetooth IoT applications, but I’d wager that you’re familiar with the underlying technology. Bluetooth connects a variety of headphones and speakers to smartphones and computers. It powers your wireless mouse and keyboard. It allows you to take calls through your car speakers, conveniently transfer files over short distances (e.g. with “AirDrop”), and more. Bluetooth “classic” was mostly about connecting you to a few everyday devices. The newer Bluetooth technologies powering IoT applications are more about connecting devices to other devices in massive “mesh” networks in domestic, urban, and industrial scenarios alike.
From Cables to Mesh: Bluetooth at a Glance
Bluetooth has come a very long way since Jaap Haartsen, an electrical engineer, invented the technology in 1994 while working for Ericsson in Lund, Sweden. He envisioned the technology as an alternative to the RS-232 data cables that since the 1960s had been the standard for connecting computer peripherals to PCs. Haartsen disrupted that standard by using short-wavelength UHF radio waves in the Industrial, Scientific, and Medical (ISM) band from 2.4 to 2.485 GHz to send small and simple data packets (“messages”) over short distances of a few meters.
In 1998, Haartsen played a key role in creating the Bluetooth Special Interest Group (SIG)—a standards-setting body like 3GPP and LoRa Alliance. The group has since taken on a life of its own as we’ve embedded Bluetooth technology into our everyday routines worldwide. Bluetooth will only continue to become more important as the SIG refines its industrial offerings: Bluetooth Low-Energy (BLE) and Bluetooth mesh (more on those shortly).
Using Bluetooth IoT Applications to Achieve Business Goals
When choosing one mode of connectivity over another—e.g. Bluetooth over LPWAN or NB-IoT over LTE-M—make sure first to first identify and articulate in clear terms the business objectives inspiring your IoT initiative.
So what are you trying to accomplish with IoT? What are the particularities of your business, your industry, your services, and the spaces in which you, your employees and your customers operate? Are you trying to track things or people indoors, outdoors, or across the boundary of the two? Will you have power readily available, or do the devices need to be battery-operated? Do you need to send small packets of data (e.g. open/close or simple active/inactive messages) over the network, or do you think you need to transmit large raw files like audio or images over the network? It’s critical to explore these questions—and many others there’s no room to mention here—before falling prey to the marketing hype around one mode of connectivity.
When Bluetooth Works Well
Maybe you’re trying to keep track of equipment, personnel, and patients as they weave through a hospital building. Properly-designed Bluetooth IoT applications are effective for such indoor asset tracking scenarios given the low-power requirements, theoretically infinite scalability, and self-healing reliability of emerging Bluetooth mesh networks. But the same Bluetooth solutions would be suboptimal for achieving other business goals.
[bctt tweet=”Well-designed @Bluetooth #IoT networks are effective for scenarios like indoor asset tracking. But #Bluetooth is no silver bullet. For example, 2.4GHz doesn’t work well under water. || #IoTforAll @mwedd91″ username=”iotforall”]
When Bluetooth Falls Short
Like all connectivity solutions, Bluetooth is no silver bullet. For example, it wouldn’t work well for tracking underwater assets in a harbor or on an oil rig. Bluetooth’s 2.4 GHz signals don’t penetrate water well. Bluetooth would also be a poor choice for security solutions that require visual, audio, or biometric information to be published through the network given the load such data types place on the network. We’ll dive into some of the important technical features of Bluetooth IoT applications below, but I first want to emphasize that the ultimate effectiveness of each mode of connectivity is intimately linked to how well the technical features of each mode align with three co-dependent factors:
- Your business goals
- The local spatial and environmental conditions
- The local radio and digital ecosystems in which you hope to achieve your goals
It all comes down to understanding your business goals, being conversational in the technical features of connectivity modes, and working with domain experts who can empathize with your business goals and help you make responsible decisions.
The Architecture of a Bluetooth IoT Application
To understand why recent shifts in Bluetooth standards are significant for IoT applications, we must first dive into the Bluetooth “stack.” The evolution of Bluetooth from a replacement for RS-232 data cables to a powerful and massive IoT connectivity solution is a story of adding new layers to the stack. Remember that a “stack” in this context essentially means the bottom-up layering of protocols, processes, and applications where each higher layer depends and builds upon the ones below it. The newest Bluetooth specification for IoT—Bluetooth mesh—must be engineered upon either the BLE 4.xx or 5.xx stack—an extension of the Bluetooth Core (“classic”) specification. The emerging Bluetooth mesh stack, therefore, comprises three stack layers: Core, then BLE, and mesh on top. Read the mesh stack diagram below from the bottom upward.
Bluetooth Topologies: Pair, Broadcast, Mesh
Over the past 24 years, Bluetooth has evolved to fit changing needs as follows:
- Point-to-point: Bluetooth as a means of pairing two devices
- Example: A computer paired with a wireless mouse
- One-to-many: Bluetooth as a means of having one device broadcast information to many devices or vice versa
- Example: Playing music on smart speakers and simultaneously casting photos to a projector—both using a single iPhone
- Many-to-many: Bluetooth as a way of connecting many devices to many others as if in a spider’s web
- Example: Connecting 1,278 overhead lights in a warehouse to each other to dim and brighten lights automatically based upon activity and personal preferences.
A Technical Evolution: BLE
Bluetooth Low-Energy (BLE), which launched in 2009, set the stage for future applications in IoT as the field was taking off. BLE is a specification targeting primarily small-scale IoT applications like wearables and broadcasting beacons that require devices to send small amounts of data using minimal power.
Bluetooth SIG made several changes to the Bluetooth Classic technology to make it less power hungry without compromising communication range—changes that will prove essential to Bluetooth IoT Applications. Increasing the modulation index and throttling load-intensive (and thus power-intensive) data types has enabled Bluetooth to lower power consumption by 95 to 99 percent (depending on the use case). Upgrading message encryption to 128-bit AES-CCM (government grade) was the final prerequisite to pivoting the BLE topology away from salesmen on their Bluetooth Classic earbuds and toward swarms of low-power nodes relaying simple messages across warehouses and smart homes alike.
I’ve highlighted some important shifts from Classic to BLE below:
Reading the above table, you’ll see that the number of active nodes was increased from seven to “unlimited.” And there’s the critical moment in the technology’s graduation from smaller, personal applications into massively scalable IoT solutions.
Bluetooth Mesh: From People to Things
Bluetooth SIG announced the “mesh specification” in 2017, standardizing the theoretically unlimited many-to-many features of BLE. Previous Bluetooth topologies were mainly about an interface between people and things. Although the end goal is still amplifying human potential, the mesh topology is fundamentally about how things communicate with each other at scale. It’s about many devices talking to many other devices.
The mesh topology has a number of new features that make it effective for certain IoT applications.
Omnidirectionality, Modularity, and Healing
In a mesh network, all nodes function as transmitters, relays, and receivers. From its origin, a given message dances from node to node omnidirectionally rather than linearly. Imagine a spider web instead of a highway. The topology thus eliminates the problem of gateway failures knocking out dependent sensor clusters since the mesh automatically “self-heals” by pushing messages around dead nodes. Areas of a mesh network can also be added or removed with little trouble beyond provisioning and state configuration. The topology is thus not only robust but also modular.
A Managed Flood of Messages
Many of the features that make Bluetooth mesh a robust topology stem from Bluetooth SIG’s refinement of the “flooding” technique. Flooding is similar to the way the internet works. When a given mesh node publishes data, it does so by “flooding” all nodes that are in direct range. Those nodes in turn flood all the nodes within their reach, and so on. And since only explicitly addressed or “subscribed” nodes act upon the data that passes through them, you can leverage every device as a relay—not just gateways. While flooding may sound inefficient, it allows for sleek hardware design, simple command execution, and short “hops” between nodes—efficiencies that translate directly into low power consumption, low unit cost, and scalability.
“Managed flooding” is a refinement of the flooding used in BLE pseudo-meshes. It enables standardized mesh networks to operate more effectively in scalable Bluetooth IoT applications. Managed flooding refers to the unique combination of several of the mesh topology’s technical features:
- Each mesh node periodically emits “heartbeats” to alert nearby nodes that it’s active and ready to convey messages.
- Nodes receiving a given heartbeat are able to calculate the distance from the heartbeat’s origin. Knowing the interval allows the network to conserve energy by choosing optimal Time-to-Live (TTL) values for messages when you constrain the number of “hops” you want messages to take through the mesh.
- Meshes can be partitioned into “subnets” that parse the flood of messages into distinct network areas, thereby conserving energy while adding only minimal dimensional complexity to the topology.
- Each node caches each message that passes through it, so when messages flood over the node, it knows to discard rather than relay any message that its cache contains. Caching enables the node to “manage” the flood while keeping the circuitry simple and conserving energy.
Friendship and Proxies
I’ve saved two of the more interesting features for last. “Friendship” is a neat feature of the new mesh topology that allows it further to manage the flood of messages while also conserving energy. You can provision some devices to be low power nodes (LPNs) and others to be their “friend.” The friend is usually not power-constrained (i.e. it’s connected to the energy grid rather than batteries). Without power limitations, the friend node listens voraciously and queues up messages addressed to the LPN like a voicemail box while the LPN keeps its receiver off to conserve power. When the LPN awakes periodically, it can ask the friend whether it has messages in store, flip on the receiver, and have the friend node send the entire queue in a burst before the LPN goes back to sleep. This allows solutions providers to utilize the benefits of the broadcast Bluetooth topology but within a flexible mesh framework, tailoring the final outcome to the use case’s specific data and power requirements.
The last exciting feature of the mesh topology is that it can interface with and include Bluetooth devices without a mesh stack. Older BLE-compatible devices include the billions of smartphones sold since BLE launched in 2009. The benefits of being able to interact with a mesh network using older tech should be clear.
Recall that the mesh stack is layered on top of the BLE stack. And consider that all BLE devices have a Generic Attributes (GATT) profile. If you provision a mesh node as a proxy, it will expose a GATT interface through which any BLE device can “join” the mesh network and interact with its nodes. In sum, mesh’s Proxy Protocol makes it backward compatible.
A Hybrid Future for Mesh?
Although it’s clear that mesh represents a significant and powerful step for Bluetooth, I’ll reiterate that we mustn’t fall prey to all the hype and exciting features. Ground yourself again in your business goals. Is Bluetooth mesh the right fit for your IoT initiative? Thankfully, you don’t really have to decide, because the future of Bluetooth may involve hybrid connectivity.
When Ericsson has an idea related to Bluetooth, we should listen because as you’ll recall, Haartsen pioneered Bluetooth at the company. Ericsson thinks the true power of mesh networks might lie in the Proxy Protocol. More specifically, that power could stem from multimodal, BLE-enabled devices that function as “capillary gateways” to other modes of connectivity, e.g. cellular. The result would effectively be a hybrid core network. Rather than mesh networks remaining discrete and isolated, such hybrid networks would be even more adaptable, modular, and scalable.
The presence of capillary gateways such as smartphones and/or proxy nodes that support both Bluetooth and cellular connectivity in the mesh area network extends the accessibility of extremely low-power, storage and memory constrained devices into the core network up and to the cloud. — Ericsson
And why shouldn’t the future be hybrid when the use case calls for it? Ultimately, some use cases will be best served by a single mode of connectivity, but others may benefit from creatively combining multiple modes to increase reliability, robustness, and utility.
The first step is always the same: define business goals, work out the intricacies of your use case, and develop a solution to match from the ground up. That being said, I wonder why some people think diverse and hybrid use cases—e.g. tracking an asset both indoors and outdoors—can be served by one mode of connectivity or another. The world is messy and hybrid. Our networks may need to reflect some of that hybridity in order to solve the underlying problem.