Associating New Clients

Figure 2 illustrates the association mechanism instrumented in DenseAP. (i) A new client $C$ with mac address $C^{mac}$ broadcasts probe requests. (ii) DAPs $DAP_1$ and $DAP_2$ receive probe requests and inform the DC of $C^{mac}$. (iii) The DC executes the association algorithm and determines which AP the client should associate with. Assuming it picked $DAP_1$, the DC then sends a message to $DAP_1$ to add $C^{mac}$ to its access control list ($ACL_{DAP_1}$). (iv) $DAP_1$, on receiving the next probe request from $C$, checks to see if $C^{mac} \in ACL_{DAP_1}$. If so, it responds to $C$ with a probe response thus initiating the association process. If $DAP_1$ was not previously beaconing, it now begins.

The reader may wonder why DAPs beacon at all. One reason is that beacons are essential for allowing the clients to enter power-save mode. In addition, certain popular drivers automatically disconnect from an AP if they do not receive periodic beacons.

We note a few points about this mechanism. First, we have verified that this mechanism works with the device drivers of a variety of popular 802.11 chipsets including Atheros, Intel Centrino, Realtek, Ralink, and Prism2. Second, if a client fails to associate with the assigned DAP (e.g. due to interference near the client), the DC detects this since DAPs periodically report back information about their associated clients. The DC then re-assigns the client to a different DAP. Third, ACL entry for a client is maintained only as long as the client is associated with the AP.