Check out the new USENIX Web site. next up previous
: Beacon Delays : Potential Bandwidth Estimation : Potential Bandwidth Estimation

Background

The protocol for data transmission is the same regardless of whether the transmitter is an AP or an affiliated host. Each node (including the AP) that has data to transmit in an IEEE 802.11 network first senses the channel for a duration equal to $DIFS$ (Distributed Inter-Frame Sequence). If the node determines the channel to be idle for this duration, then the node enters a back-off stage, in which it delays its transmission by a random number of time slots (each slot of duration $SLOT$) chosen from the interval $[0,CW]$, where $CW$ is called the contention window size. If the channel is still idle at the end of the back-off stage, then the node transmits a Request-to-Send ($RTS$) frame to the intended receiver. On receiving the $RTS$ frame, the receiver responds back with a Clear-to-Send ($CTS$) frame to the sender after a delay equal to Short Inter-Frame Sequence ($SIFS$). Nodes, other than the sender or the receiver, that hear either the $RTS$ or the $CTS$ frame delay their transmissions until after the end of the data transmission between the sender and the receiver, as specified in the duration field of the $RTS$ and $CTS$ frames. Upon receiving the $CTS$ frame, the sender waits for a duration of $SIFS$ and sends its data frame. Finally, the receiver responds back with an $ACK$ frame to acknowledge the receipt of $DATA$ frame. The absence of either a $CTS$ or $ACK$ frame causes the sender to timeout and re-transmit the $RTS$ frame or the $DATA$ frame respectively. Many implementations also allow nodes to simply turn on or disable the $RTS/CTS$ handshake. In this case, nodes directly transmit their data frames, on determining the channel to be idle at the end of the backoff stage.

We first describe our methodology to estimate the downstream bandwidth from an AP to an end-host in the absence of $RTS/CTS$ handshake and then describe how the $RTS/CTS$ handshake mechanism can be accommodated into the estimation scheme. We also discuss how an end-host can determine its upstream bandwidth to an AP. We initially ignore losses and subsequently, describe how losses can be accounted for in Section 3.5.


next up previous
: Beacon Delays : Potential Bandwidth Estimation : Potential Bandwidth Estimation