こんにちは。インフラの現場を渡り歩くネットワークエンジニアの皆さん、日々のWi-Fiトラブルシューティングや設計にお疲れ様です。
「オフィスや倉庫の隅に移動しただけで、なぜかWeb会議のパケットがドロップする」「メッシュWi-Fiを導入したのに、手元の端末（STA）が一番電波の強いアクセスポイント（AP）に張り付いてくれず、遠くのAPの残骸を掴み続けてスループットが死んでいる」——。そんな泥臭い無線LANの現場の悩みに、皆さんも一度は直面したことがあるのではないでしょうか。
現代の企業ネットワークや高密度なスマートホーム環境において、物理的な電波の強さ（RSSI）だけに頼ったローミング設計はすでに破綻しています。端末が自発的に「あ、こっちのAPの方が電波強いな」と気づいて切り替えるのを待つ時代は終わり、インフラ側からスマートに誘導してあげる必要があります。
そこで鍵を握るのが、IEEE 802.11が規定する 802.11k/v/r という3つの聖なる規格です。今回は、これらが裏側のエアインターフェースでどのように連携し、パケットをミリ秒単位でバトンタッチしているのか、シニアの視点から実務に直結する知識として紐解いていきます。
—
1. なぜ「普通のローミング」ではダメなのか？
私たちが普段何気なく使っているWi-Fiですが、ローミング（ハンドオーバー）の基本動作は、実は歴史的にかなり場当たり的でした。
標準的なローミングのシーケンスを思い浮かべてみてください。
1. 端末（STA）が現在接続しているAPの電波強度（RSSI）やリンク品質（SNR）の低下を検知する。
2. 端末が自ら周囲の全チャンネル（2.4GHzなら1, 6, 11ch、5GHzならW52/W53/W56の膨大なチャネル）をプローブ要求（Probe Request）を出しながらスキャンし始める。これをアクティブスキャンと呼びます。
3. 候補となるAPからのプローブ応答（Probe Response）を集め、最も条件の良いAPを選定する。
4. 旧APとのアソシエーションを切り、新APに対して4-Way Handshakeを含む再認証・鍵導出のプロセスを一からやり直す。
お気づきでしょうか？ ステップ2のスキャンにかかる時間だけでも数十〜数百ミリ秒を要し、最後のステップ4におけるIEEE 802.1Xの認証（EAPoL交換）や4-Way Handshakeの往復が発生すると、総ローミング中断時間は数百ミリ秒から場合によっては1秒以上に達します。
これでは、リアルタイム性の求められるVoIP通話やWebRTCによるビデオ会議、あるいは工場や倉庫のAGV（無人搬送車）の制御パケットは確実にロスし、セッション断を引き起こします。「ローミングのたびにプツッと途切れる」現象の根源は、まさにこの泥臭い「自力での総当たり探索とフル認証のコスト」にあるのです。
この課題をスマートに解決するために投入されたのが、802.11k（近隣AP情報の効率化）、802.11v（負荷分散とネットワーク支援）、802.11r（高速BSS遷移による認証のショートカット）の3兄弟です。
—
2. 802.11k / 802.11v / 802.11r の技術仕様と役割分担
それぞれの規格がエアインターフェース上でどのような役割を担っているのか、パケットの動きを見ていきましょう。
2.1 802.11k：隣人を知る（Neighbor Report）
従来、端末は周辺の全チャンネルを自力で総当たりスキャンしていました。これにはバッテリー消費も激しく、時間もかかります。
802.11kでは、接続中のAPに対して Neighbor Report Request を送信することで、AP側が管理している「周囲にどんなチャンネル・BSSIDのAPが存在するか」という近隣リスト（Neighbor Report）をピンポイントで取得できます。
これにより、端末は無駄なチャネルスキャンを一切行わず、あらかじめ指定されたターゲットチャネルだけをミリ秒単位でピンポイントに聴取（パッシブまたは短いアクティブスキャン）できるようになります。
2.2 802.11v：全体の交通整理（BSS Transition Management）
「あっちのAPの方が空いているから移動しなよ」と、インフラ側から端末にサジェスチョン（助言）を送るのが802.11vのBSS Transition Management (BTM) です。
例えば、特定のAPに端末が集中しすぎてエアタイム（Airtime）が圧迫された場合、APは BSS Transition Management Request フレームを端末に送信します。「このエリアの負荷が高いので、こちらの推奨する候補AP（Candidate List）のいずれかに移行してください」と促すわけです。
端末はこれを受け入れると、BSS Transition Management Response（ステータスコード: Accept）を返し、スムーズに移動を開始します。
2.3 802.11r：高速道路を通る（Fast BSS Transition / FT）
kとvによって「どこに、どうやって移動すべきか」の効率化が終わっても、最後に待ち受けているのが「認証の重さ」です。これを解決するのが802.11r、通称 FT（Fast BSS Transition） です。
通常のWPA2/WPA3-Enterprise環境では、RADIUSサーバーを巻き込んだ完全な認証（EAP交換）が走ります。802.11rでは、初回接続時に導出したPMK（Pairwise Master Key）から派生する PMK-R0 や PMK-R1 といったマスターキーを、同一モビリティドメイン（MDIDで定義された同一コントローラーやスイッチ配下のAP群）内であらかじめ安全に共有・キャッシュしておきます。
これにより、ローミング先のAPとの間ではフル認証を完全にバイパスし、アソシエーション要求/応答のフレーム（Reassociation Request/Response）のなかにFT情報要素（FTIE）を載せてやり取りするだけで、わずか1回のメッセージ交換（One-shot）で瞬時に暗号鍵の合意と接続が完了します。その中断時間は50ミリ秒以下、人間の耳やTCPの再送タイマーすら気づかないレベルのシームレスさを実現します。
—
3. 実務における設計・設定例（FreeRADIUS / 主なコントローラーの勘所）
インフラエンジニアとして現場でこれらを有効化する際の設定の勘所を見ていきましょう。ここでは、実務でよく遭遇するオープンソースのRADIUSサーバーである radiusd.conf や、一般的な企業向け無線コントローラー（Cisco Catalyst / Aruba / Enterasys等）を想定した設定・確認のポイントを整理します。
3.1 802.11r (FT) 運用時のRADIUS側の注意点
802.11r（特にFT-PSKやFT-EAP）を有効にする場合、バックエンドのRADIUSサーバーがPMK-R0/R1キーの導出やキャッシュ（PMK-R1 Key Distribution）をサポートしているか、あるいはコントローラー型（WLC）やクラウド管理型APが自律的にキーキャッシュを処理するアーキテクチャになっているかを確認する必要があります。
一般的な企業向けAP（例えばCisco Catalyst 9800等）でFTを有効にするWLANプロファイルのCLI設定スニペット例です。
# Cisco IOS-XE (Catalyst 9800 WLC) での無線プロファイル設定例
wlan-profile WLAN_SECURE_CORP
ssid Secure-Corp
security wpa wpa2
security wpa psk ascii 0 SuperSecretKey123!
security wpa ft # 802.11r (Fast BSS Transition) を有効化
security wpa ft mobility-domain 10AB # モビリティドメインID（HEX）を指定
security wpa ft reauth-time 600 # 再認証タイマーの指定ここで重要なのが mobility-domain（モビリティドメインID）の設計です。異なるフロアや建物間でシームレスにローミングさせたいAPグループは、必ず同一のモビリティドメインID（例: 10AB）に所属させる必要があります。これを間違えると、隣のAPへ移動した瞬間にFTハンドシェイクが失敗し、フォールバックして通常のフル認証が走るため、逆にローミングが遅延する原因になります。
—
4. トラブルシューティング：ローミング不良を暴くデバッグ手法
「802.11k/v/rを有効にしたのに、特定の古い端末（あるいは特定の産業用IoTデバイス）が頻繁に切断される、あるいはローミングしない」——。現場で最も頭を悩ませるこのトラブルの切り分け手法を解説します。
4.1 空中線上のパケットをキャプチャする（無線パケット解析）
有線LANであれば tcpdump やWiresharkで簡単にキャプチャできますが、Wi-Fiのローミング不具合は「エアインターフェース（空中）」を流れるフレームをキャプチャしなければ真相は見えてきません。
macOSやLinux（Wireshark + Monitor Modeに対応したUSB Wi-Fiアダプター）を使用し、対象チャンネルに固定してキャプチャを行います。
# macOSのairportユーティリティを使用して、特定のチャンネルとパケットロガーを起動する例
# (※ macOSのバージョンやハードウェアにより挙動が異なる場合があります)
sudo /System/Library/PrivateFrameworks/Apple80211.framework/Versions/Current/Resources/airport en0 sniff 6Wiresharkでキャプチャファイルを開いた際、以下のフィルターを使用してシーケンスを追跡します。
# Wiresharkのディスプレイフィルター例
# 802.11rのFT情報要素（FTIE）が含まれるフレームや管理フレームを抽出
wlan.fc.type_subtype == 0x00 # Association Request
or wlan.fc.type_subtype == 0x02 # Reassociation Request
or wlan_mgt.fixed.capabilities.ft == 14.2 実務でありがちな「罠」とチェックリスト
1. 古いクライアントドライバのバグ
- 802.11vのBTM（BSS Transition Management）を受信した端末が、実装のバグによって応答せず、そのままハングアップするか古いAPにしがみつき続けるケースがあります。
- 対策: 端末側のWi-Fiドライバ/ファームウェアを最新にアップデートする。どうしても改善しない古いIoTデバイスがある場合、そのSSIDだけ個別に802.11vのBTMを無効化する（ベンダー固有のSSIDプロファイル分離）といった割り切りも現場では必要です。
2. WPA3と802.11rの互換性
- WPA3-Personal (SAE) 環境下では、802.11rはFT-SAEとして動作します。古いWPA3クライアントの中には、FT-SAEのハンドシェイク実装が不完全なものがあり、接続に失敗することがあります。
- 対策: 移行期においては、WPA2/WPA3トランスitionモードと802.11rの組み合わせにおける挙動を、主要な検証端末で必ずスモークテストしてください。
—
5. おわりに：確実な設計が「見えない快適さ」を生む
ネットワークエンジニアの仕事は、すべてが正常に動いているときには誰からも感謝されず、トラブルが起きたときだけ真っ先に呼び出される職種です。しかし、今日解説した 802.11k/v/r のような仕様の機微を深く理解し、適切なパラメーターチューニングとフロア設計を行うことで、「このオフィス、どこを歩いてもWeb会議が途切れないな」という、ユーザーにとっての当たり前で最高の快適さを裏側から支えることができます。
教科書通りの仕様を覚えるだけでなく、実際の電波の挙動やパケットのやり取りに思いを馳せながら、皆さんのインフラ構築・運用の現場にぜひこの知見を役立ててください。
それでは、また次回の技術現場でお会いしましょう！
コメント