Skip to content

[RFC] The IEEE802.15.4 SubMAC #13376

@jia200x

Description

@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?

Submac

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

Metadata

Metadata

Labels

Area: networkArea: NetworkingType: new featureThe issue requests / The PR implemements a new feature for RIOT

Type

No type

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions