Thursday, August 21, 2014

Quick Take: Wider Channel Widths Are Flashy but Not Efficient

I've been thinking of writing a well-articulated blog post on why the preference for high-density Wi-Fi networks is smaller channel width over larger channel width. This post is NOT that.

Instead, I was on Twitter articulating some of the logical points why smaller channel widths provide better aggregate capacity than larger channel widths (assuming you deploy enough radios and take advantage of all the spectrum at your disposal). Here is a quick recap of those points.

You might want to reference my SNR to MCS Index Mapping Table, which shows why larger channels result in a reduction in modulation rate that can often offset the gain from using the wider bandwidth in the first place. And my 802.11ac Receiver Sensitivity charts show that you have to have a really great signal strength for wider channels to even be considered, but watch out in your design because overcompensating to achieve higher signal strength will increase co-channel interference (CCI) which travels a LONG ways! Finally, my post on 802.11ac Adjacent Channel Interference (ACI) shows that wider channels create more ACI than smaller channels, and ACI is even more detrimental and unfriendly than CCI. Therefore, radio receivers require greater adjacent channel rejection (up to 8dB more), and with fewer channels for frequency re-use ACI is more likely.


Wednesday, August 20, 2014

802.11ac Receiver Sensitivity

Following my previous post regarding typical SNR to MCS rate mappings for Wi-Fi clients, an interesting discussion was held on Twitter regarding the effects of increased channel width on the ability of a client to decode frames at any given SNR. Long story short, wider channels increase the noise power captured by the receiving radio which reduces its SNR. For every doubling of channel width, you require 3dB better signal to achieve the same MCS rate.

George Ou created a chart showing the relative range of each MCS rate based at various channel widths:

Following up on his work, I thought it would be useful to provide some context around these coverage ranges by referencing it against a typical noise floor of -93 dBm found in many environments. Using this noise floor and the SNR to MCS rate mapping table, combined with the relative coverage ranges (based on RF signal propagation using the inverse square law) we can visualize what data rates a typical 802.11ac radio will experience at various RSSI and SNR signal levels for each channel width.

Note - these receiver sensitivities are not absolute. Wi-Fi radios vary. But this chart is a good approximation for many radios and provides a generic reference for you to visualize and understand this effect.

802.11ac Receiver Sensitivity (Down to -91 dBm)

Update: as requested by various folks, here is a zoomed-in version of the same chart so that the higher data rates are easier to distinguish.

802.11ac Receiver Sensitivity (Down to -82 dBm)

Thanks to George Ou for his work on the initial chart!


Tuesday, August 19, 2014

Visualizing How Wi-Fi SNR Helps Determine the Achievable MCS Data Rate

If a Wi-Fi station has a better signal, you get more throughput. Everyone knows that. Here is a handy chart to help visualize it.

This table shows the "typical" data rates that Wi-Fi stations can achieve based on their SNR (signal to noise ratio). I say "typical" because it actually varies based on the radio chipset receiver sensitivity, but these values are a good starting point for most devices.

The achievable data rate (MCS rate) varies based on a number of variables:
  1. The 802.11 protocol - really a function of the increasing maturity of chipsets over time to handle more complex modulation types even when SNR is a bit lower.
  2. The channel width - typically doubling the channel width increases the noise floor by 3 dB, which decreases SNR. So to get the same MCS rate on wider channels you need higher SNR.
  3. The complexity of the modulation - notice as you get into more complex modulations like 64-QAM and 256-QAM that it doesn't take much more SNR to move from the lower encoding rate to the higher encoding rate, and vice versa in the opposite direction.
Typical Wi-Fi SNR to MCS Data Rate Mappings
(Download for full resolution image)

The table is color-coded based on modulation type:
- BPSK = Red
- QPSK = Orange
- 16-QAM = Yellow
- 64-QAM = Blue
- 256-QAM = Green

Update: Keith Parsons was kind enough to put this chart into a printable format in PDF. Download the printable version here (not color coded).


Saturday, August 16, 2014

Optimized Roaming, RSSI Low Check, RX-SOP, Oh My!

In the Cisco landscape today, there are three features that usually come up in the same conversation. They all solve what I'd call "related" problems, but are not the same. They are incredibly useful features and do share one thing in must know your RF environment before implementing them. I'll provide use-cases and examples below, but it should be noted that in the case of "Optimized Roaming", this is based on public information currently available and could change prior to the WLC AirOS version 8.0 release.

Optimized Roaming

The problem:
The well known "sticky client" issue. For the uninitiated, when a client refuses to roam to an assumedly "better" AP (closer, stronger RSSI, better SNR etc.) that client is being "sticky". Why is this bad? Consider the following example of a lecture hall:
As the client enters the room, it associates to AP-1. As it moves farther away from AP-1 it's RSSI gets weaker, SNR gets worse, retransmissions occur, dynamic rate-shifting happens, and you end up with a client communicating at a much lower data-rate. Lower data-rate consumes more air-time to transfer the same information, resulting in higher channel utilization. Ideally, the client would roam to AP-3 and the resulting RF space would be better for everyone.

The Solution:
With Optimized Roaming, once the client reaches either a certain RSSI, Data-Rate, or both, the AP will send an 802.11 Disassociation Frame. Ideally, after receiving a disassociation frame, the client will then associate to the closer AP (AP-3 in our example). The RSSI is from the perspective of the AP. Both RSSI & Data-rate are configurable. 
If the situation were reversed and our client is leaving the building, optimized roaming can also help. If this same client, or even a less "sticky" one, were to exit the building it may still be at or around -81 for quite some time. Considering that AP-5 is in a lobby, next to glass doors, it's possible for clients to remain connected as they approach a parking lot some distance away. While they hang on to their WiFi connection for dear life, it would be a far better experience for these clients if they drop off WiFi and pick up their 3G/4G connection.

Optimized Roaming has a built-in hysteresis. This prevents "thrashing", or a client idling at or around the threshold and therefore being disassociated, re-associating, getting disassociated again, etc. By default this threshold is 6dBm. For example, if your threshold is -75, and a client gets disassociated, that client will not be able to associate (or re-associate) to that AP until it reaches at least -69. Remember, this is from the perspective of the AP.
You can use Data-rate, instead of or in addition to, RSSI. If both are configured, both must pass in order for the client to associate.

RSSI Low Check

The Problem: 
In our last example, we outlined the issue of clients leaving a building but remaining on WiFi for far too long. A related issue is that of clients who are merely walking by the building, on their way to somewhere else. They never get stronger than a -80 RSSI, but their mobile device prefers WiFi over 3G/4G. The client tries to connect, sometimes succeeds sometimes fails. Either way, it's a poor connection, at best, leading to a poor user experience. I personally experience this often; consider the following example:
The main paths of this Campus have no outdoor coverage, however bleed-over from each building is enough for a Mobile device to "try". 

The Solution: 
With RSSI Low check enabled, a clients association requests will be ignored, unless the AP hears them stronger than -80 (configurable). To be more accurate, the 802.11 Association Request will be followed by an Association Response with status code 0x0022, meaning "poor conditions". Attached is a .pcap of this occurring (with a threshold of -60 set). Here is what it looks like:

RSSI Low Check Vs. Optimized Roaming...What's the difference? Aside from configuration specifics, RSSI Low Check does not let a "weak" client connect, where Optimized Roaming actively disassociates a "weak" client.

The takeaway here is that you do not need RSSI Low Check, if you are using Optimized Roaming. Reason being: a client must pass the Data RSSI value, configured for Optimized Roaming, in order to associate. Therefore, Optimized roaming is really a replacement for, and better than, RSSI Low Check. Thankfully, it's also configurable in an RF Profile.

Why would you use RSSI Low Check? Well, for one, RSSI Low Check is available today. At the time of this writing Optimized Roaming is not (WLC 8.0 code). Secondly, I've personally not tested Optimized Roaming in a full production environment with thousands of client-types. It's possible that certain clients, upon receiving a disassociation frame, will not immediately rejoin the ESS leading to "client issues". I think that second possibility will be rare, but possible.

If, for some reason you have both Low Check & Optimized Roaming configured, both must pass in order for a client to associate. For example, if Low RSSI Check is set to -65 and Optimized Roaming is set to -75, the client must be at -65 or stronger to associate.

Receive Start of Packet (RX-SOP)

This is arguably the coolest of the three, and surprisingly, has been around the longest. In it's first form (7.2 code I believe) it was hidden. It was then unhidden (7.5 I believe) and finally with 8.0 will be part of the GUI. You can't find any reference to RX-SOP that doesn't also include something along the lines of "if you use this, beware, it may destroy you". I can understand Cisco's trepidation about releasing this to the populous. It is powerful. It is dangerous. Remember that sentence before about knowing your RF environment? Ok disclaimer over. I'd highly recommend you go read the NSA Show review of RX-SOP, by @samuel_clements and @blakekrone. They did a great job with it, including experiments & graphs.

The Problem:
High Co-channel contention & channel utilization in high-capacity environments. The rules of co-channel interference should always be followed (avoid it!), but in HD environments it is sometimes unavoidable. What results, is typically a situation where an AP is holding off transmitting to it's clients, due to CSMA/CA. More specifically, the CCA-Carrier Sense will kick off at anything above -85 for a STA (AP or Client), and the medium determined 'busy' for the time specified by the Length value of the SIG field in the PLCP Header. Further, CCA-Energy Detect will determine the medium 'busy' at anything 20dBm stronger (-65). I'm skipping over Virtual Carrier Sense (NAV) and sticking to just the PHY for this discussion. For description of both Physical & Virtual mechanisms of CSMA/CA check here, here, here or here

Consider the following crude drawing:
This presents a situation where AP-1 "could" successfully transmit to Client-1, assuming sufficient SINR, but it does not, due to CSMA/CA.

The Solution:
RX-SOP essentially takes any frame received below the set threshold and dumps it in the Noise bucket. It's been described as tuning the AP Receive Sensitivity, or applying "Ear Muffs". Taking our example, if RX-SOP is configured at -80, AP-1 does not "hold-off", because it doesn't determine the medium as "busy" due to AP-2's transmissions. As far as AP-1 is concerned, the Medium is free to use (all be it, a bit more noisy). You can see how this could greatly improve performance in the Downlink direction. 

Client behavior does not change. If a client determines the medium busy, with or without RX-SOP yields the same result (it will back-off). In other words, this does not improve the Uplink direction.
If you configure just RX-SOP, without Optimized Roaming, it is possible that a "sticky client" will fail hard. If the client does nothing (but retransmit), in the absence of any ACK's, it could take a while for it to roam. Probably not a common occurrence, but possible.
The success of RX-SOP is dependent on SINR. Your environment will determine whether, or how much, RX-SOP will help and what level it should be set to.
I can only speculate on exactly how RX-SOP is implemented. Does the determination happen at CCA-CS; the receipt of the Short Training Field (STF) in the Preamble, or is it after receiving the full PLCP Header? Or is it happening before that? Not sure, but it's been a tool in the bag for quite some time. Check the further reading section for more.

Further Reading:

Monday, August 4, 2014

802.11ac Adjacent Channel Interference (ACI)

I was reading this article on development of 5G cellular technologies when this bit on OFDM deficiencies and the need for new waveforms to support higher capacities and user densities caught my attention (emphasis added by me):
4G and 4G+ networks employ a type of waveform called orthogonal frequency division multiplexing (OFDM) as the fundamental element in the physical layer (PHY).  In fact, almost all modern communication networks are built on OFDM because OFDM improved data rates and network reliability significantly by taking advantage of multi-path a common artifact of wireless transmissions.  However as time and demands progress, OFDM technology suffers from out-of-band spectrum regrowth resulting in high side lobes that limit spectral efficiency.  In other words, network operators cannot efficiently use their available spectrum because two users on adjacent channels would interfere with one another.  OFDM also suffers from high peak-to-average ratio of the power amplifier, resulting in lower battery life of the mobile device.  To address OFDM deficiencies, researchers are investigating alternative methods including generalized frequency division multiplexing, filter bank multi-carrier, and universal filter multi-carrier.  Researchers speculate that using one of these approaches over OFDM may improve network capacity by 30 percent or more while improving the battery life for all mobile devices."

This aligns with most Wi-Fi professionals' recommendations to deploy 5 GHz radios on non-adjacent channels to avoid that dreaded adjacent channel interference (ACI). 

And if you look at an OFDM Wi-Fi transmit spectral mask, either the limits defined in the standard or using a spectrum analyzer, you will see rather significant side lobes that can impact adjacent channels (and channels even further away, depending on proximity and power levels). I have even considered including discussion of OFDM spectral masks within my 802.11ac presentations and writing due to the fact that as channel widths get wider, so to do their side lobes because the frequency distance from the main carrier signal at which the relative power level must be reduced to be in compliance increases as well. 

Here is an illustration that I put together over a year ago but never published and kept in the appendix of my 11ac presentation. It illustrates how ACI can increase due to the spectral mask differences as channel widths get larger. I have inlaid two 20 MHz spectral masks inside the 40 MHz mask, and two 40 MHz masks inside the 80 MHz mask. Essentially, the side lobe power level reduction requirements are based on the size of the main signal lobe; as the main signal lobe gets larger, so too does the allowed power in side band lobes.

Spectral Mask Comparison of 20, 40, and 80 MHz Wi-Fi Channels
And below is a capture from a spectrum analyzer approximately 10 feet away from an 802.11ac AP operating in 80 MHz mode with a large amount of traffic. Notice the high signal level in adjacent channels (52-64, and likely would impact the as-of-yet unapproved U-NII 2B band). 

Spectrum Analysis Capture of an 802.11ac 80 MHz Waveform

This is why you need a minimum of 10 feet of separation between radios operating in the same frequency band (unless other shielding mechanisms are used, which increase cost), as well as the recommendation to have adjacent 5 GHz radios operating on non-adjacent channels. This will start to become a bigger issue as we deploy more 5 GHz radios to handle capacity and user density demands. More manufacturers are considering developing software-defined radios (SDR) as well as multi-radio APs that have more than one radio operating in the 5 GHz band. You should carefully research and verify (through real-world testing) these solutions to ensure that interference within the AP is not an issue.

As always, the better you understand what's going on at the physical layer, the better wireless engineer and architect you will be. 

Happy signal hunting,