IEEE802.15.4: Unify CSMA-CA,CCA and send in all radios

[jia200x]

Description

Following the rework of #12688, we have a problem of consistency in CSMA-CA and CCA when calling send functions.

The IEEE802.15.4 standard specifies that all packets (except ACKs and Beacons) must be sent using CSMA.

Consider the following diagram of the CSMA procedure. The green blocks are the entry points of different mechanisms:

Let's define the green blocks in the diagram with these functions:

• : "CSMA Send": ieee802154_send_csma_ca, send using the CSMA-CA procedure.
• "Transmit": ieee802154_transmit, Transmit a raw frame without any kind of channel activity detection.
• "CCA Send": ieee802154_send_cca, send using CCA procedure.
• "CCA": ieee802154_cca, perform a Clear Channel Assessment.

So, in order to have a compliant IEEE802.15.4 layer:

• The ieee802154_send_csma_ca function is always needed, regardless of the source of CSMA (hardware or software).
• If the radio doesn't support retransmissions, the ieee802154_transmit function is needed in order to send ACK packets
• If the radio doesn't support hardware CSMA-CA the ieee802154_send_cca function is needed, regardless of the source of CCA send (hardware or software)
• If the radio doesn't provide any caps, all functions are needed.

Here is a summary:

+-------------------------+----------------+------+-----+------+
| Function \ HW cap       | CSMA + Retrans | CSMA | CCA | None |
+-------------------------+----------------+------+-----+------+
| ieee802154_send_csma_ca |        x       |   x  |  x  |   x  |
+-------------------------+----------------+------+-----+------+
| ieee802154_transmit     |        -       |   x  |  x  |   x  |
+-------------------------+----------------+------+-----+------+
| ieee802154_send_cca     |        -       |   -  |  x  |   x  |
+-------------------------+----------------+------+-----+------+
| ieee802154_cca          |        -       |   -  |  -  |   x  |
+-------------------------+----------------+------+-----+------+

The problem is, calling dev->driver->send has an undefined behavior depending on the driver and configuration:

• In at86rf2xx radios it behaves as ieee802154_send_csma_ca, unless NETOPT_CSMA is disabled (in that case it will behave as ieee802154_send_cca).
• In nRF52 radios, it behaves as a plain send function (ieee802154_transmit).
• In Kinetis radios, it usually behaves as ieee802154_cca_send.

This explains why there's a QoS degradation in GNRC when comparing nRF52xx with at86rf2xx.
I'm not including hw retransmissions here, but there's a similar problem.
Also, some modules might not work OK when using different radios (openthread, csma_sender, etc).

Proposal

Implement the proposed functions.

We already have ieee802154_send_csma_ca and ieee802154_send_cca "out of the box" using the csma_sender module (event with HW caps discovery using NETOPT_AUTOCCA and NETOPT_CSMA). We might need to adjust the csma_sender module a little bit because for some radios it might not work (calling ieee802154_send_cca using at86rf2xx radios will have a strange behavior).

Then, we can explicitly call each "send" function (plain, cca and csma) where needed. E.g since we are only sending data packets in gnrc_netif_ieee802154, we should already use the csma_sender function there.

We can use radio caps to check if a feature is implemented in hardware (so no need to call the software procedure). We can also add compile time optimzations (e.g we are not interested in compiling software CSMA if only at86rf2xx radios are used)

[smlng]

Hey @jia200x nice overview, and w/o being very deep in the 15.4 specs (and csma, cca details) myself the proposal sounds about right. I don't know the current state but of cc2538 but if we implement your idea, this should bring us closer to finally get ACKs and retransmits right in cc2538 15.4 radio.

so 👍 from my side

[miri64]

The IEEE802.15.4 standard specifies that all packets (except ACKs and Beacons) must be sent using CSMA.

While standard conformity is desired for normal, out-of-the box operations, there are experimental setups (e.g. for alternative medium access schemata) where you might want to deactivate/circumvent it. As long as this is easily possible, 👍 from my side.

[jia200x]

While standard conformity is desired for normal, out-of-the box operations, there are experimental setups (e.g. for alternative medium access schemata) where you might want to deactivate/circumvent it. As long as this is easily possible, +1 from my side.

It's important to mention here that there are some setups that are "valid" in RIOT configuration but they never apply.
E.g turning off CSMA-CA in at86rf2xx also disables the retransmission procedure!
From datasheet:

A value of MAX_CSMA_RETRIES = 7 initiates an immediate TX_ARET transaction without per-
forming CSMA-CA. This is required to support slotted acknowledgement operation. Further the value
MAX_FRAME_RETRIES is ignored and the TX_ARET transaction is performed only once.

And it makes sense, since CSMA-CA is a dependency of the retransmission procedure.

Since the hardware acceleration is designed for IEEE802.15.4, I think all kind of experimental setups that don't align with the standard should be made without any kind of hardware acceleration (after all, an IEEEE802.15.4 MAC without CSMA is not a IEEE802.15.4 MAC anymore...).
This means, radios should provide "raw" PHY modes (transmit, CCA, etc)

[miri64]

As questioned offline, what does "deactivating hardware acceleration" mean in this case? Does it mean that I can't use any MAC functionalities of the device anymore if I only want the radio to not use CSMA?

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. If you want me to ignore this issue, please mark it with the "State: don't stale" label. Thank you for your contributions.

[jia200x]

I will close this one when the SubMAC is implemented.

[jia200x]

The SubMAC is there: #14787

[jia200x]

The SubMAC + Radio HAL allow these mechanisms. So this one should be closed now.