doc: thread: SSED and device type updates #11619

greg-fer · 2023-06-26T14:58:35Z

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

pjasinski990 · 2023-06-27T11:35:21Z

doc/nrf/protocols/thread/device_types.rst

+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).
+
+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 already in the network.


nit: "already" used twice

pjasinski990 · 2023-06-27T11:58:15Z

doc/nrf/protocols/thread/sed_ssed.rst

+
+Based on the SED and SSED characteristics, use SSED for cases that meet the following criteria:
+
+* You need a small latency (small CSL interval).


We could add that small latency comes from small poll period (when using SED) or small CSL interval (for SSEDs). I think this would make what we want to convey clearer.

pjasinski990 · 2023-06-27T12:23:43Z

doc/nrf/protocols/thread/sed_ssed.rst

+
+* You need a small latency (small CSL interval).
+ As a rule of thumb, use SSED when the application requires to poll more often than every 20 seconds, but make sure to make detailed measurements for your use case.
+* You want to have similar or smaller power consumption than with SED.


From what I understand, SSEDs are viable to use only when the added code and complexity are justified by the lower power usage. Frequent polling (eg. at least every 20s as proposed by Eduardo) makes the device a candidate to be a viable SSED, given the device and parent uncertainty (among other parameters) is good enough - so the decision whether to use SSED still requires some application-specific data.
We could write something along those lines - the more frequent polling, the better candidate the device is to be SSED, as long as other parameters don't make the transmission window's size abysmal.
The important thing here is also that parent devices from other vendors might have big uncertainty, which will result in a big transmission window regardless of how low the uncertainty of the child (SSED) is.

@LuDuda , any opinions about Piotr's proposal?

Good suggestions from Piotr. In general I'm a bit afraid to "recommend" SSED role blindly for manufacturers even if latency is less than ~20s.

The whole Thread/Matter ecosystem is not yet fully ready. I would say that the default option is SED. However, SSED is great when it's parent has small CSL uncertainty as well accuracy. We don't have an example in SDK, but customer may use information about parent's CSL parameters (uncertainty and accuracy) to switch to SSED role or not. This can be done just after attachment dynamically.

In general what Piotr suggested is great. E.g. that SSED is viable option and may decrease power consumption in case the CSL interval is small (~<20s) as well as parent has decent CSL parameters.

LuDuda

@greg-fer this is great, thank you!

I put few last comments, but it looks nice now.

LuDuda · 2023-06-29T10:03:12Z

doc/nrf/protocols/thread/device_types.rst

+* How they exist in a Thread network - whether the device keeps its radio enabled all the time.
+* How they route messages - whether it maintains a routing table (can route messages) or not (does not route messages).
+
+FTDs are the devices that keep their radios enabled all the time and maintain a routing table, while MTDs do not have their radio enabled at all times and they do not maintain a routing table, consequently forwarding all their messages to a parent instead.


Suggested change

FTDs are the devices that keep their radios enabled all the time and maintain a routing table, while MTDs do not have their radio enabled at all times and they do not maintain a routing table, consequently forwarding all their messages to a parent instead.

FTDs are the devices that keep their radios enabled all the time and maintain a routing table, while MTDs may have their radio enabled at all times and they do not maintain a routing table, consequently forwarding all their messages to a parent instead.

MED is one of MTD role which keeps its receiver on all the time - so "may" is more apropriate.

LuDuda · 2023-06-29T10:07:45Z

doc/nrf/protocols/thread/device_types.rst

+* How they exist in a Thread network - whether the device keeps its radio enabled all the time.
+* How they route messages - whether it maintains a routing table (can route messages) or not (does not route messages).


What about this?

Suggested change

* How they exist in a Thread network - whether the device keeps its radio enabled all the time.

* How they route messages - whether it maintains a routing table (can route messages) or not (does not 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 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 for example address resolution or address registration by itself or rely on the parent

LuDuda · 2023-06-29T10:11:41Z

doc/nrf/protocols/thread/device_types.rst

-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 categories, which depend on the topology of the network:


Suggested change

Full Thread Devices can be further divided into the following categories, which depend on the topology of the network:

Full Thread Devices can be further divided into the following roles, which depend on the topology of the network:

LuDuda · 2023-06-29T10:15:42Z

doc/nrf/protocols/thread/device_types.rst


-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.
+FEDs are End Devices that maintain a routing table, but they can't route messages.


Suggested change

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 such as address resolution. Effectively reducing it's router computation power"

In last sentence.. i want to say that FED relieves its partent from doing things on behalf of the child. This is the main advantage of FED.

LuDuda · 2023-06-29T10:17:37Z

doc/nrf/protocols/thread/device_types.rst


 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.
+(This can happen at any time, since Routers have their radio enabled all the time.)


nit: Does it make sence to have this information together with previous sentence? I mean...

"[..] to the SED (this can happen at any time..."

LuDuda · 2023-06-29T10:19:47Z

doc/nrf/protocols/thread/sed_ssed.rst

+ As a rule of thumb, use SSED when the application requires to poll more often than every 20 seconds, but make sure to make detailed measurements for your use case.
+* You want to have similar or smaller power consumption than with SED.
+
+For example, one specific market application of SSEDs could be window coverings.


Suggested change

For example, one specific market application of SSEDs could be window coverings.

For example, one specific market application of SSEDs could be window coverings. For this use-case blinds need to be very responsive e.g. latency within 500ms, while data is very rarely exchanged between controller device and window covering device.

LuDuda · 2023-06-29T10:24:28Z

doc/nrf/protocols/thread/sed_ssed.rst

+
+* You need a small latency (small CSL interval).
+ As a rule of thumb, use SSED when the application requires to poll more often than every 20 seconds, but make sure to make detailed measurements for your use case.
+* You want to have similar or smaller power consumption than with SED.


Good suggestions from Piotr. In general I'm a bit afraid to "recommend" SSED role blindly for manufacturers even if latency is less than ~20s.

The whole Thread/Matter ecosystem is not yet fully ready. I would say that the default option is SED. However, SSED is great when it's parent has small CSL uncertainty as well accuracy. We don't have an example in SDK, but customer may use information about parent's CSL parameters (uncertainty and accuracy) to switch to SSED role or not. This can be done just after attachment dynamically.

In general what Piotr suggested is great. E.g. that SSED is viable option and may decrease power consumption in case the CSL interval is small (~<20s) as well as parent has decent CSL parameters.

NordicBuilder · 2023-07-03T08:27:18Z

You can find the documentation preview for this PR at this link. It will be updated about 10 minutes after the documentation build succeeds.

Note: This comment is automatically posted by the Documentation Publishing GitHub Action.

edmont · 2023-07-03T11:25:51Z

doc/nrf/protocols/thread/device_types.rst

+
+.. 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.


Suggested change

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 usually results in lower power consumption compared to an SED, primarily because the SSED doesn't need to poll for messages, keeping transmission windows short.

doc/nrf/protocols/thread/sed_ssed.rst

greg-fer · 2023-07-03T12:03:39Z

@pjasinski990 , @edmont , @LuDuda , please kindly check again when the doc build completes.

doc/nrf/protocols/thread/sed_ssed.rst

doc/nrf/protocols/thread/device_types.rst

Updated SED vs SSED docs with clarifications about use cases. Updated Thread device type page to fix inaccuracies. KRKNWK-16099 and PR nrfconnect#11410. Signed-off-by: Grzegorz Ferenc <Grzegorz.Ferenc@nordicsemi.no>

greg-fer · 2023-07-04T10:53:48Z

Applied your edits, @edmont

greg-fer added the CI-disable Disable CI for this PR label Jun 26, 2023

greg-fer requested review from edmont, LuDuda and pjasinski990 June 26, 2023 14:58

greg-fer requested review from Damian-Nordic, kkasperczyk-no and carlescufi as code owners June 26, 2023 14:58

github-actions bot added changelog-entry-required Update changelog before merge. Remove label if entry is not needed or already added. doc-required PR must not be merged without tech writer approval. labels Jun 26, 2023

greg-fer mentioned this pull request Jun 26, 2023

doc: Thread: created types page, moved sed vs ssed #11410

Merged

pjasinski990 reviewed Jun 27, 2023

View reviewed changes

LuDuda reviewed Jun 29, 2023

View reviewed changes

greg-fer force-pushed the doc_thread_ssed_clarifications branch from 4e2a3d6 to a816516 Compare July 3, 2023 07:37

greg-fer force-pushed the doc_thread_ssed_clarifications branch from a816516 to 57564df Compare July 3, 2023 10:28

edmont reviewed Jul 3, 2023

View reviewed changes

greg-fer force-pushed the doc_thread_ssed_clarifications branch from 57564df to 6cc972b Compare July 3, 2023 12:02

edmont reviewed Jul 3, 2023

View reviewed changes

doc/nrf/protocols/thread/sed_ssed.rst Outdated Show resolved Hide resolved

edmont reviewed Jul 3, 2023

View reviewed changes

doc/nrf/protocols/thread/device_types.rst Outdated Show resolved Hide resolved

pjasinski990 approved these changes Jul 4, 2023

View reviewed changes

doc: thread: SSED and device type updates

a19e90c

Updated SED vs SSED docs with clarifications about use cases. Updated Thread device type page to fix inaccuracies. KRKNWK-16099 and PR nrfconnect#11410. Signed-off-by: Grzegorz Ferenc <Grzegorz.Ferenc@nordicsemi.no>

greg-fer force-pushed the doc_thread_ssed_clarifications branch from 6cc972b to a19e90c Compare July 4, 2023 10:53

edmont approved these changes Jul 4, 2023

View reviewed changes

LuDuda approved these changes Jul 4, 2023

View reviewed changes

nordicjm merged commit 5ccffbe into nrfconnect:main Jul 10, 2023
11 checks passed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

doc: thread: SSED and device type updates #11619

doc: thread: SSED and device type updates #11619

greg-fer commented Jun 26, 2023

pjasinski990 Jun 27, 2023

pjasinski990 Jun 27, 2023

pjasinski990 Jun 27, 2023 •

edited

Loading

greg-fer Jun 29, 2023

LuDuda Jun 29, 2023

LuDuda left a comment

LuDuda Jun 29, 2023 •

edited

Loading

LuDuda Jun 29, 2023

LuDuda Jun 29, 2023

LuDuda Jun 29, 2023

LuDuda Jun 29, 2023

LuDuda Jun 29, 2023

LuDuda Jun 29, 2023

NordicBuilder commented Jul 3, 2023

edmont Jul 3, 2023

greg-fer commented Jul 3, 2023

greg-fer commented Jul 4, 2023


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

		* You need a small latency (small CSL interval).

	FTDs are the devices that keep their radios enabled all the time and maintain a routing table, while MTDs do not have their radio enabled at all times and they do not maintain a routing table, consequently forwarding all their messages to a parent instead.
	FTDs are the devices that keep their radios enabled all the time and maintain a routing table, while MTDs may have their radio enabled at all times and they do not maintain a routing table, consequently forwarding all their messages to a parent instead.

		* How they exist in a Thread network - whether the device keeps its radio enabled all the time.
		* How they route messages - whether it maintains a routing table (can route messages) or not (does not route messages).

	Full Thread Devices can be further divided into the following categories, which depend on the topology of the network:
	Full Thread Devices can be further divided into the following roles, which depend on the topology of the network:

	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 such as address resolution. Effectively reducing it's router computation power"

	For example, one specific market application of SSEDs could be window coverings.
	For example, one specific market application of SSEDs could be window coverings. For this use-case blinds need to be very responsive e.g. latency within 500ms, while data is very rarely exchanged between controller device and window covering device.

	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 usually results in lower power consumption compared to an SED, primarily because the SSED doesn't need to poll for messages, keeping transmission windows short.

doc: thread: SSED and device type updates #11619

doc: thread: SSED and device type updates #11619

Conversation

greg-fer commented Jun 26, 2023

Choose a reason for hiding this comment

Choose a reason for hiding this comment

pjasinski990 Jun 27, 2023 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

LuDuda left a comment

Choose a reason for hiding this comment

LuDuda Jun 29, 2023 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

NordicBuilder commented Jul 3, 2023

Choose a reason for hiding this comment

greg-fer commented Jul 3, 2023

greg-fer commented Jul 4, 2023

pjasinski990 Jun 27, 2023 •

edited

Loading

LuDuda Jun 29, 2023 •

edited

Loading