ネットワークカメラ（IPカメラ）は一般に普及しているLANやインターネットを使って映像を伝送するものである。アナログカメラのように映像伝送専用のケーブルは必要なく、伝送距離に制限がないのがメリットである。ただし、4K映像をそのまま伝送するとビットレートは数 Gbpsから数10 Gbpsにもなるため、通常は1/100以下に圧縮して伝送する。そのためアナログカメラと比較すると遅延時間が大きくなる。なお、デジタルテレビ放送でも動画圧縮が行われている。テレビ映像と時計の時刻を比較すると、映像が数秒遅れているのが確認できる。テレビでの数秒の遅れは通常あまり気にならないが、遠隔制御におけるカメラ映像の遅延は問題となる。遅延の要因は動画の圧縮・伸張に要する時間だけではない。無線ではむしろ他の要因による遅延時間の方が大きい。本論文ではそれらの要因について述べ、遅延時間を極力小さくするための技術について説明する。また、我々はH.264/H.265エンコーダと5G通信機能を搭載した一体型の低遅延カメラ ¹⁾を開発した。このカメラを使ったシステムの実証例も紹介する。

　本論文ではカメラによる撮影から画面への表示にかかる時間（一般にGlass-to-Glass遅延と呼ばれる）のことを映像遅延と呼ぶことにする。公知の文献 ²⁾では、VR環境における制御で認識できる映像遅延は50 msから100 msの間に閾値があると報告されている。つまり、それ以上の映像遅延があると人間は映像に違和感を持つようになり、操作が困難になってくる。コニカミノルタの5Gラボに展示しているラジコンカーの操作デモにおいても同様のことが体感できる。映像遅延が50～70 msの低遅延カメラと数100 msの市販のネットワークカメラを並べてラジコンカーを撮影し、その映像を見ながらラジコン操作ができるようにしている (Fig. 2)。低遅延カメラ映像（右側モニター）では、直接目で見たラジコンカーと撮影した映像を並べてみないとその差がわからない。一方、市販のネットワークカメラの映像（左側モニター）では、ラジコンカーがかなり遅れて動作しているのが操作感覚でもわかる。この場合、モニター上の白線位置でリモコンの停止ボタンを押した時には、ラジコンカーはすでに壁にぶつかっている。

  　5Gの特徴として「低遅延」「高速・大容量」「多接続」の3つがあげられている。5Gは低遅延で1 ms以下を実現すると言われているが、それは無線区間での遅延時間のことを言っている。Fig. 1の「③ネットワーク通信」の区間には、無線区間以外に、無線装置 (Radio Unit, RU) やベースバンド装置 (Baseband Unit, BBU) からなる5G基地局内のネットワークやその先のUPF (User Plane Function)、そしてエッジサーバーに繋がる有線LANの区間が含まれる。 仮に無線区間で1 ms以下を満たしたとしても、それ以外の通信区間での遅延の方が大きいため、5Gだから映像遅延が小さいというにはかなり無理がある。また、よく混同されるのが、遅延とスループット（通信速度)である。遅延はあるデータの塊が送信元から送信先に届くまでの時間である。一方、スループットは単位時間あたりに送信できるデータ量のことである。一般に5Gだから速いと言っている「高速・大容量」はこのスループットの方で、2時間の映画が5Gなら3秒でダウンロードできるから速いというのは、事前に録画された映像データを一気にダウンロードできる場合の話である。2時間後に撮影されるはずのカメラ映像を事前に送ることはできないため、カメラ映像のリアルタイム伝送に「高速・大容量」は直接関係しない。ただし、4Kの高精細映像を送るためにはアップリンクの通信速度が20～60 Mbps程度は安定的に出る必要があり、現状の4Gの性能では厳しく、5G以上の「高速・大容量」が必須である。

　リアルタイム伝送で重要なのは、いま撮影された映像データが直ぐに届く「低遅延」の方であるが、映像遅延に占める5Gの遅延の割合は上述の通り小さい。また、1 msというのはあくまで目標値である。それを達成するには無線信号の伝送時間や再送に要する時間を短縮するなどして低遅延化すると同時に無線パケットの受信成功確率も高めるよう調整が必要である。2023年現在、低遅延性にフォーカスして調整された5G設備はまだほとんどないようである。

　また、5Gが「低遅延」といってもEthernetなどの有線と比較すると遅延は大きい。それは上述したように基地局などのネットワークを経由することによる遅延に加えて、無線区間で発生する通信エラーなどが原因である。無線区間で通信エラーが発生すると再送が試みられる。この再送により遅延が増大するとともに通信ジッターも増大する。また、通信パケットの順序の入れ替わりや欠落（以降パケットロス）が発生する。基地局設備の性能にもよるが、我々の実験では5Gの遅延は有線と比較して最良の通信状況でも10 ms前後は大きく、通信状況が悪くなると数100 ms大きくなることもあった。また、60 fpsの映像伝送時の遅延時間の測定結果のばらつきが、有線ではフレーム更新間隔 (16.7 ms) に近い20 ms程度にほぼ収まるのに対して、5Gでは通信状況の悪化に伴いばらつきが大きくなる。つまり、5Gのような無線通信では、最大遅延時間が大きく上振れすることがある。

 　ダウンロード方式の伝送とリアルタイムの伝送では使用する通信プロトコルも違う。前者はインターネットで通常使われているTCP/IPとそのアプリケーションに適した上位プロトコルを用いて通信を行う。TCPはIPパケットのロスがあると再送制御や輻輳制御を行い、確実にパケットを届けることを試みる。動画のダウンロードにおいては有用なこれらの制御もリアルタイム伝送ではかえって仇となる。パケットロスが多くなると受信の待ち時間が増大するのに加えて、TCPの輻輳制御により帯域が絞られて最終的に通信が止まることもある。そのため、リアルタイム伝送では通常TCPは使わず、UDPを使用する。その代わり、その上位プロトコルでリアルタイム伝送に適した制御を行う。その上位プロトコルとしてRTP (Real-time Transport Protocol) やSRT (Secure Reliable Transport) などがある。

　RTPは文字通りリアルタイムの伝送を意図して作られたプロトコルで、通常RTCP (Real-time Transport Control Protocol) と同時に使用される。RTCPを使ってどのようにRTP通信を制御するかを決めているのがRTPプロファイルである。デフォルトのRTP/AVPプロファイルはRTCPによる最小限の制御しか行わない。パケットロスがほとんどないか、多少のパケットロスにより映像が乱れても許容できる場合はこのプロファイルを使えば最も低遅延になる。パケットロスに対してある程度の再送制御も入れた方が良い場合は、RTCPによる高速フィードバック制御を行うRTP/AVPFを使った方がよい。この場合、パケットロスが多いと映像がカクカクとした不自然なものになったり、乱れたりする。また、SRTは高速な再送制御に加えて、ジッター制御や前方エラー訂正も行う。我々の実験では、10％程度のパケットロスを意図的に入れた場合でも映像が滑らかに表示されることが確認できた。しかし、ジッター制御のために送信バッファーで送信を待たせる分だけ遅延となる。滑らかに表示させるためには100 ms程度の遅延を入れる必要があり、100 ms以下の映像遅延に抑える用途では現状利用できないと判断した。RTPにするかSRTにするかは、使用条件により最適なものを選択すれば良いであろう。

　ここで、カクカクとした不自然な映像になる原因について述べておく。動画圧縮方式のMPEG2ビデオやH.264はいつ再生するかを決める時刻情報（タイムスタンプ）を仕様上持っている。本来、映像と音声の厳密な同期や滑らかな再生を求める場合はMPEG2-TSを使ってストリームを送り、タイムスタンプに忠実に再生する必要がある。デジタルテレビ放送ではそれを行っている。Fig. 3の右側のプロトコルスタックがそれである。映像がカクつくのはMPEG2-TSを使わない場合で、タイムスタンプを使用せずに映像表示を行う場合である。この場合パケットロスが発生するとデコード待ちになって映像が一瞬停止し、再送されたパケットが届くとデコードが一気に進む。それをそのまま表示すると瞬間的に早送りしたようになる。それがカクカクして見える原因と思われる。このあたりの動作（デコードエラー時の扱いや映像の見せ方）は動画再生ソフトの実装に依存する。ちなみに、Fig. 3の矢印の説明のように、MPEG2-TSをRTPやSRTに載せてストリームを流し、タイムスタンプに忠実に再生することも可能である。

　MPEG2-TSを使わずに滑らかに再生するためには、パケットロスを抑えることに加えて、ジッターも抑える必要がある。通信上のジッターに関してはSRTのような通信プロトコルである程度制御できるが、動画圧縮に関してもジッター抑制の工夫が別途必要である。

　MPEG2ビデオやH.264では例えば１秒間に30フレームのピクチャデータを送るが、各フレームの形式としてI, P, Bの3種類のピクチャタイプが定義されている。Iピクチャは単独で復号可能なピクチャデータであり、Pピクチャは前方の、Bピクチャは前方・後方の両方のピクチャを参照して復号するピクチャデータである。I, P, Bの順にデータ量が少なくなる。例えば、Iピクチャの一部のデータが欠落して映像が乱れた場合、それを参照している後続のPピクチャ、Bピクチャの映像も乱れることになる。そして完全なデータを持つIピクチャが次に来た時に正しい映像に戻る。しかしながら、IピクチャはJPEGの静止画データをそのまま送っているようなもので、時間軸方向すなわちフレーム間での圧縮（動き補償）がないためデータ量が大きい。そこで、低遅延の映像伝送ではIピクチャを使わずにPピクチャだけを送るようにする。この場合、GDR (Gradually Decoder Refresh) ³⁾と呼ばれる手法が用いられる。これはPピクチャの一部のスライスに自己完結したデータ（イントラマクロブロック）を入れて、フレームごとにそのスライス位置を順にずらして巡回させることにより、Iピクチャを送ったのと同様の効果を得るものである。また、低遅延性が必要な場合には後方参照が必要なBピクチャはフレームの並び替えが発生するので基本的に用いない。例えば、Bピクチャが直後のピクチャを参照すると、60 fpsならば16.7 ms、30 fpsならば33.3 ms、平均して待たされることになる。通常数ピクチャ後方を参照することもあるため、それだけで遅延を100 ms以下に抑えることができなくなる。Bピクチャを使わないと圧縮率は落ちるので、ビットレートを低く保つためには各フレームの圧縮率を上げる、つまり画質の方を落とす必要がある。以上を要約すると、Pピクチャだけを使うことにより、各フレームのデータ量も比較的均一になり、ビットレートの変動すなわちジッターも抑えられる。ただし、低遅延性と画質はトレードオフの関係にある。

　遅延に関係する5GとWi-Fiの重要な違いの１つは、通信の開始の仕方である。Wi-FiではEthernetに似た通信方式が採用されている。これは同じチャネルで現在通信しているホストが他にいないか確認を行い、いなければ通信を開始するというもので、簡単に言えば、早い者勝ち方式で通信を始めるものである。言い換えると、誰かが通信を占有していると待たされる。そのため、Wi-Fiは通信端末数が少ない時は問題ないが、端末数が増えてくると通信帯域の奪い合いになり、リアルタイム通信に支障が出る。一方、5Gは基地局により通信のスケジューリングが行われる。また、サービス要件に応じて最適なセルや帯域を選択するトラフィックステアリングも検討されている。そのためリアルタイム性が必要な通信端末には一定の帯域を確保して優先的に通信を行わせることも将来的に可能である。通信帯域を仮想的に分割する技術はネットワークスライシングと呼ばれている。しかし、これらは2023年現在、まだあまり普及していないようである。

　次は映像伝送というより遠隔制御コマンドを低遅延で伝送する話であるが、ネットワークスライシングとは別の手法で低遅延性を保つ実験を行ってみた。オフィスや工場内で遠隔制御のロボットカーを走らせることを想定した場合、問題となるのが通信のカバーエリアである。通信エリア外になるとハンドオーバーが起きる。ハンドオーバーとは通信相手の基地局を切り替える処理のことで、通常数100 msから数秒はかかるようである。ハンドオーバー中は通信が途絶える。また、ミリ波のような波長が短い電波は直進性が高く、回折し難いので、電波が届かない死角ができる。そのため通信エリア内であっても、通信端末の前に人が立っただけで通信が途切れてしまう。クリティカルな遠隔制御を行っている時に少しでも通信が途絶えることは危険である。我々は通信が途絶えないように複数の通信経路を使って通信を保ったまま遠隔制御する実験を行った。具体的には、ロボットカーにパブリック5G (sub-6)、ローカル5G (sub-6)、ローカル5G（ミリ波）の3台の5Gルーターを搭載し、複数の通信経路を通ってロボットカーに同一の制御コマンドが届くようにした。同一コマンドが最大3回届くことになるが、2番目以降に届いた同一コマンドは破棄される。複数経路の生成にはMQTT (Message Queuing Telemetry Transport) の機能を利用した。遠隔制御端末（コマンド送信元）とロボットカーの間の通信経路上にエッジサーバーやクラウドサーバーを置き、その上でMQTTブローカーを走らせる。ロボットカー上のMQTTクライアントからそれぞれのMQTTブローカーへサブスクライブを行うことで、遠隔制御端末から発行される（パブリッシュされる）コマンドはそのMQTTブローカーを経由して届くことになる。この実験では遠隔制御端末からローカル5G (sub-6) の基地局経由でエッジサーバーに接続しているが、インターネットの先から同サーバーに接続しても構わない。こうして複数の通信経路から同一のコマンドが届く仕組みを構築した。

　当初、通信が途切れないことを主な目的として実験を始めたが、低遅延性を保つことにも有効であることが実験をしてみてわかった。Fig. 5は各通信経路から制御コマンドが到着するまでにかかった遅延時間を示すグラフである。今回の実験環境ではローカル5Gのミリ波の遅延時間が最も短い。そのため、ミリ波圏内にいる時、大抵はミリ波で届いた制御コマンドで制御が行われるが、sub-6から早く届く場合もあり、その場合はsub-6から届いたコマンドで制御する。結果として、このシステムでは常に最も低遅延で届いたコマンドを採用してロボットカーを制御することになり、接続の安定性とともに低遅延性も保たれる。

　前述したようにミリ波などでは基地局との間にある遮蔽物により通信が遮断されることがよくある。もし近くにあるモバイル端末やIoT機器も中継器として使用して多数の経路を確保できれば、接続性と低遅延性に関する安定度がさらに増す。モバイル端末の移動により近隣の機器との接続状態が頻繁に変わる状況でも接続を保つ技術としてMANET (Mobile Ad Hoc Network) ⁴⁾がある。将来的には、MANETを拡張してメッシュネットワークを構築することにより、安定した低遅延ネットワークが実現できるかもしれない。

　前述のロボットカーを使って、インターネット経由で実用的に遠隔制御が行えるかを確認するための実証実験を実施した。アンリツ社のご協力で、アンリツ本社（神奈川）にある5Gラボとコニカミノルタ高槻サイト（大阪）の５Gラボをインターネットで繋ぎ、ロボットカーに搭載したカメラの4K映像を見ながら、ロボットカーを遠隔制御した。Fig. 6はコニカミノルタの5Gラボにあるロボットカーに搭載した低遅延カメラの映像を約350km離れたアンリツ社から見ている映像である。低遅延カメラからローカル5Gで基地局に繋ぎ、そこからインターネットまでは光回線で通信を行った。また、ラボ間はVPNで接続した。それぞれのラボに設置したカメラを使って映像を往復させて、その往復時間で映像遅延を割り出した。往復時間は約150 ms、すなわち片道の遅延時間は70 ms～80 msであり、ロボットカーの操作は特に違和感なく行えた。また、別の実験では簡易的なアームを搭載したロボットカーの位置を微調整しながら台の前まで移動させ、台に置かれた対象物をアームで取り除くことも特に支障なく行えた。ちなみに、この実験でのpingの応答時間は20～40 msであった。ただし、インターネットの通信状況は通信環境や時間帯にも依存す るため、 常にこの程度の遅延時間で映像伝送が行えるわけではないことには注意が必要である。

　また、遠隔制御においては遅延時間以外に広い視野の確保も重要だと筆者は考える。人間の目の視野は周辺視野を含めて左右方向には約200度、上下方向には約130度と言われている。通常レンズの画角は60度以下であり、視野が狭いため遠隔制御が非常にしづらい。それを解決する手段としてFig. 6のように魚眼レンズで撮影してそれを平面化してパノラマ化、あるいは複数方向の映像を映すことが考えられる。このような場合に4Kの高精細映像が必要になる。また、高精細映像では遠方にある細かなものまで映っている。細かなものは直接目で見えなくても、AIの目で見ることは可能であり、AIによる画像解析を行う際に高精細映像は有用である。次に低遅延映像伝送とAIを連携した実証例について述べる。

　遠隔制御だけでなく、AIによる遠隔監視の場合にも映像伝送の低遅延性は重要である。例えば、AIにより危険予知を行って警報を鳴らす場合である。我々は魚眼映像をサーバーに送ってFORXAI（フォーサイ）骨格検出AI ⁵⁾で人検知するシステムを開発した。それをフォークリフトに取り付け、人がフォークリフトから一定の距離に接近した時に警報を鳴らす実証実験を行った。ミライト・ワン社のご協力でコニカミノルタの神戸サイトにある工場にローカル5G基地局を設置し、実験はそこで行われた。魚眼レンズを真下に向くようにしてフォークリフトの天井にカメラを取り付けるとFig. 7の右側の映像のようにフォークリフトの周囲360度方向が見渡せる。Fig. 7の左側の映像はフォークリフトの前後左右の映像を魚眼映像から切り取って平面化して表示したものである。魚眼映像上に白い円を描き、この円内で人の骨格が検知されると警報ブザーを鳴らす。Fig. 7はフォークリフトの右側にいる人の接近を検知して、赤線で検知方向、黄色の点で検知位置を示している。尚、フォークリフトの運転手は検知されるべきでないので、黒い円で検知の除外領域を設定している。この実験では4K/60 Mbps/60 fpsで映像遅延（画像処理前）が70 ms弱であった。人が白い円のエリアに侵入してからAIで検知して警報ブザーの鳴動指示を出すまでは200 ms程度である。遅延時間としては十分に実用的であることを確認した。単純なAI処理だけであればエッジ側（カメラ側）で行うことも可能であるが、今回の実験では魚眼映像の平面化処理などCPU負荷が高い処理を行う必要があったため、サーバー側で画像処理やAI処理を行い、画像処理後の映像をサーバーから読みだしてフォークリフト上の端末に表示した。

　今回の実験ではフォークリフトに搭載したカメラ映像だけで人の接近検知を行ったが、フォークリフトからは見えないところを映す俯瞰カメラの映像と連携して危険予知をすればさらに効果的である。また、人が手動で行う制御と違って、AIが自動的に判断して行う制御では遅延時間が可能な限りゼロに近い方が良い。したがって、今後さらに低遅延で安定した無線通信が求められるであろう。

　通信速度の場合は平均的にある速度以上出ていれば問題ないことが多いが、映像遅延の場合は平均的に遅延が小さいだけでは不十分である。ベストエフォートな低遅延ではあまり意味がなく、常にある値以下の遅延時間の保証が求められる。したがって、リアルタイムの映像伝送など低遅延技術で重要なことは、伝送のジッターを抑えつつ、パケットロスのない高信頼な通信を行って低遅延性を常に保つことである。そして、局所的な区間だけでなく、区間全体の低遅延化を図らなければならない。本論文では5G無線区間の高信頼・低遅延通信技術の詳細には言及しなかったが、その周辺の低遅延化技術について述べてきた。また、その技術を用いてどの程度の低遅延性が実現できているか実証例により紹介した。AIによる映像解析技術や自動制御技術の進展により、今後ますます映像伝送における低遅延技術が重要になってくると思われる。本論文がその参考になれば幸いである。