Thanks for the info. This is a great summation of what is required.
I have identified something that you may have encountered and thought I would ask,
1x 7925G handset, with 3COM wireless deployment.
All wireless devices can connect fine and operate as expected, but the 7925G shows some funnies, one of which indicates a clear pattern.
After the phone connects, and registers with the CUCM, it can make and receive calls shortly after registration. If you leave the phone alone, but run a continual ping to it's IP address, without fail the phone disconnects from the network (and obviously unregisters) for a period of approx 2 minutes and 15 seconds, it then comes back up for a period of 55 to 60 seconds, and then drops off again for 2 minutes and 15 seconds, then back up for a minute, and so on.
Based on this finding, it clearly indicates a pattern.....some sort of timer.
I have exhausted the options available for configuration on the handset itself. I have used all your tips provided here and have gone through the 3COM controller agina and again looking for ways / options to change things further. But everything is set to "best practice" as per deployment guide.
Running out of ideas....Cisco TAC simply say it must be the 3COM wireless - but all other wireless devices, including my iPhone and iPads work fine.
Suggest to open a separate thread for your issues.
However, ensure you are using the 1.4(3)SR1 release for your 792x phones (firmware 1.4.3SR1.2) as it contains some critical fixes for 11n APs (see CSCtn75346).
We do not formally test interoperability between our Cisco 792x WLAN handsets and the 3COM WLAN solution, so we can not guarantee interoperability, but as long as standards are followed and not encountering a defect on either side, then basic call functionality should operate just fine.
Every spot in the coverage area is serviced by at least two viable 5GHz access points, at -67dBm or stronger
Up until now I've always been told to make sure there is roughly 25% overlap at -67dBm, which makes sense to me. Why two? I'm already blown away by the density of model-3600 APs required to satisfy the 25% overlap, especially on UNII-1 channels with the 6mW Tx power limit.
Let me explain the thinking here in specifying "at least two viable 5GHz access points, at -67dBm or stronger".
First of all, the -67dBm level has always been our standard for voice coverage. For one or two calls per cell, this is not strictly required, as long as you have lower data rates enabled, but this is specified in order to have the desired call capacity.
Now, the "20-30% overlap" at -67 between cells continues to be the standard as given in the 7925G DG. This design will allow phones (with the improved scanning in 1.4.2 and above) to roam smoothly across cells.
The reason for the recommendation here for two APs at -67 dBm is for purposes of reliability - specifically for deployments where the phones are operationally critical, such as healthcare. If much of your coverage area is served only by a single AP, then any phones in that location are going to have a problem in conditions such as the following:
the AP radio resets or the AP reboots (it happens ...)
the AP radio needs to change channels due to DCA, interference or radar detected, etc.
a phone associated to the serving AP decides that it is no longer viable (due to a momentary glitch - packet max retries, or BSS loss), so it needs to roam elsewhere. If there is not another viable AP in the area, that phone will need to rescan before roaming back to the serving AP (costing typically 5-6 seconds)
For deployments that are not so critical - where the clients are tolerant of (rare) 2 to 6 second audio gaps - then the 7925G DG's recommendations stand.
My biggest problem with "two APs @ -67 (at 5 GHz)" is that the CCI at 2.4 GHz is significant. 802.11n 5 GHz-capable client support has been underwhelming and therefore there are obviously still plenty of 802.11g/n clients in use. As much as we'd all like to forget it, 2.4 GHz is still an important band to design for.
I have designed for "two APs @ -67" and also for 15 - 20% overlap. Even when designing for 15 - 20% overlap (let alone two APs @ -67) some 2.4 GHz radios need to be disabled as the CCI is far too high. The problem with this solution is two-fold. In a VoWLAN environment you're often doing RTLS - by disabling that radio you lose RTLS accuracy. Yes, you could add an adjacent MM AP but you shouldn't have to bear the exta cost/mgmt overhead for what should be a software solution. The second issue is that the WLC hasn't really been designed with the thought that someone may want to deliberating and permanently disable radios. For example, the dashboard will show the number of 2.4 Ghz radios down, whether they have been administriviely disabled or have died making it hard to spot dead radios (rare as they may be).
The solution is per-radio MM, which is apparently on the way; it can't come soon enough! This would allow the 5 GHz radio to serve clients whilst the 2.4 GHz radio in MM assists with RTLS. The 3600 + module could help here but this is extra cost, doesn't help existing deployments nor address the second issue.
Limiting SSIDs / disabling low data rates of course helps with the CCI but limiting the amount of actual actual 2.4 GHz transmissions (i.e. - not having an AP density higher than required) is also a pretty important piece of the puzzle.
I think you're on the money though - "two APs @ -67" in critical environments probably should be standard. The missing piece of the puzzle imo, for Cisco deployments at least, is per-radio MM.
With that said, can you give any indication when we might see it?
Lastly, any idea when we may see CSCtt38270 fixed? 802.1X-based VoWLAN deployments have their own problems from an administritive perspective.
This document's recommendations pertain very specifically to support for 792x clients only, and only in 5GHz (not 2.4GHz). As you rightly note, 2.4GHz support is an entirely different story.
The feature that you are interested in (per-radio roles) is outside of the scope of this article.
As to addressing CSCtt38270 (7925 sometimes takes 1+ second to respond to WPA M1 key message) - for that to happen, the following sequence of events will need to occur:
a customer who is really insistent on using PSK, not EAP, must open a TAC case
that customer must keep the TAC case open till the problem is resolved
that customer must be willing to run experimental phone firmware, collect logs and wireless sniffs, etc.
CSCtt38270 is listed as Terminated in the bug tool which usually means it will never be fixed since it can not be reproduced. So, will the bug ever be fixed? WPA2/PSK is used in most of our existing implementations (that have been implemented before this bug was first seen) and is still the prefered method for large deployments (WLANDefault.xml)
Regardig the Continuous Scan, do you know how this will affect the standby time?
Do you know if and when your guidelines will be included in the 7925 deployment guide?
Regarding CSCtt38270 - you are right that this bug is not open, so it won't get fixed unless something changes. For this bug to get fixed, the following will need to occur:
there must exist a customer who is determined to use PSK
this customer must have a TAC case open
the TAC engineer must reopen the bug
the customer must be willing and able to reproduce the bug, and to collect over-the-air traces, debugs, logs, etc., and to run test code from engineering as needed
Regarding the impact of enabling continuous scan on battery life ... we haven't quantified this. I guess I would say, "some impact, but it's not devastating".
Regarding the above recommendations being included in the DG - I don't believe there are any plans per se.
All of this stuff is currently already listed in my 792xG Deployment Guides as this is where most of the content for this doc originated.
But is not in list format like this per se as this list touches on different sections of the guide providing highlights.
For #1, this is all covered in the guide already. 5 GHz has always been the preferred band for use.
For #2, we always recommend to use our latest code.
For #3, This is a bug on the WLC/AP side and not 792x specific plus we don't list caveats in design guides. We only list the AP platforms we support, but not per se the operation mode (e.g. local or HREAP) as we qualify the radio only and what happens upstream once it hits the AP is out of the phone's hands.
For #4, WPA2+CCKM is definitely the preferred security type. But we support various methods and up to the admin to select what suits them best. As mentioned above, we don't list caveats in the design guide. See below for more on CSCtt38370.
For #5, this is all covered in the guide currently. But is not just as simple as enabling 6 Mbps for all deployments. See below for more info.
For #6, it is currently stated to enable continuous scan mode if frequent roaming occurs or pico cells have been deployed.
For #7, as stated in this bullet, this is all documented in the guide already.
However, a few items are not hard requirements although they seem to indicate as such in this document.
1) "Never PSK" is a bit harsh. There are definitely scenarios where PSK can be used. But if frequent roaming occurs, then obviously WPA2+CCKM utilizing PEAP or EAP-FAST is the recommendation.
2) "Always 6 Mbps" is not the common recommendation. For capacity, throughput and RF footprint reasons, the recommendation is to enable data rates 12 Mbps and higher. And if the band used by 792x clients is for only voice applications, then could potentially disable 36-54 as there is no capacity or throughput gain. But if data, video or other applications are utilizing the same band which can take advantage of the higher data rates, then by all means enable those rates. As far as enabling 6 Mbps goes, you may want to enable this in an environment where mutlipath is inevitable or where you need max range on 5 GHz. But as mentioned, enabling 6 Mbps is NOT the norm.
As or CSCtt38270, yes this is currently in U state as we have been unable to reproduce this in our labs.
We have had a couple of customers that have had issues with PSK, but once we have engaged, they have either switched over to CCKM or are unable to reproduce the issues any longer.
If you have a customer facing issues with PSK, please open a TAC case, where the TAC engineer can then engage the DE team to assist. We have a special debug image available that we would need to get logs from in order to pursue further on this if there is truly an issue.
BTW, PSK is definitely NOT the preferred security type for large deployments. As mentioned above, WPA2+CCKM utilizing PEAP or EAP-FAST is preferred.
PSK is for personal or home deployments; not enterprise grade like WPA2+CCKM.
FYI, you can utilize the WLANDefault.xml generated by the BDU for 802.1x deployments as well if you wanted all phones to have the same username & password. If you want all phones to have unique accounts for better device management, that is also an option via the BDU, where you choose the Bulk export method vs Default export method, where you will be prompted to upload a CSV file containing the phone MAC and associated username and password to use for that phone. The bulk method will generate files including the MAC address that can be uploaded to the TFTP server the same way as the default file.
As far as idle battery life when continuous scan mode is enabled, it is minimal (maybe around 10-15%).
Should sitll last for days depending on talk time, but definitely enough to cover an 8 hour work shift.
Continuous scan mode has no impact when on call as the 792x phone is already scanning all the time.
Aaron, in response to your comment below, if you believe there are items listed here that are not listed in the 792x Deployment Guides, ping me offline and we can discuss further where I can provide necessary page #s.
"Regarding the above recommendations being included in the DG - I don't believe there are any plans per se."
Has firmware 1.4.3 been submitted for FIPS approval yet? As you may know, until this is done and approved, this is going to be a challenge in the Federal Government.
Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community:
