LED通信事業プロジェクト　エンジニアブログ

話題の3つのAIに光無線通信の標準規格について聞いてみた

記事更新日 2023年5月30日

はじめに

以前より書いていると思いますが、弊社のLEDバックホールはドイツの公的研究機関であるFraunhofer HHI（以降HHI）というところの技術を使っています。Fraunhoferは効率研究機関全体の名称で、HHIが個別の研究所の名前となります。HHIは通信研究所で、日本で言えばNICT（情報通信研究機構）に当たる研究所と言っていいでしょう。尚、ドイツでは研究所に過去の偉人の名前を付けるのが一般的らしいです。よく考えればドイツだとそんなレベルの方は沢山いますしね。ですので、Fraunhofer（フラウンホーファー）は、光学の偉人でいくつかの物理法則に彼の名前が残っていますし、HHIはHeinrich Hertz Instituteの略であり、あの周波数のヘルツから取っています。

で、なんでこんなことを書いたかというと、今日のテーマである光無線通信の規格はほとんどそのHHIによって策定されているからです。光無線通信においてはHHIがかなりリードしている状態で、まあ自虐的になってしまいますが光無線通信のプレーヤーというのも大していない状態ですので、HHIが規格策定を仕切るというのも当然の流れということになります。で、HHIが中心となって策定した（している）規格は、具体的に言うとITU-T G.vlc（正式な番号はG.9991）という規格と、IEEE802.15.13という規格です。どちらも似たような内容の規格となりますが、どちらも共通しているのが「Gigabit Home Networking」という技術をベースにしているところです。

Gigabit Home Networking（GHN）とは、簡単に言えば「屋内にある既存の配線を使って高速に通信する」ための技術です。かつて日本でも少しだけ注目を浴びた「電力線通信」もこの技術に含まれますが、それだけでなく電話線やアンテナ用同軸を使った高速通信も可能にする技術です。正直、地震や気候の関係で家の寿命が短くて建て替えが多い日本ではほとんど注目されない技術です。実際、我が家も15年以上前に建てた家ですが、その当時でさえ各部屋にテレビアンテナ線と一緒にLANケーブルも配線しましたから、うちより新しい今時の一戸建てやマンションはそんな感じでGHNを必要としない家ばかりでしょう。ただ、ヨーロッパとかだとそんなわけにいかず、100年、200年前に立てられた石積の中古の家がステータスである、みたいな地域も少なくないですから、既存の最低限の配線を有効活用するというニーズは一定数あるはずです。石積とかだとWi-Fiも通りにくいですからね。とはいえ、日本以外でもGHNがニッチでマイナーな存在である事は間違いないのですが。

話を戻すと、電力線、電話線、同軸を使った通信というのは、有線通信ではあるものの、実は無線に近い特性も必要なんです。例えばLANケーブルであれば、あまりエラーとか干渉とか気にしなくていいです。もちろん全く発生しないわけではないですが、通常使っている分にはほぼエラーフリーですし、他の（違う種類の）通信に気を遣う必要はない。しかし、電力線等の通信は、基本的に「他の用途」で使われている線で行います。ですから、その本来の用途の通信（周波数）を避けなければならないし、想定していないようなノイズが混ざることもあるし、古い建物を前提としているため有線そのものの品質も担保されていない環境が前提としなければいけない。だから、エラー訂正の機能もがっちりありますし、適応変調もある。OFDMですが、特定の周波数だけカットオフする機能もある。そして、まあ電力線とか同軸線は、屋外に出ている（繋がっている）ために外部からアクセスしやすいという理由もあって、他の有線接続と異なり暗号化も実装していなくてはいけない。そんなわけで、このGHNはいろいろな技術を包括しなければならず、それ故標準化も行われていてITU-T G.hnと呼ばれる規格となっていますし、Home Grid Forum^※1という団体で認証も行っています。

そしてGHNのこれらの機能は、実は光無線通信に最適だったりします。光無線は見通し通信（LOS）しかできないため、無線と言っても携帯電話とかWi-Fiとかほどエラー訂正能力だったり、マルチパスへの対応能力^※2だったりが必要ではないのです。GHNも腐っても有線通信ですから、エラー訂正も無線ほど高くなくていいし、マルチパスも心配する必要はない。というわけで、全く干渉やエラーが発生する訳ではないが、それでいて携帯電話とかほどに強力なモバイル通信環境も必要ない、という光通信は、有線通信のGHNと必要とすることが非常に似ていて、そのため光無線通信はGHNベースの技術を採用することになりました。そうすると、GHNのチップセットがそのまま使えるようになるため、光無線通信を容易に実装ができてメリットがあるし、GHN側も用途が広がるし、ということでwin-winの関係であると言っていいでしょう。

そういった背景があり光無線通信関連規格G.vlcとIEEE802.15.13はどちらもGHNの規格をベースとしております・・・　と前振りが長くなりましたが、今回はこのマイナーな、いやドマイナーな光無線通信の規格を最近のAIは知っているのか？理解しているのか？ということを調べたいと思います。そして、AIにこのマイナーな規格の概要を説明して貰おう、という企画です。ちなみにどちらの規格も2022年以前から存在しているため「AI学習後に作られた」ということはありません。

今回調査するのは、OpenAIのChatGPT、最近日本語化されたばかりのGoogleのBard、ChatGPTと同じGPTエンジンを使用しているマイクロソフトのBing（チャット）の3つです。この3つがドマイナーな規格をどこまで知っているのか？どのような説明をするのか？是非ご覧下さい。

※注：ChatGPTとBardはGoogle Chrome、BingはMicrosoft Edgeを使用しています。各AI回答は全部載せたら長くなるので、所々省略しますのでご承知置きください。その他、各AIの条件は以下の通りです。

ChatGPTはGPT-3.5を使用します。（GPT-4.0も試しましたが、この手の質問は3.5の方が回答してくれるので）
Bardは複数回答案が出ますが、最初の回答（回答案1）のみを採用します。
Bingは会話スタイルを選べますが、今回は”バランス"設定です。回答中にあるリンクは削除してます。また重要な部分を太文字で強調してくれますが、今回の回答転載には反映させません。

基本的な質問

Q1: あなたは、ITU-T G.vlcとIEEE802.15.13を知っていますか？

ChatGPT: はい、ITU-T G.vlcとIEEE 802.15.13について知識を持っています。 ITU-T G.vlc（可視光通信）は、可視光スペクトルを使用してデータ通信を行うための標準化された仕様です。通常、可視光通信ではLEDや蛍光灯などの光源を使用して、データを送信するための光パルスを生成します。受信側では、光パルスを検出してデータを復元します。G.vlcは、高速かつ安定したデータ転送を提供するためのプロトコル、モジュレーション手法、エラー制御手法などを定義しています。可視光通信は、無線通信が制限されている環境や、電波干渉が起こりにくい環境で利点を発揮することがあります。 IEEE 802.15.13は、Wireless Specialty Networks（WSN）の標準化グループであるIEEE 802.15によって定義された規格です。IEEE 802.15.13は、Visible Light Communication（VLC）という特定のアプリケーションに焦点を当てています。この規格は、可視光通信（VLC）を使用したワイヤレスネットワークのデータ転送を扱うための仕様を提供します。IEEE 802.15.13は、通信プロトコル、モジュレーション方式、データフレーミングなどの要素を規定しています。この規格は、光環境下でのローカルエリアネットワーク（LAN）やホームオートメーションシステムなどのアプリケーションで利用されることがあります。（後略）

Bard: はい、ITU-T G.vlcとIEEE802.15.13を知っています。 ITU-T G.vlcは、ビデオおよびオーディオコンテンツを伝送するためのブロードバンドマルチキャストメディア伝送プロトコルです。可視光通信（VLC）技術に基づいており、低帯域幅および低遅延ネットワークに最適です。 IEEE802.15.13は、低消費電力および低遅延ワイヤレスネットワーク用に設計された無線規格です。産業用オートメーション、スマートグリッド、およびウェアラブルデバイスなどのアプリケーションに最適です。 ITU-T G.vlcとIEEE802.15.13はどちらも、次の利点があるため、注目に値します。（後略）

Bing: はい、ITU-T G.vlcとIEEE802.15.13について知っています。ITU-T G.vlcは、高速な室内可視光通信トランシーバーのシステムアーキテクチャ、物理層、データリンク層の仕様を定めたITU-Tの勧告です。IEEE802.15.13は、移動端末を含む200メートル以内の範囲で数ギガビット/秒の光無線通信（OWC）を実現するプロトコルと互換性のあるネットワーク機器を定義するIEEEの標準規格です。両者ともに、光を媒体とする無線通信技術であり、電波干渉や電磁波障害の影響を受けにくいという特徴があります。

ChatGPTとBingは近い回答ですが、よりChatGPTの方が詳しいですね。まあ、これに限らずBingの回答は常に短めです。一方、BardはIEEE802.15.13を光無線通信の規格と認識していないかのようです。Bardは3つほど回答案を作りますが、他の回答案を見ても同様でした。802.15シリーズは、Bardのいうように確かにZigBeeとかと同じWANのグループなので、スマートグリッド等を意識したものではあるのですが、802.15.13は前提が光無線通信と明確に書いてある標準規格なので、それに触れないというのは回答としては若干厳しいところがあります。

さて、次はGHNの規格であるITU-T G.hnの事について聞いてみます。

Q2: G.hnについて知っていますか？

ChatGPT: はい、G.hnについて知識を持っています。 G.hn（Global Home Networking）は、ITU-T（国際電気通信連合 - 電気通信標準化セクタ）が定めたホームネットワーキングのためのグローバルな標準規格です。G.hnは、異なるメディア（電力線、同軸ケーブル、電話線など）を使用してホームネットワークを構築するための技術を提供します。 G.hnの目的は、高速かつ信頼性のあるデータ通信をホームネットワーク内で実現することです。G.hnは、異なるメディアの物理層とデータリンク層の間で相互運用性を提供するための技術を定義しています。また、セキュリティやクオリティ・オブ・サービス（QoS）などの要素も考慮しています。 G.hnは、家庭内のインターネット接続、ビデオストリーミング、音声通話、スマートホームデバイスの連携など、さまざまなアプリケーションに利用されることがあります。異なるメディアを利用するため、従来の有線や無線のネットワーキング技術に比べて、より広範囲なカバレッジや高い伝送性能を提供することが特徴です。 G.hnは、ITU-TのG.hnシリーズの一部として、G.hn PHY（物理層）、G.hn MAC（データリンク層）、G.hn Transport（トランスポート層）などの仕様で構成されています。これらの仕様は、ホームネットワークのハードウェアやソフトウェアの開発に活用されます。

Bard: はい、G.hnについて聞いたことがあります。G.hnは、Gigabit Home Networkingの略で、HomeGridフォーラム（HGF）によって管理されている有線高速ネット通信技術の統一規格です。国際電気通信連合標準化部門（ITU-T）によって制定されました。G.hnでは、家庭内において、電力ケーブル、同軸ケーブル、電話回線、光ファイバーを用いたネットワークを構築し　（後略）

Bing: G.hnとは、ITU-T（International Telecommunication Union Telecommunication Sector）のHGF（Home Grid Forum）で策定された有線高速ネットワーク通信技術規格です。この技術は、電力線、同軸ケーブル、電話線などの有線ネットワークを使用して、高速で信頼性の高いデータ通信を提供することができます。

まあ、3つとも同様な回答です。特にBardとBingの回答はHGFのメンバーである香港Allion社による解説ページをベースとしているようです。ただ、やっぱりここでもChatGPTが意味があり、ポイントを掴んだ回答をしているように感じます。ですが、本題は次。G.vlcが、G.hnをベースにというか参照して作られているかまで知っているかということ。G.vlc規格書をちゃんと読むと至る所でG.hnを参照しているということが分かりますが、ここまで来ると、文書そのもの以外のWeb上の情報はほとんどないですから、AI力と同時に学習力というか、検索力も必要となる質問です。

Q3: G.vlcがG.hnを参照して作られていることを知っていますか？

ChatGPT: 申し訳ありませんが、私の知識の範囲では、G.vlcがG.hnを参照して作られたという情報はありません。G.vlcとG.hnは、異なるITU-Tの規格であり、それぞれ独自のアプリケーションや使用環境を対象としています。（後略）

Bard: はい、知っています。 G.vlcは、G.hn（G.9960）標準をベースにした高帯域幅可視光通信（VLC）標準です。 G.hnは、既存の電気通信インフラストラクチャ（電話線、電源線、同軸ケーブル）を介して100Mbpsの速度でデータを送信できるホームエリアネットワーク（HAN）規格です。 G.vlcは、G.hnの物理層（PHY）とデータリンク層（DLL）を使用して、可視光を使用してHAN内でデータを送信します。 G.vlcは、高帯域幅、低遅延、高セキュリティの通信が必要なアプリケーションに適したソリューションです。

Bing: はい、G.vlcはG.hnを参照して作られています。

おお！ChatGPTは知らないと答えてきました。むむ、今まで一番優秀だったのに。Bingは通常回答にプラスして、その根拠となるリンクが張られます。で、この回答にもリンクが張られていました。しかし、そのリンク先の資料（ITUの公式資料）を読んでも「参照している」などとはどこにも書いていない。なぜ、「はい」と答えたのか・・・　今回Bardは、他より良い回答を出してきました。確かにG.vlcは物理層とデータリンク層でG.hnのものを使っています。いままで、変な回答が多かったBardですが、ここで検索屋さんの力を発揮、というところでしょうか。

標準規格の中身まで聞いてみる

標準規格ってものは、（ARIB等の日本ローカルなものを除けば）そもそもほとんどが英語で、英語自体は比較的読みやすくはあるものの、文章全体の構成としては極めて読みにくいものが多いです。まあ、読ませるためにあるわけではなく、ルールが書いてある「法律書」みたいなものですから当然なのですが。で、最近のものは技術の進歩からか複雑怪奇で、何かを調べたいにしても、どこの文章に何が書いてあるかすら調べるのが大変。特に、携帯電話の3GPPなんかはそのドキュメントのリストだけでも膨大で開くことすら困難。ウソだと思うなら3GPP公式サイトのこのページを開いてください。リリース別になっていることもあり、リストの行だけで一万行以上もある。中身じゃないですよ？文章のリストだけですよ！　以前も書きましたが、こんなものを全て理解している人間がいるのでしょうか？だって、基地局からコア装置から携帯端末まで全てが網羅され、それどころかこんなもの携帯電話と関係あるの？みたいな内容（例えばVR向け仕様とか）まで含まれ、それら全てを理解している必要があるんだから。少なくとも普通の人間には無理です・・・

でも、きっとAIなら能力的にできるんはずなんですよね。どんな量のドキュメントでも記憶できるし、判断できる。今時の生成系AIにとってみれば3GPPの標準規格なんて、どんな数であろうが大した量じゃない。というわけで、次はAIは規格の中身まで見ているのか？ということを調べてみたいと思います。で、手っ取り早いところでG.vlcやIEEE802.15.13の中身まで理解しているのか？ということを聞いてみます。全然規模の小さいこの標準規格に対して回答ができるのであれば、3GPPとかもっと大きい標準規格にも対応できるはず。三者ともこの光無線通信の規格は知っていると答えていますので、じゃあ中身まで理解しているのか？さっそくスタートです。まずは、ジャブから。

Q4: G.vlcやIEEE802.15.13の内容について理解していますか？

ChatGPT: はい、G.vlcとIEEE 802.15.13の内容について理解しています。 G.vlcは、可視光通信（Visible Light Communication）を使用したデータ通信のためのITU-T（国際電気通信連合 - 電気通信標準化セクタ）の規格です。G.vlcは、光源（LEDや蛍光灯など）を利用してデータを送信し、受信側で光パルスを検出してデータを復元します。この規格では、データ転送速度やモジュレーション方式、エラー制御などの要素が定義されており、可視光スペクトルを利用した効果的な通信手段を提供します。 IEEE 802.15.13は、Wireless Specialty Networks（WSN）の標準化グループであるIEEE 802.15によって定義された規格です。この規格は、可視光通信（VLC）に焦点を当てており、可視光を使用したワイヤレスネットワークのデータ転送に関する仕様を提供します。（後略）

Bard: はい、理解しています。G.vlcは、IEEE 802.15.13標準に基づく、光無線通信技術です。G.vlcは、高速、低遅延、高信頼性を特徴としています。G.vlcは、産業用オートメーション、ビデオ監視、医療機器など、さまざまなアプリケーションに使用できます。 IEEE 802.15.13標準は、2023年5月に公開されました。IEEE 802.15.13標準は、10 Gbpsまでの速度で動作する光無線通信を定義しています。IEEE 802.15.13標準は、産業用オートメーション、ビデオ監視、医療機器など、さまざまなアプリケーションに使用できます。（後略）

Bing: G.vlcとIEEE802.15.13は、光無線通信に関する規格です。IEEE 802.15.13は、最大200メートルの範囲で、静止および移動デバイスの両方に対応するマルチギガビット毎秒の光無線通信（OWC）のためのIEEE承認ドラフト標準です。G.vlcは、可視光通信（VLC）と呼ばれる技術を使用して、高速で安全な無線通信を提供するために設計された規格です。どちらかについて詳しく知りたいことがあれば、お知らせください。

ChatGPTの回答は常識的な範囲でしょうかね。IEEE802.15.13の実情は、未だグダグダしているらしく、予定より何年も遅れているのに正式な発行が未だ遅れておりドラフト状態です。なので、「あまり知らない」というのは理解できる内容です。Bardの方もおおよその内容は似たようなものですが、なんと「IEEE802.15.13が今月公開された」と言っています。なに、私の知らないうちに正式公開されたのか？と公式ページを見てみましたが、それらしき記述はなく・・・でも規格上10Gbpsまで対応を知っているのはGood。Bingは、まあありきたりの内容です。

さて、いよいよ具体的な内容に踏み込みましょう。わかりやすい簡単なものを聞いて、AIが中身まで理解しているか判断します。最初は「サブキャリアの周波数間隔」です。いわゆる1サブキャリアの幅。G.vlcでは、8.2.1.1章に書いてあって、195.3125kHzと定義されています。で、そのサブキャリア数が256個の場合だと、帯域幅は50MHz、512では100MHz、1024では200MHzになります。この値は上限であり、実際に使用する帯域幅というのは機器側で自由に設定できるようになっています。まあ、これはG.hnの規定そのままなんですけどね。で、5GNRのサブキャリア間隔は通常30KHzなので、それに比べるとずっと広い。でも、もともと有線or光無線の規格ですから周波数帯域幅の節約も不要で、ガードインターバル^※3も短くていいので1サブキャリアあたりの帯域幅は広めにとることができるわけです。サブキャリアの帯域幅が広い方がOFDMのFFT^※4が少なくて済み、機器的に安くもできますしね。

前振りが長くなってしまいましたが、それではサブキャリア間隔を各AIに聞いてみます。

Q5: ITU-T G.vlcにおいて、サブキャリアの周波数間隔はいくつですか？

ChatGPT: ITU-T G.vlcにおいて、サブキャリア（Subcarrier）の周波数間隔は、通常は1.25 MHzです。この周波数間隔は、可視光通信（VLC）におけるマルチキャリア変調方式で使用されるディスクリート・フーリエ変換（DFT）を基にしています。 G.vlcでは、通信路の帯域幅やノイズの影響を考慮しながら、1.25 MHzのサブキャリア間隔を使用してデータを変調・送信します。この間隔により、光パルスの周波数スペクトルが効果的に分割され、高速で信頼性のあるデータ通信を実現することができます。（後略）

Bard: G.vlcにおいて、サブキャリアの周波数間隔は195kHzです。これは、G.vlcがOFDM方式を使用しているためです。OFDM方式は、複数の狭帯域信号を重畳して広帯域信号を伝送する方式です。サブキャリアの周波数間隔は、重畳する信号の帯域幅によって決定されます。G.vlcでは、20MHzの帯域幅を使用しているため、サブキャリアの周波数間隔は195kHzになります。

Bing: G.vlcにおいて、サブキャリアの周波数間隔は、312.5kHz間隔になっています1。つまり、312.5、625、937.5……kHzという周波数が使われていくわけです。ご参考になれば幸いです。

いきなり三者三様。ChatGPTは具体的な数値を言ってきませんでしたが、さすがに間隔は一般的には数メガヘルツってことは無いでしょう。1.25MHzって直接拡散のCDMA（KDDIのやつ）の帯域幅ですから。Bardは195KHzという値で正解です。その前の20MHzの帯域幅を使用しているためというのはよく分かりませんが、まあ195kという正解を出しているのでよしとしましょう。Bingは、これWi-Fiのサブキャリア間隔ですよね。なぜかWi-Fiと混同している。やはり、ちょっと難しいのか。もしかして、サブキャリア間隔という混同しやすい聞き方が悪かったのかも。だったら次は、もっとさらにはっきり限定できるように、パラメータの名前とその値を聞く事にしてみます。CNM_TIMEOUTというパラメータです。これは切断までの時間を意味するパラメータでその値は200msecです。つまりは、「接続中」通信が確認できなくなって200msec経つと「切断」のステータスに変更される、というタイマーです。G.vlcはこれに限らず切断を伴うタイムアウト系のパラメータは200msecとされていることが多いです。ですので、ある程度混同していても200msecという答えが返ってくるのではないかと期待して質問してみます。

Q6: ITU-T G.vlcにおいて、CNM_TIMEOUTの値を教えてください。

ChatGPT: 私の知識の範囲では、ITU-T G.vlcにおいてCNM_TIMEOUTという具体的なパラメータや値について言及されている情報はありません。G.vlcは、可視光通信に関する標準化規格であり、通信プロトコルや物理層の仕様、モジュレーション方式などについて定義していますが、CNM_TIMEOUTという特定のパラメータについては触れられていないようです。（後略）

Bard: ITU-T G.vlcにおいて、CNM_TIMEOUTの値は100ミリ秒です。これは、CNMが応答を待つ時間です。CNMが応答を受け取らない場合は、再試行します。

Bing: ITU-T G.vlcにおいて、CNM_TIMEOUTの値は、620であることがわかりました。この値は、チェックポイントが進行中の場合に使用されます。ご参考になれば幸いです。

あー、全滅です。どれもダメですね。ChatGPTは答えてもくれないし、BardとBingは間違った値をだしてくる。Google検索の最上位項目にはちゃんとこの値が載っているドキュメントへのリンクが出てくるのに。Bingは検索からまちがえているから、AIも間違えている模様。前提が間違っているんじゃ仕方ない。

やはり今の生成系AIは事実の列挙は難しいのか？それとも、関連ドキュメントが少なすぎてAIが学習し切れていないのか？ちなみに3GPP関連のパラメータ（例えば超重要なパラメータであるN310）で試したところ、ChatGPT以外はちゃんとした答えがでました。ということはやはりダメな原因は学習不足なのかな？検索エンジンというバックボーンがあるBardとBingの方が、こういった奴は強いんでしょうかね。ちなみに英語でも試しましたが、回答内容はほとんど変わりませんでした。

まとめ

今回、今日本語対応してくれているメジャー3AIを試しました。全体的な感想を言えば、標準規格の内容についてAIに聞くのはまだ早いってことでしょうかね。でも、この結果でなんとなく分かった点もあります。

Open AIのChatGPTは、ざっくりとした答えが得意で、説明も一番正確。しかし、パラメータの値など明確な答えがあるような質問が苦手で、それをわざと答えないような仕様になっている。
- ちなみに、標準規格関連の回答は、GPTのバージョンが上がっても回答内容の正確性が上がるわけではない。むしろ上がった方が回答してくれない場合は多い。（ちなみに、無料はGPT-3.0、GPT-3.5以上は有料です）
GoogleのBardは、ググれば分かるようなことに強い。ChatGPTとBingの中間的性能と言って良いと思う。何の根拠もないような間違った事実をしれっと教えてくることも少なくない。
MicrosoftのBingチャットは回答が短く、中身が不親切な場合が多い。そして、何か別のものと勘違いすることが多い。Bing検索の正確性の低さが、そのままAIにも反映している模様(Bing検索での間違った検索結果表示がそのままAIの検索結果として出されることが多い)。ただし、AIが引用先のリンクを明示してくれるので、真贋の判断を自分でしやすいのは良いところ。

標準規格についてはこのような感じですので、標準規格の調べ物をしたい場合は、いまのところGoogle検索が最もお勧めです。あと何年かしたら、規定してるような明確な事実を答えるのが得意なAIが出てくるでしょう。しかし、残念ながら今のところは自分で標準規格を読んで、自分で判断するしかなさそうです。

最後に、三者とも似ているようで違いは結構ある、というこをは理解しておいた方が良さそうですね。ChatGPTとBingは同じエンジンのはずなのに回答の方針まで違うところを見ると、重要なのはエンジンではなく、学習したものとそれを判断するパラメータなんだろうと思います。言えることは、ググれば分かる単純な数値みたいなやつがとても苦手ということ。三者とも「プロ野球生涯ホームラン数トップ10」という質問に無茶苦茶な答えを出しますからね^※5。と、さも分かったような口を利いてますけど、実際には全然分かっていないのですが！いずれにせよ「生成系AIを活用しないとこれから生きていけない」のは自明ですから、本ブログでは今後もこれら生成系AIの活用法を追求していきたいと思います。

※1; 本部米国。米国、中国、台湾、香港のメーカーや事業者が中心となっている。詳細はこちらから。

※2; OFDMなので、耐マルチパス性としてシンボル長やCP長が重要となるが、光無線通信ではそれらはそこまで重要ではない。

※3; マルチパスの影響を防ぐための時間的なインターバルのことで、Cyclic Prefix（CP）と呼ばれる。

※4; OFDMへ変換する際のIFFT/FFT（離散フーリエ変換）を実行するためには高価な強力な計算機が必要。同じ帯域ならサブキャリア数を少なくした方が、IFFT/FFT回数が少なくて済み機器コストが下がる。

※5;　なお、正解はこちら。Google検索もBing検索も検索結果は一番上はこのページとなっているので正解を探すのは難しくない。