Zero DFS

当AP在DFS信道中出现时，需要等待60/600秒才能在该信道中开始传输帧。这里引入了一种将等待时间尽可能减少到零的机制。

考虑这样一个场景，其中Tx位于信道60。检测到雷达，关闭60信道的Tx，随机选择100信道。在信道改变后，在信道100中进行60秒的CAC，在Tx开始之前要没有任何雷达被检测到。这个60秒的持续等待是要消除的时间。

ETSI

在ETSI域实现Zero DFS后，考虑上面的场景。其中Tx在信道60中，而pre-CAC在信道100中。检测到雷达，关闭60信道的Tx，随机选择信道，例如选择100信道。信道改变后，如果在100信道完成了pre-CAC，那么就可以避免在100信道的等待。TX可以立即开始不用等待一段时间。硬件必需要兼容在一个信道上进pre-CAC，在另一个信道上进行Tx/Rx。

所有常规模式的信道切换(HT80_80除外)都应该像以前一样工作，在80_80中，次80可以是常规的或敏捷的。如果次80是敏捷的，那么第一个80中的Tx/Rx应该在信道变化期间保持不受影响。对pre-CAC-required列表进行初始化，从pre-CAC-required列表中选择一个信道执行pre-CAC(60/600秒)，并将信道移动到pre-CAC-done列表。如果在完成pre-CAC前，在第二段观测到雷达，则将信道移动到通知列表(NOL)。

在主段雷达检测后移动到DFS信道时的新信道切换逻辑:如果在新随机信道上已经完成了pre-CAC，则不需要CAC。

假设所有信道的列表包括[{42 HT80}， {58 HT80}， {106 HT80}， {122 HT80}， {138 HT80}， {155 HT80}]。NOl和pre-CAC done列表为空，而pre-CAC required列表包含[{58 HT80}， {106 HT80}， {122 HT80}， {138 HT80}]。从pre-CAC required列表中选择一个频道(例如106HT80)。在58HT80(段1)开始CAC，在106HT80(段2)开始pre-CAC。用户或ACS信道选择为60HT80=58HT80。

初始信道选择——尽管硬件同时使用主80和次80，但beacon只声明信道为HT80。从pre-CAC-required列表中选择一个信道(例如106HT80)， CAC在58HT80(段1)中启动，pre-CAC在106HT80(段2)中启动。

敏捷CAC和Primary CAC过期——从Pre-CAC-Required列表中选择一个通道(例如122 HT80)。Primary保持不变，pre-CAC开始于122 HT80(段2)。

在第二段探测到雷达——主段保持不变。二级标记通道[122 HT80]为雷达并将其添加到NOL。pre-CAC开始于138 HT80(段2)。

二级DFS引擎移动到VHT80或停留在同一频道，如果它完成CAC在所有频道。当主DFS引擎移动到非DFS通道时，将继续进行CAC。当主HT80探测到雷达时，不需要用新通道重新启动副DFS引擎。

当通道设置为80_80并且设置了agile位时，不保证固件不使用80_80模式发送数据包。当主HT80正在改变时，当wifi开启后发生第一个通道改变(VHT80_80)时，以及任何主通道改变后，都不能设置通道改变的敏捷标志。这种行为是必需的，因为HALPHY如果看到敏捷标志，就会绕过主HT80校准。（我的理解是只有80才可以使用副80进行PreCAC，如果设置80_80,主80和副80可能都在进行数据发送，没有空闲的可以进行preCAC）