WARP Project Forums - Wireless Open-Access Research Platform

Another idea on your question (3) is that you could modify the 802.11 Reference Design to log the RSSI just prior to a reception in addition to the RSSI of every reception that is already included in the receive logs. Those "early" RSSI measures would be asymmetrically sampled (i.e. whenever you actually received something), but that might be enough to make some conclusions on ambient interference levels. Also, the ratio of the two RSSI values would let you pretty directly calculate the SINR of every reception. Adding the pre-packet RSSI would require a hardware change to the Sysgen cores, but it would be straightforward.

Sorry, I missed that part of your first post.

Our design asserts CCA.BUSY when:
(a) The NAV counter is non-zero (implemented in the wlan_mac_dcf_hw core);
(b) The PHY Tx is currently active; or
(c) The PHY Rx asserts its CCA.BUSY output:
  (c.1) The PHY Rx has detected a preamble and is attempting to decode a SIGNAL field;
  (c.2) The PHY Rx has detected a valid SIGNAL field and is processing a full packet Rx; or
  (c.3) The PHY Rx detects energy above a programmed threshold

The 3-way OR for conditions [a,b,c] is in 'wlan_mac_dcf_hw/CCA'.

The 3-way OR for condition (c) is in 'wlan_phy_rx_pmd/Sync & Antenna Sel/PHY CCA/'

The energy detection for (c.3) uses the radio's RSSI signal to estimate the current Rx energy level. The threshold to assert BUSY is configurable from software via the wlan_phy_rx_set_cca_thresh() macro. The default value is set in wlan_phy_util.c :: wlan_phy_init() to approx -62dBm. You can disable physical carrier sensing by setting the threshold to its max (PHY_RX_RSSI_SUM_LEN*1023). We wrote an app note app note that demonstrates the impact of this in the presence of real interference.

Quick follow up -- we just released the Mango 802.11 Reference Design v1.2. One of the changes makes (c.3) that murphpo mentioned easier to configure.

Previously, this value was a hardcoded 10-bit number that acted as a threshold on RSSI. In the current release wlan_phy_util.c :: wlan_phy_init() calls a new function wlan_mac_low_rx_power_to_rssi() with an explicit Rx Power argument in dBm (e.g. wlan_mac_low_rx_power_to_rssi(-62)). You can change the CCA sensitivity by adjusting that number.

1) If I disable physical carrier sensing by your method, does it have any impact on  (c.1) or (c.2)?(or it only changes the -62dBm programmed threshold?)

No- the wlan_phy_rx_set_cca_thresh() method only affects the RSSI threshold condition (c.3 above)

2) Is it possible that you could share the material of how energy detection based on RSSI is implemented in WARP?

The MAX2829 transceiver (the baseband<->RF chip) has an analog RSSI output. The RSSI voltage is proportional to instantaneous Rx power on a dB scale. The WARP v3 hardware samples the RSSI signal with a 10-bit ADC clocked at 10MHz. The 802.11 Rx PHY implements physical CCA by taking a running sum (i.e. averaging without division) of the digital RSSI samples, then compares the running sum to a fixed threshold.

3) In my scenario, non-Wi-Fi interference source always transmits with interference power less than -62dBm. I found that when the bandwidth of interference signal(with constant Power spectral density) is small, Wi-Fi throughput decreases. The reason is that WARP as Tx does not transmit. I assume it is because WARP assumes channel is busy

When you observe lower throughput, are you certain it's due to fewer Tx attempts by the WARP node? How did you verify this vs. lower throughput due to more packet errors at the Rx node?

How are you controlling the observed receive power of your interference at the Rx node?

Is it possible that non-Wi-Fi signal always triggers (c.1) or (c.2)?

It is possible but very unlikely. Condition (c.1) will occur when the Rx signal is periodic in 16 samples, like the STS portion of the 802.11 preamble. Condition (c.2) will only occur after packet detection (c.1) when the Rx PHY successfully decodes a SIGNAL field. The probability of random non-802.11 interference causing false positives here is very small.

2) Is it possible that we can measure the number of packets that WARP actually sends out? (no matter this packet is being acked or not)

Yes- a major component of the 802.11 Reference Design is the wlan_exp experiments framework. You can use wlan_exp to configure/control your nodes and gather detailed statistics in real-time. The print_node_stats.py and throughput_two_nodes.py scripts would be good starting points.

One way to attribute throughput loss to fewer transmissions would be to retrieve the Tx/Rx stats from your transmitting node and compare the data_num_tx_packets_total and data_num_tx_packets_low values. The data_num_tx_packets_low value increments every time the lower-level MAC transmits, even for re-transmissions. Thus if data_num_tx_packets_low is much larger than data_num_tx_packets_total, there were many failed transmission attempts. However if data_num_tx_packets_total is nearly equal to data_num_tx_packets_total, there were fewer overall transmissions but most were successful.

Even in the absence of CCA of external interference, poor receiver performance will reduce the number of transmissions over a fixed time interval. If the transmitted packets are not ACKed, the transmitter will continue increasing its contention window and backing off more. The numbers your included in your post (311 low transmissions and 47 total high transmissions) is consistent with this. Nearly every packet was retransmitted the full 7 times. This means that the contention window was likely railed at its maximum value of 1023 for the duration of the experiment. You'd expect roughly (CWmax/CWmin = 1023/15= ~68x) the total backoff time in a scenario where no packets are ACKed vs. a scenario where every packet is ACKed. That's a lot of extra idle time and you would see a big difference in the number of transmitted frames. Given this behavior, it isn't fair to conclude that the smaller number of transmissions in the smaller bandwidth interference case must be caused by CCA.

One way to confirm this is to send broadcast or multicast traffic instead of unicast traffic. Broadcast traffic is never ACKed and the contention window is reset to a minimum after each transmission regardless of whether or not a receiver actually successfully decoded the packet. Only in this scenario can you conclude that CCA is the root cause of a fewer number of transmissions. You can do this using the wlan_exp experiments framework by sending an LTG to the FF-FF-FF-FF-FF-FF broadcast address. You could also do it from a computer command line by sending a ping to the broadcast address. You won't be able to measure throughput with the ping, but the statistics you gathered from before should still apply.

Subtle point about broadcast traffic: Only the AP and the IBSS projects are capable of sending broadcast traffic in the way we are speaking about it. The STA behavior is unique because every packet it sends is sent as a unicast transmission to the AP. Even if the underlying packet is broadcast, it is sent to the AP as a unicast transmission and the AP repeats it from there. STA devices never directly communicate with other STA devices. All traffic goes through the AP. So, for you experiment, you want the direction of your traffic to be AP->STA or just use two ad hoc IBSS designs.

Ah, that's a good point I hadn't considered. You are right -- the way we built the statistics system is keyed off a station's MAC address. Broadcast frames coming *from* any station on the network will show up in Rx stats. Transmitted broadcast frames that egress from a node don't currently show up in any stats on that node because they aren't tied to any particular station's MAC address. There are two solutions to this problem:

(1) I'd strongly consider moving away from stats-based experiments and over to log-based experiments using the wlan_exp log framework. Every single transmission and every single reception will appear in the logs on the boards, regardless of whether they are unicast or multicast/broadcast. You can build the equivalent Tx and Rx stats directly in Python by simply counting the appropriate log entries. This is really easy to do in Python and our existing examples show how to do this. The log functionality in wlan_exp is the strict superset of the stats functionality. Everything you can do with stats you can do just as easily with the logs. And with logs, you can do much more. I think this is your best bet.

(2) If you do want to continue using stats, you'll need to make some changes to the C project so you can track multicast/broadcast transmissions. Specifically, the mpdu_transmit_done() function is what ultimately updates Tx statistics. Currently, it looks at the RA (addr1) field of the packet that was just sent and then looks for the associated station that it should update the Tx stats for. You'd need to change this behavior so that, in the case of multicast, it updates the Tx stats for a new multicast stats entry in the "statistics_table". I would probably create that multicast stats entry at boot in the main function.

Honestly, I really recommend going with the logs and abandoning the stats. In the short run, those small python changes to count log entries instead of stats are easier than modifying the design to actually keep Tx statistics for multicast packets. In the long run, the logging framework is extremely powerful and you may find that you'll use it anyway. For example, the Tx Low log entries actually contain the specific backoff slot count that every transmission used. So, in addition to counting them to see how many there are, you could explicitly see that each one had a huge backoff slot count, so CCA probably isn't to blame. You also have every timestamp of every transmission. This information is really powerful and is something that stats simply can't tell you.

You can change those macros and effectively prevent the PHY from ever attempting to receive anything. This will disable (c.1) and (c.2), but it will also prevent any receptions. In your experiment, do you need the node to actually receive anything? Or is this node a "deaf" transmit-only node?

Regarding the parameters to those macros,

(1) wlan_phy_rx_lts_corr_thresholds has two arguments that are independently applied depending on what the current RSSI value is. When we built this function we were intuiting that the thresholds may be dependent on what the overall power level is. Upon testing, we learned this feature wasn't necessary and we could keep the same threshold for both regimes. The value itself is 16-bit unsigned integer. You can effectively disable detection of the LTS correlation spikes with an argument of (2^16-1) = 65535. Note: the low and high SNR regimes are defined by the macro call "wlan_phy_rx_lts_corr_config(1023 * PHY_RX_RSSI_SUM_LEN, 350/2);" That's basically defining the "low" SNR regime to be any RSSI in the range [0,1023] (i.e. every possible RSSI value). This makes the second argument to wlan_phy_rx_lts_corr_thresholds irrelevant.

(2) The first argument of wlan_phy_rx_pktDet_autoCorr_ofdm_cfg is a 8-bit correlation threshold and the second argument is a 14-bit minimum energy threshold. Calling "wlan_phy_rx_pktDet_autoCorr_ofdm_cfg(255, 16384, 4, 0x3F);" will disable all packet detection. If you do this, then you don't even have to change the LTS threshold from (1) because the receiver will never get that far.


The above solutions will disable (c.1) and (c.2) at the cost of never being able to receive anything. Disabling (c.1) and (c.2) while still being able to receive is trickier. When the PHY is actively receiving and decoding a frame, the software in CPU_LOW is actively polling the status of the PHY and doing things like creating an ACK packet (if applicable). Specifically, CPU_LOW uses the wlan_mac_dcf_hw_rx_finish macro to wait for the PHY to declare the incoming frame as FCS good or FCS bad. During this time, the node will not transmit a new MPDU from CPU_HIGH regardless of CCA because CPU_LOW is only working on the ongoing reception and not checking the mailbox IPC from CPU_HIGH to see if a new frame should be transmitted. The normal operation of the 802.11 MAC and PHY is half-duplex, so CPU_LOW does not bother dealing with transmissions while receiving. To change this, you'd need to have CPU_LOW alternate between polling the reception status of the PHY and also polling the mailbox from CPU_HIGH to see if there is something new to send. The risk of doing this is that CPU_LOW will have a tougher time hitting the SIFS requirement prior to ACK transmission if it is stuck processing a message from CPU_HIGH at an inopportune time.

Additionally, you have to deal with the case that a transmission is currently backing off while you receive a frame. At the moment, the CCA signal feeding the DCF hardware core is a big OR logic block from all of the CCA sources. Two of these sources are (c.1) and (c.2). You can make a hardware change and add a register to act as a mask to the inputs of this OR block. From software you could then disable (c.1) and (c.2). This would allow the DCF hardware core to completely ignore the ongoing reception and flip the radio into Tx mode and send the packet after the backoff has completed.

I think those are the only two changes you would need to make to disable (c.1) and (c.2) while retaining the ability to receive except for the case where the interruption of a reception with a transmission causing that reception to fail.

Really appreciate for the help from you guys.
Great job!