メッシュWi-Fiの高速ローミング：IEEE 802.11r（FT）が実現するシームレスなハンドオーバーの裏側
こんにちは、ネットワークエンジニアの皆さん。オフィスや自宅のスマートホーム環境を構築する中で、こんな経験はないでしょうか。「リビングから書斎へ移動した瞬間、ZoomやTeamsの音声が数秒間途切れる」「Web会議の画面がフリーズして再接続のマークがぐるぐる回る」。
原因はだいたい決まっています。端末がアクセスポイント（AP）間を移動する際の「ローミング（ハンドオーバー）遅延」です。特に、Web APIやリアルタイム通信を多用する開発者やインフラエンジニアにとって、この数秒の空白は許しがたいストレスですよね。
今回は、このワイヤレスの切断ストレスを根底から解決する技術、IEEE 802.11r（Fast BSS Transition / FT）にスポットを当てます。教科書的な仕様のなぞりではなく、パケットが空中をどう駆け巡り、なぜ高速化が可能なのか、その泥臭い仕組みと現場でのデバッグ手法をシニアの視点でお伝えします。
—
1. なぜ通常のローミングは遅いのか？（背景と課題）
IEEE 802.11の標準的なローミングプロセスを思い出してください。端末（STA）が現在接続しているAP（AP1）から、電波のより強い別のAP（AP2）へ切り替える際、以下の3つのステップを踏みます。
1. プローブ（探査）: 周囲のAPの電波状況を確認するために、プローブ要求をばら撒く。
2. 認証（Authentication）: 新しいAPに対して、オープンシステム認証や共有キー認証のやり取りを行う。
3. 再関連付け（Reassociation）: AP2に対して再関連付け要求を送り、通信のパスを切り替える。
これだけならミリ秒単位で終わりそうですが、問題はセキュリティ認証（4ウェイハンドシェイク）です。
WPA2-EnterpriseやWPA3-Personalを使用している場合、ローミング先のAPと再びRADIUSサーバーやコントローラーを巻き込んだフル認証、そして暗号鍵（PMK/PTK）の生成を行わなければなりません。この一連のシーケンスに数十〜数百ミリ秒（場合によっては1秒以上）を要するため、リアルタイムパケットがドロップしてしまうのです。
メッシュWi-Fiが普及した現代において、家中を歩き回りながら通話や動画ストリーミングを行うユースケースでは、この遅延は致命的です。そこで登場するのが IEEE 802.11r です。
—
2. IEEE 802.11r（FT）の核心：PMKの事前キャッシングとプレハンズシェイク
IEEE 802.11rの最大の発明は、「移動先のAPと事前に認証を済ませておく（Fast BSS Transition）」点にあります。これには主に2つの方式（Over-the-Air と Over-the-DS）がありますが、今回は実務で最も一般的かつ堅牢な「Over-the-Air」の仕組みを見ていきましょう。
ペアワイズマスターキー（PMK）階層とR0KH / R1KHの概念
802.11rでは、キー管理の構造が拡張されています。
- PMK-R0: 無線LANコントローラーまたは最初のAP（Authenticator）で生成されるルートキー。
- PMK-R1: 実際の各AP（BSSID単位）へ配布するために派生させるキー。
端末が初期接続した際、あらかじめ周辺にあるメッシュノード（AP群）の情報を取得し、それぞれのAP用の PMK-R1 をあらかじめ生成・共有（プレキャッシュ）しておきます。
通信フロー（シーケンス）の比較
通常のローミングと、802.11r（FT）を導入したローミングのパケット往復の違いを整理してみましょう。
[通常ローミング (WPA2/WPA3)]
STA AP1 (旧) AP2 (新) RADIUS/Auth
| | | |
|---(移動検知)--->| | |
| | |<-- 認証要求 --|
| | |--- 認証応答 ->|
| | |<-- 4ウェイハンドシェイク (鍵生成) -->|
|<============================= 接続完了 (遅延: 200ms〜1000ms+) ========>|
[802.11r FTローミング (Fast BSS Transition)]
STA AP1 (旧) AP2 (新)
| | |
|---(事前準備)--->|---(R0/R1キー配布)--->| ※接続中に裏で完了
| | |
|---(移動検知)--->| |
| |<-- FT認証要求 (PMK-R1利用・高速プレハンズシェイク) -->|
| |<-- FT認証応答 (即座に鍵確立) --------------------------->|
|<============================= 接続完了 (遅延: 数十ms以内) ========>|ご覧の通り、802.11rではローミング発生時に重たいRADIUS認証や長大な4ウェイハンドシェイクをバイパスし、事前に共有されたキーを使った軽量なFT認証（Fast BSS Transition Authentication）の1往復だけでリンクが確立します。これが、パケットを途切れさせない魔法の正体です。
—
3. 実務で遭遇するトラブルとデバッグの勘所
理論は美しくとも、現場のインフラ構築では「すべてのクライアントが802.11rを正しく解釈できるわけではない」というジレンマに直面します。特に古いIoTデバイス（スマート家電やIPカメラなど）は、FT機能が有効なSSIDに対して関連付け（Association）に失敗するケースが多々あります。
ここでは、Linuxベースのアクセスポイント（例: hostapd）や、エンタープライズ向けWi-Fiコントローラーを設定する際の勘所をコード例と設定ファイルで紐解きます。
設定ファイルのサンプル (hostapd.conf)
OpenWrtなどのカスタムルーターや業務用の自製APで、802.11r（FT）を有効化する際の設定記述例です。
# hostapd.conf の主要な抜粋
interface=wlan0
ssid=MyHome_Mesh_Secure
hw_mode=g
channel=6
# WPA3-Personal (SAE) と WPA2 を混在させつつ FT を有効化する場合
wpa=2
wpa_key_mgmt=WPA-PSK WPA-PSK-SHA256 FT-PSK SAE FT-SAE
wpa_passphrase=YourUltraSecurePassword123!
# --- IEEE 802.11r (Fast BSS Transition) の設定 ---
rsn_pairwise=CCMP
ft_psk_generate_local=1
# モビリティドメイン（同じメッシュグループ内で一意に指定する2オクテットのHEX値）
mobility_domain=0a1b
# R0KH (R0 Key Holder) および R1KH (R1 Key Holder) の識別子設定
r0kh=00:11:22:33:44:55 r0kh-id mesh-node-01 key=0123456789abcdef0123456789abcdef
r1kh=00:11:22:33:44:55 r1kh-id mesh-node-01 mac=00:11:22:33:44:55デバッグ時のTips：パケットキャプチャとCLIの活用
もし「特定の端末だけがローミング時に切断される」という現象に直面したら、勘で設定を変えるのではなく、Wiresharkや tcpdump、またはAP側のログで原因を特定します。
次のように、hostapd_cli を使ってリアルタイムに認証ステータスを追跡できます。
# AP側のコンソールでFT関連のイベントログを監視する
hostapd_cli -i wlan0
> sta 00:11:22:33:44:55
# 出力される情報の中から、FT関連のケーパビリティやMobility Domain ID (MDID) が
# クライアント側から正しく送信されているか確認するもし古いIoTデバイスがFTに対応しておらず接続できない場合は、メッシュ側で「アダプティブ（適応型）FT」を構成するか、IoT専用の別SSID（FT無効）を切るのが実務上の定石です。メインのスマートフォンやPC用SSIDでは必ずFTを有効にし、快適なモビリティを確保しましょう。
—
4. まとめ：スマートホーム・モバイル時代のネットワーク設計へ向けて
今回は、メッシュWi-Fiの裏側でいかに高度な暗号キーの事前共有と高速ハンドシェイクが行われているか、IEEE 802.11r（FT）の仕組みを解説しました。
- ローミング遅延の元凶は、移動先での重たい認証と4ウェイハンドシェイクにある。
- 802.11r は、
PMK-R0/PMK-R1の階層構造と事前プレキャッシュにより、このプロセスを最小限に圧縮する。 - 現場では、クライアント（IoT機器等）の互換性に配慮しつつ、適切なモビリティドメインの設定を行うことがエンジニアの腕の見せ所。
パケットの挙動を解像度高く理解していれば、無線LANはもはや「目に見えないブラックボックス」ではなく、コントロール可能なインフラに変わります。皆さんのネットワーク構築やトラブルシューティングの現場で、ぜひこの知識を役立ててください。
それでは、また次の技術トピックでお会いしましょう！
コメント