Showing posts with label 802.11ac. Show all posts
Showing posts with label 802.11ac. 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




Tuesday, 27 January 2015

5GHz in the UK White Paper (Version 2)

[Note: The information in this white paper has been superseded. Check out my updated white paper: http://wifinigel.blogspot.co.uk/2018/05/updated-white-paper-on-license-exempt.html]

I decided it was time to update my white paper detailing the use of the 5GHz band here in the UK for wireless LANs.

I've tidied a few things up and added some information around 802.11ac channel planning within the constraints of UK 5GHz spectrum.

You can download the whitepaper from here:

  • PDF download
  • Google docs
  • Scribd

Thursday, 15 May 2014

802.11ac & 5GHz: The Emperors New Clothes? - Part 3


After previously looking at the challenges we may face with 802.11ac due to the restrictions of the 5GHz band (see part 1 and part 2 of this series), in this final installment, I suggest how we may mitigate the challenges we may face, together with a possible (but no doubt controversial) solution.

The Solution?

I'm not aware of any "magic bullet" to solve all of the challenges outlined in this series of articles (sorry). More spectrum will certainly help things. But, time-scales for the allocation and adoption of new spectrum are not clear at this point in time, though many agencies around the world are considering ways to free up more spectrum to improve WiFi capacity.

Though spectrum may become available in relatively short time-frames, there will still, no doubt, be a significant time-lag before this permeates through in to the world of vendor and consumer WiFi products (remember the issues raised around UNII-2e support?) 

The best way to mitigate the issues discussed in this series of articles is through:
  • a thorough understanding of the clients that will be using a wireless LAN - for instance, do they support UNII-2e/DFS channels, do they support 802.11ac, how many spatial streams do they support, what channel widths do they support?
  • careful planning of the channels to be used throughout a facility, taking account of channels used, channel widths and DFS considerations
  • a good wireless design/survey taking account of channel planning and co-channel interference/contention - this is more important than ever!
As I said, there's no magic bullet - just careful consideration of the points raised in this series of articles, which ends up being a series of carefully planned compromises due to the challenges that 5GHz presents.

Many of the points raised in this article have been an issue since the introduction of 802.11n, with it's 40MHz channels and the increased emphasis by vendors and manufacturers on 5GHz. However, there is now even more focus on the 5GHz band (specifically) with the introduction of 802.11ac. I'm still surprised how many people who I speak to who are still unaware of the 5GHz band for WiFi usage, so there are plenty of folks who are still new to all of this information.

Many folks have likely adopted default settings for their WiFi equipment without really giving too much consideration to channel planning. Many will have accepted a default of perhaps 8 x 20MHz channels operating on channels 36 - 64, which has worked just fine for them. With the advent of 802.11ac, this approach no longer suffices - more thought and planning is required if the true benefits of 802.11ac are to be realized.

To wrap up this discussion, 802.11ac is not simply about a wholesale migration to the 5GHz band to deliver ubiquitous Gigabit WiFi connectivity for your organisation. It requires careful planning and consideration (despite what the marketing boys may tell you).

Depending on your client devices and attitude to (DFS) risk, you will be somewhere on a spectrum of marginal improvements over your existing WiFi solution, to amazingly fast WiFi. To quote a well know policeman: "...you’ve got to ask yourself one question: 'Do I feel lucky?' Well, do ya, punk?"

An Alternative?

There is an alternative approach that I would not be surprised to see some manufacturers start to more seriously consider: single channel architecture (yep...there, I said it).

In a single channel architecture (SCA) solution, all APs and clients operate on the same channel. Note that this is used by a wireless systems specifically designed to operate in an SCA mode, you can't just flip all of your existing APs on to the same channel.

Some manufacturers already provide an SCA solution, though they are currently regarded in some quarters as being something of a 'niche', 'non-standard' solution. However, they are certified by the WiFi alliance, so this  is something of an unfair label to apply to them.

There is no doubt (in my mind anyhow) that a SCA can never perform to the same level as a traditional, well-designedwell-deployed 'multichannel' architecture (MCA). If you start to consider the amount of capacity available to each non-overlapping cell in a MCA solution, the maths speak for themselves - the capacity is proportional to the number of non-contending cells available in a network. However, there are three key assumptions underlying the MCA vs SCA argument:
  1. There are a reasonable number of channels available to allow an MCA solution to be deployed
  2. All AP cells in an MCA are sufficiently isolated from other AP cells on the same channel that they do not suffer co-channel interference/contention (hence cutting the potential capacity of two cells by a significant factor)
  3. The MCA solution has been well designed and deployed (i.e. cell sizing, channel planning and co-channel contention considerations are all well implemented)
Given the limitations of the 5GHz band once we start to consider the wider channels that 802.11ac brings, and the fact that very few WiFi networks are particularly well designed in the real world (in my experience), then I believe that the SCA approach has significant merit.

Although it will not be able to hit the potential theoretical throughput that an MCA solution could provide, it can provide a ubiquitous solution that uses an 80MHz channel on non-DFS channels - a feat that cannot be achieved by MCA systems.

I believe it has more chance of delivering the promise of 802.11ac, as it allows the use of the wider channels and the accompanying benefits. Many MCA solutions will have to compromise by reducing channel widths and negate a significant advantage that 802.11ac delivers.  Though multi-user MIMO should certainly deliver increased throughput capabilities in environments with many single-stream devices, the underlying channel width issues will remain. 

WiFi gurus out there will no doubt be able to plan and tweak their WiFi networks to the nth degree and get a super-high throughput network operating on MCA. If they can find organisations who will pay for that level of expertise and commissioning (and are able to maintain their network), that's great. They will no doubt achieve excellent results.

For the vast majority of everyone else deploying WiFi, with customers who want a solution in a working in a timely and affordable manner, then it might be time to at least consider an alternative (and for vendors to start providing that option). SCA certainly isn't the solution for every environment, but is worthy of consideration in many scenarios.

I know that the proposition I'm putting forwards here won't be popular with many WiFi professionals, but I think that SCA is at least worthy of consideration as an option by more WiFi vendors. 


If you've been in the networking industry for a while, you might remember two competing LAN technologies: token ring and ethernet.

Token ring was faster, providing 16mbps LAN speeds, compared to the paltry 10mbps of Ethernet. It used an efficient, well-ordered token passing mechanism, compared to the rather inefficient and erratic random back-off and collision detection methods of Ethernet.

In many ways, token ring was a  technically superior, better-performing solution than ethernet.

It's flaw: it was complex, expensive to maintain and difficult to deploy in comparison to the ease and simplicity of rolling out UTP hubs to create an ethernet LAN. Despite its advantages, people simply got fed up with the complexity and expense of deploying and maintaining token ring networks, resulting in Ethernet winning the LAN technology battle. 

Sound familiar..?



(Thanks to Andrew (@revolutionwifi) for allowing me to use the image featured in this article. It is taken from his original article: 802.11ac Channel Planning

Wednesday, 14 May 2014

802.11ac & 5GHz: The Emperors New Clothes? - Part 2

In part one of this series looking at 802.11ac challenges, we looked at the issues that the use of the 5GHz band brings, particularly around DFS. In this second installment, we look at further challenges to designing and deploying 802.11ac networks.

Extended Channel (UNII-2e) Device Support

Although we may be located well away from any obvious sources of radar interference, there may be other obstacles to the 5GHz nirvana outlined in the 802.11ac marketing briefs. One ugly fact affecting WiFi networks on the 5GHz band is that not all devices that use the 5GHz band support all of the unlicensed channels available in our region. 

For instance, I recently purchased a Nexus 7 tablet and was extremely disappointed to find that it only supports channels 36 to 64 (for the UK). The remaining available channels, 100 - 140 are not supported at all.

I think that this variation in support for channels was originally rooted in a lack of support for devices in the UNII-2e channels (channels 100 - 140). Why this trend still persists in some devices is a mystery to me, but there is no doubt an economic consideration at work here (i.e. lower cost chip-sets). Nonetheless, it still persists with some new devices and is certainly an issue with many older devices.

It's certainly true that UNII-2e channel support among WiFi clients has increased significantly over recent years, but there is still no guarantee that all devices that may use your wireless network will be able to use all possible 5GHz channels. This has an impact if you decide to try to use all 20+ channels across your wireless network. If a wireless client that doesn't support UNII-2e channels is in an area where all APs use UNII-2e channels, then the client will simply not be able to connect. As a work-around, it is possible to alternate AP cells in such a way as to distribute UNII-2e channels amongst AP cells using UNII1,2,3 channels, so that clients may still be able to find a supported channel. But, this is still a workaround, and not an optimum design. Making an SSID available on the 2.4GHz could also be a last-ditch fall-back, but of course, we're no longer able to use our 802.11ac speeds.

(Peter Thorneycroft did a great presentation which touches on this - you can find it here)

Whichever way you look at it, having clients that do not support UNII-2e channels in a wireless network that uses UNII-2e channels is not a great situation and requires careful planning and consideration. 

Voice Over WiFi Clients

Unfortunately, the woes around DFS channels don't end there. I recently became aware of another effect of using DFS channels recently when I attended the Wireless LAN Pros conference and saw this presentation from Martin Ericson: http://www.wlanpros.com/ten-talks-martin-ericson-vofi-phones-dfs-channels/

In summary, when using wireless voice handsets, you want to keep your roaming times between access points very low as you move around a building. If the roam time between APs is too long, this can cause poor audio quality or perhaps even drop the call. Therefore, being able to make a timely roaming decision is critical for wireless handsets. 

Wireless clients use two methods for finding new APs to roam to:
  • Passive scanning - they listen to beacons which are sent every 102mS by APs and build a list of potential APs to roam to
  • Active scanning - they send out probes across all channels to more rapidly find a new AP to roam to
Although the 102mS of passive scanning sounds like a short period of time, it is actually quite a long period compared to what can be achieved using active scanning. When relying on passive scanning alone, the period taken to roam between APs is too long and will cause the quality and connectivity issues we discussed previously.

The DFS process dictates that only the access point on a wireless network has to be able to detect to radar. Clients do not detect radar blasts. For this reason, clients are not allowed to probe on DFS channels, as they may be probing (and hence causing interference) on a channel that is in use by a radar system.

Given this restriction, it does not make sense to use WiFi voice clients on DFS channels. Again, we are impeded in our channel selections for 5GHz for our WiFi network, as utilizing just the non-DFS channels is our best option.

Channel Widths

One of the key strengths of the 802.11ac standard is the speed increases that it delivers. This increase in speed itself is a nice-to-have, but it's not a huge game-changer for the average mobile client. The real advantages are in the increased spectral efficiency the speed increase it can deliver (i.e. how quickly a client can use and free-up the RF medium), which delivers higher WLAN capacity and greater battery savings for mobile devices.

One of the mechanisms used to deliver this additional speed boost is channel bonding. This isn't new - in the 802.11n standard, two standard width 20MHz channels could be bound in to a single 40MHz channel to double the speed of the wireless communication between the AP and client. But, as we double up on our channels, we have less unique channels available overall for our WLAN. The diagram below shows the effect on varying channel widths within the 5GHz band:



You can see that in this diagram (for the USA), we have 25 x 20MHz channels available. This shrinks down to a total of 12 channels when we are using 40MHz channel widths. (The actual numbers available are lower than this, as the weather radar channels aren't generally used, but lets keep things simple for now) 

When considering 802.11ac, which allows the use of 80MHz channels, you can see that the number of usable channels falls again to just six (but, again, the caveat around weather radar channels reduces this). 

Unfortunately, in the real-world, we are probably looking at being able to use 5 or less (in Europe) 80MHz channels on the 5GHz band for 802.11ac devices. And, once we consider legacy devices that perhaps don't support the UNII-2e channels, we're down to just one or two channels that all devices will be able to support. 

Anyone with a basic knowledge of building 802.11 networks will quickly see that having such a small number of available usable channels is not going to work at all well. Having so few channels talks us right back to same issues we had with co-channel interference (or contention) that we've always had on the 2.4GHz band.

So, we're back in to the land of compromise. We have to reduce our channel widths and lose many of the speed benefits that 802.11ac provides. We have to take a chance on using DFS/UNII-2e channels and hope that we don't suffer with any of the potential pitfalls I have outlined above. The 802.11ac story doesn't quite stand up to close scrutiny after all. 

Many vendors are pointing to the white knight on the horizon in the form of 802.11ac wave 2. Wave 2 will allow up to 3 (or maybe 4) single stream clients (e.g. tablets, smartphones) to connect simultaneously to an AP using a technique called multi user MIMO (MU-MIMO). This should provide a significant improvement in performance in environments where single stream devices abound. But there are again caveats: the clients have to be spatially far enough apart for the beam-forming to work correctly and the clients themselves must support beam-forming (which is not mandatory in 802.11ac). Even with these improvements, none of the obstacles outlined previously magically disappear. It's also worth considering that MU-MIMO is only a mechanism that works downstream from AP to clients - it won't be possible for 4 clients to all use the same channel at the same time.



In the third and final installment of article series, we'll look at a solutions to the issues presented in parts 1 and 2. 

Tuesday, 13 May 2014

802.11ac & 5GHz: The Emperors New Clothes? - Part 1

The WiFi industry has been buzzing with excitement around the recently ratified 802.11ac standard. The promise of higher speeds, lower battery usage for mobile devices and the enforced move to the higher-capacity 5GHz band is enough to put a smile on the face of even the most curmudgeonly members of the WiFi fraternity.

I've been giving some serious thought recently to what the best approaches might be in terms of designing and deploying 802.11ac networks. There are obviously challenges as we move through the transition from legacy standards to the shiny new 802.11ac standard: 
  • new cabling requirements for higher uplink speeds to 802.11ac APs
  • Increased power requirements for our 802.11ac APs
  • accommodating the mix of new and legacy clients
  • figuring out exactly how we plan our channels for the brave new world of 802.11ac

The 802.11ac standard mandates that access points and clients using the new standard will only be supported on the 5GHz band, which is great news...right? We can still use our legacy 802.11g and 802.11n standards on good old 2.4GHz, but 802.11ac is 5GHz only. 

The 5GHz band offers us far more channels that the noisy cesspit which is the 2.4GHz band. It provides around 20+ channels (depending on where you are in the world), compared to the pitiful 3 useable channels of the 2.4GHz band. 5Ghz is currently used by fewer (non-WiFi) devices, so has less noise and interference than it's noisy cousin down on 2.4GHz. As we have more channels to play with on 5GHz, we can also start bonding them together to get 40MHz (double-width) and 80MHz (quad-width) channels to get even faster throughput for our 802.11ac clients.

On the face of it, we are in easy-street on 5GHz compared to 2.4GHz. Faster speeds (for faster transfers and better spectral efficiency), together with lower noise and more channels for easier planning and higher capacity.

But, not so fast. 5GHz has a few little 'gotchas'' that maybe the marketing boys didn't tell you about...

DFS

When the 802.11 standards were created and the 2.4GHz and 5GHz bands were allocated for use by WiFi traffic, there was some difficulty surrounding existing services that already used the 5GHz band. Particularly in Europe, there was the issue of weather and airport radar systems that already used parts of the 5GHz band. Though this was initially confined to Europe, it is now a consideration in many areas of the world.

Unless protection mechanisms were put in place, there was a danger that a WiFi network on specific channels within the 5GHz band could interfere with these radar systems.  Therefore, it was decided to implement a protection system to guard against radar system interference: Dynamic Frequency Selection (DFS).

DFS ensures that if a WiFi network detects an RF signature that looks like a radar pulse on the channel on which an access point is operating, it will cease all transmissions on that channel and move to a new channel. This has a disruptive effect on associated wireless clients, who will also need to switch channels. This might cause a relatively short 'blip' for clients not carrying time-sensitive data (e.g. for simple web browsing, files transfers etc.). But, for latency sensitive traffic (e.g. voice & video), this channel switch will have significant effects, such as dropping established voice calls over WiFi.

To find out more about DFS, take a look at a great series of articles from Jennifer Minella at Network Computing.

Fortunately, the DFS mechanism does not apply to all channels within the 5GHz band. In many parts of the world, the first 4 channels of the 5GHz band for WiFi may operate without being subject to DFS (non-DFS channels). These are channels 36,40,44,48. This means we can confidently use these channels without any fear of service interruption due to radar detection events. (Note that in the USA, there are 9 non-DFS channels)

Unless you are near an obvious radar source (e.g. an airport), it may be difficult to determine if your network is going to affected by radar. Often, the first time this becomes apparent is when a wireless network has been deployed and radar blasts are reported by the wireless network. Due to the nature of the radar pulse width, radar systems tend not to detected during a wireless survey, even if using a spectrum analyser.

In addition to detection of genuine radar systems, there may also occasionally be local interference from non-radar systems which inadvertently trigger the DFS mechanism. This is due to the generation of a pulse of RF energy that looks similar to a radar pulse.

In the real world, reports from other wireless professionals I've spoken to suggest that actual radar events affecting WiFi networks tend to be rare. However, in very high density deployments, the incidence of false-positives from mis-behaving clients is not unusual.

In summary, although radar detection is infrequent, it may be unpredictable and may cause significant disruption when using a WiFi system on 5GHz near a radar source. The effects of DFS may be completely mitigated by using only non-DFS channels, but this will reduce our usable channels from our original 20+ channels down to just four (OK, maybe 9 if you're in the USA...).


In part 2 of this article series, we'll look at more restrictions impacting the use of the 5GHz band and 802.11ac.

Sunday, 11 May 2014

Spectrum Allocation Plans for WiFi in the UK (2014)

Plans for new spectrum allocation for WiFi networks in North America are regular fodder for many blog and news articles that I  see scrolling past in the many RSS feeds that I monitor for WiFi related news.

However, information about plans for additional spectrum allocation within the UK isn't quite so widely covered (in fact, I'd go so far as to say that it is largely ignored). But, here in the UK we still face the same issues as many other areas of the world: an explosion in mobile devices, massive deployment of WiFi networks in homes and businesses, and an ongoing increase in bandwidth demands.

WiFi in the UK operates on both the 2.4GHz and 5GHz bands. We have 13 channels allocated for WiFi on 2.4GHz, but for practical purposes, only 3 may be used across a wireless LAN. On the 5GHz band, we have 19 channels allocated to WiFi, but are generally limited to using only 16 of those channels due to restrictions in supporting 3 channels that may interfere with weather radar systems.

The latest and greatest WiFi standard, 802.11ac, will (theoretically) provide Gigabit WiFi speeds which will hopefully keep up with the growing demand for bandwidth via WiFi neworks. 

However, 802.11ac only operates on the 5GHz band. This is in recognition of the fact that the 5GHz band has much greater capacity than the 2.4GHz band (16 channels vs 3 channels) and so will be able to support the greater bandwidth required for the higher data rates that 802.11ac brings. Additionally, the 5GHz band generally has much lower noise and interference (compared to the 2.4GHz band) from other co-existing devices and services, making it more suitable for high speed services.

In April 2014, OFCOM (the UK communications regulator) published a report that outlines the current considerations around the use of RF spectrum by WiFi networks in the UK. It also discusses considerations for M2M (Machine to Machine) communications and the IoT (Internet of Things), but my interest was limited to the WiFi aspects of the report. It provides some interesting insight in to the services currently using the 5GHz band and considerations for making more spectrum available within the band.

If you'd like to take a look at the report, you can get hold of it here: "The future role of spectrum sharing for mobile and wireless data services  - Licensed sharing, Wi-Fi, and dynamic spectrum access" (section 3 is the main area of interest from a WiFi perspective)

Here are the highlights of the report around current and future WiFi spectrum usage here in the UK:
  • WiFi usage is growing rapidly and there is a need to keep pace with the increasing speeds of broadband connectivity in to homes and businesses.
  • The requirement for increased speed will have to leverage the new 802.11ac standard (for example being able to leverage the 80MHz and 160Mhz channel widths that 802.11ac provides)
  • WiFi networks using more spectrum in close proximity to other homes and  businesses will require more available channels to be able to use the required access speeds
  • Other alternatives (below) are available within homes and businesses, but WiFi is the only viable option for wireless devices
    • limited to a single room: WiGig (802.11ad) and Li-Fi
    • Around home/business: Powerline adapters (depends of quality of wiring), Ethernet cabling (expensive/disruptive) - both still require wireless access points to connect wireless devices
  • There is insufficient bandwidth in 2.4GHz band for higher speed WiFi standards
  • Proposals to extend the allocation for WiFi within the  5GHz band are being considered in preparation for the World Radiocommunication Conference in 2015. The extensions under consideration is shown in the figure below:

  • From studies carried out, it is expected that the current spectrum allocation in 2.4GHz and 5GHz is likely to be under pressure (from a capacity perspective) by 2020.
  • The report also highlights concerns from a number of other interested parties who already have services existing in the areas of proposed spectrum expansion and may be impacted by WiFi co-existing in their area of spectrum. It provides the following illustration of existing services in the 5GHz band that may be affected by any spectrum allocation expansion:

  • Due to the requirement for co-existence with these existing services, work is being undertaken to consider technical solutions for sharing the spectrum. These include dynamic frequency selection (DFS), transmit power control (TPC), restriction to indoor-use only and geolocation databases
  • Some concerns have been raised by existing users of the areas of spectrum that are proposed for sharing (e.g. ESSS - earth exploration satellite services), as they rely on equipment which detects low level signals which has incurred significant investment and cannot be modified once deployed.
  • Ofcom is carrying out a number of technical studies in preparation for the World Radiocommunication Conference in 2015 to understand the viability of spectrum sharing. However, at this time, there has been no definitive opinion formed by Ofcom around whether or not they should support the proposed extensions.
In summary, it is interesting to see that Ofcom are actively considering expanding the provision of spectrum on 5GHz for WiFi services within the UK. However, it is unclear at this point if more spectrum will be made available, or how much additional spectrum will be allocated. It looks as though we will be waiting until the World Radiocommunication Conference in 2015 before any decisions will be made.


References:

Wednesday, 22 May 2013

Aruba Tech Field Day - 802.11ac Product Announcement


Yesterday was the official launch of Aruba's journey in to the world of 802.11ac with their online (and real-world) Tech Field Day event where they presented their products and strategy for 11ac. I was a virtual participant, watching from over here in the UK. I have to say up-front that I do not currently supply or support Aruba products, but was very interested to hear more about their views on 802.11ac, together with their product offering. There was a lot of ground covered, but here a few (brief) notes of things that I found of particular interest for the sessions I managed to view.

802.11ac

There was a very informative and lengthy discussion around 802.11ac technology, together with the lessons learned by Aruba in their testing to date. I won't cover all points here, but the headlines that stuck in my mind were:

  • Smartphones/tablets will continue to be primarily single stream, capable of 80MHz bonded channel support
  • Although 11ac brings significant speed advances, it's not the speed itself which is the advantage, it's the increase in efficiency of the WLAN which is the big win. The faster a client can get on the WLAN, send its data, and then get off, the more clients will be able to use the WLAN (which remains a shared medium). This will help to meet the growing demand for WiFi capacity
  • The highest "headline" speeds of 802.11ac will only be achieved by clients being in close proximity to an AP. The more complex modulation and signal processing required means that excellent signal quality (e.g. through excellent SNR levels) to achieve the higher speeds.
  • Sticky clients continue to be an issue (see "ClientMatch" below), which can significantly impact the efficiency of a high density WLAN. As client speeds drop as they move away from an AP, causing a bottleneck for other clients on the same AP that they are "stuck" to.

ClientMatch

A mentioned above, Aruba highlighted the ongoing issue with "sticky clients". These are clients that initially associate with an AP and then, despite 'better-choice' APs being available, remain associated as the client moves away from it. The issue with this is that the client speed will drop as the signal level falls, so that it is transmitting at lower speeds and impacting the efficiency of other clients using that same AP. If  clients can be made to prefer (and roam to) a more local AP, that will facilitate a better link speed and WLAN efficieincy, together with all of the efficiency gains that this will bring.

Aruba have a 'patented' technology, called ClientMatch which apparently looks at things from a client point of view and can 'steer' clients to better-choice APs. This technology can apparently work for all types of (legacy) client, but works best on more recent types of client that support newer 802.11 features such as 802.11k/v.

Reading between the lines, I think it analyses signal quality and signal levels from clients (at the AP end of things), together with 802.11k/v information to make some decisions about how things are looking from a client's point of view. Then, somehow (presumably through band steering and ignoring probes etc. from clients below pre-defined signal thresholds) it 'steers' them to a better AP.

We all know the types of information that are available to an AP from clients and the limited amounts of information that clients themselves will supply or act on. So, it's hard to see what there is here to actually patent. Unless there is some type of agent installed on the client (which there isn't in this case), what other unknown (patentable) mechanism could possibly be at work here? Apart from some 'secret sauce' decision making from the WLAN point of view, using known measurements and techniques, it's hard to understand what can be so unique about this. To be honest, without more information, I'm struggling with the concept of a unique offering here...

Access Points

Early on in the proceedings, Aruba presented their new 11ac access points: the AP220. There are two models, one with internal and one with external antennas. The units they had on display at the event were very impressive looking. They looked relatively light-weight (judging by the way they were being handled) and they appeared pretty sleek, as they have now dispensed with the usual air-vents to meet the 'wipe down' needs of the healthcare sector.

The AP has 2 Gigabit Ethernet ports to cater for the theoretical throughput speeds that can achieved by an AP with 2 radios (1 x 5GHz 11ac & and  1 x 2.4GHz 11n). I didn't quite get the information around the power requirements (i.e. 802.3af vs 802.3at), but looking at the datasheet, it looks like it can run in an 'Efficient Mode' with an 802.3af POE port and full funtionality mode with an 802.3at POE port. The detail on how the 2 gigabit Ethernet ports will be used (i.e. load balancing or a true trunk) was also unclear (this is still TBA on the datasheet I am looking at...).

The guys from Aruba pointed out that the AP uses less power than 'other solutions which require a plug in module' (i.e. Cisco). But, from what I see so far, both solutions require a full 3at POE port to operate with full functionality, so, I don't really see an advantage there..?

They also said that in their experience to date, you can pretty much do a one for one swap out of 11n APs for 11ac, as the general coverage patterns were broadly similar.

Lync

A Microsoft representative provided an excellent presentation around the Microsoft Lync product, which was fascinating for those of us (OK, maybe just me) who aren't that familiar with Lync. He described the challenges of trying to prioritise the different traffic flows that originate from a Lync client.  

The Lync client itself may be a number of form factors (laptop, tablet, phone), which may be the source of data, voice or video traffic. Trying to configure the QOS requirements for just those traffic types is a challenge, but throw in the fact that there is signalling traffic, some traffic is encrypted and some protocols do not use well known port ranges, and you have a whole heap of trouble.

He then went on to describe how Aruba have become a certified Microsoft Lync partner, allowing them to have access to an API that is made available from a Lync server. Having access to the API means that the Aruba wireless LAN controller can exchange information and drill down in to the detail of each Lync session, allowing decisions (such as QOS prioritisation) to be made as required. Apparently, Aruba and Microsoft have invested a lot of time in testing this exchange of information across the API, which allows better decisions to be made by the wireless network and provides much richer information to be made available on the wireless management platform.

This foray in to the Lync API was described as Aruba's move in the to brave new world of SDN: the application providing information for the network fabric to provision the resources required for an application. Exciting stuff!!! It certainly sounds like a good strategic move for both organisations. but I wonder if an open, standards-based API would be a better way to go long term (...imagine an unique API for every different application)? This (SDN) isn't an area of expertise for me, so please excuse any comments which seem mis-guided and please attribute them to my technical ignorance :)

Finally

Finally, I have to say thanks to Aruba, Microsoft and Gestalt IT for providing such open access to this event. The information presented was both valuable and fascinating. 

The event itself was very well organised (as you might expect from those Tech Field Day boys), with a great deal of both vendor material (from Aruba/Microsoft), together with the opportunity for some challenging questions from vendor-neutral folks as well. I think this open-forum approach really shows that Aruba is ready to listen, as well as very generously share, which really raises my opinion of them significantly (...not that it was low before, :) I've had no previous dealings with Aruba) .

I believe that Aruba are also going to make some of the material available from the presentations, in the form of videos and some of the slide decks - I particularly look forward to the recommended Lync QOS settings that were shared :)  I also strongly recommend that you review some of the great material that Aruba have made available about 802.11ac and their products.

This has been another very interesting and exciting chapter in the unfolding 802.11ac - thanks to Aruba, Microsoft & Gestalt IT.

References

Tuesday, 7 May 2013

5GHz - 3 Missing Channels in Europe

Last year, I put up a posting which highlighted the fact that here in the UK (and I suspect all of Europe) we often have 3 channels missing from our allocation of unlicensed channels in the 5GHz band.  Looking at many manufacturer data sheets, channels 120, 124 and 128 are often shown as not being supported. This is despite the fact that they are allocated for use by local regulatory bodies (OFCOM here in the UK).

I recently posted a question about this on a partner forum of a major WiFi vendor that I deal with and finally got a definitive answer on this. In this post, I'll share my findings.

The reason that these particular channels (120 - 128) receive special treatment is that they occupy frequencies that are used by weather radar systems. WiFi systems have to be very careful not to interfere with those systems during their normal operation. Therefore, WiFi equipment has some additional checks and tests imposed on it to make sure that it does not inadvertently cause any interference.

In the ETSI region (Europe), the standard EN 301 893 dictates that any channels operating in the frequency range 5.6GHz to 5.65GHz must wait an additional period of time before using a channel. For most DFS-affected channels, a WiFi device must wait for 60 seconds to verify that no radar is present before commencing operation. However, on the channels in the 5.6GHz to 5.65GHz range, the device (i.e. Access Point) must wait 10 minutes! The table below (taken from Annex D of the standard) details this requirement:


Due to this 10 minute wait period, it seems that many manufacturers have chosen to withdraw support for the channels affected, which are 120, 124 and 128. This makes perfect sense now - who would want an AP to be allocated to a channel and then wait for 10 minutes before it can use it..?

I'm pleased to have finally got to the bottom of this particular grey area, but it seems like bad news for WiFi usage in Europe generally. With the anticipated sharp uptake in 5GHz usage around the globe, as 802.11ac starts to roll out, the loss of 3 channels is quite a chunk of spectrum to lose.

In the UK we have 19 unlicensed channels to use on 5GHz for WiFi. Losing 3 of those channels is a 15% loss in spectrum. This is at a time when we really need to be increasing spectrum availability to cope with the additional channel bonding opportunities that  802.11ac provides to increase WiFi speeds.

Hmmm....let's hope some additional spectrum turns up in the near future.

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

Saturday, 4 May 2013

Samsung Galaxy S4 WiFi Capabilities


With all of the excitement around 802.11ac that is currently unfolding, I was very interested to hear about the support for 11ac by the recently released  Saumsung Galaxy S4. Having a quick scan of the reviews across the web about the new handset, I was intrigued to see claims that it supports 802.11ac, allowing speeds up to 1.3Gbps! Feeling a little sceptical that it would support anything close to those speeds, I did a bit of digging to see what I could find.

My first port of call was a product tear-down over at TechInsights.com. They revealed that the WiFi chip in the S4 is the Broadcom BCM4335


A quick look around the Broadcom site soon revealed the product page for the BCM4335, with an overview of the chipset specification. In summary, it supports:

  • Single stream IEEE 802.11ac solution with data rates up to 433.3 Mbps
  • Full IEEE 802.11a/b/g/n legacy compatibility with enhanced performance
  • Supports 20, 40, and 80 MHz channels with optional SGI (256 QAM modulation)
  • The BCM4335 features advanced idle power consumption performance, which significantly extends mobile device's battery life
  • Broadcom's TurboQAM™ technology implements the highest data-rate 256-QAM mode in 2.4 GHz and enables devices equipped with the BCM4335 to deliver 10 percent faster throughputs than 802.11n speeds when communicating with other 5G WiFi devices
  • Key high-throughput mobility interfaces, including SDIO 3.0, PCIe and HSIC, make it suitable for smartphone, tablet and computing platforms
  • Advanced beamforming (IEEE 802.11ac/n), Low-Density Parity Check (LDPC) code and Space-Time Block Code (STBC) support for better coverage and more reliable connectivity
  • Built-in media processing to off-load host processor
  • Integrated support for Wi-Fi Direct™, Wi-Fi Certified Miracast™ and Wi-Fi Certified Passpoint™ technologies
Some very interesting facts and figures here, but this pretty much quashed the outlandish claims in some articles around the 1.3Gbps top speed, as the chipset cannot go beyond 433mbps.Even so, these potential performance gains over other non-11ac handsets are very impressive. 

Although the chipset itself may support up to 443.3 Mbps, primarily through the 80Mhz-width channel capability, this doesn't mean that the Samsung implementation has actually taken advantage of the full 80Mhz channel width. I still needed more information to find out what the S4 itself was actually capable of.
 
The next stop was the FCC web site (A3L/GTI9505 if you want to take a look yourself) to have a look to see if I could see what speeds and channel widths had been tested during the FCC approval testing process.  


The WLAN testing report shows that the handset was tested on both 2.4GHz (802.11b/g/n) and 5GHz (802.11a/n/ac). Interestingly, it was tested up to 433.3mbps, using an 80Mhz width channel! 


There were also some interesting power levels presented, which seem to suggest that the transmit power level of the device was averaging around 11-13dBm on 5GHz, depending on the data rate and channel. On 2.4GHz, it looks like it has a slightly higher power output, showing figures averaging 12-15dBm.

So, in summary, the S4 is a single stream device, supporting up to 80MHz channels (for 802.11ac ) and has a top speed of around 433Mbps. Don't forget
 these figures will assume ideal conditions (i.e. short guard interval, close proximity to AP, good SNR values etc.), and that these are connection speeds, not throughput speeds that you would see when transferring data. Actual throughput is likely to be a little over half of the top-speed of 433Mbps. 

Also, don't forget that 802.11ac is only supported on the 5GHz band. If you are using it on 2.4GHz, the best you are going to get is the top speed for a single stream 802.11n device  on a 20MHz channel (around 72Mbps connection speed).

All we need now are some 802.11ac APs to use the S4 with :)