JP2012520004A - ピアツーピアネットワークにおける優先順位付けのための方法及び装置 - Google Patents

Abstract

本発明は、データコンテンツを共有するピアツーピアネットワークと組み合わせて使用されるノード及び方法に関する。優先順位機構は、緊急度の観点からのデータコンテンツに対する必要性に基づいて対応する要求ピアを選択してもよいサービングピアを利用して導入される。要求ピアは、例えばビデオバッファにおいて再生のために使用可能なバッファリングされたデータの量であってもよいデータコンテンツに対する要求に緊急度指標を含んでもよい。サービングピアは、要求から緊急度指標を抽出してもよく（５２）、データコンテンツをアップロードするピアを選択するように緊急度指標を使用する優先順位機構を適用してもよい（５３）。

Description

本発明は、ピアツーピア（すなわち、Ｐ２Ｐ）ネットワークにおいて使用される方法及び装置に関し、特に、Ｐ２Ｐネットワークにおいて優先順位付けをサポートする方法及び装置に関する。

Ｐ２Ｐコンピュータネットワークにおいて、ピアノード（すなわち、ピア）は、互いにデータコンテンツを配信するように協働する。ピアの種々の接続性及び累積帯域幅は、例えばオーディオ、ビデオ、データ又はデジタル形式のあらゆるものを含むファイル、電話トラフィック、ビデオストリーミング、あるいはビデオダウンロード等のデータコンテンツを共有するために使用される。Ｐ２Ｐネットワークは、多くの場合、相対的に数の少ない集中サービサーがデータコンテンツをエンドノードに提供する階層ネットワークトポロジよりもデータコンテンツをはるかに効率的に配信する。ピュアＰ２Ｐネットワークにおいて、クライアント又はサーバの概念はなく、あるのは同等のピアだけである。しかし、種々のネットワーク構造が種々のタスクに対して好まれる可能性があるために、クライアント／サーバ構造をＰ２Ｐ構造と組み合わせる多くの種類のハイブリッドＰ２Ｐネットワークがある。以下において、Ｐ２Ｐネットワークという用語は、ピュアＰ２Ｐネットワーク及びハイブリッドＰ２Ｐネットワークを含むことを意図する。

Ｐ２Ｐ通信に対して使用されうる多数の種々のプロトコル、例えばＢｉｔＴｏｒｒｅｎｔ、Ｇｎｕｔｅｌｌａ、ＣＡＮ、ＦａｓｔＴｒａｃｋ及びＪＸＴＡがある。ＢｉｔＴｏｒｒｅｎｔプロトコルは、最も広範に使用されたＰ２Ｐプロトコルのうちの１つであり、２００８年２月２８日に最後に編集され、「ｈｔｔｐ：／／ｗｗｗ．ｂｉｔｔｏｒｒｅｎｔ．ｏｒｇ／ｂｅｐｓ／ｂｅｐ＿０００３．ｈｔｍｌ」で入手可能であるＣｏｈｅｎ、Ｂｒａｍによる「Ｔｈｅ ＢｉｔＴｏｒｒｅｎｔ Ｐｒｏｔｏｃｏｌ Ｓｐｅｃｉｆｉｃａｔｉｏｎ」、バージョン１１０３１において説明される。

ＢｉｔＴｏｒｒｅｎｔプロトコル及び他の多くのＰ２Ｐプロトコルは、最初にＰ２Ｐオーバレイネットワークを介してファイル共有できるように設計された。ファイル共有の場合、ユーザは可能な限り高速にファイルをダウンロードすることを望むものであり、一般にファイルの末尾がファイルの先頭の前にダウンロードされるかは少しも重要ではない。

ビデオオンデマンド（ＶｏＤ）及びライブストリーミングＰ２Ｐシステムが昨今普及するにつれ、これらの普及しているサービスにも対処できるようにＢｉｔＴｏｒｒｅｎｔ等のファイル共有のためのＰ２Ｐプロトコルを変更することに関心がある。しかし、ＶｏＤ又はビデオストリーミングの場合、ファイル共有の場合以外に考慮すべき他の要素がある。ＶｏＤの場合、ユーザは、コンテンツの再生を開始するためにファイルの先頭を最初にダウンロードすることを望む。その後ユーザは、コンテンツの後続部分等を要求する。従って、コンテンツのダウンロードは、ある自由度である程度連続している。ＶｏＤサービスのユーザにとって、起動遅延は経験品質（ＱｏＥ）の重要な部分である。起動遅延は、ビデオのダウンロードを開始してからそのファイルの再生が開始するまでにかかる時間である。ＶｏＤサービスの継続性は更に重要である。１つ又は複数の最初の部分が入手可能である限り、ビデオファイルの再生はファイル全体がダウンロードされる前に開始する。しかし、再生ポイントがビデオファイルの後続部分に到達する前に後続部分がダウンロードされていることが重要である。そうでないと、ビデオはフリーズする。コンテンツのダウンロードに対してＶｏＤと同様の要望をする可能性のあるアプリケーションの他の例は、オーディオストリーミング及びビデオストリーミング、ゲーミング、並びに場合によってはソフトウェア更新である。

元のＢｉｔＴｏｒｒｅｎｔプロトコルは、いわゆるしっぺ返し手法（tit-for-tat approch）を使用する。しっぺ返し手法は、より貢献するピアがより高速にダウンロードできるようにする動機付けアルゴリズムである。サービングピア、すなわち他の関心ピア、すなわち要求ピアがダウンロードできるデータコンテンツを有するピアは、サービングピアに最も多くアップロードした要求ピアを優先するだろう。従って、しっぺ返しアルゴリズムは、最も多くアップロードするピアをより優先するために公正であるという概念を有する。それに加え、アルゴリズムが、時々、アップロードしないピアに機会を与えることにより、コンテンツを有さないピアはコンテンツの取得及び共有を開始できる。しっぺ返し手法は、元々ファイル共有に対して更に開発されたものであり、上述したようにダウンロードの実行に対する要望が異なるため、ＶｏＤ等のサービスに対して最適化されない。

従って、Ｐ２Ｐ共有に対する従来技術の機構に関する問題は、それらが、ＶｏＤ、プログレッシブダウンロード、並びにオーディオストリーミング及びビデオストリーミング等の他の種類のサービスに対してではなく、ファイル共有の場合に対して設計されることである。

従来技術の上記の説明から、例えばＶｏＤ、並びにオーディオストリーミング及びビデオストリーミングの要望のうちの少なくともいくつかに適応されるＰ２Ｐ共有のための別の方法及び装置に対する必要性があるのは明らかである。本発明の目的は、ファイル共有以外のサービスの場合にＰ２Ｐネットワークにおいてデータコンテンツをより効率的に共有できるようにする方法及び装置を提供することである

上述の目的は、独立請求項に記載された方法、ネットワークノード、並びに運用及び保守システムを利用して達成される。

本発明の第１の実施形態は、クライアントアプリケーションを含むネットワークノードにおける方法を提供する。クライアントアプリケーションは、データコンテンツを共有するピアツーピアネットワークのサービングピアとして動作する。方法において、データコンテンツに対する少なくとも１つの要求は、多数の要求ピアから受信される。要求から緊急度指標が抽出される。緊急度指標は、緊急度に関してデータコンテンツに対する要求ピアの必要性を示す。要求されたデータコンテンツは要求ピアに配信されるが、優先順位機構は配信に適用される。優先順位機構は、対応する要求ピアを判定するために緊急度指標が使用されることを示す。

本発明の第２の実施形態は、クライアントアプリケーションを含むネットワークノードにおける方法を更に提供する。しかし、第２の実施形態によると、クライアントアプリケーションは、データコンテンツを共有するピアツーピアネットワークの要求ピアとして動作する。方法において、データコンテンツに対する要求はサービングピアに送出される。緊急度指標は要求に含まれる。方法は、この緊急度指標を判定することを更に含む。緊急度指標は、緊急度に関してデータコンテンツに対する要求ピアの必要性を示す。

本発明の第３の実施形態は、クライアントアプリケーションを含むネットワークノードを提供する。クライアントアプリケーションは、データコンテンツを共有するピアツーピアネットワークのサービングピアとして動作するように構成される。ネットワークノードは、多数の要求ピアからデータコンテンツに対する少なくとも１つの要求を受信し、且つ要求されたデータコンテンツを要求ピアに配信するように構成される。更にクライアントアプリケーションは、要求から緊急度指標を抽出するように構成される。緊急度指標は、緊急度に関してデータコンテンツに対する要求ピアの必要性を示す。クライアントアプリケーションは優先順位機構を含む。優先順位機構は、対応する要求ピアを判定するために緊急度指標を使用することにより、要求されたデータコンテンツの配信を制御するように構成される。

本発明の第４の実施形態は、クライアントアプリケーションを含むネットワークノードを提供する。クライアントアプリケーションは、データコンテンツを共有するピアツーピアネットワークの要求ピアとして動作するように構成される。ネットワークノードは、データコンテンツに対する要求をサービングピアに送出するように構成される。クライアントアプリケーションは、緊急度指標を要求に含むように構成される。クライアントアプリケーションは、緊急度指標を判定するように更に構成される。緊急度指標は、緊急度に関してデータコンテンツに対する要求ピアの必要性を示す。

本発明の第５の実施形態は、データコンテンツを共有するピアツーピアネットワークを管理する運用及び保守システムを提供する。運用及び保守システムは、ピアツーピアネットワークにおいて要求ピアから少なくとも１つのメッセージを受信するように構成される。要求ピアは、ピアツーピアネットワークにおいてサービングピアからデータコンテンツを要求している。運用及び保守システムは、要求ピアから受信したメッセージから緊急度指標を抽出するように構成される。緊急度指標は、データコンテンツに対する要求ピアの必要性を示し、緊急度に関してサービングピアから要求している。運用及び保守システムは、ピアツーピアネットワークの管理に関して判断するために緊急度指標使用するように更に構成される。

本発明の実施形態の利点は、要求ピアの必要性に従ってデータコンテンツを効率的に配信する手段を提供することにより、ＱｏＥ低下に対するリスクを軽減することである。それにより、従来技術に係る解決方法を用いる場合よりも満足した要求ピア（高レベルのＱｏＥ）及びユーザコンテンツを維持することが可能である。

本発明の実施形態の別の利点は、ビデオにおけるいわゆるシーク動作がより高速に開始することである。ユーザが再生ポイントを変更し且つビデオにおいて後続部分へのジャンプを開始する場合にシーク動作が行われる。これは、まだダウンロードされていないビデオファイルのセクションを緊急にダウンロードする要求をトリガしてもよい。所望のセクションの迅速なダウンロードが達成されるように、このような緊急の要求は、本発明の実施形態に従って考慮され、ネットワークリソース（すなわち、サービングピア）を割り当てる。

本発明の実施形態の別の利点は、システムリソースがより知的に使用されてもよいことである。本発明の実施形態により、使用可能なリソースを現時点でそれらが最も必要とされる場所に集中させることが可能となるため、これは可能である。データコンテンツを緊急に必要とする他のピアがある場合、データを即座に必要としないピアにデータコンテンツをアップロードするのにネットワークリソースを使用中にしたままにするのは無駄である。緊急に必要とするピアへのデータコンテンツ配信を優先することにより、ネットワークリソースをより効率的に使用できる。

本発明の一実施形態の更に別の利点は、一実施形態が、データコンテンツを共有するピアツーピアネットワークにおいてボトルネック及びトラフィック輻輳を管理するツールを提供することである。データコンテンツを緊急に必要としないピアがトラフィック輻輳の場合にデータコンテンツの要求を停止することを要求されるように、これは、種々のピアのデータコンテンツに対する必要性に関する情報を運用及び保守システムに提供することにより達成される。

本発明の実施形態の更なる利点及び特徴は、図面と共に以下の詳細な説明を読むことにより明らかとなるだろう。

図１は、本発明の実施形態が実現されてもよいＰ２Ｐ通信を使用してメディアサービスを配信するシステムを示す概略ブロック図である。 、 図２ａ及び図２ｂは、本発明の実施形態に従って、それぞれ低い優先順位又は高い優先順位を与えられる要求ピアのビデオバッファを示す概略ブロック図である。 図３は、ＢｉｔＴｏｒｒｅｎｔプロトコルに従って要求ピアとサービングピアとの間で送出されたメッセージを示すシーケンス図である。 、 図４ａ及び図４ｂは、要求ピアが本発明の一実施形態に従って送出してもよいメッセージを示す概略ブロック図である。 図４ｃは、本発明の一実施形態に従って、擬似コードに示されたＢｉｔＴｏｒｒｅｎｔプロトコルの変更されたアンチョーク機構を示す概略図である。 図５は、サービングピアとして動作するクライアントアプリケーションを含むネットワークノードにおける方法である本発明の一実施形態を示すフローチャートである。 図６は、要求ピアとして動作するクライアントアプリケーションを含むネットワークノードにおける方法である本発明の一実施形態を示すフローチャートである。

次に、本発明の実施形態が好適に示される添付の図面を参照して、本発明を以下に更に詳細に説明する。しかし、本発明は、多くの種々の形態で具体化されてもよく、本明細書において説明された実施形態に限定されるものとして解釈されるべきではない。これらの実施形態は、その開示内容が完璧で完全なものとなり、本発明の範囲が当業者に完全に理解されるように提供される。図中、同一の図中符号は同一の要素を示す。

図１は、メディアサービスをクライアントエンドノード１に配信するシステム７の一例を示す。図１において、本発明の実施形態が実現されてもよい。クライアントエンドノードは、この例ではネットワーク５を介するＶｏＤサーバ８及びライブストリーミングサーバ９であるヘッドエンドサーバと通信できる。ネットワーク５は、この場合、クライアント−サーバモデルに従ってクライアントエンドノード１がヘッドエンドサーバ８及び９と通信できるようにし、且つＰ２Ｐモデルに従ってクライアントエンドノード１が互いに通信できるようにするかあるいはネットワークにおいてキャッシュサーバ２等の他のノードと通信できるようにするハイブリッドＰ２Ｐネットワークである。図１において、実線の太字の双方向の矢印はノード間のＰ２Ｐ通信を概略的に示し、実線の太字の一方向の矢印はユニキャスト通信トラフィックを概略的に示し、且つ破線の一方向の矢印はマルチキャスト通信トラフィックを概略的に示すために使用される。

図１に示された例において、ネットワーク５は、例えばＴＶサービス及びＶｏＤサービスをクライアントエンドノード１のユーザに提供するオペレータの管理ネットワークであってもよい。ＴＶサービスは、ライブストリーミングサーバ９からクライアントエンドノード１へのマルチキャスト送信を利用して提供されてもよい。ＶｏＤサービスは、ＶｏＤサーバ８からのユニキャスト送信を利用してクライアントエンドノードに提供されてもよい。図１のシステム７において、クライアントエンドノードが、Ｐ２Ｐ通信を利用して他のクライアントエンドノード又はキャッシュサーバ２からビデオファイル又はビデオファイルのセクション取得することが更に可能である。クライアントエンドノード１とＶｏＤサーバ８との間のユニキャスト通信は必要なネットワークリソースの点でＰ２Ｐ通信より高いため、クライアントエンドノード１がＰ２Ｐ通信を利用して要求されたビデオファイルを取得するのがオペレータの観点から好ましい。

例えばクライアントエンドノード１は、電気通信機能を提供する入力ユニット１１と、出力ユニット１２と、処理ユニット１３とを備える格納機能を有するセットトップボックス、コンピュータ又は他の何らかの種類の電子機器であってもよい。例えばキャッシュサーバ２は、例えば最も試聴したＴＶプログラムに関連する人気のコンテンツをキャッシュするために使用されることにより、タイムシフトＴＶサービス、すなわちＴＶプログラムの実際の放送時間後にユーザが選択する時間にそのＴＶプログラムを視聴することを要求できるサービスを提供してもよい。キャッシュサーバ２は、入力ユニット１１と、出力ユニット１２と、処理ユニット１３とを更に備える。クライアントエンドノード１及びキャッシュサーバ２は、それぞれクライアントアプリケーション３及び４を更に含む。クライアントアプリケーション３、４は、一般にソフトウェアで実現されるが、ハードウェア又はファームウェア、あるいはそれらの組合せで更に実現できる。図１のシステム７において、クライアントエンドノード１のクライアントアプリケーション３は、通信に対するＰ２Ｐモデルに従って要求ピア及びサービングピアの双方として動作するように構成され、クライアントアプリケーション４は、サービングピアとしてのみ動作するように構成される。クライアントアプリケーションは、ネットワークの別のピアからクライアントエンドノードにコンテンツを要求することに関連した動作を実行する場合に要求ピアとして動作する。クライアントアプリケーションは、コンテンツを要求ピアに提供することに関連する動作を実行している場合にサービングピアとして動作すると言われている。

図１は、この例では管理コンテンツトラッカであるコンテンツトラッカ６を備えるネットワーク５を更に示す。コンテンツトラッカの機能は、異なるコンテンツが格納されるネットワークの場所を追跡することである。要求ピアは、コンテンツトラッカに接続し、コンテンツのある特定のピースを取得できる１つ又は複数のサービングピアを見つけ出す。実際には、コンテンツトラッカ６は、この場合はオペレータにより制御される管理手段である。また、図１のシステム７は、ネットワーク５の中央監視及びトラフィック管理を実行するように構成される運用及び保守（Operation and Management;Ｏ＆Ｍ）システムを含む。ネットワーク５において概略的に示される他の機器は、プロキシサーバ１４、エッジルータ１５、集約スイッチ（aggregation switch）１６及びアクセスノード１７である。これらの種々の機器は、当業者には既知である機能及び実現例を有するため、本明細書において詳細に説明しない。

背景の節で説明されたように、Ｐ２Ｐ通信に対する従来技術の解決方法は、しっぺ返し手法を使用してもよい。例えば、サービングピアが、５つの他の要求ピアからビデオチャンク等のコンテンツのピースに対する要求を受信したと仮定する。次にサービングピアは、しっぺ返し手法に従って、例えば以前にサービングピアに最も多くのコンテンツをアップロードした３つの要求ピアにアップロードし且つ他の２つの要求ピアをチョーク(choke)する（すなわち、要求ピアにいわゆるアンチョークメッセージを受信するまでコンテンツの要求を停止するように伝えるいわゆるチョークメッセージを送出する）ことを選択する。しかし、チョークされた要求ピアのうちの１つは、関連付けられたビデオバッファが殆ど空になっているために緊急にビデオチャンクを必要とすると仮定する。このビデオチャンクが取得されない場合、ユーザはサービスの中断を経験する可能性がある。すなわち、ビデオは画面においてフリーズする。更に、対応されている全ての他のピアがほぼ満杯のバッファを有すると仮定する。従来技術の解決方法によると、この状況により、対応されている要求ピアと関連付けられたちょうど３つのコンテンツユーザが得られる一方、他の２つの要求ピアと関連付けられたユーザは、サービスが中断されるために非常に不満を有するだろう。しかし、本発明の実施形態は、最初に対応する要求ピアを判断する際に要求ピアの必要性を考慮することにより、全ての５つの要求ピアコンテンツのユーザを追跡する手段を提供する。従って、本発明の実施形態は、ビデオチャンクを最も必要とするピアにビデオチャンクを送出するために適用される優先順位機構を提供する。この優先順位機構を実現するために、要求ピアは、コンテンツに対するＰ２Ｐ要求メッセージにおいて緊急度指標(urgent indicator)を含んでもよい。要求メッセージを受信する場合、サービングピアは、要求ピアと関連付けられた緊急度指標を保存してもよく、要求ピアをソートして交換レートをアップロード又は増加するピアを判断するためにこの情報を使用してもよい。

緊急度指標は、本発明の種々の実施形態に従って多くの種々の情報を含んでもよい。緊急度指標は、例えばＶｏＤアプリケーションにおいて要求ピアのビデオバッファがどのくらい空であるかに関する情報、例えば再生のために既に使用可能なバッファリングされたデータの量、バッファが空になるまでの残りの再生時間の表示、ビデオの次の部分のバッファ空き量の表示又はバッファリングされたデータの多数の事前定義された間隔のうちの１つを示す空きレベルの分類であってもよい。緊急度指標に含まれた情報の種類に関係なく、サービングピアにより解釈されてもよいコンテンツの緊急度のある種類の測定値を提供することが重要である。その後サービングピアは、最初に最も高い緊急度を示した要求ピアにアップロードすることを選択する。

図２ａ及び図２ｂは、２つの要求ピアのメディアコンテンツに対するビデオバッファの概略図であり、本発明の実施形態が種々のピアを優先順位付けするために使用されてもよい方法を示す。図２ａ及び図２ｂは、それぞれ２つのスライディングバッファ２０ａ及び２０ｂを示す。バッファ２０ａ及び２０ｂにおいて、破線の長方形は、ダウンロードされており且つ再生のために使用可能なビデオピース（この例ではいわゆるＢｉｔＴｏｒｒｅｎｔピース）を示し、白の長方形は、ダウンロードされないで残っているビデオピースを示す。従って、図２ａは満杯のバッファ２０ａを示し、図２ｂはほぼ空のバッファを示す。従って、バッファ２０ａを含む要求ピアへのあらゆるアップロードに低い優先順位を与え、バッファ２０ｂを含む要求ピアがより緊急にビデオピースを必要とするために高い優先順位を与えられるべきであることは、道理にかなうだろう。この種の優先順位付けは、本発明の実施形態に従って可能であり、Ｐ２Ｐネットワークにおいて十分なリソースがある場合に再生時間中の中断を回避できる。

次に、元のＢｉｔＴｏｒｒｅｎｔプロトコルの変更を含む本発明の一実施形態を説明する。ＢｉｔＴｏｒｒｅｎｔプロトコルに従って、あるコンテンツを要求したいピア（すなわち、要求ピア）は、最初に図１のコンテンツトラッカ６等のトラッカから所望のコンテンツ又はその一部を有する他のピアのリストを取得する。その後、要求ピアとコンテンツを含むピア（すなわち、サービングピア）と直接通信し始める。図３は、要求ピア３１とサービングピア３２との間のＢｉｔＴｏｒｒｅｎｔプロトコルに従うメッセージ交換を概略的に示す。要求ピア３１は、最初にハンドシェークメッセージ３３をサービングピアに送出する。サービングピアは、サービングピアが有するコンテンツのピースを示すビットの集合であるビットフィールド３４を用いて応答すべきである。この情報に基づいて、要求ピアは、サービングピアが必要なあるピースを有する場合には関心メッセージ３５を送出する。しかし、関心メッセージ３５を受信する場合、サービングピアは、サービングピアが有するあるデータに関心のある他の全てのピアと共に要求ピアをリストに追加し、要求ピアのうちのいくつかをアンチョークするアンチョーク機構３７を周期的に実行する。要求ピアをアンチョークする場合、サービングピアは、コンテンツのピースを要求し始めることがＯＫであることを要求ピアに示すアンチョークメッセージ３６を送出する。次に要求ピアは、コンテンツの特定のピースを要求する要求メッセージ３８を送出する。サービングノードは、メッセージ３９において要求されたコンテンツのピースを送出することにより応答する。要求ピアは、サービングンピアから関心のあったコンテンツの全てのピースを受信するまで、あるいはアンチョークメッセージが受信されるまでコンテンツの要求を停止すべきであることを示すチョークメッセージを受信するまでコンテンツのピースを要求し続ける。

元のＢｉｔＴｏｒｒｅｎｔプロトコルに従って、アンチョークアルゴリズムは、各要求ピアがサービングピアにアップロードした量に基づいて「アンチョークを待つ」ピアのリストが格納されるしっぺ返し手法を考慮し、アンチョークメッセージは、リストと共に制限された数の要求ピアに送出される。このように、サービングピアに最も貢献する要求ピアは、サービングピアからダウンロードすることを許可される。

本発明の本実施形態によると、元のＢｉｔＴｏｒｒｅｎｔプロトコルにより送出される関心メッセージ３５及び要求メッセージ３８は、上述の緊急度指標を含むように変更される。図４ａ及び図４ｂは、それぞれそのように変更された関心メッセージ３５ａ及びそのように変更された要求メッセージ３８ａの例を概略的に示す。関心メッセージ３５ａは、長さフィールド４２と、種類フィールド４３と、更に本実施形態に従って例えば上述したようにビデオバッファにおけるバッファ量であってもよい緊急度指標４１を含むフィールド４４とを含む。要求メッセージ３８ａは、長さフィールド４５と、種類フィールド４６と、ピースインデックスフィールド４７と、開始オフセットフィールド４８と、ピース長フィールド４９と、更に本実施形態に従って緊急度指標４１を含むフィールド５０とを含む。

上述したように全てのコンテンツをダウンロードし終える前に再生を開始するＰ２Ｐ ＶｏＤ配信等の例に対して理想的でない従来のしっぺ返し手法を使用するだけでなく、緊急度指標４１を関心メッセージ３５ａ及び要求メッセージ３８ａに追加することにより、サービングピアは、データを最も必要とする要求ピアに対してアップロードする手段を得る。

本実施形態の場合に関心メッセージ３５ａ及び要求メッセージ３８ａに含まれた緊急度指標が、要求ピアのビデオバッファにおけるバッファ量であると仮定すると、図３のアンチョーク機構３７は、例えば図４ｃに示されるように変更されてもよい。図４ｃは、擬似コードに示された本発明の一実施形態に係るアンチョーク機構３７ａの概略図である。アンチョーク機構は、全ての要求ピアを周期的にソートするように機能する。関心メッセージは、要求ピアの示されたバッファ空き量により受信されている（すなわち、いわゆる関心ピア）。最も低いバッファ量を示した関心ピアは、リストにおいて最初に配置される。リストから最初の３つの関心ピアが選択される。選択されたピアはチョークされる場合にアンチョークされ、選択されなかった他の全ての関心ピアはチョークされる。当然、アンチョーク機構３７ａは、本発明の一実施形態の一例にすぎない。本発明に従って可能である他の実施形態の例を挙げるために、緊急度指標は、緊急度に関して要求ピアの必要性を示すバッファ量以外の他の情報を含んでもよく、アンチョーク機構に従って選択されるピアの数は、３つに限定されず、特定の実現例に適切であると仮定されるあらゆる数であってもよく、他の可能な別のアルゴリズムがあるために、緊急度指標に基づいて対応する要求ピアを判定するために使用される優先順位機構を実現するようにアンチョーク機構を更に適用する必要はないことが言及されてもよい。

緊急度指標が関心メッセージ３５ａ及び要求メッセージ３８ａに含まれるバッファ量である上述の実施形態において、バッファ量情報は、要求ピアが既にダウンロードしたがまだ再生していないビデオブロックの数である。この情報に対して２バイトを使用することは、１秒等の非常に小さいビデオブロックサイズに対してであっても、数時間のバッファリングされたデータに等しい２¹⁶個のビデオブロック通知するのに十分である。一方、これらのメッセージに２バイトを追加することは、関心メッセージ及び要求メッセージに対してそれぞれ７５バイト又は８７バイトのうちから２バイトを示すため、大きなオーバヘッドを生成しない。

本発明の実施形態は、自身の優先順位に影響を与える手段を含む要求ピアを提供する。悪意のあるピアが他のピアに誤った情報を伝える（すなわち、実際よりも高い緊急度を示すように緊急度指標を改竄する）ことによってより高い優先順位を取得できるため、これはＰ２Ｐネットワークにおいて一般的な例ではなく、且つ全てのピアが高い優先順位を示す場合、結果として優先順位がなくなることは明らかである。しかし、上述した図１のＶｏＤの例等の多くの例において、不要な部分のみがより高速にダウンロードされるため、ユーザは自身の優先順位に対してなりすましを行う。また、図１に関連して説明された例は管理されたメディア配信サービスを考慮し、クライアントアプリケーション３、４はオペレータの制御下にある（ノード１は、例えば高信頼セットトップボックスである）。

緊急度指標に含まれた情報は、ネットワークにおいてサービングピア以外の第三者にとって関心のあるものであってもよい。運用及び保守（Ｏ＆Ｍ）システム（図１におけるＯ＆Ｍシステム１０等）は、緊急度指標を通知される場合、ネットワークが輻輳する場合にネットワークの中断を回避するために、データを緊急に必要としない要求ピアがピースの要求を停止する（例えば、所定の期間）ことを要求してもよい。これは、本発明のある特定の実施形態に係るオプションの機能であり、クライアントアプリケーション３が所定の緊急度を下回るあるレベルの低い緊急度に到達する時、例えばビデオの次の５分間のデータがバッファリングされる時をＯ＆Ｍシステムに通知するようにクライアントアプリケーション３を変更すること等により実現されてもよい。Ｏ＆Ｍシステムは、関連付けられたピアの緊急度指標を含むメッセージにより通知されてもよい。

図５は、本発明の一実施形態に係る方法の一実施形態を示すフローチャートである。図５の方法は、Ｐ２Ｐネットワークのサービングピアとして動作するクライアントアプリケーションを含むネットワークノードにおいて実行される。ステップ５１において、データコンテンツに対する１つ又は複数の要求は、Ｐ２Ｐネットワークにおいて多数の要求ピアから受信される。例えばこれらの要求は、上述したような関心メッセージ３５ａ又は要求メッセージ３８ａであってもよく、要求ピアと関連付けられた緊急度指標を含んでもよい。緊急度指標は、緊急度の観点からデータコンテンツに対する要求ピアの必要性を示している。ステップ５２において、緊急度指標は要求から抽出される。次に、ステップ５３において、優先順位機構は、対応するピアを判定するために使用される緊急度指標に適用される。上述したように、例えばこのステップは、バッファ空き量に従って要求ピアをソートすることと、バッファリングされたデータの量が最も少ない３つのピアを選択することとを含んでもよい。ステップ５４において、データコンテンツは、ステップ５３において選択したこれらのピアに配信される。

図６は、本発明の別の実施形態に係る方法の一実施形態を示すフローチャートである。図６の方法は、Ｐ２Ｐネットワークの要求ピアとして動作しているクライアントアプリケーションを含むネットワークノードにおいて実行される。ステップ６１において、サービングピアからデータコンテンツを要求する前に、データの緊急度が判定され且つ緊急度指標に変換される。例えばこのステップは、ビデオバッファにおいてバッファリングされたデータの量を判定すること又は使用可能なデータの残りの再生時間を推定することを含む。オプションのステップ６２において、緊急度がある所定の緊急度ｘを下回るか否かが判定されてもよく、下回る場合、オプションのステップ６３において、上述したように緊急度がＯ＆Ｍシステムに報告されてもよい。その後、ステップ６４において、データコンテンツに対する要求が作成され、緊急度指標は要求に含まれる。例えば要求は、関心メッセージ３５ａ又は要求メッセージ３８ａであってもよい。ステップ６５において、要求はサービングピアに送出される。

図１のクライアントアプリケーション３等、殆どのクライアントアプリケーションがサービングピア及び要求ピアの双方として動作するように構成されるため、図５の方法及び図６の方法は、同一のノードにおいて同時に実行されることが可能である。

本発明の実施形態を説明することにより、本発明を上述した。しかし、当業者により理解されるように、可能である多くの変更例がある。本発明の実施形態に係る上述の方法の実現例は、Ｐ２Ｐネットワークで使用される従来技術のネットワークノードを何らか適応することを必要とする。そのような適応は、一般に、図１のクライアントアプリケーション３又は４等のクライアントアプリケーションを適応することのみを必要とする。ファームウェア、ハードウェア又はそれらの組合せにおける実現例が更に可能であるが、新しいソフトウェアを利用してクライアントアプリケーションを適応することを選択するのが普通である。更に、図６のオプションのステップ６２及び６３の実現例は、Ｏ＆Ｍシステムを適応して、ピアからのメッセージから緊急度指標を抽出及び解釈し、且つネットワーク管理を判断するために緊急度指標を使用することを示す。Ｏ＆Ｍシステムを適応することは、ソフトウェア更新のみを含むのが好ましい。

図１は、本発明を実現するのが有益となる可能性のある例を示す。しかし、当然、本発明の実施形態が使用されてもよい他の多くの例がある。データコンテンツの文字が、データコンテンツの種々のピースがダウンロードされる順序が重要であるようなデータコンテンツのＰ２Ｐ配信の例において、本発明の一実施形態に従って優先順位機構を実現するのが有利である場合が多い。そのような例は、例えばオーディオコンテンツ又はビデオコンテンツを配信するためのライブストリーミングサービス、ＶｏＤサービス及びいくつかの例においてはゲーミング又はソフトウェアの更新に関連したダウンロードである。緊急度指標として使用される情報の種類は、実際の応用例に依存する。また、緊急度の順序で対応されるピアに従って上述した優先順位機構をしっぺ返し手法と組み合わせることが可能である。緊急度指標により示されたような緊急度は、選択されたピアがソートされる第１基準及びしっぺ返し手法の第２基準又はその逆であってもよい。それにより、複数の要求ピアが同一の緊急度を示している場合、サービングピアは、過去に最も多くのデータをサービングピアにアップロードしたデータを緊急に必要とする要求ピアに対応することを選択してもよい。

上記の説明から、説明された本発明の種々の実施形態を実現するためにどのようなソフトウェア、ファームウェア及び／又はハードウェアの変形例が必要であるかは、当業者には理解されるだろう。

図面及び明細書において、本発明の一般的に好適な実施形態が開示されており、特定の用語が採用されるが、それらは限定するためではなく一般的且つ記述的な意味でのみ使用され、本発明の範囲は以下の請求の範囲において説明される。

Claims (24)

1. データコンテンツを共有するピアツーピアネットワーク（５）のサービングピア（３２）として動作するクライアントアプリケーション（３、４）を含むネットワークノード（１、２）における方法であって、
   多数の要求ピア（３１）からデータコンテンツに対する少なくとも１つの要求（３５、３８）を受信するステップ（５１）と、
   前記要求されたデータコンテンツを前記多数の要求ピアに配信するステップ（５４）とを有し、
   緊急度に関して前記データコンテンツに対する前記要求ピアの必要性を示す緊急度指標（４１）を前記少なくとも１つの要求から抽出するステップ（５２）と、
   対応する前記多数の要求ピアを判定するために前記緊急度指標を使用する優先順位機構（３７ａ）を前記要求されたデータコンテンツの前記配信に適用するステップ（５３）とを有することを特徴とする方法。
2. 前記緊急度指標（４１）は、前記要求ピアにおいて再生のために使用可能なデータをバッファリングするバッファ（２０）におけるデータコンテンツのバッファ量を示すことを特徴とする請求項１に記載の方法。
3. 前記優先順位機構（３７ａ）は、最も少ないバッファリングされたデータの量を示す緊急度指標（４１）を含む要求ピア（３１）に前記要求されたデータコンテンツを配信することを特徴とする請求項２に記載の方法。
4. 前記少なくとも１つの要求は、前記要求ピアが前記データコンテンツをダウンロードすることに関心があることを示す関心メッセージ（３５ａ）又は前記データコンテンツの特定のピースを前記要求ピアにダウンロードするための要求を示す要求メッセージ（３８ａ）であることを特徴とする請求項１乃至３のいずれか１項に記載の方法。
5. 前記優先順位機構は、
   前記サービングピアからコンテンツをダウンロードすることに関心のある要求ピアをチェックするステップと、
   前記関心ピアを報告された緊急度指標によりソートするステップと、
   データに対して最も高い緊急度を示す緊急度指標を有する多数の関心ピアを選択するステップと、
   チョークされる選択された関心ピアをアンチョークするステップ（３６）と、
   選択されなかったあらゆるアンチョークされた関心ピアをチョークするステップと
   を周期的に実行するアンチョーク機構（３７ａ）に適用されることを特徴とする請求項１乃至４のいずれか１項に記載の方法。
6. データコンテンツを共有するピアツーピアネットワーク（５）の要求ピア（３１）として動作するクライアントアプリケーション（３）を含むネットワークノード（１）における方法であって、データコンテンツに対する要求（３５、３８）をサービングピア（３２）に送出するステップを有し、
   緊急度に関して前記データコンテンツに対する前記要求ピアの必要性を示す緊急度指標を判定するステップ（６１）と、
   前記要求に前記緊急度指標を含めるステップ（６４）と
   を更に有することを特徴とする方法。
7. 前記緊急度指標（４１）は、前記要求ピアにおいて再生のために使用可能なデータをバッファリングするバッファ（２０）におけるデータコンテンツのバッファ量を示すことを特徴とする請求項６に記載の方法。
8. 前記要求は、前記要求ピア（３１）が前記サービングピアから前記データコンテンツをダウンロードすることに関心があることを示す関心メッセージ（３５ａ）又は前記サービングピアから前記データコンテンツの特定のピースをダウンロードするための要求を示す要求メッセージ（３８ａ）である請求項６又は７に記載の方法。
9. メッセージにおける前記緊急度指標を運用及び保守システム（１０）に送出するステップ（６３）を更に含むことを特徴とする請求項６乃至８のいずれか１項に記載の方法。
10. 前記緊急度指標を前記運用及び保守システム（１０）に送出するステップ（６３）は、前記緊急度指標が所定の緊急度を下回る低い緊急度を示すと判定される場合に実行されることを特徴とする請求項９に記載の方法。
11. 前記データコンテンツは、ビデオオンデマンドサービス又はストリーミングサービスに関連したビデオコンテンツ、あるいはオーディオストリーミングサービスに関連したオーディオコンテンツであることを特徴とする請求項１乃至１０のいずれか１項に記載の方法。
12. データコンテンツを共有するピアツーピアネットワーク（５）のサービングピア（３２）として動作するように構成されたクライアントアプリケーション（３、４）を含むネットワークノード（１、２）であって、
    多数の要求ピア（３１）からデータコンテンツに対する少なくとも１つの要求（３５、３８）を受信し、
    前記要求されたデータコンテンツを前記多数の要求ピアに配信するように構成され、
    前記クライアントアプリケーション（３、４）は、緊急度に関して前記データコンテンツに対する前記要求ピアの必要性を示す緊急度指標（４１）を前記少なくとも１つの要求から抽出するように構成され、
    前記クライアントアプリケーションは、対応する前記多数の要求ピアを判定するために前記緊急度指標を使用することにより、前記要求されたデータコンテンツの前記配信を制御する優先順位機構（３７ａ）を含む
    ことを特徴とするネットワークノード。
13. 前記緊急度指標（４１）は、前記要求ピアにおいて再生のために使用可能なデータをバッファリングするバッファ（２０）におけるデータコンテンツのバッファ量を示すことを特徴とする請求項１２に記載のネットワークノード。
14. 前記優先順位機構（３７ａ）は、最も少ないバッファリングされたデータの量を示す緊急度指標（４１）を含む要求ピア（３１）に前記要求されたデータコンテンツを配信するように構成されることを特徴とする請求項１３に記載のネットワークノード。
15. 前記少なくとも１つの要求は、前記要求ピアが前記データコンテンツをダウンロードすることに関心があることを示す関心メッセージ（３５ａ）又は前記データコンテンツの特定のピースを前記要求ピアにダウンロードするための要求を示す要求メッセージ（３８ａ）であることを特徴とする請求項１２乃至１４のいずれか１項に記載のネットワークノード。
16. 前記優先順位機構は、周期的に
    前記サービングピアからコンテンツをダウンロードすることに関心のある要求ピアをチェックし、
    前記関心ピアを、報告された緊急度指標によりソートし、
    データに対して最も高い緊急度を示す緊急度指標を有する多数の関心ピアを選択し、
    チョークされる選択された関心ピアをアンチョークし、
    選択されなかったあらゆるアンチョークされた関心ピアをチョークする
    アンチョーク機構（３７ａ）を含む
    ことを特徴とする請求項１２乃至１５のいずれか１項に記載のネットワークノード。
17. データコンテンツを共有するピアツーピアネットワーク（５）の要求ピア（３１）として動作するように構成されたクライアントアプリケーション（３）を含むネットワークノード（１）であり、前記ネットワークノードは、データコンテンツに対する要求（３５、３８）をサービングピア（３２）に送出するように構成され、
    前記クライアントアプリケーションは、緊急度に関して前記データコンテンツに対する前記要求ピアの必要性を示す緊急度指標（４１）を判定するように更に構成され、
    前記クライアントアプリケーションは、前記緊急度指標を前記要求に含むように構成されることを特徴とするネットワークノード。
18. 前記クライアントアプリケーションは、前記要求ピアにおいて再生のために使用可能なデータをバッファリングするバッファ（２０）を含み、前記緊急度指標（４１）は、前記バッファにおけるデータコンテンツのバッファ量を示すことを特徴とする請求項１７に記載のネットワークノード。
19. 前記要求は、前記要求ピアが前記サービングピアから前記データコンテンツをダウンロードすることに関心があることを示す関心メッセージ（３５）又は前記サービングピアから前記データコンテンツの特定のピースをダウンロードするための要求を示す要求メッセージ（３８）であることを特徴とする請求項１７又は１８に記載のネットワークノード。
20. 前記クライアントアプリケーションは、メッセージにおける前記緊急度指標を運用及び保守システム（１０）に送出するように更に構成されることを特徴とする請求項１７乃至１８のいずれか１項に記載のネットワークノード。
21. 前記クライアントアプリケーションは、前記緊急度指標が所定の緊急度を下回る低い緊急度を示すと判定される場合に前記緊急度指標を前記運用及び保守システムに送出するように構成されることを特徴とする請求項２０に記載のネットワークノード。
22. 前記データコンテンツは、ビデオオンデマンドサービス又はストリーミングサービスに関連したビデオコンテンツ、あるいはオーディオストリーミングサービスに関連したオーディオコンテンツであることを特徴とする請求項１０乃至１９のいずれか１項に記載のネットワークノード。
23. データコンテンツを共有するピアツーピアネットワーク（５）を管理する運用及び保守システム（１０）であって、
    前記ピアツーピアネットワークにおいて少なくとも１つのメッセージを前記ピアツーピアネットワークにおいてサービングピア（３２）からデータコンテンツを要求している要求ピア（３１）から受信し、
    緊急度の関して前記データコンテンツに対する前記要求ピアの必要性を示す緊急度指標（４１）を前記少なくとも１つのメッセージから抽出し、
    前記ピアツーピアネットワークの管理に関して判断するために前記緊急度指標使用するように構成される運用及び保守システム。
24. 前記運用及び保守システム（１０）は、所定の期間データコンテンツの要求を停止する低い緊急度を報告した要求ピア（３１）に要求を送出するように更に構成されることを特徴とする請求項２３に記載の運用及び保守システム（１０）。

Images