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 

[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 

[Eirik Midttun]

nRF Connect SDK v2.1.2 which was recently released should address the reported issue. We will be thankful if you could upgrade to this version and verify. 

Updated by Hieu: Please also enable CONFIG_BT_MESH_ADV_EXT.

[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

[Oliver Weitzel]

Hi Eirik, 

Hi Hieu,

I already replied to Hieu but this reply unfortunately was invalid, because I failed to configure the extended advertising mode correctly (there where some dependencies I didn't resolve correctly and I had my fight with the KConfig until captured this). However, refined my test procedure and repeated the test series with the updated SDK and the correct configuration. Additionally I changed the position of my probes. One information I missed: My message payload length is constant and 4 bytes only.

Here my results of the test run 

	Publish	Send	Reply	Update
MIN	11	92	178	261
MAX	30	120	266	361
MED	14	102	198	294
AV	16	102	204	298

There is definitively an improvement. I will continue my evaluation, but this topic is for me solved for now, except you see here still room for improvement?

Thanks for you support,

Regards,

Oliver

[Eirik Midttun]

Further improvements should not be expected at this point. There might be some ideas that gets implemented as part of the improvement work, but for now the results are considered good enough and returns on further work is drastically decreasing.