Once again, it’s worth reminding ourselves that for a sensor to communicate with the group of lights it is associated with, only a single message is required rather than one per light.
Unicast vs Multicast Messaging
Bluetooth Mesh allows a message to be addressed to a specific, single device using a unicast address or to a collection of devices using a group or virtual address. Unicast addressing is rarely used and, in fact, it is only explicitly recommended for use when configuring new devices as they are added to the network. Group addressing is the norm and leverages the publish and subscribe messaging system which decouples devices and allows changes to be made to the network without reconfiguration being required. Group addressing also offers potentially substantial performance advantages.
Those performance advantages come from a single fact which I’ve already stated, but it’s so significant I’ll say it again. Controlling a group of two devices only requires one message to be sent. Controlling a group of 200 devices only requires one message to be sent. In fact, controlling a group of any number of Bluetooth® Mesh devices in a single operation requires only one message to be sent.
Operations involving collections of more than one device are extremely common, especially in the world of commercial buildings. If you’re sitting in an office as you read this, glance up at the ceiling now. How many lights do you see? Typically, commercial buildings have large numbers of LED lights distributed across the ceiling of each floor. Switches control groups of them, allowing them to be switched on or off, dimmed or brightened, or in some cases, have their colour varied.
The same applies to sensors, which are usually associated with groups of lights and other device types and system interfaces. The fundamental requirements and use cases of smart buildings are all about group multicast operations. Like all good technologies and design methodologies, the Bluetooth Mesh Working Group spent considerable time investigating requirements and use cases before they moved on to designing the technical solution. The emphasis on group multicast and the publish and subscribe messaging system is a consequence of that approach and a reflection of the true requirements of the commercial building and lighting sector.
To fully appreciate the benefits, consider the following use case. First, a unicast messaging approach built around the legacy, centralised controller architecture described in the previous section. Second, using Bluetooth Mesh, group messaging, and the decentralised controller architecture.
Use case: A long, rectangular open plan office has a grid of 100 lights in the ceiling, evenly distributed across the room in 20 rows of 5. There are windows running all along one side of the room so that natural light levels are uniform along the room. An ambient light sensor, strategically positioned in the room, samples ambient light levels every second and must communicate readings such that a uniform ambient light level is maintained by the lights being dynamically dimmed or brightened as required.
Let’s compare the amount of network traffic (messages) required with the two different architectures:
Centralised Controllers with Unicast Messaging
In this case, each of the five rows of lights has an associated controller, allowing independent control of each row (which is another use case, of course). The ambient light sensor must communicate with each controller and each controller must communicate with each of the lights it controls. So, in terms of messaging we have:
|Centralised Controllers with Unicast Messaging
|messages each second
|Sensor to the 20 Controllers
|Single Controller to its 5 Lights
|Total Messages for One Sensor Reading
|Total Messages per Day
|20 + (20 * 5) = 120
Decentralised Controllers with Group Multicast Messaging
In this alternative architecture, controllers are software components (lighting control models) embedded in each light, as described in the section on Decentralised Lighting Controllers. As such, there is no wireless communication required between the controllers and lights. All lighting controller models have subscribed to a group address and the sensor publishes once per second to this address. In terms of messaging we therefore have:
|Decentralised Controllers with Group Multicast Messaging
|messages each second
|Sensor to Controllers
|Controller to Associated Light
|Total Messages for One Sensor Reading
|Total Messages per Day
|0 (internal state transition)
This is a credible and representative use case and as demonstrated, Bluetooth® Mesh — with its support for decentralised controllers, publish, and subscribe messaging and use of group multicast addressing — generates less than 1% of the radio bandwidth consuming traffic of the decentralised, unicast messaging approach.
Network Design and Configuration
In addition to considering the behaviour of the specific devices our network will contain and the interactions that humans might have with them, there are some issues we need to think about when it comes to overall network design and configuration, which will have an impact on how well our network performs. For optimal performance, it’s essential that the Bluetooth Mesh network designer consider these issues on a network by network basis.
Most mesh networks will span a physical area that is larger than the point-to-point radio range of individual nodes in that network. Bluetooth® Mesh allows some nodes to be configured to act as relay nodes. Relay nodes retransmit every message they receive and are usually positioned on the edge of zones in a building so that they can extend the range of one set of devices, allowing messages to hop across the relay to reach another set in another zone. Strategically positioning relay nodes in a network is an important network design decision and the way in which mesh networks which encompass very large physical areas can be created.
When considering the need for relays, there are a number of things to think about. The physical construction of the building and presence of signal attenuating barriers is one of them. The typical point-to-point radio communication range of devices in the network is another and note that not all products will necessarily perform identically in this respect.
Relays are critical elements in a mesh network and not only extend range but also provide the basis for the multi-path delivery of messages, resulting in highly reliable network operation. The retransmission of messages by relays consumes radio spectrum though, so they should be used sparingly and placed in the network deliberately and with thought. Consider the fact that for example, the inclusion of 10 relays will more or less multiply the number of packets in the whole network by 10. As such, mesh network designers should aim to include the minimum number of relay nodes to be able to provide network coverage as required and the appropriate level of reliability. The Bluetooth Mesh Performance Study, published by Ericsson, provides excellent information on this and related topics.
Devices in range of each other share the same radio resource. I’ve used the informal term zone to allow us to visualise a physical area, within which all devices are in direct radio range, and I’ve described the role of relays positioned near the edge of zones in retransmitting messages so that they reach the adjacent zone(s).
The source of messages which are received by nodes in a given zone and which are therefore users of that zone’s radio resource may be nodes in other zones whose messages have been relayed. Therefore, mesh network designers need to ensure they take this into account when assessing the traffic levels in different parts of the building.
The Bluetooth® Mesh network PDU provides a mechanism with which to limit how far a message will travel across the network when being relayed. The time-to-live (TTL) field in network PDUs indicates how many times a message should be relayed at most. A value of zero indicates that the message should not be relayed at all and therefore will only be received by nodes which are in direct radio range of the transmitting node.
Applications may set the TTL value, but more typically its value will come from node data items (states) called Default TTL and Publish TTL which are set during initial configuration of the node.
The network planning and design process should deliver recommended values for TTL for each node and they should be optimised during on-site testing. The goal is to ensure that messages do not get relayed further than they need to be. A switch that controls only lights in the same room is unlikely to need its messages to be relayed at all and therefore Default TTL and Publish TTL should be set to zero, for example.
Using TTL correctly is an effective way of maximising the capacity of a mesh network.
Another technique for increasing the reliability of a Bluetooth® Mesh network involves configuring nodes to retransmit exact copies of packets at the network layer, automatically and with a configurable delay specified as multiples of 50ms in between each retransmission. Using this feature increases reliability but does consume radio resource through increasing traffic without increasing the number of work performing operations. Reliability and scalability may require some trade-offs therefore, and this should be considered in both the network design process and the on-site testing and optimisation process.
The Ericsson Bluetooth Mesh performance study also discusses and illustrates the use of this feature.
Unacknowledged vs Acknowledged Messages
It’s very common for communications protocols to define PDU types in pairs, with one PDU type called the request PDU and the other the response PDU. Request PDUs initiate an action and the sender should expect to receive a corresponding response PDU to indicate the outcome of the receiver processing the request. In scenarios where communication is on a one-to-one basis, a request-response approach works very well. The World Wide Web and the HTTP protocol exemplify this, with a web browser acting as the client and sending HTTP requests and the web server replying to each request with an HTTP response.
One of the fundamental goals of the request-response approach is to allow reliable communication systems to be created.
Bluetooth® Mesh defines both acknowledged messages, which require a response from nodes which receive and process the initial request message and unacknowledged messages which do not need to be responded to.
But there’s a problem with request-response. It doesn’t scale well when the majority of interactions are of the one-to-many, multicast variety which most Bluetooth Mesh node interactions tend to be.
If, for example, a switch sends an acknowledged message, requesting that the 200 lights in the conference hall be switched on, this will generate up to 200 acknowledgement messages, each consuming radio capacity. The switch will need to track the receipt of acknowledgement messages to ensure all 200 lights responded. In a further complication, the switch will need to decide what to do if it does not receive the expected 200 acknowledgement messages. Should it resend the message directly to those lights which did not respond, as a series of individual unicast messages? Should it send the same multicast message again, despite knowing that 99% of the lights already received and processed the original message? And what happens if we still do not receive acknowledgements from all devices after this initial retry?
Whatever the strategy adopted, it’s easy to see how we could quickly overwhelm the network with a storm of messages being generated in a short period of time.
The request/response approach consumes capacity and breeds significant complexity when used with multicast operations, and it is for this reason that Bluetooth Mesh takes a different approach. Reliable communication is achieved through strategies such as multipath delivery via relays and node network retransmissions, each of which substantially increase the probability of success without the need to burden the sending device with tracking and retry logic.
Bluetooth® Mesh product designers should treat unacknowledged messages as the norm and only use acknowledged messages in exceptional circumstances. Unicast messages sent during node configuration are an example of when acknowledged messages might be used.
Yes, but how many nodes will I be able to have in my network?!!
If you’re still determined to have a concrete answer to this question, I shall provide one. The answer, as stated in our Bluetooth Mesh glossary of terms, is 32,767.
And it is absolutely, 100% possible to create a Bluetooth® Mesh network with that number of nodes. That’s both the theoretical and practical limit. But if I’ve been successful in explaining the issues, you’ll now appreciate that not all concrete networks will be able to have this many nodes. Because it all depends on network density, application layer behaviours and configuration options relating to reliability that are in place.
Understanding the theory is important, but adding some real-world experience to the mix can be invaluable.
I paid a visit to Silvair’s offices in Krakow, Poland in 2017 just before the Bluetooth Mesh 1.0 specification was released. Silvair make wireless lighting control solutions and their CTO, Mr Szymon Slupik, is chair of the Bluetooth Mesh Working Group. Their office contained a comprehensive Bluetooth Mesh test environment consisting of hundreds of lights distributed across multiple rooms on the ground floor of their building, plus various sensors and switches.
Standing in reception, I was able to see a number of clusters of lights in different rooms through glass panels by each office door. Using a standard Android smartphone, I was then able to connect to a mesh proxy node and dim and brighten about 274 lights in unison. This was my first hands-on experience of Bluetooth Mesh in action. I’d seen other, proprietary mesh solutions before and had always been concerned by issues like very obvious latency which caused delays in lights responding to actions, especially those which were out of direct radio range from the switch. No such issues were apparent when I exercised control over the Silvair test environment’s lights. There was no perceivable latency at all. All lights responded instantly as I swiped my finger across the smartphone screen. Changing brightness was silky smooth and synchronized across the entire collection of lights. Everything worked perfectly. I’m a cynic who likes to see proof before I’m impressed — and I was impressed!
I caught up with Szymon recently and he told me that their entire building now features a Bluetooth Mesh lighting system. Note that this is not a test system. It’s the building’s production lighting system, relied upon by all users of the building. Rooms also contain Bluetooth Mesh sensors. In rooms with windows, ambient light sensors communicate with the mesh lights in the room so that daylight harvesting can be performed. This results in a consistent level of light in the room all day, regardless of how light or dark it is outside. Other rooms, with no natural light are equipped with occupancy sensors so that lights are only on when the room is occupied. This is helping cut costs and optimise the working environment for employees.
In fact, the Silvair building looked to me like a great example of Bluetooth communications working well in potentially very challenging circumstances. I asked Szymon about this and here’s what he had to say:
“Our building is probably the most radio-polluted, noisiest Bluetooth environment on the planet. We have more than 1000 Bluetooth devices spread around and organized into multiple stress test systems. Collectively, they generate several hundred messages per second. The most reassuring thing is that in this environment Bluetooth just works. The production lighting system works and the demos we provide to customers visiting us work and ordinary Bluetooth® devices work too… Most employees use Bluetooth keyboards and mice and have telephone conversations with their Bluetooth headsets. And by the way WiFi works too – the building has 12 high-capacity access points that serve more than 150 devices. We’ve proven to ourselves this technology is ready for prime time and large-scale adoption. We are extremely confident it delivers on the promise.” – Szymon Slupik, Silvair
The Question of Node Scalability
By way of complete contrast to everything we’ve considered so far, which has focused on the scalability of the network as a whole, there will be occasions where we might also need to consider what a single, individual device can do. Considering a single device in isolation, with a Bluetooth® LE version 5 stack underpinning the mesh stack on the device, the advertising_interval_min parameter can be set to as low a value as 20ms which would allow a maximum of 50 mesh messages per second to be transmitted (see Bluetooth Core 5.0 Specification, section 7.8.5). However, the mesh profile specification also says “Due to limited bandwidth available that is shared among all nodes and other Bluetooth devices, it is important to observe the volume of traffic a node is originating. A node should originate less than 100 Lower Transport PDUs in a moving 10 second window”.
Hopefully, I’ve given a useful introduction to the subject of scalability in Bluetooth® Mesh networks. I’ve redefined the general question in terms of messages per second and mesh operations carried out rather than in terms of the number of nodes in the network. We’ve examined the key, generally applicable factors affecting capacity and scalability and explored how Bluetooth Mesh, with its use of Bluetooth LE offers significant scalability advantages. We’ve also considered factors which need to be assessed on a case by case basis during network design and noted that sometimes there will need to be an informed trade-off between scalability and reliability.
What should be clear, is that Bluetooth Mesh allows us to create highly scalable mesh networks, capable of handling very high volumes of messages through spectral efficiency, superior radio performance, and an optimised mesh network packet design.