JP5020316B2 - パフォーマンスを意識したピアツーピアビデオオンデマンドの許可制御 - Google Patents

Description

本発明は、ピアツーピアネットワーキングに関し、より詳細には、サーバ側でのビデオオンデマンドサービスの要求の許可制御に関する。

ストリーミングサービスを提供するためにクライアントサーバサービスモデルが使用されている。クライアントは、サーバに要求を送出し、サーバは、クライアントの要求に給仕するためにサーバが十分なリソースを有し、且つサーバとクライアントとの間のパスに添って十分な帯域幅が存在する場合に、クライアントにコンテンツをストリーミングする。

サーバでの制限された計算及び記憶リソースのため、及びサーバとクライアントを接続するネットワークにおける制限された帯域幅のため、スケーラビリティは、クライアント−サーバストリーミングサービスによる問題である。近年、ピアツーピア技術は、ストリーミングサービスに導入されている。ピアは、クライアントとサーバの能力により実現される。ピアツーピアネットワークは、サーバに課される負荷を軽減し、コンテンツをアクティブにキャッシュし、他のピアを給仕することでネットワークにわたり帯域幅の要件を分散する。研究では、ピアツーピア技術はシステムのスケーラビリティを大いに改善し、システムが非常に多くのユーザにサービスするのを可能にすることが示される。

ピアツーピアネットワーキングを使用したストリーミングメディアサービスで与えられるスケーラビリティの問題に対処するために著しい試みがなされている。これらの試みは、特にピアツーピア ライブストリーミング及びピアツーピアストアドビデオストリーミング又はビデオオンデマンドといった２つのカテゴリに分類される。両者は、多数のユーザを支援することに努め、ユーザに良好な視聴品質を提供する一方で、異なる技術的な課題に面している。ピアツーピアライブストリーミングでは、システムのスケーラビリティを犠牲にすることなしにスタートアップ遅延を最小にすることが課題である。ピアツーピアビデオオンデマンドサービスでは、非同期のユーザが共有するのを可能にすることが課題である。

ピアツーピアストリーミングスキームは、異なるデータ伝達技術により彼ら自身を区別する。２つのデータ伝達方法が調査されており、特にオーバレイに基づいたアプローチ及びデータにより駆動されるアプローチである。オーバレイに基づいたアプローチでは、ピアは、ピアの間で親子の関係が形成されるメッシュ又はツリー構造を形成する。子のピアは、その親からデータを受ける。対照的に、データにより駆動されるアプローチにおけるピアは、固定された親子の関係を有さない。ピアは、失われているデータを探し、入手可能であれば何処であっても失われているデータを検索する。オーバレイに基づいたアプローチが早期のピアツーピアの試みで広く使用されている一方で、データにより駆動されるアプローチは、振動かつ非対称な帯域幅の問題に効果的に対処するため、より普及している。

大部分の従来技術は、良好なスケーラビリティを示し、従来のクライアント−サーバサービスモデルに比較して非常に多数のユーザをサポートする一方で、従来技術は事実上最善の努力であり、システムパフォーマンスの要件のサポートは、十分に調査されていない。サーバでの制限された帯域幅のため、クライアント側で知覚されるビデオ品質は、サーバがクライアントを過剰に許可する場合に苦しむ。したがって、期待されるサービス品質（Ｑｏｓ）を提供するため、許可制御が必要とされる。

関連される応用は、パフォーマンスを意識したピアツーピアビデオオンデマンドサービスに向けられる。この応用は、ピアツーピアダウンロードを従来のクライアント−サーバビデオオンデマンドサービスモデルに組み込む。ピアツーピアダウンロードは、主要なデータ転送の負荷を搬送し、したがって、サーバに化される負荷を低減する。サーバは、パフォーマンスの要件に合致するように、そのリソースの大部分を緊急のデータを供給することに当てる。クライアントのエンドで知覚されるパフォーマンスが改善される。ピアツーピアダウンロードアルゴリズムは、パフォーマンスの要件を念頭において設計される。

ビデオオンデマンドサービスにより、ユーザは、ユーザが望むときは何時でもネットワークを通してビデオコンテンツを選択及び視聴するのを可能にする。関連される応用は、ビデオオンデマンド設定におけるコンテンツの共有を可能にするセグメント化されたピアツーピアビデオシェアリングモデルを含む。パフォーマンスの問題は、パフォーマンスを意識したピアツーピアデータダウンロードアルゴリズム、及び従来のクライアント−サーバサービスモデルにより提供されるパフォーマンスに類似したパフォーマンスであって、更に多くのユーザをサポートするパフォーマンスを集合的に実現するサーバを使用した相補的なストリーミングを組み込むことで対処される。

本発明は、サーバ側で許可制御を実行することでクライアントの知覚されるビデオ品質を更に改善することに向けられる。サーバは、多数のタスク／サービスを有し、ストリーミングサービスを含めて、リーディングサブクリップを実行し、相補的なストリーミングを実行して、ピアツーピアネットワークにおいてクライアント／ユーザにコンテンツをアップロードする。サーバでの制限された帯域幅のリソース、様々なサービスを提供し様々なタスクを実行するサーバの責任のため、クライアントの知覚されるビデオ品質がクライアントの期待に合致するように、許可制御を行なうことが重要である。

ピアツーピアビデオオンデマンドサービスの許可制御をサポートする本発明の方法及び装置は、パフォーマンスを意識したビデオオンデマンドサービスの環境におけるクライアントの知覚されるビデオ品質を改善するために設計される。本発明の方法及び装置は、要求がビデオオンデマンドシステムに許可されるかを判定するため、現在の帯域幅の使用及び帯域幅の使用履歴をモニタする。

ピアツーピアビデオオンデマンドシステムにおける許可制御を実行する方法及び装置が記載され、ビデオ再生装置からの新たな要求についてリーディングサブクリップのストリーミングをサポートするために十分な帯域幅が存在するかを判定し、既存の要求のためのサービスの品質を犠牲にすることなしに、要求を許可するために十分な帯域幅は存在するかを判定し、判定処理の両者がポジティブである場合に新たな要求の許可を受け入れ、判定処理の何れかがネガティブである場合に新たな要求の許可を拒否することを含む。また、ピアツーピアビデオオンデマンドシステムに於けるビデオ再生装置にコンテンツを供給する装置が開示され、許可制御ユニット及びデータエンジンコンポーネントを含む。
本発明は、添付図面と共に呼ばれたときに以下の詳細な説明から最良に理解される。図面は、図の同じ符号が類似のエレメントを表す以下の図を含む。

ビデオオンデマンドサービスのユーザは、所与の瞬間でビデオの異なる部分を見る。ユーザ間でコンテンツの共有を可能にし、ピアツーピアネットワークを通して伝達されるコンテンツの量を最大にするため、それぞれのユーザは、再生されたコンテンツの部分的なコピー及び／又は全体のコピーをキャッシュする記憶容量を有すると想定される。これは、クライアント／ユーザにより（及びクライアント／ユーザと同期して）使用されるビデオ再生装置の迅速に増加する記憶容量が与えられた場合に妥当な想定である。ビデオ再生装置は、限定されるものではないが、コンピュータ、ラップトップ、パーソナルデジタルアシスタント（ＰＤＡ）及びモバイル装置を含む、（記憶された又はライブの）ビデオを受信及び再生可能な何れかの装置である。ピアツーピアネットワークは、有線ネットワークに限定されず、無線又は有線ネットワーク、或いは有線及び無線接続を採用するハイブリッドネットワークである場合がある。

先の研究は、ネットワーク帯域幅及び記憶帯域幅がストリーミングサーバについて潜在的なリソースのボトルネックであることが示される。本発明のため、記憶帯域幅がボトルネックではないように、サーバが良好に提供されることが想定される。以下の説明では、サーバ側のネットワーク帯域幅は、制限される、すなわちボトルネックであると想定される。

パフォーマンスを意識したピアツーピアストリーミングサービス環境におけるサーバは、３つのタイプのサービスの役割を担う。（i）クライアントが即座に再生するのを可能にするため、リーディングサブクリップをストリーミングする。（ii）サーバによりピアツーピアネットワークを通してクライアントにその後／後続するサブクリップのビデオコンテンツをアップロードする。（iii）サブクリップにおいて失われたデータが存在し、このサブクリップのデッドラインが到達したときに、クライアントへのサブクリップの相補的なストリーミングをサービスすること。

図１は、サーバからの視点からの、パフォーマンスを意識したピアツーピア ビデオオンデマンド ストリーミングサービス環境における帯域幅の使用を示す。ここでＢＷは、全体のサーバの帯域幅を示すために使用され、ＢＷ_streamingは、リーディングサブクリップをストリーミングするために使用される帯域幅を示すために使用され、ＢＷ_{comp-streaming}は、相補的なストリーミングのために使用される帯域幅を示すために使用され、ＢＷ_p2puproadingは、サーバからピアツーピアネットワークにおけるクライアント／ユーザ／ビデオ再生装置にコンテンツをアップロードするために使用される帯域幅を示すために使用される。図１からわかるように、ＢＷ＝ＢＷ_streaming＋ＢＷ_{comp-streaming}＋ＢＷ_p2puploadingである。重要なシンボルの定義は、以下の表１に列挙される。

図２は、ビデオオンデマンドの単一の要求のサービスにおけるサーバ帯域幅の使用の例である。ビデオは、４つのサブクリップから構成され、時間Ｔ₀で開始する。第一のサブクリップのコンテンツがストリーミング（Streaming）される。それぞれの後続のサブクリップのデッドライン、すなわち時間Ｔ₁，Ｔ₂及びＴ₃で、失われたデータを埋めるために再生レートで相補的なストリーミング（Comp-streaming）が始動される。サーバによりピアツーピア（P2P）ネットワークにおけるクライアント／ユーザビデオ再生装置にコンテンツをアップロードすることは、開始Ｔ₀から始まり、最後のサブクリップＴ₃のデッドラインで終了する。すなわち、最初の（リーディング）サブクリップは、クライアントにストリーミングされる。サーバによりクライアント／ユーザ／ビデオ再生装置にその後／後続のサブクリップ（サブクリップ２〜４）をアップロードすることは、Ｔ₀から同様に開始される。Ｔ₁で、サブクリップ２について失われたデータが存在する場合、サーバは、失われたデータの相補的なストリーミングを開始する。Ｔ₂で、サブクリップ３について失われたデータが存在する場合、サーバは、失われたデータの相補的なストリーミングを開始する。最後に、Ｔ₃で、サブクリップ４について失われたデータが存在する場合、サーバは、失われたデータの相補的なストリーミングを開始する。

はじめに、異なる帯域幅の使用の特性が説明される。次いで、これら帯域幅の使用の平均及び分散を推定する方法が記載される。最後に、本発明の許可制御スキームが与えられる。

リーディングサブクリップをストリーミングするために必要とされる帯域幅は、以下により与えられる定数である。

ここでｒはビデオ再生レートであり、Ｎ_streamingはストリーミングサービスを現在受けているユーザ数である。

相補的なストリーミングをサポートするために必要とされる帯域幅は、ランダムな変数である。サブクリップがそのデッドラインに到達したとき、クライアント／ユーザ／ビデオ再生装置は、データの一部が失われた場合に相補的なストリーミング要求を発生する。サーバは、十分な利用可能な帯域幅が存在する場合に、失われたデータの相補的なストリーミングを実行する。失われたデータは、再生レートでクライアントの送信／送出される。これにより、全ての失われたデータは、再生時間の前に利用可能となることが保証される。相補的なストリーミングが不十分なサーバの帯域幅のために不可能な場合、サブクリップは、失われたデータで再生され、ユーザの視聴品質は低下される。図２に示されるように、相補的なストリーミングの帯域幅の使用は、Bernoulliランダム変数により近似することができる。相補的なストリーミングレートは、ｒ又はゼロのいずれかである。

許可コントローラは、それぞれのサブクリップの相補的なストリーミングにより送信される必要があるデータ量を追跡する。この量は、Ｓ_{comp-streaming}により示される。このサブクリップの平均の相補的なストリーミングデータレートは、Ｓ_{comp-streaming}／Ｔであり、Ｔはサブクリップの長さである。許可コントローラは、平均の相補的なストリーミングの帯域幅の情報
［外１］

を維持する。

［外２］

の値は、新たな平均の相補的なストリーミングレートが計算されたときは何時でも更新される。特に、以下に示される。

重みαは、平均の相補的なストリーミングの帯域幅の使用が現在の値にどの位迅速に追いつくかを決定する。実験は、０．９５前後の値が良好な性能の結果を与えることを示す。

［外３］

の分散を推定するため、相補的なストリーミングの帯域幅の使用を近似するBernoulli分散が使用される。

［外４］

の分散は、以下のように計算される。

また、サーバは、ピアツーピアネットワークを通してユーザに送信されたデータ量を追跡する。平均のサーバのピアツーピアのダウンロードの帯域幅
［外５］

は、サブクリップのデッドラインで更新される。それぞれのサブクリップについてアップロードされるデータ量は、Ｓ_p2puploadingとして示される。平均のピアツーピアアップロードレートは、Ｓ_p2puploading／Ｔである。１つのサブクリップの長さの間にピアツーピアネットワークを使用してユーザに送信されるデータの量は、以下のように示される。

本発明の許可制御プロセスは、ピアツーピアネットワークにおけるサーバによりクライアント／ユーザ／ビデオ再生装置にコンテンツをアップロードするために使用される帯域幅の分散を無視する。

図３に示されているように、許可制御プロセスは、２つの主要なステップから構成される。第二のステップでは、許可コントローラは、サーバが全てのクライアントに対する良好なＱｏＳに新たなクライアントの要求の許可を与えることができるかを判定する。

ステップ１（３０５）。リーディングサブクリップのストリーミングのために十分な帯域幅が存在するかを判定する。

新たなクライアントの要求の到達に応じて、サーバは、クライアントを許可するため、リーディングサブクリップのストリーミングを支援するために十分な帯域幅を有する必要がある。さもなければ、クライアントは、再生を即座に開始することができず、要求は拒否される必要がある。したがって、許可のための条件は、以下の通りである。

ピアツーピアネットワークにおけるサーバによりクライアント／ユーザ／ビデオ再生装置にコンテンツをアップロードするために使用される帯域幅は、ストリーミング及び相補的ストリーミングの両者について必要とされる帯域幅に比較して低い優先度を有する。ピアツーピアネットワークは、サーバと同様に多数のクライアントを含む。サーバからの寄与なしに、クライアントは、他のピアからのデータをダウンロードすることができる。ここで、ピアツーピアネットワークにおけるサーバによりクライアント／ユーザ／ビデオ再生装置にコンテンツをアップロードするために必要とされる帯域幅の影響は、許可制御プロセスのステップで無視される。しかし、ピアツーピアネットワークにおけるサーバによりクライアント／ユーザ／ビデオ再生装置にコンテンツをアップロードする帯域幅は、クライアントの知覚された品質が良好であること、及びデータがその再生のデッドラインを失った可能性が低いことを保証するため、第二のステップで考慮される。

ステップ２（３１０）。クライアントの知覚されたＱｏＳは新たなクライアントの要求の許可により良好であるかを判定する。

第二のステップでは、収集された統計量が評価され、新たなクライアントの要求がクライアントの視聴の品質を低下させることなしに許可することができるかが判定される。特に、新たなクライアントの要求を許可することができるかを判定するため、以下の式が使用される。

ここでＮ_{comp-streaming}は、相補的なストリーミングサービスを必要とするユーザ数であり、σは、全体の相補的なストリーミング帯域幅の標準偏差であり、βは、標準偏差のファクタである。

式（６）の左手側に３つの項が存在する。ＢＷ_streaming＋ｒの値は、新たなクライアントが許可されると仮定すれば、リーディングサブクリップのストリーミングをサポートするために必要とされる帯域幅の量を示す。第二の項では、Ｎ_{comp-streaming}は、相補的なストリーミングを要求するユーザ数である。リーディングサブクリップストリームを現在受信しているユーザを除く全てのユーザは相補的なストリーミングを要求する場合があるので、Ｎ_{comp-streaming}＝Ｎ−Ｎ_streamingである。

集合された相補的なストリーミングの帯域幅の使用は、Ｎ_{comp-streaming}のBernoulliランダム変数の合計である。Central Limit Theoremによれば、ランダム変数の合計は、正規分布により近似することができ、その標準偏差は、以下の式（７）により支配される。許可制御プロセス（式（６）参照）の第二のステップでは、βは３に選択される。標準的な正規分布について、サンプルが３回を超えてその平均から逸脱する確率は、０．００５以下である。

したがって、高い確率により、ユーザの相補的なストリーミングの要求を満足させることができる。最終的に、第三の項は、ピアツーピアアップロードサービスのために要求される全体の帯域幅である。

第二のステップでは、許可コントローラは、必要とされる帯域幅が、高い確率で利用可能な帯域幅よりも狭いことを保証する。したがって、ユーザの視聴の品質は、新たなクライアントの要求の許可により低下しない。

（３０５での）ステップ１又は（３１０での）ステップ２の何れかが失敗した場合、ステップ３２０で要求が拒否される（許可されない）。（３０５での）ステップ１及び（３１０での）ステップ２の両者が成功／パスした場合、ステップ３１５で要求が許可される。

図４は、本発明の許可制御コンポーネントをもつピアツーピアストリーミングサーバのアーキテクチャの概念図である。データエンジンコンポーネントは、ストリーミングエンジン及びピアツーピアアップローダを有する。ストリーミングエンジンは、ストリーミングエンジンを担当し、ピアツーピアエンジンは、ピアツーピアアップロードサービスを担当する。新たなクライアント要求は、許可コントローラにはじめに提供される（ステップ１）。図１に例示される許可コントローラの結果に基づいて、サーバは、クライアントに判定をリターンする（ステップ２）。新たなクライアントの要求が許可された場合、許可制御ユニットは、データエンジンコンポーネントにこの判定を通知する（ステップ３）。データエンジンコンポーネントは、リーディングサブクリップをストリーミングし（ステップ４）、ピアツーピアダウンローダを通して後続するサブクリップのデータをアップロードすることで（ステップ５）、この要求に対するサービスを提供し始める。

本発明は、ハードウェア、ソフトウェア、ファームウェア、特定用途向けプロセッサ、又はその組み合わせから成る様々な形式で実現される場合がある。好ましくは、本発明は、ハードウェアとソフトウェアの組み合わせとして実現される。さらに、ソフトウェアは、プログラムストレージ装置で実施されるアプリケーションプログラムとして好適に実現される。アプリケーションプログラムは、任意の適切なアーキテクチャを有するコンピュータにアップロードされ、該コンピュータにより実行される場合がある。好ましくは、コンピュータは、１以上の中央処理装置（ＣＰＵ）、ランダムアクセスメモリ（ＲＡＭ）、及び入力／出力（Ｉ／Ｏ）インタフェースのようなハードウェアを有するコンピュータプラットフォームで実現される。また、コンピュータプラットフォームは、オペレーティングシステム及びマイクロ命令コードを含む。本実施の形態で記載された様々なプロセス及び機能は、マイクロ命令コードの一部、又はオペレーティングシステムを介して実行されるアプリケーションプログラムの一部（或いはその組み合わせ）である場合がある。さらに、様々な他の周辺装置は、更なるデータストレージ装置及びプリンティング装置のようなコンピュータプラットフォームに接続される。

添付図面に示されるシステムコンポーネント及び方法ステップのうちの一部はソフトウェアで実現されることが好ましく、システムコンポーネント（又はプロセスステップ）間の実際のコネクションは、本発明がプログラムされるやり方に依存して異なる場合がある。本実施の形態での教示が与えられると、当業者は、本発明のこれらの実現又はコンフィギュレーション、及び類似の実現又はコンフィギュレーションを考案することができる。

サーバの視点からのパフォーマンスを意識したピアツーピアビデオオンデマンドサービス環境における帯域幅の使用を示す図である。 ビデオオンデマンドの単一の要求のサービスにおける帯域幅の使用例を示す図である。 サーバ側からの許可制御プロセスのフローチャートである。 パフォーマンスを意識したピアツーピアストリーミングサーバの許可制御プロセスのアーキテクチャの概念図である。

Claims (20)

1. ピアツーピアコンテンツオンデマンドシステムで許可制御を実行する方法であって、
   再生装置からの新たな要求についてリーディングサブクリップのストリーミングをサポートするために十分な帯域幅があるかを判定するステップと、
   前記新たな要求が許可された場合の前記リーディングサブクリップのストリーミングをサポートするために必要とされる帯域幅の量と、既存の要求を満たす、失われたデータを埋めるための相補的なストリーミングをサポートするために要求される帯域幅の量と、ピアツーピアのアップロードをサポートするために要求される帯域幅の量とを計算することで、前記既存の要求についてサービス品質を犠牲にすることなしに、前記新たな要求を許可するために十分な帯域幅があるかを判定するステップと、前記相補的なストリーミングをサポートするために要求される帯域幅の量は、平均の相補的なストリーミングの帯域幅に相補的なストリーミングの帯域幅の標準偏差を加えて得られる帯域幅に基づいて計算され、
   前記第一及び第二の判定ステップに基づいて前記新たな要求の許可を判定するステップと、
   を含むことを特徴とする方法。
2. 前記第一の判定ステップは、
   前記既存の要求のリーディングサブクリップのストリーミングのために必要とされる帯域幅と、前記既存の要求について相補的なストリーミングのために必要とされる帯域幅との合計を全体の帯域幅から減算して結果を得るステップと、
   前記結果を再生レートに比較するステップと、
   前記結果が前記再生レートよりも大きいか、前記再生レートに等しい場合に十分な帯域幅があることの指示を送出するステップと、
   前記結果が前記再生レートよりも小さい場合に十分な帯域幅がないことの指示を送出するステップと、
   を更に含む請求項１記載の方法。
3. 前記既存の要求のリーディングサブクリップのストリーミングのために必要とされる前記帯域幅は、前記再生レートに、サーバからストリーミングされたサブクリップを受信する既存の要求の数を乗じたものに等しい、
   請求項２記載の方法。
4. 前記第二の判定ステップは、
   平均の相補的なストリーミングの帯域幅を計算するステップと、
   前記平均の相補的なストリーミングの帯域幅の標準偏差を計算するステップと、
   平均のサーバのピアツーピアアップロードの帯域幅を計算するステップと、
   前記新たな要求が許可された場合の前記リーディングサブクリップのストリーミングをサポートするために必要とされる帯域幅の量である、第一の量を計算するステップと、
   前記既存の要求を満たす、失われたデータを埋めるための相補的なストリーミングをサポートするために要求される帯域幅の量である、第二の量を計算するステップと、前記第二の量は、相補的なストリーミングを要求する既存のユーザの数と、計算された平均の相補的なストリーミングの帯域幅に、計算された標準偏差と該標準偏差の乗算係数との積を加えた結果との積であり、
   前記既存の要求を満たす、失われたデータを埋めるための相補的なストリーミングをサポートするために要求される帯域幅の量である、第三の量を計算するステップと、前記第三の量は、前記ピアツーピアコンテンツオンデマンドシステムにおける現在のユーザの総数と、計算された平均のサーバのピアツーピアアップロードの帯域幅との積であり、
   前記第一の量、前記第二の量及び前記第三の量を合計して第四の量を得るステップと、
   前記第四の量を全体の帯域幅に比較するステップと、
   を更に有する請求項１記載の方法。
5. 前記平均の相補的なストリーミングの帯域幅は、前に計算された平均の相補的なストリーミングの帯域幅に第一の重みを乗じたものと、平均の相補的なストリーミングレートに第二の重みを乗じたものとの合計に等しく、前記平均の相補的なストリーミングレートは、サブクリップの長さで除算されるそれぞれのサブクリップの相補的なストリーミングにより送信される必要があるデータ量である、
   請求項４記載の方法。
6. 前記第二の重みは、１から前記第一の重みを減算したものである、
   請求項５記載の方法。
7. 前記平均のサーバのピアツーピアアップロードの帯域幅は、前に計算された平均のサーバのピアツーピアの帯域幅に第一の重みを乗じたものと、平均のピアツーピアサーバのアップロードレートに第二の重みを乗じたものとの合計に等しい、前記平均のサーバのピアツーピアアップロードのレートは、サブクリップの長さにより除算されるそれぞれのサブクリップについてアップロードされる必要があるデータ量である、
   請求項４記載の方法。
8. 前記第二の重みは、１から前記第一の重みを減算したものである、
   請求項７記載の方法。
9. 前記標準偏差は、サーバからのサブクリップの相補的なストリーミングサービスの既存の要求の数で除算した前記平均の相補的なストリーミングの帯域幅の分散の平方根である、
   請求項４記載の方法。
10. 前記平均の相補的なストリーミングの帯域幅の前記分散は、前記平均の相補的なストリーミングの帯域幅に、１から前記平均の相補的なストリーミングの帯域幅を減算したものを乗算したものである、
    請求項９記載の方法。
11. 前記第一の量は、前記サーバからのリーディングサブクリップのストリーミングのために必要とされる前記帯域幅に、再生レートを乗算したものである、
    請求項４記載の方法。
12. 前記第二の量は、サーバからのサブクリップの相補的なストリーミングサービスについて既存の要求の数と、前記平均の相補的なストリーミングの帯域幅と標準偏差のファクタとの合計と、前記平均の相補的なストリーミングの帯域幅の前記標準偏差との積である、
    請求項４記載の方法。
13. 前記第三の量は、既存の要求の数と、前記平均のサーバのピアツーピアのアップロードの帯域幅との積である、
    請求項４記載の方法。
14. ピアツーピアコンテンツオンデマンドシステムで許可制御を実行する装置であって、
    再生装置からの新たな要求についてリーディングサブクリップのストリーミングをサポートするために十分な帯域幅があるかを判定する手段と、
    前記新たな要求が許可された場合の前記リーディングサブクリップのストリーミングをサポートするために必要とされる帯域幅の量と、既存の要求を満たす、失われたデータを埋めるための相補的なストリーミングをサポートするために要求される帯域幅の量と、ピアツーピアのアップロードをサポートするために要求される帯域幅の量とを計算することで、前記既存の要求についてサービス品質を犠牲にすることなしに、前記新たな要求を許可するために十分な帯域幅があるかを判定する手段と、前記相補的なストリーミングをサポートするために要求される帯域幅の量は、平均の相補的なストリーミングの帯域幅に相補的なストリーミングの帯域幅の標準偏差を加えて得られる帯域幅に基づいて計算され、
    前記第一及び第二の判定手段の結果に基づいて前記新たな要求の許可を判定する手段と、
    を含むことを特徴とする装置。
15. 前記第一の判定手段は、
    前記既存の要求のリーディングサブクリップのストリーミングのために必要とされる帯域幅と、前記既存の要求について相補的なストリーミングのために必要とされる帯域幅との合計を全体の帯域幅から減算して結果を得る手段と、
    前記結果を再生レートに比較する手段と、
    前記結果が前記再生レートよりも大きいか、前記再生レートに等しい場合に十分な帯域幅があることの指示を送出する手段と、
    前記結果が前記再生レートよりも小さい場合に十分な帯域幅がないことの指示を送出する手段と、
    を更に含む請求項１４記載の装置。
16. 前記既存の要求のリーディングサブクリップのストリーミングのために必要とされる前記帯域幅は、前記再生レートに、サーバからストリーミングされたサブクリップを受信する既存の要求の数を乗じた積に等しい、
    請求項１５記載の装置。
17. 前記第二の判定手段は、
    平均の相補的なストリーミングの帯域幅を計算する手段と、
    前記平均の相補的なストリーミングの帯域幅の標準偏差を計算する手段と、
    平均のサーバのピアツーピアアップロードの帯域幅を計算する手段と、
    前記新たな要求が許可された場合の前記リーディングサブクリップのストリーミングをサポートするために必要とされる帯域幅の量である、第一の量を計算する手段と、
    前記既存の要求を満たす、失われたデータを埋めるための相補的なストリーミングをサポートするために要求される帯域幅の量である、第二の量を計算する手段と、前記第二の量は、相補的なストリーミングを要求する既存のユーザの数と、計算された平均の相補的なストリーミングの帯域幅に、計算された標準偏差と該標準偏差の乗算係数との積を加えた結果との積であり、
    前記既存の要求を満たす、失われたデータを埋めるための相補的なストリーミングをサポートするために要求される帯域幅の量である、第三の量を計算する手段と、前記第三の量は、前記ピアツーピアコンテンツオンデマンドシステムにおける現在のユーザの総数と、計算された平均のサーバのピアツーピアアップロードの帯域幅との積であり、
    前記第一の量、前記第二の量及び前記第三の量を合計して第四の量を得る手段と、
    前記第四の量を全体の帯域幅に比較する手段と、
    を更に有する請求項１６記載の装置。
18. 当該装置は、許可制御ユニットである、
    請求項１４記載の装置。
19. ピアツーピアコンテンツオンデマンドシステムにおいて再生装置にコンテンツを供給する装置であって、
    許可制御ユニットと、
    データエンジンコンポーネントとを備え、
    前記許可制御ユニットは、
    再生装置からの新たな要求についてリーディングサブクリップのストリームをサポートするために十分な帯域幅があるかを判定し、
    前記新たな要求が許可された場合の前記リーディングサブクリップのストリーミングをサポートするために必要とされる帯域幅の量と、既存の要求を満たす、失われたデータを埋めるための相補的なストリーミングをサポートするために要求される帯域幅の量と、ピアツーピアのアップロードをサポートするために要求される帯域幅の量とを計算することで、前記既存の要求についてサービス品質を犠牲にすることなしに、前記要求を許可するために十分な帯域幅があるかを判定し、前記相補的なストリーミングをサポートするために要求される帯域幅の量は、平均の相補的なストリーミングの帯域幅に相補的なストリーミングの帯域幅の標準偏差を加えて得られる帯域幅に基づいて計算され、
    前記判定の両者がポジティブである場合に前記新たな要求の許可を受け、
    前記判定の何れかがネガティブである場合に前記新たな要求の許可を拒否し、
    前記再生装置へのコンテンツの前記新たな要求の許可及び拒否のうちの一方を示す判定を送出する、ことでコンテンツの新たな要求の許可制御を実行する、
    ことを特徴とする装置。
20. 前記コンテンツの前記新たな要求が許可された場合、前記データエンジンコンポーネントは、ストリーミングエンジンを介して前記再生装置にリーディングサブクリップをストリーミングし、ピアツーピアアップローダを介して後続するサブクリップのデータをアップロードすることで前記コンテンツの新たな要求に対するサービスを提供する、
    請求項１９記載の装置。

Images