WARP Project Forums - Wireless Open-Access Research Platform

The v1.5 Tx/Rx PHY do not support 11ac. This is something we plan to build eventually, but that's a ways off.

The Rx PHY does detect 11ac receptions in order to properly terminate Rx processing before attempting to demod/decode the payload. The Rx PHY logic terminates after detecting the VHT-SIG fields. This detection is based on the rotation of the BPSK symbols in the VHT-SIG fields; the VHT-SIG bits are not actually decoded. The MAC code knows the PHY has terminated by checking the phy_mode field wlan_mac_low.c : wlan_mac_low_poll_frame_rx(). An unsupported PHY mode terminates the MAC processing at that stage without calling the MAC application's frame_receive() callback.

The current design explicitly rejects NDP receptions because a HT-SIG.LENGTH field of 0 is interpreted as an error. For the current SISO-only 802.11n implementation this is a fair classification. For the changes you want to make, you'd have to relax this and modify the receiver to pull multiple channel estimates from the NDP reception. This is doable, but definitely a challenging modification to the PHY itself.

Another much-easier approach, though admittedly not without its limitations, would be to send rapid, short, back-to-back SISO transmissions from a multi-antenna WARP AP and then have a bunch of single antenna WARP STAs pull the channel estimates from those transmissions just like normal. The timing isn't equivalent to a proper NDP packet since you separate each transmission with a full preamble. But it would be pretty easy to do. You could easily modify the AP code to send a short transmission from each radio interface and cycle between them. The payload would only need to contain an identifier that let each client STA know which antenna it came from so that you can make sense of all of the channel estimates after the fact. This behavior is doable with just software modifications, unlike the proper NDP processing.

dang2327 wrote:

Can we achieve this one-short-packet-per-antenna sounding phase with WARPLab acting as AP and 802.11 ref. design as clients?

Yes, it would work with either WARPLab or the 802.11 Reference Design acting as a transmitter. You could tell the 802.11 Reference Design to skip the backoff between transmissions if you want to minimize Tx-to-Tx time.

dang2327 wrote:

1. We want all these sounding packets to be as close to each other as possible (to limit the sounding time), so sending them back to back would be ideal. However, can receiving those probes be a bottleneck on the client side, as we have only 8 slots of RX packet buffer? Will the MAC have enough time to pull the channel estimates and release a packet buffer in time to continue receiving additional probes? We envision this could work for an 8 antenna AP, but what about a 16 antenna AP?

I ran a quick test using the unmodified v1.5 of the Reference Design that we release a couple of days ago. I configured an AP to use the NOMAC project as low-level MAC to minimize the inter-Tx times (NOMAC doesn't do any backoffs, timeouts, or any other pesky medium access behaviors that would slow this test down). I used wlan_exp to construct an LTG (local traffic generator) to send packets to the receiver as quickly as possible. I used the 802.11n MCS 7 (65 Mbps PHY rate). Without modifying the design, the minimum LTG size is 20 payload bytes on top of the 24 bytes for a full 802.11 MAC header + 4 bytes for FCS. All told, the post-preamble payload of the transmitted waveform consists of 2 OFDM symbols.



The above plot shows, in yellow, the Tx PHY active signal on the transmitter. This signal asserts while the Tx PHY is transmitting samples. The blue line shows the FCS Good signal at the receiver. The blue spikes means that the packet is being fully decoded. The receiver is fully keeping up with decoding and logging each reception with an inter-Tx time of 80µsec. This is pretty good -- many 802.11 transmissions are much longer than this inter-Tx time (several milliseconds) and the channel is assumed to be static over these durations. So depending on the speed of your channel, having a new set of channel estimates every 80µsec might be good enough. You could lower this a bit with some modest modifications of the design (getting rid of the LTG payload that adds an extra OFDM symbols, reducing the 6µs signal extensions at the Tx and Rx, etc.).

dang2327 wrote:

2. On the AP side, using WARPLab will mean that we have to generate standard-compliant, modulated probe packets (each with custom MPDU to denote SSID/antenna ID and distinguish from normal WiFi traffic) and send them out using alternating antennas. Can this be achieved in a straightforward way?

You could actually use the simulation of the Tx PHY model in the Reference Design to construct and save a waveform with whatever payload you want. Alternatively, the IEEE posts a public waveform generator that you can similarly use to construct a waveform with an arbitrary payload. Either way, once you are down to I and Q you could use WARPLab to send it.

dang2327 wrote:

3. On the client side, will NoMAC be the appropriate starting point to start processing received probes and pull the channel estimates?

On the client side I don't think it really matters too much. Both NOMAC and the DCF will log receptions' channel estimates the same way. For what its worth, I used NOMAC at the Rx client in the experiment I discussed earlier.