[riot-notifications] [RIOT-OS/RIOT] RFC: Move PHY/MAC layer out of drivers (#11483)

José Alamos notifications at github.com
Fri May 3 13:43:54 CEST 2019


#### Description
Towards adding more features of IEEE802.15.4 and variants (TSCH, etc), having a well defined MAC layer, reduce code duplication and increase maintainability, I've been working in a series of changes like #11473 and the following proposal.

Most of the PHY and MAC logic is currently implemented in the drivers (ACK management, sending packets, etc). This leads to code duplication, radios that are not easy to maintain and it's hard to integrate full MAC features on existing radios (and it's hard to add new radios)

We already have some common PHY code in `netdev_xxx_t` descriptors (e.g `netdev_ieee802154_t`), but there are a lot of stuff that can be factorized out from the drivers.

In the case of IEEE802.15.4, the proposal is:
- Implement PHY layer logic using `netdev_ieee802154_t` so common operations (TX, RX, CCA, Energy Detection) are transceiver agnostic.
- Define a minimal `rf_ops` interface between `netdev_ieee802154_t` and the transceiver with low level operations (prepare packet, trigger send, maybe flush fifo, etc)
- Implement MAC layers on top using well known interfaces (for IEEE802.15.4, the MCPS-SAP and MLME-SAP as described in #11324 )
- A `netdev_ieee802154_ops_t` interface with specific PHY ops might be needed (cca, prepare frame, transmit, etc) in order to accomplish most MAC layers features.

For transceiver implementing PHY and MAC components use radio caps (#11473) to decide whether a feature is handled by the layer or the tranceiver.

Here is a picture about how can it look like for IEEE802.15.4:

![](https://gist.githubusercontent.com/jia200x/daac639c022d5b085e0019b63eadbdb0/raw/bc9982381f1ceb524bff8aca25e73030da39b91c/PHY_MAC.png)

I did a quick proof of concept for the PHY layer with the AT86RF231 radio and this is how generic prepare, transmit and send functions look like:
```c
/**
 * Implementation of netdev_ieee802154_ops_t members
 */

/* PSDU: PHY Service Data Unit. Equivalent to MPDU (Mac Protocol Data Unit), a.k.a full MAC header */ 
int netdev_ieee802154_prepare(netdev_ieee802154_t *dev, const iolist_t *psdu)
{
    dev->rf_ops->prepare(dev);

   if(dev->caps & NETDEV_IEEE802154_CAPS_TX_CHECKSUM)
    uint8_t psdu_len = iolist_size(psdu) + IEEE802154_FCS_LEN;

    if (psdu_len > IEEE802154_FRAME_LEN_MAX) {
        DEBUG("[at86rf2xx] error: packet too large (%u byte) to be send\n",
              (unsigned) psdu_len);
        return -EOVERFLOW;
    }

    /* Write PHDR */
    dev->rf_ops->tx_load(dev, &psdu_len, 1);

    /* load packet data into FIFO */
    for (const iolist_t *iol = psdu; iol; iol = iol->iol_next) {
        /* current packet data + FCS too long */
        if (iol->iol_len) {
            dev->rx_ops->tx_load(dev, iol->iol_base, iol->iol_len);
        }
    }

    /* return the number of bytes that were actually loaded into the frame
     * buffer/send out */
    return (int)psdu_len;
}

void netdev_ieee802154_transmit(netdev_ieee802154_t *dev)
{
   /* Transmit PHY Protocol Data Unit (PPDU) */
    dev->rf_ops->tx_exec(dev);
}

int netdev_ieee802154_send(netdev_ieee802154_t *dev, const iolist_t *psdu)
{
    if(res = netdev_ieee802154_prepare(dev, psdu)) {
        netdev_ieee802154_transmit(dev);
    }
    return res;
}
```
Any thoughts?

###
<!-- Please describe your use case, why you need this feature and why this
feature is important for RIOT. -->

### Useful links
- [IPP Hurray](http://www.open-zb.net/publications/HURRAY_TR_061106_An_IEEE_802.15.4_protocol_implementation%20_in_nesCTinyOS_%20Reference_Guide_v1.2.pdf): They used this abstraction for their IEEE802.15.4 stack using TinyOS
- [Linux Kernel](https://www.kernel.org/doc/Documentation/networking/phy.txt): Check their reasons on why they moved the PHY layer out of the drivers
<!-- Please include links to any documentation that you think is useful. -->

<!-- Thanks for contributing! -->


-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/RIOT-OS/RIOT/issues/11483
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.riot-os.org/pipermail/notifications/attachments/20190503/0705c183/attachment-0001.html>


More information about the notifications mailing list