• State Verified Answer
  • Replies 4 replies
  • Subscribers 86 subscribers
  • Views 339 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 355514
Options
Beware that this post is related to an SDK in maintenance mode
More Info: Consider nRF Connect SDK for new designs

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

Parents
  • 0

    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

  • 0 in reply to Edvin

    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

Reply
  • 0 in reply to Edvin

    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

Children
No Data
Related
Terms of service