The Importance of Signal-to-Noise Ratio

You have likely heard about Signal-to-Noise Ratio, or SNR, many times when working with Wi-Fi.  I find that it is one of the most common subjects I discuss with other Wi-Fi professionals, as well as when educating people new to Wi-Fi (or those who have configured and deployed Wi-Fi many times but are learning more about the fundamentals of 802.11).

I feel it is the most important metric in terms of measuring Wi-Fi connection quality, and the best indicator of expected end user experience.  So many aspects regarding the operations of Wi-Fi relate to SNR.  So, let’s take a look at some important considerations.

What is SNR?

SNR is an easy ratio to consider, however many don’t understand the Noise part of the equation.

Signal – this is how strong your wireless client is receiving Wi-Fi signals from access points.  It is commonly referred to as Received Signal Strength Indicator (RSSI), but more accurately called Received Channel Power Indicator (RCPI) in 802.11.  I won’t go into the specifics of RSSI vs RCPI here, perhaps a post for another day, however remember that all wireless clients receive signal differently, and some give you a measurement as a percentage and some as dBm (i.e. -65dBm).

Noise – this is actually a measurement of the noise floor, which consists of all other energy and signals on the spectrum that you aren’t trying to receive.

Tom Carpenter (@carpentertom CTO of CWNP, and a great contributor to the Wi-Fi community) has a good explanation of noise floor on his blog here.  Many people forget, or don’t realise, that the biggest contributor to the noise floor is your own, and other, Wi-Fi networks and devices.  This is in addition to non-Wi-Fi interference on the spectrum, such as radar and microwave ovens.  I recommend checking out two Ekahau webinars I presented on co-channel interference and spectrum analysis.  This will help your understanding of what contributes to the noise floor.  Noise floor is also measured in dBm.

The Formula

Here is the easy bit:

Signal – Noise = SNR (in dB).  Typical examples indicate a signal strength of -67dBm and a noise floor of -92dBm, and punching that into the SNR equation gives a result of 25dB; which is a typical minimum SNR requirement for many wireless LANs.


The Biggest Influence on SNR?

How do we aim for a high SNR?

  • High AP transmit power?
  • Well-designed coverage?
  • Standardised end user devices with good receive capabilities (i.e. multiple spatial streams and modern radio chipsets)?
  • Minimising CCI?
  • Reducing or eliminating non-Wi-Fi interference?

These factors are most certainly important, and should all be considered in a good wireless LAN design.

However, many of the elements above can be outside of our control as wireless engineers.  Wireless devices of the same make and model can have variations in received signal strength between them, and additional Wi-Fi and non-Wi-Fi interference can enter your environment at any time.

Do you know what the biggest influence on SNR, and the factor that is most in your control as a wireless engineer, is? CHANNEL WIDTH!

Channel Width

Channel widths are in your control, and they are easy to configure (and misconfigure!) and have a big influence on your SNR.  Want to know how much impact channel width has on your SNR?  It is a factor of TWO!

Every time you double you channel width, you double the strength of your noise floor!

20MHz -> 40MHz -> 80MHz -> 160MHz… the noise floor of a channel set to 160MHz is 9dB, or 23 ! Hint: if you need a refresher on dB math, check this out.

Don’t believe me?  Check out Nigel Bowden’s (@WifiNigel)  awesome blog post illustrating the increase in noise floor each time channel width is doubled!

So, this is how you can have a drastic impact on the SNR your clients experience in your environment.

SNR and Data Rates

SNR is a big influence on the data rates a wireless client can experience, as it impacts the modulation and coding efficiency that can be achieved given some other key factors (number of spatial streams, guard interval length, channel width).

To see the impact I highly recommend this excellent resource by Keith Parsons (@KeithRParsons Director of Wireless LAN Professionals and ECSE instructor): MCS Index charts for 802.11ac and 802.11n.  Note from the page: “these are not ‘absolute’ numbers – but an amalgamation of data from a variety of sources.”  So different Wi-Fi adapters might report different SNR and RSSI for a corresponding MCS Index.


You’ll quickly see how SNR influences data rates, and why you can’t always get what the vendor states on the box/datasheet.  I reference the 802.11ac chart several times a week, and always when I am running a training session.  Remember: a vendor default (of 80MHz channel width) isn’t always a vendor recommendation!

SNR is also a metric used by some client devices to determine roaming behaviour.  RSSI/RCPI, noise, and data rate can also be used as metrics; so you can understand how this relates back to ensuring your design your environment properly for high SNR.

I recommend watching another Ekahau webinar I presented on Real-world Wi-Fi Data Rates vs Throughput:

It covers the fundamentals around SNR and MCS rates, and illustrates how you can simulate the impacts of channel widths in your environment using Ekahau Site Survey.

Monitoring Data Rates

There are multiple methods of monitoring the data rates your wireless clients are experiencing from the wireless LAN infrastructure side.  If you’re a Mac user then you should get onto a series of excellent Wi-Fi tools created by Adrian Granados (@adriangranados) which you can find over at his website.  These include WiFi Explorer (live scanning and analysis of Wi-Fi beacons), Airtool (Wi-Fi packet capture), and WiFi Signal.

WiFi Signal allows you to monitor various metrics and statistics of your current Wi-Fi connection including frequency, channel, channel width, signal strength, noise, SNR, data rate, and MCS Index.  It is fully customisable and sits in your toolbar and provides live updates of the connection.  I like to set mine to show MCS, RSSI, and SNR so I can gauge the quality of the connection over time.  You can expand the view to see further details.



If you are using channel widths wider than 20MHz, please make sure the usage is justified and won’t negatively impact your wireless client’s performance.

With 802.11ax around the corner, SNR is going to be even more critical when you’re attempting to achieve 1024QAM modulation and understand different characteristics of how the 802.11ax PHY operates (OFDMA/resource units/subcarriers & tones).  It is best to be prepared now with the understanding of how SNR influences these elements, and how SNR is impacted in today’s Wi-Fi environments.

Keep an eye out in the wireless community for new and updated information around 802.11ax, and also check out the resources I posted here:


6 thoughts

  1. Nice article, but you two things are not really consistent.
    You mention that each time you double the channel BW you add 3dB to the noise floor, right? And then, this table contradicts that statement – lets take the first row, MCS0, and calculate the Noise. (N=RSSI-minSNR) -82-2=-84, -79-5=-84, -76-8=-84, -73-11=-84. All of the noise values and up at -84dBm.
    So, which one is true?

    Liked by 1 person

    1. Hi Karol,

      Excellent question – and great observation!
      As Keith mentions in his page that I link to: “Note, these are not ‘absolute’ numbers – but an amalgamation of data from a variety of sources.”

      So these could have been measurements of RSSI/SNR with a different noise floor than -84dBm and even a different wireless device. I stick to SNR as advertised by my Macbook Wi-Fi adapter and WiFiSignal as metric that the MCS Index is based on. The great thing about these tables is it correlates MCS Index and data rate.

      I’ll update my paragraph a bit.




      1. Hi Stephen,

        Thanks for a quick response.

        You are right, of course, the noise doubles(+3dB) as you double the BW – this is correct.

        That would mean that the table is incorrect. And it kind of is. The thing is that the wireless clients tend to report the noise for the primary channel, i.e. always 20MHz, which is what the table shows – noise always at 20MHz and signal at varying BW. This leads to SNR requirements going up 3dB each time double the BW for a given MCS, which is nonsense. The given MCS would require the same SNR, regardless of the BW. But again, reporting the noise always at 20MHz simply skews the whole thing. So the table is wrong in a sense that it does’n inform you that the noise values are 20MHz only, whereas the signal BW changes as given in the respective columns.

        Sorry for coming at you like this. This table, in different versions, has been circulating for years now, I believe it originated from Andrew and now Keith. Nobody seemed to have looked at the Noise or SNR aspects, the table has been simply copied countless times without giving it a thought. And I just couldn’t hold anymore:-) hope you don’t mind.

        Best regards,

        Liked by 1 person

      2. Hi Karol,

        I think Andrew covers some of that in his original post ( aside from the noise at 20MHz part? My understanding was clients report noise for the whole channel width, can you provide any further information? Keen to know more!

        No problems on regarding the comments, I appreciate the feedback as there is always something to be learned! And it encourages discussion 🙂




      3. Hi Stephen,

        Nice discussion. Well, most of the clients nowadays would not let you know the noise value at all:-) And those that report the noise don’t explain how, so I don’t have any hard evidence on that. I would think that the OFDM preamble (20MHz, regardless of the payload BW) would be a good moment to measure the noise, it’s just simpler this way, in HW. Often the noise is attributed to a given channel, say the noise on channel 40 (a 20MHz channel) is this or that. But if an AP on channel 40 sends say 80MHz wide packet it begins with 20MHz preamble, where both N and S are measured, then the payload where the signal would be spread over 80MHz. So, no evidence, just a common sense and practicality. is also based on the same assumption that noise is 20MHz limited but the signal is not. Look at the SNR requirements for different 11ac BWs – they change. +3dB for each BW doubling. Again, the required SNR for a given MCS should be constant, regardless of the BW but is not if you look at both of those tables.

        The requirement for Signal should change, +3dB if you double the BW because you open up the receiver and get double the noise, +3 dB on the N part. But SNR requirements should remain constant.

        Consider a thought experiment, look at the first table you mention in your blog where MCS0 for 20MHz requires only 2dB SNR. According to the table doubling the BW calls for +3dB SNR. Now, if we could use smaller channels, halving the channel should call for -3dBm required SNR (following the same logic), right? So what do we get: -1dB req. SNR for 10MHz channel or -4dB for 5MHz channel or -7dB for 2.5MHz channel and so on. I’d like that, I’d like to be able to get those values. Unfortunately they are not quite right.. again, the problem comes from the BW discrepancy for N and S measurements.

        Best regards,


      4. Hi Karol,

        That makes total sense. I haven’t really paid much attention to the SNR and RSSI values in the tables, aside from noticing we require higher SNR to achieve a higher quality connection for tighter constellations and less errors e.t.c.

        Whenever I have been working with Ekahau and teaching people, it is easy to illustrate the noise floor doubling but still maintaining the same requirement of say 30dB SNR. And whenever I have referenced the 802.11ac MCS Index table I have been referencing the MCS Index and data rate indicated by WiFi Signal at the time. You are correct – it doesn’t make sense that the SNR requirement should increase by 3dB, but it does that the signal should.




Leave a Reply to Karol Cancel reply

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

You are commenting using your 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 )

Connecting to %s