Openthread mesh reactivity

[Di Piazza Alain]

Hi,

We are actually building a small Mesh OpenThread network with a few devices (4 routers and 1 leader for example).

With default parameters,  if we stop the leader or reboot one router randomly, the system takes several seconds or minutes to reconfigure itself. This is due to the different default values specified in the Thread spec (MLE_END_DEVICE_TIMEOUT, LEADER_TIMEOUT, ROUTER_SELECTION_JITTER etc..)

For the purpose of a demo, we would like to have a system which ‘auto configure’ itself much more quickly, lets say in a few seconds. For instance, if I power down the leader, I want to see a new leader being elected as quickly as possible. If I stop a router, I want the leader to be aware as fast as possible of the fact that the router has been removed from the Mesh network. Etc..

Is it possible to have a set of parameters and the API associated  that we could use in order to highlight the “auto reconfiguration” aspects of a typical Thread network and improve the reactivity response time.

We can use functions like otThreadSetRouterSelectionJitter() and play with the poolperiod to improve reactivity.

Can you propose a set of values that we could use for this App in order to highlight "Thread self reconfigurations" without breaking the overall robustness.

Thanks very much for your help.

 

 

[Jonathan Hui]

You can try playing with the parameters listed below.

As you probably know, changing these protocol parameters (with the exception of child timeout) will make your implementation non-compliant with the Thread protocol specification.

Via API:

• otThreadSetChildTimeout() - how quickly a child discovers its parent has disappeared
  
• otThreadSetRouterSelectionJitter() - how quickly a REED promotes itself to router

Via code updates (i.e. no API available):

• Mle::kAdvertiseIntervalMax - how quickly router sequence number propagates to neighboring devices
  
• Mle::kMaxNeighborAge - how quickly router detects that neighbor has disappeared
  
• Mle::kNetworkIdTimeout - how quickly router detects that leader has disappeared
  
• Mle::kReedAdvertiseInterval and Mle::kReedAdvertiseJitter - how quickly neighboring REEDs in different partitions discover each other

Hope that helps.

--

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 post to this group, send email to openthre...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/openthread-users/553a67f4-2414-4e40-9cc5-b2b83cd6a4c3%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.