Thanks John,

Yes I think we've just about at the end the line of using Auto-RF for channel control. Its a good feature but it needs better (more granular) controls to be able to tune properly. I'm not looking foward to manually configuring things, though. Have you used the On-Demand feature to freeze things before re-assigning channels?

Honestly, I have no idea what that is. What I have done is just get my survey documentation from what I have completed so far and locked down the power and channels myself.

What truly turns my goat is the fact that the datarates themselves are configured globaly.

I am re-surveying a large multi-campus facility where the original survey was for coverage and not throughput. They didn't realize it would take off as quickly as it did. So, I have several areas that from one of a dozen reasons hasn't been surveyed yet where the power is too high and 1Mbps datarates are supported. I can't reconfigure my new surveyed areas to mandatory 11Mbps and turn the lower rates off. Doing so would cause holes all over the place, so even the places that are surveyed correctly, clients may not roam quite as well as I would like until the whole place is finished when i can turn the down all at once.

The on-demand feature does not and will not "freeze" what you currently have. When you turn DCA off all your APs go to channel 1. When you invoke on-demand you must wait 10 minutes (for the algorithm to kick in) and then you'll see some real channel assignments.

Do I take it from your reply that you have to turn it off first before you go to On-Demand if currently running Automatic? Or can you go directly from Automatic to On-Demand?

Hi Sonja,

I wouldn't mind hearing a liitle more about it. We have been told that a DCA on/DTPC off configuration "is not in use anywhere else," and "has not been tested by DE." Both of which I found hard to believe. Was ther any specific part of the DCA that was indicated as not not designed correctly? we suspect the neighbor beacons that form the RSSI picture go out at 100mW which is much higher than the client tx power we specify (also static at Level 3). As it turns out the dB output differs depending on AP model - 1240s L3 is 14dB (25.12mW), 1231s L3 is 15dB (31.62mW). Di you try dampening the DCA by unchecking all the avoidance boxes (AP Load, Foreign APs)? Did they say what the default Foreign AP RSSI DCA threshold was? Thanks in advance for any insight.

I believe that the DCA on/DTPC off config was not tested by Cisco. Until they finally admitted their problems they truly believed that having both on worked just fine.

The design flaw comes when clients create a coverage hole. Meaning they may be near an edge AP, even leaving the building, and the edge AP doesn't know any better and it would cause a channel change.

Neighbor beacons and their transmit power were mentioned also. That's multiplied by the number of WLANs you have too. We pretty much followed the lead of the TAC Engineer and they didn't mention anything about the Foreign APs. Although, in our environment, we don't have a guest vlan yet and we do see a lot of ADHOC clients that come in (patients/families with laptops). This would also cause a channel change.

Apparently the algorithms are due for an "overhaul" in the Sept 07 timeframe. The recommendation for us was to turn off DCA (and DTPC) for a stable environment.

I am running 4.0.216.0 on my WiSM's, 4.0.97.0 on my WCS, and 2.1.42.0 on my Location Appliances. When my deployement is completed I will have approx 1400 AP's. 98% of the AP's are 1131's. The other 2% are 1231/32's. We use both bands. We have 3 main hospital campuses and about 30 clinics throughout the immediate area. We deployed about 155 COW's using Atheros (ext. antenna) at one of our campuses to use for EPIC. All of the COW's are locked to use 5GHz. We went live with EPIC at this campus 04/29 and have not had 1 single call with any problems (I hope I didn't just jinx myself). I have been using auto-rf with the exception of a couple AP's that seemed to be installed to close other AP's in the area but, to get coverage in a lead lined wall room was needed. I am in the middle of piloting the 7921G phones and have been having one way call problems. The 7920's have been working good. I am definately interested in hearing how the DCA & DTPC is working out for anyone else. I keep hearing different stories from vendors and other companies saying they have their suspicions that auto-rf does not perform the way advertised (I will have to wait and see).

We had to turn it off -- DCA was activating too often (and on all APs simultaneously) causing de-authentications of clients.

We saw the majority of DCA events were triggered by Interference from Rogue APs. After we disabled Foreign AP Avoidance the number of channel changes dropped by an entire order of magnitude (1000s to 100s). We disabled Cisco AP Load Avoidance and this reduced the number of DCAs within an order of magnitude (100s less).

DTPC will power-up APs to max levels to provide a 3-neighbor -65 RSSI coverage "grid" and 7921s will power up to follow suit (up to their max Tx Power). Other clients with higher Tx power may send the APs to max power causing a mismatch with IP phones.

You can decrease the tx-power-threshold so the "grid" won't be as hot (default is -65, change to -71 or -74):

config advanced 802.11a tx-power-control-thresh <-50 to -80>

config advanced 802.11b tx-power-control-thresh <-50 to -80>

and reduce the coverage hole detection threshold (reduce Min SNR level in RRM Thresholds) to suppress the power-up activity. They are revamping the behavior of RRM in the WLC 4.1 Maintenance releases.

do you know of where Cisco has it documented the DCA is not designed correctly?

it sounds like you are talking about 2.4GHz..?

are you using 5GHz?

how was you data stuff working out with auto RF?

how large is your AP deployment?

are you using or planning to use Cisco phones

(7921's)?

Update: it is confirmed that the 7920s run at 20dB/100mW and the 7921s run at 17dB/50mW. This could be the source of issues with DTPC since it will power the APs up to 20dB if it thinks it has to to support a client (laptop) when the phones can only go to 17dB.

do you know where this is documented? or have a resource/contact to ask questions in regards? does is matter even if the voice is on its own vlan and ssid?

As bjohnson@partners.org points out earlier in the thread, while RRM typically works very will in most RF environments, some administrators may find themselves looking for finer, more granular control over RRM and its algorithms. Every network, after all, is different and the factors that contribute in channel and power assignments (such as noise, interference, neighboring APs? RSSIs, and AP load) could differ greatly from deployment to deployment, or even within a single installation. Many of RRM?s algorithms provides for great flexibility in allowing these varying factors to be included or excluded from channel plan computation, depending on RF environmental characteristics and network needs. It?s of paramount importance to understand RRM?s feature suite and the inner workings of its algorithms before attempting to make fine tune adjustments to algorithm thresholds and weightings. A great place to start is with the RRM whitepaper (at http://www.cisco.com/warp/public/114/rrm.html). As always, when fine-tuning such crucial network configurations, it is strongly recommended that you seek technical assistance from Cisco?s TAC.

Cisco understands the desire for such granular control because the much of the value of RRM lies in its ability to intelligently adjust RF configurations dynamically in order to provide not only an optimal configuration, but a stable network, as well. To this end, we actively collaborate with customers who run a wide variety of networks in varying RF environments, such as those in warehouses, hospitals, manufacturing, and carpeted enterprises.

With the 4.1 Maintenance Release(MR) due out on cisco.com shorly, many improvements based on such feedback have been brought into RRM's algorithms ? improvements aimed at allowing administrators to fine-tune their RRM-run WLANs where desired. These enhancements will allow for greater control over both the channel and power output selection algorithms, so administrators may assist RRM in being either more or less aggressive in such decisions, depending on application and network needs. Additionally, enhancements have been made to the management and reporting of all RRM information and configuration alterations to allow for better tracking of RF environmental fluctuations and to assist in keeping track of RRM activity. Further technical detail on the inner workings of these enhancements will be available very soon in an update to the above-mentioned RRM Whitepaper.

Cisco is excited that Radio Resource Management has become so integral to WLAN operation and we?re confident that the enhancements in our 4.1 MR release will continue to help customers realize the value that RRM brings to mission-critical WLANs.