Low probability of NoAck occurrence in thread communication

[aaa147147]

OTBR connects five thread sub devices for UDP communication (once a minute), which requires sending data and receiving replies from the thread sub devices. If it fails and tries again 9 times, there will be a low probability of sending failure (NoAck) in our testing
I think this unstable situation is normal, and the thread signal also needs to be interfered by other wireless signals

But the following log is my first time seeing it

So, I have two questions:
May I know what caused this log to appear
Is there a plan to improve NoAck that lasts for one minute

Full log:
1333.log

[aaa147147]

I may think this is a problem with the thread device or the stability of the thread network, rather than an issue with OTBR. Is my idea correct?

[aaa147147]

The following are logs from 6 consecutive minutes where not all tests were successful, for reference only.
14070.log
14071.log
14072.log
14073.log
14074.log
14075.log

[jwhui]

NoAck failures can occur due to a number of reasons:

1. Environmental issue caused by changing signal-to-noise ratio. Check the RSSI and/or interference to see if changes in connectivity are expected.
2. Radio driver failures. Unstable platform implementations can fail to receive data packets and generate ACKs. Validate that the receiving node is receiving data packets and generate ACKs during the NoAck period.