Estimating Free Air Time

Given a dense deployment of DAPs, it is likely that the DC will associate a client with a nearby DAP. Hence, it is also likely that the wireless channel conditions near the DAP and the client associated with it will be similar. Thus, we only estimate the free air time on a channel in the vicinity of the DAP.

The amount of free air time around the DAP depends on the traffic generated by the DAP itself (i.e. downlink traffic), the uplink traffic and any background traffic/interference. The background traffic includes traffic generated by other DAPs and clients in the vicinity that are functioning on the same channel. Of these quantities, the DAP can easily determine the amount of air time consumed by the traffic it generates. To determine the rest, we have devised a method inspired by the ProbeGap technique [16].

Each DAP periodically sends a small broadcast packet at a fixed transmission rate on the highest priority driver queue, which is usually reserved solely for high priority PSM packets. The packets in this queue are sent even if the DAP has other packets pending in the normal data queue.

The DAP records the difference in time from when the packet was queued to when the transmit completion interrupt signals that the frame was successfully sent. When the channel is idle, the packet will be transmitted immediately and the measured delay will be the sum of frame transmission time plus various OS overheads. We denote this value by $\delta_{min}$. Because the channel is idle, $\delta_{min}$ does not depend on channel conditions. The transmission time of the frame is determined by the transmission rate and the size of the packet, both of which are constant. The OS overheads depend on the hardware and software configuration of the DAP. If the channel is busy, the packet will be delayed by more than $\delta_{min}$. This additional delay depends on several factors such as number of contending stations, the size of packets they are sending and their transmission rates. To obtain a good estimate of the fraction of time the channel is busy, we send a number of such probe packets and count the fraction of packets that experienced a delay of more than $\delta_{min}$. Because $\delta_{min}$ does not depend on channel conditions, it can be calculated apriori by performing simple calibration experiments.

This technique works quite well in practice, as shown in Figure 4. The experiment was performed as follows. We set up a DAP with no associated clients on an otherwise idle channel in the 802.11a band. We had previously determined that $\delta_{min}$ was 250 microseconds. Using another AP and a client, we generated different volumes of CBR UDP traffic on the channel. We had also set up a sniffer to capture every packet. This graph shows the amount of free air time estimated by the DAP, as well as the ``actual'' free air time calculated using the trace captured by the sniffer. We see that the estimate provided by our method is a good approximation, although we tend to slightly underestimate the free air time.

Figure 4: Validation of ProbeGap method

Note that the probe packets are not delayed by the normal data traffic generated by the DAP itself (i.e. downlink traffic). So, to estimate the free air time, the DAP adds the air time consumed by the traffic it generates to the estimate obtained by the ProbeGap method before reporting it to the DC.

If a DAP has clients associated with it, it only needs to report the free air time for the channel it is currently on. If a DAP has no associated clients, it can scan all channels and report to the DC the channel that has the most free air time.

In our current implementation, each DAP sends the load estimation probes every 200ms. The free air time is estimated over a period of 20 seconds.