Mesh Networks, Redux

It isn’t hard to understand the advantage of mesh networking (in wireless networks). Unlike star/tree configurations in which end-points connect to a nearby hub (such as phones connecting to a conventional wireless access point), in a mesh nodes can connect to nearest neighbors, which can connect to their nearest neighbors and so on, therefore allowing for multiple possible paths to route data to a target device. Important characteristics of this approach are (in theory) reliability and lower maintenance cost. If some node in the network fails, communication can automatically route around the failure until the bad node is repaired or replaced.

Investment in this area has focused strongly on Wi-Fi, for example the solution supported by Google Home, and the Zigbee and Thread standards. Clearly these have seen some traction but there’s an obvious question – if mesh is so great, why aren’t we seeing it everywhere? Apparently the standards aren’t quite standard enough to ensure full interoperability between solutions from different vendors. So your phone, fitness tracker, thermostat, smart speaker and laptop may not collaborate seamlessly in that mesh. More annoyingly, they may appear to collaborate but fail from time to time in mysterious ways. So much for reliability and low maintenance.

A better solution has to start from a better standard which closes off any wiggle room for incompatibilities. Which is where Bluetooth gets interesting. Incidentally, I’m coming to view Bluetooth as the stealth technology of wireless communication. Just a humble little capability to connect your phone to earbuds and your car infotainment center, right? Then we got Bluetooth Low Energy (BLE) which now looks pretty interesting for many IoT edge nodes. Then the standard added broadcasting for indoor beacons, and more recently we got Bluetooth mesh, a capability defined to fix the interoperability problem. Not such a junior partner in communications anymore.

BT mesh defines a full-stack all the way from the low-level radio up to the application layer, eliminating wiggle-room; every solution built on BT Mesh should be interoperable. Also mesh requires that a device adopt and stay with a mesh model (similar to BT profiles); once a model for behavior of a node in a network is adopted it can never change. So for example, a BT mesh light switch purchased this year should be able to control a BT mesh light bulb purchased 30 years from now.

Mesh is supported through a software stack on top of BLE, so adding mesh support is just a software upgrade on top of BLE. Therefore your smartphone should be able to join a BT mesh and therefore be able to control any mesh device (given appropriate privileges). It’s less clear that this is in the roadmap for ZigBee-enabled devices.

Since BT mesh is built on BLE, it is naturally aligned with low-energy usage. In a mesh network, it may seem like this is no better than a theoretical advantage; all that peer-to-peer communication will neutralize any advantage in BLE, surely? The standards group thought of that, allowing for different classes of node in a mesh. A low-power node can operate on a low duty-cycle and on wake-up can poll an identified Friend node rather than having to broadcast to find a nearby node. A Friend node will also buffer messages addressed to its low-power friend and will forward when that node wakes up.

Friend nodes and Relay nodes will commonly be served by main power, so are not as constrained in power usage, though still quite power efficient thanks to BLE. So mesh really can be low-power friendly. Mesh is also designed to be very secure, providing end-to-end government-grade security from the sender to the target application. Even though other nodes in the mesh are receiving and retransmitting messages, they can’t read those messages. And finally, all of this builds on a long-established and widely-deployed technology (Bluetooth), minimizing adoption problems, need for major upgrades and maintenance.

What are the primary use models? Definitely in-building applications, such as controlling lighting, heating or window shades in a smart home or office or factory. Even more interesting is use for location services, especially indoors; this is where beacons become popular. We’ve already seen promos showing how we could find a store in a mall or products in a supermarket (that can’t come soon enough for me). The same technology can help track assets in a factory, patients and medical equipment in a hospital or concession stands in a stadium. The range of (non-mesh) BLE is already quite good; mesh extends that even further. There’s interest now in mesh to enable smart-city functions.

All of this sounds good, but what’s the ground reality? I’m told by Paddy McWilliams (Eng Dir at CEVA) and Franz Dugand (Sales and Mktg Dir, Connectivity, at CEVA) that in China the battle is pretty much over. Alibaba for example has specified that, of the mesh standards, they are going with BT mesh. Others in China are apparently coming to similar conclusions. In one case I heard of, after carefully comparing ZigBee and talking to customers, a services provider told their product makers they expected BT mesh support (perhaps Alibaba’s choice had something to do with that). Curiously the US and EU seem to behind in adoption at present, but China is a huge market. It seems unlikely we can simply ignore their direction.

CEVA has been active and very successful in Bluetooth for a long time. They already have a mesh stack which will run on top of their BLE4.2 and BLE5 IPs, so you probably should check them out when you’re thinking about how you can get in on this action.