3. フォーカス・リサーチ（2） 2020年を超えて−オリンピック・放送制作・インターネット− | Internet Infrastructure Review（IIR）Vol.50 | IIJの技術

目次

3. フォーカス・リサーチ（2）

2020年を超えて−オリンピック・放送制作・インターネット−

3.1 はじめに

「2020年」はどのような一年として人々に記憶されたでしょうか。誰にとっても人生はそれぞれ異なるものですが、多くの人に2020年は「コロナ禍が始まった年」という出来事で共有され思い出されるでしょう。新型コロナは猛威を奮いつつ、広範囲にわたり社会に大きな影響を与えました。その1つが東京オリンピック・パラリンピック競技大会の延期です。2020年は、その意義に様々な論があるにせよ「東京でオリンピック・パラリンピックが開催された年」として記憶されるはずだったのです。

3.2 オリンピック・パラリンピックと放送制作

放送、特にテレビジョン放送は近年ビッグイベント、殊にオリンピックやワールドカップのような巨大スポーツイベントと分かち難く結びつくようになりました。視聴率を求めるメディアは大規模なイベントを欲し、イベント主催者はその影響力をより効果的にするためマスメディアに依存します。広い帯域の電波を用いた放送はリッチメディア（視覚、聴覚）という特性を持つため、世界的に多くの人が関心を寄せるビッグイベントの模様を伝えるにあたり非常に支配的なポジションに位置しています。全世界で各国市民がほぼ同時にリッチメディアを受容できる仕組みは、放送以外にはありません。インターネットはこのような超大規模配信については未だ苦手としています。

その中でもオリンピック・パラリンピック放送は特別なものです。極めて多くの競技が短期間のうちに実施される中で番組が制作され、世界中に配信されています。オリンピック・パラリンピックの場合、2008年以降はIOCによって設立されたOlympic Broadcasting Services（OBS）がすべての競技の模様を国際映像として制作しており、契約を結んだ各国の放送局はこの供給を得ています。日本の場合はJapan Consortiumという放送局の連合体がIOCと契約を結んでいます。供給された映像は各国語のコメンタリー（アナウンサーや解説者による実況など）や独自取材映像は入っていませんので、それらを挿入するため、各国の放送局においても制作作業が実施されることになります。こうした大規模イベントでは急なデマンドも発生しがちです。予定にない（＝期待されていなかった）選手が決勝に勝ち上がったために中継を急遽編成することになったり、注目度の高い競技の時間が重なったり…こうした不確定要素に対しては、どうしても制作上の資源不足が生じます。

一般的にこのようなイベント番組制作は「現場」で実施されています。例えばスタジアムの駐車場に大型トラックを改造した中継車を派遣し、その中にスタジアム内からのカメラやマイクを集約し、車の中でスタッフが映像や音声の編集作業を実施する。ビデオスイッチングが代表的な編集作業の例ですが、それ以外にもビデオカメラの絞り制御やマイクの音響調整など、制作には非常に多様な作業が求められます。それ故、制作には多くの放送エンジニアの稼働が必須となるのです。

中継車は独立して機能することが前提で、制作に不可欠な機器がすべて搭載されます。局舎にある機器と同等の機能を持ち、入出力の数が少し抑えられた機器が車の中に装備されています。しかし、その機器は中継車の非稼働時は全く用いられません。スペースに制約のある中継車の機器を都度着脱するのは現実的ではないからです。ただし高価な機器などの場合はどうしても使い回しをせざるを得ず、現場に持ち込まれることもあるようです。いずれにせよ、効率が良い話ではありません。

更に同時進行するイベントへ対応する場合、放送エンジニアの稼働確保は困難な課題となります。放送エンジニアは機器を操作するために現場に赴かなければならず、その結果移動時間のオーバーヘッドが生じます。するとイベントの掛け持ちが不可能になってしまい、複数の放送エンジニアをそれぞれの現場へ別途充当しなければならなくなるからです。また日帰り圏にない箇所で開催されるイベントを中継するため、放送エンジニアが遠方のホテルに連泊することもよくある話です。

3.3 リモートプロダクションへの流れと壁

それを、IPが解決できるかもしれないと思われるようになりました。IPを用いた遠隔放送番組制作、「リモートプロダクション」です（図-1）。端的に言えば、カメラやマイクにIPゲートウェイを備え付け、現場で収録した高い品質のまま映像・音声をIPによって遠距離へ運び、制作作業は局舎で実施しようというものです。すると、1つの場所にリソースを集めることで成立していた番組制作の方法論が変わります。現場に持っていく機器は最小限のもので良くなりますし、作業のために移動する必要もありません。経費削減が図れるだけでなく、効率も良くなり、作業品質もアップすることは間違いありません（出張が好きなエンジニアには、残念なニュースかもしれませんね。）。

図-1 リモートプロダクションの概念図

機器やそれを扱うエンジニア・オペレータを集約し効率良く運用したいという要望は、ICT業界ではよくある話でしょう。この十数年オンプレミスからクラウドへ、ソリューションからサービスへといった継続的な流れの中で、常にICTの導入による省力化や投資のスリム化が求められてきました。ネットワーク技術の進展に伴い、この傾向が放送制作の分野にも訪れたと見ることもできます。この2、30年来様々なメディアがIPを用い流通するようになった中、最後の大物として残っていた領域が放送制作技術だったのです。

10GbEや100GbEといった高速イーサネット普及の後押しもあり、放送機器のIP対応は順調に進みつつあります。この5、6年で急速にIPへの対応が進み、現在では放送機器にはごく当たり前にイーサネットのインタフェースが設けられるようになりました（主にSFP+もしくはQSFPが採用されています）。こうした技術革新を受け、欧米を中心として大規模な放送局設備のIP技術導入が相次いでいます。IP技術を無視しては将来展望が語れないまでに、放送機器分野でのIP技術普及は進みました。

局舎内のIP対応と同様、リモートプロダクションを実現するには大容量回線の確保が必須となります。大規模なスポーツイベント中継では10台以上のカメラや何十本にも及ぶマイクが収録のために設営されます。これらのソースを現在の制作クオリティを落とさずに伝送しようとすると、10GbEクラス、あるいは100GbEの回線を複数本確保しなければなりません（フルハイビジョンの映像を圧縮せずにIPで伝送すると1.5Gbps程度、4K映像だと13Gbps程度の帯域です）。これはOTT（Over The Top）向けにネット中継をするのに比べ、段違いにハイクオリティな環境です。こうした大容量回線は通信キャリアからサービス提供されていますが、ほとんどの場合回線は年間契約で、また月額コストも高価です。放送局の観点から見ると、番組単位の予算から支出するという規模感からはみ出てしまいます。敷設のための事前調整もかなりの時間がかかるため、週末のイベントのために回線を3日間だけ敷設するというようなカジュアルな使い方は、まだまだ難しいのが実情です。

リモートプロダクションは「働き方改革」の一種と言えますし、俯瞰すれば「デジタル化」の文脈で捉えることもできるでしょう。デジタル化はワークフローを促進するだけではなく、それを根本から変えてしまう可能性があります。逆に言えば最終的にワークフローそのものの改革を目指さない限り、デジタル化はその効果を最大化できません。しかし、リモートプロダクションのPoCを経た制作現場からはこんな意見も散見されました。曰く「これまで人が集まることで制作の集約化が図られていた現場の手法にメスを入れる形になる」。まさに「密」によって成立していたコミュニケーションを、IPはいわば分断してしまうことが問題となるようです。これは既に技術の問題ではなく、デジタル化に対する組織論の範疇です。少子化を迎える社会に対して産業界がどのように備えるべきか、その試金石という側面をも持ち合わせているようです。

このように、リモートプロダクションを日常的に実施するにはまだ解決すべき課題が残っています。喩えるなら登山道を5合目、あるいは8合目まで登ってきたわけですが、本当に苦しいのはこれからなのでしょう。登山に求められるスキルもギアもバジェットもタイミングも徐々に揃いつつあるのですが、それを一気に揃えるのは難しいと関係者は感じています。登頂を諦め引き返す人も、あるいはおられるかもしれません。

しかし、IPネットワークが寄与できるポイントは他にもあるのではないか。何も始めから世界最高峰を目指すのではなく、もっと「自分がいま頂上まで登れる山」から攻めるやり方もあるだろう。そう思っていた矢先、コロナ禍が世界を覆い尽くしました。そしてリモートプロダクションの導入より遥かに緊急性が高く、誰にとっても喫緊の課題が浮上してきました。それはコロナ禍における職場での感染対策、分かりやすく言えば「3密回避」です。

3.4 リモートワークとネットワーキングの重要な関係…VidMeet Onlineでの試み

こんにち、コロナ禍に対する企業の対策として「リモートワーク」が重要視されています。これまでリモートワークは「働き方改革」的な文脈で取り上げられてきましたが、ウイルス感染に対する非常に有効な策としても注目されるようになりました。それは放送局でも例外ではなく、2020年3月の段階で欧州の放送局におけるリモートワークについてのワークショップが開催されていたほどです。職場の出社人数が制限されてしまったので、これまでの制作に必須とされた体制が構築できない。それを回避するため、自宅から職場へVPNでアクセスし、リモートから放送局舎内のリソースをコントロールする。そのような発表や議論の中には生放送に必須の「スイッチャー」を遠隔から操作したという剛の者もおり、そこまでやるのか、とその体重の乗せっぷりに驚いたほどです。

それでは、リモートワークを可能とするネットワーキングとはどのようなものでしょうか。筆者はこれこそ2020年に追求すべき課題であると考え、デモンストレーションという形で世に問いました。2020年10月より12月まで有志によりオンラインで開催された「VidMeet Online」です。

VidMeetはVideo over IPについて扱う勉強会として2017年に開始されたイベントです。筆者が主催し、これまで9回のミーティングをIIJにて開催してきましたが、コロナ禍の折り活動停止を余儀なくされていました。そんな2020年の初夏、放送機器やIP機器メーカやプロバイダの有志によるオンラインミーティングが開かれました。各種催し物のオンライン化や中止が進む中、自分たちの手でオンラインイベントを主催できないか議論したのです。方向性が定まっていく中で、イベント名にVidMeetの名前を付けることになりました。VidMeetはコミュニティに貢献する場であり、このイベントにも相応しい名前として評価されたのだと思います。

VidMeet Onlineのテーマは「インターネット・データセンター・クラウド × 放送機器が生む新たな運用スタイル」です。放送機器をデータセンターやクラウドに集約し、それらをインターネットでつないだときに何が起きるのだろう？という関心がありました。このイベントの訴求ポイントは、容易に入手可能なリソースである「リモートネットワーキング」がどのように放送制作現場へ貢献できるかというところにあります。リモートプロダクションより更にフットワークを軽くして、今できることを追求したのです（図-2）。

図-2 VidMeet Onlineネットワーク構成

今回は「データセンターを放送局舎として、また参加各社のオフィスを中継現場として見立てる」というコンセプトのもと、データセンターと参加各社を接続するためにフレッツ光回線を用い、その接続をインターネットVPNによって確立しました（図-3）。

図-3 VidMeet Online VPN上のフロー

放送機器をデータセンターに設置しようと決めた理由は2つありました。1つは、局舎システムのアウトソースを考えた際、その移設先としてデータセンターが候補に挙がるはずだからです。すべての放送機器を移せるとは思いませんが、可能性を探ってみたいと考えました。データセンターに移設が可能なリソースは、最終的にはクラウドへの移行も見えてきます。もう1つの理由は、放送機器を大容量インターネット回線に接続し、リモートコントロールしたかったからです。データセンターに設置した放送機器のデモンストレーションをインターネット越しに実現できるならば、その技術はそのままリモートネットワーキングで活用できることを意味します。デモを受けたユーザは、期せずしてこの技術の実用性を証明してみせたことになるわけです。

VidMeet Onlineのデモンストレーションでは次のような実験を実施しました。

操作用ハードウェアパネルをオフィスに置き、VPN経由でデータセンターに設置した映像プロセッサを制御
オフィスで生成した音声パケットをVPN経由でデータセンターの音声プロセッサに投入、ミキシングを実施
データセンターに設置した映像パケット分析装置をオフィスからWebブラウザ経由で操作
オフィスに設置した放送カメラ用ロボットアームをインターネットVPN経由で制御
VPN経由でのネットワークスイッチの設定投入及び運用
データセンターに設営したビデオサーバを遠隔制御
PTPパケットをVPN越しに送出し、複数の遠隔地点で放送機器を同期駆動

またデータセンターにVMware ESXi用のサーバを仮想基盤として整備の上、仮想サーバにアプリケーションをインストールし、主に制御系のサーバを運用しました。

仮想サーバにインストールした制御サーバで、データセンター及び遠隔地に設営したビデオサーバの機器制御
仮想サーバに監視アプリケーションをインストールし、各種機器のモニタリング
仮想サーバ上の制御用メタデータサーバにて、機器間のインターオペラビリティを確認

普段は通信用のルータやスイッチ、サーバが設置されるデータセンターのラックですが、VidMeet Onlineでは放送局舎や中継車で見かけるような機器が並びました。通信事業者のラックとしては珍しい光景でしたので、許可を受け特別にお目にかけたいと思います（図-4、図-5、表-1）。

図-4 ラックマウントされた放送機材

図-5 ラックマウント構成図

表-1 VidMeet Online参加社一覧

実際にVidMeet Onlineのネットワークを構築して感じたのは「案外、実用に足るのでは？」ということでした。VPN構築はL2TP、IPsec、OSPFといった汎用的なプロトコルしか用いておらず、一般的な構成になりました。しかしそのネットワークを用いて展開された実験は前述のように非常に幅が広いものとなり、リモートコントロール、あるいはリモートワークを意識した実証として世界的にもあまり例がないイベントになったと考えています。

こうした実験をデモンストレーションという形で2020年10月6日から12月11日にかけて継続実施し、その成果をウェビナーや参加各社のセミナーといった形で公表しました。主催ウェビナーは16回を数え参加者は述べ300人を超えました。各社からのウェビナーや発表資料はアーカイブされていますので、ぜひWebサイトhttps://vidmeet.tv/を訪問していただければと思います。

特筆しておきたいのが、このプロジェクトそのものもリモートネットワーキングによって運営されたということです。データセンターへの機器持ち込みや撤収、参加各社でのフィジカルな作業はあったものの、据え付けられた機器はすべてネットワーク経由でコントロールされました。ミーティング及びウェビナーはZoomで実施され、メンバーが物理的に集うことはありませんでした。プロジェクトマネージメントの観点でも、ネットワークは大いに活用できます。今後は「現場にいる重要性」と「オンラインでもできること」をいかに区分していくか、改めて問われるのではないでしょうか。

3.5 ネットワークのたどる先はクラウド

このように、VidMeet Onlineでは放送機器リモートコントロールの技術的可能性を示すことができました。今後はこの知見をいかに実運用に、あるいは実提案に落とし込んでいけるかが鍵となります。中継車などのシステムをモバイルVPN接続することで、クラウドで一元監視できる可能性が出てきました。もちろん現場でのモバイル利用は100%安心とは言い切れず、例えば人が集まるイベント会場などでは輻輳が発生し得ます。クラウド利用を前提とすると回線の選択は更に重要になります。モバイルだけではなくフレッツの利用やクラウド直結ネットワークサービスの導入など、検討すべきシナリオはまだまだあるでしょう。

放送制作や放送局のシステムにおいて、クラウドを利活用するシーンは間違いなく増大する方向にあります。これは他業界においては何年も前から起きている事象であり、放送局においても、Webサーバや動画配信での取り組みは既に始まっています。クラウドはインターネットをはじめとするICT領域における最良の果実の1つであり、利用せずにおく手はありません。その一例が、クラウドを基盤としたネットワーク機器に対する一括管理と監視です。

放送制作システムは規模や演出、つまり番組の内容によって機器の構成が毎回異なります。これまでは現場で機器を組み上げて対応していましたが、IP化するとそう簡単にはいきません。IPアドレスのアサインから始まりネットワークスイッチの設定、PTPの導入、更に機器同士の相互接続の確認や監視設定などが求められます。このように複雑なシステムをIPエンジニアの力なしに組み上げるにはかなりの困難を伴います。放送局でのIPエンジニアの育成はまだ端緒にあり、放送エンジニアが本業の合間を縫って手探りでIP技術を習得しているのが現状でしょう。

このような環境下では、ICT分野で活用されているツールの導入が有効と考えられています。ネットワークスイッチの集中管理アプリケーションや、放送機器監視用モニタツールが代表的な例です。例えばネットワークスイッチの大規模な導入と運用管理は手作業では到底スケールできず、ツールを使った一括での管理が効率的です。このようなツールは、毎回環境が動的に変わっていく現場にも適しています。エンジニアの負荷軽減という観点でも、現場に赴かずとも導入や運用ができるツールの存在は大きなサポートになります。「現場に行かなくていい」あるいは「事前に作業ができる」ことは、つまり「3密を回避」することに他なりません。

むしろネットワーキングの良さを実感できるのは、リモート監視や機器の運用といった、ある意味地味な領域からかもしれません。ネットワーキングは自分の手元でも世界のどこでも区別なく作業できるようにするための技術であり、機器がつながることで今まで不可避だった作業の手間を軽減できるかもしれない。逆に考えると、ネットワーキングは作業品質をより高めるために欠かせない技術であるともいえます。リモートプロダクションとまったく同じメリットが目指せるわけです。

このようにネットワーキングを用いたサービスやソリューションは、放送制作の現場に寄与できる余地がまだまだあることが示されました。更に開拓すべき領域もたくさん残されています。

ここで一点指摘しておきたいのは、こうしたネットワーキングの応用は必ずしもコロナ禍によって生み出されたものではないということ。これまでも存在していた手法が、コロナ禍によって誰の目にも明らかに映し出された現象だということです。実際ICT分野の多くのエンジニアはそのように仕事を続けてきています。自宅からのリモートワークはもちろん、オフィスからデータセンターやクラウド上にあるサーバを操作することもネットワークの応用です。こうした技術がコロナ禍への対策として有効と認められ、あらためて2020年になって着目された事象だったといえるでしょう。

3.6 クラウドとソフトウェアの大きな可能性

もう一点、重要な動きが起きています。それは「ソフトウェア化への流れ」です。もともと放送機器は放送局にしか販売できない、非常に狭い領域をターゲットとした商材です。放送局の数は限られており、かつ新規参入しにくい分野でもあるため、どうしても製品のコストは増加します。そこでコモディティであるIAサーバを利用したソフトウェア化への流れが起きたのです。もちろん、映像や音声のリアルタイム処理をするような機器ではLSIやFPGAがプロセッサとして採用されることが多く、こうした製品は今後も専用ハードウェアの形を取り続けるでしょう。一方、制御サーバの類はそこまで高いプロセッシング能力を必要とせず、CPUで賄える場合が多いのです。すると製品はソフトウェアのみで実装でき、専用のハードウェアを自社で開発・維持する必要がなくなるため、保守性や拡張性の面から見てもメリットが生じます。

ソフトウェア化の流れはこの10年で加速しました。かつてはIAサーバを用いたアプライアンスも多く見かけましたが、最近ではソフトウェア単体での販売も本格化してきています。仮想化技術への対応も進み、更に一歩進んでメーカが自らSaaS提供を始める事例も増えつつあります。SaaSの母体となる環境は、言うまでもなくクラウドです。

将来的にはソフトウェア化された制御サーバはクラウドで稼働させ、局舎や中継車に置かれた放送機器をネットワーク越しにコントロールする、という形態が一般化するでしょう。制御サーバをクラウドで動かすことで、多くのシステムを一括管理できるメリットが生じます。また既設のネットワークやVPNと組み合わせれば、制御サーバへのアクセスが場所を問わず可能になります。つまり手元のPCから現場の放送機器を監視・制御できるわけです。リモートワーク下にあっては、このような運用支援形態が求められるようになるのではないでしょうか。

もちろん、制御サーバは必ずしもクラウドに設置される必要はありません。被制御機器との通信でレイテンシが厳しく問われるような場合は、それをクリアするネットワークトポロジを構成する必要があります。アプリケーションの特性に応じた上で、制御サーバをクラウドで稼働させることのメリットとデメリットの評価を下せば良いのです。あるいはクラウドを選ぶのではなく、局舎内にサーバクラスタを保有するという手法が一般的になるかもしれません。ここで重要なのは制御サーバを仮想基盤に設置することです。これにより機器間のマイグレーションを容易にし、将来的にクラウドと往来するハードルを下げることにもつながります。つまり、ソフトウェア化によるメリットを最大化するための準備をしておくべきです。

3.7 ネットワークを利用したクロック供給の可能性

更に、ネットワークが放送制作の場に大きく寄与し得る可能性がある分野について紹介します。「PTP over WAN」と呼ばれる技術です。

放送システム全般にわたり、映像・音声は標本化・量子化・符号化され、時間的に区切られたデジタルデータとして扱われます。このデータを元通りに再生するためには、時間軸の物差しとなるクロックが必須になります。このクロックとは、私たちが日常生活を送る上で意識している「絶対時刻」 - 1970年1月1日午前9時0分といったような - ではなく、「相対時刻」のことで、タイミングを合わせるためのものです。デジタル機器の中にも、このクロック装置は必ず装備されています。放送機器の場合、全体を統括する同期信号用の装置が別途用意され、個々の機器に供給されます。すべての機器が同じタイミングでデータをハンドリングしないと、映像や音声の収録・再生時にずれが生じてしまうからです。

これまで映像機器に対するクロックは同軸ケーブルを経由して供給されており、Black Burst信号と呼ばれ広く使われていました。しかし放送機器のIP化に伴い、このクロックもIPを用いて供給されるようになりました。ネットワークを用いた時刻情報同期のために開発されたプロトコル、PTP（Precision Time Protocol）です。イーサネットやIPを伝送路として用い、ナノ秒オーダーでの同期精度を確保できます。源信号としてGNSSを利用し、衛星から供給された信号より高精度時刻情報を生成します。この情報は非常に高精度であるため、同期用のクロックとして用いることが可能です（絶対時刻情報も含まれています）。そしてこの高精度時刻情報をネットワークに送出するための装置を、PTP GrandMaster（GM）と称しています。このプロトコルはIEEEで規格化されましたが、応用範囲は広く、様々な規格化団体から各産業での利用形態にフィットしたプロファイルが発刊されるに至っています。

しかし、この技術の導入には一定の障壁が存在します。PTPパケットが通過する経路上において、すべてのネットワーク機器がPTPに対応する必要が生じます。PTP GMとそれを受ける放送機器だけではなく、その間をつなぐネットワークスイッチの対応も求められるのです。PTP対応の機器は、PTPのパケットに対してのみ特別な処理を実施します。正確性を保つため、PTP対応の機器はGMを源とする上流からの時刻情報を受信し続け、補正しています。更に下流へPTPパケットを送出する際も、この補正された時刻情報をパケットに打刻します。このようにPTP対応機器は一つ一つのイーサネットポートごとにパケットを処理しなければなりません。ネットワーク設計において、このようなPTPのフローを意識する必要があるのです。

現状、PTPに対応しているネットワークスイッチはおおむねミドルクラスかそれ以上の機種です（価格で言えば百万円以上の機種でしょうか）。全メーカの全機種で対応しているわけではないため、導入に当たってはしっかりした選定が求められます。また、既設LAN、あるいはWANにPTP技術を導入するのはなかなか難しいと思われます。機器のリプレースや、サービスでの対応を問うことにつながるからです（PTPに対応したWANサービスは、おそらく存在していません）。経路上に非対応の機器があると、PTPパケットは元の打刻情報を保ったままフォワードされます。こうなるとプロトコル上の正確性は担保できなくなり、パケット到着時の時間的なゆらぎが発生し、時刻が補正できる範囲を超えてしまいます。

放送の現場では、GNSS衛星からの信号が入感するか試さない限り判明しないという問題もあります。いつでも上空が開けた場所に中継車を設営できるとは限りません。一般的に良好なロケーションでは10個程度のGNSS衛星からの電波を受信できますが、衛星捕捉数が少なくなるとクロックの精度に影響してきます。例えばビルの谷間に中継車を設営すると上空の見通しが限られてしまい、GNSS衛星からの電波が十分に受信できない場面もありえます。こうなると、PTPをネットワーク越しに提供する方が良いのではないかという議論があります。リモートプロダクションやリモートコントロールが前提であれば、ネットワークは必ず敷設されるからです。

これらの課題を解決する技術が「PTP over WAN」です。PTP非対応のネットワーク越しであっても、遠隔地にPTPを供給することを目的としています。

PTP over WANへのアプローチは複数のメーカで試みられています。IIJは「RPTP Alliance」に参画し、この技術の技術開発を推進しています。RPTP Allianceは次世代のPTP提案を目的とし、2019年に立ち上げられたプロジェクトです。これまで高価な専用ネットワークを必要としていたPTP広域伝送に対し、長距離での高精度の同期を可能とし、PTPと互換であり、またPTPを通せないネットワークでも同期可能とした「RPTP（Resilient PTP）」技術の実証と普及を目的としています。現在RPTP Allianceは株式会社メディアリンクス、ネットワークアディションズ株式会社、セイコーソリューションズ株式会社及びIIJで活動が進められています。

RPTPにおいて、PTPのプロトコルに手を加えることはしていません。従って既設PTP GMの対応は必要ありません。受信側装置での同期アルゴリズムに改良を加えることで、非対応ネットワークで生ずるゆらぎにも適用できるようにしています。これにより整流されたPTPパケットを再配布する仕組みになっています。これまでのPTPの同期アルゴリズムはLANでのクリーンな状況を想定されており、技術的に見てRPTPはチャレンジングな開発です。しかしすべての機器がPTP対応である必要がなくなるため、ネットワーク構成の厳密さが緩和され、より手軽に使えるようになることが期待できます。

RPTP AllianceはVidMeet Onlineにも参加し、IIJバックボーン上でPTP over WANの実験を実施しました。IIJ松江データセンターパークとIIJ横浜第一データセンター間にL2ネットワークを構成し、PTPの疎通を確保。そしてIIJ松江DCPにGMを設置し、IIJ横浜第一DCまでPTPパケットを伝送しました。更にPTPからBBへと同期信号変換を行うことで、放送機器にPTP及びBBの同期信号源を同時に供給するという内容です。複数メーカの放送機器へPTPやBBを配布するのはRPTP Allianceとして初めての経験になりましたが、いずれも問題なく同期を確立でき、放送機器の正常な稼働を確認しています（図-6）。

図-6 VidMeet Onlineでの実験

またIIJバックボーン以外の広域イーサネットサービスを用いた実験においても、遠隔地へのPTP供給に成功しています。更にPTPからBB同期信号を生成、同軸ケーブルを経由して放送制作用のカメラに供給したところ、カメラは正常に作動し、撮影した映像が問題なく伝送できることを確認できました（図-7）。

図-7 PTP-BB変換に成功

これらの結果はRPTPの有効性を立証していると考えています。RPTP AllianceではRPTPを実用レベルの技術として確立し、ビジネス展開へと繋げるべく、活動を継続していく予定です。

3.8 VidMeet Onlineを通じて見えてきたこと…2021年、そしてその先へ

最終的には、大容量回線が中継現場に敷設されることになっていくでしょう。2019年のラグビーワールドカップでは、決勝戦が行われた横浜国際総合競技場にIP回線が敷設され、決勝戦の模様はオーストラリアの編集プロダクションにおいて制作が実施されました。バックアップ用のクルーと機器は新横浜に設置されましたが、基本的なオペレーションはオーストラリアで行われたとのことです。このように、リモートプロダクションは世界的には既に現実の選択肢となっています。増大する要求に対して効率化を図るリモートプロダクションという手法は、ごく普通の光景となり、重要度を増していくはずです。

しかしオリンピック・パラリンピックは夏季と冬季に2年ごとに開催されるために間隔があり、そもそもホストカントリーは毎回異なります。気軽に試すフィールドではありません。上述したように、IPが放送制作に貢献できる場はもっと身近なところにもあるのです。まずは、現在IPネットワーク化されていないシステムを一部でも構わないので接続していくこと。既に普及している、安価で身軽に導入できる技術の適用範囲を見定めていくこと。こういう試みを日常的なオペレーションやシステムに取り入れていけば、技術と経験が蓄積されていくでしょう。

筆者もこうした放送機器のIP化のビジネス展開を模索してきました。実際のところ、IIJサービスの中で最も基本的な場所に位置する「接続サービス」がキーテクノロジーと認められお客様にご採用いただいているという実感があります。接続サービスはIIJの中で最も歴史が深く技術にも営業にも豊富な経験があり、更にサービス内容も多彩に展開しており、お客様に安心してお使いいただける最良のものの1つです。回線接続が安定していなければ、その上に立つクラウドサービスも意味を失いかねません。専用線のみならずフレッツやモバイルなど多様なカバレッジがあることも、訴求点の1つだと捉えています。接続サービスの重要性について再認識をいただけるようになったのは、相互理解の賜物であると信じています。

今後、放送機器とIPネットワークの関係性はより深化すると考えられます。クラウドの真価を発揮するにも、リモートプロダクション、あるいはリモートワークにおいても、ネットワーキングは欠くべからざるパートを構成することになります。放送制作という機動力・即応能力が求められる現場において、いかに使いやすく、多くの要求に答えられるためのネットワークがどのようなものであるか、その進化を手助けできるよう努力を続けていきたいと考えています。

山本文治