Openthread SED detection of parent

RE: Openthread SED detection of parent

Susheel Nuguru — Mon, 24 Nov 2025 07:58:55 GMT

Yes Kaushalya, you can patch those files in your current NCSv2.9.0 but please make sure that you select CONFIG_OPENTHREAD_NORDIC_LIBRARY=n and prestine build the whole OpenThread sources.

Also note that a local edit in your SDK repo will be overwritten by a west update or similar commands, so you might have to maintain your own branch which branches out from NCSv2.9.0

RE: Openthread SED detection of parent

kaushalyasat — Mon, 24 Nov 2025 00:08:06 GMT

Hi Susheel, Many thanks for the detailed reply. In fact, I have moved on to other tasks and this issue is still holding in the backlog. So I have to refresh myself where I left off.

I guess it is ok if I modify these files in my current SDK 2.9.0 to do a temporary workaround?

Is there a way to keep these mods across SDK updates to same 2.9.0? i.e. not using SDK 2.10.x but updates to 2.9.0 itself.

Cheers,

Kaushalya

RE: Openthread SED detection of parent

Susheel Nuguru — Sun, 23 Nov 2025 10:34:08 GMT

Hi Kaushalya,

Sorry for long delay in replying this. Maria is away and this thread fell into the cracks where we could not see the delay.

I am starting to look into the configuration files and to my understanding it seems that the detach is coming from OpenThreads own link failure logic and not from the Kconfigs you are trying to calibrate/tweak.

In modules/lib/openthread/src/core/thread/mesh_forwarder.hpp the child’s parent link is dropped after kFailedRouterTransmissions consecutive NoAck results. That constant is hard-coded to 4 and is hit quickly when your polls/data all fail while the host is powered down OPENTHREAD_CONFIG_FAILED_CHILD_TRANSMISSIONS only affects how a parent drops its children; it doesn’t stop the child from detaching itself.

These thresholds are hardcoded and prebuilt into the Nordic OpenThread library so there is nothing much you can do about it. You can try to do this to make your SED to be attached for longer you need to use opensource OpenThread and need to prestine compile the whole OpenThread sources and not using the Nordic prebuilt library.

Rebuild OpenThread from source (not the prebuilt Nordic lib): set CONFIG_OPENTHREAD_NORDIC_LIBRARY=n in your app, then patch modules/lib/openthread/src/core/thread/mesh_forwarder.hpp to raise kFailedRouterTransmissions (e.g., 50 or 100) or wrap it in a macro you define. Example change: static constexpr uint8_t kFailedRouterTransmissions = 50;.
Keep your large CONFIG_OPENTHREAD_MLE_CHILD_TIMEOUT so the parent won’t drop the child while the host is down.
To avoid burning through the failure counter, back off polling and app traffic when you detect the host is off (e.g., call otLinkSetPollPeriod() to a large interval or pause transmissions). That avoids rapid NoAck accumulation.

After patching, rebuild so OpenThread is recompiled; then check build/zephyr/.config to confirm CONFIG_OPENTHREAD_NORDIC_LIBRARY is off and verify in logs that detaches no longer occur after a single failed send

Note:

RE: Openthread SED detection of parent

kaushalyasat — Wed, 15 Oct 2025 04:05:52 GMT

Hi Maria,

I have tried modifying OPENTHREAD_CONFIG_FAILED_CHILD_TRANSMISSIONS to 100 in [sdk path]\v2.9.0\modules\lib\openthread\src\core\config\misc.h. But still my SED seems detaching within one failed poll cycle.

How can I keep the SED in child state inspite of transmission failure for a longer time?

Cheers,

Kaushalya

RE: Openthread SED detection of parent

kaushalyasat — Sun, 12 Oct 2025 02:15:36 GMT

Hi Maria,

I have now given up on this MAC level parent detection mechanism.

I am trying to keep the sensors which have attached and in child state, in child state for longer in the presence of host powering down. The sensor data and polls will get NAK as transmissions fail. The idea is when the host powers up in a hour or two, it will retain the same network credentials and the sensors which are in child state can resume data tx as if nothing happened, without any MLE session.

I have tried

Enabling child supervision and extending CONFIG_OPENTHREAD_CHILD_SUPERVISION_CHECK_TIMEOUT=3000 and CONFIG_OPENTHREAD_MLE_CHILD_TIMEOUT=3000.
This didnt work as Meshforwarder detects tx failure and seemingly immediately detaches the child. I was sending conformable packet, but I got the NAK to application layer much later. The detection seems very aggressive like in one tx fail, it detaches. Following is what I see from console.

[00:00:41.370,300] <inf> [N] Mle-----------: Attach attempt 2, AnyPartition
[00:00:43.500,854] <inf> [N] Mle-----------: RLOC16 fffe -> dc01
[00:00:43.500,976] <inf> [N] Mle-----------: Role detached -> child
[00:00:43.508,239] <inf> coap_client_utils: ------- Sensor Start --------
[00:00:43.508,239] <inf> coap_client_utils: Ext Addr: e2:59:51:2d:d1:ac:01:37
[00:00:43.508,270] <inf> coap_client_utils: MAC: f4:ce:36:4b:d5:b9:c6:71
[00:00:43.508,270] <inf> coap_client_utils: RLOC: dc01
[00:00:44.069,854] <inf> coap_client: SHT4X: 22.78 Temp. [C] ; 39.90 RH [%]
[00:00:44.069,885] <inf> coap_client: Temp: 22.78       RH: 39.90
[00:00:44.074,615] <inf> coap_client_utils: ZS 0, RSSI -75, LQI 3, LQO 2, FW 1241 RET: 0, RLOC: dc01
[00:01:00.036,407] <dbg> temp_nrf5_mpsl: temp_nrf5_mpsl_sample_fetch: sample: 87
[00:01:00.036,437] <dbg> temp_nrf5_mpsl: temp_nrf5_mpsl_channel_get: Temperature:21,750000
[00:01:05.037,567] <dbg> coap_client_utils: parent_monitor_work_handler: Parent status: RESPONSIVE (in CHILD role)
[00:01:13.514,221] <inf> coap_client_utils: ---- Host ACK -----
[00:01:13.514,251] <inf> coap_client_utils: Result : 0
[00:01:13.514,282] <inf> coap_client_utils: ✓ CoAP transmission successful
[00:01:35.037,689] <dbg> coap_client_utils: parent_monitor_work_handler: Parent status: RESPONSIVE (in CHILD role)
[00:01:44.083,007] <inf> coap_client: SHT4X: 22.79 Temp. [C] ; 39.88 RH [%]
[00:01:44.083,038] <inf> coap_client: Temp: 22.79       RH: 39.88
[00:01:44.087,768] <inf> coap_client_utils: ZS 0, RSSI -75, LQI 3, LQO 2, FW 1241 RET: 0, RLOC: dc01
[00:01:44.232,666] <inf> [N] MeshForwarder-: Failed to send IPv6 UDP msg, len:103, chksum:2033, ecn:no, to:0xdc00, sec:yes, error:NoAck, prio:normal
[00:01:44.232,940] <inf> [N] MeshForwarder-:     src:[fdde:ad00:beef:0:dccd:79d4:8f11:f62d]:5683
[00:01:44.233,184] <inf> [N] MeshForwarder-:     dst:[fdde:ad00:beef:0:8c62:93f7:ebb6:e2c4]:5683
[00:01:45.612,365] <inf> [N] Mle-----------: Role child -> detached
[00:01:45.612,579] <inf> [N] Mle-----------: RLOC16 dc01 -> fffe
[00:01:46.076,538] <inf> coap_client: Paired->Not Connected
[00:01:46.356,872] <inf> [N] Mle-----------: Attach attempt 1, AnyPartition

How can I relax the MLE detachment in one tx error?

I have added the following in CMakeLists.txt

OPENTHREAD_CONFIG_FAILED_CHILD_TRANSMISSIONS=100

# Also increase MAC retries
OPENTHREAD_CONFIG_MAC_DEFAULT_MAX_FRAME_RETRIES_DIRECT=15

# Disable parent search 
OPENTHREAD_CONFIG_PARENT_SEARCH_ENABLE=0

# Disable link request on timeout 
OPENTHREAD_CONFIG_MLE_SEND_LINK_REQUEST_ON_ADV_TIMEOUT=0

Nothing seem to help. Still one tx fail, the child detaches.

Please help.
Cheers,
Kaushalya

RE: Openthread SED detection of parent

Maria Gilje — Wed, 08 Oct 2025 13:44:24 GMT

Hi Kaushalya,

Thank you for your patience.

[quote user="kaushalyasat"]

Ok, can we do any MAC level monitoring to see if the parent is back? I know my parent's commissioned details.

The issue of SED sending MLE approach is

1. if I want to save power, then I have to extend backoff. This means the SED may see the parent after a long time.

2. if I have shorter MLE cycles, then the battery will drain quickly.

This is why I am looking at another approach.

[/quote]

I asked internally about an alternative method for reattaching a SED to its parent. The feedback I got was that the only method we only provide is the MLE Attachment procedure. You are free to configure the MLE Parent Search back-off algorithm to meet your needs.

It could be possible to use and out-of-band method to determine if a parent is in range and use the OpenThread API to manually startthe attachment. otThreadBecomeChild does this, but it is only meant for demo purposes, as noted in the source code. Using the API may cause the device to cease following the Thread specification.

[quote user="Maria Gilje"] The SED periodically turning on the radio and not sending parent requests in a detached state is also not expected behaviour. [/quote][quote user="kaushalyasat"]These parent requests are the MLEs? I have relaxed my MLE backoff minimum to 5 minutes and max to 1Hr. I can see MLE current pulses occasionally. [/quote]

Yes, they are MLE Parent Requests.

[quote user="kaushalyasat"]I can. The logging is not disabled. The issue is as soon as I enable console to get the logs, it increases current consumption and I cant see the current pulses anymore. If I use RTT console, does it still affect current consumption?[/quote]

Understood. Based on my experience, the backend used for logging does not make a big difference in current consumption. Let's not go forward with this as a debugging tool for now.

[quote user="kaushalyasat"]You think I can monitor the radio space using wireshark to see if this SED is sending any radio packets? I was looking for MLE traffic but not anything else from the SED. I will relax my filters and see any traffic from the SED.[/quote]

Yes, this was what I was thinking. Let me know if you saw some possible source for the spikes in the packets after relaxing your filters.

In my internal inquiry I also asked about the 8s interval spikes, which was also not familiar to them. Some more information on your application is likely needed to move forward. Could you please share some more information on what your application is doing? Did you start with a sample?

Best regards,

Maria

RE: Openthread SED detection of parent

kaushalyasat — Wed, 24 Sep 2025 21:58:28 GMT

Hi Maria,

Thanks.

[quote userid="116814" url="~/f/nordic-q-a/124572/openthread-sed-detection-of-parent/549690"]Polling in a detached state does not make sense, as the SED would not have a parent to poll[/quote]

Ok, can we do any MAC level monitoring to see if the parent is back? I know my parent's commissioned details.

The issue of SED sending MLE approach is

1. if I want to save power, then I have to extend backoff. This means the SED may see the parent after a long time.

2. if I have shorter MLE cycles, then the battery will drain quickly.

This is why I am looking at another approach.

[quote userid="116814" url="~/f/nordic-q-a/124572/openthread-sed-detection-of-parent/549690"]The SED periodically turning on the radio and not sending parent requests in a detached state is also not expected behaviour.[/quote]

You think I can monitor the radio space using wireshark to see if this SED is sending any radio packets? I was looking for MLE traffic but not anything else from the SED. I will relax my filters and see any traffic from the SED.

[quote userid="116814" url="~/f/nordic-q-a/124572/openthread-sed-detection-of-parent/549690"]Are you able to get device logs from the SED[/quote]

I can. The logging is not disabled. The issue is as soon as I enable console to get the logs, it increases current consumption and I cant see the current pulses anymore. If I use RTT console, does it still affect current consumption?

[quote userid="116814" url="~/f/nordic-q-a/124572/openthread-sed-detection-of-parent/549690"]The 8s interval spikes are strange, and I don't have a first step to begin to investigate those at this point[/quote]

Does the radio performs any calibration during detached state?

These parent requests are the MLEs? I have relaxed my MLE backoff minimum to 5 minutes and max to 1Hr. I can see MLE current pulses occasionally.

Cheers,

Kaushalya

RE: Openthread SED detection of parent

Maria Gilje — Wed, 24 Sep 2025 12:57:09 GMT

Hi Kaushalya,

[quote user=""] Is there a way for the SED to keep on the polling even when in detached state?[/quote]

Polling in a detached state does not make sense, as the SED would not have a parent to poll. When a SED detaches from its parent it will send parent requests until a potential parent responds, then it performs a parent selection and attaches to the best parent.

If you want to implement another way to reattach your SED it seems from your description that you will not follow the specification.

[quote user="kaushalyasat"]Also I can see current pulses from the SED like this, even when detached. Could you explain what are they? None of them seem to increase MAC counters, so I think none of these are actual radio tx/rx sessions(?).[/quote]

I must admit that these pulses are unfamiliar to me. The current level could align with the radio being on, though the actual value is lower than the expected typical value from this table. The SED periodically turning on the radio and not sending parent requests in a detached state is also not expected behaviour.

Since you are mentioning the lack of increase for MAC counters during these spikes, I assume that you are already sniffing and analyzing the packets?

Are you able to get device logs from the SED? The current consumption will of course increase by enabling logging, but it could help to explain what the spikes are.

The 8s interval spikes are strange, and I don't have a first step to begin to investigate those at this point. Sorry about that.

Please also let me know if you are working with a DK or a custom board.

Best regards,

Maria

RE: Openthread SED detection of parent

kaushalyasat — Wed, 24 Sep 2025 03:15:27 GMT

Also I can see current pulses from the SED like this, even when detached. Could you explain what are they? None of them seem to increase MAC counters, so I think none of these are actual radio tx/rx sessions(?).

The pulses are like this in detail.

Also there is another pulse here

Which looks like this in detail