[riot-notifications] [RIOT-OS/RIOT] RDM: The 802.15.4 Radio HAL (#13943)

José Alamos notifications at github.com
Tue Nov 10 14:25:21 CET 2020


BTW, while developing the IEEE 802.15.4 MAC (and after some feedback from @MichelRottleuthner trying to port the `kwrf2x`), I think we should address a couple of stuff:

1) The current use cases of RIOT assume that the address filter is a function of (short addr, ext addr, panid). But check the specification of the IEEE 802.15.4 standard:
```
1. The Frame Type subfield shall not contain a reserved frame type.
2. The Frame Version subfield shall not contain a reserved value.
3. If a destination PAN identifier is included in the frame, it shall match macPANId or
shall be the broadcast PAN identifier (0xFFFF).
4. If a short destination address is included in the frame, it shall match either
macShortAddress or the broadcast address (0xFFFF). Otherwise, if an extended
destination address is included in the frame, it shall match aExtendedAddress.
5. If the frame type indicates that the frame is a beacon frame, the source PAN
identifier shall match macPANId unless macPANId is equal to 0xFFFF, in which case
the beacon frame shall be accepted regardless of the source PAN identifier.
6. If only source addressing fields are included in a data or MAC command frame, the
frame shall be accepted only if the device is the PAN coordinator and the source
PAN identifier matches macPANId.
```

As described in point 6, the device needs to know if it's a PAN coordinator or not. In fact, all radios with HW address filter provide PAN coordinator bit. Otherwise implementing an IEEE 802.15.4 Frame Filter would not be possible.

Also, note that "promiscuous mode" is also a configuration of the address filter (rather than an "rx_mode", as we have it now). There are also other filters that are partially or not included at all in the radio HAL, like sniffer mode (promiscuous but also accepts frames with wrong CRC), Beacon and MAC command filters. We only have partial support for ACK filter (using the `rx_mode` function). But indeed, this seems to speak for a more powerful `set_hw_addr_filter` function.

2) We defined RX with pending bit for ACK frames as an RX mode too. This is extremely impractical for the MAC layer, for the following reasons:
- The upper layer sets the frame pending bit when the MAC layer needs to send a frame using Indirect Transmission (a.k.a putting the outgoing message in a queue and waiting for the receiver to send a Data Request MAC command). This is independent of the state of the transceiver.
- Some radios (e.g CC2538 and kwrf2x) have support for Source Address Matching tables. This features exposes a table of sources addresses with pending data. When the radio receives a frame from one of these source addresses, it automatically sets the frame pending bit. With the current "rx_mode" approach, we rule out this semantic.

### Proposal

1) Remove the `rx_mode` function. Replace it with the mechanisms described in 2) and 3) and 4)
2) Rewrite the `set_hw_addr_filter` to `config_addr_filter` with the following signature:
```c
int (*config_addr_filter)(ieee802154_dev_t *dev, ieee802154_af_t type, void *param);
```
Considering:
```c
typedef enum {
    IEEE802154_AF_SHORT_ADDR, /* Set sjort address */
    IEEE802154_AF_EXT_ADDR,      /* Set ext address */
    IEEE802154_AF_PANID,              /* Set PAN ID */
    IEEE802154_AF_PAN_COORD,  /* Set PAN coordinator bit */
    IEEE802154_AF_MODE,             /* Set AF mode (enabled, promiscuous, sniffer) */
    /* Optional commands */
    IEEE802154_AF_MAC_CMD,      /* Filter MAC command frames */
    IEEE802154_AF_BEACON,         /* Filter beacon frames */
    IEEE802154_AF_DATA,               /* Filter Data frames*/
    IEEE802154_AF_ACK,                /* Filter ACK frames */
} ieee802154_af_t;
```

The function must implement setting short address, ext address, PAN ID, PAN Coordinator bit and AF Mode (for enabled and promiscuous). All the other might return `-ENOTSUP` and/or might be indicated with a proper CAP.

3) Define a function `config_src_addr_match` with the following signature:
```c
int (*config_src_addr_match)(ieee802154_dev_t *dev, ieee802154_src_match_t type, void *param);
```
Considering:
```c
typedef enum {
    IEEE802154_SRC_MATCH_EN, /* Enable or disable source address match. 
                              * Enabling it sets the frame pending to all ACK frames in
                              * response to a Data Request command (if the radio doesn't
                              * support Source Address Matching) or to a specific address
                              * in the Source Address Matching table
                              */
    IEEE802154_SRC_MATCH_SHORT_ADD,  /* Add a short address to entry */
    IEEE802154_SRC_MATCH_SHORT_CLEAR, /* Clear short address from entry */
    IEEE802154_SRC_MATCH_EXT_ADD,  /* Add a extended address to entry */
    IEEE802154_SRC_MATCH_EXT_CLEAR, /* Clear extended address from entry */
} ieee802154_src_match_t;

...
/* Device support src address match. */
IEEE802154_CAP_SRC_ADDR_MATCH
```

4) Leave the "Disable AACK" feature as a Compile Time flag.
Disabling the AACK (a.k.a not sending the ACK even if requested) is not a part of the standard, and might be used only in the following cases:
- Research scenarios
- Upper layer requires to handle ACK frames (e.g OpenWSN).

In both cases this could be handled with a compile time flag.

Opinions?

-- 
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/pull/13943#issuecomment-724699696
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.riot-os.org/pipermail/notifications/attachments/20201110/a42f2ac6/attachment-0001.htm>


More information about the notifications mailing list