Hello!
Just here to tell you all that if you happen to encounter issues with client connectivity on multiple 702i deployment environment, it is not just your environment facing these issues. In our environment following issues have been detected on these types of AP:s.
Tested on several laptops / mobile devices:
- Client on "radio auto select" so they can choose between 2.4Ghz and 5Ghz as they would naturally do. When 702i radios are on 40mHz band, on 5Ghz, clients have poor datarate - dramatic droprates to be excact. Yet for short periods of time they work as they should (10-30 seconds). Jitter, oh that jitter. Irratic mahoosive jitter is allso present with this setup.
- When clients are forced to use 2.4Ghz and 702i 5Ghz radios are on 40mHz band (2.4Ghz run allways 20mHz) - otherwise normal behaviour, yet crosschannel intereference drops performance as it would normally do. That is an small issue on this site, not major, but therefore we would have loved to run on 5...
- When clients are forced to use 5 Ghz and 702i A-radios are on 40mHz band - issues arise immediately or when clients should roam.
- Clients forced on 5 Ghz and 20Mzh band in place on AP:s 5Ghz radio -> normal roaming and performance.
- Windows clients allowed to "freely" choose between 2.4Ghz and 5Ghz and 5Ghz running 20mHz bandwidth -> Roaming might work between few ap:s, or it might take 10-20 pingdrops to establish connection. On its worst client might eventually reset wifi-nic when trying to roam and then resume operation. So actually, as an "out of the box" setup - it won't work, it will need tinkerin enduser device setup to fastselect 2.4Ghz or 5.0Ghz.
In this very same site, we have several parts of this multibuildingsite covered with 702i and 1602i/1702i APs. So that I can choose to go to "pure 1602i/1702i zone" vs 702i zone. (There are -15db walls between rooms which easily provide proper attentuation for the 1602i/1702i signals not to be heard on 702i zone.). Airquality has been sweeped with proper bandanalyzer tools for several times and there is NO interreference on any band/channel other than std AP noice/wifi traffic. Stay assured, we have experience on this kind of issues on other sites, we would have picked that sort of issues up by now.
When on 40mHz band, on 5Ghz, in 1602i/1702i zone, clients have normal datarates, roaming might make client loose a single ping packet, nothing else. When the same client resumes the 702i area - issues return and roaming from an 702i ap to an other ap just does not happen. As if the previous AP would stubbornly want to posses that client as its own.
WLC runs 8.1.131.0 version. WLC is 5520. 5508 was tested as well but it made no difference on this issue.
Commonly on all scenarios : The AP-radio is allways audible, properly audible -72dBm atleast. On any given location. You might allready have a 4ft line of sight to next audible ap (@-45dBm) - where client should roam to - but nothing happens but pingdrops. So this is not a radiocoverage issue. Given that "N-series" wifi has been around for a good while, I would not have expected this kind of issues with 40Mhz bandwidth.
Now the issue has been defined as what has been described above. We'll most likely just ditch the 702i ap:s and get functional units instead. Waiting for hardware/software fix is just too time consuming. None the less Cisco should fix this issue with 702i ap:s. They might get some TAC data from us related to this, but at the moment that is not our top priority point of concern as the HW is to be swapped.
Sunny summerdays to all ye! Hopefully you won't face these issues that we have had. Horrible enduser experience with business grade wifi. I would not have expected this kind of issues.
