Effect of CCI on MCS rates in WLAN Clients

With knowledge comes more questions, and thus the desire for more knowledge to answer those questions.  No, that’s not a quote from a famous person (at least not that I’m aware of) but one that I thought of recently during my studies in pursuit of my CWNE.

It would seem as though based on reading various posts from WLAN professionals that the topic of CCI is one that many times opens a proverbial “can of worms”. I began to realize the very real effects of this, even in a small environment (my home), a few weeks ago when I noticed that my laptop was no longer connecting at the blazing speeds previously noticed in my lab. The original behavior was my laptop was connecting at MCS 9 and a data rate of 1300 mbps while running 80Mhz channels in my environment with no outside interference on either channel. Instead, my laptop was only showing a connection of MCS 5 & a data rate of around 780 mbps. Upon digging, I discovered that my WLAN at home (Aruba Networks AP-225s, Aruba 7010 controller) decided to place both access points (APs) on the same channel.

Disclaimer: Before we get too far along, this is not a discussion about RRM/ARM/whatever your vendor calls it. It just happens in this scenario that ARM can be blamed for causing this curiosity with regards to how CCI affects the MCS rate that a particular client utilizes.

First, lets get some necessary definitions out of the way for those that are less familiar with terms we professionals use often.

  • RSSI (Signal) – stands for Received Signal Strength Indicator and is different for virtually every client even if in the same position/environment and even if the clients are identical. With no way to calibrate the WLAN chip, this is pretty much the worst possible value to base a network’s success/failure on.
  • Noise – the value that a WLAN chip associates with an observed level of non-WLAN energy or WLAN energy too weak to be decoded. Think of this as the ambient room noise in a large crowd, where you can’t understand what is being said, but you know people are talking and other environmental factors like air conditioners are running. Again, this number is different for every client and is sometimes referred to as the “noise floor”.
  • SNR – (Signal to Noise Ratio) this is one of the most important values that a WLAN professional will use when designing & measuring the success/failure of a WLAN and as the acronym implies it’s a ratio of the WLAN chip’s measured RSSI to the Noise Floor.
  • CCI – (Co-Channel Interference) is probably best described as the impact on the environment when two APs on the same channel are placed near enough to each other, that the operation of either AP impacts the ability for the other AP (or associated clients) to transmit. CSMA/CA Explained It is important to note that this impact can also be induced by client activity as well as mentioned in Tom Carpenter’s blog here
  • MCS – (Modulation Coding Scheme) simply put this is how fast the client can transmit data on the WLAN. For a better understanding, you can refer to this chart and associated info (posted on the WLAN professionals site via Andrew Von Nagy’s blog post from 2014) MCS Table

Now that that’s out of the way, lets get to the meat of the article.

As you will see in the images below, the metrics for the client being tested were virtually the same for both the APs on the same channel and APs on different channels. The key value to look at here is that the SNR of the client in both cases was identical. This is important as SNR plays a pivotal role in what MCS rate a client can use. These values were measured over a period of several minutes and held steady at the values pictured.

Same_CH_MCS

Same Channel MCS

Diff_CH_MCS

Different Channel MCS

Now this made me even more confused. How is it possible to have the same client, in the same test position, with the APs in the same position, yet get different data rates with only the AP’s operating channel being manipulated? To try and create a level playing field for this test, I made sure to limit as many variables as possible. This included making sure that no other energy was detected on the channels used during the test via SpecAn as seen in the Wifi Explorer images here:

Same_CH_Spec

Same Channel Spectrum

Diff_CH_Spec

Different Channel Spectrum

My theory was that the reason for the difference in MCS rates between these tests was due to CCI and that is shown by seeing lower connectivity when testing on the same channel. The reason for this is that the interference domain is greatly expanded with APs on the same channel.  Since we now have more devices attempting to communicate simultaneously, the amount of wireless energy in the environment is greater and clients will have a tougher time when attempting to transmit on the medium. We go more into this “game” in one of my other blog posts, Playing the Game. You can read more about the effect of CCI on MCS in the paper by Kriara, Marina, and Farshad, University of Edinburgh, page 7 “C. Differentating Interference Types”. They do a great job of explaining their test scenario and how they were able to measure the affect of CCI on MCS rates.

When professionals design WLANs, what we strive for is keeping the amount of CCI as low as possible (this also applies to ACI – adjacent channel interference but we will save that topic for another posting). By keeping APs on different channels we increase the amount of capacity in the network, in this case we are referring to the amount of data (not necessarily clients) that the network can handle. However, please keep in mind that a CCI value of zero in many environments is simply not possible. This is typically seen in VHD environments, but can also be seen in places like apartment buildings in metropolitan areas where there is no coordination between tenant APs and the channel they choose to operate on.

The closing argument is very simple. When designing a WLAN, pay special attention to what your channel plan is in your environment. While large networks can cause pain within the implementing engineer due to the shear number of APs to manage, RRM/ARM isn’t always the best approach. Break the network up into smaller pieces to make implementing the correct channel plan easier. However, note I’m not saying don’t use RRM/ARM, simply be vigilant of the parameters that it is implemented with. ALWAYS remember that NOTHING out of the box will operate in a way that gives you the best network possible.

I welcome your feedback.

-Scott

While many products were mentioned in this article, please note that all opinions are of the author and no compensation was received from any vendor mentioned.

Title graphic courtesy of Divdyn.

4 thoughts on “Effect of CCI on MCS rates in WLAN Clients

  1. I don’t want to suggest that the issue is NOT due to CCI however I think you’d really need to get into the head of the driver to be sure of the reason. Whether this is possible (perhaps on OS X or a *nix system you can pull this out of client debugs or something?). Personally, I wouldn’t think it’s CCI causing the issue. The client should be listening for it’s turn to transmit and this shouldn’t cause an increase in retransmissions unless hidden node is at play (or near far, etc). That wouldn’t be a factor here though.

    I may have missed it but you didn’t go into detail about if the laptops were just sitting there idling.. this will mean the CCI from a practical perspective (channel utilisation) is almost non-existent. When I see big jumps in MCS rate I tend to think that its due to different SS’s being used for different frames. Either way, a packet capture may reveal more info.

    CCI is an issue but it’s overblown in many cases; yes minmising channel reuse should be a priirity but real WLAN throughput is far lower than most people expect.

    But I could be way off of course!

    Like

    • The likelihood of hidden nodes in a CCI environment are pretty high I would say. If clients can (or should) lower their MCS rate when they fail to receive an ACK, then hidden nodes would definitely cause the potential for retransmissions and thus clients to decrease their MCS.

      I’m curious as to why our say hidden node wouldn’t be an effect here (assuming you mean this particular test)?

      I wanted to make sure that the testing was done in as close to a real world scenario as possible. Some details about the test environment:

      -The environment is my home with the 2 APs at opposite ends of my home on different floors with spacing horizontally about 65′ & vertically 12′.
      -There are normally about 20 devices associating in the 5Ghz spectrum, and I usually get pretty good balance between APs due to where the devices are sitting.
      -All clients (including devices evaluated) were stationary during the test.
      -To ensure that I didn’t see strange MCS shifts due to traffic patterns (or lack of it), both APs had MacBook Pros associated and downloading a 10GB file and streaming video from Netflix.

      Like

  2. Interesting blog post; really well written! I’m not entirely sure i agree with the analysis though… I always think of CCI as “Co-Channel-Co-Operation”; that is, a client deferring transmissions when it hears another client/AP talking on channel. In that scenario client B would not reduce client A’s MCS as it’d just be an idle observer. Where client B transmitted at the same time from a long way away, then it might be received at a low enough RSSI to allow client A to transmit – although with a higher noise floor (A’s transmission, received as can’t-demodulete-this noise); reducing effective SNR and therefore, possibly, MCS rate.

    PS. Good job ARM! 😉

    Liked by 1 person

    • I’m thinking that your scenario B is what is the culprit here since the AP are tuned to just enough power to barely overlap. I think I have an Aircheck G2 test taken during this and will see if it can see both clients or not. The Aircheck measurements were taken at the same location as the measurements shown in the post. Only concern is that with the Aircheck being way more sensitive, it’s data might only be of marginal value since the clients still might not be capable of seeing each other causing a hidden node to be present.

      Thanks for your comments! They help me ensure I’m applying the knowledge correctly.

      Like

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s