「スティッキークライアント」の苛立ち
誰もが経験したことがあるでしょう。重要なZoom会議中、デスクから会議室へ移動していると、突然音声がロボットのような不自然な音に変わります。ノートPCは、すぐ頭上にあるアクセスポイント（AP）を無視して、15メートルも離れた場所にある微弱な信号のAPにしがみつこうとします。接続が実質的に切れるまで、頑なに離そうとしません。5秒間の沈黙と通話の切断を経て、ようやく近くのAPへとホップするのです。
この「スティッキークライアント（粘着質なクライアント）」の挙動は、ネットワークにおける古典的な悩みの種です。ほとんどの設定では、ローミングの判断は完全にスマートフォンやノートPC側に委ねられています。インフラ側との連携がなければ、ローミングは遅く、通信を中断させるものになります。hostapdを使用してLinuxベースのWi-Fi環境を構築している場合、これがおそらく直面する最大のボトルネックとなるでしょう。
なぜ標準のローミングは失敗するのか
標準的なローミングは、リアルタイムのトラフィックにとって「スローモーションの惨事」です。一般的なWPA2-PSK設定でクライアントがAP-AからAP-Bに移動すると、完全な再認証がトリガーされます。このプロセスは非常に手間がかかります。デバイスはチャネルをスキャンし、認証フレームを交換し、暗号化キーを導出するために新しい4ウェイ・ハンドシェイクを完了させる必要があります。WPA2-Enterpriseを使用している場合は、さらにRADIUS/EAPの交換を待つ必要があります。
この一連のシーケンスには100msから500msかかることがあります。一見速そうに聞こえますが、SSHやVoIPのようなリアルタイム・アプリケーションは、遅延が50msを超えた瞬間にカクつき始めます。200msを超えると、接続が完全に失敗したように感じられます。デバイスは、スキャンを行うためにデータの送信を停止するまで他のAPがどこにあるかを知ることができないため、この移行期間中は実質的に「盲目」状態になります。
3つの解決策：802.11r、802.11k、802.11v
真にシームレスな遷移を実現するには、3つの特定のプロトコルを連携させる必要があります。私はこのスタックを高密度のオフィス環境に導入してきましたが、感度の高いVoIP通話でもパケットロスが1つも発生しないレベルまで、ローミング時間を一貫して短縮できています。
802.11r (高速BSS遷移)
802.11r、または高速遷移（Fast Transition: FT）は、最も重要な役割を担います。これは、クライアントが実際に切り替わる前に、クライアントと新しいAPが4ウェイ・ハンドシェイクを処理できるようにするものです。デバイスがAP-Aとのリンクを切断する頃には、すでにAP-Bとキーの交渉を終えています。これにより、遷移時間は50ms未満に短縮されます。
802.11k (無線リソース管理)
802.11kは、クライアントに「地図」を提供します。バッテリーを消耗し時間を無駄にする40以上の全チャネルのスキャンの代わりに、クライアントは「ネイバー報告（Neighbor Report）」を要求します。APは、近くにあるアクセスポイントとその現在の負荷をまとめたリストを返します。これにより、クライアントは次にどのチャネルにジャンプすべきかを正確に把握できます。
802.11v (BSS遷移管理)
802.11vは、ネットワークに「意志」を与えます。AP-Aがクライアントの信号強度（RSSI）が-75 dBmを下回っている一方で、AP-Bが-50 dBmの信号でアイドル状態にあることに気づいた場合、BSS遷移管理リクエストを送信できます。これは実質的にクライアントに対し、「今すぐAP-Bに移動したほうが、ずっと快適ですよ」と促すものです。
hostapdでの設定の実装
これを設定するには、hostapd.confを修正する必要があります。すでに基本的な動作設定が完了していることを前提として、ここに802.11r、k、vのパラメータを重ねていきます。
ステップ1：802.11rの基本設定
まず、モビリティドメイン（Mobility Domain）を定義します。クライアントがローミングできるすべてのAPは、同じ4文字の16進数IDを共有する必要があります。
# 802.11r 高速BSS遷移
mobility_domain=e642
# FTの無線経由(0)またはDS経由(1)を有効化
ft_over_ds=0
# この特定のAPの一意の識別子
nas_identifier=ap-office-01
# R0KHとR1KHをローカルで生成
ft_psk_generate_local=1ステップ2：キー管理
802.11rが複数のハードウェアユニット間で機能するためには、AP同士が互いを信頼する必要があります。AP-1がAP-2との以前のハンドシェイクを検証できるように、R0KH（Remote Key Holder）とR1KHのリストを定義する必要があります。
AP-1 (IP: 192.168.1.10, MAC: aa:bb:cc:dd:ee:01) の場合：
# 形式: [MACアドレス] [NAS-ID] [32文字の16進数キー]
# ローカルAPのエントリ
r0kh=aa:bb:cc:dd:ee:01 ap-office-01 00112233445566778899aabbccddeeff
r1kh=aa:bb:cc:dd:ee:01 aa:bb:cc:dd:ee:01 00112233445566778899aabbccddeeff
# リモートAP (AP-2) のエントリ
r0kh=aa:bb:cc:dd:ee:02 ap-office-02 00112233445566778899aabbccddeeff
r1kh=aa:bb:cc:dd:ee:02 aa:bb:cc:dd:ee:02 00112233445566778899aabbccddeeff※32文字の16進数キーは、ローミンググループ内のすべてのAPで同一である必要があります。
ステップ3：802.11kと802.11vの有効化
これらの設定は単純ですが、最新のiPhoneやAndroidデバイスと連携するためには不可欠です。
# 802.11k: ネイバー報告とビーコン報告
rrm_neighbor_report=1
rrm_beacon_report=1
# 802.11v: BSS遷移とスリープモード
bss_transition=1
wnm_sleep_mode=1
# 低信号時にACKが失敗した場合、クライアントにローミングを促す
disassoc_low_ack=1ステップ4：キー管理の更新
hostapdにFT対応のスイートを通知させる必要があります。wpa_key_mgmtの行を更新して、FT-PSKを含めます。
wpa_key_mgmt=WPA-PSK FT-PSKテストと検証
hostapdを再起動したら、クライアントデバイスからの接続を確認します。LinuxノートPCを使用している場合は、wpa_cliでステータスを確認してください。
sudo wpa_cli -i wlan0 statuskey_mgmt=FT-PSKという表示を探します。もしWPA2-PSKのままなら、高速遷移はトリガーされていません。また、AP間を歩きながらゲートウェイへの継続的なpingを実行することもできます。標準的な設定では3〜4個のパケットロスが見られるかもしれませんが、これらの最適化を行えば、ロスはゼロになり、ホップ中の遅延スパイクも30〜50ms以内に収まるはずです。
よくある落とし穴
802.11rの導入が失敗する原因として、以下の3つの見落としが多く見られます。
- 時刻のズレ: AP間でシステム時刻が異なると、ハンドシェイクキーが期限切れとして拒否されることがあります。NTPを使用して、完全に同期させてください。
- L2接続性: ローミングが機能するのは、すべてのAPが同じレイヤー2セグメント（同じVLAN/ブリッジ）にある場合のみです。移動後にクライアントが新しいDHCPアドレスを取得しなければならない場合、802.11rは役に立ちません。
- ドライバの制限: 一部の安価なWi-FiカードはFTオフロードをサポートしていません。設定ファイルで悩む前に、ハードウェアが
NL80211_IFTYPE_APをサポートしているか確認してください。
最後に
Wi-Fiのパフォーマンスを改善することは、単に送信出力を上げることではありません。実際、出力を上げると「スティッキークライアント」問題が悪化することがよくあります。802.11r、k、vを実装することで、デバイスがインテリジェントなローミング判断を行うために必要なデータを提供できます。hostapdでの手動設定には手間がかかりますが、その結果、移動中も安定したプロフェッショナルグレードেরワイヤレス体験が得られるのです。
