Questions Regarding CSL Retransmission Handling in OpenThread

[testter2]

Hi,

I have some questions related to CSL retransmission :-

1- According to Thread specification, it is optional to modify the CSL IE in retransmitted frames. If a radio platform supports both OT_RADIO_CAPS_TRANSMIT_SEC and OT_RADIO_CAPS_TRANSMIT_RETRIES, it can handle securing the packets include CSL IE. In such cases, would it be acceptable to resecure the packet in retransmission after modifying the CSL IE, or would this behavior contradict how the OT stack is designed to handle CSL retransmissions?

2- If a radio platform does not support retransmission capabilities, does OpenThread take responsibility for re-securing a retransmitted CSL frame ?

3- According to my understanding to #6342, this was a workaround by OT stack and there's a also TODO item "SPEC-977: Retransmissions of CSL frames" in the OpenThread project board. Could you provide any updates on when this might be implemented or if there are plans for it in the near future?

Thanks

[abtink]

@testter2, I will add some information and suggestions (based on what I know). Others who are more familiar with CSL implemenation may be able to provide more details:

I would generally recommend that, if CSL operation is desired, the radio platform provide OT_RADIO_CAPS_TRANSMIT_SEC and OT_RADIO_CAPS_TRANSMIT_RETRIES.

• The OT core does not update/set the appended CSL IE in a transmission frame (Mac::Frame::SetCslIe() is not called). So the radio platform is expected to update CSL IE on the frame and only afterward transmission security processing can be done.
• Enhanced ACK requires the radio platform to be involved and manage assigning security frame counters, which also requires it to perform transmission security processing (afterward).

In such cases, would it be acceptable to resecure the packet in retransmission after modifying the CSL IE, or would this behavior contradict how the OT stack is designed to handle CSL retransmissions?

I would expect the radio platform re-securing the transmission frame (after updating the CSL IE on a retransmission) should be fine and is probably the recommended way. It is important that the same security frame counter (and key ID) is used so that the frame can be correctly processed as a duplicate on the receiving node.

2- If a radio platform does not support retransmission capabilities, does OpenThread take responsibility for re-securing a retransmitted CSL frame?

Regarding processing security, when the SubMac module in OT handles this, it checks VerifyOrExit(!mTransmitFrame.IsSecurityProcessed());. Once frame transmission security is performed, mIsSecurityProcessed is set on the frame. So, effectively, security processing is done once.

3- According to my understanding of #6342, this was a workaround by the OT stack, and there's also a TODO item "SPEC-977: Retransmissions of CSL frames" in the [OpenThread project board](https://github.com/orgs/openthread/projects/1/views/1). Could you provide any updates on when this might be implemented or if there are plans for it in the near future?

I believe the answer here is that it is delegated to the radio platform and that the OT core (Mac/SubMac) is not involved in CSL frames and their retransmission. OpenThread provides helper utility functions in examples/platforms/utils/mac_frame.h to help with radio platform implementations with this.

[testter2]

Thanks for the detailed answer.