帯域の調和と「スティッキー端末」の呪縛：バンドステアリングを再定義する
ネットワークエンジニアの端くれとして、家庭用Wi-Fiルーターのスペックシートに踊る「バンドステアリング」という文字を冷ややかな目で見てきた方は多いだろう。SSIDを統合し、クライアントを2.4GHzから5GHz/6GHzへ「よしなに」誘導する――。この耳当たりの良いマーケティング用語の裏側で、プロトコルスタックがどのような死闘を繰り広げているか、皆さんは考えたことがあるだろうか。
今日は、単なる「便利な機能」として片付けられがちなバンドステアリングの深淵と、それがもたらす「スティッキー端末（Sticky Client）」問題という現代のネットワークにおける難問について、パケットレベルの視点から紐解いていきたい。
—
バンドステアリングのアルゴリズム：魔法ではない、観測と拒絶の積み重ね
バンドステアリングの本質は、ルーター側からの「消極的な拒絶」にある。クライアントが低速な2.4GHz帯で Probe Request を投げても、AP（アクセスポイント）側があえて Probe Response を送らない、あるいは Authentication や Association の段階でステータスコード 17 （AP is busy）を返し、より好ましい帯域への接続を促すのが基本的な挙動だ。
しかし、この仕組みはクライアント側の実装に依存しすぎる。特に、IEEE 802.11k/v/rへの対応が不完全な安価なIoTデバイスや、古いWi-Fiチップを積んだクライアントは、電波強度が低下しても現在のAPにしがみつく。これが「スティッキー端末問題」だ。
内部挙動の最適化：RTTとTCPハンドシェイクへの影響
クライアントが不適切な帯域に留まり続けると、チャネルの空気時間（Airtime）が浪費され、結果として TCP の Retransmission が多発する。RTT（Round Trip Time）が増大すれば、TLS ハンドシェイクのレイテンシが跳ね上がり、アプリケーション層での体感速度は著しく低下する。
特に、TCP の初期ウィンドウサイズ（initcwnd）が小さい状態でパケットロスが起きると、Slow Start アルゴリズムが正しく機能せず、スループットは理論値の数パーセントまで落ち込む。
—
実践的チューニング：スティッキー端末を「強制」排除する
ルーターのファームウェアやコントローラーレベルで制御可能な場合、単なるRSSI閾値による判定だけでなく、クライアントのトラフィック特性を監視し、Probe 応答の抑制と Disassociation フレームの積極的な送信を組み合わせる必要がある。
以下は、LinuxベースのAP（hostapd等）を想定した、接続性を制御するための概念的なパラメータ設定例である。
# hostapd.conf の設定例
# 2.4GHz帯への接続を抑制し、5GHzへの移行を強力に促す設定
# RSSIによるクライアントの追い出し（-75dBm以下は強制切断）
disassoc_low_ack=1
# 接続試行時に、2.4GHzでのProbe Responseを意図的に遅延させる（ミリ秒単位）
probe_resp_delay=500
# 802.11v BSS Transition Management の有効化
# クライアントに対して、より電波強度の強いAP/バンドへ移動するよう通知を送る
bss_transition=1—
脆弱性とセキュリティ：ハンドシェイクの「隙」を突く
バンドステアリングを過剰に働かせると、思わぬセキュリティリスクを招く。特に 802.11w（Management Frame Protection）が未実装の環境で Disassociation フレームを乱発すると、悪意のあるアクターがこれらを偽装してDoS攻撃を仕掛けることが可能になる。
また、バンドステアリングによって発生するクライアントの再接続は、EAP-TLS や WPA3-SAE のハンドシェイクを再発生させる。この際、TCP バッファが適切にクリアされない状態で高速なローミングが発生すると、セッションの不整合を突いた攻撃の機会を与えてしまう可能性がある。
トランスポート層の最適化案
インフラ構築においては、以下の設定を検討することで、帯域切り替え時のパケットロスを最小限に抑えることができる。
1. TCP Fast Open (TFO) の活用:
再接続時の TLS ハンドシェイクのオーバーヘッドを削減する。
2. BBR (Bottleneck Bandwidth and RTT) の採用:
クライアントが低速な2.4GHzから高速な6GHzへ切り替わった際、CUBIC よりも素早く帯域幅を再評価し、スループットを最大化する。
# LinuxカーネルでのBBR有効化コマンド
# ネットワークの輻輳制御をより賢いアルゴリズムへ切り替える
sysctl -w net.core.default_qdisc=fq
sysctl -w net.ipv4.tcp_congestion_control=bbr—
結論：技術者は「見えないパケット」を信じろ
バンドステアリングは、家庭用デバイスの利便性を最大化するための「最後のあがき」とも言える技術だ。しかし、真に高密度かつ安定したネットワークを構築するためには、ルーター任せの自動化に頼るのではなく、クライアントの特性を理解し、RSSIや BSSID の統計情報を基に、プロトコルレベルで制御をかける必要がある。
ネットワークのパフォーマンスとは、結局のところ、いかにして「不必要な通信（再送やハンドシェイクの繰り返し）」を削ぎ落とし、純粋なデータペイロードを届け続けるかという技術的誠実さに帰結する。
明日、皆さんの家庭やオフィスにあるAPのログを覗いてみてほしい。そこに刻まれているのは、接続を切られまいと必死に Probe を送るスティッキー端末たちの、健気で、そして厄介なパケットの軌跡であるはずだ。
コメント