How Bluetooth Mesh Puts the ‘Large’ in Large-Scale Wireless Device Networks

June 26, 2018
Martin Woolley
Bluetooth Low Energy, Connected Device, Device Networks, Mesh, Smart Building

Abstract

This article provides a comprehensive look at:

Redefining scalability in terms of the number of mesh operations which can be processed per second
How the overall capacity of a Bluetooth^®Mesh network is affected by node density, packet collisions, symbol rate, and other key factors
The importance of decentralization and multicast messaging for achieving scale
How Bluetooth Mesh design and configuration options can optimise performance and scalability for a network
A real-world use case of a scalable Bluetooth Mesh network in action

Introduction

Mesh Stack

The specifications for Bluetooth^® Mesh networking were released in the summer of 2017. This new Bluetooth technology is designed for use cases such as smart buildings, commercial lighting, and smart industry.

Bluetooth Mesh expands the capabilities of Bluetooth, joining as it does the other Bluetooth technologies, Bluetooth BR/EDR and Bluetooth Low Energy (LE). It’s worth briefly reflecting on their individual capabilities and characteristics.

Bluetooth BR/EDR, which is designed for the transmission of a steady stream of data over point-to-point connections between two devices, and Bluetooth LE, which supports exceptionally power-efficient point-to-point communication but can also broadcast data in a one-to-many topology, are both radio communications technologies, each with its particular strengths and application biases.

Bluetooth Mesh networking is not a radio technology. It’s a networking technology which allows many-to-many networks of large numbers of Bluetooth devices or nodes to be formed. Messages transmitted by one node can hop from node to node across the network until they reach their destination. This allows communication to take place substantially beyond direct radio range. Copies of messages can travel via multiple paths through the network, providing architectural redundancy and the benefit of high reliability to the network, without the need to configure special rules or routes. Multi-hop and multi-path delivery are capabilities which are inherent in the way Bluetooth Mesh works.

There is an important relationship between Bluetooth^® Mesh and Bluetooth LE. Bluetooth Mesh uses Bluetooth LE for radio communications; so if you look at the full mesh stack, you can see that Bluetooth LE sits underneath Bluetooth Mesh .

As engineers start to learn about Bluetooth Mesh, and become familiar with its terminology and capabilities, one of the questions I sometimes get asked is:

“How many nodes can a Bluetooth Mesh network scale to?”

The short answer, which I’m often constrained by time to give, but the only short answer which has any technical merit is this:

“It all depends…”

In this article I’d like to take some time to examine that question more closely and provide a more useful answer for those wishing to assess how well Bluetooth Mesh might fit their requirements.

A Better Question?

Asking how many nodes a mesh networking technology can support is understandable. It’s not a particularly useful place to start when assessing the potential performance and scalability of the technology or of a particular network design, however. The answer will always be “it all depends” and here’s why.

Capacity

The primary constraining factor in the scalability of a system which uses any wireless communications technology concerns the fact that radio is a shared resource with a finite capacity. Any collection of devices which are within radio range of each other and using the same frequency or set of frequencies for transmitting data are sharing and competing for the use of that radio resource. Those which are out of range of each other or using different frequencies are not. The density and verbosity of our network is of greater concern therefore than the total number of nodes it contains.

Consider Figure 1. It shows a mesh network consisting of a large number of street lights, each a node in the mesh. Due to the linear, well-spaced distribution of those nodes, an individual node is rarely within range of more than a small number of other nodes, and therefore there’s little competition for access to the shared radio spectrum.

Figure 2, on the other hand, shows the ground floor of a building with the majority of mesh nodes all within direct radio range of each other due to the dense deployment pattern and so these nodes are all competing for use of the same radio resource. How well they fare becomes an interesting question and is a much more useful and answerable version of the original “how many nodes…” question we started with.

We now appreciate that network node density is an important factor, but it still doesn’t tell us much about capacity or scalability in real terms. How those nodes make use of the shared radio spectrum and, more to the point, how efficiently they make use of it is the next issue to consider and is key to understanding the scalability question.

I’ll seek to illustrate capacity in an idealized, theoretical way, but before I do, it’s necessary to better define what we mean by capacity. In the context of a mesh network, ultimately we’re concerned with how much useful work the network can support. To put it another way, how many mesh network operations can be successfully carried out in a given time span? Examples of network operations might include a message which increases the brightness of a large group of lights, sent by a dimmer switch and sensor readings which inform other building systems that there are people in a room. There are other, more academic measurements we could consider, but at the end of the day when we consider capacity and scalability, we’re really interested in how much useful work involving the devices and systems in our building, our network will allow us to accomplish.

I’ll be using an analogy to explore the concept of capacity. See Figure 3.

Figure 3 – Units of work being carried by the network

Each of the trucks in Figure 3 represents a unit of work which would typically be accomplished by the transmission of a single packet in a wireless network. The trucks are travelling along a single lane road and are bumper to bumper. The single lane represents a single radio frequency. The bumper-to-bumper trucks indicate that we’re using all the theoretical capacity afforded by that single frequency network. The trucks are travelling quite slowly and only a relatively small number, I’ll refer to as X, pass under the bridge each minute. We can say, therefore that the anonymous wireless communications technology represented by Figure 3 can handle X operations per minute at the maximum theoretical capacity.

Bluetooth^® Mesh relies on Bluetooth LE version 4.0 minimum for its underlying radio communications. Bluetooth LE 4.x has a symbol rate of 1 mega-symbols per second (ms/s) which is four times faster than other mesh technologies based, for example on IEEE 802.15.4, which runs at 250 kilo-symbols per second (ks/s). Note that a symbol is the equivalent of a bit in the analog world of radio rather than the digital world of the layers higher up in the Bluetooth stack.

With that in mind, imagine our trucks can go four times faster than in Figure 3.

Figure 4 – A higher symbol rate allows 4 x the units of work

Clearly, we can get four times as much work done now, due to the faster symbol rate of Bluetooth LE.

Our large trucks represent large network Protocol Data Units (PDUs), and this is an issue since they occupy significant radio airtime. Bluetooth Mesh uses incredibly small PDUs of at most 29 octets with common message types like those used to switch devices on or off, only 22 octets in length. There’s some additional data in the Bluetooth LE packet which wraps the mesh PDU, but only about another 18 octets. So, whichever way you look at it, mesh packets are small and efficient. Other radio technologies have similar, additional radio data alongside their network PDUs too, of course.

You can read all about the Bluetooth^® Mesh packet in an interesting article by the Bluetooth Mesh working group chairman, Mr Szymon Slupik. 29 octets is a fraction of the PDU size of some other mesh technologies, possibly as little as one third of the size of the PDUs they use.

Figure 5 – Small packets allow more work to be accommodated by the same radio resource

With small packets, optimised for mesh networking, we can get many times more useful work out of the available radio spectrum, since the airtime consumed by each packet is so much less than with larger packets.

As a final modification to my transportation analogy, consider this. Many wireless technologies operate on a single frequency (i.e. RF channel). You may be able to choose from a selection of supported channels when configuring your system, but once that selection has been made, all communication will be on that single channel. The single lane in figures 3, 4, and 5 represents just that. But Bluetooth^® Mesh may use three different frequencies and therefore has three times more raw radio resource available to it, as shown in Figure 6.

Figure 6 – 3 radio channels provide 3 x the capacity

Extra capacity can be used in various ways, not just to increase the amount of meaningful work which can be accomplished. Later on, I’ll explain how the three radio channels which Bluetooth^® Mesh uses are instead harnessed to optimise reliability.

Making efficient and effective use of that shared radio spectrum is key to capacity and scalability and both are about getting work done. Bluetooth Mesh is efficient and scalable because of its optimised packet design and its use of the Bluetooth LE radio.

Figure 7 – An example Bluetooth mesh packet

Collisions

The previous section should give you a sense of the basic factors governing the capacity of a shared radio medium. It was a rather simplified description though, intended to get the ball rolling on this subject. In practice, the full theoretical capacity of any radio resource is not available for meaningful use because of the increasing likelihood of packet collisions as the number of devices sharing that medium grows.

Adding an understanding of collisions helps develop better insight into the question of scalability and can help inform our network design decisions too.

If two devices which are within radio range of each other transmit on the same frequency at the same time, we have what is termed a collision. Colliding packets are essentially lost. Wireless technologies generally either seek to avoid collisions or accommodate them through schemes which ensure the devices involved in the collision waiting a random amount of time and then retransmitting. Bluetooth^® falls into the latter camp.

Collisions degrade performance and limit scalability.

Two devices do not have to attempt to transmit at precisely the same instant for a collision to occur. The transmitted packets just have to overlap in time and use the same RF channel as shown in Figure 8.

Figure 8 – Overlapping packets cause collisions

Alpha in Figure 7 is the duration for which a packet occupies the radio channel. Any other packet transmitted by another device during that time will cause a collision, as the example in Figure 7 illustrates.

In all wireless communication, regardless of the technology being used, there comes a point when the amount of traffic being carried by the network is giving rise to such a high level of collisions that the network reaches its effective capacity limit, which is something less than the theoretical, absolute limit depicted in Figures 3 – 6.

The less radio airtime a packet requires, the lower the probability of a collision. The small packet size of Bluetooth^® Mesh and the high symbol rate of the Bluetooth LE radio reduce the required airtime for a packet and means that Bluetooth Mesh networks fare well in this respect. Far more packets can be handled before a network reaches its effective limit due to collisions and therefore the network can scale to handle a greater volume of operations.

Revisiting the Question of Network Scalability

We should now be able to revisit and revise the question of mesh network scalability.

Rather than asking how many nodes a network can support, it should be clear that a better definition of performance and scalability involves the number of mesh messages per second that the network can handle, since mesh messages are the mechanism by which work is carried out in a Bluetooth^® Mesh network. We should also factor the concept of reliability into our definition, since we know that as traffic volumes increase, so do collisions and the potential for message loss. Finally, since we know that it’s only devices which are in range of each other that are sharing the same radio medium, to assess the question of scalability, we only need consider physical zones where devices are close enough to communicate directly.

Consider the following definition of scalability in a Bluetooth Mesh network:

Scalability: The maximum, total number of mesh messages per second which can be communicated between nodes in direct radio range of each other.

FEATURED INFOGRAPHIC

Build a Smarter Building With Blue

See new data on how building with blue can increase reliability, reduce costs, and enhance the ROI of smart building solutions.

SEE THE INFOGRAPHIC

Mesh Messages and the Advertising Bearer

With a new definition based on mesh messages per second and our knowledge of the factors influencing capacity in wireless communication, we should now consider more carefully how mesh messages make use of the underlying Bluetooth LE radio. In the mesh specification, this topic is covered by the bearer layer of the mesh protocol stack. Two bearers are currently defined, but communication between nodes in a mesh network generally makes use of one of them, the advertising bearer.

The advertising bearer defines how mesh network PDUs can be broadcast within Bluetooth LE advertising packets on the three Bluetooth^® LE advertising channels and how they can be received by scanning for packets on those same channels.

Most mesh messages fit in a single mesh network PDU. And we already know that the Bluetooth LE radio is fast at 1 ms/s and that mesh PDUs are small at 29 octets. Figures 4 and 5 from the transportation analogy apply well to Bluetooth Mesh and the advertising bearer. Bluetooth LE advertising, and therefore the mesh advertising bearer, uses up to three distinct and specific radio channels, and this is what is illustrated in Figure 6. This does triple the capacity for PDUs to be broadcast, but it does not increase the capacity to perform work. Typically, identical copies of each PDU are transmitted on up to three advertising channels, one at a time; this is a strategy which is designed to increase reliability rather than application layer throughput.

From the General to the Specific

Up to this point, we’ve been considering generally applicable theory and issues. Issues that apply to any and all Bluetooth^® Mesh networks. And I’ve suggested that asking how many nodes Bluetooth Mesh can support is not the right question, preferring instead an approach based on the number of mesh messages per second which can be handled.

When it comes to considering specific networks and network designs, with specific types of products acting as nodes, we find that the “how many” question is a lot more meaningful in these concrete cases than in the abstract. Because it all depends, remember?

When designing a particular Bluetooth Mesh network with specific devices which will communicate with each other, we can and must be able to assess whether the number of devices in range of each other, say in particular parts of a building, will perform in a satisfactory way. To do so, we need to combine our knowledge of the generally applicable theory with our knowledge of the expected behaviour of the devices that are to be members of our mesh network and the way we intend to configure them. In simple terms, we have a finite radio capacity available to us and we know that Bluetooth mesh makes efficient and scalable use of that finite resource, but how exactly will the devices in our network be making use of it? There are several issues to consider in order that this question can be answered.

The Application Layer

Does our network contain large numbers of very chatty devices, which transmit high volumes of messages throughout the day and night? Perhaps sensors that are sampling and transmitting various environmental measurements, frequently? Or are most of our devices only occasional transmitters of messages like light switches that perhaps only get pressed twice a day? These are questions about the application layer behaviour of the devices in our network and about the human users of some of those devices. It’s perhaps an obvious thing to say, but what devices we have in our network and what they do is a factor in how our shared radio resource is going to be used and how many devices in a given area will therefore be able to share it.

Note though that operations which affect a group of devices, like dimming all of the lights in the office require only a single message to be sent, not one message per target device. Bluetooth Mesh uses a publish and subscribe messaging system which means that one message published by something like a dimmer switch will be processed by every device which subscribed to it. This is another example of the efficiency inherent in the design of Bluetooth^® Mesh.

Decentralized Lighting Controllers

A common requirement in commercial buildings is for lights to be controlled by sensors. Occupancy sensors can be used to turn lights on and off. Ambient light sensors can be used to dynamically control the level of artificial lights so that a constant ambient light level is maintained throughout the day, regardless of the brightness of the natural light coming in through windows.

In wired systems, meeting such requirements typically needs devices called controllers to be included in the network. Controllers sit in between sensors and the lights they are required to control. The controlling logic which decides what to do when a given type and value of sensor data is received resides within the controller. All legacy wireless systems take exactly the same architectural approach and require dedicated controller devices in precisely the same way. This is what we call a centralized approach to lighting control logic and have depicted in Figure 9.

In a Bluetooth^® Mesh network, the controller is a software component that is defined by a standard mesh model, such as the Light LC Server model. The Light LC Server model is part of the software running on the light itself and, as such, there is no discreet controller device; control logic is an integral part of the device under control and sensors talk directly to it by publishing mesh sensor messages to which the light’s Light LC Server model has subscribed. The Light LC Server will cause appropriate action to be taken in its host light, often exploiting mesh state bindings to other models such as the Light Lightness Server or Generic On Off Server.

The decentralised, software-based Bluetooth Mesh approach is a more efficient topology, with fewer radio-resource-consuming messages being required for each operation type when compared with the centralised approach with its dedicated controller devices.

Figure 10 – Decentralised lighting control

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	5	20 + (20 * 5) = 120	10,368,000

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
1	0 (internal state transition)	1	86,400

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.

Relays

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.

TTL

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.

Network Retransmissions

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.

Real-World Experiences

Understanding the theory is important, but adding some real-world experience to the mix can be invaluable.

Silvair

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”.

Conclusion

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.

FEATURED DOWNLOAD

Bluetooth Mesh Developer Study Guide

The Bluetooth Mesh Developer Study Guide is a self-study educational resource which covers both the theory and practice of Bluetooth Mesh device firmware development.

INSTANT DOWNLOAD