Wi-Fiローミングの深淵：スティッキー端末を飼い慣らし、802.11k/v/rを極める
ネットワークエンジニアの端くれなら一度は経験があるだろう。リビングから寝室へ移動した途端、オンライン会議の音声が途切れ、SSHセッションがフリーズするあの瞬間。原因は明白、端末が古いAP（アクセスポイント）にしがみつく「スティッキーローミング」現象だ。
なぜモダンなWi-Fi環境でもこの問題が起きるのか。そして、それを解決するために802.11k/v/rをどうチューニングすればよいのか。今日は、パケットキャプチャの向こう側にある「真実」を紐解いていく。
—
1. スティッキーローミングの正体：クライアント側の「怠慢」
まず理解しなければならないのは、ローミングの意思決定権は100%クライアント側（端末）にあるという事実だ。AP側から「あっちへ行け」とプッシュ（Disassociate）したとしても、端末がそれを無視、あるいは再接続に失敗すれば通信は途切れる。
多くのクライアントは、受信信号強度（RSSI）が一定の閾値（通常 -70dBm〜-75dBm程度）を下回るまで、現在のAPを離そうとしない。この「しがみつき」こそが、トランスポート層におけるTCP再送の嵐を招き、RTT（Round Trip Time）を増大させる元凶だ。
2. IEEE 802.11k/v/r：パケットレベルの最適化
インフラ側の設計として、以下の3要素を単なる「機能」ではなく「プロトコル上の最適化」として捉える必要がある。
802.11k (Neighbor Reports)
クライアントに「周辺のAPリスト」を事前に教える。スキャン範囲を絞り込むことで、チャンネルを総当たりする時間を劇的に短縮する。
802.11v (BSS Transition Management)
APがクライアントに対して「あっちの方が空いていて電波も強いよ」とサジェストを送る。端末のOSがこれを解釈すれば、自発的なハンドオーバーを促せる。
802.11r (Fast BSS Transition)
ここが本題だ。認証のオーバーヘッドを削減する。通常、WPA2/3-Enterprise環境では、ローミングのたびにRADIUSサーバーとの間で4ウェイハンドシェイクが必要となる。802.11rは、初回認証時のキー（PMK）をAP間で共有（Key Holder化）することで、ハンドシェイクを数パケットに圧縮する。
—
3. 実践：802.11rの検証とTCPチューニング
ローミング時の「切断」を最小化するためには、TLSハンドシェイクを含む上位層のタイムアウトを考慮したバッファ設計が不可欠だ。
LinuxカーネルにおけるTCPチューニング
ローミング中に発生する短時間のパケットロスを補完するため、sysctlでの調整を推奨する。
# ローミング中のバーストロスを許容するため、TCPキューを拡張
sysctl -w net.ipv4.tcp_rmem="4096 87380 16777216"
sysctl -w net.ipv4.tcp_wmem="4096 65536 16777216"
# 再送タイムアウト(RTO)の初期値を短くし、高速な回復を狙う
# ローミング直後のパケットロスに即座に応答させる設定
sysctl -w net.ipv4.tcp_retries2=5Wi-Fiローミングの検証（wpa_cliコマンド）
実際にローミングの挙動を追うには、wpa_cliを用いてイベントを監視する。以下のスクリプトは、ローミング発生時のタイムスタンプとイベントを記録する例だ。
import subprocess
import time
def monitor_roaming():
# wpa_cliのイベントをストリームとして読み込む
process = subprocess.Popen(['wpa_cli', '-i', 'wlan0', 'monitor'], stdout=subprocess.PIPE)
while True:
line = process.stdout.readline().decode('utf-8')
if "CTRL-EVENT-BSS-ADDED" in line or "CTRL-EVENT-CONNECTED" in line:
print(f"[{time.ctime()}] ローミングイベント発生: {line.strip()}")
# ここでパケットキャプチャのトリガーを引くことも可能
# ローミングの閾値を調整できるOSであれば、-70dBmよりも高い値
# (例: -65dBm)を推奨値として設定を検討する—
4. セキュリティとパフォーマンスのトレードオフ
802.11rを有効にする際、最大の懸念は「セキュリティの低下」ではない。「クライアントとの互換性」だ。古いIoTデバイスや一部のAndroid端末は、802.11rのパケットを正しくパースできず、接続すらできないケースがある。
もし、高いセキュリティとパフォーマンスを両立させたいのであれば、以下の構成をインフラアーキテクチャの標準とすべきだ。
1. WPA3-SAEの採用: PMF（Protected Management Frames）が必須となり、ローミング時の管理フレームの改ざんリスクを排除できる。
2. Fast Transition (FT) Over-the-DS: AP間でバックボーンネットワークを経由して認証キーを渡す方式。有線LANの物理的な遅延が、そのままローミング時間となる。
3. MTUの最適化: 802.11rのパケットヘッダーは通常より大きくなる。ネットワーク全体のMTUを1500から少し下げ（1450〜1480）、フラグメンテーションによる再送を回避する設定も、地味だが非常に効果的だ。
結びに代えて
ネットワークエンジニアリングとは、結局のところ「いかにして通信のゆらぎを隠蔽するか」という哲学である。802.11k/v/rを闇雲に有効にするのではなく、パケットキャプチャで EAPOL パケットのやり取りを観察し、ハンドシェイクが完了するまでのミリ秒を追い詰める。
その「泥臭い」試行錯誤こそが、インフラを「繋がるのが当たり前の空気のような存在」へと昇華させる唯一の道だ。次回の現場では、ぜひ統計的な数値だけでなく、フレームレベルのハンドシェイクを凝視してみてほしい。そこには、OSやAPの設計者の意図が、ビットの羅列として刻まれているはずだ。
コメント