Forum

I am a relative newcomer to 802.11n. I've been involved with plenty of 802.11a/b/g WLANs in enterprise environments in the past, but am only just now really getting up to speed with 802.11n as the demand is beginning to arise.

I work exclusively with the Cisco lightweight (controller-based) solution, and I only work with WLANs in Europe (the UK). So, most of what I will be outlining below is written from that perspective.

My current concerns surrounding 802.11n revolve around channel useage, in particular 40Mhz channels created by channel bonding.

My understanding is that for 2.4Ghz, due to the nature of the overlapping channels in that band, we are effectively stuck with a single 40Mhz channel by binding together 2 channels (e.g. 7 & 11) that will form a 40Mhz channel. Beyond this, there is simply not enough non-overlapping channel spectrum to form another 40Mhz channel. Therefore, in an enterprise environment, channel bonding on 2.4Ghz is pretty much impractical as you are stuck with a single 40Mhz channel (asssuming the Cisco solution previously mentioned) which obviously gives you a very limited channel plan.

So, for 2.4Ghz, I'm resigned to the fact that I'll be using 802.11n with no 40Mhz channels. So, looking at the current data sheet for a Cisco 1140 AP, I'm looking at a theoretical top client connection speed of (depending on the guard interval) maybe 130 - 144 Mbps (wireless connection speed, not client data throughput).

But, when I start looking at 5Ghz, the whole picture seems a lot less clear...

On the face of it, as the 5Ghz band uses non-overlapping channels we have plenty of spectrum to use and start bonding channels together to give us plenty of 40 Mhz channels.

In Europe, I believe we could theoretically pair up as follows:

* 36 & 40
* 44 & 48
* 52 & 56
* 60 & 64
* 100 & 104
* 108 & 112
* 116 & 120
* 124 & 128
* 132 & 136

This gives us (on the face of it) 9 x 40Mhz channels, which is a great number to create a nice easy channel plan to accomodate most situations without having to worry about co-channel interference.

But, upon digging in to the detail a little more, we have to start thinking about DFS, the mechanism that ensures that our WLAN won't interfere with commercial or military radar, or weather radar equipment. Access points which conform to 802.11a have to cease transmitting on a channel if they detect radar-type signals on the channel that they are operating on.

Looking at the 5Ghz channels that operate on the DFS-affected channels (52 - 140), this seems to suggest we have only 2 x 40 Mhz channels avalable that are not affected by DFS (i.e. 36 &40, 44 & 48).

I initially thought this wouldn't be too much of an issue, as I could rely on the Cisco radio resource management (RRM) to move away from any channels on which radar signals are detected. But, it appears that it isn't possible to use Cisco RRM when using channel bonding - a manual channel plan has to be implemented. If a radar signal is detected, then the channel will simply go down (as I understand things on the Cisco solution), and that part of the WLAN is down for a reasonably long period of time until the radar signals are no longer detected.

So, I guess that a good approach is to ensure that during the wireless survey for a new network, a check is done with a spectrum analyser for the presence of radar signals. In theory, if no radar is detected, then we should be able to use the channels which are potentially affected by DFS.

My main issue with this approach is that it is a huge assumption that radar signals not being present is 'normal', just because none were detected during the time that the survey was conducted. I'm guessing there are scenarios where there could be new radar sources that appear or false-positives caused by other sources, which could potentially cause an AP outage (...not to mention DOS attacks).

This seems to suggest that if I want to be ultra-safe and want to ensure maximum WLAN uptime, I have to avoid using the DFS-affected channels and am stuck with just 2 x 40Mhz channels in the 5Ghz band.

If my assertions above are correct (and I would be more than pleased to find out I am wrong), then I seem to be stuck with just 2 'safe' 40Mhz channels in the 5Ghz band. If I am correct in this, then I would appear to be far better off running just 20Mhz channels in the 5Ghz band and let RRM look after radar detection and channel allocation. This would also mean however, that client speeds (for instance using an 1140 AP) are again limited to 130 - 144 Mbps.

The reason I have rather laboured the various points as I understand them is that I had a conversation last week with a customer who has a new 802.11n WLAN and was fully expecting a 300Mbps WLAN network. I know there was probably a level of expectation-setting that should have been done by whoever sold the solution, but as-ever in the 'real world' this didn't happen. I want to be clear I have sufficient technical understanding to confidently convey the technical reasons why he won't hit 300Mbps (aside from the usual obvious issues with client types, 802.11 frame over-heads etc.).

I know there could be possible solutions for the DFS issue involving ongoing monitoring with spectrum analysers or 'clean air' solutions, but most customers I deal with don't have the time, money or technical expertise for such solutions (and, they won't pay for me to keep going back in to do it!). So, I have to provide them with a solution which is as robust and low-maintenance as possible.

My question is this: am I correct in my analysis of the 5Ghz DFS/channel bonding issue?

I'd also welcome any comments or corrections to the information I have outlined above. I've done a reasonable amount of reading on 802.11n, but still class myself as a newbie in this area.

Thanks for your time and any feedback you can provide.

Nigel.

Nigel

Very good post. You have raised some excellent points about the whole DFS business. The vast majority of all Wi-Fi installations will never "see" a true radar signal, but "false positives" are a big problem.

Radar signals are very complex. Many of the present DFS algorithms are not sufficiently sophisticated enough to properly discriminate between true radar signals and ?other stuff?.

You can contact the MOD and the UKCAA to see if there are any military bases/airports nearby. A google search of RAF, ARMY, RN, RM bases, airports etc will usually do just as well.

Be aware that there are some radar systems out there that not ?advertised? for security reasons.

http://www.mod.uk/DefenceInternet/Home/
http://www.caa.co.uk/
http://www.metoffice.gov.uk/

http://www-europe.cisco.com/en/US/docs/wireless/access_point/ios/release/notes/12_3_8_JEC.html

Years ago I was working at a satellite station in the Middle East. Out of nowhere our comms links suffered massive interference. Over 10,000 phone calls at a time were being cut off. I looked on the spectrum analyzer and told the senior people that it was a military radar. This was greeted with great scorn. ?We?re in the middle of a DESERT..there?s nothing out there !!? I was told. They all had a good laugh. Problem got worse and experts were flown in to no avail. One morning a cleaner came in very excited and told us ?Man comes out of hole in ground !!? Turns out that a military radar had been installed in the middle of the night over weeks, not far from us. It was camouflaged and could not be seen unless you were right on it. One of our neighbors was getting ready to invade and the military had put it in. A few calls to the embassy and the problem was solved.

DFS is necessary for protection of radar systems, but unfortunately causes big headaches for many Wi-Fi users. Unfortunately, many times DFS is a ?suck it and see? type of situation, whereby you have to put a pilot setup (for example ) in place to see if you have problems from radars or other devices ( causing false postives ). Although a spectrum analyzer is a useful device, the quality of the device and operator familiarity with radar signatures are quite important. Due to multiple technical factors ( as well as the huge number of different types of radar signatures ), positively determining radar interference can be a challenge. Multipath etc can cause radar signals to only ?appear? at your location at certain times ( depending upon radar boresight elevation, physical surroundings etc ). Cisco has log files for DFS events for some of it?s kit, but they really don?t tell you that much.

Wi-Max has it?s problems too.

http://www.muniwireless.com/2010/06/22/worldmax-shuts-wimax-in-amsterdam/

In summary:

Can radar cause problems ? Yes, but for the ?average? ( away from military, civilian etc radars ) install?no.

Can false postives cause problems ? Yes.

Can we ?scan? for radar using a spectrum analyzer before installation ? Good idea if you have the kit, but beware the caveats mentioned above, including the fact that due to propagation and hours of use, you may only "see" the radar signals at certain times.

Can logs be used ? Yes, but with caution. Most only say ?an event? has taken place.

Can false positives and radar cause disruption (channel changing?.assuming there is a ?good channel? to go to !! , 30 minute wait times etc ) ? Yes, but for ?most? installations these are not too much of a problem. Some places never suffer ?hits?.

Dave

I think I may have answered my own question on this...I just found this in some Cisco release notes for 5.1 code:

"[i]40-MHz channelization?In controller software releases prior to 5.1.151.0, only radios using 20-MHz channelization are supported by dynamic channel assignment (DCA). In controller software release 5.1.151.0, DCA is extended to support 802.11n 40-MHz channels in the 5-GHz band. 40-MHz channelization allows radios to achieve higher instantaneous data rates (potentially 2.25 times higher than 20-MHz channels).[/i] "

Looks like DCA for 40Mhz channels is supported after all....

For those unfamiliar with the terms DCA and DFS:

DCA mechanisms ( Dynamic Channel Assignment ) were originally designed to help mitigate the detrimental effects of co-channel interference. If the system detected excess co-channel interference on a particular AP or group of APs, new frequency assignments would be ?handed out? causing one or more of the APs to change frequency ( channel ) to something more appropriate ( as determined by the controller ).

In most modern controller based systems, the APs send back useful RF information at regular periods. The controller uses this information to make decisions about whether to cause frequency changes. This has been going on even prior to 802.11k.

DFS was designed specifically to help prevent Wi-Fi systems from causing interference with military and civilian radars operating the 5 GHz band. The system was orginally setup for the European theatre, but was rapidly adopted by the US and other countries.

DCA basically causes an AP or APs to change frequency in order to get ?better service?. This involves clients being disconnected ( disassociated ). It is often used when, for one reason or another, channels overlap.

DFS is designed to help prevent interference with radars. At the other end of the scale, even if a Wi-Fi system is not necessarily causing interference with a radar, that radar could cause interference with the Wi-Fi system. DFS could be helpful in that case. Interference calculations are very complex and involve multiple factors. It?s not always just a simple case of ?Well he?s causing interference to me, so I must be causing interference to him?.

For many Wi-Fi users, DFS can be ?a nuisance?, but is something we have to live with.

Many vendors nowadays tend to combine the two terms to describe some form of intelligent frequency agility.

http://wifi-doc.com/Cisco.Press-802.11.Wireless.Ne/1587051648/ch03lev1sec4.html

Dave

Dave,

Thanks for the feedback and reference material. Much appreciated :)

All the best.

Nigel.

You're welcome Nigel.

When I get some time, I'll put up a posting about how radar systems work and the similarities and differences between them and Wi-Fi systems.

Dave

Dave and Nigel.
Please also observe that the DFS cahnnels are unsuitable for voice. Handset do frequently roam and to find the best access point the rely on the roaming table built from information received from the APs.

The handset normally builds this table by passively listen to beacons and roam to a better AP when quality drops to a low level. If there is no suitable roaming candidate in the table, the handset can do a active scanning by probing and see if they may pick up an additional entry to store in the roaming table. This situation may of cause happen frequently if you are at the perimeter of your campus.

Active probing of a DFS AP is something that needs special attention and requires that the handset does a radar interference check.

Google for this document !
Dynamic Frequency Selection (DFS) and the 5GHz Unlicensed Band
by Mark Briggs, Principal Engineer at Elliott Labs.

------ Excerpt from above document

[quote]While master devices (APs) are required to employ interference detection capabilities, EN 301 893 does not require this feature for slave devices (STA) provided that they:

[list=1]Operate below a power level of 200mW
[u]Are not capable of initiating communication on a channel (in effect, this prohibits them from using active scanning to detect a wireless network)[/u]
May only operate on a channel under control of a device with the detection capability (a master device).[/list][/quote]

If teh handset chip does not support radar interference detection then active scannin gis not allowed and seamless roamiing will be more difficult and thus the DFS channels should be avoided.

Summary. In the FCC domain there will be 8 suitable voice channles at 20 Mhz, 4 if 40 Mhz channels are used In the ETSI domain there will be only 4 voice channes and as litlte as 2 if channel bonding is implemented using n-standard.

Cheers
Martin

Martin,

Is it also true that if a VoWiFi handset was associated with an AP on a DFS channel, and the AP detected radar, it would drop the handset immediately and thus disconnect the call?

Thanks,
Andrew

From Cisco Deployment guide for the 7825

[quote]DFS dynamically instructs a transmitter to switch to another channel whenever radar signal is detected. If the access point detects radar, the radio on the access point goes on hold for at least 60 seconds while the access point passively scans for another usable channel.[/quote]

A 60 seconds stop of traffic will be problematic for the call if the ahndset has no roaming suitable candidate to go to. I am not sure if a handset has a chance to roam becasue of this condition before the call drops.

In a controller based solution this may be mitagated by the Auto RMM system but with thick APs it may be another story.

I have to go to the airport to test!

Hi Every one,

I am new to this 802.11 standards. I am presently going through DFS section. Many regulatory domains require "In service monitoring". May I know what does this exactly mean? Does it asks for detection of radar signal during normal reception of WLAN packets. Is it possible to detect presence of radar signal from the received combination of Radar and WLAN signals with DFS detection threshold of -64dBm (as per regulatory domains).

Or does it says that WLAN system needs to schedule radar detection during In service monitoring such that AP is in ideal state and does not receive or transmit WLAN packets, so that if any presence of Radar above the threshold can be detected.

Which of the above perceptions are true as per In service monitoring is considered?? Please help me to have a clear idea with your valuable comments...

I knew that it may not be correct to put my question as a comment, but as many people involved in this discussion are aware of DFS, I would like to ask from you. 

Thank you very much in advance...