Sleepy End Device types in Thread

Sleepy End Devices (SEDs) and Synchronized Sleepy End Devices (SSEDs) are both Minimal Thread Devices (MTDs). Unlike Full Thread Devices (FTDs), MTDs do not maintain a routing table and are typically low-power devices that are not always on.

For more information, see the Minimal Thread Devices section in the Thread device types documentation.

The SEDs and SSEDs are often used as one of the measures to optimize power consumption.

Sleepy End Device

SEDs are MTDs that sleep most of the time in order to minimize the power consumption. They communicate with the Thread network by occasionally polling the parent Router for any pending data.

The CONFIG_OPENTHREAD_POLL_PERIOD Kconfig handles the SED configuration by configuring the polling period. A higher polling frequency results in lower latency (better responsiveness), but also higher power consumption.

The polling period can also be configured in runtime. See the pollperiod command in the OpenThread CLI reference.

Synchronized Sleepy End Device

SSEDs are MTDs that are further optimized for power consumption. A Thread SSED is synchronized with its parent Router and uses the radio only at scheduled intervals. It does this by using the Coordinated Sampled Listening (CSL) feature (introduced as one of the Thread 1.2 Base Features). During those intervals, the device waits for the Router to send it any data related to the desired device activity. This reduces the network traffic (since there is no polling) and the power consumption (since the radio is off most of the time).

An SSED does require sending packets occasionally to keep synchronization with the Router. However, unlike a regular SED, an SSED does not actively communicate with the Router by polling and it goes into the idle mode between the scheduled activity periods. If there is no application-related traffic for an extended period of time, the SSED sends a data poll request packet to synchronize with the parent.

The nRF Connect SDK provides the following Kconfig options that let you enable CSL and specify the CSL parameters:

The following Kconfig options affect the size of the receive window, and thus also affect the device’s power consumption:

Additionally, you must configure the period CLI parameter to enable CSL. For more information on using the CLI to configure parameters for CSL, see the csl command in the OpenThread CLI reference.

Comparison of SED and SSED

Compared to an SED, an SSED has no drawbacks for transmission and provides reduced power consumption and network traffic.

Based on the SED and SSED characteristics, use SSED for cases that meet one or more of the following criteria:

  • You need a small latency (ensured by small poll period for SEDs or small CSL Period for SSEDs). As a general rule, SSED is a viable option and may decrease power consumption if the CSL Period is small (less than 20 seconds) and the parent has decent CSL Accuracy.

  • You want to have similar or smaller power consumption than with SED.

  • You want to reduce over-the-air radio traffic in an environment with many SEDs.

In short, SSEDs are viable only when the additional application code and complexity to handle the more frequent polling are justified by the lower power usage or less intensive radio channel usage (or both).

For example, one specific market application of SSEDs could be window coverings. For this use case to work as an SSED, the blinds must be very responsive (for example, with a latency within 500 ms), while the data must be very rarely exchanged between the controller device and the window covering device.

You can see the difference in power consumption on the Thread power consumption page.

Comparison of Thread SED and Thread SSED radio activity

Comparison of Thread SED and Thread SSED radio activity