BLE Mesh Unicast vs Multicast Message packet RX Latency and Loss

[EAn]

Hi all,

I am using the latest Mesh SDK (3.2.0) and SDK (15.3.0) in an nRF52840 SoC.

I developed a message model to send 32 bytes payloads (which I assume would require 3 PDUs with a 32 bit TransMIC, according to section 3.7.3 of Mesh Profile Specification by Bluetooth SIG).

I am getting a weird behavior with my vendor models, which is:

• If I publish messages from the server using unicast messages the client can receive all messages sent even if I send messages within an a 200ms  interval of each other.
• However if I send messages using multicast, the client isn't receiving all messages. In particular, the number of packets loss is deterministic and a function of the time interval between sent messages. That is, if the server sends messages every 500ms the client receives every sixth (+/-2) message. If I increase the interval to 1000ms, I receive every 3rd message (+/-1), if I send messages every 3000ms I can receive all messages....

Why is that?! I need to solve this fast, so any assistance would be very appreciated.

This message service is meant to communicate with the highest throughput possible in multicast in order to be scalable to larger networks.

So my real question is: How can I have the highest possible throughput in a multicast transmission (discarding the acknowledged  messages, I will have a routine to retrieve missing packets in a larger transaction)?

Thank you so much for your prompt assistance and pointers!

Regards

//E

[ti_me1]

Hi Mttrinh

I had exactly the same behaviour as EAn initially was describing, working with the current Mesh SDK v4.0.0.

Section 3.5.3.3 in the Mesh Profile Specification v1.0.1 says the following regarding to sending messages to Non-Unicast addresses:

• We do not have to expect Segment ACKs when sending messages to non-Unicast addresses (as discussed)
• It is recommended to send lower transport PDUs multiple times, with small random delays between repetitions.

I derived from those statements, that it is not correct to wait for segment ACKs after sending to Non-Unicast addresses. The segment transmission retries looked for me like a result of the fact, that the transport layer of the SDK does not differentiate the destination address types and always waits for segment ACKs. Of course, we should add redundancy when sending to Non-Unicast addresses, which is recommended in the standard. But with "small random delays" between the repetitions.

After reading the discussion of this devzone case, I would like to put the following in question:

1. Can we be sure that we do not mix-up "Retries" (required when segment ACKs are missing) with "Retransmission" (recommended when sending to Non-Unicast addresses) ?
2. If we are retransmitting after the constant retry timeout of 500ms (initial setting in the SDK), can we really speak of "small random delays" as stated in section 3.5.3.3 ?

My workaround looks like this: I differentiate between the message destination addresses in the transport layer. If the destination is non-unicast, I set "artificial" segment ACKs directly after successful passing it to function "sar_segment_send(..)". The function segmented_packet_tx had to be modified too, for finishing the SAR session as soon all segments are out.

What does the Nordic Team think about this? I would send you this solution more detailled if you say that this is the correct way of solving it.

Regards