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.

[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