Wi-Fiローミングのはなし
ローミング(Roaming)は特に業務用無線LANで重要で、かつ複雑で問題を起こすことの多い機能です。今回はこのローミングの話です。
BSSとESS、そしてローミング
個人用途(家庭内無線LAN)では大抵、インターネットにつながったWi-Fiアクセスポイント(AP)を１台置いてそこにスマートフォン・PC・TVなどの子機(STA)をぶら下げる使い方をします(※註１)。IEEE802.11の用語ではこれをBSS(Basic Service Set)と呼びます。アクセスポイントが１台しかない場合、ローミングは発生しません。
(図１) 個人用Wi-FiのBSSネットワーク
(※註１) 個人向けのプロバイダでは回線あたり１つのIP(v4)アドレスしか割り当てられないのが普通なので、IPアドレスの集約と再配分を行うNAT機能を統合した「Wi-Fiルーター」として使われる場合が多いです。昔はアップリンク回線(FTTH, CATV, DSL)とイーサネットを接続する「モデム」、IPアドレスの再配布を行う「ルーター」、イーサネットと無線LANを接続する「アクセスポイント」がそれぞれ別の箱になっていましたが、最近では１つの箱に３つの機能が実装されて単に「ルーター」と呼ばれることが多くなり、かえってわかりにくくなりました。
建物１軒や区画一帯を丸ごとWi-Fiでカバーする業務用Wi-Fiでは、建物の各所に複数のAPを置いて有線ネットワーク(バックボーン)で接続することが行われます。これをIEEE802.11用語ではESS(Extended Service Set)と呼びます。ESS環境では全てのAPが同じSSID・同じセキュリティ設定を共有しますが、干渉を避けるため隣接するAP同士間では意図的にチャンネルを違えます。
(図２) 業務用Wi-FiのESSネットワーク
STAはESS環境において、電波圏内にある複数のAPの中から「最も適切」と思えるAPを選択して接続します。しかしSTAが移動する場合はAPとの接続状況は逐次変化してゆくので「最も適切な接続条件のAP」が変化します。STAは電波状況を見ながらどこかの段階で現在接続しているAPを「見限って」、「より適切なAP」に接続し直すことになります。これが広義のローミング動作です。
(図３) ローミングの原理
ローミングの動作には大きく３つのポイントがあり、
(1) 現状のAP接続を維持しながら、より良い接続のAP候補を検索する。
(2) 接続候補APの推定条件と現状のAP接続条件を比較し、一定の閾値を越えればローミングを決断し、
(3) なるべく少ないオーバーヘッドで、現接続APからの切断・新候補への接続を行う
ことになります。以下、この３つのポイントついてhostapd/wpa_supplicantを例に出しながら解説してゆきます。
ローミングの問題(1) AP候補の検索
前述のようにESS環境では通常、隣接するAPは異なるチャンネルで動作しています。なので、現在のAP接続を維持したままでは他のチャンネルを検索できません。他のチャンネルを検索するためには、現在のAP接続を一時保留し、他のチャンネルを検索したあと保留を解除する必要があります。この動作をバックグラウンド・スキャン、短縮してバックスキャン(backscan)と呼びます。
バックスキャン中は現APとの接続が保留されて通信が止まります。どのくらいの時間止まるかは「スキャンするチャンネルの数」×「１チャンネルあたりに送信するProbe-Requestの数とProbe-Replyの待ち時間」ですが、短くても数秒はかかります。なのでバックスキャンを頻発すると現接続APとの通信性能に悪影響が出ますが、バックスキャン間隔が長すぎると、現APとの接続が悪化してもそれを検出して「より良いAP」に切り替えるのが遅くなり過ぎてしまいます。なのでバックスキャン間隔の設定はAPの密度・ローミングの頻度・通信量などを考慮して行う必要があり、その設定は多分に経験則的です。
wpa_supplicantの場合、wpa_supplicant.confのbgscan="simple:30:-70:180"のような指定でバックスキャン条件を指定します。"simple"はアルゴリズムの指定で、現APとの接続RSSIを高低２段に分けてバックスキャン間隔を切り替えることを意味します。"30:-70"は「RSSIが-70dBm未満になったら30秒間隔」、":180"は「それ以外の場合は180秒間隔」を意味します。なおbgscan=の指定がなかった場合は、現APとの接続が(Beacon Lossで)切れるまで接続を維持する動作(通称"Sticky Link")になります。
Wi-Fiには2.4GHzで13個・5GHzで20～30個ほどのチャンネル(国地域によって異なります)があり、この全てをスキャンすると一回のバックスキャンあたりにかかる時間が長くなります。しかし2.4GHzでは(OFDMのバンド重複を避けるため)通常1・6・11の３チャンネルしか使いませんし、5GHz帯でもESS内で全てのチャンネルを使うわけではありません。スキャンするチャンネル数を制限する「チャンネルマスク」によってバックスキャンのオーバーヘッドを低減することができます。wpa_supplicantの場合、wpa_supplicant.confのscan_freq=の後に周波数(4桁のMHz表記)を羅列することでチャンネルマスクを設定できます。
APアシストローミングの数々
STAが自発的に行うバックスキャン以外に、APからローミング先候補を教えてもらう「AP Assisted Roaming」という手段もあります。しかし困ったことにこれには複数の規格仕様があってかなり混沌としており、いまひとつ有効に活用されていないのが実情です。
IEEE802.11k Radio Resource Management (RRM Neighbor Report)
STAから現接続APにAction Frameを送って、「APの知っている近隣APの一覧」を教えてもらうことができます。一覧情報にはBSSID、チャンネル、キャパビリティなどが含まれますが、他APとSTA間の電波状況はわからないのでRSSI情報は乗りません。しかしチャンネルとBSSIDがわかれば名指し(ユニキャスト)でProbe-Requestを問い合わせることができ、全チャンネルに対してProbe-Requestをブロードキャストして回るより遥かに速く接続先候補のRSSIを得ることができます。
wpa_supplicantではwpa_cliの"neighbor_rep_req"コマンドとして実装されていますが、取得したAP一覧はただ表示されるだけでスキャン結果(scan_results)には格納されず、ローミングの参考情報に使う機能は無いようです。
hostapdには近隣APの自動スキャン機能はなく、hostapd_cliの"set_neighbor"コマンドを使って人力でで近隣リストを追加しなければなりません。３番めの引数"nr="には(EIDとLengthを除いた)IEEE802.11 Neighbor Report IEを16進で直接指定します。最低11バイト/22文字が必要で、こんな風になります。
set_neighbor 84253F123457 ssid="silexAP" nr=84253F12345700000007510104
6バイトがBSSID、
4バイトがCapabilities(7=Reachable + Security)
1バイトがOperationg Class(0x51=81=Global Class 2.4GHz)
1バイトがチャンネル(1=2412MHz)
1バイトがPHY Type(4=OFDM PHY)
詳しくはIEEE802.11-2020 9.4.2.36を参照してください。いずれにせよ、現状のwpa_supplicant/hostapdのRRM機能は「動作を試すことができる」というレベルの実装で、ローミングの高速化に役立つものではありません。
IEEE802.11v Wireless Network Management (WNM BSS Transition)
これもAction Frameの枠組みを使っていますが、STAからの要求(Query)に答えてAPからSTAに接続候補APの一覧(Candidate List)を送り、「このAPに接続した方が良いと思うよ」と推薦することができます。
wpa_supplicant/hostapdではビルド時のCONFIG_WNM=yで11vを有効にできることになっていますが、"This is experimental and not complete implementation"と書かれています。試した範囲では、wpa_cliから"wnm_bss_query 0"コマンドを発行するとBSS Transition Management Query,Transition Management Request,Transition Management Replyが1.5往復することは確認できましたが、APから渡されるBSS Transision Candidate Listは空になっており、STAはそれに対してリジェクト(コード1:Unspecified reason)を返していました。
hostapdのソースを見るとCandidate Listを設定するコードが見当たらず、付加情報を示すreq_modeには常に0が設定されています。そしてwpa_supplicantでは受信したCandidate Listが空の場合は"WNM: BSS Transition Management Request did not include candidates"としてリジェクトとしているので、現状では動くはずのないものになっています。
IEEE802.11u Interworking
Interworkingというのは、アップリンクの有無やセキュリティ設定の詳細などBSSの詳細情報をAPからSTAに知らせる仕組みです。Wi-Fiが普及してAPが乱立するようになったので、適切なSSID選択のためにネットワークの素性を知らせる仕組みが作られたもので、ローミング用ではありませんがついでなので簡単に解説しておきます。
IEEE802.11uではAPのビーコンにInterworking(type=107)とAdvertisement Protocol(type=108)という拡張IEが乗り、そこから更にAction Frameを用いて詳細情報をやり取りすることができます。Action FrameによるInterworking情報の交換プロトコルはAccess Network Query Protocol(ANQP)という名前で呼ばれ(IEEE802.11-2020 9.4.5)、ANQPを用いたAP-STA間の情報交換プロトコルはGeneric Advertisement Service (GAS)と呼ばれます(IEEE802.11-2020 11.22.3)。
Interworking IEは8bitの"Access Network Options"フィールドを持ち、オプションで16bitの"Venue Info"と6byteの"HESSID"を含み得ます。オプションフィールドの有無はフラグでは示されず、Lengthだけで判断します(1=オプションなし,3=Venue Info,7=HESSID,9=Venue Info+HESSID)。Access Network Optionsは下のような情報を含んでいます。
Access Network Type(4bit) : 私用・公用・共用などの種別
Internet(1bit) : アップリンクの有無
ASRA(1bit) : 接続に必要な追加手順の有無
ESR(1bit) : 緊急接続能力の有無
UESA(1bit) : 認証なし緊急接続能力の有無
Venue Infoは更に詳細な「個人用/業務用/研究用/教育用」だとか「オフィス/レストラン/学校/交通機関」などの用途や設置場所を示す情報です。HESSIDはSSIDを補填する情報で、同名SSIDのAPが隣接していてもHESSIDが異なれば「別のBSS/ESS」であると認識されます(Homogeneous ESSと呼ばれます)。
Advertisement Protocol IEはもっと複雑で、それ自身が独自のタグ体系を持ち、種々雑多としか言いようのない情報を含みます。
wpa_supplicant/hostapdではビルド時のCONFIG_INTERWORKING=yで有効にすることができ、hostapd.confに"interworking=1"を設定することでビーコンにInterworking IEとAdvertisement Protocol IEが乗るようになります。ANQPで応答する「種々雑多な情報」はhostapd.confの"IEEE 802.11u-2011"の下にずらずら並んでいるアトリビュートで設定します。
STA側ではwpa_supplicant.confのcred{}ブロックにAP選択の基準属性を書き、wpa_cliのinterworking_selectコマンドを実行するとIEEE802.11uのANQPスキャンが実行され、条件に一致したAPに接続...するかも知れません。Interworkingのアトリビュートには矢鱈滅鱈沢山ありますが、現状のwpa_supplicant 2.11には暗黙の必須項目があり、少なくとも
・RSNセキュリティであること
・EAP認証であること
・hostapd側のANQPにnai_realm名がEAP属性つきで設定されていること
・wpa_supplicant側のcredにrealm名とEAP属性またはroaming_consortiumが設定されていること
が必要です。これらを満たしていないと"No network with mathcing credentials found"というエラーになりますが、具体的に何がどう足りないのかは表示してくれません。私が確認できた組み合わせは
AP側：WPA2-Enterpriseのhostapd.confに以下を追加
interworking=1
nai_realm=0,silexamerica.com,25[4:7]
STA側:WPA2-Enterpriseのwpa_supplicant.confに以下を追加
cred={
realm="silexamerica.com"
eap=PEAP
username=<EAP-PEAPユーザー名>
password=<EAP-PEAPパスワード>
}
でした。hostapd.confの25[4:7]という謎めいた項目はEAP属性で、PEAP(25)+MSCHAPv2(4)+username/password(7)を意味しています(不親切ですね)。
現状のinterworking_selectスキャンは開始～完了まで(見えているAPの数にもよりますが)1分ほどかかり、到底「高速ローミング」とは言えません。そもそもIEEE802.11uの目的が高速ローミングではないにせよ、なんだか取って付けたような機能だと感じます。
Cisco CCX Assisted Roaming
Cisco社の独自拡張規格です。現在ではCisco社もIEEE802.11kに移行しておりCCXはレガシー扱いで、wpa_supplicant/hostapdにも実装されていないので詳細は割愛します。
ローミングの問題(2) 接続条件の把握とローミングの決断
さて２番めの問題「より良い条件の判断」は、現状のwpa_supplicantではハードコーディングされています(wpa_supplicant/events.c)。つまり設定ファイル(wpa_supplicant.conf)などで調整できるパラメータはありません。ソースを読むとローミングの判断条件は
・推定スループットの大小
・5GHz→2.4GHzよりも2.4GHz→5GHzを優先
・推定S/N比の大小
・RSSIの大小(非線形比較)
などを並べてあり、境界値として「推定スループット+5000」とか「RSSI値+10以上」とかの数字がハードコーディングで埋め込まれています。このコーディングもおそらく経験則的なものでしょう。
ローミングの要求はアプリケーション毎に違うので、wpa_supplicant標準のアルゴリズムでは「もっと頻繁に切り替わって欲しい」とか「もっとギリギリまで粘って欲しい」という要望が出るかも知れませんが、しかし現状のwpa_supplicant(2.11)ではローミング判断条件のカスタマイズにはソースコードを直接弄る必要があるので、気軽に調整できるものではありません。
ローミングの問題(3) 切断～接続切り替えの高速化
いわゆる「高速ローミングプロトコル」の殆どがこのカテゴリーに入ります。ローミングプロトコルに踏み込む前に、まずWi-FiのSTA-AP接続手順についておさらいする必要があります。
セキュリティ無し、あるいはWEPの接続手順
この場合「鍵交換」という手順はありません。
Probe-Request, Probe-Reply交換による接続先APの検出
Disassociation-Request, Disassociation-Replyによる現APとの切断
Authentication-Request, Authentication-Reply交換(Open)
Association-Request, Association-Reply交換
(合計4往復)
(図４) OPEN/WEP接続手順
WPA/WPA2-PSKの接続手順
PSK方式では、全てのノードにPMK(マスターキー)が事前設定されています。PMKは128bitのPSKとして直接設定されるか、任意長文字列のパスフレーズから生成されます。実際に通信の暗号化に使う鍵(PTK)はPMKに疑似乱数(Nonce)を加えてAP-STAの接続ごとに異なるPTKが動的生成され、そのために4-Way Key Handshake(2往復)が行われます。
Probe-Request, Probe-Reply交換による接続先APの検出
Disassociation-Request, Disassociation-Replyによる現APとの切断
Authentication-Request, Authentication-Reply交換(Open)
Association-Request, Association-Reply交換
4-Way Key HandshakeによるMIC認証、PTK/GTK交換(2往復)
(合計6往復)
(図５) WPA2-PSK接続手順
WPA3-SAEの接続手順
SAE方式では、Authentication手順においてSAE-ECDH鍵共有方式によってPMKが交換されます。ノードに設定されるパスワードはSAE-ECDHの認証に使われるだけで、WEPやPSKと違ってPMKとは直接の関係を持ちません。SAEでもPMKからPTKを動的生成するために4-Way Key Handshakeが行われます。
Probe-Request, Probe-Reply交換による接続先APの検出
Disassociation-Request, Disassociation-Replyによる現APとの切断
Authentication-Request, Authentication-Reply交換(SAEによるPMK鍵交換, 2往復)
Association-Request, Association-Reply交換
4-Way Key HandshakeによるMIC認証、PTK/GTK交換(2往復)
(合計7往復)
(図６) WPA3-SAE接続手順
WPA/WPA2/WPA3-EAPの接続手順
EAP方式ではAssociationの直後にEAPoL(EAP over LAN)パケットが複数回往復して認証と鍵交換を行います。EAPoLの上は大抵TLS系で、EAP-TLS, EAP-TTLS, PEAP, EAP-FASTなど複数のなる規格があり、中身はそれぞれ微妙に異なります。EAP方式の場合もPMKからPTKを動的生成するために4-Way Key Handshakeが行われます。
Probe-Request, Probe-Reply交換による接続先APの検出
Disassociation-Request, Disassociation-Replyによる現APとの切断
Authentication-Request, Authentication-Reply交換(Open)
Association-Request, Association-Reply交換
EAPoLによる認証とPMK鍵交換(n往復)
4-Way Key HandshakeによるMIC認証、PTK/GTK交換(2往復)
(合計6+n往復)
(図7) EAP接続手順
さて、いわゆる「高速ローミングプロトコル」の目的は大きく分けると２つあって、
(A) PMK交換(主にEAP手順)の簡略化、あるいは省略
(B) 4-Way Key Handshakeの簡略化、あるいは省略
になります。
PMKSA Caching (type A)
最も単純かつ基本的な高速ローミング方式で、STA-AP間の最初の接続時には通常の接続手順を踏みますが、再接続時のPMK交換(EAP手順)を省略します。STAはAPと交換したPMKをキャッシュして覚えておき、次にそのAPと再接続するときRe-Association RequestにPMKのハッシュ値を記して(※註２)「以前に貴方と接続したときこのPMKを交換しましたが、また使いますか？」と問い合わせます。AP側がそれを拒否した場合は通常の接続手順になりますが、AP側が受け入れた場合はEAP手順を飛ばして、互いに持っているPMKの値を元にした4-Way Key Handshakeを行います。
(※註２) 具体的には、RSN IEの「PMKID List」フィールドに格納されます。
(図９) Oppotunistic Key Caching
wpa_supplicant.conf, hostapd.confともデフォルトではOFFで、"okc=1"を設定することにより一応有効にはなりますが、OKCが動作するにはEAPサーバの側でも「STA 1台に対しESS内の全APが同じPMKを使う」設定をする必要があります。
IEEE802.11r Fast BSS Transition (FT) (type B)
2回目以後の再接続で、PMK交換(EAP手順)だけでなく4-Way Key Handshakeも省略する(※註３)もので、今日のWi-Fiでは標準の高速ローミングプロトコル仕様とされています。PMK→PTKの算出をPMK-R0(AP毎) / PMK-R1(STA毎)という2つの中間鍵を用いる方式に変え、4-Way Key HandshakeではなくAuthentication手順とRe-Association手順の2往復にAP/STAそれぞれのID(※註４)とNonce値を含めることで接続手順と認証・鍵交換を同時に行います。
(※註３) 802.11rでも最初の接続では通常のWi-Fi接続に近い手順を踏みますが、鍵算出方式の変更に応じて細部が異なります。"FT initial mobility domain association"と呼びます。
(※註４) 802.11rの仕様ではKey Handle ID(KH-ID)と呼び、R0/R1ともにAPを特定するR0KH-HD(=nas_identifier文字列)/R1KH-ID(=APのMACアドレス)、STAを特定するS0KH-ID/S1HD-ID(=STAのMACアドレス=SPA:Supplicant Address)がペアで使われて鍵が算出されます。
(図１０) IEEE802.11r Fast BSS Transition
wpa_supplicant.conf, hostapd.confともビルド時にCONFIG_IEEE80211R=yとして、key_mgmt=に"WPA-PSK"や"WPA-EAP" "SAE"に代えて"FT-PSK"や"FT-EAP" "FT-SAE"を指定することで802.11rが有効になります。hostapd.confにはAP識別子である"nas_identifier=<文字列>"も設定する必要があります。
なお、IEEE802.11r仕様ではAuthentication交換を「現接続APから切断したあと、ローミング先APに対して通信する」方式(図に示したもの)を"Over-the-air"方式、現APに接続したまま3-addressフォーマットのブリッジで有線バックボーン回線を経由して行う方式を"Over-the-DS"方式と呼んでいますが、現状wpa_supplicantはOver-the-air方式にしか対応していません(wpa_cliの"FT_DS <BSSID>"コマンドで人力発動することはできます)。
IEEE802.11i Pre-Authentication (type A)
EAP手順を現APに接続したまま、3-addressフォーマットのブリッジで有線バックボーン回線を経由して行うことで先回しに認証とPMK交換を行うもので、IEEE802.11i時代からある標準仕様です。ローミングに要する通信量と時間は変わりませんが、EAP手順を「現APに接続したまま」行うので、ローミング時間に占める切断時間を短縮する効果があります。
(図１１) Pre-Authentication
hostapdではビルド時にCONFIG_RSN_PREAUTH=yを設定し、hostapd.confにrsn_preauth=1, rsn_preauth_interfaces=にブリッジi/f名を書くことで有効になります。Pre-Authenticationを有効にしたAPは、ビーコンのRSN IEのCapability IEフィールドのbit0 Preauthentication=1になります。
wpa_supplicant.confの方にはPre-Authentication使用/不使用の明示的な設定がなく、スキャン(バックスキャン)結果のPreauthentication bitを見て自動的にPre-Authenticationを発動します。wpa_cliを使って"preauth <BSSID>"コマンドを発行する人力操作でPre-Authenticationを発動させることもできます。
IEEE802.11ai FILS (Fast Initial Link Setup) (type B)
FILSは2016年にIEEE802.11aiとして制定されたWi-Fiの拡張仕様で、本来の目的はその名前通り「APの検索・応答・接続手続きの高速化」です。FILS仕様はショートビーコン(FILS Discovery Frame)やDHCPトンネリング(FILS Container frame)など様々な道具立てからなっており、高速ローミング(再接続時の4-Way handshake省略)はその一部に過ぎませんが、高速ローミング方式の一種には違いないのでここに含めました。
FILSの動作原理は802.11rと似ていて、初回接続時にはフルセットの認証手続きが必要ですが、二回目にはAuthentiation FrameにA-Nonce, S-Nonceを含めて交換します。ただし802.11rがFast Transition IE(ID=55)を使うのに対しFILSは拡張IE(ID=255)を使い、PMKの算出方式も違うので「似ている」というだけで互換性は全くありません。
FILSを使うためにはhostapd,wpa_supplicantともビルド時にCONFIG_FILS=yに設定する必要があります。hostapd.conf,wpa_supplicant.confにkey_mgmt=WPA-EAPにかえて(※註５)FILS-SHA256ないしFILS-SHA384を指定することでFILSが有効になり、APビーコンのRSN IEのAKMフィールドには802.1X(00:0f:ac：01)とFILS-SHA256(00:0f:ac:0e)が併記されます。
(※註５) 現状のwpa_supplidant 2.11ではEAP+FILSのみサポートされおり、PSKやSAEとFILSを組み合わせて使うことはできないようです。設定はできますが、"reason=2 PREV_AUTH_NOT_VALID"エラーが出て接続できず延々リトライします。
Cisco CCKM(Cisco Centralized Key Management) (type B)
Cisco社の独自拡張「CCX」機能の１つで、802.11rの制定以前には業務用無線LANの高速ローミングプロトコルとして「事実上の標準」でした。802.11rの標準制定・普及以後は使われることは少なくなっています。動作原理は802.11rとOKCを合わせたようなもので、再接続手順に鍵交換手順を合わせるところは802.11rと似ていますが、PMK-R0/R1の分割を行わず、STA毎のPMKをESS内の全APで共有する(Master Session Key:MSKと呼ぶ)ところはOKCに似ています。中枢サーバによる鍵共有が必要なのでEAP方式のみ対応で、PSKやSAE方式には対応できないところが802.11rとの大きな違いです。
wpa_supplicant/hostapdのソースコードにはWPA_KEY_MGMT_CCKMなど痕跡のようなものがありますが、サポートはされていません。
メッシュとローミングの違い
メッシュネットワーク(IEEE802.11s)も「複数の通信局を用い」「無線接続状況に応じて伝達経路を変える」技術なので、ローミングと似ています。しかしローミング環境(ESS)では原則として隣接AP同士は異なるチャンネルで稼働するのに対し、メッシュでは全てのメッシュノードは同じチャンネル上で稼働し、あるノードが送信したパケットは電波到達範囲内に居る全てのノードによって受信されます。従ってメッシュにはバックスキャンも無ければ「切断・再接続」も鍵の再交換手順も存在せず、経路制御は「電波到達範囲内に居る全てのノード」が受信したパケットを「再送信することで先に伝えるか否か(フォワーディング)」の判断によって行われます。
(図１２) メッシュネットワークの場合
これだけ聞けばローミングよりメッシュのほうが効率が良くて合理的なように思えますが、メッシュは全てのノード部が同じチャンネルで稼働するため台数が増えるほど・広域になるほど・通信量が増えるほどネットワークの負荷が増します(ESSとローミングはむしろ、AP毎に担当区域を限定してチャンネルを違えることで負荷の局限化を行う技術でもあります)。また「バックスキャンが無い」といっても経路制御テーブルはネットワーク状態の変化に呼応して更新する必要があり、その方式(Distance Vector型とLink State型)や更新間隔・経路コスト(リンクメトリック)の計算方式によって効率や性能が変わり、「全ての問題を解決する夢の万能ルーティングプロトコル」は存在しないことは以前に「IEEE802.11sメッシュのはなし」で解説しました。
実用論としては、ESSはBSSの上位互換でありWi-Fiに接続できる機器ならばとりあえずESSにも接続できる(※註６)のに対して、メッシュへの接続はドライバやサプリカントに拡張実装が必要で、現状では限られた実装系しか対応していません(事実上Linuxのみ)。そして同じLinux同士であってもカーネル・サプリカント・ドライバ・チップセットの品種・バージョン・ビルド(CONFIG)・設定によって動作が微妙に違う問題もあって、実用業務システムにはほとんど使われていません。
(※註６) ただし「接続できる」というだけで、高速ローミングに対応するとは限りません。この辺も家庭用と業務用Wi-Fiに求められる製品品質の違いです。
まとめ
Wi-Fiローミングについてまとめると、
- 効率的なローミングのためにはバックスキャンの頻度と境界RSSI値、適切なチャンネルマスクの設定が必要になる。
- AP側からAP状況の通知・ローミング示唆を行うAP Assisted Roamingは複数の規格が混在し混沌としている。また、現状のwpa_supplicantでのサポートは中途半端で実用に耐えない。
- 高速ローミングプロコルは基本的にセキュリティ手順を高速化するもので、PMK交換(EAP手順)を高速化するものと、4-Way Key Handshakeを高速化するものがある。
- 前者にはPMKSA Caching, OKC, Pre-Authenticationがあり、後者にはIEEE802.11r, IEEE802.11ai, Cisco CCKMがある。これらにはIEEE標準とベンダ独自拡張が混在しており、使用するセキュリティ(PSK, SAE, EAP)との組み合わせによって使えたり使えなかったりする。
簡単にまとめると下の表のようになりますが、必ずしもOが多い方式＝より優れた方式というわけでもありません。例えばPMKSA Cachingは基本的に全ての高速ローミング方式の基底技術で、これを行わなければ基本的にローミングするたびフルスペックでのPMK交換が必要となります(但しWPA2-PSKは最初からPMKが共有されているので例外となります)。また、Pre-AuthenticationはIEEE802.11rと組み合わせることでEAP手順/PMK鍵交換をローミング前に済ませてキャッシュしておくことが可能になりますが、OKCとCCKMはEAPサーバ側で最初の接続時認証時にSTA毎のPMKを全APで共有するので、Pre-Authenticationと組み合わせる意味はありません。こういう組み合わせ条件のややこしさもローミングを難解なものにしています。
| 方式 | IEEE標準 | PMK交換高速化 | 4-Way高速化 | PSK | SAE | EAP | 註 |
|---|---|---|---|---|---|---|---|
| PMKSA Caching | O | O | X | X | O | O | 同一APへの再接続時のみ有効 |
| OKC | X | O | X | X | X | O | PMKSA Cachingの変形・応用 ESS内の他APへの再接続時にも有効 |
| Pre-Authentication | O | O | X | X | X | O | ESS内のAPがブリッジ接続している必要あり |
| IEEE802.11r (FT) | O | O | O | O | O | O | Over-the-airとOver-the-FTの２方式がある |
| IEEE802.11ai (FILS) | O | X(*) | O | X | X | O | 本来は高速接続プロトコル (*)現状のwpa_supplicantでは未対応 |
| Cisco CCKM | X | O | O | X | X | O |
