Ask the Expert: Wireless 802.11ac Configuration and Client Interoperability

[ciscomoderator]

   

Welcome to this Cisco Support Community Ask the Expert conversation. This is an opportunity to learn and ask questions about configuring and client interoperability of wireless 802.11ac with Richard Hamby and Yilin Weng.

The ever-growing demand for faster wireless connectivity brings us to the 802.11ac standard. Cisco’s new portfolio of 802.11ac-capable access points delivers new features to the enterprise. The current range of unified and converged wireless controllers supports 802.11ac and uses the overall Cisco strategy to deliver performance and management to your network. 

For this discussion, Richard Hamby and Yilin Weng will help to demystify some of the concepts and deployment considerations required to make your 802.11ac environment the best it can be. They will also answer your questions related to specifics of the 11ac standard, client interop, configuration, troubleshooting, and deployment considerations for your wireless network. 

Richard Hamby is a technical support engineer in the Cisco Technical Assistance Center in Richardson, Texas. He is an expert in wireless products, including the Cisco Unified Wireless Network and the new Unified Access Wireless products. Prior to his current position, Richard was a customer support engineer with the authentication-authorization-accounting team supporting Cisco identity management solutions.

Yilin Weng is a technical support engineer in the Cisco Technical Assistance Center in Richardson, Texas. He is an expert in the Cisco Unified Wireless Network and Next-Generation Wiring Closet (NGWC). Yilin has been working for Cisco since 2011 and holds CCIE certification 39885 in wireless.

Remember to use the rating system to let Richard and Yilin know if you have received an adequate response. 

Because of the volume expected during this event, our experts might not be able to answer every question. Remember that you can continue the conversation in the Wireless Mobility community, under subcommunity Security and Network Management, shortly after the event. This event lasts through May 9, 2014. Visit this forum often to view responses to your questions and the questions of other Cisco Support Community members.

[yiweng]

I will be using 3700 datasheet for rates for reference (different model rates may vary).  Table 1, under 5GHz 11n and 11ac

http://www.cisco.com/c/en/us/products/collateral/wireless/3700-series-access-point/data_sheet_c78-729421.html

On the Controller, you can go into each client to check what speed that client is getting.  You can either go to the controller GUI -> Monitor -> Clients -> Select MAC address, the controller CLI> show client detail <mac of the client>, or from AP CLI, the command ‘show controller d1 client’ (or d2 if using the 11ac module on AP3600) gives real-time connection info.

You will see 2 formats of ac client data rates in the GUI.

Examples:

• M7 SS2 – This format implies Short Guard Interval 400ns

The 7 Is the MCS index number and the SS2 is Spatial Stream number. In this example, should be MCS index 7 with 2 spatial streams, client’s date rate is 144.4Mbps, 300Mbps, or 650Mbps (20MHz, 40MHz, and 80MHz respectively).  The GUI does not show the channel width in client details.

• M7 130 – Long Guard Interval 800ns

There’s a little difference for 800ns Guard Interval rates, MCS index is still 7 and the number 130 is what rate client is getting. From that you can cross reference 3700 date sheet chart what spatial stream and what MHz client is using. In this case, MCS index 7, spatial stream 2, and 20MHz rate. The GUI again does not show the channel width in client details.

802.11n rates will be reported by the MCS Index number, and rate will be listed if long GI (see 11n section of Table 1). 

In general, it’s rare to see a long GI rate.  Most devices support short GI and our APs will automatically support whatever the client can.  There is one exception – when using the AP3600 with the 11ac module, it is not uncommon to see the client rate reported in long GI rates.  This has more to do with how the slave radio reports the client data rate value than what is actually being achieved.  If you want to verify, use the AP CLI and run ‘show controller d2 client’ for the real-time connection specifics of your client.

Please note:The controller might not show client data rate immediately after association. The client needs to pass traffic in order for AP/controller to report proper rate.

[hhtyson11]

Hello both,

I'm not getting better performance with 11ac than ith 11n - sometimes it's even slower.  Why is that? Appreciate your help on this.

Thanks,

Henry

[Richard Hamby · Accepted solution]

Hi Henry,

This is probably the most frequent topic and there are a number of typical root causes.  Here are some of the most common:

• Client wireless device drivers

While 802.11ac-capable client devices and access points have been on the market for the last 12-18 months or so, the fact is it's still an evolving technology and plenty of interoperability issues have been discovered and addressed during its adoption.  Too, early versions may not yet have supported many features defined in the standard.  Check with your vendor and install current versions of the drivers as a first step.

• Interoperability issues for non-11ac clients

11ac-capable APs advertise new information elements (IEs) in their beacon/probe responses that did not exist a couple of years ago.  And from an RF perspective, things look a little strange in the air compared to when that adapter or driver was state-of-art.  While the device may not be 11ac-capable, it needs to be able to interoperate.  The 802.11ac standard is written to be backwards compatible with b/g/a/n devices, but older drivers may not have been written or tested with 11ac in mind.  Again, consider starting with a driver upgrade as first troubleshooting step.

•Adapter Capabilities

802.11ac promises to deliver raw wireless data rates up to 1300 Mbp/s – and it can with the right hardware under the right conditions.  But the proper access point and client adapter are required – just because a device is 802.1ac-capable doesn’t mean it is able to fully exploit it.  To achieve that speed, the client adapter and the access point must be capable of supporting 80MHz-wide 4-channel bonds, 3 spatial streams, and a guard interval of 400ns.  Most USB 11ac client adapters and integrated chipsets in mobile devices on the market are 1SS or 2SS, therefore the max possible rates they can achieve will be lower.  The data rates supported by each AP are in their respective Data Sheets,  and the Tables are useful to describe what's possible for each # SS, GI, channel width, etc. Below is the link to the AP 3700 data sheet for reference.

So for example, take a 1SS-capable 11ac device with 80MHz channel.  The maximum possible 11ac DTR for that device is 433.3Mb/s.  Many Apple MacBook Air and Pro models have a Broadcom 3SS-capable card so they are the most common we see in the field capable of top DTRs.  Check the specs on your adapter, and if purchasing a new one compare the capabilities.

http://www.cisco.com/c/en/us/products/collateral/wireless/3700-series-access-point/data_sheet_c78-729421.html

• Configuration

802.11ac (like 11n) requires the WLAN to have AES encryption (or Open) and WMM. Also, 4 channels must be available and assigned to each AP for the 80MHz bond to achieve highest rates.  If using the WLC, check under DCA and verify 80MHz channel width is enabled.  If any one of these is not met then 11ac will not work.  Too, check the driver configuration of the client adapter and verify it’s set properly for 11ac.

One other common quirk that comes up is how the WLC reports client 11ac rates.  It does not report the clients' rate in channel-width qualified terms,  only an MCS Index and # of SS (refer to Yilin's earlier post). So if you see M9 3SS (for example), that could mean 288.9, 600, or 1300 depnding on the channel-width configuration of the AP.  For long GI rates, we list the actual DTR value the client is using.  So when reading client details, keep in mind what the channel width is of the AP.  I may file an enhancement request for this so it's clearer.

• RF Conditions

All typical WiFi caveats apply for 802.11ac just like legacy standards.  Wireless is a half-duplex, shared medium environment so think ‘Hub’ (not switch) when considering throughput math.  Each addition of a new associated device divides the aggregate available bandwidth of the AP.  Even under the best of RF conditions, WiFi is lossy.  802.11 frame loss over-the-air occurs regularly and can vary greatly  depending on hardware (client and AP), interference, and distance from the AP just to name a few.  The impact this loss can have on protocol packet data performance also varies depending on the type of stream, IP stack, protocal, etc.  Realized data transfer rates will be lower than the raw wireless data rate by an appreciable margin.

Also – until a few years ago when MIMO and 11n came into play, multipath was the devil.  Much of our own documentation still discusses ‘multipath mitigation’ in evil terms.  But to achieve 11n and 11ac rates, multipath is essential.  This requirement presents special challenges especially in outdoor environments where there are no convenient cubes/windows/floors/ceilings to induce MP.  For environments where MP may not be intrinsic, consider the use of external antennae with cross-polarized elements which can help induce it.

• Software Bugs

If you are not running the current versions of AP or controller code and are experiencing an issue, check the Release Notes of latest images to see if any issues have been addressed.  There have been a few 11ac-specific fixes published since 7.5/7.6 first released so consider current code (7.6.110.0 as of this writing).  You can also check the Bug Toolkit on cisco.com for more up-to-date information or call TAC for assistance.

[George Stefanick]

Richard,

You hit the nail on the head. In all the cases, in my testing, it has been something on the client or config. 

Thanks for sharing this. Great point of reference for all!