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]

Hello Alejandro,

I don't know if you have seen it, but there is a sample found in:

NCS(v3.2.0, for example)\nrf\samples\peripheral\802154_phy_test.

It is intended as a serial shell sample, where you write via UART what you want to do (the sample description in the link above lists a whole lot of serial commands), but I am not sure it is actually exposing the levels that you wanted. Perhaps you can have a look, and see if this is something you can use.

Please note that we will be very short staffed on DevZone the next two weeks. If you have any followups, it might be faster to create a new ticket, and link to this one. If it can wait until January, feel free to post here, and I will get back to you when I return (5th of January).

Best regards,

Edvin

[hort]

Hi Edvin,

thank you very much for your reply and for pointing me to the 802154_phy_test sample.

Yes, I have already looked into that sample. Unfortunately, it does not expose the interface level we need for our labs, as it operates mainly through direct PHY operations and raw frame handling, rather than through a MAC service interface comparable to MCPS / MLME. That approach is perfectly fine for PHY-level testing, but it does not align with the MAC-centric learning objectives of the existing labs.

No worries regarding the delayed response, as you can see, I am also replying now (5th of January), so the timing works out well.

Thanks again for taking the time to respond and for the suggestion. I appreciate the help.

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