Handling channel changes

93 views
Skip to first unread message

Lander Noterman

unread,
Jun 10, 2021, 10:16:40 AM6/10/21
to openthread-users

I would like to understand how one would handle channel changes gracefully?

While thread devices are online, we can use the pending dataset mechanism (as employed by channel manager) to propagate the channel change, but what about thread devices that are offline (out of range, battery depleted, deep sleep...) at that point in time? When they come back online they form their own network (in case of FTD) or stay detached (in case of MTD).

Is there some setting that would allow these devices to re-join the existing network on another channel?

I've already looked into the
OPENTHREAD_CONFIG_ANNOUNCE_SENDER_ENABLE option, but the time it takes to re-join the network with this configuration is too long for our usecases (also, I think this only works if the disconnected device is in range of the announce sender device?).
It would be preferable if the disconnected device would scan the other channels,  compare the active timestamp of matching networks (matching masterkey) and join the network if the timestamp is newer. Is this behaviour achievable?

Thanks!

Jonathan Hui

unread,
Jun 10, 2021, 10:41:53 AM6/10/21
to Lander Noterman, openthread-users
Yes, OPENTHREAD_CONFIG_ANNOUNCE_SENDER_ENABLE was intended to pick up devices that did not yet receive the new dataset. However, because this process occurs during normal steady state operation, there's a tradeoff between how often devices announce and the amount of channel capacity devices consume just to check if they are on the right channel.

One possibility is to force a router-capable device to first attach to an existing device before becoming a Leader. You can do this today by updating the device's Active Dataset to exclude the Active Timestamp. In other words, get the Active Dataset, remove the Active Timestamp, then set it back (with the removed Active Timestamp). Of course, doing this would mean that a router-capable device is not capable of becoming a Leader on its own if it is the only router-capable device in the network.

Would this work for your use case?

--
Jonathan Hui



--
You received this message because you are subscribed to the Google Groups "openthread-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to openthread-use...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/openthread-users/e8192b32-95d2-4a97-9741-9a3a8d3c076bn%40googlegroups.com.

Lander Noterman

unread,
Jun 10, 2021, 11:16:27 AM6/10/21
to openthread-users
Hello Jonathan,

Thank you for the quick response. This solution does fit our usecase. Currently, however, we can only make it work for our FTDs, our MTD seems to stay detached without the full dataset, is this expected?

Op donderdag 10 juni 2021 om 16:41:53 UTC+2 schreef Jonathan Hui:

Jonathan Hui

unread,
Jun 10, 2021, 2:19:59 PM6/10/21
to Lander Noterman, openthread-users
Great to hear that this will address your use case.

The same method should work for MTDs as well. I just tested it by only providing the master key and the MTD will scan across the different channels looking for a parent. That said, MTDs are not able to become a leader on their own, so you should not need to deal with partial datasets on an MTD.

--
Jonathan Hui



Lander Noterman

unread,
Jun 10, 2021, 2:29:40 PM6/10/21
to openthread-users
After further testing, we could indeed reproduce the (desired) behaviour on our MTD, there must currently be some other issue with our setup that we should turn our attention to.

Thanks again for your (quick!) responses.

Op donderdag 10 juni 2021 om 20:19:59 UTC+2 schreef Jonathan Hui:

Jonathan Hui

unread,
Jun 10, 2021, 2:38:08 PM6/10/21
to Lander Noterman, openthread-users
Great to hear you got it working. Thanks for testing and reporting back.

--
Jonathan Hui



Reply all
Reply to author
Forward
0 new messages