Random delay for Bluetooth Mesh Access messages?

Hi,

Looking at the source code for nRF Connect SDK v1.7.0-677-ge3c356ec8 and SDK For Mesh 5.0.0 I can't find any indication that the following section of the Mesh Profile standard is implemented.

"3.7.4.1 Transmitting an access message

....

If the message is sent in response to a received message that was sent to a unicast address, the node
should transmit the response message with a random delay between 20 and 50 milliseconds. If the
message is sent in response to a received message that was sent to a group address or a virtual
address, the node should transmit the response message with a random delay between 20 and 500
milliseconds. This reduces the probability of multiple nodes responding to this message at exactly the
same time, and therefore increases the probability of message delivery rather than message collisions.

A node can also be configured to publish a message due to a local state change or to indicate the
progress of a transition to a new state or when the transition to the new state has been completed (see
Section 3.7.6.1). If the transition to a new state is caused by the user action, the device should send the
status message as soon as possible. When the publication of a message is caused by a power up, the
transition to a new state progress update, or to indicate the completion of the transition to a new state
multiple nodes may be reporting the state change at the same time. To reduce the probability of the
collision, these messages should be sent with a random delay between 20 and 500 milliseconds.

Due to limited bandwidth available that is shared among all nodes and other Bluetooth devices, it is
important to observe the volume of traffic a node is originating. A node should originate less than 100
Lower Transport PDUs in a moving 10-second window."

Is this implemented in any of the two Mesh stack?

I'm currently using the SDK For Mesh but are considering nRF Connect SDK for future products.

Thanks.

Parents Reply Children
Related