Packet structure

nRF54L15 | nRF54L10 | nRF54L05 Datasheet

IEEE 802.15.4 defines an on-the-air frame/packet that is different from what is used in Bluetooth Low Energy.

The following figure provides an overview of the physical frame structure and its timing.

Figure 16. IEEE 802.15.4 frame format (PPDU)
Page-1 Sheet.213 PHY protocol data unit (PPDU) PHY protocol data unit (PPDU) Sheet.215 Preamble sequence Preamble sequence Sheet.218 SFD SFD Sheet.221 Length Length Sheet.224 PHY payload PHY payload Sheet.227 5 octets synchronization header (SHR) 5 octets synchronization header (SHR) Sheet.230 1 octet (PHR) 1 octet (PHR) Sheet.233 Maximum 127 octets (PSDU) Maximum 127 octets (PSDU) Sheet.265 MAC protocol data unit (MPDU) MAC protocol data unit (MPDU) Dynamic connector Sheet.277 160 µs 160 µs Dynamic connector.279 Dynamic connector.280 Sheet.281 32 µs 32 µs Dynamic connector.282 Dynamic connector.283 Sheet.285 ≤4064 µs ≤4064 µs Dynamic connector.286 Dynamic connector.287

The standard uses the term octet for an 8-bit storage unit within the PPDU. For timing, the value symbol is used, and it has a duration of 16 µs.

The total usable payload (PSDU) is 127 octets, but when CRC is in use, this is reduced to 125 octets of usable payload.

The preamble sequence consists of four octets that are all 0 and are used for synchronizing the RADIO peripheral's receiver. Following the preamble is the single octet start of frame delimiter (SFD), with a fixed value of 0xA7. An alternate SFD can be programmed through the SFD register, providing an initial level of frame filtering when non-standard compliance is chosen. It is a valuable feature when operating in a congested or private network. The preamble sequence and the SFD are generated by RADIO and are not programmed by the user into the frame buffer.

Following the five octet synchronization header (SHR) is the single octet PHY header (PHR). The least significant seven bits of PHR denote the frame length of the following PSDU. The most significant bit is reserved and is set to 0 for frames that are standard compliant. RADIO reports all eight bits which can be used to carry additional information. The PHR is the first byte written to the frame data memory pointed to by PACKETPTR. Frames with zero length are discarded, and the FRAMESTART event is not generated in this case.

The next N octets carry the data of the PHY packet, where N equals the value of the PHR. For an implementation also using the IEEE 802.15.4 medium access control (MAC) layer, the PHY data is a MAC frame of N-2 octets, because two octets occupy a CRC field.

An IEEE 802.15.4 MAC layer frame consists of the following:
  • A header, which is composed of the following:
    • The frame control field (FCF)
    • The sequence number
    • Addressing fields
  • A payload
  • The 16-bit frame control sequence (FCS)
Figure 17. IEEE 802.15.4 frame format (MPDU)
IEEE 802.15.4 frame format (MPDU)

The two FCF octets contain information about the frame type, addressing, and other control flags. This field is decoded when using the assisted operating modes offered by RADIO.

The sequence number is a single octet in size and is unique for a frame. It is used in the associated acknowledgement frame sent upon successful frame reception.

The addressing field can be zero (acknowledgement frame) or up to 20 octets in size. The field is used to direct packets to the correct recipient and denote its origin. IEEE 802.15.4 bases its addressing on networks being organized in PANs with 16-bit identifier and nodes having a 16-bit or 64-bit address. In the assisted receive mode, these parameters are analyzed for address matching and acknowledgement.

The MAC payload carries the data of the next higher layer, or in the case of a MAC command frame, information used by the MAC layer itself.

The two last octets contain the 16-bit ITU-T CRC. The FCS is calculated over the MAC header (MHR) and MAC payload (MSDU) parts of the frame. This field is calculated automatically when sending a frame, or indicated in the CRCSTATUS register when a frame is received. If configured, this feature is maintained autonomously by the CRC module.