Bluetooth® technology  uses low-power radio frequency to enable short-range communication at a low cost. In 2010, Bluetooth 4.0 introduced a new variant known as Bluetooth low energy (BLE), or Bluetooth Smart. BLE supports a point-to-multipoint or broadcast communication that is useful for a short-range navigation beacon mode such as real-time locating systems used for asset-tracking and people tracking. Auxiliary improvements to Bluetooth technology were released with the introduction of Bluetooth 5.0 . In addition to Bluetooth 5.0, the Bluetooth Special Interest Group (SIG) defined a new connectivity model for BLE, known as the Mesh Profile . The BLE Mesh Profile establishes the option of many-to-many communication links for BLE devices and is optimized for creating large scale Internet of Things (IoT) networks. The mesh stack defined by the BLE Mesh Profile is located on top of the BLE core specification. For more information about the mesh stack, see Bluetooth Mesh Stack. This new mesh networking capability of Bluetooth is ideally suited for building automation, large scale sensor networks, and other IoT solutions that require tens and hundreds of devices to be reliably and securely set up.
As mesh networking topologies offer the best way to satisfy different increasingly common and popular communications requirements, Bluetooth mesh networking was introduced. Some of the fundamental requirements include:
Low energy consumption
Extension of the coverage area through multihop communication
Increased network scalability through efficient use of radio resources
Interoperability with different standards
Increased communications security through authentication and encryption
Improved system reliability through multipath message-oriented communication
Ability to deliver optimal network responsiveness
Other low-power wireless communication technologies, such as ZigBee® and Thread, also support mesh networking topologies. However, these technologies often face issues such as low data rates, restricted number of hops when relaying data across the mesh, limitations in scalability often caused by the way radio channels are used, and delays when following procedures to change the device composition of the mesh topology. Additionally, these wireless communication technologies are not supported by standard smartphones, tablets, and PCs. The Bluetooth mesh meets the previously mentioned requirements and creates an industry-standard mesh communications technology based on BLE.
Bluetooth mesh networking integrates the trusted, global interoperability with an evolved, trusted ecosystem to create industrial-grade device networks.
This figure illustrates how the Bluetooth mesh stack fits into the standard BLE protocol stack. The figure shows the Bluetooth mesh stack over the BLE advertising bearer and generic attribute (GATT) bearer.
The Bluetooth mesh stack consists of these layers:
Model layer: This layer defines the models, messages, and states required for use-case scenarios. For example, to change the state of a light to On or Off, the Bluetooth nodes use the Generic OnOff Set message from the Generic OnOff model.
Foundation model layer: This layer defines the models, messages, and states required to configure and manage the mesh network. This layer also configures element, publish, and subscription addresses.
Access layer: This layer defines the interface to the upper transport layer and the format of the application data. It also controls the encryption and decryption of the application data in the upper transport layer.
Upper transport layer: This layer defines functionalities such as encryption, decryption, and authentication of the application data and is designed to provide confidentiality of access messages. This layer is also responsible for generating transport control messages (Friendship and heartbeat) internally and transmits those messages to a peer upper transport layer. The network layer encrypts and authenticates these messages.
Lower transport layer: This layer defines functionalities such as segmentation and reassembly of upper transport layer messages into multiple lower transport layer messages to deliver large upper transport layer messages to other nodes. This layer also defines the friend queue used by the Friend node to store the lower transport layer messages for a Low Power node.
Network layer: This layer defines functionalities such as encryption, decryption, and authentication of the lower transport layer messages. This layer transmits the lower transport layer messages over the bearer layer and relays the mesh messages when the Relay feature is enabled. The network layer also defines the message cache containing all recently seen network messages. If the received message is found to be in the cache, then it is discarded.
Bearer layer: This layer defines the interface between the Bluetooth mesh stack and the BLE protocol stack. This layer is also responsible for creating a mesh network by provisioning the mesh nodes. The two types of bearers supported by the Bluetooth mesh are advertising bearer and GATT bearer.
BLE is the wireless communications protocol stack of which the Bluetooth mesh makes use. For more information about BLE protocol stack, see BLE Protocol Stack.
Most BLE devices communicate with each other using a simple point-to-point (one-to-one communication) or point-to-multipoint (one-to-many communication) topology as shown in this figure.
Devices using one-to-one communication operate in a Bluetooth piconet. As shown in this figure, each piconet consists of a device in the role of Master (M), with other devices in the Slave (S) or Advertiser roles. Before joining the piconet, each S node is in an advertiser role. Multiple piconets connect to each other, forming a Bluetooth scatternet.
For example, a smartphone with an established one-to-one connection to a heart rate monitor over which it can transfer data is an example of point-to-point connection.
On the contrary, the Bluetooth mesh enables you to set up many-to-many communication links between Bluetooth devices. In a Bluetooth mesh, devices can relay data to remote devices that are not in the direct communication range of the source device. This enables a Bluetooth mesh network to extend its radio range and encompass a large geographical area containing a large number of devices. Another advantage of the Bluetooth mesh over point-to-point and point-to-multipoint topologies is the capability of self healing. The self-healing capability of the Bluetooth mesh implies that the network does not have any single point of failure. If a Bluetooth device disconnects from the mesh network, other devices can still send and receive messages from each other, which keeps the network functioning.
These concepts of Bluetooth mesh networking serve as the foundation to study the functionality of a Bluetooth mesh network.
Devices that belong to a Bluetooth mesh network are known as nodes. Devices that are not a part of a Bluetooth mesh network are known as unprovisioned devices. The process of transforming an unprovisioned Bluetooth device into a node is called Provisioning. Each node can send and receive messages either directly or through relaying from node to node. This figure shows a web of Bluetooth nodes spread across the MathWorks, Natick office.
Each Bluetooth mesh node might possess some optional features enabling them to acquire additional, special capabilities. These features include the Relay, Proxy, Friend, and the Low Power features. The Bluetooth mesh nodes possessing these features are known as Relay nodes, Proxy nodes, Friend nodes, and Low Power nodes (LPNs), respectively.
Relay nodes: Bluetooth mesh nodes that possess the Relay feature are known as Relay nodes. These nodes use the relaying mechanism to retransmit the received messages through multiple hops. Depending on the power source and computational capacity, a mesh node might become a Relay node.
Proxy nodes: To enable communication between a BLE device that do not possess a Bluetooth mesh stack and the nodes in the mesh network, proxy nodes can be used. A Proxy node acts as an intermediary and utilizes the proxy protocol with generic attribute profile (GATT) operations. For example, as shown in the preceding figure, a smartphone that does not support the Bluetooth mesh stack interacts with mesh nodes by a Proxy node through GATT operations.
Friend node: Bluetooth mesh nodes that do not have any power constraints are good exemplars for being Friend nodes. LPNs work in collaboration with Friend nodes. A Friend node stores messages destined to an LPN and delivers the messages to the LPN whenever the LPN polls the Friend node for the waiting messages. The relationship between an LPN and a Friend node is called Friendship.
Low Power node: Bluetooth mesh nodes that are power constrained can use the Low Power feature to minimize the On time of the radio and conserve energy. Such nodes are known as LPNs. LPNs are predominantly concerned with sending messages but have a need to occasionally receive messages. For example, a temperature monitoring sensor that is powered by a small coin cell battery sends a temperature reading once per minute whenever the temperature is above or below the configured threshold values. If the temperature stays within the thresholds, the LPN sends no message.
For more information about Bluetooth mesh features, see sections 3.4.6, 126.96.36.199, 188.8.131.52, and 7.2 of the Bluetooth Mesh Profile .
Some Bluetooth mesh nodes possess one or more independent constituent parts known as elements. This figure shows that a mesh node must have at least one element (primary element) but can have multiple elements.
Elements consists of entities that define the functionality of a node and the condition of the element. Each element in a mesh node has a unique unicast address that enables each element to be addressed.
This figure shows the mesh node and its constituents. The basic functionality of a mesh node is defined and implemented by models. Models reside inside elements, and each element must have at least one model.
Bluetooth Core Specifications  defines these three categories of models.
Server model: This model defines a collection of states, state transitions, state bindings, and messages that the element containing the model can send or receive. It also defines behaviors pertaining to messages, states, and state transitions.
Client model: This model defines the messages that it can send or receive in order to acquire values of multiple states defined in the corresponding server model.
Control model: This model comprises of a server model and client model. The server model enables communication with other client models, and the client model enables communication with server models.
A state is a value of a certain type that defines the condition of elements. Additionally, states also have associated behaviors. For example, consider a simple light bulb that can be either On or Off. The Bluetooth mesh defines a state called generic OnOff. When the light bulb acquires this state and a value of On, the bulb is illuminated. Similarly, when the light bulb acquires the generic OnOff state and a value of Off, the bulb is switched off.
For more information about Bluetooth mesh models and states, see section 4 of the Bluetooth Mesh Profile .
Bluetooth Core Specifications  defines these four types of addresses.
Unassigned address: Nonconfigured elements or elements without any designated addresses have an unassigned address. Mesh nodes with unassigned addresses are not involved in messaging.
Unicast address: During provisioning, a provisioner assigns a unicast address to each element in a node. Unicast addresses can appear in the source address field of a message, the destination address field of a message, or both. Messages sent to unicast addresses are processed by only one element. For more information about provisioning, see Provisioning.
Virtual address: A virtual address represents a set of destination addresses. Each virtual address logically represents a 128-bit label universally unique identifier (UUID). The Bluetooth nodes can publish or subscribe to these addresses.
Group address: Group addresses are types of multicast addresses that represent multiple elements from one or more nodes. Group addresses can be fixed (allocated by Bluetooth SIG) or dynamically assigned.
Communication in Bluetooth mesh networks is realized through messages. A message can be a control message or an access message.
Control message: These messages are involved in the actual functioning of the Bluetooth mesh network. For example, heartbeat and friend request messages are types of control messages.
Access message: These messages enable client models to retrieve or set the values of states in server models. Access messages can be acknowledged or unacknowledged. Acknowledged messages are transmitted to each receiving element. The receiving element acknowledges the messages by sending a status message. No response is sent to an unacknowledged message. Bluetooth mesh network status messages are an example of unacknowledged messages.
For every state, the server model supports a set of messages. For example, these message can include a client model requesting the value of a state or requesting to change a state and a server model sending messages about the states or a change in the state.
Messages are identified by opcodes and have associated parameters. A unique opcode defines these three types of mesh messages:
GET message: This mesh message requests the state value from one or more nodes.
SET message: This mesh message changes the value of a given state.
STATUS message: This mesh message is used is these scenarios.
In response to a GET message containing the state value
In response to an unacknowledged SET message
Sent independently to report the status of an element
For more information about Bluetooth mesh addresses, see section 3.4.2 of the Bluetooth Mesh Profile .
Bluetooth mesh networking implements a publish/subscribe message-oriented communication system. Such an approach ensures that different types of products can coexist in a mesh network without being affected by messages from devices they do not need to listen to. The act of sending a message is known as publishing. Based on the configuration, the mesh nodes select messages sent to specific addresses for processing. This technique is known as subscribing. A publisher node sends messages to those nodes that have subscribed to the publisher. Typically, mesh messages are addressed to group or virtual addresses.
Consider the example shown in this figure. Each room can subscribe to messages from the specific light bulbs for that room. Additionally, these messages can be unicast, multicast, broadcast, or any combination of these three options.
Switch #1 publishes to the group address Dinning Room. Light bulbs 1, 2, and 3 each subscribe to the Dinning Room address and therefore process messages published to this address. Switch #2 publishes to the group address Kitchen. Light bulb 3 subscribes to the Kitchen address and is the only bulb controlled by Switch #2. Similarly, Switch #3 publishes to the group address Bedroom and hence controls light bulbs 4 and 5. This example also shows that the mesh nodes can subscribe to messages addressed to more than one unique address.
The group and virtual addresses used in the publish/subscribe communication system enables removing, replacing, or adding new nodes to the mesh network without any reconfiguration. For example, an additional light bulb can be added in Kitchen using the Provisioning process and then configured to subscribe to the Kitchen group address. In this process, no other light bulbs are impacted.
For more information about the Bluetooth mesh publish/subscribe communication, see section 2.3.8 of the Bluetooth Mesh Model Specification .
Provisioning is the process by which a Bluetooth device (unprovisioned device) joins the mesh network and becomes a Bluetooth node. This process is controlled by a provisioner. A provisioner and the unprovisioned device follow a fixed procedure as defined in the Bluetooth Mesh Profile . A provisioner is typically a smartphone running a provisioning application. The process of provisioning can be accomplished by one or more provisioners. This figure shows the five steps of provisioning.
Beaconing: In this step, the unprovisioned Bluetooth device advertises its availability to be provisioned by sending the mesh beacon advertisements in the advertisement packets. A typical way to trigger beaconing is through a specified sequence of button clicks on the unprovisioned Bluetooth device.
Invitation: In this step, the provisioner invites the unprovisioned Bluetooth device for provisioning by sending a provisioning invite protocol data unit (PDU). The unprovisioned Bluetooth device responds with information about its capabilities by sending a provisioning capabilities PDU.
Public key exchange: In this step, the provisioner and the unprovisioned device exchange their public keys. These public keys can be static or ephemeral, either directly or using an out-of-band (OOB) method.
Authentication: In this step, the unprovisioned device outputs a random, single or multidigit number to the user in some form, using an action appropriate to its capabilities. The authentication method depends on the capabilities of both devices used. Irrespective of the authentication method that the Bluetooth node uses, the authentication also includes a confirmation value generation step and a confirmation check step.
Provisioning data distribution: After successfully completing the authentication step, the provisioner and the unprovisioned device generate a sesion key by using their private keys and the exchanged peer public keys. The provisioner and the unprovisioned device use the session key to secure the subsequent exchange of data needed to complete the provisioning process. This process includes the distribution of a security key called the network key (NetKey). After provisioning is completed, the provisioned device acquires the NetKey, a mesh security parameter called IV Index, and a unicast address assigned by the provisioner. At this point, the Bluetooth device can be termed as a Bluetooth node.
For more information about the Bluetooth mesh provisioning, see section 5 of the Bluetooth Mesh Profile .
To reduce the duty cycles of the LPN and conserve energy, the LPN must establish a Friendship with a mesh node supporting the Friend feature. This figure from  shows the relationship between LPNs and Friend nodes.
LPNs 5, 6, and 7 have a Friendship relationship with Friend node 20. Friend node 18 has Friendship with LPNs 11 and 12. Subsequently, Friend node 20 stores and forwards messages addressed to LPNs 5, 6, and 7. Similarly, Friend node 18 stores and forwards messages addressed to LPNs 11 and 12. Forwarding by the Friend node occurs only when the LPN wakes up and polls the Friend node for messages awaiting delivery. This mechanism enables all of the LPNs to conserve energy and operate for longer durations.
This figure shows the Bluetooth mesh messages exchanged between an LPN and a Friend node to establish Friendship.
The Bluetooth nodes use these timing parameters to establish Friendship:
Receive delay: This parameter specifies the time between when an LPN sends a request and listens for a response from the Friend node. The LPN is in sleep state for the complete duration of the receive delay.
Receive window: This parameter specifies the time for which an LPN listens for a response from a Friend node. The LPN is in the scanning state for the complete duration of the receive window.
Poll timeout: This parameter specifies the maximum time between two successive requests from an LPN. Within the poll timeout, if the Friend node or the LPN fails to a receive request or response from the other node, the Friendship is terminated.
Periodically, LPNs poll Friend nodes for any data messages stored in the friend queue. After polling the Friend node, the LPN enters a sleep state for the duration of receive delay. The Friend node uses the receive delay to prepare the response for the LPN. After the receive delay, the Friend node responds to the LPN before the sum of the receive delay and the receive window. For more information about Friendship, see Energy Profiling of Bluetooth Mesh Nodes in Wireless Sensor Networks example.
For more information about Friendship, see section 3.6.6 of the Bluetooth Mesh Profile .
Many mesh networks implement routing mechanisms to relay messages in the network. Another mechanism to relay messages is to flood the network with messages being relayed without any consideration of the optimal routes to reach their respective destinations. Bluetooth mesh networking uses an approach known as managed flooding that comprises of both of these mechanisms. Bluetooth mesh networking leverages the strengths of the flooding approach and optimizes its operations such that it is both reliable and efficient. This figure demonstrates the process of managed flooding in the Bluetooth mesh.
The figure illustrates communication between a switch and a connected light bulb in a Bluetooth mesh. Initially, the switch and bulb are in the Off state. Changing the switch to the On state broadcasts a message to turn on the bulb. All of the mesh nodes in range of the switch hear the message, but only the relay nodes retransmit the message. The message is relayed in this manner across the network until it reaches the bulb and turns on the bulb. This process is termed as managed flooding. To optimize this process, Bluetooth mesh implements these measures.
Heartbeat messages: These messages are transmitted by mesh nodes periodically to indicate to other mesh nodes that the node sending the heartbeat is still active. Heartbeat messages contain information that enables the receiving nodes to determine the number of hops between it and the sending node.
Time to live (TTL): This field is present in all Bluetooth mesh PDUs. It manages the maximum number of hops over which a message is relayed. Setting the TTL value enables mesh nodes to have control over relaying and to conserve energy. Heartbeat messages enable nodes to determine the optimal TTL value required for each published message.
Message cache: Every mesh node contains a message cache to determine whether it has seen a message before. If the node has seen the message before, the node discards the message and avoids unnecessary processing higher up the stack.
Friendship: For more information about the Friendship mechanism, see Friendship.
For more information about managed flooding in Bluetooth mesh networks, refer Bluetooth Mesh Flooding in Wireless Sensor Networks example.
The addition of mesh capabilities to Bluetooth creates opportunities for applying Bluetooth mesh networking in automation and IoT domains. These are some of the prominent applications of Bluetooth mesh networking.
Smart home automation — Bluetooth mesh networking can be used to simplify the smart home automation processes by enabling a mesh network of devices (such as smart bulbs, thermostats, and vents) readily established and provisioned with the user's smartphone. A Bluetooth mesh network of such connected devices can be used to relay messages through multiple paths, thus increasing the communication reliability and network scalability. Bluetooth mesh does not have any single point of failure. This prevents service outages if a mesh node fails. For example, consider a home scenario with a Bluetooth mesh network of all lighting devices. If some of the lighting devices in the mesh network fail, the messages from the rest of the mesh can still reach the user’s control device.
Beaconing — One of the prominent use case of Bluetooth mesh networking is the beaconing. In beaconing, an external event triggers a mesh node to transmit data. This data can include sensor information, location information, or point-of-interest information. Any mesh node can integrate one or more beacon standards (such as iBeacon of Apple or EddyStone from Google) and can be transformed into a virtual Bluetooth beacon while operating as a Bluetooth mesh node. This approach can enable new use-case scenarios, such as indoor positioning, asset tracking, and point-of-interest information delivery. Use cases involving Bluetooth direction finding (introduced in Bluetooth Core Specifications 5.1 ) implement beaconing to support high-accuracy direction finding. Bluetooth mesh combined with direction-finding features such as angle of arrival and angle of departure can pave way for many commercial IoT-based use case scenarios. For more information about beaconing and Bluetooth direction-finding capabilities, refer Bluetooth Location and Direction Finding topic.
Automated irrigation systems and plant lighting — Bluetooth mesh networks can be used to develop intelligent solutions in automated irrigation systems and plant lighting. For example, as land resources decline, many plants are grown in greenhouses for higher harvesting yields. Automated indoor planting needs a combination of appropriate light source with a smart control system and a Bluetooth mesh network. In this scenario, Bluetooth mesh modules are placed into the light sources. This mechanism enables the mesh modules to automate the control of the light source, soil moisture, air temperature, moisture, humidity, and automatic irrigation.
Low latency — Bluetooth mesh networks can be useful in low-latency use-case scenarios. In networks where round-trip time is of a high significance, specific functional nodes and relay nodes can be used to minimize the communication delay while maintaining coverage and reliability.
Mesh networking with the Bluetooth standard can be used in intelligent IoT solutions to facilitate home, commercial, and industrial automation. In summary, Bluetooth mesh networking is comparable to all other Bluetooth connectivity and establishes hub-less networks that expand the coverage and reliability of Bluetooth systems.
 Bluetooth Technology Website. “Bluetooth Technology Website | The Official Website of Bluetooth Technology.” Accessed March 22, 2020. https://www.bluetooth.com/.
 Bluetooth Special Interest Group (SIG). "Bluetooth Core Specification." Version 5.0. https://www.bluetooth.com/.
 Bluetooth Special Interest Group (SIG). "Bluetooth Core Specification." Version 5.1. https://www.bluetooth.com/.
 Bluetooth Special Interest Group (SIG). "Bluetooth Mesh Profile." Version 1.0.1. https://www.bluetooth.com/.
 Bluetooth Special Interest Group (SIG). "Bluetooth Mesh Model Specification." Version 1.0.1. https://www.bluetooth.com/.