• State Verified Answer
  • Locked Locked
  • Replies 2 replies
  • Subscribers 25 subscribers
  • Views 111 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 288901
Options
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Should an acknowledged message that replies a lot of data be broadcasted into the mesh?

user91456

Dear Bluetooth Mesh experts,

The firmware contains a proprietary message that sets a node's parameters and returns 100 bytes of data. The Android app sends it as an acknowledged message.
The idea is to keep the messages sent into the mesh at a minimum, hence setting parameters and returning updated values is done in a single message.

If all nodes should be updated, the Android app simply broadcasts the message into the mesh (again acknowledged).
This seems to work well (at least on a mesh network with a handful of nodes), and all nodes deliver the data. I'm a little concerned thou, if broadcasting an acknowledged message that delivers 100 bytes of data is a good idea. Question is, is it? Or should that be avoided?
Do you think it would reliably work on a mesh network with hundreds of nodes?

Your advise is very much welcome,
Thank you,
Michael.

Parents
  • +1

    Hi BlueMike, 

    We had a related discussion here that might be useful for you: https://devzone.nordicsemi.com/f/nordic-q-a/87396/nrf-mesh-sending-hundreds-of-bytes-packets-to-the-mesh-nodes-causes-nrf_mesh_evt_sar_failed

    The take out from the discussion is that: 

    - When sending SAR message to a unicast address, the segmented messages are ACKed and retransmitted if needed on lower transport layer. When sending SAR message to a group address they are not ACKed and no retransmission happens. This is requires multiple re-tranmission on the upper transport layer to compensate but still it's not the best way of delivering reliable message. 

    - When sending SAR message from a phone, at least in our implementation on the Android app, there is no retransmission on upper transport layer. So you may need to do that in the application. 

     - So what we would suggest is to try to keep the message under 11 bytes, to avoid SAR.  If the data is above 11 bytes, you can think of doing the segmentation on the application. Try to divide the data into chunks and can send and verify all nodes have acknowledged the chunks, if not you can resend the data. Then continue with the next chunk.

Reply
  • +1

    Hi BlueMike, 

    We had a related discussion here that might be useful for you: https://devzone.nordicsemi.com/f/nordic-q-a/87396/nrf-mesh-sending-hundreds-of-bytes-packets-to-the-mesh-nodes-causes-nrf_mesh_evt_sar_failed

    The take out from the discussion is that: 

    - When sending SAR message to a unicast address, the segmented messages are ACKed and retransmitted if needed on lower transport layer. When sending SAR message to a group address they are not ACKed and no retransmission happens. This is requires multiple re-tranmission on the upper transport layer to compensate but still it's not the best way of delivering reliable message. 

    - When sending SAR message from a phone, at least in our implementation on the Android app, there is no retransmission on upper transport layer. So you may need to do that in the application. 

     - So what we would suggest is to try to keep the message under 11 bytes, to avoid SAR.  If the data is above 11 bytes, you can think of doing the segmentation on the application. Try to divide the data into chunks and can send and verify all nodes have acknowledged the chunks, if not you can resend the data. Then continue with the next chunk.

Children
Related
Terms of service