Cisco Meraki、HPE Aruba 與 Ruckus 上的 DFS 雷達事件：頻道變更診斷清單

要在符合 IEEE 802.11h 標準下運作的 Cisco Meraki、HPE Aruba 或 Ruckus WiFi 網路中診斷並解決 DFS 雷達事件，請分析您的控制器記錄以找出雷達偵測。一旦偵測到，無線基地台必須在 10 秒內撤離該 5GHz 頻道，且在 30 分鐘內不得返回。

您的 5GHz 網路上，DFS 雷達事件是什麼樣子？

動態頻率選擇 (DFS) 可讓 WiFi 與雷達共用部分 5GHz 頻段。IEEE 802.11h 定義了此機制。主管機關則設定了時間規則：美國為 FCC 的 47 CFR Part 15.407，歐洲各地則為 ETSI EN 301 893。在 ETSI 地區，頻道 52 至 64 以及 100至 140 為 DFS 頻道。FCC 規則則額外增加了頻道 144。

當無線基地台 (AP) 偵測到雷達時，其處理順序是固定的：

1. 偵測。 無線電將其運作頻道上的脈衝模式與雷達特徵進行比對。
2. 頻道切換公告 (CSA)。 AP 在其信標中加入 CSA 元素，告知用戶端新頻道以及移動前的倒數計時。
3. 頻道更換。 無線電必須在 10 秒內停止在該頻道上傳輸。
4. 非佔用期。 該頻道在至少 30 分鐘內禁止使用。
5. 頻道可用性檢查 (CAC)。 在啟用 DFS 頻道之前，無線電必須至少監聽 60 秒。在 ETSI 地區，頻道 120、124 和 128 (5600 - 5650 MHz) 與氣象雷達共用，該處的檢查需持續 10 分鐘。

訪客體驗到的情況取決於其裝置。遵守 CSA 的用戶端會跟隨 AP，但會有短暫停頓。忽略 CSA 的用戶端則會斷開連線、重新掃描並重新關聯，通常會連到 2.4GHz 或鄰近的 AP。如果 AP 移動到尚未通過檢查的 DFS 頻道，5GHz 無線電可能會保持靜音一分鐘或更長時間。

需要留意的模式：

• 單一 AP 或一組鄰近 AP 上的所有用戶端在同一時刻全部斷線。
• AP 在不同的頻道上重新提供服務，通常是 36 到 48 之間的非 DFS 頻道。
• 此變更發生在您排定的頻道最佳化時間之外。
• 相同的 AP 重複此模式，有時是在一天的相似時間。
• 2.4GHz 的負載驟增，同時 5GHz 的用戶端消失。

通常是什麼原因導致 DFS 頻道變更？

真實雷達

在歐洲，5600 - 5650 MHz 範圍內的氣象雷達是常見的真實來源。在美國，主要機場的終端都卜勒氣象雷達 (TDWR) 使用相同的範圍。視線傳播比距離更重要。戶外 AP、高樓層和玻璃帷幕牆偵測到的雷達，是低樓層 AP 永遠看不到的。

單憑鄰近程度很難預測。許多機場監視和海上導航雷達運作於其他頻段，遠在 5GHz 之外。港口旁的場所可能永遠不會記錄到一次雷達事件。您的事件記錄是證據，而不是地圖。

誤報

DFS 誤報是指在沒有雷達存在的情況下觸發了雷達偵測。無線電將突發的能量讀取為雷達脈衝模式。典型的觸發因素包括：

• 來自無線視訊傳輸設備或故障設備的脈衝式非 WiFi 干擾；
• 來自附近 AP 或相鄰通道上點對點連線的強大傳輸；
• 無線電或韌體瑕疵，通常製造商會在軟體版本更新中修正。

判別關鍵在於孤立性。一個 AP 在不同通道上記錄了重複的事件，而具有相同空間視野的鄰近 AP 卻完全沒有記錄。

寬通道會增加遭遇真實與虛假偵測的風險。一個 80 MHz 通道包含四個 20 MHz 子通道，在其中任何一個子通道上偵測到訊號，都會移動整個通道。

類似的非雷達變化

通道規劃工具會因應干擾和負載而移動無線電。Meraki Auto RF、Aruba ARM 與 AirMatch，以及 Ruckus ChannelFly 與 BackgroundScanning 都會在沒有雷達觸發的情況下更改通道。AP 重新啟動和功率變化也會導致用戶端斷開連線。這些故障需要不同的修正方法，因此在排除任何問題之前，請先確認原因。

您如何確認斷線是否由雷達引起？

請依序執行以下檢核清單：

1. 鎖定問題時間與地點。 取得精確到分鐘的時間，以及房間、樓層或區域。
2. 擷取通道變更事件，針對服務該區域的 AP，讀取前後各一小時的記錄。
3. 讀取記錄原因。 雷達（radar）或 DFS 原因可確認此為起因。而干擾、雜訊或最佳化原因則可排除此因素。
4. 注意通道。 集中在 120、124 和 128 的事件通常指向氣象雷達。
5. 計算受影響的 AP 數量。 多個鄰近 AP 同時發生，表示存在真實的雷達。單一 AP 則可能代表虛假陽性。
6. 尋找每週規律。 定期重複出現表示雷達具有固定的時程或掃描週期。
7. 檢查通道寬度。 僅在 80 或 160 MHz 通道上出現的事件，代表寬度是問題的一部分。
8. 閱讀韌體版本說明，查看您 AP 型號的 DFS 偵測修正。

如果您運行 Purple 顧客 WiFi，各場域的登入量可以提供交叉比對。某個場地與雷達事件時間相吻合的急劇下降，即可證實對顧客造成的影響。

如何在 Meraki、Aruba 和 Ruckus 上解決 DFS 事件？

製造商	雷達事件顯示位置	通道規劃工具	您在哪裡限制通道
Cisco Meraki	篩選 DFS 事件後的無線網路事件記錄；每個 AP 的 RF 頻譜頁面	Auto RF	RF 設定檔通道清單，套用至受影響的 AP
HPE Aruba	控制器或 Instant 叢集上的 ARM 歷程記錄；AOS 8 與 Aruba Central 中的 AirMatch 事件	ARM (AOS 6, Instant), AirMatch (AOS 8, AOS 10)	AP 群組之無線電設定檔中的允許通道清單
Ruckus	用於雷達偵測的 SmartZone 事件與告警	ChannelFly 或 BackgroundScanning	專用區域或 AP 群組的無線電設定

Cisco Meraki

Meraki 會將雷達偵測記錄在事件記錄中，並標記為 DFS 事件，指出 AP 和頻道。請依事件類型與客訴時間範圍進行篩選。每台 AP 的 RF 頻譜頁面會顯示使用率和干擾，這能將雷達干擾與網路擁塞區分開來。若要防止重複發生，請在 RF 設定檔的 Auto RF 中移除有問題的頻道。僅將該設定檔套用至受影響的 AP。Meraki 官方的 DFS 說明文件包含了確切的操作步驟。

HPE Aruba

ARM 歷史記錄會列出每次頻道變更及其原因，而雷達偵測會顯示為一個獨立原因。AirMatch 集中建構頻道規劃，但雷達訊號觸發會迫使 AP 立即進行切換。因此，DFS 頻道在午後非排程的時間點發生變更，是一個強烈的線索。請在僅包含受影響 AP 的 AP 群組無線電設定檔中限制頻道。如果訪客重新連線後被重新導向回登入頁面，這屬於不同的故障，請參閱 HPE Aruba captive portal 故障排除：重新導向、憑證與 walled garden 檢查清單。

Ruckus

當 AP 偵測到雷達時，SmartZone 會引發事件，指出 AP 和頻道。檢查該時間範圍內的事件和警報，然後將其與 ChannelFly 或 BackgroundScanning 活動進行比較。若 Ruckus DFS 頻道變更背後沒有雷達事件，則是規劃程式的決策，而非 DFS 所致。請在專屬區域或 AP 群組的無線電設定中移除有問題的頻道。

在這三個平台上，僅需變更受影響的 AP 即可。在整個場域中排除頻道會降低那些從未偵測到雷達的 AP 的容量。

您是否應該在機場、港口或氣象雷達附近停用 DFS 頻道？

預設不建議停用。排除 ETSI 地區的所有 DFS 頻道後，僅會剩下四個 20 MHz 頻道：36, 40, 44 和 48。FCC 規則會剩下九個頻道，另外加上 149 至 165。在高密度場地中，四個頻道會迫使 AP 共用空中時間，並使每台用戶端裝置的速度變慢。請讓記錄來做決定。

您的記錄顯示內容	可能原因	建議	剩餘的 20 MHz 頻道 (ETSI / FCC)
數台相鄰 AP 上的事件，集中在 120 - 128	氣象雷達	在受影響的 AP 上排除 120, 124 和 128	16 / 22
每天在多台 AP 上，大多數 DFS 頻道皆發生事件	附近有強烈雷達	僅在受影響的 AP 上排除 DFS；在其他地方保留它	受影響的 AP 上為 4 / 9
單一 AP 上重複發生事件，頻道多變	誤判	更新韌體，測試或更換無線電硬體，保留 DFS	19 / 25
僅在 80 或 160 MHz 頻道上發生事件	頻寬暴露	調降至 40 或 20 MHz，保留 DFS	19 / 25
頻道發生變更，但無雷達記錄	規劃程式或干擾	解決干擾與功率問題，保留 DFS	19 / 25

實際情境：區域機場附近的飯店

一家位於 ETSI 地區、擁有 180 間客房的飯店，距離設有氣象雷達的機場 3 公里。入住朝西高樓層的房客反映，大多數下午時段會斷線。事件記錄顯示，一週內在 46 台 AP 中的 11 台上發生了 63 次雷達事件，全部集中在頻道 120 到 128。團隊將這 11 台 AP 移至排除氣象頻道的設定檔，並設定為 40 MHz 頻寬。在接下來的四週內，該飯店記錄到的雷達事件降為零。櫃檯收到的 WiFi 抱怨從每週 14 次減少到 2 次。其他 35 台 AP 則保留了所有 DFS 頻道。如需了解更多關於飯店部署的資訊，請參閱 飯店。

實戰案例：擁有一台雜訊 AP 的零售連鎖店

一家擁有 120 家分店的零售連鎖店發現，其中一家分店在兩週內於頻道 52、100 和 116 上記錄了 30 次雷達事件。同一家分店中的鄰近 AP 均未記錄任何事件，這指向了誤報。該 AP 型號的候選版本說明中列出了 DFS 偵測修正，因此團隊升級了韌體。然而事件仍在發生，隨後該 AP 在保固內進行了更換。該分店的雷達事件降至零，顧客在收銀台區域不再斷線。整個連鎖體系保留了所有 19 個頻道。多據點訪客網路存取請參閱 零售。

實戰案例：港口旁的市政廳辦公室

一個市政 IT 團隊計劃停用鄰近商業港口之辦公室的 DFS。三十天的記錄顯示完全沒有任何雷達事件。頻道變更其實是源於規劃人員對鄰近租戶網路的反應。團隊保留了 DFS，降低了發射功率並修正了頻道規劃。每週斷線回報從 9 次降至 1 次。

如何防止 DFS 事件再次干擾房客？

• 在高密度場域中使用 20 或 40 MHz 頻道。較窄的頻道可減少暴險並增加重複使用率。
• 僅在受影響的 AP 上，針對事件集中在 120 到 128 的地方，精準排除氣象頻道。
• 保持韌體為最新版本，並閱讀每個版本說明中的 DFS 修正。
• 每月審查 DFS 事件，並對每週記錄超過少數幾次的任何 AP 發出警報。
• 為 6GHz 做好規劃。6GHz 頻段沒有 DFS 要求，因此 WiFi 6E 和 WiFi 7 用戶端可以完全避免雷達轉移。
• 將 RF 與訪客網路存取分離。Purple 作為與硬體無關的雲端重疊網路，運行於 Cisco Meraki、HPE Aruba、Ruckus、Juniper Mist、Ubiquiti UniFi、Cambium、Extreme 和 Fortinet 之上。您的控制器掌管頻道規劃，而 Purple 掌管訪客登入。在 2024 年，Purple 在全球超過 80,000 個實體場域中處理了 4.4 億次登入（Purple 數據）。

常見問題

Purple Guest WiFi 是否支援我們現有的 Meraki、Aruba 或 Ruckus 基地台？

是的。Purple Guest WiFi 是一個與硬體無關的雲端重疊網路，可運行於 Cisco Meraki、HPE Aruba 和 Ruckus，以及 Juniper Mist、Ubiquiti UniFi、Cambium、Extreme 和 Fortinet。您可保留既有的基地台、控制器和 RF 設定。Purple 在此基礎上增添了訪客登入、自主選擇同意和第一方數據。無需汰換既有設備，且您的 DFS 設定仍由您掌控。

Purple 會變更我們的 DFS 或頻道設定嗎？

不會。Purple 不會設定無線電通道、通道寬度或發射功率。這些設定仍保留在 Meraki Auto RF、Aruba ARM 或 AirMatch，以及 Ruckus ChannelFly 或 BackgroundScanning 中。Purple 在無線電層之上處理訪客驗證與數據擷取。這種分離讓您可以在廠商的儀表板中解決 DFS 問題，而無需變動訪客登入體驗，也能在不影響射頻的情況下變更登入設定。

停用 DFS 通道是否符合法規？

是的。ETSI EN 301 893 與 FCC Part 15.407 要求在您使用的任何 DFS 通道上進行雷達偵測。兩者皆未要求您必須使用 DFS 通道。排除這些通道一向符合法規。您絕對不能做的是在停用偵測的情況下在 DFS 通道上運作。排除通道的實際代價是容量：在 ETSI 地區，移除每個 DFS 通道會使原有的 19 個 20 MHz 通道減少到只剩 4 個。

我們是否需要新的無線存取點來避免 DFS 問題？

通常不需要。大多數 DFS 問題都可以透過設定來解決：在受影響的 AP 上排除氣象通道、變窄通道寬度或更新韌體。當某個無線電在更新韌體後仍持續產生偽陽性，或者當您要增加 6GHz 容量時，更換設備才有意義。6GHz 頻段沒有 DFS 要求，因此支援 WiFi 6E 和 WiFi 7 的無線存取點能為支援這些技術的用戶端免除雷達移轉的問題。

在繁忙的場地中排除 DFS 通道會損害訪客 WiFi 嗎？

會的，如果您在整個場所中排除它們。在 ETSI 地區，4 個 20 MHz 通道無法在體育場、會議中心或大型飯店中將數十個 AP 分開。AP 最終會共享空口時間，導致每位訪客的吞吐量下降。請僅在記錄雷達的 AP 上排除通道，並在其他所有地方保留 DFS。這種方法可以在不放棄容量的情況下控制問題。

英國、歐洲和美國之間的 DFS 規則是否不同？

是的。英國和歐盟遵循 ETSI EN 301 893，該標準將 DFS 應用於通道 52 至 64 以及 100至 140。它還要求對氣象通道 120、124 和 128 進行 10 分鐘的可用性檢查。美國遵循 FCC Part 15.407，該標準增加了通道 144 並保留了 9 個非 DFS 通道。兩者都要求在偵測到雷達後至少 30 分鐘內不得佔用。

MSP 能否在混合廠商的資產中診斷 DFS 事件？

可以，但雷達事件存在於各個廠商自己的工具中：Meraki 事件記錄、Aruba ARM 歷程記錄或 AirMatch 事件，以及 SmartZone 事件和警報。MSP 應該標準化檢查清單而非工具，並記錄每次事件的時間、通道、AP 數量和原因。Purple 跨所有這些廠商為您提供一個統一的訪客存取平台，而射頻診斷仍保留在各個控制器中。