WARP Project Forums - Wireless Open-Access Research Platform

Timing is critical in both frame_receive and frame_transmit, but for different reasons.

First, it's important to clarify that these timing constraints exist in order to correctly implement the 802.11 DCF. You can customize the MAC however you want, including changes to timing that break the DCF spec. Our DCF code will recover gracefully[1] if one of the critical timing paths is not met.

Timing is critical in frame_receive where the C code must prepare an ACK and enable the ACK Tx before the post-Rx SIFS interval ends. The ACK Tx must start at precisely a SIFS duration after the received DATA waveform arrives. If frame_receive takes too long, the ACK will not be ready at the SIFS boundary and will not be transmitted. You could transmit the ACK late, but the receiving node may already have entered timeout.

Timing is critical in frame_transmit where the C code must prepare a new DATA frame for transmission before the DIFS interval ends. The DIFS interval starts when the medium goes idle. If a node needs to transmit a frame while the medium is busy, it chooses a random backoff interval. This random interval might be 0, meaning the node is allowed to transmit immediately when the DIFS interval ends. We call this the "zero slot" case in the code. Missing the "zero slot" creates a fairness problem. "Slow" nodes that cannot achieve a zero-slot Tx after the DIFS will be disadvantaged when competing for a busy medium.

[1] At least, our code *should* recover gracefully. There have been bugs in past releases when handling late Tx events. We have fixed every Tx/Rx timing bug we know about as of v1.4.