I am using nrf52833 to make a Thread end device as SED and RCP. All firmware versions use NCS V1.8.0.
The compilation options for OTBR is:
CMAKE_OPTIONS += \
-DOT_THREAD_VERSION="1.2" \
-DCMAKE_INSTALL_PREFIX=/usr \
-DBUILD_TESTING=OFF \
-DOT_READLINE=OFF \
-DOTBR_MDNS=OFF \
-DOT_CHILD_SUPERVISION=ON \
-DOT_POSIX_SETTINGS_PATH="\"/usr/lib/thread\"" \
-DOTBR_OPENWRT=ON
The RCP firmware code path is nrf\samples\openthread\coprocessor.
SED and RCP add CONFIG_OPENTHREAD_CHILD_SUPERVISION=y in prj.config, and define OPENTHREAD_CONFIG_CHILD_SUPERVISION_ENABLE as 1 in the openthread/src/core/config/child_supervision.h file
All other options use the default values:
#define OPENTHREAD_CONFIG_CHILD_SUPERVISION_CHECK_TIMEOUT 170
#define OPENTHREAD_CONFIG_CHILD_SUPERVISION_INTERVAL 129
I use the sniffer to capture packets during the process to observe.I noticed that if there is no transmission to the child within the supervision intervalthe ,OTBR would not send a supervision message to child.
Fortunately, the child supervision functioning is normal on SED: SED initiates the re-attach process when it not hear from its parent within the specified timeout interval.
Addresses of OTBE is:
fd11:22:0:0:2da2:4c5d:7782:e9fd
fdb4:c194:4e7d:12c7:0:ff:fe00:fc00
fdb4:c194:4e7d:12c7:0:ff:fe00:7000
fdb4:c194:4e7d:12c7:5c06:a2d9:ba14:3838
fe80:0:0:0:64a4:f937:a29:c5f2
In addition, the sniffer caught child_supervision.pcap and OTBR corresponding output logs, but the packet was not seen in the captured packet at the time when OTBR prompted the packet to be sent.
Mon Dec 27 14:45:58 2021 user.info otbr-agent[3703]: 00:10:44.962 [INFO]-PLAT----: > childsupervision interval
Mon Dec 27 14:45:58 2021 user.notice otbr-agent[3703]: 00:10:44.962 [NOTE]-CLI-----: Input: childsupervision interval
Mon Dec 27 14:45:59 2021 user.info otbr-agent[3703]: 00:10:46.098 [INFO]-PLAT----: > childsupervision interval
Mon Dec 27 14:45:59 2021 user.notice otbr-agent[3703]: 00:10:46.098 [NOTE]-CLI-----: Input: childsupervision interval
Mon Dec 27 14:48:04 2021 user.info otbr-agent[3703]: 00:12:51.238 [INFO]-UTIL----: Sending supervision message to child 0x7003
Mon Dec 27 14:48:18 2021 user.info otbr-agent[3703]: 00:13:05.188 [INFO]-PLAT----: > childsupervision interval
Mon Dec 27 14:48:18 2021 user.notice otbr-agent[3703]: 00:13:05.188 [NOTE]-CLI-----: Input: childsupervision interval
Mon Dec 27 14:51:14 2021 user.info otbr-agent[3703]: 00:16:01.182 [INFO]-UTIL----: Sending supervision message to child 0x7003
Mon Dec 27 14:54:24 2021 user.info otbr-agent[3703]: 00:19:11.171 [INFO]-UTIL----: Sending supervision message to child 0x7003
I met some problems.
1. Thread has the OPENTHREAD_CONFIG_MLE_CHILD_TIMEOUT_DEFAULT macro, which has a timer to let the child and router know whether the device is still connected. Superchildvision is similar to it. Is there a relationship between the two? Or are they completely separate?
2. The documentation from openthread description of OPENTHREAD_CONFIG_CHILD_SUPERVISION_INTERVAL:If a parent router does not transmit to its child SED within the OPENTHREAD_CONFIG_CHILD_SUPERVISION_INTERVAL, the parent router enqueues and sends a Child Supervision message to the child SED. However, after the router exceeds the macro time, the captured packet does not see the router sending the packet.
3. The thing with SEDs is that they are Sleeping, and while they are sleeping the radio is off. Hence, there is no way to reach the SED when it is sleeping. The above mentioned packets sent by the router should not be received by SED, which I think is contradictory.
Thanks in advance.
Best,
tao
Does the use of child supervision require the cooperation of CSL functions? CSL seems to make SEDsimply wake up and listen for a short duration to
determine if there are any buffered messages .
1. Thread has the OPENTHREAD_CONFIG_MLE_CHILD_TIMEOUT_DEFAULT macro, which has a timer to let the child and router know whether the device is still connected. Superchildvision is similar to it. Is there a relationship between the two? Or are they completely separate?
2. The documentation from openthread description of OPENTHREAD_CONFIG_CHILD_SUPERVISION_INTERVAL:If a parent router does not transmit to its child SED within the OPENTHREAD_CONFIG_CHILD_SUPERVISION_INTERVAL, the parent router enqueues and sends a Child Supervision message to the child SED. However, after the router exceeds the macro time, the captured packet does not see the router sending the packet.
3. The thing with SEDs is that they are Sleeping, and while they are sleeping the radio is off. Hence, there is no way to reach the SED when it is sleeping. The above mentioned packets sent by the router should not be received by SED, which I think is contradictory.
Does the use of child supervision require the cooperation of CSL functions? CSL seems to make SEDsimply wake up and listen for a short duration to
determine if there are any buffered messages .
A Child Supervision message is an empty MAC Data frame. A parent will only send a Child Supervision message if it has not sent another secure data frame within the Child Supervision interval.The problem is that the router did not send any packets within the Child Supervision interval , and after that time still did not send any packets.
A SED must poll for data frames by sending MAC Data Request messages.You mean that even if the router sends a Child Supervision message, the SED will not receive it until the SED wakes up and sends a request packet?That seems child supervision does not reduce message transmission and cannot reduce power consumption.Is that right?
--
You received this message because you are subscribed to the Google Groups "openthread-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to openthread-use...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/openthread-users/1766b87e-d546-4fbd-93b0-21eb48314b8cn%40googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/openthread-users/b1163671-ea7a-416a-9287-0afec5de86a8n%40googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/openthread-users/72c60137-6a3b-45e7-ac44-9b6a6cf070adn%40googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/openthread-users/169c2fa3-3ef6-4881-8503-8430f969cbf7n%40googlegroups.com.