Some questions about Child Supervision

[taoyinzhou]

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.

child_supervision.pcap

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.What is the relationship between child supervision and the OPENTHREAD_CONFIG_MLE_CHILD_TIMEOUT_DEFAULT function? Is it a low-power alternative?
2.Why does the function of Child Supervision not take effect on OTBR and RCP? Could you please tell me which configuration items need to be enabled?
3.If the OPENTHREAD_CONFIG_CHILD_SUPERVISION_MSG_NO_ACK_REQUEST option is enabled, does that mean the SED is receiving the message from the OTBR and does not need to respond with an ACK?

Thanks in advance.

Best,

tao

[taoyinzhou]

I use the following two options to make the device SED:

CONFIG_OPENTHREAD_MTD=y

CONFIG_OPENTHREAD_MTD_SED=y

sleep interval option:

#ifndef OPENTHREAD_CONFIG_MLE_CHILD_TIMEOUT_DEFAULT
#define OPENTHREAD_CONFIG_MLE_CHILD_TIMEOUT_DEFAULT 600
#endif

[Edvin]

Hello,

The OPENTHREAD_CONFIG_MLE_CHILD_TIMEOUT_DEFAULT 600

doesn't set the sleep interval of the child. It decides how long a child has to be "radio silent" before it is considered lost for the network. The poll_period is something you set when you enter the SED state. Perhaps you can show some snippets from where you are doing this?

Best regards,

Edvin

[taoyinzhou]

I'm sorry. I made a mistake.

Because of the need to control the power consumption of the device，when the device needs to communicate with the Internet, I set poll_period to 2000. When the device needs to sleep, I set poll_period to 64800000.

I use otLinkSetPollPeriod()  to set poll_period.

[Edvin]

Ok. Does that mean that your questions were answered? If not, can you please clarify what you want to know at this point?

Best regards,

Edvin

[taoyinzhou]

But I asked about the function of Child Supervision. 

And my three additional questions haven't been answered.

[Edvin]

1.What is the relationship between child supervision and the OPENTHREAD_CONFIG_MLE_CHILD_TIMEOUT_DEFAULT function? Is it a low-power alternative?

Child supervision timeout is the time it takes from radio silence until a child is considered lost in the network (disconnected). This is in case of the child runs out of battery, or comes out of range, or is turned off. This setting is set using OPENTHREAD_CONFIG_MLE_CHILD_TIMEOUT_DEFAULT.

2.Why does the function of Child Supervision not take effect on OTBR and RCP? Could you please tell me which configuration items need to be enabled?

What do you mean by "not take effect on OTBR and RCP"? Do you mean that you set the OPENTHREAD_CONFIG_MLE_CHILD_TIMEOUT_DEFAULT on your OTBR, and it doesn't change the behavior on the SED? As mentioned in a previous reply, this setting doesn't change how often the SED will wake up, but how long it takes until it is considered lost from the network.

3.If the OPENTHREAD_CONFIG_CHILD_SUPERVISION_MSG_NO_ACK_REQUEST option is enabled, does that mean the SED is receiving the message from the OTBR and does not need to respond with an ACK?

Yes and no. All messages are ACKed on the 802.15.4 MAC layer, but this setting says that it doesn't need to be ACKed by the application.

As an example, if a light switch sends a message to a light bulb, and they are not within range, then the message will be sent via another node. Let us call light switch node A, middle node is node B, and light bulb is node C. A wants to send a message to C, without acking:

A->B payload

B->A ack (MAC layer)

B->C payload

C->B ack (MAC layer)

However, if this message requires ACKs, then it would be:

A->B payload (C should turn on the light)

B->A ack (MAC layer)

B->C payload

C->B ack (MAC layer)

C->B application ack (I have received the message and turned on the light)

B->C ack (MAC layer)

B->A application ack (I have received the message and turned on the light)

A->B ack (MAC layer).

Best regards,

Edvin