【実務・中級編】 RSSIとSNRに基づくローミング判定アルゴリズム – 家庭用ネットワーク・IoT・モバイル通信実践ガイド

こんにちは、ネットワークエンジニアの皆さん。現場で泥臭いトラブルシューティングに明け暮れ、日々パケットのささやきに耳を傾けているシニアエンジニアの私です。

オフィスやスマートホームのネットワーク構築で、こんな相談を受けたことはありませんか？
「最新のWi-Fi 7ルーターを導入したのに、なぜか端の部屋に行くと速度がガタ落ちする」「親機の目の前にいるのに、子機がわざわざ遠くの古い中継器にしがみついて離れない……」

そう、これが無線LANエンジニアを長年悩ませ続けている「スティッキー端末（Sticky Client）問題」です。

教科書には「電波が弱くなったらローミングする」とサラッと書かれていますが、実はどのタイミングでどのアクセスポイント（AP）へ切り替えるかの決定権は、インフラ側ではなくすべてクライアント端末（スマホやPCのOS、Wi-Fiチップのドライバー）に委ねられています。この端末側の気まぐれとも言えるローミング判定アルゴリズムを理解し、適切なしきい値を設計しないと、どれだけ高価なWi-Fi 6E/7の機器を導入しても宝の持ち腐れになってしまいます。

今回は、ローミングの裏側を支配するRSSIとSNRの物理的な意味から、実務で使える具体的なしきい値設計、そしてスティッキー端末をスマートに追い剥がすための回避策まで、現場の知見をたっぷり詰め込んで解説します。

—

1. ローミングを支配する2大指標：RSSIとSNRの正体

クライアント端末が「そろそろ別のAPに乗り換えようかな」と判断する際、主に以下の2つの無線指標を監視しています。

RSSI (Received Signal Strength Indicator)

受信信号強度。文字通り「今どれくらい電波が届いているか」の絶対値です。単位は dBm で表され、物理的な距離や障害物によって減衰するため、通常はマイナスの値（例: -45 dBm から -85 dBm）になります。

  • -30 dBm ～ -50 dBm: 最高のコンディション。APの真下にいます。
  • -65 dBm: 実用的な下限の目安。これより下がると変調方式（MCS）のランクが落ち始めます。
  • -75 dBm 以下: ローミングを検討し始めるべき危険水域。

SNR (Signal-to-Noise Ratio)

信号対雑音比。RSSIが「声の大きさ」だとすれば、SNRは「周囲の騒音（他のAPからの電波干渉やノイズフロア）に対して、どれだけクリアにその声が聞こえているか」という品質を表します。単位は dB です。

  • 30 dB 以上: 非常にクリア。最高速度が出せます。
  • 15 dB ～ 20 dB: 実用限界。干渉が多い環境。
  • 10 dB 以下: パケットロスが頻発し、通信がプチプチと途切れる状態。

【現場の教訓】
「電波（RSSI）は強いのに通信が遅い・切れる」というトラブルの9割は、同チャンネル干渉などによるSNRの悪化が原因です。単にRSSIのしきい値だけでローミングを設計すると、大きな落とし穴にハマります。

—

2. スティッキー端末問題はなぜ起きるのか？

なぜ端末は、もっと近くにある強力なAPに切り替えず、遠くのAPにしがみついてしまうのでしょうか？

その原因は、OSやWi-Fiチップベンダーの省電力・接続維持バイアスにあります。多くのクライアント端末は、「現在接続中のAPの電波が完全にロスト（通信断）するまで、次のAPを探さない（または切り替えない）」という保守的なアルゴリズムで実装されています。一度掴んだ絆をなかなか手放さない、頑固な職人のようなものです。

結果として、廊下を挟んだ向こう側の高速なAPが存在するにもかかわらず、リビングの古いAPからの-75 dBmの電波をか細く掴み続け、リンク速度が最低MCS（1 Mbpsや6 Mbpsなど）に落ち込み、フロア全体のエアタイム（電波の占有時間）を盛大に食いつぶす「ガンマン端末」が誕生してしまうのです。

—

3. しきい値設計とIEEE 802.11規格群の連携

この問題に対処するため、IEEE 802.11規格ではローミングを支援するためのいくつかのプロトコルが規定されています。これらを組み合わせることで、インフラ側から端末へ「こっちのAPの方が優秀だよ」と優しく（あるいは強制的に）促すことができます。

ローミングを円滑にする主要規格

1. IEEE 802.11k (Radio Resource Measurement)

  • 端末が周囲のAPの電波状況を効率的にスキャンできるよう、近隣APのリスト（Neighbor Report）を事前に提供します。これにより、端末が無駄なフルチャンネルスキャンを行う時間を削減します。

2. IEEE 802.11v (BSS Transition Management)

  • AP側からクライアントに対し、「負荷分散のために、あっちのAPへローミングしてくれませんか？」と提案（BTM Request）を送る機能です。これを受信した端末は、自発的にローミングを開始しやすくなります。

3. IEEE 802.11r (Fast BSS Transition / FT)

  • ローミング時の認証ハンドシェイクを高速化し、ローミング中のパケットロスや音声通話の途切れ（プツ断）を防ぎます。

—

4. 実務で設定する！無線コントローラー・APの設定例

では、実際のエンタープライズ向けWi-Fiコントローラーや、オープンソースのAPファームウェア（OpenWrtなど）でどのようにしきい値を設定すべきか、具体的な設定ファイルの例を見ていきましょう。

以下の設定例は、「RSSIが一定値を下回った端末を積極的に排除（切断）し、強制的により良いAPへ誘導する」ための、いわゆるバンドステアリングおよびローミングアグレッシブネスのチューニング例です。

# ネットワーク管理用YAML設定ファイルのサンプル
# エンタープライズ向けWi-Fiコントローラーの設定イメージ

wifi_roaming_policy:
  global_settings:
    enabled: true
    # IEEE 802.11k/v/r の一括有効化（シームレスローミングの必須基盤）
    dot11k_neighbor_report: true
    dot11v_bss_transition: true
    dot11r_fast_roaming: true

  radio_bands:
    - band: "5GHz"
      # スティッキー端末対策の肝：クライアントの最小RSSIしきい値
      # この値を下回った端末からのフレームを受信した場合、AP側でサイレントドロップまたは強制切断を行う
      min_rssi_threshold_dbm: -72
      
      # BSS Transition Management (802.11v) のトリガーしきい値
      # -68 dBmを下回った時点で、近隣の負荷が低いAPへの移行を促すクエリを送信
      bss_transition_threshold_dbm: -68

      # デアソシエーション（強制切断）の猶予時間（秒）
      # BTMを送っても無視してしがみつき続ける端末を強制的に蹴落とすまでのタイムアウト
      deauth_on_low_rssi: true
      deauth_timeout_sec: 5

    - band: "2.4GHz"
      # 2.4GHz帯は干渉が多く遠くまで届くため、あえてしきい値を厳しくし、
      # 可能な限り5GHz帯やWi-Fi 6E/7の6GHz帯へ誘導（バンドステアリング）する
      min_rssi_threshold_dbm: -78
      bss_transition_threshold_dbm: -72
      deauth_on_low_rssi: true
      deauth_timeout_sec: 3

パラメーターチューニングの現場のコツ

  • 攻めすぎたしきい値に注意: 例えば -60 dBm などの非常に高い値で強制切断（Deauth）を設定してしまうと、わずかに電波が揺らいだだけで端末が頻繁に切断・再接続を繰り返し、かえってWeb会議が切れるなどの致命的なトラブルにつながります。まずは -72 dBm あたりからテストし、フロアの減衰特性を見ながら -75 dBm 付近で落ち着かせるのが安全です。
  • デバイスの多様性を考慮する: 安価なIoT家電や古いスマートスピーカーの中には、802.11v や 802.11r の実装がバグっているものが存在します。アグレッシブなローミング設定を有効にした途端、特定のIoT機器が一切繋がらなくなる現象（いわゆる「IoT孤立問題」）が発生するため、SSIDを分ける、あるいは当該端末のマックアドレスを例外リスト（BTM除外）に登録するなどの泥臭い対応が必要になります。

—

5. トラブルシューティング：ローミングの挙動をデバッグする

「端末がちゃんとローミングしているか」を確認するためには、感覚に頼らずパケットやログを追う必要があります。Linux環境やスマートフォンの開発者モード、あるいは無線アナライザーを活用した実務的なデバッグ手順を解説します。

CLI / ログからの追跡

Linuxクライアント（ラズベリーパイやノートPC）で、現在の接続状態やRSSIの変動をリアルタイムに監視するには、iw コマンドや watch コマンドを組み合わせます。

# 1秒ごとにWi-Fiのリンク状態（RSSIやTx/Rxビットレート）を監視する
# インターフェース名（wlan0等）は環境に合わせて書き換えてください
watch -n 1 "iw dev wlan0 link"

出力の見方のポイント:

  • signal: 現在のRSSI（例: -67 dBm）
  • rx bitrate / tx bitrate: 現在の変調速度。これが不自然に低い値（例: 1 Mbpsや6.5 Mbps）で固定されている場合、典型的なスティッキー状態です。

また、AP側のsyslogやイベントログを tail で監視し、BSS Transition Management Request が送出された後に端末が正しく切断（Association）し直しているかを追跡します。

# SyslogからWi-Fiのローミング・認証関連のログをリアルタイム抽出する
tail -f /var/log/syslog | grep -E "Deauth|Association|BSS-Transition|Roaming"

—

まとめ：美しい理論と現場の泥臭さのバランス

Wi-Fiの進化は目覚ましく、Wi-Fi 6EやWi-Fi 7ではマルチリンクオペレーション（MLO）など、より高度な帯域活用が可能になっています。しかし、電波という目に見えない物理層を相手にしている以上、「どこで切り替えるべきか」というローミングの基本原則は変わりません。

  • RSSIで大まかな距離と減衰を測り、SNRで通信の品質を見極める。
  • 802.11k/v/rを適切に有効化し、インフラ側からスマートにエスコートする。
  • どうしても頑固な端末には、適切な -dBm しきい値による強制切断（BTM / Deauth）という名の「愛のムチ」を使う。

ネットワークの最適化に「これさえやれば絶対に完璧」という魔法の杖はありません。実際に現場に足を運び、フロアのレイアウトや壁の材質、利用者のデバイス傾向を観察しながら、シキイ値をミリ単位（dBm単位）で追い込んでいく。その泥臭いプロセスの積み重ねこそが、ユーザーに「このWi-Fi、なんだかいつも快適だ」と言わせる最高のエンジニアリングなのです。

皆さんのネットワークが、今日もパケットロスなく軽快に駆け巡ることを祈っています！

スポンサーリンク

コメント

タイトルとURLをコピーしました