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 128. 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 128. Layers of Bluetooth Mesh

Starting from the bottom, the BLE 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 BLE 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 129. 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

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. 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.

TI Bluetooth Mesh Software Architecture

Figure 130. TI Bluetooth Mesh High-level Software Architecture

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

• BLE5 Stack - BLE 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 Bluetooh Mesh stack uses the BLE 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 BLE 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 Generic 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 131. Provisioning over PB_ADV high level overview

Figure 131. 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 132. Provisioning over PB_GATT high level overview

Figure 132. 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 BLE 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 133. Inbound Relay Data processing

As shown above in Figure 133., 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 134.

Figure 134. 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 135. 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 136. 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.