2
\$\begingroup\$

I am trying to implement a UWB ranging system using IEEE 802.15.4 standard data frame encoding, but the example I found only uses 16-bit addressing with a frame control byte of 0x8841, like this:

tx_poll_msg[] = {0x41, 0x88, 0, 0xCA, 0xDE, 'W', 'A', 'V', 'E', 0xE0, 0, 0};

What frame control bytes should I use for 32-bit addressing like this:

tx_poll_msg[] = {0x??, 0x??, 0, 0xCA, 0xDE, 'W', 'A', 'A', 'W', 'V', 'E', 'E', 'V', 0xE0, 0, 0};

I can't find references to what those first two bytes mean anywhere.

\$\endgroup\$

1 Answer 1

1
\$\begingroup\$

Wireshark's IEEE 802.15.4 dissector does a good job of explaining the fields:

Frame Control Field: 0x8841
    .... .... .... .001 = Frame Type: Data (0x1)
    .... .... .... 0... = Security Enabled: False
    .... .... ...0 .... = Frame Pending: False
    .... .... ..0. .... = Acknowledge Request: False
    .... .... .1.. .... = PAN ID Compression: True
    .... .... 0... .... = Reserved: False
    .... ...0 .... .... = Sequence Number Suppression: False
    .... ..0. .... .... = Information Elements Present: False
    .... 10.. .... .... = Destination Addressing Mode: Short/16-bit (0x2)
    ..00 .... .... .... = Frame Version: IEEE Std 802.15.4-2003 (0)
    10.. .... .... .... = Source Addressing Mode: Short/16-bit (0x2)

This shows that bits [15:14] are the source addressing mode, and bits [11:10] are the destination addressing mode.

Looking into the IEEE 802.15.4 dissector source, the mode strings are defined in ieee802154_addr_modes:

static const value_string ieee802154_addr_modes[] = {
    { IEEE802154_FCF_ADDR_NONE,     "None" },
    { IEEE802154_FCF_ADDR_RESERVED, "Reserved" },
    { IEEE802154_FCF_ADDR_SHORT,    "Short/16-bit" },
    { IEEE802154_FCF_ADDR_EXT,      "Long/64-bit" },
    { 0, NULL }
};

This implies that there isn't a 32-bit mode, or at least Wireshark is unaware of it. The associated header file defines these constants:

/* Address Mode Definitions */
#define IEEE802154_FCF_ADDR_NONE               0x0
#define IEEE802154_FCF_ADDR_RESERVED           0x1
#define IEEE802154_FCF_ADDR_SHORT              0x2
#define IEEE802154_FCF_ADDR_EXT                0x3

It's possible that the IEEE added a new 32-bit addressing mode in place of the reserved value (1), and it hasn't had any press, but I suspect you probably want the 64-bit extended address mode. I'm not familiar with "PAN ID compression" here, so perhaps that also has something to do with different length addresses.

In the case of the example frame control field above, 0x8841 would become 0xCC41 if both source and destination used extended addresses.

\$\endgroup\$
1
  • 1
    \$\begingroup\$ I see, thank you! That makes sense. I think we assumed there was a 32 bit mode when maybe the only options are 16 of 64. Thanks! \$\endgroup\$ Feb 23, 2022 at 18:49

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.