More aggressively moving back to DFS channels?

[JohnD]

On my home office network, the non-DFS 5GHz channels are super crowded, around 20 neighboring APs. As a result, I'm seeing DFS channels offer 30-50% more throughput than non-DFS channels.

Unfortunately my local police department's helicopter training course (no joke!) is right over my residence so every few days I get a DFS event.

My previous APs from another vendor would stay off the DFS channels for 30 minutes after a DFS event, then they move back to the DFS channel they were on.

However, on Meraki, I'm noticing that especially with channel width = 80MHz, after a DFS event, the AP no longer moves back to the DFS channel ever. So basically every 3-4 days I have to manually reassign DFS channels to my AP, and then they eventually get knocked off to 36 or 149 again, and then I have to repeat this process.

Is there any way (like via NFO) to get more aggressive auto channel selection back to DFS? I understand why some networks might find this not desirable, but for me, I'd rather move back to the DFS channel as soon as it's legally compliant to do so, as the throughput loss from using a non-DFS channel is simply too much.

It seems like if I use 40MHZ channels, AutoRF is more willing to change channels regularly including DFS channels. But at an 80MHz channel width, this isn't the case anymore. I know historically clients have had issues with 80MHz 802.11h channel changes but in this day and age, none of the clients I've tested have struggled with that.

[NolanHerring]

Assuming your on 26.7 firmware?

The issue might be the 3rd radio scanning and hearing DFS on one of the four 20MHz channels that the 80MHz comprises of, so it never really has an opportunity to go back. Which 80MHz have you tried using? UNII-2 or UNII-2e (58 vs 106). Or are they both getting hit hard by the chopper? GET TO THE CHOPPA!

[JohnD]

Correct, on 26.7 (BTW 26.7 is so much better than the older 26.x series)

I've tried both and UNII-2e tends to have more DFS events than UNII-2 but they both aren't immune from DFS.

I definitely understand the impact of 80MHz channels and 4x the DFS events. The main issue is that AutoRF doesn't seem to want to move channels in general at 80MHz -- https://documentation.meraki.com/MR/Monitoring_and_Reporting/Location_Analytics/Meraki_Auto_RF%3A__W...

"Our tests have found that moving from one 80Mhz channel to another can cause interruptions and thus we do not change from an 80Mhz channel if clients are connected. "

This doesn't seem true in my testing (anymore?) so I am really hoping there might be a NFO for this behavior.

(For example, right now my MR56 is hanging out on 161/80 and experiencing about 20% channel utilization. Meanwhile 56 is 0% occupied, and if I manually switch to 56 it will stay there for 24-48hrs and experience much better throughput.)

[NolanHerring]

I read this as it being in your house/apartment situation with only 1 AP. Is that accurate?

Honestly you might just be better off doing 40 or 20MHz

Stability > Performance

You only need so much goodput to do stuff, no real need for jigabytes of bliss 😃

[JohnD]

I've got two APs in order to achieve >400mbps in each office area. That is a strict requirement for me, otherwise wifi is simply not worth the effort. Each day I transfer about 50-100GB of firmware images across 10 devices to start my work day. If they cannot get this done then I cannot start working. That's why throughput is more important than goodput for me, unfortunately, not to mention the 149-161 area has no goodput and the 36-48 channels are basically the only non-DFS usable channels.

I can settle for goodput and 40MHz channels but I'd rather not when I only have 2 APs in my deployment and 80MHz performs measureably better, DFS or not.

As far as DFS regulations, I am within FCC jurisdiction and I have thoroughly reviewed DFS rules for my jurisdiction and I'm not in violation. Meraki doesn't even support any channels between 5600MHz and 5650MHz, at any width, unlike some enterprise competitors that do implement the 1-24hr backoff rules.

The only defined non-occupancy period for US FCC DFS channels that Meraki supports is 30 minutes (well 34 minutes including off-channel CAC time).

I believe the ETSi rules are slightly more restrictive but I have APs on hand from 3 other enterprise vendors and they are all capable of automatically moving back to 80MHz DFS channels approximately 30 minutes after a DFS event.

All of my clients are capable of 80MHz channel width on 5GHz. In fact half of them are capable of 160MHz but that's not practical to deploy.

Definitely please let me know if I'm in violation of any regulatory limits. I've tried my best to do my homework here and I'm even voluntarily registered with both of the nearest airports.

[Uberseehandel]

I get pinged all the time by the Apaches, but I am deliberately trailing my coat-tails, as it amuses us all when they do the bee-dance.

I would suggest you try turning down the TX value as much as you can whilst maintaining adequate WiFi coverage, don't go looking for trouble, as it were. Also, if the signals don't reach the APs, they won't react.

Some wallboard has foil on one side, for insulation purposes, it blocks WiFi pretty effectively.

[Uberseehandel]

You appear to be running foul of the CAC time, which under certain circumstances can extend to 240 minutes.

Excerpts from my working notes - 

SPECTRUM MANAGEMENT SERVICES

Because the 5 GHz spectrum used by Wi-Fi equipment is also used by others, defence, satellite communications, the maritime and aviation sectors, and weather stations when spectrum managers had anticipated they would move to other parts of the spectrum, steps had to be taken to allow this portion to be shared.

Therefore regulations were introduced that require Wi-Fi access points to

• change channels if other users (weather radar) are detected (DFS)
• reduce transmit power if other users (satellite communications) are detected (TPC)
• check that an alternative channel is not being used before using or switching to it (CAC)
• make uniform use of the available channels (DFS)

CHANNEL AVAILABILITY CHECKING (CAC)

Before a device can commence operating on a channel which requires the Channel Availability Checking function to be active, it has to listen for a set period to ensure that the channel is not already in use.

PARAMETER	VALUE
Channel Availability Check Time	60 seconds
Minimum Off Channel CAC Time	6 minutes
Maximum Off Channel CAC Time	4 hours
Channel Move Time	10 seconds
Channel Closing Transmission Time	1 second
Non-Occupancy Period	30 minutes

NOTE 1 For channels whose nominal bandwidth falls completely or partly within the band 5 600 MHz to 5 650 MHz (Channels 120, 124 & 128) the Channel Availability Check Time shall be 10 minutes

NOTE 2 For channels whose nominal bandwidth falls completely or partly within the band 5 600 MHz to 5 650 MHz the Off Channel CAC Time shall be within the range 1 hour to 24 hours

Table 6 Channel Availability Check Parameters - ETSI EN 301 893 V1.8.0 (2015-01)

In the event that an access point is required to switch channels, all devices communicating with the access point are supposed to stop transmitting until advised by the access point to resume transmissions on the new, and available, channel. This channel will continue to be used until a radar system using the channel is detected, in which case the access point will find another available channel that is free of radar signals. The access point uses the protocols set out in IEEE802.11h to advise the connected client devices (described as slave devices by the spectrum management organisations) that transmissions should cease and that they should not transmit until advised that a clear channel has been found.

I have pages of notes relating to this. There are good reasons to reassess use of 80MHz wide channels as not all client devices can make use of the additional bandwidth.

I don't know what domain you are in, but would suggest investigating legal use of the spectrum above the DFS affected channels. Life is going to get worse, not better.