802.11ac DFS channels and radar

[Bruce123]

We have been testing the use of DFS channels (in the 5Ghz band) and are experiencing quite frequent "radar" detection events, which is causing the affected AP to drop to a non-DFS channel for 30 mins, before trying again.

 

Unfortunately, the majority of channels on the 5Ghz are DFS:

 

Number of 80Mhz wide channels: 1 non-DFS and 4 DFS

Number of 40Mhz wide channels: 2 non-DFS and 8 DFS

Number of 20Mhz wide channels: 4 non-DFS and 16 DFS

 

Which doesn't leave us much to play with (in fact it's not much better than 801.11bg 2.4Ghz, where there are 3x 20Mhz channels available)

 

I just wondered if anyone else were using thee DFS chnanels, and if so how many radar events are being detected? Is there anything that we can do to reduce the number of these events? (I suspect that some are false positives). Perhaps using 40Mhz wide channels could half the probability of a radar signal being detected?

 

Kind Regards,

 

Bruce.

[chazzy2501]

You can use the UK spec 2.4ghz of 1,5,9,13 to gain that precious extra channel.

 

The Ubiquity Unifi UAP-AC equipment limits our site to the lower 36 to 48 channels.

[AlanD]

Yes, I often think that those idealists who have a vision of doing away with ICT suites and using cabinets of laptops are misguided by the wireless salesmen. Yes - you can get gigabit speeds - in a large hall away from other APs, but not in neighbouring classrooms.

We use 40MHz channels (Aerohove) and let the APs decide - and to be fair Aerohive seems to do it well. I suppose I might be looking to see if the radar detection was limited to certain channels and use a script to avoid the AP using them.

[njc235]

People on multi cell solutions never listen to Meru (now Fortinet) but often wish they'd at least taken a trial! The single channel solution only needs, yeah you guessed it, one channel.

[Bruce123]

People on multi cell solutions never listen to Meru (now Fortinet) but often wish they'd at least taken a trial! The single channel solution only needs, yeah you guessed it, one channel.

 

We are using Meru/Fortinet's Virtual Cell operating on a single non-DFS 80Mhz channel and it works well for what it was designed for ("zero handoff"). The problem is, it struggles in areas of high client density (there is just too much traffic on the single channel). So we are testing "channel layering" with DFS channels (which are the only other 5Ghz channels available). It resolves the contention issue in the areas of high client density, but we would ideally like to reduce the frequency of "radar" detection events (which causes the affected AP to drop to the main non-DFS channel / merge back into the main virtual cell for 30 minutes, before trying the DFS channel again).

 

Thanks,

 

Bruce.

Edited February 4, 2017 by Bruce123

[AlanD]

No. You definitely don't want to use 1,5,9, and 13. This was often tauted in pre "n" days when spectrum usage at the edge of the channel was low. With "n" data rates - higher QAM etc the use at the edge of the channel is as high as anywhere else. And you WILL get significant cross channel interference using 4 channels. And your total through put WILL be less than using 3 channels with better spacing. There might be an argument for using Channels 1, 7 and 13 because that will give you better separation - but not all clients can connect using channel 13. Remember channels are not completely confined to 20 to 40MHz - there is always overspill - and that overspill will degrade data rates in the neighbouring channel. There was a CISCO paper on this showing all the maths and graphs - and their conclusion was Don't use 4 channels.

[Bruce123]

We have been testing the use of DFS channels (in the 5Ghz band) and are experiencing quite frequent "radar" detection events, which is causing the affected AP to drop to a non-DFS channel for 30 mins, before trying again.

 

Unfortunately, the majority of channels on the 5Ghz are DFS:

 

Number of 80Mhz wide channels: 1 non-DFS and 4 DFS

Number of 40Mhz wide channels: 2 non-DFS and 8 DFS

Number of 20Mhz wide channels: 4 non-DFS and 16 DFS

 

Which doesn't leave us much to play with (in fact it's not much better than 801.11bg 2.4Ghz, where there are 3x 20Mhz channels available)

 

I just wondered if anyone else were using thee DFS chnanels, and if so how many radar events are being detected? Is there anything that we can do to reduce the number of these events? (I suspect that some are false positives). Perhaps using 40Mhz wide channels could half the probability of a radar signal being detected?

 

Kind Regards,

 

Bruce.

 

I monitored the number of DFS events logged each day for one week and there is a close correlation with the amount of WiFi usage here in the College (high usage Mon-Fri and very low Sat-Sun), suggesting that most of these events are actually "false positives" (see image).

 

Perhaps caused by WiFi frame collisions and the AP seeing the resulting corrupt frame as "potentially a radar signal", or misbehaving WiFi clients?

 

Thanks,

 

Bruce.

 

DFS Radar Events.bmp

[AlanD]

Hmmm...OK as you say, certainly looks like a significant number of false positives. (And sounds as if you are ahead of my thinking on this)

I guess a half term or holiday (are you a college/school?) will help identify if the weekdays ones come down....but I'm quite alarmed at even the number during the weekend - which would seem to be either somebody's device (if they are in working at that time..) or (and more likely) the access points themselves. Again I would be nagging the hell out of Meru/Fortinet about it.

 

I have been thinking about the power reduction strategy.....and I'm not sure that is the best option with Meru's single channel - and the reason is that clients always transmit at maximum power and I'm not sure how that affects Meru's strategy. Might be better to set up layers so that one block of rooms (possibly a whole floor) is on one layer (use a 40MHz channel) and next block a different layer, etc - only reusing the first channel when some distance away (of course without DFS you soon run out of layers...and of course you lose the zero hand off - although devices are pretty good at migrating these days)...clearly you can (and have done) waste a lot of time experimenting with this. I am thinking/wondering that maybe Meru's strategy is good with a high number of clients on one or two APs - because it significantly reduces the numbers of collisions) but when you have a very large number of rooms each with an access point that can see many of the others - perhaps it begins to fall apart....but that's no excuse if the APs are creating their own false positive radar detections - they really need to do something to stop that.

[Bruce123]

Hmmm...OK as you say, certainly looks like a significant number of false positives. (And sounds as if you are ahead of my thinking on this)

I guess a half term or holiday (are you a college/school?) will help identify if the weekdays ones come down....but I'm quite alarmed at even the number during the weekend - which would seem to be either somebody's device (if they are in working at that time..) or (and more likely) the access points themselves. Again I would be nagging the hell out of Meru/Fortinet about it.

 

I logged the number of DFS events over our half-term week (13-17 Feb Mon-Fri) and there is about half the number of events compared to a term-time week Mon-Fri. There was some wireless usage even over half-term by a small number of classes, which might explain the increased compared to the weekend.

 

The first week shown is a term-time week (for comparison) and the second week shown is during half-term week.

 

I have been thinking about the power reduction strategy.....and I'm not sure that is the best option with Meru's single channel - and the reason is that clients always transmit at maximum power and I'm not sure how that affects Meru's strategy. Might be better to set up layers so that one block of rooms (possibly a whole floor) is on one layer (use a 40MHz channel) and next block a different layer, etc - only reusing the first channel when some distance away (of course without DFS you soon run out of layers...and of course you lose the zero hand off - although devices are pretty good at migrating these days)...clearly you can (and have done) waste a lot of time experimenting with this. I am thinking/wondering that maybe Meru's strategy is good with a high number of clients on one or two APs - because it significantly reduces the numbers of collisions) but when you have a very large number of rooms each with an access point that can see many of the others - perhaps it begins to fall apart....but that's no excuse if the APs are creating their own false positive radar detections - they really need to do something to stop that.

 

I think the power reduction strategy only works (up to a point) because typical clients don't typically transmit at the maximum power permissible by the standard (i.e. 200mW ERP for 5Ghz and 100mW ERP for 2.4Ghz, if memory serves). In additional to this, their antennae tend to be smaller with significantly lower gain. So I imagine a typical mobile phone's (or laptop) transmit "coverage" is probably a lot less than an AP's transmit "coverage".

 

We did consider the one layer per floor strategy, but there are disadvantages;

 

1) If there are a high density of clients on a particular floor, you could still end up with too high channel utilization on the floor.

 

2) We would probably need to utilize DFS channels, as the two 40Mhz non-DFS channels probably wouldn't be sufficient to avoid contention between 3,4,5 floors. And by putting all APs on one floor into the same DFS channel it could put wireless on the whole floor "at risk" if all APs on the floor drop down simultaneously. Although I guess they may be able to roam to the layer on the floor above or below.

 

However, this strategy is mentioned in one Meru's guidance documents we found on layering.

 

I think you are right about a high number of APs within range of each other causing issues with single cell when there are multiple areas of high density.

 

The DFS detection issue probably relates to an algorithm embedded on the WiFi chip-set of the AP, which for the 832 would appear to be a Broadcom chipset. The DFS event is reported by the Chipset to the OS of the AP, and then onto the controller itself. But I just wonder if this particular chipset has more issues with false positives when used in a virtual cell, compared to micro cell?

 

Kind Regards,

 

Bruce.

Edited February 20, 2017 by Bruce123

[localzuk]

My question regarding this is - why is using DFS an issue. The whole point of the system is that they dynamically adjust if there is a radar hit. The re-association time is pretty small is it not? So, for our average use networks (we don't really have much wireless realtime data needs, unlike, say, medical equipment or the like), is using the DFS channels not acceptable?

 

We've got a 5Ghz P2P link in place between 2 buildings and in over a year it hasn't been an issue - and that's using DFS channels.

[Bruce123]

My question regarding this is - why is using DFS an issue.

 

I am sorry, are you asking why DFS events we are experiencing could be an issue for the wireless / connected devices?

 

Or are you asking why we are experiencing this level of DFS events?

 

The whole point of the system is that they dynamically adjust if there is a radar hit.

 

The data suggests a lot of these DFS events are actually "false positives" (why would weather radar decease at half term week?)

 

The re-association time is pretty small is it not?

 

It's not just the re-association time, it's the issue of contention on the single channel when APs drop down to the same (non-DFS) channel.

 

So, for our average use networks (we don't really have much wireless realtime data needs, unlike, say, medical equipment or the like), is using the DFS channels not acceptable?

 

That depends very much on how the wireless network is being used, who is using it and what level of service they expect. In our case, it matters. Much of the advise I've read online is to avoid DFS channels (if at all possible) for this reason.

 

We've got a 5Ghz P2P link in place between 2 buildings and in over a year it hasn't been an issue - and that's using DFS channels.

 

Again, are you saying you don't experience any DFS events on the two ends of the links? Or do you not monitor this? Which DFS channel is it setup to use?

 

Or, that you are experiencing DFS events, but that you don't notice it causing any issues on the link?

 

If it's a point-to-point link, does it really need to use any DFS channels at all?

 

Could it not just be setup to use the one 80Mhz non-DFS channel?

 

We use DFS channels in-doors to reduce the contention in the airwaves generated by clients/APs (i.e. more collision domains), but in a directed point-to-point this wouldn't be an issue.

 

Kind Regards,

 

Bruce.

Edited February 20, 2017 by Bruce123