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.

[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.

[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.

[Hieu]

Hi Oliver,

To be honest, I cannot comment if there is room for improvement, since the numbers still don't make sense to me...

My expectation would be that message of any kind in any direction should take the same time; and the round trip should take just twice the one-way trip with some minor processing delay.

However, I am new to considering the BT Mesh message timing, so I might be missing something here.

For optional next steps, I recommend you to:
- Review your experiment setup, see if your sampling points are taking in any additional processing time in between.
- Setup some really simple firmware and run the experiments again. Some lightly modified Mesh Light and Mesh Light Switch, perhaps?

Of course, they are optional, since the judge, who is you, has considered the current state acceptable.

For me, I am interested in this but can't afford the effort right now, so I have put doing the same steps above into my optional-todo list (which unfortunately has not shortened for many weeks now)

Finally, I suggested the relevant comments as the answer. If you can verify them, that would be great.

Regards,

Hieu

[Hieu]

Hi Oliver,

I found this part of section 3.7.4.1 the Mesh Profile Specification that explains why a round trip (Reply/Update cases) is way longer than two times a one-way trip (Publish, Send).

Just to share with you. The other differences still seem strange, however. And the numbers aren't adding up yet.

If the message is sent in response to a received message that was sent to a unicast address, the node should transmit the response message with a random delay between 20 and 50 milliseconds. If the message is sent in response to a received message that was sent to a group address or a virtual address, the node should transmit the response message with a random delay between 20 and 500 milliseconds. This reduces the probability of multiple nodes responding to this message at exactly the same time, and therefore increases the probability of message delivery rather than message collisions.

A node can also be configured to publish a message due to a local state change or to indicate the progress of a transition to a new state or when the transition to the new state has been completed (see Section 3.7.6.1). If the transition to a new state is caused by the user action, the device should send the status message as soon as possible. When the publication of a message is caused by a power up, the transition to a new state progress update, or to indicate the completion of the transition to a new state multiple nodes may be reporting the state change at the same time. To reduce the probability of the collision, these messages should be sent with a random delay between 20 and 500 milliseconds.

[Oliver Weitzel]

Hi Hieu, 

thanks for the information regarding the specified times. You are right, the timings are confusing. I was concerned that my implementation might be unfortunate, because of the enabled provisioner on the central unit. Therefore, I repeated some measurements with a slightly modified chat sample (I just added LED on/off in the corresponding callbacks to indicate transmission activities). But the measured times (message -> reply) are equivalent to the measurements I did with my test setup. 

I don't know whether the shell requires too many resources and leads to time delays, but I checked already the influence of the printk function on the timing without any negative effects. I assume that counts for the shell as well. 

I still have a question regarding the provisioner. As already written before we want to establish a network without a smart device, hence we need a provisioner device for doing this. In my test setup that basically worked fine, but I'm wondering whether it is possible to stop the provisioner activities (searching for unprovisioned beacons) during runtime to save µC resources? I didn't find a function to do this. The goal is to allow adding units only within a defined time frame. 

Regards, 

Oliver 

[Hieu]

Hi Oliver,

I actually talked to R&D about the spec yesterday and the 20-50 and 20-500ms delay was optional and not implemented. There is just a flat 20ms delay. So that still doesn't explain the huge delay you have.

Oliver Weitzel said:

I was concerned that my implementation might be unfortunate, because of the enabled provisioner on the central unit. Therefore, I repeated some measurements with a slightly modified chat sample (I just added LED on/off in the corresponding callbacks to indicate transmission activities). But the measured times (message -> reply) are equivalent to the measurements I did with my test setup. 

Thank you for writing about your result. That is strange indeed. I will have to get to that one day.

Oliver Weitzel said:

In my test setup that basically worked fine, but I'm wondering whether it is possible to stop the provisioner activities (searching for unprovisioned beacons) during runtime to save µC resources?

I currently don't know and thus cannot answer you quickly. Since that is also a different topic from the one in this thread, do you mind creating a new one? Unless you are thinking it is the provisioner that is causing your timing to be off?

Regards,

Hieu