Radio/Mac layer scheduling capabilities #10058
CodingRays
started this conversation in
General
Replies: 1 comment
-
This would require a significant change to the Thread Specification. I would suggest carrying this discussion within the Thread Group, which is responsible for developing and maintaining the Thread Specification. |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
Currently the are no scheduling capabilities in the radio layer besides setting a csl receive time. Such features could however be attractive for a variety of issues. Especially with regards to stability depending on additional features a device might need. For example multi protocol with Bluetooth or future advanced features for thread.
I have noticed this while working on our child network prototype. For that we are communicating with up to 8 neighbors using CSL bidirectionally. The lack of scheduling capabilities makes it significantly harder to implement features that would be needed to improve stability and latency spikes. These arise out of higher layers like the MAC and MLE layer not being aware of time slots needed by various components.
As the number of time based transmissions increases complexity naturally increases drastically making a more universal solution very attractive. As previously stated such a feature in the radio layer could also be used to improve stability of running openthread alongside other protocols on a time multiplexed radio.
Has there been some discussion around this before? And what would be the feasibility of improving support in this direction?
Beta Was this translation helpful? Give feedback.
All reactions