(57)【特許請求の範囲】
【請求項１】
通信リンクのダウンロードスループットを動的に最大化する輻輳制御方法であって、
同時ダウンロードセッションを１もしくはそれ以上のＵＲＬから動的に生成および削除するステップと、
前記リンクの全体的な輻輳状況を継続的に監視するステップによって各セッションのデータチャンクのサイズを動的に変更するステップと
を有する輻輳制御方法において、
前記監視するステップは、
同時ダウンロードセッションの数と各セッションの継続時間とを定義する現行ストラテジーを選択するステップと、
前記現行ストラテジーを使用してデータを前記１もしくはそれ以上のＵＲＬからダウンロードするステップと、
前記定義された数の同時ダウンロードセッションがアクティブであるかどうかと、前記現行ストラテジーを新しいストラテジーに置き換えるべきかどうか、とを周期的にチェックするステップとを有し、前記現行ストラテジーを置き換えるべきかどうかを前記周期的にチェックする前記ステップは、ストラテジー変更が前回の周期中に実行されたかどうかをチェックするステップとそれに基づいてダウンロードスループットをチェックするステップとを含み、さらに、
ストラテジー変更が前記した前回の周期中に実行されていないときのダウンロードスループットをチェックする前記ステップは、
前記現在測定されている合計ダウンロード速度が、最大でも予め定義された割合で、前記現行ストラテジーについて測定された最大ダウンロード速度よりも遅い場合には、前記測定されたダウンロード速度の最低速（ｈｉｇｈｅｓｔ    ｗｏｒｓｔ）を有する新しいストラテジーを選択するステップと、
前記現在測定されている合計ダウンロード速度が、最小でも予め定義された割合で、前記現行ストラテジーについて計算された最適ダウンロード速度よりも速い場合には、最高速（ｈｉｇｈｅｓｔ    ｂｅｓｔ）が予め定義されたダウンロード速度を有する新しいストラテジーを選択するステップと、
新しいチャンクサイズを計算するステップと、を有するものであり、
前記監視するステップは、前記チェックによって、ダウンロードのスループットを効率良く活用できるストラテジーが示された場合に新しいストラテジーを選択するステップと
を有するものである輻輳制御方法。
【請求項２】
請求項１記載の輻輳制御方法において、前記定義された数の同時ダウンロードセッションがアクティブであるかどうかを前記周期的にチェックするステップは、
最初のアクティブセッションが終了した場合に、次のデータチャンクのダウンロードを開始するか、それともセッションを放棄するかを判定するステップと、
次のダウンロードセッションが保留中の場合に、それをアクティブと定義して前記判定するステップを繰り返すステップと、
セッションの現在の数が、前記現行ストラテジーによって定義された前記同時ダウンロードセッションの合計数より小さい場合に、保留中のダウンロードセッションを追加するステップと
を有するものである輻輳制御方法。
【請求項３】
請求項１記載の輻輳制御方法において、ストラテジー変更が前記した前回の周期中に実行されたときのダウンロードスループットをチェックする前記ステップは、
現在測定されている合計ダウンロード速度が前回の周期に測定された合計ダウンロード速度よりも速い場合に、目標同時セッションの数の増加を有する新しいストラテジーを選択するステップと、
新しいチャンクサイズを計算するステップと
を有するものである輻輳制御方法。
【請求項４】
請求項３記載の輻輳制御方法において、前記目標同時セッションの数の増加は、前記現在測定されている合計ダウンロード速度と前記前回の周期に測定された合計ダウンロード速度との差に基づいて計算される輻輳制御方法。
【請求項５】
通信リンクのダウンロードスループットを動的に最大化する輻輳制御システムであって、
ダウンロード・セッション・コントローラーであって、パラレル・データ・ストリームを１もしくはそれ以上のＵＲＬから動的に生成および削除するように構成されていて、
前記リンクの全体的な輻輳状況を継続的に監視するステップによって各ストリームのデータフラグメントのサイズを動的に変更するように構成されている、
前記ダウンロード・セッション・コントローラーを有する輻輳制御システムにおいて、
前記ダウンロード・セッション・コントローラーは、
同時ダウンロードセッションの数と各セッションの継続時間とを定義する現行ストラテジーを選択する手段と、
前記現行ストラテジーを使用してデータを前記１もしくはそれ以上のＵＲＬからダウンロードする手段と、
前記定義された数の同時ダウンロードセッションがアクティブであるかどうかと前記現行ストラテジーを新しいストラテジーに置き換えるべきかどうかとを周期的にチェックする手段とを有し、前記現行ストラテジーを置き換えるべきかどうかを周期的にチェックする前記手段は、ストラテジー変更が前記した前回の周期中に実行されたかどうかチェックする手段とそれに基づいてダウンロードスループットをチェックする手段とを含み、さらに、
ストラテジー変更が前記した前回の周期中に実行されていないときのダウンロードスループットをチェックする前記手段は、
前記現在測定されている合計ダウンロード速度が、多くても予め定義された割合で、前記現行ストラテジーについて測定された最大ダウンロード速度よりも遅い場合には、前記測定されたダウンロード速度の最低速（ｈｉｇｈｅｓｔ    ｗｏｒｓｔ）を有する新しいストラテジーを選択する手段と、
前記現在測定されている合計ダウンロード速度が、少なくても予め定義された割合で、前記現行ストラテジーについて計算された最適ダウンロード速度よりも速い場合には、最高速（ｈｉｇｈｅｓｔ  ｂｅｓｔ）が予め定義されたダウンロード速度を有する新しいストラテジーを選択する手段と、
新しいチャンクサイズを計算する手段と、を有するものであり、
前記ダウンロード・セッション・コントローラーは、前記チェックによって、ダウンロードのスループットを効率良く活用できるストラテジーが示された場合に新しいストラテジーを選択する手段と
を有するものである輻輳制御システム。
【請求項６】
請求項５記載の輻輳制御システムにおいて、前記定義された数の同時ダウンロードセッションがアクティブであるかどうかを前記周期的にチェックする手段は、
最初のアクティブセッションが終了した場合に、次のデータチャンクのダウンロードを開始するか、それともセッションを放棄するかを判定する手段と、
次のダウンロードセッションが保留中の場合に、それをアクティブと定義して前記判定するステップを繰り返す手段と、
セッションの現在の数が、前記現行ストラテジーによって定義された前記同時ダウンロードセッションの合計数より小さい場合に、保留中のダウンロードセッションを追加する手段と
を有するものである輻輳制御システム。
【請求項７】
請求項５記載の輻輳制御システムにおいて、ストラテジー変更が前記周期中に実行されたときのダウンロードスループットをチェックする前記手段は、
現在測定されている合計ダウンロード速度が前回の周期に測定された合計ダウンロード速度よりも速い場合に、目標同時セッションの数の増加を有する新しいストラテジーを選択する手段と、
新しいチャンクサイズを計算する手段と
を有するものである輻輳制御システム。
【請求項８】
請求項７記載の輻輳制御システムにおいて、前記目標同時セッションの数の増加は、前記現在測定されている合計ダウンロード速度と前記前回の周期に測定された合計ダウンロード速度との差に基づいて計算される輻輳制御システム。
【請求項９】
コンピューター可読プログラムが組込まれたコンピューター可読記憶媒体であって、
前記コンピューター可読プログラムはパラレル・データ・ストリームを１もしくはそれ以上のＵＲＬから動的に作成および削除するよう構成されていて、
前記リンクの全体的な輻輳状況を継続的に監視して各ストリームについてデータのサイズを動的に変更するように構成されている、前記コンピューター可読プログラムを格納し、
前記コンピューター可読プログラムは、
同時ダウンロードセッションの数と各セッションの継続時間とを定義する現行ストラテジーを選択し、
前記現行ストラテジーを使用してデータを前記１もしくはそれ以上のＵＲＬからダウンロードし、
前記定義された数の同時ダウンロードセッションがアクティブであるかどうかと前記現行ストラテジーを新しいストラテジーに置き換えるべきかどうかとを周期的にチェックし、前記現行ストラテジーを置き換えるべきかどうかを周期的にチェックすることは、ストラテジー変更が前記した前回の周期中に実行されたかどうかチェックすることとそれに基づいてダウンロードスループットをチェックすることとを含み、さらに、
ストラテジー変更が前記した前回の周期中に実行されていないときのダウンロードスループットを前記チェックすることは、
前記現在測定されている合計ダウンロード速度が、多くても予め定義された割合で、前記現行ストラテジーについて測定された最大ダウンロード速度よりも遅い場合には、前記測定されたダウンロード速度の最低速（ｈｉｇｈｅｓｔ    ｗｏｒｓｔ）を有する新しいストラテジーを選択し、
前記現在測定されている合計ダウンロード速度が、少なくても予め定義された割合で、前記現行ストラテジーについて計算された最適ダウンロード速度よりも速い場合には、最高速（ｈｉｇｈｅｓｔ    ｂｅｓｔ）が予め定義されたダウンロード速度を有する新しいストラテジーを選択し、
新しいチャンクサイズを計算することと、を有するものであり、
前記コンピューター可読プログラムは、前記チェックによって、ダウンロードのスループットを効率良く活用できるストラテジーが示された場合に新しいストラテジーを選択するように構成されている
コンピューター可読記憶媒体。
【請求項１０】
請求項９記載のコンピューター可読プログラムが、さらに、前記定義された数の同時ダウンロードセッションがアクティブであるかどうかを前記周期的にチェックするように構成されているコンピューター可読プログラムにおいて、
最初のアクティブセッションが終了した場合に、次のデータチャンクのダウンロードを開始するかまたはセッションを放棄するかどうかを判定し、
次のダウンロードセッションが保留中の場合に、それをアクティブと定義して前記判定するステップを繰り返し、
セッションの現在の数が、前記現行ストラテジーによって定義された前記同時ダウンロードセッションの合計数より小さい場合に、保留中のダウンロードセッションを追加することと
を有するものであるコンピューター可読記憶媒体。
【請求項１１】
請求項９記載のコンピューター可読プログラムにおいて、ストラテジー変更が前記周期中に実行されたときのダウンロードスループットを前記チェックすることは、
現在測定されている合計ダウンロード速度が前回の周期に測定された合計ダウンロード速度よりも速い場合に、目標同時セッションの数の増加を有する新しいストラテジーを選択し、
新しいチャンクサイズを計算することと
を有するものであるコンピューター可読記憶媒体。
【請求項１２】
請求項１１記載のコンピューター可読プログラムにおいて、前記目標同時セッションの数の増加は、前記現在測定されている合計ダウンロード速度と前記前回の周期に測定された合計ダウンロード速度との差に基づいて計算されるコンピューター可読記憶媒体。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、コンピューターネットワークの分野に関係し、具体的には、かかるネットワークにおけるデータファイルのネットワークに関係する。
【背景技術】
【０００２】
本出願は、２０１２年１０月１８日に出願された米国仮特許出願第６１／７１５、３２２号に関連し請求され、その全ての開示内容が参照によって本願に組み込まれる。
【０００３】
多くのインターネットユーザーが頻繁に遭遇する問題は、動画ストリーミング中の再バッファリングの休止である。この現象は、実際のエンドユーザーのインターネット接続能力/スループットが、消費中のストリーム品質のそれに極めて近い場合、または動画ソースがそのエンドユーザーから離れていて、以下に例示するような、複数のネットワークを通じて交差する必要がある場合に、特に頻繁に生じる。
−  共有のＷｉ−Ｆｉ接続
−  ３Ｇモバイルネットワーク
−  混雑した高速リンク(ケーブル)
−  開発途上国における低質（パケット損失過多）のリンク
−  ローカルＩＳＰ接続が、外部へ向かうＩＳＰ接続よりも強く、完全に活用できない（例えば、エンドユーザーが５ＭｂｐｓのＡＤＳＬラインを有していても、実際のダウンロード速度は２Ｍｂｐｓである）。
−  不十分なルーティング、ただし、サーバーとクライアントの接続は実質的に強い。
【０００４】
ストリーミングプロトコルの輻輳制御機構を調整したり、圧縮レートを調整したり、ストリーミングのビットレートをそのリンクの変更条件に合わせて動的に変更（Ａｄｏｂｅ  Ｈｔｔｐ  Ｄｙｎａｍｉｃ  Ｓｔｒｅａｍｉｎｇ（登録商標））したりして、バッファリングを減らす試みが数多く行われてきた。  
【０００５】
ファイルのダウンロードに複数のストリームを用いることは、以前に提案されているが、そのような試行は、ファイルすべてをダウンロードするか、またはフラグメントダウンロードの計算について再生ビットレートを考慮しながらメディアファイルをストリーミングするかのどちらかに偏った。
【０００６】
Ａｐｐｌｅ  ＨＬＳ（登録商標）、Ｍｉｃｒｏｓｏｆｔ  Ｓｍｏｏｔｈ  Ｓｔｒｅａｍｉｎｇ（登録商標）、またはＭＰＥＧ−ＤＡＳＨなどのアダプティブ・ストリーミング・プロトコルは、同一ファイルの複数バージョン（一般に、異なる品質レベル）を使用して、変動するリンクの帯域幅に適応する。異なる品質レベル間でスムーズなトランジションを実現するには、一般に、ファイルを断片化して、チャンクに分割される。プレーヤーは、特定の品質レベルの対応する断片のリスト（およびその読み出し方、すなわちＵＲＬ／ＵＲＬパターン）を伝えるマニフェストファイルを受信する。続いて、一般的なプレーヤーは、処理能力/帯域幅を測りながら、その断片を順番にダウンロードし始め、それに応じて、品質レベルの変動を判断する。
【発明の概要】
【発明が解決しようとする課題】
【０００７】
本発明は、単一ストリームに関連する問題を最小化することによって効率的に複数の接続のスループットを最大化するために輻輳コントローラーメカニズムを使用する方法を開示することを目的とする。
【課題を解決するための手段】
【０００８】
本発明の観点によると、通信リンクのダウンロードスループットを動的に最大化する輻輳制御方法が提供され、この方法は、同時ダウンロードセッションを１もしくはそれ以上のＵＲＬから動的に生成および削除するステップと、前記リンクの全体的な輻輳状況を継続的に監視するステップによって各セッションのデータチャンクのサイズを動的に変更するステップとを有する。
【０００９】
前記監視するステップは、同時ダウンロードセッションの数および各セッションの継続時間を定義する現行ストラテジーを選択するステップと、データを前記１もしくはそれ以上のＵＲＬから前記現行ストラテジーを使用してダウンロードするステップと、前記定義された数の同時ダウンロードセッションがアクティブであるかどうかと前記現行ストラテジーを新しいストラテジーに置き換えるべきかどうかとを周期的にチェックするステップと、前記チェックによって、ダウンロードのスループットを効率良く活用できるストラテジーが示された場合に新しい現行ストラテジーを選択するステップとをを有することができる。
【００１０】
前記定義された数の同時ダウンロードセッションがアクティブであるかどうかを前記周期的にチェックするステップは、（ａ）最初のアクティブセッションが終了した場合に、次のデータチャンクのダウンロードを開始するか、それともセッションを放棄するを判定するステップと、（ｂ）次のダウンロードセッションが保留中の場合に、それをアクティブと定義して（ａ）のステップを繰り返すステップと、（ｃ）セッションの現在の数が前記現行ストラテジーによって定義された前記同時ダウンロードセッションの合計数より小さい場合に、保留中のダウンロードセッションを追加するステップとを有することができる。
【００１１】
前記現行ストラテジーを新しいストラテジーと置き換えるべきかどうかを前記周期的にチェックするステップは、ストラテジー変更が前記周期中に実行されたときのダウンロードスループットをチェックするステップを有することができて、前記ステップは、前記現在測定されている合計ダウンロード速度が、前回の周期に測定された合計ダウンロード速度よりも速い場合に目標同時セッションの数を増やすステップと、新しいデータのチャンクサイズを計算するステップとを有する。
【００１２】
前記増やすステップは、前記現在測定中されている合計ダウンロード速度と前記前回の周期に測定された合計ダウンロード速度との差に基づいて目標同時セッションの数を増やすステップを有することができる。
【００１３】
前記周期的にチェックするステップは、ストラテジー変更が前記周期中に実行されていないときのダウンロードスループットをチェックするステップを有することができて、前記ステップは、前記現在測定されている合計ダウンロード速度が、多くても予め定義された割合で、前記現行ストラテジーについて測定された最大ダウンロード速度よりも遅い場合に、前記測定されたダウンロード速度の最低速（ｈｉｇｈｅｓｔ  ｗｏｒｓｔ）を有する新しいストラテジーを選択するステップと、前記現在測定されている合計ダウンロード速度が、少なくても予め定義された割合で、現行ストラテジーのために計算された最適ダウンロード速度よりも速い場合は、最高速（ｈｉｇｈｅｓｔ  ｂｅｓｔ）が予め定義されたダウンロードスピードを有する新しいストラテジーを選択するステップと、新しいデータのチャンクサイズを計算するステップとを有する。
【００１４】
本発明の別の観点によると、通信リンクのダウンロードスループットを動的に最大化する輻輳制御システムが提供され、前記システムは、ダウンロード・セッション・コントローラーを有し、前記ダウンロード・セッション・コントローラーは、パラレル・データ・ストリームを１もしくはそれ以上のＵＲＬから動的に生成および削除するように構成されていて、前記リンクの全体的な輻輳状況を継続的に監視するステップによって各ストリームのデータフラグメントのサイズを動的に変更するように構成されている。
【００１５】
前記ダウンロード・セッション・コントローラーはさらに、同時ダウンロードセッションの数および各セッションの継続時間を定義する現行ストラテジーを選択して、前記現行ストラテジーを使用して前記１もしくはそれ以上のＵＲＬからデータをダウンロードして、前記定義された数の同時ダウンロードセッションがアクティブであるかどうかと前記現行ストラテジーを新しいストラテジーに置き換えるべきかどうかとを周期的にチェックして、前記チェックによって、ダウンロードのスループットを効率良く活用できるストラテジーが示された場合に新しいストラテジーを選択するように構成されていてもよい。
【００１６】
前記定義された数の同時ダウンロードセッションがアクティブであるかどうかを周期的にチェックするステップは、（ａ）最初のアクティブセッションが終了した場合に、次のデータチャンクのダウンロードを開始するか、それともセッションを放棄するかを判定するステップと、（ｂ）次のダウンロードセッションが保留中の場合に、それをアクティブと定義して（ａ）のステップを繰り返すステップと、（ｃ）セッションの現在の数が前記現行ストラテジーによって定義された前記同時ダウンロードセッションの合計数より小さい場合に、保留中のダウンロードセッションを追加するステップとを有することができる。
【００１７】
前記現行ストラテジーを新しいストラテジーと置き換えるべきかどうかを周期的にチェックするステップは、ストラテジー変更が前記周期中に実行されたときのダウンロードスループットをチェックするステップを有することができて、前記ステップは、現在測定されている合計ダウンロード速度が、前回の周期に測定された合計ダウンロード速度よりも速い場合に目標同時セッションの数を増やすステップと、新しいデータのチャンクサイズを計算するステップとを有する。
【００１８】
前記増やすステップは、前記現在測定中されている合計ダウンロード速度と前記前回の周期に測定された合計ダウンロード速度との差に基づいて目標同時セッションの数を増やすステップを有することができる。
【００１９】
前記周期的にチェックするステップは、ストラテジー変更が前記周期中に実行されていないときのダウンロードスループットをチェックするステップを有することができ、前記ステップは、現在測定されている合計ダウンロード速度が、多くても予め定義された割合で、現行ストラテジーについて測定された最大ダウンロード速度よりも遅い場合に、前記測定されたダウンロード速度の最低速度（highest  worst）を有する新しいストラテジーを選択するステップと、現在測定されている合計ダウンロード速度が、少なくても予め定義された割合で、現行ストラテジーについて計算された最高ダウンロード速度よりも速い場合に、最高速（highest  best）が予め定義されたダウンロード速度を有する新しいストラテジーを選択するステップと、新しいデータのチャンクサイズを計算するステップとを有する。
【００２０】
本発明の別の態様によると、コンピュータープログラム製品が提供され、前記製品は、コンピューター可読プログラムが組込まれたコンピューター可読記憶媒体と、コンピューター可読プログラムとを有し、前記コンピューター可読プログラムはパラレル・データ・ストリームを１もしくはそれ以上のＵＲＬから動的に作成および削除するよう構成されていて、前記リンクの全体的な輻輳状況を継続的に監視して各ストリームについてデータのサイズを動的に変更するように構成されている。
【００２１】
前記コンピュータープログラム製品はさらに、同時ダウンロードセッションの数および各セッションの継続時間を定義する現行ストラテジー選択して、前記現行ストラテジーを使用して前記１もしくはそれ以上のＵＲＬからデータをダウンロードして、前記定義された数の同時ダウンロードセッションがアクティブかどうかと、その現行ストラテジーを新しいストラテジーと置き換えるべきかどうかとを周期的にチェックして、前記チェックによって、ダウンロードスループットを効率良く活用できる新しいストラテジーが示された場合に新しい現行ストラテジーを選択するように構成されていてもよい。
【００２２】
前記コンピュータープログラム製品はさらに、前記定義された数の同時ダウンロードセッションがアクティブであるかどうかを前記周期的にチェックするように構成されていてよく、これは（ａ）最初のアクティブセッションが終了した場合に、次のデータチャンクのダウンロードを開始するかまたはセッションを放棄するかどうかを判定して、（ｂ）次のダウンロードセッションが保留中の場合に、それをアクティブと定義して（ａ）のステップを繰り返して、（ｃ）セッションの現在の数が前記現行ストラテジーによって定義された前記同時ダウンロードセッションの合計数より小さい場合に、保留中のダウンロードセッションを追加するように構成されていてもよい。
【００２３】
前記コンピュータープログラム製品はさらに、前記現行ストラテジーを新しいストラテジーと置き換えるべきかどうかを前記周期的にチェックするように構成されていてよく、これは、ストラテジー変更が前記周期中に実行されたときのダウンロードスループットをチェックするように構成されていて、これは、前記現在測定されている合計ダウンロード速度が、前回の周期に測定された合計ダウンロード速度よりも速い場合に、目標同時セッションの数を増やして、新しいデータのチャンクサイズを計算するように構成されていてもよい。
【００２４】
前記増やすステップは、前記現在測定中されている合計ダウンロード速度と前記前回の周期に測定された合計ダウンロード速度との差に基づいて目標同時セッションの数を増やすステップを有することができる。
【００２５】
前記周期的にチェックするステップは、ストラテジー変更が前記周期中に実行されていないときのダウンロードスループットをチェックするステップを有することができ、このステップは、前記現在測定されている合計ダウンロード速度が、多くても予め定義された割合で、現行ストラテジーについて測定された最大ダウンロード速度よりも遅い場合に、測定されたダウンロード速度の最低速度（ｈｉｇｈｅｓｔ  ｗｏｒｓｔ）を有する新しいストラテジーを選択するステップと、現在測定されている合計ダウンロード速度が、少なくても予め定義された割合で、現行ストラテジーについて計算された最適ダウンロード速度よりも速い場合に、最高速度（ｈｉｇｈｅｓｔ  ｂｅｓｔ）が予め定義されたダウンロード速度を有する新しいストラテジーを選択するステップと、新しいデータのチャンクサイズを計算するステップを有する。
【図面の簡単な説明】
【００２６】
本発明の実施形態をより良く理解できるように、そしてそれをいかに実行に移すかを示すために、単に実施例として、添付図面を参照に用いる。なお、前記添付図面では類似の番号は、各図面を通して、対応する要素またはセクションを示している。
【００２７】
【図１Ａ】ダウンロードセッションの変数と輻輳コントローラーとを含む代表的なマルチセッション・ダウンロード・コントローラーを含む２つの主要素を図式的に示す。
【図１Ｂ】ペンディングフラグメントのバッファーリストを図式的に示す。
【図２】例示的なセッションコントローラーによって行われる判定プロセスのフローチャートである。
【図３】図４のプロセスによって選択されたストラテジーを実行するプロセスのフローチャートである。
【図４】回線利用を最適化するための最適ストラテジーを判定する輻輳コントローラーの別のプロセスのフローチャートである。
【図５】複数のストリームを使用することが、どのようにパフォーマンスの向上をもたらすかを実証する概略グラフである。
【図６】単一のストリームを使用することによって得られた実際の成果を示すチャートである。
【発明を実施するための形態】
【００２８】
本発明は、単一ストリームに関連する問題を最小化することによって効率的に複数の接続のスループットを最大化するために輻輳コントローラーメカニズムを使用する方法を開示する。
【００２９】
下記の説明および添付図面を通して、次の頭字語が使用される。
ＣＳＣ−現行ダウンロードセッション数（Ｃｕｒｒｅｎｔ  Ｄｏｗｎｌｏａｄ  Ｓｅｓｓｉｏｎｓ  Ｃｏｕｎｔ）
ＴＳＣ−目標ダウンロードセッション数＝現行の全体的なリンク容量（Ｔａｒｇｅｔ  Ｄｏｗｎｌｏａｄ  Ｓｅｓｓｉｏｎｓ  Ｃｏｕｎｔ＝Ｃｕｒｒｅｎｔ  ｏｖｅｒａｌｌ  ｌｉｎｋ  ｃａｐａｃｉｔｙ）
ＰＳＣ−前回のセッション数（Ｐｒｅｖｉｏｕｓ  Ｓｅｓｓｉｏｎ  Ｃｏｕｎｔ）
ＣＤＳ−現行ダウンロード速度（Ｃｕｒｒｅｎｔ  Ｄｏｗｎｌｏａｄ  Ｓｐｅｅｄ）
ＰＤＳ−前回のダウンロード速度（Ｐｒｅｖｉｏｕｓ  Ｄｏｗｎｌｏａｄ  Ｓｐｅｅｄ）
【００３０】
以下のアイテムは、下記の説明を通して使用される。
チャンク−その最初と最後のオフセットによって指定された可変長データセクション。
フラグメント−所定の長さを有するデータセクション。フラグメントは単一のチャンクを有してよく、またはプロセスによって多数のチャンクに分割されてもよい。
各チャンクは、１もしくはそれ以上の範囲リクエストを使用することによって、１もしくはそれ以上のセッションごとにダウンロードできる。加えて、いくつかのチャンクを同時にダウンロードすることができる。
現行フラグメント（ＣＦ）−現在リクエストされているフラグメント。
アクティブフラグメント（ＡＦ）−ダウンロード中のフラグメント。
ペンディングフラグメント（ＰＦ）−プレーヤーがフラグメントをリクエストする前にダウンロードされるフラグメント。
完了間近のフラグメント（ＴＣＦ）−次に完了が見込まれるフラグメントの連続番号（シーケンス番号）。
ペンディングフラグメント数（ＰＦＣ）−ペンディングフラグメントの数。
アクティブ（ＡＣＴＩＶＥ）なペンディングフラグメント数（ＡＰＣ）。
前回のペンディングフラグメント（ＬＰＦ）。
ダウンロードセッション−ＵＲＬ（Ｕｎｉｆｏｒｍ  Ｒｅｓｏｕｒｃｅ  Ｌｏｃａｔｏｒ：ユニフォーム・リソース・ロケーター）からクライアントへのチャンクデータの転送を制御する論理要素。例えば、クライアントとｈｔｔｐ：／／ｗｗｗ．ｙｏｕｔｕｂｅ．ｃｏｍ／との間のＨＴＴＰ接続。ダウンロードセッションは、その接続およびその継続時間によって定義される。
アダプティブセッション−フラグメント全体または所定のフラグメントの可変長チャンクをダウンロードするセッション。
プログレッシブセッション−所定のフラグメントを有していないファイルの可変長チャンクをダウンロードするセッション。
合計ダウンロード速度−時間間隔によって分割された時間間隔中に全てのセッションから取得した合計データ（バイト数）。
ストラテジー−同時ダウンロードセッションの数およびそれぞれの目標ダウンロード継続時間。
【００３１】
各ストラテジーは次の属性を有する。
ａ．currentStrategyBest、これは次によって定義される。
If(currentDownloadSpeed＞currentStarategyBest){currentStarategyBest＝currentDownloadSpeed;}Else{currentStrategyBest＝currentStrategyBest−(currentStrategyBest−currentAverageSpeed)/20);}
ｂ．currentStrategyWorse、これは次によって定義される。
If(currentDownloadSpeed＜currentStarategyWorse){currentStarategyWorse＝currentDownloadSpeed;}Else{currentStarategyWorse＝currentStarategyWorse＋(currentAverageSpeed−currentStarategyWorse)/20;}
ｃ．currentStrategyMaxは、現行ストラテジーがアクティブとして選択されて以来、現行ストラテジーが測定した最大ダウンロード速度によって定義される。
ｄ．currentStrategyMinは、現行ストラテジーがアクティブとして選択されて以来、現行ストラテジーが測定した最小ダウンロード速度によって定義される。
【００３２】
本発明は、リンクのスループットをいつでも最大化するために、ダウンロード中のコンテンツから独立している、またはストリームの変数を同時に使用するその再生レートから独立している、代表的な機構を提供する。
【００３３】
図１Ａは、本発明の例示的な実施形態の主要素を図式的に示す。セッションコントローラー１００は、クライアントアプリケーションに統合されたソフトウェアモジュールまたはクライアントデバイスメーカーによって供給されるオペレーティングシステム／ファームウェアの一部である１つのソフトウェアであってよく、ＵＲＬ（１３０）からのダウンロードセッション１１０の変数を管理することおよび監視することに関与していて、同時セッションの数、各セッションの継続時間、および／またはフラグメントサイズを判別するストラテジーは、輻輳コントローラー１２０によって判別される。
【００３４】
図１Ｂの図式に示されているように、前記セッションコントローラーは、現行フラグメントならびにペンディングフラグメントのリスト（このリストは最初は空である）を保持しているバッファーを収容する。
【００３５】
図２は、例示的なセッションコントローラーによって行われる判定プロセスのフローチャートである。これは、特定のファイルをダウンロードするために、プレーヤーからリクエストを受信する２００ことから始まる。当該プロセスは、まず、前記リクエストされたファイルがプログレッシブまたはアダプティブのどちらのセッション（すなわち、前記ファイルは一定のサイズにあらかじめ分割されている）でダウンロードされるべきかを、前記ファイルのタイプに基づいて、チェックする２０５。前記コントローラーは、当該マニフェスト／プレイリストファイルの情報を有し、現在の品質レベルを読み出す方法を知っているものと仮定する。
【００３６】
当該ダウンロードモードがアダプティブ（すなわち、所定のフラグメントサイズ）であると判定されると、当該プロセスは、第１アクティブセグメントについてアクセラレーションが始まっていないかどうかと残りのダウンロード時間が特定の閾値より長いかどうかとをチェックする２１０。両方の条件を満たすと、アクティブフラグメントのフラグメントアクセラレーションが開始される２２０（図３）。
【００３７】
当該セッションコントローラーは同時に、完了間近のフラグメント（ＴＣＦ）（すなわち、現在ダウンロード完了を前記プロセスが待機しているフラグメント）が完了しているかどうかをチェックする２３０。完了している場合、前記プロセスは、単一フラグメントのダウンロード速度を遅らせることなくダウンロードできるフラグメントの許容同時発生数を、次の公式に基づいて計算する。
【００３８】
許容同時発生数＝（前回完了したフラグメントダウンロード時間／前回完了したフラグメント持続時間）ｘ（ペンディングフラグメントの数＋１）。
【００３９】
前記ＴＣＦ、すなわち、前記プロセスが現在待機しているフラグメントに１が加算される２５０。前記プロセスは続いて、次の条件が真ならば、ペンディングフラグメントを追加すべきかどうかをチェックする２６０。
（ＬＰＦの実行時間は１００ｍｓを超えている｜｜ＬＰＦは完了している）＆＆（ＰＦＣ＜ＭａｘＰｅｎｄｉｎｇＦｒａｇｍｅｎｔｓ）＆＆（許容同時発生数＞ＡＰＣ＋１）｜｜（ＡＰＣ＜許容同時発生数＋１）＆＆（ＬＰＦの残り時間＜ＬＰＦのフラグメント持続時間／（ＰＦＣ＋保証係数））｜｜（ＬＰＦ進捗度＆＞１００−１００／（ＰＣ＋３））。ここで、ＭａｘＰｅｎｄｉｎｇＦｒａｇｍｅｎｔｓはペンディングフラグメントの最大数である。最大値より多いデータは無用であるため、最大値より多く読み出す必要はない。
【００４０】
これらの条件は、現行ダウンロードが、現行ストラテジーによって定義された継続時間の少なくとも一定の割合（保証係数を追加して、無秩序な変動に基づく判別を回避する）まで完了した場合、またはフラグメントサイズによって定義されたバイト数の一定の割合まで完了した場合にのみ、次のダウンロードが開始されることを保証する。
【００４１】
続いて、ペンディングフラグメントが、アクティブ２７０として定義（追加）され、前記プロセスは保守間隔２８０の待機を経て、２１０に戻る。
【００４２】
ＴＣＰプロトコルを使用する場合、合計ダウンロード速度は、パケット損失分の再送量に応じて、ＴＣＰの内部輻輳コントローラーの影響を受けることがある。
【００４３】
前記ダウンロードモードがプログレッシブと判定される場合、第１セッションは、無限継続時間２５５の１フラグメントを有する初期ストラテジーによって定義される。
【００４４】
図３は、図４のプロセスによって選定されたストラテジーを実行するフローチャートである。図３のプロセスが、各所定の時間間隔に呼び出され、当該ＣＳＣ（現行のセッション数）が図４のプロセスによって判定されたものと同等であることを確認し、利用可能な帯域幅を任意の時点で利用するために図４のプロセスを呼び出す。当該プロセスは、現在のダウンロードレートを測定し、それを前回に測定されたダウンロードレートと比較して、実行すべき同時セッション数と各セッションの継続時間を判定する。
【００４５】
ステップ３０５において、当該プロセスは、バイトオフセットでのダウンロードにＵＲＬが対応しているかどうかどうかをチェックする（範囲リクエスト）。部分的なダウンロードに対応している場合、当該プロセスは、アクティブセッションの状態を監視して、当該輻輳コントローラーによってセットされたパラメーターセットに基づいてＣＳＣのセッションを加減する、というループを経由する。セッションコントローラーは、第1セッションをアクティブセッションのリストから引き込み３１５、それが終了している３１７かどうかをチェックする。当該セッションが終了している場合は、現行のセッション数（ＣＳＣ）が目標のセッション数（ＴＳＣ）より大きいかどうかをチェックする３２０。大きい場合は、１セッションを放棄して３２５、次のセッションがある３３５かどうかをチェックして、次のセッションがある場合は、それをアクティブ３４２として選択する。当該プロセスは、続いて、３１７に戻り、第1アクティブセッションが終了しているかどうかをチェックする。そうでなければ、次のセッションがない場合は、当該プロセスは、ＣＳＣがＴＳＣより小さいかどうかをチェックし３４０、小さい場合は、ＣＳＣがＴＳＣと同等になるまで、次のチャンクとともに新しいセッションを追加する３４５。そこから、当該プロセスは図４に進み、現行のストラテジーのパフォーマンスをチェックする。
【００４６】
ステップ３２０において、ＣＳＣは目標のセッション数（ＴＳＣ）より小さいまたは同等であると判定される場合は、すなわち、セッションを追加することができる場合は、当該プロセスは、次のチャンクを現行のセッションに割り当てて３３０、３３５へ進む。
【００４７】
図４は、回線利用を最適化するための最適ストラテジーを判定する輻輳コントローラーのプロセスのフローチャートである。図４のプロセスは、アクティブセッションが、図３のプロセスによってもはや見つからない場合に呼び出される。当該フローチャートは、外部的変更（回線変更）または内部的変更（システムによって行われた前回のストラテジーの変更）を考慮して、最適なストラテジーを選定するプロセスを説明する。
【００４８】
当該プロセスは、前回のＣＳＣの変更から経過した時間が許容時間制限内かどうかをチェックする４００。許容制限時間内ではない場合、タイマーはリセットされる４６０。このチェックの目的は、ストラテジーの変更とその結果生じることをチェックすることとの間に、十分な時間を持たせるためである。
【００４９】
十分な時間が経過すると、当該プロセスは、現行ストラテジーが第1ストラテジーであるかどうか、すなわち、無限継続時間の１セッションを有する初期システムストラテジーであるかどうかをチェックする４２０。そうである場合は、最後のオフセットが第1セッションについてセットされ４０３、セッションの所定数を有する第2初期ストラテジーが選択され４０４、当該プロセスは先へ進み、次の公式に基づいて新しいチャンクサイズを計算する４５０。チャンクサイズ（ＣｈｕｎｋＳｉｚｅ）＝ＣＤＳｘ  時間間隔（ＴｉｍｅＩｎｔｅｒｖａｌ）／ＴＳＣ。ここで、ＴｉｍｅＩｎｔｅｒｖａｌは一般に数秒で、ＴＳＣは前記選択されたストラテジーによって判定される。
【００５０】
現行ストラテジーが第1ストラテジーではない場合、当該プロセスは、ストラテジーが前回のチェック以降に変更したかどうかをチェックする４０５。ストラテジーの変更がない場合、当該プロセスは先へ進み、外部的変更が通信回線に影響を与えたかどうかとストラテジーの変更が必要かどうかをチェックする。当該プロセスは、現行の合計ダウンロード速度（ＣＤＳ）がｃｕｒｒｅｎｔＳｔｒａｔｅｇｙＭａｘ  ｘ  定数１より小さいかどうかをチェックする４１０。ここで、ＣＯＮＳＴ１は割合を示す定数である。例えば、ＣＯＮＳＴ１＝０．８ならば、ステップ４１０は、現行のストラテジーの最大スループットと比較して少なくとも２０％の低下がパフォーマンスにあるかどうかをチェックする。小さいことが断定的である場合、ストラテジーを変更する判定が行われ、最低（ｈｉｇｈｅｓｔ  Ｗｏｒｓｅ）のストラテジーが選択される４１５。続いて、当該プロセスは先へ進み、新しいチャンクサイズを計算する４５０。  
【００５１】
前記現行の合計ダウンロード速度（ＣＤＳ）がｃｕｒｒｅｎｔＳｔｒａｔｅｇｙＭａｘ＊ＣＯＮＳＴ１より小さくない場合は、当該プロセスは、前記現行の合計ダウンロード速度（ＣＤＳ）がｃｕｒｒｅｎｔＳｔｒａｔｅｇｙＢｅｓｔ  ｘ  ＣＯＮＳＴ２より大きいかどうかをチェックする４２０。ここでＣＯＮＳＴ２は割合を示す定数である。例えば、ＣＯＮＳＴ２＝０．９ならば、ステップ４２０は、現行のパフォーマンスが、現行ストラテジーの上限との差が１０％かどうかをチェックして、最高（ｈｉｇｈｅｒ  ｂｅｓｔ）のストラテジーが存在する場合、当該プロセスは、それを選択する必要があると言える。小さくないことが断定的である場合、ストラテジーを変更する判定が行われ、最高（ｈｉｇｈｅｓｔ  Ｂｅｓｔ）のストラテジーが選択される４２５。
【００５２】
ストラテジーの変更が有ろうと無かろうと、当該プロセスは先へ進み、新しいチャンクサイズを計算する４５０。
【００５３】
ステップ４０５において、前回のチェック以降にストラテジー変更が行われていた場合、当該プロセスは先へ進み、ストラテジーの変更が通信回線に影響を与えたかどうかと、他にストラテジー変更が必要かどうかとをチェックする。当該プロセスは、ＣＤＳがＰＤＳ  ｘ  ｌｏｗｅｒＴｈｄ（所定の下限閾値）より大きいかどうか、すなわち、ダウンロード速度が改善されたかどうかをチェックする４３０。改善されている場合、当該プロセスは、ＣＤＳがＰＤＳ  ｘ  ｕｐｐｅｒＴｈｄ（所定の上限閾値）より大きいかどうか、すなわち、ダウンロード速度が劇的に改善されたかどうかをチェックする４３５。続いて、合計セッション数（ＴＳＣ）に、ダウンロード速度の変更量に基づいて、1を加える４４５か、または２を乗じる４４０。次に、新しいチャンクサイズが計算され４５０、タイマーがリセットされる４６０。
【００５４】
ステップ４３０において、ダウンロード速度が前回のストラテジーの変更以降、改善されていないと判定される場合、当該プロセスはステップ４５０へ進み、最適チャンクサイズを再計算してから、タイマーがリセットされる。
【００５５】
図５は、本発明の方法に基づいて複数の動的ストリームを使用することによって得られた実際の成果を示すチャートである。
【００５６】
図６は、単一のストリームを使用することによって得られた実際の成果を示すチャートである。単一のストリームレートは、一時的なパケットの大損失によって大幅に低下することがあるが、複数のストリームを使用する場合は、全体のレートへの影響は大きくない（実際に、多数のストリームであるために、影響は小さくなる）。合計スループットの監視とフラグメントサイズの調整を行わずにストリームを追加することは、全てのストリームがパケット損失を受ける結果になる可能性があり、合計スループットは極めて低質になる。  
【００５７】
当業者に理解されるように、本発明の観点は、システム、方法、またはコンピュータープログラム製品として具現化することができる。したがって、本発明の観点は、完全にハードウェアの実施形態、完全にソフトウェアの実施形態（ファームウェア、常駐ソフトウェア、マイクロコードなど）、または一般に「回路」、「モジュール」、または「システム」として本書にて言及されるソフトウェアおよびハードウェアの態様を組み合わせた実施形態という形をとることができる。さらに、本発明の観点は、１もしくはそれ以上のコンピューター可読媒体にコンピューター可読プログラムコードが組込まれたコンピュータープログラム製品という形をとることができる。
【００５８】
１もしくはそれ以上のコンピューター可読媒体の任意の組み合わせを利用することができる。前記コンピューター可読媒体は、コンピューター可読信号媒体またはコンピューター可読記憶媒体であってもよい。コンピューター可読記憶媒体は、例えば、電子、磁気、光学、電磁気、赤外線、または半導体のシステム、装置、デバイス、または前述の任意の適切な組み合わせであってもよいが、これらに限定されない。コンピューター可読記憶媒体のより具体的な例（非包括的なリスト）には、１もしくはそれ以上のワイヤーを有する電気接続、携帯型コンピューターディスク、ハードディスク、ランダム・アクセス・メモリ（ＲＡＭ）、読取専用メモリ（ＲＯＭ）、消却・プログラム可能型読取専用メモリ（ＥＰＲＯＭまたはフラッシュメモリ）、光学ファイバー、携帯型コンパクトディスク読取専用メモリ（ＣＤ−ＲＯＭ）、光学記憶装置、磁気記憶装置、または前述の任意の適切な組み合わせが含まれる。本書において、コンピューター可読記憶媒体は、命令実行システム、装置、またはデバイスによってまたはそれに関連して使用するためのプログラムを含むまたは記憶できる任意の有形媒体であってもよい。
【００５９】
コンピューター可読信号媒体は、例えば、ベースバンドにまたは搬送波の一部として組み込まれたコンピューター可読プログラムコードを伴う伝搬データ信号を含む。かかる伝搬信号は、電磁気、光学、またはこれらの任意の適切な組み合わせを含む、さまざまなどの形であってもよいが、これらに限定されない。コンピューター可読信号媒体は、コンピューター可読記憶媒体ではなくて、命令実行システム、装置、またはデバイスによってまたはそれに関連して使用するためのプログラムを通信、伝搬、または移送できる任意のコンピューター可読媒体であってもよい。
【００６０】
コンピューター可読媒体に組み込まれたプログラムコードは、ワイヤレス、有線接続、光学ファイバー、無線周波など、または前述の任意の適切な組み合わせを含むがこれに限定されない任意の適切な媒体を使用して伝送されてもよい。
【００６１】
本発明の観点のために動作を実行するコンピュータープログラムコードは、１もしくはそれ以上のプログラミング言語の任意の組み合わせで書いてもよく、これにはＪａｖａ(登録商標である)、Ｓｍａｌｌｔａｌｋ、Ｃ＋＋等のオブジェクト指向プログラミング言語、および「Ｃ」プログラミング言語または同類のプログラミング言語などの従来の手続き型プログラミング言語が含まれる。前記プログラムコードは、ユーザーのコンピューターで完全に、ユーザーのコンピューターで部分的に、スタンドアローン型ソフトウェアパッケージとして、ユーザーのコンピューターで部分的におよび遠隔コンピューターで部分的に、または遠隔コンピューターまたはサーバーで完全に実行してもよい。後者のシナリオにおいて、前記遠隔コンピューターは、ローカル・エリア・ネットワーク（ＬＡＮ）またはワイド・エリア・ネットワーク（ＷＡＮ）を含む任意のタイプのネットワークを介してユーザーのコンピューターに接続していてもよく、またはその接続が（例えば、インターネット・サービス・プロバイダーを使用したインターネットを介して）外部コンピューターに行われてもよい。
【００６２】
本発明の観点は、本発明の実施態様にしたがう方法、装置（システム）、およびコンピュータープログラム製品のフローチャート図および／または部分的な線図を参照して前述されている。当然のことながら、前記フローチャート図および／または部分的な線図の各部分、および前記フローチャート図および／または部分的な線図の各部分の組み合わせを、コンピュータープログラム命令によって実行してもよい。前記コンピュータープログラム命令は、汎用コンピューター、特殊コンピューター、または他のプログラム可能なデータ処理装置のプロセッサーに備えることができて、これにより、前記コンピューターまたは他のプログラム可能なデータ処理装置のプロセッサーを通じて実行する前記命令が、前記フローチャートおよび／または部分的な線図の一部に特定された機能／動作を実行する手段を生み出すようなマシンを作り出すことができる。
【００６３】
また、前記コンピュータープログラム命令は、コンピューター、他のプログラム可能なデータ処理装置、または特有の方法で機能する他のデバイスに指示を出すことができるコンピューター可読媒体に保存することができて、これにより、前記コンピューター可読媒体に記憶された命令（前記フローチャートおよび／または部分的な線図の一部に特定された機能／動作を実行する命令を含む）が、製品を作り出すようにできる。
【００６４】
前記コンピュータープログラム命令は、コンピューター、他のプログラム可能なデータ処理装置、または他のデバイスにロードして、一連の動作ステップが前記コンピューター、他のプログラム可能なデータ処理装置、または他のデバイスで実行されるようにすることができて、これにより、前記コンピューターまたは他のプログラム可能なデータ処理装置で実行する命令が、前記フローチャートおよび／または部分的な線図の一部に特定された機能／動作を実行するプロセスを与えるようなコンピューター実行型プロセスを作り出すことができる。
【００６５】
上記のフローチャートおよび線図は、本発明のさまざまな実施形態に基づくシステム、方法、およびコンピュータープログラム製品において可能な実施例のアーキテクチャ、および機能、動作を図示している。ただし、前記フローチャートまたは部分的線図の各部分は、特定の理論機能を実行するための１もしくはそれ以上の実行可能命令を含むモジュール、セグメント、またはコードの一部を表現していてもよい。代替の実施例の中には、各部分に記述されている機能が、図に記述されているものとは異なる順番で実施されてもよいという点に留意されたい。例えば、連続して表示されている２部分は、実際には、実質的に同時に実行されてよく、または場合によってはその２部分が、関係する機能に応じて逆の順番で実行されてもよい。また、当該部分的線図および／またはフローチャート図の各部分、および当該部分的線図および／またはフローチャート図の各部分の組み合わせは、特定の機能または動作を実行する特殊なハードウェアベースのシステム、または特殊なハードウェアおよびコンピューター命令の組み合わせで実行することもできる。
【図１Ａ】
0006310925.tif 000002
【図１Ｂ】
0006310925.tif 000003
【図２】
0006310925.tif 000004
【図３】
0006310925.tif 000005
【図４】
0006310925.tif 000006
【図５】
0006310925.tif 000007
【図６】
0006310925.tif 000008