Mesh standard adapts wireless technology to professional lighting needs (MAGAZINE)

SZYMON SLUPIK and SZYMON RZADKOSZ explain what you should know about the architecture of the Bluetooth mesh standard and why the IoT network technology is an optimal match for connected SSL.

Bluetooth mesh networking technology is finally here. Was it worth waiting for? Can it really drive widespread adoption of connected solid-state lighting (SSL)? And what exactly does it mean that it has been designed for professional lighting applications? As one of the leading contributors to the development of this new wireless standard, Silvair has answers to questions you might be asking yourself today. Let's review the development of the standard and consider the impact it may have in bringing LED lighting into the Internet of Things (IoT) movement.

Interested in articles & announcements on IoT, smart lighting technology, and Bluetooth mesh?

A pinch of history

For Silvair, the interest in Bluetooth all started back in 2013 when Google rolled out Android 4.3 with API level 18, introducing support for Bluetooth Low Energy (BLE). At that time, the company wasn't too familiar with Bluetooth, but already knew that IPv6 over the 802.15.4 standard (used by ZigBee, for example) was a pipe dream. Even with the 6Lo compression (6LoWPAN - Ipv6 over Low Power Wireless Personal Area Network, a lightweight protocol envisioned to bring IP networking to embedded or IoT devices), IPv6 was simply too heavy to fly, and 802.15.4 turned out to be too slow to give it a lift. Back in 2012-2013, Silvair was experimenting with something very similar to what Thread is today. But eventually we found this combination (IPv6 + 802.15.4) incapable of addressing the needs of professional wireless lighting. Hence, Silvair kept looking for a suitable radio technology.

Google's announcement of support for Bluetooth Low Energy in Android sparked hopes. BLE was already supported by iOS, so with Android on board, it seemed like a good candidate to try. But it did not fly, either. The single-hop range was very limited and the hub-and-spoke topology was far from anything usable for lighting needs; it could provide only a handful of point-to-point connections. Great for linking a heart rate monitor to a phone but certainly not to control a ceiling with 500 lights in a hotel lobby. There was hope, though.

With Bluetooth mesh networking, entire building systems can communicate in an orderly fashion especially when lights are used as the primary network nodes. (Photo credit: Bluetooth Special Interest Group.)

BLE offered the physics

The underlying physics of BLE was very promising. Within a couple of months, Silvair managed to build a BLE module capable of communicating over a 500m single-hop distance. The company also discovered that with proper software engineering, it was able to run multiple Bluetooth roles (a GAP Observer and a GAP Broadcaster) at the same time (GAP stands for General Access Profile). This experiment was carried out in early 2014 and you can see it now being the fundamental requirement of the Mesh Profile specification (see the last paragraph in Section 3.3.1).

This could be described as the conception of Bluetooth mesh networking. After all, if the software part of an off-the-shelf Bluetooth SoC (system-on-chip) could be modified in a way that allowed receiving and retransmitting messages, building a mesh network on Bluetooth would be possible. It was "just" a matter of nailing down the details of this software and documenting it as an open specification, so others could do the same.

This "just" step took more than three years and resulted in the publication of three specifications, approximately 1000 pages combined. Indeed, it is a complex solution. But along the way, it turned out that a solid technology for connected lighting simply could not be outlined in a dozen pages and delivered within several months. The nature of wireless mesh networks is complex. Jet engines are complex, too. Cars are complex. So are cellular networks and many other technology wonders we're using every day. They are all successful because they are complex and solve the intricate nature of problems. This is what Bluetooth mesh is doing, too - trying to address the complex challenge of low-power communications in the resource-scarce IoT environment while ensuring wire-like performance in connected lighting networks. Many technologies have promised that, but none of them has delivered so far.

It's all about the packet

Why should we trust that Bluetooth mesh will be different? As the Bluetooth mesh networking specifications are now public, we can start dissecting and discussing various building blocks of this new wireless standard. There are many novel and unique concepts in mesh, but perhaps the key asset and differentiator is the packet. It is extremely compact. This compactness contributes to the spectral efficiency (and throughput) of Bluetooth mesh networks.

Radio is a shared medium and data-packet collisions are one of the key problems to address. This is what makes scalability such an enormous challenge in connected lighting networks. The math is simple: A shorter packet means fewer collisions. But how short can it be? The answer is up to 29 bytes, as described in Section 3.4.4 of the Mesh Profile specification.

Of course, such design begins with the basics: compressed binary payload instead of a text representation. Covering a broad set of use cases (including connected lighting, building automation, and sensors), 11 bytes for the application payload seems appropriate. The standard allows 1-2 bytes for an opcode and up to 10 bytes for parameters, such as a value measured by a sensor, or a multidimensional light (light level, hue, saturation) with a transition time.

On top of that, there are two items that may be considered overhead, but it is an absolutely necessary overhead: addressing and propagation control (SRC, DST, CTL+TTL: 5 bytes in total) and security (IVI+NID, SEQ, AppMIC, and NetMIC). The IVI+NID is 1 byte. This byte helps identify a network (is this a network I know and have keys to interact with?). SEQ is 3 bytes and together with the unique concept of a slowly propagated IV Index, forms a 7-byte-long sequence number. Each packet sent on a mesh network has a unique sequence number, per given SRC address. The smart part here is that only 3 bytes are included in the air interface packet. The remaining 4 bytes are slow changing and are "known" to the network. Sequence is essential in two areas: detecting replayed packets (very trivial security attack) and also being the key ingredient of both network and application nonces - see Section 3.8.5 of the aforementioned spec.

Securing the system

MICs, or Message Integrity Checks, define the level of security of the system. Bluetooth mesh has dual-layer security - it includes the network layer and the application layer. Messages may be secured with two independent keys. This is useful for relay nodes to authenticate a message on a network layer without enabling tampering with the application payload. A lightbulb that relays a message to a door lock cannot change the payload from "open" to "close," but it does check whether the packet belongs to its own network. The network layer MIC can be either 8 or 4 bytes long. In its shorter form, it is combined with the application layer MIC that can again be 8 or 4 bytes long.

The end result is an application payload that is sufficient for almost any building automation, lighting control, and sensor application, with strong security and flexible addressing. And this all comes in an extremely compact form factor. Combined with the modulation scheme offered by BLE, it is also feather light. Including all necessary radio interface fields, such as a preamble, an access address, and a CRC (cyclical redundancy check), it totals 47 octets. As a result, a single transmission on a single frequency lasts less than 400 μs. This is 10× less than it takes to transmit a comparable message using other existing wireless technologies. And when using the new 2M PHY introduced by Bluetooth 5, this advantage can potentially be doubled.

A Silvair evaluation kit enables SSL product developers to experiment with the capabilities of Bluetooth mesh, and accelerate the connected SSL product design cycle.

The success of any wireless system fundamentally relies on the spectral efficiency. It is similar to how the success of an airliner fundamentally rests on its fuel efficiency. In the low-power, ultrashort-message category, Bluetooth mesh delivers an order of magnitude more than other wireless solutions. As far as data transmission is concerned, it is the first wireless standard capable of meeting the enormous expectations of the IoT era.

Why lighting?

Still, you may wonder why a technology from the IT and telecommunications field is right for lighting. When working on the architecture of the Bluetooth mesh system, the Bluetooth SIG's (Special Interest Group's) Mesh Working Group kept on diving deep into the roots of problems it was aiming to solve. In particular, the team of contributors has focused strongly on addressing the many challenges of the smart lighting environment. There are many reasons to treat lighting as the primary application for a mesh system. Most important, lights are everywhere and they are powered. So depending on how you look at it, a lighting control system may be the goal itself or may just be the initial step to develop more services that are based on a mesh-connected infrastructure.

Imagine an airport, a hospital, a company campus, or a high-rise, multi-tenant office building. Now imagine you want to roll out a service that requires a dense infrastructure of radio nodes - perhaps thousands of them. Rolling out adequate hardware would be very expensive, as each component would require a mounting point and power supply. Now suppose that each light is already mounted and powered, and is capable of supporting your wireless application. Suddenly, you realize the hardware is already there: a mesh network of thousands of low-power wireless computing nodes.

This is why the lighting category is so crucial for Bluetooth mesh technology. And to be a winning solution in that category, the new wireless standard had to be outstanding for connected lighting applications. Everything else comes afterward.

A tough world of lighting controls

There are many important details that contribute to why a given solution is good for lighting. Let's take a closer look at two simple examples.

First, consider eliminating the so-called popcorn effect. There are two challenges for wireless lighting control systems here:

• They have to be absolutely reliable when it comes to delivery of control messages. If any light in a ceiling doesn't turn on, it will be immediately noticed and considered a system failure.



• The execution of a control command must be synchronous - any popcorn effect simply disqualifies a system, being a clear step backward compared to smooth and synchronous operation of traditional lighting controls.

A lot of effort has been put into ensuring that Bluetooth mesh networking can effectively address both of these challenges. First, it is primarily optimized for multicast traffic. So regardless of whether there are ten, a hundred, or a thousand lights in a ceiling, they can all be addressed with a single message that goes out. This message, in real life, may reach around 90% of lights. To ensure that all of them are eventually reached, the message is repeated a couple of times. With two messages, the probability of delivery of at least one message goes up to approximately 99%. With five messages in a row, the reliability jumps to five nines, or 99.999%.

Now, some lights will receive the first message, while some lights will receive one of the later messages. But we want all of the lights to turn on at exactly the same time, since this is how lighting controls have worked for us for decades. How does the new standard ensure that? Here comes the Delay parameter to the rescue. Let's say that five messages are spaced 20 ms apart. The first one goes out at T=0 with the Delay set to 100 ms. The second is sent at T=20 ms with the Delay set to 80 ms. The scheme repeats until the fifth message is sent at T=100 ms with the Delay set to 0. Now, regardless of which one is picked by a given light, all lights will turn on at exactly the same time. Of course, there is the overall execution delay of 100 ms, but that is below the human perception level. The speed of the underlying radio, combined with multicast transmissions and time-compensated retransmissions, guarantees that the final effect matches application requirements.

The second example is simpler but nicely illustrates the attention to details characterizing the Bluetooth mesh specifications. How does a lighting system behave when the power is cut off and restored later on? How should it behave? The answer is that it depends. Of course, it depends on the type of lights, what purpose they serve, etc. In some cases, you might not want a power cycle to turn the lights on (this is unfortunately the case with some popular home lighting systems). But in many other scenarios, this may be the desired behavior.

In Bluetooth mesh networking, there is a configuration state called OnPowerUp (Section 3.1.4 of the Mesh Model specification). It can be set to Off, Default, or Restore (to the last value before the power was cut off). It works in tandem with another configuration state, the Light Lightness Default (Section 6.1.2.4), which can be any arbitrary level, or the last non-zero value (e.g., if you dimmed the lights down to 20% and then turned them off, after a power cycle they will turn on but at 20%, not at their full brightness). Again, the attention to tiny details presented by the design team seems to be going much deeper than in the case of other wireless solutions.

Scaling it up

Scalability was the initial reason why Silvair turned to BLE when trying to find a foundation for a robust low-power mesh networking technology. Its wireless capabilities were simply much better than anything else available. This was primarily due to the extremely compact packet structure, which flies over the fastest low-energy radio. But, of course, every solution has certain limits. So what are the limits of Bluetooth mesh? The answer is, as always, it depends. It depends what the network is doing (how many and what types of messages it keeps sending around) and how it is set up. Bluetooth mesh has many parameters that may be fine-tuned to adjust its performance to specific requirements.

As a general rule of thumb, one can assume that at 200 devices (or fewer), there is no need to worry about any tuning at all. The likelihood that any two communications will collide is pretty low. So let them loose at will.

Above 200 devices, depending on how talkative they are, some collisions might occur. This is why Bluetooth mesh provides a number of tools that help optimize the network and let it grow significantly while maintaining an excellent packet delivery ratio. The most important ones include the following.

TTL, or Time To Live. It defines how many relay hops a message is allowed to travel. It is rarely the case for large networks that every sender has to be heard across the entire network. An occupancy sensor, for example, usually needs to report only to light fixtures in the same room. And maybe to a gateway, but not across the entire building, to locations where nobody is interested in its status. Setting the Default TTL to a low value (even to 0 in some cases) is a good way to significantly increase scalability.

Relays. They retransmit received messages, obviously multiplying traffic in a given space. Usually, the default setting for the relay function is "on" in order to make setting up small networks seamless. In large networks, it pays to carefully select how many devices are designated as relays and disable relaying where it is not needed. Ericsson Research has recently published a thorough case study (http://bit.ly/2xV2XLm) modeling an office floor with close to 900 talkative mesh devices. It is based on real data captured from a live network. It shows that for a case like an office floor, it is enough to assign about 1.5% of nodes as relays.

Subnets. Mesh networks can be significant in size, spanning entire multi-story buildings. But it is extremely rare that devices on separate floors need to communicate with each other. Except for administrative tasks like re-keying the entire network or shutting down the whole building, typically each floor is self-contained. This fact is why subnets are a great mechanism to confine network traffic. A mesh node can be a member of multiple subnets, so it is a good practice to have the base network spanning all floors and then have a subnet defined for each floor. And to configure the nodes to transmit only on subnets they belong to, not on the main network (except the administrative tasks). A single mesh network can have more than 4000 subnets. We have yet to build a structure that vast. Until then, subnets should help in scaling up any network you imagine.

Is this the beginning of a new era?

According to wireless architects from Silvair, the v1.0 of Bluetooth mesh is much more capable than anybody has anticipated. It is a complete system for low-power, fully-interoperable mesh networking, with a deep and flexible application layer addressed in the Mesh Model and Mesh Device Properties specifications. By defining basic functionalities of network nodes, mesh models make devices aware of what function they perform, what other nodes they can connect with, and what actions can be performed upon them.

To enable maximum design flexibility, models include multiple properties that can be adjusted in accordance with specific applications. In addition to covering a full range of standard lighting functionalities, mesh models fully support additional functionality such as advanced lighting control strategies including occupancy sensing, daylight harvesting, or time scheduling. They also come with multiple tunable parameters and properties, effectively future-proofing buildings against increasingly stringent environmental requirements that we can expect to see as the world strives for a low carbon future.

With the Bluetooth mesh networking specifications already published, we will soon be able to see how these networks perform in practice, and whether this new wireless standard has what it takes to move connected lighting to another level. What already seems certain is that no other technology has fostered such a comprehensive approach to challenges typical for lighting applications. Time will tell whether this is enough.