JP2007521753A - 分散したｍｃｕ（マルチポイント制御ユニット） - Google Patents

Abstract

本発明は、カンファレンス・ネットワーク・システムに関し、特に、分散したビデオ・カンファレンス・システムにおいて、重み付け関数に従って、複数のエンド・ポイント（ＥＰ）のマルチサイト接続ユニット(ＭＣＵ)への最適の設定を自動的に行う方法に関する。更に本発明は、分散したカンファレンス・ネットワーク・システム内で、呼びを設定し、互いに接続された分散したＭＣＵを監視／管理する装置に関する。呼びに関する情報を収集し統合することにより、本発明の方法と装置は、特定のコマンドを、このコマンドを実行できるＭＣＵに送ることができる。

Description

本発明は、ビデオ・カンファレンス・ネットワーク装置に関し、特に、分散したビデオ・カンファレンス（テレビ会議）において、複数のエンド・ポイントのマルチ・サイト接続ユニットへの最適設定の生成と割り当てを自動的に行う方法と装置に関する。

本発明はさらに、分散したビデオ・カンファレンスにおいて、呼びに関連して接続されたマスターＭＣＵと１つあるいは複数のスレーブＭＣＵとを有する分散したＭＣＵを監視し、管理する方法と装置に関する。

ビデオ（画像）とオーディオ（音声）で会議設定する技術は、長距離通信を行うのに用いられる技術である。呼びの設定／管理の間に発生する多くの問題故に、カンファレンス（会議）を設定し管理するための多くの解決方法が、カンファレンスの設定管理を行う者に必要とされている。呼びの設定と会議の管理のジョブを容易にするために、大きな組織等のサービスプロバイダーがマルチポイント制御ユニット（Multi-point Control Unit (ＭＣＵ））と称する中央管理サーバーを用いている。ＭＣＵは、複数の参加者による呼びを取り扱うために用いられるサーバー、あるいは２人の参加者からｎ人の参加者までの呼びを中央で制御するサーバーである。

エンド・ポイント（ＥＰ）へアクセスのみを有することにより呼びを管理することは、実効性のある解決方法ではない。その理由は、ネットワーク・アクセスが制限されることおよび複数のベンダーからの装置、あるいは同一のベンダーからの異なる型式の装置を理解するために、トレーニングおよび教育が必要だからである。エンド・ポイント（ＥＰ）は、ビデオ・カンファレンスで使用されるビデオ／オーディオ端末／電話またはゲートウェイとして定義される。

中央サーバー（すなわち、ＭＣＵ）を有することにより、会議の管理者は、１つのインターフェースから呼びの大部分の態様を制御できる。多くのＭＣＵは、複数のカンファレンス（会議）が可能であるために、管理者は同一のインターフェースからの複数の呼びを監視することもできる。

現在、エンド・ポイントとＭＣＵの管理を補助する複数のシステムがある。例えばこのシステムの一例は、Ｐｏｌｕｃｏｍ ＧＭＳと、Ｐｏｌｙｃｏｍ Ｃｏｎｆｅｒｅｎｃｅ Ｓｕｉｔｅ（Ａｐｐｌｉｅｄ Ｇｌｏｂａｌ Ｔｅｃｈｎｏｌｏｇｉｅｓ（ＡＧＴ）ＶＣＡＳとしても公知）と、Ｆｏｒｇｅｎｔ ＶＮＰである。しかし、これらは、単一の呼びの設定および管理インターフェースの問題を解決することはできない。これらのシステムでは、管理者はネットワーク上の様々な機器を理解する必要がある。

Ｐｏｌｙｃｏｍ ＧＭＳは、エンド・ポイント間のみの呼びを監視することができる。Ｐｏｌｙｃｏｍ Ｃｏｎｆｅｒｅｎｃｅ Ｓｕｉｔｅ（ＡＧＴ ＶＣＡＳ）は、システム毎のレベルにおいて呼びを監視することができる。

Ｆｏｒｇｅｔ ＶＮＰは、システム毎のレベルで呼びの監視と呼びの設定が可能である。
ＴＡＮＤＢＥＲＧ Ｍａｎａｇｅｍｅｎｔ Ｓｕｉｔｅは、システム毎のレベルでの呼びの監視が可能である。

ビデオ・カンファレンス（テレビ会議）のさまざまな技術的側面を記載したいくつかの文献が存在する。

米国特許第６１５７４０１号明細書 欧州特許第１３５９７０８号明細書 米国特許第２００３／０１４３５７号明細書 米国特許第２００２／００７１０２６号明細書 米国特許第５５９４７２５号明細書 米国特許第２００２／００３２７０７号明細書 米国特許第６５９０６０３号明細書

特許文献１は、ビデオ・カンファレンス・システムで使用されるゲートキーパについて記載する。ゲートキーパにより、システム上でロギングされるＥＰのアリアス・アドレス（alias address）を制御している。アドレスが「組み合わせアドレス（compound address）」であるか否かがチェックされ、そのチェックが肯定的な場合には、ＭＣＵは、カンファレンス資源を指定された複数の参加者の間でのビデオ・カンファレンスに割り当てる。

特許文献２は、のビデオ通信端末からビデオ・カンファレンスの他の参加者との間のビデオ接続を創設する方法を記載している。

特許文献３は、ビデオ通信端末によるビデオ通信サービスと、関連するメッセージ・データ・フォームを呼び出す方法を記載している。具体的には、特許文献３は、ＭＣＵの使用によりビデオ・カンファレンスを設定し、発呼者に便利なカンファレンス・モードを設定する方法を記載している。

特許文献４は、仮想ビデオ・カンファレンス背景を組み込む装置と方法を記載している。具体的には、特許文献４は、システムにログインされたユーザーが、ビデオ・カンファレンス中にカメラ装置により通常検出されるデフォルトの背景以外の他の背景を指定しているか否かを決定する装置と方法を記載している。ユーザーが他の背景を指定している場合には、背景プロセッサが背景データベースからある背景を抽出し、ビデオ・カンファレンス装置がこの指定された背景を用いる。ユーザーが指定していない場合には、背景プロセッサは、可能性のある背景のリストを送信し、ユーザーはこのリストから好ましい背景を選択する。ユーザーが別の背景を選択することを望まない場合には、デフォルト背景が選択される。

特許文献５は、ビデオレートの制御用のプロセスとシステムを記載している。

特許文献６は、複数に織り込まれた画像（multi-threaded video）からアーティファクトをフィルタ除去する方法を記載している。

特許文献７は、流れているデータを管理するシステムと方法を記載している。

これらの文献は、多少なりとも、本発明のビデオ・カンファレンスの関連する態様を記載している。特許文献５、６、７は、ビデオ・カンファレンス技術の一般的な背景技術に含まれるものである。

既存のビデオ／オーディオ・カンファレンス・システムにより、管理者はシステム内に入り呼びを監視し編集することができる。ＴＭＳと、Ｆｏｒｇｅｔ ＶＮＰと、Ｐｏｌｙｃｏｍ Ｃｏｎｆｅｒｅｎｃｅ Ｓｕｉｔｅもまた呼びを設定するが、カスケード接続されたＭＣＵ接続を処理することはできず、あるいは一体物としてカンファレンスをシステム毎のレベルで監視することができるだけである。

中央サーバー（ＭＣＵ）を用いることにはいくつかの問題点がある。これらの問題点は、ピーク状態を処理する必要性から中央サーバーのサイズが大きくなりコストが上がる。全ての状態を処理するためには、ＭＣＵは、平均的な使用と平均的な会議参加者に対し、時に大きくなりすぎることがある。これは、多くのビジネス時間帯で通常発生するピーク状態を処理するのに必要なことである。通常この問題は、１個の会議のサイズに起因する問題ではなく、行われる会議の量にも起因する。ポイント・トゥ・ポイントの呼びも管理を必要とし、これらは中央サーバーを介してルーティングしなければならず、資源を必要とする。

サーバーを配置することにより呼びのコストが増加することは重要なファクターである。通常大容量中央集中サーバー（ＭＣＵ）はあまり存在しないので、全ての呼びは中央集中サーバーとの間でやり取り（ダイアル）しなければならない。例えば、企業が英国ロンドンにＭＣＵを有している場合には、呼びがスウェーデンとノルウェーとの間で行われた場合には、一方の呼びをスウェーデンのサイトとロンドンのＭＣＵとの間で設定し、別の呼びをノルウェーのサイトとロンドンのＭＣＵとの間で設定しなければならない。中央集中管理の必要性がない場合には、この呼びは、ノルウェーのサイトとスウェーデンとの間で直接行われる１個の呼びのみで行うことができる。

中央に集中したビデオ／オーディオ・カンファレンス・サーバーは、他のサーバーとは異なるものではなく、このサーバーが故障すれば、このサーバーを介してルーティングされた全ての呼びも中断される。すなわち単一故障である。

上記の問題点に関して、本発明の解決方法は次の利点を有する。

ピーク状態を処理する必要性により、サイズが大きくなったりコストが上がったりすることを大幅に低減できる。１個のカンファレンス・サーバー（ＭＣＵ）は必要とされないので、複数の小さな装置すなわちあるエンド・ポイントで直接利用可能なＭＣＵを使用することができる。ＭＣＵの容量を過剰に設定する必要はない。これは、ポイント・トゥ・ポイント（端末間）の呼びが直接ダイアルされるので、多数の会議を処理するオーバーヘッドが遙かに小さくなる。一方、１個のＭＣＵでは処理できないような多数の参加者がいる呼びは、多くの小さなＭＣＵの間で分割される。

大きなＭＣＵを必要とするような単一ポイントでの管理がもはや必要とされないために、多くの小さなＭＣＵを会社の事務所内に分散して配置することができ、かくして、サーバーを配置することに起因する呼びのコストを低減できる。多くのエンド・ポイントは、内部ＭＣＵ機能を有するため、あるいは呼びは２つのシステム間でのみ行われるために、外部にあるＭＣＵへダイアルする必要性がなく、呼びは、会議に関与するシステム間で直接行うことができる。

本発明の解決方法は、ある一部のＭＣＵに到達することができない、あるいはＭＣＵがダウンしている場合でも機能するために、単一ポイント故障（single point of failure）の問題はない。

本発明の目的は、従来技術の欠点を解決するために、前述した方法と装置を提供することである。

本発明の第１の態様は、分散したビデオ・カンファレンス・システムにおいて、複数のエンド・ポイント（ＥＰ）のマルチサイト接続ユニット（Multisite connection unit (ＭＣＵ)）への最適設定の生成と割り当てを自動的に行う方法において、第１ステップとして、必要とされるＭＣＵの数を、ビデオ・カンファレンス・セッションでの接続に必要とされるＥＰの数に基づいて、見積もるステップと、第２ステップとして、各ＥＰをＭＣＵに割り当てることにより、見積もりにより利用可能な十分の数のＭＣＵがあるかをチェックするステップと、第３ステップとして、ＥＰをＭＣＵに接続することにより、ＥＰのＭＣＵへの割り当てを最適化するステップとを含む。

計画されたミーティングがネットワーク上でいずれか１個のＭＣＵで利用可能な資源よりも多くの会議システムを含む時には、ＭＣＵをカスケード接続する必要がある。本発明は、カスケード接続されたＭＣＵの呼びも自動的に設定する。

ＥＰとＭＣＵは、ある場合には、同一の物理的機器でもよい。

本発明の第２の態様は、第１ステップとして、呼び中の装置からプロトコルと持続時間のような呼び情報を収集するステップを有する。その後、管理機能を受信した後、マスター装置が、特定のコマンドを実行できるかをチェックするステップと、マスター装置が前記コマンドを実行できない場合には、スレーブ装置が、特定のコマンドを実行できるかをチェックするステップと、マスター装置とスレーブ装置がこのコマンドを実行できない場合には、このコマンドが実行されることになるエンド・ポイント（ＥＰ）が、この特定のコマンドを実行できるかをチェックするステップと、特定のコマンドを実行できる装置上で、前記コマンドを実行するステップとを有する。最終ステップとして、前記特定のコマンドを実行できる装置に対し、前記装置上でコマンドを実行するステップを有する。

機器（デバイス）は、複数のビデオ・カンファレンスの呼びの設定で用いられる如何なる構成要素でも良い。すなわち、ＭＣＵ、ゲートウェイ（異なるネットワーク、例えばＩＰとＩＳＤＮを接続する機器）、ゲートキーパー（中央制御ポイントとして機能し、呼び制御サービスを登録されたエンド・ポイントに提供する機器）、ＥＰ等である。

上記の本発明の目的は、特許請求の範囲に記載した方法と装置により達成できる。

図１は、呼びが如何にしてシステムのグループ間で設定されるかの実施例を示す。上部の左部分には、３個のシステムが外部ＭＣＵ・Ａに接続されている。上部の右側には別の３個のシステムが外部ＭＣＵ・Ｂに接続されている。呼びがＭＣＵ・Ａと、ＭＣＵ・Ｂとの間に発生し、情報がこれら２つの間で転送される。図の下の方に、ＭＣＵ内に組み込まれたエンド・ポイントは、それに接続される別の２個のシステムを有する。これにより、１個の会議に全部で９つのエンド・ポイントが接続される。

本発明の第１部分は、全てのシステムを自動的に接続するよう呼びをルーティングすることである。これは、さまざまなファクター（呼びのコスト、品質、機能等）を参照して行われる。この方法により、呼びは中央ロケーションがなくても設定できる。

本発明の第２のユニークな部分は、１つあるいは複数のサービスが構築されたシステムを能動的に監視し管理することである。管理者は、１つのインターフェースを与えて呼びを設定し、監視し、管理する。例えば、会議に参加している人（その人のオーディオおよび／またはビデオ情報が他の参加者に与えられている）を変更するために、要求がＭＣＵ・Ａと、ＭＣＵ・Ｂと、内部ＭＣＵに送らなければならない。今日用いられている解決方法（管理者は、呼びの流れを変更するためにこれらのユニットのそれぞれに入って行かなければならない）の代わりに、本発明の管理者は、この設定を１つのロケーションで変更し、一連のアクションを呼びで必要とされるユニットに発生させる。これは、エンド・ユーザーが、呼びは中央にあるＭＣＵから管理されているように見えるようにして行われる。

図２は、２個の利用可能なＭＣＵで呼びを設定する一例を示す。同図は、本発明の方法が分散した呼びを如何に設定するかを示す。この実施例は、１４個のビデオ・カンファレンス・システムで行われる呼びに関連する。ユーザーが手動で分散したカンファレンス全体を設定する代わりに、本発明の方法は、カンファレンス・システムの数が１個のＭＣＵ上で利用可能な資源よりも多い時は、最適化されたカスケード接続されたマルチＭＣＵソリューションを自動的に生成する。

同図において、１４個のビデオ・カンファレンス・システムがあり、その内７個がアメリカ合衆国、テキサス州、Ｄａｌｌａｓにあり、４個がニューヨーク州にあり、３個がノルウェー、オスロのＬｙｓａｋｅｒにある。２個のＭＣＵがあり、１個はＤａｌｌａｓに、１個はＬｙｓａｋｅｒにある。ＤａｌｌａｓにあるＭＣＵは、システムの内１０個のシステムを保持できる十分な資源を有し、一方で、ＬｙｓａｋｅｒにあるＭＣＵは、８個のシステムを保持するのに十分な資源がある。
いずれのＭＣＵも１４個のシステム全部を保持する十分な資源を有していないために、２個のＭＣＵをカスケード接続する必要がある。Ｄａｌｌａｓからの７個のシステム全ては、それらは近い場所にあるために、ＤａｌｌａｓのＭＣＵに配置し、ニューヨークからの２個のシステムは、同一のＤａｌｌａｓのＭＣＵに配置する。残りの１０番目の資源を用いてノルウェーにある第２のＭＣＵにリンク接続する。ＤａｌｌａｓのＭＣＵは、現在は満杯状態なので、Ｌｙｓａｋｅｒにある３つのシステムをＬｙｓａｋｅｒのＭＣＵに置き、ニューヨークにある残りの２個のシステムをこのＬｙｓａｋｅｒのＭＣＵに置く。

図３Ａは、分散したＭＣＵの呼びを作り出すプロセスを示す。分散したビデオ・カンファレンス・システム内で複数のエンド・ポイント（ＥＰ）をマルチ・サイト接続ユニット（ＭＣＵ）に最適に設定することを自動的に生成し割り当てる方法は次のステップを含む。

第１ステップ１００は、重み付け関数に基づいて、利用可能なＭＣＵのＭＣＵ優先リストを生成する。この重み付け関数は、ＭＣＵの好ましい特性およびプロパティとＥＰの数に基づいている。これは、ＭＣＵ内の利用可能な処理資源の量とＭＣＵをＥＰに接続するのに必要なバンド幅資源である。このリストから最良のＭＣＵがマスターＭＣＵとして選択される。

次のステップ１１０は、必要とされるＭＣＵの数を予測することである。これは、現行のビデオ・カンファレンス・セッションの間に接続するのが必要なＥＰの数に基づいて行われる。ここから、ステップ１２０で十分なＭＣＵがあるか否かがチェックされる。十分なＭＣＵがない場合には、エラーメッセージがステップ１４０で表示され、分散したＭＣＵの呼びを創設するプロセスは停止する。十分なＭＣＵがある場合には、プロセスはいくつかのサブステップで継続する。

最初のサブステップ１３０は、ステップ１００で生成された優先リストから必要とされるＭＣＵを、選択されたＭＣＵを含むデータベースの「選択」リストに追加する。

次のサブステップ１６０では、マスターＭＣＵから、ステップ１３０で生成されたＭＣＵデータベースのリスト内の他のＭＣＵへの必要なリンクを計算する。

この後、サブステップ１７０が行われる。ここでは、マスターＭＣＵがビデオ・カンファレンス・リーダー（もしあれば）のＥＰに割り当てられる。このビデオ・カンファレンス・リーダーは、オーディオおよび／またはビデオ情報を他の全ての参加者に供給するＥＰである。

ステップ１８０において、ステップ１３０で生成された「選択」リスト内の次のＭＣＵが処理される。最初は、これはマスターＭＣＵであるが、次は、マスターＭＣＵの後、第２の最良の重みを持つＭＣＵである。

ステップ１９０において、各ＥＰに対する呼びの重みの計算が実行される。ここで、ＥＰとＭＣＵとの間の呼びのコストは、重みの中に含まれるファクターの１つである。この後、ステップ２００が行われ、ここで、各ＭＣＵ用のＥＰ優先リストが生成される。すなわち、各ＥＰから「選択された」リスト内の別のＭＣＵへの呼びの重みが、ステップ１３０で生成される。

ステップ２１０において、ステップ２００で生成されたＥＰ優先リスト内に残りのＥＰがあるかがチェックされる。ない場合には、ＥＰ優先リスト内の全てのエンド・ポイントが処理され、最適化ルーティンがステップ３００で開始される。これが成功すると、現行ビデオ・カンファレンス内の全てのシステムが最適の方法で互いに接続される。この最適化ルーティンは、図３Ｂを参照して、以下詳述する。

ＥＰ優先リスト内に残りのＥＰがある場合には、新たなテストがステップ２２０で実行され、ステップ１８０に従って処理された現行ＭＣＵが満杯かチェックされる。満杯でない場合には、ステップ２００で生成されたＥＰ優先リストの最初のＥＰが現行ＭＣＵに割り当てられる。これは、ステップ２３０で実行され、その後、ステップ２４０が実行される。ここで、最初のＥＰがＥＰ優先リストから外される。ステップ２１０、２２０、２３０、２４０を含むループが実行されるが、これは、全てのＥＰがＭＣＵに割り当てられるまで、あるいは現行ＭＣＵが満杯になるまで、すなわちその資源が使い切るまで行われる。これが当てはまる場合には、ステップ２５０が実行される。

ステップ２５０において、ステップ１３０で生成された「選択」リストが空か否かのテストが行われる。空でない場合には、上記のステップ１８０に再び入り、その後ステップ１９０、２００が実行される。「選択」リストが空の場合には、ステップ２６０で新たなＭＣＵが利用可能かどうかのチェックが行われる。利用可能な場合、ステップ２３０で実行された全ての割り当てられたＥＰがステップ２８０で割り当てから外され（de-allocated）、プロセスが再び新たなＭＣＵを選択リストに追加した（ステップ１５０）後、ステップ１６０から開始する。新たなＭＣＵが利用可能でない場合には、エラーメッセージがステップ２７０で生成される。

前述したステップで実行されたＥＰとＭＣＵの接続／割り当てを最適化することが望ましい。この理由は、あるケースでは、要求された資源は必要以上に遙かに多く、それ故に高価となるからである。

図３Ｂは、最終的に分散したＭＣＵルートを最適化するプロセスを示す。最適化方法は、全てのＥＰがＭＣＵに割り当てられた時、すなわちエラーメッセージが発生しなかった時に完了する。

最適化方法は、ステップ４００で開始し、これは、マスターＭＣＵを除く全てのからＥＰの割り当てを外すことにより行われる。割当除外リスト（de-allocated list）がステップ２３０で実行されたＥＰをＭＣＵに割り当てる優先リストから生成される。

ステップ４１０で、割当除外リストから次のＥＰが見いだされる。ステップ４３０で、割当除外リストから次のＭＣＵが見いだされる。ステップ４３０で、ＥＰとＭＣＵとの間のルートが創設される。この後ステップ４４０で、このルートをルート集団（collection of route）に追加する。

ステップ４５０で、割当除外ＭＣＵリストの終わりに到達したか否かがチェックされる。到達していない場合には、ステップ４２０に入り、ステップ４２０、４３０、４４０、４５０が実行されるが、これは、現行ＥＰと割当除外リスト内のＭＣＵとの間にルートが創設されるまで行われる。割当除外ＭＣＵリストの終了点に達すると、新たなテストがステップ４６０で実行される。このステップにおいては、ＥＰリストの終了点に到達したか否かがチェックされる。到達していない場合には、ＭＣＵの割当除外リストは、ステップ４７０で、最初の場所にリセットされ、ＥＰの割当除外リストから次ぎのＥＰが見いだされ、この後ステップ４２０−４６０が行われる。ステップ４６０が、ＥＰリストの終了点に到達したと報告したときには、ステップ４８０に入る。

ステップ４８０において、ステップ４００−４６０から得られたルート集団が最低のウエイトで分類される。

ステップ４９０において、分類したルート集団内のＥＰとＭＣＵとの間の次のルートが見いだされる。ステップ５００において、特定のＭＣＵに十分な資源があるか否かがチェックされる。ない場合には、最適化プロセスは失敗し、ステップ３００に入る前に示された元のソリューションが表示されて実行される。特定のＭＣＵに十分な資源がある場合には、ステップ５２０に入る。

ステップ５２０において、ルート内に含まれるＥＰがＭＣＵに割り当てられる。この後ステップ５３０が行われ、このルートが集団から取り除かれる。

ルートの集団内によりさらにルートは存在するか否かのチェックがステップ５４０で行われる。存在する場合には、ステップ４９０に再び入り、次のステップ５００−５３０が全てのルートにアクセスされるまで実行される。

最適化プロセスは、ステップ５５０で終了する。

上記の方法により、ビデオ・カンファレンス装置の間の呼びが効果的に安価な方法で設定され、中央集権化したロケーションを用いずに設定される。

図３Ａと３Ｂに関して記載した方法は、ベストモードであり、それ故に好ましいステップを含む。この方法の変更も可能であり、しかしそれも本発明の範囲内に入る。

本発明はまた、上記の方法に従った、分散したビデオ・カンファレンス・システム内の複数のＥＰをＭＣＵへ最適な割り当てを自動的に行う装置に関する。

本発明の第２の目的は、ネットワーク内の複数のビデオ・カンファレンス装置を監視し管理する方法と装置を提供することである。ビデオ・カンファレンス装置は、ビデオ・カンファレンスの設定の際に含まれるあらゆる機器であり、例えば、内部ＭＣＵの有無を問わないエンド・ポイント、ゲートウェイ、ゲートキーパー、ＭＣＵ等である。

監視（Monitoring）とは、呼びと参加者とそれらの状態に関する情報を見ることである。

管理（Administration）とは、参加者の状態を変更すること、参加者を追加すること、参加者と外すこと等である。

ビデオ・カンファレンスを監視し管理することは、ビデオ・カンファレンスに参加する装置の設定を成功裏に完了した後行われる。

本発明の方法は、第１ステップとして、呼び中の装置からプロトコルと持続時間のような呼び情報を収集する。このステップは、各ビデオ・カンファレンス装置に対し、処理を促進するためにキャッシュに利用可能なさまざまな機能に対するサポート・レベルを行わせることにより実行する。このステップの後、管理機能を受信した後、マスター装置（通常、ＭＣＵ，この方法におけるマスター装置は、カスケード接続された呼びマスターＭＣＵ（内部ＭＣＵ）か、カスケード接続されていない呼びのＭＣＵ（外部ＭＣＵ）か、ポイント間の呼びでは最大の機能を有するエンドポイントのいずれかである）が、特定のコマンド（無言（mute）、発言権（floor）、音量（volume））を実行できるかをチェックするステップが行われる。更にこの後、マスター装置が前記コマンドを実行できない場合には、スレーブ装置が、特定のコマンドを実行できるかをチェックするステップが続く。更にその後、マスター装置とスレーブ装置がこのコマンドを実行できない場合には、このコマンドが実行されることになるエンド・ポイント（ＥＰ）が、この特定のコマンドを実行できるかをチェックするステップが行われる。最終ステップとして、前記特定のコマンドを実行できる装置に対し、前記装置上でコマンドが実行される。

監視し管理しているユーザー・インターフェースは、ビデオ・カンファレンス装置に動作可能に接続されている。すなわち、中央にあるサーバーからこれらのタスクを実行する必要はない。

次の３つの実施例においては、監視し管理する本発明の方法を用いた例が記載される。この場合、複数のシステムが接続され、呼びに係属するものとする。

さまざまな場合において、一人の管理者が、１つのインターフェースが全ての呼びを監視し管理することを望み、以下の説明は、これが本発明の方法により如何に行われるかを示す。

ケース：ポイント・トゥ・ポイント（Point-to-point）
監視：呼び情報は、ポイント・トゥ・ポイント（ポイント間）のカンファレンスにある複数のシステムの１つから集められる。この１つのシステムは、最大機能（ＭｕｌｔｉＳｉｔｅ、ＩＳＤＮバンド幅）を具備したシステムとして選択される。このシステムは、マスター・システムと称する。この情報は、プロトコル、会議継続時間等に関する情報を含む。この１つのシステムが、関連外（out-of-house）のシステムの場合には、関連（in-house）システムが、この情報を集めるのに用いられる。

管理：管理機能が、システムの能力に応じて、カンファレンス上で実行される時には、マスター・システムが最初にチェックされる。機能がそのマスター・システム上で実行できない場合には、他のシステムを用いてこの機能を実行する。この他のシステムが、関連システムでない場合には、この機能は実行不可能となる（どのようなシステムもこれに反して機能を実行することはできない）。通常、音量（volume）、無言（mute）が、それを制御しようとするエンド・ポイントで制御され、一方、会議の継続、参加者の追加と脱退、発言権制御（floor control）が、マスター・システムで行われる。

ケース：ＭＣＵ（内部または外部）
監視：呼び情報が、ＭＣＵであるＭＣＵカンファレンス内のシステムから集められる。このシステムは、マスター・システムと称する。この情報は、プロトコル、継続時間等に関する情報を含む。

管理：管理機能が、システムの能力に応じて、カンファレンス上で実行される時には、マスター・システムが最初にチェックされる。機能がそのマスター・システム上で実行できない場合には、その機能を実行することになるシステムがチェックされる（例、ＭＣＵが無言（mute）をサポートしない場合には、無言は無言状態におかれるべきサイトで実行される）。他のシステムが、関連システムでない場合には、この機能は実行不可能となる（どのようなシステムもこれに反して機能を実行することはできない）。通常、音量、無言（内部ＭＣＵにおいて）が、それを制御しようとする個々のエンド・ポイントで制御され、一方、会議の継続、参加者の追加と脱退、無言（外部ＭＣＵにおいて）、発言権制御が、マスター・システム（ＭＣＵ、内部または外部のＭＣＵのいずれか）で行われる。

ケース：カスケード接続／分散ＭＣＵ（内部または外部）
監視：呼び情報が、カンファレンス内でＭＣＵとして機能する全てのシステムから集められる。あるシステムがカスケード接続／分散のトップにある場合には、このシステムが、マスター・システムと呼ばれる。この集められた情報は、プロトコルと会議継続時間等に関する情報を含む。

管理：管理機能が、システムの能力に応じて、カンファレンス上で実行される時には、マスター・システム（マスターＭＣＵ）が最初にチェックされる。機能がそのマスター・システム上で実行できない場合には、他のＭＣＵのおのおの（スレーブＭＣＵ）がチェックされる。このスレーブＭＣＵがこの機能をサポートしない時は、この機能を実行することになるシステムがチェックされる（例、マスターＭＣＵとスレーブＭＣＵが無言（mute）をサポートしない場合には、無言は無言状態におかれるべきサイトで実行される）。他のシステムが、関連システムでない場合には、この機能は実行不可能となる（どのようなシステムもこれに反して機能を実行することはできない）。通常、音量、無言（内部ＭＣＵにおいて）が、それを制御しようとする個々のエンド・ポイントで制御され、一方、会議の継続、参加者の追加と脱退、無言（外部ＭＣＵにおいて）が、マスターＭＣＵあるいはスレーブＭＣＵで実行され、、発言権制御が、マスター・システム（ＭＣＵ、内部または外部のＭＣＵのいずれか）で行われる。

本発明の方法と実際のシステム制御が如何に行われるかは、システム毎に異なる。ＴＮＡＤＢＥＲＧシステムは、他の競業製品（ＲａｄＶｉｓｉｏｎ、Ｐｏｌｙｃｏｍ、Ｅｚｅｎｉａ）等とは別の方法で管理機能をサポートしている。主要な点は、各システムは、さまざまな機能用にそのサポートレベルを利用可能にしている点である。呼び情報を集めるために、個々のシステムの状態が組み合わされる（最適化するために、多くの場合このような情報をマスター・システムに問い合わせるだけでよい）。しかし、管理を行うためには、本発明の方法／装置によれば、機能の実行は、最初にマスター・システムで、その後スレーブＭＣＵ（それらが用いられている場合には）で、最後に個々のシステムで試みる。

その結果は、大部分の場合そして大部分の特徴でもって、マスター・システムのみにアクセスするだけでよく、その結果、ＩＰネットワーク問題に起因する接続を失う機会が減ることになる。常時接続がマスター・システムでは可能となっているために、多くの機能にアクセスでき、そして、全てのシステムに接続する必要はない。

本発明の方法は、全てのカンファレンスを制御する１つのスクリーンと１つの方法を管理者に与え、それらは、ポイント・トゥ・ポイント、内部ＭＣＵ、外部ＭＣＵ、あるいは分散／カスケード接続したカンファレンスを問わない。これにより、同レベルの監視と管理機能を有するために、全ての呼びがそこを通らなければならない大きなＭＣＵを必要としない。

以上の説明は、本発明の一実施例に関するもので、この技術分野の当業者であれば、本発明の種々の変形例を考え得るが、それらはいずれも本発明の技術的範囲に包含される。特許請求の範囲の構成要素の後に記載した括弧内の番号は、図面の部品番号に対応し、発明の容易なる理解の為に付したものであり、発明を限定的に解釈するために用いてはならない。また、同一番号でも明細書と特許請求の範囲の部品名は必ずしも同一ではない。これは上記した理由による。

システムのグループ間で呼びを設定するためのブロック図。 ２個の利用可能なＭＣＵで呼びを設定するためのブロック図。 本発明の方法により分散された呼びのソリューションの一例を示すフローチャート図。 図３Ａに示されたフローチャート図を最適化ステップの部分を示す図。

符号の説明

図１
エンドポイント（内部ＭＣＵの有無を問わない）
図２
ダラス・システム、リサカー・システム、ニューヨーク・システム
図３Ａ
１００ ＩＳＤＮバンド幅によりＭＣＵを分類し、トップのＭＣＵ（マスター）を「選択 リスト」に追加する
１１０ 必要とされるＭＣＵを見積もる
１２０ ＭＣＵは十分か？
１３０ 必要とされるＭＣＵを「選択」リストに追加する
１４０ エラー
１５０ 新たなＭＣＵを「選択」リストに追加する
１６０ マスターからスレーブへのリンクを計算する
１７０ ビデオ・カンファレンス・リーダーをマスターＭＣＵに追加する
１８０ 「選択」リスト内の次のＭＣＵを処理する
１９０ ＭＣＵからＥＰへの呼びのコストに基づいて、各エンドポイントに対する呼びの 重みを計算する
２００ 最低の呼びコスト重みによりＥＰリストを分類する
２１０ ＥＰは残っているか？
２２０ ＭＣＵは満杯か？
２３０ ＥＰリスト内の最初のエンドポイントを割り当てる
２４０ ＥＰリストから最初のＥＰを取り除く
２５０ ＭＣＵ「選択」リストは空か？
２６０ 新たなＭＣＵは利用可能か？
２７０ エラー
２８０ 全てのエンドポイントの割り当てを外す、全てフリーにする
３００ 最適化（図３Ｂの４００）
３１０ 完了
図３Ｂ
４００ マスターＭＣＵを除く全のＭＣＵからエンドポイントの割り当てを外す
４１０ 割当除外リストから次のエンドポイントを得る
４２０ 割当除外リストから次のＭＣＵを得る
４３０ ＭＣＵとエンドポイントとの間のルートを創設する
４４０ ルートをルート集団に追加する
４５０ ＭＣＵリストの終わりか？
４６０ エンドポイントリストの終わりか？
４７０ ＭＣＵリストを最初の位置にリセットする
４８０ 呼びの最低ウエイトによりルート集団を分類する
４９０ 次のルートを得る
５００ ＭＣＵ上の資源は十分か？
５１０ 出口 最適化が失敗し、元のソリューションを提示する
５２０ ルート内に含まれるエンドポイントをこのＭＣＵに割り当てる
５３０ 集団からルートを外す
５４０ 更にルートがあるか？
５５０ 完了

Claims (25)

1. 分散したビデオ・カンファレンス・システムにおいて、複数のエンド・ポイント（ＥＰ）をマルチサイト接続ユニット（Multi site connection unit (ＭＣＵ)）への最適の設定を自動的に行う方法において、
   （ａ） 必要とされるＭＣＵの数を、ビデオ・カンファレンス・セッションで接続するのに必要とされるＥＰの数に基づいて、見積もるステップと、
   （ｂ） 各ＥＰをＭＣＵに割り当てることにより、見積もり値により利用可能な十分の数のＭＣＵがあるかをチェックするステップと、
   （ｃ） 重み付け関数に従って、ＥＰをＭＣＵに割り当てることにより、ＥＰのＭＣＵの割り当てを最適化するステップと
   を有する
   ことを特徴とする分散したテレビ会議システムにおいて複数のエンドポイントをマルチサイト接続ユニットへ最適に設定することを自動的に行う方法。
2. 前記ステップ（ａ）は、
   （ａａ） 重み付け関数に基づいて、およびＭＣＵの好ましい特性あるいはプロパティ、およびＥＰの数に基づいて、利用可能なＭＣＵ優先リストを生成するステップと、
   （ａｂ） 最適の重みを有するＭＣＵをマスターＭＣＵとして選択するステップと
   を有する
   ことを特徴とする請求項１記載の方法。
3. 前記ステップ（ｂ）は、
   （ｂａ） マスターＭＣＵから、ＭＣＵ優先リスト内の他のＭＣＵへの必要なリンクを計算するステップと、
   （ｂｂ） 前記マスターＭＣＵをビデオ・カンファレンス・リーダーのＥＰ（もしあれば）に割り当てるステップと、
   （ｂｃ） 各ＥＰに対する呼びの重みを計算するステップと、
   ＥＰとＭＣＵとの間の呼びのコストは、重み内に含まれる係数であり、
   （ｂｄ） 各ＭＣＵに対し、ＥＰ優先リストを生成するステップと、
   （ｂｅ） ＥＰとＭＣＵに対し、生成された優先リストに従って、各ＥＰをＭＣＵに割り当てるステップと
   を有する
   ことを特徴とする請求項１記載の方法。
4. 前記ステップ（ｃ）は、
   （ｃａ） ＥＰをＭＣＵに割り当てる生成された優先リストから、マスターＭＣＵ以外の全てのＭＣＵからＥＰの割り当てを外すリストを生成するステップと、
   （ｃｂ） ＭＣＵの割り当てを外すリスト内の各ＥＰと各ＭＣＵとの間のルートを生成するステップと、
   （ｃｃ） これらのルートの集団を具備したリストに追加するステップと、
   （ｃｄ） ルートの集団を具備したリストを最低の重みの呼びにより分類するステップと、
   （ｃｅ） 十分な資源がＭＣＵ上で利用可能な場合には、ルートの集団内に含まれる各ＥＰを最も好ましいＭＣＵに割り当て、このＥＰが存在する分類されたリスト中の他の全てのルートを除くステップと
   を有する
   ことを特徴とする請求項１記載の方法。
5. 生成されたＭＣＵ優先リストは、計画されたミーティング時におけるロケーション、バンド幅、チャネルにより分類される
   ことを特徴とする請求項２記載の方法。
6. 呼びの重みの計算は、バンド幅のファクターを含む
   ことを特徴とする請求項３記載の方法。
7. 前記生成されたＥＰ優先リストは、異なる重み付けファクターにより分類され、
   コストとバンド幅が優先ファクターに含まれる
   ことを特徴とする請求項３記載の方法。
8. 各ＥＰをＭＣＵに割り当てることは、利用可能なＭＣＵの分類されたリストに従って行われる
   ことを特徴とする請求項３記載の方法。
9. 各ＥＰをＭＣＵに割り当てることは、全てのＥＰがＭＣＵに割り当てられるまで行われる
   ことを特徴とする請求項３記載の方法。
10. 各割り当てられたＥＰは、ＥＰの優先リスト内のＭＣＵ上の資源の不足に起因して、１つあるいは複数のＥＰが割り当てられなかった場合は、割り当てから外される
    ことを特徴とする請求項３記載の方法。
11. 前のＭＣＵが占有されている時には、ＥＰは、優先リスト上の次のＭＣＵに割り当てられる
    ことを特徴とする請求項３記載の方法。
12. ルートの集団内に含まれるＥＰをそのＭＣＵに割り当てることが中止され、
    前記最適化ステップの前に、割り当てられたルートが、問題となっているＭＣＵに対し、十分な資源がない場合に選択される
    ことを特徴とする請求項４記載の方法。
13. 生成されたＥＰ優先リストは、重み付けファクターの内の１つのファクターにより分類される
    ことを特徴とする請求項７記載の方法。
14. 生成されたＥＰ優先リストは、重み付けファクターにより分類される
    ことを特徴とする請求項７記載の方法。
15. 前記割り当てから外されたＥＰは、新たなＭＣＵ優先リストに追加した後、再度割り当てられる
    ことを特徴とする請求項１０記載の方法。
16. 分散したビデオ・カンファレンス・システムにおいて、複数のエンド・ポイント（ＥＰ）をマルチサイト接続ユニット（Multi site connection unit (ＭＣＵ)）への最適の設定を自動的に行う装置において、
    （ａ） 必要とされるＭＣＵの数を、ビデオ・カンファレンス・セッションで接続するのに必要とされるＥＰの数に基づいて、見積もる見積もりユニット（予測する予測ユニット？）と、
    （ｂ） 各ＥＰをＭＣＵに割り当てることにより、見積もり値により利用可能な十分の数のＭＣＵがあるかをチェックするチェック・ユニットと、
    （ｃ） 重み付け関数に従って、ＥＰをＭＣＵに割り当てることによりＥＰのＭＣＵの割り当てを最適化する最適化ユニットと
    を有する
    ことを特徴とする分散したテレビ会議システムにおいて複数のエンドポイントをマルチサイト接続ユニットへ最適に設定することを自動的に行う装置。
17. 前記見積もりユニット（予測ユニット）（ａ）は、
    （ａａ） 重み付け関数に基づいて、およびＭＣＵの好ましい特性あるいはプロパティ、およびＥＰの数に基づいて、利用可能なＭＣＵ優先リストを生成する手段と、
    （ａｂ） 最適の重みを有するＭＣＵをマスターＭＣＵとして選択する手段と
    を有する
    ことを特徴とする請求項１６記載の装置。
18. 前記チェック・ユニット（ｂ）は、
    （ｂａ） マスターＭＣＵから、ＭＣＵ優先リスト内の他のＭＣＵへの必要なリンクを計算する手段と、
    （ｂｂ） 前記マスターＭＣＵをビデオ・カンファレンス・リーダーのＥＰ（もしあれば）に割り当てる手段と、
    （ｂｃ） 各ＥＰに対する呼びの重みを計算する手段と、
    ＥＰとＭＣＵとの間の呼びのコストは、重み内に含まれる係数であり、
    （ｂｄ） 各ＭＣＵに対し、ＥＰ優先リストを生成する手段と、
    （ｂｅ） ＥＰとＭＣＵに対し、生成された優先リストに従って、各ＥＰをＭＣＵに割り当てる手段と
    を有する
    ことを特徴とする請求項１６記載の装置。
19. 前記最適化ユニット（ｃ）は、
    （ｃａ） ＥＰをＭＣＵに割り当てる生成された優先リストから、マスターＭＣＵ以外の全てのＭＣＵからＥＰの割り当てを外すリストを生成する手段と、
    （ｃｂ） ＭＣＵの割り当てを外すリスト内の各ＥＰと各ＭＣＵとの間のルートを生成する手段と、
    （ｃｃ） これらのルートの集団を具備したリストに追加する手段と、
    （ｃｄ） ルートの集団を具備したリストを最低の重みの呼びにより分類する手段と、
    （ｃｅ） 十分な資源がＭＣＵ上で利用可能な場合には、ルートの集団内に含まれる各ＥＰを最も好ましいＭＣＵに割り当てる手段と
    を有する
    ことを特徴とする請求項１６記載の装置。
20. （ａ） 呼び内の装置からプロトコルと持続時間のような呼び情報を収集するステップと、
    （ｂ） 装置が、管理機能を受信した後、特定のコマンドを実行できるかをチェックするステップと、
    （ｃ） 前記特定のコマンドを実行できる装置に対し、装置上でコマンドを実行するステップと
    を有する
    ことを特徴とするネットワーク内において複数のテレビ会議装置を監視／管理する方法。
21. 前記ステップ（ｂ）は、
    （ｂａ） マスター装置が、管理機能を受信すると、特定のコマンドを実行できるかをチェックするステップと、
    （ｂｂ） スレーブ装置が、マスター装置が前記コマンドを実行できない場合には、特定のコマンドを実行できるかをチェックするステップと、
    （ｂｃ） マスター装置とスレーブ装置がこのコマンドを実行できない場合には、コマンドが実行されるエンド・ポイント（ＥＰ）がこの特定のコマンドを実行できるかをチェックするステップと、
    （ｂｄ） 特定のコマンドを実行できる装置上で前記コマンドを実行するステップと
    を有する
    ことを特徴とする請求項２０記載の方法。
22. 前記ステップ（ａ）は、各ビデオ・カンファレンス装置が、処理を促進するためにキャッシュに利用可能なさまざまな機能に対するサポート・レベルを行わせることにより実行する
    ことを特徴とする請求項２０記載の方法。
23. 監視し、管理しているユーザー・インターフェースは、ビデオ・カンファレンス装置に動作可能に接続されている
    ことを特徴とする請求項２０記載の方法。
24. （ａ） 呼び内の装置からプロトコルと持続時間のような呼び情報を収集する受領手段と、
    （ｂ） 装置が、管理機能を受信した後、特定のコマンドを実行できるかをチェックする手段と、
    （ｃ） 前記特定のコマンドを実行できる装置に対し、装置上でコマンドを実行する手段と
    を有する
    ことを特徴とするネットワーク内において複数のテレビ会議装置を監視／管理する装置。
25. 前記チェックする手段（ｂ）は、
    （ｂａ） マスター装置が、管理機能を受信すると、特定のコマンドを実行できるかをチェックする手段と、
    （ｂｂ） スレーブ装置が、マスター装置が前記コマンドを実行できない場合には、特定のコマンドを実行できるかをチェックする手段と、
    （ｂｃ） マスター装置とスレーブ装置がこのコマンドを実行できない場合には、コマンドが実行されるエンド・ポイント（ＥＰ）がこの特定のコマンドを実行できるかをチェックする手段と、
    （ｂｄ） 特定のコマンドを実行できる装置上で前記コマンドを実行する手段と
    を有する
    ことを特徴とする請求項２４記載の装置。

Images