Sleepy Heavy Networks

[mmb-davidsmith]

I'm working on a project which is using sleepy sensors as the primary device on the thread network. These are configured as SED devices. There's a specific router/leader device in the network which presents a service to which these devices push data periodically. We do not expect a border router to be present in many of the deployments of these networks (joining is handled via UI on the router device). To expand the size of the network beyond what a single router can handle it its child table, we also have mesh extender devices which are simple thread router capable devices.

We've encountered a scenario that's causing us issues and wanted to figure out if there's a way to solve this with some configuration changes in OpenThread. Specifically, we have the max children of the router running the application code set to 10. If we set up the network with 10 sensors, we know that we can't add another without adding a router.

At some point in the future, we attempt to introduce a router so that we can continue to grow the network. However, because the child table of the single router in the network is full, we can't join the router. To do this, we need to power off a child (or remove it from radio range), wait for the child to expire from the child table, join the router and then re-power the child.

Is there a way to configure OpenThread such that it reserves 1-2 spots (or maybe OPENTHREAD_CONFIG_MLE_CHILD_ROUTER_LINKS) in the child table for only REED type devices? The thought it that this would allow us to introduce new routers without the friction and complicated instructions for an installer.

[jwhui]

OpenThread does not implement such a capability today, but it is an interesting idea to explore.

One challenge is that a router does not explicitly know whether a attaching child is router eligible. The MLE messaging indicates whether a device is an FTD, but that alone does not indicate whether the device is capable of upgrading to a router. Another complication is that a device could decide to become router eligible (or not) after attaching.

Your use case seems to be whether or not the device is a SED, which we could work with. So maybe whether the device is an FTD is sufficient for your use case. The approach wouldn't generalize to a FED, but maybe that's OK.

[mmb-davidsmith]

@jwhui - As you mention, there's not a lot which we could do with the existing MLE messaging past checking the device type is FTD. Anything that changes this would have to be a spec update and have backwards compatibility failings.

Is the idea of restricting a few spots in the child table for FTD entries something that would need to be part of the thread spec or something that an implementation could do without being out of spec?

[jwhui]

The Thread Specification already allows such behavior:

A Thread Router MUST support a minimum of ten (10) Children, of which at least six (6) MUST be SEDs.