Bluetooth Mesh Response Times

RE: Bluetooth Mesh Response Times

Hieu — Wed, 23 Nov 2022 09:52:25 GMT

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.

[quote user="Oliver Weitzel"]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. [/quote]

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

[quote user="Oliver Weitzel"]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?[/quote]

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

RE: Bluetooth Mesh Response Times

Oliver Weitzel — Wed, 23 Nov 2022 08:14:33 GMT

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

RE: Bluetooth Mesh Response Times

Hieu — Mon, 21 Nov 2022 14:39:26 GMT

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.

[quote]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.[/quote]

RE: Bluetooth Mesh Response Times

Hieu — Wed, 09 Nov 2022 20:15:17 GMT

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

RE: Bluetooth Mesh Response Times

Eirik Midttun — Wed, 09 Nov 2022 13:07:40 GMT

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.

RE: Bluetooth Mesh Response Times

Oliver Weitzel — Wed, 09 Nov 2022 11:06:35 GMT

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

RE: Bluetooth Mesh Response Times

Hieu — Tue, 08 Nov 2022 15:41:55 GMT

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

RE: Bluetooth Mesh Response Times

Eirik Midttun — Tue, 08 Nov 2022 12:42:23 GMT

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.

RE: Bluetooth Mesh Response Times

Oliver Weitzel — Tue, 08 Nov 2022 12:32:04 GMT

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

RE: Bluetooth Mesh Response Times

Hieu — Mon, 07 Nov 2022 15:46:04 GMT

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

RE: Bluetooth Mesh Response Times

Oliver Weitzel — Fri, 04 Nov 2022 12:46:23 GMT

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

RE: Bluetooth Mesh Response Times

Hieu — Fri, 04 Nov 2022 12:14:57 GMT

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

RE: Bluetooth Mesh Response Times

Oliver Weitzel — Fri, 04 Nov 2022 11:29:46 GMT

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

RE: Bluetooth Mesh Response Times

Hieu — Thu, 03 Nov 2022 13:25:21 GMT

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:

[quote user="Oliver Weitzel"]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)? [/quote]

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

RE: Bluetooth Mesh Response Times

Hieu — Wed, 02 Nov 2022 15:00:18 GMT

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

RE: Bluetooth Mesh Response Times

Oliver Weitzel — Thu, 27 Oct 2022 12:52:39 GMT

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

RE: Bluetooth Mesh Response Times

Eirik Midttun — Wed, 26 Oct 2022 09:03:30 GMT

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.

RE: Bluetooth Mesh Response Times

Oliver Weitzel — Wed, 26 Oct 2022 08:03:05 GMT

Hi Hieu,

first I have to correct a statement: The send time (case 2) wasn't 20ms. Here actually I measured various times between ~120ms and ~150ms.

The times I determined with an oscilloscope. I captured a button press on the sender side which starts a transmission and on the receiver side I captured a LED signal change that indicates the reception.

The complete system update time (case 3) I measured on the system with the system cycle time by calculating the difference of a start and stop time get with k_cycle_get_32(). This correlates with measurement I did with the scope as in the other cases.

Regards,

Oliver

RE: Bluetooth Mesh Response Times

Hieu — Tue, 25 Oct 2022 08:49:04 GMT

Hi Oliver Weitzel,

It is a very interesting question you got today. Before we begin, could you please let me know what your method of measuring these time intervals is?

Best regards,

Hieu