Showing posts with label 802.11n. Show all posts
Showing posts with label 802.11n. Show all posts

Saturday, 10 February 2018

Noise Floor Penalty of Wider Channels in Wi-Fi Networks

I’ve been told a number of times that although wider channels in a Wi-Fi network generally provide a higher connection speed (and hopefully a higher throughout), it comes at the cost of increasing the perceived noise floor of the client device. I thought it would be interesting to test this out for myself.

With the advent of 802.11n, it became possible to bond together the 20MHz wide channels of earlier standards in to 40MHz channels (though in reality, this was only practically feasible on the 5GHz band).

Several years later, 802.11ac enabled us to bond together even larger chunks of contiguous channels and achieve 80MHz and 160MHz wide channels on the 5GHz band. Though 80MHz channels are not feasible in many environments and 160MHz is limited to very niche scenarios, they nonetheless are options.

Theoretically, each time we double our channel width, we are going to double our connection speed and our throughput (there are some protocol efficiencies achieved which mean we may slightly more than double our throughput, but lets keep it simple).

However, each time we double our channel width, so the theory goes, we also double the amount of noise our Wi-Fi station is exposed to. I guess this is (kind of) intuitive…

So here’s a quick check using my trusty Macbook Pro:

First of all, I connected to an SSID that is configured for a 20MHz channel width and took a look at the noise floor. In this instance, the noise is reported as –98dBm:

Screen Shot 2018-02-04 at 15.11.35

Fig 1 – 20MHz channel width

Next, I reconfigured the same SSID for a 40MHz channel width. Now, the noise floor was reported as –95dBm. Our noise floor had gone up by 3dB. (Sidenote: an increase of 3dB indicates a doubling of power).

Screen Shot 2018-02-04 at 14.57.30

Fig 2 – 40MHz channel width

Then, I reconfigured the SSID to double the channel width of the same SSID to achieve an 80MHz channel width. The noise floor increased by another 3dB (i.e. doubled again), changing from –95dBm to –92dBm:

Screen Shot 2018-02-04 at 15.17.31

Fig 3 – 40MHz channel width

The observed effect fits the theory. There, that’s 10 minutes of your life you’ll never get back….but never mind, at least you didn’t choose accountancy as a profession.

OK, so why are we really interested in this anyway? Well, the other aspect to this is that if you look back at the results again,  you can see that the received signal level has remained the same in each instance, but our noise floor has crept up. Our signal to noise ratio (SNR) has gone down by 6dB as we moved from 20MHz to 80MHz:

  • Rx_sig_level – Noise_level = SNR
  • 20MHz: –54dBm - -98dBm = 44dB
  • 40MHz: –54dBm - -95dBm = 41dB
  • 80MHz: –54dBm - -92dBm = 38dB

Our SNR values are  still very good in this example, but in an environment with a higher noise floor, a 6dB difference could make a significant difference. Many higher MCS values for 802.11n and 802.11ac rely on having high SNR values for successful operation. This means that a lower SNR could, in some environments have an impact on the higher speeds that are achievable across a network.

Well, that’s pretty much it. Hope this has been of interest.

(By the way, if you wonder how I got the additional Wi-Fi connection info on the Mac, when you click on the Wi-Fi symbol on the Mac top-bar, press the ‘alt’ key at the same time to see the enhanced connection info).



Tuesday, 9 February 2016

How Fast Is My Wi-Fi Client?

In the Wi-Fi For Beginners podcast, I've spent a lot of time talking about WLAN clients. Understanding their characteristics, capabilities and behavior is crucial when designing and deploying a wireless LAN. Without understanding the clients on your network, you will not be able to anticipate their demands on your WLAN infrastructure and the level of performance that you will be able to realistically be able to provide to end users.

The discussion about WLAN clients is fairly extensive and spans a number of episodes as this is such an important topic. In the podcast I highlight the importance of understanding the capabilities of the clients that connect to a WLAN. Just because you buy yourself a nice new shiny smartphone that (you hope) supports 802.11ac, doesn't mean you are going to get 1.3Gbps of throughput when you hook it up to your Wi-Fi network. Unless you understand its capabilities in terms of 802.11 amendment support, number of streams available etc., then you can never anticipate its demands on your WLAN and the level of throughput you might reasonably expect to achieve with that device. 

However, you may be wondering how you actually find out about a clients' capabilities. In this article we take a quick look at a number of methods to determine the capabilities of devices that you may be using (or plan to use) on your WLAN.

As a an example to demonstrate the process, I took an Apple iPhone 5c and put on my detective hat to try to find out the capabilities of the phone from a Wi-Fi networking perspective. With this information, I will be able to anticipate the maximum speed I could realistically expect to achieve on a Wi-Fi network. 

MCS Rates
There's one piece of additional information we need before we start on our investigation: a suitable MCS table to cross reference our results. MCS tables are used to provide information about possible connection speeds for 802.11n and 802.11ac devices. You can find the relevant information here:


Once we discover the 802.11 amendment, number of spatial streams and channel width our device supports, we can use the MCS tables to lookup the available connection speeds for each  stream/width combination.

The table for 802.11n shows all possible MCS combinations that are available for all combinations of stream count and channel width.

The table for 802.11ac MCS table shows the available connection speeds for a variety of channel widths, but only for a single spatial stream. To determine the connection speed for a multi-stream device, simply multiply the data rate value for a single stream by the number of streams the device supports.

Two important caveats:
  • the capabilities of your client device must be matched by your WLAN access points - if your access point doesn't have equivalent (or better) capabilities, then you will be limited by the speed capabilities of the access point (e.g. an 802.11ac client device is never going to give you gigabit Wi-Fi if your AP only supports 802.11a)
  • Although we may determine the maximum connection speed of a client device using the methods outlined in this article, please remember that this is the RF connection speed of the device, NOT the data throughput of the device. The actual device throughout is likely to be closer to 50% of the RF connection speed that we discover, due to the half duplex nature of Wi-Fi connections and various other overheads inherent in the WLAN protocol.

Manufacturers Documentation
The most obvious place to start when trying to understand the capabilities of a client device is the vendor documentation or web site of the client that we're investigating.

Unfortunately, the information provided by many support pages is lacking in any real technical real detail. Sure, you may get information about the WLAN bands supported and the headline 802.11 amendment information, but there is generally little low-level detail for items such as channel width support, guard interval support and number of streams. 

Here is the information I was able to find on the Apple support pages for the iPhone 5c:


We can see from the support information that the 5c operates on the 2.4GHz and 5GHz bands. It also supports all 802.11 PHY amendments up to 802.11n. But, without knowing its channel width support and the number of streams it can support, we have no understanding of the maximum connection speed we might achieve with this device on our WLAN.

Although this is useful information, it provides only part of the answer we are seeking.

Wi-Fi Alliance (WFA) Product Finder
A great place to find detailed information about wireless LAN clients is the Wi-Fi Alliance Product Finder. (https://www.wi-fi.org/product-finder)

As many WLAN products are certified to verify their interoperability with various 802.11 amendments, WFA interoperability certificates are a great source of data about WLAN clients.

The Product Finder tool allows you to enter details about the device you'd like to know more about, and will (hopefully) allow you to find the WFA certificate for the device you're investigating.

For our investigation I hit the jackpot for the iPhone 5c by looking at its WFA certificate. I've shown a couple of screen grabs of the type of information you can find on the WFA certificates, highlighting the pertinent information:



Although the first part of the certificate shows us very similar information to the support page from Apple, the second page shows us the number of spatial streams the 5c supports, channel width support and guard interval support.

The 'guard interval' gives a small, but useful, bump in performance if we have short guard interval support. It's nice to have, but to keep things simple, we'll focus mainly on channel width and spatial stream capabilities in this article.

We'll have a look at the end of this article at how we determine our maximum connection speed from the information shown above.

FCC Web Site
Unfortunately, not all devices go through the WFA certification process so may not appear on the WFA product finder. There may also be a time-delay between devices being released and obtaining their WFA certification.

Another alternative is to take a look through the FCC ID database (https://fccid.io/).

Each wireless device that is used in the USA must be tested to ensure that it meets various RF-related requirements before it can be used. The testing that is conducted by the FCC on each type of device is recorded and made available as s series of documents on a searchable database. To find the test documentation, you need the FCC ID off the device. In the case of the iPhone 5c, I simply read it off the rear of the iPhone's case: BCG-E2694B 

I then typed the ID in to the FCC search form:


When the search results are returned, the number of results can be a little overwhelming, There are a whole series of documents that cover different aspects of the device's operation and testing. To find documents that will most likely be of interest, look for documents that are  in the 'Available Exhibits' section and are listed as 'Type': 'Test Report'.

Looking through these documents can take some detective work and is certainly not as easy as the WFA product finer. There are test documents for different RF bands and technologies, so finding what you need takes a little digging. However, there is also some very interesting information buried in there about how the devices are tested and other aspects of the devices performance which are fascinating. 

As an example of what I turned up in a very short space of time, here is a table I found in a test document for the 5GHz band. It shows me that the on 5GHz band we support the 802.11n amendment, 20 & 40 MHz channels and that there is single spatial stream support (SISO = single inout, single output). You can see the document yourself here: https://fccid.io/document.php?id=2841731



With a bit more time spent digging around I could also find the 2.4GHz information and various other aspects of device support if I need them. I'll leave this as an exercise for you, the reader, to complete :)

(Side-note: have a look through the FCC documents - there is some fascinating information in there)

As the testing is completed by the FCC, it obviously relates to operation within the USA. However, many aspects of a devices capabilities will apply across the globe. One area that will be significantly different from country to country is the channels used on the WLAN RF bands (i.e. the same channels may not be available for use or be subject to the same power restrictions) - remember this when reviewing the FCC report data.

(Tip: Check out this page for Apple devices, which has direct links to FCC documentation)

Controller or Management System Information
Another potentially useful source of client capability information is the wireless LAN controller(s) or management system that runs your WLAN network.

Many systems will provide good information about clients that are associated with your network. If you can attach the client to your network the you may be able to inspect its properties to understand its capabilities. The type and quality of information will vary form system to system. Again, some detective work my be required to find the information you are seeking, but it's likely to be buried somewhere on the system GUI or in some CLI output.

As an example, I associated the iPhone 5C with a test SSID on a Merkai AP I have in my lab. I took a look a the client information that was available for the iPhone from the Meraki cloud management GUI. You can see the partial output in the screen grab below (pertinent information is highlighted):


The Meraki dashboard does a good job of showing us that we have 802.11n support on the 2.4GHz & 5GHz bands. It also shows that we have 40MHz channel width support and that the client supports one spatial stream.  It also shows us that the maximum connection speed is 150Mbps, which is what we could expect when using a single stream device with a 40MHz channel width. The only area that this falls down is that it is unlikely that the iPhone supports 40MHz channel widths on the 2.4GHz band (which could be inferred from the information shown).  

Wireless Packet Capture
Another way to understand the capabilities of a client device is to capture a few frames from the device and to look at some of the fields in an Association Request frame that is sent from the client to an access point. This method is quite tricky to complete in terms of both technical complexity and interpretation (but is more fun for most geeks).

To capture the required frames, you need a wireless NIC that can operate in monitor mode to capture all frames heard over the air on a partticular channel. Getting hold of a suitable NIC and drivers can be very challenging. If you have a commercial product such as Omnipeek or AirMagnet Analyzer, then this is a trivial task as they are built to perform this type of capture. However, it you don't have access to these tools, then you can use a MacBook with its native NIC and Wireshark, or on Windows you might like to try a trial version of the Acrylic wireless analyzer. There is no doubt support wireless capture in various Linux flavours, but you'll have to rely on Google for help with that :) 

(Side note: Windows support for wireless NICs that can be put in to monitor mode is very rare, making wireless captures very difficult on Windows for free tools such as Wireshark).

You can generally capture an association request by connecting the iPhone to the target SSID while having your analyzer configured to capture frames on the target SSID (AP) channel. Then, you can filter out the Association request frames with the Wireshark filter 'wlan.fc.type_subtype == 0x0.

A sample frame is shown below for my iPhone 5C on the 5GHz band (remember capabilities may vary between bands):

Understanding the frame and interpreting its content requires some background knowledge of WLAN frame analysis, but is very interesting if you're a real geek :) (and its' a GREAT way to learn more about WLAN technology - if you want to know more, get hold of a copy of the CWNP CWAP certification book - new version coming out first quarter 2016).

Looking at the example above, as we have HT capabilities, then  by implication, this is an 802.11n device. In the HT capabilities fields, we have indications that 40MHz operation is supported and that the device uses a single spatial stream. The eagle-eyed among you may also spot that Short Guard interval is also supported (HT Short GI for 20MHz: Supported).

From the frames, we can deduce the same information that we saw in the WFA certificate. It's harder to find this way, but a lot more fun :)

Google
The last port of call, I guess, is to Google for the information. In my experience, this won't usually turn up much beyond the usual marketing data sheets, or vendor support page. But, give it a try of all else fails :) 

Converting Your Data In To Maximum Connection Speeds
Once you've obtained the required data from your Internet sleuthing, it's time to run the data through the MCS rates table we spoke about earlier, to determine our theoretical maximum connection speed.

We determined that our capabilities on 5GHz were: single stream, 40MHz channel and short guard interval support. If we take a look at the 802.11n MCS table we come up with the following when determining our maximum connection rate:

Note that this is an extract from the table - there are also values for 2, 3 and 4 spatial streams in the full MCS rates table. We can see that the maximum connection speed we can achieve with our 802.11n device supporting a single spatial stream, a 40MHz channel and the short guard interval is 150mbps. Remember, this is the RF connection speed of the client to the access point NOT ,the throughput speed of the client (which is likely to be closer to 50% of the RF connection speed)

You may be wondering a few things when looking at this table:

  • What are all those other values below 150bmps? These are other data rates available for use by various combinations of modulation type, channel width and guard interval. Although we have determined the maximum connection speed, as your client physically moves around and factors such as signal level and error rates vary, the rate used may drop to suit the conditions that a client experiences. Remember, we have determined the theoretical maximum rate a client can achieved, not its guaranteed data rate on your WLAN.
  • What about old clients that only support 802.11b, 802.11g, or 802.11a? MCS rates only apply to 802.11n & 802.11ac clients. The maximum for 802.11b clients is 11mbps and 802.11a & 802.11g have a 54mbps maximum connection speed.
  • What are those 800ns GI and 400 ns GI figures? 800ns is the long guard interval, 400ns is the short guard interval.

Hopefully you'll now have enough information to know how to find the maximum connection speed for most devices that you'll hook up to your wireless LAN. Don't forget that for 802.11ac devices you need to check out the rates in the 802.11ac MCS table and multiply the rate for your device by the number of streams that it supports. Also remember that the physical rate you derive using the information above is not the throughput rate of the device (you need to assume around 50% of the physical rate). Finally. remember that the rate we have looked at in this article is the maximum rate - the actual rate your client will achieve will vary with the RF conditions it experiences in your environment.

If you've found this article useful, you might like to check out my Wi-Fi For Beginners Podcast.


Feedback
When I post a new blog entry, I often get some great nuggets of useful feedback. I'll post any useful items here:
  • Excellent reference for Apple device Wi-Fi capabilites from Henry Stukenborg on apple web site: http://help.apple.com/deployment/ios/#/ior65f75e248
  • Great site for Apple device FCC docs (thanks for the tip Scott McDermott): https://www.theiphonewiki.com/wiki/Models




Monday, 8 October 2012

The Missing Channels on 5GHz in the UK : 120, 124, 128

In my recent article : 'WiFi Channels On The 5GHz Band In The UK', I noted that although the 5GHz channels 120, 124 and 128 are unlicensed channels available for use by WiFi equipment in the UK, it appears that a few major WiFi equipment manufacturers do not allow their use (in the UK or EU).

I spoke with a major vendor representative today who advised me that the 3 channels are available for use, but that an update to the ETSI standard 301 893 v1.5.1 introduced some detection techniques for various military equipment used in the EU. However, many access points that were already manufactured (or using chip-sets that had already been manufactured) did not support the granularity of detection that is required for this equipment. So, it was decided to simply disable support for the affected channels.

Apparently, later APs which use an updated chip-set will not be subject to the same limitations (once a few firmware updates are sorted out).

I had a poke about in the standard to see if I could track down the offending addition, but there didn't seem to be a "what's new" or "change log" that accompanies the document. All I could find was the following note in the ETSI work program item that accompanies the standard:

"Include Staggered PRF radar test signals across the 5 250 MHz to 5 725 MHz band. Include narrow pulse widths for the radar test signals (0,8 ┬Ás) across the 5 250 MHz to 5 725 MHz band. Address noise calibration scan ("zero check") in the 5 600 MHz to 5 650 MHz band."

Perhaps the "zero check" scan that is referenced is the offending item that caused the issue - it certainly falls within the range of the channels that have been disabled.

Although this doesn't provide a comprehensive answer, it at least suggests why we have lost a few channels on 5GHz here in the EU (at least for the moment, anyhow).

UPDATE: I now have an answer on this! Check out my later article here.

Update: I've now created a white paper which details 5GHz usage for WiFi in the UK. Find it here

Sunday, 23 September 2012

Which 5GHz Channels Does My Device Support?

I've been on a bit of a 5GHz quest recently, trying to get to grips with all of the nuances of supporting WiFi devices on this rather (in my mind) troubling band.

Until fairly recently, it seems that the default band of choice for many WiFi devices has been 2.4GHz (802.11g/n). But as the whole 'bring your own device' area has exploded, networks require more high-density deployments, 802.11ac is on the horizon and consumer grade devices are starting to support 5GHz in increasing numbers, it looks like 5GHz is going to transition to being the band of choice over the next year or two.

However, there seem to be a number of considerations that need to be taken in to account when delving in to the 5GHz 'wonderland'. There are far more non-overlapping channels available (19 in the UK) compared to 2.4GHz (generally 3 channels), which is going to potentially deliver much better performance gains (with the mitigation of co-channel interference, lower noise floor etc.). However,  terms such as 'DFS' and' TPC' start to crop-up and a myriad of channel usage restrictions across the band need to be understood (e.g. indoor/outdoor use, varying power levels, varying DFS support etc.).

As if this isn't enough, I was recently warned of the dangers of ensuring that client devices support all of the 5GHz channels that you intend to use. I must admit that my assumption (until recently) was that if a device supports 802.11a/n, then it will support all of the channels that are dictated by the local  regulatory authority (e,g, FCC, ETSI etc.). But, apparently not...

I'm not sure how extensive the lack of support for all available 5GHz channels is among 802.11a/n devices, but it is certainly a consideration when designing WiFi networks that use the 5GHz band (I am reliably informed). I'd be interested to know if this issue is only applicable to older devices, or is due to device assumptions about their regulatory domain - drop me a comment with your experiences/knowledge!

I fired up a couple of devices to check their support for 5GHz channels as a bit of an experiment. I have an iPad 2 and a Galaxy S3 phone, which both support 5GHz.

My initial thought was to fire up my test AP on channel 36 and test both devices to verify they can associate to a test SSID. Then I would move on to channel 40 and check again. Checking each of the channels supported in my particular part of the world, I could verify if all channels are in fact supported by both devices.

However, I had a WiFi analyzer to hand and was capturing a few frames to see what was going on during my testing. Luckily, I spotted some capability fields in the association request of each device which really helped me out. In the association frame there are 'supported channels' fields that show which 5GHz channels the client device supports. This is exactly the information I needed to know!

I've posted a couple of screen shots below to show what I saw using a WiFi analyzer:

Fig. 1 - iPad 2 Association Frame

Fig. 2 - S3 Association Frame
In each association request, you can see the supported channels for the client device. It's a bit tricky to read on first glance, but if you look carefully, you can see the start of a channel range (called 'First Channel') followed by the number of channels in that range.

Looking at the iPad frame, we have channels 36, 40, 44, 48 (first channel - 36, num of channels = 4), followed by channels 52, 56, 60, 64 (first channel - 52, num of channels = 4), followed by 15 other channels (see frame detail). This gives the full 23 channels you might expect in the USA, but is actually more than we can support here in the UK!

The S3 supports just the 19 channels we have available here in the UK. I'm guessing this is because it is manufactured specifically for Europe.

Looking at these frame captures, we shouldn't have any issues using these here in the UK, using all 19 channels we have over here on 5GHz, if we wanted to use them.

It's certainly worth checking your devices when planning to use them on a 5GHz WLAN, just to be sure you don't have clients that  only work on a subset of the channels you intend to use on your WLAN (which could obviously cause connectivity issues to some clients).

If you don't have a wireless analyzer to do this investigation, it might be worth checking out running Wireshark on Linux. You can sometimes find a wireless NIC card that will run with a Linux distribution in a promiscuous mode, so that it can capture frames. I recently downloaded the latest copy of the Backtrack distribution (the penetration toolkit) and found that the built-in wireless NIC in my Dell laptop is now supported (a nice surprise!). I can run the Backtrack distribution by booting from a USB stick and use it as a great wireless analyzer (Wireshark is part of the distribution) - I don't have to disturb the main OS on my laptop at all.

Anyhow, as I said, I'd be interested to hear of other folks experiences with client support on 5GHz. Drop me a comment if you can.

Nigel.

Related Post: Which iPads Are on the Network?