Bluetooth mesh networking
Sept 03, 2020
Introduction
Bluetooth mesh, officially launched in July 2017, is a highly anticipated addition to the Internet of Things (IoT) connectivity space. Bluetooth is a widely used short-range technology found in smartphones, tablets and consumer electronics, and the Bluetooth Special Interest Group (SIG) has a strong reputation for delivering specifications and tools that guarantee global, multi-vendor interoperability.
The Bluetooth Mesh Profile [3] standardizes a full stack connectivity solution for mesh networking, extending Bluetooth applicability for IoT use cases. Ericsson is a founding member of the Bluetooth SIG and has actively participated in the definition of the architecture and the development of the mesh profile specification.
This white paper provides an overview of the Bluetooth Mesh Profile and highlights some of its unique features. It also presents a large-scale building automation use case and illustrates the impact of configuration and deployment strategies on the mesh network.
The challenge
Mesh networking is a key technology-agnostic enabler for IoT in the short range space. Well-known technologies such as Wi-Fi and ZigBee have already standardized mesh support, and products that feature mesh networking are available on the market. Adding mesh functionality to Bluetooth is a necessary step, but the success of Bluetooth mesh depends on the ability to provide unique features and the possibility to address a wider range of applications than those offered by competing technologies.
The design of Bluetooth mesh has been driven by a desire to create a simple, efficient and flexible wireless mesh networking solution. With the Bluetooth Mesh Profile, thousands of nodes could potentially communicate within the same network in a connectionless manner. Since Bluetooth was originally designed for point-to-point communication, it has been important to review the scalability requirements for Bluetooth mesh networks.
Relaying in a Bluetooth mesh network is based on a managed flooding communication model. With managed flooding, a message injected in the mesh network can potentially be forwarded by multiple relay nodes. This approach offers flexibility in deployment and operation, but has the drawback of high congestion, resulting in packet loss for contention-based access in the unlicensed spectrum. It is therefore important to determine the supported traffic and QoS of Bluetooth mesh.
The solution
Bluetooth is a strong candidate to become the dominant short-range technology to connect edge nodes in a capillary network. Adding mesh to Bluetooth enables low-power sensors to communicate with the remote capillary gateways that can be implemented in any Bluetooth capable handset.
Bluetooth mesh provides several ways to configure the network based on the characteristics of the deployment and the requirements of the application, and the impact of such network configurations scales with the network size and throughput. Examples of configuration options include configuration of the relay feature, use of acknowledged or unacknowledged transmissions, message repetition schemes and transmission randomization.
To support standardization, validate implementation recommendations and assess the performance of a Bluetooth mesh network comprising of hundreds of devices, we carried out a full stack implementation of the Bluetooth Mesh Profile in a system-level simulator.
Capillary gateways
A capillary network is a LAN that uses short-range radio-access technologies to provide groups of devices with wide area connectivity [1]. Capillary networks therefore extend the range of the wide area mobile networks to constraint devices. Figure 1 illustrates the Bluetooth capillary gateway concept. As a capillary radio, Bluetooth standardizes the messages and behaviors of a variety of user scenarios that require sensing and/or actuation commands for constraint nodes. The relaying of these commands over multiple hops in the mesh also enables communication between nodes that are not within direct radio reach of each other.
The presence of capillary gateways such as smartphones and/or proxy nodes that support both Bluetooth and cellular connectivity in the mesh area network extends the accessibility of extremely low-power, storage and memory constrained devices into the core network up and to the cloud.
The bluetooth mesh profile
The Bluetooth Mesh Profile builds on the broadcasting of data over the Bluetooth low-energy advertising channels, as specified in the Bluetooth core specification [2]. Since the Bluetooth Mesh Profile is based on Bluetooth Core v4.0 and later versions, it works on existing devices after a simple firmware update.
Bluetooth mesh builds on top of an ecosystem of billions of compatible devices such as smartphones, laptops and low-power devices on the market today, making it possible to penetrate existing markets and extend Bluetooth's applicability to new areas.
Bluetooth mesh is standardized and interoperable by design. Qualification and interoperability testing is rigorous and involves all aspects of the protocol stack, including security. There is no risk of companies developing separate processes for different parts of the stack. Moreover, the specifications are open and can be tested by the community.
All nodes are asynchronously deployed and can talk to each other directly. After provisioning them, the network simply starts working and does not require any centralized operation – no coordination is required and there is no single point of failure. A group of nodes can be efficiently addressed with a single command, making dissemination and collection of information fast and reliable.
Design principles
Several characteristics make Bluetooth mesh unique, including:
- The publish/subscribe model: The exchange of data within the mesh network is described as using a publish/subscribe paradigm. Nodes that generate messages publish the messages to an address, and nodes that are interested in receiving the messages will subscribe to such an address. This allows for flexible address assignment and group casting.
- Two-layer security: Messages are authenticated and encrypted using two types of security keys. A network layer key provides security for all communication within a mesh network, and an application key is used to provide confidentiality and authentication of application data sent between the intended devices. The application key makes it possible to use intermediary devices to transmit data. Messages can be authenticated for relay without enabling the intermediary devices to read or change the application data. For example, a light bulb should not be able to unlock doors, even if the unlock command needs to be routed though the light bulb to reach the lock.
- Flooding with restricted relaying: Flooding is the most simple and straightforward way to propagate messages in a network using broadcast. When a device transmits a message, that message may be received by multiple relays that in turn forward it further. Bluetooth mesh includes rules to restrict devices from re-relaying messages that they have recently seen and to prevent messages from being relayed through many hops.
- Power saving with "friendship": Devices that need low-power support can associate themselves with an always-on device that stores and relays messages on their behalf, using the concept known as friendship. Friendship is a special relationship between a low-power node and one neighboring "friend" node. Friendship is first established by the low-power node; once established, the friend node performs actions that help reduce the power consumption on the low-power node. The friend node maintains a cache that stores all incoming messages addressed to the low-power node and delivers those messages to the low-power node when requested. In addition, the friend node delivers security updates to the low-power node.
- Bluetooth Low Energy Proxy: Some Bluetooth devices such as smartphones may not support the advertising bearer defined by Bluetooth mesh natively. To enable those devices within the mesh network, Bluetooth Mesh Profile specifies a proxy protocol using legacy Bluetooth connectivity, over which mesh messages can be exchanged.
Architecture
Seven different protocol layers have been defined, as illustrated in Figure 2. They are known as the bearer layer, the network layer, the lower transport layer, the upper transport layer, the access layer, the foundation model layer and the model layer.
Each layer has its own functions and responsibilities, and it provides certain services to the layer above it. Full details on the layers and their functionalities can be found in the Bluetooth Mesh specifications [3].
The network and transport layers are essential for network design and deployment strategies. The network layer handles aspects such as the addressing and relaying of messages, as well as network layer encryption and authentication. The lower transport layer handles segmentation and reassembly, and provides acknowledged or unacknowledged transport of messages to the peer device at the receiving end. The upper transport layer encrypts and authenticates access messages, and defines transport control procedures and messages. The latter is used to set up and manage the friendship feature, for example.
The choice of utilizing acknowledged or unacknowledged transport at the transport layer, and the selection of repetition scheme at the network layer, both represent means of controlling message delivery reliability and should be considered jointly. The reliability of the mesh network also depends on the performance of the lower layers and the utilization of the frequency resources used by the advertising channels.
All Bluetooth mesh nodes can transmit and receive messages. In addition, the nodes in a Bluetooth mesh network may support a set of optional features known as the relay, proxy, low-power and friend features. Nodes that support the relay feature can forward messages over the advertising bearer, facilitating communication between mesh nodes that are not within direct radio range. The proxy feature is used to forward messages between the advertising bearer and the GATT bearer (legacy Bluetooth Low Energy connections), so that even nodes with no support for the advertising bearer can be included in the mesh network.
The low-power feature facilitates low duty cycle operation of constrained mesh nodes. A node that makes use of the low-power feature must always be supported by a friend node, which stores incoming messages to the low-power node. Thanks to the assistance of the friend node, the low-power node can spend most of the time in sleep mode to save the battery.
Figure 3 provides an example of a simple Bluetooth mesh network. In this example, most nodes, such as the light bulbs, are mains powered and can continuously scan the advertising channels for incoming messages. Some of these nodes may also support the relay, proxy and friend features. Furthermore, in the topology of this example, the low-power temperature sensor uses the low-power feature and is assisted by one of the mains-powered nodes that has the friend feature implemented. Similarly, a smartphone that has no support for the advertising bearer communicates with the mesh network via a node that supports the proxy feature.
Network configuration options
The contention-based access to the Bluetooth advertising channels makes the ability to relay packets efficiently important to network performance. We want to highlight three configuration options: flooding restriction, message repetition and randomization. (This is not an official list from the standard, but rather our way of describing configuration options.)
With the flooding option, a message injected in the mesh network is potentially forwarded by every relay node that receives it. To avoid loops with infinite retransmissions, the Bluetooth mesh network layer introduces restrictions to the relaying of messages. The network cache method of doing this checks a received message against a cache of previously received messages, and relaying is restricted to messages that are not present in the cache. Time to live (TTL) can also be used to limit the number of times a message can be forwarded. The initial TTL value is determined by the source node, and decremented by one every time the message is relayed. Relay nodes only forward messages with a TTL value greater than one.
The Bluetooth Mesh Profile specification also allows for message repetitions at the network layer as a way of providing an appropriate level of reliability in the network. For example, when relaying a message, the network layer can be configured to send every network layer packet several times to the bearer layer below. The time between such message repetitions is configurable and should typically include a random component. As a recommended option to enhance the performance of mesh, the source repeats each message three times, whereas relays only retransmit each message once. The intuition behind this enhanced scheme is that the bottleneck of Bluetooth mesh in the considered scenario is often the first hop to inject the packet in the network. Once the neighboring relays receive the packet, there is a high chance that the packet propagates further to the intended destination due to the plurality of alternative paths in the mesh. Repetitions, however, have a negative impact in terms of advertising channel congestion for coexisting Bluetooth devices utilizing the same channels. As a general indication, the density of neighboring relays and the number of retransmissions at each relay need to be considered together to maximize network performance.
Randomization is the third option. By default, relay nodes scan the advertising channels for messages from neighboring nodes. The initial advertising channel to scan on is selected randomly (among the three advertising channels) and all channels are scanned periodically. When transmitting a message, nodes utilize advertising packets transmitted over all three advertising channels (channels 37, 38 and 39) [2]. It is recommended to add a random delay component within an advertising event. The use of a random time within the same advertising event is not explicitly defined by the Bluetooth Core v4.x specifications, and therefore it may not be implemented by some existing chipsets. However, adding a random delay is allowed if the total interval between advertising packets is shorter than 10ms [2]. Adding a random delay decreases the probability of collisions on all channels simultaneously. For mesh, assuming that multiple receiving relays are scanning on different channels, it increases the probability that a packet is propagated in the network.
A building automation use case
The first target use cases for Bluetooth mesh are in the building automation market, with the first deployments expected in connected lighting. One of the main characteristics of a building automation use case is that the message size is in the order of bytes and fits a single Bluetooth advertising packet. The average inter-arrival time is in the following ranges: light switches (two minutes to one day); heating, ventilation and air conditioning (HVAC) temperature sensors (one to 20 minutes); and occupancy and window sensors (five to 100 seconds). The deployment can be very dense, up to 0.5 devices/sq m, and total areas of thousands of square meters. The indoor propagation environment contains many inner walls and other constructions such as elevator shafts, which impact the radio signal.
Relays should be selected only among the powered nodes. As a best practice, relay nodes can be selected among nodes deployed in open areas, with preference given to corridors, so that every node is well within coverage of at least one relay node and that the network of relay nodes is connected. It is therefore possible to find a path between an arbitrary pair of nodes. Due to the uncertain propagation conditions, it is not always possible to optimize the deployment of the relays, and some redundant designs often need to be considered. Relay selection is not standardized by Bluetooth mesh, but the configuration of the relay functionality is flexible to adapt to more complex and dynamic procedures for future releases of the standard.
The network is served by one or more capillary gateways. HVAC devices, along with window and occupancy sensors, send their packets to the gateway, which forwards the data to an application in the cloud. Commands to HVAC actuators from the cloud application are sent via the gateway. Light bulbs are associated to light switches. More than one light bulb can be controlled by a light switch, and some bulbs are associated to more than one switch.
The network performance evaluation is based on a large-scale office automation scenario of the kind shown in Figure 4. A total of 879 devices, including window sensors, occupancy sensors, HVAC sensors and actuators, light switches and light bulbs are deployed in an area of 2,000sq m.
Three traffic setups were considered in the evaluation:
- a low traffic case with aggregate application throughput of ~150bps
- a medium traffic case with aggregate application throughput of ~1kbps
- a high traffic case with aggregate application throughput of ~3kbps
To benchmark the performance of the network, a baseline configuration was considered, utilizing only the mandatory components: message cache and TTL. To improve the performance, an enhanced configuration that also included first hop message repetitions and randomization of the advertising triplet was also evaluated. Both configurations were analyzed for a sparse relay deployment, with 12 relays uniformly distributed in the area to guarantee full coverage and a dense relay case with 49 relays redundantly deployed in the area.
The most crucial performance metric of the mesh network is the QoS, which we defined as the ratio of transmitted packets that reach the end destination within human perceivable time (300ms in this case). Studying relaying statistics also provides further insight into the behavior of the system.
For low traffic and sparse relay deployment, Bluetooth mesh performs satisfactorily with the baseline network configuration. Figure 5 shows that 99.1 percent of messages can be successfully delivered. Most packets are delivered within two hops, while a small number of message transactions require three hops, as can be seen in Figure 6. However, as the traffic increases, the baseline network configuration is not sufficient to cope with the higher channel congestion. This will be especially critical if the network deployment is not properly optimized and there is a risk of saturating the system by adding too many relay nodes.
Figure 7 shows the hop count distribution for the dense relay deployment case for the various traffic cases, in which it is sometimes necessary to forward a packet over four or five hops to get to the destination. In cases like these, careful network planning is needed in the deployment of the network.
Due to the channel congestion, the only way to obtain satisfactory performance with high traffic is by using the enhanced configuration for network layer retransmissions and randomization. By including the enhanced settings, the QoS of the network goes up to an expected level of >99.9 percent for five out of the six tested cases and up to 99.1 percent for the final dense relay deployment with high traffic (see Figure 5). All end points are reached within a 300ms delay, which is a typical requirement for lighting applications.
The best performance among the studied cases is obtained when deploying six relays every 1,000sq m, corresponding to roughly 1.5 percent of the total number of nodes. Note, however, that while this indication was obtained for the deployed installation, it may not be valid in general.
Conclusion
Bluetooth mesh is a scalable, short-range IoT technology that provides flexible and robust performance. The Bluetooth Mesh Profile is an essential addition to the Bluetooth ecosystem that enhances the applicability of Bluetooth technology to a wide range of new IoT use cases. Considering the large Bluetooth footprint, it has the potential to be quickly adopted by the market.
With proper deployment and configuration of relevant parameters of the protocol stack, Bluetooth mesh is able to support the operation of dense networks with thousands of devices. The building automation use case presented in this white paper shows that Bluetooth mesh can live up to high expectations and provide the necessary robustness and service ratio. Furthermore, the network design of Bluetooth mesh is flexible enough to handle the introduction of managed operations on top of flooding, to further optimize behavior and automate the relay selection process.
References
Contributors
The contributors to Ericsson's opinion on this topic are Piergiuseppe Di Marco, Per Skillermark, Anna Larmo and Pontus Arvidson.
Piergiuseppe Di Marco is a senior researcher at Ericsson Research in Stockholm, Sweden. He received a M.Sc. in telecommunications engineering from the University of L'Aquila in Italy in 2008 and a Ph.D. in telecommunications from KTH Royal Institute of Technology in Stockholm in 2013. Di Marco has also been a visiting scholar at the University of California, Berkeley, and a post-doctoral researcher at the ACCESS Linnaeus Centre at KTH Royal Institute of Technology and at the University of L'Aquila. In 2009, Di Marco received the Best Paper Award at the IEEE International Conference on Mobile Ad-hoc and Sensor Systems and, in 2014, the Best Conference Paper Award from the IEEE Sweden VT-COM IT Chapter. His research interests include wireless networking, standards and protocols for IoT, and 5G cellular networks.
Per Skillermark is a senior specialist in radio network modelling and performance at Ericsson Research in Stockholm. He holds a M.Sc. in applied physics and electrical engineering from Linköping University, Sweden. Skillermark is currently working on the development and standardization of low-power wireless communication systems, such as Bluetooth, and he is a member of the Bluetooth Architectural Review Board. He has previously worked with radio resource management in LTE. His research interests include medium access control principles, mesh networking and radio network performance analysis.
Anna Larmo is a master researcher who has been with Ericsson Research in Finland since 2004, where she has focused on radio protocols on different wireless systems. She received a M.Sc. in communication technology from the Helsinki University of Technology, Finland, in 2005. She is currently leading research in the wireless connectivity for the IoT domain with main focus on L1/2, and is responsible for the teams working on Bluetooth and Wi-Fi technologies.
Pontus Arvidson is a senior researcher within Wireless Access Networks at Ericsson Research. He received a M.Sc. in electrical engineering from KTH Royal Institute of Technology in 2010. Arvidson joined Ericsson in 2011, and his current research interests include radio resource management, radio network modelling and algorithm development for IoT. He is also an active member of the Bluetooth SIG.