-----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&amp;sdata=z1Edg744yIkqD3jj69noIdJCjZvRZ520tNYigJ%2FONRY%3D&amp;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&amp;sdata=28b3NH0N4A8BGbJKi9600zA6Cktb7r54FXWtYmgGECg%3D&amp;reserved=0 (802.15.4 Soft MAC 2015 version support)