(57)【特許請求の範囲】
【請求項１】
帯域幅制限通信ネットワーク内のネットワークリソース管理のためのコンテンツリソースブローカユニット（１００）であって、
−コンテンツの転送のため利用できる現在および将来のネットワーク容量に関する情報を取得するようになっているリソースユニット（１１０）と、
−要求側エンティティからコンテンツＣの転送のためのネットワークリソースに関する要求を受信するようになっている受信ユニット（１０２）と、
−所定の応答時間内の前記利用できるネットワーク容量が前記所定の応答時間が満了する前に前記コンテンツＣを転送するのに十分であるかどうかを判定するようになっている判定ユニット（１０４）と、
−前記所定の応答時間が満了する前に前記コンテンツＣを転送できるかもしれない場合、前記要求を許可するようになっている許可ユニット（１０６）と、
−前記利用できるネットワーク容量（５０２）を考慮して、前記所定の応答時間内での転送のため前記コンテンツＣをスケジュールに入れるようになっているスケジューリングユニット（３１２）と
を備えるコンテンツリソースブローカユニット。
【請求項２】
前記コンテンツＣの転送レートが前記所定の応答時間内で可変である、請求項１に記載のコンテンツリソースブローカユニット。
【請求項３】
前記所定の応答時間が、コンテンツリソースブローカと前記要求側エンティティとによって取り決められる、請求項１または２に記載のコンテンツリソースブローカユニット。
【請求項４】
前記スケジューリングユニットが、さらに、転送のためにコンテンツＣをスケジュールに入れるとき、前記コンテンツＣの応答時間に対する敏感さを考慮するようになっている、請求項１〜３のうちのいずれか１項に記載のコンテンツリソースブローカユニット。
【請求項５】
前記スケジューリングユニットが、さらに、前記所定の応答時間中に動的に前記利用できるネットワーク容量のある一定の部分を前記コンテンツＣの転送に割り当てるようになっている、請求項１〜４のうちのいずれか１項に記載のコンテンツリソースブローカユニット。
【請求項６】
前記リソースユニットが、さらに、前記要求が許可された場合に前記コンテンツＣの転送を開始できるときに関する指示を備える、前記要求側エンティティへの応答を生成するようになっている、請求項１〜５のうちのいずれか１項に記載のコンテンツリソースブローカユニット。
【請求項７】
前記受信ユニットが、さらに、前記受信した要求から、
前記コンテンツＣのサイズ、および／または、
前記コンテンツＣが時間内に配信されるべき最大応答時間
を導出するようになっていて、または、
前記判定ユニットは、最大応答時間が前記受信した要求の中で指示されていない場合、前記コンテンツＣが時間内に配信されるべき前記最大応答時間を推定するようになっていて、
前記推定される最大応答時間が
ａ．コンテンツサイズと、
ｂ．コンテンツタイプと、
ｃ．ユーザ嗜好と、
ｄ．ユーザ加入タイプと
のうちの少なくとも１つに基づいて算出される、請求項１〜６のうちのいずれか１項に記載のコンテンツリソースブローカユニット。
【請求項８】
受信した要求を処理するとき、さらに、
受信した要求の優先レベルおよび／または前記要求の中で指示された前記コンテンツ転送の優先レベルを考慮するようになっている、請求項１〜７のうちのいずれか１項に記載のコンテンツリソースブローカユニット。
【請求項９】
優先レベルが受信した要求の中で指示されていない場合、さらに、前記受信した要求および／または前記要求の中で指示された前記コンテンツ転送に優先レベルを設定するようになっていて、
ａ．コンテンツサイズと、
ｂ．コンテンツタイプと、
ｃ．ユーザ嗜好と、
ｄ．ユーザ加入タイプと、
のうちの少なくとも１つに基づいて前記優先レベルを設定するようになっている、請求項７に記載のコンテンツリソースブローカユニット。
【請求項１０】
前記受信ユニット（１０２）がさらに様々なネットワークエンティティから利用できるネットワーク容量の情報を受信するように適合していて、前記コンテンツの転送のため利用できる現在および将来のネットワーク容量に関する情報が、他のネットワークエンティティから取得できない場合、前記コンテンツの転送のため利用できる現在および将来のネットワーク容量に関する情報を、トラフィック負荷に関する統計値に基づいて推量するようになっている、請求項１〜９のうちのいずれか１項に記載のコンテンツリソースブローカユニット。
【請求項１１】
帯域幅制限通信ネットワーク内のネットワークリソース管理のための方法であって、
コンテンツリソースブローカユニットによって実行される、
−コンテンツの転送のため利用できる現在および将来のネットワーク容量に関する情報を取得するステップ（２０２）と、
−要求側エンティティからコンテンツＣの転送のためのリソースに関する要求を受信するステップ（２０４）と、
−所定の応答時間内の前記利用できるネットワーク容量が前記所定の応答時間が満了する前に前記コンテンツＣを転送するのに十分であるかどうかを判定するステップ（２０６）と、
−前記コンテンツＣが前記所定の応答時間が満了する前に転送できるかもしれない場合、前記要求を許可するステップ（２０８）と
−前記利用できるネットワーク容量（５０２）を考慮して、前記所定の応答時間内での転送のために前記コンテンツＣをスケジュールに入れるステップと
を含む方法。
【請求項１２】
前記所定の応答時間は前記要求側エンティティと取り決められる、請求項１１に記載の方法。
【請求項１３】
前記利用できるネットワーク容量のある一定の部分が前記所定の応答時間中に動的に前記コンテンツＣの転送に割り当てられる、請求項１１または１２に記載の方法。
【請求項１４】
−前記コンテンツＣのサイズ、および／または、
−前記コンテンツＣが時間内に配信されるべき最大応答時間
が前記受信した要求から導出され、最小転送レートが前記受信した要求から導出される、請求項１１〜１３のうちのいずれか１項に記載の方法。
【請求項１５】
要求および／またはコンテンツ転送の優先レベルに基づいて、または、ネットワーク容量の変動のために、
ａ．既に許可されているが、未だ実現されていない要求の拒絶と、
ｂ．既にスケジュールされているが、未だ実現されていないコンテンツ転送の再スケジューリングと、
ｃ．コンテンツの転送に予め割り付けられたネットワークリソースの再割り付けと
のうちの１つまたは複数を実施することが可能である、請求項１１〜１４のうちのいずれか１項に記載の方法。
【請求項１６】
前記コンテンツの転送のため利用できる現在および将来のネットワーク容量に関する情報を取得するステップ（２０２）が、様々なネットワークエンティティから利用できるネットワーク容量の情報を受信することを含み、前記コンテンツの転送のため利用できる現在および将来のネットワーク容量に関する情報が、他のネットワークエンティティから取得できない場合、前記コンテンツの転送のため利用できる現在および将来のネットワーク容量に関する情報を、トラフィック負荷に関する統計値に基づいて推量することをさらに含む、請求項１１〜１５のうちのいずれか１項に記載の方法。
【請求項１７】
プロセッサ（１１２）によって実行されるとき、請求項１１〜１６のうちのいずれか１項に記載の方法を実行することになる命令（１１６）を備えるコンピュータプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、通信システムにおける方法および配置構成、詳細には、制限付き転送容量をもつ通信ネットワーク内のネットワークリソース管理に関する。
【背景技術】
【０００２】
今日では、あらゆるデータトラフィックの大部分は、たとえば、音楽、映画、ニュース、ウェブページなどのようなコンテンツの転送に関連している。ネットワークのボトルネック越しのコンテンツの同時転送の回数が増加するとき、ボトルネック越しにすべての同時セッションによって共有される総容量が一定であるため、各転送セッションのスループットは、比例的に減少する。原則として、特定のリソース、たとえば、伝送リンク越しに許可される同時転送の回数に最大限度がない。
【０００３】
典型的に、ＴＣＰ（伝送制御プロトコル）は、負荷条件に依存して転送レートを調整するために使用されるメカニズムである。
【０００４】
さらに、コンテンツ転送の大部分は、いわゆるファイル共有を介して、たとえば、Ｐ２Ｐ（ピアツーピア）ファイル共有通信プロトコルであるビットトレントを使用して行われる。ファイル共有の使用は、大規模コンテンツファイルがインターネットを介して転送されることを可能にする。しかし、ファイルの配信のための応答時間、すなわち、ファイルがユーザによって要求されてからこのファイルがこのファイルの宛先に到着するまでの時間は、ファイル共有を使用するとき、非常に長くなる可能性がある。
【０００５】
さらに、ウェブトラフィックなどのコンテンツおよびファイルの転送は、通常では、いわゆる「ベストエフォート」を使用して転送される。「ベストエフォート」は、通常では、ネットワークが、データがある一定の制限時間内に、もしくは、どんな形でも配信されるという特定の保証、または、ユーザにある一定のＱｏＳ（サービスの質）、もしくは、ある一定の優先度が与えられるという特定の保証、あるいは、特定の最小帯域保証を提供しないネットワークサービスを表現する。ベストエフォート型ネットワークでは、ユーザは、現在のトラフィック負荷に依存して、不特定の可変ビットレートおよび配信時間を取得する。
【０００６】
以上に鑑みると、コンテンツ転送状況におけるリソース管理に関して依然として改善の余地がある。
【発明の概要】
【発明が解決しようとする課題】
【０００７】
コンテンツ転送と関連して信頼できるリソース管理のためのメカニズムを取得することが望ましいであろう。本発明の目的は、概説された上記の問題点の少なくとも一部に対処することである。さらに、本発明の目的は、所定の時間内に、より予測可能な方法で、要求されたコンテンツの配信を可能にするリソース管理のためのメカニズムを提供することである。これらの目的は、独立請求項に記載された方法および装置によって達成されることがある。
【課題を解決するための手段】
【０００８】
一態様によれば、コンテンツリソースブローカユニット（ＣＲＢＵ）が、ネットワーク通信におけるネットワークリソース管理のため提供される。ＣＲＢＵは、コンテンツの転送のために利用できる現在および将来のネットワーク容量に関する情報を取得するリソースユニットを備える。ＣＲＢＵは、要求側エンティティからコンテンツＣの転送のためのネットワークリソースに関する要求を受信する受信ユニットをさらに備え、所定の応答時間内に利用できるネットワーク容量が所定の応答時間が満了する前にコンテンツＣを転送するのに十分であるかどうかを判定する判定ユニットをさらに備える。ＣＲＢＵは、コンテンツＣが所定の応答時間が満了する前に転送できる可能性がある場合、要求を許可することがある許可ユニットをさらに備える。
【０００９】
別の態様によれば、通信ネットワーク内のネットワークリソース管理の方法が提供される。この方法は、コンテンツの転送のために利用できる現在および将来のネットワーク容量に関する情報を取得するステップを含む。この方法は、要求側エンティティからコンテンツＣの転送のためのリソースに関する要求を受信するステップをさらに含み、所定の応答時間内に利用できるネットワーク容量が所定の応答時間が満了する前にコンテンツＣを転送するのに十分であるかどうかを判定するステップをさらに含む。要求は、コンテンツＣが所定の応答時間が満了する前に転送できる可能性がある場合、許可される。
上記の方法および配置構成は、それぞれ、ネットワークリソース管理が、転送されるコンテンツのボリュームまたはサイズに基礎を置くことを可能にするために使用されることがある。これは、たとえば、スループット不足に起因した中断の回避を可能にすることにより、たとえば、ネットワークボトルネック越しのコンテンツダウンロードのためのＱｏＥを改善するメカニズムを提供する。
【００１０】
第１の方法および配置構成は、以下の特徴の一部または全部の種々の組み合わせを備える種々の実施形態で実施されることがある。
【００１１】
応答時間は、一部の状況では、ＣＲＢＵが要求の中で指示された応答時間内に転送を実現できない場合、ＣＲＢＵと要求側エンティティとの間で取り決められることがある。この特徴は、システムに柔軟性を加え、厳密さのレベルが要求の中で指示された応答時間に設定されることがある機能性を可能にする。
【００１２】
ＣＲＢＵは、所定の応答時間内での転送のためにコンテンツＣをスケジュールに入れるとき、利用できるネットワーク容量と、場合によってはコンテンツＣの時間感度とを考慮するスケジューリングユニットを備えることがある。スケジューリングユニットは、所定の応答時間中に動的に、利用できるネットワーク容量のある一定の割合をコンテンツＣの転送にさらに割り当てることがある。
【００１３】
要求側エンティティが、コンテンツ転送をいつ開始すべかに関する情報を受信するために、要求が許可された場合にコンテンツＣの転送をいつ開始することができるかに関する指示を備える応答を要求側エンティティへ送信することができる。
【００１４】
ＣＲＢＵは、コンテンツのボリュームおよび応答時間と連動する。その結果、ＣＲＢＵは、これらのパラメータに関する情報を取得できるべきである。時間内にコンテンツＣが配信されるべきコンテンツＣのサイズ、および／または、最大応答時間は、受信した要求から導き出すことができる。これらのパラメータのうちの一方または両方が要求の中に明示的に包含されていない場合、コンテンツＣのサイズは、たとえば、コンテンツＣが記憶されているロケーションから導き出すことができ、および／または、応答時間は、コンテンツサイズ、コンテンツタイプ、ユーザ嗜好、または、ユーザ加入タイプのうちの少なくとも１つに基づいて推定することができる。
【００１５】
最小転送レートを必要とするサービスを支援するために、ＣＲＢは、受信した要求から最小転送レートを導き出すことも可能である。
【００１６】
受信した要求の優先レベルおよび／または要求の中で指示されたコンテンツ転送の優先レベルは、受信した要求を処理するときに考慮されることがある。優先レベルは、コンテンツサイズ、コンテンツタイプ、ユーザ嗜好、または、ユーザ加入タイプのうちの少なくとも１つに基づいて要求の中で指示されるか、または、ＣＲＢＵによって設定されることがある。
【００１７】
既に許可されているが、未だ実現されていない要求の優先レベルは、ネットワーク内のコンテンツの転送のため利用できる現在および将来のネットワーク容量に関する情報を取得するときに考慮されることがある。この特徴は、以下の特徴のうちの１つまたは複数の性能を可能にすることによって柔軟性を可能にする。
【００１８】
許可されているが、未だ実現されていない要求は、拒絶されることがあり、スケジュールに入れられているが、未だ実現されていないコンテンツ転送は、スケジュールを変更されることがあり、コンテンツ転送に予め割り付けられているネットワークリソースは、要求および／またはコンテンツ転送の優先レベルに基づいて、または、たとえば、ワイヤレスリンクにおけるネットワーク容量の変動に起因して再割り付けされることがある。
【００１９】
優先度に関係する特徴は、リソース管理をより効率的にするように、たとえば、種々のコンテンツ転送と種々のサービスとの間で優先順位を付けることを可能にする。
【００２０】
さらに別の態様によれば、通信ネットワーク内のネットワークリソース管理を支援する第２の方法が、要求側エンティティに提供される。この方法は、転送されるコンテンツのサイズに基づいてコンテンツの転送のためにネットワークリソースを管理することができるコンテンツリソースブローカユニットへコンテンツＣを転送するためのネットワークリソースに関する要求を送信するステップを含む。要求は、コンテンツＣのサイズ、および／または、その時間内にコンテンツＣが配信されるべき応答時間を指示すべきである。
【００２１】
さらに別の態様によれば、通信ネットワーク内のネットワークリソース管理を支援する要求側エンティティが提供される。要求側エンティティは、転送されるコンテンツのサイズに基づいてコンテンツの転送のためのネットワークリソースを管理することができるコンテンツリソースブローカへコンテンツＣを転送するためのネットワークリソースに関する要求であって、コンテンツＣのサイズ、および／または、その時間内にコンテンツＣが配信されるべき応答時間を指示する要求を送信する要求ユニットを備える。
【００２２】
上記の第２の方法および配置構成は、たとえば、前述されているコンテンツリソースブローカのようなコンテンツリソースブローカへ転送されるコンテンツのサイズのような基本的な情報を提供することによりネットワークリソース管理を支援するために使用されることがある。
【００２３】
別の態様によれば、プロセッサなどによって実行されるとき、前述の実施形態のいずれかによる方法を実施することになる命令を備えるコンピュータプログラムプロダクトが提供される。
【図面の簡単な説明】
【００２４】
発明は、例示的な実施形態を用い、添付図面を参照してより詳細に説明されることになる。
【図１】コンテンツリソースブローカユニットの実施形態を示すブロック図である。
【図２】方法ステップの実施形態を示すブローチャートである。
【図３】コンテンツリソースブローカユニットの別の実施形態を示すブロック図である。
【図４】一実施形態によるコンテンツリソースブローカへの要求を行う種々のエンティティを示す概略図である。
【図５】一実施形態によるコンテンツの転送へのネットワークリソースの割り付けを示す概略図である。
【図６】一実施形態によるマルチホップブローカリングを示す概略図である。
【図７】本発明の一実施形態によるコンテンツリソースブローカユニットへのコンテンツの記憶を示す概略図である。
【図８】本発明の一実施形態によるリソース要求と要求への代替的な応答とのコンポーネントを示す概略図である。
【図９】ネットワーク内のコンテンツリソースブローカのための例示的なロケーション代替を示す概略図である。
【発明を実施するための形態】
【００２５】
簡単に説明すると、種々の要求を差別化し、また、ネットワークリソースを割り当てるときに所定の応答時間を考慮することができるコンテンツリソースブローカを導入することにより、輸送能力が制限されたネットワーク内で新規性のあるより制御可能な方法でコンテンツ転送のためのネットワークリソースを管理する解決策が提供される。記載されたリソース管理アーキテクチャは、どんなトラフィッククラスにも適用できる。記載されたリソース管理アーキテクチャは、データのボリュームに基礎を置き、すなわち、従来的に使用される「ビット毎秒」に基礎を置かない。
【００２６】
本文書中では、ここで簡単に定義されるある種の表現が使用されることになる。たとえば、用語「応答時間」は、ある一定のコンテンツがユーザによって要求されてから、上記コンテンツがこのコンテンツの宛先へ配信されるまでの時間を意味するように使用される。表現「制限付き輸送容量」または「帯域幅制限ネットワーク」は、ネットワークが、通過トラフィックをある一定の程度に制限する制限付きスループット容量をもつボトルネックを備えることを指示するため使用される。輸送ネットワークでは、帯域幅制限を指示することがあり、ワイヤレスネットワークでは、制限は、信号対雑音比によって記述されることもある。用語「コンテンツ」は、エンドユーザに価値を提供することがある情報および体験、たとえば、映画と、ニュースと、映像クリップと、音楽と、ゲームと、テキスト、たとえば小説、本などとを意味するように使用される。コンテンツの「ボリューム」または「サイズ」の用語は、コンテンツをある一定のピアまたはエンドユーザへ配信するために転送される必要があるビット数を意味するように使用される。このボリュームは、実際のコンテンツ、たとえば、符号化フィルムを表現するビットだけを含むように定義されること、または、ネットワークを介してコンテンツを転送するために典型的に同様に必要とされる付加制御情報さらに含むように定義されることがある。
【００２７】
表現「利用できるネットワークリソース」および「利用できるネットワーク容量」は、コンテンツの転送のため自由かつ有効に使用できるリソースおよび容量を指す。リソースは、割り付けられないことがあるが、たとえば、より低い優先度をもつコンテンツの転送に予め割り付けられ、その結果、より高い優先度をもつコンテンツを自由かつ有効に転送できるとみなされることもある。
【００２８】
本文書で検討されたリンクは、リンクがワイヤードでもワイヤレスでもよい数個のホップまたはサブリンクを備えることがあることを意味するいわゆる「仮想」リンクということがあり得る。種々のタイプのコンテンツは、応答時間に種々の要件を有している。たとえば、ある種のタイプのコンテンツ、たとえば、ＹｏｕＴｕｂｅまたはウェブページからの映像は、かなり素早く消費されるべきであり、他のタイプのコンテンツ、たとえば、ファイル共有フルサイズ映画は、後で使用される。
【００２９】
これらの要件の相違は、種々の転送タイプに関する情報を使用し、様々な種類の優先順位付けメカニズムを適用する集中リソースブローカによって利用することができる。
【００３０】
これまでのところ、受信したリソース要求を拒絶または許可するＣＡＣ機能（呼許可制御）を提供する音声呼のようなリアルタイムサービスのための多数の種類のリソースブローカアーキテクチャが存在する。これらのリソースは、ビット毎秒で記載される。本文書に記載されたブローカは、全体的なリソース管理サービスを提供するために、たとえば、リアルタイムサービスからの従来型のリソースの要求を支援するように適合されることも可能である。
【００３１】
本文書に提示されたリソース管理手順では、新しいタイプのネットワークリソースブローカが導入されることになる。この新しいタイプのネットワークリソースブローカは、「コンテンツリソースブローカ」（ＣＲＢ）または「帯域幅セクションブローカ」と称されることになる。本文書に記載された新しいネットワークリソースブローカと、従来型のブローカとの間の主な相違点は、従来型のブローカが要求され許可されたリソースとして、ビット毎秒単位の帯域幅と連動し、一方、本文書に記載されたネットワークリソースブローカは、バイト単位の転送されるコンテンツの全ボリューム、およびダウンロードする時間、すなわち、コンテンツが転送されるための応答時間と連動することである。このようにして、完全に新しいリソース管理アーキテクチャが開発される。
リソース管理のこの新しいアプローチは、コンテンツ配信ネットワーク（ＣＤＮ）に、および／または、たとえば、コンテンツの中間ホスティングがＱｏＥ（経験の質）の観点から動機付けされるネットワーク内で有利に適用することができる。今日のＱｏＥの１つの問題は、ネットワーク内のコンテンツのための、保証された最小帯域幅が存在しないことである。しかし、記載されたリソース管理アプローチでは、最小帯域幅の保証と、ネットワーク内の種々の配信時間の間の差別化とが両方共に支援される。ファイル共有およびＱｏＥに敏感なトラフィックのトラフィック混合において、新しいアーキテクチャは、より詳細に後述される差別化されたコンテンツ転送性能を提供できるようにすることによって、特に有利である。記載されたアーキテクチャは、より優れた保証付きの他のタイプのネットワークサービスに対しても、すなわち、大量のコンテンツの配信を伴い、また、種々の配信間の差別化がネットワーク性能を改善することになるネットワークにおいて同様に有益である。
【００３２】
新しいネットワークリソースブローカは、同時転送の回数を制限するために、リソースの要求を許可または拒絶することができるべきである。さらに、ブローカは、ネットワーク内のコンテンツの転送のため利用できる空きネットワーク容量に関する情報に基づいて、要求の中で指示されたコンテンツをスケジュールに入れることができるべきである。たとえば、コンテンツの転送は、十分な空きリソースが割り付けのために利用できるようになるまで遅延させることができる。ネットワークリソースは、多くの場合に比較的大きいタイムスロット、すなわち、帯域幅のポーション、セクションまたは「チャンク」の割り付けによって、ある一定のコンテンツの転送に割り当てられる。これらのポーションは、どのようなサイズでもよく、動的に割り当てられてもよい。たとえば、参照される時分割技術において広く用いられるタイムスロットのように、固定サイズのタイムスロットまたはサブフレームではなく、典型的にかなり大きいスロット、すなわち、ポーションまたは「チャンク」であることに留意されたい。このようなポーションまたはチャンクは、ギガバイトのサイズでもよいが、通常では、たとえば、ＴＤＭタイムスロットは、典型的に、およそ１００バイトのサイズである。
【００３３】
さらに、ブローカは、たとえば、応答時間に敏感な転送と応答時間に敏感ではない転送との間、および、他の優先度根拠を有している要求の間を区別し、優先順位を付けることができるべきである。ネットワークリソースの割り付けは、たとえば、応答時間に基づいて実施することができ、短い応答時間を要求する転送に積極的に優先順位を付けることができ、逆もまた同様である。さらに、ブローカは、ブローカにネットワークリソースを要求したエンティティへの応答を生成することができるべきである。ブローカは、必要に応じて、最小帯域幅の要求に適合することも可能である。
【００３４】
新しいアーキテクチャは、最小ＱｏＥ保証およびより短い待ち時間をこのサービスを要求するアプリケーションに提供することがある。本文書に記載された解決策は、ワイヤードネットワークおよびワイヤレスネットワークの両方とこれらの組み合わせとに適用できる。ワイヤレスネットワーク、または、より明示的なセルラネットワークに対し、ＣＲＢは、無線ネットワークコントローラ（ＲＮＣ）、基地局、中継ノード、または、前述の機能性を実施することができる他の機器に埋め込むことができる。ワイヤレスネットワーク、たとえば、ＷＬＡＮ  ３ＧまたはＬＴＥでは、最大スループットは、たとえば、基地局への距離および無線条件のような数種類の態様に依存する。その結果、ワイヤレスネットワークにおける帯域幅は、ワイヤードネットワークのシナリオの場合のように静的ではない。ワイヤレスネットワークのシナリオでは、リソースブローカは、端末とネットワークノードとの間で帯域幅のダイナミクスを考慮することが必要である。高い優先度のコンテンツ転送が先に行われ、より低い優先度のコンテンツ転送が後に行われる。帯域幅の変動は、コンテンツの再スケジューリングと、ネットワークリソースの再割り付けとを引き起こすこともある。これは、既に許可された要求の一部が拒絶されるという結果をさらにもたらすことがある。
【００３５】
応答時間パラメータは、要求側エンティティによって送信されたリソースの要求の中に指示されるとき、指示された最大応答時間の厳密さのインジケータを備えることがある。指示された応答時間は、たとえば、厳密な取り決めることができない応答時間、または、単なる推薦でもよい。要求された応答時間が相談可として指示される状況では、ＣＲＢおよび要求側エンティティは、たとえば、ＣＲＢが最初に要求された応答時間に適合できない場合、応答時間に関して取り決めることがある。応答時間が要求側エンティティによって送信されたリソースの要求の中で指示されないとき、応答時間は、代わりに、さらに後述されるＣＲＢによって推定されることがある。推定された応答時間の厳密さは、その後、たとえば、転送されるコンテンツの時間感度に基づいて設定され、または、たとえば、相談可として初期設定によって設定されてもよい。応答時間の厳密さは、要求の優先度と関連付けられてもよい。優先度は、後でさらに議論される。
【００３６】
以下、例示的なブローカリング手順および例示的なコンテンツリソースブローカユニット（ＣＲＢＵ）が、図２のフローチャートを参照してより詳細に説明される。
【００３７】
図２は、本発明の一実施形態によるコンテンツリソースブローカユニット２００で実施される方法ステップを示す。最初に、利用できるネットワーク容量、すなわち、種々のコンテンツ転送に自由に割り当てられる帯域幅の現在および将来のスロットまたはセクションに関する情報は、第１のステップ２０２で取得される。その後、ある一定のコンテンツＣを転送することを望む要求側エンティティから転送要求が次のステップ２０４で受信される。代替的に、ステップ２０２および２０４は、反対順に実施されてもよい。その後、所定の応答時間が満了する前に利用できるネットワーク容量がコンテンツＣを転送するのに十分であるかどうかが、次のステップ２０６で判定される。利用できるネットワーク容量が十分であると判明した場合、受信した要求は、ステップ２０８で許可され、利用できるリソースが十分ではないと判明した場合、受信した要求は、ステップ２１０で拒絶される。代替的に、修正された代替的な応答時間は、承認または拒否のために要求側エンティティに提示されることがある。
【００３８】
図１は、ブロック図であるが、コンテンツリソースブローカユニット１００の実施形態を示す。ＣＲＢＵ１００は、要求側エンティティからコンテンツの転送のための要求を受信するように適合し、様々なネットワークエンティティから利用できるネットワーク容量の情報を受信するようにも適合した受信ユニット１０２を備える。ＣＲＢＵ１００は、利用できるネットワーク容量、すなわち、種々のコンテンツ転送に自由に割り当てられる帯域幅の現在および将来のスロットまたはセクションに関する情報を取得するように適合したリソースユニット１１０をさらに備える。この情報は、たとえば、ＣＲＢＵによって行われた要求に対する返答として、種々の方法でＣＲＢＵに供給されてもよく、または、定期的に、ブロードキャストもしくは明示的に配布されてもよい。利用できるネットワーク容量に関する情報は、このような情報が他のネットワークエンティティから取得できない場合、ＣＲＢＵによってさらに推定されてもよい。利用できるネットワーク容量の推定は、たとえば、１日のうちの種々の時間、種々の平日などにおける、たとえば、トラフィック負荷に関する統計値に基づいていてもよい。ＣＲＢＵは、前述の応答時間が満了する前に利用できるネットワーク容量がある一定のコンテンツＣを転送するのに十分であるかどうかを判定するように適合した判定ユニット１０４をさらに備える。利用できるリソースが十分であると判明したか否かに依存して、受信した要求は、許可ユニット１０６で許可または拒絶され、この判定は、送信ユニット１０８によって要求側エンティティに通知されることがある。
【００３９】
図３のブロック図は、図１に示されたコンテンツリソースブローカユニットと類似したコンテンツリソースブローカユニットの実施形態を示すが、スケジューリングユニット３１２をさらに示す。スケジューリングユニット３１２は、リソースユニット３１０によって取得された利用できるネットワーク容量に関する情報を考慮して、所定の応答時間内の転送のためにある一定のコンテンツＣをスケジュールに入れるように適合している。
【００４０】
スケジューリングユニットは、たとえば、時間に敏感なコンテンツをそれほど時間に敏感でないコンテンツに対して優先することができるように、転送のためコンテンツをスケジュールに入れるとき、コンテンツの応答時間感度を考慮することがある。スケジューリングユニットは、空いている利用できるリソースをコンテンツの転送に動的にさらに割り当てることがある。コンテンツ転送は、図５に示される帯域幅５０２のスロットの形をしたリソースが割り当てられることになる。
【００４１】
図１および図３には、プロセッサ１１２、３１４などによって実行されるとき、機能ユニット１０２〜１１０および機能ユニット３０２〜３１２のそれぞれに上記手順の実施形態によるこれらのタスクを実施させることになる命令１１６、３１８を備えるコンピュータプログラムプロダクト１１４、３１６がさらに示される。プロセッサは、図示された機能ユニットに接続されている。これらの接続は、プロセッサ１１２、３１４から出る破線矢印として単に示される。
【００４２】
図４は、一実施形態による種々の要求側エンティティから要求を受信するＣＲＢＵ４０８を示す。ＣＲＢＵ４０８は、複数の種々のネットワークエンティティ４０２〜４０６からコンテンツ転送のネットワークリソースに対する要求４０２：１、４０４：１、４０６：１を受信することがある。要求は、たとえば、アプリケーション４０４へのＡＰＩ（アプリケーションプログラミングインターフェイス）によって、または、コンテンツが転送されるべきとき、通過するメッセージを解析し、別個の要求をブローカへ送信するアプリケーションプロキシ４０２によって明示的に生成されることがある。要求は、たとえば、コンテンツのための通過する要求を点検し、対応する、ネットワークリソースの要求をＣＲＢＵへ送信するＤＰＩ（ディープパケットインスペクション）機能４０６によって、さらに生成されることがある。
【００４３】
以下、ネットワークリソース、要求および応答がさらに説明される。
【００４４】
ＣＲＢＵによって管理されるリソースは、時間［ｓ］と帯域幅［ｂｐｓ］との組み合わせの観点から管理され、ここで、時間と帯域幅との掛け算は、転送されるボリューム［ビットまたはバイト］以上とすべきである。時間および帯域幅は、間隔および帯域幅の点に関して、以下の通り図５に示される、ある一定の限度内でどのようなサイズでもよく、かつ、種々のサイズをもつ帯域幅のスロット、または、「チャンク」として割り当てられる。
【００４５】
図５は、一実施形態によるＣＲＢＵによって管理される、たとえば、伝送リンクにおけるネットワークリソースを示す。一実施例として、コンテンツＣ１の転送は、Ｃ１を用いて指示される帯域幅のタイムスロットが割り当てられ、また、帯域幅の残りのタイムスロットは、他のコンテンツ転送のため既に割り当てられているか、または、割り当てのため利用できることがある。
【００４６】
ＣＲＢは、パラメータ：転送されるコンテンツのボリューム（ギガバイト）と、コンテンツに対する最大応答時間とを要求から導出することができるべきである。パラメータは、要求から直接的に、または、たとえば、要求中の情報に基づいて間接的に導出することができる。コンテンツボリュームが要求の中に明示的に包含されない場合、ボリュームは、たとえば、要求の中に指示されたコンテンツが記憶されているロケーション、たとえば、ネットワークノード内のキャッシュから取得できる。最大応答時間が要求の中に明示的に包含されていない場合、最大応答時間は、たとえば、指示されたコンテンツのタイプ、指示されたコンテンツのサイズ、ユーザ嗜好、および／または、ユーザ加入タイプのうちの１つまたは複数に基づいて推定し、設定することができる。
【００４７】
一実施形態による要求の例示的なコンポーネントは、図８に示される。要求側エンティティのユーザは、コンテンツＣを転送することを望んでいる。要求側エンティティは、要求側エンティティのユーザが転送することを望むコンテンツＣのボリュームを指定するパラメータ８０２を備える要求８０６を形成する。実施例では、ボリュームは、Ｘｃで示され、ギガバイトの単位で与えられる。しかし、たとえば、ビットのようなボリュームを指定する他の単位可変要素がさらに可能である。要求は、最大の所要または所望の応答時間Ｔｃ秒を指定するパラメータ８０４をさらに備える。パラメータ８０２および８０４を備える要求８０６は、コンテンツＣが転送されるときに越すネットワークリンクの全部または一部のためのブローカである第１のＣＲＢＵへ送信される。第１のＣＲＢＵは、利用できるネットワークリソースを解析し、必要に応じて、要求を第２のＣＲＢＵへ送信する。第１のＣＲＢＵは、応答時間Ｔｃ内にコンテンツＣを転送するために十分に空いた利用できるネットワークリソースが存在するかどうかを判定し、ここでは、代替的な応答８０８ａ〜ｃとして示される応答がＣＲＢＵによって要求側エンティティへ送信される。応答は、「許可」通知または「拒絶」通知を備えることがあり、コンテンツＣの転送が開始されるべきとき、または、開始できるときに関する指標を含むことがある。要求がコンテンツのボリュームおよび応答時間というパラメータの一方または両方を備えない場合、これらのパラメータは、前述された通り、要求を受信するＣＲＢＵによって他の方法で取得することができる。
【００４８】
ＣＲＢは、ｂｐｓ（ビット毎秒）単位での一定の最小転送レートを要求するアプリケーションを支援するために、最小転送レートの要求をさらに含むリソースの要求を支援するようにも適合させることができる。最小帯域幅を提供することは、たとえば、ＹｏｕＴｕｂｅおよびＷｅｂ−ＴＶアプリケーションによって使用される、たとえば、プログレッシブダウンロードのための適切なＱｏＥを達成するために時には重要である。最小帯域幅を提供できない場合、このようなアプリケーションは、ユーザに表示されるとき、転送の中断、およびその結果、おそらくコンテンツの中断の被害を受けることがある。
【００４９】
図４に４０２：２、４０４：２、および４０６：２として示される、要求側エンティティに送信される応答は、リソース要求の許可または拒絶の通知を備えることができる。応答は、要求側エンティティが許可するかまたは拒絶する代替の提案された応答時間を備えることができる。さらに、応答は、いつコンテンツの転送が開始されるか、たとえば１０ｍｓまたは２時間の指示を備えることができる。
【００５０】
代替的に、要求、および／または、要求への応答が、コンテンツの転送が開始されるまで、ＣＲＢＵでキューに入れられることができる。次いで、応答は、転送の開始の許可とともに要求側エンティティに送ることができる。
【００５１】
以下、要求の間に優先順位を付けるＣＲＢ能力が検討されることになる：コンテンツの転送のためのリソースのスケジューリングと組み合わされた種々の要求の優先順位付けは、種々の方法で解決することができる。複数の優先レベルを使用することができ、また、優先レベルは、たとえば、要求の中に指示されることができ、または、たとえば、要求の中で指示されたコンテンツのボリュームおよび／または最小応答時間のような要求の中で指示された他の情報から導出することができる。代替的に、優先レベルは、たとえば、ＨＬＲ（ホームロケーションレジスタ）などから取得することができるユーザ嗜好、または、ユーザ加入タイプから導出することができる。許可された要求は、より高い優先度をもつ要求がＣＲＢによって受信された場合、再びスケジュールに入れられるか、または、拒絶されるかもしれない。
【００５２】
優先レベルは、要求の中で指示されたコンテンツに付加的にまたは代替的に関連付けられてもよい。コンテンツの転送の優先レベルは、要求の優先レベルに対応することができるか、またはできない。コンテンツの転送の優先レベルは、たとえば、転送のコンテンツをスケジュールに入れるときに使用されてもよい。スケジュールに入れられるべきコンテンツ転送の優先レベルよりも低い優先レベルをもつコンテンツ転送に割り付けられたリソースは、転送のためにコンテンツをスケジュールに入れるとき、割り付けなし、すなわち、割り付け自由としてみなされてもよい。
【００５３】
要求は、優先度に関して分類することができ、また、適切な要求の優先度キューに入れることができる。要求がキューの前方に到達し、サービスを受ける必要があるとき、適切な、おそらく前もって予約されたリソースは、できることなら、当該問題となっている要求の中で指示されたコンテンツの転送に割り付けられることになる。要求の中で指示されたコンテンツの転送を達成するために十分な利用できるリソースが存在する場合、要求が許可されたことを指示する応答は、要求側エンティティへ送信されることになる。要求の中で指示されたコンテンツの転送を達成するために利用できるリソースが十分に存在しない場合、要求が否定されたことを指示する応答は、要求側エンティティへ送信されることがある。代替的に、ＣＲＢは、推定された配信時間に基づくことがある、提案された新しい応答を備える応答を送信することがある。この提案された応答時間は、その後、要求側エンティティによって承認されるか、または、拒絶されることがある。たとえば、重み付き公平キューイング（ＷＦＱ）、絶対優先キューイング（ＰＱ）または重み付きラウンドロビン（ＷＲＲ）のようなどんな種類の優先メカニズムでも使用可能であり、本発明がこの点で限定されないことに留意されたい。
【００５４】
以下、マルチホップブローカリングのシナリオと、コンテンツを記憶するＣＲＢの提案された能力とが記載される：記載されたリソース管理アーキテクチャは、オーバーレイノードが記憶能力を有することがあるオーバーレイネットワーク内で分散アーキテクチャとして適用することができる。ノード間の各ホップでは、現在のＣＲＢは、送信リンクに対するリソース制約を仮定して、要求を許可または拒絶し、たとえば、最小スループットが要求された場合に最小エンドツーエンドスループットを確保するためにリソースを割り付けることができる。送信リンクは、仮想または論理リンク、すなわち、数個のホップまたはサブリンクを備えるリンクということがある。２つ以上のＣＲＢがマルチホップのシナリオで協働するとき、コンテンツの転送のための最大応答時間は、転送を完了するために関与しているＣＲＢの間で分割されるべきである。この応答時間の分割は、種々の方法で行うことができ、たとえば、ＣＲＢは、ＣＲＢの分布に関する情報、たとえば、順番に関与することになる何台のＣＲＢが、ある一定の転送を可能にするかを与えられることがあり、ＣＲＢは、その後、応答時間のうちこれらのＣＲＢが支配できる部分を計算することができる。代替的に、各ＣＲＢは、たとえば、通知側ＣＲＢおよび通知側ＣＲＢに先行するＣＲＢによって仲介されたリンク越しの転送中に消費されることになる応答時間の長さ、すなわち、転送の残りの部分に残存する応答時間の長さをマルチホップチェーン内の次のＣＲＢに通知することができる。
【００５５】
ＣＲＢは、たとえば、コンテンツの局所記憶が転送されることを可能にするキャッシュである記憶ユニットを備えるか、または、記憶ユニットと同じ場所に配置されることがある。転送中のコンテンツの局所記憶は、コンテンツの転送が時間的にシフトされること、すなわち、種々の時点に種々のリンクを介して制御可能な方法で転送されることを可能にさせ、リソース管理の効率をさらに増大することがある。
【００５６】
図６は、マルチホップネットワーク内で協働するＣＲＢを示す概略図である。各ＣＲＢは、いわゆる仮想リンクとしてもよいある一定のリンクの組のような明確なリソースの組に対するブローカである。第１のＣＲＢＵ６０８は、たとえば、要求側ユニット６０２、６０４および６０６から要求６０２：１、６０４：１および６０６：１を受信する。第１のＣＲＢＵ６０８は、たとえば、要求の中に指示された応答時間の一部の範囲内で要求の中に指示されたコンテンツを転送するのに十分な空いた利用できるネットワークリソースが存在するかどうかを判定するために、ＣＲＢＵ６０８がブローカとして使われるリンクの組の中で利用できるネットワークリソースを解析する。たとえば、ＣＲＢＵ６０８がすべての要求６０２〜６０４：１が許可できることを見出した場合、適切なリソースが割り付けられ、要求６１０：１は、第１のＣＲＢＵ６０８から第２のリンクの組のために使われる第２のＣＲＢＵ６１０へ送信され、要求の中で指示されたコンテンツがこの第２のリンクの組を介して転送されるべきである。第２のＣＲＢＵ６１０は、次に、この第２のＣＲＢＵが支配できる応答時間の一部分の範囲内に（複数の）要求の中で指示されたコンテンツを転送するのに十分な空いた利用できるネットワークリソースが存在するかどうかを判定するために、ＣＲＢＵ６１０がブローカとして使われるリンクの組の中で利用できるネットワークリソースを解析する。ＣＲＢＵ６１０は、たとえば、要求６０２：１および６０４：１の中で指示されたコンテンツを転送するが、要求６０６：１の中で指示されたコンテンツを転送しないために、十分な空いた利用できるネットワークリソースが存在すると判定することがある。その後、このことは、要求６０２：１および６０４：１に対する「許可」と、要求６０６：１に対する「拒絶」とを備える応答６１０：２の中でＣＲＢＵ６０８へ通知される。その後、ＣＲＢＵ６１０は、要求６０２：１および６０４：１の中で指示されたコンテンツの転送のためのネットワーク要求を割り付け、「許可」を備える応答６０２：２および６０４：２と、「拒絶」を備える応答６０６：２とを送信することにより要求側エンティティ６０２〜６０６に応答する。代替的に、要求側エンティティへの応答のうちの１つまたは複数は、第２のＣＲＢＵ６１０から応答６１０：２を受信した後、第１のＣＲＢＵ６０８によって送信することができる。ここでは、２ホップのシナリオが例示されているが、原理は、３台以上のＣＲＢＵが関与している状況においても同じである。実施例における要求６０６：１のように要求が１台のＣＲＢＵによって拒絶されたとき、要求６０６：１を許可する第１のＣＲＢＵ６０８は、十分なネットワークネットワークリソースを有することがあり図示されていない別のＣＲＢＵがブローカとして使われるリンクの組が、コンテンツの宛先へのネットワークを経由する代替的な、冗長なルートの一部である場合、この別のＣＲＢＵへ要求を送信することも可能であろう。
【００５７】
一体としてとらえられたすべてのホップに対する推定配信時間が初期要求応答時間を超えるとしても、要求が許可されることも考えられる。このような場合、要求側エンティティは、前述された通り、ＣＲＢＵからの応答の中で、たとえば、すべてのホップに対する総推定配送時間の形式で新しい提案応答時間を受信することになる。
【００５８】
図７は、一実施形態によるコンテンツ記憶設備７０４、たとえば、キャッシュを備えるＣＲＢＵ７０２を示す。この記憶エンティティ７０４では、コンテンツは、転送中に一時的に記憶することができる。このようにして、転送の一部分は、ネットワークの第１の部分に十分な利用できるリソースが存在する時点で実施することができ、また、転送の第２の部分は、ネットワークの第２の部分に十分な利用できるリソースが存在する後の時点で実施することができる。転送の第１の部分と第２の部分との間で、転送中のコンテンツは、ＣＲＢＵ７０２に記憶することができる。
【００５９】
図９は、例示的なネットワークにおけるコンテンツリソースブローカのための例示的な代替ロケーションを示す。図示されたネットワークは、ルーティングノード（Ｒ）９０８、たとえば、ルータまたはイーサネットスイッチを備える。さらに、例示的なネットワークは、無線ネットワークノード９１０、たとえば、無線基地局（ＲＢＳ）を備える。図示されたノードは、様々なリンクによって互いに、また、ネットワーク内の他のノードと相互接続されている。これらのリンクは、たとえば、ワイヤードリンクおよび／またはワイヤレスリンクの適当な組み合わせであればどれでもよい。コンテンツリソースブローカは、ネットワーク内の多数の異なるレベルにおいて動作することができ、また、多数の異なるレベルに位置することができる。ＣＲＢは、ＣＲＢ９０２によって示されるように、たとえば、ネットワークノード、たとえば、ルーティングノードの中に、および／または、ＣＲＢ９０６によって示されるようにＲＢＳの中に設置することができる。ＣＲＢは、ＣＲＢ９０４によって示されるように、たとえば、別個のノードとしてさらに設置することができる。
【００６０】
ネットワーク容量リソースは、種々のタイプからなることがあり、たとえば、すなわち、ＭＰＬＳトンネル（マルチプロトコルラベルスイッチング）によって支援されたＩＰネットワークリソース、伝送リンク、すなわちＳＤＨ／ＰＤＨ、または、イーサネットリソース、すなわちＭＥＦ（メトロイーサネットフォーラム）定義済のＳＬＡ（サービスレイヤアグリーメント）でもよい。ネットワークのワイヤレス部分では、ワイヤレスリンク越しのネットワーク容量は、統計的な配信保証付きのスループットとしてモデル化することができる。
【００６１】
以下、いくつかの結語を示す。
図１および図３は、論理的な意味でＣＲＢＵ１００および３００の様々な機能ユニットを単に示すだけであることに留意されたい。しかし、当業者は、実際には適当なソフトウェアおよび／またはハードウェア手段を使用してこれらの機能を自由に実現できる。よって、本発明は、一般的に、図示されたＣＲＢＵ１００および３００の構造に限定されることがない。図１に示された手順ステップは、同様に論理的な意味で示される。
【００６２】
本発明の利点は、帯域幅制限ネットワーク内のコンテンツ配信のためにより効率的なリソース管理を可能にすることである。本発明は、リソース管理機能をネットワークに追加することによりボトルネック越しのコンテンツ配信のためのＱｏＥ（経験の質）の問題に対処する。本発明の実施形態を構成するアーキテクチャは、たとえば、ファイル共有およびＱｏＥに敏感なトラフィックなどのコンテンツの種々のタイプに対するネットワーク性能の差別化を可能にするので、ＱｏＳ（サービスの質）の態様もコンテンツの転送に追加することができる。このアーキテクチャは、所定の応答時間内に、ある一定のＱｏＥ要件を実現するコンテンツ配信を提供することがある。本発明の実施形態によるリソース管理は、スループットを提供するネットワークリソースの不足によってダウンロードが中断されないように、コンテンツダウンロードのＱｏＥを改善することがある。リソース管理は、コンテンツ配信を意図し、たとえば、転送ネットワークおよびセルラワイヤレスネットワークに適用することができる。
【００６３】
本発明は、特定の例示的な実施形態を参照して説明されているが、説明は、一般的に、創作性のある考え方を示すことだけを意図し、発明の範囲を限定するものとして考えられるべきではない。前述の例示的な実施形態の種々の特徴は、必要性、要件または嗜好に応じた種々の方法で組み合わされることがある。本発明は、一般的に、以下の独立請求項によって規定される。
【図１】
0005496353.tif 000002
【図２】
0005496353.tif 000003
【図３】
0005496353.tif 000004
【図４】
0005496353.tif 000005
【図５】
0005496353.tif 000006
【図６】
0005496353.tif 000007
【図７】
0005496353.tif 000008
【図８】
0005496353.tif 000009
【図９】
0005496353.tif 000010