メッシュWi-Fiの裏側：IEEE 802.11k/v/r が描き出すシームレスローミングの極北
オフィスやスマートホームのフロアを歩き回りながら、途切れることのないビデオ会議や、パケットロスを一切許容しないリアルタイム遠隔制御。私たちは今や、無線空間が「どこでも均一に広がるエーテル」であるかのような錯覚の中で生きている。しかし、その裏側で何が起きているかをご存知だろうか。
現代の無線インフラストラクチャにおいて、複数のアクセスポイント（AP）が協調し、一つの巨大なESS（Extended Service Set）を構築するメッシュWi-Fiはもはや標準装備だ。だが、クライアントデバイス（STA）が物理的な移動に伴って接続先を切り替える（ローミングする）瞬間、そこには古典的な無線LANが抱える「切断と再接続の断絶」という深い闇が横たわっていた。
この遅延とパケットロスのジレンマを鮮やかに解決し、ミリ秒単位でのハンドオーバーを実現しているのが、IEEE 802.11k/v/r という3つの頭文字で表されるプロトコル群である。本稿では、教科書的な解説のさらに一段下、パケットの往来、暗号学的ハンドシェイクの最適化、そしてLinuxカーネルやホストapd（hostapd）の内部挙動に至るまで、インフラアーキテクトが知るべき極限の技術的ディープダイブをお届けする。
—
1. IEEE 802.11k：隣接AP情報の提供による「測位の合理化」
従来のローミングにおいて、STAが最も多くの時間を浪費していたのは「次に接続すべき優れたAPを探す作業（スキャン）」である。
アクティブスキャンという名のタイムロス
何も最適化されていない環境では、STAは周辺の全チャネル（2.4GHz帯の3チャンネル、5GHz帯の多数のチャンネル、さらに6GHz帯の広大な空間）に対して Probe Request をブロードキャストし、各APからの Probe Response を待たなければならない。このチャネルホッピングと待機時間（Dwell Time）だけで、数十ミリ秒から数百ミリ秒が平然と消え去る。これは、TCPの遅延を致命的に悪化させ、リアルタイムストリームを破壊するには十分すぎる時間だ。
802.11k (Radio Resource Measurement) の内部挙動
802.11kは、この非効率な「総当たりスキャン」を過去のものにする。STAが親APに対して Beacon Report Request を送信するか、あるいはAP側が自律的に、同一ESS内の周辺APの電波強度、チャネル、BSSID、負荷情報をまとめた Beacon Report Response を返す。
ここで重要なのは、STAが無駄なチャネルをスキャンせず、あらかじめ指定されたターゲットチャネルのみをピンポイントで測定（Neighbor Report）できる点だ。これにより、ターゲット選定にかかるRTT（Round Trip Time）とCPUリソースが劇的に削減される。
現場で hostapd を用いて隣接APマップを構築する場合の設定例を以下に示す。
# /etc/hostapd/hostapd.conf
# 802.11k (Radio Resource Measurement) の有効化
rrm_beacon_report=1
rrm_neighbor_report=1
# 隣接AP（BSSID）の静的登録（メッシュコントローラーが動的に流し込むのが理想だが、基本構造の理解用）
neighbor_desc=00:11:22:33:44:55,1,2412,15,3,0,0,0
neighbor_desc=00:11:22:33:44:56,36,5180,15,3,0,0,0—
2. IEEE 802.11v：クライアントの接続先誘導と BSS Transition Management
802.11kによって「どこに電が来ているか」が分かっても、STAが古いAPにしがみつき続ける（スティッキー・クライアント問題）現象は後を絶たない。人間と同様、機械もまた「現状維持バイアス」に囚われやすいのだ。
BSS Transition Management (BTM) のメカニズム
802.11vの神髄は、BSS Transition Management にある。電波状況が悪化したり、特定のAPに負荷が集中（ロードバランス）した際、AP側からSTAに対して「こちらのAPへ移動しなさい」という旨の BSS Transition Management Request フレームを突きつける。
このフレームには、単なる「移動命令」だけでなく、以下の高度な情報が含まれる。
- 候補となる隣接APのBSSIDとチャネルリスト
- 移行を強制するかどうかのフラグ（Disassociation Imminent）
- 猶予時間（Timer）
STAはこの要求を受信すると、自発的に切断を判断するのではなく、ネットワーク側の全体最適化の意図を汲み取ってスムーズに接続先を切り替える。
[STA] <--- (BSS Transition Request: 移行先候補提示) --- [AP A]
[STA] ---> (BSS Transition Response: 受諾 / 拒否) -------> [AP A]
[STA] === (高速ローミングへ移行) =======================> [AP B]Linuxの無線制御デーモンである wpa_supplicant 側では、802.11vのシグナリングを適切に処理するよう以下の設定が不可欠となる。
# /etc/wpa_supplicant/wpa_supplicant.conf
ctrl_interface=/var/run/wpa_supplicant
update_config=1
# 802.11v BSS Transition Management の有効化
bss_transition=1—
3. IEEE 802.11r：高速BSS Transition（Fast BSS Transition / FT）による暗号ハンドシェイクの圧縮
802.11kでスキャンを省き、802.11vで誘導されても、移動先のAPで再び 4-Way Handshake（4ウェイハンドシェイク）や 802.1X/RADIUS による認証をイチからやり直していたのでは、結局数百ミリ秒の通信断が発生してしまう。ここで登場するのが 802.11r である。
暗号学的ハンドシェイクのオーバーヘッド
通常、WPA2-PSKやWPA3-SAEの環境では、新しいAPへ接続するたびに認証サーバーやAPとの間で鍵交換のシーケンスが発生する。これがローミング時の最大のボトルネックだ。
802.11r（Fast BSS Transition: FT）は、この暗号ハンドシェイクの大部分を「事前計算」および「モビリティドメイン内での鍵の引き継ぎ」によってバイパスする。
FTの内部構造：PMK-R0, PMK-R1, そして PTK
802.11rのアーキテクチャでは、鍵階層（Key Hierarchy）が以下のように再定義されている。
1. PMK-R0 (Pairwise Master Key R0): STAと、モビリティドメイン（MDIDで定義された同一管理下のメッシュエリア）全体を統括するR0KH（R0 Key Holder）の間で導出されるルート鍵。
2. PMK-R1 (Pairwise Master Key R1): PMK-R0から派生し、特定のAP（R1 Key Holder）に紐づく鍵。
3. PTK (Pairwise Transient Key): 最終的な暗号化通信に用いられる一時鍵。
STAがモビリティドメイン内に参加した初期段階で、あらかじめ将来移動する可能性のある周辺AP用の PMK-R1 をバックグラウンドで安全に共有（あるいはローカルで導出）しておく。そのため、実際にAPを切り替える瞬間には、通常の4ウェイハンドシェイク（4回の往復）が、FT認証フレーム（Reassociation Request/Response）のなかに組み込まれた2ウェイのハンドシェイクへと圧縮される。
この最適化により、認証に要する時間は数ミリ秒（< 50ms）にまで短縮され、TCPセッションが切断されるタイムアウト閾値を安全に回避できるようになる。 ---
4. 極限のパフォーマンスとセキュリティ：RTT削減・TCPチューニングの実装
ここまでのプロトコル最適化をハードウェアおよびOSレベルで最大限に活かすためには、トランスポート層やカーネルパラメータのチューニングが欠かせない。メッシュノード間のバックホール（有線または無線）における遅延ジッターを極限まで抑え込むための実践的設定を記す。
LinuxカーネルにおけるTCPバッファと輻輳制御の最適化
ローミング時の瞬断（数十ミリ秒のパケット停滞）が発生した際、TCPの輻輳制御アルゴリズムが誤動作してウィンドウサイズを極端に縮小させないよう、BBR（Bottleneck Bandwidth and RTT）の採用とバッファチューニングが有効だ。
以下のカーネルパラメータを /etc/sysctl.conf に適用する。
# /etc/sysctl.conf
# ネットワークスタックのバッファサイズ最大値の拡張 (High-Bandwidth, High-Delay環境対策)
net.core.rmem_max = 16777216
net.core.wmem_max = 16777216
net.ipv4.tcp_rmem = 4096 87380 16777216
net.ipv4.tcp_wmem = 4096 65536 16777216
# 最新のTCP輻輳制御アルゴリズム BBR の有効化 (RTT変動に対する耐性強化)
net.core.default_qdisc = fq
net.ipv4.tcp_congestion_control = bbr
# TCPキープアライブの調整（メッシュ端末の生死判定を高速化）
net.ipv4.tcp_keepalive_time = 30
net.ipv4.tcp_keepalive_intvl = 10
net.ipv4.tcp_keepalive_probes = 3設定を即時反映させるには、以下のコマンドを実行する。
sudo sysctl -p重大な脆弱性の回避とセキュリティ上の留意点
802.11r（Fast Roaming）を導入する際、セキュリティ専門家が必ず直面するのが「PMK cachingの悪用」や「FT Replay Attack」のリスクである。
特に古い実装や不十分なファームウェアでは、モビリティドメイン内での鍵の再利用や、悪意ある不正AP（Rogue AP）によるモビリティドメインへの不正参加を防ぐため、以下の点に厳格な注意が必要である。
- WPA3-SAEとFTの併用: 可能であれば、レガシーなWPA2-PSK（AES）ベースのFTではなく、WPA3-SAE（Simultaneous Authentication of Equals）と組み合わせたFT（
wpa_key_mgmt=SAE FT-SAE）を強制すること。これにより、初期認証時の辞書攻撃耐性を高めつつ、高速ローミングの恩恵を受けられる。 - PMK-R1のキャッシュ寿命の最小化:
hostapd側で、不必要に長くキーを保持させないようライフタイムを適切に設定する。
# hostapd.conf におけるセキュリティ強化設定例
wpa=2
wpa_key_mgmt=WPA-PSK FT-PSK
wpa_pairwise=CCMP
rsn_pairwise=CCMP
# FT関連パラメータ
ft_psk_generate_local=1
mobility_domain=a1b2
r0_key_lifetime=10000—
5. 結びにかえて：見えない空間を支配するエンジニアリング
IEEE 802.11k, v, r が連係して織りなす世界は、まさにパケットレベルの精密機械細工である。
- 11k が周囲の地図を寸分違わず描き出し、
- 11v が渋滞を避けた最適なルートへと背中を押し、
- 11r が門番との身分証確認を一瞬で済ませる。
この一連のシームレスなバトンタッチがあるからこそ、私たちは無線という不安定な物理媒体の上で、有線LANと遜色のない堅牢なリアルタイムアプリケーションを享受できている。
教科書通りの設定をなぞるだけでは、高密度なオフィス環境や干渉の激しいスマートホームの電波泥沼に足元をすくわれる。パケットの挙動を読み解き、カーネルのバッファからプロトコルのステートマシンまでを一気通貫でチューニングすること――それこそが、真のインフラストラクチャを構築するエンジニアに求められる美学であり、醍醐味なのだ。
コメント