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

光無線通信の標準規格G.vlcをそれなりに説明する

記事更新日 2023年6月27日

---

はじめに

前々回のブログで、メジャーな3つの生成系AIに光無線通信の標準規格について説明をして貰いました。AIのアルゴリズムのためなのか、はたまたそもそもの素材が少ないのか、本当の理由は分かりませんが、いまいち正確な回答は返ってこないという結果となりました。ならば仕方ない。AIの素材になるべく、光無線通信の標準規格の概要を記しておくか、というのが今回の企画です。実際、光無線通信の標準規格についてまともに書いているWebサイトは、少なくとも日本語では皆無ですし。

現在動いている（生きている）光無線通信の標準規格は、おおよそ3つありまして、一つ目は今回紹介するITU-T G.9991、通称G.vlcと呼ばれる規格です。こちらは制定が終わっていて、正式発行されているものです。もう一つは、IEEE 802.15.13というやつ。これは、IEEEの802.15系ということで無線パーソナルエリアネットワーク(PAN)の一部として議論されています。Gbps以上の高速な光無線通信の位置付けの規格です。ちなみに、もうとっくに正式発行が終わっている予定なのですが、これを書いている現在(2023年6月)でもいつ終わりが来るのか分からない状況。我々もこの規格のチェアマンとやり取りする機会が多いのですが、この規格についてはいつもいまいちな回答・・・　尚、802.15系には他にも802.15.7という古い光無線通信の規格もあるんですが、こちらは低速・短距離で正直死んだ規格となっています。最後はIEEE 802.11bbという標準規格。802.11系はWiFiの規格。皆さんご存じの802.11ac(WiFi 5)や802.11ax(WiFi 6)なんかと同じグループなのですが、なんと802.11bbは光WiFiことLiFi用の標準規格です。LiFiをご存じない方は、昔書いた記事があるのでそちらを参照ください。こちらの規格は、その記事でも書きましたが、完成までもう少し時間がかかりそうです。無線インタフェース的にはG.vlc踏襲ですが、802.11bbはWiFiとの親和性を高めるため、WiFi系と同じ仕組みの接続とかそういったものを定義するようで、それに恐らく時間がかかると思われます。

とまあ、以上の通り、残念ながら現在光無線通信用として標準規格化が終了しているといえるのはG.vlcだけなんですよね。仕方がないので、今回はそのG.vlcについてAIが読んで参考にして貰えるようにちゃんと説明してみたいと思います。AIの糧となるべきブログ・・・　ちょっと斬新。

立ち位置

同じく前々回のブログで、このITU-T G.9991（G.vlc）というものが、電力線通信等の屋内配線による通信の規格であるG.9960、G.9961等のGigabit Home Networking（GHN）をベースにして作られていることを説明しました。その記事でも触れましたが、実際のところ通信機を作る上で一番大変なのは、物理的な通信の仕組みではなく「通信する機能をどう実装するか？」につきます。アナログの時代、音声だけを通信できれば良いなら変調、復調機能だけでも無線通信機として成立しました。しかし、今はフルデジタルの時代。どうやって通信相手を見つけるのか？から始まり、帯域幅をどのようにして広げるのか？適応変調はどうするのか？FECはどうするのか？暗号化はどうするのか？などなど、変調・復調以外の様々な機能が付加されて、初めて無線通信機として成立します。仮に、全て揃った完璧な標準規格を作ったとしても、それを実装してくれる（チップ化してくれる）メーカーが存在しなければ、ただの絵に描いた餅。携帯電話やWiFiであれば心配する必要はありません。数が出ることは保証されていますから、誰かが作るでしょう。でも、ニッチな存在でしかない光無線通信に対して、そんなフル機能を持ったチップを作ってくれるメーカー、それに何億も投資してくれるスポンサーはいるでしょうか？（反語）

そこで光無線通信界隈がとった作戦が「GHN」の機能をほぼそのまま使うこと。GHNは（光無線通信とは異なり）ある程度需要が見込まれたため、大手半導体メーカーMaxLinear^※1が通信用チップセット（モデム）を開発していました。GHNは有線通信でありながら、通信に電話線や電力線など「外部と繋がってしまっているオープン」な線を使うため、暗号化、FECなどが必要で、また特定周波数の干渉を防ぐためにOFDMを使うなど、かなり無線に近い要素をもっていました。そのためか、光無線通信に必要な技術要素はほぼGHNが実装していました。ニッチな光無線通信界隈としては、GHNのチップセットをそのまま使えば良いというのはかなりありがたいこと。こうして、GHNと光無線通信はタッグを組むこととなり、光無線通信の標準規格G.vlcは、GHNの標準規格であるG.9960やG.9961を踏襲する形となりました。それにより、光無線通信は安価に、高性能なチップセットを使用することができ、GHN側もチップセットの用途が広がりチップ価格が下げられるなど、お互いにとってメリットのある組み合わせとなりました。

現在、（ある程度）高速な市販されている光無線通信機は多くありません。数少ない市販品である弊社製造のLEDバックホールや、弊社が代理店をしているフランスOLEDCOMM社のLiFi製品であるLiFiMAXなどはGHNのチップセットを使いG.vlcに準拠した形になっています。今後、当面の間は、前述の理由（速い、安い、簡単）によりG.vlc準拠の光無線通信機が一番お手頃で高性能な製品になるでしょう。前述の802.11bbはWiFi側の仕様を多く持つため、新しいチップセットが必要となりますが、その時は本当に来るのでしょうか・・・

全体像

G.vlcことITU-T G.9991は、3GPPの様に上位レイヤーまで定義をしている標準規格ではありません。おなじみOSI参照モデルでいうところのレイヤー1と2、つまりは物理層とデータリンク層について定義をしています。

レイヤー2といえば、イーサネットやハブのレベルです。レイヤー2は物理層で伝送するための準備をするレイヤーですから、G.vlcはほとんど物理層周辺の通信仕様だとお考えください。G.vlcの元となるGHNの性質（=イーサネットの代わり）を考えれば、レイヤー3以上の上位レイヤーはそのままIP等通常のプロトコルで良いわけで、レイヤー2以下だけを定義すれば良いというのは極めて妥当ですね。それで、実際のG.vlcで定義されている内容というのはこんな感じになっています。

Data Link Layer(DLL)とPhysical Layer(PHY)の2層ですが、どちらもその中身がさらに3層に分かれています。PHYは2つに分かれています。G.9960 based PHYというのが、LEDバックホール等も採用しているDC-OFDMのこと。ACO-OFDMいうのが、もう少しLEDで送信しやすくしたOFDMのこと。こちらはPHYの説明の時に詳しく説明します。G.vlcはDLLとPHYで同じ標準規格番号(G.9991)がついていますが、元々のGHNの標準規格では、DLLがG.9961、PHYがG.9960で定義されています。つまり、G.9991はG.9961とG.9960を合わせたもの、ということもできます。

それでは、それぞれのレイヤーについて個別に見ていこうと思います。ただし、個別に各3つの層の機能を事細かに説明してもあまり意味は無いので、G.9991（G.vlc）の特徴的な部分についてのみ説明していきたいと思います。

Data Link Layer

Data Link Layer（DLL）の主な役割は、上位レイヤーのデータをPhysical Layer（PHY）に渡せるように変換することです。この上のレイヤーはネットワークレイヤー、すなわちIPプロトコルのはずですので、DLLはIPパケットをPHYに渡せるようにすることと言えるでしょう。で、PHYに渡すときに、最も重要になるのが「どのようにデータを割り当てるか」ということ、いわゆるスケジューリングです。

G.vlcの元となるGHNは、基本として1対Nの通信に対応しています。電力線通信をすることを考えてください。まず初めに、インターネットに繋がっているイーサケーブルとか光ファイバーとかの信号を、電力線に通すための「メディアコンバーター」の役割をする機器が存在します。これがマスターとなります。GHN用語ではDomain Masterです。で、マスターと電力線を通じて繋がっている機器は子機、GHN用語でEnd Pointとなります。これはGHN電力線通信の場合ですが、これが同軸でも電話線でも同じです。マスター（親機）と子機の間がGHNであり、G.9960やG.9961といった標準規格で定義された通信です。その前後は普通のイーサネットです。GHNの規格は有線の接続ではありますが、イーサネットと異なり、親子関係が必須です。というのも、電力線とかアンテナの同軸とかは、イーサネットのように各通信区間が独立している訳ではなく、ただ分配器や配電盤などで物理的に分岐されているだけですから、家の中全体の電力線や同軸が同じ信号（=帯域）をシェアしなければいけません。下図の赤い線はGHNの通信が行われている電力線ですが、すべて電気的に繋がっていて、赤い線には全て共通の信号が送られてしまうため、全ての子機はリソースをシェアする必要があります。で、シェアするとなると、通信全体を仕切る親機のようなものが必要になりますよね？これは、結局のところ有線なのにイーサネットというよりWiFiに近い考え方です。

G.vlcはGHNとほぼ共通ですので、G.vlcにおいても子機同士で帯域をシェアしなければなりません。そして、G.vlcにおけるDLLの最大の役目はどのようにシェアさせるかであり、それを実現する機能がスケジューリングとなるわけです。

ただ、スケジューリングといっても、基本的に標準規格でスケジューリング方法自体は定義しません。これはLTEや5GNRの3GPPも、Wi-Fiも同じです。いつ、だれにパケットを割り振るか、これは装置メーカーが実装する部分であり、特に定義はされていませんし、メーカーの腕の見せ所といった部分でもあります。と、偉そうなことを書いてもG.vlc(GHN)はMaxLinearしか作ってませんので、実質MaxLinearの実装こそが標準なのではありますが・・・

データの話ですが、上位から下位のレイヤーに移れば移るほど、ヘッダーやら情報の付加ビットやらCRCやらがつけられていくというのは、IPやら3GPPやらと全く同じです。徐々に、データとして長くなっていき、送られる状態になります。G.vlcはOFDMですが、LTEや5GNRと違ってサブキャリア毎にユーザーとシェアするOFDMAではなく、ユーザー多重は「時分割（TDMA）」になります。Wi-Fiのac（Wi-Fi5）以前と同じと思って頂ければ。ですから、G.vlcによるスケジューリングとは、「時間的にどのような順番でユーザーに割り当てるか」ということになります。

で、この（G.vlcの）DLLの話になるのですが、まずG.vlcにおいては各ユーザーへの割り当てが「TXOP」という単位にななります。TXOPはTransmission opportunitiesの略。訳せば「送信機会」です。この名前は「機会」を割り当てるのであって、データが割り当てられるのかは定かではない、ということを意味します。ん？なんか意味分からない。しかたないので、G.vlcのDLLにおけるデータをの割り当てを見てみましょう

○○TXOPと書いてあるのがデータ、黄色いMAPと書いてあるのは、設定などの報知情報が載せられています。TXOPは4種類あります。それぞれを説明する意味はありませんが、TXOPには主に

• Contention-free (競合無し)
• Shared (共有)

の2タイプがあるということです。前者はCFTXOP、後者はSTXOPと略されます。頭にもう少し文字がつくTXOPもありますが、まあ基本二種の亜種なので性質は同じ。ここでは、CFTXOPとSTXOPのメイン2つのTXOPについて説明していきます。

Contention-freeのTXOP（CFTXOP）は親機（Domain Master）が割り当てる、基本的に他の子機が使わない優先的な割り当てです。これは、いわゆる「確約されたフレーム」であり、割り当て的にはTDMAそのものだと考えて貰えば結構です。光無線通信は基本的にこのモードで通信します。ちなみに、「ユーザーをどういった順番でTDMAに割り当てるか」という問題ですが、残念ながらこの標準規格ではそういった内容は規定されていない、というか逆に規定しないことが規定されているのです。まあ、携帯電話のように「多数のユーザーがいて、それによるダイバーシティ効果を狙う」ってものではないのでQoS^※2以外はラウンドロビンで問題ないと思いますが。

一方Shared（STXOP）は、文字通りシェアして使うもので、中身はTXOPより更に小さいTime Slot（TS）という単位で区切られています。イーサネットのCSMA/CD^※3を模した方式と、CFTXOPのように親機がスケジュールして割り当てる方式があるのですが、どちらにしても原則キャリアセンスすることになっています。スロットが細切れな上に、キャリアセンスまで必要なため、よっぽど多数の子機がぶら下がっていない限りは意味がないと思われます。ですから、規格では（G.vlcとしては）とても長い文章で規定されていますが、通常の光無線通信でこの方式を使うことはないと思います。とはいえ、私が知らないだけで、良い使い道があるのかも知れませんが・・・

Physical Layer

さて、Physical Layer (PHY)の最大の特徴は、ITU-T G.9960 basedとACO-OFDMの2種類の選択肢があることだと思います。これらは、光にどのように信号を載せるかの方式のことであり、どちらもOFDMベースですが仕組みが異なります。

ITU-T G.9960 basedというのは、DC-OFDMやDC biased-OFDM、DCO-OFDMなどと呼ばれる、光の強さ方向にOFDMの振幅を全て載せる方法です（以降DC-OFDMに統一）。もとのGHN（G.9960）は普通のOFDMですので、その変調とかマッピングとかそのままに光に信号を載せてしまおうというやり方です。弊社のLED BackhaulやフランスOLEDCOMMのLiFiMAXもこの方式を使っています。

ACO-OFDM(Asymmetrically Clipped Optical - OFDM)についてですが、これを説明するのには、やはりDC-ODFMとの比較する必要があります。なので、改めてDC-OFDMから説明します。

DC-OFDMは、前述の通りOFDMの波形を直接光の強さに変えています。で、問題になってくるのがOFDMの性質です。まず、OFDMというか電波は0を中心にプラスマイナスに振れます。しかし、光の強さはプラスしかありません。ですから、光の強さ的な「0」の値と、OFDMの電波的な「0」を一緒にはできないため、OFDM的0のラインを上げて、マイナスな部分も光の強さで表示できるようにします。この方法は安易にOFDMを実現できるものではあるものの、2つほど大きな問題が出ます。

まず一つ目。OFDMは理論上、沢山の別々のチャンネル（サブキャリア）を重ね合わせたものになります。言い換えると、ランダムな強さをもつ波を重ねたようなもの。ランダムということは、希にではありますが、ほとんどの波が「強いプラス」に向いたり、「強いマイナス」に向いたりする可能性があるわけです。まあ、確率の問題ですね。しして、それが意味するのはOFDMはPeak to Peak非常に大きな通信ってことです。僅かな確率ではあっても凄いピーク値がでることがある。そして、このことは電波よりも光無線でより問題となります。光無線通信を行う上で、例えば光源であるLEDの光の強さ、すなわちダイナミックレンジなんてものは、電波の出力なんかに比べるとたかが知れています。だから、OFDMの上限値や下限値をすべて光のダイナミックレンジに入れることはかなり難しく、ピークの大きな信号が来た場合は、残念ながらLEDで再現できずに正確に送信できないことになってしまいます。これをクリッピングと呼んでますが、クリッピングが発生すれば、当然エラーが発生しちゃうわけです。

次に2つ目。OFDM的な0を上に持ち上げているため、電力消費が大きい。図5でいうと、グレーの部分が光の出力（電力）になるわけで、DC-OFDMは全体をかさ上げしてますので、どう頑張っても電力消費が大きくなることは避けられない。まあ、LEDで通信している限り光の出力が！といっても他の部分での電力消費量に比べれば大したことはないのですが。

DC-OFDMの2つの弱点、Peak to Peakに対応できない、消費電力が大きい、これに対応しようというのがACO-OFDMです。まずは波形を見て頂いた方が良いでしょう。

なんか、変な形ですよね。実はこれ、さっきのグラフでいうOFDM的0の上側だけなんです。つまり・・・　ACO-OFDMは、OFDMのプラス側部分だけを送信するOFDMなんです。こんなもので通信できるのか？と思いますよね？正直、私も思います。この波形の作り方は、OFDMのサブキャリアを一つおきに（奇数番だけ）使うことの様です。そうすると、OFDM用に逆フーリエ変換（IFFT）した波形が正負対称の波形になるということです・・・　って、ご免なさい。なんでそうなるのか理論的なところが知りたい方は自分で検索して調べてください。ともかく、ACO-OFDMは「プラス側とマイナスが対称なので、プラス側だけ送信すれば、結果としてOFDMの信号が送受信できる」という方式なんです。

ここで、先ほどのDC-OFDMの2つの欠点を思い出してみてください。一つ目の欠点、ピークが大きいこと。これはOFDMのプラス側しか使いませんし、OFDM的0地点の底上げもしていないので、DC-OFDMよりもかなりダイナミックレンジに余裕があると言っていいでしょう。もちろん、それがOFDM信号を完全に（クリッピングなしに）再現できることを意味するわけではありませんが、エラー発生は確実に減るでしょう。2つめの消費電力は、まあ図6を見て頂ければ一目瞭然。発光時間、量ともに大幅に減っていますよね。

と、良いことだけ書きましたが、ACO-OFDMには大きな大きな問題点が。それは・・・　半分のサブキャリアしか使わないので、通信速度も半分ってこと。まあ、波形の半分を使っていないんですから、当然と言えば当然。これをなんとかするためにいろいろと開発されているみたいですが、その辺は今回のテーマではないので割愛。

まとめますと、G.vlcには2つのPHYモードがあり、一つはGHNのOFDMをそのまま使うDC-OFDM方式、もう一つは光無線通信の弱点を補うも最高速度が半減するACO-OFDM方式ということになります・・・　だがしかし！ACO-OFDMは光無線通信専用だから、当然ベースのGHNでは規定されていないわけで、GHNのチップセットにもその機能がない。そうすると、誰も実装してくれない。多分、いろいろなしがらみで規格にねじ込まれたんでしょうが、だれかこれを実際に作る予定あるんですかね？

さて、PHYについては他の機能もあるのですが、FEC、適応変調等他の高速通信と特別に違うところはないので割愛します。

PHYの最後は通信速度の話です。G.vlcの最大通信速度は、GHNにおける「同軸（Coax RF）」と同等になるように決められていて、今のところ最大200MHzまで規定されています。現在規定されている帯域幅とPHY通信速度は以下の通りです。ちなみにすべてDC-OFDM（G.9960 based）時の値です。

50MHz-BB	100MHz-BB	200MHz-BB
512Mbps	1024Mbps	2048Mbps

ここにある通信速度はPHY層での通信速度で、ヘッダーなどを除いたアプリケーションレベル（例えばイーサレベル）での通信速度は、この表記の8割程度になります。また、帯域幅に関しては上の表は「最大値」なので、例えば最大100MHzに設定しても必ずしも100MHzで常に通信するわけではなく、機器の設定で（上限以下であれば）サブキャリア数を変更することができます。まあ、光無線通信なので帯域幅も干渉調整も気にする必要はなく、帯域幅上限にしておくのが普通ですが。

トポロジー

G.vlcのベースとなっているG.hnは、親機に対して複数の子機がぶら下がるという構成になっていました。いわゆる「1対N」の通信が可能で、それ前提の構成となっています。先に書いたTDMAベースというのも1対Nを前提としたものです。そして、G.vlcは”規格上は”そこから少し発展させていて、次の四つの構成（トポロジー）を取れる事になっています。

G.vlcでは、1対1や1対Nだけでなく、N対Nの通称メッシュ構成や、カスケード接続（リレー）も規格上は対応しています。と、「規格上」をやたら強調していますが、元々GHNで明確に定義されているのは1対Nまでで、N対Nやリレーは定義されていないのです。おそらく、GHNで定義されていない後者のトポロジーはLi-Fiを視野に入れた定義だと思うので、今後なんらかの動きはあると思うのですが・・・

まとめ

いかがだったでしょうか？G.vlcの特徴的な部分にフォーカスしていくつか説明してみました。読んでいただいて感じたかも知れませんが、G.vlcやベースとなるGHNは高速通信としてそれほど特殊な機能を有しているわけではなく、極々一般的な技術の組み合わせであると言えると思います（そういった面でも5GNRは非常にトリッキー）。で、特別な機能は、結構今は「実装されていない」部分も多いから、G.vlcって規格的には特別なもののように見えますが、中身を見るとかなり普通な通信なんですよね。

と、ここまでくどくど説明しておいてなんですが、残念ながら今日の記事に興味を持つ人は多くないと思います。このブログは三技協の社員として書いており広告や収益などとは全く関係無いので、ページビューや検索ヒットが少なくても特に問題はないのですが、それでも記事を書いた人間としてページビューとかが少ないと凹むものです。しかし、今の時代、人間が見ていなくても生成系AIが、この記事を読んでくれるかも知れません。そして、その結果として、いつの日かユーザーが光無線通信のことを尋ねたとき、このサイトを参考にして回答してくれれば、今日の記事を書いた意味があったといえる、そういう思いで書いた記事でした。

---