Sabhasin,
I appreciate your response, however the issue, even with the current enhancements over execution of the DCA algorithm, is that it sends simultaneous channel-change requests to multiple APs at once, and dis-associates active clients from their APs, and any nearby APs that they might be able to connect to, with no regard to applications.
As before, it also lacks the means to set a Rogue AP RSSI DCA floor (rogues are the main trigger for DCA), and the DCA beacons sent from each AP to determine DCA changes is sent at 100mW and 1Mbps data rate, rather than the user-configured data-service rate, which the clients hear and use. As a result APs are changing channels for no good reason as far as the clients are concerned. As it stands now, good luck using more than one subnet (via AP Groups VLANs) per building w/o DCA kicking clients off and changing their IP address (and breaking apps). Unless they can treat these clients like a standard roam event, one subnet per building is the limit (and aren't we supposed to be following Cisco's wired subnet design policies of one VLAN per floor?).
There have been recent changes to the algorithm to modify the execution. The "5dB better SNR" metric now has a range of 3 values instead of one, DTPC will not power up if it has only 1 client on the fringe of coverage, and they've defaulted the neighbor RSSI to -71). This "numbs" DCA so it is not as reactive, but its equally or more important that it be sensitive to existing (including non-intelligent) associated clients and traffic.
What happpened to providing min/max TxPower limits for DTPC, and how about deferring DCA on APs with clients or any traffic (not just voice)?
Its all well and good to make things work for Intel and the CCX/CCKM compliant crew, but if you have any of the other brands of WLAN NICs (like those made by medical device manufacturers, who won't subscribe to fast roaming features until they're adopted by the IEEE) you are best keeping RRM disabled until it delivers on its promise as stated in the following 802.11TGv Objectives draft:
Service and Function Objectives
Solutions shall define mechanisms to provide the service listed below.
[Req2000] TGv shall support Dynamic Channel Selection, to allow STAs to avoid interference. Solution shall be able to change the operating channel (and/or band) for the entire BSS during live system operation and be done seamlessly with no intermittent loss of connectivity from the perspective of an associated STA. Solution shall not define algorithm for channel selection.
P.S. And how about a detailed doc showing how to tune the product in a live environment? Is it too much to ask for a legitimate case study with requisite RF environment assumptions and real before and after data with a mixed client base?
