Should I use the flexibility of the RRM function provided by LWAPP controller or should I use the static values that are given to me from a site survey. Some people say that VOIP on wireless will have some problem with the dynamic method (RRM).
Feedback from large LWAPP installation will be very appreciate.
Typically the issues I have heard of with RRM focus on power levels more than channel selection. I have done several large deployments and it is very rare for RRM to change the channel of any APs once all of the APs have been deployed. I do like that it can react to neighboring interference and rotate all the channels if necessary though.
As for power, as long as your phones support DTPC (7920s do) dynamic power management is also a good thing. It allows for automatic mitigation of failed APs.
In my opinion, the initial survey is essential to get enough density for your needs, but after that I let the controller do its job. The only possible exception in my experience is outdoor, where I tend to do manual power due to the nature of sector antenna coverage.
Does the RRM process ever causes APs to reboot or effect RF throughput? We have seen several strange occurrences of this in our LWAPP deployment (80 APs). We are running VOIP (7920 & Vocera).
It definitely should not cause a reboot. It should not affect RF throughput, though if a client does not implement DTPC (dynamic transmit power control) properly, I could see potential for client issues when it adjusts power. 7920s with the most recent code support DTPC, but I am not sure about Vocera.
As a frame of reference, I have ~850 APs running with RRM enabled, and after the first day they seldom change power levels, and almost never change channels. When troubleshooting some client issues, the first thing they had me do was kill the rrm, but when that didnt fix it I re-enabled it.
kwonza - what version of software are you running on your WLCs?
I recently had an issue where our client thought the rrm was rebooting APs and it turned out to be a recent bad release of code (184.108.40.206 I think)... there's an update (220.127.116.11) available to fix this...
Please rate helpful posts...
One semi-related note: With version 18.104.22.168 we observed that performing manual, on demand RRM does not produce the same results as when the system is allowed to run constantly. It appears as if the system must run for a number of hours before it "settles down".
We are at the latest code for WLC4404 4.179(8). Another thing I have noticed is that all of our AP (85) are at full power. We are set for RRM and have not made any static changes. We surveyed for -65dbm as well. Has anyone else seen this?
If all power settings are at "1" (full power), it might imply that the APs cannot "hear" each other.
Can you perform a limited post-install survey in a small area or two to see what your coverage actually is?
Before performing a survey, I have temporary changed the AUTO RF settings on the WLC to ensure that it is not trying to dynamically adjust the RF during my walkthrough. After the survey, I will set it back to auto channel/auto power.
Yes, this was our next step to perform again. We did do a walk-through after the initial survey and verified the RF numbers of -65dbm or better. We even added a few more APs to fill in a few holes on the border. Did see one floor with pwr level at 2 and 3. First time I've seen this. Thanks
Cisco told me that any change by RRM (ie. to Tx power &/or channel allocation) would cause all clients on the changing APs to have to associate from scratch.
What is your experience.
I have not had that experience. My APs change every once in a while, and it does not force a re-auth. If you are seeing drops, you may have another issue at work.
Please remember to rate all helpful posts.
This document here will answer all your questions about RRM. One of the better ones I've read.
My LWAPP environment changes as well without any client issues.
I agree - this is a most extraordinarily useful document.
If only it were avg. for Cisco doc. :)
Going back to the original question, you may find conflicting recommendations based upon what the 3rd-party VoWLAN phone manufacturer recommends vs those of Cisco (who typically recommends leaving RRM on constantly).
If the VoWLAN phone cannot automatically adjust its transmit power (i.e.: using CCX extensions - see http://www.cisco.com/web/partners/pr46/pr147/partners_pgm_concept_home.html for more details), you may have to make accomodations for the specific requirements of the RF client.
For example, you may find that a phone manufacturer may recommend that the WLAN power settings for the APs be set to the power setting throughout the system. This is true of SpectraLink phones which, to my knowledge, do not support CCX extention for dynamic client power adjustment.
Ultimately, you will need to decide whether voice quality takes priority over some of the RRM features.
One other observation I would like to add is that my experience so far with the WLC's automatic channel selections are less than optimal compared to those from the original design.
I have had good success "suggesting" the approprate channel for each AP (by setting it manually), turning off AUTO RF channel selection temporarily, returning each AP back to auto channel selection, and re-enabling the global AUTO RF channel settings.
Typically, the WLC will keep the manually-set channel (unless there is significant outside interference later on - which is what it is supposed to do). So far, this has resulted in better power levels since the APs are not being turned down to avoid same-channel interference that was present from the WLC's automatically-selected channels.
This may not be necessary for every environment, but I have found it to be the case so far.
I wouldn't mind seeing a product enhancement that would permit an optional "suggested" channel setting for each AP that would be used initially by the WLC.
I have requested a formal product enhancement for the WLC to provide a a "preferred channel" that the WLC would attempt to use if possible.
Apparently, this feature has been requested by others as well.
So... maybe we will see this in future releases.