Openthread sleepy Child re-attach process

[Exormeter]

Hello, I have a question about the timeslot where the sleepy end device is searching for a router in it area.
I am experimenting with the energy consumption and was wondering if the timeslot could be reduced. Openthread certification is currently not a concern for me, so I am free in this regard.

I have found this thread for the subject matter (https://devzone.nordicsemi.com/f/nordic-q-a/48433/openthread-sleepy-child-re-attach-process) and I was able to recompile my project with changes in the values of kParentResponseMaxDelayRouters
kParentResponseMaxDelayAll, but I could not observe any change in duration for the re-attach interval. The attached screenshot shows the spike in energy consumption for about 3.5 seconds.

My question is, why does the change of the parameters do not change the interval and which parameter could I change to see a difference in behavior?

[abtink]

The kParentResponseMaxDelayAll and kParentResponseMaxDelayRouters values determine how long a child device waits for "Parent Response" messages after sending a "Parent Request". Parents randomly delay their responses within this window to prevent collisions (multiple responses at once). These are Thread specification-defined constants essential for the attach process. I would highly advice against changing these values

I think you may be interested in the OpenThread-specific "Attach Backoff" feature.

openthread/src/core/config/mle.h

Lines 137 to 220 in 8b906eb

	/**
	* @def OPENTHREAD_CONFIG_MLE_ATTACH_BACKOFF_ENABLE
	*
	* Define as 1 to enable attach backoff feature
	*
	* When this feature is enabled, an exponentially increasing backoff wait time is added between attach attempts.
	* If device is sleepy, the radio will be put to sleep during the wait time. This ensures that a battery-powered sleepy
	* end-device does not drain its battery by continuously searching for a parent to attach to (when there is no
	* router/parent for it to attach).
	*
	* The backoff time starts from a minimum interval specified by
	* `OPENTHREAD_CONFIG_MLE_ATTACH_BACKOFF_MINIMUM_INTERVAL`, and every attach attempt the wait time is doubled up to
	* `OPENTHREAD_CONFIG_MLE_ATTACH_BACKOFF_MAXIMUM_INTERVAL` which specifies the maximum wait time.
	*
	* Once the wait time reaches the maximum, a random jitter interval is added to it. The maximum value for jitter is
	* specified by `OPENTHREAD_CONFIG_MLE_ATTACH_BACKOFF_JITTER_INTERVAL`. The random jitter is selected uniformly within
	* range `[-JITTER, +JITTER]`. It is only added when the backoff wait interval is at maximum value.
	*
	*/
	#ifndef OPENTHREAD_CONFIG_MLE_ATTACH_BACKOFF_ENABLE
	#define OPENTHREAD_CONFIG_MLE_ATTACH_BACKOFF_ENABLE 1
	#endif
	/**
	* @def OPENTHREAD_CONFIG_MLE_ATTACH_BACKOFF_MINIMUM_INTERVAL
	*
	* Specifies the minimum backoff wait interval (in milliseconds) used by attach backoff feature.
	*
	* Applicable only if attach backoff feature is enabled (see `OPENTHREAD_CONFIG_MLE_ATTACH_BACKOFF_ENABLE`).
	*
	* Please see `OPENTHREAD_CONFIG_MLE_ATTACH_BACKOFF_ENABLE` description for more details.
	*
	*/
	#ifndef OPENTHREAD_CONFIG_MLE_ATTACH_BACKOFF_MINIMUM_INTERVAL
	#define OPENTHREAD_CONFIG_MLE_ATTACH_BACKOFF_MINIMUM_INTERVAL 251
	#endif
	/**
	* @def OPENTHREAD_CONFIG_MLE_ATTACH_BACKOFF_MAXIMUM_INTERVAL
	*
	* Specifies the maximum backoff wait interval (in milliseconds) used by attach backoff feature.
	*
	* Applicable only if attach backoff feature is enabled (see `OPENTHREAD_CONFIG_MLE_ATTACH_BACKOFF_ENABLE`).
	*
	* Please see `OPENTHREAD_CONFIG_MLE_ATTACH_BACKOFF_ENABLE` description for more details.
	*
	*/
	#ifndef OPENTHREAD_CONFIG_MLE_ATTACH_BACKOFF_MAXIMUM_INTERVAL
	#define OPENTHREAD_CONFIG_MLE_ATTACH_BACKOFF_MAXIMUM_INTERVAL 1200000 // 1200 seconds = 20 minutes
	#endif
	/**
	* @def OPENTHREAD_CONFIG_MLE_ATTACH_BACKOFF_JITTER_INTERVAL
	*
	* Specifies the maximum jitter interval (in milliseconds) used by attach backoff feature.
	*
	* Applicable only if attach backoff feature is enabled (see `OPENTHREAD_CONFIG_MLE_ATTACH_BACKOFF_ENABLE`).
	*
	* Please see `OPENTHREAD_CONFIG_MLE_ATTACH_BACKOFF_ENABLE` description for more details.
	*
	*/
	#ifndef OPENTHREAD_CONFIG_MLE_ATTACH_BACKOFF_JITTER_INTERVAL
	#define OPENTHREAD_CONFIG_MLE_ATTACH_BACKOFF_JITTER_INTERVAL 2000
	#endif
	/**
	* @def OPENTHREAD_CONFIG_MLE_ATTACH_BACKOFF_DELAY_TO_RESET_BACKOFF_INTERVAL
	*
	* Specifies the delay wait interval (in milliseconds) used by attach backoff feature after a successful attach before
	* it resets the current backoff interval back to the minimum value.
	*
	* If it is set to zero then the device resets its backoff attach interval immediately after a successful attach. With
	* a non-zero value, if after a successful attach, the device happens to detach within the delay interval, the reattach
	* process resumes with the previous backoff interval (as if the attach did not happen).
	*
	* This behavior is helpful in the situation where a battery-powered device has poor link quality to its parent and
	* therefore attaches and detaches frequently from the parent. Using a non-zero wait interval ensures that the attach
	* backoff interval does not reset on each attach and that the device does not drain its battery quickly trying to
	* re-attach too frequently.
	*
	*/
	#ifndef OPENTHREAD_CONFIG_MLE_ATTACH_BACKOFF_DELAY_TO_RESET_BACKOFF_INTERVAL
	#define OPENTHREAD_CONFIG_MLE_ATTACH_BACKOFF_DELAY_TO_RESET_BACKOFF_INTERVAL 20000
	#endif

There are a bunch of config parameters that control the timings of this feature:

• OPENTHREAD_CONFIG_MLE_ATTACH_BACKOFF_MINIMUM_INTERVAL
• OPENTHREAD_CONFIG_MLE_ATTACH_BACKOFF_MAXIMUM_INTERVAL
• OPENTHREAD_CONFIG_MLE_ATTACH_BACKOFF_JITTER_INTERVAL
• OPENTHREAD_CONFIG_MLE_ATTACH_BACKOFF_DELAY_TO_RESET_BACKOFF_INTERVAL