Parent Child Table Lost While SED Continues Data Polling When Child Supervision Is Disabled

[fuxiaoming-lumi]

During interoperability testing with several Thread devices currently available on the market, we observed that some devices do not enable Child Supervision.

We are trying to better understand the potential impact of this configuration in real deployments.

In our tests we observed that both the FTD parent and the Sleepy End Device (SED) did not enable Child Supervision.
OPENTHREAD_CONFIG_CHILD_SUPERVISION_CHECK_TIMEOUT is Zero
OPENTHREAD_CONFIG_CHILD_SUPERVISION_INTERVAL is Zero

From the Thread documentation, we understand that Child Supervision helps detect stale parent-child relationships, especially when MAC ACKs are still received even if the parent no longer maintains the child entry.

However, since some deployed devices do not enable this feature, we would like to understand what scenarios could lead to inconsistent states.

We are interested in situations where the following condition occurs:

1. A SED successfully attaches to an FTD parent
2. The parent creates a child table entry
3. At some point the parent removes the child entry
4. The SED continues sending Data Poll requests
5. The parent radio still responds with MAC ACK
6. The SED believes the parent is still valid

Result:

1. The parent's child table no longer contains the SED
2. The SED continues polling the parent

I want to understand under what circumstances this abnormal phenomenon would occur, and what causes the parent node's childtable to lose the SED node.

[fuxiaoming-lumi]

FYI https://github.com/SiliconLabs/simplicity_sdk/blob/36e12f01947c2bed82922015e87b926df0745bc2/protocol/openthread/platform-abstraction/efr32/openthread-core-efr32-config.h#L218
And Matter 1.4.0.0 tag for https://github.com/project-chip/connectedhomeip/tree/v1.4.0.0/third_party/silabs 36e12f01947c2bed82922015e87b926df0745bc2

[abtink]

I would strongly suggest to enable child supervision on all devices (very important on SED).

[jwhui]

When Child Supervision is disabled, a Sleepy End Device (SED) relies entirely on MAC layer acknowledgments to determine if its parent is still valid. Here is a breakdown of why this illusion occurs and the specific scenarios that cause the parent to lose the child entry in the first place.

The Root Cause of the Illusion: Hardware Auto-ACKs

To understand why the SED thinks it is still attached, we have to look at how the radio hardware interacts with the OpenThread software stack:

1. The Poll: The SED wakes up and sends an IEEE 802.15.4 Data Request (a MAC poll) to the parent. This frame has the "Ack Request" bit set.
2. The Hardware Response: The parent's 802.15.4 radio transceiver receives the frame, validates the Frame Check Sequence (FCS) and destination address, and automatically fires back a MAC ACK in hardware within microseconds.
3. The Software Drop: After the radio sends the ACK, it passes the frame up to the OpenThread software stack. OpenThread checks the source address, realizes this device is not in its child table, and silently drops the packet (often logging an UnknownNeighbor error).

Because the MAC ACK is generated by the radio hardware before the OpenThread stack validates the child table, the SED receives the ACK, assumes the parent is happily holding onto its messages, and goes back to sleep.

Scenarios Leading to the Lost Child Entry

Since the SED successfully attached initially, the parent must have actively removed the child entry. Here are the most common deployment scenarios that trigger this:

• Scenario A: Parent Power Cycle or Reset (Most Common)
  If the FTD parent loses power, reboots due to a watchdog reset, or receives a firmware update, its RAM is cleared. When it boots back up, its child table is completely empty. When the SED wakes up and polls, the parent radio ACKs it, but the parent stack has no memory of the SED.
• Scenario B: The SED Missed its Child Timeout
  During the initial MLE attach process, the SED registers a "Child Timeout" value with the parent. If the parent does not receive a poll from the SED within this window, it times out the SED from its table. This can happen if the SED experiences deep-sleep clock drift, if RF interference blocks several consecutive polls, or if the SED's application layer incorrectly delayed a wake-up cycle.

The Impact

Without Child Supervision, the SED is entirely blind to these upper-layer disconnections. It will remain stuck in this "zombie" loop—polling, getting an ACK, and sleeping—indefinitely. It will never realize it needs to initiate a new MLE attach process to find a new parent, resulting in a complete loss of IPv6 connectivity for that node.

[fuxiaoming-lumi]

Yes, we are aware of this issue and need to enable this feature. Unfortunately, some chip SDKs do not enable this function by default.

Returning to the question, I also considered the possibility of a parent node reboot, or that the parent node might not have received data polling, leading to the loss of information in the child table. However, the polling interval for this SED is 5 seconds. Normally, packet loss shouldn't be consistent. Because if there are more than 4 polling packet losses, it should trigger a reattach behavior on the device.

One possibility I can think of is that the parent node underwent a role switch within a short period, say 5 seconds, from router->mtd->router, and the router's short address did not change.

[jwhui]

It is possible for a node to reboot and restore connectivity in less than 5 seconds.