“You need to be careful with a Bluetooth headset, because some guys look crazy with them.” – Neil Strauss
If you shout “Bluetooth!” in a crowded theater, most people will think, “earpiece,” or “car phone,” or “Danish king with iffy dental work.” Or they’ll just think you’re a nerd. But few will think, “hmmm… mesh networking.”
That’s because “Bluetooth” and “mesh” didn’t fit together in the same sentence until a couple of weeks ago. But on July 13, the Bluetooth SIG announced its official support for a mesh-ified version of the ubiquitous wireless standard. Now, Bluetooth connections can frustrate a whole new class of users.
The short-range wireless interface with the funny name, the insanely complex software stack, and the reliable ability to confound users who just want to talk and drive at the same time (“Is that a crime?” Actually, yes) is now coming to the Internet of Things. And Silicon Labs is leading the charge.
First, some background. Bluetooth has always been monogamous. That is, it’s a one-to-one connection. Pair your cellphone with a Bluetooth earpiece and that earpiece (and your phone) are semi-permanently joined, disappearing from the Bluetooth dating pool until such time as their bonds are rent asunder. Your expensive Bluetooth speaker can blare tunes from only one iPhone (a nuisance at parties), and your car can talk to only one passenger’s Bluetooth-enabled phone at a time (a nuisance for mobile families).
The “sticky” nature of Bluetooth pairing leads to hilarious/embarrassing moments, like standing outside your car talking to the dashboard through the window.
Bluetooth has been through many revisions, but the one-to-one nature has been inviolate. Bluetooth Mesh aims to change that. Now, you can use Bluetooth in your consumer, industrial, or sensor network. The number of participating nodes is essentially infinite (in the hundreds, anyway), and nodes can join or drop off the network at will. It’s like ZigBee or Thread or Z-Wave, but with all the goodness of Bluetooth!
For most practical purposes, Bluetooth Mesh is an entirely different and separate network from “normal” Bluetooth. Your earpiece and your Android phone (and your car) won’t suddenly join the new mesh topology. Apart from some levels of the protocol stack – and the branding – Bluetooth Mesh is essentially a brand-new interface that’s incompatible with anything else. That’s fine; most new wireless standards are incompatible with the rest of the world when they’re introduced. So was the original Bluetooth, and it seemed to do okay.
Although it uses a mesh topology, Bluetooth Mesh is fundamentally different from most other meshes like ZigBee or Thread. Those both use the IEEE 802.15.4 standard for routing packets. Bluetooth Mesh, on the other hand, relies on the much simpler technique of “network flooding.” In short, each node simply rebroadcasts every packet it receives, hoping (correctly) that the message will eventually find its way to its destination. Nodes don’t have to think very hard about where, when, or how to rebroadcast packets. They just repeat what they’ve heard and go back to sleep.
Network flooding has the advantage of simplicity. It also tolerates nodes that go dormant periodically and don’t always participate in the rebroadcast. That means Bluetooth Mesh networks might have a constantly changing cast of characters, some broadcasting, some receiving, some repeating messages to their neighbors, and some doing nothing at all. There are no fixed routing tables, and no guarantees of minimum or maximum latency. Every node makes its best effort (if it’s awake) and calls it a day.
Flooding sounds like an elegantly simple idea, but it requires some careful safeguards. As Albert Einstein is reported to have said, “Everything should be made as simple as possible, but not simpler.” Mindless repetition can get mesh networks into trouble. If your nodes are placed in just the wrong way, messages can repeat forever as packets circle endlessly around and around without end.
Bluetooth Mesh solves this problem with a simple expediency of a time-to-live (TTL) counter. Each new message is born with a TTL counter embedded in its packet, which is decremented each time the packet is retransmitted. If a node receives a packet with a TTL=1, it stops there, having exhausted its useful life. The theory is that TTL will be initially set high enough to cover the worst possible routing outcome, but no higher. This minimizes the amount of wasted rebroadcasting and prevents deathless zombie packets from circulating forever.
There’s also a danger of creating an echo chamber, as nodes repeat messages that they themselves just rebroadcast. A message cache avoids this problem. Nodes check each incoming message ID against a small cache of recently received messages, and don’t rebroadcast anything they just saw. As long as the lifespan of the cache is longer than the worst-case routing time of the overall network, you’re fine.
Flooding also wastes bandwidth, almost by design, since each packet will probably be broadcast to other nodes that don’t need to hear it. And once a packet reaches its intended destination, it doesn’t automatically die. Other nodes will continue to forward it, unaware that their job is already done. This is more of a problem for heavily trafficked networks that need to keep their airspace (or network channel) clear. But Bluetooth Mesh is intended for lightly used networks where a few stray packets rattling around here and there aren’t a problem. It has short, 11-byte packets and is intended for low-power, low-data-rate networks with lots of sleeping nodes. Think sensor networks, not auditoriums with massive wireless speaker clusters.
So where does Silicon Labs fit into all this? As the company name might suggest, it’s providing… software. The company’s Blue Gecko and Mighty Gecko MCU families already support Bluetooth hardware. What’s needed is an entirely new software stack so that these chips can participate in Bluetooth Mesh networks. And that’s what Silicon Labs is providing. Starting now, the company is rolling out development software, test boards, packet-analysis tools, pre-compiled demos, and an Android app to give it all a friendly face.
Silicon Labs’ software is a good and necessary start. When Bluetooth first appeared in the mid-90s, a lot of programmers were surprised by how complex the software was. Bluetooth Mesh won’t be any easier, so any head-start the company can provide will be welcome. And if the code helps to sell a few extra chips, so much the better.
But getting Bluetooth Mesh to work is one thing; getting it to be useful is another. The Bluetooth SIG is also working on application-level standards that all manufacturers will follow so that all Bluetooth Mesh–enabled devices are interoperable. A wireless light switch should work with anybody’s light bulbs; a temperature sensor should talk to any thermostat; and so on. And that’s a very big undertaking. Imagine trying to define all the possible capabilities, characteristics, and interface needs for devices that won’t be invented for another 10 years. And then document them in a written specification. And get all the manufacturers to agree and follow it. Bigger projects than that have succeeded, but I don’t envy the committee members working on it.
In the meantime, Silicon Labs has chips, boards, and software ready to go. So get out there and make some… networked things.
