top of page
検索

【第1章】同一SSID・複数AP環境の技術解説 — 接続先を決めるのは端末である

シリーズ「複数APの同一SSID環境での端末接続メカニズム」全3回の第1回。本章では端末がAPを選ぶ仕組みとOS別の実装差を、第2章では同一チャンネルAP間の物理を、第3章では隠れ端末の実例解剖とサイトサーベイ実務を扱います。


「SSIDを揃えてAPを複数台置けば、端末が勝手に一番良いAPにつながってくれる」— 無線LANの設計・運用に携わっていると、この期待が裏切られる場面に何度も出会います。会議室を移動したのにノートPCが遠くのAPを掴んだまま遅い。至近に空いているAPがあるのにスマホが粘着する。原因を理解する鍵は、802.11の設計思想にあります。接続先を決める権限は、規格上100%端末側にあるのです。

本章では、同一SSID複数AP環境(ESS)における端末の接続・ローミングのメカニズムを、規格の仕組みからOS別の実装差まで掘り下げます。


同一SSID・複数AP環境の技術解説
同一SSID・複数AP環境の技術解説


1. ESSの基本構造 — 同じ名前、別々の顔


同一SSIDで複数APを運用する構成は、802.11規格ではESS(Extended Service Set)と呼ばれる正式な設計です。各APはBSS(Basic Service Set)という独立したセルを形成し、それぞれ固有の**BSSID(APの無線インターフェースのMACアドレス)**を持ちます。

端末(STA)から見ると、同じSSIDを名乗る複数の候補が、それぞれ別のBSSIDを持つリストとして見えます。チャンネルが同じでも異なっても、識別は常にBSSID単位で行われるため、「同じ名前のAPが複数あって混乱する」ことは仕組み上ありません。混乱するのは、むしろ人間の側の期待です。


接続までの3ステップ

端末が1台のAPに接続するまでの流れは次の通りです。


① スキャン(AP発見)

  • パッシブスキャン: 各チャンネルに滞在し、APが定期送信するビーコン(標準で約102.4ms間隔)を待ち受ける

  • アクティブスキャン: Probe Requestを送出し、Probe Responseを受け取る。パッシブより速いが電波を消費する


② 認証と接続

  1. Authentication(Open System認証。2フレームの形式的な手続き)

  2. Association Request/Response(対応レート、HT/VHT/HE capabilities、チャンネル幅などの能力交換。端末にAIDが付与される)

  3. 4-way handshake(WPA2/WPA3の暗号鍵確立。パスフレーズが同一なら鍵の素材は共通だが、セッション鍵PTKはAPごとに個別に導出される)


③ データ通信開始

ここで最重要の事実を確認します。**ステップ①で見つけた候補のうち、どのBSSIDを選ぶかのアルゴリズムは802.11規格で定義されていません。**完全に端末実装(OS・ドライバ・チップファームウェア)に委ねられています。AP側やネットワーク側から「このAPにつなげ」と強制する標準手段は存在しないのです。


2. ローミング — 端末はいつ、なぜ乗り換えるか


接続後、端末が移動して電波が弱くなると、より良いAPへの乗り換え(ローミング)が起きます。これも端末の自発的判断です。フローは以下です。

  1. 現接続のRSSIが端末固有のトリガー閾値を下回る

  2. 端末が同一SSID(ESSID)の候補BSSIDをスキャン

  3. 現APより一定以上強い候補があればReassociation(再接続)

  4. 有線側では、新APが端末のMACアドレスでフレームを送出し、上流スイッチのMACテーブルが更新されて下り経路が切り替わる(同一VLAN/サブネットならIPアドレスは維持)


なぜ端末は「粘る」のか — スティッキークライアント問題の構造

現場で最も悩まされるのが、至近に良いAPがあるのに古いAPに粘着し続けるスティッキークライアントです。これは端末の欠陥ではなく、合理的なトレードオフの結果です。


理由1: スキャンは通信を止める。 ローミング判断には他チャンネルのスキャンが必要ですが、スキャン中は自チャンネルを離れるため通信が中断します。オフチャンネル滞在は1chあたり数十〜150ms、5GHz全チャンネルを舐めると合計1秒級です。VoIP通話中にこれをやると音が途切れます。だから各OSは「本当に必要になるまでスキャンしない」方向に倒しています。


理由2: ピンポン防止のヒステリシス。 RSSIはフェージングで常時±5dB程度揺れます。「少しでも強い方へ」というロジックだと、2つのAPの境界で切り替えが発振します(ピンポンローミング)。これを防ぐため、候補には現APより8〜12dB強いことを要求します。粘着とピンポンはトレードオフの両端であり、各社の閾値はその妥協点なのです。


高速ローミングと誘導の規格 — 11k/v/r


端末主導の原則を保ったまま、インフラ側が「支援」する仕組みが3つあります。

  • 802.11k (RRM): APが近隣APリスト(Neighbor Report)を端末に渡し、スキャン対象チャンネルを絞らせる。スキャンコスト(理由1)を直接削減

  • 802.11v (BTM): APが「あちらのAPへ移ってはどうか」とBSS Transition Requestを送る。ただしあくまで勧告で、従うかは端末次第

  • 802.11r (FT): 鍵階層を事前配布し、ローミング時の4-way handshakeを省略。切替ギャップを数十msに短縮

これらは「端末が賢く動くための情報提供」であり、決定権の所在は変わりません。


ローミング判断のタイムライン図
ローミング判断のタイムライン図


3. OS別・チップ別の選択ロジック — 公開情報で読み解く


ここからが本章の核心です。「端末実装依存」の中身を、公開情報ベースで層別に整理します。なお各社の仕様はバージョンで変わり得るため、確定判断が必要な案件では対象実機での検証が前提です。


Apple (iOS / iPadOS / macOS) — 最も詳細に公式文書化


Appleは自社デバイスのローミング挙動を展開ガイドで明文化しています。公式値は次の通りです。

デバイス

トリガー閾値

候補の要求(データ送信中)

候補の要求(アイドル時)

iPhone 5s以降 / 主要iPad

-70dBm

現APより+8dB強い

+12dB強い

Mac(Appleシリコン/Intel共)

-75dBm

+12dB強い

+12dB強い

例として、通話中のiPhoneが-75dBmまで落ちた場合、-67dBm以上の候補を探しに行きます。Macは同条件で-63dBm以上を要求するため、iPhoneよりさらに粘る計算です。

接続先の初期選択では、既知ネットワーク(接続履歴)、セキュリティ種別、バンド(5GHz/6GHz優遇)、RSSIの順で評価されます。また11k/v/rにフル対応しており、Neighbor ReportやBTMに従順です。RSSIだけでなくビーコンロスや再送率といった品質指標もトリガーに使われるため、「RSSIは良好なのに通信が壊れている」状況からも逃げられる設計です。


Android — フレームワーク共通部+ベンダー差


AOSPのネットワーク選択コードは公開されており、フレームワーク層にバンド別RSSI閾値とスコアリング(5GHz/6GHzへの加点)が実装されています。ローミングトリガーは概ね-70〜-75dBm帯ですが、実際のスキャンと選択の多くはチップベンダーのファームウェア(Qualcomm系、Broadcom/MediaTek系)に委譲されており、同じAndroidバージョンでも機種により挙動が異なります。11k/v/rはAndroid 9以降おおむね対応ですが、BTMへの従順度はベンダー実装次第で、iOSほどの一貫性はありません。設計上は「iOS準拠でおおむね動くが、主要機種での検証は必須」という扱いが現実的です。


Windows — NICドライバへの委譲


WindowsはBSSID選択をほぼNICドライバに委ねています。Intel Wi-Fiではドライバ詳細設定に「ローミングの積極性」(5段階)と優先バンドが露出しており、既定の中間設定はかなり粘る傾向が知られています。管理された企業環境では、ドライバ設定のポリシー配布によるチューニングが定番の対処です。


Linux — wpa_supplicantという本丸


デスクトップ・サーバー・産業機器のLinuxでは、選択とローミングの実務を担うのはwpa_supplicantというユーザー空間デーモンです。構造は3層に分かれます。

NetworkManager等(ポリシー層: どのSSIDにつなぐか)
     ↓
wpa_supplicant(選択層: どのBSSIDか、いつローミングするか)
     ↓
カーネルmac80211+ドライバ、ファームウェア(実行層)

wpa_supplicantのBSS選択は、スキャン結果を推定スループット(RSSIから推定したSNRと、能力情報から達成可能なPHYレートを算出)でソートする設計で、単純なRSSI比較より一歩進んでいます。5GHz優遇はこの構造から自然に生まれます(同RSSIなら広帯域の方が推定スループットが高い)。

しかし決定的な注意点があります。接続後のバックグラウンドスキャン(bgscan)は、明示設定がなければ動かない構成が多いのです。bgscanモジュールはビルド時にCONFIG_BGSCAN_SIMPLEを有効化し、さらに設定ファイルで

bgscan="simple:30:-70:3600"

(RSSI -70dBm未満なら30秒間隔、以上なら3600秒間隔でスキャン)のように指定して初めて機能します。これがないLinux端末は、リンクが切断されるまでローミングしません。「デスクトップLinuxで部屋を移動するとWi-Fiが遅いまま」の主因はここにあります。逆に言えば、管理された端末群(POS、キオスク、産業ハンディ)なら、この1行の配布でiOS類似のプロファイルに矯正できます。

もう一つの分岐がチップの型です。Intel iwlwifiやAtheros ath9k/10kのようなソフトMACチップはホスト側(mac80211)が制御するためwpa_supplicantの設定が素直に効きますが、Broadcom brcmfmac等のフルMACチップはローミング判断の一部がファームウェア内にあり、ホストからの制御が部分的にしか効きません。


ChromeOS / BSD / IoT


  • ChromeOS: shill(独自マネージャ)+wpa_supplicant構成で、Googleがbgscanを既定有効にチューニング済み。素のLinuxと違い、iOS並みに積極的に動きます

  • FreeBSD/OpenBSD: 構造はLinux同型ですが対応チップとローミング機構が限られ、実務では「粘着前提」の扱いが安全です

  • ESP32等のIoT機器: 接続時にスキャン結果の最強RSSI等を選ぶだけで、接続後の自発ローミングをしない実装が基本。プリンタ、決済端末、センサー類も同傾向で、同一SSID多AP設計における最弱リンクです


一覧表

クライアント層

選択主体

ローミング既定

設計上の扱い

iPhone/iPad

OS統合

-70dBm、送信中+8dB(公式)

11k/v/r前提の設計が通る

Mac

OS統合

-75dBm、+12dB(公式)

iPhoneよりセル重複を厚めに

Android

FW+フレームワーク

概ね積極的、機種差あり

主要機種で検証

Windows

NICドライバ

中庸〜粘着

ドライバ設定の配布

ChromeOS

shill+wpa_s(調整済)

積極的

iOS並み

Linux

wpa_supplicant

bgscan未設定なら切断まで粘着

conf配布で矯正可能

BSD

net80211等

粘着

IoT扱い

ESP32/IoT

SDK最小実装

ローミングなし

全域を単一APでカバー

4. 技術解説 — なぜこう分かれるのか


各実装のロジックは、本質的に同じ形のスコア関数に還元できます。

Score(BSSID) = f(RSSI) + バンド加点 + 帯域幅加点 + 履歴加点 − 負荷減点 − ヒステリシス

  • f(RSSI) は飽和型です。-50dBmと-40dBmの差は実用上無意味なので、上側で頭打ちにします

  • バンド加点(5/6GHz優遇)の物理的根拠は「2.4GHzは同RSSIでも混雑と干渉でSINRが悪い」という統計的事実の先取りです

  • ヒステリシス(8〜12dB)が最重要パラメータで、前述のピンポン防止そのものです


もう一点、見落とされがちな事実として、RSSIの絶対値は規格上未校正です。同じ電波でもチップにより数dB違い、測定対象(ビーコンのみか、データフレーム込みか)や平均化の時定数も実装差があります。各社が「-70dBmトリガー」と言っても、物理的に同じ点を指していない。サーベイで測定器の値と端末の自己申告RSSIがずれるのは正常であり、設計は校正された測定器基準、検証は対象実機基準と分けるべき理由がここにあります。当店で取り扱っているOscium Wi-Spyのような校正済み測定器が設計フェーズで基準になるのは、この「端末ごとの物差しのばらつき」から独立した判断軸が要るためです。


5. 同一SSID 複数AP 接続時の実務への落とし込み


本章の内容は、設計要件として次のように翻訳できます。

  1. セルエッジ設計の定番「-67dBm」の根拠: iPhoneのトリガー(-70dBm)より手前で、次のAPが十分強く見える状態を作るため。Apple公式値から逆算された数字です

  2. 最弱クライアントが基準になる: ローミングしないIoT機器が稼働する範囲は、単一APで全域-65dBm以上を確保する設計に格上げが必要

  3. ヒアリング項目に「Linux系端末のbgscan設定有無」を追加: 現地で原因不明の粘着を追う時間を大幅に節約できます

  4. 11k/v/rの有効化は正攻法: 特にiOS比率の高い環境では効果が大きい。ただしBTMは勧告であり、切り札はチャンネル設計(第2章・第3章で詳述)です

次章では、端末が選んだ先で待っている物理 — 同一チャンネルAP間のCSMA/CAとエアタイムの奪い合い — を掘り下げます。


出典・参考資料

  1. Apple「Wi-Fi roaming support in Apple devices」(Apple Platform Deployment) — iOS/iPadOS/macOSのローミングトリガーと候補要求の公式値 https://support.apple.com/guide/deployment/dep98f116c0f/web

  2. Cisco「iPhone 6 Roaming Behavior and Optimization」 — iOSローミング実測検証の古典的資料 https://www.cisco.com/c/en/us/td/docs/wireless/controller/technotes/8-0/iPhone_roam/b_iPhone-roaming.html

  3. wpa_supplicant ソースコード(bgscan_simple.c ほか)および設定ドキュメント — bgscan書式、BSS選択ロジック https://w1.fi/wpa_supplicant/

  4. Silicon Labs「Roaming And Background Scan」 — CONFIG_BGSCAN_SIMPLEビルド要件と設定例 https://docs.silabs.com/wifi91xrcp/latest/wifi91xrcp-developers-guide-wifi-features/roaming-and-background-scan

  5. IEEE 802.11-2016 — ESS/BSS/BSSID、Association手続き、11k/v/rの規格定義

※ Android/Windows/BSD/IoTの記述は公開ソース・ベンダー文書・実測知見に基づく一般傾向であり、個別機種の挙動を保証するものではありません。


【シリーズ】


コメント

bottom of page