複数のコンピュータ間のデータ配布システム、方法及びソフトウェアアプリケーション
本発明は複数のコンピュータの間でデータを伝送する方法に関する。複数のコンピュータが複数のバーチャルゾーンに分類される。アルゴリズムが用いられることにより複数のバーチャルゾーンのそれぞれに属する各コンピュータのリンク方式が決定される。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、複数のコンピュータ間のデータ配布システム、方法及びソフトウェアアプリケーションに関する。本発明は、限定的にではなく、特にコンピュータネットワーク間のデータのピアツーピアマルチキャスト及びユニキャストの分野における用途に資する。
【背景技術】
【０００２】
近年のソーシャルネットワークコンピュータシステム及びマルチユーザのバーチャルコンピュータ環境の誕生により、マルチパーソンツーマルチパーソン通信の必要性が高まってきている。
【０００３】
バーチャルコミュニティの通信ツールは、非同期通信（例えばチャット、電子メール、メッセージングなど）又は電話方式のワンツーワン相互通信に制限されている。「臨場型通信（immersive communications）」の分野においていくつかの試みがなされているが、この分野ではバンド幅の制限克服のためのさらなる試みが必要とされている。
【０００４】
臨場的通信は、ユーザが実際のクラウド（crowd）に接した際の感覚と同様の聴覚的かつ視覚的場面を当該ユーザに対して与える。例えば、聴者の音響環境においてバーチャルクラウドにおける他人の音声が、各人の仮想の場所に完全に調和して空間的に配置される。同様に、観者の視野内に他の参加者の映像が適当に配置される。「臨場型」という用語は、バーチャルリアリティヘッドマウンテッドディスプレイ又はＣＡＶＥ（Cave Automatic Virtual Environment）等の臨場型ディスプレイ技術に限定されるわけではない。「臨場型」とは、聴覚的かつ視覚的場面における適当な情報が利用可能であることを広く意味する。多くのシナリオにおいて、簡易なモニター又はハンドヘルドディスプレイがあれば臨場的経験を提供するのに十分である。
【０００５】
臨場型マルチメディア通信は、基本的にマルチポイントツーマルチポイント通信システムである。各ユーザの音声及び映像又はコンテンツ等、各ユーザにより創出されたマルチメディア情報はリアルタイムで他の参加者の部分集合に届けられる必要がある。この部分集合は、バーチャルクラウドにおけるユーザの移動の結果として動的に変化し、かつ、環境におけるバリヤ、ウォール及びその他のバーチャルアーチファクトの存在に影響される。それは、バーチャル環境を通じたメディアの伝播特性にも依存する。例えば、音声はウォールを通じて伝播可能である一方、視覚的情報は伝播不可能である。
【発明の概要】
【発明が解決しようとする課題】
【０００６】
マルチポイントツーマルチポイント通信システムの可能性に関してはほとんど研究されてこなかった。
【課題を解決するための手段】
【０００７】
第１態様において、本発明は、複数のコンピュータの間でデータを伝送する方法であって、前記複数のコンピュータを複数のバーチャルゾーンに分類する過程と、アルゴリズムを用いることにより前記複数のバーチャルゾーンのそれぞれに属する各コンピュータのリンク方式を決定する過程と、を含んでいる方法を提供する。
【０００８】
一態様において、前記複数のコンピュータがツリー構造を用いてリンクされている方法が提供される。前記ツリー構造が、前記複数のコンピュータの間の仮想的距離及び物理的距離のうち一方を、前記ツリー構造を定義するための計量として用いてもよい。他の態様において、前記ツリー構造が、前記複数のコンピュータの間の仮想的距離及び物理的距離の組み合わせを、前記ツリー構造を定義するための計量として用いてもよい。
【０００９】
第２態様において、本発明は、複数のコンピュータの間でデータを伝送するシステムであって、前記複数のコンピュータを複数のバーチャルゾーンに分類する手段と、アルゴリズムを用いることにより前記複数のバーチャルゾーンのそれぞれに属する各コンピュータのリンク方式を決定する手段と、を備えているシステムが提供される。
【００１０】
一態様において、前記複数のコンピュータがツリー構造を用いてリンクされているシステムが提供される。前記ツリー構造が、前記複数のコンピュータの間の仮想的距離及び物理的距離の組み合わせを、前記ツリー構造を定義するための計量として用いてもよい。前記ツリー構造が、前記複数のコンピュータの間の仮想的距離及び物理的距離のうち一方を、前記ツリー構造を定義するための計量として用いてもよい。
【００１１】
第３態様において、本発明は、複数のコンピュータの間でデータを伝送する方法であって、前記複数のコンピュータを包含するコンピュータネットワークのトポロジーを決定する過程と、前記トポロジーを用いることにより適当なネットワーク形成アルゴリズムを選択する過程と、を含んでいる方法を提供する。
【００１２】
第４態様において、本発明は、コンピュータの読み取り記録媒体に格納され、第１態様又は第３態様の方法を前記コンピュータに実行させるコンピュータプログラムを提供する。
【００１３】
第５態様において、本発明は、第４態様のコンピュータプログラムを提供するコンピュータ読み取り可能な記録媒体を提供する。
【００１４】
明細書において「データ（data）」という用語は、コンピュータシステムにより利用されうる任意のデータの集合を包含する広い概念を意味している。データは、例えば、マルチメディアファイル（例えば、音響映像ファイル、映像ファイル、データファイルなど）、電子メール、インスタントメッセージ若しくはあらゆる潜在的な情報の「断片」等の他の情報集合である。データは必要に応じて暗号化されてもよい。
【図面の簡単な説明】
【００１５】
本発明の範囲にはここで述べる以外の実施形態も包含されるが、本発明の実施形態を実施例の添付図面を参照しながら説明する。
【図１】図１Ａ〜図１Ｃは、本発明の一実施形態にしたがった複数のコンピュータ装置の間のデータ伝送用のコンピュータネットワークの実施例を示す図である。
【図２】図２Ａ〜図２Ｂは、本発明の一実施形態にしたがったマルチキャストツリーを示す図である。
【図３】図３Ａ〜図３Ｃは、本発明の一実施形態にしたがったマルチキャストスキームの正規化コストを表わすグラフである。
【図４】図４Ａ〜図４Ｂは、本発明の一実施形態にしたがったマルチキャストネットワークにおいて生じる遅れ違反及び合計超過遅れを表わすグラフ。
【発明を実施するための形態】
【００１６】
複数のコンピュータシステムの間であらゆるタイプのデータを伝送するためのシステム又は方法、特に、インターネット等の通信ネットワークを介して遠く離れて接続されている複数のコンピュータシステムの間で（圧縮された又は非圧縮の）映像及び音声ファイル等のマルチメディアファイルを伝送するためのシステム又は方法に関連して本発明の実施形態が記述される。ただし、本発明は記載された実施形態に限定されず、任意の数かつ任意の構成のコンピュータシステムの間でのあらゆる形式の電子ファイルの伝送に適用されうることを理解されたい。
【００１７】
図１Ａ及び図１Ｂに示されているように、それぞれが一又は複数のサーバコンピュータ１０２，１０４の形態である複数のコンピュータ装置の間でデータファイルが伝送される。
【００１８】
コンピュータ１０２及び１０４は、ローカルネットワーク又は広域ネットワークの形態の通信ネットワーク１０８を通じて接続され、かつ、ＴＣＰ／ＩＰプロトコル等のパケットスイッチプロトコルを用いて通信する。
【００１９】
コンピュータ１０２及び１０４のそれぞれは、マザーボード、ＣＰＵ（central processing unit）１１０、ＲＡＭ（random access memory）１１２、ハードディスク１１４及びネットワーク用ハードウェア１１６を含む適当なコンピュータハードウェアを備えている。コンピュータ１０２及び１０４のそれぞれは、ハードウェアに加えて、オペレーティングシステム（例えば、ＵＲＬがhttp://www.redhat.com、http://www.suse.com及びhttp://www.ubuntu.comであるウェブサイト等、多数のプロバイダからインターネット経由で取得可能なLinux OSなど）を備えている。オペレーティングシステムは、ハードディスクに収められ、ハードウェアと協働してソフトウェアアプリケーションが実行されうる環境を提供する。
【００２０】
コンピュータ１０２及び１０４のそれぞれは、データファイルを受信（かつ送信）するための標準的なソフトウェア及び（ＴＣＰ／ＩＰソケット等の）ハードウェアを有する受信モジュールを備えている。
【００２１】
図１Ｂ及び図１Ｃには、本実施形態のシステムが詳細に示されている。図１Ｂには、ピア（peer）Ｐ１〜Ｐ１１のバーチャル表現（アバター）を示す符号Ａ１〜Ａ１１とともにバーチャルクラウドの一部分が示されている。図１Ｃに示されているように、Ｐ１〜Ｐ１１は、基礎となるインターネット又はイントラネットに対するピアツーピアオーバーレイネットワークを構成する。
【００２２】
ピアＰ１に対応するＡ１等、バーチャルクラウドのあらゆるメンバーを勘案し、臨場型の音響及び映像通信に限定されると仮定する。ジェスチャー、触覚及びユーザが創出したコンテンツ等の他のタイプのメディアの伝播は類似しているものの異なる要求があるため、本実施形態においては勘案されない。Ａ１の視覚的範囲及び聴覚的範囲のそれぞれは、図１Ｂに実線及び破線のそれぞれにより示されている。
【００２３】
対称性（すなわち、バーチャルクラウドの各メンバーＡ１〜Ａ１１が、ウォール等のバリヤが存在しない場合、相互に視聴可能である）を仮定すると、Ｐ１の音声及び映像は、聴覚的かつ視覚的場面に包含されるレンジに存在するすべてのピアに届けられる必要がある。これは、音声に関してはＰ２〜Ｐ７、映像に関してはＰ１〜Ｐ５及びＰ１１に相当する。さらに、Ａ５〜Ａ７はＡ１から遠く離れており、当該ピアに対してＡ１の音声は大きな遅れを伴って伝達され、かつ、空間的な正確性が低下した状態になる。同様に、バーチャル間隔が大きいため、Ａ３、Ａ５及びＡ１１は、Ａ１の映像について低い解像度及びフレームレートを許容することができる。しかし、このＱｏＳ（Quality of Service）の変化は、バーチャルクラウドにおける現在は位置に依存しており、バーチャルスペースでアバターＡ１〜Ａ１１が動くことにより時間経過とともに変化する。
【００２４】
ＩＰレイヤーにおけるネイティブマルチキャストサポートが存在しない場合、マルチポイントツーマルチポイントコンテンツの伝播のためのユニキャストモデルは図１Ｃに示されているように理解されうる。図１Ｃを乱雑にすることを回避するため、Ｐ１の映像配信のみが示されている。しかし、各ピアは、聴覚的又は視覚的範囲におけるピアの部分集合に対して音声及び映像の両方をユニキャストする必要がある。したがって、バーチャルクラウド全体に対して、平均でｍＤＮのユニキャストフローが必要とされる。ここで「ｍ」はメディアのタイプ（例えば音声及び映像）の数であり、「Ｎ」は参加者の数であり、密度「Ｄ」は書くピアノ通信範囲内に存在する参加者の平均数である。Ｐ１に着目し、かつ、ｒが映像のビットレートだと仮定すると、このピアノ映像を配信するために必要とされるアップロードキャパシティの平均はｒＤである。後述するように、映像フローの間のＱｏＳ差別化を用いることによりこの値は低減されうる。この目的で用いられる２つの可能性があるコーディング技術が、レイヤードコーディング及びマルチプルディスクリプションコーディングである。両方の場合、バーチャルワールドにおいて著しく離れているピアに対する映像フローは、図１Ｃに薄い矢印で示されている映像パケットの部分集合を含んでいるのみであろう。
【００２５】
受信側において、各ピアは、聴覚的範囲及び視覚的範囲における全員から多数のユニキャストフローを受信する。
【００２６】
平均的に、このダウンロードキャパシティは、ユニキャスト配信の場合のアップロードキャパシティと同じである。マルチキャストスキームの形式を用いることによりアップロードキャパシティの要求を低減することが考えられるが、ダウンロードキャパシティを低減させる唯一の途は前記のようにＱｏＳ差別化の採用であることに注意を要する。
【００２７】
ネイティブマルチキャストサポートがＩＰレイヤーに存在する場合、Ｐ１は、アップロードキャパシティの要求を著しく低減する一の映像フローをマルチキャストフローとして送信すれば足りる。ＩＰマルチキャストは、同一リンクを通じた重複フローを解消することにより、ネットワーク送信キャパシティの利用効率を向上させる。マルチキャストに対して最短経路ツリーが用いられることが仮定され、かつ、マルチキャストフローの複製及びルーティングに必要な付加的な処理が無視された場合、各フローが接するレイテンシ（latency）はユニキャストの場合に近いものになる。ダウンロードキャパシティは同一のままに維持され、マルチキャストがＱｏＳ差別化を提供しない場合には悪化することはない。
【００２８】
（マルチキャストのためのピアツーピアモデル）
コンテンツ配信のためのピアツーピアマルチキャストを生じさせるためには３つの手法がある。ここでは、例として、Ｐ１の映像伝播のための単一のマルチキャストツリーが考察される。しかし、マルチポイントツーマルチポイント通信セッションは、平均的にｍＮ個のオーバーレイマルチキャストツリーを必要とし、各ピアは、ソース、リレー又はリーフノードとして‘ｍＤ＋ｍ’個のマルチキャストコネクションに参加するとともに、当該ツリーの形成及び補修のオーバーヘッドに貢献する。バーチャルクラウド及び攪拌（churn）（ピアの参加及び離脱）は、マルチキャストツリーの変化に変換される。平均的に、参加者のバーチャルムーブメント又は攪拌は、再計算されかつ他のピアに通信される必要がある‘ｍＤ＋ｍ’個のマルチキャストツリーに影響を及ぼす。
【００２９】
以下の実施例を明確化するため、各参加者の視覚的範囲が３つのゾーンに分割されていると仮定する（図２Ｂ参照）。レシピエントがゾーン１に存在する場合、映像のための最高ビットレートが必要とされる。ゾーン２及び３は、映像送信のために段階的に低いビットレートを必要とする。これは、３つのディスクリプションを有するマルチプルディスクリプションコーディングスキーム、又は階層レイヤードコーディングが用いられることにより実現される。以降、明確化のため、連続するゾーンにおけるビットレートの減少をモデル化するため、単一のパラメータが用いられる。換言すると、レシピエントがゾーン１からゾーン２へ移動した場合又はゾーン２からゾーン３に移動した場合、映像ビットレートが因子α（α≦１）だけ低下する。メインプロファイルＨ．２６４（ＩＴＵ（International Telecommunication Union）により開発された映像コーディングスキーム）を用いて暗号化された多数の「トーキングヘッド」映像について実験結果が得られた。映像の質の変化は、α〜０．６５がビットレート低下率についてよい近似であることが確認された。
【００３０】
（マルチキャストツリー形成スキーム）
図２Ａは、ピア同士の物理的間隔がコスト計量として用いられる最短経路マルチキャストツリーが生成される場合を示している。マルチキャスト用のピアツーピアアルゴリズムとして最も一般的なものが適用される。ピアは、通信遅れの直接検出、又は周知のランドマークを基準とする測定等、物理的近似性を近似する多数のアルゴリズムを利用することができる。最良の結果のため、このような情報はすべてのピアに対して有効なものとされ、かつ、矛盾がないように維持される。
【００３１】
ＱｏＳ差別化を考慮に入れるための付加的なアルゴリズムがないと、送信キャパシティの一部が無駄になる。例えば、Ｐ５がＰ１に対してゾーン３に存在し、ビットレートα２ｒの映像を要求した場合、より質の高いコンテンツを要求する他のピアに至る唯一の経路であるため、当該映像はフルレートでダウンロードされる必要がある。
【００３２】
一方、図２Ｂは、バーチャルシーンにおける複数のピアの配置に基づき、アバター間のバーチャル距離が第１の「コスト」計量として用いてマルチキャストツリーが構築されている場合を示している。このスキームの利点は、マルチメディアコンテンツがツリーの下方に移動した場合、多くのホップが横断され、かつ、遅れが大きくなる点である。しかし、バーチャル距離も増加し、これは、知覚インパクトが弱い、より長い遅れをピアが許容することができることを意味する。
【００３３】
例えば、Ａ１に最も近いアバターＡ２及びＡ４は、Ａ５への経路が３つのオーバーレイホップを有する一方（経路Ｐ１−Ｐ２−Ｐ３−Ｐ５）、最小の遅れを伴って音声及び映像を受け取る（直接的なオーバーレイ経路Ｐ１−Ｐ２及びＰ１−Ｐ４）。
【００３４】
直感的に、視覚的範囲における３つのゾーンが示され、かつ、αが一のゾーンから他のゾーンへの映像の質低下に関連するビットレート低減因子を表わし、Ａ１及びＡ５のバーチャル間隔のためにこの遅れのインパクトは弱くなる。映像パケットはツリーを下方に移動し、リレーされる映像レイヤー又はディスクリプションの数が減らされること等により、続くホップにおいてリレーされる情報量が減少する。このため、遅れ及びビットレートに関するＱｏＳ差別化は、オーバーヘッドがほとんどない又は皆無の当該手法の自然な結果である。
【００３５】
当該手法の他の利点は、ツリー構造に関するトポロジー情報の変換が不要である点である。これは、全員に対する一貫したバーチャル環境を表わす状態に関する情報の変換を通じて、バーチャルトポロジーの詳細が、各ピアにとってすでに有効なものであるためである。これにより、マルチキャストツリーの構築のためのアルゴリズムの開発、及びピアの再組織化を伴わないバーチャルムーブメント又は攪拌の結果としてのリペアが促される。
【００３６】
ルート最適化の基礎としてバーチャル間隔を用いることの鍵となる短所は、バーチャル環境に近いアバターが、物理的に遠く離れており、送信キャパシティの利用が不十分になるということである。前記例において、Ａ１の音声及び映像が、バーチャル近接性に基づいてＡ２に送信され、さらにＡ３に送信される。Ｐ１及びＰ２がオーストラリアにいる一方、Ｐ２が英国にいると仮定する。Ａ１のコンテンツがＡ２に届けられるためには英国に行く必要があるという事実は、当該ピアが相互通信する際の助けとはならない。しかし、Ａ１のデータがＡ３に届けられるために英国から戻ってこなくてはならない点が関心事項である。
【００３７】
図２Ｃに示されている第３の手法は、前記２つのスキームの欠点を補い合うハイブリッドスキームである。この場合、物理的距離は最短経路ツリーを生成するために用いられるが、アルゴリズムはバーチャルゾーンに応じた３つの連続する段階に対して適用される。前記例において、第１段階ではＰ１とゾーン１におけるその他のすべてのピアとの最短経路ツリーが生成される。このツリーは、第２段階ではゾーン２におけるピアを包含するように拡張される。最終段階において、ゾーン３におけるピアがツリーに参加する。この目的は、キャパシティ利用効率を過剰に犠牲にすることなく、ＱｏＳ差別化スキームを改良することにある。
【００３８】
簡単のため、マルチキャストツリー形成のための前述の３つの方法のそれぞれは、「物理的」「仮想的」及び「ハイブリッド」モデルのそれぞれとして参照される。
【００３９】
（実験結果）
前記３つの方法を試験するため、３個のトランジットと、平均８個のルータをそれぞれが有する２４個のスタブドメインとを有するトランジット−スタブネットワークトポロジーがシミュレーションされた。当該トポロジーにおけるノードペア間の最大遅れは約３８０ｍｓであり、これはネットワークのインフラストラクチャの地理的間隔を表わしている。合計５０００のピアがスタブノードに無作為に連結されている。スモールバーチャルクラウドをシミュレートするため、各ランにおいて２０のピアが当該プールから抽出され、２００×２００サイズの矩形状のバーチャル環境において対応するアバターの無作為の配置が形成される。このサイズ測定ユニットを用いて、ゾーン１、２及び３のそれぞれの距離が５０、１００及び１５０ユニットのそれぞれであると仮定される。さらに、ゾーン１、２及び３のそれぞれにおける許容レイテンシは、１００、２００及び４００ｍｓのそれぞれである。
【００４０】
キーとなる特性を変化させる２つのパラメータが用いられる。第１パラメータは前記のように定義されたαである。このパラメータは乗算因子であり、これによりゾーン２及び３について映像ビットレートが低減されるのはもちろんのこと、使用されている映像コーディングの種類及び要求されている映像表現の質に依存する。当該パラメータを［０．１，１．０］の範囲で変化させることにより、ビットレートに関するＱｏＳ差別化の効率がモデル化される。すなわち、α＝１．０は、通信ゾーンを横断するビットレート差別化が不可能であることを表わし、α＝０．１は、ゾーン２及び３を横断する際に映像ビットレートが１桁又は２桁だけ低下することを表わしている。
【００４１】
βと記載される第２パラメータは、ネットワークの地理的スケールを変化させる。これは、各ネットワークリンクの遅れにこの因子を乗じることにより実現される。前述のように、本来のトポロジーにおけるノードペア間の最大遅れは約３８０ｍｓである。［０．１，５．０］の範囲でβを変化させることにより、標準的な街又は州に相応するスケールのネットワークから地球ネットワークに至るまでシミュレーションが可能になる。明らかに、ラージスケールネットワークにおいてレイテンシバイオレーションの蓋然性が高くなり、かつ、遅れ制御に関するあらゆる不適当な設計の影響がより顕在化される。
【００４２】
次の結果を得るため、各トポロジーが２０個の異なるノードセットを有し、かつ、各ノードセットが２０個のアバターを包含するような、１０個の異なる物理的ネットワークトポロジーが形成される。したがって、各グラフにおける点は、２００回のシミュレーション実施の結果（例えば平均値）である。
【００４３】
（送信効率）
結果の第１集合は、ピアのアップロードキャパシティの要求及びマルチポイントツーマルチポイント映像の配布コストを低下させる際の３個のマルチキャストスキーム（「物理的」「仮想的」及び「ハイブリッド」）の効率を示している。
【００４４】
図３Ａにおいて正規化された合計アップロードキャパシティコストが縦軸に示されている。このコストは、図１Ｃに示されているユニキャストスキームに関して正規化されている。横軸はパラメータαの範囲０．１〜１．０を示している。このグラフから、ピアツーピアマルチキャストスキームが、ユニキャストの場合と比較して、合計アップロードキャパシティのピアによる利用効率をなんら改善できていないことは明らかである。ビットレートの差別化の可能性がある場合（α＜１）、「物理的」マルチキャストのパフォーマンスは、ユニキャストよりもかなり劣る。
【００４５】
この結果は次のように説明できる。ソースからの音楽ファイルのダウンロード等、単一のマルチキャストに関して、ピアツーピアのマルチキャストは、ソースへのアップロードコストを低下させ、かつ、当該ロードを参加しているすべてのピアに対して配信するのに有用である。この場合でも、合計アップロードコストは同じままであるが、ピアが当該合計のシェアを占めることによりスケーラビリティが向上する。マルチポイントツーマルチポイントコンテンツ配信シナリオに関して、各ピアはソースであるのみならず、他のマルチキャストツリーのリレーノードでもある。各マルチキャストツリーは、そのソースのアップロードキャパシティを分配するが、全体的に合計は同じままであり、複数のピアの平均アップロードコストは変化しない。われわれのモデルにはパケットサイズの細かさに関して仮定はなされていないので、事実、配布のためにコンテンツを小さいブロック（例えばビットトレント）に分割することを含むピアツーピアマルチキャストスキームについてこの結論は正しい。
【００４６】
「物理的」マルチキャスト手法は、前述のようにＱｏＳ差別化に際しての当該スキームの非効率性のため、α＜１．０のユニキャストと比較して劣る（図２Ａ参照）。
【００４７】
アップロードキャパシティ基準に関するピアツーピアマルチキャストの唯一の長所は、合計は同じであるにもかかわらず、複数のピアの間でのロード配信が、マルチキャストツリーの形成方法と、当該ツリーにおける特定ピアの中心性（centrality）に依存することである。シミュレーションにおいて、ユニキャストアップロードコストは多少均一に配分される一方、他のスキームではピアの間で顕著な相違がある。賢明な設計により、特にピアの間に不均質が存在する場合には当該設計が利点となる。例えば、いくつかのピアが、スーパーピアの役割を果たし、能力が劣る他のピアのロードを低下させてもよい。
【００４８】
図３Ｂにおけるグラフは、ネットワークインフラストラクチャにより生じる合計送信コストを示している。これは、リンクコスト（本実施形態では距離に比例する）が掛け合わせられるのに用いられるビットレートとして定義されている。「物理的」及び「ハイブリッド」手法の両方が、より少数の高コストリンクの使用により、合計送信コストを適度に低下させるという結果をもたらすことがわかる。この利益は、ビットレートに関するＱｏＳ差別化が不可能である場合により顕著になる。差別化が増大した場合、ユニキャストのパフォーマンスはマルチキャストに著しく近接することになる。
【００４９】
（遅れバイオレーション）
先に議論したように、許容通信レイテンシはバーチャル距離に依存する。ここで述べるモデルにおいて、３つのゾーンが使用され、かつ、許容最大遅れが１００、２００及び４００ｍｓのそれぞれに設定されている。しかし、本考察の結論を一般化するため、図４Ａ及び図４Ｂの横軸に示されているように、ネットワークの地理的スケールが広範囲にわたって変更される。
【００５０】
図４Ａは、許容レイテンシを超えている相互通信「コネクション」の様子を示している。通信コネクションは、相互に相手方の視覚的範囲に存在する２個のアバターのあらゆるアクティブマルチメディア交換を包含する。予想通り、ネットワークサイズ（パラメータβ）を増加させることにより、この数は増加する。レイテンシの最小化のため、最善の移送方法は、映像配信のために最短経路ルート及び単一のオーバーレイホップが採用されるユニキャストスキームである。「物理的」及び「ハイブリッド」スキームは段階的にパフォーマンスが悪く、「仮想的」スキームはパフォーマンスが最悪である。
【００５１】
レイテンシバイオレーションの程度を評価することも重要である。そのために図４Ｂには計量の１つが例示されている。この計量は、許容レベルに関して正規化された超過レイテンシの合計を表わしている。隔離に際して、この計量は物理的に直感的な尺度に変換されず、対比ツールとして役立つ。図４Ｂに示されているように、さまざまなスキームの間のギャップは、レイテンシ制御に関する相対的なパフォーマンスを示している。
【００５２】
（結論）
チャット及び電子メール等の現在のツールに加えて、バーチャルクラウドのメンバー同士の自然な通信に対する必要性は、ユーザがより相関的かつ現実的なマルチメディア経験を望むにつれてますます増大しているようである。マルチポイントツーマルチポイントのマルチメディア通信サービスに対する初期の多大な要望がある。
【００５３】
ピアツーピアマルチキャストは、ポピュラーなコンテンツ伝送技術である。しかし、マルチポイントツーマルチポイントマルチメディア通信の伝送のための当該スキームの利益は限界である。
【００５４】
大半の場合、より単純なユニキャスト方法はオーバーレイマルチキャストと同等であり、さらには優れていることも多い。マルチキャストのためのＩＰレイヤーサポートが欠如している場合、「関心範囲」制御及びＱｏＳ差別化は、サービス伝送のキャパシティ要求を低減するのに有効なツールである。
【００５５】
オーバーレイマルチキャストの１つの利益は、ピアの間の不均質性の利益を享受するような不均質な方法によりピアの間のアップロードコストを分配することができることにある。これらの場合、マルチキャストスキームは、増加したレイテンシのコスト及びツリーを成立させかつ補修するためのより複雑なコントロールシステムにおいていくつかの利益をもたらす。
【００５６】
換言すると、技術の組み合わせを用いること及び前記ハイブリッドモデルを用いることにより、接続された複数のコンピュータシステム間のより効率的なデータ伝送方法論が確立される。当該方法論は、ソーシャルネットワーク及び複数のユーザのバーチャル環境に関する発展中の市場における用途を見出す。
【００５７】
（他の変更された実施形態）
本発明の広い概念から乖離することなく、前記実施形態に対してさらなるサービスが追加されてもよい。例えば、ソフトウェアアプリケーションが、他のコンピュータシステム（図示略）における他のソフトウェアアプリケーションと相互作用するように構成されていてもよい。実施形態は、携帯電話機を含むモバイルコンピュータデバイスに適用されてもよい。このような他の実施形態は当業者の創作能力の範囲内の事項である。
【００５８】
一実施形態において、ソフトウェアアプリケーションは、一又は複数の中央サーバにおいて動作するように構成されているアプリケーションであってもよい。アプリケーションは、インターネット等の公的又は私的ネットワークを通じて、適当な遠隔端末からアクセスされてもよい。
【００５９】
ソフトウェアアプリケーションが他のコンピュータシステム及びデータベースのうち一方又は両方にインターフェイスしている場合、インターネット、占有ネットワーク（例えば、組織の異なるオフィス間の私的な接続）、８０２．１１標準ネットワーク等のワイヤレスネットワーク、又は（限定されないものの、電話回線、ＧＳＭ、ＣＤＭＡ、ＥＤＧＥ若しくは３Ｇモバイル電話通信ネットワーク、又はマイクロ波リンクを含む）電話通信ネットワークを含む適当なネットワークを通じてデータが通信されてもよい。
【００６０】
前記実施形態が、開発者による利用のためにＡＰＩ（application programming interface）を介して又はＡＰＩとして改良されてもよいこと、又は他のソフトウェアアプリケーションにおけるコードとして改良されてもよいことが理解されるはずである。一般に、ソフトウェアアプリケーションが、特定の機能を発揮する又は支援するようなルーティン、プログラム、オブジェクト、コンポーネント及びデータファイルを有しているので、ソフトウェアアプリケーションが多数のルーティン、オブジェクト及びコンポーネントに分配されるが、前記実施形態及び本発明の概念と同等の機能性を発揮することが理解されるはずである。当該変形及び改良は当業者の通常の創作能力の範囲内のことである。
【００６１】
前記実施形態に関する記載は、当業者が本発明を実施又は使用するために十分なものである。記載された特定の実施形態に関して本発明が説明されたが、当業者にとって当該実施形態にさまざまな改良を加えることは明確なことであり、ここで定義された包括的原則は、本発明の思想又は範囲から乖離することなく、他の実施形態に対して適用されうる。
【００６２】
したがって、本実施形態は、すべてに関して例示的なものであり、かつ、限定的ではないと考えられるべきである。
【技術分野】
【０００１】
本発明は、複数のコンピュータ間のデータ配布システム、方法及びソフトウェアアプリケーションに関する。本発明は、限定的にではなく、特にコンピュータネットワーク間のデータのピアツーピアマルチキャスト及びユニキャストの分野における用途に資する。
【背景技術】
【０００２】
近年のソーシャルネットワークコンピュータシステム及びマルチユーザのバーチャルコンピュータ環境の誕生により、マルチパーソンツーマルチパーソン通信の必要性が高まってきている。
【０００３】
バーチャルコミュニティの通信ツールは、非同期通信（例えばチャット、電子メール、メッセージングなど）又は電話方式のワンツーワン相互通信に制限されている。「臨場型通信（immersive communications）」の分野においていくつかの試みがなされているが、この分野ではバンド幅の制限克服のためのさらなる試みが必要とされている。
【０００４】
臨場的通信は、ユーザが実際のクラウド（crowd）に接した際の感覚と同様の聴覚的かつ視覚的場面を当該ユーザに対して与える。例えば、聴者の音響環境においてバーチャルクラウドにおける他人の音声が、各人の仮想の場所に完全に調和して空間的に配置される。同様に、観者の視野内に他の参加者の映像が適当に配置される。「臨場型」という用語は、バーチャルリアリティヘッドマウンテッドディスプレイ又はＣＡＶＥ（Cave Automatic Virtual Environment）等の臨場型ディスプレイ技術に限定されるわけではない。「臨場型」とは、聴覚的かつ視覚的場面における適当な情報が利用可能であることを広く意味する。多くのシナリオにおいて、簡易なモニター又はハンドヘルドディスプレイがあれば臨場的経験を提供するのに十分である。
【０００５】
臨場型マルチメディア通信は、基本的にマルチポイントツーマルチポイント通信システムである。各ユーザの音声及び映像又はコンテンツ等、各ユーザにより創出されたマルチメディア情報はリアルタイムで他の参加者の部分集合に届けられる必要がある。この部分集合は、バーチャルクラウドにおけるユーザの移動の結果として動的に変化し、かつ、環境におけるバリヤ、ウォール及びその他のバーチャルアーチファクトの存在に影響される。それは、バーチャル環境を通じたメディアの伝播特性にも依存する。例えば、音声はウォールを通じて伝播可能である一方、視覚的情報は伝播不可能である。
【発明の概要】
【発明が解決しようとする課題】
【０００６】
マルチポイントツーマルチポイント通信システムの可能性に関してはほとんど研究されてこなかった。
【課題を解決するための手段】
【０００７】
第１態様において、本発明は、複数のコンピュータの間でデータを伝送する方法であって、前記複数のコンピュータを複数のバーチャルゾーンに分類する過程と、アルゴリズムを用いることにより前記複数のバーチャルゾーンのそれぞれに属する各コンピュータのリンク方式を決定する過程と、を含んでいる方法を提供する。
【０００８】
一態様において、前記複数のコンピュータがツリー構造を用いてリンクされている方法が提供される。前記ツリー構造が、前記複数のコンピュータの間の仮想的距離及び物理的距離のうち一方を、前記ツリー構造を定義するための計量として用いてもよい。他の態様において、前記ツリー構造が、前記複数のコンピュータの間の仮想的距離及び物理的距離の組み合わせを、前記ツリー構造を定義するための計量として用いてもよい。
【０００９】
第２態様において、本発明は、複数のコンピュータの間でデータを伝送するシステムであって、前記複数のコンピュータを複数のバーチャルゾーンに分類する手段と、アルゴリズムを用いることにより前記複数のバーチャルゾーンのそれぞれに属する各コンピュータのリンク方式を決定する手段と、を備えているシステムが提供される。
【００１０】
一態様において、前記複数のコンピュータがツリー構造を用いてリンクされているシステムが提供される。前記ツリー構造が、前記複数のコンピュータの間の仮想的距離及び物理的距離の組み合わせを、前記ツリー構造を定義するための計量として用いてもよい。前記ツリー構造が、前記複数のコンピュータの間の仮想的距離及び物理的距離のうち一方を、前記ツリー構造を定義するための計量として用いてもよい。
【００１１】
第３態様において、本発明は、複数のコンピュータの間でデータを伝送する方法であって、前記複数のコンピュータを包含するコンピュータネットワークのトポロジーを決定する過程と、前記トポロジーを用いることにより適当なネットワーク形成アルゴリズムを選択する過程と、を含んでいる方法を提供する。
【００１２】
第４態様において、本発明は、コンピュータの読み取り記録媒体に格納され、第１態様又は第３態様の方法を前記コンピュータに実行させるコンピュータプログラムを提供する。
【００１３】
第５態様において、本発明は、第４態様のコンピュータプログラムを提供するコンピュータ読み取り可能な記録媒体を提供する。
【００１４】
明細書において「データ（data）」という用語は、コンピュータシステムにより利用されうる任意のデータの集合を包含する広い概念を意味している。データは、例えば、マルチメディアファイル（例えば、音響映像ファイル、映像ファイル、データファイルなど）、電子メール、インスタントメッセージ若しくはあらゆる潜在的な情報の「断片」等の他の情報集合である。データは必要に応じて暗号化されてもよい。
【図面の簡単な説明】
【００１５】
本発明の範囲にはここで述べる以外の実施形態も包含されるが、本発明の実施形態を実施例の添付図面を参照しながら説明する。
【図１】図１Ａ〜図１Ｃは、本発明の一実施形態にしたがった複数のコンピュータ装置の間のデータ伝送用のコンピュータネットワークの実施例を示す図である。
【図２】図２Ａ〜図２Ｂは、本発明の一実施形態にしたがったマルチキャストツリーを示す図である。
【図３】図３Ａ〜図３Ｃは、本発明の一実施形態にしたがったマルチキャストスキームの正規化コストを表わすグラフである。
【図４】図４Ａ〜図４Ｂは、本発明の一実施形態にしたがったマルチキャストネットワークにおいて生じる遅れ違反及び合計超過遅れを表わすグラフ。
【発明を実施するための形態】
【００１６】
複数のコンピュータシステムの間であらゆるタイプのデータを伝送するためのシステム又は方法、特に、インターネット等の通信ネットワークを介して遠く離れて接続されている複数のコンピュータシステムの間で（圧縮された又は非圧縮の）映像及び音声ファイル等のマルチメディアファイルを伝送するためのシステム又は方法に関連して本発明の実施形態が記述される。ただし、本発明は記載された実施形態に限定されず、任意の数かつ任意の構成のコンピュータシステムの間でのあらゆる形式の電子ファイルの伝送に適用されうることを理解されたい。
【００１７】
図１Ａ及び図１Ｂに示されているように、それぞれが一又は複数のサーバコンピュータ１０２，１０４の形態である複数のコンピュータ装置の間でデータファイルが伝送される。
【００１８】
コンピュータ１０２及び１０４は、ローカルネットワーク又は広域ネットワークの形態の通信ネットワーク１０８を通じて接続され、かつ、ＴＣＰ／ＩＰプロトコル等のパケットスイッチプロトコルを用いて通信する。
【００１９】
コンピュータ１０２及び１０４のそれぞれは、マザーボード、ＣＰＵ（central processing unit）１１０、ＲＡＭ（random access memory）１１２、ハードディスク１１４及びネットワーク用ハードウェア１１６を含む適当なコンピュータハードウェアを備えている。コンピュータ１０２及び１０４のそれぞれは、ハードウェアに加えて、オペレーティングシステム（例えば、ＵＲＬがhttp://www.redhat.com、http://www.suse.com及びhttp://www.ubuntu.comであるウェブサイト等、多数のプロバイダからインターネット経由で取得可能なLinux OSなど）を備えている。オペレーティングシステムは、ハードディスクに収められ、ハードウェアと協働してソフトウェアアプリケーションが実行されうる環境を提供する。
【００２０】
コンピュータ１０２及び１０４のそれぞれは、データファイルを受信（かつ送信）するための標準的なソフトウェア及び（ＴＣＰ／ＩＰソケット等の）ハードウェアを有する受信モジュールを備えている。
【００２１】
図１Ｂ及び図１Ｃには、本実施形態のシステムが詳細に示されている。図１Ｂには、ピア（peer）Ｐ１〜Ｐ１１のバーチャル表現（アバター）を示す符号Ａ１〜Ａ１１とともにバーチャルクラウドの一部分が示されている。図１Ｃに示されているように、Ｐ１〜Ｐ１１は、基礎となるインターネット又はイントラネットに対するピアツーピアオーバーレイネットワークを構成する。
【００２２】
ピアＰ１に対応するＡ１等、バーチャルクラウドのあらゆるメンバーを勘案し、臨場型の音響及び映像通信に限定されると仮定する。ジェスチャー、触覚及びユーザが創出したコンテンツ等の他のタイプのメディアの伝播は類似しているものの異なる要求があるため、本実施形態においては勘案されない。Ａ１の視覚的範囲及び聴覚的範囲のそれぞれは、図１Ｂに実線及び破線のそれぞれにより示されている。
【００２３】
対称性（すなわち、バーチャルクラウドの各メンバーＡ１〜Ａ１１が、ウォール等のバリヤが存在しない場合、相互に視聴可能である）を仮定すると、Ｐ１の音声及び映像は、聴覚的かつ視覚的場面に包含されるレンジに存在するすべてのピアに届けられる必要がある。これは、音声に関してはＰ２〜Ｐ７、映像に関してはＰ１〜Ｐ５及びＰ１１に相当する。さらに、Ａ５〜Ａ７はＡ１から遠く離れており、当該ピアに対してＡ１の音声は大きな遅れを伴って伝達され、かつ、空間的な正確性が低下した状態になる。同様に、バーチャル間隔が大きいため、Ａ３、Ａ５及びＡ１１は、Ａ１の映像について低い解像度及びフレームレートを許容することができる。しかし、このＱｏＳ（Quality of Service）の変化は、バーチャルクラウドにおける現在は位置に依存しており、バーチャルスペースでアバターＡ１〜Ａ１１が動くことにより時間経過とともに変化する。
【００２４】
ＩＰレイヤーにおけるネイティブマルチキャストサポートが存在しない場合、マルチポイントツーマルチポイントコンテンツの伝播のためのユニキャストモデルは図１Ｃに示されているように理解されうる。図１Ｃを乱雑にすることを回避するため、Ｐ１の映像配信のみが示されている。しかし、各ピアは、聴覚的又は視覚的範囲におけるピアの部分集合に対して音声及び映像の両方をユニキャストする必要がある。したがって、バーチャルクラウド全体に対して、平均でｍＤＮのユニキャストフローが必要とされる。ここで「ｍ」はメディアのタイプ（例えば音声及び映像）の数であり、「Ｎ」は参加者の数であり、密度「Ｄ」は書くピアノ通信範囲内に存在する参加者の平均数である。Ｐ１に着目し、かつ、ｒが映像のビットレートだと仮定すると、このピアノ映像を配信するために必要とされるアップロードキャパシティの平均はｒＤである。後述するように、映像フローの間のＱｏＳ差別化を用いることによりこの値は低減されうる。この目的で用いられる２つの可能性があるコーディング技術が、レイヤードコーディング及びマルチプルディスクリプションコーディングである。両方の場合、バーチャルワールドにおいて著しく離れているピアに対する映像フローは、図１Ｃに薄い矢印で示されている映像パケットの部分集合を含んでいるのみであろう。
【００２５】
受信側において、各ピアは、聴覚的範囲及び視覚的範囲における全員から多数のユニキャストフローを受信する。
【００２６】
平均的に、このダウンロードキャパシティは、ユニキャスト配信の場合のアップロードキャパシティと同じである。マルチキャストスキームの形式を用いることによりアップロードキャパシティの要求を低減することが考えられるが、ダウンロードキャパシティを低減させる唯一の途は前記のようにＱｏＳ差別化の採用であることに注意を要する。
【００２７】
ネイティブマルチキャストサポートがＩＰレイヤーに存在する場合、Ｐ１は、アップロードキャパシティの要求を著しく低減する一の映像フローをマルチキャストフローとして送信すれば足りる。ＩＰマルチキャストは、同一リンクを通じた重複フローを解消することにより、ネットワーク送信キャパシティの利用効率を向上させる。マルチキャストに対して最短経路ツリーが用いられることが仮定され、かつ、マルチキャストフローの複製及びルーティングに必要な付加的な処理が無視された場合、各フローが接するレイテンシ（latency）はユニキャストの場合に近いものになる。ダウンロードキャパシティは同一のままに維持され、マルチキャストがＱｏＳ差別化を提供しない場合には悪化することはない。
【００２８】
（マルチキャストのためのピアツーピアモデル）
コンテンツ配信のためのピアツーピアマルチキャストを生じさせるためには３つの手法がある。ここでは、例として、Ｐ１の映像伝播のための単一のマルチキャストツリーが考察される。しかし、マルチポイントツーマルチポイント通信セッションは、平均的にｍＮ個のオーバーレイマルチキャストツリーを必要とし、各ピアは、ソース、リレー又はリーフノードとして‘ｍＤ＋ｍ’個のマルチキャストコネクションに参加するとともに、当該ツリーの形成及び補修のオーバーヘッドに貢献する。バーチャルクラウド及び攪拌（churn）（ピアの参加及び離脱）は、マルチキャストツリーの変化に変換される。平均的に、参加者のバーチャルムーブメント又は攪拌は、再計算されかつ他のピアに通信される必要がある‘ｍＤ＋ｍ’個のマルチキャストツリーに影響を及ぼす。
【００２９】
以下の実施例を明確化するため、各参加者の視覚的範囲が３つのゾーンに分割されていると仮定する（図２Ｂ参照）。レシピエントがゾーン１に存在する場合、映像のための最高ビットレートが必要とされる。ゾーン２及び３は、映像送信のために段階的に低いビットレートを必要とする。これは、３つのディスクリプションを有するマルチプルディスクリプションコーディングスキーム、又は階層レイヤードコーディングが用いられることにより実現される。以降、明確化のため、連続するゾーンにおけるビットレートの減少をモデル化するため、単一のパラメータが用いられる。換言すると、レシピエントがゾーン１からゾーン２へ移動した場合又はゾーン２からゾーン３に移動した場合、映像ビットレートが因子α（α≦１）だけ低下する。メインプロファイルＨ．２６４（ＩＴＵ（International Telecommunication Union）により開発された映像コーディングスキーム）を用いて暗号化された多数の「トーキングヘッド」映像について実験結果が得られた。映像の質の変化は、α〜０．６５がビットレート低下率についてよい近似であることが確認された。
【００３０】
（マルチキャストツリー形成スキーム）
図２Ａは、ピア同士の物理的間隔がコスト計量として用いられる最短経路マルチキャストツリーが生成される場合を示している。マルチキャスト用のピアツーピアアルゴリズムとして最も一般的なものが適用される。ピアは、通信遅れの直接検出、又は周知のランドマークを基準とする測定等、物理的近似性を近似する多数のアルゴリズムを利用することができる。最良の結果のため、このような情報はすべてのピアに対して有効なものとされ、かつ、矛盾がないように維持される。
【００３１】
ＱｏＳ差別化を考慮に入れるための付加的なアルゴリズムがないと、送信キャパシティの一部が無駄になる。例えば、Ｐ５がＰ１に対してゾーン３に存在し、ビットレートα２ｒの映像を要求した場合、より質の高いコンテンツを要求する他のピアに至る唯一の経路であるため、当該映像はフルレートでダウンロードされる必要がある。
【００３２】
一方、図２Ｂは、バーチャルシーンにおける複数のピアの配置に基づき、アバター間のバーチャル距離が第１の「コスト」計量として用いてマルチキャストツリーが構築されている場合を示している。このスキームの利点は、マルチメディアコンテンツがツリーの下方に移動した場合、多くのホップが横断され、かつ、遅れが大きくなる点である。しかし、バーチャル距離も増加し、これは、知覚インパクトが弱い、より長い遅れをピアが許容することができることを意味する。
【００３３】
例えば、Ａ１に最も近いアバターＡ２及びＡ４は、Ａ５への経路が３つのオーバーレイホップを有する一方（経路Ｐ１−Ｐ２−Ｐ３−Ｐ５）、最小の遅れを伴って音声及び映像を受け取る（直接的なオーバーレイ経路Ｐ１−Ｐ２及びＰ１−Ｐ４）。
【００３４】
直感的に、視覚的範囲における３つのゾーンが示され、かつ、αが一のゾーンから他のゾーンへの映像の質低下に関連するビットレート低減因子を表わし、Ａ１及びＡ５のバーチャル間隔のためにこの遅れのインパクトは弱くなる。映像パケットはツリーを下方に移動し、リレーされる映像レイヤー又はディスクリプションの数が減らされること等により、続くホップにおいてリレーされる情報量が減少する。このため、遅れ及びビットレートに関するＱｏＳ差別化は、オーバーヘッドがほとんどない又は皆無の当該手法の自然な結果である。
【００３５】
当該手法の他の利点は、ツリー構造に関するトポロジー情報の変換が不要である点である。これは、全員に対する一貫したバーチャル環境を表わす状態に関する情報の変換を通じて、バーチャルトポロジーの詳細が、各ピアにとってすでに有効なものであるためである。これにより、マルチキャストツリーの構築のためのアルゴリズムの開発、及びピアの再組織化を伴わないバーチャルムーブメント又は攪拌の結果としてのリペアが促される。
【００３６】
ルート最適化の基礎としてバーチャル間隔を用いることの鍵となる短所は、バーチャル環境に近いアバターが、物理的に遠く離れており、送信キャパシティの利用が不十分になるということである。前記例において、Ａ１の音声及び映像が、バーチャル近接性に基づいてＡ２に送信され、さらにＡ３に送信される。Ｐ１及びＰ２がオーストラリアにいる一方、Ｐ２が英国にいると仮定する。Ａ１のコンテンツがＡ２に届けられるためには英国に行く必要があるという事実は、当該ピアが相互通信する際の助けとはならない。しかし、Ａ１のデータがＡ３に届けられるために英国から戻ってこなくてはならない点が関心事項である。
【００３７】
図２Ｃに示されている第３の手法は、前記２つのスキームの欠点を補い合うハイブリッドスキームである。この場合、物理的距離は最短経路ツリーを生成するために用いられるが、アルゴリズムはバーチャルゾーンに応じた３つの連続する段階に対して適用される。前記例において、第１段階ではＰ１とゾーン１におけるその他のすべてのピアとの最短経路ツリーが生成される。このツリーは、第２段階ではゾーン２におけるピアを包含するように拡張される。最終段階において、ゾーン３におけるピアがツリーに参加する。この目的は、キャパシティ利用効率を過剰に犠牲にすることなく、ＱｏＳ差別化スキームを改良することにある。
【００３８】
簡単のため、マルチキャストツリー形成のための前述の３つの方法のそれぞれは、「物理的」「仮想的」及び「ハイブリッド」モデルのそれぞれとして参照される。
【００３９】
（実験結果）
前記３つの方法を試験するため、３個のトランジットと、平均８個のルータをそれぞれが有する２４個のスタブドメインとを有するトランジット−スタブネットワークトポロジーがシミュレーションされた。当該トポロジーにおけるノードペア間の最大遅れは約３８０ｍｓであり、これはネットワークのインフラストラクチャの地理的間隔を表わしている。合計５０００のピアがスタブノードに無作為に連結されている。スモールバーチャルクラウドをシミュレートするため、各ランにおいて２０のピアが当該プールから抽出され、２００×２００サイズの矩形状のバーチャル環境において対応するアバターの無作為の配置が形成される。このサイズ測定ユニットを用いて、ゾーン１、２及び３のそれぞれの距離が５０、１００及び１５０ユニットのそれぞれであると仮定される。さらに、ゾーン１、２及び３のそれぞれにおける許容レイテンシは、１００、２００及び４００ｍｓのそれぞれである。
【００４０】
キーとなる特性を変化させる２つのパラメータが用いられる。第１パラメータは前記のように定義されたαである。このパラメータは乗算因子であり、これによりゾーン２及び３について映像ビットレートが低減されるのはもちろんのこと、使用されている映像コーディングの種類及び要求されている映像表現の質に依存する。当該パラメータを［０．１，１．０］の範囲で変化させることにより、ビットレートに関するＱｏＳ差別化の効率がモデル化される。すなわち、α＝１．０は、通信ゾーンを横断するビットレート差別化が不可能であることを表わし、α＝０．１は、ゾーン２及び３を横断する際に映像ビットレートが１桁又は２桁だけ低下することを表わしている。
【００４１】
βと記載される第２パラメータは、ネットワークの地理的スケールを変化させる。これは、各ネットワークリンクの遅れにこの因子を乗じることにより実現される。前述のように、本来のトポロジーにおけるノードペア間の最大遅れは約３８０ｍｓである。［０．１，５．０］の範囲でβを変化させることにより、標準的な街又は州に相応するスケールのネットワークから地球ネットワークに至るまでシミュレーションが可能になる。明らかに、ラージスケールネットワークにおいてレイテンシバイオレーションの蓋然性が高くなり、かつ、遅れ制御に関するあらゆる不適当な設計の影響がより顕在化される。
【００４２】
次の結果を得るため、各トポロジーが２０個の異なるノードセットを有し、かつ、各ノードセットが２０個のアバターを包含するような、１０個の異なる物理的ネットワークトポロジーが形成される。したがって、各グラフにおける点は、２００回のシミュレーション実施の結果（例えば平均値）である。
【００４３】
（送信効率）
結果の第１集合は、ピアのアップロードキャパシティの要求及びマルチポイントツーマルチポイント映像の配布コストを低下させる際の３個のマルチキャストスキーム（「物理的」「仮想的」及び「ハイブリッド」）の効率を示している。
【００４４】
図３Ａにおいて正規化された合計アップロードキャパシティコストが縦軸に示されている。このコストは、図１Ｃに示されているユニキャストスキームに関して正規化されている。横軸はパラメータαの範囲０．１〜１．０を示している。このグラフから、ピアツーピアマルチキャストスキームが、ユニキャストの場合と比較して、合計アップロードキャパシティのピアによる利用効率をなんら改善できていないことは明らかである。ビットレートの差別化の可能性がある場合（α＜１）、「物理的」マルチキャストのパフォーマンスは、ユニキャストよりもかなり劣る。
【００４５】
この結果は次のように説明できる。ソースからの音楽ファイルのダウンロード等、単一のマルチキャストに関して、ピアツーピアのマルチキャストは、ソースへのアップロードコストを低下させ、かつ、当該ロードを参加しているすべてのピアに対して配信するのに有用である。この場合でも、合計アップロードコストは同じままであるが、ピアが当該合計のシェアを占めることによりスケーラビリティが向上する。マルチポイントツーマルチポイントコンテンツ配信シナリオに関して、各ピアはソースであるのみならず、他のマルチキャストツリーのリレーノードでもある。各マルチキャストツリーは、そのソースのアップロードキャパシティを分配するが、全体的に合計は同じままであり、複数のピアの平均アップロードコストは変化しない。われわれのモデルにはパケットサイズの細かさに関して仮定はなされていないので、事実、配布のためにコンテンツを小さいブロック（例えばビットトレント）に分割することを含むピアツーピアマルチキャストスキームについてこの結論は正しい。
【００４６】
「物理的」マルチキャスト手法は、前述のようにＱｏＳ差別化に際しての当該スキームの非効率性のため、α＜１．０のユニキャストと比較して劣る（図２Ａ参照）。
【００４７】
アップロードキャパシティ基準に関するピアツーピアマルチキャストの唯一の長所は、合計は同じであるにもかかわらず、複数のピアの間でのロード配信が、マルチキャストツリーの形成方法と、当該ツリーにおける特定ピアの中心性（centrality）に依存することである。シミュレーションにおいて、ユニキャストアップロードコストは多少均一に配分される一方、他のスキームではピアの間で顕著な相違がある。賢明な設計により、特にピアの間に不均質が存在する場合には当該設計が利点となる。例えば、いくつかのピアが、スーパーピアの役割を果たし、能力が劣る他のピアのロードを低下させてもよい。
【００４８】
図３Ｂにおけるグラフは、ネットワークインフラストラクチャにより生じる合計送信コストを示している。これは、リンクコスト（本実施形態では距離に比例する）が掛け合わせられるのに用いられるビットレートとして定義されている。「物理的」及び「ハイブリッド」手法の両方が、より少数の高コストリンクの使用により、合計送信コストを適度に低下させるという結果をもたらすことがわかる。この利益は、ビットレートに関するＱｏＳ差別化が不可能である場合により顕著になる。差別化が増大した場合、ユニキャストのパフォーマンスはマルチキャストに著しく近接することになる。
【００４９】
（遅れバイオレーション）
先に議論したように、許容通信レイテンシはバーチャル距離に依存する。ここで述べるモデルにおいて、３つのゾーンが使用され、かつ、許容最大遅れが１００、２００及び４００ｍｓのそれぞれに設定されている。しかし、本考察の結論を一般化するため、図４Ａ及び図４Ｂの横軸に示されているように、ネットワークの地理的スケールが広範囲にわたって変更される。
【００５０】
図４Ａは、許容レイテンシを超えている相互通信「コネクション」の様子を示している。通信コネクションは、相互に相手方の視覚的範囲に存在する２個のアバターのあらゆるアクティブマルチメディア交換を包含する。予想通り、ネットワークサイズ（パラメータβ）を増加させることにより、この数は増加する。レイテンシの最小化のため、最善の移送方法は、映像配信のために最短経路ルート及び単一のオーバーレイホップが採用されるユニキャストスキームである。「物理的」及び「ハイブリッド」スキームは段階的にパフォーマンスが悪く、「仮想的」スキームはパフォーマンスが最悪である。
【００５１】
レイテンシバイオレーションの程度を評価することも重要である。そのために図４Ｂには計量の１つが例示されている。この計量は、許容レベルに関して正規化された超過レイテンシの合計を表わしている。隔離に際して、この計量は物理的に直感的な尺度に変換されず、対比ツールとして役立つ。図４Ｂに示されているように、さまざまなスキームの間のギャップは、レイテンシ制御に関する相対的なパフォーマンスを示している。
【００５２】
（結論）
チャット及び電子メール等の現在のツールに加えて、バーチャルクラウドのメンバー同士の自然な通信に対する必要性は、ユーザがより相関的かつ現実的なマルチメディア経験を望むにつれてますます増大しているようである。マルチポイントツーマルチポイントのマルチメディア通信サービスに対する初期の多大な要望がある。
【００５３】
ピアツーピアマルチキャストは、ポピュラーなコンテンツ伝送技術である。しかし、マルチポイントツーマルチポイントマルチメディア通信の伝送のための当該スキームの利益は限界である。
【００５４】
大半の場合、より単純なユニキャスト方法はオーバーレイマルチキャストと同等であり、さらには優れていることも多い。マルチキャストのためのＩＰレイヤーサポートが欠如している場合、「関心範囲」制御及びＱｏＳ差別化は、サービス伝送のキャパシティ要求を低減するのに有効なツールである。
【００５５】
オーバーレイマルチキャストの１つの利益は、ピアの間の不均質性の利益を享受するような不均質な方法によりピアの間のアップロードコストを分配することができることにある。これらの場合、マルチキャストスキームは、増加したレイテンシのコスト及びツリーを成立させかつ補修するためのより複雑なコントロールシステムにおいていくつかの利益をもたらす。
【００５６】
換言すると、技術の組み合わせを用いること及び前記ハイブリッドモデルを用いることにより、接続された複数のコンピュータシステム間のより効率的なデータ伝送方法論が確立される。当該方法論は、ソーシャルネットワーク及び複数のユーザのバーチャル環境に関する発展中の市場における用途を見出す。
【００５７】
（他の変更された実施形態）
本発明の広い概念から乖離することなく、前記実施形態に対してさらなるサービスが追加されてもよい。例えば、ソフトウェアアプリケーションが、他のコンピュータシステム（図示略）における他のソフトウェアアプリケーションと相互作用するように構成されていてもよい。実施形態は、携帯電話機を含むモバイルコンピュータデバイスに適用されてもよい。このような他の実施形態は当業者の創作能力の範囲内の事項である。
【００５８】
一実施形態において、ソフトウェアアプリケーションは、一又は複数の中央サーバにおいて動作するように構成されているアプリケーションであってもよい。アプリケーションは、インターネット等の公的又は私的ネットワークを通じて、適当な遠隔端末からアクセスされてもよい。
【００５９】
ソフトウェアアプリケーションが他のコンピュータシステム及びデータベースのうち一方又は両方にインターフェイスしている場合、インターネット、占有ネットワーク（例えば、組織の異なるオフィス間の私的な接続）、８０２．１１標準ネットワーク等のワイヤレスネットワーク、又は（限定されないものの、電話回線、ＧＳＭ、ＣＤＭＡ、ＥＤＧＥ若しくは３Ｇモバイル電話通信ネットワーク、又はマイクロ波リンクを含む）電話通信ネットワークを含む適当なネットワークを通じてデータが通信されてもよい。
【００６０】
前記実施形態が、開発者による利用のためにＡＰＩ（application programming interface）を介して又はＡＰＩとして改良されてもよいこと、又は他のソフトウェアアプリケーションにおけるコードとして改良されてもよいことが理解されるはずである。一般に、ソフトウェアアプリケーションが、特定の機能を発揮する又は支援するようなルーティン、プログラム、オブジェクト、コンポーネント及びデータファイルを有しているので、ソフトウェアアプリケーションが多数のルーティン、オブジェクト及びコンポーネントに分配されるが、前記実施形態及び本発明の概念と同等の機能性を発揮することが理解されるはずである。当該変形及び改良は当業者の通常の創作能力の範囲内のことである。
【００６１】
前記実施形態に関する記載は、当業者が本発明を実施又は使用するために十分なものである。記載された特定の実施形態に関して本発明が説明されたが、当業者にとって当該実施形態にさまざまな改良を加えることは明確なことであり、ここで定義された包括的原則は、本発明の思想又は範囲から乖離することなく、他の実施形態に対して適用されうる。
【００６２】
したがって、本実施形態は、すべてに関して例示的なものであり、かつ、限定的ではないと考えられるべきである。
【特許請求の範囲】
【請求項１】
複数のコンピュータの間でデータを伝送する方法であって、
前記複数のコンピュータを複数のバーチャルゾーンに分類する過程と、
アルゴリズムを用いることにより前記複数のバーチャルゾーンのそれぞれに属する各コンピュータのリンク方式を決定する過程と、を含んでいることを特徴とする方法。
【請求項２】
請求項１記載の方法において、
前記複数のコンピュータがツリー構造を用いてリンクされていることを特徴とする方法。
【請求項３】
請求項２記載の方法において、
前記ツリー構造が、前記複数のコンピュータの間の仮想的距離及び物理的距離の組み合わせを、前記ツリー構造を定義するための計量として用いることを特徴とする方法。
【請求項４】
請求項２記載の方法において、
前記ツリー構造が、前記複数のコンピュータの間の仮想的距離及び物理的距離のうち一方を、前記ツリー構造を定義するための計量として用いることを特徴とする方法。
【請求項５】
複数のコンピュータの間でデータを伝送するシステムであって、
前記複数のコンピュータを複数のバーチャルゾーンに分類する手段と、
アルゴリズムを用いることにより前記複数のバーチャルゾーンのそれぞれに属する各コンピュータのリンク方式を決定する手段と、を備えていることを特徴とするシステム。
【請求項６】
請求項５記載のシステムにおいて、
前記複数のコンピュータがツリー構造を用いてリンクされていることを特徴とするシステム。
【請求項７】
請求項６記載のシステムにおいて、
前記ツリー構造が、前記複数のコンピュータの間の仮想的距離及び物理的距離の組み合わせを、前記ツリー構造を定義するための計量として用いることを特徴とするシステム。
【請求項８】
請求項７記載のシステムにおいて、
前記ツリー構造が、前記複数のコンピュータの間の仮想的距離及び物理的距離のうち一方を、前記ツリー構造を定義するための計量として用いることを特徴とするシステム。
【請求項９】
複数のコンピュータの間でデータを伝送する方法であって、
前記複数のコンピュータを包含するコンピュータネットワークのトポロジーを決定する過程と、
前記トポロジーを用いることにより適当なネットワーク形成アルゴリズムを選択する過程と、を含んでいることを特徴とする方法。
【請求項１０】
請求項９記載の方法において、
前記ネットワーク形成アルゴリズムが、ユニキャストネットワーク形成アルゴリズム及びマルチキャストネットワーク形成アルゴリズムのうち一方であることを特徴とする方法。
【請求項１１】
請求項１０記載の方法において、
前記ネットワーク形成アルゴリズムが、マルチキャストアルゴリズムであり、前記マルチキャストアルゴリズムが、物理的アルゴリズム、仮想アルゴリズム及びハイブリッドアルゴリズムのうち１つであることを特徴とする方法。
【請求項１２】
複数のコンピュータの間でデータを伝送するシステムであって、
前記複数のコンピュータを包含するコンピュータネットワークのトポロジーを決定する手段と、
前記トポロジーを用いることにより適当なネットワーク形成アルゴリズムを選択する手段と、を備えていることを特徴とするシステム。
【請求項１３】
請求項１２記載のシステムにおいて、
前記ネットワーク形成アルゴリズムが、ユニキャストネットワーク形成アルゴリズム及びマルチキャストネットワーク形成アルゴリズムのうち一方であることを特徴とするシステム。
【請求項１４】
請求項１３記載のシステムにおいて、
前記ネットワーク形成アルゴリズムが、マルチキャストアルゴリズムであり、前記マルチキャストアルゴリズムが、物理的アルゴリズム、仮想アルゴリズム及びハイブリッドアルゴリズムのうち１つであることを特徴とするシステム。
【請求項１５】
コンピュータの読み取り記録媒体に格納され、請求項１〜４及び請求項９〜１１のうちいずれか１つの方法を前記コンピュータに実行させることを特徴とするコンピュータプログラム。
【請求項１６】
請求項１２記載のコンピュータプログラムを提供することを特徴とするコンピュータ読み取り可能な記録媒体。
【請求項１】
複数のコンピュータの間でデータを伝送する方法であって、
前記複数のコンピュータを複数のバーチャルゾーンに分類する過程と、
アルゴリズムを用いることにより前記複数のバーチャルゾーンのそれぞれに属する各コンピュータのリンク方式を決定する過程と、を含んでいることを特徴とする方法。
【請求項２】
請求項１記載の方法において、
前記複数のコンピュータがツリー構造を用いてリンクされていることを特徴とする方法。
【請求項３】
請求項２記載の方法において、
前記ツリー構造が、前記複数のコンピュータの間の仮想的距離及び物理的距離の組み合わせを、前記ツリー構造を定義するための計量として用いることを特徴とする方法。
【請求項４】
請求項２記載の方法において、
前記ツリー構造が、前記複数のコンピュータの間の仮想的距離及び物理的距離のうち一方を、前記ツリー構造を定義するための計量として用いることを特徴とする方法。
【請求項５】
複数のコンピュータの間でデータを伝送するシステムであって、
前記複数のコンピュータを複数のバーチャルゾーンに分類する手段と、
アルゴリズムを用いることにより前記複数のバーチャルゾーンのそれぞれに属する各コンピュータのリンク方式を決定する手段と、を備えていることを特徴とするシステム。
【請求項６】
請求項５記載のシステムにおいて、
前記複数のコンピュータがツリー構造を用いてリンクされていることを特徴とするシステム。
【請求項７】
請求項６記載のシステムにおいて、
前記ツリー構造が、前記複数のコンピュータの間の仮想的距離及び物理的距離の組み合わせを、前記ツリー構造を定義するための計量として用いることを特徴とするシステム。
【請求項８】
請求項７記載のシステムにおいて、
前記ツリー構造が、前記複数のコンピュータの間の仮想的距離及び物理的距離のうち一方を、前記ツリー構造を定義するための計量として用いることを特徴とするシステム。
【請求項９】
複数のコンピュータの間でデータを伝送する方法であって、
前記複数のコンピュータを包含するコンピュータネットワークのトポロジーを決定する過程と、
前記トポロジーを用いることにより適当なネットワーク形成アルゴリズムを選択する過程と、を含んでいることを特徴とする方法。
【請求項１０】
請求項９記載の方法において、
前記ネットワーク形成アルゴリズムが、ユニキャストネットワーク形成アルゴリズム及びマルチキャストネットワーク形成アルゴリズムのうち一方であることを特徴とする方法。
【請求項１１】
請求項１０記載の方法において、
前記ネットワーク形成アルゴリズムが、マルチキャストアルゴリズムであり、前記マルチキャストアルゴリズムが、物理的アルゴリズム、仮想アルゴリズム及びハイブリッドアルゴリズムのうち１つであることを特徴とする方法。
【請求項１２】
複数のコンピュータの間でデータを伝送するシステムであって、
前記複数のコンピュータを包含するコンピュータネットワークのトポロジーを決定する手段と、
前記トポロジーを用いることにより適当なネットワーク形成アルゴリズムを選択する手段と、を備えていることを特徴とするシステム。
【請求項１３】
請求項１２記載のシステムにおいて、
前記ネットワーク形成アルゴリズムが、ユニキャストネットワーク形成アルゴリズム及びマルチキャストネットワーク形成アルゴリズムのうち一方であることを特徴とするシステム。
【請求項１４】
請求項１３記載のシステムにおいて、
前記ネットワーク形成アルゴリズムが、マルチキャストアルゴリズムであり、前記マルチキャストアルゴリズムが、物理的アルゴリズム、仮想アルゴリズム及びハイブリッドアルゴリズムのうち１つであることを特徴とするシステム。
【請求項１５】
コンピュータの読み取り記録媒体に格納され、請求項１〜４及び請求項９〜１１のうちいずれか１つの方法を前記コンピュータに実行させることを特徴とするコンピュータプログラム。
【請求項１６】
請求項１２記載のコンピュータプログラムを提供することを特徴とするコンピュータ読み取り可能な記録媒体。
【図１】
【図２】
【図３】
【図４】
【図５】
【図２】
【図３】
【図４】
【図５】
【公表番号】特表２０１３−５２０１１２（Ｐ２０１３−５２０１１２Ａ）
【公表日】平成２５年５月３０日（２０１３．５．３０）
【国際特許分類】
【出願番号】特願２０１２−５５３１５２（Ｐ２０１２−５５３１５２）
【出願日】平成２３年２月１８日（２０１１．２．１８）
【国際出願番号】ＰＣＴ／ＡＵ２０１１／０００１７２
【国際公開番号】ＷＯ２０１１／１００７９９
【国際公開日】平成２３年８月２５日（２０１１．８．２５）
【公序良俗違反の表示】
（特許庁注：以下のものは登録商標）
１．Ｌｉｎｕｘ
２．ＧＳＭ
【出願人】（５１２２１４９８２）スマート サービシィズ シーアールシー プロプライエタリー リミテッド (1)
【氏名又は名称原語表記】ＳＭＡＲＴ ＳＥＲＶＩＣＥＳ ＣＲＣ ＰＴＹ ＬＩＭＩＴＥＤ
【Ｆターム（参考）】
【公表日】平成２５年５月３０日（２０１３．５．３０）
【国際特許分類】
【出願日】平成２３年２月１８日（２０１１．２．１８）
【国際出願番号】ＰＣＴ／ＡＵ２０１１／０００１７２
【国際公開番号】ＷＯ２０１１／１００７９９
【国際公開日】平成２３年８月２５日（２０１１．８．２５）
【公序良俗違反の表示】
（特許庁注：以下のものは登録商標）
１．Ｌｉｎｕｘ
２．ＧＳＭ
【出願人】（５１２２１４９８２）スマート サービシィズ シーアールシー プロプライエタリー リミテッド (1)
【氏名又は名称原語表記】ＳＭＡＲＴ ＳＥＲＶＩＣＥＳ ＣＲＣ ＰＴＹ ＬＩＭＩＴＥＤ
【Ｆターム（参考）】
[ Back to top ]