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

[Oliver Weitzel]

Hi Hieu,

these configurations I found in the KConfig: 

CONFIG_BT_MESH_NETWORK_TRANSMIT_COUNT=2
CONFIG_BT_MESH_NETWORK_TRANSMIT_INTERVAL=20

I don't change these parameters during runtime (the central unit acts as provisioner, because the network should be established without a smart device). 

Regarding you comment: It is clear that the response times will become longer if the number of nodes increase. But usually we don't have a lot of nodes and hops and just few node will act as repeaters. Also the number of transferred bytes is little, except of an initial synchronization. 

I think a response time of <200ms would be acceptable, but for a final decision we have to check this with a real system. 

Thanks for your support. 

Regards, 

Oliver

[Hieu]

Hi Oliver,

Could you please help with a few more questions?

- In your cases, are all messages the same length? If they are different, what are the lengths of each message in each case?

- Is case 4 a central>unit>central case?

- Is it possible that some processing time is captured in your measurement? For example, are there any processing before the central replies to a participant? The fact case 1 and case 2 don't measure the same also doesn't make sense.

- Are your devices using the same TX Power configuration?

- What hardware are you making the tests on?

By the way, as of Friday last week, NCS 2.1.2 was released with some bugfix for Mesh on extended advertising. Could you please try again with NCS 2.1.2, while enabling CONFIG_BT_MESH_ADV_EXT, and let me know the result?

Best regards,

Hieu

[Oliver Weitzel]

Hi Hieu,

I updated the nRF Connect and repeated the tests with the CONFIG_BT_MESH_ADV_EXT enabled. 

The TX output power is on both units set to 0dBm.

I use a nRF52840-Preview-DK as a central and a nRF52-DK as a node (see image).

Just to define the tests clearer. The times are measured from corresponding function call to corresponding event callback, sure that includes some processing times, but the system is not really loaded, except of a couple of printk calls, and the LED and button handling.
The button handling could create a jitter up to +10ms (due to the polling rate) at test cases 1 and 2. 

1: Publish (Central publishes a broadcast message to a group address) 
2: Send (Node sends a message to the central) 
3: Reply (Node sends a message to the central and waits for the reply as realized in the chat sample) 
4: Update (Node sends a message to the central and waits for the broadcast message after the reply) 

The times (ms) I measured after the update don't seem to be as different as before. 

	Publish	Send	Reply	Update
MIN	16	140	245	356
MAX	46	154	272	371
MED	20	146	252	365
AV	24	146	255	364

I see the option to speed up the update time by preventing a reply transmission after a received message, but actually I would like to have this acknowledge handling in.

Regards, 

Oliver 

[Hieu]

Hi Oliver,

How about the data length in each case? Are they all the same?
If the data is long enough that it has to be broken down into different packets, then the numbers would make more sense.

It is most likely not the problem here, but please also avoid having the probe wires close to the antenna. In the picture, the ground wire is very close to the tip of the antenna, which could affect the signal quite a lot.

Regards,

Hieu