Based on a solution just announced by CSR (now part of Qualcomm), you can outfit your new building with lights – and your network will be in place.
OK, they’re not positioning it to replace your Ethernet plant, perhaps, but it could become part of the network. They do this by making each LED lightbulb fixture also a Bluetooth mesh node. In case you missed the news early last year and are objecting that Bluetooth doesn’t have a meshing feature, you’re right – the standard doesn’t. CSR has overlaid the capability in a proprietary offering.
The lighting solution they’re announcing now provides both Bluetooth beacons – supported by the standard – and meshing. They set up and manage the beacons using the mesh; once up and running, the beacons operate independently of the mesh.
But this does raise some questions – especially as Greenpeak founder and CEO Cees Links questioned Bluetooth mesh latency in a conversation we had at Imec’s ITF in Brussels early this summer. The point being that, you might be able to create a mesh, but would it have characteristics that make it useful? Apparently folks tried to mesh WiFi at some point… and that has not become a thing. A reasonable question…
So I asked CSR for some more detail on their latency. And this resulted in a broader explanation of how they handle meshing.
They do what they call “flood meshing” instead of routed meshing. In other words, they start a message going and it follows all routes until a time-to-live flag expires, indicating that a particular trajectory has involved too many hops and should just stop. Presumably, at least one route will take the message to its intended receiver. Nodes keep track of messages they’ve received so that the flood doesn’t reverse.
This is actually more nuanced than it sounds. For power reduction purposes, each node in the mesh wakes up occasionally to see if there’s any message. This means that, at any given time, some number of the nodes in the mesh will be asleep and miss the message. So this flood doesn’t actually cover all nodes – just the ones that happen to be awake at the right time.
To increase the likelihood that nodes can pick up the message and run with it, each node advertises the message on 3 channels 6 times. You can ask for an acknowledgment, but it’s not required. The design of the mesh and the specific timing have to balance the likelihood of at least one node listening at any given time against the power required to listen. Obviously, the denser the network, the better your chances of your message propagating.
A network is protected by an overall network key, keeping networks from leaking information into each other (presumably). A network is also a virtual entity overlying the specific devices – meaning that an individual light bulb, in this case, could participate in more than one network.
And as to that original latency question, best-case single-hop latency is around 15 ms. From a quick check on my part, this doesn’t seem too different from Zigbee. They’re a bit hard to compare directly, since Zigbee uses routed meshing, and may need to request a route before sending a message – which adds to the latency for such instances (routing tables presumably make that necessary only for new destinations). But delivery in the range of 15-100 ms or so doesn’t seem unreasonable for either one.
You can read more about their lighting solution, done in conjunction with SK Telecom, in their announcement.
