Wi-Fi 6Eで飛躍的に増えるチャネル、その運用にはさらなる議論が必要？

Wi-Fi 6出荷台数は2024年度までに44億4000万台、うち6Eは16％　普及が進まないのは折り込み済み？

　前回の「Regulatory Update」に続き、今回は「Wi-Fi 6E Update」について見ていこう。発表を行ったWi-Fi AllianceのNicholas Sargologos氏（Senior Product Manager）によれば、2021年のWi-Fi 6E対応製品は3億3800万台になる見込みだという。

　IDCの予測では、2023年がWi-Fi 6対応製品のピークで、2024年になると次第に減少する見込みであり、一方でWi-Fi 6Eは引き続き投入製品数が増えるとされている。

もっとも、2021年度にWi-Fi 6を含めた全体の出荷台数は21億台を超えるなか、Wi-Fi 6E対応製品は全体の16％ほどに留まる予定である

　その2024年度におけるWi-Fi 6/6E対応製品の総出荷台数はおおよそ44億4000万台前後。うちWi-Fi 6E対応製品は14億台程度と、全体の3割程度を占める程度に留まりそうである。

　これは納得の数字であって、やっとWi-Fi 6対応製品が増えてきたと言いつつ、いまだにIoT向けにはWi-Fi 4とBluetooth 5のコンボモジュールの新製品が投入される（例えばu-bloxのMAYA-W1など）というくらいに、市場の動きはゆっくりなのだ。

　ある意味Wi-Fi 6Eというのは、来るWi-Fi 7に向けての6GHz帯の露払い的な役割を期待されているところもあって、普及がそれほど急速に進まないのは、ある面では折り込み済みの部分もあるかと思う。

圧倒的に増えるチャネル数がWi-Fi 6Eのメリット

　そのWi-Fi 6Eのメリットとして挙げられているのは、圧倒的に増えるチャネル数と、これにより以前よりも高速につながる「場合が増える」ことにあるとする。特に以前のWi-Fi 6では160MHzチャネルは仕様上は定められていても、実際にそれを使える機会は非常に稀であった。6GHz帯を使うと、160MHzチャネルを利用できる機会は大幅に増えるだろう。

2.4GHz帯は言うまでもなく、5GHz帯も最近は混雑してきているので、利用周波数帯が増えるのはそれだけでありがたい。6GHz帯は、500MHz幅でも、従来の2.4GHz帯と5GHz帯を合わせたのと同等の帯域になる

　これをもう少し細かく説明したのが下の図である。Channel width/number availableの説明は不要だろう。IEEE 802.11axで新機能として追加されたのが「AP discovery」で、Section 26.17.2.4に追加されることになっている（まだIEEE 802.11ax-2021がGet 802 Programの対象になっていない関係で、筆者も仕様そのものは確認できていない）。

5GHz帯のチャネル数が（）付なのは、国によって5GHz帯が制限されている場合があるから（日本も以前は（）内の状態だった）

　もっとも、Wi-Fi Allianceの側もこのAP Discoveryまわりに関してはIEEE 802.11axの標準化完了を待てなかったようで、実害はないだろうがDraft 5.0をベースに議論されていたりする。

　そのAP Discoveryであるが、従来はIn-Band、つまり自分が利用する周波数帯（2.4GHz/5GHz）のみのDiscoveryしかできなかった。これがややこしくなるのは、アクセスポイント（AP）の側で2.4GHz帯と5GHz帯でしばしば異なるBSSが設定されており、さらに5GHz帯のうちでもLow Band（W52・W53）とHigh Band（W56）で別々のBSSになっているケースすらあったことだ。

　となると、クライアントでAP Discoveryを行う場合、2.4GHzと5GHz×2を別々に探索する必要があった。これがIn-Band AP Discoveryである。そして6GHz帯に関しては、AP Discoveryを行う場合に6GHz帯に加えて2.4GHz/5GHz帯もBSS検索を同時に行うことで、結果的に目的のBSSを迅速に見つけられるようになった。これがOut-of-Band AP Discoveryであり、要するに6GHz帯以外（Out-of-band）も同時に検索する、というわけだ。

Standard Powerの電力クラスで利用が必須の「AFC」とは？

　さて前回、LPI/VLP/Standardの3つの電力クラスがあるという話をしたが、以下がその内訳となる。

LPIの帯域でVLPを使ってはいけない、ということはないので、米国ではLPI＆AFCの周波数帯をVLPでも利用できる。ただ、LPIだけの国で、屋内では使えるVLPが屋外でも使えるかは微妙なところ

　1200MHz帯の場合、おおむねLPI＆Standard（表記ではLPI＆AFCになっている）に割り当てられているが、UNII-6とUNII-8にはLPI Only（つまりAFCを利用したStandar Powerは不許可）な周波数帯が広がっている。逆に言えばVLP Onlyという周波数帯はない。

　一方でEUなど500MHz帯の場合、すべてがLPI＆VLP対応ということになっている。ただこれは前回も書いたが、VLPにしてもLPIにしても国ごとに細かく規定が違うので、上の図では"US and other countries"と能天気に分類しているが、実際には国によって変わってくる可能性もありそうだ。

　さて、問題のAFC（Automated Frequency Coordination）である。Standard Deviceの場合はAFCの利用が必須となっているが、その仕組みを簡単にまとめたのが以下の図である。全てのStandard Powerに対応するAPは、AFC Systemなるものへ直接ないしProxy経由で接続することになる。

このAFC Systemそのものは世界に1つだけというわけではなく、当然さまざまなプロバイダーが提供することになるとは思うが、どういう形態で提供されるのかはこれからの議論となる

APのIDや位置情報から利用周波数やチャネルを割り振る「AFC System」

ちなみにGoogle マップで位置を確認すると太平洋上（サンフランシスコから47Kmほど東）だったのだが、解釈が間違ってるのだろうか？出典は"AFC System to AFC Device Interface Specification Version 1.0"のAppendix A

　AFC Systemに接続して何をやるかというと、APは自分のIDおよび位置情報とともに、利用したい周波数帯と出力をAFC Systemに対してリクエストし、その結果としてAFCからは利用できる周波数帯や出力が戻ってくる、というものだ。右がそのリクエストのサンプルとなる。

　最初のdeviceDescriptionが自身のIDであり、次のlocationが位置情報で、ここに高さなどの情報も含まれる格好だ。このlocationの指定方法はいくつかあり、この例だとecripseということで、楕円の中心と長軸／短軸の半径、および傾きの方向が示され、サンフランシスコ沖約47kmの海中を中心とした、長軸100m／短軸50mの楕円の中に設置されることになるらしい。アンテナの高さは水面から3mで、そこから2mの位置にAP本体が置かれるようだ（普通に考えたらアンテナの下だろうが、verticalUncertainyはアンテナと機器の距離の絶対値なので、上下の位置関係は不明）。

　その次がリクエストとなる。周波数レンジを指定しての問い合わせ（inquiredFrequencyRange）と、チャネルを指定しての問い合わせ（inquiredChannels）の2種類がリクエストでき、この例で言えば5925～6425MHz、つまりUNII-5に対してのリクエストをまず出すとともに、UNII-5で160MHzのチャネル、およびUNII-5/7で80MHzのチャネルをリクエストしている。

返答はこんな感じに、利用可能な周波数とチャネルのリストが返ってくる格好。出典は"AFC System to AFC Device Interface Specification Version 1.0"のAppendix A

　リクエストに対するAFC Systemからの返答が右となる。ここでは5925～6020MHzがEIRP 23dBm/MHz、6020～6050MHzが1dBm/MHz、6050～6360MHzが23dBm/MHz、6360～6390MHzが-24dBm/MHz、6390～6425MHzが23dBm/MHzでそれぞれ運用可能とされる。

　さらにUNII-5ではChannel 7/39/55/71/135/151/167が、UNII-7ではChannel 47がそれぞれ利用可能として割り当てられた格好だ。あとはAPがこれを解釈し、渡された利用可能周波数帯にそれぞれ許された出力の範囲内でオペレーションを行うことになる。

　ちなみに、最後にはExpireTimeが入っており、このExpireTimeを超える前に次のRequestを出し、新たに利用可能な周波数帯および出力を確認する必要がある。このExpresTimeがどの程度の間隔になるのかは不明だが、逆に言えば、こうしたExpireTimeが設けられているというあたり、そもそもAPが移動することは（当然だが）念頭に置いていないようだ。

APには位置情報取得が必須、AFC Systemの運用には、さらなる議論が

　この仕組みを実現するために、APに位置情報取得システムとしてのGNSS（普通はGPSだろうが、GLONASSやGalileoのニーズもありそうだ）などの搭載が望ましいのだろう。位置情報が分かればいいのでRNSSでも構わず、例えば「みちびき」でもいいはずだ。

　ただし、アンテナの高さ、本体の位置といった情報までを自動で取得させるのは、不可能ではないにせよ、なかなか大変である。となるとAPへ、こうした情報を入力するためのインターフェースが追加され、設置の際にそうした情報を入力していく、というオペレーションが一般的になるだろうし、APは必然的に家庭向けというより業務用がメインになるだろう。公衆無線LANや大規模建造物（スタジアムや展示場など）向けのAPなどが一番ありそうな例だ。

　面倒なのは、むしろAFC Systemの側だろう。こちらは既存のFS/FSSの運用情報を位置情報付きで保有した上で、AFC Device（つまりAP）からのリクエストに対し、干渉を起こさないように周波数とチャネルを適切に配慮して割り振る必要がある。

　あと、例えばAFC Device 1～3がそれぞれ別組織のものという場合も当然あり得るわけで、これらに対して周波数とチャネルを均等に割り振るとともに、互いの干渉も防がないといけない。そもそもFS/FSSの運用情報と位置情報を保有する段階で、現時点でそれが可能なのはアメリカならFCC、日本なら全国11カ所の総合通信局（旧電波監理局）しかない。

　こう組織がAFC Systemをどのようなルールにのっとって運用を行うか、ということまで考慮すれば、議論すべき内容はたっぷりありそうだ。とりあえず米国が先行するのは間違いないが、まずそこでどういう運用が行われるかが焦点となりそうだ。