Curated by Vinay Prabhakar Minj
In the beginning, Bluetooth was actually a cable replacement technology. Now, it involves many-to-many communication between thousands of devices. That’s what mesh networking is all about.
Bluetooth is a standard, which means you can buy products from different manufacturers and they will work together as a consequence of the standardisation process. Bluetooth has been around for quite some time now. I think the key to Bluetooth’s lasting success is that it hasn’t stood still. It has been systematically developed over the years to keep pace with market requirements. Its usage has become broader and broader, and it has found it’s way in different types of devices and industry sectors. All these have enabled Bluetooth to survive till now.
Today, as many as 10 million Bluetooth devices are shipped every day in total, by the many manufacturers who use Bluetooth in their products. This is quite remarkable. In the summer of last year, we released the specification for Bluetooth Mesh, version 1.0. It’s a completely new way of using Bluetooth for smart buildings.
Bluetooth technology has evolved in terms of topologies. In the beginning, it was actually a cable replacement technology. It was about taking serial cables between two devices, throwing that away and replacing it with wireless communication. Now, we are talking about many-to-many communication between thousands of devices. That’s what mesh networking is all about. And it will be used in all types of industry sectors. We probably don’t even know what those sectors are because the marketplace always surprises us in the way it uses technology.
Today, as many as 10 million Bluetooth devices are shipped every day by the many manufacturers who use Bluetooth in their products.
Types of Bluetooth radios: There are two distinct Bluetooth radios.
First is called Bluetooth Basic Rate/Enhanced Data Rate (BR/EDR). This is the original Bluetooth best used for steady streams of data and very successful in the world of wireless audio. It was released 20 years ago, and is still going strong.
The next is Bluetooth Low Energy Rate, which was released in 2010. It has a completely different design with different goals. It is designed to reduce power consumption.
These two radio types are for two distinct cases. The Bluetooth mesh is not a radio but a networking stack. It’s for enabling thousands of devices to communicate using Bluetooth low energy as an underlying Bluetooth technology. This is the relationship between these three things.
Mesh networking
Mesh network is probably well described by the name itself; this is like a spider’s web where any device can talk to any other device, as opposed to a WiFi which is a hub router with some spokes, where every communication takes place by going through the router.
Devices that are members of the mesh network (nodes) can communicate with other devices and they do not have to be in direct radio range. This is accomplished by sending messages across the network by hopping, from device to device until they reach their final destination. So, the problem of range is solved through a mesh topology and multi-hop delivery. With this idea, you can encompass an entire building with a mesh network where messages reach their destination, travelling at the speed of sound. Latency is very low with Bluetooth mesh. Even a collection of buildings like business campuses and universities can all have an entire mesh network.
Bluetooth low energy has a range of hundreds of meters in clear sight but less in a building. Meanwhile, Bluetooth mesh allows messages to travel upto 127 hops.
Multi-path is more unique to Bluetooth and the way we do mesh networking. One of the primary goals while designing the mesh network is that it has to be reliable. It is hard to create a wireless communication technology that is sufficiently reliable for large scale commercial lighting systems. Often you are dealing with multi-cast operations and you are addressing a large group of devices all in one go. Technologies like IP do not work well because of the way acknowledgments work in their networking stack. Thus, the network gets flooded very quickly.
In multi-path delivery, any message sent by a device, for example, a message sent by a light will travel through multiple paths through mesh network to arrive at its destination. Even if one of those paths is blocked by a physical barrier or a device is broken, the function would not be affected. Another copy of the message will get there. So, a very high level of availability and reliability can be accomplished through such mechanisms.
Bluetooth mesh
Bluetooth mesh is inherently a secure approach to mesh networking. It is not good for things like ad-hoc networking because devices that are not members of your network cannot communicate in it. Consequently, there is a membership process called provisioning. If you ever use Bluetooth, then you have to obviously pair devices. But in Bluetooth mesh, you don’t pair devices because it is not about relationships between only two devices, it’s many to many. So, the standard pairing would not scale. It will take forever if pairing has to be done separately for each light or thermostat in the building.
We have a new process called provisioning that can be carried out using a small phone or tablet application. For provisioning an unprovisioned device that you have just taken out from the box, it is equipped with various security keys that make it a member of your network and allows it to interact with other parts of the network securely. During the provisioning process or immediately after it, you’re also going to do some configuration using exactly the same application which one of the manufacturers will provide. And while doing so, it is important to specify which application it is a part of, because your network hosts a different number of applications. So, in a building context, heating, lighting and physical security can be some of the applications. And particular types of devices will participate in one or more of those applications, but not all of them.
Different ways of addressing messages
Devices have, what we call states, which really are data items that indicate or control different states or conditions that device can be in. A very simple idea would be ON or OFF. That will be represented by a state that has a 1 or 0 in it. And state data items are all in the specifications where they are all defined. So, the values that they can take, what those values mean and how they can be changed and what should happen are all defined because this is a standard design that allows interoperability between devices from different manufacturers.
So because we are sending and receiving messages, not surprisingly there is an addressing scheme. There are different ways of addressing your messages and are of three types.
Unicast addresses are present in every type of devices and have a unique ID for that device. Surprisingly enough, you will hardly ever use them because most of the addressing of the messages will be done to sets of devices, even if that set only contains one device.
There are two types of address which can be used with collections of multiple devices; group addresses and virtual addresses. Group addresses are the ones which will be used most commonly.
Group addresses define some kind of set or a collection of devices. More often than not, they are associated with physical parts of a building like a certain room or a certain type of device in that room, so all of the lights in the main reception area may have their own group address. Then you can control them all by sending a message to that group address.
Here’s why you’ll probably use group addresses even when the group has only one device in it: the messaging system is based around the concept of publish and subscribe. To illustrate the way this would work, consider lights and light switches. For example, I install some light switches in some part of the building and I want to control them from a particular switch or light switches. Then I would have each of those lights subscribed to a particular address. On the other hand, I’m going to tell the switch to publish a message to that particular address. Now, this might sound very obvious at this stage; when I flick the light switch, it will send a message to the destination address and all of the lights subscribed to that address will respond. They will all switch OFF or switch ON, get dim or brighter or something like this. The beauty of this technique is that the light switch doesn’t know anything about the lights that it is sending a message to. And the lights themselves don’t know anything about the light switches that are controlling them. So I can make changes by adding more lights to the building and subscribe to that same address.Or I can remove them and it has hardly any impact at all on the configuration. I won’t need to reconfigure the various devices because they don’t know enough to be affected by that change.
Bringing together the above concepts gives us models. Models are specifications for software components and the collection of models that the device implements determine the things it can do. A model will specify what messages it supports, what state values are associated with those messages and what transition changes in those state values should be accomplished. So, models bring everything together and a typical product will support multiple models. Now the current specification for version 1 has a number of separate lists of models. The first list is called the generics and the generic models are the ones that are applicable to any type of product having a simple behaviour such as ON and OFF. There is a big list of these generic models which you can control in your mesh network wirelessly. Beyond the generics list, the current version has a list of models specifically for lighting because it is really important and also for sensor networks comprising of any type of sensor. There are also things to do with automation and time because scheduling events in a mesh network are very important.
Bluetooth mesh for smart buildings
Automation can be important in smart buildings and smart homes. Bluetooth mesh defines ‘scene’ as a mechanism by which you can build automation. Imagine I’am walking into a room. Probably I’ll want a lot of things to happen in response to that event, like lights to come ON or maybe get brighter as you’re in the room, may be the air conditioner livens up or the shutters come down. The point here is that there is a whole collection of changes, spanning different devices and systems, that should all take place in a single orchestrated action in response to that one occupancy event indicated by the sensor. Scenes are the bluetooth mesh mechanism that lets you do that.
Switch models, light models and sensor models have a series of bluetooth mesh standard models defined by the specification inside them. Lights can be switched ON or OFF, so probably the generic model server will go inside them. Light switches control lights by switching them ON or OFF, so there will be the generic ON /OFF client model inside them. The difference between a client and a server is that servers have state values whereas clients do not. Clients just send and receive messages and they can change the state of the server and the device having the server model will respond by switching ON or OFF. Light Lightness Server or LLS controls the brightness and dimming of lights while Light Hue Saturation Lightness Server or LHSLS is for colour control. Light Lighting Control Server or LLCS allows to interface sensors with light to accomplish some useful effects.
State Bindings are relationships between state items. So if a particular state changes its value through State Binding, then I can automatically trigger a change in another state inside the device in another model perhaps for which I have specified this special relationship.
In Bluetooth mesh, you don’t pair devices because it is not about relationships between only two devices, it’s many to many.
Now, imagine the occupancy sensor detecting people entering and leaving a room. When I walk into the room, the sensor is sampling occupancy data and will send a message using the sensor model to the Light LC Server to indicate occupancy. The Light LC Server gets to know about this occupancy by registering it’s value in the state server. Thanks to the state binding between the occupancy state in the Light LC Server and the ON/OFF state in the Generic ON/OFF server, changing the occupancy state will automatically change the ON/OFF state. In other words, as I walk into the room, the sensor will notice my presence and the light will switch ON. We can build relationships between these models to achieve all sorts of useful things.
In place of a light sensor, imagine now having an ambient light sensor. This is a very common requirement in smart buildings. With my ambient light sensor, we are sampling the light levels and as changes occur, we send messages to report ambient light level to Light LC Server model. It has a State Binding with the light’s lighting server. When the sensor detects brightness from an external source (bright sunlight), then the lights will get dim or may be completely turned OFF. Conversely, when it gets darker, then the lights will get brighter. A time server can also be included in the model as well to schedule time changes.
Smart lights consist of some hardware, possibly some sensors integrated into that same unit. These include a microcontroller and a bluetooth mesh communications component that can communicate with other devices in the mesh network. At the top of this stack, we have an application software which controls the light (switching ON/OFF, changing the colours). For multiple lights, multiple applications can be implemented on that same microcontroller. Now, every single light can become a beacon.
Bluetooth beacons are increasingly common. They are bluetooth transmitters that broadcast unique ID and if you are walking along a smartphone with some software in it and it receives that broadcast with that unique ID, then it can translate that ID into knowledge of a place or an object. So, they are often used to give localised information when you are in proximity with something or to give you indoor navigation capabilities. These days, they are also being used for space optimisation as well. So, in a really large building like an airport, I can deploy an indoor navigation system because I have the infrastructure.
Ways of creating a mesh network
There are two distinct ways of creating a mesh network. One involves Routing, which is about figuring out how to get some data from A to B via some intermediate points. There are algorithms that determine routes. However, Routing gives rise to a single point of failure in your network and that is not acceptable. Routing is an efficient way of handling data but it is not sufficiently reliable, so we rejected it.
Flooding, on the other hand, is at the other end of the spectrum and involves no routing whatsoever. The messages get broadcast and every device that receives that broadcast will broadcast it again, so it will spread across the whole network and everything receives everything. Your message will get through in a very reliable way given the amount of re-transmission that’s going on. But it’s really not very efficient.
So we used something halfway in between. We used something called Managed Flooding. It uses some of the fundamentals of Flooding (we don’t do Routing, we don’t want single points of failure). But we have various strategies of doing Flooding which makes it efficient. So, we get the best of both worlds. You can control how many hops a message will do. There are heartbeat messages flowing across the network so the devices can inform each other about where they are or how far away they are. This way the network can learn about itself and it’s topology and use that to optimise the way it sends data, how far messages will go and so on.
Regardless of the type of product, nodes can fulfill a variety of network functions whether it’s a light, light switch or a thermostat.
Devices that are part of my network that I have provisioned are called nodes. Regardless of the type of product, nodes can fulfill a variety of network functions whether it’s a light, light switch or a thermostat. In Relay Nodes, messages get relayed (hopping through the network) only by nodes that are acting as relay nodes. It’s a software feature, so not all devices or nodes in your network are relays. You decide when you are designing and implementing your network which devices will provide that service.
Friendship in bluetooth network works like this. In any network, particularly in a smart building world, you will have some devices that are power rich such as lights, as they have limitless power because they are connected to the grid. And you will have low power nodes, such as sensors, that are embedded on a surface and hence their batteries cannot be changed every time. Managing their power consumption is absolutely critical. So, if a Low Power Node was equipped with a temperature sensor and was supposed to report temperature only when it went above a certain limit or below, then it is a very efficient sensor because it is going to send one byte of data every three months or something like that. Hence, we have no problem. However, if one of our requirements is that we must be able to change those thresholds by sending a message to the sensor whenever we want to, then now we have an efficiency problem since the sensor must keep the radio on for a high proportion of time so that it can receive messages.
Friendship involves low power nodes discovering devices that act like friends. It’s a software feature that can send out messages to any other device. And now these two devices work together. The messages that get sent to the low power sensor actually gets stored by the friend and it will accrue messages addressed to the sensor until the sensor wakes up and receives messages. So, devices can discover each other and agree to help each other.
The last network role a node can have is called proxy, which is really important because the proxy lets any compatible bluetooth low energy device in the market stay like a smartphone to talk to a bluetooth mesh network without waiting for Google or Apple to upgrade stack with new APIs. You can use the standard APIs that are already available under those platforms to talk via a proxy node to the rest of the network. You can send messages via a proxy node, which can be one of your lights. You have multiple proxy nodes all over the building and you can write standard bluetooth low energy applications that work with your mesh network. So the range of compatibility increases with every device. That’s a major advantage this technology has.
Bluetooth low energy vs Bluetooth mesh
In the world of bluetooth low energy, security is optional. It’s all about two devices and the question about the type of security required is something which only the manufacturers can decide. It’s like a toolbox; there are lots of security capabilities but manufacturers decide which of those capabilities they are going to use for their products. Bluetooth mesh is different because no manufacturer is allowed to reduce the security of the network. All messages are encrypted and authenticated. This means you cannot spoof messages in the network, and so all communication is secure. We can separate the security of different applications by issuing network keys which make devices members of your network and allow them to operate within the network. For use in particular applications, there are application keys and devices only get application keys that are relevant to the application they are a member of. We can also divide our networks into sub-nets and isolate different areas cryptographically. This is great for hotels where each individual room will have it’s own sub-net key issued at the time when you book the room. Messages are also obfuscated. This is a privacy mechanism and you can’t do network analysis attacks and figure out patterns of communication.
And the whole thing starts with the provisioning process, which is how devices get those keys in the first place.
About the author
Martin Woolley, Developers Relation Manager, Bluetooth Sig is an international public speaker on Bluetooth technology, software development, smart buildings, smart home, IoT, smart industry, location and proximity applications, Web Bluetooth and more.
The above article is a part of the speech he delivered at the India Electronics Week, 2018 held in Bengaluru. Using his wit and humour, he explained the intricacies of the latest Bluetooth technology and it’s applicability for lighting and other purposes.
