期待のネット新技術
“メタル線で高速通信”国内普及の鍵は技術より「人」か？ データリンクレイヤー「ITU-T G.9961」と今後の展望～G.hnへ至る道（その5・最終回）
2024年9月3日 06:00
集合住宅などでメタル線を使って高速通信を行う技術を取り上げた「G.hnへ至る道」シリーズの最終回となる。前回はG.hnのPhysical Layerである「ITU-T G.9960」をご紹介したので、今回はDataLink Layerの「ITU-T G.9961」のご紹介。といってもDataLink Layer自体はそれほど複雑というわけでもないので、簡単にまとめて説明したい。
APC、LLC、MACの3層構造
図1がG.hnのDataLink Layerの構造図である。最上位がAPC（Application Protocol Convergence）で、ここで上位アプリケーション、というか上位プロトコルの差異を吸収するかたちになる。
アプリケーションから渡される or 送り出すデータのことをADP（Application Data Primitive）と呼び、Applicationに対してADPの送受信を行うと共に、LLC（Logical Link Layer）に対してAPDU（APC Protocol Data Unit）と呼ばれるかたちでAPCをカプセル化したデータの送受信を行うのが主な処理である。
ちなみに、ここに出てくるAEはApplication Entityの略で、要するにAPCへのエントリポイントのことであり、ここでApplicationと通信を行う。また管理I/F（DLL management entry）とAAT（Address Association Table）その他のデータのやり取りも、仕事に入っている。
その下のLLCは、APDUのデータをLPDU（LLC protocol data units）に分割する。いわゆるフレームにデータを分割して格納するイメージだ。この際にLPH（LPDU Header）やCRCも付加されるほか、必要であれば暗号化もここで行うかたちになる。
このLPDUはそのままMACに送り出すほか、逆にMACから受け取ったLPDUを元にAPDUを生成し、APCに送り出すのも当然LLCの仕事である。また管理I/FとLCDU（Link Control Data Unit）と呼ばれる制御パラメータの送受信を行うほか、QoSパラメータの受信を行う。このLLCは、プロトコルにも物理層にも非依存なレイヤである。
一番下がMAC（Media Access Control）で、ここはLPDUをMPDU（MAC Protocol Data Unit）に変換（あるいはその反対）を行うと共に、LLCから渡されたスケジューリング情報をもとに、PMI経由でPHYに対してデータ送信を行う。また受信側ではPMI経由で受信データと併せてPHYのFrame Error Informationの受け取りも行うといった形だ。まあ、比較的一般的な構造だとは言える（APCはちょっと珍しいが）。
そのAPCをもう少しBreakdownしたのが、図2だ。
このAPCは当然ながら上位のアプリケーションというかプロトコルに影響を受けやすい、というか、その上位に対応した構造を取る必要があるのだが、現時点でこのAPCのターゲットとなってるのはEthernetのみである。
実際、ITU-T G.9661を見ると、Annex AにApplication protocol convergence sublayerという節があるのだが、Annex A.1が"Ethernet APC（EAPC）"で、これはいいとして、A.2の"Other types of APC"を見ると一言"Other types of APC are for further study."だったりするあたり、現状のAPC（というか、ITU-T G.9961）はEthernetしか考慮していないように見える。APCもそんなわけで現状は（ある程度汎用的にはなっているものの）基本Ethernetを通すことを第一目標にしているのが判る。
同様にLLCの詳細（図3）を見てみる。
途中に含まれるRelay Functionというのは、要するに受信したフレームをリレーしてそのまま送信するような構図である。これ、普通に考えるとわけが分からないが、前回記事の図2でいうところのRelay nodeを構成する場合に利用できる。Bridgeについては同じく前回記事の図4のように、Applicationの上位にIDB Functionを持つものを用意する必要があるが、同一媒体上で動作するRelayに関しては、LLCの中でその対応が行われるわけだ。
ちなみにEncryptionを掛けた場合と掛けない場合での、フレーム構造の違いが図4となる。
Relay Frameに関しては、そもそもRelay Functionを利用して転送する場合は、受信したフレームを復号化してはいけない"Relayed LLC frames shall not be decrypted."と規定されており、暗号化されたまま受け取って、それをそのまま送り出す格好になる。
MACの詳細が図5になるが、これが一番シンプルで、基本的にはLPDUをベースにMPDUに変換する（あるいはMPDUをLPDUに変換する）のと、送信時にフロー制御を行うだけである。ちなみにLPDUとMPDUの変換のイメージは、図6に示す。
ついでに伝達方式についても少し言及しておきたい。G.hnでは、送信のスケジュール（MAC Cycle）が連続するかたちになるが、このMAC Cycleの内部は複数に分割され、1つ以上の複数のTXOPs（Transmission Opportunities）と1つのMAP（Medium Access Plan） Frameから構成される。これを示したのが図7だ。
このMAP FrameはDomain Masterから送信されるもので、次のMAC Cycleをどの送信ノードが利用するかと、その次のMAC Cycleに含まれるTXOPのリストが含まれている。要するにDomain Masterは毎回、「次はどのNodeが何個TXOPを利用できるか」を明示的に示しており、各Nodeは毎回MAC Cycle内のMAP Frameを参照し、いつ何個TXOPを利用できるのかを判断して、それに合わせて送出を行う格好である。
この個々のTXOPは、それぞれ内部にTIDLEと呼ばれる無送信期間（ITU-T G.9961ではこれをIDG:Inter-Frame Gapと定義している）が設けられている。このIFGの長さに関しては、ITU-T G.9960の方で定められているが、ここでは割愛する。
話を戻すと、個々のTXOPを利用する通信方式には、CFTXOP（Contention-Free Transmission Opportunities）とSTXOP（Shared Transmission Opportunities）の2つがある。CFTXOPの方は、特定の送受信ノード間の通信に利用され、固定の占有時間が保証されるため、QoSを利用しての通信に適した方法である。対してSTXOPの方は1:1の通信だけでなく1:nの、Broadcast的な通信も可能となっている。
1つのSTXOPは複数のTS（Time Slot）で分割され、このTSの単位で通信を切り替えるかたちになる。このTSには、CFTS、CBTSの2種類があり、違いは次のようなものだ。
CFTS（Contention-Free Time Slots）
Domain Masterは連続したCFTSを、多数のNodeにBroadcastを利用して割りあてる。要するに全てのNodeは、自分が何番目に送信可能になるのかを判断できる（というか「自分の前のNodeが誰か」を知っているので、そのNodeが通信を終わったら自分の番であると判断できる）。いわば暗黙のToken Passingとでもいう方式であり、なので送信の衝突は原理的に発生しない。
CBTS（Contention-Based Time Slots）
こちらはCSMA/CARP（Carrier-Sense Multiple Access with Collision Avoidance and Resolution using Priorities）の技法を利用した送信制御が行われる。Ethernetで使われていたCSMA/CDと原理は一緒だが、Collisionが発生しないようPriority制御が加味されている。このCBTSを利用する場合、CBTS back-off ruleとして定められている仕組みを利用することが義務付けられている。
基本はCFTSを利用するかたちであり、CBTSを利用するのはそれほど優先度が高くない（リアルタイム性とか帯域保障への要求がそれほど高くない）通信に限られることになるかと思われる。
結果として、1つのMAC Cycleは、図9のような具合になる。
つまりSTXOPはCFTSのみ、CBTSのみ、及びCFTSとCBTSが混在したものの3種類があり、その合間にCFTXOP（とMAP）が入る格好だ。ちょっと複雑な構成であるが、2018年の記事で ご紹介した、G-PON/GE-PONやその派生型も、考え方としては似たようなものである。
現在のG.hnはHomeGrid Forumが立ち上げたものという話は前々回にあたるその3でも触れたが、ということは当然SmartGridと接続することを前提とした構成を考える必要があり、そうなると、アクセス回線と似たプロトコルにすることで回線の利用効率を高める工夫がなされるのは当然であろう。
欠点は、MACというかDataLink Layerが複雑になるので、プロトコル処理のために回路が複雑になることだが、2000年代頃まではいざしらず2010年代に入ると、こうしたNetwork Controllerのマーケットもプロセス微細化の恩恵で、それなりに複雑な回路を入れてもコストがそう上がらなくなってきた。実際にはプロトコルを全部Hard Wiredで処理するわけではなく、内部にCPUを組み込んでここで処理するかたちになると思われるが、それなりの性能のCPUであってもそうコスト上昇につながらなくなりつつある時期だから、これが可能になったと思われる。
G.hnがまだ求められる環境で、導入の鍵となるのは「人」
ということで、一通りG.hnに至る歴史的経緯と実装技術について簡単にご紹介した。正直に言えば、国内で言うとアクセス回線向けの用途は次第に減りつつある。その1で説明したように、日本ではメタル線を飛び越えて光接続に一気に移行してしまったからだ。
アクセス回線にG.hnを利用している例として筆者が知っているのは長野県の上田ケーブルビジョンであるが、同社は2022年10月より同軸ケーブルから光ケーブルへの移行、を進めており、現状ではかなり広範囲で光化が完了している模様だ。
なので、どこまでG.hnでのサービスが提供され続けるかは不明である。他の事業者で仮にG.hnでサービスを行っているところがあるとしても、多分似たような状況になっているものと思われる。今後使われる可能性としては、Ruijie Networksのインタビュー記事にあるように、既存の集合住宅のVDSL回線の置き換えとかいう話がメインになると思う。
ところが、集合住宅で設備の更新となると、その集合住宅の理事会の承認だけでなく、殆どのケースでは総会決議が必要になる可能性が非常に高い。これがまた手間が掛かる話であって、自主管理でない場合はマンション管理業者も巻き込んでの大騒動となる。
実はこの理事会やら総会やらで、住人の要望やら不満やらを受け止めて決議に持ってくという非技術的な要素が、こうした新しいネットワークを導入する際の最大のネックになっているのが実情である。その1でちょっとCATV業者の話に触れたが、CATV業者はこのあたりのケアが非常に上手いというか、そうした折衝に長けた担当者を派遣して話をまとめることでシェアを伸ばしたという背景がある。
Ruijie Networksが、そうしたことをどの程度まで行えるのか（あるいは、そうした折衝に長けた代理店と契約しているのか）が、日本におけるG.hnの普及の鍵を握っているというのはちょっと情けない話ではあるのだが、実情は実情である。Ruijie Networksの健闘を祈りたい。