(57)【要約】      （修正有）【課題】ネットワークやサーバの負荷や遅延が小さい多地点間通信システム及び方法並びにプログラムを提供する。【解決手段】中継ネットワーク３０に地理的に分散配備された複数のエッジサーバ４０において動作する多地点接続装置（ＭＣＵ：Multipoint Control Unit）５０と、ＭＣＵ管理機能６０を備えた。ＭＣＵ管理機能６０は、グループ通信の開始に先立ち、ネットワーク構成情報並びに前記ネットワーク及び前記サーバのリソース情報に基づき、グループ通信のコストが最適となるような１又は複数の多地点接続装置５０を選択し、多地点接続装置５０が複数の場合には、互いの多地点接続装置５０を連携させ、複数の多地点接続装置にまたがりながらも端末１０からは単一のグループ通信が実施されているかのように振る舞わせるよう各多地点接続装置５０を制御する。【選択図】図２
2019125996.tif 000002
【特許請求の範囲】
【請求項１】
ネットワークに収容された複数の端末間でグループ通信を行う多地点間通信システムであって、
前記ネットワーク内に地理的に分散配備された複数のサーバにおいて動作する多地点接続機能と、
前記グループ通信の開始に先立ち、少なくとも前記端末の位置情報と前記サーバの位置情報とを含むネットワーク構成情報並びに前記ネットワーク及び前記サーバのリソース情報に基づき、前記グループ通信に係る前記ネットワーク及び前記サーバの利用コストが最適となるような１又は複数の前記多地点接続機能を選択する多地点接続機能選択手段と、
前記多地点接続機能選択手段によって選択された多地点接続機能が複数の場合に、互いの多地点接続機能を連携させ、複数の多地点接続機能にまたがりながらも端末からは単一のグループ通信が実施されているかのように振る舞わせるよう各多地点接続機能を制御する多地点接続機能制御手段とを備えた
ことを特徴とする多地点間通信システム。
【請求項２】
前記多地点接続機能は前記サーバ上に構築された仮想マシン上のアプリケーションとして実装されている
ことを特徴とする請求項１記載の多地点間通信システム。
【請求項３】
前記多地点接続機能選択手段は、グループ通信予約情報に基づき選択処理を行う
ことを特徴とする請求項１又は２何れか１項記載の多地点間通信システム。
【請求項４】
予約時刻を含む前記グループ通信予約情報を受け付ける予約情報受付手段と、
受け付けた前記予約情報を記憶する予約情報記憶手段とを備え、
前記多地点接続機能選択手段は、自身での処理時間及び前記多地点接続機能制御手段の処理時間から逆算して前記予約時刻に前記グループ通信が開始できるよう自身での処理を開始する
ことを特徴とする請求項３記載の多地点間通信システム。
【請求項５】
前記多地点接続機能選択手段は、複数のグループ通信が並行して行われる場合には、各グループ通信についての多地点接続機能の選択処理において、前記複数のグループ通信に係る前記ネットワーク及び前記サーバの利用コストが最適となるような１又は複数の前記多地点接続機能を選択する
ことを特徴とする請求項１乃至４何れか１項記載の多地点間通信システム。
【請求項６】
前記多地点接続機能選択手段は、前記ネットワークが中継装置をノードとする木構造であるものとして前記ネットワークの利用コストを算出する
ことを特徴とする請求項１乃至５何れか１項記載の多地点間通信システム。
【請求項７】
ネットワークに収容された複数の端末間でグループ通信を行う多地点間通信方法であって、
多地点接続機能が動作する複数のサーバを前記ネットワーク内に地理的に分散配備し、
多地点接続機能選択手段が、前記グループ通信の開始に先立ち、少なくとも前記端末の位置情報と前記サーバの位置情報とを含むネットワーク構成情報並びに前記ネットワーク及び前記サーバのリソース情報に基づき、前記グループ通信に係る前記ネットワーク及び前記サーバの利用コストが最適となるような１又は複数の前記多地点接続機能を選択し、
多地点接続機能制御手段が、前記多地点接続機能選択手段によって選択された多地点接続機能が複数の場合に、互いの多地点接続機能を連携させ、複数の多地点接続機能にまたがりながらも端末からは単一のグループ通信が実施されているかのように振る舞わせるよう各多地点接続機能を制御する
ことを特徴とする多地点間通信方法。
【請求項８】
コンピュータを請求項１記載の多地点接続機能選択手段及び多地点接続機能制御手段として動作させることを特徴とする多地点間通信プログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、多地点接続機能を交流点として複数の端末間でグループ通信を行う多地点間通信システムに関する。
【背景技術】
【０００２】
近年、４Ｋ／８Ｋなど超高精細カメラ／ディスプレイ装置やＡＲ（拡張現実：Augmented Reality）／ＶＲ（仮想現実：Virtual Reality）技術の発達とあわせ、省エネやライフワークバランスを目的とした各企業のテレワーク推奨施策等により、ネットワークを介した映像コミュニケーションサービスへの需要が高まっている。
【０００３】
映像コミュニケーションサービスの代表例として映像会議が挙げられる。映像会議システムを構成する上で良く知られる装置として多地点接続装置（ＭＣＵ：Multipoint Control Unit）が挙げられる。ＭＣＵは、グループ通信の交流点としてネットワークに配置される装置であり、映像会議システム用のＭＣＵは、全ユーザ端末からの映像／音声パケットを受信したのち、各参加者の映像を１つの画面に合成して、全ユーザ端末に映像／音声を配信する装置である。
【０００４】
ＭＣＵを用いた多地点間映像会議では、Ｐ２Ｐ（Peer to Peer）方式の多地点映像会議と比べて端末負荷が下げられる一方で、ＭＣＵサーバの計算負荷およびネットワーク負荷が増大するという課題がある。ＭＣＵのネットワーク負荷低減方法の一例として、複数のＭＣＵを地理的に分散配備したシステムが知られている（例えば、特許文献１参照）。このシステムでは、例えば、大阪エリアと東京エリアとで会議参加端末を収容するＭＣＵを分離しつつ、大阪のＭＣＵと東京のＭＣＵとをカスケード接続させる。大阪エリアの複数端末の会議参加者映像は大阪のＭＣＵにおいて１画面に合成された状態で東京のＭＣＵへ送出される。また逆方向も同様、東京エリアの複数ユーザの会議参加者映像が東京のＭＣＵにおいて１画面に合成された状態で大阪のＭＣＵへ送出される。このようなシステムにより、東京−大阪間のネットワーク帯域の増加を抑制することができる。
【先行技術文献】
【特許文献】
【０００５】
【特許文献１】特許第３４５７２０２号公報
【特許文献２】特開第２００３−６９５６３号公報
【発明の概要】
【発明が解決しようとする課題】
【０００６】
上述の特許文献１に記載の方法によれば、複数のＭＣＵをカスケード接続しているので、会議参加端末数が増大した場合または映像品質レートをより高品質にしようとした場合においても、中継ネットワークや他網との相互接続部（ゲートウェイ）におけるネットワーク負荷の増大を防ぐことができると期待される。しかし、特許文献１に記載のものは、専用ハードウェアを予め準備する必要があり、また、ＭＣＵは固定的に配備したものを利用するしかない為、当初の設備設計からサービス加入者状況が変化してしまった場合などにおいて最適性が損なわれるという課題がある。
【０００７】
そこで、特許文献２に記載されているように、地理的に分散配備されたＭＣＵ群の中から、会議が発生するごとに参加端末の構成に応じて利用するＭＣＵを動的に変更させる方法が提案されている。この方法では、会議が開催される度に最適な（たとえば会議によって発生するネットワークトラヒックを最小限にするような）ＭＣＵを選択することができるので、初期の設計に縛られることなく参加者エリア構成に応じて効果的な中継ネットワーク帯域節約が可能となる。また、あるＭＣＵが故障した場合においても、他の候補ＭＣＵを選択すればよいので会議の開催が可能となる。また、同様の他の方法として、参加端末ごとに近接度（各区間の可用帯域の逆数の総和）を計算し、当該会議において近接度の総和が最小となるＭＣＵを選択する方法も考えられている。
【０００８】
しかし、特許文献２等に記載のものは、会議ごとに単一のＭＣＵを選出する方法が与えられているのみであって、会議参加端末の地域的な偏り等に応じて効果的に複数のＭＣＵを選出しカスケード接続させる方法については言及されていない。
【０００９】
本発明は上記事情に鑑みてなされたものであり、その目的とするところは、ネットワークやサーバの負荷や遅延が小さい多地点間通信システム及び方法並びにプログラムを提供することにある。
【課題を解決するための手段】
【００１０】
上記目的を達成するために、本願発明は、ネットワークに収容された複数の端末間でグループ通信を行う多地点間通信システムであって、前記ネットワーク内に地理的に分散配備された複数のサーバにおいて動作する多地点接続機能と、前記グループ通信の開始に先立ち、少なくとも前記端末の位置情報と前記サーバの位置情報とを含むネットワーク構成情報並びに前記ネットワーク及び前記サーバのリソース情報に基づき、前記グループ通信に係る前記ネットワーク及び前記サーバの利用コストが最適となるような１又は複数の前記多地点接続機能を選択する多地点接続機能選択手段と、前記多地点接続機能選択手段によって選択された多地点接続機能が複数の場合に、互いの多地点接続機能を連携させ、複数の多地点接続機能にまたがりながらも端末からは単一のグループ通信が実施されているかのように振る舞わせるよう各多地点接続機能を制御する多地点接続機能制御手段とを備えたことを特徴とする。
【発明の効果】
【００１１】
本発明によれば、グループ通信への参加端末数が増大した場合においてもネットワークや他網とのゲートウェイ部分の帯域の増加を防ぐことができる。そして、ネットワークや他網とのゲートウェイ部分の帯域の制約が緩和されるので、端末〜サーバ間のアクセス区間がＦＴＴＨ（Fiber to the Homeの）や５Ｇ等の高速回線である場合は、広帯域性を活かしたより高精細・高臨場感な映像会議が可能となる。また、特定のサーバに故障や可用リソース不足が発生したとしても、当該サーバの使用を回避して多地点間のグループ通信が実施可能となる。
【図面の簡単な説明】
【００１２】
【図１】本発明の概要を説明する図
【図２】多地点間通信システムのシステム構成図
【図３】他の例に係る多地点間会議システムのシステム構成図
【図４】ＭＣＵ管理機能の機能ブロック図
【図５】他の例に係るＭＣＵ管理機能の機能ブロック図
【図６】他の例に係るＭＣＵ管理機能の機能ブロック図
【図７】多地点間会議システムにおける会議予約から会議開催、会議終了までのフロー例
【図８】多地点間会議システムにおける会議予約から会議開催、会議終了までのフロー例（複数会議同時開催）
【図９】ＭＣＵ最適配置計算処理のフロー例
【図１０】ＭＣＵ最適配置計算処理の詳細フロー例
【図１１】ＭＣＵ最適配置計算処理の具体例を説明する図
【図１２】コスト計算の簡単な具体例
【図１３】コスト計算の簡単な具体例
【図１４】コスト計算の簡単な具体例
【図１５】コスト計算の簡単な具体例
【図１６】コスト計算の簡単な具体例
【図１７】他の例に係るＭＣＵ最適配置計算ステップを説明する図
【図１８】他の例に係るＭＣＵ最適配置計算ステップを説明する図
【図１９】他の例に係るＭＣＵ最適配置計算ステップを説明する図（１／３）（複数会議同時開催）
【図２０】他の例に係るＭＣＵ最適配置計算ステップを説明する図（２／３）（複数会議同時開催）
【図２１】他の例に係るＭＣＵ最適配置計算ステップを説明する図（３／３）（複数会議同時開催）
【発明を実施するための形態】
【００１３】
まず、本発明の概要について図１を参照して説明する。本発明は、図１（ｂ）に示すように、ネットワークに収容された複数の端末１間でグループ通信を行う多地点間通信システムであって、ネットワークに地理的に分散配備（例えば市町村エリア毎に分散配備）された多地点接続機能３を交流点としてグループ通信を行う多地点間通信システムに関する。ここで「多地点接続機能」とは、従来の多地点接続装置（ＭＣＵ：Multipoint Control Unit）として機能するものを意味し、後述するようにその実装形態は不問である。図１（ｂ）では多地点接続機能３をＭＣＵ３と標記する。なお、図１では、多地点間通信システムの適用例として多地点間の映像会議を実現する多地点間会議システムについて図示している。
【００１４】
図１（ａ）に示す従来技術では、ＭＣＵ３は全体で１つ配備されているのみであり、全会議参加端末１の画像を合成して、各参加端末１に配信している。このため、映像トラヒックが１つのＭＣＵ３に集中するという課題がある。一方、本発明では、図１（ｂ）に示すように、分散配備された各ＭＣＵ３においてエリア毎に一次とりまとめ画面合成を行い、各ＭＣＵ３間で前記一次とりまとめ画面を交換して最終合成を行い、各参加端末１に配信する。これにより、中継ネットワークの利用が一画面の帯域で済むという利点がある。
【００１５】
本発明では、グループ通信参加者の端末１の在圏エリアを含むネットワーク構成情報、各ネットワーク区間の可用帯域などのネットワークリソース情報、エッジサーバ２のサーバリソース情報などのインフラ情報に応じて最適な（１または複数の）ＭＣＵ用のエッジサーバ２を選択する（最適配備計算）。
【００１６】
また、本発明では、複数のＭＣＵ３同士を連携させ、ユーザの端末１からは同一の仮想的なグループ通信に見えるようＭＣＵ３間を制御させる。制御の一例としては、決定されたＭＣＵ３の中から親ＭＣＵと子ＭＣＵとを選出し、臨時的にカスケード接続させるなどが挙げられる。
【００１７】
また、本発明では、上記のグループ通信が、予約情報に基づいて開催され、ＭＣＵ選択計算やＭＣＵインスタンス展開にかかる時間から逆算してＭＣＵ選択計算が開始されることも特徴とする。
【００１８】
本発明では、上記のグループ通信を実現するために、ＭＣＵ群を管理するＭＣＵ管理機能４（または前記機能を備えたノード／装置）を提供する。ＭＣＵ管理機能４は、前述したように、ＭＣＵ３の最適配備計算を行い、ＭＣＵ３に連携指示を行う。
【００１９】
なお、図１においては、複数のエッジサーバ２を収容したネットワークは、インターネットなどの他網に接続している。このため、インターネットなどの他網からみると各エッジサーバ２はネットワークの「エッジ」側、すなわち、他網含めたネットワーク全体の中において端末１とより近い側に配置されているように見えることから、同図の各サーバをエッジサーバと呼ぶものとする。以下の説明においても同様である。
【００２０】
次に、本発明のより具体的な実施形態について図２を参照して説明する。本実施の形態では、前述の図１と同様に、多地点間会議システムについて説明する。図２は多地点間会議システムのシステム構成図である。
【００２１】
図２に示すように、多地点間会議システムは、複数の端末１０と、アクセスネットワーク２０と、複数地域にまたがる中継ネットワーク３０と、地理的に分散配備されたエッジサーバ４０と、前記エッジサーバ４０上に配備されたＭＣＵアプリケーション５０と、前記エッジサーバ４０及びＭＣＵアプリケーション５０を制御するＭＣＵ管理機能６０と、を含んで構成される。
【００２２】
アクセスネットワーク２０は、端末１０を中継ネットワーク３０に収容するネットワークである。図２では、複数の端末１０が１つのアクセスネットワーク２０によって中継ネットワーク３０に収容されることを意味するのではなく、ネットワークトポロジーにおけるアクセスネットワーク２０の相対的な配備位置を示す論理的なネットワークである点に留意されたい。
【００２３】
中継ネットワーク３０は、地理的に分散して構築された複数の地域ネットワークの相互接続により構成された論理的なネットワークであり、地理的に分散配備されたルーターなどの複数のネットワーク装置３５を含む。本実施の形態における中継ネットワーク３０のネットワークトポロジーは、図２に示すように、ネットワーク装置３５をノードとするツリー構造であるものとする。中継ネットワーク３０は、ツリー構造の最上位のネットワーク装置３５を介して、インターネットなどの他網７０に接続している。以下の説明では、アクセスネットワーク２０及び中継ネットワーク３０における各ノード間を「ネットワーク区間」と呼ぶものとする。
【００２４】
エッジサーバ４０は、ネットワーク装置３５の近傍において当該ネットワーク装置３５に接続されている。すなわち、エッジサーバ４０も、中継ネットワーク３０において地理的に分散配備されている。エッジサーバ４０は、中継ネットワーク３０内における任意のネットワーク装置３５に接続されている。図２では、エッジサーバ４０が接続されているネットワーク装置３５のみを図示している。また、エッジサーバ４０は、１つのネットワーク装置３５に複数接続されていてもよい。図２では、全てのネットワーク装置３５について、接続されているエッジサーバ４０の数が１つである場合を示している。
【００２５】
前記ＭＣＵ管理機能６０は、前記アクセスネットワーク２０・前記中継ネットワーク３０・前記エッジサーバ４０のうちいずれかまたは複数のリソース情報（ネットワークトポロジー、端末１０の位置情報、エッジサーバ４０の位置情報、経路コスト、各ネットワーク区間の可用帯域、エッジサーバの可用リソース、エッジサーバ稼働コスト等）を取得するための手段を備える。図２の例では、前記リソース情報のうち、ネットワークに係る情報はネットワーク管理ノード８１を介して、サーバリソースに係る情報はサーバインフラ管理ノード８２を介して取得する場合を示している。
【００２６】
前記ＭＣＵ管理機能６０は、ユーザからの会議予約情報（会議開始／終了時刻、最大参加人数、参加端末リスト等）を得るための手段を備える。図２の例では、前記会議予約情報を、会議予約システム９０を介して取得する場合を示している。
【００２７】
前記ＭＣＵ管理機能６０は、取得した前記リソース情報および会議予約情報に基づき、会議参加者の在圏エリアによって最適な一または複数のＭＣＵ用エッジサーバ４０を選択する機能を備える。
【００２８】
前記ＭＣＵ管理機能６０は、前記選択機能で算出された結果に基づいて、各エッジサーバ４０上のＭＣＵ５０に対して会議開催／終了などの指令を行う手段を備える。また、ＭＣＵ５０が仮想ハイパーバイザ上のＶＭ（Virtual Machine）上で動作するソフトウェアであった場合は、仮想ハイパーバイザやＶＭに対してもＶＭ作成・削除・起動・終了、ＭＣＵアプリケーション５０の起動・終了などの指令を行う手段を備える。尚、図２の例では、前記各種指令を、サーバインフラ管理ノード８２を介して行う例を用いて説明している。
【００２９】
前記エッジサーバ４０とＭＣＵ５０は種々の形態が考えられる。エッジサーバ４０が仮想ハイパーバイザ（または仮想ホスト）であり、ＭＣＵ５０が仮想マシン（ＶＭ：Virtual Machine）上で動作するソフトウェア、という形態とすることができる。また、エッジサーバ４０がコンテナホストであり、ＭＣＵアプリケーション５０がコンテナ上で提供される、という形態とすることができる。また、エッジサーバ４０が汎用サーバであり、ＭＣＵ５０がアプリケーションソフトウェア、という形態とすることができる。また、エッジサーバ４０とＭＣＵ５０とが一体となったアプライアンス製品、という形態とすることができる。
【００３０】
ＭＣＵ５０は、ＭＣＵ管理機能６０からの指示によりグループ通信に係る処理を実施する。グループ通信を複数のＭＣＵ５０により実施する場合、各ＭＣＵ５０は他のＭＣＵ５０と連携し、複数のＭＣＵ５０にまたがりながらも端末１０からは単一のグループ通信が実施されているかのように振る舞うようグループ通信に係る処理を実施する。本実施の形態のように会議システムの場合、ＭＣＵ５０は自身の配下にある各端末１０からのデータを一次合成し、他のＭＣＵ５０に当該合成データを送信する。また、ＭＣＵ５０は、自身で合成した合成データと、他のＭＣＵ５０から受信した合成データとを合成して最終合成データを作成し、当該最終合成データを自身の配下にある各端末１０に送信する。ＭＣＵ５０は、他のＭＣＵ５０と連携して、グループ通信の開催・削除・終了、端末１０の途中参加・途中退出等を制御する。
【００３１】
ネットワーク管理ノード８１は、前記アクセスネットワーク２０・前記中継ネットワーク３０のうちいずれかまたは複数の、ネットワークに係るインフラリソース情報（ネットワークトポロジー、端末１０の位置情報、エッジサーバ４０の位置情報、経路コスト、各ネットワーク区間の可用帯域等）を取得する手段を備える。当該インフラリソース情報は、アクセスネットワーク２０や中継ネットワーク３０を構成する各種ネットワーク機器やネットワーク管理機器から取得する。図２の例では、少なくとも各ネットワーク装置３５からインフラリソース情報の一部を取得する。また、前記ネットワーク管理ノード８１は、前記取得した情報をＭＣＵ管理機能６０へ通知する手段を備える。
【００３２】
サーバインフラ管理ノード８２は、エッジサーバ４０に係るリソース情報（エッジサーバ４０の可用リソース（ＣＰＵ、メモリ、ストレージ、ＧＰＵ等）、サーバを利用した場合の稼働コスト等）を取得する手段を備える。当該サーバリソース情報は、当該エッジサーバ４０から直接又は当該エッジサーバ４０を管理している管理機器がある場合には当該管理機器から取得する。また、前記サーバインフラ管理ノード８２は、前記取得したエッジサーバ４０に係るリソース情報をＭＣＵ管理機能６０へ通知する手段を備える。
【００３３】
また、前記サーバインフラ管理ノード８２は、ＭＣＵ管理機能６０からの指示に基づいて、エッジサーバ４０やＭＣＵ５０に対して様々な操作を行う手段を備える。例えばエッジサーバ４０が仮想ハイパーバイザ（仮想ホストサーバ）でありＭＣＵ５０がＶＭ上で動作するソフトウェアアプリケーションであった場合、前記サーバインフラ管理ノード８２は、各エッジサーバ４０に対してＶＭイメージを送信したり、新規ＶＭを作成したり、既存ＶＭを削除したり、ＶＭを起動／停止させる手段を備える。また、ＭＣＵアプリケーション５０に対して会議室を作成／削除したり、端末へ発呼指示したり、複数のＭＣＵアプリケーションを連携させ、同一仮想会議室として実行させる手段を備える。
【００３４】
なお、前述した、連携や会議室作成／削除、発呼等のＭＣＵ管理機能６０からＭＣＵ５０に対する指示を、サーバインフラ管理ノード８２を介さず前記ＭＣＵ管理機能６０から直接送出するような形態であっても良い。
【００３５】
また、図３に示すように、前述した、連携や会議室作成／削除、発呼等のＭＣＵ管理機能６０からＭＣＵ５０に対する指示を、別途設けたＭＣＵ管理ノード８３を介して前記ＭＣＵ管理機能６０から送出するような形態であっても良い。
【００３６】
次に、ＭＣＵ管理機能６０について図４を参照して詳述する。図４はＭＣＵ管理機能６０の機能ブロック部である。図４に示すように、ＭＣＵ管理機能６０は、会議予約情報受信部６１と、インフラ情報受信部６２と、ＭＣＵ選択計算部６３と、エッジサーバ・アプリケーション制御送信部６４と、を備える。
【００３７】
前記会議予約情報受信部６１は、ユーザからの会議開催予約情報を受け付ける。前記会議開催予約情報には、会議開始／終了時刻、最大参加人数、参加端末一覧等の情報が含まれる。
【００３８】
前記インフラ情報受信部６２は、ネットワークトポロジー、各端末１０の位置を特定する為の情報、各サーバインフラの位置を特定する為の情報、各ネットワーク区間の可用帯域等のリソース情報をネットワーク管理ノード８１から受信する。また、サーバインフラ管理ノード８２から、地域分散された各エッジサーバ４０のリソース情報（可用ＣＰＵ／メモリ／ＧＰＵ／ストレージ等）の情報を受信する。
【００３９】
前記ＭＣＵ選択計算部６３は、前記会議開催予約情報やインフラリソース情報のうち一部または全部の情報を元に、当該開催会議をするにあたりネットワークコスト・サーバインフラリソース・会議品質のバランスが最適となるような１または複数のＭＣＵ５０を算出する。ＭＣＵ選択計算部６３における処理の詳細については後述する。
【００４０】
前記エッジサーバ・アプリケーション制御送信部６４は、ＭＣＵ選択計算部６３で算出された最適計算結果に基づき、選択したＭＣＵ５０が他のＭＣＵ５０と連携してユーザ端末１０からは単一の仮想会議室が開催されているかのように振る舞わせるよう、選択したＭＣＵ５０に対応するエッジサーバ４０及び当該ＭＣＵ５０に対して制御指示を送出する。当該制御指示は、サーバインフラ管理ノード８２を介してエッジサーバ４０及びＭＣＵ５０に送信される。ＭＣＵ５０が、仮想サーバインフラとしてのエッジサーバ４０上のアプリケーションとして動作する場合、エッジサーバ・アプリケーション制御送信部６４は、各仮想サーバインフラに対してＭＣＵアプリケーションのインスタンスを展開し、展開された前記各ＭＣＵアプリケーションインスタンス同士の連携を指示し、仮想会議室を作成し、会議開催時刻になり次第会議参加端末を呼び出し、また、会議終了時に切断・仮想会議室終了・不要となったＭＣＵアプリケーションインスタンスの削除等の指令を、サーバインフラ管理ノード８２を介して送出する。
【００４１】
なお、前述したように、前記制御指示のうちＭＣＵ５０への指示についてはサーバインフラ管理ノード８２を介することなくＭＣＵ管理機能６０から直接送信する形態の場合には、図５に示すように、前記エッジサーバ・アプリケーション制御送信部６４は、エッジサーバ制御送信部６４ａとアプリケーション制御送信部６４ｂを含んで構成する。また、図６に示すように、前記制御指示のうちＭＣＵ５０への指示についてはＭＣＵ管理ノード８３を介して送信する形態の場合も同様である。
【００４２】
次に、本実施の形態に係る多地点間会議システムにおける会議予約から会議開催、会議終了までのフロー例について図７を参照して説明する。ここでは説明の簡単のため、単一の会議の開催手順について説明する。
【００４３】
ＭＣＵ管理機能６０は、まず、開催会議の予約を受け付ける（ステップＳ１）。次に、ＭＣＵ管理機能６０は、ＭＣＵ５０の最適配置を計算する（ステップＳ２）。ここで、ＭＣＵ５０の最適配置計算処理は、会議開始直前、より具体的には、計算およびＭＣＵインスタンス展開にかかる時間から逆算して、会議開始時刻には仮想会議室が利用可能となっているような時刻に開始する。なお、最適配置計算処理の詳細については後述する。
【００４４】
次に、ＭＣＵ管理機能６０は、前ステップで選出されたＭＣＵ位置へＭＣＵインスタンス展開、各ＭＣＵを連携（カスケード接続等）するよう制御指示をエッジサーバ４０及びＭＣＵ５０に対して送出する（ステップＳ３）。
【００４５】
以上の処理により会議が開催される（ステップＳ４）。なお会議開始時には、ＭＣＵ５０は、必要に応じて参加端末１０に対して呼び出しを行う（コールアウト）。会議が終了すると、ＭＣＵ５０は、接続している参加端末１０を切断して、会議終了処理を行う（ステップＳ５）。また、ＭＣＵ管理機能６０は、当該会議を開催していたＭＣＵ５０のＭＣＵインスタンスを削除するようエッジサーバ４０に対して制御指示を送出する。
【００４６】
次に、同時刻に開催予定の複数の会議予約がある場合における会議予約から会議開催、会議終了までのフロー例について図８を参照して説明する。ここでは同時刻にｎ個の会議の開催予約がある場合について説明する。
【００４７】
ＭＣＵ管理機能６０は、まず、開催会議の予約を受け付ける（ステップＳ１１）。次に、ＭＣＵ管理機能６０は、会議１〜ｎのそれぞれについてＭＣＵ５０の最適配置を計算し、最適配置の評価指標となる「コスト（後述する）」をそれぞれ記憶しておく（ステップＳ１２）。
【００４８】
次に、ＭＣＵ管理機能６０は、会議１〜ｎの何れかに参加する全端末の情報に基づき、同様のコスト計算を行う（ステップＳ１３）。ただし、ＭＣＵ配備候補場所は前ステップで選択された場所に限定する。そして、ＭＣＵ管理機能６０は、前ステップで算出されたトータルコストと本ステップで算出されたコストとを比較し、最終配置を決定する。なお、本ステップの他の実施例としては、会議１の開催によって占有されるリソースを差し引いて会議２以降の最適配備計算をする方法や、一旦この段階では他の同時刻会議のリソースを度外視して計算する方法などが考えられる。
【００４９】
次に、ＭＣＵ管理機能６０は、前ステップで選出されたＭＣＵ位置へＭＣＵインスタンス展開、各ＭＣＵを連携（カスケード接続等）するよう制御指示をエッジサーバ４０及びＭＣＵ５０に対して送出する（ステップＳ１４）。
【００５０】
以上の処理により会議が開催される（ステップＳ１５）。なお会議開始時には、ＭＣＵ５０は、必要に応じて参加端末１０に対して呼び出しを行う（コールアウト）。会議が終了すると、ＭＣＵ５０は、接続している参加端末１０を切断して、会議終了処理を行う（ステップＳ１６）。また、ＭＣＵ管理機能６０は、当該会議を開催していたＭＣＵ５０のＭＣＵインスタンスを削除するようエッジサーバ４０に対して制御指示を送出する。
【００５１】
なお、会議開催時刻が同じでも、終了時刻は会議によって異なるので、実施例のバリエーションとしては、時間も加味したコスト比較を行う方法も考えられる。また、１５分未満の会議では最適配置計算をしない等の例外処理も考えられる。
【００５２】
次に、前記ステップＳ２や前記ステップＳ１２のＭＣＵ最適配置計算処理の詳細について図９を参照して説明する。なお、本例では、最適配置計算処理に必要な情報の一部であって頻繁に変更されるものでない情報については、予めＭＣＵ管理機能６０に保持されているものとする。このような情報は、最適配置計算の度にリクエストするのではなく、別のタイミングで定期的または情報更新トリガに応じて取得すればよい。このような情報の例としては、ネットワークトポロジー、エッジサーバ４０の位置、各ネットワーク区間の経路コスト、各エッジサーバ４０の利用コスト、などが挙げられる。
【００５３】
図９に示すように、ＭＣＵ管理機能６０は、ネットワーク管理ノード８１に対して、会議参加端末１０の位置を照会する（ステップＳ２１）。ここでネットワーク管理ノード８１は、会議予約情報および会議サービス構成要素（例えばＨ．３２３であればＧａｔｅｋｅｅｐｅｒ）から得られた会議参加端末１０のＶＰＮ（Virtual Private Network）上の識別子（プライベートＩＰアドレスやＥ．１６４番号等）と、インフラ側の識別子（ＮＧＮ（Next Generation Network）であれば網内ＩＰｖ６アドレスや回線番号等、モバイルネットワークであれば端末識別子やＧＴＰ（GPRS Tunneling Protocol）トンネルのＩＤ等）との対応関係を参照し、会議参加端末１０のネットワークトポロジー上の位置をＭＣＵ管理機能６０へ返答する。
【００５４】
次に、ＭＣＵ管理機能６０は、ネットワーク管理ノード８１に対して、当該時点の各ネットワーク区間の可用帯域情報をリクエストする（ステップＳ２２）。
【００５５】
次に、ＭＣＵ管理機能６０は、サーバインフラ管理ノード８２に対して、当該時点のエッジサーバ４０の可用リソース情報をリクエストする（ステップＳ２３）。
【００５６】
ＭＣＵ管理機能６０は、以上のステップにより取得した各情報及び予め取得・保持している情報に基づき最適配置計算処理を実行する（ステップＳ２４）。
【００５７】
次に、前記ステップＳ２４の詳細な処理の一例について図１０を参照して説明する。ここでは、図２に示すように、中継ネットワーク３０のネットワークトポロジーが、他網７０側が上位階層であり且つ端末１０側が下位階層とするツリー構造を有しているものとする。
【００５８】
ＭＣＵ管理機能６０は、最上位階層から順に階層毎に以下の処理を行う（ステップＳ３１〜Ｓ３７）。各階層（階層ｉ）の処理は、まず、前述したように予め取得しておいたネットワークトポロジー情報から、当該階層ｉにおけるエッジサーバ数（ｊ）の最大値Ｊを調べる（ステップＳ３２）。次に、ＭＣＵ管理機能６０は、当該階層ｉのエッジサーバリストのうちリソースが可用なものをリスト化（ｊ＝０〜Ｊ）する（ステップＳ３３）。ここで、当該階層ｉに可用なエッジサーバがない場合には、次の下位階層に処理を移す（ステップＳ３４，Ｓ３６，Ｓ３７）。
【００５９】
次に、ＭＣＵ管理機能６０は、Ｎｏｄｅｉ−０〜Ｎｏｄｅｉ−Ｊ（のうち可用なもの）の全ての場所にＭＣＵを配置したと仮定した場合の、
（ａ）各端末（Ｅｎｄｐｏｉｎｔ０〜Ｎ）から最寄りの（ネットワークトポロジーを上流方向へ辿った際に最短で到達可能な）ＭＣＵまでの経路コストの総和
（ｂ）エッジサーバ稼働コストの総和（ただし、会議トラヒック流通のないエッジサーバや、１入力・１出力のエッジサーバはカウントしない）
について重みを考慮して算出し、合算する（ステップＳ３５）。そして、ＭＣＵ管理機能６０は、合算値をＣｏｓｔ［ｉ］として記憶する。なお、厳密には、どのＭＣＵを親ＭＣＵとするか（または上位階層に１つＭＣＵを新たに配置して親ＭＣＵとする）など、同一階層においても複数のパターンのコストを算出可能である。その場合はコストが最小のものを当該階層の代表コスト値としてＣｏｓｔ［ｉ］に代入すればよい。ここで、親ＭＣＵとは、２台以上のＭＣＵが連携することで一つの仮想的な会議が開催されるようなシステム（例えばカスケード接続されたＭＣＵ群）の中で、制御の中心となるＭＣＵを意味する。３台以上のＭＣＵがツリー状トポロジーでカスケード接続される場合は、一般的にはツリーの根に位置するＭＣＵが親ＭＣＵとして動作する。（ただし、本実施例ではツリー状カスケード接続を行うＭＣＵを例として用いて説明しているが、連携し合う複数のＭＣＵ群が親ＭＣＵ／子ＭＣＵの概念なく対等に連携するシステムも考えうることに留意されたい。）以上の処理を下位に向かって各階層で行う（ステップＳ３６，Ｓ３７）。
【００６０】
次に、ＭＣＵ管理機能６０は、Ｃｏｓｔ［０］〜Ｃｏｓｔ［Ｉ］の全てが空値の場合には、サービス提供不可エラーフラグを付与して処理を終了する（ステップＳ３８，Ｓ４０）。一方、ＭＣＵ管理機能６０は、Ｃｏｓｔ［０］〜Ｃｏｓｔ［Ｉ］の何れかに値がある場合には、空値でないＣｏｓｔ［０］〜Ｃｏｓｔ［Ｉ］のうち最小となる場合のＭＣＵ配置パターンを最適配置であるとして確定する（ステップＳ３８，Ｓ３９）。
【００６１】
次に、図１０を参照して詳述した最適配置計算処理の具体例について説明する。計算に使う情報の例としては以下のものが挙げられる。
【００６２】
・ネットワークトポロジー
・参加者位置情報
・エッジＭＣＵ動作コスト（経路コストとつり合うような値が予め設定される。階層ごとに重み付けが異なっても良いし、「離島などメンテナンスの保守稼働のかかる地域のエッジサーバを使用するコストは高い」、「特殊なイベントが開催中な場合、当該地域近傍のエッジサーバの使用コストが一時的に高く設定される」などの形態があってもよい。）
・各ネットワーク区間の可用帯域
・エッジサーバの可用リソース情報、ＭＣＵをあるエッジサーバで稼働させた場合の使用見込みコスト（エッジサーバが使用可能かどうかの判定に使う）
・会議端末帯域
・ＭＣＵ間帯域
・ＭＣＵカスケード接続段数上限
・ＭＣＵ数上限
・各ネットワーク区間の経路コストの重み付け係数（上位階梯になる程係数が大きい（コストが高い）等）
・最小収容ユーザ数（例えば配下に１端末しか収容されない（１入力・１出力となる）ＭＣＵは稼働させる意味が無いので、「２」以上とする等）
【００６３】
本具体例では、説明を簡単にするため、以下のような条件を仮定する。
【００６４】
・ネットワークトポロジー：ツリー構成、階層は４階層（ｉ＝０〜３）（図１１参照）
・参加者位置情報：図１１に示すとおり。便宜上、会議参加端末の名前を端末１〜端末８とする
・エッジＭＣＵ動作コスト：簡単のため、重み付けはせず、一律「４」とする
・特定経路の許容最大帯域：本例ではボトルネックが存在しないこととする
・エッジサーバの可用リソース情報：全てのエッジサーバに十分な可用リソースがあるとする
・端末帯域：一律「１Ｍｂｐｓ」とする。また、重み付け係数なしの経路を通るときの経路コストを１Ｍｂｐｓあたりコスト「１」とする
・ＭＣＵ間帯域：受信した映像データがＭＣＵにおいて合成された後は、一律１画面分（１Ｍｂｐｓ）の帯域に圧縮され、他のＭＣＵや配下の端末に配信されるとする
・ＭＣＵカスケード接続段数上限：「２」とする
・ＭＣＵ数上限：上限なしとする
・各ネットワーク区間の経路コストの重み付け係数：（階層０（再上流）：４，階層１：３，階層２：２，階層３：１とする（図１１参照）
・最小収容ユーザ数：「２」とする
【００６５】
以上の仮定のもと図１０を参照して詳述した最適配置計算処理を実行する。まず階層０におけるコスト計算について図１２を参照して説明する。階層０ではノードはＮｏｄｅ０−０の１つのみなので、この位置にＭＣＵを配備した場合の総コストを計算する。その結果、図１２に示すように、Ｃｏｓｔ［０］は８４となる。
【００６６】
次に、階層１におけるコスト計算について図１３を参照して説明する。階層１ではＮｏｄｅ１−０とＮｏｄｅ１−１の位置にＭＣＵを配備した場合の総コストを計算する。その結果、図１３に示すように、Ｃｏｓｔ［１］は６４となる。
【００６７】
次に、階層２におけるコスト計算について図１４を参照して説明する。階層２ではＮｏｄｅ２−０〜Ｎｏｄｅ２−３の位置にＭＣＵを配備した場合の総コストを計算する。ただし、Ｎｏｄｅ２−１については配下に会議参加端末が１つしか収容されず、当該ノードは１入力・１出力となるため、当該ノードでＭＣＵは稼働させる意味が無い。このため、Ｎｏｄｅ２−１は不使用とする。そして、Ｎｏｄｅ２−１配下の参加端末は、Ｎｏｄｅ２−１の代わりに、最短で到達可能な他の同階層のノード、換言すれば最も小コストで収容可能な他の同階層のノードであるＮｏｄｅ２−０に収容させることとする（図１４の※１参照）。
【００６８】
また、図１４では、複数ＭＣＵのうち中核となるＭＣＵ（「親ＭＣＵ」と呼ぶ。それ以外のＭＣＵを「子ＭＣＵ」と呼ぶ。）をＮｏｄｅ２−０とした場合について説明している（図１４の※２参照）。なお、本例では説明を省略するが、厳密にはＮｏｄｅ２−２  ，Ｎｏｄｅ２−３それぞれを親ＭＣＵとした場合のＭＣＵ間の経路コストも計算して大小比較する。その結果、図１４に示すように、Ｃｏｓｔ［２−１］は７０となる。
【００６９】
次に、図１５では、階層２において、不使用とするＮｏｄｅ２−１配下の参加端末は、Ｎｏｄｅ２−１の代わりに、最短で到達可能な他の上位階層のノード、換言すれば最も小コストで収容可能な他の同階層のノードであるＮｏｄｅ１−０に収容させることとする（図１５の※１参照）。また、親ＭＣＵを同一階層中のＭＣＵから選出するのではなく、１階層上のＮｏｄｅ１−０に別途配置する（図１５の※２参照）。その結果、図１５に示すように、Ｃｏｓｔ［２−２］は６８となる。
【００７０】
次に、図１６では、階層２において、不使用とするＮｏｄｅ２−１配下の参加端末は、Ｎｏｄｅ２−１の代わりに、最短で到達可能な他の同階層のノード、換言すれば最も小コストで収容可能な他の同階層のノードであるＮｏｄｅ２−０に収容させることとする（図１６の※１参照）。また、親ＭＣＵを同一階層中のＭＣＵから選出するのではなく、１階層上のＮｏｄｅ１−１に別途配置する（図１６の※２参照）。その結果、図１６に示すように、Ｃｏｓｔ［２−３］は６３となる。
【００７１】
以上の処理により階層２について各Ｃｏｓｔ［２−１］〜Ｃｏｓｔ［２−３］のうち、Ｃｏｓｔ［２−３］が最小であるので、階層２の代表コストとしてＣｏｓｔ［２］に６３を代入する。
【００７２】
本例では、階層３についての計算過程例は省略するものとする。階層０〜２の各コストＣｏｓｔ［０］〜Ｃｏｓｔ［２］のなかでＣｏｓｔ［２］がコスト最小なので、当該コストを計算した際のＭＣＵ配置構成をメモリに記憶して計算を終了させる。
【００７３】
ＭＣＵ最適配置計算ステップの他の例について図１７を参照して説明する。例えば、ＭＣＵ増設コストが高めの設定であったり、会議参加端末の地域偏りが大きい場合には、参加端末の地域分散性の偏りに応じて、ベストなＭＣＵ配置階層にばらつきがあっても対応可能なようにすると好適である。すなわち、全体コストだけでなく、部分的なコスト増減を見るようにすると好適である。図１７の例では、会議参加端末（図中のハッチングが付されている端末）が地域的に偏っている場合を示している。
【００７４】
この場合、
・階層０の計算
・階層１：Ｎｏｄｅ１−１配下の計算、階層１−２配下の計算、・・・、階層１−ｋ配下の計算
・階層２：Ｎｏｄｅ１−１−１〜１−１−ｌ  ＋  Ｎｏｄｅ１−１  〜  Ｎｏｄｅ１−１−ｘ間の経路コストが増加していないか確認
というステップで計算を行う。なお、ＭＣＵ増設コスト次第では前階層有利と判断し、一部の枝だけ階層を戻ることを許容すると好適である。
【００７５】
ＭＣＵ最適配置計算ステップの他の例について図１８を参照して説明する。本例は、あらゆる合流地点にまずはＭＣＵを配備した場合を仮定し、徐々にＭＣＵ稼働個所を除外していき、コスト和がより最適となる配置を探索する。なお、最適解は、各コスト重み付けやＭＣＵ数上限、ＭＣＵ多段数上限等の条件により異なる。
【００７６】
本例では、総当たりで探索する場合２１１＝２０４８通りのＭＣＵ配置パターンがありうる（厳密には更に、同一ＭＣＵ配置でも親−子ＭＣＵ関係の各パターンも考慮が必要）。そこで、
・１−ｉｎ−１−ｏｕｔを優先的に除外する
・下層（ＮＷコスト低）で収容数の少ないＭＣＵを優先的に除外する
など、無駄な計算をなるべく削減し、効率良く計算する。より発展的には、機械学習を併用し、効率的な省略パターンの実績情報を蓄積し、次回の計算に反映するなどが考えられる。
【００７７】
ＭＣＵ最適配置計算ステップの他の例について図１９〜図２１を参照して説明する。本例は、同時刻に２つの会議が開催される場合の例である。この場合、図１９に示すように、まず第１会議について図１１を参照して詳述したアルゴリズムによりＭＣＵ最適配置を計算する。同様に、図２０に示すように、第２会議について図１１を参照して詳述したアルゴリズムによりＭＣＵ最適配置を計算する。次に、（Ａ）第１会議と第２会議を一体とみなした上で同様のコスト計算をするとともに、（Ｂ）第２会議のＭＣＵ設置候補を第１会議の結果算出された場所に限定して計算をしてみる。そして、（Ｃ）前記（Ａ）と前記（Ｂ）のコストを比較して最小コストの構成を採用する。なお、図１９〜図２１の例では、前記（Ａ）の方がコストは低くなるが、ただしサーバ稼働コストの重み次第では、別の会議で立ち上がる見込みのＭＣＵ設置個所に相乗りすることで、トータルのコストが逆転する可能性がある。
【００７８】
以上本発明の実施の形態について詳述したが本発明はこれに限定されるものではない。例えば、上記実施の形態では、多地点間通信システムの適用例として会議システムについて説明したが、他のシステムにも適用できる。適用例としては、例えば、Ｗｅｂ会議システムや、リアルタイム映像配信システム、ファイル転送を行うマルチキャスト配信システムなどが挙げられる。
【００７９】
また、上記実施の形態においては、ＭＣＵ５０の管理機能として、ＭＣＵ管理機能６０、ネットワーク管理ノード８１、サーバインフラ管理ノード８２、ＭＣＵ管理ノード８３による実装例を説明したが、各機能を集中化や分散化など他の実装形態でも本発明を実施できる。
【００８０】
また、上記実施の形態では、中継ネットワーク３０のネットワークトポロジーがツリー構造の場合について説明したが、他のネットワークトポロジーであっても本発明を実施できる。この場合には、ネットワークトポロジーに応じて好適なコスト計算アルゴリズムを採用すればよい。
【符号の説明】
【００８１】
１０…端末
２０…アクセスネットワーク
３０…中継ネットワーク
３５…中継装置
４０…エッジサーバ
５０…ＭＣＵアプリケーション
６０…ＭＣＵ管理機能
６１…会議予約情報受付部
６２…インフラ情報受信部
６３…ＭＣＵ選択計算部
６４…エッジサーバ・アプリケーション制御送信部
６４ａ…エッジサーバ制御送信部
６４ｂ…アプリケーション制御送信部
７０…他網
８１…ネットワーク管理ノード
８２…サーバインフラ管理ノード
８３…ＭＣＵ管理ノード
【図１】
2019125996.tif 000003
【図２】
2019125996.tif 000004
【図３】
2019125996.tif 000005
【図４】
2019125996.tif 000006
【図５】
2019125996.tif 000007
【図６】
2019125996.tif 000008
【図７】
2019125996.tif 000009
【図８】
2019125996.tif 000010
【図９】
2019125996.tif 000011
【図１０】
2019125996.tif 000012
【図１１】
2019125996.tif 000013
【図１２】
2019125996.tif 000014
【図１３】
2019125996.tif 000015
【図１４】
2019125996.tif 000016
【図１５】
2019125996.tif 000017
【図１６】
2019125996.tif 000018
【図１７】
2019125996.tif 000019
【図１８】
2019125996.tif 000020
【図１９】
2019125996.tif 000021
【図２０】
2019125996.tif 000022
【図２１】
2019125996.tif 000023