Access_model_reliable_publish and acknowledge, retries

Question

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 · Accepted Answer

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.

Access_model_reliable_publish and acknowledge, retries

Top Replies