1. Introduction
BLE-mesh connects multiple Bluetooth Low Energy technology devices with mesh networking capability for internet of things (IoT) solutions. Mesh network has a many-to-many topology, with each device able to communicate with every other device in the network.
The BLE-mesh communication is done using messages relayed by the devices which are part of the mesh network (called nodes). In this way, the end-to-end communication range is extended far beyond the radio range of each individual node.
2. Topology
There are different types of nodes:
- Simple Nodes
- Proxy Nodes
- Relay Nodes
- Low-Power Nodes
- Friend Nodes
For more information about the node types, please refer to ST BLE-Mesh Application Note:
AN5292 - How to build a Bluetooth® Low Energy mesh application for STM32WBx5 line microcontrollers
A typical BLE mesh topology is illustrated in the figure below.
3. Elements and Models
Each BLE-mesh node contains one or more elements, and each element can support different models.
3.1. Elements
The elements define the functionalities of a single node, each element can be independently controlled.
3.2. Models
Models define the functionality of a specific element. Several models are defined by the Bluetooth® SIG, and many of them are deliberately defined as “generic” models, having potential use across a wide range of device types.
Refer to ST BLE-Mesh Application Note for more details about Element and Models:
AN5292 - How to build a Bluetooth® Low Energy mesh application for STM32WBx5 line microcontrollers
4. Provisioning
The process of adding a device into a BLE-mesh network, and configuring it, is called provisioning.
This process is started by a device called “provisioner”, which can be a smartphone with a BLE mesh application installed on it, or a mesh platform as STM35WBx5 line microcontroller. The provisioned device is now known as a node.
Refer to ST BLE-Mesh Application Note for more details about provisioning steps: AN5292 - How to build a Bluetooth® Low Energy mesh application for STM32WBx5 line microcontrollers
5. Go further
BLE-Mesh basic example: ST_BLE-Mesh_Lighting_Example
Friendship: Friendship
Embedded Provisioner: Embedded_Provisioning
6. STM32WB - Fast Firmware Update Over The Air
This is a description how to improve the data throughput while updating the STM32WB Application or Wireless Stack thanks to wireless STM32WB BLE protocol. The current implementation of "BLE_ota" application is described with the following Application Note:
6.1. Limitation with current implementation
- The OTA RAW Data Characteristic is limited to 20 bytes
- So ATT Packet data transmitted is limited.
The following figure is an air capture of the raw data characteristic sent by the ST BLE Sensor application
| ATT Write - 20 bytes |
|---|
6.2. How to increase the data throughput
- by increasing the size of the OTA RAW data characteristic to 248 - done with CubeWB 1.12.0 release
#define OTAS_STM_RAW_DATA_SIZE (248) //otas_stm.h
#define OTA_RAW_DATA_CHAR_SIZE OTAS_STM_RAW_DATA_SIZE //otas_stm.c
/**
* Add Raw Data Characteristic
*/
aci_gatt_add_char(OTAS_Context.OTAS_SvcHdle,
OTA_UUID_LENGTH,
(Char_UUID_t *)OTA_RAW_DATA_CHAR_UUID,
OTA_RAW_DATA_CHAR_SIZE,
CHAR_PROP_WRITE_WITHOUT_RESP,
ATTR_PERMISSION_NONE,
GATT_NOTIFY_ATTRIBUTE_WRITE | GATT_NOTIFY_WRITE_REQ_AND_WAIT_FOR_APPL_RESP,
10,
1,
&(OTAS_Context.OTAS_Raw_Data_CharHdle));
- by increasing the size of ATT Maximum Transmission Unit (MTU) which is the maximum length of an ATT packet
/**
* Maximum supported ATT_MTU size
* This parameter is ignored by the CPU2 when CFG_BLE_OPTIONS is set to 1"
*/
#define CFG_BLE_MAX_ATT_MTU (251)
- by managing with GATT Client remote application the negotiation of the ATT MTU to increase the data payload for the transmitted packets
| ATT MTU Exchange |
|---|
6.3. ANDROID - ST BLE Sensor v4.12.0 - How to
The version v4.12.0 is available on Google Play https://play.google.com/store/apps/details?id=com.st.bluems&hl=en&gl=US