[RFC] The IEEE802.15.4 SubMAC

[jia200x]

This issue introduces the concept of IEEE802.15.4 SubMAC.

Motivation

The SubMAC is a common layer used by the IEEE802.15.4 MAC and direct communication on top of the radio.

The SubMAC handles the following tasks (if not provided by the radio):

• CSMA-CA backoff logic
• ACK timeout event
• Frame retransmissions
• Energy scan procedure
• CRC calculation
• Address management (short, extended, PAN-ID)

With this layer it's possible to use hardware that doesn't support acceleration (retransmissions, ACK timeout, etc) in direct radio communication or gnrc_netif_ieee802154.

Although not strictly a SubMAC component, it might also be practical to define here the PHY layer for IEEE802.15.4 (set transceiver state, set channel, tx power, etc). This pattern is seen in some implementations like the Freescale PHY layer.

How does it work?

This layer should have functions like:

• ieee802154_submac_send(): Equivalent to netdev->driver->send() using radios with Extended Mode support (at86rf2xx, mrf24j40)
• ieee802154_submac_recv(): Receive a packet into a buffer (do CRC calculations if needed)
• Probably some callbacks to the upper layer (packet arrived, tx done, tx done with frame pending, channel busy, no ACK).

Each function should ask the transceiver if a given acceleration is present. If not, the layer is in charge of calling the appropriate component to handle the task (CSMA-CA, Retransmissions, etc).

What's required in order to implement this?

We already have some of the components to implement the SubMAC (e.g csma_sender).
There's a proposal for unifying the CSMA-CA, CCA and send in all radios in #13173, it would be relevant here.

We require to implement the retransmission and ACK handling logic by ourselves.

We would also need:
a) An interface between the SubMAC and the transceiver to access transceiver services (transceiver HAL)
b) An interface to check if a hardware acceleration is present on the given device ("radio caps")

We can use in the beginning the netdev interface for "a)". In the long run it might beneficial to have a dedicated IEEE802.15.4 HAL (as pointed out in #12469).

For b) there's #11473. Some modules already model this concept of radio caps (e.g the csma_sender using NETOPT_AUTOACK and NETOPT_CSMA)

Implications

• If we put this layer in gnrc_netif_ieee802154, all radios will work with retransmission logic and CSMA-CA.
• Several radio abstractions can be implemented with this layer (LWIP, OpenThread, etc).
• Users of raw communication can benefit of CSMA-CA and retransmissions with radios without support of hardware acceleration e.g CC2538).
• We improve maintainability of the drivers since we move MAC and PHY components out of there (see RFC: Move PHY/MAC layer out of drivers #11483)

Optimizations

If we are only using radios that have a certain hardware acceleration (e.g frame retransmission), we don't want to pull csma_sender and code to check if a radio has the acceleration or not.
The other way around if we know all radios are "basic" radios, then we don't need to ask if a given radio has the acceleration.

We can aim to have radio caps function that resolve in compile time:

bool ieee802154_radio_caps_retrans(void *radio)
{
    if(CONFIG_THERE_IS_AT_LEAST_ONE_RADIO_THAT_HAS_HW_RETRANS) {
        if(CONFIG_THERE_IS_AT_LEAST_ONE_RADIO_THAT_REQUIRES_SOFT_RETRANS) {
            radio_get_caps(radio, HAS_RETRANS);
        }
        else {
            return true;
        }
    }
    else {
        return false;
    }
}

So the following snippet:

/* ieee802154_submac_send function */
if(ieee802154_radio_caps_retrans(radio)) {
    /* We know the radio handles the retransmission procedure */
    ieee802154_send_and_dont_care_about_retransmissions(radio, packet);
}
else {
    ieeee802154_submac_send_with_retrans(radio, pkt);
}

will always generate the minimum amount of instructions (what's not needed gets optimized out by the compiler)

Does this whole concept makes sense?

Related issues

I mentioned about this concept in #12741 .
CSMA-CA, CCA and send get automatically unified by this concept (see #13173)
Radio caps become relevant for this: #11473.
Move PHY/MAC out of drivers: #11483

[PeterKietzmann]

+1 for the concept in general. However, if I see it correctly this issue acts as a place to summarize different efforts that you described in separate issues, right? In particular, I don't understand the difference (or synergy?) between this one and the proposal in #11483. Could you elaborate?

[jia200x]

However, if I see it correctly this issue acts as a place to summarize different efforts that you described in separate issues, right? In particular, I don't understand the difference (or synergy?) between this one and the proposal in #11483. Could you elaborate?

Yes. Basically this is an actual proposal for "Moving the PHY/MAC layer out of the drivers". It updates though the "pure PHY" into a SubMAC to add common operations (for a MAC layer and a raw link user).

Following this diagram:

The SubMAC replaces the netdev_ieee802154_t block. Instead of a pure PHY layer, this layer also adds ACK handling, retransmissions and address filtering.
The reason is because almost all network stack integration fall in one of these categories:

1. The network stack requires access to the radio (OpenWSN, OpenThread can be also implemented like this)
2. The network stack requires access to a PHY layer that already handles retransmissions, CSMA-CA and address filtering (OpenThread, GNRC, LWIP, etc)
   The rf_ops part is the transceiver HAL (WIP)

[PeterKietzmann]

So this issue (#13376) sticks with the proposal from #11483 and adds (software) Mac features in the same layer which are en-/disabled by radio ops during compile time?

[jia200x]

So this issue (#13376) sticks with the proposal from #11483 and adds (software) Mac features in the same layer which are en-/disabled by radio ops during compile time?

Yes. Basically this layer provides an uniform northbound API that mimics a radio in extended mode (e.g a user on top of the SubMAC will see a cc2538 and at86rf2xx as if they provided the same features). The SubMAC module is the one in charge of dispatching between hardware and software features

[jia200x]

In other words, basically if we plug this module below gnrc_netif_ieee802154 then all radios would have the same behavior. But the logic is still not implemented in the driver.

If someone needs low level access there's always the transceiver HAL (to be defined)

[jia200x]

it's there! #14787

[jia200x]

The SubMAC was merged (#14950 ). We can close this one now