Migrating the tranditional BLE protocol to BLE MESH, how about the roles?

[esonhon]

I am a newbie for BLE MESH. Trying to migrate the existing product which based on self-defined GATT service to BLE MESH network, and got confused.

Current scenerio, the network has

1. 100+ battery powered devices with e-ink display, need the lowest power consumption as possible; it's based on NRF52832

2. One or more BLE gateway, based on NRF52840, have WIFI connection ability to internet back server, it's AC powered.

The GATEWAY send message to all DEVICEs., DEVICE group or specific DEVICE, the DEVICE display the message and report task status to GATEWAY, then goto low power mode. The procedure is time insensitive and message size is less than 1k bytes.

For my current workarounds, the gateway maintain a device MAC list, connect to the device, write message, then disconnecte one by one. If it's a public message to all devices, the procedure will be very slow even if the GATEWAY build 10+ connections concurrently.

So I decided to use MESH.

My question:

1. Which MESH role is suitable for the device and gateway?

2. Is it necessary and possible to implement multiple roles in one physical device/gateway?

3. Do we have any easy procedure to do MESH provision without a smartphone or APP?

Thanks!

[tesc]

Hi,

1. Bluetooth mesh has a concept of models, where nodes typically implement either a server model or a client model. The server model is for the node with the state (e.g. light bulb, or in your case it sounds like the node with e-ink display.) The client model is for setting or reading the state of a server model (e.g. a light switch, or in your case it sounds like the gateway.) It sounds like you want two models; one for setting the message to display, and one for reading back status.

2. It is possible to combine any set of models on a node. E.g. some server models, some client models, etc.

3. We do have, in our nRF5 SDK for mesh, a provisioner example to run on an nRF52 device. It automatically provisions the devices from the light switch example, so that light switches (generic on/off clients) can control the lights (generic on/off servers).

Please note that the main "backbone" of the Bluetooth mesh network uses a lot of power, as it needs to be continuously in RX mode, to listen for packets being sent over the mesh network. This means you typically need a number of nodes that are mains powered.

There is a feature named "Friendship", where you have some "Friend" nodes that are always on, and those initiate friendships with "Low Power Nodes" (LPN) who only wakes up once in a while. The Friend node keeps packets that are addressed to the LPN, so that when it wakes up it can ask for and get all the pending messages. This means if you have some Friend nodes that are mains powered, the rest of the nodes may be LPN and use less power.

There is also a feature named "GATT proxy", where you have some "GATT proxy" nodes that are always on, and those nodes lets "GATT client" nodes connect over a normal BLE connection using GATT. It is primarily meant for legacy devices such as smartphones that support BLE but do not support Bluetooth mesh. The mechanism can also be used for other devices. GATT client nodes have power consumption similar to BLE central devices, as they are in fact BLE central devices that uses GATT to connect to the network.

Both LPN and GATT client nodes are fully part of the Bluetooth mesh network, just as any other node.

Regards,
Terje

[esonhon]

Thanks.

I got the answer from your detailed reply. Actually, MESH network isn't the best solution for my product.