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

[taoyinzhou]

Thank you for your reply. 

On the first question, I feel there is something wrong with the answer.The Child Supervision setup for timeouts should be this macro: OPENTHREAD_CONFIG_CHILD_SUPERVISION_CHECK_TIMEOUT.
OPENTHREAD_CONFIG_MLE_CHILD_TIMEOUT_DEFAULT works in connection timeouts with the router, such as age in the figure below.I think the functions of the two are repetitive, so I want to know their relationship

The second issue, when I say it doesn't work, is that there's a parameter OPENTHREAD_CONFIG_CHILD_SUPERVISION_INTERVAL that doesn't work. If I understand correctly, this is for the router. When the router does not send a message to SED within this time, the router will send such a message to SED. I did not see such a packet in the packet capture，the OTBR did not send a packet to SED after the time expired.

[Edvin]

Please see the documentation from openthread on:

OPENTHREAD_CONFIG_CHILD_SUPERVISION_CHECK_TIMEOUT

This is the child's way of knowing whether it is still connected or not, while the OPENTHREAD_CONFIG_MLE_CHILD_TIMEOUT_DEFAULT is the parent/router's way of knowing whether the child is alive. If more time than this passes, then the child is considered disconnected.

OPENTHREAD_CONFIG_CHILD_SUPERVISION_INTERVAL 

is the interval of which the parent tries to ping the child.

So these are similar, but they have different uses. 

taoyinzhou said:

When the router does not send a message to SED within this time, the router will send such a message to SED

I don't understand exactly what you mean by this, but I guess you don't see the messages in the sniffer trace. Do you see them if the node is just a child, but not an SED? And again, What is the sleep/wake up interval of your SEDs? The reason I keep asking about this is that when an SED goes to sleep, the parent has no way of reaching it before it wakes up, so if you don't wake up within the interval, then the parent can't send a ping until it is awake again. 

[taoyinzhou]

The documentation from openthread on:

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" It explains what the Router does in the Child Supervision function.

You said  if SED don't wake up within the interval, then the parent can't send a ping until it is awake again.It seems contradictory.

According to the description in the document, I understand that if the router doesn't have a packet to send to SED within the OPENTHREAD_CONFIG_CHILD_SUPERVISION_INTERVAL, it will send a packet, regardless of whether SED accepts it or not, but I don't see the message. My confusion is that the Router did not send this packet.

Does the Router have to wait for the child to wake up and send a notification to the Router that it is awake? It seems that Child Supervision is not efficient.

[Edvin]

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. Therefore you need to make sure that the child wakes up more often than OPENTHREAD_CONFIG_CHILD_SUPERVISION_CHECK_TIMEOUT. To be sure, perhaps try to make it wake up twice every timeout interval. 

Edvin said:

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?

Did you check this?