Extending Timeouts

[nicksinas]

We are attempting the following network:

• 2 Border Routers, mains powered
• More than 50 FTD nodes, battery powered
• All nodes are stationary

Nodes are fully powered and running while installed to allow the network to form and roles be assigned. Once all nodes have been placed and heard from, the nodes enter a low power mode (transceiver off) through a downlink command from our server. Then all nodes time synchronize to wake up on the hour, resume their role, transmit a payload, then back to sleep after another downlink command from the server.

We have this system working, except for the hourly timing. Timeout values within the Thread Stack cause the nodes to be dropped from the route list, thereby causing the nodes to default to End Nodes, and the Network has to be re-formed all over again.

There are a limited number of configurable timeout values, it seems like to properly support this behavior, we would need to extend several different timeouts within the source code to achieve this.

Can you provide some guidance on which timeout values need to be increased to prevent the nodes from being dropped and all defaulting back to End Nodes, causing the network forming to start from scratch? For instance, we changed kMaxNeighborAge and were able to keep the device’s role for longer while being “offline”. However, it seems more than this would need to be changed to function reliably.

It is OK if this means that the devices will not be Thread certified.

[jwhui]

@nicksinas , thanks for reaching out and sharing your use case. As you noted, something like this would be non-standard Thread behavior.

I'm not sure extending the timeouts is the best path forward. The timeouts allow devices to determine lost connectivity and adjusting the mesh topology to account for connectivity changes. Extending the timeouts will effectively place long time constants on OpenThread's ability to adjust to connectivity changes.

Maybe a better approach is to effectively suspend/resume time for parts of OpenThread that are responsible for maintaining the mesh topology - MLE at the very least. If you have sleepy devices, then components like the Data Poll Manager as well. However, this kind of change won't be as simple as changing a few constants.