【実務・中級編】 DFS (Dynamic Frequency Selection) の動作とレーダー検知 – 家庭用ネットワーク・IoT・モバイル通信実践ガイド

【Wi-Fiの裏側】DFSとレーダー検知のリアル：CACの待機時間とインフラエンジニアが知るべきチャネル退避の全貌

やあ、ネットワークの海を日々パケットと一緒に泳いでいるエンジニアの皆さん。
オフィスや自宅で「なんだか急にWi-Fiの通信速度が落ちた」「特定の5GHz帯のSSIDだけ数分間ロストする」なんて謎の怪奇現象に頭を抱えたことはないだろうか？

その犯人、実はあなたのルーターの頭脳が真面目に働いた結果である「DFS（Dynamic Frequency Selection）」かもしれない。

教科書的には「気象レーダーなどとの干渉を防ぐための機能」の一言で片付けられるこのDFSだが、いざ現場のインフラ設計やトラブルシューティングに直面すると、この仕組みがなかなかに厄介な挙動を引き起こす。今回は、Wi-Fiの5GHz帯（W53/W56）を支えるDFSの裏側と、レーダー波を検知した際のシビアなパケットの現実について、現場の知見を交えて徹底的に解説しよう。

—

1. DFSとは何か？ なぜ5GHz帯でレーダーを避ける必要があるのか

私たちの身の回りを飛び交うWi-Fiは、電波という有限の資源を共有している。特に5GHz帯（W53：チャンネル52〜64、W56：チャンネル100〜140）は、航空管制レーダー、気象レーダー（気象庁のドップラーレーダー等）、そして防衛用のレーダーといった「プライマリユーザー（優先利用者）」と周波数を共有（共用）している特等席だ。

Wi-Fiルーターやアクセスポイント（AP）は、これらに対して「セカンダリユーザー（次点利用者）」として居候させてもらっている立場にすぎない。だからこそ、「レーダー波を検知したら、速やかにそのチャネルから立ち退かなければならない」という絶対のルールがある。この動的なチャネル回避の仕組みこそがDFSだ。

もしあなたのAPがレーダー波を検知したのにそのチャネルに居座り続けたらどうなるか？ 気象レーダーの観測データにノイズが混ざり、竜巻やゲリラ豪雨の予報が遅れるという、人命に関わる大惨事につながりかねない。Wi-Fiの安定接続は重要だが、社会インフラの安全の前にはひれ伏すしかないのだ。

—

2. DFSのライフサイクル：CAC、インサービスモニタリング、そして退避

DFS対応チャネルを使用する際、APは厳格なステートマシーンに従って動作している。現場でトラブルシューティングを行う際、このシーケンスを頭に叩き込んでおくことが不可欠だ。

[電源投入 / チャネル変更]
       ↓
【CAC (Channel Availability Check)】 ──(レーダー検知)──> [別チャネルへフォールバック]
       │ (通常60分 / 気象レーダー帯は10分待機)
       ↓
【インサービスモニタリング (常時監視)】 ──(レーダー検知)──> [NEM (Non-Occupancy Period)]
       │                                                         │ (最低30分間は利用禁止)
       └──(正常稼働)─────────────────────────────────────────────┘

2.1 CAC（Channel Availability Check：チャネル可用性チェック）

APの電源を投入した際、または管理画面からDFSチャネルを手動・自動で変更した際、APはすぐに電波を出してはならない。
まずはそのチャネルがレーダーによって使われていないかを「聴音（Listen Before Talk）」する。これがCACだ。

  • 通常のDFSチャネル（W53等）： 最低60秒間の静穏確認が必要。
  • 気象レーダー帯（W56の一部）： レーダー波の種類（長パルス等）によっては、なんと10分間（600秒）もの間、ビーコンすら出せずに沈黙を余儀なくされる。

「新しいAPを設定したのに、いつまで経ってもWi-Fiが飛んでこない！」という現場の悲鳴の多くは、このCACの待ち時間に原因がある。エンジニアたるもの、初期化直後のこの沈黙をバグと勘違いして再起動を繰り返してはならない。ただ静かに待つのが正解だ。

2.2 インサービスモニタリングとNEM（Non-Occupancy Period）

CACを無事にクリアしてWi-Fiの提供を開始した後も、APの無線チップは常に周囲の電波を監視し続けている（インサービスモニタリング）。

もしここでレーダー波を検知すると、APは以下の強烈なアクションを即座に実行する。
1. 即座の送信停止（Transmission Cessation）： 検知から通常10ミリ秒（ms）以内に、そのチャネルでの電波出力を完全に停止する。接続中のクライアントは一瞬で切断される。
2. チャネル退避（Channel Move Time）： 規定時間内（通常200ms以内）に、別の非DFSチャネル（W52など）や、まだ安全が確認されている別のDFSチャネルへ退避し、リンクを再確立する。
3. NEM（非居住期間）： レーダーを検知したチャネルは、法律（電波法）および規格により、最低30分間は二度と使用してはならないというペナルティ（クールダウン）が課される。

—

3. 現場で直面する「DFS起因の切断」とインフラエンジニアの処方箋

オフィスビルやマンションで、「1時間に1回、決まったように数秒間通信が途切れる」「特定の時間帯に社内無線が不安定になる」という相談を受けたことはないか？
周囲に気象レーダーや河川監視レーダー、あるいは高出力のワイヤレスカメラなどがあると、誤検知（False Alarm）も含めて頻繁にDFSが発動してしまう。

こうした現場のトラブルを防ぎ、あるいはデバッグするために、インフラエンジニアが取るべき実践的なアプローチを紹介しよう。

3.1 ログの確認とsyslogの常時監視

多くのプロフェッショナル向けルーター（Cisco Catalyst、Aruba、Yamaha、あるいはOpenWrtを導入したカスタム機など）は、DFSによるチャネル変更をカーネルログやsyslogに残している。

例えば、LinuxベースのAPで hostapd が動いている環境や、一般的なルーターのCLIからログを抽出する際の手順をイメージしてみよう。Pythonを用いて、Syslogサーバーに飛んできたログからDFS関連のイベントをリアルタイムにフィルタリングするスクリプトの例を挙げる。

#!/usr/bin/env python3
# -*- coding: utf-8 -*-

import socket
import re

# Syslogサーバーの設定（UDP 514ポートでルーターからのログを受信）
SYSLOG_IP = "0.0.0.0"
SYSLOG_PORT = 514

# DFS検知やチャネル変更に関連するキーワードの正規表現パターン
dfs_pattern = re.compile(r"(radar|dfs|channel availability check|non-occupancy|cac)", re.IGNORECASE)

def monitor_dfs_logs():
    sock = socket.socket(socket.AF_INET, socket.SOCK_DGRAM)
    sock.bind((SYSLOG_IP, SYSLOG_PORT))
    
    print(f"[*] DFS Log Monitor started on {SYSLOG_IP}:{SYSLOG_PORT}...")
    
    try:
        while True:
            data, addr = sock.recvfrom(1024)
            message = data.decode('utf-8', errors='ignore')
            
            # ログ内にDFS関連のキーワードが含まれているかチェック
            if dfs_pattern.search(message):
                print(f"[ALERT] Router {addr[0]} reported DFS Event: {message.strip()}")
                
    except KeyboardInterrupt:
        print("\n[*] Stopping monitor.")
        sock.close()

if __name__ == "__main__":
    monitor_dfs_logs()

このようなスクリプトを運用の踏み台サーバーに常駐させておくだけで、「あ、今レーダー波を拾ってチャネルが100から36に退避したな」という相関関係が手に取るようにわかるようになる。

3.2 ネットワーク設計における現実的な回避策

もしあなたがインフラの設計段階、あるいは運用フェーズでDFS起因の切断に悩まされているなら、以下のアーキテクチャ上の対策を検討してほしい。

1. W52（チャネル 36, 40, 44, 48）の積極的な活用：
W52は屋内専用であり、DFSの対象外だ。CACの待ち時間もなく、レーダーによる強制退避もないため、極めて安定している。ただし、チャネル数が少ないため、高密度環境（APが密集するオフィスなど）ではチャネル設計（干渉設計）がシビアになる点に注意が必要だ。
2. 帯域幅（Channel Width）の設計見直し：
現在主流のWi-Fi 6 / 6E / 7では、80MHz幅や160MHz幅といった広大な帯域を束ねて通信することが可能だ。しかし、束ねたチャネルの中に1つでもDFSチャネルが含まれている場合、そのバンド全体のどこかでレーダーを検知すると、束ねた帯域ごとすべて強制退避させられる。
安定性を最優先するミッションクリティカルな環境（工場や倉庫のAGV制御、店舗のPOS端末など）では、あえて帯域幅を40MHzや20MHzに制限し、DFSの影響範囲を最小限に抑えるという設計判断が極めて有効である。

—

4. 次世代規格（Wi-Fi 6E / Wi-Fi 7）と今後の展望

近年普及が進んでいるWi-Fi 6E、そして最新のWi-Fi 7では、新たに6GHz帯が解放された。
6GHz帯は、5GHz帯のように既存の気象・航空レーダーとの共用周回が原則として少ない（一部地域や国による例外はあるが）、非常にクリーンな帯域だ。そのため、6GHz帯を用いたチャネルでは基本的にDFSによる面倒なCACの待ち時間や、突然の強制退避に怯える必要がない。

「じゃあ、これからは全部6GHz帯に移行すれば解決じゃん！」と思いたくなるが、そう問屋が卸さないのがネットワークの奥深いところだ。
6GHz帯は周波数が高いため、5GHz帯や24GHz帯に比べて障害物（コンクリートの壁やパーティション）による減衰が激しい。「電波の直進性が強すぎて、フロアの隅まで届かない」という物理の壁にぶぶつかる。

だからこそ、私たちインフラエンジニアは、それぞれの特性を理解し適材適所で使い分ける必要がある。

  • 広範囲をカバーしつつ安定させたいインフラ： 5GHz帯（ただし用途に応じてW52をメインにするか、DFSの痛みを許容してW53/W56を使うか設計する）
  • 遅延とスループットが命の近距離・高密度空間： 6GHz帯のノンDFSチャネルをフル活用

—

まとめ：パケットの向こう側にある物理世界を想像する

ネットワークエンジニアの仕事は、画面上の設定ファイルをいじることだけではない。その背後で、目に見えない電波が空間を飛び交い、法規制や自然界のレーダー波とダイナミックに共存しているその「物理的な営み」を想像することに醍醐味がある。

DFSのCACやレーダー検知による切断に直面したとき、「ルーターの故障かな？」と疑う前に、電波法の背景や、気象観測を支える公共の電波との共生関係に思いを馳せてみてほしい。きっと、トラブルシューティングの視野がグッと広がるはずだ。

さあ、今日もログを眺めながら、最高のネットワーク環境を構築しよう。Happy Networking!

スポンサーリンク

コメント

タイトルとURLをコピーしました