nRF Mesh , sending hundreds of bytes packets to the mesh nodes causes NRF_MESH_EVT_SAR_FAILED

[Stanley Hung]

Hi,

 

I am conducting a mesh test and it contains:

1. An android smartphone,

- running nrf mesh 3.1.7 on github

- sending hundreds of bytes packets to the mesh nodes by “broadcasting”.

2. At least 2 nodes

- using nRF52840DK

- based on nrf5_SDK_for_Mesh_v4.2.0_src  light_switch server

 

The result shows:

1. Only the last provisioned node receives the full set of packets from smartphone.
2. Other nodes report NRF_MESH_EVT_SAR_FAILED in mesh_evt_cb(access.c) unless the total packets is limited to 8 Bytes.

 

Could you help on

1. How to solve NRF_MESH_EVT_SAR_FAILED?
2. We speculated that because the app used the last node as a proxy node, and there is a limitation with the proxy relay in large packets. If yes, is there any way to make the direct broadcasting instead of proxying ?

[Hung Bui]

Hi Stanley, 

Could you please describe what exactly you did by doing "broadcasting" from the phone? 

You are correct that the phone only connect to a proxy node to talk to the mesh network. Usually it's the last provisioned node. You can disconnect a proxy node and connect to other proxy node of your choice. 

Please be aware that in most case a phone doesn't do mesh directly. It requires a BLE connection to a proxy node to be able to talk to other nodes. 

There isn't a "broadcast" packet in mesh, you can send a packet to all nodes (address 0xFFFF) but it's not recommended. It's preferred if you setup a Group address and then subscribe the model on the nodes to this address. 

Also, Bluetooth mesh is not designed for high throughput communication. So sending a large amount of bytes to all the nodes in the network expose the risk of network congestion as packet about 11bytes will be segmented. For example to transmit 100 bytes, there would be 12 segmented packets, this also require ACK packets for each of them. 

[Stanley Hung]

I believe I am using “group” as you mentioned instead of “broadcast”, since I use a comment (in Android-nRF-Mesh-Library) to send my packet to specified group address.

 

Furthermore, a similar test is conducted by 3 of nRF52840DK, where

- No.1 works as a generic onoff client;

- No.2 works as a server, and is placed in the wireless working rang with No.1; and

- No.3 works as a server, and placed far away from No1, but in the working range of No.2.

 

The result is No.1 is able to publish 300 bytes to both No2 and No3 successfully by nrf mesh publish and subscribe addresses.

 

My question is:

1. Does it indicate that the proxy node has any relay restrictions?

 

[Hung Bui]

Hi Stanley, 

We are suspecting that the issue may be due to the communication between the phone and the proxy node doesn't have enough buffer for all segments. We are looking into it. 

If you are not planning to send the data to large number of node I think sending it to unicast address would be a better solution. SAR message when sending to unicast address will have acknowledgment on transport layer so you can be sure the data has arrived to the end node properly. 

[Stanley Hung]

In our application, the larger number of packets, the better application performance (in terms of user experience). Before this issue is fixed, we will try to find an optimum condition to make the design works. It would be very much appreciated if you could keep me informed once a new solution is available.

 

Could you share me more details about “the buffer for all segments” in the communication between phone and proxy node? Perhaps, I can do some test accordingly.

 

By the way, I also summarize what I found these days for your reference:

1.

It requires 4 times of retry number (TRANSPORT_SAR_TX_RETRIES_DEFAULT (4)) on phone to send a group message via a proxy node. And the message size is limited to 11 Bytes with successful sending.

2.

In above condition, when the packet size is over 11 Bytes for group address, it always fails.

3.

In case sending a group message from a nRF52840DK (generic onoff client), the result is successful even the packet size is up to 100 Bytes. Why not from a phone ?

4.

With unicast address from a phone to a node via a proxy node, and the retry number is set to 4 times, the packet size can be up to 100 Bytes. However, the performance is poor in sending time.

 

[Hung Bui]

Hi Stanley, 

I believe the buffer that you may want to try to increase is CORE_TX_QUEUE_BUFFER_SIZE_RELAY (128) in core_tx_adv.c 

You can find how it's called by looking at rx_handle() in proxy.c where the MESH_GATT_PDU_TYPE_NETWORK_PDU is feed into network_packet_in(). 

Inside network_packet_in() packet_relay() will be called if it's the packet to be relayed. And inside that you can find that if the buffer is full you will simply get a Warning level log of "Unable to allocate memory for relay packet" and the packet will be discarded. 

So I believe that if the data to be relayed are queued larger than CORE_TX_QUEUE_BUFFER_SIZE_RELAY they will be just discarded. This is fine if it's normal relay packet as the packet may get relayed by other node. But if it's the proxy node is the only node that has the packet to be relayed it will be discarded. 

This is different from when the proxy node itself want to send a large SAR message. The segmented message will be sent one by one from the source and the relay buffer is not used (because it's the source, not the relay). 

So what you can do is to try increasing CORE_TX_QUEUE_BUFFER_SIZE_RELAY, and also try to increase the connection interval between the phone and the proxy node, so that the data throughput is reduced giving more time for the proxy node to relay the messages. 

[Stanley Hung]

Thank you for your information, and I increased
- CORE_TX_QUEUE_BUFFER_SIZE_RELAY to 512 Bytes, and
- sent 100 bytes (resend 4 times) to group address,
The other nodes receive packet successfully sometimes, and sometimes fails. In this condition, increasing connection interval is not improved obviously.

1) In general, if increasing the RAM buffer in CORE_TX_QUEUE_BUFFER_SIZE_RELAY, to the upmost of a processor, what will be the disadvantage? Or what is the best percentage of RAM size to be allocated for buffer (I assume after proxy command, the RAM will be released, is it?)

2) Will it help by increasing CORE_TX_QUEUE_BUFFER_SIZE_ORIGINATOR in core_tx_adv.c?

[Hung Bui]

Hi Stanley, 

As far as I can see increasing CORE_TX_QUEUE_BUFFER_SIZE_RELAY  wouldn't cause any side effect except for that it would require more RAM and maybe making the latency for sending the originator message longer (just my guess). It's a fixed buffer so this amount of RAM is dedicated for CORE_TX_QUEUE_BUFFER_SIZE_RELAY.

My suggestion is to try  CORE_TX_QUEUE_BUFFER_SIZE_RELAY  at 512 but with only one sendmessage() call at a time. Then you can run a test and check the success rate to decide how many times should you resend. 

2. I don't think CORE_TX_QUEUE_BUFFER_SIZE_ORIGINATOR would help. It's for the message that's originated from the proxy node.