Questions about the enabling software CSMA / Ca

[tuopu]

When using Linux platform simulation, test the software CSMA / Ca function, and the radio function enables ot_ RADIO_ CAPS_ TRANSMIT_ RETRIES |OT_ RADIO_ CAPS_ CSMA_ Backoff function also enables opentread_ CONFIG_ MAC_ SOFTWARE_ CSMA_ BACKOFF_ Enable, but no call to get RSSI or energy scanning function is found. Is the implementation based on the RSSI received in the receive function?

[jwhui]

OpenThread requires the radio to implement Clear Channel Assessment (CCA). As a result, OpenThread itself does not sample the RSSI to determine whether or not to transmit a given message.

• OT_RADIO_CAPS_CSMA_BACKOFF indicates that the radio implements the CSMA backoff.
• OT_RADIO_CAPS_TRANSMIT_RETRIES indicates that the radio implements retransmissions.

[tuopu]

In other words, opentread itself does not have CCA function. When it needs to be transplanted, it is implemented by the user according to specific hardware. OPENTHREAD_ CONFIG_ MAC_ SOFTWARE_ CSMA_ BACKOFF_ ENABLE
This definition tells openthead protocol stack that the user has realized CCA function. Is that right?
otPlatRadioGetRssi(otInstance *aInstance) and otPlatRadioEnergyScanDone(sInstance, rssi); What are the functions of these two functions in thead implementation? Is it independent of CCA；

[jwhui]

OPENTHREAD_ CONFIG_ MAC_ SOFTWARE_ CSMA_ BACKOFF_ ENABLE only controls whether OpenThread implements the CSMA backoff. It is independent of the CCA and the radio platform must implement the CCA.

otPlatRadioGetRssi() and otPlatRadioEnergyScanDone() are used to implement features like Energy Scan and Channel Monitor and are not used to implement CCA.

[tuopu]

Which function should be implemented to tell openthead to back off。

[jwhui]

If the radio transmission fails due to a CCA failure, then it should pass OT_ERROR_CHANNEL_ACCESS_FAILURE via otPlatRadioTxDone():

openthread/include/openthread/platform/radio.h

Lines 808 to 824 in 3c4caed

	/**
	* The radio driver calls this function to notify OpenThread that the transmit operation has completed,
	* providing both the transmitted frame and, if applicable, the received ack frame.
	*
	* When radio provides `OT_RADIO_CAPS_TRANSMIT_SEC` capability, radio platform layer updates @p aFrame
	* with the security frame counter and key index values maintained by the radio.
	*
	* @param[in] aInstance The OpenThread instance structure.
	* @param[in] aFrame A pointer to the frame that was transmitted.
	* @param[in] aAckFrame A pointer to the ACK frame, NULL if no ACK was received.
	* @param[in] aError OT_ERROR_NONE when the frame was transmitted,
	* OT_ERROR_NO_ACK when the frame was transmitted but no ACK was received,
	* OT_ERROR_CHANNEL_ACCESS_FAILURE tx could not take place due to activity on the channel,
	* OT_ERROR_ABORT when transmission was aborted for other reasons.
	*
	*/
	extern void otPlatRadioTxDone(otInstance *aInstance, otRadioFrame *aFrame, otRadioFrame *aAckFrame, otError aError);

BTW, you can keep this conversation in a a single thread by replying in the "Write a reply" box, rather than the "Suggest an answer" box.

[tuopu]

I understand. After reading other protocol stacks, I realized the CCA algorithm by obtaining the air RSSI. I take it for granted that thread is also implemented in this way.
Thead actually interacts with the user through the otplatradiotxdone function. The user informs thead of what happened, not judging by the hardware state.