Wireless・のおと
サイレックスの無線LAN 開発者が語る、無線技術についてや製品開発の秘話、技術者向け情報、新しく興味深い話題、サイレックスが提供するサービスや現状などの話題などを配信していきます。
WiFiの盲腸のはなし
前回はWiFiの接続手順...スキャン、アソシエート、認証、ローミングなどの話題を取り上げましたが、その中で「WiFiは段階的に発展してきたため、盲腸のような仕様が各所に残っている」と書きました。今回はその「盲腸」について軽く(全部網羅するとキリがありませんから)取り上げてみます。
今回は主に Management Frame の Capability Information Field に残っている仕様(Capability Bit)のなかから、今ではあまり使われなくなったものについて解説してゆきます。なお今回もあえて「WiFi」という用語を使っていますが、厳密に言えばIEEE802.11無線ネットワーク仕様書に記されている定義と、Wi-Fi Alliance がロゴ認証に求める仕様定義は異なります。
PCF(Point Coordination Function)
コンピュータネットワークには様々な接続形態(ツリー型、リング型など)がありますが、無線ネットワークは全てのノードが通信媒体を共有する「バス型」だと考えられます。バス型ネットワークでは２台以上のノードが同時に送信することはできないので、何らかの通信タイミング制御機構が必要になります。WiFi において、これは DCF(Distributed Coordination Function)と PCF という２方式が使用できることになっています。
DCF というのは各ノードが一定期間「誰も送信してないよね？僕が送信してもいいよね？」と聞き耳を立てる(キャリアセンス)こと、もし誰かが送信していればランダム時間の遅延後に再トライする(バックオフ)する方式で、実装・設定が簡単でノード数が少ないときは高速に動く反面、ノード数が増えると衝突が増えて効率が落ちる欠点を持ちます。
PCF はこれに対し、１台のノード(コーディネイター、通常は AP)が主導権を持って「○○さん送信してください。終わりましたか？では次は××さん送信してください」と送信タイミングを指示する方式で、有線ネットワークで「トークン方式」と呼ばれているものに似ています。PCF は実装の手間が増え、台数が少ない(衝突確率が低い)時にもオーバーヘッドがかかってピーク性能が出ない欠点がありますが、台数が増えても衝突確率を抑えることで極端な性能低下を避けられる利点があります。
PCF/DCF は WiFi 教科書の前半あたりによく出てくる話題ですが、現実にはほとんどの AP には DCF しか実装されていません。高価な業務用の AP には PCF が実装されている場合もありますが、そこに接続される STA (PC やスマートフォン)が PCF の仕様どおりに動作するかどうかは怪しいものです。しかし PCF の機能・考え方の一部は QoS(Quality of Service) 機構として IEEE802.11e/WMM(WiFi Multi Media) 仕様に取り込まれており、WiFi で帯域保証が必要な場合は PCF ではなく WMM を使うことが現在では一般的になっています。
CFP(Contention Free Period)
PCF 通信方式では使われるタイミングパラメータです。定義や文脈によっては Contention Free Parameter の略である場合もありますが、基本的には同じことを意味しています。PCF モードは単一のビットではなく、Capability Information の３ビット(QoS, CF-Pollable, CF-Poll Request)を組み合わせて動作モードが通知設定されますが、詳細については割愛します(IEEE802.11-2012 Section 8.4.1.4 を参照してください)。
Short Preamble
プリアンブル(Preamble) というのは送信データの手前に付けられる一定パターンの反復で、このパターンを用いて送受信器間のクロック同期などを行います。技術的な定義において「プリアンブル」は(通常)有意なデータを含まないのですが、便宜上の WiFi 用語としての「プリアンブル」は技術上の意味における「プリアンブル」にパケットヘッダ(PLCP ヘッダ)を含めたものを指す場合が多いです。
元祖 802.11 DSSS 仕様でのプリアンブルは PLCP ヘッダ部 1Mbps 変調の 192μ秒でしたが、801.11b では高速化オプションとして 2Mbps 変調 96μ秒のモードが追加されました。これを Short Preamble と呼ぶようになったので、元祖 802.11 互換 192μ秒のモードを Long Preamble と呼んで区別しています。
STA は自身が Short Preamble を処理できるか否かを Capability Bit にセットして AP に通知し、AP は管理下のネットワークで Short Preamble の使用を許可するか否かを Capability Bit にセットして周辺に通知します。
Short Preamble は 802.11g 以降で実装必須となったので、「Long Preamble を使わなければ互換性が保証できない」という事態はよほど古い仕様の 802.11b 専用機材、あるいはプレミアが付きそうな元祖 802.11 DSSS 専用の機材を使わないかぎり発生しません。また 802.11g の OFDM レートで通信する場合は Long/Short とは別仕様の ERP-OFDM Preamble (20μ秒)が使用される(※註)ため、現在では Long/Short Preamble の区別はあまり意味を持っていません。また 5GHz 帯にはそもそも 802.11/b 互換の必要がなく常に ERP-OFDM が使用され、Short/Long Preamble の概念はありません。
(※註)ただし例外もあり得ます。詳細については後述の DSSS-OFDM に関する記述を参照してください。
バーカー・プリアンブル・モード(Barker Preamble Mode)
802.11g 以降の 2.4GHz 帯において AP から通知される情報の１つで、AP 接続配下に Short Preamble をサポートしない STA があるか否かを示す情報です。Barker Preamble Mode=1 の場合は AP 接続配下に少なくとも１台、Short Preamble を解釈できないノードが居ることを示し、 Short Preamble の使用が禁止されます。0 の場合は許可されます(※註)。前述のように Long Preamble しか受信できない機材は現在ではきわめて稀なため、これが 1 になることは滅多にありません。
バーカー・プリアンブル・モードは Capability Bit を「はみ出して」しまった情報の１つで、拡張情報要素(IE:Information Element)の番号 42 番「ERP IE」のなかに示されます。また「バーカー・プリアンブル」という妙な名前は、元祖 802.11 DSSS および 802.11b CCK 変調が 11 チップのバーカー拡散符合系列(Barker Code Spreading) というアルゴリズムを使用していることに由来しています。802.11b 互換 1～11Mbps の通信では必ずバーカー符号が使われるわけで、「バーカー・プリアンブル・モード」という特殊な通信モードがあるわけではありません。いっそ「Short Preamble Enable」という名前のほうがわかりやすかったのでないかと思いますが、何でここだけわざわざ名指しでアルゴリズム名を冠しているのかは判りません。そもそも「AP 接続配下における Short Preamble の使用禁止/許可」という機能は Capability Bit の Short Preamble ビットと重複するのですが、何故 802.11g でわざわざ重複する機能を追加したのかもよくわかりません。
(※註)ただし Short Preamble の使用は「許可される」だけであって Long Preamble の使用が禁止になるわけではないので、802.11/b レートで常に Long Preamble を送信する実装(Forced Long Preamble)もあり得ます。ただしこの場合でも、Short Preamble の受信は可能でなければなりません。
Short Slot Time
802.11b と 802.11g 混在制御機能のひとつです。プリアンブルと紛らわしいのですが、Short/Long プリアンブルが元祖 802.11(DSSS) と 802.11b(CCK) 互換性のために定義されているのに対し、Short/Long Slot Time は 802.11/b と 802.11g(以降)互換性のための定義です。Slot Time というのは WiFi が動作する上で定義されている基底時間単位の１つで、例えば既出のキャリアセンス時間は SIFS + 2 x Slot Time として定義されます(※註)。
802.11/b では Slot Time=20μ秒でしたが、802.11g では高速化のため新たに 9μ秒の Short Slot Time オプションが追加されたため、例によって古い 20μ秒のものを Long Slot Time と呼んで区別します。AP は接続配下に 802.11/b(802.11g 非互換) のノードが居るかどうかを監視し、居た場合には Capability Bit の Short Slot Time=0 を設定し、接続配下のノードに対して Long Slot Time の使用を要求します。またプリアンブル同様 5GHz 帯に Long Slot Time の定義はなく、常に Short Slot Time が使用されます。
現在 802.11b オンリーの機器はさすがに少なくなってはいますが、ニホンカワウソなみに珍しい元祖 802.11 DSSS の機器に比べればまだ稼動数は多く、Long Slot Time が盲腸化する(Short Slot Time=常に 1 とみなせる)にはもう少し時間がかかりそうです。
(※註)SIFS(Short Interframe Space) はまた別の基底時間単位で、2.4GHz 帯で 16μ秒、5GHz 帯で 10μ秒として定義されています。802.11n ではこれを 2μ秒に短縮する RIFS(Reduced Inter Frame Space)モードが追加され、また新たな盲腸の種が増えました。
ERP-PBCC(Extended Rate PHY - Packet Binary Convolutional Coding)
802.11g では 802.11a から QAM 変調と OFDM 伝送方式の仕様が取り込まれて高速化(ERP:Extended Rate PHY)が行われましたが、実はこのとき PBCC という方式も採用されていました。PBCC は OFDM でもなければ周波数拡散もしない(古典的な)シングルキャリア伝送方式で、変調速度 16.5M シンボル/秒 x 8-PSK (3bit/シンボル) 変調で基底レート 49.5Mbps、符号化率の違いによって 22Mbps と 33Mbps のデータレートを持ち、802.11b に対してはちょうど２倍速・３倍速となります。
PBCC は Alantro Communications 社によって開発され、後に同社ごと Texas Instruments 社が買収したものと言われています。このモードが 802.11g 標準に取り入れられた経緯と背景について何となく想像はできますが、詳しいことは知りません。既述のように PBCC の通信原理は DSSS とも OFDM とも異なるため、PBCC 対応のためには送受信器の追加回路を実装する必要があり、これは開発コストにも製品単価にも影響します。しかもそれで実現できる性能が OFDM 以下とあっては、PBCC を実装する意味は全くないと言っていいでしょう。PBCC は IEEE802.11-2012 仕様書にもオプションとして残されていますが、今日これを実装した製品は皆無だと思います。
DSSS-OFDM
802.11b から 802.11g の移行期に提案された仕様です。前述のように WiFi(DCF) ではキャリアセンスによる送信タイミング制御を行いますが、これは「今この瞬間誰かが送信しているか否か」を常時傍受するわけではなく、送信開始時のプリアンブル(の中の PLCP ヘッダ部分)に「今から何マイクロ秒間送信しますよ」という情報が入っているので、受信した PLCP ヘッダを利用してバックオフ時間を算出します。
さて元祖 802.11 で使われていた DSSS(+BPSK/QPSK) と 802.11b で拡張された CCK は同じバーカー符合を用いた周波数拡散方式であり、プリアンブルフォーマットは全く同じです。しかし 802.11g の OFDM+(BPSK/QPSK/QAM) は周波数の利用形態からして全く異なる通信方式です。802.11b/g の機器は 802.11/b 形式のプリアンブル(バーカー・プリアンブル)も受信できますが、802.11/b の機器は 802.11g 形式のプリアンブル(ERP-OFDM プリアンブル) を受信できません。したがって 802.11b と g の機器が混在した場合、11g は 11b のプリアンブルを受信して「道を譲る」ことができますが、11b は 11g のプリアンブルを解釈できず、11g 送信中にもお構いなしに送信を開始して衝突し「潰し合う」確率が高くなります。
DSSS-OFDM はこれを回避するために提案されたフォーマットで、802.11g OFDM レート(6～54Mbps) で通信するときもプリアンブルと PLCP ヘッダだけは DSSS で送信し、その後にデータ本体(MPDU)を本来の OFDM で送信することで 11b ノードにも 11g パケットのキャリアセンスが効くようにして衝突を低減することが目論まれていました。STA は DSSS-OFDM の送受信が可能であるか否かを DSSS-OFDM Capability Bit にセットして AP に通知します。AP は接続配下において DSSS-OFDM の使用が許可されているか否かを DSSS-OFDM Capability Bit にセットして周辺に通知します。
DSSS-OFDM を使用した場合、11b/g 衝突低減の代償として 802.11g モードのスループットが低下します。802.11g 本来の ERP-OFDM プリアンブル占有時間約 20μ秒に対し、DSS-OFDM Long Preamble では 192+12μ秒、Short Preamble でも 96+12μ秒が占有されます。なお「+12」というのは通信途中で DSSS から OFDM に切り替えるオーバーヘッドです。
DSSS-OFDM も IEEE802.11-2012 仕様にオプションとして残っていますが、実装されている製品は多くありません。PBCC と異なり DSSS-OFDM は既存回路の組み合わせで実現できるのですが、DSSS-OFDM 適用時のスループット低下が少なくないこと、802.11b 機材が混ざって衝突を起こしても「使えなくなる訳でない」ので(特にコンシューマ市場では)「そんな問題が存在することすら認識されていない」場合が多いこと、802.11b 専用機材が減ってゆく一方であることなどが理由でしょう。
Channel Agility
802.11b で提案された拡張機能で、特定周波数妨害(tone jammer)に対応するために考えられたものです。DSSS/CCK 変調を使いながらも中心周波数(チャネル)を一定時間ごとにポンポン切り替えるという、周波数ホッピング(FH)の考え方を導入したものでした。この機能も IEEE802.11-2012 にオプションとして記載が残っていますが、802.11b モード(HR-PHY)の機能とされており 802.11g 以降には適用されず、事実上 Capability Bit に「常に 0」のビットとして残る盲腸となっています。
Radio Measurement
これも Capability Bit に残る盲腸の一つです。無線 LAN システムがどのように敷設運用されてどんな問題が出るかわからなかった時代、子機(STA)に電波使用計測機能を持たせておき、必要に応じて基地局(AP)からの指令で測定・報告を行わせればエリア全体の電波使用状況が把握でき、その測定結果に応じてパワーの増減、データレートやチャネル変更など適切な対応が取れるのではないかと考えられていました。STA は AP に対し、Capability Bit の Radio Measurement をセットすることで計測能力を持っていることを通知します。
IEEE802.11-2012 仕様では Section 10.11 を Radio Measurement 機能に充て、かなりの分量(26 ページ)を割いてこと細かく解説されていますが、実際にこの機能を実装した製品はほとんどありません。測定結果を受け取ったとしても、それを自動的に分析して「適切な対応」を取る機能の実現は非常に難しいのではないかと思います。将来そんな機能が実現したとしても、そこで用いられる計測・報告機構は 802.11 Radio Measurement とは別の枠組みで実装されるのではないかと思います。
まとめ
普段「何だか知らないけど常に 0」と読み飛ばしている機能について真面目に調べてみたら、思った以上に手間がかかってしまいました(WiFi の裏歴史が垣間見えて面白くもありましたが)。Short/Long Preamble だとか DSSS-OFDM モードについては誤解している人も少なくないのではないかと思います。この記事を書くにあたって IEEE802.11 仕様書原典だけでなく google 検索の結果も参照しましたが、「ん？！」と首を傾げる記事も散見されました。
今回は触れませんでしたが、802.11n 仕様ではまたテンコ盛りにオプション機能が追加されました。これは主要十数社が３つの標準化団体(WWiSE, TGnSync, MITMOT)に分かれて約３年間にわたり標準化論争をくり広げ、IEEE802.11n 標準制定が延々と遅延した騒動の痕跡でしょう(むしろ「傷跡」かな？)。802.11n 仕様の多すぎるオプションについてはさすがの IEEE も問題と認識していたようで、802.11ac 仕様では実用価値の少ない(と考えられた)多くのオプションが廃止扱いとなりました。例えば 802.11n「真の高速モード」と呼ばれた Greenfield mode も廃止されています。増え続けるオプション仕様に「いい加減にしてくれ」と辟易しているエンジニアとしては歓迎すべきことですが、かくしてまた多くの盲腸が WiFi 仕様に残されたわけです。
こんな仕事をしていると、人はどうして同じ過ちを何度も繰り返すのだろうと虚無的な気持ちになることもあります。世界中全てのコンピュータを統一規格で統合接続する OSI プロジェクトがバベルの塔のごとく崩壊したのが 1980 年代、その後も IPv6 で世界をもう一度つなぎ直すんだとか、Java の Write Once Run Everywhere 構想だとか SOAP/XML で何でもつなぐ .NET 構想、最近では HTML5 さえあれば APP は不要になるんだとか、そんな夢が語られて標準委員会が結成されるたびに宗教戦争にも似た派閥争いが起こり、あるいは皆で寄ってたかって「良かれ」と思いついたオプション仕様を放り込んで電話帳みたいな仕様書の山を作り、それが実装される前にブームが去って忘れられ、その頃には次のブームに乗っかってまた宗教戦争をやったり仕様書の山を作ったりしています。
まぁ、そんなことに一喜一憂する歳も過ぎました。何が出てきても「これは凄い革命だ！これで世界は変わる！」と興奮したり「どうしてあんな下らないものが流行るんだ？みんな騙されてる！」とか憤ったりすることもなく、「で？何すりゃいいの？言われりゃ何でも作るよ」という気分です。
PCF(Point Coordination Function)
コンピュータネットワークには様々な接続形態(ツリー型、リング型など)がありますが、無線ネットワークは全てのノードが通信媒体を共有する「バス型」だと考えられます。バス型ネットワークでは２台以上のノードが同時に送信することはできないので、何らかの通信タイミング制御機構が必要になります。WiFi において、これは DCF(Distributed Coordination Function)と PCF という２方式が使用できることになっています。
DCF というのは各ノードが一定期間「誰も送信してないよね？僕が送信してもいいよね？」と聞き耳を立てる(キャリアセンス)こと、もし誰かが送信していればランダム時間の遅延後に再トライする(バックオフ)する方式で、実装・設定が簡単でノード数が少ないときは高速に動く反面、ノード数が増えると衝突が増えて効率が落ちる欠点を持ちます。
PCF はこれに対し、１台のノード(コーディネイター、通常は AP)が主導権を持って「○○さん送信してください。終わりましたか？では次は××さん送信してください」と送信タイミングを指示する方式で、有線ネットワークで「トークン方式」と呼ばれているものに似ています。PCF は実装の手間が増え、台数が少ない(衝突確率が低い)時にもオーバーヘッドがかかってピーク性能が出ない欠点がありますが、台数が増えても衝突確率を抑えることで極端な性能低下を避けられる利点があります。
PCF/DCF は WiFi 教科書の前半あたりによく出てくる話題ですが、現実にはほとんどの AP には DCF しか実装されていません。高価な業務用の AP には PCF が実装されている場合もありますが、そこに接続される STA (PC やスマートフォン)が PCF の仕様どおりに動作するかどうかは怪しいものです。しかし PCF の機能・考え方の一部は QoS(Quality of Service) 機構として IEEE802.11e/WMM(WiFi Multi Media) 仕様に取り込まれており、WiFi で帯域保証が必要な場合は PCF ではなく WMM を使うことが現在では一般的になっています。
CFP(Contention Free Period)
PCF 通信方式では使われるタイミングパラメータです。定義や文脈によっては Contention Free Parameter の略である場合もありますが、基本的には同じことを意味しています。PCF モードは単一のビットではなく、Capability Information の３ビット(QoS, CF-Pollable, CF-Poll Request)を組み合わせて動作モードが通知設定されますが、詳細については割愛します(IEEE802.11-2012 Section 8.4.1.4 を参照してください)。
Short Preamble
プリアンブル(Preamble) というのは送信データの手前に付けられる一定パターンの反復で、このパターンを用いて送受信器間のクロック同期などを行います。技術的な定義において「プリアンブル」は(通常)有意なデータを含まないのですが、便宜上の WiFi 用語としての「プリアンブル」は技術上の意味における「プリアンブル」にパケットヘッダ(PLCP ヘッダ)を含めたものを指す場合が多いです。
元祖 802.11 DSSS 仕様でのプリアンブルは PLCP ヘッダ部 1Mbps 変調の 192μ秒でしたが、801.11b では高速化オプションとして 2Mbps 変調 96μ秒のモードが追加されました。これを Short Preamble と呼ぶようになったので、元祖 802.11 互換 192μ秒のモードを Long Preamble と呼んで区別しています。
STA は自身が Short Preamble を処理できるか否かを Capability Bit にセットして AP に通知し、AP は管理下のネットワークで Short Preamble の使用を許可するか否かを Capability Bit にセットして周辺に通知します。
Short Preamble は 802.11g 以降で実装必須となったので、「Long Preamble を使わなければ互換性が保証できない」という事態はよほど古い仕様の 802.11b 専用機材、あるいはプレミアが付きそうな元祖 802.11 DSSS 専用の機材を使わないかぎり発生しません。また 802.11g の OFDM レートで通信する場合は Long/Short とは別仕様の ERP-OFDM Preamble (20μ秒)が使用される(※註)ため、現在では Long/Short Preamble の区別はあまり意味を持っていません。また 5GHz 帯にはそもそも 802.11/b 互換の必要がなく常に ERP-OFDM が使用され、Short/Long Preamble の概念はありません。
(※註)ただし例外もあり得ます。詳細については後述の DSSS-OFDM に関する記述を参照してください。
バーカー・プリアンブル・モード(Barker Preamble Mode)
802.11g 以降の 2.4GHz 帯において AP から通知される情報の１つで、AP 接続配下に Short Preamble をサポートしない STA があるか否かを示す情報です。Barker Preamble Mode=1 の場合は AP 接続配下に少なくとも１台、Short Preamble を解釈できないノードが居ることを示し、 Short Preamble の使用が禁止されます。0 の場合は許可されます(※註)。前述のように Long Preamble しか受信できない機材は現在ではきわめて稀なため、これが 1 になることは滅多にありません。
バーカー・プリアンブル・モードは Capability Bit を「はみ出して」しまった情報の１つで、拡張情報要素(IE:Information Element)の番号 42 番「ERP IE」のなかに示されます。また「バーカー・プリアンブル」という妙な名前は、元祖 802.11 DSSS および 802.11b CCK 変調が 11 チップのバーカー拡散符合系列(Barker Code Spreading) というアルゴリズムを使用していることに由来しています。802.11b 互換 1～11Mbps の通信では必ずバーカー符号が使われるわけで、「バーカー・プリアンブル・モード」という特殊な通信モードがあるわけではありません。いっそ「Short Preamble Enable」という名前のほうがわかりやすかったのでないかと思いますが、何でここだけわざわざ名指しでアルゴリズム名を冠しているのかは判りません。そもそも「AP 接続配下における Short Preamble の使用禁止/許可」という機能は Capability Bit の Short Preamble ビットと重複するのですが、何故 802.11g でわざわざ重複する機能を追加したのかもよくわかりません。
(※註)ただし Short Preamble の使用は「許可される」だけであって Long Preamble の使用が禁止になるわけではないので、802.11/b レートで常に Long Preamble を送信する実装(Forced Long Preamble)もあり得ます。ただしこの場合でも、Short Preamble の受信は可能でなければなりません。
Short Slot Time
802.11b と 802.11g 混在制御機能のひとつです。プリアンブルと紛らわしいのですが、Short/Long プリアンブルが元祖 802.11(DSSS) と 802.11b(CCK) 互換性のために定義されているのに対し、Short/Long Slot Time は 802.11/b と 802.11g(以降)互換性のための定義です。Slot Time というのは WiFi が動作する上で定義されている基底時間単位の１つで、例えば既出のキャリアセンス時間は SIFS + 2 x Slot Time として定義されます(※註)。
802.11/b では Slot Time=20μ秒でしたが、802.11g では高速化のため新たに 9μ秒の Short Slot Time オプションが追加されたため、例によって古い 20μ秒のものを Long Slot Time と呼んで区別します。AP は接続配下に 802.11/b(802.11g 非互換) のノードが居るかどうかを監視し、居た場合には Capability Bit の Short Slot Time=0 を設定し、接続配下のノードに対して Long Slot Time の使用を要求します。またプリアンブル同様 5GHz 帯に Long Slot Time の定義はなく、常に Short Slot Time が使用されます。
現在 802.11b オンリーの機器はさすがに少なくなってはいますが、ニホンカワウソなみに珍しい元祖 802.11 DSSS の機器に比べればまだ稼動数は多く、Long Slot Time が盲腸化する(Short Slot Time=常に 1 とみなせる)にはもう少し時間がかかりそうです。
(※註)SIFS(Short Interframe Space) はまた別の基底時間単位で、2.4GHz 帯で 16μ秒、5GHz 帯で 10μ秒として定義されています。802.11n ではこれを 2μ秒に短縮する RIFS(Reduced Inter Frame Space)モードが追加され、また新たな盲腸の種が増えました。
ERP-PBCC(Extended Rate PHY - Packet Binary Convolutional Coding)
802.11g では 802.11a から QAM 変調と OFDM 伝送方式の仕様が取り込まれて高速化(ERP:Extended Rate PHY)が行われましたが、実はこのとき PBCC という方式も採用されていました。PBCC は OFDM でもなければ周波数拡散もしない(古典的な)シングルキャリア伝送方式で、変調速度 16.5M シンボル/秒 x 8-PSK (3bit/シンボル) 変調で基底レート 49.5Mbps、符号化率の違いによって 22Mbps と 33Mbps のデータレートを持ち、802.11b に対してはちょうど２倍速・３倍速となります。
PBCC は Alantro Communications 社によって開発され、後に同社ごと Texas Instruments 社が買収したものと言われています。このモードが 802.11g 標準に取り入れられた経緯と背景について何となく想像はできますが、詳しいことは知りません。既述のように PBCC の通信原理は DSSS とも OFDM とも異なるため、PBCC 対応のためには送受信器の追加回路を実装する必要があり、これは開発コストにも製品単価にも影響します。しかもそれで実現できる性能が OFDM 以下とあっては、PBCC を実装する意味は全くないと言っていいでしょう。PBCC は IEEE802.11-2012 仕様書にもオプションとして残されていますが、今日これを実装した製品は皆無だと思います。
DSSS-OFDM
802.11b から 802.11g の移行期に提案された仕様です。前述のように WiFi(DCF) ではキャリアセンスによる送信タイミング制御を行いますが、これは「今この瞬間誰かが送信しているか否か」を常時傍受するわけではなく、送信開始時のプリアンブル(の中の PLCP ヘッダ部分)に「今から何マイクロ秒間送信しますよ」という情報が入っているので、受信した PLCP ヘッダを利用してバックオフ時間を算出します。
さて元祖 802.11 で使われていた DSSS(+BPSK/QPSK) と 802.11b で拡張された CCK は同じバーカー符合を用いた周波数拡散方式であり、プリアンブルフォーマットは全く同じです。しかし 802.11g の OFDM+(BPSK/QPSK/QAM) は周波数の利用形態からして全く異なる通信方式です。802.11b/g の機器は 802.11/b 形式のプリアンブル(バーカー・プリアンブル)も受信できますが、802.11/b の機器は 802.11g 形式のプリアンブル(ERP-OFDM プリアンブル) を受信できません。したがって 802.11b と g の機器が混在した場合、11g は 11b のプリアンブルを受信して「道を譲る」ことができますが、11b は 11g のプリアンブルを解釈できず、11g 送信中にもお構いなしに送信を開始して衝突し「潰し合う」確率が高くなります。
DSSS-OFDM はこれを回避するために提案されたフォーマットで、802.11g OFDM レート(6～54Mbps) で通信するときもプリアンブルと PLCP ヘッダだけは DSSS で送信し、その後にデータ本体(MPDU)を本来の OFDM で送信することで 11b ノードにも 11g パケットのキャリアセンスが効くようにして衝突を低減することが目論まれていました。STA は DSSS-OFDM の送受信が可能であるか否かを DSSS-OFDM Capability Bit にセットして AP に通知します。AP は接続配下において DSSS-OFDM の使用が許可されているか否かを DSSS-OFDM Capability Bit にセットして周辺に通知します。
DSSS-OFDM を使用した場合、11b/g 衝突低減の代償として 802.11g モードのスループットが低下します。802.11g 本来の ERP-OFDM プリアンブル占有時間約 20μ秒に対し、DSS-OFDM Long Preamble では 192+12μ秒、Short Preamble でも 96+12μ秒が占有されます。なお「+12」というのは通信途中で DSSS から OFDM に切り替えるオーバーヘッドです。
DSSS-OFDM も IEEE802.11-2012 仕様にオプションとして残っていますが、実装されている製品は多くありません。PBCC と異なり DSSS-OFDM は既存回路の組み合わせで実現できるのですが、DSSS-OFDM 適用時のスループット低下が少なくないこと、802.11b 機材が混ざって衝突を起こしても「使えなくなる訳でない」ので(特にコンシューマ市場では)「そんな問題が存在することすら認識されていない」場合が多いこと、802.11b 専用機材が減ってゆく一方であることなどが理由でしょう。
Channel Agility
802.11b で提案された拡張機能で、特定周波数妨害(tone jammer)に対応するために考えられたものです。DSSS/CCK 変調を使いながらも中心周波数(チャネル)を一定時間ごとにポンポン切り替えるという、周波数ホッピング(FH)の考え方を導入したものでした。この機能も IEEE802.11-2012 にオプションとして記載が残っていますが、802.11b モード(HR-PHY)の機能とされており 802.11g 以降には適用されず、事実上 Capability Bit に「常に 0」のビットとして残る盲腸となっています。
Radio Measurement
これも Capability Bit に残る盲腸の一つです。無線 LAN システムがどのように敷設運用されてどんな問題が出るかわからなかった時代、子機(STA)に電波使用計測機能を持たせておき、必要に応じて基地局(AP)からの指令で測定・報告を行わせればエリア全体の電波使用状況が把握でき、その測定結果に応じてパワーの増減、データレートやチャネル変更など適切な対応が取れるのではないかと考えられていました。STA は AP に対し、Capability Bit の Radio Measurement をセットすることで計測能力を持っていることを通知します。
IEEE802.11-2012 仕様では Section 10.11 を Radio Measurement 機能に充て、かなりの分量(26 ページ)を割いてこと細かく解説されていますが、実際にこの機能を実装した製品はほとんどありません。測定結果を受け取ったとしても、それを自動的に分析して「適切な対応」を取る機能の実現は非常に難しいのではないかと思います。将来そんな機能が実現したとしても、そこで用いられる計測・報告機構は 802.11 Radio Measurement とは別の枠組みで実装されるのではないかと思います。
まとめ
普段「何だか知らないけど常に 0」と読み飛ばしている機能について真面目に調べてみたら、思った以上に手間がかかってしまいました(WiFi の裏歴史が垣間見えて面白くもありましたが)。Short/Long Preamble だとか DSSS-OFDM モードについては誤解している人も少なくないのではないかと思います。この記事を書くにあたって IEEE802.11 仕様書原典だけでなく google 検索の結果も参照しましたが、「ん？！」と首を傾げる記事も散見されました。
今回は触れませんでしたが、802.11n 仕様ではまたテンコ盛りにオプション機能が追加されました。これは主要十数社が３つの標準化団体(WWiSE, TGnSync, MITMOT)に分かれて約３年間にわたり標準化論争をくり広げ、IEEE802.11n 標準制定が延々と遅延した騒動の痕跡でしょう(むしろ「傷跡」かな？)。802.11n 仕様の多すぎるオプションについてはさすがの IEEE も問題と認識していたようで、802.11ac 仕様では実用価値の少ない(と考えられた)多くのオプションが廃止扱いとなりました。例えば 802.11n「真の高速モード」と呼ばれた Greenfield mode も廃止されています。増え続けるオプション仕様に「いい加減にしてくれ」と辟易しているエンジニアとしては歓迎すべきことですが、かくしてまた多くの盲腸が WiFi 仕様に残されたわけです。
こんな仕事をしていると、人はどうして同じ過ちを何度も繰り返すのだろうと虚無的な気持ちになることもあります。世界中全てのコンピュータを統一規格で統合接続する OSI プロジェクトがバベルの塔のごとく崩壊したのが 1980 年代、その後も IPv6 で世界をもう一度つなぎ直すんだとか、Java の Write Once Run Everywhere 構想だとか SOAP/XML で何でもつなぐ .NET 構想、最近では HTML5 さえあれば APP は不要になるんだとか、そんな夢が語られて標準委員会が結成されるたびに宗教戦争にも似た派閥争いが起こり、あるいは皆で寄ってたかって「良かれ」と思いついたオプション仕様を放り込んで電話帳みたいな仕様書の山を作り、それが実装される前にブームが去って忘れられ、その頃には次のブームに乗っかってまた宗教戦争をやったり仕様書の山を作ったりしています。
まぁ、そんなことに一喜一憂する歳も過ぎました。何が出てきても「これは凄い革命だ！これで世界は変わる！」と興奮したり「どうしてあんな下らないものが流行るんだ？みんな騙されてる！」とか憤ったりすることもなく、「で？何すりゃいいの？言われりゃ何でも作るよ」という気分です。
