Overview

This section describes the functionality of the Bluetooth Mesh features and provides a list of APIs to interface with Bluetooth Mesh. The TI Mesh offering consists of Mesh models, provisioning and an example application.

TI Bluetooth Mesh is implemented on top of the Zephyr Mesh project. For more information on this, refer to TI Bluetooth Mesh and the Zephyr Project.

Introduction

A general mesh network has a many-to-many topology, where each device is able to communicate with every other device in the mesh network. Communication is achieved using messages, and devices are able to relay messages to other devices so that the end-to-end communication range is extended far beyond the radio range of each individual node.

Basic communication over a mesh network is based on flooding. This means that each node acts as a relay node, forwarding all messages that have been received (except messages designated to the local node). Managed flooding is a related term and means that time to live and message caching mechanisms are implemented. This is used to reduce the flooded traffic over the network. Enhanced implementations include management of forward paths to further optimize the forwarded traffic load.

The Mesh network support over Bluetooth is standardized by the Bluetooth SIG in the Bluetooth Mesh specifications and defines fundamental requirements to enable an interoperable mesh networking solution for Bluetooth low energy wireless technology.

Bluetooth Mesh Basics

Layers of Bluetooth Mesh

Figure 127. shows the layers of Bluetooth Mesh. Starting from the bottom up, the Bluetooth Mesh standard enables overlay of a complete protocol stack on top of a Bluetooth LE protocol stack. The BLE-Stack provides bearer services, both connectionless (advertisement based) or connection-oriented (GATT based) connectivity. At the GATT bearers’ level, Bluetooth Mesh is seen as a profile where attributes are used to exchange mesh data.

Figure 127. Layers of Bluetooth Mesh

Starting from the bottom, the Bluetooth Mesh protocol stack layers provide the following functionalities and services:

• The bearer layer

  • Transport of network messages between connection-less nodes (advertisement based) and the connection bearers (GATT based)

• The network layer

  • Network addressing of transport messages towards one or more elements (unicast/group/virtual)

  • Network message format definition which allows transport PDUs to be transported by the bearer layer

  • Network message handling including relay/forward, accept further processing, or reject message.

  • Encryption and authentication of network messages

• The lower transport layer

  • Segmentation and reassembly of upper transport layer messages into multiple lower transport PDUs to deliver large upper transport layer messages to other nodes

• The upper transport layer

  • Encryption and authentication of application data for providing confidentiality of access messages

  • Control messages for managing the upper transport layer between nodes

• The access layer

  • Definition of how higher layer applications can use the upper transport layer and how to format the application data

  • Definition and control of the application data encryption and decryption performed in the upper transport layer

  • Validation of whether incoming application data has been received in the context of the correct network and with correct application keys before forwarding it to the higher layers.

• The foundation model layer

  • Definition of the states, messages, and models required to configure and manage a mesh network

• The model layer

  • Definition of models that are used to standardize the operation of typical user scenarios and are defined in the Bluetooth Mesh Model specification or other higher layer specifications

Network Architecture

The Bluetooth Mesh specifications defines a managed flood-based mesh network, which uses broadcast channels to transmit messages so that nodes can receive messages and relay these messages, thus extending the range of the original message. Any device in a managed flood mesh network can send a message at any time as long as there is a sufficient density of devices that are listening and relaying messages. Under the managed flooding, message caching is used to discard and not forward a message that has already been accepted. In addition, packet time to live (TTL) is used to limit the number of hops a packet can be forwarded in the mesh network.

The Bluetooth Mesh network topology is built of different mesh nodes types:

• Mesh node: A member of a mesh network. It includes basic node functionality for receiving and processing broadcast, multicast and unicast messages designated for the node as well as transmission of local mesh data.

• Mesh relay node: Local processing as well as mesh message relaying for range extension within a mesh network. (Multiple hops supported)

• Mesh proxy node: Proxying between GATT-Bearer and Advertise bearer. This allows transmission to devices that support GATT-bearer only (e.g. mobiles phones).

• Mesh low power node (LPN): A power limited node which wakes up on specific time intervals to send messages or receive messages which are aggregated by a designated friend node.

• Mesh friend node: Used to aggregate messages for LPN during their sleep cycles and deliver their messages upon wake-up.

Note that Bluetooth LE devices that are connected to a mesh proxy node are not counted as part of the Bluetooth Mesh network.

Node combinations are allowed over the same device. For example, one device can be a Friend and Relay node.

Provisioning

Provisioning is the process of adding the devices into a mesh network. A device that is not a member of a mesh network is known as an unprovisioned device.

A provisioner is used to add a device to the network and manage the transitions between unprovisioned devices and a (provisioned) mesh node via the provisioning protocol. Provisioning of devices into a mesh network differs from the pairing and bonding process that is typically used in Bluetooth wireless technology.

There are two provisioning bearers (PBs) for provisioning protocol messages:

• PB-ADV bearer (connectionless oriented): This vector is implemented on all Bluetooth mesh nodes.

• PB-GATT bearer (connection oriented): This vector is only implemented on mesh proxy nodes. This feature allows Bluetooth LE devices (which do not support advertising bearers), such as mobile phones, to act as provisioners.

For more information on Provisioning, please see the Provisioning Procedures section below.

Node Configuration

A mesh node is managed by a Configuration Client to configure how the node communicates with other nodes. A Configuration Client can remove a node from a mesh network, which reverts it back to an unprovisioned device. The Configuration Client can be the same device as the provisioner.

For more information on node configuration, please see Configuring a Bluetooth Mesh Node to a Mesh Network.

Elements and Models

An element is an addressable entity within a node. Each node has at least one element, the primary element, and may have one or more additional secondary elements.

Each element has one or several Models. A model defines the basic functionality of a node by defining the required states, the messages that act upon those states, and any associated behavior. A node may include multiple models. Foundation configuration and health server models are mandatory in every node.

Figure 128. Node - Element - Model - State

To recap:

• Node: One device

• Element: Addressable entity in the network

• Model: Implements functionality

• State: Contains the condition of a model

Data Distribution

Publication and subscription of data within the mesh network uses a publish-subscribe paradigm. Nodes that generate messages publish the messages to a single address. Nodes that are interested in receiving the message will subscribe to this address. Generated messages are sent to destination mesh addresses that can be unicast (associated with a single element), pre-configured group addresses, or virtual addresses. Messages can be sent as replies to other messages or can be unsolicited messages. When an instance of a model is sending a reply message, it uses the incoming message originator’s source address as the destination address. This way only the originator will receive this message. When an instance of a model is sending unsolicited messages, it uses a model publish address as the destination address. Each instance of a model within a node has a single publish address.

For more information on this, navigate to Message handling

Client - Server - Control

As in GATT, Bluetooth Mesh messages follow a Client - Server architecture:

• A Server is a Node that exposes an Element and stores the condition of all the states associated.

• A Client can interact with Elements through requests to the Server.

The models are thus divided into Server Models, Client Models and Control Models:

• Server Model: Contains states associated to the model and elements. Also contains rules for how the model will react to incoming requests.

• Client Model: Contains definitions of messages used for read, write and other requests from the Client to the Server.

• Control Model: A control model can contain server models, client models and rules for interactions between these.

Security

As per the Bluetooth Mesh specifications, security in a Bluetooth mesh network is mandatory.

All messages in the mesh network are encrypted and authenticated using two types of keys. One key type is for the network layer communication. This ensures that all communication within a mesh network uses the same network key. The other key type is for application data, used to secure payloads at the upper transport layer. Separating the keys for networking and applications allows sensitive access messages (e.g. for access control to a building) to be separated from non-sensitive access messages (e.g. for lighting).

In addition, the network security model utilizes a privacy mechanism called obfuscation which utilizes the Advanced Encryption Standard (AES) to encrypt the source address, sequence numbers, and other header information using a private key. The intent for obfuscation is to make tracking nodes more difficult.

Bluetooth Mesh networks also protect against replay attacks. A replay attack happens when a malicious third party eavesdrops on the communication of a mesh network with the aim to intercept secure network communication and resend secure payloads. The goal of the attacker is to misdirect the recipient of the message by replaying or resending a payload, hoping the recipient believes the source of the payload is genuine. In this way, the attacker can extract secure data from the recipient or perform a malicious task. For example, the malicious user may replay a message to try to switch on the lights in the middle of the night. Message sequence numbers and an IV Index are added to mesh network payloads to protect against replay attacks. Each mesh message has its own 24-bit sequence number. The sequence number is incremented each time a message is sent. If a node receives a message with an old sequence number, the node will discard the payload. Similar to sequence numbers, an IV Index is a separate field inside the network payload. When a node receives a message, it will also check the IV Index value for validity. In short, the IV Index must always be equal to or greater than the last valid message sent to that node. The IV Index itself is protected by encryption and CRC performed when a node is added to a network and is not easily modifiable by an attacker.

Additional security measures are defined in the Bluetooth Mesh specifications that protect a mesh network from nodes removed from the network so that these expired nodes cannot be used to attack the network, i.e. a trashcan attack. To protect against this, the specification implements a reject list that the provisioner maintains. When a node is ready to leave the network, the provisioner adds the node to the reject list and initiates the Key Refresh Procedure. The Key Refresh Procedure is initiated by the provisioner and it assigns new keys to all the nodes in the network.

Nodes may also make use of Secure Network Beacons, which are used to indicate the security status of a node. The Secure Network Beacon is sent to update a network with an updated IV index and to expect a Key Refresh Procedure.

For more information regarding Bluetooth Mesh Security, please review Section 3.8 Mesh security of the Mesh Profile Bluetooth Mesh specifications.

Tip

TI’s Bluetooth Mesh solution implements the above security model as defined by the specification inside the stack. As such, a developer need not worry about implementing at the application layer.

TI Bluetooth Mesh Software Architecture

Figure 129. TI Bluetooth Mesh High-level Software Architecture

As shown above in Figure 129., TI’s Bluetooth mesh solution consists of 3 core functional components:

• BLE5 Stack - Bluetooth LE protocol stack implementation

• Bluetooth Mesh Stack - Bluetooth Mesh protocol stack implementation

• Bluetooth Mesh Application - User application implementation

TI BLE5-Stack is at the foundation of the Bluetooth Mesh implementation. The Bluetooth Mesh stack uses the TI BLE5-Stack services for transporting data over GATT based connection oriented data channels and Advertisement based connection-less channels. For example, the traditional broadcaster role is used by nodes to send packets over the advertisement (ADV) bearer. In parallel, the observer role is used by nodes to receive packets by passively scanning. Finally, the peripheral/central roles are used by nodes in the Proxy configuration to communicate with legacy Bluetooth LE devices over the GATT bearer.

Our Bluetooth Mesh stack is implemented on top of the Zephyr Project’s Bluetooth Mesh stack. For more information on this, refer to TI Bluetooth Mesh and the Zephyr Project.

The Bluetooth Mesh application is the core interface for users to control and manage the Bluetooth Mesh functionality. Here, specific node configurations and models are defined and used by each node in a mesh network.

Alongside the stack, additional OS services and Drivers/Middleware are used by the application. These functional components consist of TI Drivers and TI-RTOS.

Note

Currently, only certain SIG-defined Models and Vendor Models are supported.

Provisioning Procedures

The following section describes the provisioning procedure for both PB-ADV and PB-GATT bearers.

Provisioning with PB-ADV

Figure 130. Provisioning over PB_ADV high level overview

Figure 130. shows provisioning over the advertisement bearer (PB-ADV). Here, we can see there is no connection establishment. All communication occurs through advertisements, as the name suggests. Once the mesh application has been initialized, MeshApp_unprovisioned_beacon() is called to enable Provisioning. Then unprovisioned beacon advertisments are sent until a separate device (i.e. the Provisioning Client) receives the unprovisioned beacon. At this time, the stack handles any response and the provisioning process until the device is successfully provisioned. At the application level, the user simply waits until the prov_complete_cbk() is called.

Note

The application defines the provision complete callback by default and is modifiable via SysConfig. Check the SysConfig file inside BLE Mesh->Provisioning Data Configuration-> Complete Callback Name.

Provisioning with PB-GATT

Figure 131. Provisioning over PB_GATT high level overview

Figure 131. shows provisioning over the GATT bearer (PB-GATT), which is used by Proxy configured nodes. To provision over PB-GATT, the mesh Proxy node must first send connectable advertisements. Once the mesh application has been initialized, MeshApp_unprovisioned_beacon() is called to enable Provisioning. From here, the mesh Proxy node waits for the provisioner to initiate a connection. Once the connection is established, provisioning beacons are sent to the provisioner, this time, using the GATT bearer. At this time, the stack handles any response and the provisioning process until the device is successfully provisioned. At the application level, the user simply waits until the prov_complete_cbk() is called.

Once provisioned, the Mesh Stack will trigger a disconnect. This is done so the node can then expose its Bluetooth Proxy Service, as defined in the Bluetooth Mesh specifications.

Message handling

The following section describes how messages are sent/received by the Bluetooth mesh stack. One important note here is that application data is only decrypted at the target destination with a valid, separate application key. The target destination may be a Group Address the node has subscribed to, or it can be the Unicast address of a particular node/model.

Relay node processing

Figure 132. Inbound Relay Data processing

As shown above in Figure 132., when a mesh node publishes to an address in a network, it sends advertisement PDUs over the air. When a mesh node receives this PDU, the message is received by the stack and processed. Here, the network key is used to determine the message’s target destination. If the target address is a Group Address or received by a relay node, the mesh node will relay this information to the Mesh stack, and the advertisement PDU will be sent back out to the mesh network/target address. This process is shown below in Figure 133.

Figure 133. Outbound Relay Data processing

Proxy node processing

Proxy Nodes request data over the GATT bearer, so an additional step is required for proxy configured nodes when receiving messages.

Figure 134. Inbound Proxy Data processing

First, the Peer GATT node must submit a request for data from the mesh network. When the mesh stack receives this message, it will trigger a callback to the application and the Mesh Stack will request that data from the Mesh Net. Once received, it will forward this message using a GATT tx to the Peer GATT node.

Figure 135. Outbound Proxy Data processing

Similar to the Inbound Proxy Data process, a mesh Proxy node waits for its Peer GATT node to send it a message before forwarding it to the Mesh Net.