IEEE 802.15.4 Hardware-Accelerated MAC Features#

The APIs introduced in the following sections work with any proprietary PHY which meets the IEEE 802.15.4 frame format specification. This includes all PHYs defined under the Connect and Long Range profiles in the Radio Configurator. Meeting this requirement is sufficient to use the protocol-specific RAIL APIs at the IEEE 802.15.4 PHY layer. The Connect SDK provides a good example of how to use these features with PHYs that are not fully IEEE 802.15.4 compliant.

The hardware supports address and frame filtering, Auto-ACK, and handling of the frame pending bit in the ACK through RAIL. To enable these features, use the sl_rail_ieee802154_init() API call and the other calls related to address filtering or frame pending.

You can configure address filtering and Auto-ACK by using the init API. These features also have dedicated configuration APIs, described in the following sections:

Address Filtering#

To configure address filtering, call sl_rail_ieee802154_set_addresses() with a structure containing all addresses, or call the individual sl_rail_ieee802154_set_pan_id(), sl_rail_ieee802154_set_short_address(), and sl_rail_ieee802154_set_long_address() APIs. You can configure up to three addresses for each IEEE 802.15.4 address field. You can also set these addresses by using the sl_rail_ieee802154_init() API.

With enabled address filter, packet reception will be immediately aborted after the address fields if the configured address filtering does not match with any configured addresses.

Note: The IEEE 802.15.4 address filter is different from the generic RAIL address filter feature.

Best Practices for Address Filtering#

Broadcast addresses are supported by default and do not require additional configuration. They do not consume address slots.
Set unused addresses to the broadcast address (0xFFFF) if you do not need all three addresses.
Do not change addresses during reception. Reconfiguring the address filter while receiving a packet might cause unexpected behavior.

To know more, see the IEEE 802.15.4 page of the API documentation and sl_rail_ieee802154_addr_config_t type’s documentation.

Auto-Ack and Frame Pending#

Auto-ACK is controlled by the ackConfig and timings fields passed to sl_rail_ieee802154_init(). After initialization, you can control it by using the Auto-ACK and state transition APIs.

The ackTimeout interval is measured from the end of the transmitted (Tx) packet to the end of the sync word (SFD) of the received (Rx) ACK packet. Therefore, the configured ackTimeout value must account for the transmission time of both the ACK PHY header and the ACK payload to ensure correct operation.

For an example, see the RAIL IEEE 802.15.4 detailed description.

To listen for an ACK packet, you must transmit the packet with the SL_RAIL_TX_OPTION_WAIT_FOR_ACK option.

The ACK frame includes the same sequence number as the frame that it responds to.

The AR bit in the Frame Control Field (FCF) specifies whether an acknowledgment is required from the receiver device. Upon a reception, the receiver sends an ACK frame only if the frame passes the filtering. If this bit is 0, the receiver does not send an ACK packet. Usually, the AR is located at the 5th position of the FCF.

The Frame Pending bit is used for data polling. The end device polls the coordinator with a data request command. If the coordinator has a message to the end device, it responds with an ACK packet with the frame pending bit set in the FCF.

In IEEE 802.15.4 mode with a 2.4 GHz PHY, the ACK frame has a length of 5 bytes. It includes the FCF, sequence number, and FCS (MAC fields) but no payload. The frame type is ACK, and the frame version is 0 (2003).

The ACK frame pending bit is false unless the SL_RAIL_EVENT_IEEE802154_DATA_REQUEST_COMMAND event is triggered. In that case, it defaults to the setting configured in the sl_rail_ieee802154_config_t.default_frame_pending_in_outgoing_acks. If the default frame pending setting is incorrect, call sl_rail_ieee802154_toggle_frame_pending() while handling the SL_RAIL_EVENT_IEEE802154_DATA_REQUEST_COMMAND event.

Enable this event so it fires when a data request is received. This allows the stack to determine whether data is pending.

If you need to change the default frame pending bit, do so quickly. Otherwise, the ACK might already be transmitted with the default setting. To trigger this event earlier during packet reception, use the sl_rail_ieee802154_enable_early_frame_pending() API.

Check the return code of sl_rail_ieee802154_toggle_frame_pending() to confirm that the frame pending bit was updated in time.

The SL_RAIL_EVENT_IEEE802154_DATA_REQUEST_COMMAND event is triggered only for data request MAC command frames that request an ACK. To trigger this event for data frames as well, call the sl_rail_ieee802154_enable_data_frame_pending() API.

Enhanced ACK#

The SL_RAIL_IEEE802154_E_OPTION_ENH_ACK option allows the radio to receive packets with Frame Version 2 in the MAC header. By default, RAIL accepts packets with frame version 0 or 1. Enable this option to handle enhanced ACK frames.

RAIL automatically assembles immediate ACK frames but does not assemble enhanced ACK frames. The SL_RAIL_EVENT_IEEE802154_DATA_REQUEST_COMMAND event is triggered for every received frame that requests an ACK. The application must determine whether to assemble an enhanced ACK payload based on the partially received packet, which you can access through sl_rail_get_rx_incoming_packet_info().

For more information, see the API documentation for SL_RAIL_IEEE802154_E_OPTION_ENH_ACK.

Note: This feature does not enable reception of multipurpose frames. To enable this capability, use the sl_rail_ieee802154_accept_frames() API. The Thread protocol always sets the FP bit to 1.

Implicit Broadcast#

The SL_RAIL_IEEE802154_E_OPTION_IMPLICIT_BROADCAST option enables the MAC implicit broadcast feature. If the frame Version is 2 and the frame does not include the destination PAN ID or destination address fields, the radio treats the packet as a broadcast packet. If this option is disabled, the radio typically filters such packets.

Runtime PHY Reconfiguration with SUN FSK and Wi-SUN PHYs#

2-byte Header Options#

Call sl_rail_ieee802154_config_g_options() with the SL_RAIL_IEEE802154_G_OPTION_GB868 option to support dynamic CRC and whitening reconfiguration coded in a 2-byte PHR PHY.

In this mode, RAIL automatically reads the PHR field of the transmitted and received packet, and reconfigures the radio during frame reception. For example, it enables or disables whitening for the payload and selects 2- or 4-byte CRC configuration based on the FCS and whitening bitfields.

Although the API name might be misleading, it enables all the IEEE 802.15.4g features.

Dynamic FEC#

To enable or disable IEEE 802.15.4g dynamic FEC feature, use the SL_RAIL_IEEE802154_G_OPTION_DYN_FEC option.

SFD field (implemented as the sync word) indicates whether the rest of the packet is FEC encoded or not. As the SFD field is configured as the sync word on the EFR32 radio platform, it enables dual sync word detection to detect whether FEC should be enabled or not.

Address Filtering and FEC work together only on radio platforms where SL_RAIL_IEEE802154_SUPPORTS_G_DYN_FEC is defined.

For more information, see IEEE 802.15.4.

Mode Switch#

The mode switch mechanism enables a device using the MR-FSK PHY to change its symbol rate or modulation scheme on a packet-by-packet basis. You can enable or disable this feature by using the SL_RAIL_IEEE802154_G_OPTION_WI_SUN_MODE_SWITCH option.

A specific mode switch PPDU informs the receiver of the mode switch and specifies the new PHY mode for the next PPDU.

To switch the receiver to a higher-rate PHY mode, send a mode switch packet that indicates the new PHY mode. The mode switch packet is an FSK-modulated 2-byte PHY header with no payload.

To generate the mode switch frame, use the pre-generated value. For more details, see previous page and IEEE 802.15.4.

Note: This is the mode switch feature defined by Wi-SUN, not the outdated IEEE 802.15.4g standard.