Following my previous post on DFS, I’m testing a modern Extreme Networks AP410C with the Wifimetrix tool.
AP410C is a new cloud managed wi-fi 6 access point evolved from the Aerohive product line, now acquired by Extreme. Tested model: AP410C Rev: F, OS 10.1.3.0 (10.1r3).
As usual, the AP is on a DFS channel, Wifimetrix sends a simulated radar wave, and the packet capture is analyzed.
Test: channel switch
After detecting a simulated radar signal, the AP does not send a channel Switch Announcement action frame. It sends a beacon frame containing a Channel Switch Announcement information element with channel switch mode 1 (clients are not allowed to transmit during the switch), destination channel, count 8 (AP will switch after the 8th beacon is transmitted), last transmitted beacon count 1 (AP switching immediately before the next TBTT). This behavior is consistent, either with and without client stations associated to the AP.
Test: channel switch-back
The switch back to the original DFS channel happens after about 30 minutes and does not use any Channel Switch Announcement to inform the associated stations of the new channel.
I observed that when stations are associated to the AP, they keep transmitting on the same channel after the switchback, sending probes, retries, and eventually disassociating. I had a Windows10 laptop and an iPhone associated and streaming video (Youtube), both lost connectivity and did not reconnect to the original channel. Zero-wait DFS was enabled on the AP.
Impact assessment of channel switch
With AP410C it takes about 918ms (9 TBTT) from an initial radar detection to the move to a new channel, during which clients are not allowed to transmit (mode 1). This is way more that the maximum 150ms roaming hand-off time required for VoWiFi. I can figure out 2 scenarios:
- The client station remains associated to the AP, the voice call will suffer degradation during the channel switch.
- The client station decides to roam away to another AP, therefore voice calls and videoconferencing are not disrupted (provided FT is enabled or PSK is used).
Which of the two scenarios is more likely depends on the roaming decisions made by the client (if roaming is feasible at all, that is).
The disruption from a radar-induced DFS event is noticeable, but very limited and quickly recovered.
Impact of channel switch-back
After a defined amount of time on the new channel, the AP switches back to the original DFS channel without any announcement to the associated stations. There are two scenarios that come to my mind:
- The AP implements Zero-wait DFS or a similar mechanism: a client station on the channel fails to receive frames from the AP (beacons, ACKs) and either:
- somehow it discovers the AP on the new channel and moves, keeping the original association;
- or it roams to another AP.
- The AP performs a Channel Availability Check (CAC) before transmitting, the client station roams to another AP.
It is unclear to me how long the roaming will take, considering the time spent by the station sending retry frames, probes, listening to beacons on different channels. I tested an SSID on a single AP and experienced complete loss of connectivity.
My personal impression is that the channel switch back is even more disruptive to service than the initial radar-triggered channel switch. Where CAC is performed (without Zero-wait DFS mechanisms), service from the original AP is disrupted for 30 seconds or more.
Final thoughts
Mitigating the impact of DFS events seems to focus on roaming. Careful roaming design is called for, including secondary converage, 802.11k (which should be enabled anyway if DFS channels are used), Fast Transition and 802.11v.