JP2016533569A - マルチメディア・コンテンツを受信するように構成されたクライアント端末のダウンロード動作を適応させる方法および対応する端末 - Google Patents

Abstract

本発明は、少なくとも１つの提示態様によって定義されるマルチメディア・コンテンツを少なくとも１つのサーバから受信するように構成されたクライアント端末のダウンロード動作を適応させる方法であって、所与の提示態様を有するマルチメディア・コンテンツの第１の部分を要求するステップ（Ｓ０）と、第１の部分の要求に基づいて、キャッシュがクライアント端末とサーバとの間の伝送経路沿いに位置するかどうかを検出するステップ（Ｓ１）と、キャッシュが検出された場合に、少なくとも１つの性能基準によって決まる提示態様を有するマルチメディア・コンテンツの第２の部分を要求するステップ（Ｓ３）とを含む方法に関する。

Description

本発明は、一般に、例えばＨＴＴＰ（ハイパーテキスト転送プロトコル）（ただしこれに限定されない）を介した適応型ストリーミング技術の領域に関し、詳細には、１つまたは複数のサーバからマルチメディア・コンテンツを受信するように構成されたクライアント端末のダウンロード動作を適応させる方法に関する。

本項は、以下で述べ、且つ／または特許請求する本発明の様々な態様に関係する可能性がある様々な技術的特徴を、読者に紹介するための項である。この記述は、本発明の様々な態様に対するより深い理解を促す背景情報を読者に与えるのに有効であると考えられる。従って、以下の記述は、この点に照らして読まれるべきものであり、従来技術を承認するものとして読まれるべきものではないことを理解されたい。

ＨＴＴＰを介した適応型ストリーミングは、急速に主要なマルチメディア・コンテンツ配信技術となりつつある。既に使用されているＨＴＴＰ適応型ストリーミング・プロトコルの中で、最も有名なものは、Ａｐｐｌｅ社によるＨＴＴＰ Ｌｉｖｅ Ｓｔｒｅａｍｉｎｇ（ＨＬＳ）、Ｍｉｃｒｏｓｏｆｔ社によるＳｉｌｖｅｒｌｉｇｈｔ Ｓｍｏｏｔｈ Ｓｔｒｅａｍｉｎｇ（ＳＳＳ）、Ａｄｏｂｅ社によるＡｄｏｂｅ Ｄｙｎａｍｉｃ Ｓｔｒｅａｍｉｎｇ（ＡＤＳ）、およびＳＡ４グループの３ＧＰＰにより開発されたＤｙｎａｍｉｃ Ａｄａｐｔｉｖｅ Ｓｔｒｅａｍｉｎｇ ｏｖｅｒ ＨＴＴＰ（ＤＡＳＨ）である。

クライアント端末は、適応型ストリーミングで視聴覚コンテンツ（またはＡ／Ｖコンテンツ）を再生しようとするときには、まずどのようにすればこのＡ／Ｖコンテンツを取得することができるかを記述したファイルを手に入れなければならない。これは、ＨＴＴＰプロトコルを介して、いわゆるマニフェストと呼ばれる記述ファイルをＵＲＬ（Ｕｎｉｆｏｒｍ Ｒｅｓｏｕｒｃｅ Ｌｏｃａｔｏｒ）から手に入れることによって行われるのが一般的であるが、その他の手段（例えば放送、電子メール、ＳＭＳなど）によって手に入れることもできる。マニフェストは、基本的には、Ａ／Ｖコンテンツなどの利用可能な提示態様（ビット・レート、解像度、およびその他のプロパティ）を列挙したものである。このマニフェストは、予め生成され、例えば遠隔サーバからクライアント端末に向けて送信される。

実際に、様々な品質を有するＡ／Ｖコンテンツに対応するデータのストリームが、ＨＴＴＰサーバでは利用可能である。最高品質は、高ビット・レートに関連し、最低品質は、低ビット・レートに関連する。これにより、非常に変化しやすいネットワークの状態の影響を受ける様々な多くの端末への配信が可能になる。

データ・ストリーム全体は、クライアント端末が２つのチャンクの間で１つの品質レベルから別の品質レベルに滑らかに切り替わることができるように構成された複数のチャンクに分割される。その結果として、ビデオ品質は再生中に変化する可能性があるが、中断（フリーズとも呼ばれる）することは滅多になくなる。

プロトコルによって、マニフェストは様々なフォーマットを提示する可能性がある。Ａｐｐｌｅ社のＨＬＳプロトコルでは、それは、「マスタ・プレイリスト」と呼ばれるＭ３Ｕ８プレイリストである。このプレイリストの各要素は、別のプレイリストであり、提示態様ごとに１つのプレイリストがある。他のプロトコル（例えばＤＡＳＨ）によれば、マニフェストは、全ての提示態様を次々に記述した１つまたは複数のＸＭＬファイルで構成される。何れの場合も、マニフェストを作成することは、テキスト・ファイルを作成すること、および決定性文法に従ってテキストを書くことと同じくらい簡単である。

クライアント端末が、利用可能な帯域幅に従って、所与の時点で、品質（例えばビデオ品質）とネットワークの変化に対するロバストネスとの間のトレードオフを最適化するように最良の提示態様を選択することは、周知である。利用可能な帯域幅は、受信するチャンクごとに動的に測定される。実際には、所与のチャンクを求めるＨＴＴＰ要求の発信と対応するＨＴＴＰ応答の受信との間で定義されるラウンド・トリップ・タイム（以下、ＨＴＴＰ ＲＴＴと呼ぶ）を測定し、伝送経路に沿った利用可能な帯域幅を推定するために使用するのが一般的である。

クライアント側での受信レートは、チャンクをダウンロードする時とともに変化する。開始時に、クライアント端末は、チャンクを求めるＨＴＴＰ要求を発行する。最初に、上記のＨＴＴＰ要求のＨＴＴＰ ＲＴＴに対応する「アイドル」時間の期間がある。次いで、チャンクのパケットが受信される。これらのパケットは、この接続のピーク・レートで入来する。最後に、チャンクのダウンロードが終了したときに、受信レートは再度０まで低下する。

このように、クライアント端末は、ＨＴＴＰ要求のＨＴＴＰ ＲＴＴおよび利用可能なピーク帯域幅の両方を推定することができ、次いで、これらの推定値を使用して、１つのチャンクの受信期間内に高い確率で受信され得る要求可能な最大チャンク・サイズを決定する。

既知のように、クライアント端末は、一般的に、以下の数式により、帯域幅推定を平均化する。
ＢＷ_ｎ＝αＢＷ_ｎ−１＋（１−α）Ｄ_ｎ
ここで、ＢＷ_ｎは、次のチャンクｎ＋１の要求に使用される、チャンクｎの平均帯域幅であり、
Ｄ_ｎは、（チャンクｎの伝送の開始から終了までの間の）チャンクｎの瞬間受信データ・レートであり、
αは、０≦α≦１である。

さらに、クライアント端末は、いくつかのバッファも使用して、突然の帯域幅の不足に対する保護を講じている。バッファを満たすために、これらの端末は、チャンクの持続時間より短い時間で受信するのに十分に小さいチャンクを要求して、前のチャンクを受信したらすぐに次のチャンクを求める。バッファが通常のサイズであるときには、クライアント端末は、チャンクの持続時間に適合したチャンクをロードしようとする。ロードが遅すぎるチャンクがある場合には、バッファは、使い果たされており、クライアント端末は、バッファを後続のチャンクで再度満たそうとする。

クライアント端末と遠隔サーバの間の伝送経路に沿ってキャッシュが位置していることもよくあるが、そのようなときには、別のクライアントが以前に同じ提示態様を有する同じチャンクを要求した場合、またはコンテンツ・デリバリ・ネットワーク（ＣＤＮ）が既にそのチャンクをそのキャッシュに供給している場合には、あるチャンクが既にそのキャッシュに記憶されている可能性がある。

従って、上記の所与のチャンクを求めるＨＴＴＰ要求に対する応答は、そのチャンクが遠隔サーバから入来する場合より速い。クライアント端末とキャッシュとの間のＨＴＴＰ要求のＨＴＴＰ ＲＴＴは、伝送経路が短くなるので、クライアント端末と遠隔サーバとの間のＨＴＴＰ ＲＴＴよりはるかに小さくなることがある。

さらに、伝送経路沿いにキャッシュが存在する（要求されたチャンクがそのキャッシュに記憶されている）場合には、特にキャッシュと遠隔サーバの間に位置するこの伝送経路に輻輳があるときには、ピーク・レートがより良好になる可能性がある。

クライアント端末は、通常は、遠隔サーバから送信された応答と中間キャッシュから送信された応答とを区別しないので、帯域幅の変動を、エンド・ツー・エンドのネットワーク状態の変動であるものとして誤って解釈しているが、実際には、「クライアント端末からサーバまで」の経路から「クライアント端末からキャッシュまで」の経路への伝送経路の切替えを監視している。

その結果として、クライアント端末によって行われる帯域幅推定は、過大評価になり、エンド・ツー・エンドの伝送経路の特徴を期待したようには正確に反映していない。

このような過大評価は、一般に、エンド・ユーザの体験の劣化につながる。実際に、推定帯域幅が予想帯域幅より高い場合には、適応型ストリーミングのクライアント端末は、通常は、より高い品質の提示態様（例えばより高いビット・レート）からのチャンクを要求する。この要求されたチャンクは、提示態様が変化するので、キャッシュ内にある可能性が低い（キャッシュは、同じマルチメディア・コンテンツを一定のビット・レートで再生する以前のクライアント端末によって満たされたと仮定する）。この要求されたチャンクに関連するダウンロード時間は、予想よりはるかに長くなり、要求されたチャンクの到着は遅すぎるはずである。この場合、クライアント端末は、キャッシュ内で再び見つかる可能性が高い、より低い品質の提示態様に戻ることになる。

その結果として、クライアント端末は、高品質のチャンクと低品質のチャンクとの間で切り替わり、これがキャッシュがないことによって絶えず中断され、それによりキャッシュの利点が完全に損なわれてしまう。

本発明は、エンド・ユーザの体験の品質を改善するために、上述の問題の少なくとも一部を解消しようとするものである。

本発明は、少なくとも１つの提示態様によって定義されるマルチメディア・コンテンツを少なくとも１つのサーバから受信するように構成されたクライアント端末のダウンロード動作を適応させる方法であって、好ましくはクライアント側で、
所与の提示態様を有するマルチメディア・コンテンツの第１の部分を要求するステップと、
第１の部分の要求に基づいて、キャッシュがクライアント端末とサーバとの間の伝送経路沿いに位置するかどうかを検出するステップと、
キャッシュが検出された場合に、少なくとも１つの性能基準によって決まる提示態様を有するマルチメディア・コンテンツの第２の部分を要求するステップとを含むことを特徴とする方法に関する。

従って、本発明により、１つまたは複数の中間キャッシュが存在するときのクライアント端末のダウンロード動作を適応させることによって、不安定な再生を回避することができ、配備された大量のキャッシュを活用する可能性を再度もたらすことができる。実際には、ほとんどのＨＴＴＰ適応型ストリーミング・サーバは、あるチャンクはキャッシュされ、その他のチャンクはキャッシュされていないときにクライアント端末が帯域幅推定で混乱することを回避するために、「ｎｏ−ｃａｃｈｅ」ヘッダを有するチャンク・データを送信して、キャッシュをさせないようにする。本発明は、クライアント・サーバ・アーキテクチャ全体にキャッシュすることの利益を再度もたらし、全体としてのネットワーク性能を改善することができる。

この方法は、クライアント端末と検出されたキャッシュとの間の伝送経路の帯域幅を推定するステップをさらに含むことが好ましい。

上記の性能基準によれば、マルチメディア・コンテンツの要求された第２の部分は、
帯域幅推定の結果に関わらず、検出されたキャッシュに記憶された第１の部分の提示態様と同じ提示態様、または
第１の部分の提示態様とは異なる、推定された帯域幅を考慮に入れた代替の提示態様によって定義され得る。

さらに、第２の部分の要求は、検出されたキャッシュにより理解できる情報を含み、第２の部分が検出されたキャッシュに記憶されていない場合に、クライアント端末が、第２の部分がキャッシュから入手不能であることを示すメッセージを受信するようにすることができるので有利である。例えば、この情報は、ＨＴＴＰ要求の制御ヘッダ中の指示文「ｏｎｌｙ ｉｆ ｃａｃｈｅｄ」とすることもできる。

別の態様では、この方法は、検出されたキャッシュからのマルチメディア・コンテンツのダウンロードが、少なくとも１つのダウンロード基準を満たす場合に、第１の部分の提示態様とは異なる新たな提示態様を有するマルチメディア・コンテンツのさらに別の部分を要求するステップをさらに含むことができる。

本発明の好ましい実施形態によれば、キャッシュを検出するステップは、クライアント端末からサーバへの接続確立要求のラウンド・トリップ・タイムを測定するステップをさらに含む。

さらに、キャッシュを検出するステップは、マルチメディア・コンテンツの第１の部分を求める要求の発信と要求された第１の部分の受信の開始との間の受信遅延を測定するステップをさらに含むことができる。

さらに、キャッシュを検出するステップは、測定した接続確立要求のラウンド・トリップ・タイムと測定した受信遅延とを比較するステップをさらに含むことができる。

この好ましい実施形態のさらに別の態様では、測定した受信遅延と測定した接続確立要求のラウンド・トリップ・タイムとの間の差が、
第１の検出しきい値以上である場合には、クライアント端末とサーバとの間の伝送経路沿いにキャッシュが検出され、要求された第１の部分は、この検出されたキャッシュに記憶されておらず、
それ以外の場合には、
クライアント端末とサーバとの間の伝送経路沿いにキャッシュが存在して、要求された第１の部分はそのキャッシュから入来する、あるいは
クライアント端末とサーバとの間の伝送経路沿いにキャッシュがなく、要求された第１の部分はサーバから入来する。

この好ましい実施形態の変形形態または相補的形態では、キャッシュを検出するステップは、
クライアント端末からサーバへのエコー要求の発信とエコー要求に対する応答の受信との間の応答時間を測定するステップと、
測定した接続確立要求のラウンド・トリップ・タイムを応答時間と比較するステップとをさらに含むことができる。

さらに、キャッシュを検出するステップは、測定した応答時間を測定した受信遅延と比較するステップをさらに含むことができる。

この変形形態または相補的形態の追加の態様によれば、測定した応答時間と測定した接続確立要求のラウンド・トリップ・タイムとの間の差が、
第２の検出しきい値以下である場合には、クライアント端末とサーバとの間の伝送経路沿いにキャッシュが検出されず、チャンクはサーバから入来し、
第３の検出しきい値以上である場合には、クライアント端末とサーバとの間の伝送経路沿いにキャッシュが検出され、チャンクは、
測定した応答時間と測定した受信遅延との間の差が第４の検出しきい値以上である場合には、検出されたキャッシュにロードされており、または
そうでない場合には、サーバから入来する。

さらに別の態様では、上記の性能基準は、少なくとも、
マルチメディア・コンテンツの品質に関連する基準、
マルチメディア・コンテンツのダウンロードの速度に関連する基準
を含む一群の基準に属することがある。

本発明は、さらに、少なくとも１つの提示態様によって定義されるマルチメディア・コンテンツを少なくとも１つのサーバから受信するようにそのダウンロード動作を適応させるように構成された端末に関する。本発明によれば、この端末は、
所与の提示態様を有するマルチメディア・コンテンツの第１の部分を要求する通信モジュールと、
第１の部分の要求に基づいて、キャッシュがクライアント端末とサーバとの間の伝送経路沿いに位置するかどうかを検出するキャッシュ検出器と、
キャッシュが検出された場合に、少なくとも１つの性能基準によって決まる提示態様を有するマルチメディア・コンテンツの第２の部分を要求する判定モジュールとを含む。

さらに、この端末は、その端末と検出されたキャッシュとの間の伝送経路の帯域幅を推定する帯域幅推定器をさらに含むことができる。

開示する実施形態と範囲が対応する特定の態様について、以下に述べる。これらの態様は、単に本発明が取り得る特定の形態の簡単な概要を読者に与えるために与えるものであり、本発明の範囲を限定するためのものではないことを理解されたい。実際には、本発明は、以下に記載していないこともある様々な態様を包含することができる。

本発明は、以下の実施形態および実施例によって、よりよく理解されるであろう。本発明について、以下の実施形態および実施例を用いて、添付の図面を参照して非限定的に説明する。

本発明を実施することができるクライアント・サーバ・ネットワーク・アーキテクチャを示す概略図である。 本発明の好ましい実施形態によるクライアント端末の一例を示すブロック図である。 図２のクライアント端末によって実施される第１のキャッシュ検出機構を示す流れ図である。 伝送経路沿いに位置するキャッシュがない場合のＴＣＰ−ＲＴＴを示す図である。 伝送経路沿いに位置するキャッシュがある場合のＴＣＰ−ＲＴＴを示す図である。 伝送経路沿いにキャッシュがない場合のＨＴＴＰ−ＲＴＴを示す図である。 伝送経路沿いにキャッシュがあるが、所与のチャンクがキャッシュされていない場合のＨＴＴＰ−ＲＴＴを示す図である。 伝送経路沿いにキャッシュがあり、所与のチャンクがキャッシュされている場合のＨＴＴＰ−ＲＴＴを示す図である。 図２のクライアント端末によって実施される第２のキャッシュ検出機構を示す流れ図である。 図２のクライアント端末によって実施されるダウンロード動作を適応させる方法を示す流れ図である。

図１および図２に示すブロックは、純粋に機能的なエンティティであり、必ずしも物理的に別個のエンティティに対応しているとは限らない。すなわち、これらのブロックは、ソフトウェアの形態で実施することも、ハードウェアの形態で実施することもでき、あるいは１つまたは複数のプロセッサを含む１つまたは複数の集積回路に実装することもできる。

全ての図面を通じて、同じ、または同様の部分は、可能な限り同じ参照番号を使用して示す。

本発明の図面および説明は、本発明を明快に理解するために関わりのある要素を例示するために簡略化してあり、分かりやすくするために、通常のディジタル・マルチメディア・コンテンツを配信する方法およびシステムで見られるその他の多くの要素が省略されていることを理解されたい。しかし、これらの要素は当技術分野では周知であるので、これらの要素の詳細な説明は、本明細書では与えていない。本明細書の開示は、当業者に既知のこれら全ての変形形態および修正形態も対象とする。

好ましい実施形態によれば、本発明は、ＨＴＴＰ適応型ストリーミング・プロトコルに関連して説明される。もちろん、本発明は、この特定の環境に限定されるわけではなく、その他の適応型ストリーミング・プロトコルを考慮し、実施することができることは言うまでもない。

図１に示すように、本発明を実装することができるクライアント・サーバ・ネットワーク・アーキテクチャは、クライアント端末Ｃ、ゲートウェイＧＷ、および１つまたは複数のＨＴＴＰサーバＳ（図１には１つしか示していない）を含む。

第１のネットワークＮ１（ホーム・ネットワークまたは企業ネットワーク）を介してゲートウェイＧＷに接続されたクライアント端末Ｃは、第２のネットワークＮ２（例えば、インターネット）を介してＨＴＴＰサーバＳに接続しようとする。第１のネットワークＮ１は、ゲートウェイＧＷにより第２のネットワークＮ２に接続される。

ＨＴＴＰサーバＳは、クライアント要求に応じて、１つまたは複数のＴＣＰ／ＩＰ接続を介するＨＴＴＰ適応型ストリーミング・プロトコルを使用して、クライアント端末Ｃにチャンクを送る。

図２に示す好ましい実施形態によれば、クライアント端末Ｃは、少なくとも以下を含む。
第１のネットワークＮ１への接続インタフェース１（有線および／または無線のもの、例えばＷｉ−Ｆｉ、Ｅｔｈｅｒｎｅｔなど）。
ＨＴＴＰサーバＳと通信するためのプロトコル・スタックを含む通信モジュール２。具体的には、通信モジュール２は、当技術分野で周知のＴＣＰ／ＩＰスタックを含む。もちろん、通信モジュール２は、クライアント端末ＣがＨＴＴＰサーバＳと通信することを可能にするものであれば、その他の任意のタイプのネットワークおよび／または通信手段とすることもできる。
ＨＴＴＰサーバＳからＨＴＴＰストリーミング・マルチメディア・コンテンツを受信する適応型ストリーミング・モジュール３。適応型ストリーミング・モジュール３は、ネットワークの制約およびそれ自体の制約により良好に一致するビット・レートでチャンクを絶え間なく選択する。
マルチメディア・コンテンツを復号およびレンダリングするように適応されたビデオ・プレーヤ４。
クライアント端末Ｃの不揮発性メモリに記憶されたアプリケーションおよびプログラムを実行する１つまたは複数のプロセッサ５。
ＨＴＴＰサーバＳから受信したチャンクをビデオ・プレーヤ４に伝送する前にバッファする揮発性メモリなどの記憶手段６。
一般的なクライアント端末の機能を実行するための上記の様々なモジュールおよび当業者に周知の全ての手段に接続するための内部バスＢ１。

この好ましい実施形態では、クライアント端末Ｃは、携帯型メディア・デバイス、携帯電話、タブレット、またはラップトップである。もちろん、クライアント端末Ｃは、ビデオ・プレーヤ全体を含むのではなく、メディア・コンテンツを多重化解除および復号するための部分要素など、一部の部分要素のみを含んでいて、復号したコンテンツをエンド・ユーザに対して表示するのは外部の手段に頼ってもよい。その場合には、クライアント端末Ｃは、セット・トップ・ボックスなど、ＨＴＴＰ適応型ストリーミング（ＨＡＳ）可能なビデオ・デコーダである。

本発明によれば、クライアント端末Ｃは、サーバＳからマルチメディア・コンテンツを受信するようにそのダウンロード動作を適応させるように構成される。

この目的のために、クライアント端末Ｃは、以下をさらに含む。
クライアント端末ＣとサーバＳの間の伝送経路に沿ってキャッシュを検出するように適応されたキャッシュ検出器７。
クライアント端末Ｃと検出されたキャッシュＲの間の伝送経路の帯域幅および／またはクライアント端末ＣとサーバＳの間の伝送経路の帯域幅を測定するように構成された帯域幅推定器８。
性能基準に従って上記のマルチメディア・コンテンツのチャンクを要求するように構成された判定モジュール９。変形形態では、この判定モジュール９は、通信モジュール２または適応型ストリーミング・モジュール３に一体化することもできる。

具体的には、この好ましい実施形態によれば、クライアント端末Ｃのキャッシュ検出器７は、図３に示すように、クライアント端末ＣとサーバＳの間のキャッシュＲを検出する第１の機構Ｍ１を実施する。

第１のキャッシュ検出機構Ｍ１は、以下のステップを含む。
クライアント端末ＣからサーバＳのへの接続確立要求のラウンド・トリップ・タイム（図４Ａおよび図４Ｂに示すいわゆるＴＣＰ−ＲＴＴ）を測定するステップ（ステップＥ０）。
所与の提示態様ｒを有するマルチメディア・コンテンツの所与のチャンクＩ_ｎを求める要求の発信と要求されたチャンクＩ_ｎの受信の開始との間の受信遅延Ｄｅｌａｙ_Ｒｘを測定するステップ（ステップＥ１）。
測定した接続確立要求のラウンド・トリップ・タイムＴＣＰ−ＲＴＴを測定した受信遅延Ｄｅｌａｙ_Ｒｘと比較するステップ（ステップＥ２）。

要求されたチャンクＩ_ｎが（検出される）キャッシュＲ内にあるときには、受信遅延Ｄｅｌａｙ_Ｒｘは、以下を含む可能性がある。
クライアント端末ＣとキャッシュＲの間の所与のチャンクＩ_ｎを要求するラウンド・トリップ・タイムＨＴＴＰ−ＲＴＴ（図４Ｅに示す）。
キャッシュＲが、要求されたチャンクＩ_ｎが利用可能か確認する時間。
キャッシュＲからデータをフェッチする時間。
チャンクＩ_ｎの最初のデータ・パケットの転送時間。

これらの時間は全て、キャッシュが適切に位置づけられているときには、短くなるものと予想される。

要求されたチャンクＩ_ｎがキャッシュＲ内にロードされていないときには、受信遅延Ｄｅｌａｙ_Ｒｘは、以下で構成される追加遅延を含む。
キャッシュＲとサーバＳの間の所与のチャンクＩ_ｎを要求するラウンド・トリップ・タイムＨＴＴＰ−ＲＴＴ（図４Ｄに示す）。
サーバＳが、チャンクＩ_ｎをフェッチする時間。
サーバＳからキャッシュＲへの最初のデータ・パケットの転送時間。

この追加遅延は、一般に、先の遅延よりはるかに長い。その理由は、以下である。
サーバＳまでのホップの数が多い可能性があり、これによりＲＴＴが大きくなり、各経路指定ノードが輻輳する可能性がある。
経路中のどこかで輻輳が生じた場合に、ＴＣＰ帯域幅が、著しく低下する可能性がある。
サーバＳが、多数のクライアントを有し、過負荷状態になる可能性がある。

測定した受信遅延Ｄｅｌａｙ_Ｒｘと測定した接続確立要求のラウンド・トリップ・タイムＴＣＰ−ＲＴＴとの間の差が、０ではない第１の検出しきい値Ｔｈ１以上である（すなわちＤｅｌａｙ_Ｒｘ−ＴＣＰＲＴＴ≧Ｔｈ１≠０）場合には、キャッシュＲは、クライアント端末ＣとサーバＳとの間の伝送経路に沿って検出される。要求された所与のチャンクＩ_ｎは、検出されたキャッシュＲに記憶されていない（図４Ｄに示す）。

測定した受信遅延Ｄｅｌａｙ_Ｒｘと測定した接続確立要求のラウンド・トリップ・タイムＴＣＰ−ＲＴＴとの間の差が、第１の検出しきい値未満である（すなわちＤｅｌａｙ_Ｒｘ−ＴＣＰＲＴＴ＜Ｔｈ１）場合には、
キャッシュＲが、クライアント端末ＣとサーバＳとの間の伝送経路沿いに存在し、要求された所与のチャンクＩ_ｎが、キャッシュＲから入来する（図４Ｅに示す）、または
クライアント端末ＣとサーバＳとの間の伝送経路沿いにキャッシュがなく、要求された所与のチャンクＩ_ｎが、サーバＳから入来する（図４Ｃに示す）。

後続の遅延Ｄｅｌａｙ_Ｒｘを比較することにより、キャッシュ検出器７は、以前に受信したチャンクがサーバＳから入来するものであっても、キャッシュＲから入来するものであっても、要求されたチャンクが以前に受信したチャンクと同じソースから入来するかどうかを知ることができる。

なお、所与のチャンクについて、伝送経路沿いにキャッシュが既に検出されているときには、このキャッシュの存在に関する情報は、後に再利用することができることに留意されたい。

さらに、変形形態では、クライアント端末Ｃのキャッシュ検出器７は、クライアント端末ＣとサーバＳとの間のキャッシュＲを検出する第２の機構Ｍ２を実施することができる。

図５に示すように、第２の機構Ｍ２は、第１の機構Ｍ１のステップＥ０およびＥ１を含み、さらに、
クライアント端末ＣからサーバＳへのインターネット制御メッセージ・プロトコル・エコー要求（いわゆるＩＣＭＰエコー）の発信と、このＩＣＭＰエコー要求に対する応答の受信との間の応答時間Ｔ_Ｒｘを測定するステップ（ステップＥ３）、
測定した接続確立要求のラウンド・トリップ・タイムＴＣＰ−ＲＴＴを応答時間Ｔ_Ｒｘと比較するステップ（ステップＥ４）、
測定した応答時間Ｔ_Ｒｘを測定した受信遅延Ｄｅｌａｙ_Ｒｘと比較するステップ（ステップＥ５）、を含む。

測定した応答時間Ｔ_Ｒｘと測定した接続確立要求のラウンド・トリップ・タイムＴＣＰ−ＲＴＴとの間の差が第２の検出しきい値Ｔｈ２（例えば０に近い値）以下であるとき、すなわち｜Ｔ_Ｒｘ−ＴＣＰＲＴＴ｜≦Ｔｈ２≒０であるときには、クライアント端末ＣとサーバＳの間の伝送経路沿いにキャッシュは検出されず、チャンクＩ_ｎはサーバＳから入来する。

これに対して、測定した応答時間Ｔ_Ｒｘと測定した接続確立要求のラウンド・トリップ・タイムＴＣＰ−ＲＴＴとの間の差が０ではない第３の検出しきい値Ｔｈ３以上であるとき、すなわちＴ_Ｒｘ−ＴＣＰＲＴＴ≧Ｔｈ３≠０であるときには、クライアント端末ＣとサーバＳの間の伝送経路沿いにキャッシュＲが検出され、チャンクＩ_ｎは、
測定した応答時間Ｔ_Ｒｘと測定した受信遅延Ｄｅｌａｙ_Ｒｘとの間の差が第４の検出しきい値（例えば応答時間Ｔ_Ｒｘの半分）以上であるとき、すなわち

であるときには、検出されたキャッシュＲにロードされており、
そうでないときには、サーバＳから入来する。

キャッシュＲはこうしたＩＣＭＰ要求を行わないので、第２の機構Ｍ２は、サーバＳにＩＣＭＰエコー要求を送信し、応答時間Ｔ_Ｒｘを測定することによって、遠隔サーバＳまでの「距離」を明示的に測定する。

ＴＣＰ−ＲＴＴとＴ_Ｒｘの値とが近い場合には、これは、直接サーバＳにつながるＴＣＰ接続が１つしかないことを意味している（図４Ａ参照）。キャッシュＲが２重ＴＣＰ接続（図４Ｂ参照）を確立する場合には、ＩＣＭＰエコーの全部のＲＴＴ（すなわちＴ_Ｒｘ）の方がはるかに大きくなる。

さらに、両方の機構を組み合わせて、キャッシュ検出の信頼性を高めることもできることは理解されるであろう。上述したパラメータのいくつかの測定を実施して、例えば一時的なネットワークの輻輳などによるエラーのリスクを制限することもできる。

さらに、クライアント端末Ｃの帯域幅推定器８は、以下の数式により伝送経路の利用可能な帯域幅を推定するように構成される。
ＢＷ_ｎ＝αＢＷ_ｎ−１＋（１−α）Ｄ_ｎ

クライアント端末Ｃが、キャッシュ検出器７によりチャンクＩ_ｎがキャッシュＲを介して受信されたか遠隔サーバＳから受信されたかを把握しているときには、帯域幅推定器８は、両方の状況（チャンクＩ_ｎがキャッシュされている場合と、サーバＳから入来する場合）についての受信遅延Ｄｅｌａｙ_Ｒｘおよびピーク・レートの別個の値を保持し、
「クライアント端末ＣからサーバＳまで」の伝送経路の値ＢＷ_{ｓｅｒｖｅｒ}、および
「クライアント端末Ｃから検出されたキャッシュＲまで」の伝送経路の値ＢＷ_{ｃａｃｈｅ}
の２つの異なる値を、帯域幅推定のために維持するように構成される。

帯域幅推定は、クライアント端末Ｃのキャッシュ検出器７からの検出情報を受信したときに更新することができる。

さらに別の態様では、ピーク・レートは主に「ラスト・マイル」アクセス・リンクの影響および／または無線ホーム・リンクの使用の影響を受けるので、クライアント端末Ｃがピーク・レートの低下を観測した場合には、それは両方の状況についての同様の低下と仮定することができるので、このピーク・レートの低下を考慮に入れて両方の推定を更新することができる。

この好ましい実施形態によれば、キャッシュＲが検出されている場合には、判定モジュール９は、以下の判定プロセスを実施して、性能基準に応じて、次のチャンクＩ_ｎ＋１を要求することを判定する。
帯域幅推定の結果に関わらず、上記キャッシュＲに留まる可能性を最大限に高めるために、キャッシュＲに記憶されているチャンクＩ_ｎの提示態様と同じ提示態様ｒを有するチャンクＩ_ｎ＋１を要求する。この場合には、判定モジュール９は、帯域幅推定値未満で最も近いものではない関連するビット・レートを有する提示態様を要求することができる。従って、キャッシュにより、ロバストネスが最大品質より優先される。または、
帯域幅推定（例えば、チャンクＩ_ｎがキャッシュされている場合のＢＷ_{ｃａｃｈｅ}、チャンクＩ_ｎがサーバＳから入来する場合のＢＷ_{ｓｅｒｖｅｒ}）を考慮した代替の提示態様ｒ’（チャンクＩ_ｎの提示態様とは異なる）を有するチャンクＩ_ｎ＋１を要求する。この代替の提示態様ｒ’は、有利には帯域幅推定ににより決まる。この代替の提示態様ｒ’がチャンクＩ_ｎの現在の提示態様ｒより高いビット・レートで定義されている場合には、品質がロバストネスより優先される。

この好ましい実施形態のさらに別の態様によれば、同じ提示態様ｒまたは代替の提示態様ｒ’を有する次のチャンクＩ_ｎ＋１の要求は、検出されたキャッシュＲにより理解することができる情報（例えば、「ｏｎｌｙ−ｉｆ−ｃａｃｈｅｄ」ＨＴＴＰヘッダ）を含むことがあるので、次のチャンクＩ_ｎ＋１が検出されたキャッシュＲに記憶されていない場合には、クライアント端末Ｃは、次のチャンクＩ_ｎ＋１がキャッシュＲで入手できないことを示すメッセージを受信するので有利である。これにより、キャッシュＲにおける別のチャンクの利用可能性を確かめるための遅延による不利益を制限することができる。代替の提示態様ｒ’がキャッシュＲで利用できない場合には、クライアント端末Ｃは、提示態様ｒを有するチャンクＩ_ｎ＋１を再度要求することができる。

例えば、性能基準は、例えばマルチメディア・コンテンツの品質やダウンロードの速度など、自分の好みを選択するように、クライアント端末Ｃのエンド・ユーザが選択することができる。変形形態では、この性能基準は、マルチメディア・コンテンツのカテゴリ（例えばスポーツのイベント、映画、ドキュメンタリーなど）に関連して自動的に定義することもできる。別の変形形態では、１つまたは複数の追加の基準を使用することもできることは明らかである。

この好ましい実施形態のさらに別の態様では、検出されたキャッシュＲからのマルチメディア・コンテンツのダウンロードがダウンロード基準を満たす（例えば、キャッシュからのダウンロードが十分に速く、クライアント端末Ｃのバッファ６が満杯になる）ときには、判定モジュール９は、提示態様の変更（例えばより高い品質を得るためのもの）を試みるために、このマルチメディア・コンテンツのチャンクＩ_ｎの提示態様ｒとは異なる新たな提示態様ｒ”を有する別のチャンクＩ_ｋを要求し、この新たな提示態様ｒ”が持続可能である（すなわち次のチャンクＩ_ｋが時間通りに到着し、次の帯域幅推定がこの新たな提示態様ｒ”で継続可能である）か否かを決定することができる。新たな提示態様ｒ”が持続可能でない場合には、判定モジュール９は、以前のキャッシュされた提示態様ｒに戻る。

この好ましい実施形態のさらに別の態様では、マルチメディア・コンテンツの全ての提示態様のフラグ・リストを、クライアント端末Ｃに記憶することができる。このフラグ・リストは、提示態様が以前にキャッシュＲで検出されたことがあるか否かを示す。判定モジュール９が、現在の提示態様ｒを変更しようとするときには、このフラグ・リストが、検出されたキャッシュＲ中に変更に係る提示態様が見つかる可能性を示す指示を提供することができる。

キャッシュがある場合の帯域幅推定（ＢＷ_{ｃａｃｈｅ}）とキャッシュがない場合の帯域幅推定（ＢＷ_{ｓｅｒｖｅｒ}）の比によっては、現在のビット・レートよりわずかに低いビット・レートを選択することにより、現在のチャンクＩ_ｎがキャッシュＲにあり、次のチャンクＩ_ｎ＋１がない場合、現在の受信条件より、受信条件が悪化する可能性もあることは理解されるであろう。従って、判定モジュール９は、キャッシュにない場合の不利益を補償するために、はるかに低いビット・レートを選択するように判定することができる。

本発明によれば、図６に示すように、クライアント端末Ｃは、所与のマルチメディア・コンテンツをネットワークＮ２から受信するようにそのダウンロード動作を適応させるように構成される。具体的には、クライアント端末Ｃは、以下のステップを含む適応方法ＡＭを実施することができる。
所与の提示態様ｒを有するマルチメディア・コンテンツの第１のチャンクＩ_ｎを要求するステップ（ステップＳ０）。
キャッシュ検出機構Ｍ１および／またはＭ２に基づいて、上記の所与のマルチメディア・コンテンツを含む、クライアント端末Ｃと遠隔サーバＳとの間のキャッシュＲを検出するステップ（ステップＳ１）。
クライアント端末Ｃと検出されたキャッシュＲとの間の伝送経路の帯域幅ＢＷ_{ｃａｃｈｅ}を推定するステップ（ステップＳ２）。
キャッシュＲがステップＳ１で検出されている場合に、上述の判定プロセスに従って、性能基準によって決まる提示態様ｒ’を有するマルチメディア・コンテンツの次のチャンクＩ_ｎ＋１を要求するステップ（ステップＳ３）。

本発明によれば、ＨＴＴＰ適応型ストリーミングのクライアント端末の動作を、伝送経路沿いのキャッシュの存在を検出し、それに応じてその判定プロセスを調節するように適応させることができる。エンド・ユーザの経験品質（ＱｏＥ）を改善することができる。

実際に、要求されたチャンクＩ_ｎ（提示態様ｒのチャンクｎ）が検出されたキャッシュＲ内に既に存在しているときには、同じレートの次のチャンク（提示態様ｒのチャンクＩ_ｎ＋１）もキャッシュＲにロードされている可能性が高い。場合によっては、同じ提示態様ｒを維持して、この特定のチャンク（提示態様ｒのチャンクＩ_ｎ＋１）を要求することが有利であることもある。この場合の明らかな利点としては、キャッシュされたチャンクが再利用されることが挙げられ、この場合、スムーズな再生体験が得られ、キャッシュＲとサーバＳとの間のトラフィックがかなり低減する。その他の判定は、キャッシュＲの存在が分かっていることに基づいて行うことができる。

さらに、検出されたキャッシュが、ゲートウェイＧＷの内部キャッシュに対応して、
マルチメディア・コンテンツの以前に要求されたチャンクをより高速にダウンロードすること、
オーバ・ザ・トップ（ｏｖｅｒ−ｔｈｅ−ｔｏｐ）業者が、ゲートウェイの内部キャッシュに自分たちのコンテンツを提供して、ユーザ・エクスペリエンスを向上させること
が可能であることもあることを理解されたい。

本明細書、特許請求の範囲および図面に開示する言及事項は、独立して実現してもよいし、任意の適当な組合せで実現してもよい。様々な特徴は、適宜、ハードウェア、ソフトウェア、またはその両者の組合せで実施することができる。

特許請求の範囲に見られる参照番号は、単に例示を目的としたものに過ぎず、特許請求の範囲に限定的な影響を及ぼすものではない。

好ましい実施形態において本発明について説明したが、本発明は、当業者の能力の範囲内で、発明的な才能を発揮することなく、多数の修正形態および実施形態が可能であることは明らかである。従って、本発明の範囲は、以下の特許請求の範囲によって定義される。

本明細書の特許請求の範囲では、特定の機能を実行するための手段として表現される任意の要素（例えばキャッシュ検出器７、帯域幅推定器８、判定モジュール９など）は、例えば、ａ）この機能を実行する回路要素の組合せ（例えば１つまたは複数のプロセッサ）、あるいはｂ）この機能を実行するソフトウェアを実行する適当な回路と組み合わされた、ファームウェアやマイクロコードなども含む任意の形態のソフトウェアなど、この機能を実行する任意の方法を包含するものとする。特許請求の範囲によって定義される本発明の原理は、記載した様々な手段によって提供される機能を、特許請求の範囲が求める方法で組み合わせて一体化することにある。従って、これらの機能を提供することが可能な任意の手段は、本明細書に示す手段と等価であるものとみなされる。

Claims (11)

1. 少なくとも１つの提示態様によって定義されるマルチメディア・コンテンツを少なくとも１つのサーバ（Ｓ）から受信するように構成されたクライアント端末（Ｃ）のダウンロード動作を適応させる方法であって、
   所与の提示態様を有する前記マルチメディア・コンテンツの第１の部分（Ｉ_ｎ）を要求するステップ（Ｓ０）と、
   前記第１の部分（Ｉ_ｎ）の前記要求に基づいて、キャッシュ（Ｒ）が前記クライアント端末（Ｃ）とサーバ（Ｓ）との間の伝送経路沿いに位置するかどうかを検出するステップ（Ｓ１）と、
   キャッシュ（Ｒ）が検出された場合に、少なくとも１つの性能基準によって決まる提示態様を有する前記マルチメディア・コンテンツの第２の部分（Ｉ_ｎ＋１）を要求するステップ（Ｓ３）とを含むことを特徴とする、前記方法。
2. 前記クライアント端末（Ｃ）と前記検出されたキャッシュ（Ｒ）との間の伝送経路の帯域幅を推定するステップをさらに含む、請求項１に記載の方法。
3. 前記性能基準に従って、前記マルチメディア・コンテンツの前記要求された第２の部分（Ｉ_ｎ＋１）が、
   前記帯域幅推定の結果に関わらず、前記検出されたキャッシュ（Ｒ）に記憶された前記第１の部分（Ｉ_ｎ）の提示態様と同じ提示態様、または
   前記第１の部分（Ｉ_ｎ）の提示態様とは異なる、前記推定された帯域幅を考慮に入れた代替の提示態様
   によって定義される、請求項２に記載の方法。
4. 前記第２の部分（Ｉ_ｎ＋１）の前記要求が、前記検出されたキャッシュ（Ｒ）により理解できる情報を含み、前記第２の部分（Ｉ_ｎ＋１）が前記検出されたキャッシュ（Ｒ）に記憶されていない場合に、前記クライアント端末（Ｃ）が、前記第２の部分（Ｉ_ｎ＋１）が前記キャッシュ（Ｒ）から入手不能であることを示すメッセージを受信するようにする、請求項１から３の何れか１項に記載の方法。
5. 前記検出されたキャッシュ（Ｒ）からの前記マルチメディア・コンテンツのダウンロードが、少なくとも１つのダウンロード基準を満たす場合に、前記第１の部分（Ｉ_ｎ）の前記提示態様とは異なる新たな提示態様を有する前記マルチメディア・コンテンツのさらに別の部分（Ｉ_ｋ）を要求するステップをさらに含む、請求項１から４の何れか１項に記載の方法。
6. キャッシュ（Ｒ）を検出する前記ステップが、前記クライアント端末（Ｃ）からサーバ（Ｓ）への接続確立要求のラウンド・トリップ・タイム（ＴＣＰ−ＲＴＴ）を測定するステップをさらに含む、請求項１から５の何れか１項に記載の方法。
7. キャッシュ（Ｒ）を検出する前記ステップが、前記マルチメディア・コンテンツの前記第１の部分（Ｉ_ｎ）を求める要求の発信と前記要求された第１の部分（Ｉ_ｎ）の受信の開始との間の受信遅延を測定するステップをさらに含む、請求項６に記載の方法。
8. キャッシュ（Ｒ）を検出する前記ステップが、前記測定した接続確立要求のラウンド・トリップ・タイム（ＴＣＰ−ＲＴＴ）と前記測定した受信遅延とを比較するステップをさらに含む、請求項７に記載の方法。
9. キャッシュ（Ｒ）を検出する前記ステップが、
   前記クライアント端末（Ｃ）からサーバ（Ｓ）へのエコー要求の発信と前記エコー要求に対する応答の受信との間の応答時間を測定するステップと、
   前記測定した接続確立要求のラウンド・トリップ・タイム（ＴＣＰ−ＲＴＴ）を前記応答時間と比較するステップとをさらに含む、請求項７または８に記載の方法。
10. 少なくとも１つの提示態様によって定義されるマルチメディア・コンテンツを少なくとも１つのサーバ（Ｓ）から受信するようにダウンロード動作を適応させるように構成された端末であって、
    所与の提示態様を有する前記マルチメディア・コンテンツの第１の部分（Ｉ_ｎ）を要求する通信モジュール（２）と、
    前記第１の部分（Ｉ_ｎ）の前記要求に基づいて、キャッシュ（Ｒ）がクライアント端末（Ｃ）とサーバ（Ｓ）との間の伝送経路沿いに位置するかどうかを検出するキャッシュ検出器（７）と、
    キャッシュ（Ｒ）が検出された場合に、少なくとも１つの性能基準によって決まる提示態様を有する前記マルチメディア・コンテンツの第２の部分（Ｉ_ｎ＋１）を要求する判定モジュール（９）とを含むことを特徴とする、前記端末。
11. 前記端末と前記検出されたキャッシュとの間の伝送経路の帯域幅を推定する帯域幅推定器をさらに含む、請求項１０に記載の端末。

Images