Among the different releases of the Bluetooth protocol, the Bluetooth Low Energy (BLE) corresponds to its low-power variant and is a promising technology which allows to build low-power and low-cost networks composed by a large amount of nodes. BLE is presently raising more and more attention and is becoming one of the leading technologies for both IoT-oriented and industrial scenarios. Moreover, the relevance of BLE technology is due to the fact that it can be found as a natively implemented feature in the majority of current devices (e.g., laptops, smartphones, mobile tablets, and other smart devices), thus enabling users to interact with environmental BLE objects without the use of additional gateways. Despite that, most applications developed in last years focus on different network topologies, either point-to-point or star-based, where the smart device (i.e., a smartphone or another BLE-enabled device) acts as the center of the network. Looking at the technological aspects, BLE may be described as a short-range technology: in order to cover large areas or to allow complex networking behaviors, a multi-hop network is required. Therefore, BLE has recently shown a great attention even for its use as a reference technology to build mesh networks, in order to enable many-to-many communications in network scenarios. Hence, this general interest has led to the definition of a plethora of proprietary BLE-oriented networking solutions that generally lack of interoperabilty due to missing common mesh standards [30
]. A first change happened in 2017 thanks to the release of the official Bluetooth mesh networking standard specifications [34
] by the Bluetooth Special Interest Group (SIG).
With respect to the original and classical version of the Bluetooth protocol, able to achieve high-speed transmission, the low-power BLE protocol aims at significantly reducing the power consumption of a BLE node itself. Moreover, it is notable that BLE-enabled devices (especially those oriented to IoT) are generally battery-powered (by coin-cell batteries) and should operate for a long time (e.g., several years) with a limited duty cycle without the need for replacing the internal battery. Similarly to the classic Bluetooth, BLE uses frequencies in the range of 2402–2480 MHz, thus working in the 2.4 GHz band; at the opposite, BLE is provided with 40 2 MHz-spaced channels.
Looking at the operating plane, BLE provides two different communication ways among the devices participating to the communication: (i) advertising mode, in which a BLE node broadcasting packets allows its neighbors (within its transmission range) to receive the transmitted data; and (ii) connection-oriented mode, where the packet transmission happens only between two BLE nodes which, through a handshake, establish a direct connection. Focusing on these modes, in 2013 the iBeacon protocol [35
] has been announced by Apple with the goal of building applications and services in a location-aware fashion. Hence, in order to mark a BLE advertising packet as an iBeacon message, it has to contain the following information (useful for identifying the specific iBeacon device which sent the iBeacon message): (i) a 16-byte Universally Unique IDentifier (UUID), and (ii) two 2-byte fields identifying Major and Minor identifiers.
Even though both advertising and connection-oriented communication strategies can be used to implement a BLE mesh network, the SIG selected the former one as backbone mode for the mesh standard. In the BLE standard, nodes composing the mesh network are denoted as “nodes” and those which are not are called “unprovisioned devices”. The process which transforms an unprovisioned device into a node is called “provisioning”: this is a secure procedure resulting in an unprovisioned device getting a series of encryption keys and being known to the Provisioner device (typically a tablet or a smartphone). One of these keys is called NetKey and all nodes in the mesh network must possess at least one NetKey, as the possession of this key (together with other requirements) makes a device a member of the network and, namely, a node. Some BLE nodes can have multiple constituent parts, each of which can be independently controlled. In Bluetooth Mesh terminology, these parts are called “elements”. An example of a BLE device with multiple elements can be a LED lighting product which, if added to a Bluetooth mesh network, would form a single node with three elements, one for each individual LED light.
Communication in the mesh network is message-oriented. Messages exchanged between nodes can have different types, each one with a defined unique “opcode”. Moreover, messages can be acknowledged or unacknowledged. An acknowledged message requires a response from the node that receives it, which has two purposes: (i) it confirms that the message has been received and (ii) it returns data to the sender, if needed. The sender of an acknowledged message may resend the message if it does not receive the expected response(s) and, therefore, acknowledged messages must be idempotent. This means that the effect of a given acknowledged message, arriving at a node multiple times, will be the same as it had only been received once. Unacknowledged messages, instead, do not require any response.
Messages must be sent by nodes to an address. The Bluetooth Mesh standard defines the following three types of addresses.
Unicast address, identifying a single element or a node in the network in a unique way. A unicast address is assigned to a device during the provisioning process, when it becomes part of the network.
Group address, corresponding to a multicast address able to represent either a single element or node, as well as multiple elements or nodes. Moreover, group addresses can be either assigned dynamically (i.e., established by the user via a configuration application), as well as fixed by the official SIG group (in this case, denoted as SIG Fixed Group Addresses).
Virtual address, corresponding to a 128-bit UUID that can be assigned to either one or more elements, as well as to a single or multiple nodes.
The Bluetooth Mesh standard architecture follows, as communication paradigm, the publish/subscribe model, in which the publisher node sends its data on a well-defined topic, while several subscriber nodes, manifesting their interest in such data information, listen to one or more of the available topics. Moreover, nodes are thus configured to select messages sent to specific addresses for processing, and in the Bluetooth Mesh standard this is the “subscribing” operation. A node in a Bluetooth mesh network maintains a subscriber list (containing the subscribers addresses and its unicast address) and the publish address with the single address onto which publish contents. Before joining a selected mesh group , a node has to add in the subscriber addresses list; after that a node is able to forward a packet to addressing the unicast identified of or through the address to which belongs to. The links created in the network among publishers and subscribers generate a mesh topology, with the main advantage that if nodes are removed, replaced or a new node is added, other nodes in the network should not be reconfigured.
To implement the communication, the BLE standard provide two kinds of procedures, namely advertising and scanning operations. In detail, flooding is the mechanism through which messages are exchanged in a BLE mesh network, thus ensuring that each intermediate node N is able to relay incoming messages till the target node. In addition, Bluetooth mesh nodes differ from BLE advertising ones in the way that they do not consider an advertising interval for sending their packets, instead directly sending them after a back-off time which is randomly generated. Moreover, the mesh nodes has a 100% duty cycle for scanning incoming packets on the advertisement channels. This means that nodes are continuously scanning when they are not sending a packet. The advertisement in the standard is managed through a new type of BLE packet, which is supported only by devices able to work with both BLE and Bluetooth Mesh protocol. To maintain an acceptable interoperability degree, the standard considers a backwards compatibility feature, in this way allowing all BLE devices not supporting Bluetooth Mesh to join anyway a Bluetooth mesh network. In a mesh network, each node can transmit and receive messages but the standard considers several optional features which a mesh node N can implement, in order to manage and enhance the communication. The main additional features can be summarized as follows.
Relay feature: since the scalability and the robustness of the network can be reduced, if not properly managed, by the adoption of the flooding mechanism (as required by the standard), then, in order to avoid inefficiencies, the relay feature requires that only relay-enabled nodes in the network are allowed to forward received messages further in the network. Another additional features are the message cache and the Time-To-Live (TTL) field, which ensure that a a message M will be relayed by a device N only once. In fact, N only relays M if: (i) M is not already stored in the cache memory of the device N and (ii) the TTL value proper of the message M is greater than 1. Moreover, each time M is relayed further into the network, then its TTL field value is decreased by 1.
Proxy feature: this feature has been defined aiming at maintaining compatibility with all BLE devices not supporting Bluetooth Mesh. A node N with the proxy feature enabled can perform communication in two ways: (i) employing the default BLE mesh advertising method, and (ii) using the backwards compatibility feature that is based on traditional BLE connections.
Friendship and Low-Power feature: since the standard forces nodes to scan advertisement channels with a 100% duty cycle, this strongly affects the low-energy aspect of BLE advertising precluding the use of mesh networking in all power-constrained applications. The friendship feature has been introduced to overcome this limitation, allowing a power-limited device P to join the mesh network without the 100% duty cycle. Another, not constrained, node N can establish a friendship relationship with P becoming its friend. In the mesh network, friend nodes are in charge to store and to relay further all incoming messages. Then, the low-power node P can ask to N for new messages with a rate compatible with its reduced duty cycle, and limiting its power usage.
In Figure 4
a, examples for each different feature of the standard are shown. In Figure 4
b, the BLE protocol stack is shown. This stack corresponds to a layered architecture, on top of which applications can be implemented. The following layers appear in the stack.
Bluetooth Low Energy Core Specification layer: this bottom layer provides basic wireless communications capabilities on top of which the whole mesh architecture is built (either using connection-oriented and advertising mechanisms).
Bearer layer: this layer defines the interfaces (also denoted as “bearers”) between the underlying core specification and the upper layers, through two interfaces: the (i) ADV bearer, managing the BLE advertisement processes, and (ii) the GATT bearer, managing BLE connections.
Network layer: this layer implements security aspects and defines the various message address types and a network message format which is employed in the bearer layer.
Transport layer: this layer manages both segmentation and reassembly of larger messages into the original message, thus passing them to the Application level.
Access layer: works as an interface between the application-oriented layers above and the technology-oriented layers below. The main aim of the Access layer is to guarantee the correctness of all messages exchange between lower layers and application layer.
], an analysis of the performance of a small-scale BLE mesh network (composed by Nordic nRF52832 modules on top of which the Nordic implementation of the Bluetooth Mesh standard is running), using link communication delays as metrics, is presented.
Besides SIG, also the IETF has worked on its own BLE mesh standard based on its IPv6-related standards initially published for the IEEE 802.15.4 technology, more specifically IPv6 Routing Protocol for Low-Power and Lossy Networks (RPL) and IPv6 over Low-Power Wireless Personal Area Network (6LoWPAN), this has led to two approaches for adapting 6LoWPAN aiming at making BLE mesh network supporting IPv6: “IPv6 Mesh over Bluetooth Low Energy using IPSP” [37
] and “IPv6 over Bluetooth Low Energy” [38
] specifications. The IETF Bluetooth Mesh protocol is based on the assumption of the existence of connections at link layer among a node N
and other nodes in its neighbourhood (say
) allowing to exchange different IPv6 packets. In turn, these links are established adopting the Internet Protocol Support Profile (IPSP) [39
] and using a 6LoWPAN-based adaptation layer between L2CAP and IPv6, which in turn provides: (i) an optimized IPv6 neighbor discovery mechanism; (ii) User Datagram Protocol (UDP) and IPv6 header compression mechanisms (thus improving the communication efficiency); and (iii) network configuration mechanisms (especially suitable for constrained devices). Finally, even if the adopted routing protocol is not forced by the draft specification [37
], in this case the routing useful to find communication paths from an end device to another is at the IP layer. Lastly, the work described in [40
] provides a delivery rate and energy consumption performance analysis of IPv6-based BLE mesh networks with very minimal topologies (at most 3 nodes).
4.2. Other Solutions
The Bluetooth Mesh standard has not been designed to support real-time communications over multi-hop mesh networks. To overcome this limitation, in [41
] the authors describe the Multi-hop Real-time BLE (MRT-BLE): a real-time protocol built on top of the BLE standard, which is able to implement mesh networks with BLE devices. The proposed MRT-BLE protocol is connection-oriented, since the connection mode is generally characterized by a higher throughput with respect to a connection-less approach. Moreover, the connection-oriented model allows to employ 37 channels for hopping, instead of the 3 that are available in the connection-less one. The core feature of the proposed MRT-BLE protocol resides in the fact that the network is split into a set of sub-networks coordinated by a master node. Sub-networks are linked by a device that, acting as a bridge, behaves both as a slave and a master node. To show the feasibility of the proposed protocol the authors implement it on the X-NUCLEO-IDB05A1 devices produced by STMicroelectronics and provide a performance analysis.
As the SIG Bluetooth Mesh specifications is recent, in recent years chip vendors and researchers made efforts to develop mesh protocols for BLE devices. In 2014, a proprietary flood-based mesh protocol for BLE, denoted as CSRmesh, was released by CSR Inc. [32
]. The CSRmesh protocol is highly scalable (support up to 65535 nodes) and has a measured propagation delay between nodes shorter than 15 ms. In [32
], the packet delivery ratio of different setups using CSRmesh protocol is investigated. The presented results show that the flooding approach, even if simpler than route-based approaches, is not the optimal solution in traffic intensive applications. Another option to enable mesh networking with BLE devices is the nRF OpenMesh [42
], a flooding mesh protocol for BLE, developed by Nordic Semiconductor Inc. nRF OpenMesh is based on the Trickle algorithm [43
] that, considering the node density and value update frequency as metrics, is able to dynamically control the rebroadcasting behavior of mesh nodes. An Opportunistic Routing (OR)-based mesh protocol, denoted as BLEmesh, was also proposed in [30
], before the release of the SIG standard. In the BLEmesh approach, a source node S
broadcasts messages to a set of nodes, selected in an opportunistic way, among those which successfully received the packets. With respect to conventional routing protocols for wireless mesh networks, the OR-based ones requires to broadcast less packets to accomplish the transmission, which also results in a minor power consumption. As previously described, the Bluetooth Mesh standard uses the advertising communication mode and is based on flooding mechanisms—we remark that the vast majority of proprietary BLE mesh protocols make use of the advertising approach. Despite that, in [44
] the authors try to compare the performance of flooding and connection-oriented networking considering the Packet Delivery Ratio (PDR), end-to-end latency, and power consumption as metrics. The conclusion is not definitive, as the obtained results show that none of the mesh BLE approaches can offer optimal performance for all metrics simultaneously. Therefore, the right choice is led by the specific application requirements. In [44
], a hybrid BLE mesh approach, denoted as Bluetooth Now paradigm, is proposed, allowing able to use both advertising and connection modes. More in detail, in Bluetooth Now-based networks, nodes runs in connected mode to send periodic and non-time-sensitive data to the sink, while switching to flooding to deliver sporadic and urgent data.
A comprehensive analysis of available alternative solutions for BLE mesh is provided in [45
], where a taxonomy for BLE mesh network solutions is presented considering two main categories besides the standard solution, namely academic and proprietary.
The SIG Bluetooth Mesh standard is still relatively recent and solutions employing this standard are under development. Despite that, the use of mesh networks based on BLE devices is of great interest and has applications in different fields. In the following, some examples are provided.
One of the most relevant applications of BLE technology is localization: in this context, the use of a mesh network allows to cover larger areas and to connect multiple subnetworks. In [46
], the authors propose a BLE-based location tracking system to monitor livestock behavior collecting useful information about animals health and welfare. In the proposed approach, BLE nodes are used for continuous tracking of cows in a barn through a self-organizing multi-hop mesh network which collects the data. This data is processed with an advanced tracking algorithm that copes with signal fading and body shadowing. The mesh network is implemented using a BLE 4.1-based open source implementation of a mesh network, denoted as FruityMesh. Concerning localization, in [47
] the authors present a localization system able to support real-time communications between interactive nodes (through the joint adoption of mesh topology and broadcast options useful for beacon solutions). More in detail, the proposed development is composed by beacon devices (namely, smartphones) able to form a mesh network. This allows to show that smartphones are able to detect, at specific locations, those users of interest, while this information is ready to be forwarded to the collector through relay devices. This kind of solution presents the advantage of being able to manage the communication entirely through the BLE Mesh network, while end users are not required to look for a mobile connection for reaching services in the backend system.
Another relevant application scenario for BLE mesh is the Smart City context. The work described in [48
] presents a novel approach to implement smart city-oriented services based on SIG BLE mesh standard specifications. Experimental results show that collected information can be forwarded among BLE nodes even in the presence of an already existing Metropolitan Area Network (MAN). The focus of [49
] is on Proximity Services (ProSe), which can be classified into two categories: public safety communication and social discovery. The authors present the implementation of a multi-hop BLE mesh in which a proactive routing mechanism with Received Signal Strength Indicator (RSSI) link-quality assistance is proposed. Then, a ProSe development framework, denoted as BLE Mesh is presented, with the aim to provide significant benefits for application developers, framework maintenance professionals, and end users to build ProSe apps easily and quickly.
The last topics in which the usage of the BLE for building mesh networks is emerging as a relevant solution is the Industry 4.0 and the industrial monitoring scenario. In [41
], the problem of real-time industrial environments monitoring is addressed with a multi-hop mesh BLE topology. In [50
], authors propose a Fog Computing-based architecture designed for Industrial Cyber-Physical System (ICPS) and aimed at supporting low-latency distributed applications (oriented to the Industry 4.0 paradigm) which normally offload processing and traffic resource consumption from high-level systems (e.g., the Cloud).