───まず、2014年から今に至るまでの研究の流れを教えてください。

丸山教授（以下、丸山）：私の前職はNTTだったのですが、2012年に今の大学に着任しまして、2014年にたまたま8Kカメラを使わせていただけるという事で、「8K非圧縮映像"さっぽろ雪まつり"の超高速伝送実験」として8K映像伝送に着手したのが最初です。その時は8Kディスプレイがなかったので、4Kディスプレイのベゼルを剝がしたものを4面繋げて「なんちゃって8K」と称していました。

その次の年、2015年2月に「8K非圧縮映像“さっぽろ雪まつり”の超広帯域IPマルチキャスト伝送実験^*1」で映像サーバをStarBEDで構築しました。その頃には、アクティビティが認められてSHARP様から当時1500万円する8Kディスプレイ^*2をお借りする事ができました。

映像サーバの増強や、暗号化伝送や様々な事をやったあとでネットワーク上での映像処理に着手しました。最初のプロトタイプはハードウェアを組み合わせたものでコンセプトモデルを作りました。当時は100Gbpsのネットワーク帯域しかなかったので、非圧縮の24Gbpsを扱うのに複数のパスに分けてマルチレーン伝送していました。しかし、これはこっちのパス、半分はあっちのパス、といったようにすると、どうしても伝送遅延差が出てしまいます。かつ処理を挟むと処理速度によって更に差が広がります。ここを合わせないと綺麗に画面が出ないということで着手したのがDPDK^*3を使った遅延補正装置です。

24Gbpsを扱うためにはDPDKが向いているという話を、当時NTT未来ねっと研究所でLagopus（ラゴパス）^*4を開発していた中島さん（現在: NTTドコモネットワーク開発部 中島佳宏氏）から伺い、実際に使ってみたところ性能が出ることを実感したのがきっかけです。そして、DPDKを用いた映像処理機能を色々と開発していくと同時に、映像機能間の接続のためにSRv6^*5の適用が始まったという流れです。

元々NTT時代の最後の頃に、君山先生や瀬林先生と共にi-Visto（アイビスト）^*6という非圧縮映像をIPで送るプロジェクトに取り組んでいました。この際に開発した4K対応の端末装置があり、それをタンデムで並べて8K化したのが我々の出発点です。

その後は48Gbpsの帯域を持つフル解像度8Kが東京オリンピックを契機に主流となり、我々も使わせていただいています。将来的には144Gbps⾮圧縮のフルスペック8Kをやってみたいと考えています。商用網の帯域としては400Gbpsを利用して、現在サブテラビットである800Gbpsが処理可能なエッジ装置の開発を⽬指し、さらなる上限を追及しています。

───ついにテラビットを超えてきているのですね！そこに至るまでにも、デジタル化、HD、FHD、4Kと時代ごとの課題があったかと思いますが、共通点はありましたか？。

丸山：回線速度とリンクしていた気がします。元々、レイヤー2のプロトコルの研究をしていて、2.4Gbpsのスイッチやカードを作っていた頃に、HDの1.5Gbpsに出会いました。当時の朝日放送さんの局舎を見せて頂いた際、同軸ケーブルで一杯だった状況を見て光IP化への移行をアドバイスしました。JGNは当時10Gbpsの回線だったと思います。

放送屋さんの間ではIPはまだ使えないという意見が大半だったのですが、朝日放送の当時の技師長だった香取さん（朝日放送 最高技術顧問 香取啓志氏）がIP推進派で意見が合い、次世代に向けていろいろ活動しました。それがちょうど松坂大輔がレッドソックスに入ったころの話です。レッドソックス本拠地のフェンウェイ球場からの中継は費用が高いというので、球場が見渡せる隣のビルをお借りしてそこからファイバーを張って放送局の局舎まで伝送したという思い出があります^*7。

IPは使えないという意見もそこから何年か活動をしている内に変化して行きました。ようやく現在は、本線部分のIP化が進展してきており、20年前に思い描いていたものが現実になったなと思っています。そこら辺の実用化をやっていたのが君山先生だったりします。何か一言ありますか？

君山教授（以下、君山）：そうですね。当時、20年くらい前は映像をIPで送るなんてとんでもないっていう話を色んなところにされましたけど、今はもうね、IPIP……。早すぎましたね、我々。

───そんなにも早くから現在の業界の標準を考えていらしていたのですね…！そこに研究が役立ってきた、と。では、現時点での研究が目指しているところをお聞きしたいです。

目指す世界の背景としては、Beyond5Gの端末が普及することで高精細映像の利用シーンが拡大していること、特に8Kは人間の視野の限界であると言われていますので、それがあれば没入感や臨場感が出るんじゃないかというところから始まっています。8Kディスプレイが安くなりましたので利用可能なシーンの拡大も見込んでいます。それと、我々はリアルタイムにこだわっていまして、特にライブ配信としてスポーツイベントやe-sports、遠隔授業などの様々なイベントで使えるようなシステムにしたいと考えています。

8Kの高精細映像のリアルタイム映像処理を行うには、現状では専用装置で構成されたローカルの拠点を用意する必要があります。この8Kの最終映像編集はあまりにコストが高く、そう簡単に手に入らないという地方局の方の声もうかがいまして、クラウドをうまく利用したいというのがモチベーションになっています。

ただ、クラウドはご存じのように遅延などの不安定さがあります。そこで、やはり端末-エッジ-クラウドを連携させた形のアーキテクチャが必要です。それとともに映像編集以外に配信系を考えなくてはいけません。様々な回線速度、端末に応じて低遅延で配信する必要性がありますので、ハイエンドから配信系まですべてをやりましょうということで提案しております。

───8Kのリアルタイム映像処理・配信について、現在はNICTの委託研究に取り組んでいらっしゃるそうですね。

丸山：NICT委託研究「高臨場感通信環境実現のための 広帯域・低遅延リアルタイム配信処理 プラットフォームの研究開発」^*8として、高周波数帯Beyond 5G端末の広帯域・低遅延データ転送機能と、網上のエッジコンピューティングやクラウドなど様々なコンピューティングリソースを協調連携させた高臨場感通信環境の研究開発を進めています。

高周波数帯のB5Gの端末というのは非常に広帯域で、かつ低遅延のデータができますが、それを支えるエッジ側、クラウド側の処理能力もかなり高速になる必要があるため、B5Gの高速無線アクセス帯域が実現できた際に必要となるエッジやクラウドの処理速度の向上を狙ったアーキテクチャの研究を実証的に行っています。

最終的にはせっかく今後広まる技術で8Kがあるのだから8Kをやりましょうということで、誰もが8K高精細映像をはじめとする10Gbpsを超える高精細映像を使った高臨場感通信ができる環境を目指して、8K超高精細映像のライブ映像編集をネットワーク上で行ったり、様々な回線速度・端末種類に対して低遅延で配信したりするシステムを開発しています。

───今日は4人の皆さまにご参加いただいております。NICTの委託研究ではそれぞれどのような役割を演じていますか。

丸山：神奈川工科大学とミハル通信がサブTbpsを目指そうということで「（研究開発項目1）サブTbpsの高精細映像処理が可能な低遅延大容量通信処理プラットフォーム技術の実現」を担務して、高速映像処理機能を実現できるプラットフォーム技術を開発しています。

また、大同大学と琉球大学が「（研究開発項目2）多地点間での高臨場感通信を実現する低遅延配信技術の実現」を担務しています。主に映像の制作系を神奈川工科大学とミハル通信が担当し、配信系の方を大同大学と琉球大学がコンビになってやっています。

研究開発項目

拡大

琉球大学の方ではもう少し新しい圧縮方式の提案なども入っていまして、面白い研究成果が出ている状態です。ミハル通信は、もともと低遅延配信のためのELL8Kというシステムを持っていまして、それもせっかくあるのですから、このプロジェクトの一環として使いましょうということで配信系の低遅延の部分はミハルさんのELL8Kシリーズを使って、相互でつないでアプリケーション実験を行っている状況です。

───神奈川工科大学・ミハル通信が中心となって取り組んでいる「研究開発項目1：サブTbpsの高精細映像処理が可能な低遅延大容量通信処理プラットフォーム技術の実現」について聞かせてください。番組制作環境が実現されるとどのようになるのか知りたいです。

丸山：誰でも8K YouTuberと言っておりますが、一般の方やプロの方でもノート端末しかない状況で、高精細な映像が制作できる時代がくると思っています。それを支えるB5Gのアクセス回線を含めてそれに寄与できればと思っています。特に時間がかかるレンダリングを裏でエッジ装置がハンドリングしてくれて、ネットワーク上の莫大なコンピューティングリソースのサポートを受けられると本当に便利です。

現在実験で使用しているエッジ装置の概念図

拡大

───高精細映像処理にはエッジやクラウドの使い分け、遅延調節、大量のパケットの監視など様々な技術的課題があると思いますが、それについてお聞かせください。

丸山：エッジとクラウドの使い分けについてですが、当初はクラウドのコンピューティングの力を借りれば良いと思っていましたが、様々な方と共同利用するためにデッドラインスケジューリング^*10が困難であるため、よりユーザに近いエッジが中心で高速処理を行い、クラウドはバックグランドでアシストするほうが良いと思っています。特に映像の場合は、同期が重要となりますので、クラウド、エッジ、端末で実現できる同期タイミングを分けて考えております。映像の世界ではフレーム単位の同期とか、ライン単位の同期とか、そういったことを考えなくてはならないのですが、同期タイミングを協調することでより低遅延な世界が作れるのではないかと思っています。 遅延調節についてはマルチレーン伝送で大容量映像配信を行っているため特に気を使っています。つまり、48Gbpsを複数のストリームに分けて、処理と伝送を行います。その際、処理遅延差や伝送遅延差が生じるため、それを合わせてから表示装置に入力させる必要があります。そのため、ネットワーク上のパケットの遅延差を見て、遅延補正装置で処理をしています。

遅延補正装置は単に遅いところに合わせるだけですので、バッファがあればいくらでも延ばせるのですが、最大で15秒ぐらいまでは遅延補正ができるようにしています。今後SMPTE^*11の規格への準拠が重要だと思っていますが、48Gbpsエッジストリームも定義されておりますので相互変換についても開発して行こうと思っています。

パケットの監視については、パケットのヘッダ部分だけを抜き出す事によって、情報量を減らして処理しています。そのヘッダもレイヤー2以上、レイヤー7までのヘッダが重要であると思っていまして、そこを抜き出して処理しようということです。

100Gbpsの回線でもヘッダ部分だけにすれば10Gbpsが1本か2本くらいの量になると思います。ただ、小さいパケットが多量にくる事と同様になるので、こちらもDPDKを使って解析処理をしています。モニター装置は、当初パケット量だけを見ていたのですが、これでは満足できずに、RTP^*12のシーケンス番号を確認する事で、パケットの抜けやリオーダという順序逆転、ジッタなどの特性を確認しています。

アプリケーションが回線帯域に対して、かなりの割合を占めるので、ジッタには特に気を使います。例えば回線帯域100Gbpsに対して24Gbpsや48Gbpsを占めることになるわけです。そのため、ネットワークのリソース監視を同時にしないと安定運用ができません。ジッタ-センシティブになるとマイクロバーストといって一時的に回線速度の限界を超えてしまう事があり、バッファで持ちこたえられないとパケットロスが発生します。長期的には安定して見えても、短期的には回線帯域を溢れてしまう場合があるので、それを発見するのにもこのモニター装置が大変有効です。

モニターで異常を検知した場合、パスの再割り当てで対応しようと思っています。ある程度はFEC^*13で耐えてもらって、それでも駄目そうなときは別パスに切り替える運用です。

トラフィックやストリームは常に監視されている

拡大

問題が起こったときのトラフィック情報。
ほとんどデータが流れていないことがわかる（一般回線程度に流れている）

拡大

───高精細の映像編集において必要な機能とは、それぞれどのようなものなのでしょうか。

丸山：映像編集に必要な機能を我々はVVF^*14と呼んでいますが、このVVFはDPDKを用いる事によって、Over 10Gbpsの速度域を扱えるようになりました。DPDKを使わなければ実時間で処理できなかったと思います。また、IntelのSIMD^*16命令であるAVX-512^*16等により、高速にペイロードを加工しています。処理の中で、ペイロード部分を触る処理と触らない処理に分かれます。

VVFの概念図

拡大

先ほどお話しした遅延調整は、単なるバッファリングですのでペイロードは特に見ておりません。スイッチングも差し替えだけですのでペイロードは見ていません。色調整（カラーコレクティング）は、複数のカメラで撮影した場合に、カメラの色温度^*17の差を調整する機能です。

こちらはペイロードの中身を見て、AVXで処理して調整しています。フル解像度8Kは、YUV422^*18という色差信号を使った間引きを行って、48Gbpsにしています。これをRGBに直して、その空間上で色調整をしています。トランスコーディング^*19は、複数の8K非圧縮間（8K デュアルグリーン^*20とフル解像度 8K）の相互変換を行います。

合成機能としては、キャプション挿入を実現しています。また、最近では、8Kの映像の中の一部を切り出す処理を行っています。

───スイッチングの処理はどのように行っているのでしょうか。映像が切り替わる際に遅れや黒フレームが入らないための工夫を教えて下さい。

丸山：VVFのスイッチング処理機能は複数のストリームの中から、マスターの映像を決める方式でやっています。ネットワークを流れるデータを使ってどうすれば簡易的にできるかを考えた結果、特定のフローをマスターにして、そのペイロード部分だけを他のストリームの内容に置き換える方式で実現しました。

つまり端末には継続的に、マスターの映像を流しっぱなしにしております。切り替えたときには、2番目の映像のペイロード部分だけをマスターの受ける部分と差し替えます。すると、受信端末にとってはシーケンス番号もそのままのパケットとして処理できますので、セッションも切れずに扱う事ができます。中身だけすり替わっているというような設計です。

　1フレーム以下とかそんなものではなく、数百µsぐらいでも簡単に切り替えができます。通常スイッチャーは24Gbpsなら24Gbps×Ｎ回線分を入力するのですが、ネットワーク上でやってしまえば中継地点までトラフィックの集約ができます。切り替えた後の映像だけ送れば良いわけです。もちろん現場の運⽤としては全回線分のプロキシ映像^*21を⾒ながらモニターを切り替えるといったオペレーションを想定しています。

映像をスイッチングするブース

拡大

手元の操作系は簡単なもので可能となっている。
処理はほとんどエッジ/クラウド上で行われている。

拡大

───パケットだけは一連のものとして中身だけすり替えているのですね！ちなみになのですが、映像において要求される低遅延、とは具体的に何ミリ秒程度までを指すものなのでしょうか。

丸山：アプリケーションによりますが、映像の世界では、3フレーム以内に処理などと言われています。これは、おそらく以前1フレームが33msだった時代に100ms以内に抑えるという事だと思います。ターゲットタイムは、1フレーム以下です。（16.7ms）

テレビで遠隔地の掛け合いなどをするシーンがありますが、これもアナウンサーさんからは、100ms以内なら自然な掛け合いができる。それ以降は原稿を早めに読み始めるなどのテクニックを使うと教わりました。ただ、最近のテレビ中継を見ていると、あまりに遅延があり、ぎくしゃくする感じがありますね。

あと、もしロボットアームで遠隔手術をやるなら数msにしてくださいと言われています。遠隔診断なら1秒あっても大丈夫と言われていますが、術野を見てアドバイスする場合には、100ms以下ぐらいが必要と思います。また、建設業界の遠隔操作やドローン操作は、10数ms以下と言われています。対面授業などは、100ms以内なら、横に先生がいるような感覚になると思います。相手の音を聞きながら演奏するスタイルでは、20ms以下で実現できます。

加藤：去年の11月のInter BEE^*22では、幕張の会場と、そこから離れた遠隔地点で楽器を同時演奏でセッションするという実演^*23をやりました。今までは映像に音声を乗せたエンベデッドオーディオで同期をとるという形でずっとやってきたのですが、これだとどうしても音声の方が遅れてしまいます。

同時演奏をする上では、音声が低遅延で来ることの方が重要で、極端な話音声さえ来てしまえばなんとかなってしまうということが分かっています。そこで今回の実験では、まず音声を届けて、そのあとに映像を届けるということで音声は往復20ms、映像は100ms程度でやりました。 これくらい低遅延になってくると、わざわざAVの同期をとる必要がありません。更に音声はビットパーフェクトでそのまま高音質な音声を相手のところに届けて、届けた先で加工して再生するという手法を使っています。演者の方達からは全く違和感がないということでした。

一昨年に東京国際展示場で行った「4K・8K 映像技術展」では、大阪とのやり取りで、回線が混んでいない時間帯に数msで通信できたことがあって、それを聞いたミュージシャンの方からはステージの端から端までよりも速いように聞こえるとのご意見を頂きました。

遠隔医療について、実際の手術をされるお医者さんの意見は感覚的なところも多いのですが、100msを切ったあたりであれば使えるということでした。ただ、まずは手術よりも先に遠隔診断に力を入れていきましょうというのが現状の話かと思います。

───感覚として音声が優先だというのは理解できます。医療の分野でも8K高精細映像の応用があるのですね！

丸山：8K内視鏡を使ったプロジェクトに関わった事がありますが、医療機器の高精細化は、見えなかった糸が可視化できるなどのインパクトがあると聞いております。熟練の外科医しか扱えない12-0という極細の糸^*25があるのですが、これは肉眼ではほとんど見えません。仮に若手の外科医の育成をするとして、見えない糸の縫い方のコツを教えることは難しいと思います。しかし、8K内視鏡であればはっきりと見えますので、後進を教育する上で役立てることができます。

他にもネットワークのサポートを受ける事で、8K内視鏡手術と病理医診断を組み合わせて、手術中に顕微鏡画像を病理医さんのところに送って、即座に癌細胞かどうかの判定をしていただき、その結果を元に切除部分を変えるなどの対処ができると伺いました。

また、録画時間が問題という事も伺いましたが、それもネットワークに繋ぐことでクラウドの莫大なリソースを使ってサポートできると感じています。更に録画した映像をネットワーク上で編集してしまえれば、そのまま医学教材として利用することもできるのではないでしょうか。

───では、大同大学・琉球大学で取り組んでいる「研究開発項目2：多地点間での高臨場感通信を実現する低遅延配信技術の実現」の実験目的について教えてください。

君山：Beyond5Gなどの次世代のモバイルネットワークを介して8Kのような高精細映像を圧縮配信する際に、さすがに40Gbpsとか100Gbpsの映像をそのまま配信するわけには行かないので、基本的には圧縮したりサイズを変えたりして配信します。

このときにどのくらいの負荷が必要で、どんな配信方式が必要なのかを明らかにすることが目的です。特に、我々の研究室ではこれまでモバイルネットワークのQoS^*26特性の実験評価を行ってきた経験から、通信場所や時間によってダイナミックにQoS特性が変わることがわかっています。秒単位でどんどん変わっていく上に、半分くらいの帯域になってしまうこともあります。

従って、高精細映像を品質を落とさずに配信するためには、時々刻々と変わっていくQoS特性に追従して、圧縮方式を含めダイナミックに配信方式を変えていく必要があります。ここではそのための基盤技術を提案するとともに、テストベッドを使ってその技術を実証・技術確立することを目指しています。条件次第で圧縮方式や圧縮のパラメータも変えないといけないですし、解像度やフレームレートをなるべく品質を落とさずにどうやってバランスするかを突き詰めて行こうというのがこの実験の目的です。

───SRTというプロトコルの実験もされていると聞きました。実験ではVPNを使ってデータを流していたと思いますが、理由を教えてください。

加藤：JGN回線のみを利用する伝送実験でしたら、SRT^*27とマルチキャストのどちらもVPNは必要ありません。JGN回線が敷設されていない施設を端点として繋ぐ場合、JGN網に加えて公衆網を利用します。その際の公衆網回線にはマルチキャストは流せないのでVPNトンネルを形成します。さらに回線状況によりパケットロス対策としてSRTを利用します。

琉球大学の生物圏研究センターの例では、フレッツで繋ぐ場合にNGN^*28網を使うのですが、トンネル化しなくてはいけないということでVPNで接続しています。

公衆回線に出したときに最も考えなくてはならないのはジッタとパケットロスの二つです。ジッタの方は、レコーダー側の干渉バッファを大きくとることでジッタ対策ができます。パケットロスは再送するしかありませんので、そのためにSRTを使うとなると低遅延化と相反することになってしまうのですが、公衆回線を使う上では仕方がないところです。

───研究において大変なこと、困難なことがあれば教えてください。

丸山：実際に動かないものは説得力がないということで、とにかくマイルストーンごとに物を作って、お見せして、いろんな方からの意見を伺って絶えず方向性を修正していく形でやっております。これが相当大変ですね。実ネットワークを使った実証実験をちゃんと組んで実装しなくてはなりませんので。

2月のNICT雪まつり実験、6月のInterop Tokyo^*29、11月のSC展示会^*30と連続して実施して、というのは本当に大変です。また実証システム設計・構築に積極的に学生を関わらせて、ほとんど学生が組んでいます。教育効果はあると思いますが、毎年メンバーが変化してしまうため、技術移転が大変です。2022年初にJGNやSINETの機種更改があった際には、新機種のバグなどで悩まされておりましたが、このような実証の機会を通して、安定度向上に寄与できたと思います。そのあたり、瀬林先生はどうですか。

瀬林教授（以下、瀬林）：やはり見てもらってフィードバックが貰えるのは委託研究でこのようなことをやっているからかなと思います。SC展示会に行った時も、NICTブースの中で普段別々に研究している人たちがお互いにやっていることを見てコラボが生まれるのが良いところです。

去年もNICTの先生でIPAを兼務している小林先生のところがDDoS攻撃を再現するものを作っていましたので、私たちの8K映像を満たす攻撃をしてもらいました。するとブロックノイズにはならず、ラインごとに消えていきます。攻撃されているトラフィックでどのように映像のパケットの遅延が変化したかを私たちの計測技術モニターを使い、絵の乱れとトラフィックの乱れを同時に見せることでNICTブースの中で急遽デモンストレーションを一つ加えることができました。

───本研究に、複数のテストベッド（JGN、StarBED、高信頼仮想化環境、B5Gモバイル環境等）を利用しておりますが、これらのテストベッドの役割分担、利用者環境との役割分担についてお聞かせください。

丸山：実証実験の機会を使って、それぞれの機能を活用しています。JGNはSINETと組み合わせて、広帯域マルチキャスト網を構築しています。

StarBEDには8Kの映像サーバを複数台組み合わせて、並列伝送する形で構築しています。一つの映像ソースを複数に分散して処理しています。このアーキテクチャを考えたのが君山先生です。

また、高信頼仮想化環境が最近構築されましたのでこれを使って、映像送信源のデータをSRv6網に接続するためのカプセル化を行っています。

B5Gモバイル環境に関しては、今後の配信網の転送特性を得るために利用させていただいています。

StarBEDやJGNは常時数10Gbpsの転送に使わせていただいて、助かっております。かなりのヘビーユーザーではないかと思っております。

NICT「超高精細映像を用いた広域映像配信実証実験」

拡大

───テストベッドはどういうところで有用ですか。いままでもお使いになってきたなかでこういうところが嬉しかった、ということがあればお聞かせください。

丸山：このクラスの実証実験は、大学単独ではとても実施は無理だと思いますので、研究インフラとして提供して頂いて本当に助かっています。学生にネットワークの技術を教えていても、やはり教科書だけでは実感がわかないようです。実証実験で本当に触らせることによって、ネットワーク技術に興味のある学生がどんどん増えていますので、そのようなところでも寄与しているのかなと思っています。

将来のインフラを担う人材の育成をしているわけですが、教育のために実地でネットワークを触ると言っても、業務で使われているネットワークを触るわけにはいきません。その点、このような実験ネットワークを使った教育ができているのは素晴らしいことだと思います。

───テストベッドの不便さ、改善すべきだと考えられる点について教えてください。

丸山：アクセス手段を自分で構築しなければいけないところが、利用するハードルを高くしている気がします。多くの大学の場合には、対外回線はインフラになっていると思いますので、それを使って実験というのはかなり抵抗されそうな気がします。

私は、自分の研究室の予算だけで実験アクセス手段を構築しましたが、回線は5年契約なのが一般的です。来年度の予算がどうなるか分からない中で、最悪自分で支払うかというぐらいのリスクを背負わないとなかなか利用に踏み切れないと思います。予算がなくなるとアクセスができなくなってしまいますので。そのあたりを何とかサポートして頂くような施策があると嬉しいなという気がします。 君山先生はいかがですか？

君山：同感です。うちは5年契約ではなく1年契約でやっていますので自分のポケットマネーから出すようなことにはなっていませんが、大変です。

───今後のテストベッドに対して希望・期待することがあれば教えてください。

丸山：やはり1Tbpsを超える最先端の速度の実現と、あとせっかくセグメントルーティングが色んなところで使われ始めていますので、誰でも気軽にセグメントルーティングが利用できるものが導入されると嬉しいなと思っております。例えばJuniperのセグメントルーティング対応のルーターを買おうとするとソフトだけで1000万円かかります。このようなものを導入して頂いて皆で使い倒せるようになると日本のネットワーク技術が底上げできるのではないかと思います。

あとは、どこからでも時刻情報が得られるPTP環境^*31を全国各地で得られるシステムを作って欲しいと思います。今はNTPと合わせているのですが、例えば複数のマシンに同時に命令を発行すると当然遅延が起きるじゃないですか。そこでRTSP^*32というプロトコルを使って、ある時刻に一斉に時刻を出すようにする方式を使っています。しかし、全てのマシンの時刻が出揃わないと時刻がずれてしまいます。そこが苦労しているところですので、このような要望をしました。

他には、イベントで8Kの非圧縮映像がどんどん溜まって行くわけですけれども、このような大容量映像をアーカイブできるPeta byteクラスのストレージ環境を是非置いて頂けると嬉しいです。

私たちは圧縮映像を用いて、ローカル5Gの伝送実験も多くやっているのですが、8Kの映像を圧縮して高画質で送るためには80Mbpsくらい欲しいところです。例えばNHKの8K放送ですとリミットで99Mbpsなのですが、実際は80Mbpsくらいで映像が送られています。しかし、ローカル5Gの施設を持っているところの多くはアップで20Mbpsとか30Mbpsとか、それくらいしか速度が出ないところが多々あります。そこは準同期にしていただいて、100Mbpsを出す環境になると良いと思います。マルチキャスト伝送もあると良いですね。

───今後の展望についても教えて下さい。

丸山：今、リアルタイムサービスチェイニングに取り組んでおりまして、クラウドエッジソースがあったときに、クラウドやエッジなど、複数の映像処理機能を連携させることをやっています。電子ブロックのように機能要素を繋げて、所望のワークフローを作ります。その時に重要なのが全てをソフトウェアで動かさなければいけないところです。ここにハードルがあります。

　そこで、先に述べたように我々はDPDKを応用しています。DPDKはコアやネットワークインターフェースカードなどのリソースから切り離して専⽤処理をさせるため設定が難しいのですが、ちょっとしたコンフィグをすることで誰でもある程度知識があれば使えるようにしようというのがまず我々のやっていることです。⼀種のAPIのようなものですね。

　その映像処理機能と連携するときに、複数の映像処理機能の間を⾃在に相互接続するための仕組みとして、先に述べたSRv6という経路制御を使っています。これはかつてIPの世界でソースルーティングと呼ばれていたものの拡張です。あるパケットにヘッダをつけておくと、このルーターを通って、次のルーターはこれだよ、と経路を明⽰的に指定できるシステムです。SIDと呼ばれる単位があり、ここにロケーションとファンクション（何をやるか）の情報が埋め込まれています。

VVFを使用した映像制作のワークフロー

拡大

このセグメントルーティングを書き換えるのがコントローラです。コントローラでは、空いているエッジ装置やクラウド装置に映像処理機能をネットワーク帯域も加味して割り当てて、それらをSRv6で接続する形の運用を考えています。

このセグメントルーティングを発展させて、NTTコミュニケーションズ様と一緒にインラインコンピューティングという枠組みで我々の研究を最初のケーススタディとして標準化を進めようとしています。インラインコンピューティングはルーターの中に一種の処理装置が入っていて、ルーターの中で映像処理を含め、ある程度処理してしまおうという発想のアーキテクチャです。

またSRv6のルーター部分をオープンソースソフトウェアとして皆で展開して行きたいという思いがありまして、今後は、パケットフォーワードを行うルーター機能と映像処理機能を密接に連携して、ネットワークを流れていくデータをより低遅延で処理できるフレームワークを新しい提案としてできれば面白いな、と考えています。これが今の先のゴールです。

───直近のご予定はありますか？

丸山：次回の雪まつり実験で、8K-3DのSRv6を使った映像処理に着手します。それと、22chのイマーシブマイクをミハルさんが作られるんですよ。これを札幌から大阪までトランスペアレント伝送^*33し、受信側で22.2chにしてチェアで聞ける空間を作りますので、そこでどれくらい臨場感のある音声伝送ができるかの実験をします。

加藤：ただいま22.2チャンネルマイクを絶賛製作中でございます。まもなくできるかなと。一体どういう音になるかと楽しみなのですが、雪の中に置くものなので雪対策と、あとは風対策についても念頭に置いてやっています。作っている人たちはみんな北海道出身で、雪とはどういうものか、風が吹いたらどうなるかと、そういう頭のある人たちで今作っている最中です。^*34

───お時間をいただきありがとうございました。この取材の後、大阪うめきたにて、さっぽろ雪まつりの映像配信実験を見に行く機会に恵まれました。最後にそのときの様子を掲載し、本記事を締めくくります。

今年の雪まつりは3D映像の配信を行った。
右目用と左目用の映像が同時に写っているので、2重に見える。

拡大

来場者に配布された3Dメガネ。

拡大

アストロデザインのプロジェクタによってスクリーンに映し出された。

拡大

ミハル通信のブースでは受診した22.2ch音声をソフトウェア上で扱っていた。

拡大

提供する音響の空間設定画面。これによって22.2chを空間的に振り分けられている。

拡大

22.2ch再生できる椅子型スピーカー「TamaToon」

拡大

このように一人で座って楽しむ。

拡大

謝辞(順不同)：情報通信研究機構(NICT) 雪まつり実証実験の実施にあたり、NII国立情報学研究所、宜野座村IT オペレーションパーク、北海道テレビ放送株式会社、アストロデザイン株式会社、株式会社池上通信機、アリスタネットワークスジャパン合同会社、セイコーソリューションズ株式会社、アンリツ株式会社、エヌ・ティ・ティ・コミュニケーションズ株式会社、東日本電信電話株式会社、ピュアロジック株式会社をはじめ関連組織の皆様のご協力をいただき感謝します。

本研究成果の一部は、NICTの委託研究（JPJ012368C03101）およびJSPS科研費22K12021、22K12003により得られたものです。

＜2024.2／5＞

【総合テストベッドに関するお問合せはこちら】
　　tb-info[アット]ml.nict.go.jp