(57)【特許請求の範囲】
【請求項１】
複数の装置から、信号を求める複数の要求を受信するステップと、
前記複数の装置を、複数の装置サブセットに編成するステップであって、前記複数の装置サブセットは、下位階層レベルにおける第１のピアの複数のクラスタおよび上位階層レベルにおける第２のピアの複数のクラスタとして配置され、前記第１のピアの複数のクラスタの各クラスタはメッシュ・トポロジを示す、ステップと、
前記信号を、装置サブセットの数に等しい数のいくつかの部分に分割するステップと、
前記第１のピアの複数のクラスタの各クラスタ内で、前記装置のうちでアップロード容量が最大の単一の装置を、前記第１のピアの複数のクラスタの前記各クラスタのクラスタ・ヘッドとして指定するステップであって、複数の前記クラスタ・ヘッドは前記上位階層レベルにおける前記第２のピアの複数のクラスタを形成し、前記第２のピアの複数のクラスタはサーバから前記信号を受信する、ステップと、
前記信号の一部分を、前記クラスタ・ヘッドのうちの各クラスタ・ヘッドに提供するステップと、
各クラスタ・ヘッドが、それぞれが受信した信号の一部分をその他のクラスタ・ヘッドのそれぞれに提供して、各クラスタ・ヘッドが、前記その他の各クラスタ・ヘッドから信号の各部分を受信することによって、各クラスタ・ヘッドが前記信号を表す再結合信号を生成できるようにするステップと、
装置サブセット内の各クラスタ・ヘッドが、前記信号の前記再結合信号表現をいくつかの部分に分割し、それらの部分の１つを装置サブセット内のその他の各装置に提供することができるようにするステップと、
装置サブセット内のその他の各装置が、前記信号の再結合表現のそれぞれが受信した部分を、装置サブセット内の前記その他の各装置に提供して、装置サブセット内のその他の各装置が前記信号の再結合表現の各部分を装置サブセット内のその他の各装置から受信することによって、装置サブセット内のその他の各装置が前記信号を表す再結合信号を表すデータセットを生成できるようにするステップと、
を含む方法。
【請求項２】
前記第１のピアの複数のクラスタのうちの少なくとも１つのクラスタ内の前記複数の装置は、完全に接続されている、請求項１に記載の方法。
【請求項３】
前記第１のピアの複数のクラスタのうちの各クラスタは、同様の平均アップロード容量を示す、請求項１に記載の方法。
【請求項４】
前記クラスタ・ヘッドのうちの少なくとも１つに、該クラスタ・ヘッドにより表される前記ピアのクラスタの平均アップロード容量より大きいアップロード容量を割り当てるステップをさらに含む、請求項１に記載の方法。
【請求項５】
前記複数の装置にさらなる装置を追加するよう求める要求を受信するステップと、
前記さらなる装置のアップロード容量に応じて、前記さらなる装置を分類するステップと、
前記第１のピアの複数のクラスタのうちのクラスタの平均アップロード容量に応じて、前記さらなる装置を、前記第１のピアの複数のクラスタのうちの前記クラスタに割り当てるステップと、
をさらに含む、請求項１に記載の方法。
【請求項６】
離脱する装置を除去するよう求める要求を、前記複数の装置から受信するステップと、
前記離脱する装置が前記クラスタ・ヘッドのうちの１つであるか判断するステップと、
前記第１のピアのクラスタのうちの前記離脱する装置が属するクラスタから前記装置を除去するステップと、
前記離脱する装置がクラスタ・ヘッドであることに応じて、前記離脱する装置が属する前記第１のピアのクラスタのうちの前記クラスタ内で、別の装置を、新たなクラスタ・ヘッドとして指定するステップと、
をさらに含む、請求項１に記載の方法。
【請求項７】
複数の装置から、信号を求める複数の要求を受信する第１のインタフェース手段と、
前記複数の装置を複数の装置サブセットに編成することを可能にし、前記複数の装置サブセットは、下位階層レベルにおける第１のピアの複数のクラスタおよび上位階層レベルにおける第２のピアの複数のクラスタとして配置され、前記第１のピアの複数のクラスタの各クラスタはメッシュ・トポロジを示し、
前記信号を、装置サブセットの数に等しい数のいくつかの部分に分割することを可能にし、
前記第１のピアの複数のクラスタの各クラスタ内で、前記装置のうちでアップロード容量が最大の単一の装置を、前記第１のピアの複数のクラスタの前記各クラスタのクラスタ・ヘッドとして指定し、複数の前記クラスタ・ヘッドは前記上位階層レベルにおける前記第２のピアの複数のクラスタを形成することを可能にし、前記第２のピアの複数のクラスタはサーバから前記信号を受信するプロセッサ手段と、
前記信号の一部分を、前記クラスタ・ヘッドのうちの各クラスタ・ヘッドに送信する第２のインタフェース手段と、
を備え、
前記プロセッサ手段は、さらに、
各クラスタ・ヘッドが、それぞれが受信した信号の一部分をその他のクラスタ・ヘッドのそれぞれに提供して、各クラスタ・ヘッドが、前記その他の各クラスタ・ヘッドから信号の各部分を受信することによって、各クラスタ・ヘッドが前記信号を表す再結合信号を生成できるようにし、
装置サブセット内の各クラスタ・ヘッドが、前記信号の前記再結合信号表現をいくつかの部分に分割し、それらの部分の１つを装置サブセット内のその他の各装置に提供することができるようにし、
装置サブセット内のその他の各装置が、前記信号の再結合表現のそれぞれが受信した部分を、装置サブセット内の前記その他の各装置に提供して、装置サブセット内のその他の各装置が前記信号の再結合表現の各部分を装置サブセット内のその他の各装置から受信することによって、装置サブセット内のその他の各装置が前記信号を表す再結合信号を表すデータセットを生成できるように動作可能である装置。
【請求項８】
前記第１のピアの複数のクラスタのうちの少なくとも１つのクラスタ内の前記複数の装置は、完全に接続されている、請求項７に記載の装置。
【請求項９】
前記第１のピアの複数のクラスタのうちの各クラスタは、同様の平均アップロード容量を示す、請求項７に記載の装置。
【請求項１０】
前記プロセッサ手段は、前記クラスタ・ヘッドのうちの少なくとも１つに、該クラスタ・ヘッドのうちの１つにより表される前記ピアのクラスタの平均アップロード容量より大きいアップロード容量を割り当てることができるようにさらに動作可能である、請求項７に記載の装置。
【請求項１１】
前記プロセッサ手段は、さらに、前記複数の装置にさらなる装置を追加するよう求める要求を受信し、
前記さらなる装置のアップロード容量に応じて、前記さらなる装置を分類し、
前記第１のピアの複数のクラスタのうちのクラスタの平均アップロード容量に応じて、前記さらなる装置を、前記第１のピアの複数のクラスタのうちの前記クラスタに割り当てることを可能にする、請求項７に記載の装置。
【請求項１２】
前記プロセッサ手段は、さらに、離脱する装置を除去するよう求める要求を、前記複数の装置から受信し、
前記離脱する装置が前記クラスタ・ヘッドのうちの１つであるか判断し、
前記第１のピアのクラスタのうちの前記離脱する装置が属するクラスタから前記装置を除去し、
前記離脱する装置がクラスタ・ヘッドであることに応じて、前記離脱する装置が属する前記第１のピアのクラスタのうちの前記クラスタ内で、別の装置を、新たなクラスタ・ヘッドとして指定することを可能にする、請求項７に記載の装置。
【発明の詳細な説明】
【技術分野】
【０００１】
（優先権主張）
本願は、２００７年３月２０日出願の、「ＨＩＥＲＡＲＣＨＩＣＡＬＬＹ  ＣＬＵＳＴＥＲＥＤ  Ｐ２Ｐ  ＳＴＲＥＡＭＩＮＧ  ＳＹＳＴＥＭ」と題する米国仮特許出願第６０／９１９０３５号の利益を請求するものである。
【０００２】
本発明は、ディジタル電子消費者装置および／またはコンピュータなどの技術的装置でネットワークを生成する方法に関する。
【背景技術】
【０００３】
コンピュータ技術では、データの交換を行いハードウェア資源を共有する装置を接続して、ネットワークを構築することは周知である。個々の装置は、一般にノードと呼ばれる。現在のところ、ノードはコンピュータであることが多いが、セット・トップ・ボックスや携帯電話、移動電子装置など、その他の技術的装置であってもよい。ノード間の接続は、主に電気的接続、光学的接続、または無線接続である。ネットワークは、クライアント・サーバ・アーキテクチャ式、またはピア・ツー・ピア（Ｐ２Ｐ）アーキテクチャ式に分類することができる。Ｐ２Ｐ方式のネットワークでは、ノードはピアとも呼ばれる。クライアント・サーバ・アーキテクチャでは、各ノードはクライアントまたはサーバとして定義されるが、Ｐ２Ｐネットワークでは、そのような区別は存在しない。その代わりに、ピアは、サーバおよびクライアント双方の機能性を有する。Ｐ２Ｐ技術では、それぞれのノードが、ネットワーク内のそれ以外の任意のノードに対してサービスまたは資源を提供することもできるし、あるいはネットワーク内のそれ以外の任意のノードから提供されたサービスまたは資源を利用することもできる。
【０００４】
Ｐ２Ｐネットワークは、通常は、いかなる特殊な応用分野または基礎ネットワーク・トポロジにも制限されないが、特定のプロトコルの特定の組合せに依拠した１組のノードまたはピアとして理解することができる。ピアがその他のピアと直接通信するので、中央ネットワーク機構が不要であることは、Ｐ２Ｐの特徴である。ほとんどのＰ２Ｐネットワークは、いつでもピアをネットワークに接続し、ネットワークから切断することができるようになっている。
【０００５】
上述のＰ２Ｐプロトコルは、例えば接続されているその他のピアを発見する、自分のサービスまたは資源をその他のピアに提供する（広告する）、その他のピアノ広告メッセージを理解する、または特定の接続を確立するための接続機能をその他のピアに割り当てるなど、基本的なネットワーク機構のために必要である。また、１群のピアが協働してピア・グループを形成することができるようにするプロトコルもある。このようなピア・グループは、通常は、当該ピア・グループ内で共通のサービス・セットを提供するために使用される。ただし、ピア・グループの目的は、一般に定義されていない。あるピア・グループに属するピアは、通常は、同じグループに属するその他の全ての接続されたピアに対するアクセス権を有し、またそれらのピアからアクセスされることもできる。さらに、各ピアは、それ以外のピア・グループのメンバであってもよい。ピア・グループにピアを追加する、またはピア・グループからピアを除去するために、ユーザは、常に特定の管理アクティビティを実行している必要がある。
【０００６】
Ｓｔｏｃｈａｓｔｉｃ  Ｆｌｕｉｄ  Ｔｈｅｏｒｙ  ｆｏｒ  Ｐ２Ｐ  Ｓｔｒｅａｍｉｎｇ  Ｓｙｓｔｅｍｓ（Ｒ．Ｋｕｍａｒ、Ｙ．ＬｉｕおよびＫ．Ｒｏｓｓ、２００７年、ＩＥＥＥ  ＩＮＦＯＣＯＭの議事録）の教示によれば、Ｐ２Ｐストリーミング・システムの最大ビデオ・ストリーミング速度は、ビデオ・ソース・サーバの容量、システム内のピア数、および全ピアの総アップロード容量によって決まる。最大ストリーミング速度を達成するための完璧なスケジューリング・アルゴリズムも提案されている。このスケジューリング・アルゴリズムでは、各ピアは、サーバから直接取得したビデオ・コンテンツをシステム内のその他の全てのピアにアップロードする。全てのピアにおいてアップロード容量利用率１００％を保証するために、それぞれのピアは異なるコンテンツをサーバからダウンロードし、ピアがサーバからコンテンツをダウンロードする速度はそのアップロード容量に比例する。
【０００７】
スケジューリング・アルゴリズムが完璧なら、システムが許容する最大ストリーミング速度が達成される。システム内にｎ個のピアがあり、ピアｉのアップロード容量がｕｉ（ｉ＝１、２、…、ｎ）であると仮定する。システム内には、アップロード容量ｕｓを有するソースが１つ存在する。このシステムによって許容される、ｒｍａｘで表される最大ストリーミング速度は、以下の通りである。
【０００８】
【数１】
0005390413.tif 000002
【０００９】
【数２】
0005390413.tif 000003
の値は、ピアあたりの平均アップロード容量である。図１は、あるデータの異なる部分が、完璧なスケジューリング・アルゴリズムによってどのように３つの異種ノードの間でスケジューリングされるかを示す、従来技術による例示的なシステム（１００）を示す図である。このシステム内には、３つのピア（１２０、１３０、１４０）が示されている。サーバ（１１０）の容量が６であり、ａ（１３０）、ｂ（１４０）およびｃ（１２０）のアップロード容量がそれぞれ２、４および６であり、全てのピアが十分なダウンロード容量を有していると仮定すると、このシステムが対応できる最大ビデオ速度は６である。この速度を達成するために、サーバは、ビデオ・データを６の部分に分割する（１５１、１５２、１５３）。ａ（１３０）は、ビデオ・データの１の部分のアップロードを担当し、ｂ（１４０）およびｃ（１２０）はそれぞれ各ビデオ・データ内の２の部分および３の部分のアップロードを担当する。このようにして、全てのピア（１３０、１４０、１２０）が最大速度６でビデオをダウンロードすることができる。このような完璧なスケジューリング・アルゴリズムを実施するためには、各ピアが、システム内のその他の全てのピアとの接続を維持し、それらとビデオ・コンテンツを交換する必要がある。さらに、サーバは、ビデオ・ストリームを、ピアごとに速度の異なる複数のサブ・ストリームに分割する必要がある。現実のＰ２Ｐストリーミング・システムでは、ピアの数はすぐに数千にもなる。現在のオペレーティング・システムでは、普通のピアが数千もの同時接続を維持することは非現実的である。また、サーバが実時間でビデオ・ストリームを数千のサブ・ストリームに分割することも困難である。従って、理論上の上限に近いストリーミング速度を達成することができるＰ２Ｐストリーミング・システムがあり、その方式が実用化できる程度に実用的であることが望ましい。
【発明の概要】
【課題を解決するための手段】
【００１０】
本発明の１つの特徴によれば、ノード・ネットワーク内でデータを同報通信する装置および方法が開示される。データは、ビデオ信号、オーディオ信号、オーディオおよびビデオ両方の信号、ならびにテキスト・データ、補助データ、符号化情報など様々な形態のデータを含むことができる。例示的な実施例によれば、信号を同報通信する方法は、複数のピアから、前記信号を求める複数の要求を受信するステップと、データを要求しているピアの数を決定するステップと、前記複数のピアを、複数のピア・サブセットに編成するステップと、前記信号を、ピア・サブセットの数に等しい数のいくつかの信号部分に分割するステップと、各ピア・サブセット内の１つのピアを、前記ピア・サブセットのクラスタ・ヘッドとして指定するステップと、前記信号の一部分を、各ピア・サブセット内の前記クラスタ・ヘッドに伝送するステップとを含む。
【００１１】
本発明の別の特徴によれば、信号を同報通信する方法は、各クラスタ・ヘッドが、それぞれが受信した信号の一部分を前記その他のクラスタ・ヘッドのそれぞれに伝送して、各クラスタ・ヘッドが、その他の各クラスタ・ヘッドから信号の各部分を受信することによって、各クラスタ・ヘッドが前記信号を表す再結合信号を生成できるようにするステップをさらに含む。
【００１２】
本発明の別の特徴によれば、この装置は、複数のノードからデータを求める要求を受信するインタフェースと、データを要求しているノードの数を決定し、前記複数のノードを複数のノード・サブセットに編成し、前記データをノード・サブセットの数に等しい数のいくつかの部分に分割するプロセッサと、前記データの一部分を、各ノード・サブセットのクラスタ・ヘッドに送信する送信機とを備える。
【図面の簡単な説明】
【００１３】
【図１】完璧なスケジューリング・アルゴリズムを使用するためのＰ２Ｐアーキテクチャを示す、従来技術による例示的なシステム（１００）を示す図である。
【図２】本発明による階層的にクラスタ化されたＰ２Ｐストリーミング・システムを示す図である。
【図３】本発明による新たなピアの加入を処理する方法を教示する例示的な実施例を示す図である。
【図４】本発明によるピアの離脱を処理する方法を教示する例示的な実施例を示す図である。
【図５】本発明によるクラスタのリバランシングの第１の段階の例示的な実施例を示す図である。
【図６】本発明によるリバランシングの第２の段階の例示的な実施例を示す図である。
【図７】本発明によるクラスタ・マージ・プロセスの例示的な実施例を示す図である。
【図８】本発明によるクラスタ分割プロセスの例示的な実施例を示す図である。
【図９】本発明によるブートストラップ・ノードのアーキテクチャの例示的な実施例を示す図である。
【図１０】本発明によるＨＣＰＳシステムの垂直拡張の例示的な実施例を示す図である。
【発明を実施するための形態】
【００１４】
本発明の概念を除けば、図面に示す各要素は周知であり、詳細には説明しない。また、テレビジョン放送および受信機については精通していることを前提とし、それについても本明細書では詳細には説明しない。階層的にクラスタ化されたＰ２Ｐストリーミング方式（ＨＣＰＳ）は、完璧なスケジューリング・アルゴリズムが直面するスケーラビリティの問題に対処するものである。大きなメッシュを１つだけ形成する代わりに、ＨＣＰＳでは、ピアをクラスタというグループに分ける。１つのクラスタ内のピアの数は比較的少ないので、クラスタ・レベルでは、完璧なスケジューリング・アルゴリズムをうまく適用することができる。ピアは、ネットワーク状の構造に構成された、装置、携帯電話、テレビジョン信号処理装置、無線周波受信機、コンピュータ、シン・クライアント、セット・トップ・ボックス、モデム、遠隔装置、ブリッジ装置などとすることができる。クラスタ内の１つのピアがクラスタ・ヘッドとして選択され、このピアがこのクラスタのソースとして働く。クラスタ・ヘッドは、システム階層における上位レベルのクラスタに加入することによってストリーミング・コンテンツを受信する。クラスタ・ヘッドは、クラスタ内のどのピアでもよく、システム設計者が決定する任意の基準に基づいて選択することができる。クラスタ・ヘッドは、装置、携帯電話、テレビジョン信号処理装置、無線周波受信機、コンピュータ、シン・クライアント、セット・トップ・ボックス、モデム、遠隔装置、ブリッジ装置などとすることができる。
【００１５】
図２を参照すると、本発明によって提案されるシステム（２００）の簡単な一例の例示的な実施例が示してある。図２のシステムでは、ピア（ａ１〜ａ３、ｂ１〜ｂ３）は、２レベルの階層（Ｌ２、Ｌ３）に構成される。ベース・レベル（Ｌ３）では、ピアは、小さなサイズのピア・サブセットまたはクラスタ（２４０、２５０、２６０）にグループ化される。１つのクラスタ内では、全てのピアが互いに接続されている。最大のアップロード容量を有するピア（ａ１、ｂ１、ｃ１）が、クラスタ・ヘッドとして選択される。トップ・レベル（Ｌ２）では、全てのクラスタ・ヘッドとビデオ・サーバとが、２つのクラスタ（２２０、２３０）を構成する。ビデオ・サーバ（２１０）は、トップ・レベル（Ｌ２）において、完璧なスケジューリング・アルゴリズムを用いて全てのクラスタ・ヘッド（ａ１、ｂ１、ｃ１）にコンテンツを配布する。ベース・レベル（Ｌ３）では、各クラスタ・ヘッド（ａ１、ｂ１、ｃ１）が、そのクラスタにおけるビデオ・サーバとして機能して、ダウンロードしたビデオを、やはり完璧なスケジューリング・アルゴリズムを用いて同じクラスタ内のその他のピアに配布する。普通のピアそれぞれにおける接続数は、それが属するクラスタのサイズによって制限される。クラスタ・ヘッド（ａ１、ｂ１、ｃ１）は、さらに上位レベルのクラスタ（Ｌ２）における接続も維持している。
【００１６】
例示的な実施例では、クラスタ・サイズはＮｍａｘによって制限され、ソースは最大でＮｓ個のトップ・レイヤ・クラスタをサポートできるものと仮定する。図２に示すように、２レイヤＨＣＰＳシステムは、最大でＮｓ（Ｎｍａｘ）２個のピアに対応することができる。Ｎｓ＝１０、Ｎｍａｘ＝２０であると仮定すると、ＨＣＰＳは最大で４０００個のピアをサポートすることができる。１つのピアが維持しなければならない接続の最大数は、クラスタ・ヘッドの場合で４０個、普通のピアの場合で２０個となり、これは十分に管理できる数である。階層のレベル数を増やせば、さらに多くのピアに対応することができる（垂直拡張）。
【００１７】
本発明によるシステムを設計する際には、サポート可能なストリーミング速度を最大にすることができるようにピアをクラスタ化することが望ましい。所与のセットのピアおよびソースについて、最大ストリーミング速度ｒｍａｘは、接続の完全なメッシュで完璧なスケジューリング・アルゴリズムを用いて達成される。ＨＣＰＳで構築されるメッシュは、完全には接続されておらず、サポート可能な最大ストリーミング速度が低下する可能性がある。ＨＣＰＳがｒｍａｘに近いストリーミング速度をサポートできるようにするピア・クラスタ化ストラテジを有することが望ましい。ヒューリスティックなピア・クラスタ化ストラテジにより、ＨＣＰＳは、良好なサポート可能なストリーミング速度を有することができる。
【００１８】
所与のＨＣＰＳメッシュ・トポロジの望ましいサポート可能なストリーミング速度を最適化問題として定式化するために、ＨＣＰＳメッシュ内にクラスタがＣ個、ピアがＮ個、ソースが１つ存在するものと仮定する。クラスタｃは、Ｖｃ個のピアを有する（ｃ＝１、２、…、Ｃ）。ピアｉのアップロード容量をｕｉで表す。ピアは、普通のピアとして、あるいは上位レイヤ・クラスタのクラスタ・ヘッドとして、且つベース・レイヤ・クラスタの普通のピアとして、ＨＣＰＳメッシュに参加することができる。普通のピアとしてクラスタｃに属するピアｉのアップロード容量をｕｉｃ、クラスタ・ヘッドとしてクラスタｃに属するピアｉのアップロード容量をｈｉｃと表す。発明者らは、さらに、ソースのアップロード容量をｕｓで表し、トップ・レイヤのクラスタｃに使用されるソースの容量を
【００１９】
【数３】
0005390413.tif 000004
と表す。
【００２０】
【数４】
0005390413.tif 000005
が、完璧なスケジューリング・アルゴリズムを用いるクラスタｃの最大ストリーミング速度を表す場合には、所与のクラスタ型ＨＣＰＳメッシュのサポート可能な最大ストリーミング速度ｒＨＣＰＳは、以下の最適化問題として定式化することができる。
【００２１】
【数５】
0005390413.tif 000006
ただし、
【００２２】
【数６】
0005390413.tif 000007
である。ここで、数式（３）は全てのｃ（ｃ＝１、２、…、Ｃ）に対して成立し、数式（４）は全てのｉ（ｉ＝１、２、…、Ｎ）に対して成立する。ピアｉがクラスタｃに含まれない場合は、ｕｉｃ＝０であり、ピアｉがクラスタｃのヘッドでない場合は、ｈｉｃ＝０である。
【００２３】
所与のメッシュ・トポロジのサポート可能な最大ストリーミング速度は、全てのクラスタがサポートできるストリーミング速度である。クラスタ・ヘッドは上位レイヤのクラスタおよび下位レイヤのクラスタの両方に参加し、ソースのアップロード容量はいくつかのトップ・レイヤのクラスタによって使用されるので、ＨＣＰＳのサポート可能なストリーミング速度は、クラスタのアップロード容量およびソースのアップロード容量の割当てを調節することによって最大にすることができる（数式２）。数式（３）の第１項は、ピアあたりの平均アップロード容量を表し、第２項は、クラスタ・ヘッドのアップロード容量を表す（クラスタ・ヘッドはソースになることもピアになることもできる）。クラスタｃにおけるストリーミング速度の最大値
【００２４】
【数７】
0005390413.tif 000008
は、完璧なスケジューリング・アルゴリズムによって支配されるので、これは数式（３）となる。さらに、上位レイヤのクラスタおよび下位レイヤのクラスタに割り当てられたクラスタ・ヘッドの帯域幅の量は、その全体としてのアップロード容量を超えてはならない（数式４）。最後に、ソースでは、全てのクラスタに割り当てられた全体としてのアップロード容量が、ソースの全体としてのアップロード容量を超えてはならない（数式５）。
【００２５】
ＨＣＰＳメッシュ・トポロジでは、最適速度ｒｍａｘに近いストリーミング速度をサポートすることが望ましい。４００個のピアおよび１つのソース・ノードが存在し、クラスタ・サイズが２０であり、ピアは２０個のベース・レイヤ・クラスタにグループ化され、クラスタ・ヘッドごとに１つのトップ・レイヤ・クラスタが形成されるものと仮定する。ＨＣＰＳのサポート可能な最大ストリーミング速度は、数式（２）に定式化した最適化問題によって計算される。
【００２６】
数式（２）によれば、サポート可能な最大ストリーミング速度ｒＨＣＰＳは、全てのクラスタの中で最小のクラスタ・ストリーミング速度をとる。クラスタ・ストリーミング速度（数式３）は、クラスタの平均アップロード容量とクラスタ・ヘッドの速度の最小値である。資源の浪費を避けるために、ピアの分割は、平均アップロード容量の近いクラスタに分割されるように行われるものとする。各ピアにおける個々のクラスタの平均アップロード容量のずれは、最小限に抑えなければならない。クラスタ・ヘッドのアップロード容量は、可能な限り大きくしなければならない。ボトルネックを回避するために、ベース・レイヤの容量に割り当てられるクラスタ・ヘッドの容量は、平均アップロード容量より大きくなければならない。さらに、クラスタ・ヘッドは、上位レイヤのクラスタにも加入する。理想的には、クラスタ・ヘッドの速度は、２ｒＨＣＰＳ以上であるものとする。
【００２７】
クラスタ内のピアの数の上限は、比較的小さな値であることが望ましい。クラスタ内のピアの数によって、ピアのアウト・ディグリー（ｏｕｔ−ｄｅｇｒｅｅ）が決まり、クラスタのサイズが大きいと、クラスタが完璧なスケジューリングを使用した適切な実行を行うことができなくなる。
【００２８】
ピアのダイナミクス（ｐｅｅｒ  ｄｙｎａｍｉｃｓ）があるので、すなわちピアのシステムへの加入およびシステムからの離脱が常に起きているので、整合性のある高いサポート可能なストリーミング速度を有するように、ＨＣＰＳメッシュを動的に調節しなければならない。ＨＣＰＳシステムは、ネットワーク全体に関する知識、すなわちシステム内のピア、それらのピアのアップロード容量、メッシュ・トポロジ（クラスタのメンバシップおよびそのクラスタ・ヘッド）などに関する知識を有するブートストラップ・ノードを有する。ブートストラップ・ノードは、数式（２）に定式化した最適化問題を解く最適化プログラムも実行する。一方、クラスタ・ヘッドは、それが属するクラスタを管理する。クラスタ・ヘッドが担当するのは、（ｉ）メンバ・ピアのアップロード容量およびクラスタ・ヘッドとして割り当てられたアップロード容量の大きさにローカルに基づいて完璧なスケジューリング・アルゴリズムを実行すること、（ｉｉ）ローカルなピアの離脱およびクラッシュを処理すること、（ｉｉｉ）ブートストラップ・ノードからの命令を処理すること、等である。この命令には、クラスタに新たなピアを加入させる、クラスタのマージを行う、クラスタを分割する、クラスタ・ヘッドを変更する、等がある。また、（ｉｖ）ブートストラップ・ノードとの通信を維持することもクラスタ・ヘッドの担当である。クラスタのメンバシップについては、定期的にブートストラップ・ノードを更新する。
【００２９】
図３から図５は、新たなピアの加入処理、ピアの離脱処理、およびクラスタのリバランシング（ｒｅｂａｌａｎｃｉｎｇ）処理をそれぞれ示す図である。
【００３０】
図３を参照すると、新たなピアの加入を処理する方法を教示する例示的な実施例が示してある（３００）。新たに到着したピアは、最初にブートストラップ・ノードに接触する（３０５）。そのピアのアップロード容量ｕおよび現在のサポート可能なストリーミング速度ｒＨＣＰＳに基づいて、ピアが分類される（３１０）。このピアは、ｕ≧ｒＨＣＰＳ＋δである場合にはＨＰｅｅｒ（大アップロード容量）に分類され、ｒＨＣＰＳ−δ＜ｕ＜ｒＨＣＰＳ＋δである場合にはＭＰｅｅｒ（中アップロード容量）に分類され、それ以外の場合にはＬＰｅｅｒ（小アップロード容量）に分類される。ピア数がＮｍａｘ未満である全てのクラスタは、新たなピアを受け入れる資格がある。ここで、Ｎｍａｘは、クラスタによって許容されるノードの最大数である。
【００３１】
新たなピアのアップロード容量ｕがいくつかの資格のあるクラスタ・ヘッドのアップロード容量よりあるマージン分だけ大きい場合（３１５）には、ピアは、クラスタ・ヘッドのアップロード容量が最も小さいクラスタに割り当てられる。新たなピアが元のクラスタ・ヘッドに取って代わり、元のヘッドは普通のピアとなってクラスタ内に留まる（３２０）。
【００３２】
ブートストラップ・ノードは、この新たなピアをクラスタ・ヘッドに転送し、クラスタ・ヘッドに対して新たなピアがそれに取って代わることを通知する。クラスタ・ヘッドは、メンバシップ情報を新たなピアに転送し、自分自身を上位レイヤ・クラスタから登録解除する。元のクラスタ・ヘッドは、この時点から普通のピアとなる。新たなピアは、自分自身を上位レイヤ・クラスタに登録することによってクラスタ・ヘッドの役割を担い、それが新たなヘッドとなったクラスタ内のピアに通知する。新たなヘッドは、完璧なスケジューリング・アルゴリズムを実行し、クラスタを運営する。マージンの値は、通常は構成パラメータであることに留意されたい。クラスタ・ヘッドの変更のオーバヘッドは大きいので、通常は、マージンは、比較的大きな値に設定される。
【００３３】
新たなピアは、何れのクラスタ・ヘッドにも取って代わらない場合には、ｕの値およびクラスタの平均アップロード容量に応じて何れかのクラスタに割り当てられる。ピア間のクラスタ割当ての例示的な実施例では、ピアは、それがＨＰｅｅｒである場合（３２５）には、平均アップロード容量が最小であるクラスタに割り当てられ（３３０）、ＭＰｅｅｒである場合（３３５）には、ピア数が最小であるクラスタに割り当てられ（３４０）、ＬＰｅｅｒである場合（３４５）には、平均アップロード容量が最大であるクラスタに割り当てられる（３５０）。このように分配するのは、クラスタ間でアップロード資源のバランスをとるためである。新たなピアは、対応するクラスタ・ヘッドに転送され、ブートストラップ・ノードは、クラスタ・ヘッドに対して新たなピアを承認するよう要求する。クラスタ・ヘッドは新たなピアを受け入れ、クラスタ内のその他のピアに通知する。新たなピアとその他のピアとの間で接続が確立され、クラスタ・ヘッドが完璧なスケジューリングを適用することによって伝送速度を調節する。全てのクラスタが満杯で、新たなピアを受け入れることができない場合には、ブートストラップ・ノードは、１つのクラスタを無作為に選択し、そのクラスタを２つのクラスタに分割する。
【００３４】
図４を参照すると、ピアの離脱を処理する方法を教示する例示的な実施例が示してある（４００）。ピアが離脱を決定したとき（４０５）、そのピアが普通のピアである場合（４０７）には、そのピアはクラスタ・ヘッドに離脱を通知する（４１５）。クラスタ・ヘッドは、そのピアをクラスタ・メンバ・リストから削除し、その他のピアにそのピアの離脱を通知する（４５０）。次いで、クラスタ・ヘッドは、完璧なスケジューリングに基づいてその他のピアへの送信速度を再計算する。クラスタ・ヘッドは、ブートストラップ・ノードに対してもそのピアの離脱を通知する（４６０）。
【００３５】
離脱するピアがクラスタ・ヘッドである場合（４０７）には、そのピアは、ブートストラップ・ノードにその離脱を通知する（４１０）。ブートストラップ・ノードは、クラスタ内の既存のピアから１つのピアを新たなクラスタ・ヘッドとして選択する（４２０）。次いで、ブートストラップ・ノードは、選択したノードに、それが次のクラスタ・ヘッドになることを通知する（４３０）。次いで、新たなクラスタ・ヘッドは、クラスタ・ヘッドの機能を引き継ぐ（４４０）。次いで、新たなクラスタ・ヘッドは、古いクラスタ・ヘッドをそのクラスタ・メンバ・リストから削除し、そのクラスタ・ヘッドの離脱を他のピアに通知する（４５０）。次いで、新たなクラスタ・ヘッドは、完璧なスケジューリングに基づいてその他のピアへの送信速度を再計算する。クラスタ・ヘッドは、ブートストラップ・ノードにもそのピアの離脱を通知する（４６０）。
【００３６】
ピアがクラッシュした場合には、普通のピアの場合と同じ処理が行われる。クラスタ・ヘッドは、ピアのクラッシュを検知し、普通の離脱の場合と同じように処理する。クラスタ・ヘッドがクラッシュした場合には、当該クラスタ内のピアが、ブートストラップ・ノードに通知することができる。ブートストラップ・ノードは、アップロード容量が最大であるピアを、新たなクラスタ・ヘッドとして選択する。ブートストラップ・ノードがクラスタ・ヘッドとして振る舞い、選択したピアがそれに取って代わって新たなクラスタ・ヘッドになるようにする。
【００３７】
クラスタは、ピアのダイナミクスの結果として、クラスタ内のピア数および資源量のバランスを失う恐れがある。図５を参照すると、クラスタのリバランシングの第１の段階が示してある。ＨＣＰＳでは、ブートストラップ・ノードが、定期的にクラスタのリバランシングを試みる。一周期の最後に、ブートストラップ・ノードは、まずクラスタ・サイズのバランシングを試みる。クラスタは、クラスタ・サイズの降順に分類される（５１０）。ピア数が最大のクラスタとピア数が最小のクラスタの間の差（５２０）がしきい値
【００３８】
【数８】
0005390413.tif 000009
より大きい場合（５３０）には、これら２つのクラスタをマージした後に、これをバランスのとれた２つのクラスタに分割する（５４０）。ここで、
【００３９】
【数９】
0005390413.tif 000010
は平均クラスタ・サイズである。マージ動作および分割動作については、それぞれ以下で述べる。上記プロセスは、条件に合わないクラスタがなくなるまで続く（５５０）。次いで、プロセスは、図６にさらに示すように、リバランシングの第２の段階を開始する（５６０）。
【００４０】
図６を参照すると、リバランシングの第２の段階が示してある（６００）。クラスタ・リバランシングの第２の段階では、ブートストラップ・ノードは、資源のバランシングを試みる。クラスタは、ピアあたりの平均アップロード容量の降順に分類される（６１０）。アップロード容量が最大であるクラスタとアップロード容量が最小であるクラスタの平均アップロード容量差（６２０）がしきい値
【００４１】
【数１０】
0005390413.tif 000011
より大きい場合には、これら２つのクラスタをマージした後に、これをバランスのとれた２つのクラスタに分割する（６４０）。ここで、
【００４２】
【数１１】
0005390413.tif 000012
はシステムの平均アップロード容量である（６３０）。
【００４３】
次に図７を参照すると、クラスタのマージ処理が示してある（７００）。ブートストラップ・ノードは、２つのクラスタ・ヘッドに、マージを行う決定を通知し、どのクラスタをマージするかを示す（７１０）。マージされたクラスタ・ヘッドは、自分自身を上位レイヤ・クラスタから登録解除し（７２０）、メンバ・リストを新たなクラスタ・ヘッドに送信する（７３０）。新たなクラスタ・ヘッドは、新たなクラスタ内の全てのピアに、このメンバ・リストを通知する（７４０）。ピア間で接続が確立される。新たなクラスタ・ヘッドは、完璧なスケジューリングを用いて送信速度も再計算する。新たなクラスタ・ヘッドは、この拡大されたクラスタ内で完璧なスケジューリングを実行する（７５０）。
【００４４】
次に図８を参照すると、クラスタの分割プロセスが示してある（８００）。クラスタ分割の目的は、ほぼ同数のピアを有し、ピアあたりの平均アップロード容量もほぼ同じである２つのクラスタにピアを分割することである。ブートストラップ・ノードは、プロセス全体を管理する。クラスタ・ヘッドは、アップロード容量の降順にピアを分類する（８１０）。アップロード容量が最大であるピアが、新たに生じるクラスタのクラスタ・ヘッドになる（８２０）。その後のラウンドでは、分類リストの最上位に位置する２つのピアを、リストから取り出す（８３０）。アップロード容量がより大きいピアを、総アップロード容量がより小さいクラスタに割り当て（８３５）、アップロード容量がより小さいピアを、総アップロード容量がより大きいクラスタに割り当てる。プロセスは、全てのピアが割り当てられるまで続く（８２５）。最後のラウンドでピアが１つしか残っていない場合（８４０）には、そのピアは、総アップロード容量がより大きいクラスタに割り当てられる（８４５）。
【００４５】
クラスタのメンバシップが決定されると、新たなクラスタ・ヘッドが、新たなクラスタを生成する（８５０）。新たなクラスタ・ヘッドは、自分自身を上位レイヤのクラスタに登録し、次いで、全てのピアにメンバ・リストを同報通信する（８５５）。クラスタ・ヘッドは、完璧なスケジューリングを用いて各ピアへの送信速度を計算する（８６０）。元のクラスタ・ヘッドも、新たなメンバ・リストのクラスタに残っているピアに通知し、新たな送信速度を計算する。
【００４６】
動的ピア管理によって、ＨＣＰＳは、高いストリーミング速度を達成するためにメンバ・クラスタのバランシングを行う自己適応型機能を有することができ、これにより、ＨＣＰＳは、その他のＰ２Ｐストリーミング・システムとの関連においても望ましいものとなる。例えば、１つのノードｉがある特定のデータ・セグメントをその他のピアに送達するのに伝送遅延ｔｓが必要であると仮定すると、完璧なスケジューリング・アルゴリズムにより、トップ・レベルの中で最後にそのデータ片を受信するピアは、時間ｔｐ＋Ｎｍａｘ＊ｔｓだけ待機することになる。ここで、ｔｐはサーバからノードｉまでの伝搬遅延である。所期の小さなＮｍａｘならびに従来の伝搬遅延および伝送遅延を仮定すると、１つのクラスタ内の遅延は、かなり小さくすることができる。ベース・レベルの普通のピアがクラスタ・ヘッドからデータをフェッチするプロセスは、ヘッドがサーバからデータをフェッチするプロセスと同様なので、２レベルＨＣＰＳシステムでは、データ片は、システムの全てのピアに到達するのに最大で２回、上記のようなプロセスを受けることになる。
【００４７】
次に図９を参照すると、ブートストラップ・ノードのアーキテクチャが示してある（９００）。ブートストラップ・ノードは、３つの重要な構成要素（９１０〜９３０）を有する。通信インタフェース構成要素は、ピアとブートストラップ・ノードとの間の入来／出力信号通信の処理を担当する。コーディネート（ｃｏｏｒｄｉｎａｔｉｎｇ）構成要素は、キー・アルゴリズムを実行する。これらのアルゴリズムには、上記の説明によれば、クラスタ・リバランシング・アルゴリズム、ピア加入アルゴリズム、ピア離脱アルゴリズム、ピア・マージ・アルゴリズム、ピア分割アルゴリズムなどがある。コーディネート構成要素は、構成要素３（９３０）に記憶されたピア関連情報およびクラスタ関連情報を使用する。コーディネート構成要素は、入来信号情報に基づいて構成要素３（９３０）を更新することもできる。構成要素３（９３０）は、ピア関連情報およびクラスタ関連情報を記録するデータベースである。この情報としては、ピアのＩＰアドレス、ピアのアップロード容量、あるピアがクラスタ・ヘッドであるかどうか、ピアがどのクラスタに加入するか、等があるが、これらに限定されるわけではない。
【００４８】
ピア・ノードのアーキテクチャ（図示せず）は、ブートストラップ・ノードのアーキテクチャと同様である。ピアも、３つの構成要素を有する。通信インタフェース構成要素は、その他のピアおよびブートストラップ・ノードとの信号通信の処理を担当する。コーディネート構成要素は、キー・アルゴリズムを実行する。当該ピアがクラスタ・ヘッドである場合には、そのピアは、完璧なスケジューリング・アルゴリズムを実行し、メンバ・ピアの到着、離脱およびクラッシュ、クラスタのマージおよび分割などを処理する。当該ピアが普通のピアである場合には、そのピアは、クラスタ・ヘッドおよびブートストラップ・ノードに接触して、その情報を更新する。また、クラスタ・ヘッドおよびブートストラップ・ノードから、その他のクラスタ・ヘッドに取って代わる命令も受信する。クラスタ関連情報データベースは、同じクラスタに属するピアの情報を記憶する。
【００４９】
図１０を参照すると、ＨＣＰＳシステムの垂直拡張の例示的な実施例が示してある（１０００）。ＨＣＰＳは、２レベル構造により、他の信号レベルＰ２Ｐストリーミング・システムより多数のピアをサポートすることができる。垂直方向に拡張されたシステムは、第１のビデオ・サーバ（１０１０）と、第２のレベルのクラスタ（１０５１〜１０５６）のための第１のレベルのソース（１０２０、１０３０）とを含む。レベルを追加することにより、ピアの数をさらに増加させることができる。これを以下では垂直拡張と呼ぶ。第２のレベルのクラスタ（１０５１〜１０５６）内のピアは、ビデオ−サーバとして、別の２レベルＨＣＰＳシステムを駆動することができる。もちろん、次の２レベル・クラスタ（１０４０、１０５０）のヘッドとなるピアは、現在のクラスタ内で機能し、且つ下位レベル・クラスタ（１０５７〜１０６２）のソースとして機能するだけの十分なアップロード容量を有していなければならない。垂直拡張により、システムのレベル数が増加するにつれて、ピア数は指数関数的に増加する。
【図１】
0005390413.tif 000013
【図２】
0005390413.tif 000014
【図３】
0005390413.tif 000015
【図４】
0005390413.tif 000016
【図５】
0005390413.tif 000017
【図６】
0005390413.tif 000018
【図７】
0005390413.tif 000019
【図８】
0005390413.tif 000020
【図９】
0005390413.tif 000021
【図１０】
0005390413.tif 000022