ページの先頭です。
このページの本文へ移動します。
 平日9:00-17:30  03-5210-5021

MCUの接続性について
3.相互接続性の向上について

MCU入門 第2回

MCU入門 第2回

MCUの接続性について – 3.相互接続性の向上について

2010年4月掲載
MCU入門 第2回 MCUの接続性について 目次
 

パソコンがここ10年で大きく性能を向上させたのと同様に、MCU / 多地点接続サーバーも処理能力を向上させてきました。
このため、より複雑な処理を、より短時間で行えるようになりました。

これまでは、端末に能力差があっても、護送船団方式的に、一番能力の低い端末にあわせた帯域・映像品質で、全ての端末がテレビ会議を行わざるを得ませんでした。
今では個別に接続を行う処理ができるようになったので、端末ごとに異なる帯域・映像品質で、自分の能力に最適化されたテレビ会議を行うことができるようになりました。

また、最新のMCU / 多地点接続サーバーは、後方互換性(過去のバージョンの端末でも、現在のバージョンのMCUと接続互換性があること)に優れています。
端末同士だと接続ができないときでも、MCU / 多地点接続サーバーを介することで、可能なことがあるほどです。

新しい機種が後方互換性をもっていたにもかかわらず、古い機種がちょっとした手抜きをしたために接続ができなかった例をあげます。

専用機で広く使われる映像プロトコルの標準は、時代と共に、H.261⇒H.263⇒H.264AVCと変化してきました。
H.264AVCを搭載している機種は、相手に「あなたが話せるのはH.264AVCですか?H.263ですか?H.261ですか?」と問合せをするのが基本です。
しかし、H.261しか搭載していない古い機種は、映像プロトコルが複数あることを前提としたつくりになっていませんでした。このため、無条件にH.261の送信を行ってしまい、H.264AVC搭載端末は、どの方法で解凍再生すればよいのかわからなくなって、「接続はできたが、映像が再生されない」という不具合が頻発したことがあります。

このとき、H.261にしか対応していない古い機種と、H.264AVCまで対応している新しい機種の両方を接続できるMCUを間に介すことによって、接続ができました。


標準準拠系の多地点接続について (H.323 / H.320 / SIPなど)

旧来のMCU / 多地点接続サーバー:

端末は、同帯域、同プロトコル、同解像度、同フレームレートで、MCUにデータを送信します。
MCUは、各端末からのデータをもとに映像にレイアウト処理を施し、全端末に同じデータを返送します。
このため、端末の能力が異なっていると、一番低い能力のものに、画質音質を合わせる必要がありました。

MCU / 多地点サーバーによる処理 護送船団方式

現在のMCU / 多地点接続サーバー:

端末からMCUに送信するデータは、MCUが対処可能な範囲ならば、各端末が全く異なるものであってもかまいません。
MCUは、各端末からのデータをもとに、映像音声を素材として統合し、各端末に合わせたレイアウト処理を施し、それを各個に返送します。このため、端末の能力が異なっていても、各端末に最適な画質音質のテレビ会議を行うことができます。
IP同士なら例えば「H.323⇔SIP」、IP同士ですらないISDNとIPの間であっても「H.320⇔H.323」などの「通訳」たるゲートウェイがいれば、利用できる言語(プロトコル)が違っていても、通信することができるのです。

MCU / 多地点サーバーによる処理 個別処理方式

PC会議系の多地点接続について (独自プロトコルなど)

PC会議系の場合は、他社と合わせる必要がないので、独自の世界を作ることができます。
バージョンなどの違いで接続性が悪くなる可能性を消すために、クライアントがサーバーに接続したときに、自動的にバージョンを合わせるのが昔からの主流です。

接続形態は2つあります。
1つは、上記のMCU / 多地点接続サーバーのように、中央集権的なサーバーが、データの受信・解凍・レイアウト処理・圧縮・送信を行うタイプ。
もう1つは、サーバー自体はデータを相手に届けるだけで、レイアウト処理その他を行わないタイプ。
前者のタイプは、前述の「標準準拠系の多地点接続」と同じと考えてよいので、説明は割愛します。
後者の「サーバー自体はデータを相手に届けるだけで、レイアウト処理その他を行わない」タイプについて、ご説明します。

旧来のMCU / 多地点接続サーバー:

端末は、同帯域、同プロトコル、同解像度、同フレームレートで、多地点接続サーバーにデータを送信します。
多地点接続サーバーは、各端末からのデータを接続している端末分だけコピーし、そのまま端末に転送します。 端末の都合は考えずに、単純にデータを転送するところは、リピーターハブのようなものです。 非常に単純なつくりなので、コストを抑えることができ、またサーバーの処理能力も高い必要はありません。

しかし、接続拠点数が増えれば増えるほど、サーバーから全端末に送信する帯域が膨大なものとなり、ネットワーク負荷が高くなります。
このため、少人数の会議には適当ですが、多人数の会議には不適です。
例えば、4拠点接続していると、各端末には自分以外の3拠点のデータが転送されます。よって、サーバーからは、3x4拠点分=12拠点分のデータが送信されます。10拠点接続のときは、9×10=90拠点分のデータが転送されます。
拠点側のPCも、これだけの量が転送されてくると、処理が追いつかなくなります。

PC会議系の多地点接続 旧来のMCU / 多地点サーバー

再生側のレイアウトやPCスペックによって、多地点サーバーから送信されるデータ量を 変えるので、ムダに帯域を消費しない。
(IPネットワークにおけるスイッチングハブのイメージ)

今のMCU / 多地点接続サーバー:

端末からサーバーに送信するデータは、対処可能な範囲ならば、各端末が全く異なるものであってもかまいません。

サーバーはこれとは別に、リアルタイムで端末側のレイアウト、CPUリソースやネットワークの状況を監視しています。サーバーは、監視データをもとに、送られてきた映像データの量を最適化して、各端末に転送します。どこにどんなデータを転送すればよいかを考えるところは、ネットワークでいうとスイッチングハブのようなものです。
受け取ったデータをもとに、映像を展開し再生します。
このため、端末の能力が異なっていても、各端末に最適な画質音質のテレビ会議を行うことができます。

旧来のものと同じで、データを転送するだけなので、処理遅延が原理的に発生しませんから、遅延が少ない会議を行うことができます。
リアルタイムでインテリジェントにデータ量を加減する点が旧来のものと異なるため、ネットワークリソースを無駄に使わないというメリットの他に、インターネットというベストエフォート型のネットワークを利用していても、ブロックノイズなどの映像不具合が発生しにくいメリットがあります。

PC会議系の多地点接続 今のMCU / 多地点接続サーバー

再生側のレイアウトやPCスペックにかかわらず、全拠点のデータが各拠点に送信される。
ムダな帯域を消費し、PCの負担も多い。(IPネットワークにおけるリピーターハブのイメージ)

上記の「旧来のMCU / 多地点接続サーバー」と「今のMCU / 多地点接続サーバー」の図を比べると、A・B・C・Dのいずれの拠点も同じ画面レイアウトですが、実際に受信しているデータ量(あるいはサーバーから送信しているデータ量)は、ずいぶん違うことが分かります。