Is this possible to add data with ACK messages in BLE mesh ?

[Manuel YGUEL]

Our use case is the following:

• We have sleeping nodes, that are time synchronized thanks to an external RTC, and that all wake-up at predefined dates, transmit data with ACK to a gateway and go back to sleep.
• The nodes are organized in a mesh with one gateway.

Sometimes we would like to perform additional actions for certain or all nodes (change of configuration, update, or time synchronization).

We are wondering if the BLE mesh protocole and the last NRF SDK provide a mechanism to add an extra data to the ACK (a bit would suffice) that we could use to tell the nodes to not go to sleep after receiving the ACK but wait for further instructions.

It seems that there will be many strategies if the possibility to piggyback a bit in the ACK does not exist, like setting up an other date for the downlink communications (gateway toward node) or having the nodes wait for a sleep order from the gateway.

We are eager for suggestions and returns of experience to help us choose the strategy we will implement.

We will publish our solution and describe what kind of success or failure we encounter.

[tesc]

Hi,

Is this a Bluetooth mesh application, or is it a different type of mesh built using BLE?

In Bluetooth mesh, nodes that are only sporadically actively participating in a mesh network are typically using the role of Low Power Node (LPN). They use the radio only when they need to send a packet, and periodically to check if there has been any incoming packets (those packets are stored by a Friend node, with which the LPN has established a friendship.) The LPN can poll the Friend for new packets whenever it wakes up, which would mean any packet sent to the LPN at any time will be read by the LPN at its next wakeup, for instance when it wakes to send data over the network.

In a normal BLE connection, data can be sent both ways during a connection event.

If only using BLE advertisements, there are no communication channels from observer to broadcaster, but if the broadcaster advertises for a connection (connectable advertisement) then a central can connect in order to communicate.

I am sure there are ways to achieve what you need, but the possible approaches depend on the specific technology used. (Bluetooth mesh, or BLE, or other.)

Regards,
Terje

[Manuel YGUEL]

Hi Terje,

Thank you for your answer. It is a Bluetooth mesh application.

I am looking at a model of SET with acknowledgement where the SERVER would perform the SET on the gateway/CLIENT.

In the SET the sensor will set its current data and expect a STATUS answer as part of the ACK.

In the STATUS, we plan to add the info for order sleep or order to wait for further command.

Is there a model, that we could derive from, that would be a good starting point for such kind of use ?

[tesc]

Hi,

Thanks for the update. Yes, then I think the answer to your question is basically "yes".

The server/client model paradigm is one of several ways to organize nodes in a Bluetooth mesh network. If you make your own models, you can mix and match the messaging protocol as you wish. In this case, it looks like you want the sensor to act more like a client, and the gateway to act more like a server. You are basically free to make your own vendor specific models that act in such a way. For general information about making vendor models in nRF Connect SDK, see Creating a new model.

Other references include the client/server model implementations from SDK examples such as the Bluetooth: Mesh light and Bluetooth: Mesh light switch samples. For an example using a model that does not adhere to the server/client paradigm, see the Bluetooth: Mesh chat sample and the vendor specific model it uses: the Chat Client model.

Regards,
Terje

[Manuel YGUEL]

Hi,

The first implementation we have made is derived from the Buletooth: Mesh chat. We experimented with this example. First we thought that the ACK was sent through the Message Reply. So we removed that message, however we still had the notification the message was not received (for instance by trying to send a message to a non existant node).

It looks like the use of the ack was enable in the context definition: when the field send_rel of the bt_mesh_msg_ctx structure is set to true.

When we put this field to false we did not get a notification when the message was not received (for instance by trying to send a message to a non existant node).

What confuse us, is that it looks like there is two kinds of ACK. 

Is this possible to customize the message that is used for the ACK controlled by the send_rel field ?

[tesc]

Hi,

I can confirm there are two kinds of ACK. In addition to the fact that you can implement acking on the model layer, there is also acking features further down in the stack.

Basically there are two ways of sending messages, one which uses segment acknowledgement and one which does not. The setting of send_rel in the bt_mesh_msg_ctx structure controls which one to use. The ack on this level cannot be piggybacked for other information.

If however you implement acking on the access (model) layer, through your own protocol, then you are free to decide what information to send along with this ack message. For instance tell the node it should stay awake for a while because there will be other messages incoming.

Regards,
Terje