Date
1 - 2 of 2
Improved L2/L3 decoupling in IEEE 802.15.4 stack
|
jerico.dev
Hi!
I'm currently trying to implement a non-IP custom protocol on top of zephyr's IEEE 802.15.4 MAC (L2) layer. This requires me to... 1) implement additional 802.15.4 MAC service primitives from the 2015 standard, namely (some aspects of) RIT and/or TSCH, 2) rely on already implemented L2-features like CSMA plus most of the existing management commands, but 3) not depend on any IP-only features like 6LoWPAN. While analyzing zephyr's source code with this goal in mind I realized that: 1) There are IEEE 802.15.4 "RAW" and "CUSTOM" L2 modes. Unfortunately both seem to exclude most of zephyr's generic IEEE 802.15.4 MAC implementation in [1] including those parts I'd like to re-use. 2) Parts of the IEEE 802.15.4 L2 implementation are coupled to IP-specific L3 concerns - namely 6LoWPAN fragmentation and header compression. This breaks L2 re-usability and encapsulation in my case. 3) There are some hurdles to overcome in order to add additional service primitives to the MAC layer: * The "*_IEEE802154_RADIO_*" constants in Kconfig.radio and some L2 structs mix up PHY and MAC concerns. * The internal L2/L1-API makes only partial or indirect reference to IEEE 802.15.4 PHY/MAC service primitives. This is probably partially required to maintain a common API across zephyr's L2 implementations. Nevertheless there seem to be a few opportunities to improve readability, standards compliance and extensibility of the stack while I'm on it. * Some of the existing services are not yet fully 2015-standards compliant. Rather than patching zephyr locally, I'd prefer to contribute some of the more generic changes upstream. It's just a weekend project on my part but I'm used to provide small iterative patches. I'd like to start with some low hanging fruits and let it grow as my availability allows. *One thing that seems to be rather easy to achieve is improved L2/L3 decoupling by factoring 6LoWPAN aspects into conditionally included files.* * Would such a first contribution be welcome? * Would someone from the zephyr dev team be available as a sparrings partner to discuss architecture and integration issues? * Some of my requirements are addressed in or related to [2]. Who owns these issues? Would these people be interested in collaborating? Kind regards, Florian -- [1] https://github.com/zephyrproject-rtos/zephyr/tree/main/subsys/net/l2/ieee802154 [2] https://github.com/zephyrproject-rtos/zephyr/issues/3710 (802.15.4 Soft MAC 2015 version support) |
|
|
|
Lubos, Robert
Hi Florian,
toggle quoted message
Show quoted text
Generally, contributions are always welcome. We usually communicate over GitHub (you can either submit a PR directly or open an issue first to discuss ideas). The truth is that 802.15.4 L2 is not the most popular module hence it did not receive too many contributions in the past. Definitely there is a room for improvements in there. On the contrary, the OpenThread L2, also built on top of the 802.15.4 radio API is regularly updated/maintained. It's actually the OpenThread requirements that mostly shaped the low level 15.4 radio API into its current form. Please keep that in mind when working on the 15.4 L2, API breaking changes won't be accepted. Kind Regards, Robert -----Original Message-----
From: devel@... <devel@...> On Behalf Of jerico.dev via lists.zephyrproject.org Sent: poniedziałek, 1 sierpnia 2022 18:50 To: devel@... Subject: [Zephyr-devel] Improved L2/L3 decoupling in IEEE 802.15.4 stack Hi! I'm currently trying to implement a non-IP custom protocol on top of zephyr's IEEE 802.15.4 MAC (L2) layer. This requires me to... 1) implement additional 802.15.4 MAC service primitives from the 2015 standard, namely (some aspects of) RIT and/or TSCH, 2) rely on already implemented L2-features like CSMA plus most of the existing management commands, but 3) not depend on any IP-only features like 6LoWPAN. While analyzing zephyr's source code with this goal in mind I realized that: 1) There are IEEE 802.15.4 "RAW" and "CUSTOM" L2 modes. Unfortunately both seem to exclude most of zephyr's generic IEEE 802.15.4 MAC implementation in [1] including those parts I'd like to re-use. 2) Parts of the IEEE 802.15.4 L2 implementation are coupled to IP-specific L3 concerns - namely 6LoWPAN fragmentation and header compression. This breaks L2 re-usability and encapsulation in my case. 3) There are some hurdles to overcome in order to add additional service primitives to the MAC layer: * The "*_IEEE802154_RADIO_*" constants in Kconfig.radio and some L2 structs mix up PHY and MAC concerns. * The internal L2/L1-API makes only partial or indirect reference to IEEE 802.15.4 PHY/MAC service primitives. This is probably partially required to maintain a common API across zephyr's L2 implementations. Nevertheless there seem to be a few opportunities to improve readability, standards compliance and extensibility of the stack while I'm on it. * Some of the existing services are not yet fully 2015-standards compliant. Rather than patching zephyr locally, I'd prefer to contribute some of the more generic changes upstream. It's just a weekend project on my part but I'm used to provide small iterative patches. I'd like to start with some low hanging fruits and let it grow as my availability allows. *One thing that seems to be rather easy to achieve is improved L2/L3 decoupling by factoring 6LoWPAN aspects into conditionally included files.* * Would such a first contribution be welcome? * Would someone from the zephyr dev team be available as a sparrings partner to discuss architecture and integration issues? * Some of my requirements are addressed in or related to [2]. Who owns these issues? Would these people be interested in collaborating? Kind regards, Florian -- [1] https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fzephyrproject-rtos%2Fzephyr%2Ftree%2Fmain%2Fsubsys%2Fnet%2Fl2%2Fieee802154&;data=05%7C01%7Crobert.lubos%40nordicsemi.no%7Cdc483f41d3cf4bf0d96408da73de9529%7C28e5afa2bf6f419a8cf6b31c6e9e5e8d%7C0%7C0%7C637949697086927429%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=z1Edg744yIkqD3jj69noIdJCjZvRZ520tNYigJ%2FONRY%3D&reserved=0 [2] https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fzephyrproject-rtos%2Fzephyr%2Fissues%2F3710&;data=05%7C01%7Crobert.lubos%40nordicsemi.no%7Cdc483f41d3cf4bf0d96408da73de9529%7C28e5afa2bf6f419a8cf6b31c6e9e5e8d%7C0%7C0%7C637949697086927429%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=28b3NH0N4A8BGbJKi9600zA6Cktb7r54FXWtYmgGECg%3D&reserved=0 (802.15.4 Soft MAC 2015 version support) |
|
|