On Tuesday the Bluetooth Special Interest Group (SIG) released the long-awaited Bluetooth Mesh specification, a technology rumored to disrupt smart lighting, smart home, smart retail, and building automation networks for some time.

Version 1.0 of the Bluetooth Mesh specification is somewhat of an optional “profile” based on the LE 1M PHY (physical layer) and three advertising channels of Bluetooth 4.0 (Figure 1). However, support for the 1M PHY is mandatory in all subsequent Bluetooth specifications, making Bluetooth Mesh compatible with all Bluetooth 4.0 or later-compliant devices. This enables the creation of interoperable mesh networks comprised of Bluetooth 4.0, Bluetooth 4.2, and even Bluetooth 5.0 nodes.

[Figure 1 | Bluetooth Mesh technology utilizes three advertising channels to minimize 2.4 GHz spectrum interference.]

Although the Bluetooth Mesh working group continues to investigate ways the technology can utilize more advanced features, such as those of Bluetooth 5, the most important revelation of the Bluetooth Mesh specification is the architecture of the mesh network itself. Bluetooth Mesh employs a “managed flooding” topology in which packets are broadcast to all nodes on a network. This is in contrast to the routing topology used by technologies like zigbee.

Flooding versus routing mesh networks: Advantages and disadvantages

Just like it sounds, data packets in a flooding mesh are indiscriminately broadcast to every node on the network. While this approach doesn’t inherently provide optimized message management, latency, or power efficiency, it does make software development and ad hoc network deployment and recovery much more simple than with the alternative.

That alternative is a routing network, which relies on routing tables installed on each node that contain information about the optimum relay path for passing messages across a mesh network to specific nodes. Although this enables more precise control over data transfer, network bandwidth utilization, and power consumption, it also requires additional RAM on each node. Routing tables must also be updated when there is a change in the network (such as a node failure) to ensure that packets reach their destination through an alternate relay path, which can add significant overhead.

While both architectures provide bi-directional communications and rely on a hub or gateway for TCP/IP conversion and Internet connectivity, the flooding topology of Bluetooth Mesh favors ease of use over optimization. “This first version of the Mesh spec was focused on enabling the lighting market, and lighting nodes are typically mains powered,” says Lee Ratliff, Principal Analyst for Connectivity and IoT at IHS Technology. “They may have traded some efficiency for a speedier time to market. Routed mesh architectures are very complicated and would probably have taken much more time.”

It remains to be seen how reduced control in Bluetooth Mesh will impact the performance of larger scale deployments, although Mikko Savolainen, Senior Marketing Manager at Silicon Labs notes that “the routing approach has not been abandoned.”

“The Bluetooth Mesh working group will continue to develop the technology during 2017, 2018, and beyond to meet new market requirements,” Savolainen says. “A routing feature is one of those items.”

Range, power efficiency, and getting by with a little help from “friends”

The basic concept of a mesh network is that messages are relayed from node to node across a network, theoretically extending the transmit range of an individual device through a series of handoffs. As Bluetooth Mesh is more of an optional profile for Bluetooth 4.0 and later devices, “the fundamental [transmit] characteristics of the node are dictated by the base spec they were designed for, not the mesh spec. Mesh will work with whatever capabilities the node has as long as it is not prior to Bluetooth version 4.0,” Ratliff says.

A number of factors contribute to the transmit range of nodes on a mesh network (or any network, for that matter), including the transmit (TX) power, receive (RX) sensitivity, and antenna efficiency of the devices involved, as well as path loss incurred in the deployment environment. Calculating the range of Bluetooth Mesh network nodes isn’t straightforward as a result, but a line-of-sight benchmark based on the Silicon Labs EFR32BG12 Blue Gecko radios is provided in Figure 2.

[Figure 2 | Several factors contribute to the range of nodes on a Bluetooth Mesh network, including TX power, RX sensitivity, antenna efficiency, and link budget. The estimated range between two Silicon Labs EFR32BG12 Blue Gecko radios is shown here, assuming designs with -5 dB antenna loss placed 1.5 meters above the ground.]

As line of sight tends to be a theoretical variable in mesh deployments, Figure 3 shows the practical range of a EFR32BG12-based Bluetooth Mesh node transmitting at +10 dBm TX to another with a -95 dBm RX sensitivity in Silicon Labs Finland offices. The yellow line represents the indoor range using the 1M PHY currently leveraged by Bluetooth Mesh.

[Figure 3 | The yellow line here represents the indoor range of an EFR32BG12 to EFR32BG12 Bluetooth Mesh network using the 1M PHY. Other colors indicate the device’s range using 2M and 125K (Bluetooth 5) PHYs, which are not currently supported by the Bluetooth Mesh specification.]

Of course, range also has a direct correlation with power consumption and efficiency, which, as mentioned previously, is one of the challenges in the Bluetooth Mesh flooding architecture. Indeed, Ratliff points out that “the biggest problem with most flooded mesh networks is that it is hard to achieve low power performance if every node is required to relay every packet, [not] allowing them to sleep.”

Savolainen predicts that the typical TX/RX power consumption of Bluetooth Mesh network nodes will be on the order of 5 mA to 10 mA despite the fact that most of them will probably spend 95 percent of their time in RX mode and only 5 percent in TX mode (depending on network traffic). Given the target applications for mesh networking, this is not exactly “low power.”

To offset some of the power inefficiency incurred by the flooding topology, the Bluetooth Mesh specification allows for packet transfer to be managed through the use of “friend” nodes that collect messages for sleeping nodes.

While the implementation of these nodes is not defined by the Bluetooth Mesh specification, friend nodes contain additional RAM that allows them to buffer received messages and relay them on to their sleeping counterparts later. This allows one or more network nodes to remain in a low power state for longer. Providing an example, Savolainen references a hypothetical scenario in which a friend node equipped with 16 kB RAM can store up to twenty 33-byte messages for 24 low-power sleeping nodes. Once the buffer is full, the oldest messages are simply dropped.

Still, the Bluetooth Mesh working group appears to be betting that the nodes in most lighting applications will be mains powered, making the use of friend nodes more applicable in emerging use cases or with later versions of the specification that target systems powerd by coin cells or energy harvesting.

Bluetooth Mesh: Taking the next step without the tradeoffs

As discussed, there are gives and gets associated with the first iteration of the Bluetooth Mesh specification. In its current form it is best suited for large lighting installations such as malls, warehouses, and office buildings that don’t require low-latency, uniform response, but overall it’s a step in the right direction. It will bring more visibility to the mesh networking space, and perhaps drive innovations from competing standards that hope to maintain market share.

Fortunately for developers, multi-protocol silicon is available that support Bluetooth, zigbee, Thread, and proprietary communications, or Bluetooth low energy (BLE), Bluetooth 5, and Bluetooth Mesh networking in a single package (Figure 4). As the Bluetooth SIG continues to revise and enhance its Mesh specification, these solutions enable IoT mesh networks to be positioned for the future without the tradeoffs.

[Figure 4 | The EFR32BG13 Blue Gecko SoC from Silicon Labs supports Bluetooth Mesh, Bluetooth 5, and BLE networking.]