(57)【要約】      （修正有）【課題】ネットワークやサーバの負荷や遅延が小さい多地点間通信システム及び方法並びにプログラムを提供する。【解決手段】中継ネットワーク２０に地理的に分散配備された複数の仮想サーバインフラ３０において動作する互いにカスケード接続可能な多地点接続装置（ＭＣＵ：Multipoint Control Unit）４０と、ＭＣＵ管理ノード５０を備える。ＭＣＵ管理ノード５０は、グループ通信の実施中に、多地点接続装置４０の配置計算処理を行うとともに、この配置計算処理の算出結果に基づき、端末１０から多地点接続装置４０との間で張られているセッションを他の多地点接続装置４０との間に張り替えるよう制御する。【選択図】図３
2019125997.tif 000002
【特許請求の範囲】
【請求項１】
ネットワークに収容された複数の端末間でグループ通信を行う多地点間通信システムであって、
前記ネットワーク内に地理的に分散配備された複数のサーバにおいて動作し且つ前記複数の端末との間にセッションを張りグループ通信に係る通信トラヒックを集約する１つ以上の多地点接続機能であって、他の多地点接続機能とカスケード接続することにより前記複数の端末に対して単一のグループ通信が実施されているように動作可能な多地点接続機能と、
グループ通信で用いる多地点接続機能の配置を算出する配置計算処理手段と、
グループ通信の実施中に前記配置計算処理手段により配置計算処理を行うとともに、この配置計算処理の算出結果に基づき、端末から多地点接続機能との間で張られているセッションを他の多地点接続機能との間に張り替えるよう制御する多地点接続機能制御手段とを備えた
ことを特徴とする多地点間通信システム。
【請求項２】
前記多地点接続機能制御手段は、前記多地点接続機能間の通信品質、前記多地点接続機能と端末間の通信品質、前記グループ通信に参加する端末数の何れか又は任意の組み合わせに基づき、前記配置計算処理手段による配置計算を実施するか否かを判定する
ことを特徴とする請求項１記載の多地点間通信システム。
【請求項３】
前記配置計算処理手段は、グループ通信に係る通信トラヒックを中継するノードから取得したネットワーク負荷情報の増減に基づき多地点接続機能の配置を算出する
ことを特徴とする請求項１又は２記載の多地点間通信システム。
【請求項４】
前記多地点接続制御手段は、上りトラヒックに係るセッションと下りトラヒックに係るセッションとを別々に張り替える
ことを特徴とする請求項１乃至３何れか１項記載の多地点間通信システム。
【請求項５】
前記配置計算処理手段は、グループ通信に参加する端末毎に当該端末が前記ネットワーク内の最上位ルータまでの最短経路内で利用可能な前記サーバのサーバ情報を保持しておき、前記サーバ情報に基づき複数の端末で重複して利用可能なサーバに限定し、且つ、優先順位付けを行い、この限定情報及び優先順位情報に基づき、多地点通信接続機能の配置場所を計算する
ことを特徴とする請求項１乃至４何れか１項記載の多地点間通信システム。
【請求項６】
前記配置計算処理手段は、過去に多地点通信接続機能の配置場所計算で利用したサーバ間及び端末・サーバ間の通信コストを記憶しておき、この通信コスト情報を利用して他の多地点通信接続機能の配置場所計算を行う
ことを特徴とする請求項１乃至５何れか１項記載の多地点間通信システム。
【請求項７】
前記ネットワーク内に端末に対して最近傍に配備された複数のサーバにおいて動作し且つ前記複数の端末とのセッション管理のみを行いグループ通信に係る通信トラヒックを集約することなく転送する１つ以上の第１の転送機能を備え、
前記多地点接続制御手段は、多地点間接続機能と前記第１の転送機能との間のセッションを張り替える
ことを特徴とする請求項１乃至６何れか１項記載の多地点間通信システム。
【請求項８】
前記多地点接続制御手段は、前記サーバで動作する多地点間接続機能を、当該サーバにおいて動作し且つ前記複数の端末とのセッション管理のみを行いグループ通信に係る通信トラヒックを集約することなく転送する第２の転送機能として動作するよう切り替え制御を行うとともに、他の多地点間接続機能と前記切り替え前の多地点接続機能との間に張られていたセッションを前記他の多地点間接続機能と切り替え後の前記第２の転送機能との間の端末毎のセッションに張り替える
ことを特徴とする請求項１乃至７何れか１項記載の多地点間通信システム。
【請求項９】
ネットワークに収容された複数の端末間でグループ通信を行う多地点間通信方法であって、
他の多地点接続機能とカスケード接続することにより前記複数の端末に対して単一のグループ通信が実施されているように動作可能な多地点接続機能が動作する複数のサーバを前記ネットワーク内に地理的に分散配備し、
グループ通信で用いる多地点接続機能の配置を算出する配置計算処理手段と、
グループ通信の実施中に、
配置計算処理手段が、グループ通信で用いる多地点接続機能の配置を算出し、
多地点接続機能制御手段が、前記配置計算処理の算出結果に基づき、端末から多地点接続機能との間で張られているセッションを他の多地点接続機能との間に張り替えるよう制御する
ことを特徴とする多地点間通信方法。
【請求項１０】
コンピュータを請求項１記載の配置計算処理手段及び多地点接続機能制御手段として動作させることを特徴とする多地点間通信プログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、多地点接続機能を交流点として複数の端末間でグループ通信を行う多地点間通信システムに関する。
【背景技術】
【０００２】
近年、４Ｋ／８Ｋなど超高精細カメラ／ディスプレイ装置やＡＲ（拡張現実：Augmented Reality）／ＶＲ（仮想現実：Virtual Reality）技術の発達とあわせ、省エネやワークライフバランスを目的とした各企業のテレワーク推奨施策等により、ネットワークを介した映像コミュニケーションサービスへの需要が高まっている。
【０００３】
映像コミュニケーションサービスの代表例として映像会議が挙げられる。映像会議システムを構成する上で良く知られる装置として多地点接続装置（ＭＣＵ：Multipoint Control Unit）が挙げられる。ＭＣＵは、グループ通信の交流点としてネットワークに配置される装置であり、映像会議システム用のＭＣＵは、全ユーザ端末からの映像／音声パケットを受信したのち、各参加者の映像を１つの画面に合成して、全ユーザ端末に映像／音声を配信する装置である。
【０００４】
ＭＣＵを用いた多地点間映像会議では、Ｐ２Ｐ（Peer to Peer）方式の多地点映像会議と比べて端末負荷が下げられる一方で、ＭＣＵサーバの計算負荷およびネットワーク負荷が増大するという課題がある。ＭＣＵのネットワーク負荷低減方法の一例として、複数のＭＣＵを地理的に分散配備したシステムが知られている（例えば、特許文献１参照）。このシステムでは、例えば、大阪エリアと東京エリアとで会議参加端末を収容するＭＣＵを分離しつつ、大阪のＭＣＵと東京のＭＣＵとをカスケード接続させる。大阪エリアの複数端末の会議参加者映像は大阪のＭＣＵにおいて１画面に合成された状態で東京のＭＣＵへ送出される。また逆方向も同様、東京エリアの複数ユーザの会議参加者映像が東京のＭＣＵにおいて１画面に合成された状態で大阪のＭＣＵへ送出される。このようなシステムにより、東京−大阪間のネットワーク帯域の増加を抑制することができる。
【先行技術文献】
【特許文献】
【０００５】
【特許文献１】特許第３４５７２０２号公報
【特許文献２】特開第２００３−６９５６３号公報
【発明の概要】
【発明が解決しようとする課題】
【０００６】
上述の特許文献１に記載の方法によれば、複数のＭＣＵをカスケード接続しているので、会議参加端末数が増大した場合または映像品質レートをより高品質にしようとした場合においても、中継ネットワークや他網との相互接続部（ゲートウェイ）におけるネットワーク負荷の増大を防ぐことができると期待される。しかし、映像会議の参加者やネットワーク負荷は時々刻々と変わるため、最もネットワーク負荷の小さいＭＣＵ配置場所も変化する。上述の特許文献１に記載の方法では、ＭＣＵの動的な配置場所変更ができないため、ネットワークの負荷軽減ができないという課題がある。
【０００７】
そこで、特許文献２に記載されているように、地理的に分散配備されたＭＣＵ群の中から、会議が発生するごとに参加端末の構成に応じて利用するＭＣＵを動的に変更させる方法が提案されている。この方法では、会議が開催される度に最適な（たとえば会議によって発生するネットワークトラヒックを最小限にするような）ＭＣＵを選択することができるので、初期の設計に縛られることなく参加者エリア構成に応じて効果的な中継ネットワーク帯域節約が可能となる。また、あるＭＣＵが故障した場合においても、他の候補ＭＣＵを選択すればよいので会議の開催が可能となる。
【０００８】
しかし、特許文献２に記載のものは、会議ごとに単一のＭＣＵを選出する方法が与えられているのみであって、会議参加端末の地域的な偏り等に応じて効果的に複数のＭＣＵを選出しカスケード接続させる方法については言及されていない。またＭＣＵの配置場所の候補は、配置可能な場所と参加者の増加に伴って指数関数的に増加するため、最もネットワーク負荷最小となる最適配置が現実的な時間で探索できないという課題もある。
【０００９】
本発明は上記事情に鑑みてなされたものであり、その目的とするところは、ネットワークやサーバの負荷や遅延が小さい多地点間通信システム及び方法並びにプログラムを提供することにある。
【課題を解決するための手段】
【００１０】
上記目的を達成するために、本願発明は、ネットワークに収容された複数の端末間でグループ通信を行う多地点間通信システムであって、前記ネットワーク内に地理的に分散配備された複数のサーバにおいて動作し且つ前記複数の端末との間にセッションを張りグループ通信に係る通信トラヒックを集約する１つ以上の多地点接続機能であって、他の多地点接続機能とカスケード接続することにより前記複数の端末に対して単一のグループ通信が実施されているように動作可能な多地点接続機能と、グループ通信で用いる多地点接続機能の配置を算出する配置計算処理手段と、グループ通信の実施中に前記配置計算処理手段により配置計算処理を行うとともに、この配置計算処理の算出結果に基づき、端末から多地点接続機能との間で張られているセッションを他の多地点接続機能との間に張り替えるよう制御する多地点接続機能制御手段とを備えたことを特徴とする。
【発明の効果】
【００１１】
本発明によれば、グループ通信実施中においてもグループ参加者の増減やネットワーク負荷の変動に応じて多地点接続機能の配置場所を変更することで、グループ通信を中断することなくネットワークのサーバ、回線帯域負荷を低減することができる。
【図面の簡単な説明】
【００１２】
【図１】本発明の概要を説明する図
【図２】本発明の概要を説明する図
【図３】多地点間会議システムのシステム構成図
【図４】インフラ管理ノード、ＭＣＵ管理ノード及び仮想サーバインフラの機能ブロック図
【図５】再配置制御部及び分散ＭＣＵの機能ブロック図
【図６】端末数の増減による再配置判定方法を説明するフローチャート
【図７】ネットワーク輻輳による再配置判定方法を説明するフローチャート
【図８】分散ＭＣＵの負荷による再配置判定を説明するフローチャート
【図９】既にカスケード接続済みの分散ＭＣＵ１と分散ＭＣＵ２間で端末Ａのセッションを張り替える手順を示す図
【図１０】実施例１に係るセッション張り替え手順を説明する図
【図１１】上下別にセッションを張り替える手順を説明する図（１／２）
【図１２】上下別にセッションを張り替える手順を説明する図（２／２）
【図１３】実施例２に係るセッション張り替え手順を説明する図（１／２）
【図１４】実施例２に係るセッション張り替え手順を説明する図（２／２）
【図１５】実施例２の変形例に係るセッション張り替え手順を説明する図（１／２）
【図１６】実施例２の変形例に係るセッション張り替え手順を説明する図（２／２）
【図１７】実施例３に係るセッション張り替え手順を説明する図（１／２）
【図１８】実施例３に係るセッション張り替え手順を説明する図（２／２）
【図１９】実施例４に係る多地点間会議システムのシステム構成図
【図２０】実施例４に係る多地点間会議システムにおける通信経路の変更を説明する図
【図２１】実施例４に係るセッション張り替え手順を説明する図（１／２）
【図２２】実施例４に係るセッション張り替え手順を説明する図（２／２）
【図２３】ＭＣＵ管理ノードとインフラ管理ノードの事業者が異なる場合の例
【図２４】実施例５に係る多地点間会議システムにおける通信経路の変更を説明する図
【図２５】実施例５に係る通信経路変更手順を説明する図
【図２６】分散MCU配置計算アルゴリズムの一例を説明するフローチャート
【図２７】仮想サーバインフラ、端末間の帯域利用コスト計算例を説明する図
【図２８】端末毎に利用可能な仮想サーバインフラの優先度を説明する図
【発明を実施するための形態】
【００１３】
以降の説明では多地点接続機能を映像会議における多地点接続装置（ＭＣＵ：Multipoint Control Unit）として機能するものとして説明する。
【００１４】
まず、本発明の概要について図１及び図２を参照して説明する。本発明は、図１（ｂ）に示すように、端末１の上位の中継ネットワークに地理的に分散して存在する仮想サーバインフラ２に、ＭＣＵ機能３を分散配置し、分散したＭＣＵ３間はカスケード接続することで一つのＭＣＵのように振る舞わせる。またそれぞれのＭＣＵ３は、同一の会議参加者の映像を合成／縮小して他のＭＣＵ機能３へ映像を転送することで通信帯域の削減を行う。以上を実現するためにＭＣＵ管理機能４を配置する。
【００１５】
一方、図１（ａ）に示す従来技術では、ＭＣＵ３は全体で１つ配備されているのみであり、全会議参加端末１の画像を合成して、各参加端末１に配信している。このため、映像トラヒックが１つのＭＣＵ３に集中するという課題がある。一方、本発明では、図１（ｂ）に示すように、分散配備された各ＭＣＵ３においてエリア毎に一次とりまとめ画面合成を行い、各ＭＣＵ３間で前記一次とりまとめ画面を交換して最終合成を行い、各参加端末１に配信する。これにより、中継ネットワークの利用が一画面の帯域で済むという利点がある。
【００１６】
そして本発明では、図２に示すように、ＭＣＵ管理機能４により、会議参加者の増減や、仮想サーバインフラ２、回線帯域などのネットワーク負荷が変動した際に、会議情報を分散されたＭＣＵ３間で引き継ぎ、ＭＣＵ機能３の配置を動的に変更することを特徴とする。なお、図２は、会議途中にユーザが途中参加し、ＭＣＵの配置場所を変更する例を示している。
【００１７】
次に、本発明のより具体的な実施形態について図３を参照して説明する。図３は多地点間会議システムのシステム構成図である。
【００１８】
図３に示すように、多地点間会議システムは、複数の端末１０と、複数地域にまたがる中継ネットワーク２０と、地理的に分散配備された仮想サーバインフラ３０と、前記仮想サーバインフラ３０上に配備された分散ＭＣＵ４０と、前記仮想サーバインフラ３０及び分散ＭＣＵ４０を制御するＭＣＵ管理ノード５０及びインフラ管理ノード６０と、を含んで構成される。
【００１９】
中継ネットワーク２０は地理的に分散して構築された複数の地域ネットワークの相互接続により構成された論理的なネットワークであり、地理的に分散配備された複数のルータ２５を含む。本実施の形態における中継ネットワーク２０のネットワークトポロジーは、図３に示すように、ルータ２５をノードとするツリー構造であるものとする。中継ネットワーク２０は、ツリー構造の最上位のルータ２５を介して、他網であるインターネット７０に接続している。
【００２０】
各ルータ２５の近傍には仮想サーバインフラ３０が存在する。任意の仮想サーバインフラ３０はインフラ管理ノード６０からの指示により分散ＭＣＵアプリケーションを起動、終了できる。
【００２１】
端末１０は、例えばスピーカー、マイクなどを備えるコンピュータであり、仮想サーバインフラ３０上に起動している何れかの分散ＭＣＵ４０とセッションを確立して映像会議を行う。
【００２２】
仮想サーバインフラ３０は仮想ハイパーバイザ（または仮想ホスト）であり、ＭＣＵ４０は仮想マシン（ＶＭ：Virtual Machine）上で動作するアプリケーションの実体（インスタンス）である。
【００２３】
インフラ管理ノード６０は中継ネットワーク２０全体を管理しており、端末−ルータ間、ルータ−ルータ間の回線帯域使用率、仮想サーバインフラ使用率（ＣＰＵ（Central Processing Unit）、ＧＰＵ（Graphics Processing Unit）、メモリ、ストレージ利用率等）をリアルタイムに監視している。監視方法としては、例えばＳＮＭＰ（Simple Network Management Protocol）を用いることで各ルータ２５のポート別送受信量、ＣＰＵ利用率、メモリ利用率などを取得できる。
【００２４】
ＭＣＵ管理ノード５０は、全開催会議情報（仮想会議室識別子、会議開催分散ＭＣＵ、分散ＭＣＵ毎の端末割当、端末識別子等）を管理し、分散ＭＣＵ４０への会議割当、端末１０への分散ＭＣＵ４０の割当、分散ＭＣＵ４０の起動、終了指示、分散ＭＣＵ４０間のカスケード接続指示等を行う。
【００２５】
なお仮想サーバインフラ３０、分散ＭＣＵ４０、ＭＣＵ管理ノード５０は中継ネットワーク２０内に限定されず、例えばインターネット７０等の他網上にあっても良い。また本実施の形態では説明は省略するが、分散ＭＣＵ４０は端末１０が持つことも考えられる。
【００２６】
映像会議を行う際、仮想会議室が一つまたは複数の分散ＭＣＵ４０上に開催され、会議に参加する端末１０は何れかの分散ＭＣＵ４０とセッションを確立する。一つまたは複数の分散ＭＣＵ４０は、セッションを確立している端末１０の映像を取得及び合成し、他の分散ＭＣＵ４０へ合成した映像を転送する。分散ＭＣＵ４０は他の分散ＭＣＵ４０から取得した合成済みの映像を取得し、自身が合成した映像と更に合成して、自身とセッションを確立している全端末１０に、全参加ユーザが合成された映像を転送する。映像の合成方法としては他に、それぞれの分散ＭＣＵ機能４０が、セッションを確立している端末１０の映像を合成せずに縮小だけして他の分散ＭＣＵ４０へ送信し、各分散ＭＣＵ４０は全ての映像が揃ってから合成を行う方法も考えられる。
【００２７】
次に、インフラ管理ノード、ＭＣＵ管理ノード、仮想サーバインフラ、端末の構成について図４を参照して説明する。図４は、インフラ管理ノード、ＭＣＵ管理ノード、仮想サーバインフラの機能ブロック図である。
【００２８】
各仮想サーバインフラ３０は、サーバ・ネットワーク負荷監視部３１と、負荷情報送信部３２と、アプリケーション管理部３３と、当該仮想サーバインフラ３０上で動作する分散ＭＣＵ４０とを備えている。
【００２９】
ＭＣＵ管理ノード５０は、再配置制御部５１と、分散ＭＣＵ配置要求送信部５２と、分散ＭＣＵ管理部５３と、会議受付部５４と、会議情報データベース５５とを備えている。
【００３０】
インフラ管理ノード６０は、負荷情報取得部６１と、インフラ状態管理部６２と、制御要求受信部６３と、仮想サーバインフラ制御部６４とを備えている。
【００３１】
また、ＭＣＵ管理ノード５０又はインフラ管理ノード６０は、ＭＣＵ配置計算部８０を備えている。図４は、ＭＣＵ配置計算部８０の実装先がＭＣＵ管理ノード５０又はインフラ管理ノード６０の何れであってもよいことを示している。
【００３２】
各仮想サーバインフラ３０のサーバ・ネットワーク負荷監視部３１では、ＣＰＵ、メモリその他計算資源の使用率と、仮想サーバインフラ３０から送受信したパケット量から算出した帯域使用量を常に監視しており、負荷情報送信部３２からインフラ管理ノード６０の負荷情報取得部６１へ定期的に各種使用率の通知を行う。前述の各種使用率はインフラ状態管理部６２で管理され、分散ＭＣＵ４０の最適配置を行う際に必要があればＭＣＵ配置計算部８０へ通知される。
【００３３】
各仮想サーバインフラ３０のアプリケーション管理部３３は、分散ＭＣＵ４０など中継ネットワーク２０上に配置されるアプリケーションの管理をしている。ＭＣＵ管理ノード５０から分散ＭＣＵ４０の起動・終了指示があった場合、当該指示は、インフラ管理ノード６０の制御要求受信部６３・仮想サーバインフラ制御部６４からアプリケーション管理部３３へ通知される。アプリケーション管理部３３は、当該指示に基づき、分散ＭＣＵ４０の起動・終了処理を実施する。
【００３４】
各分散ＭＣＵ４０はＭＣＵ管理ノード５０と通信可能であり、ＭＣＵ管理ノード５０の分散ＭＣＵ管理部５３からは仮想会議室の追加／削除、分散ＭＣＵ４０間のカスケード接続指示、端末１０の収容、転送指示などが通知される。また、分散ＭＣＵ４０は、分散ＭＣＵ４０の処理負荷量、各端末１０の会議品質、端末１０の増減情報を、分散ＭＣＵ管理部５３に通知する。また、分散ＭＣＵ４０は、分散ＭＣＵ４０間同士でカスケード接続を行う場合も、分散ＭＣＵ４０間の通信品質を収集し、ＭＣＵ管理ノード５０の分散ＭＣＵ管理部５３に通知する。
【００３５】
ＭＣＵ管理ノード５０の会議情報データベース５５は、全ての会議情報を管理する。ＭＣＵ管理ノード５０の会議受付部５４は、端末１０に対して、会議参加のために接続すべき分散ＭＣＵ４０を指示する。再配置制御部５１は、分散ＭＣＵ４０及びインフラ管理ノード６０からのサーバ、ネットワーク負荷情報に応じて分散ＭＣＵ４０の再配置を実施するかの判定を行う。
【００３６】
次に、ＭＣＵ管理ノード５０内の再配置制御部５１と仮想サーバインフラ３０内の分散ＭＣＵ４０の機能構成について図５を参照して説明する。図５は再配置制御部及び分散ＭＣＵの機能ブロック図である。
【００３７】
再配置制御部５１は、図５に示すように、再配置判定部５１１と、再配置計算判定部５１２と、再配置バッファ５１３と、端末増減数管理部５１４と、ネットワーク輻輳判定部５１５と、サーバ負荷判定部５１６とを備える。分散ＭＣＵ４０は、分散ＭＣＵ負荷監視部４１と、ＲＴＴ（Round Trip Time）・ジッタ計測部４２と、パケットロス計測部４３と、端末管理部４４と、品質情報送信部４５とを備える。
【００３８】
分散ＭＣＵ４０は、各会議毎に、端末１０の増減情報を端末管理部４４により常時計測する。また、分散ＭＣＵ４０は、各会議毎に、会議に参加する各端末１０との通信における、パケットロス率をパケットロス計測部４３により、ＲＴＴ及びジッタをＲＴＴ・ジッタ計測部４２により常時計測する。これらの情報は、ＴＣＰ（Transmission Control Protocol）、ＲＴＣＰ（Real Time Control Protocol）等一般的なプロトコルで取得可能である。また分散ＭＣＵ４０間がカスケード接続している場合は、分散ＭＣＵ４０間の通信におけるパケットロス率、ＲＴＴ、ジッタを分散ＭＣＵ負荷監視部４１により常時計測する。分散ＭＣＵ負荷監視部４１、ＲＴＴ・ジッタ計測部４２、パケットロス計測部４３、端末管理部４４により取得された各情報は、定期的に品質情報送信部４５からＭＣＵ管理ノード５０の分散ＭＣＵ制御部５３を通じて再配置制御部５１へ送信される。
【００３９】
再配置制御部５１は、上記の情報を元に端末数の増減、ネットワーク品質の輻輳状況、分散ＭＣＵ４０の負荷状況に応じて、中継ネットワーク２０上の分散ＭＣＵ４０を再配置すべきかを判定する。当該判定は、ＭＣＵ配置計算部８０による再配置計算処理を行うか否かを再配置計算判定部５１２が判定するステップと、ＭＣＵ配置計算部８０により算出されたＭＣＵ配置情報に対して再配置処理を行うか否かを再配置判定部５１１が判定するステップとを含む。
【００４０】
分散ＭＣＵ４０の再配置が決定した場合、ＭＣＵ配置計算部８０により計算されたＭＣＵ配置情報に係る再配置タスクが再配置バッファ５１３に保存され、逐次的に再配置処理が実施される。これは分散ＭＣＵ再配置時の一時的な負荷増大を軽減するための処理である。なお、前記再配置タスクは、例えば、分散ＭＣＵ４０の他の仮想サーバインフラ３０への移動、分散ＭＣＵ４０間のカスケード接続や接続解除、端末１０のセッション張り替え等が挙げられる。また、再配置バッファ５１３に再配置タスクを保存しているので、再配置処理として、インフラ管理ノード６０から取得した中継ネットワーク２０、仮想サーバインフラ３０の負荷情報を利用し、負荷の小さい端末１０や仮想サーバインフラ３０から優先して処理することも可能である。
【００４１】
図６に、端末数の増減によってＭＣＵ４０の再配置を行う手順を示す。図６の処理は会議毎に独立に実施される。図６に示すように、会議の開始時や終了時に頻発する端末１０の短時間での増減や、端末１０の一時的な切断によって、ＭＣＵ４０の再配置が行われることを防ぐため、端末１０の増減が一定時間行われなかった場合に再配置の計算を実施する（ステップＳ１〜Ｓ３）。また、再配置の計算は、前回配置計算時から会議端末数の変動あった場合にのみ実施する（ステップＳ４）。ステップＳ６の分散ＭＣＵの最適配置計算では、配置コスト（該当映像会議で使用する回線帯域、特定のリンク、仮想サーバインフラ３０の負荷等）の最小化を実現する分散ＭＣＵ４０の配置場所と、分散ＭＣＵ４０と端末１０の対応を算出する。分散ＭＣＵ４０を配置する仮想サーバインフラ３０の変更、および、端末１０の通信経路の変更にも負荷が生じるため、配置コストが一定以上（再配置閾値）改善する場合に実際の配置変更を実施する（ステップＳ７，Ｓ８）。
【００４２】
図７に、ネットワーク輻輳によって再配置を実施する手順を示す。図７は分散ＭＣＵ４０−端末１０間と、互いにカスケード接続するＭＣＵ４０間の通信毎に独立に実施し、輻輳と判定された端末１０または分散ＭＣＵ４０が参加／開催する会議について再配置計算を実施するものである。
【００４３】
図７に示すように、取得したＲＴＴが、該当する通信において最小のＲＴＴであった場合、最小ＲＴＴとして保存する（ステップＳ１１〜１３）。取得したＲＴＴと最小ＲＴＴとの差が一定値（非輻輳閾値）以下であれば、輻輳が起きていなと判断し、非輻輳時のパケットロス率、ＲＴＴ、ジッタ値の平均値を計算する（ステップＳ１４，１５）。端末１０の接続状況に応じて平常時のパケットロス率、ＲＴＴ、ジッタは異なるため本手順を実行する。また輻輳がＲＴＴの増加に現れないネットワーク環境では、ＲＴＴの代わりにパケットロス率の変動やＥＣＮの利用によって輻輳を判定できる。現在のパケットロス率、ＲＴＴ、ジッタと非輻輳時の平均値の差が一定値（輻輳閾値）以上の場合、該当する通信が輻輳状態にあると判定し、その通信を含む会議についてＭＣＵの再配置計算を図６のステップＳ５〜８と同様に行う。
【００４４】
なお、現在のパケットロス率、ＲＴＴ、ジッタ値は、取得した値をそのまま利用せずに、過去の値によって平準化した値を利用することで瞬間的な変動を検知させないことも可能である。
【００４５】
図８に、分散ＭＣＵ４０の負荷上昇によってＭＣＵ４０の再配置を実施する手順を示す。図８では、分散ＭＣＵ４０から取得した分散ＭＣＵの負荷（ＣＰＵ、メモリその他の計算資源リソース、映像会議の管理セッション数、同時開催会議数等）が高負荷と判定される閾値を超えた場合に再配置（図６のステップＳ５〜８と同様）を実行する。
【００４６】
なお、再配置処理を実行するタイミングの他の例としては、定期的にインフラ管理ノード６０から仮想サーバインフラ３０及び中継ネットワーク２０の負荷を取得したタイミングや、特定のリンク、仮想サーバインフラ３０の負荷が増加した際にインフラ管理ノード６０からＭＣＵ管理ノード５０に分散ＭＣＵ４０の配置変更指示がなされる状況なども考えられる。
【実施例１】
【００４７】
図９に、既にカスケード接続済みの分散ＭＣＵ１と分散ＭＣＵ２間で端末Ａのセッションを張り替える手順を示す。なお、以下の説明では複数の同種の構成要素を区別するために、構成要素の名称の後に連番等を付すとともに、その後に参照符号に同連番等を付したものを括弧付きで付記している。
【００４８】
ここでは、図９に示すように、会議＃１に参加している既存の端末１０は分散ＭＣＵ１（４０−１）とセッションを張っている（ステップＳ１０１）。ここで、端末Ａ（１０−Ａ）も他の端末１０と同様に、分散ＭＣＵ１（４０−１）とセッションを張っている（ステップＳ１０２）。各分散ＭＣＵ４０は定期的に、端末増減、分散ＭＣＵ負荷情報、通信品質情報等をＭＣＵ管理ノード５０に送信している（ステップＳ１０３）。
【００４９】
分散ＭＣＵ４０からの情報を取得したＭＣＵ管理ノード５０は、再配置計算判定を行い、再計算が必要と判定された場合、インフラ管理ノード６０から回線帯域使用率、仮想サーバインフラ使用率を取得し、ネットワーク負荷が低減するＭＣＵ４０の配置及び端末１０とＭＣＵ４０の対応付けを計算し、再配置を実施するかを判定する（ステップＳ１０４〜Ｓ１０７）。
【００５０】
図９では端末Ａ（１０−Ａ）のセッションを分散ＭＣＵ１（４０−１）から分散ＭＣＵ２（４０−２）へ変更するため、ＭＣＵ管理ノード５０は会議情報を管理する会議情報データベース５５を更新し、分散ＭＣＵ１，２（４０−１，４０−２）へ端末Ａ（１０−Ａ）のセッション変更指示を出す（ステップＳ１０８，Ｓ１０９）。指示を受けた分散ＭＣＵ１（４０−１）は端末Ａ（１０−Ａ）へ転送先の分散ＭＣＵ２（４０−２）の識別子（ＩＰアドレス等）と共に転送指示をだし、端末Ａ（１０−Ａ）は分散ＭＣＵ２（４０−２）の呼び出しを行う（ステップＳ１１０，Ｓ１１１）。端末Ａ（１０−Ａ）は分散ＭＣＵ２（４０−２）とセッションを確立後、分散ＭＣＵ１（４０−１）とのセッションを切断する（ステップＳ１１２，Ｓ１１３）。
【００５１】
なお、図１０に示すように、セッションの張り替えを行う際、通常は、転送先の分散ＭＣＵ４０と完全にセッションを確立してから転送元のセッションを切断するため、回線帯域が狭い端末−分散ＭＣＵ間で一時的に映像の送受信両方を二重に転送することになる。このため、図１１及び図１２に示す手順で上り通信トラフィックに係るセッションと下り通信トラヒックに係るセッションを別々に張り替えることで、端末１０からの送受信を送受信の何れかのみを二重に転送するだけでセッションを切断することなく分散ＭＣＵ間で張り替えることができるので、帯域削減の観点から好適である。
【実施例２】
【００５２】
図１３及び図１４に、分散ＭＣＵ１と分散ＭＣＵ２が連携していない状態から、新たに端末Ａが会議へ参加し、カスケード接続する分散ＭＣＵ２を追加して端末Ａのセッションを分散ＭＣＵ２機能へ張り替える手順を示す。
【００５３】
ここでは、端末Ａ（１０−Ａ）が参加を希望する会議についてデフォルトの接続先の分散ＭＣＵ４０が分散ＭＣＵ１（４０−１）であり、当該対応情報が予め会議情報データベースに記憶されているものとする。
【００５４】
図１３及び図１４に示すように、会議＃１に参加している既存の端末１０は分散ＭＣＵ１（４０−１）とセッションを張っている（ステップＳ２０１）。端末Ａ（１０−Ａ）からの会議参加要求を受け取ったＭＣＵ管理ノード５０は、会議情報データベース５５を参照し、該当会議のデフォルトで接続する分散ＭＣＵ１（４０−１）に対して端末の追加指示を行うとともに、端末Ａ（１０−Ａ）へ分散ＭＣＵ１（４０−１）の識別子を通知する（ステップＳ２０２，２０３）。
【００５５】
端末Ａ（１０−Ａ）は分散ＭＣＵ１（４０−１）とセッションを確立する（ステップＳ２０４，Ｓ０５）。分散ＭＣＵ１（４０−１）は会議＃１に端末Ａ（１０−Ａ）が追加されたことを検出して当該追加をＭＣＵ管理ノード５０に通知する（ステップＳ２０６）。その後、ＭＣＵ管理ノードは、ＭＣＵの再配置配判定を行って再計算を実行する。ＭＣＵ配置計算部８０は、インフラ管理ノード６０から取得した、回線帯域使用率、仮想サーバインフラ使用率を元に、ネットワーク負荷が低減するＭＣＵ４０の配置及び端末１０とＭＣＵ４０の対応付けを計算する（ステップＳ２０７〜Ｓ２１０）。端末１０とＭＣＵ４０の紐付けに変更があった場合、ＭＣＵ管理ノード５０は会議情報を管理する会議情報データベース５５を更新し、該当する分散ＭＣＵ４０へ端末の紐付け変更の指示を出す（ステップＳ２１１，Ｓ２１２）。図１３及び図１４の例では分散ＭＣＵ２（４０−２）を新たに会議に追加し（ステップＳ２１３〜Ｓ２１５）、端末Ａ（１０−Ａ）のセッションを分散ＭＣＵ１（４０−１）から分散ＭＣＵ２（４０−２）へ張り替えを行う（ステップＳ２１６〜Ｓ２１９）。
【００５６】
既に複数端末１０が参加している会議に新規端末１０が途中参加する場合、会議主催ＭＣＵ配置は既存の参加端末１０においてネットワーク負荷を低減するように選択されているため、新規端末１０にとってはネットワーク負荷が大きく、会議全体としてはネットワーク負荷が低減できていない可能性がある。本実施例２では新規端末１０が会議へ途中参加時に、ネットワーク負荷が低減される分散ＭＣＵ４０を選択し、会議が中断することなく、既存の会議参加端末１０を含めて新しいＭＣＵ４０に再接続することを実現する。
【００５７】
なお、図１３及び図１４の例では、新規端末Ａ（１０−Ａ）は初めにデフォルトの分散ＭＣＵ４０へ接続したが、図１５及び図１６に示すように、新規端末Ａ（１０−Ａ）から会議参加要求（ステップＳ２５２）があった時点で、最適配置を計算し（ステップＳ２５３〜Ｓ２５６）、計算結果に基づきＭＣＵ配置を行い（ステップＳ２５７〜Ｓ２６３）、最初から配置変更後の分散ＭＣＵ４０へ接続しに行くパターンも考えられる（ステップＳ２６４〜Ｓ２６６）。
【実施例３】
【００５８】
図１７及び図１８に、会議参加端末が減少した際に、残存端末のセッションを張り替えて、分散ＭＣＵ機能を削除する手順を示す。本実施例は会議参加端末が減少した場合に、残っている会議接続端末にネットワーク負荷を最適化するために実施する。
【００５９】
図１７及び図１８の例では、エリア１、２の二つの地域に各分散ＭＣＵ１，２（４０−１，４０−２）が配置されており、各分散ＭＣＵ１，２は１つの会議＃１について連携動作するためにカスケード接続されている（ステップＳ３０１）。エリア１の５台の端末１０がエリア１の分散ＭＣＵ１（４０−１）から会議に接続している（ステップＳ３０２）。一方、エリア２の２台の端末Ａ，Ｂ（１０−Ａ，１０−Ｂ）がエリア２の分散ＭＣＵ２（４０−２）から会議に接続している（ステップＳ３０３，Ｓ３０４）。
【００６０】
ここで、エリア２の１台の端末Ｂ（１０−Ｂ）が会議を切断した場合（ステップＳ３０５）、エリア２の分散ＭＣＵ２（４０−２）の利用端末（残存端末）は端末Ａ（１０−Ａ）の１台のみとなる。この場合、映像を集約して帯域を削減する効果がないため、分散ＭＣＵ２（４０−２）の機能を実行するだけの仮想サーバリソース３０が無駄となる。そこで、本実施例では、このような場合に、分散ＭＣＵ４０の再配置処理を実施する。
【００６１】
図１７及び図１８の例では、端末Ｂ（１０−Ｂ）が切断され会議から離脱したことは分散ＭＣＵ２（４０−２）からＭＣＵ管理ノード５０に通知される（ステップＳ３０６）。ＭＣＵ管理ノード５０は、分散ＭＣＵ４０の再配置計算を行い（ステップＳ３０７〜Ｓ３１０）、その結果、当該会議から分散ＭＣＵ２（４０−２）の利用は解除し、分散ＭＣＵ２（４０−２）に接続していたエリア２に残存する端末Ａ（１０−Ａ）が分散ＭＣＵ１（４０−１）から当該会議に接続するよう制御を行う（ステップＳ３１１〜Ｓ３１９）。
【００６２】
なお、上記の実施例１〜３では一つの分散ＭＣＵ４０及び端末１０の変更のみを扱ったが、複数の分散ＭＣＵ４０、端末１０が同時に変更する場合などその他の分散ＭＣＵ４０及び、端末セッションの張り替えについても、実施例１〜３の組合せで対応可能である点に留意されたい。
【実施例４】
【００６３】
本発明の実施例４について図１９〜図２３を参照して説明する。図１９は実施例４に係る多地点間会議システムのシステム構成図、図２０は実施例４に係る多地点間会議システムにおける通信経路の変更を説明する図、図２１〜図２２は実施例４において端末１０が新規に追加された際のＭＣＵ変更手順を説明する図、図２３はインフラ管理ノードとＭＣＵ管理ノードを異なる事業者が所有する場合のＭＣＵ変更手順を説明する図である。
【００６４】
本実施例４では、図１９に示すように、端末近傍の仮想サーバインフラ３０上に、端末１０とのセッション管理及び分散ＭＣＵ４０までの映像送受信機能のみを持つ分散ＳＦＵ（Selective Forwarding Unit）機能を具備する。ＭＣＵ４０が処理負荷の大きい映像のデコード・エンコード・合成を行うのに対し、分散ＳＦＵ９０は端末１０に変わって映像の転送のみを実施する。
【００６５】
本実施例では、図２０〜図２２に示すように、端末１０は常に最寄りの分散ＳＦＵ９０とのみセッションを張れば良く（ステップＳ４０１，Ｓ４０３）、中継ネットワーク２０上で分散ＭＣＵ４０の配置が変更しても、変更処理は分散ＳＦＵ９０が担う（ステップＳ４０４〜Ｓ４２１）。端末１０は分散ＭＣＵ４０の変更を意識することなく会議が実施可能となる。なお、図２１〜図２２の分散ＭＣＵ４０の変更処理は前述の実施例２で説明した処理と同様である。
【００６６】
また、本実施例４では、ＭＣＵ配置計算に個々の端末１０の情報ではなく分散ＳＦＵ４０の情報によって配置計算が可能となる。これにより図２３に示すように、ＭＣＵ管理ノード５０とインフラ管理ノード６０を異なる事業者が所有する場合に、インフラ管理ノード６０側にＭＣＵの最適配置計算機能（ＭＣＵ配置計算部）８０を具備することで、仮想サーバインフラ３０の負荷、中継ネットワーク２０のトポロジー情報や、映像会議に参加する端末１０の情報を互いに提供することなくＭＣＵの最適配置計算が可能となる。
【００６７】
図２３の例では、分散ＭＣＵ４０及びＭＣＵ管理ノード５０は事業者１が所有し、分散ＳＦＵ９０及び最適配置計算機能（ＭＣＵ配置計算部）８０並びにインフラ管理ノード６０は事業者２が所有している場合を示している。図２３に示すように、事業者１のＭＣＵ管理ノード５０がＭＣＵ配置計算を行うと判定した際には（ステップＳ４５３）、ＭＣＵ管理ノード５０は事業者２の最適配置計算機能（ＭＣＵ配置計算部）８０に、配置を変更したい端末１０が利用するＳＦＵ８０の識別子のみを提供する（ステップＳ４５４）。最適配置計算機能（ＭＣＵ配置計算部）８０は、事業者２の仮想サーバインフラ３０とＳＦＵ９０間に閉じたＭＣＵ配置計算を行い、ＭＣＵ４０の配置場所とＳＦＵ９０の紐付けをＭＣＵ管理ノード５０に通知する（ステップＳ４５５，Ｓ４５６）。ＭＣＵ管理ノード５０は、ＳＦＵ９０を端末１０に紐付けてＭＣＵ４０の配置、ＳＦＵ９０の映像転送指示を実施する（ステップＳ４５７）。
【実施例５】
【００６８】
本発明の実施例５について図２４及び図２５を参照して説明する。図２４は実施例５に係る多地点間会議システムにおける通信経路の変更を説明する図、図２５は実施例５において分散ＭＣＵ機能をＳＦＵ機能に切り替える手順を説明する図である。
【００６９】
実施例５では、分散ＭＣＵ４０内にＳＦＵ機能９０を具備し、ＭＣＵ４０とＳＦＵ機能９０の切り替え（端末１０からの映像合成を行うか、他の分散ＭＣＵ４０へ転送のみを行うかの変更）を行う。これにより、図２４に示すように、分散ＭＣＵ機能を配置した仮想サーバインフラ３０の負荷が、バースト的に増加した際に、一時的に映像合成を行わず、他ＭＣＵ４０への転送のみに切り替えることで、仮想サーバインフラ３０の負荷を低減することができる。
【００７０】
図２５の例では、端末１０が仮想サーバインフラ１（３０−１）上の分散ＭＣＵ１（４０−１）に接続しており（ステップＳ５０１）、端末Ａ（１０−Ａ）が仮想サーバインフラ２（３０−２）上の分散ＭＣＵ２（４０−２）に接続している（ステップＳ５０３）。そして、分散ＭＣＵ１（４０−１）と分散ＭＣＵ２（４０−２）は連携して１つの会議を開催しており、それぞれ全端末の映像合成処理を行っているものとする（ステップＳ５０２，Ｓ５０４）。
【００７１】
ここで仮想サーバインフラ２（３０−２）の負荷が大きくなったことを想定する。インフラ管理ノード６０は当該負荷増大を検出してＭＣＵ管理ノード５０に通知する（ステップＳ５０５）。ＭＣＵ管理ノード５０は、分散ＭＣＵ２（４０−２）に対して、動作中の分散ＭＣＵ４０機能をＳＦＵ機能９０に切り替えるために、映像転送の切り替え指示をだす（ステップＳ５０６）。また、ＭＣＵ管理ノード５０は、分散ＭＣＵ１（４０−１）に対して合成映像を分散ＭＣＵ２へ転送するよう指示をだす（ステップＳ５０７）。これにより、仮想サーバインフラ２（３０−２）の分散ＭＣＵ２（４０−２）は、以降、端末Ａ（１０−Ａ）の通信トラフィックを仮想サーバインフラ１（３０−１）の分散ＭＣＵ１（４０−１）に転送するＳＦＵとして機能する（ステップＳ５０８，Ｓ５１０，Ｓ５１３，Ｓ５１４）。また、映像合成処理は仮想サーバインフラ１（３０−１）の分散ＭＣＵ２（４０−２）のみで行われる（ステップＳ５１１）。
【００７２】
次に、上述のＭＣＵ配置計算部８０において分散ＭＣＵ機能の配置場所を決定する方法について詳述する。
【００７３】
まず、分散ＭＣＵ配置の決定に用いる配置コストの一例を以下に列挙する。
【００７４】
１．帯域利用コスト
帯域利用コストの例としては以下が挙げられる。
（ａ）映像帯域総和：映像ビットレート×総ホップ数
（ｂ）重みを考慮した帯域利用コスト：Σ（映像ビットレート×リンク毎の重み）
なお、前記のリンク毎の重みの例としては、ＲＴＴ、最大帯域、利用料金等が挙げられる。
【００７５】
２．帯域利用率コスト
帯域利用率コストの例としては以下が挙げられる。
（ａ）帯域利用率総和：Σ｛（他通信利用帯域＋ＭＣＵ利用帯域）／リンク最大帯域｝
（ｂ）重みを考慮した帯域利用率コスト：Σ｛（他通信利用帯域＋ＭＣＵ利用帯域）／リンク最大帯域×リンク毎の重み｝
【００７６】
３．仮想サーバインフラ使用コスト
仮想サーバインフラ使用コストの例としては以下が挙げられる。
（ａ）ＣＰＵ：分散ＭＣＵ基本処理量×分散ＭＣＵ数
＋  １映像当りの映像エンコード・デコード処理量×セッション数
＋  １映像当りの映像合成処理量×（セッション数−１）
（ｂ）メモリ：分散ＭＣＵ基本メモリ使用量×分散ＭＣＵ数
＋  １映像当りの映像エンコード・デコードメモリ使用量×セッション数
＋  １映像当りの映像合成メモリ使用量×（セッション数−１）
【００７７】
４．仮想サーバインフラ使用率コスト
仮想サーバインフラ使用率コストの例としては以下が挙げられる。
（ａ）ＣＰＵ  ：Σ（他アプリＣＰＵ使用率＋ＭＣＵのＣＰＵ使用率）／１００×仮想サーバインフラ毎の重み
【００７８】
５．遅延コスト
遅延コストの例としては以下が挙げられる。
（ａ）伝送遅延＋ＭＣＵ処理遅延
【００７９】
また、分散ＭＣＵ配置ポリシー（目的関数）の例としては以下が挙げられる。
（ａ）一つの会議のコスト最小化
（ｂ）中継ネットワーク全体のコスト最小化
（ｃ）特定のリンク帯域の利用率最小化
（ｄ）特定の仮想サーバインフラ使用率最小化
【００８０】
以下の説明では、説明を簡単にするため、コストとして「帯域利用コスト」、目的関数として「一つの会議のコスト最小化」を用いて分散ＭＣＵ配置計算のアルゴリズムについて説明する。なお、一般的には、コストは前述した各項目等を複合的に考える必要がある点に留意されたい。
【００８１】
分散ＭＣＵ配置計算アルゴリズムの一例を図２６に示す。
【００８２】
まず、後述するステップＳ３５で分散ＭＣＵの総帯域利用コストを計算するのに先だって、全仮想サーバインフラ間、仮想サーバインフラ−端末間の帯域利用コストを計算しておく（ステップＳ３１）。各リンクの帯域利用コストが既知であれば、仮想サーバインフラ間、仮想サーバインフラ−端末間の帯域利用コストは１つ辺り１回の演算で計算可能である。
【００８３】
後述するステップＳ３５で総帯域利用コスト計算を実施する際、一から総帯域利用コストを計算する場合、仮想サーバインフラ数ｍ、会議参加端末数ｎ台に対して、O(nlog m)の演算が必要であるが、上記のステップＳ３１の処理を実施しておくことで、端末−ＭＣＵ間の総帯域利用コストはO(n)の演算で計算可能である。なお、O(nlog m)やO(n)はＯ−記法によるものである。なお、ステップＳ３１で予め計算をするのではなく、後述するステップＳ３５で計算した仮想サーバインフラ、端末間の帯域利用コストを順次保存して再利用する方法でも計算量の削減が可能である。
【００８４】
ここで、ステップＳ３１の具体例について図２７を参照して説明する。図２７では８台の仮想サーバインフラと４台の端末が完全二分木のツリー構造となっているものとし、４台の端末Ａ，Ｃ，Ｄ，Ｆが会議参加端末であるものとする。
【００８５】
図２７の表は仮想サーバリソース間、端末−仮想サーバリソース間の帯域利用コストであり、表中のＣｉｊはノードｉからノードｊの帯域利用コストを示している。
【００８６】
端末Ａ，Ｃ，Ｄ，Ｆが仮想サーバリソース（２）を、端末Ｆが仮想サーバリソース（３）を利用する場合の帯域利用コストは、
端末Ａのコスト＋端末Ｃのコスト＋端末Ｄのコスト＋端末Ｆのコスト＋ＭＣＵ間のコスト＝ＣＡ２＋ＣＣ２＋ＣＤ２＋ＣＦ３＋Ｃ２３
となる。
【００８７】
完全二分木の場合、一つの配置コストの計算量は、端末数ｎ、仮想サーバリソース数ｍに対して、一から計算する場合は、O(log m)×n=O(nlog m)となるが、上記の場合ｍ２＋ｎｍの計算をしておくことでO(n)となる。
【００８８】
再び図２６に戻りアルゴリズムの説明を続ける。ステップＳ３２では帯域利用コストを計算する分散ＭＣＵの配置を一つ選択し、ステップＳ３３で分散ＭＣＵ間のカスケード接続方法を選択し、ステップＳ３４で端末をどの分散ＭＣＵに接続するかを選択する。
【００８９】
ここで分散ＭＣＵの選択方法は、分散ＭＣＵの最大数を端末数ｎ−１個としたとき次式の通り数だけ存在する。
【００９０】
【数１】
2019125997.tif 000003
【００９１】
更に端末が任意の分散ＭＣＵを利用できる場合、総数は次式の通り数となる。
【００９２】
【数２】
2019125997.tif 000004
（ここでＳはスターリング数）
【００９３】
これは、例えば端末が１０台、仮想サーバリソースが５０ヵ所でも約６京通りとなり、毎回全組合せを計算して最適配置を計算するのは現実的ではない。
【００９４】
そこで本発明では、端末が利用する分散ＭＣＵは、前記ステップＳ３１で計算した端末−仮想サーバリソース間のコストを用い、前記ステップＳ３２で選択された分散ＭＣＵの配置場所の中で最もコストが最小となる分散ＭＣＵとする。
【００９５】
次に、ステップＳ３５では前記ステップＳ３１で計算した値からO(1)で前記ステップＳ３２〜Ｓ３４で選択した分散ＭＣＵ配置の総帯域利用コストを計算する。総帯域利用コストがこれまでの計算で最少であれば、分散ＭＣＵの配置とコストを保存し（ステップＳ３７）、ステップＳ３８で計算を終了するか判定する。全ての分散ＭＣＵ配置の組合せを計算するか、別に定めた終了条件を満たせば、総帯域利用コスト最小の分散ＭＣＵ配置を出力して終了する（ステップＳ３９）。
【００９６】
ここで、終了条件としては、例えば一定時間の経過や、以下で述べる帯域削減効果が見込めるＭＣＵに限定した配置の探索終了などが考えられる。
【００９７】
すなわち、端末が接続する分散ＭＣＵが一意に決定したとしても、分散ＭＣＵ配置は、端末数、仮想サーバリソース数によって膨大となるため、更にステップＳ３２で選択する仮想サーバリソースを限定して分散ＭＣＵ配置の探索を行う。
【００９８】
インフラ管理ノード６０にて各端末毎に、各端末と最上位ルータ間の最短経路内で利用可能な仮想サーバインフラリストを保持する。
【００９９】
ここでＭＣＵを配置する仮想サーバインフラの候補を、会議に参加する端末の上記リストを参照し、２端末以上が共通する（重複する）仮想サーバリソースに限定することができる。分散ＭＣＵの配置場所は複数端末の映像を集約可能な場所が望ましいため、上記の仮想サーバインフラに限定してもある程度帯域削減が可能なＭＣＵ配置が期待できる。
【０１００】
また、端末に近く、複数端末で共通する端末数が多い仮想サーバインフラはより帯域削減効果が大きいと考えられるため、端末に近く、複数端末で共通する端末数が多い仮想サーバインフラに配置場所を限定したり、分散ＭＣＵ配置の候補として優先度を高くすることで更に配置場所の探索範囲を低減することもできる。図２８にリストの一例を示す。
【０１０１】
図２８の例では、一つの映像会議で使用する総帯域の最小化を目的としたが、特定のリンクの帯域削減が目的であれば、該当リンクより下位（端末側）の仮想サーバインフラに候補を限定する、特定の仮想サーバインフラの負荷低減であれば該当仮想サーバインフラを分散ＭＣＵ配置の候補から除外するなどの処理が効果的である。
【０１０２】
以上詳述したように、本発明によれば、会議開催中にも会議参加者の増減やネットワーク負荷の変動に応じてＭＣＵの配置場所を変更することで、会議を中断することなくネットワークのサーバ、回線帯域負荷を低減することができる。
【０１０３】
また、本発明によれば、端末−分散ＭＣＵ間、分散ＭＣＵ−分散ＭＣＵ間のネットワーク品質、端末増減数を監視することで、常時中継ネットワークの情報を取得することなくＭＣＵの配置変更が可能となる。
【０１０４】
また、本発明によれば、イベント的なバーストトラヒックが生じた際にも、柔軟にＭＣＵ配置を変更することで、会議の品質低下を防ぐことができる。
【０１０５】
また、本発明によれば、端末近傍の仮想サーバインフラにＳＦＵ機能を具備することで、動的なＭＣＵ配置の変更に対応していない端末でも、本発明の通信システムの利用が可能になる。
【０１０６】
また、本発明によれば、端末近傍の仮想サーバインフラにＳＦＵ機能を具備することで、インフラ管理ノードとＭＣＵ管理ノードを所有する事業者が異なっていても、ＳＦＵの識別子以外の情報を互いに共有することなく分散ＭＣＵの配置計算を可能となる。
【０１０７】
また、本発明によれば、効率的にＭＣＵ配置コストを計算することで、ＭＣＵ管理ノードの負荷低減と、よりネットワーク負荷の小さいＭＣＵ配置が可能となる。
【０１０８】
以上本発明の実施の形態について詳述したが本発明はこれに限定されるものではない。例えば、上記実施の形態では、多地点間通信システムの適用例として会議システムについて説明したが、他のシステムにも適用できる。適用例としては、例えば、Ｗｅｂ会議システムや、リアルタイム映像配信システム、ファイル転送を行うマルチキャスト配信システムなどが挙げられる。
【０１０９】
また、上記実施の形態においては、ＭＣＵ管理ノード５０とサーバインフラ管理ノード６０により分散ＭＣＵの管理・制御を行っているが、各ノードの機能を集中化や分散化させるなど他の実装形態でも本発明を実施できる。
【０１１０】
また、上記実施の形態では、中継ネットワーク２０のネットワークトポロジーがツリー構造の場合について説明したが、他のネットワークトポロジーであっても本発明を実施できる。
【０１１１】
また、上記実施の形態では、サーバ上で動作する多地点接続機能を仮想インフラサーバ上で動作するアプリケーションという形態で実装したが、他の形態での実装も考えられる。例えば、サーバがコンテナホストであり、ＭＣＵアプリケーションがコンテナ上で提供される、という形態とすることができる。また、サーバが汎用サーバであり、ＭＣＵがアプリケーションソフトウェア、という形態とすることができる。また、サーバとＭＣＵとが一体となったアプライアンス製品、という形態とすることができる。ＳＦＵ機能についても同様である。
【符号の説明】
【０１１２】
１０…端末
２０…中継ネットワーク
２５…ルータ
３０…仮想サーバインフラ
３１…サーバ・ネットワーク負荷監視部
３２…負荷情報送信部
３３…アプリケーション管理部
４０…ＭＣＵ
４１…分散ＭＣＵ負荷監視部
４２…ＲＴＴ・ジッタ計測部
４３…パケットロス率計測部
４４…端末管理部
５０…ＭＣＵ管理ノード
５１…再配置制御部
５１１…再配置判定部
５１２…再配置計算判定部
５１３…再配置バッファ
５１４…端末増減数管理部
５１５…ネットワーク輻輳判定部
５１６…サーバ負荷判定部
５２…分散ＭＣＵ配置要求送信部
５３…分散ＭＣＵ管理部
５４…会議受付部
５５…会議情報データベース
６０…インフラ管理ノード
６１…負荷情報取得部
６２…インフラ状態管理部
６３…制御要求受信部
６４…仮想サーバインフラ制御部
７０…インターネット
８０…ＭＣＵ配置計算部
９０…ＳＦＵ
【図１】
2019125997.tif 000005
【図２】
2019125997.tif 000006
【図３】
2019125997.tif 000007
【図４】
2019125997.tif 000008
【図５】
2019125997.tif 000009
【図６】
2019125997.tif 000010
【図７】
2019125997.tif 000011
【図８】
2019125997.tif 000012
【図９】
2019125997.tif 000013
【図１０】
2019125997.tif 000014
【図１１】
2019125997.tif 000015
【図１２】
2019125997.tif 000016
【図１３】
2019125997.tif 000017
【図１４】
2019125997.tif 000018
【図１５】
2019125997.tif 000019
【図１６】
2019125997.tif 000020
【図１７】
2019125997.tif 000021
【図１８】
2019125997.tif 000022
【図１９】
2019125997.tif 000023
【図２０】
2019125997.tif 000024
【図２１】
2019125997.tif 000025
【図２２】
2019125997.tif 000026
【図２３】
2019125997.tif 000027
【図２４】
2019125997.tif 000028
【図２５】
2019125997.tif 000029
【図２６】
2019125997.tif 000030
【図２７】
2019125997.tif 000031
【図２８】
2019125997.tif 000032