Bluetooth mesh communication failure probability

RE: Bluetooth mesh communication failure probability

Elfving — Thu, 31 Mar 2022 08:26:46 GMT

Hello,

[quote user="KaZu_Meistier"] Since the message to the client uses the group address,[/quote]

As in the client having the group address, or the server? Using group addresses in the context of ACKing is dangerous road, as you wouldn't know the amount of receivers of a message. Segmented messages are ACKed when they are transmitted to a unicast address, either by a recipient or by a friend.

[quote user="KaZu_Meistier"]- Negative influence of "sending a message 6 times in quick succession "
[/quote]

How fast are we talking here? It might be that the buffer is full, and the messages are in fact not being sent. Have you checked for errors like these?

And as I mentioned before about noisy environments, you could check if the noise of the environment by using the RSSI viewer in nRF Connect for Desktop, and see if anything stands out.

[quote user="KaZu_Meistier"]Thank you for the information on the specific application example
and the expected value information on the specific communication failure rate.
[/quote]

I actually had that double checked, and it seems I was mistaken; these factors can get you packet loss of maybe a couple of percent. However, 10% still sounds high. But in the context of mesh this still wouldn't be too much of an issue, as relaying of messages would compensate. You could also send the messages as acknowledged (meaning that they require an ACK) which would make it reliable. You can also increase the retransmission of all messages, though this have downsides as it will increase the traffic in the network.

Regards,

Elfving

RE: Bluetooth mesh communication failure probability

Kazu — Thu, 31 Mar 2022 01:13:40 GMT

Hello,

Thank you for your comments and information.

I will investigate the specifications and analyze by experiment
with the following points as the differences from the expected value of the failure probability.
I will post the results in this thread by the end of April. Please continue the support.
- Negative influence of "sending a message 6 times in quick succession "
Since the message to the client uses the group address,
I think that the client sends the message after receiving it by the relay function.

<Other information>
At the time of the experiment, the GATT proxy function was disabled.

>Not exactly that it can't receive while flash writing, but that the CPU gets stopped when running
>flash operations, which might lead to some packet loss. Though this would depend on the SDK.
Thank you for the supplementary information. OK.

p.s.
Thank you for the information on the specific application example
and the expected value information on the specific communication failure rate.
It's exciting to know the use cases of technology.

Best regards.

RE: Bluetooth mesh communication failure probability

Elfving — Mon, 28 Mar 2022 12:18:58 GMT

Hello,

[quote user="KaZu_Meistier"]The information that the device will not be able to receive while flash writing is useful to me.
[/quote]

Not exactly that it can't receive while flash writing, but that the CPU gets stopped when running flash operations, which might lead to some packet loss. Though this would depend on the SDK.

[quote user="KaZu_Meistier"]

what communication failure rate do you think is reasonable?

[/quote]

Hard to say, but maybe one in a thousand, or 10 thousand. That would at least sound like it is in the right ballpark.

[quote user="KaZu_Meistier"]If it is one way(server -> client), it is estimated that the communication failure rate will drop a little more.
[/quote]

That does make sense, however it wouldn't be enough to explain the entire discrepancy.

Regards,

Elfving

RE: Bluetooth mesh communication failure probability

Kazu — Fri, 25 Mar 2022 05:02:57 GMT

Hello,

Thanks for your comments and advice.

The information that the device will not be able to receive while flash writing is useful to me.
Thank you for information.

Please give me additional information. Under the conditions under discussion,
what communication failure rate do you think is reasonable?

About "Communication failure occurs with a probability of about 10%.",
Since the server was operating to send 9-byte messages 6 times in quick succession in one communication,
there was a possibility that it could not be sent in the first place. I'm sorry I failed to tell you.
And, in my experiment, "the server receiving an ACK message (application layer)
from the client" was defined as successful communication.(Means round trip)
If it is one way(server -> client), it is estimated that the communication failure rate will drop a little more.

I'm not familiar with GATT proxy, so I'll investigate and experiment for improvement.

Best regards.

RE: Bluetooth mesh communication failure probability

Elfving — Thu, 24 Mar 2022 08:53:26 GMT

Hello! Sorry about the delay.

[quote user=""]Communication failure occurs with a probability of about 10%.
[/quote]

This is surprising. It is understandable that there is some failure rate, as GATT-proxy advertising or other BLE activity, flash writing etc. might make the radio miss one package. And if the publish settings are configured to only send one unacked message once, there might be some losses between the nodes. The beacon interval can be as low as 10s, but that still makes your estimation of 10% seem very high.

When it comes to the segmented kind not having any errors that makes sense to me, as segmented messages are ACKED, which results in you not knowing if some messages were in fact lost.

You should note however that with multiple nodes in the network you will decrease this probability of the message not making it across, as all the nodes will relay the message forward, giving the receiving node multiple opportunities to catch it.

You should try it again in a less noisy environment, and disable GATT proxy.

Regards,

Elfving