Showing posts with label 5GHz. Show all posts
Showing posts with label 5GHz. Show all posts

Sunday, 20 May 2018

Updated White Paper on Licence-Exempt Spectrum in the 5GHz band for Wireless LANs in the UK

For the past few years, I've maintained a white paper on the use of the 5GHz spectrum for Wi-Fi networks here in the UK. As Wi-Fi text books tend to focus on the spectrum available in the USA, I put this document together to clarify how 5GHz spectrum may be used in the UK.

Following the release of a Voluntary National Specification document by Ofcom in August 2017 (VNS 2030/8/3), additional channels became available for use in the UK on 5GHz.

As we now have additional spectrum, it's time for an update to my white paper to detail the new spectrum that is available.

Prior to updating the white paper, I published a summary sheet that shows the new spectrum allocation. This can be obtained obtain from my previous blog article: UK 5GHz WLAN Spectrum Allocation (August 2017) (this is definitely one to print off and laminate).

I have now completed my updates to the white paper, which I am pleased to share with you now. Note that in addition to adding the new spectrum details, I have added a few other topics around the use of 5GHz and the unique challenges that it presents. I'd recommend taking a look at my description of how DFS operates in Appendix 2, and have a play with the Opera weather radar location tool shown in Appendix 3.

I hope you find the update useful and informative.

Links:





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).



Sunday, 15 October 2017

UK 5GHz WLAN Spectrum Allocation (August 2017)



In August 2017, Ofcom in the UK made some additional channels available in the 5GHz band for license exempt usage.

The details can be found in the following Ofcom document: VNS – Voluntary National Specification 2030/8/3

This means that we have an additional 6 x 20Mhz channels available for use here in the UK for our Wi-Fi networks. This also translates in to a possible additional 3 x 40MHz channels and 2 x  80 MHz channels.

I have put together a cheat sheet showing the 5GHz channels now available in the UK, together with a few useful references.

You can download the sheet from here: link

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

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, 14 August 2013

5GHz Unlicensed WiFi Channels in the UK - White Paper

(Note: this white paper has been superseded with this new updated version)

I put together a few articles a few months ago talking about how the unlicensed 5GHz band is used for WiFi here in the UK.

I thought it might be a good idea to consolidate all of the information that I found in to one place, so that people researching the topic could find and digest it more easily.

Therefore I put together a white paper about how 5GHz is used for WiFi here in the UK. You can download it from here.

There will no doubt be errors, omissions and other facts that folks would like to suggest. So, please feel free to drop me a note and I'll update this document from time to time to improve the quality of information that it contains.

Nigel.

Download the document from the following sources:
  • Scribd
  • Google Docs

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

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?