Access_model_reliable_publish and acknowledge, retries

[Amadeus]

Hi,

I am using nRF52840 and nRF SDK 15.2 and nRF SDK for Mesh 3.1.

When I try to send acknowledged messages, sometimes my device needs to retry several times before the message is acked. Sometimes it takes 5 retries before I get an ack, even though my development boards are right next to each other with good signal strength. Why is this? With unacknowledged publishing, the same device always receives the message when no retries.

Furthermore, I have logged the status in access_model_publish() return by packet_alloc_and_tx() and sometimes, under reliable publishing, it returns (NRF_ERROR_INVALID_STATE) which makes access_model_publish() to call add_reliable_message(). What's the implication of this and why does it return NRF_ERROR_INVALID_STATE??

[Mttrinh]

Hi,

Sorry for the late response on this,

How often does this happen? How big is you packets and how fast do you send them?

access_model_publish() returning NRF_ERROR_INVALID_STATE means that there is already a segmented packet to this destination in progress. Wait for it to finish before sending new segmented packets.

[Mttrinh]

Just to be sure that you don't send messages too fast you should wait for the NRF_MESH_EVT_TX_COMPLETE before sending a new message. 

Amadeus said:

I have not changed the retry interval of reliable publish, where can I do that?

You can change it using the define ACCESS_RELIABLE_RETRY_DELAY found in the access_reliable header file.

[Amadeus]

I can try that, but I am able to send unacknowledged messages MUCH faster, so I really don't think that is the problem. Furthermore, shouldn't access_model_reliable_cancel() cancel ongoing packets if I was sending messages to fast?

[Mttrinh]

Yes, if access_model_reliable_cancel() is called it should cancel an ongoing reliable message.

[Amadeus]

Yes, and I am calling that function before access_model_reliable_publish() and get no "Acknowledged transfer canceled" log in the above snippet, therefore, the problem should not be that I am sending messages to fast.

[Mttrinh]

Hi,

Sorry for the late response. I have talked to one of our developers and this is his response to the issue:

I see why the customer is facing the issue. He uses the 30 Byte long messages and uses the "acknowledged transfer" API. In a case when he uses the acknowledged transfer API, he is sending these messages to a Group address. When SAR transfer is triggered to the group address, according to the specification there will be no block acknowledgements to the SAR message segment (Note that these transport layer block acknowledgements are different than the access layer unack/acked message classification). Therefore, the nrf mesh stack will retry 4 times (i.e. TRANSPORT_SAR_TX_RETRIES_DEFAULT) before declaring the SAR transfer completion. It takes about 4-5 seconds to finish this process, it will take longer, if the message is bigger. Therefore, customer sees that he cannot initiate new SAR message earlier than 4 seconds to the same destination.

How does he see things working differently for unacknowledged messages?
The SAR mechanism does not distinguish if the message being sent is acknowledged or not at the model/access layer. Therefore, the SAR transfer for unacknowledged model messages to the Group destination should work exactly like that of acknowledged model messages. Therefore, he should see the same ~4 second waiting period before he can trigger another unacknowledged model message. I verified this by on desk experiment. Now, since this does not happen in customer's case (he is reporting much better performance for unacked messages), then the destination for these unacked messages is not a Group address (I suspect that these unacked messages are being sent from another client instance which is publishing to a Unicast address). If the destination is Unicast, the SAR transfer will succeed as soon as full transport layer block acknowledgement is received from the destination node thereby unblocking the transport layer for accepting further SAR messages to the same destination.

In summary, if a customer wants better throughput while delivering data to the group, it is better to use model messages that will fit into single segment. For a reference, see Table 3.42 in Mesh Specification v1.0.1.