doc: Thread: created types page, moved sed vs ssed #11410
Conversation
wiba-nordic
added
doc-required
wiba-nordic
requested review from
Damian-Nordic,
kkasperczyk-no and
carlescufi
as code owners
| Both Routers and REEDs have routing capabilities, while FEDs do not. | ||
| REEDs function similar to FEDs, but 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. |
There was a problem hiding this comment.
I am now thinking we could add a sentence informing that the limit of routers is 32 for a single network (enforced by 5-bit router id encoding in RLOC16)
There was a problem hiding this comment.
Added mention of maximum number, but left the bit about RLOC16 out.
wiba-nordic
force-pushed
the
doc_update
branch
2 times, most recently
from
6eff8a9
to
41167be
Compare
|
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. |
| :depth: 2 | ||
|
|
||
| Thread devices can be either Full Thread Devices (FTD) or Minimal Thread Devices (MTD). | ||
| The devices are divided based on their ability 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). |
There was a problem hiding this comment.
| The devices are divided based on their ability 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). | |
| 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). |
| The devices are divided based on their ability 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. | ||
|
|
||
| Another type separation is based on the device's ability to route messages. |
There was a problem hiding this comment.
| Another type separation is based on the device's ability to route messages. | |
| Another type of Thread device classification is based on the device's ability to route messages: |
| We can divide thread devices into Routers and End Devices: Routers can route messages, while End Devices cannot. | ||
| FTDs can be either Routers or End Devices, while MTDs can only be End Devices. | ||
| Only Routers can function as parents. |
There was a problem hiding this comment.
| We can divide thread devices into Routers and End Devices: Routers can route messages, while End Devices cannot. | |
| FTDs can be either Routers or End Devices, while MTDs can only be End Devices. | |
| Only Routers can function as parents. | |
| * 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. |
| Full Thread Devices can be further divided into three categories: | ||
|
|
||
| * Router | ||
| * Router Eligible End Device (REED) | ||
| * Full End Device (FED) | ||
|
|
||
| Routers can be regarded as the backbone of a Thread network. | ||
| They maintain the routing table and forward messages to other devices. | ||
| A router is required for a Minimal End Device to join the network. | ||
| Routers, unlike End Devices, can also be used to extend the network range. | ||
| The maximum number of routers in a single Thread network is 32. | ||
|
|
||
| Both Routers and REEDs have routing capabilities, while FEDs do not. | ||
| REEDs function similar to FEDs, but 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. | ||
|
|
||
| FEDs don't require a parent to function, but they can't become parents (Routers) themselves. |
There was a problem hiding this comment.
Would it make sense to present the information in lines 36-47 as a table? I feel a table with multiple columns would better showcase the differences. It is really hard to grasp the differences when the text is constantly jumping between device types and says "this does this, while that doesn't".
There was a problem hiding this comment.
I rearranged the information. Will try to mull a table that makes sense.
| They maintain the routing table and forward messages to other devices. | ||
| A router is required for a Minimal End Device to join the network. | ||
| Routers, unlike End Devices, can also be used to extend the network range. | ||
| The maximum number of routers in a single Thread network is 32. |
There was a problem hiding this comment.
| The maximum number of routers in a single Thread network is 32. | |
| The maximum number of Routers in a single Thread network is 32. |
Unless you refer to an off-shelf router and not a Thread device type.
| 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. | ||
|
|
||
| The |NCS| provides Kconfig options that let you enable CSL and specify the CSL parameters: |
There was a problem hiding this comment.
| The |NCS| provides Kconfig options that let you enable CSL and specify the CSL parameters: | |
| The |NCS| provides the following Kconfig options that let you enable CSL and specify the CSL parameters: |
| The |NCS| provides Kconfig options that let you enable CSL and specify the CSL parameters: | ||
|
|
||
| * :kconfig:option:`CONFIG_OPENTHREAD_CSL_RECEIVER` - Enables SSED child mode. | ||
| * :kconfig:option:`CONFIG_OPENTHREAD_CSL_AUTO_SYNC` - Enables CSL autosync. |
There was a problem hiding this comment.
| * :kconfig:option:`CONFIG_OPENTHREAD_CSL_AUTO_SYNC` - Enables CSL autosync. | |
| * :kconfig:option:`CONFIG_OPENTHREAD_CSL_AUTO_SYNC` - Enables the CSL autosynchronization feature. |
| * :kconfig:option:`CONFIG_OPENTHREAD_CSL_AUTO_SYNC` - Enables CSL autosync. | ||
| * :kconfig:option:`CONFIG_OPENTHREAD_CSL_TIMEOUT` - Sets the default CSL timeout in seconds. | ||
| * :kconfig:option:`CONFIG_OPENTHREAD_CSL_CHANNEL` - Sets the default CSL channel. | ||
| Corresponds to the ``csl channel`` CLI parameter. |
There was a problem hiding this comment.
| Corresponds to the ``csl channel`` CLI parameter. | |
| This option corresponds to the ``csl channel`` CLI parameter. |
| * :kconfig:option:`CONFIG_OPENTHREAD_PLATFORM_CSL_UNCERT` - Sets the fixed uncertainty of the device for scheduling CSL Transmissions in units of 10 microseconds. | ||
|
|
||
| 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 <OpenThread CLI Reference - csl command_>`_. |
There was a problem hiding this comment.
| For more information on using the CLI to configure parameters for CSl, see the ``csl`` command in the OpenThread `CLI reference <OpenThread CLI Reference - csl command_>`_. | |
| For more information on using the CLI to configure parameters for CSL, see the ``csl`` command in the OpenThread `CLI reference <OpenThread CLI Reference - csl command_>`_. |
| Added: | ||
|
|
||
| * A page on :ref:`ug_wireless_coexistence` in :ref:`protocols`. | ||
| * Pages on :ref:`thread_device_types` and :ref:`thread_sed_ssed` to the :ref:`ug_thread` documentation. |
There was a problem hiding this comment.
I think this could be featured in Protocols/Thread section, actually.
There was a problem hiding this comment.
I was kind of 50/50 on it, seeing as it's purely a documentation addition.
wiba-nordic
force-pushed
the
doc_update
branch
2 times, most recently
from
320b0e5
to
388a100
Compare
|
Added tables, though I'm not happy with the entry for No new messages for MEDs. If anyone has better ideas for that one, I'm all ears. |
I like the table formatting. |
There was a problem hiding this comment.
@wiba-nordic , are you planning any more changes wrt my other comments?
Added dedicated pages for Thread device types, as well as SED and SSED comparison. Signed-off-by: Piotr Jasiński <piotr.jasinski@nordicsemi.no> Signed-off-by: Wille Backman <wille.backman@nordicsemi.no>
|
Resolved last unaddressed comments. |
| 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. |
There was a problem hiding this comment.
I would definitely not advise to use SSED always but only for cases where we need a small latency (small csl interval) and want to have similar or smaller power consumption than SED has (e.g. window coverings). For sensors that report a new measurement each e.g. 30-60 seconds, is it justified to use CSL?
The common misconception is that SSED role is just better version of SED role. This is not true, it was designed for specific use cases and I would still expect vast majority of devices to use SED role rather than SSED role.
@edmont could you comment here? I would like to provide a clear recommendation when usage of SSED is better. Unfortunately, we need to account the possibility of being a child of a router that has very large uncertainty - which would make solution much worse than SED.
There was a problem hiding this comment.
In general e.g. from HomeKit or Matter perspective, it would be great that potential user will read this section and will be able to choose the SED or SSED role depending on its device type / communication patters.
There was a problem hiding this comment.
I totally agree, SSEDs are not intended to fully replace SEDs. As a rule of thumb it would be beneficial (in terms of energy and spectrum usage) to used SSEDs when the application requires to poll more often than 20 seconds. But this depends on many factors, like routers CSL Accuracy. KRKNWK-13546 should address this topic more in detail.
|
|
||
| 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. | ||
| If the parent has messages for the SSED, it sends them during the designated transmission window. |
There was a problem hiding this comment.
In practice, often there might be more frames that are buffered on Router side. In such case the first frame is received in designated transmission window, but the rest are "pulled" using regular Data Polls (exactly like SED).
| 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 Routers in a single Thread network is 32. | ||
|
|
||
| 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. |
There was a problem hiding this comment.
This is not correct. FEDs operate as End Devices and require parent (Router) to function.
|
|
||
| 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. |
There was a problem hiding this comment.
FTDs may also be in a "Child" state in the Thread network - forwarding all their messages to parent. I guess this sentence might be differently understood.
There was a problem hiding this comment.
I leave it up to @pjasinski990 if we want to mention this child state and where.
| - 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>`. |
There was a problem hiding this comment.
This is not fully acurate. The difference between MTD and FTD is not about the routing table only. It's about certain functionalities/capabilites which FTD has, but MTD has not, like ability to resolve IPv6 addresses, handling address registration, maintaining routing table, maintaining links with neighbors and so on.
| 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. | ||
| Otherwise, the parent will send a response indicating no pending messages. | ||
|
|
There was a problem hiding this comment.
I think it would be worth to mention how SED and SSEDs transmit messages (not data polls) to parent e.g. that it may happen 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. |
There was a problem hiding this comment.
What does it mean that the parent "wakes up"? Parent never goes to sleep. It may may rather send the non-polled frame only in designated transmission window.
| 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. |
There was a problem hiding this comment.
"MAY further reduce energy" - it's not granted ;)
| 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. |
There was a problem hiding this comment.
"MAY further reduce energy" - it's not granted ;)
@LuDuda , let me introduce your changes in a separate PR. |
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>
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>
Added dedicated pages for Thread device types, as well as SED and SSED.