IP通信で構築するビデオ監視システム（2/2 ページ）

[Gordon Wilkinson（米Trinity Convergence社），EDN]

ハードウエアの構成

　ドアエントリシステムの端末は、通常、マンション/オフィスの壁や机に設置される。その端末を構成するのは、まず、マイクが接続されるアンプやA-Dコンバータ、スピーカが接続されるD-Aコンバータやアンプである（図3）。これらはオーディオコーデックに集積されていることが多い。ほかには、アナログもしくはデジタルのビデオカメラや液晶パネルなどのディスプレイ、有線/無線LANインターフェース、V2IPやそのほかの処理を行うアプリケーションプロセッサを備える。さらに、ビデオのエンコードを行うコプロセッサも搭載する。プロセッサ上では、OSのアプリケーション層でV2IPを取り扱うソフトウエアが稼働する。このソフトウエアは、音声/映像の処理とSIP通話制御の処理を担う。

図3　V2IP端末のハードウエア構成　

　ほとんどの端末では、何らかの形の組み込みOSが稼働している。OSは独自のものでもよいが、民生製品や通信業界では組み込みLinuxや「Windows CE」が使用される傾向にある。これらのOSを利用するには、搭載するプロセッサ向けのBSP（Board Support Package）を開発するか、ライセンスを購入する必要がある。このBSPには、ドライバやOSを構成するファイルシステム、CPUやメモリーI/Oなどのリソースを管理するカーネル、周辺機器を制御するドライバが含まれる。

　OSは、ドライバを介してオーディオコーデックやカメラ、ディスプレイなどの周辺機器を制御する。Linuxでは、OSS（Open Sound System）やALSA（Advanced Linux Sound Architecture）などの音声用標準インターフェースと、V4L2（Video for Linux Two）などの映像用標準インターフェースを提供することにより、異なるハードウエア間におけるソフトウエアの移植性を高めている。周辺機器メーカーの多くも、自社製品用のLinuxドライバを無償で提供していることが多い。

　多くのICベンダーは、自社製品用のリファレンスプラットフォームを提供している。それを利用することにより、設計者は、ハードウエアの設計をより迅速に進めることができる。そうしたプラットフォームには、端末の設計に必要な周辺機器のほとんどが、設計情報とともに含まれているからだ。また、BSPもソースコードに含まれている場合が多く、設計者はそのプラットフォームを開始点として、ソフトウエアやハードウエアを開発することができる。

通信の仕組み

　端末間で通話を行うためには、ドアエントリシステムであればマンション入り口の装置と各戸内の端末など、2つの機器間の接続を確立する必要がある。小規模なネットワークの場合、IPアドレスまたは独自のプロトコルを用いて、容易に相手を選択して接続することができるだろう。しかし、2つの端末がインターネットを介して接続されるのならば、SIPを用いるほうがよい。なぜなら、ネゴシエーションを適切に処理し、安全で信頼性の高い通信を確立することができるからである。

　SIPを用いる場合、まず最初に、端末はSIPサーバーに自分の存在を知らせる。このSIPサーバーは、ネットワークにおけるほかのSIPユーザーを検出して特定するための手段として用いられる。SIPユーザーは、電子メールアドレスと同じ形式の識別名を持つ。例えば「[e-mail]」などといった具合だ。ここで「sipservice」の部分は、SIPネットワークのサービスプロバイダを表している。

　あるSIPユーザーがほかのSIPユーザーとの通話を希望する場合、通話を希望するSIPユーザーがインビテーション（招待状）を相手のSIPユーザーに送信し、相手のSIPユーザーはIPアドレスあてにメディアデータを直接送信したほうが効率的である。従って、インビテーションには、サポートするオーディオ/ビデオコーデックなどの端末の機能を示す情報が必要となる。

　SIPサーバーは、ルックアップサービスを用いてインビテーションをリモートの通信相手の端末へと送信する。リモートの端末は、自分の機能と接続情報を、送信元の端末に応答として直接返す。このようなネゴシエーションが完了すると、音声と映像による通話が開始される。

　2者間の簡単な接続のほかに、SIPでは、通話の転送や保留、音声メール、インスタントメッセージなどの高度なサービスも提供する。ドアエントリシステムで行われるような音声/映像による通話は、オーディオストリームとビデオストリームから構成される。これらのデータストリームは、ネットワーク内で互いに独立しており、それぞれを処理するソフトウエアの多くも個別のものとなる。従って、端末においては、これらを統合して同期させることによって、ユーザーが問題なくシステムを利用できるようにする必要がある。

　マイクやカメラからネットワークまでの間には、オーディオ/ビデオのドライバがあり、コーデックのデータバッファに保持された音声/映像を受信する。この処理の後、音声に対してはAEC（Acoustic Echo Cancellation：音響エコーキャンセレーション）が行われる。AECによって、全二重やハンズフリーのスピーカホンの利用が可能になる。この処理には、機器固有の音響特性に対するチューニングが必要となる。AEC処理に続いて、ビデオの前処理が行われる。その際には、ビデオストリームのリサイズや回転、ミラーリングなどの処理が施される。次に、ネットワークにおいて必要となる帯域幅を低減するために、エンコードによってデータストリームが圧縮される。

　帯域幅は、コーデックの性能と画像サイズを決定する要因の1つである。スピーチコーデックの符号化方式には、一般的にITU-T（International Telecommunication Union Telecommunication Standardization Sector）のG.729が利用される。また、ビデオ用によく使用されているのはH.264である。

　一連の処理の後、データストリームをネットワーク上に伝送するために分割するパケット化が行われる。受信側でストリームを再構成するために、各パケットにはRTP（Realtime Transport Protocol）ヘッダーが必要となる。RTPヘッダーには、シーケンス番号、タイムスタンプ、ストリームに一意的に対応する番号などのフィールドがある。次に、UDP（User Datagram Protocol）/IP処理が行われる。この処理では、RTPヘッダーを備えるパケットがIPスタックに引き渡され、判明した送信先アドレスに対応するUDPヘッダーが付加される。

　受信側では、IPパケットからデータストリームを復元し、デコード処理が行われる。まず、受信したIPパケットは、受信端末のUDP/IPスタックで処理される。ここには、ジッターバッファと呼ばれるバッファがあり、RTPヘッダーの情報に基づいて受信パケットからデータストリームが組み立てられる。このバッファの管理機能は、PLC（Packet Loss Concealment：パケットロス補償）技術を用いて、順序の誤りや損失パケットを処理する。これが装置のQoS（Quality of Service）を担う中心的な存在である。デコード処理では、データストリームがデコードされて、オーディオ/ビデオドライバへと引き渡される。最終的に、受信端末側で音声/映像が再生されることとなる。

ソフトウエアの構成

図4　V2IP端末のソフトウエア構成　

　端末がリアルタイムに動作するには、上述した全機能が単一のV2IPモジュールによって働くと見なせる状態でなければならない。すなわち、個々の機能が正しい順序で実行され、すべてが同一の処理装置内に共存し、装置が必要とするほかの任意のアプリケーションと共に動作する必要がある。さらに、V2IPモジュールは、管理ドライバによる低消費電力モードへの移行や、アドレス帳からの直接通話が行えるように、アプリケーション層からのアクセスが可能でなければならない。

　上述したことを満たせるようにするための最良の方法は、VoIPとVideo over IPを低レベルで処理するフレームワークを利用することである（図4）。このフレームワークは、個々の処理を専門に実行する独立したモジュールで構成される。その目的は、製品の設計/開発を全体的に加速することである。　フレームワーク内のモジュールは、リアルタイムアプリケーションで管理する。このアプリケーションは、入出力データをリアルタイムで処理し、モジュールの動作をAPI（Application Programming Interface）の集合によって定義する。フレームワークとアプリケーションの相互作用をAPIで表現することにより、アプリケーションのコードを各モジュール内の各コンポーントの処理スケジューリングにおいて抽象化することができる。

　また、リアルタイムアプリケーションは、コーデックやAEC、フレームレート、画像のサイズ、帯域幅といった主要な要素の制御を実現する。すなわち、ネットワークの状況に応じた最大の利用効率をユーザーに提供することが可能だ。

　リアルタイムアプリケーションは、発信/応答といったユーザーによる操作に間接的に対応し、ユーザーはGUI（グラフィカルユーザーインターフェース）によって操作に対応するコマンドを入力する。GUIの基盤には、電話帳、データベース、通話/メッセージの履歴などをサポートするためのサービスアプリケーションがある。GUIとサービスアプリケーションは、リアルタイムアプリケーションとは異なり、リアルタイムではなくイベント駆動であるという点で共通している。リアルタイム処理とイベント駆動処理の2つの間には隔たりがあり、2つの層の間で通信するには、図4におけるイベントルーターのような通信パスを確立する必要がある。イベントルーターは、システムにおけるイベント駆動の部分とリアルタイム処理の部分との間のメッセージ伝送を行う。そのメッセージには、プロトコルを使用してキューメカニズムを提供する必要がある。

　今日では、GUIからサービスアプリエーション、リアルタイムアプリケーションに至るまで、すべてのアプリケーションを含む既製ソフトウエアを、サードパーティのベンダーから入手することが可能になっている。

　ここまでに述べてきたように、ビデオ監視システムをIP化することには、アナログ技術を用いたポイントツーポイントのシステムにおける接続性の欠点を解消できるという大きな利点がある。ただし、技術的な観点から見ると、アナログからデジタルのパケットスイッチシステムへ移行するのは、簡単なことではない。

　しかし、システム上の各要素の開発を外部に委託し、チップ/ソフトウエアのベンダーとともに作業することにより、その負担は大きく軽減できるだろう。特に、スピーチ/ビデオコーデック、エコーキャンセレーション、通話制御といったすべての機能が、構造化されたモジュールの集合として統合されたソフトウエアを活用することをお勧めする。それだけでも、製品の開発期間は短縮され、市場投入までの期間が大幅に改善することになるだろう。