(57)【特許請求の範囲】
【請求項１】
マルチメディア配信ネットワークであって、前記ネットワーク上のＵＥ（ユーザ装置）デバイスと配信サーバの間のネットワークセッションに帯域幅を割り当てるためのＲＡＣＳ（リソースおよび管理制御サーバ）を備え、前記ＲＡＣＳが、ネットワークセッションが開かれるときに前記ネットワークセッションのための公称帯域幅を予約するようになされ、それによりＱｏＳが保証される公称レートでの配信サーバからＵＥへのデータの配信が可能になり、前記配信サーバが、公称レートよりも高いバースト配信レートでの前記配信サーバから前記ＵＥへのデータの配信を可能にするために、前記ネットワークセッションが開かれた後は、前記ネットワークセッションの帯域幅をより高い帯域幅に増やすようになされ、前記配信サーバが、前記ネットワークセッション中の任意の時間に使用可能なネットワーク帯域幅に応じて変化するバースト配信レートを提供するために、前記ＲＡＣＳが前記配信サーバに優先しつつ、前記ＲＡＣＳから独立して、前記ネットワークセッションに割り当てられる帯域幅を公称帯域幅よりも上に動的に変化させるようになされた、ネットワーク。
【請求項２】
前記ＵＥが、前記配信サーバから受信されたデータが格納される間もデータ配信が継続することができるような、前記配信サーバから受信されたデータを格納するためのデータ格納手段を備える、請求項１に記載のネットワーク。
【請求項３】
前記ＵＥがＩＰＴＶ装置である、請求項１または２に記載のネットワーク。
【請求項４】
ネットワークが許容する限り高いバースト配信レートを提供するように、前記配信サーバが帯域幅を使用可能な最大帯域幅まで増やすようになされた、請求項１から３のいずれか一項に記載のネットワーク。
【請求項５】
前記配信サーバが徐々に帯域幅を増やすようになされた、請求項１から４のいずれか一項に記載のネットワーク。
【請求項６】
前記ＵＥがフィードバックを前記配信サーバに提供するようになされた、請求項５に記載のネットワーク。
【請求項７】
前記配信サーバが、徐々に帯域幅を増やすようになされ、バースト配信レートを前記配信サーバと前記ＵＥの間の接続に適した速度に制限するために、前記ＵＥによって受信されるコンテンツの状態を示すフィードバックを受信する手段を含む、請求項６に記載のネットワーク。
【請求項８】
前記ＵＥが、紛失データを検出するように、および、再伝送フィードバック機構を使用して前記配信サーバまたはネットワークに紛失パケットを要求するようになされた、請求項１から７のいずれかに記載のネットワーク。
【請求項９】
前記配信サーバが、再伝送要求が受信されるまで徐々に帯域幅を増やすように、および、再伝送要求が受信された後は、再伝送要求が受信されなくなるまで帯域幅を減らすようになされた、請求項８に記載のネットワーク。
【請求項１０】
前記配信サーバが、再伝送要求に従って、帯域幅を周期的に増やすおよび減らすようになされた、請求項９に記載のネットワーク。
【請求項１１】
ネットワークを介したコンテンツ配信方法であって、前記ネットワーク上のＵＥ（ユーザ装置）デバイスと配信サーバの間のネットワークセッションにＲＡＣＳ（リソースおよび管理制御サーバ）によって割り当てられるネットワーク帯域幅を修正することを備え、ネットワークセッションが開かれるときに前記ＲＡＣＳによって前記ネットワークセッションのための公称帯域幅が予約され、それによりＱｏＳが保証される公称レートでの配信サーバからＵＥへのデータの配信が可能になり、公称レートよりも高いバースト配信レートでの前記配信サーバから前記ＵＥへのデータの配信を可能にするために、前記ネットワークセッションが開かれた後は、前記ネットワークセッションの帯域幅がより高い帯域幅に増やされ、前記ネットワークセッション中の任意の時間に使用可能なネットワーク帯域幅に応じて変化するバースト配信レートを提供するために、前記配信サーバが、前記ＲＡＣＳが前記配信サーバに優先しつつ、前記ＲＡＣＳから独立して、前記ネットワークセッションに割り当てられる帯域幅を公称帯域幅よりも上に動的に変化させる、方法。
【請求項１２】
ネットワークが許容する限り高いバースト配信レートを提供するために、前記配信サーバが帯域幅を使用可能な最大帯域幅まで増やす、請求項１１に記載の方法。
【請求項１３】
前記配信サーバが帯域幅を徐々に増やし、前記配信サーバと前記ＵＥの間の接続に適した速度にバースト配信レートを制限するために、フィードバックが前記ＵＥから前記配信サーバによって受信され、配信されたときのコンテンツの状態を示す、請求項１１に記載の方法。
【請求項１４】
コンテンツのプレイバックまたは受信が休止されるまたは中断される間にも、配信が持続される、請求項１１から１３のいずれかに記載の方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、配信ネットワークにおける帯域幅利用の最適化に関する。特に、本発明は、ネットワークセッションのために予約されるネットワークリソースが使用可能なネットワークリソースに従って変化されることができる、マルチメディア配信ネットワークに関する。本発明は、オンデマンドマルチメディア配信、ゲーミング、コンテンツ共用、または、サービス品質（ＱｏＳ）を要求する他のサービスに適用可能となり得る。
【背景技術】
【０００２】
競争力のあるサービス品質を提供し、既存の顧客を維持し、新しい顧客に訴えるために、ＩＰＴＶ（インターネットプロトコルテレビ）および増加するＯＴＴ（オーバーザトップ）のサービスプロバイダは、配信ネットワークによって提供される、ＱｏＳ（サービス品質）に依存して、マルチメディアコンテンツおよびサービスを配信する。かかるサービスの例は、ＩＰＴＶビデオオンデマンド、インターネットビデオ共用サイトからのビデオ、およびブロードキャストＴＶを含み、それらすべてはインターネットプロトコル（ＩＰ）ネットワークを介して配信されることができる。サービス品質（ＱｏＳ）は、確実にマルチメディアコンテンツがよいタイミングで配信され、ユーザがそれを見ている間に損なわれないようにすることを必要とされる。ＱｏＳを達成するために、ネットワーク構成要素は、必要なリソース（ネットワーク帯域幅など）を予約することができ、予約されたリソースをマルチメディアコンテンツの配信に専用にする。
【０００３】
たとえば、ＩＰＴＶ解決法を考えると、これらは一般に、ネットワークリソース制御サブシステムでマルチメディア配信を統合することによってＱｏＳを保証し、安定した符号化ビットレートでマルチメディアを配信する。
【０００４】
この手法を使用するリソース解放フローが、図６に概略的に示されている。これは、３つの素子、リソースおよび管理制御サーバ（ＲＡＣＳ）２０、ユーザ装置（ＵＥ）１０（顧客のセットトップボックスなど）、ならびに、コンテンツオンデマンド（ＣｏＤ）サーバ３０を示す。ＴＣＰ接続が、リアルタイムストリーミングプロトコル（ＲＴＳＰ）セッションのために行われる。コンテンツは次に、ＣｏＤ  ＭＦ（メディア機能）３０からＵＥに、固定レートでストリームされる。ストリーミングが完了したとき、ＲＴＳＰ  ＴＥＡＲＤＯＷＮメッセージ（ＲＦＣ２３２６に定義されるような）が送信され、コンテンツストリームが終了され、ＣｏＤ  ＭＦ３０がＲＡＣＳ２０に要求を送信して、割り当てられたネットワークリソースを解放する。次に、セッションが完了したというメッセージが、ＵＥに送信される。
【０００５】
しかし、このフローは、サービスセッションの全持続期間について公称サービスビットレート（たとえば、マルチメディアコンテンツのマルチメディア符号化ビットレート）でネットワークリソースが予約されることを必要とし、サービスセッションおよびネットワークＱｏＳセッションが効率的に連結され、同一の持続期間をもつことを意味する。
【０００６】
たとえば、ＩＰＴＶ  ＣｏＤ（コンテンツオンデマンド）サービスの場合、図６に示すように、ネットワーク帯域幅（ＢＷ）は、サービスセッションの全持続期間についてマルチメディア符号化ビットレートで予約される。
【０００７】
この予約されたネットワーク帯域幅（ＢＷ）はしばしば、そのサービスセッションの間（たとえば、ユーザがいつでも彼の都合で休止することを望むことができる−休止の間）の期間について使用されない。従って、知られている配信ネットワークでは、リソース予約は必要以上に長く保持され、有効なネットワーク容量が減らされる。さらに、ネットワークは、低いネットワーク需要の期間中などの短期間について予約されない、追加リソースをもち得る。ネットワークセッションのコンテンツが符号化ビットレートでのみ配信される場合、これらのリソースは実際には未使用である。
【発明の概要】
【発明が解決しようとする課題】
【０００８】
本発明は、改良された配信ネットワークを提供する目的で生まれた。
【課題を解決するための手段】
【０００９】
本発明によれば、第１の態様で、マルチメディア配信ネットワークが提供され、そのネットワーク上のＵＥ（ユーザ装置）デバイスと配信サーバの間のネットワークセッションに帯域幅を割り当てるためのネットワークリソース割当て手段を備え、その割当て手段は、セッションが開かれるときにネットワークセッションのための公称帯域幅を予約するようになされ、それにより公称サービスレートで配信サーバからＵＥへのデータの配信が可能になり、その配信サーバは、公称レートよりも高いバースト配信レートで配信サーバからＵＥへのデータの配信を可能にするために、セッションが開かれた後はより高い帯域幅にセッションの帯域幅を増やすようになされる。
【００１０】
これは、ネットワーク容量が増やされ、より効率的に使用されることを可能にする。コンテンツは以前に提案された方式でよりも速く配信されることができるため、それはリソースがより早く解放されることも可能にする。
【００１１】
データが配信される最大帯域幅は、使用可能なネットワーク帯域幅に依存し得る。
【００１２】
好ましくは、ＵＥは、配信サーバから受信されるデータを格納するためのローカルデータ格納手段を提供される。ＵＥは、ＩＰＴＶ、インターネットＴＶ、ケーブルまたは他の装置でもよい。
【００１３】
それによって、コンテンツのプレイバックがユーザによって休止された場合でも、コンテンツ配信は継続し、要求されるまでローカルにキャッシュされる。
【００１４】
配信サーバは、好ましくは、ネットワークセッション中の任意の時間に使用可能なネットワーク帯域幅に応じて変化するバースト配信レートを提供するために、使用可能なネットワーク帯域幅に応じて、公称帯域幅を超えるようにネットワークセッションに割り当てられる帯域幅を動的に変化させるようになされる。
【００１５】
配信サーバは、ネットワークが許す限り高いバースト配信レートを提供するために、帯域幅を使用可能な最大帯域幅まで増やすようになされることができる。
【００１６】
ＵＥは、配信サーバにフィードバックを提供するようになされることができる。ＵＥは、再伝送手法およびＲＴＰ／ＲＴＣＰ（リアルタイムプロトコル／リアルタイム制御プロトコル）フィードバック機構を使用して、紛失データを検出し、紛失パケットを配信サーバまたはネットワークに要求するようになされることができる。もともと伝送されたものが損なわれているまたは不完全であることをＵＥが発見した場合、要求に応じて１つまたは複数のパケットまたはコンテンツの部分（ビデオフレームなど）が再伝送されることができるように、再伝送は、コンテンツをキャッシュする、再伝送（Ｒｅｔｒ）サーバを使用することができる。
【００１７】
配信サーバは、徐々に帯域幅を増やすようになされることができる。
【００１８】
配信サーバは、バースト配信レートを配信サーバとＵＥの間の接続に適した速度に制限するために、配信サービスによって受信されたフィードバックの結果を待ち、徐々に帯域幅を増やすようになされることができる。
【００１９】
配信サーバは、再伝送要求が受信されるまで徐々に帯域幅を増やすようになされることができ、そして、再伝送要求が受信された後は、再伝送要求がもう受信されなくなるまで徐々に帯域幅を減らすようになされることができる。配信サーバは、再伝送要求に従って、帯域幅を周期的に増やすおよび減らすようになされることができる。
【００２０】
本発明によれは、さらなる一態様で、ネットワークを介したコンテンツ配信方法が提供され、そのネットワーク上のＵＥ（ユーザ装置）デバイスと配信サーバの間のネットワークセッションに割り当てられるネットワーク帯域幅を修正することを備え、そこでは、セッションが開かれるときにネットワークセッションの公称帯域幅が予約され、それにより配信サーバからＵＥへの公称サービスレートでのデータの配信が可能になり、セッションが開かれた後には、配信サーバからＵＥへの公称レートよりも高いバースト配信レートでのデータの配信を可能にするように、セッションの帯域幅がより高い帯域幅まで増やされる。
【００２１】
コンテンツは一般にマルチメディアコンテンツになろうが、他のタイプのコンテンツでもよい。
【００２２】
配信サーバは、ネットワークセッション中の任意の時間に使用可能なネットワーク帯域幅に応じて変化するバースト配信レートを提供するために、使用可能なネットワーク帯域幅に応じて、ネットワークセッションに割り当てられる帯域幅を公称帯域幅よりも上に動的に変化させることができる。
【００２３】
配信サーバは、ネットワークが許す限り高いバースト配信レートを提供するために、その帯域幅を使用可能な最大帯域幅まで増やすことができる。別法として、配信サーバは、帯域幅を徐々に増やすことができる。
【００２４】
ＵＥは、配信サーバにフィードバックを提供することができる。配信サーバは、バースト配信レートを配信サーバとＵＥの間の接続に適したレートに制限するために、配信サーバによって受信されるフィードバックの結果を待ち、徐々にその帯域幅を増やすことができる。
【００２５】
ＵＥは、配信サーバまたはネットワークに、再伝送手法およびＲＴＰ／ＲＴＣＰフィードバック機構を使用して、任意の紛失パケットを要求することができる。
【００２６】
配信サーバは、再伝送要求が受信されるまで徐々に帯域幅を増やすことができ、また、再伝送要求が受信された後は、再伝送要求が受信されなくなるまで徐々に帯域幅を減らすことができる。
【００２７】
従って、バースト配信の速度が高信頼の配信のためには速すぎることが発見された場合、それは減速されるまたは高信頼の配信をまだ提供する最高レートまで減らされることができる。
【００２８】
配信サーバは周期的に、再伝送要求に従って、帯域幅を増やすまたは減らすことができる。
【００２９】
本発明はまた、本明細書で開示されるいずれかの１つまたは複数の新しい特徴、特徴の組合せ、ステップ、またはステップの組合せを含む、ネットワークまたは方法を提供する。
【００３０】
本発明の実施形態が、以下の添付の概略図を参照して、例示のみを目的として、ここで説明される。
【図面の簡単な説明】
【００３１】
【図１】本発明によるネットワークを概略的に示す図である。
【図２】図１のネットワーク内の例示的なリソースフローの説明図である。
【図３】どのように配信レートがネットワークセッション中の時間に対して変化し得るかを概略的に示す図である。
【図４】どのように配信レートがネットワークセッション中の時間に対して変化し得るかの代替例を概略的に示す図である。
【図５】どのように配信レートがネットワークセッション中の時間に対して変化し得るかのさらに別の例を概略的に示す図である。
【図６】先行技術のネットワークにおけるリソースフローを示す図である。
【発明を実施するための形態】
【００３２】
図１を参照すると、本発明に従って動作するネットワーク構成が示されている。ＵＥ１、この場合にはＩＰＴＶ  ＵＥ（セットトップボックスにディスプレイなど）、がネットワークに接続されて、そのネットワークからデータを受信する。ＵＥ１は、ネットワークから受信されたデータがＵＥ１にローカルに格納されることができるように、ソリッドステートメモリ、ハードディスクドライブ、または同様のものなどの関連メモリを備える。これは、一体型でもよく、あるいは、ＵＥと、ローカルに、ハードリンクによって、無線で接続される、または他の方法で関連付けられることができる。単一のＵＥ１のみが示されているが、ＵＥ１の間で共用されるネットワークリソースをもつ、ネットワークに接続された多数のＵＥ１が一般には存在することになることを理解されたい。
【００３３】
ネットワークは、ＮＧＮ（次世代ネットワーク）、即ち音声、データ、およびビデオを含むがこれらに限定されないすべてのタイプの顧客トラフィックをサポートするためにＩＰおよびＱｏＳ（サービス品質）技術を使用して設計されたネットワーク、であり、さまざまなＩＰベースの顧客デバイスならびに次世代のおよび高度のアプリケーションが単一の共通のネットワークを介して通信することを可能にする。
【００３４】
このネットワークは、ネットワークリソース割当て手段２、この場合にはＩＰＴＶミドルウェア２９およびＲＡＣＳ（リソースおよび管理制御サーバ）２６、配信サーバ３、この場合にはＣｏＤサーバ、ならびに、ＢＧＦ（境界ゲートウェイ制御機能）デバイス４を備える。これらは図１に概略的に示されている。
【００３５】
代替ネットワーク構成が本発明の範囲内で可能であることが、当業者には容易に理解されよう。
【００３６】
図２を参照すると、マルチメディアオンデマンドネットワークセッション中の図１のネットワーク上のリソースフローが示されている。図３は、本例で、どのように配信レートが時間に対してネットワークセッションに割り当てられるリソースの変化により変化し得るかを示す。
【００３７】
制御接続（ネットワークセッション）が、ＵＥ１とＣｏＤサーバの間に開かれる。これは、図３のグラフ上に点Ａとして示されている。この場合、ＵＥ１とＣｏＤサーバの間の配信機構はＴＣＰ（伝送制御プロトコル）である。しかし、例を参照して後で説明されるように、本発明は同様に、ＵＤＰ（ユーザデータグラムプロトコル）を含むがこれに限定されない、代替配信機構に適用可能である。制御接続は、ＵＥ１でマルチメディアオンデマンドサービスを要求するユーザによって開かれる。その要求は、ＲＡＣＳと接続され、ネットワークリソース（ネットワーク帯域幅）を予約する、ＩＰＴＶミドルウェアに送信される。そのネットワークリソースは、要求されたマルチメディアオンデマンドサービスの公称サービスレート（マルチメディア符号化ビットレートなど）で、たとえば２Ｍｂ／ｓで、制御接続の持続期間について予約される。公称サービスレートは、図３に破線で示されている。予約された必要なネットワークリソース、およびそれによって保証される公称サービスレートで、ネットワークセッションの持続期間について、ＱｏＳが保証される。
【００３８】
制御接続が開かれた後は、ＣｏＤサーバが、ネットワークセッションに割り当てられるネットワークリソースを使用可能なネットワークリソース（図３の点Ｂ）に依存する公称ネットワークリソースよりも上に増やす。これは、公称レートよりも高い、バースト配信レートでのＵＥ１へのコンテンツのストリーミングを可能にする。
【００３９】
ＣｏＤサーバは、「ベストエフォート」手法（「ベストエフォート」オーバレイ）を使用していずれかの使用可能な（未使用の）ネットワークリソースを活用する。ＣｏＤサーバが、ＲＡＣＳとは無関係に追加のリソースをネットワークセッションに割り当てる。従って、ＲＡＣＳは公称レートでリソースを予約するおよび割り当てる（ＱｏＳを保証する）責任を負うが、ＲＡＣＳによって１つまたは複数の任意のネットワークセッションに割り当てられなかった、またはそのために予約されていなかった、追加のネットワークリソースを割り当てる責任を負うのはＣｏＤサーバである。これらのリソースの使用は、バースト配信レートでの配信を可能にする。ＲＡＣＳは、割り当てられていない／予約されていない帯域幅のＣｏＤサーバによる割当てを認識せず、ＣｏＤサーバに優先する、即ちＣｏＤサーバによるバースト配信のための割り当てられていない／予約されていない帯域幅の使用は他のいずれのネットワークセッションのＱｏＳにも影響を与えないことになる。ＲＡＣＳがＣｏＤサーバによって使用されている帯域幅を割り当てて／予約してバースト配信を提供する（ＣｏＤサーバが使用していることをそれが認識していない）場合、そのとき追加の帯域幅は単にもはやＣｏＤサーバに使用可能ではないことになる。しかし、ネットワークセッションの帯域幅は、公称予約レベル未満には下がらない。
【００４０】
配信方法がＴＣＰである、この場合には、バースト配信レートは好ましくは、ネットワークが許す最大速度まで上げられる。しかし、それに続く例と図４および５を参照して、以下に説明されるような、代替構成では、バースト配信レートは徐々に上げられることができる。
【００４１】
公称レートを超えて配信される、超過コンテンツ、またはコンテンツ全体さえも、ＵＥ１にローカルに格納される。
【００４２】
ＣｏＤサーバは、すべてのコンテンツがＵＥ１によって受信されるまで連続的にＵＥ１にコンテンツを配信する。特に、ストリーミングコンテンツがＵＥ１でユーザによって休止されるまたは同様のときも、コンテンツは配信され、そして、たとえばプレイバックが休止されている間もそれはＵＥに（またはそれと関連するメモリ手段に）キャッシュされる。
【００４３】
コンテンツはＵＥ１にローカルに格納されるので、いわゆるトリックプレイ（早送り、巻戻し、休止など）が本発明によって対応される。
【００４４】
すべてのコンテンツがＵＥ１に配信された後は、ＣｏＤサーバは、ネットワークセッションに割り当てられたすべてのリソースを解放する、または、ＩＰＴＶミドルウェアにリソースを解放するように命令する。図３の点Ｃは、リソースの解放を表す。通知がＣｏＤサーバからＵＥ１に送信されてユーザにすべてのコンテンツが配信されたことを通知する。ユーザが手動でＵＥ１でのネットワークセッションを終了する場合にもまた、リソースは解放される。ネットワークリソースは、解放されるとすぐに、必要に応じて、再割当てされることができる。
【００４５】
エンドユーザが見るのを休止するときでさえも、配信は休止しないため、コンテンツは継続的に配信され、公称サービスレート（コンテンツ符号化ビットレートなど）よりも速いレートでキャッシュされ、ネットワーク帯域幅の解放および再使用が以前に提案された方式でよりもはるかに速く生じる。
【００４６】
代替構成では、バースト配信レートが任意の時点でネットワークが許す限りの最大に維持され、コンテンツが可能な限り速くＵＥ１に配信されるように、ＣｏＤサーバが動的に、任意の時間に使用可能なネットワークリソースに応じて、ネットワークセッションに割り当てられるリソースを公称帯域幅よりも上に変化させる。かかる変化は図３には示されていないが、この代替では、点ＢとＣの間のバースト配信レートは使用可能なネットワークリソースに従って動的に変化することになることが、容易に理解されよう。
【００４７】
バースト伝送中、ＵＥ１とＣｏＤサーバの間に再伝送フィードバックが存在することができる。これは、配信機構が信頼できないときの特定の使用、たとえばＵＤＰ、のであり、さらなる例を参照して以下に説明される。ＴＣＰ配信機構の場合、ＴＣＰ確認メッセージが許容時間制限内に受信されないという条件においてバースト配信レートが低減される場合に、再伝送フィードバックが提供されることができるが、再伝送フィードバックの必要性はない。かかるフィードバックは、前述の「ベストエフォート」技法と使用されることができる。
【００４８】
ネットワークセッションは、コンテンツ配信の持続期間に持続するＱｏＳセッションを使用する。バースト配信では、コンテンツは、コンテンツの持続期間よりも短い期間内に配信されることができるので、マルチメディア配信セッションおよびＱｏＳセッションは効率的に分離されることができる。結果として、ネットワークリソースは、ＱｏＳに影響を与えることなしに、早く解放されることができる。
【００４９】
本発明の範囲内にあるさまざまな例が説明される。
【００５０】
先に説明したような、ＴＣＰ配信方法の代わりに、ＵＤＰ配信方法が使用されることができる。この場合、フィードバック機構が提供され、前述のように、ネットワークによって許容される最大まで配信レートを上げるのではなくて、配信レートは、フィードバックを待ち、徐々に公称アセット符号化ビットレートを超えて上げられることができる。
【００５１】
フィードバックがないときは、配信レートは継続的に徐々に上げられることができる。図４は、点Ｂからネットワークによって許容される最大まで継続的に徐々に上がる配信レートをもつ、かかる構成で時間に対してネットワークセッションに割り当てられるリソースの変化により配信レートがどのように変化し得るかを示す。斬新的な増加が図４には直線で示されているが、その増加は、等しいまたはさまざまであり得る、斬新的ステップ（図５に見られるような）ででもよいことを理解されたい。
【００５２】
配信レートはまた、周期的にフィードバックを待ち、ＩＰＴＶミドルウェアで、または各増加の後に、徐々に上げられることもできる。
【００５３】
任意の構成で、符号化／提示レートより上の帯域幅でＵＥ１によって受信されるマルチメディアデータは、先に説明したように、ＵＥ１に格納されることができる。
【００５４】
本明細書で説明する構成のいずれかに定義されるように、ネットワークは、ＵＥが任意の時点で紛失データを検出したときに、ＵＥが再伝送手法およびＲＴＰ／ＲＴＣＰ（リアルタイムプロトコル／リアルタイム制御プロトコル）フィードバック機構または同様のものを使用して紛失パケットを要求することができる、再伝送機構を備えることができ、そして、ネットワークかＣｏＤサーバのいずれかが、ＣｏＤサーバに使用可能なフィードバックで、紛失パケットを再送信することになる。
【００５５】
再伝送要求を受信したとき、ＣｏＤサーバからの伝送レートは、再伝送要求が停止するまで下げられることができる。再伝送要求が停止した後は、伝送レートは再び上げられることができる。その上げ下げは、再伝送要求に基づいて、周期的でもよい。従って、配信のレートは、高信頼の配信が生じる限界まで上げられることができる。
【００５６】
図５は、そこで再伝送要求が受信される、構成で時間に対して配信レートがどのように変化し得るかを示す。配信レートは直接的に、ネットワークセッションに割り当てられるネットワークリソースに依存している。ネットワークセッションは点Ａで開かれ、ネットワークセッションに割り当てられるネットワークリソースは、公称ネットワークリソースを超えて点Ｂで第１の増加レベルまで増やされる。点Ｂ１で、再伝送要求が受信されないため、ネットワークリソースがさらに増やされる。再び、再伝送要求が受信されないため、さらなる増加が点Ｂ２で生じる。点Ｂ３で、再伝送要求の受信に続いて、ネットワークリソースが低減されて、バースト配信レートは再伝送要求が受信されなかった前のレベルまで下げられる。点Ｂ４で、再伝送要求がないことに続いて、ネットワークリソースおよびバースト配信レートは再び増やされる。点Ｂ５で、再伝送要求の受信に続いて、配信レートおよびバースト配信レートは、再伝送要求が受信されなかった前のレベルまで低減される。図示されている構成では、このリソースレベルは次に維持され、すべてのコンテンツが配信され、点Ｃでリソースが解放されるまで、接続によって許容される最大高信頼レートでバースト配信レートを維持する。代替構成では、再伝送要求に続く帯域幅を増やすための多少の試みが行われることができる。さらには、ステップは同等のものとして図示されているが、各ステップでの帯域幅の増加は異なることがあり、そして／または、増加と次の再伝送要求の間の時間は異なることがあるため、これはそうである必要はないことを理解されたい。第１の増加は、その接続による、適切な最大配信レートが判定されるまでのその後の減少をもつ、ネットワークによって許容される最高レートまででもよい。
【００５７】
本発明の好ましい実施形態は、プレイバック休止または他の要因が配信の休止の原因にならないため、ユーザ経験を低下させることなしに、サービス中により早いネットワークＱｏＳセッションの解放を可能にし、解放されたネットワークリソースは他のサービスのために使用されることができる。本発明はまた、ネットワーク利用を最適化することができ、ネットワーク容量、特にボトルネックがしばしば生じるコアネットワークの容量、の増加をもたらし、サービスセッションの持続期間を下線を引いたＱｏＳネットワークセッションから分離する。それはＩＰＴＶおよびＯＴＴＰサービスに適用可能であり、ダウンロードトラフィックのバースト特質を保存する一方で使用可能な帯域幅を飽和状態にするＯＴＴＰサービスのＱｏＳを可能にする。
【００５８】
本発明の好ましい実施形態が、オンデマンドマルチメディア配信、即ちオンデマンドＩＰＴＶ、に関して説明されたが、本発明は、ゲーミングおよびコンテンツ共用を含むがこれらに限定されない、ＱｏＳを要求する任意のサービスに適用可能であることに留意されたい。
【図１】
0005302415.tif 000002
【図２】
0005302415.tif 000003
【図３】
0005302415.tif 000004
【図４】
0005302415.tif 000005
【図５】
0005302415.tif 000006
【図６】
0005302415.tif 000007