Bluetooth Mesh Time Server Multi-Hop

[BjoernS]

Hi everyone,

I got a question regarding the Bluetooth Mesh Time Server/Client models. I would like to propagate a common time base within my Bluetooth Mesh network by using the Time Server model. However, during reading the documentation I read something in the time_srv.rst that dampened my enthusiasm:

"To ensure a high level of accuracy, Time Status messages are always transmitted one hop at a time.
This means that every mesh node that needs access to the common time reference must be within radio range of at least one other node with the Time Server model.
Time Server nodes that have no neighboring Time Servers need to get this information in some other way."

One hop at a time is not what I was looking for. I am aware that with every hop in the network the uncertainty and accuracy of the common time base will be affected. However, high accuracy is not of a major concern in my desired application, thus I would like to know if there is a way to bypass the one hop limitation.

Regards,
Bjoern

[Mttrinh]

Hi,

I have asked the Mesh team to clarify this, I will update you as soon as I get a response from them.

[BjoernS]

Hi,

just wanted to ask if there are any updates yet?

[Marjeris Romero]

Hi,

No update from the Mesh team yet. It's summer vacation time here in Norway so it can take up to 2-3 weeks before I can come back to you with an answer, as much of the staff is on vacation right now. I am sorry for the inconvenience.

Best regards,

Marjeris

[Marjeris Romero]

Hi,

Here is an update from the team:

Brief resume:

Time Status as an unsolicited message is sent with 1 hop limitation.

Time Status as a response is sent with configured TTL.

Customer, of course, is able to avoid this limitation for retransmission by removing this line:

https://github.com/nrfconnect/sdk-nrf/blob/master/subsys/bluetooth/mesh/time_srv.c#L471

but it will break spec requirements:

5.3.1.2.2 Sending a Time Status message

...

If sent as an unsolicited message, the Time Status message shall be sent with TTL=0 to avoid building up cumulative time errors resulting from delays in processing the messages by relays.

...

PR with doc clarification here: https://github.com/nrfconnect/sdk-nrf/pull/5109

Best regards,

Marjeris

[BjoernS]

Hi Marjeris,

thank you very much for the response! That clarifies my question.