VoIP over WLAN - Client Roaming Settings

[Frank Wagner]

Hello,

what would you suggest, are the best settings in the "Client Roaming Section" of the WLC Configuration for the following requirements:

VoIP over WLAN deployment, 802.11a, WLC 4402, 25 - 30 access points (mainly 1252, a few 1130), 7925G phones.

In the moment the settings are set to default, that means: Min. Rssi = -85; Hysteresis = 3; Scan Tresh. = -72; Trans. Time = 5

Unfortunately we are not completely satisfied with the roaming behavior of our phones, so there is the question,

if the roaming behavior of the phones can be improved. Sometimes it looks like the phone takes too much time to make a roaming decision.

Thanks,

Greeting Frank

[migilles]

Yes it would be very wise to have the necessary tools to support and maintain your WLAN.

Internally we standardize on Omnipeek (sniffer) and Airmagnet (wlan utilities).

For UvaldeMemorialHospital, can you open a new thread / topic for each of your issues.

I will reach out to the TAC engineer on your SR as I am from the 792x team.

Yes 1.4.2ES.1 will not help you here as that only fixes CSCtk58591, where the 792x phone is not able to connect at all after an invalid beacon is received (outside WLAN).

I don't see any traces / logs in your SR and it has been open for 153 days.

I assume that TAC has requested the necesary logs already????

If not, since you are seeing unexpected roaming and you believe that is the reason for the choppy audio, we need to gather phone logs as well as correlated WLAN sniffer traces.

The phone should have Kernel, WLAN Driver, WLAN manager set to DEBUG level.

You can increae the # of files and file size to 10 /250 kb or enable syslog via USB.

Be aware that with this increased logging, audio quality can be impacted, but since we are troubleshooting unexpected roaming it should be ok.

Just want to be sure you don't enable this debug level on many phones / production user phones, where we make things worse.

Once you get the logs, attach them to the case by replying to your SR thread with attach@cisco.com copied.

For Terri, since your case is not 792x specific, would suggest to continue to work with your TAC engineer.

But feel free to open a new thread / topic for your issues as well.

As mentioned, this thread is closed and deemed answered for the original submitter already.

So we shouldn't be using this thread any longer.

Thanks.

[migilles]

UvaldeMemorialHospita,

What is your SR #?

Also we should open a new thread here as this one is outdated and deemed resolved for the originator.

Sent from Cisco Technical Support iPhone App

[uvaldememorialhospital]

It is SR 618866317.

[Terri Carstenson]

Our #SR 619794173.

Did I miss the originator's resolution somewhere?

[Terri Carstenson]

Our consultant has identified another hospital they support that h as 79 7925 phones with the 4400 controllers and they do not have the problems discussed here.  They are running firmware version 1.3.3 on their 7925 phones.  We are going to downgrade some of ours today and test.  I will try to see what version of firmware is on their controllers.

[migilles]

The following post triggered the question as answered.

But that was back in Feb 2011 and was with 7.0.98.0.

They may have been hitting issues with that WLC release.

mlieber

32 posts since
Oct 30, 2002

Feb 9, 2011 2:51 AM                             (in response to Frank Wagner)

Correct AnswerRe: VoIP over WLAN - Client Roaming Settings

Hi Frank,

it seems that we have exactly the same issue.

WLC5508, SW 7.0.98

AP1140 and 1250

Phone 7921 and 7925 and 1.4.1 SW Version

Did you have got any news from Cisco about your TAC case?

Best regards

Martin

[migilles]

FYI, the 1.3(3) firmware release does not contain seamless interband  roaming (5 GHz to 2.4 GHz or vice versa); it can roam between the 2  while on call, but not seamless.

This was added in the 1.3(4) release, but also the scanning was re-worked in that release to accomodate for this feature.

And via the 1.4(2) release, we enhanced the scanning further where scanning frequency is increased.

Also some minor roaming changes as well.

So if you want to try 1.3(3), I would recommend to only try on 1 or 2 phones only and not do a bulk downgrade.

1.3(3)  is quite old now and there has been 6 792x releases since that release  now, so quite a few fixes and features you may need from those later  releases.

But 1.4(2) scanning and roaming will be close not if not exact to 1.3(3); at least from a scanning frequency perspective.

But  also 1.4(2) will contain interband roaming support, so if in an Auto-x  mode, then it will be scanning 5 GHz and 2.4 GHz simultaneously after  the initial association; always scanning on call and for idle it depends  on the scan mode configured in CUCM; auto scan mode means the 792x  phone's RSSI must reach a certain threshold before it starts scanning  and continuous scan mode means it is always scanning regardless of call  state.

For highly mobile users / environments, we recommend to  enable continuous scan mode, so that the neighbor list is always up to  date.  There will be just a small reduction in idle battery life; on  call battery life it not impacted with continuous scan mode.

[Terri Carstenson]

Thank you, migilles .

We have our 7925 phones set to 802.11a, not auto.  We do not need interband roaming support.

We only have the A 5ghz radio configured for the voice ssid. 

We do have WoWs also allowed on the 5ghz radios.  All other traffic in set to the 2.4ghz radios.

We have tried so many things here with no luck.  The changes made by the TAC do not seem to have improved our environment either.

Users are losing their patience and not using the phones and will often be seen moving the WoWs around in the hallway trying to get that 'sweet' spot.  They are not able to use them as intended.

The B/G network is much better, but I do notice while testing roaming using an Intel card on a laptop that I will experience dropped network connections with a -85 RSSI or higher while roaming.  Often there is an AP directly overhead and my client has not roamed to the stronger connection.

[Scott Fella]

Looks like you need to set your data rates. I dot know how it was surveyed or what TAC did, but if you don't have old devices on the network, maybe disabling the lower data rates... say everything below 12mbps in the 5ghz will help with clients holding onto an AP. When I see this happen in a hospital environment where the users are looking for a sweet spot. It almost is due to poor coverage. If you don't have AP's in the perimeter of the building and most are in the hallways, RRM should not be used in my opinion. Again, I have no clue what your design is and the layout of access points.

Thanks,

Scott Fella

Sent from my iPhone

[Terri Carstenson]

Scottfella -

I do have the data rates below 12 disabled.  54 is disabled.  12 mandatory, 18, 24, 36, 48 supported.

There are APs in rooms as well as hallways.

[migilles]

Yeah that's the recommended mode of operation, just pointing out the differences between the releases.

From reading the SR, it stated that the WLC was not configured per Cisco's best practices.

This would be outlined in my 7925G Deployment Guide.

http://www.cisco.com/en/US/docs/voice_ip_comm/cuipph/7925g/7_0/english/deployment/guide/7925dply.pdf

Have we cleaned up the WLC config yet?

If the issues are area specific, then would suggest you check your coverage.

We require -67 dBm at the cell edge, so ideally you should see 2 APs at -67 dBm or better.

This allows for seamless roaming.

Since you are not using UNII-1, CSCtx43105 woudln't be in play here.

Sorry, I can't speak about the Intel clients or their roaming behavior.

But -85 is a pretty weak signal in the WiFi world.  That would be on the edge of the rx sensitivity scale for even the lower 5 GHz data rates (e.g. 12 Mbps).

Suggest to work with the TAC engineer further on this SR.

[Terri Carstenson]

I believed the configs to be per Cisco specs.  I used the WLC Controller templates to configure the changes.  I had to go to each controller to get the controllers to accept the changes.  WLC software indicated it had successfully completed the changes.  I had not performed an audit to confirm that the software actually applied the changes.

I have been told by two Cisco TACs and two consultants not to use WLC to perform changes, only to report and monitor the wireless environment.  They had seen similar issues.

[uvaldememorialhospital]

I have created a new thread:

https://supportforums.cisco.com/thread/2128250

I also uploaded a short video of the described behavior but it hasn't posted yet.

Trace logs have been provided to our contact person on Nov. 16 of last year. The trace was set to "info" and in this case the phone roamed from an AP with an RSSI of -51 to an AP with an RSSI of -83 while stationary.

I sent new logs today with "debug" level of data in them on kernel and wireless lan driver. I didn't include wireless lan manager in the trace but will... (does that capture WLC information?)