TDLSのはなし
今回は小ネタです。「Wi-Fiの盲腸」のひとつ、IEEE802.11z TDLS(Tunneled Direct Link Setup)の話です。
はじめに
802.11gのWi-Fiアクセスポイントが普及しだした2000年代の始め頃、「カタログスペックで54Mbpsを歌っているのに、実測では半分も出ない！」という批判がありました。当時のWi-Fiの実装がまだハード・ソフトともに未熟だったこともありますが、そもそも論として「STA間の通信は必ずAPを経由する」「同じ周波数で同時に通信できるのは１ペアに限られる」というIEEE802.11無線LANの原理上、STA-AP-STAの通信ではビットレートの半分以上のスループットが出るはずがないという事情もありました。
(図) 通常のインフラストラクチャモードでのSTA間の通信は、必ずAPを経由する２度手間になる
TDLSは「そもそもSTA同士が1:1ペアで通信するなら、いちいちAPを経由しない方が効率が良くなるんじゃないか？」と考えられたWi-Fiの拡張仕様で、IEEE802.11タスクグループZ(TGz)として2007年9月に発足しました。これが誰の(どの企業の)発案だったのかはわかりませんが、2008年10月15日付けの議事録では、TGzのメンバーは
となっているので、言い出しっぺの顔ぶれはわかります。また、検索してみるとLG Electronics Incが2008年10月付けでUS Patent 8665844B2として特許出願しています。言い出しっぺの経緯はどうあれ、TDLSの正式仕様はIEEE802.11z-2010として発表され、IEEE802.11-2012以後では標準仕様のなかに取り込まれました。
TDLSの原理
TDLSの原理は割と単純で、あるSTA(イニシエーター)が通信したい相手のSTA(レスポンダー)に「今から直接通信しようぜ！」という要求(TDLS Setup Request)を(AP経由で)送りつけ、それが了承(TDLS Setup Response、これもAP経由)されたらAPの支配下を一時的に離れてSTA同士が直接通信し、用事が済んだら「じゃあ元の通信に戻るから(TDLS Teardown)」を送ってAP支配下に戻るというものです。ただしSetup手順以前に、通信相手がTDLSに応じる能力があるかどうか問い合わせるための「TDLS Discovery」という手順もあります。
(図) TDLS Discoveryの原理図、Discovery Replyが直接送信されていることに注意
(図) TDLS Link Setupの原理図
DLSにはAPと同じチャンネルで通信するOn-Channelモードと、APとは異なるチャンネルで通信するOff-Channelモード(オプション)があります。Off-Channelの場合、2台のSTAはお互いにサポートしているチャンネル情報を交換し、「Channel Switch Request」を発行する側のSTAがチャンネルを選択(※註)して切り替えを要求、それが受理されれば「Channel Switch Response」が返ってチャンネル切り替えが成立する、と定義されています。これらのTDLS手順はTDLS Action Frame(Action Frame Code=12)として実装されます。
(※註) IEEE802.11-2020 11.20.6.1 "The target channel is specified by the STA that initiates a channel switch, from the set of operating classes supported by both TDLS peer STAs."
具体的に何をどうやってチャンネル選択すべきかについて、TDLS仕様ではあまり詳しく延べられていません。DFSチャンネルは回避すべきこと、20/40MHz APでのセカンダリチャンネルは避けるべきこと、40MHz帯を使うためにはCCA/NAV手順を踏むべきこと、などは定められています。
TDLSが制定された2007～2010年頃は5GHzの無線LANも普及しだして、2.4GHzと5GHzが別々の回路になっていて同時動作も可能な「Concurrent Dual-Band」な無線チップも出てきた頃です。Off-Channelは「APが使うのはどちらか片方のバンドだけなんだから、TDSLリンクを使えばコンカレント機能を有効に活用できる」という目論見があったのかも知れません。
TDLSはセキュリティにも対応しています。同じAPにつながっていたよしみでマスターキー(PMK)は共有しているはずなので、TDLSリンク専用の通信鍵TPK(TDLS Peer Key)を交換するTPK Handshake手順(IEEE802.11-2020 12.7.8)というのが定められています。
TDLSはSTAだけでなくAP側にもサポートが必要で、ビーコンに含まれるExtended Capabilities IEに示されます。特にBit37(+4バイト目Bit5)の"TDLS Support"が重要なはずですが、個人的にはこれが1になったAPは見たことがありません。
(図) WiresharkでキャプチャしたビーコンのExtended Capabilities とTDLS Supportビット(拡大表示)
TDLSの動作テスト
hostapd/wpa_supplicantにはいちおうTDLS機能が実装されています。ただし実装は限定的で、無線モジュール/ドライバとの組み合わせで動いたり動かなかったりします。
まず、ドライバにTDLSがサポートされていなければなりません。wpa_cli/hostapd_cliで"driver_flags"を実行して"TDLS_SUPPORT"が出ることを確認してください。あるいはiw phy <phy name> info"に"Device supports T-DLS"が出ることでもいいですが、iw infoの表示は量が多すぎて見にくいです。
TDLSのコマンド自体は単純で、
となります。
(※註) hostapdにはビルドオプションにもTDLS設定がありません。hostapd.confにはTDLSを禁止するtdls_prohibit=1設定がありデフォルトでは0です。これを1にするとExtended Capabilities IEの+4バイト目Bit6"TDLS Prohibited"が1になります。
(※註) wpa_supplicantはビルドオプションでCONFIG_TDLS=yにする必要がありますが、デフォルトのdefconfigではyになっています。しかしSTAから送信するProbe-ReqやAssociation-ReqのTDLS Supportedビットは0のままです。また、tdls_discover, tdls_setupコマンドともAPビーコンの"TDLS Supported"ビットは見ていないようです。
実装はかなり中途半端で、tdls_discoverやtdls_setupはAPに接続していないMACアドレスに対して実行してもOKになります。なので成功したかどうかはtdls_link_statusを見てみなければわかりません。
モジュール・ドライバとの「相性」も激しく、ドライバがTDLS_SUPPORTを宣言していても、TDLS Setup Requestを受け付けないこともあります。OPENでは動いてもWPA2では動かないこともあります。動くけれどもtdls_teardown後にAP-STAの通信が戻らないこともあります。
試した範囲では、hostap-2.11を使い、ath9kをAPに、STAのイニシエータにBCM2835(Raspberry Pi)、STAのレスポンダにath9kを使った場合に一応動作はしました。何故か逆の組み合わせ(BCM2835をイニシエータにした場合)は動きませんでした。
TDLSが動いた場合のiperf3によるスループットは以下のようになりました。
AP経由の場合にくらべると2.5～4倍になっており、このテスト条件では「APを経由しない方が効率が良くなる」というTDLSの目的は効果を発揮していることがわかります。
TDLSの現状
冒頭で述べたように、TDLSは2022年現在では実質的に誰も使っていない盲腸機能になっています。何故そうなったのか理由は幾つか考えられますが、だいたい次のようなところだと思います。
(1) 実装サポートが遅れた
Wi-Fi接続の事実上リファレンスとなっているオープンソースのhostapd/wpa_supplicantのTDLSサポートは、上記のように現状最新の2.11でも心許ないものです。メジャーどころのOS...Windows, MacOS, iPhone, AndroidなどはそもそもTDLSをサポートしていません。AndroidについてはVer4.4 "Kitkat"のリリース(2013)時に「Wi-Fi TDLSサポート！」という報道(※註)がありましたが、それっきりです。これが原因なのか結果なのかは判然としませんが、「ちょっとTDLSを試してみよう」と思っても、すぐに使える実装環境が存在しないのが実情です。
(※註) https://developer.android.com/about/versions/kitkat
(2) 必ず動くとは限らない
「実装が中途半端で組み合わせによる相性がある」以外にも、動作原理上の問題もあります。APを中心とした無線ネットワークは「ハブ型」トポロジーを形成しますが、AP-STA1・AP-STA2間の通信状況が良好だったとしても、STA1-STA2間では事情が違うかも知れません。これは「隠れ端末問題(Hidden node problem)」という古典的な問題で、STA同士が物理的に近くないかぎり、TDLSモードにするとかえって遅くなる可能性がありました。
(図) 隠れ端末問題
TDLS仕様ではTDLS DiscoveryのRequestはAP経由・Responseは直接パスで返されるので、イニシエータがTDLS Discovery Responseの信号強度を見て「このSTAとTDLSすべきか否か」を判断する意図があったと思いますが、IEEE802.11仕様書を読んだ範囲では「RSSIを見てTDLS適用の是非を判断すべし」という既述は見当たりませんでした。
(3) 想定したユースケースが失われた
TDLSは「自宅に据えたメディアサーバーから、各部屋に置かれたメディアプレイヤーへのストリーミング」のような用途を想定して制定されましたが、その後インターネットの速度はどんどん速くなり、HuluやNetflixのようなストリーミングサービスが普及した結果、「インターネット上のコンテンツをWi-Fiルーター経由で各端末へストリーミングする」使い方のほうが一般的になりました。このような使い方では、もはやTDLSの想定した「APを経由しないSTA同士での直接通信による効率向上」は大した意味を持ちません。むしろ「インターネット常時接続」が当たり前になった今、ストリーミング中にAPとの接続が切れるTDLSは有害ですらあります。
(図) 家庭内メディアサーバーモデル(TDLSが活用できる)と、インターネットストリーミングモデル(TDLSは殆ど無意味)
(4) 競合技術が実用化された
TDLSの発想は「同じ周波数で同時に通信できるのは１ペアに限られる」故の制限を突破することでしたが、まずIEEE802.11ac(2013)でAPが複数のアンテナ指向性を操作して複数STAと同時に通信するMU-MIMOを実装して、その制限を破りました。続いてIEEE802.11ax(2021)では周波数サブバンドを分割して複数STAと同時通信するOFDMAが実装され、ますますTDLSの意味は無くなりました。
まとめ
結果的には「誰も使わない発明」になってしまったTDLSですが、無線チップとドライバには相当な影響がありました。例えばLinux無線レイヤーのnl80211.cのTDLSサポートはLinux 3.9 (2013/4/28)から始まって、少なくともLinux 4.5 (2016/3/14)まで丸3年間弄くり回しており、副作用でAP-STAモードの動作にまでバグが出たりしています。オンチップのファームウェアでもTDLSサポートのために少なからぬコードが入って容量を食われ、副作用でバグが出たりもしました。
これだけひっかき回して結局使われていないのだから、振り回されたエンジニアとしては文句のひとつも言いたくなります。Bluetooth 3.0+HS(2009年)のときも似たようなことを書いた記憶がありますが、標準規格の世界では往々にして「大山鳴動してネズミ一匹」があるもので、TDLSもネズミの一匹だったのでしょう。