MESH Throughput

[WesC]

Using NCS V1.4 for Mesh on a nRF52840, My customer wants to send higher rate sensor data via mesh.  It seems the fastest continuous rate they can obtain is about 1Hz.  When going down to about 10 Hz buffers start to overflow and packets are lost.

When going thru the source code it appears in the function "adv_send()" there is a  k_sleep(K_MSEC(duration)); where the duration ranges from about 60ms to 120ms within this experiment.

With that fixed delay, it seems the mesh message rate is limited to less than 10Hz.  Can someone verify how this was determined?  Can it be improved?

Also I tried to enable the BT5 advanced adv features via CONFIG_BT_CTLR_ADV_EXT=y but then I get errors and the mesh stops working.  Is their any plan to use these features to improve the performance of the mesh in the future?

[Hung Bui]

Hi Wes, 

I haven't looked deep into how the sleep duration is calculated but if you have a look at the spec (3.7.4.1 Transmitting an access message - Mesh profile v1.0) you can find that: 

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.

So it makes sense that the message rate is limited to less than 10Hz. 
The current Mesh spec doesn't support using extended advertising. 

[daviddedwin]

The k_sleep( ) in the send function is very odd.

The fastest advertising interval the mesh can use is 20ms, lets assume that additionally the packet gets re-transmitted in 3 separate events, which mean each packet would take 60ms. This should still allow for a 10HZ data delivery rate. (The specification restriction is using the word "should" which means you can look at it but its not a hard restriction)

Additionally, make sure that the number of hops and the number of relay nodes are strictly controlled as they will impact the bandwidth. Typically enable only one relay in each hop neighborhood, so relaying should be off by default in all the nodes during configuration.

Keep the sensor data at 8 bytes or lower if you are using a vendor specific opcode to prevent segmentation and creating bandwidth issues.

Try the nRF5 SDK for Mesh to check this as well as that does not have the k_sleep() in the send function and is likely to get better bandwidth numbers. The nRF5 SDK for Mesh also has statistics that you can extract to see if packet losses are the problem or data buffers are the problem.