Bluetooth Mesh Response Times

[Oliver Weitzel]

Hello all, 

I'm currently evaluating Bluetooth Mesh as potentiell solution for a remote control system with the option to extend the range via range extenders. 

To get an understanding of the timing conditions I created a test setup based on the chat and provisioner sample (using the Zephyr API with the nRF52 DK). 

The basic concept is that central unit manages a property that can be changed by other network participants via a change request. That's done by sending the new property value to the address of the central. If the change request has been approved and applied then the other network participants (addressed by a group identifier) will be notified. That's done via publishing the new property value to group address. 

Well, that's working so far. But I am confused because of the timings I have measured in the different scenarios. I checked the following cases: 

1. The central unit publishes a new property value: Here the other group units are updated in ~20ms 
2. A unit sends a new property value to the central: Even here the central receives a new message in ~20ms 
3. A unit sends a new property value to the central and waits for the notification: Here the response time from sending the message until receiving the update notification is ~360ms 

The case 3 is really confusing to me. I already checked configuration options to get this time down. I found the publishing retransmission count and timing, as well as the network retransmission configuration, but that doesn't explain this behavior. My assumption is that the reason for the delay is somewhere located in the physical layer that locks message publishing directly after a message reception. From my experiences with BLE I know that there are a couple of options to modify the response times (min/max interval time), and theoretically these parameters could have an influence. But neither I know whether that's really correct nor I see the opportunity to modify these values within the context of a Bluetooth Mesh application. 

That leads to my final question: Is it possible accelerate the publishing directly after a message reception in Mesh application? And if yes, how? 

Thanks in advance and regards, 

Oliver Weitzel 

[Eirik Midttun]

Hi Oliver,

Thanks for reporting the finding and providing the details. The description corresponds well with an issue that is already reported and which we are working on internally. A fix for the issue will be available in the next nRF Connect SDK. We don't provide dates publicly, but you should be notified when it is available.

I suggest you continue to inform Hieu about the issue so we can be sure we are in fact adressing the same issue.

[Oliver Weitzel]

Hi Hieu, 

an additional information I can add is the response time of the reply. Here I measured ~250ms. 

A question I actually still have: Is there a definition of a typical response time I can expect (assuming we have good environment conditions, no hops and no segmented messages)? 

Regards, 

Oliver 

[Hieu]

Hi Oliver,

Sorry for the long time without follow-up. I just want to let you know that I have been looking into the details of the known issue Eirik talked about, and the technical reasons of that limitation.

I hope to return with more details by end of tomorrow.

Best regards,

Hieu

[Hieu]

Hi Oliver,

Once again, I am very sorry for the long wait.
It turns out that my approach to this case was not good, and I was going in the wrong direction.

To answer your newest question:

Oliver Weitzel said:

A question I actually still have: Is there a definition of a typical response time I can expect (assuming we have good environment conditions, no hops and no segmented messages)? 

It is very complicated. What I can say is the best-case scenario should be way lower than 250/360ms.

When a node sends a message, the message is resent a number of times in the BLE Controller layer, multiplies by a number of times in the Mesh Stack layer. Worse cases happen when your "Central's" response came at an unfortunate moment where your "Group Unit" is busy repeating itself and cannot listen. 

---

To better understand whether that happened or not, could you please help with some questions?

- Is the measurement the average/median of some repetitions of the experiment?

- If it is done over several repetitions, what are the typical, best-case, and worst-case of the intervals we are talking about?

- In each attempt, is the property-change message sent only once by the application?

- What nRF Connect SDK version are you using?

- What is the Network Transmit configuration of the nodes involved? (Transmit Count and Transmit Interval)

- Are there only two nodes in your experiment, or are there more relay nodes nearby?

Edit*: undeleted draft points, already addressed above: There are message "repeat" mechanisms in the stack. And while a node is transmitting its message or relaying another's it cannot listen. An unfortunate combination of these

Best regards,

Hieu

[Oliver Weitzel]

Hi Hieu, 

regarding your questions:

• I didn't setup a test sequence to get statistics. I just checked single transmissions. However I repeated my measurements with some more cycles and captured the min/max delay times. I was surprised regarding the big ranges:
  • Case (1): From 14ms up to 86ms (measured with the scope) 
  • Case (2): From 138ms up to 148ms (measured with the scope) 
  • Case (3): From 350ms up to 450ms (measured with system time) 
  • Case (4 - reply response): From 240 up to 360 (measured with system time) 
• The send function was called only once (triggered by a button press) 
• On the mesh layer I defined no retransmission for the publish message (assuming this is handled properly at the network layer). Periodic publishing has been disabled.
• I'm working with the latest nRF Connect SDK revision 2.1.1
• The configuration is (hopefully these are the correct cofig parameters):
  • CONFIG_BT_MESH_TX_SEG_RETRANS_COUNT=2
  • CONFIG_BT_MESH_TX_SEG_RETRANS_TIMEOUT_GROUP=20
  • CONFIG_BT_MESH_TX_SEG_RETRANS_TIMEOUT_UNICAST=200
    
• Currently I'm just working with two nodes, coming from the future application requirements these are also configured as relays 

Regards, 

Oliver 

[Hieu]

Thank you, Oliver,

I will consult further with some Mesh-experienced colleagues and get back to you.

Meanwhile, the Retransmit configurations you got are for the Relay feature. Can you also get these please?

CONFIG_BT_MESH_NETWORK_TRANSMIT_COUNT
CONFIG_BT_MESH_NETWORK_TRANSMIT_INTERVAL

A thing to note is that such configuration can also be changed by a node. I can't remember if it has to be a provisioner or any node can do it. If you view the Configuration Server using the nRF Mesh app for instance, you will know for sure the nodes' current config.

By the way, I hope that you understand when deploy in field, with more 2.1GHz noises and more hops, the delay will be quite higher?
Just want to be sure since a "remote control system" usually requires responsiveness. Your UX people probably already have some requirements regarding maximum response time.

Best regards,

Hieu