SED detecting ACK/NAK from the parent before issuing a MLE

[ksathara]

Hi all,
Instead of issuing MLE with backing off, which consumes a hefty amount of current, is there a possibility for the SED to issue a low power MAC based scanning, either MAC counters or MAC handshake? When the SED 'knows' a parent is online the SED can issue a MLE.

Cheers,
Kaushalya

[jwhui]

To discover the presence of a neighboring router, a SED needs to receive a message from that router.

The SED could enable its receiver and wait for the router to send a message, but that could take up to 30 seconds and multiples of that to account for packet loss. Keeping the receiver on for tens of seconds or minutes is very costly as well.

The SED could also solicit a message from the router by sending a data message and waiting for a response, but that is not much different than sending an MLE Parent Request, which is a single MAC data frame.

[jwhui]

Sending a unicast data frame assumes a static parent, which is not robust to time-varying connectivity properties that are common in radio environments. It would help if you could do an implementation of your proposal and present data that demonstrates the performance tradeoffs in a variety of use cases and real-world environments.

[abtink]

I was thinking to send MAC packets from SED to get ACK/NAK from parent.

To request a MAC ACK, the transmission from the child must be a unicast frame. However, a detached child does not know the MAC address of a potential parent.

As Jonathan mentioned, your suggestion assumes the child is somehow aware of parent candidates and knows their MAC addresses, which is not a valid assumption.

The child is detached and has no knowledge of how many nodes are available that could act as its parent. Some of these candidates may even be REEDs.

[ksathara]

Hi Abtin, Jonathan,

Many thanks to both of you for consistent support.

Our scenario is we have one Leader and many SEDs in our network. There could be other Leaders nearby, but with different the network parameters such as network keys. So the SEDs can only communicate with one Leader. When we commission the system, all the SEDs are joined to this particular Leader. So each SED knows it’s parent when they got commissioned. So in application level, the parent can share its MAC address to the joining SED. But the question is this MAC is a true static MAC or not. From Jonathan’s reply, I got the feeling this may not so. Is it correct?

Can we use the parents EUI64 for a unicast frame?

Cheers,
Kaushalya

[ksathara]

Hi Abtin, Jonathan,
I dont know if it is better to start a new thread on this. I am trying to keep the sensors which have attached and in child state, in child state for longer in the presence of host powering down. The sensor data and polls will get NAK as transmissions fail. The idea is when the host powers up in a hour or two, it will retain the same network credentials and the sensors which are in child state can resume data tx as if nothing happened, without any MLE session.

I have tried

1. Enabling child supervision and extending CONFIG_OPENTHREAD_CHILD_SUPERVISION_CHECK_TIMEOUT=3000 and CONFIG_OPENTHREAD_MLE_CHILD_TIMEOUT=3000.
   This didnt work as Meshforwarder detects tx failure and seemingly immediately detaches the child. I was sending conformable packet, but I got the NAK to application layer much later. The detection seems very aggressive like in one tx fail, it detaches. Following is what I see from console.

[00:00:41.370,300] <inf> [N] Mle-----------: Attach attempt 2, AnyPartition
[00:00:43.500,854] <inf> [N] Mle-----------: RLOC16 fffe -> dc01
[00:00:43.500,976] <inf> [N] Mle-----------: Role detached -> child
[00:00:43.508,239] <inf> coap_client_utils: ------- Sensor Start --------
[00:00:43.508,239] <inf> coap_client_utils: Ext Addr: e2:59:51:2d:d1:ac:01:37
[00:00:43.508,270] <inf> coap_client_utils: MAC: f4:ce:36:4b:d5:b9:c6:71
[00:00:43.508,270] <inf> coap_client_utils: RLOC: dc01
[00:00:44.069,854] <inf> coap_client: SHT4X: 22.78 Temp. [C] ; 39.90 RH [%]
[00:00:44.069,885] <inf> coap_client: Temp: 22.78       RH: 39.90
[00:00:44.074,615] <inf> coap_client_utils: ZS 0, RSSI -75, LQI 3, LQO 2, FW 1241 RET: 0, RLOC: dc01
[00:01:00.036,407] <dbg> temp_nrf5_mpsl: temp_nrf5_mpsl_sample_fetch: sample: 87
[00:01:00.036,437] <dbg> temp_nrf5_mpsl: temp_nrf5_mpsl_channel_get: Temperature:21,750000
[00:01:05.037,567] <dbg> coap_client_utils: parent_monitor_work_handler: Parent status: RESPONSIVE (in CHILD role)
[00:01:13.514,221] <inf> coap_client_utils: ---- Host ACK -----
[00:01:13.514,251] <inf> coap_client_utils: Result : 0
[00:01:13.514,282] <inf> coap_client_utils: ✓ CoAP transmission successful
[00:01:35.037,689] <dbg> coap_client_utils: parent_monitor_work_handler: Parent status: RESPONSIVE (in CHILD role)
[00:01:44.083,007] <inf> coap_client: SHT4X: 22.79 Temp. [C] ; 39.88 RH [%]
[00:01:44.083,038] <inf> coap_client: Temp: 22.79       RH: 39.88
[00:01:44.087,768] <inf> coap_client_utils: ZS 0, RSSI -75, LQI 3, LQO 2, FW 1241 RET: 0, RLOC: dc01
[00:01:44.232,666] <inf> [N] MeshForwarder-: Failed to send IPv6 UDP msg, len:103, chksum:2033, ecn:no, to:0xdc00, sec:yes, error:NoAck, prio:normal
[00:01:44.232,940] <inf> [N] MeshForwarder-:     src:[fdde:ad00:beef:0:dccd:79d4:8f11:f62d]:5683
[00:01:44.233,184] <inf> [N] MeshForwarder-:     dst:[fdde:ad00:beef:0:8c62:93f7:ebb6:e2c4]:5683
[00:01:45.612,365] <inf> [N] Mle-----------: Role child -> detached
[00:01:45.612,579] <inf> [N] Mle-----------: RLOC16 dc01 -> fffe
[00:01:46.076,538] <inf> coap_client: Paired->Not Connected
[00:01:46.356,872] <inf> [N] Mle-----------: Attach attempt 1, AnyPartition

How can I relax the MLE detachment in one tx error?

2. I have added the following in CMakeLists.txt

OPENTHREAD_CONFIG_FAILED_CHILD_TRANSMISSIONS=100

# Also increase MAC retries
OPENTHREAD_CONFIG_MAC_DEFAULT_MAX_FRAME_RETRIES_DIRECT=15

# Disable parent search 
OPENTHREAD_CONFIG_PARENT_SEARCH_ENABLE=0

# Disable link request on timeout 
OPENTHREAD_CONFIG_MLE_SEND_LINK_REQUEST_ON_ADV_TIMEOUT=0

Nothing seem to help. Still one tx fail, the child detaches.

Please help.
Cheers,
Kaushalya

[abtink]

A child will detach if it detects its parent is gone/offline.

The trigger for a SED to consider its parent link broken is the repeated failure to receive an acknowledgment (ACK) for unicast frames sent to the Parent.

The number of consecutive MAC layer transmission failures required before a SED treats the Parent as timed out is defined by the constant FAILED_CHILD_TRANSMISSIONS. The default value for FAILED_CHILD_TRANSMISSIONS is 4 (Section 4.12, Table 4-3).

Note on Maximum Retries: The constant value of 4 is the number of consecutive MAC Data/Command Frames that fail entirely (resulting in a NO_ACK status or other errors). Each individual frame transmission attempt itself involves multiple lower-layer retransmissions and CSMA/CA failures, which are tracked separately.

---

The keep-alive messages for a Sleepy End Device (SED), which operates in an rx-off-when-idle mode, are crucial for maintaining the Child-Parent relationship and preventing the Parent Router from timing out the SED and reclaiming network resources.

Data polls or other data frames sent by the child can be used as keep-alive messages.

The frequency of keep-alive messages is determined by the Child Timeout period that the SED sets during its attachment process.

• Determination by Child Timeout: During the initial attachment handshake (Child ID Request), the SED specifies its expected maximum inactivity interval in the Timeout TLV (a 32-bit unsigned integer value in seconds).

• Parent Responsibility: The Parent Router maintains a timeout timer for the Child based on this value. If the timer reaches this specified timeout value without receiving a keep-alive, the Parent considers the Child to have left and may reclaim resources.

• SED Responsibility: Consequently, the SED MUST send a keep-alive message frequently enough to ensure that the Parent's timeout timer is continuously reset before it expires.