バンドステアリングの「理想」と「現実」：エンジニアが向き合うスティッキー端末問題
ネットワークエンジニアの皆さん、お疲れ様です。家庭用Wi-Fiルーターのスペックシートに必ずと言っていいほど記載されている「バンドステアリング」。一見、魔法のように2.4GHzと5GHzを適切に振り分けてくれる便利機能に見えますが、現場で設計やトラブルシューティングに携わる我々にとっては、時に頭痛の種になることも多いですよね。
今日は、マーケティング用語の皮を被ったこの機能の裏側にあるロジックと、エンジニアとしてどう「スティッキー端末（古いルーターに固執する端末）」を飼い慣らすかについて、泥臭い知見を共有したいと思います。
—
1. バンドステアリングのアルゴリズム：魔法の裏側にある「追い出し」のロジック
バンドステアリングの正体は、クライアントデバイス（STA）に対するルーターからの「誘導」です。IEEE 802.11規格では、どのアクセスポイント（AP）に接続するかは完全にクライアント側の裁量に委ねられています。そのため、ルーター側は「もっと良い電波があるよ」と、あの手この手でクライアントを追い出し、再接続を促す必要があります。
一般的なバンドステアリングのシーケンスは以下の通りです。
1. プローブ（Probe）抑制: 2.4GHz帯でクライアントが Probe Request を送っても、ルーターがこれを無視（ドロップ）します。
2. ステアリング判定: ルーターは、RSSI（受信信号強度）やトラフィック負荷状況を評価し、5GHz/6GHzへの移行が妥当か判断します。
3. 強制切断（Deauthentication）: 2.4GHzで接続し続けようとする端末に対し、Deauth フレームを送りつけて接続を切断します。
4. 再接続誘導: 追い出されたクライアントが再接続先を探す際、5GHz側の Probe Response だけを返すことで、半強制的に5GHzへ誘導します。
この「追い出し」の閾値パラメーターが調整できないルーターが多いことが、我々エンジニアを悩ませる最大の要因です。
—
2. スティッキー端末問題：なぜ彼らは低速バンドを離さないのか
「電波強度は十分なはずなのに、なぜか遠くの2.4GHzに張り付いている」。これがスティッキー端末問題です。
主な原因は、クライアント側のOSやNICドライバの「ローミングアルゴリズムの保守性」にあります。多くの端末は、現在のリンクが切れるまで次のAP（またはバンド）を探しに行きません。特に、家庭内の移動中に一度掴んだ2.4GHz帯の接続を、RSSIがマイナス80dBmを下回るまで手放さない挙動は、現代のマルチデバイス環境では致命的です。
—
3. 実践的デバッグ：パケットから現状を可視化する
論理的に追い詰めるために、まずは現場でパケットをキャプチャしましょう。tcpdump を使って、Deauth フレームが飛んでいるかを確認するのが第一歩です。
# wlan0インターフェースでAPからのDeauthフレームを監視する
# 0x0cは管理フレームのDeauthを指すフィルタリング例
sudo tcpdump -i wlan0 -e type mgt subtype deauthもし、特定の端末が接続を拒絶されているのに再接続を繰り返している様子が見えれば、バンドステアリングのアルゴリズムが「過剰な追い出し」を行っている証拠です。
—
4. エンジニアとしてどう対処するか：実装と運用のTips
もしあなたがカスタムファームウェアや、高度な設定が可能なOpenWrtベースのAPを運用しているなら、以下の hostapd の設定例を参考に、ステアリングの挙動をチューニングしてみてください。
# /etc/hostapd/hostapd.conf の設定例
# 5GHz側の優先度を高める設定
# 2.4GHz側で高負荷（クライアント数やスループット）を検知した際に
# ステアリングを積極的に行うためのパラメーター
band_steering_threshold_rssi=-70 # RSSIが-70dBm以下ならステアリング対象にする
band_steering_load_balancing=1 # 負荷分散を有効化
# 端末がスティッキーな場合、再接続を制限する（最小待機時間の設定）
# 短時間での過剰なDeauthを防ぐための運用上の工夫
disassoc_low_ack=1また、クライアント側の挙動を制御できない以上、API経由でトラフィック状況を監視し、特定のMACアドレスに対して「ブラックリスト入り」させるようなスクリプトを組むのも手です。
import requests
# ルーターの管理APIへアクセスし、特定の端末のRSSIを監視する擬似コード
def check_sticky_client(mac_address):
# ルーターの内部APIからクライアントリストを取得
response = requests.get("http://192.168.1.1/api/clients")
client_data = response.json()
# 対象クライアントの情報を抽出
target = next((c for c in client_data if c['mac'] == mac_address), None)
# 5GHz圏内にいるのに2.4GHzに固執している場合、一度接続をリセットする
if target and target['band'] == '2.4GHz' and target['rssi'] > -60:
print(f"クライアント {mac_address} を5GHzへ強制誘導します...")
# API経由でキック（Deauth実行）
requests.post("http://192.168.1.1/api/kick", json={"mac": mac_address})
# 定期的に実行する運用を想定—
まとめ：ネットワークは「生き物」である
バンドステアリングは便利な機能ですが、結局のところ「クライアントの自主性に任せる」というWi-Fiの根本的な仕様と、無理やりコントロールしたいという「管理者の欲望」が衝突する場所です。
現場でトラブルに遭遇した際は、まず「クライアント側がどのタイミングでローミングを判断しているか」をログから読み解いてください。ステアリングが「追い出し」に失敗しているのか、それともクライアントが「頑固に接続を維持しようとしている」のか。この切り分けができるだけで、対応の精度は劇的に向上します。
ネットワークは生き物です。スペックシートの数字を信じすぎず、パケットの挙動という「嘘をつかない事実」を信じて、設計・運用に当たってください。次回は、メッシュWi-Fiにおけるバックホール通信の最適化について、さらに深掘りしていきましょう。
コメント