2年半ほど前から,家庭向けのIPv6ルーターを開発している。今では,IPv6 の世界が具体的にイメージできるようになっているが,私が参加した当時は「IPv6 のキラー・アプリケーションは何か?」といった議論がしばしば技術者の間で交わされていた。議論の中で,「IPv6を,パソコンでなく家電で動かすのはどうか」――という意見が出た。この延長線上に,今の開発テーマである「IEEE1394 で AV 機器を接続し,IPv6で映像を流す」というアプリケーションがある。最近では,これと平行してインターネットで映像を配信するシステムの開発も手がけている。

 開発している機能としては,(1)IEEE1394 デバイスドライバ,(2)IP over IEEE1394,(3)IEEE1394 通信とIP 通信を中継するアプリケーション,(4)MPEG2 over IEEE1394およびDV over IEEE1394 である。このうち,IP over IEEE1394は,IPv4 版が RFC2734 として標準化されており,IPv6 版は RFC への最終段階にある。これは,IPv6ルーターがAV家電とIP通信するための機能であるが,残念ながらIP通信機能を持つAV機器がないのが現状である。

 そこで,「IEEE1394 通信と IP 通信を中継するアプリケーション」と「MPEG2 over IEEE1394 および DV over IEEE1394」の開発を始めた。中継アプリケーションとは,IEEE1394 端末とIP端末間通信のゲートウェイ機能のことである。これらを組み合わせれば,IP通信機能を持たない AV 機器もインターネットに接続できる。本来ならAV機器にIPアドレスを割り当てるところだが,それまでの移行期間にはこうした機能も必要になるはずだ。AV機器としては,D-VHSビデオデッキ,HDDビデオレコーダー,BSデジタルチューナー,DVカメラ,DVデッキ,テレビなどを想定している。私の実験室には,パソコンなどの IP 機器と一緒にこれらのAV機器が並んでいる。

 開発項目はいくつかあるが,IP 通信とIEEE1394通信を中継するゲートウェイが一番難しい。単純にIP+UDPヘッダーをIEEE1394ヘッダーに置き換えるだけではすまない。IPパケットのサイズと到着間隔が,IEEE1394で送り出すときのパケット・サイズと送出間隔とは違ってくるからだ。これらを IEEE1394の仕様に合わせて計算しなおす必要があり,そこではマイクロ秒単位の高い精度が求められる。これをリアルタイム系OSではなく,UNIXのような汎用OS上で実現するのは,なかなか骨が折れる。

 アドレスの問題もある。IPとIEEE1394ではアドレス体系が違う。このため,外部からAV機器をどのように指定すればいいのか(アドレッシングするか)を考える必要がある。こちらはまだ具体的な解決策が見えていない。

 家電のIP化そのものは,IPv6だから難しいということでもない。IPv4とIPv6の違いはそれほどなく,アドレスだけともいえる。実際,IPv6で動くアプリケーションはたいていIPv4でも動くように実装されているし,われわれもそうしている。IPv6ならではの何らかの機能を求めたというのではなく,グローバル・アドレスを家電に割り当てられることが重要だった。

 ただし家電ならではの制約はある。CPUは処理能力が乏しく,メモリ容量は小さい。これらを十分に考慮する必要がある。とくにIPsecは,関連するコードの量が多いだけでなく,処理にかかる負荷も重い。

 動画伝送の開発に取り組んで改めて感じたのは,「やっぱりリアルタイム通信にはIEEE1394が適している」ということ。IPでリアルタイム通信を実現するときは,帯域保証や遅延,時刻同期をどうやって確保するのかに頭を痛める。この悩みがIEEE1394を使うとなくなる。IEEE1394自身が実行してくれるからだ。その一方で,IEEE1394ではタイム・スタンプの計算や送出間隔がマイクロ秒単位と細かく,取り扱いに苦労した。これほど精密な動作は,IPにはとても期待できない。

 IPにも帯域保証のしくみとしてdiffservがある。ただ,IPの帯域保証は統計的に保証するものであり,パケット・ロスを完全に防ぐといった保証はできない。頻繁なパケット・ロスは映像伝送に好ましくない。というのは,映像信号は前後の画像情報を加味して圧縮符号化されるので,一つでもパケットが落ちるとそれ以降のパケットに入っている情報を正しく復号化できなくなり,画像が大きく乱れるという問題があるからだ。

 WWWのようなファイル転送型のアプリケーションなら,パケット・ロスが生じたら再送制御機能でパケットを送信し直してもらえばいい。だが,映像のようなリアルタイム性の要求されるアプリケーションでは,せっかく再送しても,そのパケットを使うべき場面はすでに処理されてしまっているので単純な再送制御は役に立たない。例えばインターネット放送のような形態,つまり片方向で多数の受信者がいる通信形態では,特定の受信者のためだけに再送することは現実的でない。

 遅延については,IPでは遅延のないように中継することは原理的に難しい。もともとIPは,ルーターでいったんデータをストアしてから別のルーターに中継するという蓄積交換型の中継方式であるからだ。

 ただしインターネット放送で重要なのは,遅延の大きさではなく,個々のパケットの遅延を一定にすることである。遅延間隔がゆらぐと適切に映像を再現できないからだ。そこで映像伝送では,受信側に大きめのバッファを用意し,ここで遅延のゆらぎを吸収して遅延時間が一定になるように工夫している。

 インターネット放送では,遅延のほかにも“時間”に関係する課題が二つある。一つは,送信側と受信側との間で時刻を合わせること。いわゆる時刻同期だ。ただし,これはさほど大きな問題ではない。

 重要なのはもう一つの課題である。それは,送信側のクロックと受信側のクロックを合わせること。つまり,送信側の1秒と受信側の1秒が,マイクロ秒単位で同じであるようにすることだ。これがずれると,送信側の映像送出速度と受信側でのデコード速度がずれ,どこかでバッファが溢れたり,バッファのデータがなくなってしまったりする。実際に実験してみたが,映像送信間隔をわずか1マイクロ秒ずらしただけでも,映像にブロック・ノイズが出た。

 BSデジタル放送やIEEE1394は,定期的に同期信号を送ることで時刻の同期とクロックの同期を実現している。しかしIPは同期信号を持っていないので,送信側のクロックと受信側のクロックを同じにできない。NTPと呼ぶ時刻同期手順を使えば,その瞬間はかなり高い精度で時刻を合わせることができるが,時間とともに時刻とクロックはずれていく。

 動画伝送やIEEE1394では,時間の考え方が厳密でなければならない。おそらく映像を扱っている人には常識なのかもしれないが,IP分野から飛び込んだ私には,それらは新鮮な驚きだった。



IEEE1394
 ディジタル・データをやりとりするためのシリアル・バス規格。リアルタイム通信に優れるという特徴を持つ。iLink という名称で呼ばれることもある。最近のディジタルAV機器は,たいてい備えている。IEEE1394 を使う規格としては,「MPEG2 over IEEE1394」,「IP over IEEE1394」,AV機器を遠隔操作するための「AV/C コマンド規格」などがある。
MPEG2
 moving picture experts group-2の略。ディジタル動画および音声を圧縮符号化するための規格の一つ。データ転送レートは数M~数十Mビット/秒。DVDやBSデジタル放送で採用されている。
DV
 digital videoの略。ディジタル動画および音声を圧縮符号化するための規格の一つ。MPEG2 と違い,フレーム内で完結する圧縮方式である。
diffserv
 IPレベルでサービス品質を実現する技術の一つ。IPフローをいくつかのクラスに分け,そのクラスごとに優先制御を行う。クラスの識別子はIPヘッダーの中に埋め込んで通信する。
デコード速度
 圧縮符号化されたデータを復号化するスピード。
ブロック・ノイズ
 表示画像の乱れ。高いレートで圧縮符号化したデータを復号化したときや,復号化するためのデータが一部欠けている場合に発生する。

酒井 淳一
入社と同時に家庭向けIPv6ルーターの開発に取り組む。テーマは,AV機器とインターネットの接続。IEEE1394 でAV機器をIPv6ルーターに接続する部分や,インターネット経由で映像をAV機器に配信するシステムなどのソフトウエアを開発している。