[mac] remove consecutive data polling for reduced power consumption #9763
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Currently in thread if a sleepy end device receives a frame with the frame pending bit set it must send a data poll to receive the next frame. This adds significant latency and as a result increased power consumption. This PR adds an experimental feature which if enabled removes the data polling after receiving a frame with the frame pending bit set. In testing this reduced the power consumption of a 512 byte UDP packet by 25% on a SED.
For testing purposes if the feature is enabled it assumes that all connected devices support the feature. This should be adjusted in the future depending on thread standardization.
The FTD will simply send all queued fragments until one fails to be transmitted. The end device will upon receiving a frame with the frame pending bit set switch to the waiting for data mode. If it times out it sends a data poll to continue receiving data.
We tested this by sending a 512byte UDP packet to a SED using the nrf52840 platform. The receive power on standard openthread was 1.19mC while with our feature enabled it was 0.9mC. This reduction arises almost entirely out of the reduced transmit time 66ms vs 50ms. This is a high current as we had some peripherals running, however this is a constant factor for this test. To eliminate external influences the test was performed within a Faraday cage.
Openthread:
Our feature:
Previous claims of higher power savings were due to a bug #9820 which our code avoided.