doc: thread: SSED and device type updates

Updated SED vs SSED docs with clarifications about use cases.
Updated Thread device type page to fix inaccuracies.
KRKNWK-16099 and PR #11410.

Signed-off-by: Grzegorz Ferenc <Grzegorz.Ferenc@nordicsemi.no>

doc/nrf/protocols/thread/device_types.rst

@@ -8,15 +8,38 @@ Thread device types
  :depth: 2
 
 Thread devices can be either Full Thread Devices (FTD) or Minimal Thread Devices (MTD).
-The devices are divided based on their ability to exist in a network without a parent, determined by whether the device maintains a routing table (doesn't need a parent) or not (needs a parent).
-FTDs are the devices that maintain a routing table, while MTDs do not, forwarding all their messages to a parent instead.
+Generally speaking, the devices are classified based on the following criteria:
 
-Another type of Thread device classification is based on the device's ability to route messages:
+* What role they have in a Thread network - whether they are router-capable (Router, Leader) or can be just an End Device.
+* What is the communication scheme - whether the device keeps its radio enabled all the time or sporadically (allowing the device to sleep and save power).
+* How they route messages - whether it maintains a routing table (can route messages) or not (does not route messages).
+* Which Thread management functionalities they implement - whether they perform them by itself (for example, address resolution or address registration) or rely on the parent.
+
+The role and routing criteria can be used to classify the Thread devices as follows:
 
 * Routers can route messages, and they can function as parents to other Thread devices.
 * End Devices cannot route messages, and they cannot function as parents.
 
-Based on this classification, FTDs can be either Routers or End Devices, while MTDs can only be End Devices.
+Based on all these criteria, the Thread devices can be classified as follows:
+
+.. list-table:: Thread device classification
+ :header-rows: 1
+
+ * -
+ - Role
+ - Communication scheme
+ - Message routing method
+ - Thread management functionalities
+ * - Full Thread Devices (FTDs)
+ - Routers (Leaders) or End Devices
+ - Keep their radios enabled all the time.
+ - Maintain a routing table.
+ - Routers perform them by itself. End Devices classified as FTDs have some management functionalities.
+ * - Minimal Thread Devices (MTDs)
+ - End Devices
+ - May not have their radio enabled at all times.
+ - Do not maintain a routing table and forward all their messages to the parent.
+ - Rely on the parent to perform them.
 
 For additional information about Thread device types, see the documentation for `Device Types on OpenThread portal`_.
 
@@ -25,48 +48,50 @@ For additional information about Thread device types, see the documentation for
 Full Thread Devices
 *******************
 
-In order to maintain the routing table, FTDs keep their radio on at all times.
-An important difference between FTDs and MTDs is that FTDs subscribe to special "all-routers" multicast addresses (``ff02::2`` and ``ff03::2``, see `IPv6 multicast addressing`_).
-Because of these reasons, they typically consume more power than MTDs.
+FTDs keep their radio enabled at all times to be ready to receive messages asynchronously.
+They typically consume more power than MTDs and are mains-powered, which allows them to have the following functionalities that MTDs do not have, among others:
+
+* Ability to resolve IPv6 addresses
+* Handling address registration
+* Maintaining routing table
+* Maintaining links with neighbors
 
-Full Thread Devices can be further divided into three categories:
+Another important difference between FTDs and MTDs is that FTDs subscribe to special "all-routers" multicast addresses (``ff02::2`` and ``ff03::2``, see `IPv6 multicast addressing`_).
+
+Full Thread Devices can be further divided into the following roles, which depend on the topology of the network:
 
 * Router
-* Full End Device (FED)
-* Router Eligible End Device (REED)
+* Full End Device (FED) or Router Eligible End Device (REED)
 
-.. list-table:: Full Thread Device categories
- :widths: 15 10 10 15
+.. list-table:: Full Thread Device network role categories
  :header-rows: 1
 
  * -
  - Router
- - Full End Device
- - Router Eligible End Device
+ - Full End Device (FED) or Router Eligible End Device (REED)
  * - Maintains a routing table
  - Yes
  - Yes
- - Yes
  * - Routes messages
  - Yes
  - No
- - When working as a Router
  * - Can extend the network
  - Yes
  - No
- - When working as a Router
 
 Routers can be regarded as the backbone of a Thread network.
 They maintain the routing table and forward messages to other devices.
 Routers, unlike End Devices, can also be used to extend the network range and a Router is required for a Minimal End Device to join the network.
-The maximum number of Routers in a single Thread network is 32.
+The maximum number of active Routers in a single Thread network is 32.
+
+FEDs are End Devices that maintain a routing table, but they can't route messages.
+FEDs are End Devices with FTDs capabilities to perform certain Thread management functionalities on behalf of their parent (Router), such as address resolution, effectively reducing the parent's computation power.
+They are child devices that require a parent to function, but they cannot become parents themselves.
 
-FEDs maintain a routing table, but they can't route messages.
-This means they don't require a parent (Router) to function, but they cannot become parents themselves.
+REEDs are End Devices that maintain a routing table and can be promoted to be Routers if needed.
+If a REED is the only device in range of an End Device trying to join the network, it will proactively request promotion to the Router role (see `Joining an existing Thread network`_ in the OpenThread documentation for more information).
 
-REEDs maintain a routing table and, unlike FEDs, they can become Routers if needed.
-If a REED is the only device in range of an End Device trying to join the network, it will promote itself to a Router (see `Joining an existing Thread network`_ in the OpenThread documentation for more information).
-Conversely, when a Router has no children it can downgrade itself to a REED.
+Depending on the network topology conditions, a Router may downgrade itself to a REED role, for example when it does not have any children and there is already a sufficient number of Routers in the network.
 
 .. _thread_types_mtd:
 
@@ -84,7 +109,6 @@ Minimal Thread Devices can be further divided into three categories:
 * Synchronized Sleepy End Device (SSED)
 
 .. list-table:: Minimal Thread Device categories
- :widths: 15 10 10 15
  :header-rows: 1
 
  * -
@@ -95,33 +119,37 @@ Minimal Thread Devices can be further divided into three categories:
  - No
  - No
  - No
- * - Radio on
- - Always
- - Periodically
- - Periodically
+ * - Radio
+ - Always enabled
+ - Periodically enabled
+ - Periodically enabled
  * - New messages
  - Parent immediately forwards the messages
  - The SED polls for new messages when it wakes up
- - Parent forwards the messages during designated transmission window
+ - Parent forwards the messages during designated transmission window or when SSED explicitly polls data
  * - No new messages
  - No data transmission
  - Parent indicates no pending messages
- - No data transmission
+ - No data transmission*
 
-MEDs are the most basic MTDs, and their radio is always on.
-They don't keep a routing table, but otherwise operate like :ref:`FEDs <thread_types_ftd>`.
+MEDs are the most basic MTDs, and their radio is always enabled.
+They don't keep a routing table and have a :ref:`more limited range of functionalities than FEDs <thread_types_ftd>`.
 
 SEDs try to limit their power consumption by sleeping most of the time, waking up periodically to poll for messages from their parent.
 After waking up, they send a data request to their parent.
-If the parent has any pending messages, it will send them to the SED.
+If the parent has any pending messages, it will send them to the SED (which can happen at any time, since Routers have their radio enabled all the time.)
 Otherwise, the parent will send a response indicating no pending messages.
 
 SSEDs operate similarly to Sleepy End Devices, but they are synchronized with their parent.
-They wake up at the same time as their parent, eliminating the need for polling for messages.
+They wake up at designated transmission windows agreed with their their parent, which eliminates the need for polling for messages.
 If the parent has messages for the SSED, it sends them during the designated transmission window.
 The SSED allows the transmission to finish if radio activity is detected during the transmission window.
+
+.. note::
+ If the length of the message exceeds the length of the transmission window, the first frame is received in the designated transmission window, but the rest is transmitted using regular Data Polls, exactly like SED.
+
 Conversely, if there is no radio activity during the specified duration of transmission window, this indicates that the parent has no messages for the SSED and the SSED returns to sleep.
-The SSED synchronization results in lower power consumption compared to an SED, primarily because the SSED doesn't need to poll for messages, keeping transmission windows short.
+The SSED synchronization results in lower power consumption compared to an SED in some scenarios, primarily because the SSED doesn't need to poll for messages, keeping transmission windows short.
 
 For more information about SSED activity, see the :ref:`thread_sed_ssed` page.
 

doc/nrf/protocols/thread/sed_ssed.rst

@@ -55,7 +55,19 @@ Comparison of SED and SSED
 **************************
 
 Compared to an SED, an SSED has no drawbacks for transmission and provides reduced power consumption and network traffic.
-This means you should configure your SED devices as SSEDs whenever possible.
+
+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 :ref:`Thread power consumption <thread_power_consumption>` page.
 
 .. figure:: overview/images/thread_sed_ssed_comparison.svg

samples/matter/window_covering/README.rst

@@ -50,7 +50,7 @@ During those intervals, the device waits for the router to send it any data rela
 The 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 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.
-Compared to a standard SED, the SSED features further reduce energy consumption of the device and generate less data traffic.
+Compared to a standard SED, the SSED features can further reduce energy consumption of the device and generate less data traffic.
 
 .. figure:: ../../../doc/nrf/protocols/thread/overview/images/thread_sed_ssed_comparison.svg
  :alt: Comparison of Thread SED and Thread SSED radio activity