Next Version: Require any REED to be able to be commissioned or downgraded to FED-only.

[ekobres]

Is your feature request related to a problem? Please describe.
Retrofit devices connected to power switches should often not be eligible as routers.
When power is interrupted to a retrofit light bulb in a lamp or in a fixture connected to a switch, the resulting disruption to the mesh is often significant. This is especially true for fixtures that contain multiple bulbs, like chandeliers. This is also true for certain types of fixtures like lamps and other things that humans are in the habit of turning off manually.

Describe the solution you'd like
An ideal solution would be to require REEDs to be able to be downgraded to FEDs in cases where the installer knows it is a bad idea for the device to become a router. This could either be an option during commissioning, or a special command issued to the device that would cause a persistent, non-permanent downgrade of the device. This process should be reversible, and reconfiguration in either direction (REED->FED or FED->REED) should require proof of control of the device by either requiring re-commissioning, or manipulating the power to the device. It would not be ideal to allow this to happen seamlessly during otherwise normal operation or without some security controls.

Describe alternatives you've considered
Alternatives would be for manufacturers to provide alternative firmware for devices for REED and FED operation, but this is a big ask of manufacturers, and would be arduous for installers.

Additional context
This concept is well-documented in the Zigbee universe - and in many cases retrofit bulbs are specifically shipped as child-only devices for precisely the reasons mentioned above, although Zigbee does not provide a way to alter the capabilities of a device.

Anecdotally, I have 38 Nanoleaf bulbs in a 62-device mesh, and any time power is interrupted to a bulb with a router role, the network is destabilized for multiple minutes. Conversely, I have 40+ Zigbee devices on a mesh, and zero of the bulbs are routers. Interrupting power to these bulbs never destabilizes the Zigbee mesh.

[abtink]

Related to this OpenThread already provides an API otThreadSetRouterEligible().

[ekobres]

Yes, and that would be the expected implementation. This request is to require REEDs to persistently honor a request to set their state to not-eligible through a new mechanism during commissioning or at a later time such that the person setting up the device can control whether or not it is router-eligible. I am asking to require device manufacturers allow router functionality to be disabled.

"Shall" rather than "may".

[abtink]

I am asking to require device manufacturers allow router functionality to be disabled

Thread spec allows a device to be configured as FED (an FTD that is always ED and cannot be promoted to router). And OT provides the otThreadSetRouterEligible() API to set this.

In my view, this seems similar to other configurations which are device and/or application specific:

• For example, on an MTD, whether device to be rx-always-on or act as sleepy?
• And if sleepy
  • Whether to use CSL (at what period and on what channel)?
  • Or use "data poll" mechanism (and then how often to send data polls, etc)?

Thread spec defines the mechanisms for these and OpenThread provides APIs to set/change these.

I would say it is up to the device manufacturer and/or the application code running on the device to determine these configurations based on the use-case (and whether/how to expose functionality to configure these).

[ekobres]

Device manufacturers often simply drop a suitable module into their design without carefully considering all of the use cases. They have outsourced the technical design to this group, Nordic, Si Labs, espressif, et al.

Adding useful features and configurability in a standard way makes all certified products better.

A solution to this as part of the standard means site designers and installers can do this one way rather than have to rely on how (and even whether) device makers choose to implement it.

[abtink]

You may want to bring this up in Thread group for more discussion. OpenThread may not be right forum for this.

[jwhui]

How this is configured on a given device largely depends on the application layer as well. For example, Matter defines its own mechanism for commissioning. Matter could include a "router capable" parameter as part of its network configuration.

[ekobres]

The problem is unique (so far) to Thread where Matter is concerned, and it would be preferable not to require applications to change. This is a network-layer problem, and it needs a network-layer solution that can work (with or) without the support of upper layers.

This could be a border agent-enabled protocol for example, similar to channel management or jitter settings and added to the dataset. (E.g. commissioning dataset could have a field that specifies all REEDs commissioned while policy is active are commissioned as FEDs or even MTDs & policy could have a timestamp to expire.)

Preferably nothing new needs to happen with the leader since the device will use its own ability to become router-ineligible and will not initiate an Address Solicit message after joining as a child.

I’m admittedly no Thread expert; I’m primarily interested in any solution to the problem of ephemeral devices causing poor mesh performance.

It seems that several of the pieces are already in place.

[jwhui]

Matter defines its own way to commission the Thread network interface. While Thread could specify its own protocol for configuring router eligibility, that would not happen as part of Matter commissioning. Of course, it could happen after Matter commissioning, but as a separate, independent step. Usability issues would need to be addressed as well. Whereas Matter has its own application-layer node identifiers that are user facing, those would need to be mapped to Thread identifiers that are not typically user facing. I'm not saying that it can't be done, but I think integrating it properly across Matter and any other application layer is not as simple as it may seem. Any proposed change to the Thread Specification needs to be done through the Thread Group.