こんにちは、シニアネットワークエンジニアの私です。
日々、モダンなWebアプリケーションのAPI設計や、それを支える堅牢なクラウドインフラの構築に奔走しているエンジニアの皆さんなら、一度はこんな悩みに直面したことがあるのではないでしょうか。「オフィスや自宅のフロアを移動した瞬間、APIのKeep-Aliveセッションがプツリと切れ、DBへの書き込み途中でリクエストがタイムアウトした」——と。
クラウド側の冗長化やロードバランシング（HTTP/3のConnection Migrationなど）がいかに洗練されていようとも、足元の物理レイヤーやデータリンクレイヤー、すなわちWi-Fiローミングでモタついていると、アプリケーション層の努力はすべて水の泡です。
特に、昨今のスマートホームや高密度なオフィス環境において、複数台のアクセスポイント（AP）でエリアをカバーする「メッシュWi-Fi」は必須のインフラストラクチャとなっています。しかし、「電波が強い方に勝手に繋がってくれるんでしょ？」という甘い認識で設計・運用していると、ローミング時の数秒に及ぶブラックアウトに足元をすくわれます。
今回は、このWi-Fiローミングの暗黒面をスマートに解決し、ミリ秒単位のシームレスな移動を実現するIEEE 802.11k/v/rの仕組みについて、現場のインフラエンジニアの視点から泥臭く、かつ徹底的に解説していきます。
—
なぜ従来のWi-Fiローミングは「遅い」のか？
私たちが普段何気なく使っているスマートフォンやノートPCなどの無線クライアント（STA）は、移動に伴って現在接続しているAPの電波（RSSI）が低下すると、より良いAPを探す旅に出ます。
標準的な（これらの規格に対応していない）ローミングプロセスは、概ね次のような悲劇的なステップを踏みます。
1. 受動的・能動的スキャン: クライアントが突然「今の電波悪いな」と気づき、全チャネル（2.4GHz帯なら14チャンネル、5GHz帯なら優に20チャンネル以上）を1つずつプローブ要求（Probe Request）を出しながらしらみ潰しにスキャンします。このスキャン処理だけで、数百ミリ秒から場合によっては数秒が消え去ります。
2. 切断と再認証 (Authentication): 接続先を見つけると、古いAPとの接続を断ち、新しいAPに対してIEEE 802.11のオープンシステム認証（または共有キー認証）をゼロからやり直します。
3. 4ウェイ・ハンドシェイク (4-Way Handshake / WPA2/WPA3): ここが最大のボトルネックです。WPA2-PSKやWPA3-SAEの暗号鍵を確立するために、APとクライアント間で4往復のメッセージ交換（4-Way Handshake）を行います。共通鍵暗号の導出やRADIUSサーバーへの問い合わせ（802.1X環境の場合）が発生するため、さらに数百ミリ秒が経過します。
この間、パケットは完全にブラックホール行きです。TCPコネクションは断たれ、Websocketは切断され、リアルタイム性の高いIoTデバイスの制御コマンドはロストします。
この「ローミング遅延」というエンジニアの頭痛の種を根絶するために策定されたのが、IEEE 802.11k（隣接AP情報）、IEEE 802.11v（BSS遷移管理）、IEEE 802.11r（高速BSS遷移）の3兄弟です。
—
1. IEEE 802.11k：隣接AP情報の提供（事前の地図渡し）
概念と仕組み
盲目的に全チャネルをスキャンする非効率さを解消するのが 11k（Neighbor Report）です。
クライアントが「ねぇ、周りにどんなAPがある？」と Beacon や Probe Request で聞くのではなく、現在の接続先APが「君の周りにはこういうチャネルとBSSID（MACアドレス）のAPがあるよ」という近隣レポート（Neighbor Report）をあらかじめテーブルとして渡してあげます。
これにより、クライアントは無駄なチャネルスキャンを一切行わず、提示されたターゲットチャネルピンポイントで電波測定（Passive/Active Scanning）を行うことができるため、スキャン時間を劇的に短縮できます。
通信シーケンスのイメージ
[Client (STA)] [Current AP (AP1)]
| |
|--- (1) Radio Measurement Req ---->| ※「周囲の環境を教えて」
| |
|<-- (2) Radio Measurement Rep -----| ※「隣接APのリスト（チャネル/BSSID）を渡す」
| |
(スキャン時間を大幅短縮し、ターゲットAPへ即座に移行準備)—
2. IEEE 802.11v：BSS遷移管理（インテリジェントな誘導）
概念と仕組み
11k が「地図」だとすれば、11v（BSS Transition Management: BTM）は「ナビゲーションシステム」です。
クライアント側が「どのタイミングでローミングするか」を独自の判断（多くはRSSIが特定の閾値を下回ったとき）に頼っていると、電波が劣化しきってから慌てて移動するため、ローミング中にパケットロスが発生しやすくなります。
11v を有効にすると、インフラ側（APコントローラーやメッシュ親機）が全体の負荷分散や電波状況を俯瞰し、クライアントに対して「そこのAP、混雑してるからあっちのAPに移動してくれないか？」というリクエスト（BSS Transition Management Request）を能動的に送信できます。
実務でのハマりどころ
ここでインフラエンジニアとして注意しなければならないのが、クライアント側の実装依存です。
どれほど優れたAP側が 11v のBTMクエリを投げても、古いAndroid端末や一部の安価なIoTモジュール（ESP8266や古めのESP32など）は、このリクエストを無視するか、正しくハンドリングできずに接続が不安定になるケースがあります。現場導入前の検証（PoC）では、必ず主要評価端末での 11v 応答性をキャプチャ（Wireshark等）で確認することが鉄則です。
—
3. IEEE 802.11r：高速BSS遷移（Fast BSS Transition / FT）
概念と仕組み
そして、ローミング高速化の真打ちが 11r（FT: Fast BSS Transition）です。
先ほど触れた「4ウェイ・ハンドシェイク」の重い処理を、移動先のAPであらかじめスキップ、あるいは軽量化する仕組みです。
11r では、最初のAPに接続した際に生成されるマスターキー（PMK-R0）を元に、メッシュを構成するすべてのAPで共通利用できる派生キー（PMK-R1）をあらかじめ各AP間で安全に共有（あるいはモビリティドメイン内で管理）しておきます。
これにより、クライアントが新しいAPに移動した際、暗号鍵の生成・交換プロセスが圧倒的に簡略化され、認証とキーネゴシエーションをわずか1〜2回のメッセージ交換（FT Initial Mobility Domain Associationなど）で完了させることができます。
ローミングにかかる時間は、なんと50ミリ秒以下。これなら、VoIP通話やリアルタイムのWebSocket通信であっても、パケットロスを感じさせずにシームレスに生き残ることができます。
—
実践：OpenWrtルーター環境における11k/v/rの設定例
では、実際のオープンソース・ルーターファームウェアである OpenWrt（多くの家庭用・中小規模向けメッシュルーターのベースとなっています）の無線設定ファイル（/etc/config/wireless）を例に、これらの機能をどのように有効化・チューニングするのかを見ていきましょう。
実務のインフラ構築を想定し、セキュリティ（WPA3/WPA2混在環境でのFT動作など）に配慮した設定記述例です。
config wifi-device 'radio0'
option type 'mac80211'
option channel '36'
option band '5g'
option htmode 'VHT80'
# 5GHz帯の高パフォーマンスなメッシュバックホールおよびクライアント収容を想定
config wifi-iface 'default_radio0'
option device 'radio0'
option network 'lan'
option mode 'ap'
option ssid 'MySmartHome_Mesh'
option encryption 'sae-mixed' # WPA3-SAEとWPA2-PSKの混在モード
option key 'YourSuperSecretKey123!'
# --- IEEE 802.11r (Fast BSS Transition) の設定 ---
option ieee80211r '1' # 11rを有効化
option mobility_domain '4a42' # モビリティドメインID (Hex値 2オクテット)
option FT_over_DS '1' # 分配システム（有線バックホール等）経由のFTを有効化
option FT_SAE '1' # WPA3-SAE環境でのFT認証を有効化
# --- IEEE 802.11k (Neighbor Report) の設定 ---
option ieee80211k '1' # 隣接AP情報の提供を有効化
# --- IEEE 802.11v (BSS Transition Management) の設定 ---
option ieee80211v '1' # BSS遷移管理を有効化
option bss_transition '1' # クライアントの負荷分散・誘導を有効化設定値のワンポイント解説
mobility_domain: メッシュを構成するすべてのAPで完全に同一のHEX値（例:4a42）を設定する必要があります。このドメイン内に属するAP間であれば、クライアントは瞬時にキーを再利用して移動できます。FT_over_DS: AP間のバックホールが有線（イーサネット）でしっかりと結ばれているメッシュ環境やルーター間セントラル管理環境では1に設定することで、無線区間を介さずにAP間で直接認証情報をやり取りでき、さらに高速化します。
—
現場のトラブルシューティングとデバッグTips
「設定をすべて有効にしたのに、なぜかスマホがいつまでも古いAPにしがみついてローミングしてくれない……」
これは、現場のフィールドテストでエンジニアが一番絶望する瞬間です。最後に、こうしたトラブルに直面した際のデバッグ手順を共有します。
1. クライアント側の対応状況を確認する
いくらインフラ側（AP）が 11k/v/r をフルスロットルで喋っていても、接続するクライアント（スマートフォンやIoTデバイスのWi-Fiチップ）がそれに対応していなければ意味がありません。
Linux環境（Raspberry Piなど）であれば、iw コマンドや wpa_cli を使って確認できます。
# クライアント側がサポートしているIEEE 802.11機能の確認例
wpa_cli status出力結果の中に ft_enabled=1 や関連するフラグが立っているか、あるいは接続ログ（/var/log/messages や dmesg）で FT: * といったハンドシェイクのログが綺麗に流れているかを追います。
2. Wiresharkとエアモニターによるパケットキャプチャ
どうしても原因が切り分けられない場合は、5GHz帯の特定のチャネルをモニタモードでキャプチャし、Wiresharkで以下のフィルタをかけて空中線を流れるフレームを覗き見ます。
btmまたはdot11.elt.id == 255（BSS Transition Managementのフレーム確認）dot11.fixed.auth_alg == 2（FT認証フレームのやり取り確認）
「APがちゃんと 11k のNeighbor Reportを返しているか」「クライアントが 11v のBTM Requestに対して BSS Transition Management Response（ステータスコード 0: Accept）を返しているか」をパケットベースで追うことで、問題のボトルネック（APの設定ミスなのか、クライアントの拒否なのか）が鮮明に浮かび上がります。
—
おわりに
家庭用ネットワークやIoT、そしてモバイル通信の境界線がどんどん曖昧になる現代において、無線LANの物理・データリンク層の挙動を正しく理解しコントロールすることは、もはやインフラエンジニアやバックエンドエンジニアにとっても必須の教養となりつつあります。
「たかがWi-Fi、されどWi-Fi」。
IEEE 802.11k/v/rという黒衣の技術たちを正しく手ななづけ、パケットがストレスなく自宅やオフィスを駆け巡る、美しいネットワーク環境をぜひご自身の設計・構築現場でも実現してみてください。あなたの書いたコードや構築したインフラが、ユーザーの快適な体験を裏からしっかりと支えてくれるはずです。
コメント