Anyone deploying Auto-RF for channel-assignment only?

Unanswered Question

Hi folks,

Curious to know if anyone is deploying LWAPP Auto-RF just for Dynamic Channel Allocation (DCA), not for Dynamic Transmit Power Control (DTPC).

We have a dense deployment of APs (ten floors of a hospital in a 4-leaf clover design with "pods" at each leaf having 2 APs each) and have enabled DCA only, with a static Tx Power constant of TPL3 (31mW). Note: the original IOS AP setup was at 20mW and we intend to lower the TX Power to TPL4. Its our understanding that AP neighbor beacons (sent at 100mW) are controlling DCA behavior regardless of this.

We are finding that DCA is going nuts in this environment (12-24 channel changes/day on several floors of APs all at once). It seems to never to stabilize. And it impacts both APs in a coverage area: each floor "pod" loses both APs (due to client de-authentications prior to the channel change) at the same time. See attached DCA reports for two floor pods APs (9 floors apart).

Is it acceptable to enable Dynamic Channel Allocation but not enable Dynamic Transmit Power Control in this way? Could this be contributing to the DCA activity?

Thanks folks,

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 4.5 (9 ratings)
john.preves Mon, 04/23/2007 - 10:34
User Badges:
  • Silver, 250 points or more

Why not save your hair and just manually allocate everything? I am currently attempting to migrate from autonomous to LWAPP and it is pure funk. I do not believe a hospital was what they had in mind when they invented this stuff.

If you do not have 80% overlap in your cells the channels and power will never stabilize because they do not see each other properly. A hospital has too many things that get in the way.

A warehouse probably would work well. But a hospital, or at least our hospital just doesn't work dynamical.:0

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?

john.preves Mon, 04/23/2007 - 21:22
User Badges:
  • Silver, 250 points or more

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.

sonjam Tue, 04/24/2007 - 06:14
User Badges:

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.

sonjam Tue, 04/24/2007 - 06:05
User Badges:

Please let me save you some major headache. We are also a healthcare facility with a very dense deployment of APs. I've always had the Auto-Power turned off and manually set to 3 (25mW) for our Vocera deployment. Recently, we had to open a case with Cisco about our wireless data connections "dropping." Long story short, and a tremendous amount of troubleshooting, Cisco admitted that the "algorithm" that's used for DCA isn't designed correctly. We had to turn DCA off in order to get a stable wireless environment. Let me know if you need more details.

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.

sonjam Wed, 04/25/2007 - 05:36
User Badges:

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.

coolccnp Mon, 05/07/2007 - 14:56
User Badges:

I am running on my WiSM's, on my WCS, and 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.

coolccnp Tue, 05/08/2007 - 06:44
User Badges:

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


coolccnp Tue, 05/08/2007 - 08:05
User Badges:

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?

sabhasin Thu, 07/19/2007 - 15:19
User Badges:

As [email protected] 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 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 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.


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?


This Discussion



Trending Topics: Other Wireless Mobility

client could not be authenticated
Network Analysis Module (NAM) Products
Cisco 6500 nam
reason 440 driver failure
Cisco password cracker
Cisco Wireless mode