【実務・中級編】メッシュWi-Fiのローミングプロトコル：IEEE 802.11k（近隣レポート）の仕様 – 家庭用ネットワーク・IoT・モバイル通信実践ガイド

家庭やオフィスの無線LAN環境で、こんな理不尽な現象に直面したことはないだろうか。

リビングから自室へ移動した途端、YouTubeの動画が突如としてバッファリングを始め、リモート会議の音声がロボットボイスのように途切れる。スマートフォンの画面を覗くと、アンテナピクトは辛うじて立っているものの、リンク速度は最低レートまで落ち込んでいる。頭上にはついさっきまで接続していたメインルーターよりも、目の前にあるメッシュ子機の方が圧倒的に物理的に近いというのに、だ。

「なぜ、もっと電波の強い近くのアクセスポイント（AP）へ勝手に切り替えてくれないのか？」

ネットワークエンジニアなら誰もが一度は頭を抱えるこの「ローミング（Sticky Client問題）」の泥沼。この長年の悪夢をスマートに解決してくれる黒幕こそ、今回スポットを当てる IEEE 802.11k（Neighbor Report：近隣レポート） だ。

教科書的な仕様の丸暗記は現場では何の役にも立たない。パケットが空中を舞い、ドライバのクソ仕様と格闘してきたシニアエンジニアの視点から、IEEE 802.11kのリアルな挙動と、インフラ設計・デバッグの現場で使える実践知を余すところなく伝授しよう。

—

1. なぜローミングは失敗するのか？（Sticky Clientのメカニズム）

無線LANのローミング（ハンドオーバー）の主導権は、基本的にクライアント端末（スマートフォンやノートPC）側が握っている。AP側から「こっちに引っ越せ！」と強制的に追い出すことは、古いプロトコルでは難しかった。

端末の多くは、現在接続しているAPの電波強度（RSSI）が、あらかじめ設定された閾値（例: -70 dBmなど）を下回るまで、頑なにそのAPにしがみつき続ける。これが「スティッキー・クライアント（しがみつき端末）」と呼ばれる現象だ。

従来のブラインドローミングの悲劇

IEEE 802.11kが存在しない世界では、端末が「そろそろ別のAPを探すか」と思い立ったとき、以下のような泥臭いプロセスを踏む。

1. アクティブ／パッシブスキャン: 端末が周囲の全チャンネル（2.4GHz帯なら1〜13ch、5GHz帯ならW52/W53/W56の多数のチャンネル）に対して、ひたすら Probe Request をブロードキャストするか、各チャンネルのビーコンを待ち受ける。
2. 時間のロス: 全チャンネルを舐め回すようにスキャンするため、数十〜数百ミリ秒の通信断（ブラックアウト）が発生する。
3. 無駄な電力消費: バッテリー駆動のモバイル端末にとって、全チャンネルスキャンは地味に重い負荷となる。

結果として、ユーザーは「移動したのに回線が数秒間フリーズする」という最悪の体験を味わうことになる。

—

2. IEEE 802.11k（Neighbor Report）がもたらすパラダイムシフト

ここで登場するのが IEEE 802.11k だ。この規格の核心は、「クライアントに周囲の地形図（近隣APのリスト）をあらかじめ渡しておくこと」にある。

メッシュWi-Fi環境において、各ノード（AP）はお互いの電波状況や、どのチャンネルで稼働しているかを常に把握している。クライアントから「お隣さんの情報をくれ」とリクエスト（Neighbor Report Request）があった際、現在のAPは周囲の状況を記した Neighbor Report を返す。

メッシュネットワークにおける無線リソース最適化

IEEE 802.11kによって、端末は全チャンネルを総当たりでスキャンする必要がなくなる。
「あそこのAPとあそこのAPのチャンネルはこれだから、そこピンポイントで電波強度測ればいいんだな」と、スキャン対象を劇的に絞り込めるため、ローミングにかかる時間を数ミリ秒単位まで短縮できるのだ。

—

3. 通信フロー（シーケンス）の解剖

実際の無線空間で、IEEE 802.11kのネゴシエーションがどのように行われているか、そのシーケンスを紐解こう。

[Client (STA)]                     [Current AP (Node A)]
      |                                      |
      |--- 1. Radio Measurement Request ---->|  ※「隣のAPの情報をくれ」
      |    (Category: 0, Action: 2)          |
      |                                      |
      |<-- 2. Radio Measurement Report ------|  ※「お勧めのAPリスト（BSSID, チャンネル等）」
      |    (Neighbor Report Elements)        |
      |                                      |
      |--- 3. Direct Probe Request --------->|  [Target AP (Node B)] ※ピンポイント測定
      |<-- 4. Direct Probe Response ---------|
      |                                      |
      |--- 5. Reassociation Request -------->|  [Target AP (Node B)] ※ローミング実行
      |<-- 6. Reassociation Response --------|

1. Radio Measurement Request: クライアントが現在の接続先APに対して近隣レポートを要求する。
2. Radio Measurement Report: APが周囲のAPのBSSID、チャンネル番号、Operating Class、PHYタイプなどの詳細情報を詰め込んだ Neighbor Report Element を返送する。
3. Targeted Scanning: クライアントはレポートに記載された特定のチャンネルだけを狙い撃ちしてプローブ（あるいはビーコン受信）を行い、実際の電波状況（RSSI）を評価する。
4. Reassociation: 最も条件が良いと判断したターゲットAPへ再関連付け（Reassociation）を仕掛け、瞬時にローミングを完了する。

—

4. 無線パケットとパラメーターの深掘り

インフラエンジニアとして、無線パケットキャプチャ（Wireshark等）を叩いた際に注目すべき Neighbor Report の主要なフィールド構造を以下に整理する。

—

5. 実務で役立つ設定・デバッグTips

ここからは、現場のトポロジー設計やトラブルシューティングで即座に使える実践的な知見を共有しよう。

① 11k/11v/11rの「三位一体」で真価を発揮する

IEEE 802.11k単体では、あくまで「情報の提供」に過ぎない。シームレスなローミングを実現するためには、以下の3兄弟をセットで有効化するのが鉄則だ。

IEEE 802.11k: 近隣APの探索効率化（今回解説したマップ提供）
IEEE 802.11v: BSS Transition Management（AP側から「あっちの空いてるAPに移動しなよ」と促すサジェスチョン）
IEEE 802.11r: Fast BSS Transition (FT)（ローミング時の4ウェイハンドシェイクを高速化し、認証切れによる切断を防ぐ）

この3つが揃って初めて、現代のモダンなメッシュWi-Fiの真価が発揮される。

② デバッグ時の罠：クライアント側の対応状況

「ルーター側で11kを有効にしたのに、一向にローミングが改善しない！」というトラブルの9割の原因は、クライアント端末（特に安価なIoTデバイスや古いノートPCのWi-Fiカード）がIEEE 802.11kに非対応であることだ。

Linux（Ubuntu等）の端末側で、対象のインターフェース（例: wlan0）が11kをサポートしているかは、iw コマンドで確認できる。

# 端末の無線インターフェースがサポートしている機能（VHT/HE capabilitiesやRMなど）を確認
iw dev wlan0 info

# もしくは、iw list でドライバの機能一覧をダンプし、"Radio Measurement" の記述を探す
iw list | grep -i "Radio Measurement"

もしクライアントが11kに対応していない場合、AP側がどれだけ親切に近隣レポートを差し出しても、クライアントはそれを無視して自力でブルートフォースなスキャンを続けることになる。メッシュを導入する際は、接続するクライアント側のスペックシート（Wi-Fi Allianceの認証資格など）の確認を怠らないことだ。

③ プロダクション環境でのコントローラー設定例（概念的アプローチ）

エンタープライズ向けや高性能メッシュルーターのCLI/コンフィグ（YAMLやJSONライクな設定）において、無線リソース管理（RRM）および11kを有効化する際のイメージは以下の通り。

# 無線LANコントローラー / メッシュAP設定の抜粋例
wireless_settings:
  band_24ghz:
    enabled: true
    channel_width: "20MHz"
  band_5ghz:
    enabled: true
    channel_width: "80MHz"
    
  # ローミング最適化機能群の有効化
  roaming_protocols:
    ieee_802_11k: true  # 近隣レポート（Neighbor Report）を有効化
    ieee_802_11v: true  # BSSトランジション管理（負荷分散・誘導）を有効化
    ieee_802_11r: true  # 高速BSS遷移（Fast Roaming / FT）を有効化
    
    # スティッキークライアント対策の閾値設定
    roaming_aggressiveness: "high" # アグレッシブに切り替えを促す
    rssi_steering_threshold_dbm: -75 # -75dBmを下回ったら強めに誘導開始

—

6. おわりに

IEEE 802.11kというプロトコルは、派手な通信速度の向上をもたらすわけではない。しかし、電波という目に見えない不安定な物理レイヤーの上で、私たちユーザーが「家の中を歩き回っても途切れない快適なネットワーク」を享受できるのは、こうした地味ながらも緻密な情報共有の仕組みが背後で泥臭く働いているからに他ならない。

ネットワーク設計やトラブルシュートの現場において、「なぜそのパケットが流れているのか」「どちらが主導権を持っているのか」をレイヤーごとに分解して考える視点こそが、インフラエンジニア最大の武器となる。

あなたの自宅のメッシュWi-Fiが、今日も滑らかにパケットをリレーしてくれることを願っている。