IEEE 802.15.4 MCPS interface for teaching purposes – alternatives in nRF Connect SDK?

[hort]

Hello everybody,

I am a research assistant at a university, responsible for maintaining and porting existing student lab exercises from the legacy nRF5 SDK to the nRF Connect SDK / Zephyr. The labs are used in a wireless communications course (taught by a faculty member).

We are using the nRF52840 Dongle for these labs and are very happy with it, especially due to its low cost, robustness, and ease of use for students, which makes it an excellent platform for teaching wireless fundamentals.

The BLE labs migrated cleanly to the nRF Connect SDK.
However, I am currently blocked on the IEEE 802.15.4 labs, which are MAC-centric and explicitly based on the MCPS / MLME service model defined in the IEEE 802.15.4 specification.

In the original nRF5 SDK labs, students directly work with:

• MCPS-DATA.request (custom MSDU, ACK on/off)

• MLME-START.request (beacon-enabled PAN, BO/SO)

• MLME-SCAN.request

• MLME-ASSOCIATE.request

• MLME-GTS.request

and correlate these primitives directly with Wireshark captures and relevant specification sections.

In the nRF Connect SDK, I understand that:

• IEEE 802.15.4 is used as the PHY/MAC foundation by Zephyr networking, OpenThread, and Zigbee,

• Nordic’s nrf_802154 radio/MAC driver is provided via nrfxlib and used by these stacks,

• but the MCPS / MLME service interface itself is no longer exposed, even for standalone or experimental use.

My constraints for the migration are:

• students should use VS Code + nRF Connect SDK only (single toolchain),

• no SEGGER Embedded Studio or additional SDK installations if possible,

• but we still need explicit MAC-level interaction for teaching purposes.

My questions are therefore:

1. Is there any supported or intended way in the nRF Connect SDK to access IEEE 802.15.4 at a level comparable to MCPS / MLME (even partially or experimentally)?

2. Is the nrf_802154 driver from nrfxlib intended to be usable standalone (outside Zephyr networking / OpenThread / Zigbee) for custom or academic MAC-level experimentation, or is this explicitly discouraged?

3. Are there any recommended migration paths or legacy components for users who previously relied on the nRF5 SDK IEEE 802.15.4 MAC for educational labs?

I fully understand that modern production stacks intentionally abstract the MAC and that features such as GTS are rarely used in practice. The goal here is strictly to preserve existing academic labs that teach IEEE 802.15.4 MAC concepts, while moving to the newer toolchain where possible.

Any guidance, even confirmation that such an interface is not supported or planned, would be very helpful.

Best regards,
Alejandro

[Edvin]

I understand, Alejandro,

I understand. Then I am afraid I am not aware of anything exposing the layers that you are looking for. You can look into the IEEE 802.15.4 Net Management headers (ieee802154_mgmt.h) in a custom application, but it is not something that I have experience with.

If you require MLME-level access, you would likely need to interface with the IEEE 802.15.4 Net Management headers (ieee802154_mgmt.h) in a custom application, as no specific sample is listed as a dedicated MLME layer exposure tool.

Since we use mostly Zigbee or Thread, we don't work with the MLME layers, typically. But perhaps you are more familiar with the functions in this file.

Best regards,

Edvin

[hort]

Hi Edvin,

thanks again for the clarification.

Yes, I am familiar with the IEEE 802.15.4 net management headers and have already experimented with a small custom application using ieee802154_mgmt.h. While this does move closer to the MLME-level functionality we require, it is still missing several features that are essential for our existing MAC-centric labs. That said, I fully understand that for most Zephyr-based applications, direct interaction with the MLME layers is not required.

For the time being, I have therefore taken a different approach: I created a minimal, portable version of the nRF5 SDK, keeping only the components required by our IEEE 802.15.4 MAC labs, and added a custom Makefile that uses the compiler packaged with the nRF Connect SDK. This allows us to preserve the MCPS/MLME-based lab content while still meeting our main constraint of a VS Code–based workflow without SEGGER Embedded Studio.

Thank you very much for your time and for confirming the current state of MLME support in Zephyr. This information is very helpful for setting the correct expectations on our side.

Best regards,
Alejandro