WARP Project Forums - Wireless Open-Access Research Platform

My first guess would be that setting the DIFS to 0 is the underlying problem.

The Tx A state machine only executes a pre-Tx backoff if the medium as not been idle for a DIFS interval immediately before the FSM is started. When DIFS=0, the MAC core's IDLE_FOR_DIFS will always be 1, leading the Tx A FSM to always skip the pre-Tx backoff.

Is your goal to give one node priority access to the medium? If so, giving that node a shorter DIFS is a good starting point. This is analogous to the 802.11 PIFS. DIFS is defined as (SIFS + 2*SLOT). PIFS is (SIFS + 1*SLOT), resulting in PIFS-based Tx getting priority access over DIFS-based Tx. I think it's helpful to think of PIFS as a backoff of -1 slot.

You're right - I hadn't noticed in your code that you're explicitly starting a backoff with wlan_mac_dcf_hw_start_backoff() before starting the Tx A FSM. As a result the Tx A FSM doesn't start a new backoff but does defer Tx until the already-running backoff expires.

However I think setting DIFS to zero is still the underlying problem. The backoff counter decrements by 1 after an idle slot. The slot timer runs whenever IDLE_FOR_DIFS is true. Normally if the medium has been busy within a DIFS interval the slot counter resets and the backoff counter does not decrement. This is the mechanism by which distributed nodes align their slot boundaries (i.e. everyone starts counting their first T_SLOT interval from 0 exactly T_DIFS after the last medium event). When T_DIFS=0, IDLE_FOR_DIFS is always 1, so the slot counter is always running and the backoff counter starts decrementing every slot interval after you call wlan_mac_dcf_hw_start_backoff() until it hits 0, triggering the Tx PHY. Critically, forcing IDLE_FOR_DIFS=1 allows the slot/backoff counters to run even after the Rx PHY starts receiving a waveform. Normally when the Rx PHY is active the MAC core asserts BUSY, causing IDLE_FOR_DIFS=0, thereby resetting the slot counter and pausing any backoff. This will defer any pending Tx until after the Rx event. In your case IDLE_FOR_DIFS=1 (independent of Rx PHY state), which allows the Tx PHY to begin transmitting during a reception. This would definitely result in corrupted waveforms at all nodes.

I would suggest trying a small non-zero value for T_DIFS. This will allow the MAC core to de-assert IDLE_FOR_DIFS long enough to properly sequence Rx/backoff/Tx events.

I think I may be missing something, here. I've done away with all usage of backoff slots and am now just testing with different DIFS sizes by altering this line code in wlan_mac_low.h and reprogramming the WARP:

#define T_DIFS				(T_SIFS + (num_slots * T_SLOT))

For num_slots = 2, the observed timings are

which shows that the STA is waiting 50,000 + 30 = 50,030 us, give or take. The implication seems to be that the DIFS is being ignored entirely, otherwise I should see 50,000 + 30 + 28 = 50,058 us.

To further confirm this, I redid this test with

num_slots = 4:


and num_slots = 10:


In no case is the T_DIFS value referenced by the PHY DCF. Again, these timings are observed by another STA which references the same beacon timestamp that the transmitting STA is referencing to wait for 50,030 us.

Last edited by cancub (2016-Jul-12 13:21:46)

I'm confused. My understanding of the DCF was that the process (for a brand new frame) is:

1) Frame arrives at MAC sublayer to send out.
2) Wait for DIFS
    a) if idle for entirety of DIFS, transmit
    b) if not idle for entirety of DIFS then
        i) draw backoff value
        ii) wait for end of current DATA + ACK communication
        iii) wait for DIFS
        iv) wait for entirety of backoff (pausing for comms + DIFS for overheard transmissions) and then tx
        v) if collision, increase contention window size and go to i)

But what you're saying here sounds like once an initial wait for DIFS is performed after a busy medium, the next frame that comes down (whenever it comes down) will be transmitted immediately without waiting for  DIFS. So, in theory, two STAs see the beacon, wait a DIFS, wait 50,000 microseconds and then just transmit immediately without performing another DIFS wait prior to transmitting? I thought that -- according to the standard -- the arrival of a new frame into the DCF FSM would always trigger a DIFS wait prior to sending anything.

Last edited by cancub (2016-Jul-12 14:50:28)

I find this part of the standard confusing. We've spent a lot of time debating it internally. We're pretty confident in our current implementation, but it's definitely possible our interpretation is inconsistent with other 802.11 implementations.

A few sections we find helpful here:

"In general, a STA may transmit a pending MPDU when it is operating under the DCF access method...when the STA determines that the medium is idle for greater than or equal to a DIFS period" (802.11-2012 9.3.4.2)

"Immediate access when medium is free >= DIFS" (label in 802.11-2012 Figure 9-11)

"A STA using the DCF may transmit if its CS mechanism determines that the medium is idle at the TxDIFS slot boundary as defined in 9.3.7 after a correctly received frame, and its backoff time has expired." (802.11-2012 9.3.2.3.5)

I take this to mean that a node may transmit immediately if, at the time an MPDU is received by the DCF Tx state machine, the medium has already been idle for >=T_DIFS and the backoff counter is expired. Our Tx A FSM implements this behavior - these are the conditions for the direct-to-Tx transition from IDLE.

Let me rephrase all this. My goal is to -- given an idle medium and irrespective of past medium (in)activity -- have a STA wait X microseconds prior to transmission, where X is modifiable at runtime. If the STA should hear another transmission within the X microsecond window, the transmission should be cancelled and CPU low should be informed that the transmission was unsuccessful. Is this possible with any sort of parameter in WARP's current design?

I believe you are already very close to this. If you set the DIFS/TxDIFS values to non-zero (to preserve the MAC core's normal sequencing of idle/busy/Tx/Rx), then use explicitly-started backoffs, you can arbitrarily delay a node's transmission relative to the start of the Tx A FSM. If you synchronize two STA's backoff starts and Tx A starts via the beacon timestamp, the node with the shorter backoff will reliably transmit first. With a non-zero DIFS, the other node will defer its own transmission by pausing its backoff counter during the not-IDLE_FOR_DIFS time until after the receive process completes.

You will need to add code to terminate the Tx A FSM in the case that an Rx starts before the Tx A FSM starts the Tx PHY. This is not standard behavior. By default the Tx A FSM will always transmit a packet once started; it might take a long time, but it will happen eventually.

Here you need to reset the Tx A FSM in the case of an RX_START event occurring while the FSM is in the DEFER state. The Rx event will be observed by the existing call to check of the WLAN_MAC_STATUS_MASK_RX_PHY_STARTED status bit in the "while( mac_hw_status & WLAN_MAC_STATUS_MASK_TX_A_PENDING )" loop. You will need to modify this flow to reset the Tx A FSM, either before or after calling wlan_mac_low_poll_frame_rx(). You can reset the Tx A FSM with "wlan_mac_reset_tx_ctrl_A(1);  wlan_mac_reset_tx_ctrl_A(0);".

You know, I can't think of a situation where the network overall would benefit from waiting a DIFS when a frame arrives if a DIFS has already been performed previously and the network has been idle since then.

Yeah. It's taken me a long while to develop intuition about this stuff. I find it helpful to remember the definition of T_DIFS = T_SIFS + 2*T_SLOT.

DIFS defines how long after medium activity that every node with something to transmit must wait before resuming their backoffs. The end of the DIFS is a shared event across all Tx-pending nodes. The key is if a node's backoff has expired it gets to transmit immediately at the end of the DIFS. This motivates the T_DIFS definition. SIFS is the shortest time between any two transmissions (RTS/CTS, CTS/DATA, DATA/ACK). Obviously DIFS must be at least this long. Further the DIFS must be at least T_SLOT longer than the SIFS. This permits a node that will transmit after T_SIFS to know its transmission will not collide with another node's transmission. Post-SIFS transmissions do not defer to medium activity. Therefore other nodes must wait at least 1 slot after the SIFS so they can sense whether any post-SIFS Tx has begun. My best guess for the DIFS being SIFS + 2 slots is to permit the PIFS definition of T_SIFS+T_SLOT, giving post-PIFS Tx priority over post-DIFS Tx.

Does this mean that a "high" voltage for clear channel assessment sets idle_for_difs to 0?

The wlan_mac_hw core has a BUSY signal that is the OR of the various "channel busy" sources (Tx PHY, Rx PHY, physical CS, NAV). IDLE_FOR_DIFS de-asserts immediately upon BUSY asserting. IDLE_FOR_DIFS re-asserts as soon as BUSY has been 0 for T_DIFS.

If I understand properly, even if a previous wait for DIFS was performed, the moment that the high-priority STA transmits, idle_for_difs for both STAs goes to 0 and the low-priority STA will move back into software for further processing/decision making. Does that sound about right?

Yes, the Tx/Rx activity will cause both nodes' IDLE_FOR_DIFS signals to de-assert. If the Tx A FSM has already been started, the new medium event will continue the deferral by the FSM. In the C code this is monitored in the do{...}while(TX_A_PENDING) loop in frame_transmit(). The Rx PHY is polled in this loop in case a reception occurs during a deferred transmission.

Yeah, it's confusing that "PIFS" stands for "PCF interframe space." I think it's more useful to think of it as a "Priority" interframe space. Section 9.3.2.3.4 of 802.11-2012 outlines a few other scenarios where a PIFS is used even when not using the PCF.