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

[Manuel YGUEL]

Hi Terje !

Next question though : do we have to implement timeout and/or retry with the acking on the access (model) layer ?

We have seen that for the low-level ack timeout/retry is implemented (by the way we are looking where the timeout value and the retry number are defined, if those can be user defined).

[tesc]

Hi,

The low-level ack is part of the mesh stack, and is implemented by our stack implementations. The benefit is that it is already an integral part of the stack, but the drawback is you must take it as is.

If you choose to do an acking schceme on the access layer instead, then you have to implement any timeout, retry, etc. mechanisms yourself. The benefit is you can tailor it to your needs, but the drawback is you need to implement the full protocol yourself.

As an alternative, you could for instance use the low-level acking (for ensuring packets are delivered), but make your devices listen for a while after having sent packets (or poll the friend after a set, short timeout), in order for the acking node to also send a new message in addition to the ack.

Please note that if a message addressed to a low power node needs to be acked on the low-level layer, then it is the friend who does the acking. I.e. the ack will indicate that the message is stored by the friend, but has not necessarily been delivered to the low power node yet, and may also risk not being delivered if the friendship is lost before delivery.

Regards,
Terje

[Manuel YGUEL]

Dear Terje,

Thank you very much for your detailed answer.

We will implement timeout and retry on the access layer then. Do you have documentation on how they are implemented on the low-level layer and if it is possible to configure and choose the timeout value and the number of retry ?

Regards,

Manuel

[tesc]

Hi,

Since the transport layer acking (SAR acknowledge) is an internal part of the stack it is not thoroughly publicly documented, although the code is part of the SDK if you want to look at the implementation. (See e.g. transport.c and transport.h.)

It seems to mostly use parameters from the Bluetooth mesh specification. The timeout is a base timeout of 150 ms plus 50 ms per hop (i.e. per TTL). This is the minimum mandated by specification, and ensures enough time for the packet to reach its destination, get handled by the transport layer, and then acked back. Default timeout is 500 ms, and default number of TX retries is 4. These are all settings in transport.h, and is integral to the stack (not overridable through any app configs.)

Regards,
Terje