You are not logged in.
Hello, we have some questions regarding the frame detection in the 802.11 reference design.
Chapter 20 of the 802.11-2012 standard details the HT PHY (802.11n). It appears there are three HT modes, NON_HT, HT_MF and HT_GF. The latest version of the reference design (1.4) has some support at the RX PHY for HT MCS rates but our question is about the frame detection of other HT transmissions on the channel.
1) Would v1.4 correctly detect an HT transmission and determine frame length from the SIGNAL field, hence set NAV etc?
2) We assume v1.4 should detect frames transmitted via mode NON_HT and HT_MF but not HT_GF, is this correct?
3) For example, an application measuring utilisation of the WiFi channel (via frame detection at the PHY) would be accurate amongst 802.11n devices unless they operated in HT_GF mode?
On a slightly different topic we have been testing v1.4 and the wlan experiments framework but we are detecting odd MAC addresses. We have made no modifications to either python or C frameworks, completely out of the box. The situation is:
-Configure node with v1.4 and init wlan_exp
-Run /examples/log/log_capture_continuous.py for a few minutes.
-Run /examples/log/log_process_summary.py
Here is an extract of what we observe.
08:cc:68:ac:ee:15 232 64835
08:cc:68:ac:ee:17 316 83668
0c:f3:03:35:00:00 3 42
1e:63:c5:37:00:00 2 28
2f:0a:b0:d6:00:00 9 126
53:30:8f:b1:00:00 1 14
The top two MAC addresses are fine, these are infrastructure APs in our environment. The bottom four are meaningless and do not exist as real devices.
We have checked the environment using an AirPcap and indeed these addresses do not exist.
Where are they coming from? The high number of packets indicate they are unlikely to be frame errors which pass the FCS.
Does this indicate some kind of byte offset when transferring data from the WARP to python, or in decoding?
We have observed this in other versions of the framework, but assumed the problem was with modifications we have made.
Perhaps we just have a very odd WiFi environment, although a poor channel ought to create FCS errors which shouldn't pass the filter in log_process_summary.
Any ideas?
Thanks
Offline
1) Would v1.4 correctly detect an HT transmission and determine frame length from the SIGNAL field, hence set NAV etc?
2) We assume v1.4 should detect frames transmitted via mode NON_HT and HT_MF but not HT_GF, is this correct?
Short answer- "yes" to SIGNAL, "sometimes" to NAV.
Our PHY supports NON_HT (i.e. 11a/g) and HT_MM formats. We do not implement the greenfield format.
The NAV is set from the MAC header's DURATION field. The NAV can only be updated when a MAC header is received in a packet with a valid checksum. Thus the NAV is only updated from receptions at supported rates/formats. I think it's common that RTS/CTS are transmitted as NON_HT frames, even if the following DATA is transmitted as HT_MM. In these cases the NAV will be updated with the large DURATION value from the RTS and/or CTS, protecting the DATA transmission even if it uses an unsupported rate/format.
The Rx PHY does keep CCA.BUSY asserted for the duration indicated by the SIGNAL field's RATE and LENGTH fields. This happens for any valid SIGNAL field, independent of the payload rate/format/checksum.
3) For example, an application measuring utilisation of the WiFi channel (via frame detection at the PHY) would be accurate amongst 802.11n devices unless they operated in HT_GF mode?
In the current design there won't be log entries for receptions with unsupported rates/formats. For these waveforms the Rx PHY decodes the L-SIG (11n name for SIGNAL) field, then decodes the HT-SIG. If the HT-SIG indicates an invalid rate/format the Rx PHY stops processing the waveform, asserts the PHY_RX_PARAMS.UNSUPPORTED output and resets. The MAC captures the UNSUPPORTED flag in its Rx status.
I guess it would be possible to create a log entry (OFDM_RX_UNSUPPORTED?) with the correct RX_START time and recording the HT-SIG values for MCS/length. We'll think about this for a future version.
On a slightly different topic we have been testing v1.4 and the wlan experiments framework but we are detecting odd MAC addresses. We have made no modifications to either python or C frameworks, completely out of the box. The situation is:
That wlan_exp example script isn't properly filtering out control frames that lack the address2 field. Chris will post more momentarily.
Offline
Regarding the weird MAC addresses,
What you are seeing is actually an oversight in the log_process_summary example. From the example:
# Extract all receptions
log_rx = log_np['RX_OFDM']
# For this experiment, only look at Good = 0 or Bad = 1 receptions
# Extract only Rx entries with good checksum (FCS = good)
rx_good_fcs = log_rx[log_rx['fcs_result'] == log_entry_types['RX_OFDM'].consts['FCS_GOOD']]
# Extract addr2 field from all good packets
rx_addrs_2 = rx_good_fcs['addr2']The above code block tries to pull out "addr2" from any FCS good RX_OFDM log entry. The problem is that ACKs and CTSs don't have an "addr2" field -- they are only 14 bytes long. Those strange XX:XX:XX:XX:00:00 addresses aren't actually MAC addresses -- they are the last 4-bytes (FCS) of received control frames.
This was an oversight on our part -- when we first wrote the log_process_summary.py example, we didn't support logging of control frames. Every log entry had a full 24-byte 802.11 MAC header. When we added support for logging control frames, we didn't update the example script to filter out control frame entries and only parse full header entries. To fix this, you want to change the definition of "rx_good_fcs" to filter out the short control frames:
rx_idx = (log_rx['fcs_result'] == log_entry_types['RX_OFDM'].consts['FCS_GOOD']) & ( (log_rx['pkt_type'] != 21) ) & ( (log_rx['pkt_type'] != 23) ) rx_good_fcs = log_rx[rx_idx]
The "pkt_type" fields of 21 and 23 are for ACKs and CTSs respectively. You can find the definitions for those numbers here.
Offline
Thank you both for the replies, very helpful. To clarify the HT questions
This
The Rx PHY does keep CCA.BUSY asserted for the duration indicated by the SIGNAL field's RATE and LENGTH fields. This happens for any valid SIGNAL field, independent of the payload rate/format/checksum.
and this
For these waveforms the Rx PHY decodes the L-SIG (11n name for SIGNAL) field, then decodes the HT-SIG. If the HT-SIG indicates an invalid rate/format the Rx PHY stops processing the waveform, asserts the PHY_RX_PARAMS.UNSUPPORTED output and resets. The MAC captures the UNSUPPORTED flag in its Rx status.
From 802.11-2012 (pg 1682) a HT-mixed format PPDU has:
{L-STF}{L-LTF}{L-SIG}{HT-SIG}{HT-STF}{HT_LTF}.....DATA
So if we receive an HT_MF frame, the ref. design can decode the L-SIG and will assert CCA.BUSY for the correct duration, even if the following HT-SIG is not decoded?
PHY_RX_PARAMS.UNSUPPORTED will be asserted but as long as we are not interested in the data it doesn't matter since we are able to obtain the duration from CCA.BUSY via the L-SIG?
We will try to implement log entries for this case.
Offline
So if we receive an HT_MF frame, the ref. design can decode the L-SIG and will assert CCA.BUSY for the correct duration, even if the following HT-SIG is not decoded?
Right. The NON_HT and HT_MF waveforms are identical through the first OFDM symbol. The PHY decodes the first symbol, checks the validity of the SIGNAL field and updates its LENGTH/RATE duration if valid. This all happens before the HT-SIG samples are fully received.
PHY_RX_PARAMS.UNSUPPORTED will be asserted but as long as we are not interested in the data it doesn't matter since we are able to obtain the duration from CCA.BUSY via the L-SIG?
CCA.BUSY is a signal driven from the PHY to the MAC core. The PHY asserts this signal for physical carrier sensing (RSSI > threshold), OFDM/DSSS packet detection and for the SIGNAL LENGTH/RATE duration. This logic is in "wlan_phy_rx_pmd/Sync Antenna Sel/PHY CCA".
The PHY's CCA.BUSY signal is one of the inputs to the MAC's medium BUSY or IDLE determination.
If the PHY decodes a valid SIGNAL/L-SIG field (these are indistinguishable), it will continue processing the reception. If it then detects an HT-SIG (via the rotated BPSK symbols in the HTSIG1/2 symbols) it will attempt to decode the HT-SIG. If the HT-SIG is invalid or if the HT-SIG specifics an unsupported PHY config, the reception terminates. If you want handle valid-but-unsupported HT-SIG receptions differently you will need to modify the wlan_mac_low_poll_frame_rx() function in the low framework.
Offline