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

Sunday, 25 January 2015

Cisco AP Channel Utilization

One thing that keeps me awake at night is the whole concept of Co-channel interference in WiFi networks (well, that and acid reflux) . I'm always concerned by it's presence in a Wireless LAN, how to detect it, how to avoid it and how to measure its effect. In this article I share a tip I picked up from a recent Cisco webinar to determine the general level of utilization of an AP's channel. I also look at how this may give us a clue about the level of CCI in a Cisco wireless network.


Background

Co-channel interference (CCI), co-channel contention (CCC)...whatever you want to call it (I'm growing quite fond of the term "Co-channel Chatter"), is a blight in many WiFi networks. In all but the most isolated and carefully designed of wireless LANs, it lurks, waiting to disrupt the efficient operation of our WiFi network.

As the number of WiFi networks rises, AP channel-widths increase (with newer WiFi standards) and the population of WiFi devices explodes, the growing spectre of CCI/CCC  increases steadily over time. In simple terms, if you deploy a wireless access point on a particular channel, it contends for access to the channel with any other access points (and clients) assigned to the same channel that are within "hearing range" of the AP. (Here's a link to a very useful article that gives more background on this subject).

In an ideal world, each AP we deploy on a WLAN is assigned to a unique channel and is isolated sufficiently (from an RF perspective) so that it cannot "hear" any other APs on the same channel. This will ensure that they are at a sufficiently low level that they not will impinge on the AP's clear channel assessment (CCA) process. In this ideal scenario, our AP will not have to contend with any other APs for access to the RF channel. Therefore, it will be able to service the needs of its associated clients with all of the bandwidth (air-time) that is theoretically available, within the limitations of the client and AP standard support.

However, the real world is rarely like this. All too often, APs from neighboring networks or even APs on our own network will operate on the same channel that a particular AP may be using. APs on the same channel may "hear" each other and will have to contend for (i.e. share) access to the RF channel that they are all using. This limits the potential data throughput that may be offered by each AP.

(Note: this is something of a simplified explanation, as there are additional CCC effects from WLAN clients. However this will suffice for the point I am trying to demonstrate.)

Channel Utilization Statistics

For a while, I have been troubled by the question: "how does the world (well, channel) look from an AP's point of view?" If an AP is assigned to a channel, how busy does that channel look from its perspective? I'm not talking about data the AP may itself be passing over the channel, but the level of traffic it perceives, including "chatter" from other APs and clients on the same channel.

Understanding how busy the channel is by considering all sources tells us how often the AP has an opportunity to use the channel. It may also give us a indication of how much co-channel contention (CCI/CCC) our AP may be exposed to. Once we know how busy a channel is, we can decide whether using this channel is viable for our AP.

In the Cisco AireOS solution (traditional 5508/2504 controller solution), each AP has a set of statistics available from the WLC GUI that show the AP's channel utilization. The screen shot below shows the AP channel statistics ("Load Statistics") available. Theses are available from GUI option:

Monitor > Access Points > Radios > 802.11x/y/z  >  AP Name

Figure 1 - AP Channel Utilization Stats 

The statistics available are: Rx Utilization, Tx Utilization and Channel Utilization. The statistic we're interested in is: "Channel Utilization".

The "Rx Utilization" and "Tx Utilization" figure indicate the level of traffic (%) sent and received by the AP itself.

Channel Utilization indicates how much 802.11 traffic the AP can "hear" on its channel, from all sources. The statistic is a percentage figure (15% in the example shown). This will include all 802.11 frames that the AP can hear from all APs and clients in the vicinity. It indicates the amount of time that the AP considers the channel to be busy.

High Channel Utilization

This is incredibly useful. For one thing, we can see when our channel is "full". Once we hit 100%, no amount of additional APs is going to improve things and allow us to accommodate more traffic - all air-time (i.e. opportunities to transmit) is being used up. The utilization may be caused by our own AP, by nearby clients or by nearby APs using the same channel. Whatever the reason, having the ability to detect a highly utilized channel means that we can come up with a strategy to try to fix the situation.

A typical concern in new WLANs is the effect of APs in our own WLAN network that are using the same channel. We have a finite number of channels to use, so channel re-use is inevitable in all but the simplest of networks. Although we may have planned our network channels carefully, just how "clear" or "available" is the channel we have chosen for each AP? The channel utilization statistic give us an excellent view of this aspect of a channel, from the AP's viewpoint. If we choose a channel and the channel utilization statistic is low, we're probably in pretty good shape.

I recently installed a new wireless network which required a fairly dense deployment of access points. Co-channel interference was unavoidable in some areas and had to be minimized as far as possible. In some areas of the network, the Channel Utilization statistic revealed that the channel used by some APs was being heavily utilized (around 60%). The question I had was: "Is this due to client traffic, or the effect of co-channel interference from other APs nearby?" By waiting until the end of day, I saw that the channel utilization did, in fact, fall down to much lower levels once all users (and their clients) had gone home for the day. The majority of the channel utilization was down to real client traffic, rather than CCI  from nearby APs (which was a relief).

Lab Test

To demonstrate the effect of CCI on the Channel Utilization statistic, I ran up some APs in my home lab and placed them on the same channel to deliberately cause AP CCI. I used the 2.4GHz band, created several SSIDs and configured the AP radios to support rates down to 1Mbps to chew up some air-time. By varying the number of APs on the channel and the number of SSIDs being broadcast, we can see the effect on the channel utilization from the point of view of our test AP.

Here are the results:

1. The first test had 3 SSIDS, with 1 AP enabled. I also had a neighbor's home network using the same channel which was adding to the channel utilization observed. The channel used (channel 11) was running at around 16% utilization:

Figure 2 - 1AP, 3SSIDs

2. Next I added another AP running the same 3 SSIDs - so now we had 2 lab APs on the same channel. Again, it ran on channel 11 to create more CCI/CCC via the beacons being broadcast by the APs. This increased the channel utilization to 24%:


Figure 3 - 2 APs, 3SSIDs

3. Next, I added a third AP, again running the same 3 SSIDs on channel 11. This bumped the channel utilization up to 33% with the additional beacon traffic.
Figure 4 - 3 AP, 3 SSIDs
4. Finally, I doubled the number of SSIDs to 6 across all 3 APs. This again bumped up the beacon traffic and increased utilization to 54%:
Figure 5 - 3 APs, 6 SSIDs

Note that in all cases, only new SSIDs and APs were being added to the equation - little or no client traffic was being generated to cause this effect. This was due to the CCI/CCC being added by the beacons being broadcast by the APs on the same channel.

Although in the real world, not all channel utilization is caused by AP CCC/CCI, channel utilization can be a useful indication, particularly if you compare levels in-hours and out-of-hours (when client numbers are very low). 

(Note: channel utilization statistics update around every minute or so - they are not dynamic)

CLI Utilization Stats

If you're a 'CLI' sort of person, you may prefer to look at this information from the CLI of your WLC. You can pull the same information using the commands:

show ap auto-rf 802.11b <ap name> 

or

show ap auto-rf 802.11a <ap name>

You'll get an output similar to the output shown below when you run the command.The channel utilization information is highlighted below in the example using red text:

(Note: channel utilization stats update around every minute or so - they are not dynamic)

Number Of Slots.................................. 2
AP Name.......................................... AP2600
MAC Address...................................... 44:2b:03:9a:xx:xx
  Slot ID........................................ 0
  Radio Type..................................... RADIO_TYPE_80211b/g
  Sub-band Type.................................. All
  Noise Information
    Noise Profile................................ PASSED
    Channel 1....................................  -95 dBm
    Channel 2....................................  -94 dBm
    Channel 3....................................  -76 dBm
    Channel 4....................................  -85 dBm
    Channel 5....................................  -93 dBm
    Channel 6....................................  -78 dBm
    Channel 7....................................  -88 dBm
    Channel 8....................................  -91 dBm
    Channel 9....................................  -92 dBm
    Channel 10...................................  -93 dBm
    Channel 11...................................  -93 dBm
    Channel 12...................................  -92 dBm
    Channel 13...................................  -92 dBm
  Interference Information
    Interference Profile......................... PASSED
    Channel 1....................................  -77 dBm @  7 % busy
    Channel 2.................................... -128 dBm @  0 % busy
    Channel 3.................................... -128 dBm @  0 % busy
    Channel 4.................................... -128 dBm @  0 % busy
    Channel 5.................................... -128 dBm @  0 % busy
    Channel 6....................................  -83 dBm @  2 % busy
    Channel 7....................................  -81 dBm @  7 % busy
    Channel 8.................................... -128 dBm @  0 % busy
    Channel 9.................................... -128 dBm @  0 % busy
    Channel 10................................... -128 dBm @  0 % busy
    Channel 11................................... -128 dBm @  0 % busy
    Channel 12................................... -128 dBm @  0 % busy
    Channel 13................................... -128 dBm @  0 % busy
  Load Information
    Load Profile................................. PASSED
    Receive Utilization.......................... 0 %
    Transmit Utilization......................... 4 %
    Channel Utilization.......................... 66 %
    Attached Clients............................. 0 clients


WLCCA

Another great way to assess channel utilization is to use the WLC Configuration Analysis (WLCCA) tool from Cisco.

Briefly, the tool is a Windows application  available for free from Cisco and provides an analysis of a WLC configuration. You simply load in the output of the show 'run-config' command from the WLC CLI. You can get it from : https://supportforums.cisco.com/document/7711/wlc-config-analyzer (access request required)

It does plenty more than showing AP channel utilization, but it provides a nice report showing both 2.4 and 5GHz channel utilization per AP. Here are the results from my lab:

Figure 6 - WLLC AP Channel Utilization

Prime Infrastructure

One other way of viewing AP channel utilization is to use the Cisco Prime Infrastructure management application. 

If you have set up building and floor maps of your wireless LAN within CPI, one of the available maps views for access points  is channel utilization. I don't have a graphic to add in to this article, but I'm sure you will be able to find it with a little experimentation.

How Do We Fix High Utilization?

Although my fixation with CCI/CCC has been the main focus of this article, high channel utilization will not necessarily be caused by CCI/CCC.

Here are a number of suggestions for sources of high channel utilization. By attending to one or more of these possible causes, we may cut down the levels of utilization observed, and improve the performance of our WLAN:
  1. WLAN support for low basic rate speeds: if your AP radios are configured to support lower, legacy basic-rate connection speeds, then much of the management traffic (e.g. beacons) that is exchanged will use the lowest available connection speeds. This causes the traffic to occupy more of the available air-time and takes longer to transmit (increasing channel utilization).

    Support for lower speeds also provides wireless clients the opportunity to rate shift to use lower connection speeds as they move away from an AP and consume more air-time (increasing channel utilization).
  2. Channel planning: have a look at your WLAN channel planning. Do you have APs on the same channel that are perhaps contending to use the same channel (i.e. CCC/CCI)? This will be most obvious once users have gone home for the day and channel utilization levels remain high. Try adjusting channel allocations to avoid APs in close proximity using the same channel.
  3. Cell size adjustment: you might also try adjusting  AP transmit power to reduce AP cell sizes (and hence how well APs can "hear" each other). One caveat of this approach is that it may affect the coverage experienced by clients in a negative way. You need to be very careful with this approach, or you may get calls about users who suddenly can't connect in a particular area. You might need to get the survey gear out for this one.
  4. Neighboring networks: high channel utilization may be caused by access points (or their clients) on neighboring WiFi networks. Check you rogue AP lists and see if they are operating on the same channel as your own WLAN APs.You may need to change your AP channel to avoid the neighboring network.
  5. Client traffic levels: it may be that a high level of channel utilization is simply due to a high level of client traffic. This might be caused by the number of clients connecting to an AP, or perhaps the type of traffic that some clients are imposing on the network (e.g. HD video). This would need careful analysis, with perhaps some attempts to more evenly distribute clients across APs or perhaps rate-limit specific applications.  

Summary

In this article, we've taken a brief stroll through the Channel Utilization statistic available for Cisco APs. Hopefully it has provided some useful information to assess how busy an AP's channel appears from a channel availability perspective. 

We've seen that it shows us the air-time utilization of a channel that an AP may be using. This can be very useful to understand whether a channel is appropriate for use. If it's too busy, we may be well-advised to select an alternative. 

We also looked at how we might get an indication of CCC/CCI by comparing utilization levels in and out of hours. 

We explored the various methods we can use to look at utilization figures, which included: the WLC GUI, WLC CLI, WLCCA and Prime Infrastructure.

Finally, we took a quick look at possible causes of high channel utilization and possible remediation of the issue.

Wednesday, 12 November 2014

Effect of Transmit Power Changes on AP Cell Sizing

There's a well known rule of thumb when planning wireless LAN networks which states that for every 6dB increase in AP transmit power, the coverage distance of the AP doubles, This is obviously assuming there are no obstacles to limit or reduce coverage - it assumes a clear path and considers the effect of Free Space Path Loss (FSPL). Nonetheless, it is a useful rule of thumb for planning. Although doubling coverage with 6dB is useful, I thought it might be interesting to look at the effect of increasing power by other increments too, to see the (theoretical) effect on coverage.


Background


Quite a few articles, web pages and wireless LAN text books quote the following rule of thumb when considering the effect of increasing the transmit power of an access point.

  • For every increase of 6 dB, the coverage distance doubles.
  • For every decrease of 6 dB, the coverage distance is cut in half.

Here is an example of such an article: http://www.cisco.com/c/en/us/support/docs/wireless-mobility/wireless-lan-wlan/23231-powervalues-23231.html

Whilst it is quite useful to remember when increasing or decreasing AP power settings, I always wonder what the effect would be of adjusting the transmit power by perhaps 3dB - would this increase the coverage distance by only half the distance that 6dB gives us? Given the logarithmic nature of dB measurements, my gut instinct has always been that things are probably not quite that intuitive.

The easiest way to test for the coverage increase provided by an increase in transmit power is to use our old friend the Free Space Path Loss formula. By plugging in a few values, we should be able to observe the effect of cell radius distance as we increase the transmit value that we are considering.


Free Space Path Loss (FSPL) Formula


The cornerstone of our coverage calculations will be the Free Space Path Loss formula. The energy available from an RF transmission source decreases in a predictable manner as you move away from that source. It is analogous to observing a carbon filament lamp hanging from a ceiling: the level of light that you observe decreases as you move away from it. By using the FSPL formula we can predict what the level of RF energy should be as we move away from an RF source (a wireless access point in our case).

When looking at these calculations, you need to understand that the calculation is based on the loss in "free space". This asumes that RF energy is passing through space with no obstructions that might degrade, block, reflect or otherwise change or disrupt with the signal. If you take the example of an access point in a indoors environment, RF signals will be subject to a whole range of obstructions (walls, doors, windows, people, furniture) which will generally have a negative effect on RF signals.Therefore, the calculations shown in the examples presented below are not "real world" in many instances, but give an indication of how power changes affect RF coverage

For our purposes, we need to understand the distance at which a particular signal level might be heard. The variables we have in the FSPL formula are frequency and distance. These are used to derive the loss (in dB) over the distance specified (in metres) at a given frequency (in hertz). Here is the forumla:


This isn't the correct format for our requirements. What we need to understand is the distance over which a particular loss occurs for a given frequency. Therefore, we need to re-arrange the formula to make distance the subject of the formula:



Modelling Approach


Now that we have the FSPL formula in a useful format, we need to decide how we are going to test the '6dB increase' rule of thumb and look at other loss values. The easiest way to do this is to assume we have an AP that is set to a number of transmit values and test what the distance for a particular cell edge value.

For instance, a general useful cell edge is a value of -67dBm which is often used as the cell edge for voice-grade wireless networks. If we assume a range of tx power values for an access point, we know what the loss will be (in dB to our cell edge) - for example, if our AP is set to a tx power of 1dBm and we are using a cell edge of -67dBm, we know that our expected loss is 68dB (calc: 1dBm - (-67dBm) = 68dB). We can calculate the distance required to incur that loss and check the distance to our nominated cell edge. By varying the tx power of the theoretical AP, we can see how the distance to the edge of the cell varies.

The diagram below demonstrates the approach:


With a bit of help from Excel, we look at a whole range of transmit values, the distance to the cell edge and then compare the distance covered from the AP to the cell edge.


Power Level Comparison


The tables below show the application of the approach outlined above. They look at the distance to a -67dBm cell edge for a range of transmit powers from an initial value of 0dBm in 1dB increments up to 20dBm. As the power increases, we can see that the distance to the cell edge increases (as we would expect). The increase at each point is also expressed as a percentage increase, together with a proportional increase over the original 0dBm (1mW) power level. Interestingly, the figures produced verify the rule of thumb that states that a 6dB increase doubles the distance (highlighted in blue in the tables for both 2.4GHz and 5GHz below):



Band (GHz)EIRP (dBm)dB IncreaseCell Edge (dBm)Expected Loss (dB)Distance (m) to Cell Edge% Distance IncreaseProportion Distance Increase
2.40N/A-676722.2N/AN/A
2.411-676825.012.2%1.1
2.422-676928.025.9%1.3
2.433-677031.441.3%1.4
2.444-677135.358.5%1.6
2.455-677239.677.8%1.8
2.466-677344.499.5%2.0
2.477-677449.8123.9%2.2
2.488-677555.9151.2%2.5
2.499-677662.7181.8%2.8
2.41010-677770.4216.2%3.2
2.41111-677878.9254.8%3.5
2.41212-677988.6298.1%4.0
2.41313-678099.4346.7%4.5
2.41414-6781111.5401.2%5.0
2.41515-6782125.1462.3%5.6
2.41616-6783140.4531.0%6.3
2.41717-6784157.5607.9%7.1
2.41818-6785176.7694.3%7.9
2.41919-6786198.3791.3%8.9
2.42020-6787222.5900.0%10.0


Band (GHz)EIRP (dBm)dB IncreaseCell Edge (dBm)Expected Loss (dB)Distance (m) to Cell Edge% Distance IncreaseProportion Distance Increase
50N/A-676710.7N/AN/A
511-676812.012.2%1.1
522-676913.425.9%1.3
533-677015.141.3%1.4
544-677116.958.5%1.6
555-677219.077.8%1.8
566-677321.399.5%2.0
577-677423.9123.9%2.2
588-677526.8151.2%2.5
599-677630.1181.8%2.8
51010-677733.8216.2%3.2
51111-677837.9254.8%3.5
51212-677942.5298.1%4.0
51313-678047.7346.7%4.5
51414-678153.5401.2%5.0
51515-678260.1462.3%5.6
51616-678367.4531.0%6.3
51717-678475.6607.9%7.1
51818-678584.8694.3%7.9
51919-678695.2791.3%8.9
52020-6787106.8900.0%10.0

(Note: you can have a look at these sheets here: http://bit.ly/WiFiNigel-CellSizes)


Conclusions


The figures above speak for themselves. They confirm that 6dB increments increase the distance to the cell edge by 100% (i.e. double it). 

It's interesting to consider that each 3dB increment is (in real terms) a doubling of power. Therefore a 6dB (3dB + 3dB) increase is actually a quadrupling of power. To double the distance to the same cell-edge power level, transmit power has to increased by a factor of 4. 

What is interesting is that no matter what start value that is inserted in to the table (for any frequency), the distance increase (expressed as a percentage/proportion of the original distance) remains the same. This can be seen by comparing the 2.4GHz and 5GHz tables above - both have the same percentage increases despite being different frequency bands.

On the face of it, the distance increments and the percentage increments per dB appear to be almost linear in the tabulated values shown. But don't be fooled by this (as I was) - the increase in distance per dB is not a regular linear value - get hold of the sheets and have a look at this yourself by comparing the distance and percentage increase increment sizes..

Finally, please remember the values all apply in a free space environment, not one that includes lots of obstructions. They are only theoretical values which don't often apply in the real world, but are still very useful to consider.

OK, that's about as much RF math as I can stand - I'm off to have a migraine. Hope it's been useful.

(Note: the measurements expressed are from the AP to a cell edge (i.e. cell radius), not the coverage area of the cell. I'll leave you to work out the effect on the cell area, which is a whole new world of pain encompassing squared radius values...)



References