sys/net/link_layer/ieee802154/submac: move ack transmission

[Lukas-Luger]

Contribution description

The transmission of IEEE802.15.4 Acknowledgements should be handled by the SubMAC-Layer itself, rather than the SubMAC-netdev. This will allow applications using SubMAC directly, to reduce redundant code.

Testing procedure

Flash tests/net/ieee802154_submac onto two devices which do not contain the IEEE802154_CAP_AUTO_ACK capability.
Send a message using txtsnd from one device to the other. Notice, that No ACK will appear in the terminal, because SubMAC does not send Acks.

Issues/PRs references

#13376
#14950

[mguetschow]

Thanks for doing this!

[riot-ci]

Murdock results

✔️ PASSED

6a3ffa4 sys/net/link_layer/ieee802154/submac: add tx ack logic

Success	Failures	Total	Runtime
11108	0	11108	11m:28s

Artifacts

• Documentation preview

[fabian18]

This will allow applications using SubMAC directly

Using the radio without netdev.
Is this something RIOT should support, or do you just want to fix tests/net/ieee802154_hal?
The test could use the implementation of netdev_ieee8902154_submac, or what is the burden to use it?

The test mimics the netdev implementation as well as the txtsnd command. I can imagine the test was only useful in an early development phase of the radio hal.

[Lukas-Luger]

For my use-case it makes more sense to use SubMAC directly rather than hacking 802.15.4 features into the netdev. I am told, that netdev should abstract various media types into a uniform API, therefore adding 802.15.4 specific stuff is questionable. This also allows for less overhead (netdev will typically run in a separate thread).
IMO both ieee802154_hal and ieee802154_submac tests should not be changed as they verify the functionality of SubMAC itself. Various tests concerning netdev_ieee802154_submac are already present (drivers/{cc2538_rf, kw2xrf, mrf24j40, nrf802154}, net/{socket_zep, gnrc_legacy_tx_sync})

[fabian18]

I get the point that netdev should only create an API and not offer features.
That reading a frame did not happen in submac was for me the reason to not add it there.

Judging from the nrf802154_radio.c, this should not be the case.

This is still an assumption to me. In my opinion it should be coded in a way that a frame is read at only one place (submac then and no longer netdev_ieee802154_submac). Because the read also for the nrf is accessing a buffer rxbuf which is written in a drivers ISR, so I would not be sure that reading twice always would return the same frame.

[mguetschow]

Judging from the nrf802154_radio.c, this should not be the case.

This is still an assumption to me. In my opinion it should be coded in a way that a frame is read at only one place (submac then and no longer netdev_ieee802154_submac).

Maybe @jia200x as the original author of the radio HAL has some comments on this? In any case I would expect documentation in https://doc.riot-os.org/structieee802154__radio__ops.html#a99394547c65c7872bff808bba1d69c46 to establish a clear API contract of when calling this function returns correct results.

Edit: it actually states

If the radio provides any kind of framebuffer protection, this function should release it.

which probably translates to "the data could be overwritten"

[Lukas-Luger]

Alright. I just implemented an rx_buffer and also contacted @jia200x. Another method would be to send the Ack inside ieee802154_read_frame, simmilar to _recv inside netdev_ieee802154_submac.c. However this is not instantaneous, because it must be called from the application side.

[jia200x]

Using the radio without netdev.
Is this something RIOT should support, or do you just want to fix tests/net/ieee802154_hal?
The test could use the implementation of netdev_ieee8902154_submac, or what is the burden to use it?

Many of us require to work with the radios directly without netdev, and this was a major motivation behind the IEEE 802.15.4 rework. netdev is useful for "network interface" semantics (e.g., sending data over a link layer), but it becomes less predictable when trying to control radios directly.

In cases where a component is certain that it's interacting with an IEEE 802.15.4 radio (such as with Zigbee, openDSME, OpenWSN, etc.), the netdev abstraction makes it harder to control radio states and ensure consistent operation across devices.

This challenge has existed for quite some time, at least since the first attempts to port OpenWSN, and the rework was designed to allow us to use netdev as a "network interface" and not as a "radio interface."

For more context, check out this year's RIOT Summit presentation on the Radio HAL and SubMAC
, which summarizes the issue and explains why we are advocating for this approach.

The test mimics the netdev implementation as well as the txtsnd command. I can imagine the test was only useful in an early development phase of the radio hal.

I agree that the test could be improved, but it was intended as an entry point for testing the Radio HAL. We've encountered cases where broken network tests were actually due to incomplete or inconsistent Radio HAL implementations. Testing the Radio HAL using the netdev API doesn't allow us to test key aspects like compliance with the Abstract State Machine, timing issues, and so on.

In general, I’d suggest we avoid adding more workarounds on top of netdev. It has taken significant effort to create a more consistent experience across radios, and this has required careful attention to the layering. Continuing to refine this will help maintain long-term stability and flexibility.

[jia200x]

Alright. I just implemented an rx_buffer and also contacted @jia200x. Another method would be to send the Ack inside ieee802154_read_frame, simmilar to _recv inside netdev_ieee802154_submac.c. However this is not instantaneous, because it must be called from the application side.

Based on previous experience working with other radios, it’s difficult to guarantee that this will work across all radios. In many cases, modifying states inside the read function may violate the assumptions of the Abstract State Machine.

For this issue, I see two potential solutions:

First solution (likely simpler): Allow peeking into the framebuffer by modifying the Radio HAL API. This would allow the upper layer (e.g., SubMAC) to access the SQN or any other frame section. We could make this a requirement for radios that don’t support AutoACK, such as the AT86RF2xx in Basic Mode or NRF52, which usually offer a mechanism to peek into the framebuffer. These radios typically expect the driver to handle the ACK logic.

Second solution (a bit more controversial): Modify the drivers or SubMAC to handle the framebuffer directly, potentially changing the receive logic from a "pull" model (calling a read function) to a "push" model (subscribing to a framebuffer). This would decouple the state-changing logic from the read function and allow for better control.

[Lukas-Luger]

I've added an if-statement to not call ieee802154_submac_cb_t::tx_done in IEEE802154_FSM_STATE_TX_ACK, so the upper layer won't get confused.

[fabian18]

Oh, something went wrong during your git rebase. Maybe you have rebased on top of the wrong branch?
I would try to rebase your last 2 commits on to master: git rebase -i HEAD~2 master.
Or maybe because of this:

commit a4dc64dce38cf5096a63264c6f2fc41c2ce3cfa1
Merge: b518b31111 80b5a54d78
Author: Lukas-Luger <lukas.luger@mailbox.tu-dresden.de>
Date:   Fri Feb 6 13:12:40 2026 +0100

    Merge branch 'master' into pr/submac-tx-ack

This is not the workflow that I think most people follow.
Usually you have your PR commits and fixup commits and you do: git rebase -i master --autosquash to squash your fixups. Worst case I would fix it with:

git checkout -b pr/submac-tx-ack-backup
git checkout pr/submac-tx-ack
git reset --hard master
git cherry-pick a01ece91130ca1c8349b793af067164df7aa5b96
git cherry-pick 9107fecb9abc2464c9f41b4f1c8281eaa2f557ff

[fabian18]

@mguetschow have all your change requests been addressed?