UHR

Type

38 (not assigned yet)

Structure

• u32 known
• u32 data[9]
• {u32 user_known, u32 user_info}[] (Note this is variable length)

Required Alignment

4

Unit(s)

none

known

Note that for trigger-based (TB) PPDUs, the UHR-SIG isn’t present over the air as all the information for each station is provided in the trigger frame. Sniffer should - where possible - provide a subset of the OFDMA related fields to simplify understanding of the resulting capture (i.e. to be able to read it without having to go back to the prior trigger frame.)

Note: The “RU/MRU/DRU Size” and “RU/MRU Index” fields are provided for sniffers that cannot provide the entirety of the RU allocations and user information fields for downlink OFDMA PPDUs (which would allow knowing exactly which AID got which RU allocation), but can only provide a subset of the information. They apply only to the captured AID. It’s advantageous to provide this even when all the RU Allocaction and User Information fields are known, so the display tool need not parse all of them.

Note: For uplink OFDMA, the DRU size could also be given here for similar reasons, though the actual DRU allocation should then be given for the captured AID from the trigger frame in the DRU/RRU Allocation fields.

Some values here could also appear for non-OFDMA PPDUs.

data[0]

data[1]

Note: The RU Allocation 1 here and other RU Allocation fields are in the downlink OFDMA format and do not represent DRUs, which are used only in uplink OFDMA. All RU allocations in uplink OFDMA are are visible only in the trigger frame, and, for the PPDU that was captured, in the other RU related fields.

Note: The RU/MRU/DRU Size and RU/MRU/DRU Index are calculated fields, ideally the sniffer should provide them for all OFDMA and punctured non-OFDMA PPDUs to simplify filtering and other data uses.

Note: The Primary 80 MHz channel position is numbered from low frequency to high frequency. Also note that it is required in order to decode the “RU Allocation (TB format)” field, since the decoding thereof requires doing the table lookup from 802.11 Table 9-65 (Lookup table for X1 and N) to have the correct values for interpretation of 802.11 Table 9-64 (Encoding of PS160 and RU Allocation subfields in an EHT variant User Info field).

data[2]-data[6]

RU Allocation field order

Together with the “RU Allocation 1” field from data[1], the RU Allocation fields shall be in the following order:

data[7]

data[8]

Note: The 0x1ff bits here indicate the RU Allocation for the captured station (AID) in the trigger-based (TB) format, per Table 9-64 “Encoding of PS160 and RU Allocation subfields in an EHT variant User Info field”. This may be given by the sniffer even for downlink OFDMA PPDUs if calculated from the RU Allocation from EHT-SIG for the given station. Note the bit split to ease cross-referencing Table 9-64.

Note: The DRU/RRU Indication bit can only be 0 (indicating DRU) for uplink OFDMA. There’s no separate “known” bit for it since it must be given to interpret the DRU/RRU Allocation.

user entry

Each user_known and user_info entry carries information for a given user entry in the UHR preamble. If multiple user fields are captured, ideally all of them are, and they should be given in the same order as they were ordered in the frame.

Note that to simplify parsing we indicate non-MU-MIMO (e.g. OFDMA) and MU-MIMO information via separate known bits, so that parsers can show these fields without consulting other information to know the PPDU type.

The “Data captured for this user” bit indicates which user the data was captured for that this radiotap header is attached to. It should be set for exactly one user entry in the entire radiotap header, even if potentially the entire UHR field is given multiple times.

user_known

user_info