JP6370916B2 - アダプティブメディアストリーミングを実行し、コンピュータ回路を備えるユーザ機器（ｕｅ）、動的アダプティブストリーミング（ｄａｓｈ）を実行するための方法、および、ハイパーテキストトランスファープロトコルでの動的アダプティブストリーミング（ｄａｓｈ）を実行し、コンピュータ回路を備えるユーザ機器（ｕｅ） - Google Patents

Description

ストリーミングサービスおよび会話形式サービスを含むマルチメディアサービスの発展は、モバイルブロードバンドの新しい技術および規格への進化の推進力となる重要な要素の１つである。モバイルデバイスでのデジタルビデオコンテンツの利用が増加している。スマートフォン、タブレットおよびその他のモバイルコンピューティングデバイスの購入数が増加するにつれて、ビデオ録画およびビデオ会議にそれらを利用する機会が急増するであろう。このようにマルチメディアサービスに対する消費者の需要が高いことと、メディア圧縮インフラストラクチャおよび無線ネットワークインフラストラクチャの発展とが相まって、未来のセルラー方式およびモバイル型のブロードバンドシステムのマルチメディアサービス機能を向上させ、消費者の使用感（Ｑｕａｌｉｔｙ ｏｆ ｅｘｐｅｒｉｅｎｃｅ：ＱｏＥ）を高めることによって、場所、時間、デバイスおよび技術に関係なく、ビデオコンテンツおよびビデオサービスへのユビキタスアクセスを保証することに関心が集まっている。

本開示の特徴および利点は、以下に記載する詳細な説明を添付図面と共に参照することで明らかとなるであろう。添付図面は、一例として、本開示の特徴を図示している。添付図面は以下の通りである。

一例に係る、メディアプレゼンテーション記述（ＭＰＤ）メタデータファイル設定を示すブロック図である。

一例に係るハイパーテキストトランスファープロトコル（ＨＴＴＰ）ストリーミングを示すブロック図である。

一例に係る、ハイパーテキストトランスファープロトコルベースの（ＨＴＴＰベースの）ビデオストリーミングのためのエネルギー特徴認識型無線アクセスネットワーク（ＲＡＮ）アーキテクチャを示すブロック図である。

一例に係る、予定ルート上のネットワーク状況、および、ユーザの使用感を改善するための、予定ルート上の特定の場所におけるメディアセグメントのキャッシュを示す図である。

一例に係る、アダプティブメディアストリーミングを実行するよう動作可能なユーザ機器（ＵＥ）のコンピュータ回路の機能を示す図である。

一例に係る、ハイパーテキストトランスファープロトコルでの動的アダプティブストリーミング（ＤＡＳＨ）を実行するための方法を示すフローチャートである。

一例に係る、ハイパーテキストトランスファープロトコルでの動的アダプティブストリーミング（ＤＡＳＨ）を実行するよう動作可能なユーザ機器（ＵＥ）のコンピュータ回路の機能を示す図である。

一例に係る、無線デバイス（例えば、ＵＥ）を示す図である。

以下では図示した実施形態例を説明する。本明細書では図示した実施形態例を説明するべく具体的な用語を用いる。しかし、これによって本発明の範囲の限定を意図したものではないと理解されたい。

本発明の開示および説明の前に、本発明は、本明細書で開示する特定の構造、処理工程または材料に限定されるものではなく、当業者が認識し得るそれらの均等物にまで拡張されるものと理解されたい。また、本明細書で用いる用語は具体例を説明することのみを目的として用いられており限定を意図したものではないことも理解されたい。複数の図面にわたって同じ参照番号が用いられている場合、同一の構成要素を表す。フローチャートおよびプロセスの番号は、工程および処理を図示する際に分かり易いよう用いているものであり、具体的な順序または順番を必ずしも意味するものではない。

以下ではまず技術の実施形態の概略を説明した後、具体的な技術の実施形態をさらに詳細に説明する。最初に記載する要約は、当該技術をより短時間で理解できるようにすることを意図しているが、当該技術の重要な特徴または不可欠な特徴を特定することを意図したものではなく、請求の対象となる主題の範囲を限定することを意図したものでもない。

ハイパーテキストトランスファープロトコル（ＨＴＴＰ）アダプティブストリーミング（ＨＡＳ）は、インターネットビデオのマルチメディア配信の一形態として利用され得る。ＨＴＴＰベースの配信によれば、ＨＴＴＰおよびＨＴＴＰの下位プロトコルの両方、トランスミッションコントロールプロトコル（ＴＣＰ）／インターネットプロトコル（ＩＰ）等を広範囲にわたって採用することにより、高い信頼性が得られ、配備が単純になり得る。ＨＴＴＰベースの配信によって、ネットワークアドレス変換（ＮＡＴ）およびファイアウォールの突破の問題を回避し、簡単で手間のかからないストリーミングサービスが可能となり得る。ＨＴＴＰベースの配信またはストリーミングによってさらに、特別なストリーミングサーバではなく、標準的なＨＴＴＰサーバおよびキャッシュを利用することが可能になり得る。ＨＴＴＰベースの配信は、サーバ側のステート情報が最小限に抑えられるため、または、少なくなるため、スケーラビリティを実現し得る。

ＨＡＳを用いてインターネットマルチメディアコンテンツを配信する場合、モバイルデバイスで動作しているビデオクライアントは、レート適応化において主要な役割を果たすよう構成され得る。具体的には、マルチメディアサーバ等の特定されたリソースからデータを取り出すべくＨＴＴＰ ＧＥＴまたはパーシャル（部分的）ＧＥＴコマンドを利用して、ビデオサーバに対して、適切なビデオリプレゼンテーションレベルを選択して要求する。ビデオクライアントは最初に、オーディオまたはビデオ等のストリーミングマルチメディアコンテンツの再生を開始する前に、ある程度のレベルまでバッファを構築する。このフェーズは、スタートアップフェーズと呼ばれる。この後、クライアントはバッファリングされたマルチメディアコンテンツの再生を開始する。クライアントデバイスにおけるマルチメディア再生の品質および解像度は、利用可能なリンク帯域幅によって決まる。ビデオクライアントは普通、ＨＴＴＰレベルのビデオストリーミングスループット等の上位層のスループット推定値、または、トランスミッションコントロールプロトコル（ＴＣＰ）スループットにのみ基づいて、利用可能なリンク帯域幅を推定する。

移動が多い環境におけるマルチメディアストリーミングは、ネットワーク状況の変動（つまり、ネットワーク可変性）によってマルチメディアコンテンツに対応付けられている通信データレートが劣化し、課題が多いとしてよい。ネットワークの負荷が過剰になると通信データレートが下がり、エンドユーザの使用感（ＱｏＥ）も同様に下がってしまう可能性がある。例えば、モバイルデバイスで受信したマルチメディアコンテンツは、解像度または品質が低くなっている場合があり、および／または、マルチメディアコンテンツは、負荷が過剰になったネットワークを介して提供されている最中には、周期的に中断または一時停止する場合がある。

リソースが限られているモバイルネットワークにおける先行ダウンロードベースのストリーミング技術の利用は、帯域幅の利用率が非効率的であり、エンドユーザの使用感が悪いので、望ましくない場合がある。以下でさらに詳細に説明するが、ハイパーテキストトランスファープロトコル（ＨＴＴＰ）ベースのストリーミングサービス、例えば、ＨＴＴＰでの動的アダプティブストリーミング（ＤＡＳＨ）は、先行ダウンロードベースのストリーミングの弱点に対処するべく用いられるとしてよい。

ユーザ機器（ＵＥ）等のクライアントに対してストリーミングされるマルチメディアコンテンツは、複数のマルチメディアコンテンツセグメントを含むとしてよい。各マルチメディアコンテンツセグメントは、マルチメディアコンテンツの複数の異なる品質レベルを表す複数の異なるエンコードバージョンを含むとしてよい。複数の異なるエンコードバージョンを含むことによって、クライアントは、変動するネットワーク状況にシームレスに適応することが可能になるとしてよい。例えば、ネットワーク状況が良好である場合（つまり、ネットワーク状況が予め定められたしきい値を上回る場合）、クライアントは、高いビデオ品質のマルチメディアコンテンツセグメントを要求するとしてよい。ネットワーク状況が悪い場合（つまり、ネットワーク状況が予め定められたしきい値を下回る場合）、クライアントは、低いビデオ品質のマルチメディアコンテンツセグメントを要求するとしてよい。この結果、クライアントは、ネットワーク状況が悪い場合もマルチメディアコンテンツセグメントを（品質は低くなるものの）変わらず受信することが可能であり、アダプティブメディアストリームが中断される可能性が減るとしてよい。

ＤＡＳＨでは、メディア再生の際にリバッファリングイベントを発生させることなくメディア再生に間に合うようにマルチメディアコンテンツセグメントをクライアントにダウンロードすることができるように、クライアントはビットレートが最も高いマルチメディアコンテンツセグメントを選択するとしてよい。言い換えると、クライアントは、ビットレートが高くてアダプティブメディアストリームが周期的に中断され、クライアントでのメディア再生を再開する前にメディアコンテンツの一部分をクライアントにキャッシュまたはプリロードするようなマルチメディアコンテンツセグメントは選択しないとしてよい。一例を挙げると、ネットワーク状況が不利な場合、メディアコンテンツストリームの品質が劣化する可能性がある。不利なネットワーク状況とは、ゼロカバレッジ、急峻な帯域幅の変動、パケット損失、遅延の大きなばらつき等を含むとしてよい。アダプティブストリーミング技術は、利用可能なスループットを算出する際、且つ、利用可能なスループットに基づいて適切なストリーミングビットレートを決定する際に現在のネットワーク状況を考慮し得るが、ネットワーク変動が急峻である場合、および／または、ネットワーク状況が不利な場合には、クライアントにおける円滑なメディア再生は保証されないとしてよい。

このため、クライアントにおけるアダプティブメディアストリームについて望ましいユーザ感を維持するべく、クライアントの予定ルート、および、予定ルート上の現在のネットワーク状況に基づき、マルチメディアコンテンツセグメントをクライアントに戦略的にキャッシュするとしてよい。これにより、メディア再生がより円滑化され、クライアントにおけるユーザ感が改善される。クライアントは、予定ルート（つまり、クライアントが進み始める予定の地理的ルート）を選択するとしてよい。クライアントは、予定ルートを進みつつメディアコンテンツ（例えば、映画）をストリーミングするとしてよい。一例を挙げると、クライアントは、移動している車両内に配置されているモバイルデバイス、または、当該車両のコンピューティングデバイスを含むとしてよい。クライアントは、チャネル情報データベース（ＣＩＤ）から、予定ルートについての現在のネットワーク状況を受信するとしてよい。現在のネットワーク状況は、予め定められたしきい値を下回るネットワーク状況が対応付けられている、予定ルート上の特定の場所（例えば、トンネル、橋、へき地）を含むとしてよい。クライアントは、メディアコンテンツサーバに対して、メディアコンテンツの追加メディアコンテンツセグメント（例えば、映画の追加セグメント）を要求して、これらの追加メディアコンテンツセグメントをキャッシュに格納するとしてよい。クライアントは、予め定められたしきい値を下回るネットワーク状況に対応付けられている予定ルート上の場所に到着すると、キャッシュに格納されているメディアコンテンツを再生するとしてよい。この結果、クライアントにおいてはメディア再生が実質的に、予定ルート上の現在のネットワーク状況が予め定められたしきい値を下回っている間であっても、連続的に行われるとしてよい。

＜無線マルチメディア規格＞ モバイルコンピューティングデバイスへの、モバイルコンピューティングデバイスからの、または、モバイルコンピューティングデバイス間でのマルチメディアの通信を可能とするべく多くのマルチメディア規格が開発されてきた。例えば、ビデオのストリーミングについて、第３世代パートナーシッププロジェクト（３ＧＰＰ）が、オンデマンドコンテンツまたはライブコンテンツのユニキャストストリーミングのためのリアルタイムストリーミングプロトコル（ＲＴＳＰ）ベースのパケットスイッチングストリーミングサービス（ＰＳＳ）を説明している技術仕様書（ＴＳ）２６．２３４（例えば、リリース１１．０．０）を開発した。さらに、先行ダウンロードおよびＨＴＴＰでの動的アダプティブストリーミング（ＤＡＳＨ）を含むハイパーテキストトランスファープロトコル（ＨＴＴＰ）ベースのストリーミングサービスは、３ＧＰＰ ＴＳ ２６．２４７（例えば、リリース１１．０．０）に記載されている。３ＧＰＰベースのマルチメディアブロードキャストマルチキャストサービス（ＭＢＭＳ）の仕様のＴＳ２６．３４６（例えば、リリース１１．０．０）は、マルチキャスト／ブロードキャストのコンテンツ配信のためのストリーミングおよびダウンロードの技術の仕様を説明している。このため、ＤＡＳＨ／ＰＳＳ／ＭＢＭＳベースのモバイルコンピューティングデバイス、例えばユーザ機器（ＵＥ）は、ＵＥデバイスにおいて、ストリーミングされたビデオをデコードしてレンダリングする。３ＧＰＰ ＴＳ２６．２４４（例えば、リリース１１．０．０）における３ＧＰファイル形式のサポートは、ファイルダウンロードおよびＨＴＴＰベースのストリーミングの利用をサポートするべく、これらの仕様のいずれにおいても義務付けられている。

会話形式ビデオ通信、例えば、ビデオ会議の規格の一例が３ＧＰＰ ＴＳ ２６．１１４（例えば、１１．０．０）に記載されている。この規格は、高度なマルチメディア会話形式サービスおよびコンテンツを、インターネットプロトコル（ＩＰ）マルチメディアサブシステム（ＩＭＳ）ベースのネットワークを介して配信できるようにする、ＩＭＳでのマルチメディア電話サービス（ＭＴＳＩ）を説明している。ＩＭＳは、３ＧＰＰ ＴＳ ２６．１４０（例えば、リリース１１．０．０）で規格化されている。ＭＴＳＩベースの送信側ＵＥ端末は、ビデオの撮影および録画が可能であり、当該ビデオをＭＴＳＩベースの受信側ＵＥ端末に３ＧＰＰネットワークを介して転送することができる。受信側ＵＥ端末はこの後、ビデオをデコードしてレンダリングするとしてよい。３ＧＰＰ ＴＳ ２６．１４０はさらに、３ＧＰファイル形式がサポートされているマルチメディア共有サービス（ＭＭＳ）を用いたビデオ共有も可能とする。

上述した規格は、マルチメディアファイルをマルチメディアデバイスに対して、マルチメディアデバイスから、および／または、マルチメディアデバイス間で通信するために用いられ得る無線マルチメディア規格の例として記載している。上述した例は限定を意図したものではない。ストリーミングビデオ、会話形式ビデオまたはビデオ共有を実現するべく他の規格を追加で利用するとしてもよい。

＜ストリーミングメディア規格＞ ここでＨＴＴＰストリーミング、より具体的にはＤＡＳＨ規格を、本発明の実施形態に基づきより詳細に説明する。記載する詳細な説明は限定を意図したものではない。以降のパラグラフでさらに説明するが、本発明の実施形態は、モバイルデバイスに対して、モバイルデバイスから、および／または、モバイルデバイス間で、モバイルデバイスまたは当該モバイルデバイスと通信しているサーバが、所望のエネルギー特徴を持つマルチメディアを選択および／または通信できるようにすることで、マルチメディアを効率的に通信するべく用いられ得る。マルチメディアは、規格化された通信方式または規格化されていない通信方式を用いて通信し得る。

ハイパーテキストトランスファープロトコル（ＨＴＴＰ）ストリーミングは、インターネットビデオのマルチメディア配信の一形態として利用され得る。ＨＴＴＰストリーミングでは、マルチメディアファイルは、一または複数のセグメントに分割されて、ＨＴＴＰプロトコルを用いてクライアントに配信されるとしてよい。ＨＴＴＰベースの配信によれば、ＨＴＴＰおよびＨＴＴＰの下位プロトコルの両方、トランスミッションコントロールプロトコル（ＴＣＰ）／インターネットプロトコル（ＩＰ）等を広範囲にわたって採用することにより、高い信頼性が得られ、配備が単純になり得る。ＨＴＴＰベースの配信によって、ネットワークアドレス変換（ＮＡＴ）およびファイアウォールの突破の問題を回避し、ストリーミングサービスの簡略化が可能になり得る。ＨＴＴＰベースの配信またはストリーミングによってさらに、特別なストリーミングサーバではなく、標準的なＨＴＴＰサーバおよびキャッシュを利用することが可能になり得る。ＨＴＴＰベースの配信は、サーバ側のステート情報が最小限に抑えられるため、または、少なくなるため、スケーラビリティを実現し得る。ＨＴＴＰストリーミング技術の例には、Ｍｉｃｒｏｓｏｆｔ社のＩＩＳ Ｓｍｏｏｔｈ Ｓｔｒｅａｍｉｎｇ、Ａｐｐｌｅ社のＨＴＴＰ Ｌｉｖｅ ＳｔｒｅａｍｉｎｇおよびＡｄｏｂｅ社のＨＴＴＰ Ｄｙｎａｍｉｃ Ｓｔｒｅａｍｉｎｇが含まれ得る。

ＤＡＳＨは、規格化されたＨＴＴＰストリーミングプロトコルである。図１に示すように、ＤＡＳＨは、セグメント形式と同様に、サーバに格納されているメディアコンテンツリプレゼンテーションの複数の異なるバージョンおよび構造に関する情報を提供するメディアプレゼンテーション記述（ＭＰＤ）メタデータファイル１０２について複数の異なる形式を特定し得る。ＭＰＤメタデータファイルは、メディアプレーヤ用の初期化セグメントおよびメディアセグメントに関する情報（例えば、メディアプレーヤは、初期化セグメントを参照して、コンテナ形式およびメディアタイミング情報を決定するとしてよい）を含み、他のリプレゼンテーションとのプレゼンテーションの同期およびスイッチングのためにメディアプレゼンテーションタイムラインへのセグメントのマッピングを確実に行う。ＤＡＳＨ技術はさらに、Ｍｏｖｉｎｇ Ｐｉｃｔｕｒｅ Ｅｘｐｅｒｔｓ Ｇｒｏｕｐ（ＭＰＥＧ）、Ｏｐｅｎ ＩＰＴＶ Ｆｏｒｕｍ（ＯＩＰＦ）およびＨｙｂｒｉｄ Ｂｒｏａｄｃａｓｔ Ｂｒｏａｄｂａｎｄ ＴＶ（ＨｂｂＴＶ）等の他の機関によっても規格化されている。

ＤＡＳＨクライアントは、一連のＨＴＴＰ要求−応答トランザクションを利用してセグメントをダウンロードすることによってマルチメディアコンテンツを受信し得る。ＤＡＳＨによって、モバイルデバイスが利用可能な帯域幅の変化に応じて、メディアコンテンツの複数の異なるビットレートリプレゼンテーションの間で動的に切り替えることが可能になるとしてよい。このように、ＤＡＳＨによれば、変動するネットワークおよび無線リンクの状況、ユーザの好み、ならびに、表示解像度、利用している中央演算処理装置（ＣＰＵ）の種類および利用可能なメモリリソース等のデバイス機能への短時間での適応化が可能となるとしてよい。ＤＡＳＨの動的適応化によって、他のストリーミングプロトコルに比べ、ユーザの使用感（ＱｏＥ）が改善され、スタートアップ遅延が短くなり、リバッファリングイベントが少なくなるとしてよい。

ＤＡＳＨでは、図２に示すように、ウェブ／メディアサーバ２１２に格納されているメディアコンテンツリプレゼンテーションの複数の異なるバージョンおよび構造に関する情報をメディアプレゼンテーション記述（ＭＰＤ）メタデータ１０２が提供し得る。図１に図示した例では、ＭＰＤメタデータを、予め定められた長さ、例えば、本例では６０秒の期間に時間軸に沿って分割する。それぞれの期間は、複数のアダプテーションセット１０４を含むとしてよい。各アダプテーションセットは、一または複数のメディアコンポーネントについての情報にエンコードされた複数の選択肢を与えるとしてよい。例えば、本例におけるアダプテーションセット０は、さまざまな異なる方法でエンコードされたオーディオの選択肢、例えば、異なるビットレート、モノラル方式、ステレオ方式、サラウンドサウンド方式等を含むとしてよい。アダプテーションセットは、期間ＩＤにわたって一のマルチメディアプレゼンテーションについて複数の異なる品質のオーディオを提供することに加え、さらに複数の異なる言語のオーディオを含むとしてもよい。アダプテーションセットで提供される複数の異なる選択肢は、リプレゼンテーション１０６と呼ぶ。

図１において、アダプテーションセット１は複数の異なるビットレート、例えば、５メガビット毎秒（Ｍｂｐｓ）、２Ｍｂｐｓ、５００キロビット毎秒（ｋｂｐｓ）またはトリックモードのビデオを提供するものとして図示されている。トリックモードは、検索、高速早送り、巻き戻し、または、その他のマルチメディアストリーミングファイル内での位置の変更のために用いられ得る。ビデオはさらに、複数の異なる形式、例えば、２次元（２Ｄ）ビデオまたは３次元（３Ｄ）ビデオで利用可能であるとしてもよい。各リプレゼンテーション１０６は、セグメント情報１０８を含むとしてよい。セグメント情報は、初期化情報１１０および実際メディアセグメントデータ１１２を含むとしてよい。本例において、ＭＰＥＧ４（ＭＰ４）ファイルはサーバからモバイルデバイスにストリーミングされる。本例ではＭＰ４を利用しているが、先述したように、広範囲にわたるさまざまな異なるコーデックを利用するとしてよい。

アダプテーションセットでは、マルチメディアはさらにより小さいセグメントに分割され得る。図１の例では、アダプテーションセット１の６０秒のビデオセグメントがさらに、それぞれ１５秒の４つのサブセグメント１１２に分割される。これらの例は限定を意図したものではない。アダプテーションセットおよび各メディアセグメントまたは各サブセグメントの実際の長さは、メディアの種類、システム要件、発生し得る干渉の種類等に応じて決まる。実際メディアセグメントまたはサブセグメントの長さは、１秒未満から数分であってよい。

図２に示すように、ＭＰＤメタデータ情報は、モバイルデバイス等のクライアント２２０に通信され得る。モバイルデバイスは、ストリーミングメディアを受信および表示するよう構成されている無線デバイスであってよい。一実施形態において、モバイルデバイスはこの機能の一部のみを実行するとしてよい。例えば、ストリーミングメディアを受信した後、当該ストリーミングメディアをレンダリングのために別のデバイスまたは表示デバイスに通信するとしてよい。モバイルデバイスは、クライアント２２０を実行するよう構成されているとしてよい。クライアントは、ＨＴＴＰ ＧＥＴ２４０メッセージまたは一連のパーシャルＧＥＴメッセージを用いてセグメントを要求するとしてよい。クライアントは、無線リンク、デバイス状態またはユーザの嗜好の変化に対応するべく、ストリーミングセッションを制御することができる。例えば、クライアントは、複数のセグメントから成るシーケンスの円滑な再生およびオンタイム要求の管理、または、ビットレートまたはその他の属性の調整が可能である。

図２は、ＤＡＳＨベースのストリーミングフレームワークを示す図である。ウェブ／メディアサーバ２１２のメディアエンコード部２１４は、オーディオ／ビデオ入力２１０からの入力メディアを、格納またはストリーミング用の形式にエンコードするとしてよい。メディア分割部２１６は、入力メディアを一連のセグメント２３２に分割するために利用され得る。一連のセグメント２３２はウェブサーバ２１８に提供し得る。クライアント２２０は、ウェブサーバ（例えば、ＨＴＴＰサーバ）に送信されるＨＴＴＰ ＧＥＴメッセージ２３４を用いてセグメント単位で新しいデータを要求するとしてよい。

例えば、クライアント２２０のウェブブラウザ２２２は、ＨＴＴＰ ＧＥＴメッセージ２４０を用いてマルチメディアコンテンツを要求するとしてよい。ウェブサーバ２１８は、クライアントに、マルチメディアコンテンツのＭＰＤ２４２を提供するとしてよい。ＭＰＤは、各セグメントのインデックス、および、対応付けられているメタデータ情報に示されている当該セグメントの対応する位置を伝えるために用いられ得る２５２。ウェブブラウザは、２３６に図示しているようにＭＰＤ２４２にしたがってセグメント単位でサーバからメディアを引き出すとしてよい。例えば、ウェブブラウザは、ＨＴＴＰ ＧＥＴ ＵＲＬ（ｆｒａｇ １ ｒｅｑ）２４４を用いて、第１のセグメントを要求することができる。ユニフォームリソースロケータ（ＵＲＬ）またはユニバーサルリソースロケータを用いて、クライアントがどのセグメントを要求しているのかウェブサーバに伝えるとしてよい２５４。ウェブサーバは、第１のフラグメント（つまり、セグメント１ ２４６）を提供するとしてよい。後続のセグメントについては、ウェブブラウザは、ＨＴＴＰ ＧＥＴ ＵＲＬ（ｆｒａｇ ｉ ｒｅｑ）２４８を用いてセグメントｉを要求するとしてよい。尚、ｉはセグメントの整数値のインデックスである。この結果、ウェブサーバはセグメントｉ２５０を提供するとしてよい。セグメントはメディアデコーダ／プレーヤ２２４を介してクライアントに渡されるとしてよい。

図３は、ＨＴＴＰサーバ３１０との間のマルチメディアコンテンツ３１２の流れを説明するための図である。ＨＴＴＰサーバ３１０は、マルチメディアコンテンツを、ＵＥ３３６等のモバイルデバイスで動作する３ＧＰＰクライアント３３８に提供する。ＨＴＴＰサーバは、ワイヤレスワイドエリアネットワーク（ＷＷＡＮ）のコアネットワーク３２４と通信している公共ネットワークまたは私用ネットワーク３２２（またはインターネット）とやり取りすることができる。一実施形態において、ＷＷＡＮは、３ＧＰＰ ＬＴＥベースのネットワークまたはＩＥＥＥ８０２．１６ベースのネットワーク（つまり、８０２．１６−２００９）であってよい。コアネットワークは、無線アクセスネットワーク（ＲＡＮ）３３２を介してエボルブドパケットシステム（ＥＰＳ）等の無線ネットワーク３３０にアクセスすることができる。ＲＡＮ３３２は、ノード（例えば、エボルブドＮｏｄｅＢ（ｅＮＢ）３３４）を介してＵＥ３３６で動作しているクライアントにマルチメディアコンテンツを提供するとしてよい。

一例を挙げると、ＨＴＴＰサーバ３１０は、チャネル情報データベース３５０に結合されるとしてよい。チャネル情報データベース３５０は、複数の地理的な場所について現在のネットワーク状況を含むとしてよい。複数の地理的な場所とは、特定の道路、道、地域、地理的領域、橋、トンネル等を含むとしてよい。現在のネットワーク状況は、複数の地理的な場所について現在のネットワーク状況をリアルタイムで監視することに基づいて得られるとしてよい。このため、チャネル情報データベース３５０は、現在のネットワーク状況の変化に応じて動的に更新されるとしてよい。これに代えて、現在のネットワーク状況は、複数の地理的な場所についての過去のネットワーク状況情報に基づき推測されるとしてもよい。さらに別の例では、現在のネットワーク状況は、クラウドソーシングで得たネットワーク状況情報を用いて決定するとしてよい。

図４は、予定ルート上のネットワーク状況、および、予定ルート上の特定の場所に到着する前のメディアコンテンツセグメントの戦略的なキャッシュを説明するための図である。ユーザ機器（ＵＥ）は、当該ＵＥに対応付けられる予定ルートを決定するとしてよい。予定ルートは、目的予定地に到着するべくＵＥがこれから進もうとしている地理的ルートを含むとしてよい。例えば、予定ルートは、職場、学校、食料品店、映画館、国立公園等へのルートを含むとしてよい。一例を挙げると、ＵＥは、目的予定地に到着するべく予定ルートを同様に進む予定の車両内にあるとしてよい。言い換えると、ＵＥおよび車両は、目的予定地に到着するべく予定ルートで同時に（例えば、同じ速度で）移動するとしてよい。ＵＥは、これに限定されないが、モバイルデバイス、タブレットコンピュータ、ラップトップコンピュータ、スマートウォッチ等を含むとしてよい。

一の構成によると、ＵＥは、当該ＵＥの予定ルートを進む間にメディアサーバからメディアコンテンツをストリーミングするとしてよい。メディアサーバは、ＨＴＴＰサーバに結合されているとしてもよいし、または、ＨＴＴＰサーバに含まれるとしてもよい。言い換えると、ＵＥは、目的予定地へ向かう間に、映画、テレビ番組等をストリーミングするとしてよい。一例を挙げると、ＵＥは、目的予定地に移動している途中の車両内にあるとしてよい。ＵＥは、運転手が操作するとしてもよいし、または、車両内にいる同乗者が操作するとしてもよい。さらに別の例によると、車両に組み込まれているコンピューティングシステムは、車両が目的予定地に向かって移動している間に、車両内のディスプレイスクリーンにメディアコンテンツをストリーミングするとしてよい。

一例を挙げると、ＵＥは、ウェブマッピングサービスアプリケーションに目的地の名称または目的地の住所を提供するとしてよい。目的地の名称または住所は、ＵＥおよび／または車両の所望の目的地であってよい。ウェブマッピングサービスアプリケーションは、リモートサーバまたはクラウドサーバで動作するとしてよい。ＵＥはさらに、ＵＥの現在の地理的な場所をウェブマッピングサービスアプリケーションに提供するとしてよい。ＵＥは、自分の現在の地理的な場所を、グローバルポジションシステム（ＧＰＳ）、三角測量法、または、ＵＥの現在の地理的な場所を決定するために利用可能なその他のメカニズムを用いて決定するとしてよい。ウェブマッピングサービスアプリケーションは、目的地の名称／住所およびＵＥの現在の地理的な場所を用いて、ＵＥの予定ルートを作成するとしてよい。予定ルートは、ＵＥが目的地の名称または目的地の住所に到着するべくＵＥが進み得る一連の道路およびナビゲーション指示（例えば、左折および右折）を含むとしてよい。ウェブマッピングサービスアプリケーションは、予定ルートに対応付けられている予定ルート情報をＵＥに対して提供するとしてよい。予定ルート情報によって、ＵＥは、ＵＥの現在の場所（例えば、職場の建物）から目的地（例えば、近隣の公園）までの間を移動出来るようになるとしてよい。

別の構成によると、車両に組み込まれているコンピューティングシステムは、目的地の名称または目的地の住所をウェブマッピングサービスアプリケーションに提供するとしてよい。ウェブマッピングサービスアプリケーションは、車両が望む目的地に到着できるように予定ルートを決定するとしてよい。車両は、ウェブマッピングサービスアプリケーションを介して予定ルートを受信すると、所望の目的地に到着するように予定ルートに従って進むとしてよい。

ＵＥは、予定ルート情報をウェブマッピングサービスアプリケーションから受信すると、予定ルート情報をＨＴＴＰサーバに提供するとしてよい。ＨＴＴＰサーバは、チャネル情報データベース（ＣＩＤ）を含むとしてよい。上述したように、ＣＩＤは、複数の地理的な場所について現在のネットワーク状況または無線チャネル情報を含むとしてよい。現在のネットワーク状況は、ネットワークをリアルタイムで監視することおよび／またはクラウドソーシングされた情報に基づいて、リアルタイムで動的に更新されるとしてよい。さらに、現在のネットワーク状況は、過去のネットワーク状況情報を用いて推測するとしてもよい。ＨＴＴＰサーバは、ＣＩＤに格納されている情報を用いて、ＵＥの予定ルートについて現在のネットワーク状況を特定するとしてよい。言い換えると、ＨＴＴＰサーバは、ＵＥが予定ルート上を移動している間に通る予定の特定の道路、橋等についての現在のネットワーク状況を提供するとしてよい。ＵＥは、ＨＴＴＰサーバから、予定ルートについての現在のネットワーク状況または無線チャネル情報を受信するとしてよい。

グラフ４１０および４２０は、予定ルートの現在のネットワーク状況または無線チャネル情報の例を図表で示す。予定ルートの現在のネットワーク状況は、ＨＴＴＰサーバからＵＥにおいて受信するとしてよい。予定ルートは、第１の地理的な場所（例えば、地点Ａ）で始まり、第２の地理的な場所（例えば、地点Ｂ）で終わるとしてよい。例として、地点Ａと地点Ｂとの間の距離が１０キロメートル（ｋｍ）で、地点Ａが学校、地点Ｂが公園であるとする。

一例を挙げると、グラフ４１０のＸ軸はＵＥが移動する予定の距離を表しており、グラフ４１０のＹ軸は信号ノイズ比（ＳＮＲ）予想値を表すとしてよい。さらに、ＳＮＲ予想値は、予定ルートの現在のネットワーク状況に対応するとしてよい。相対的に高いＳＮＲ予想値は、予定ルートの対応部分においてネットワーク状況が良好であることを示すとしてよく、相対的に低いＳＮＲ予想値は、予定ルートの対応部分においてネットワーク状況が良好でないことを示すとしてよい。

同様に、グラフ４２０のＸ軸はＵＥが移動する予定の距離を表しており、グラフ４２０のＹ軸はフレームドロップレート予想値を表すとしてよい。フレームドロップレート予想値は、予定ルートの現在のネットワーク状況に対応するとしてよい。相対的に高いフレームドロップレート予想値は、予定ルートの対応部分においてネットワーク状況が良好でないことを示すとしてよく、相対的に低いフレームドロップレート予想値は、予定ルートの対応部分においてネットワーク状況が良好であることを示すとしてよい。

予定経路の無線ネットワークチャネル状況（つまり、予定ルート上のＳＮＲ予想値およびフレームドロップレート予想値）は、メディアストリームがＵＥおよび／または車両に提供されている場合のユーザの使用感に影響を与えるとしてよい。例えば、良好なネットワーク状況（つまり、比較的高いＳＮＲ値および比較的低いフレームドロップレート）は概して、比較的望ましいユーザ使用感を実現できるが、良好でないネットワーク状況（つまり、比較的低いＳＮＲ値および比較的高いフレームドロップレート）は概して、比較的望ましくないユーザ使用感につながってしまうとしてよい。

ＵＥは、ＨＴＴＰサーバから受信した無線チャネル情報に基づき、無線ネットワークチャネル状況が定められたしきい値未満になる予定ルート上の場所を特定するとしてよい。例えば、ＵＥは、ＳＮＲ予想値が定められたしきい値未満になる予定ルート上の場所を特定するとしてよい。同様に、ＵＥは、フレームドロップレート予想値が定められたしきい値を上回る予定ルート上の場所を特定するとしてよい。ＵＥは、予定ルート上のそのような場所に到着する前に、無線ネットワークチャネル状況が定められたしきい値未満になると予想される場所を特定するとしてよい。例えば、ＵＥは、予定ルートを進み始める前に、および／または、目的予定地まで予定ルートを進んでいる間に、場所を特定するとしてよい。

図４に示す例では、ＵＥは、ＳＮＲ予想値が定められたしきい値未満である、地点Ａから地点Ｂまでの予定ルート上の場所を特定するとしてよい。また、この場所では、フレームドロップレート予想値が定められたしきい値を超えるとしてよい。この場所は、ネットワークチャネル状況が概して悪い橋、トンネル、へき地等に対応するとしてよい。言い換えると、この特定の場所においてメディアサーバからＵＥおよび／または車両へストリーミングされるメディアコンテンツは、コマ落ち（フレームドロップ）が発生する可能性があり（つまり、ビデオ品質が低下し）、および／または、メディアコンテンツセグメントのバッファリング中にはメディアコンテンツ再生が中断される可能性がある。

一の構成によると、ＵＥは、現在のネットワーク状況に基づいて、ＵＥの予定ルート中にＵＥに提供されるメディアコンテンツセグメントの平均送信速度を決定するとしてよい。例えば、ＵＥは、予定ルートに係る時間の長さ（例えば、３０分）を決定するとしてよい。ＵＥはこの後、予定ルート中にＵＥに提供されるメディアコンテンツを特定するとしてよい。一例として、ＵＥは、３０分間の予定ルート中にＵＥに提供される３０分間のメディアコンテンツを特定するとしてよい。ＨＴＴＰサーバから受信した予定ルートのための無線チャネル情報に基づき、ＵＥは、予定ルートを移動中に提供されるメディアコンテンツセグメントのそれぞれについて平均ビットレートを決定するとしてよい。ＵＥは、ＨＴＴＰサーバから受信する予定ルートのための無線チャネル情報で示されるように、無線ネットワークチャネル状況が良好であると予想される時にＵＥで受信されるメディアコンテンツセグメント、および、無線ネットワークチャネル状況が悪いと予想される時にＵＥで受信されるメディアコンテンツセグメントを特定するとしてよい。

ＵＥは、無線ネットワークチャネル状況が定められたしきい値未満である予定ルート上の一または複数の場所に進入する前に、メディアサーバに追加メディアコンテンツセグメントを要求するとしてよい。ＵＥが要求した追加メディアコンテンツセグメントは、既にＵＥによって特定されたものであってよい。ＵＥが特定したこれらのメディアコンテンツセグメントは、予定ルートのネットワークチャネル状況が悪いと予想される時にＵＥで受信されるように最初にスケジューリングされるとしてよい。このため、ＵＥは、予定ルートのネットワークチャネル状況が悪いと予想される間にこれらのメディアコンテンツセグメントがＵＥに通信されないように、これらのメディアコンテンツセグメントを前もって要求するとしてよい。

ＵＥは、予め定められた期間にしたがって、ある場所に進入する前に、追加メディアコンテンツセグメントを要求するとしてよい。例えば、ＵＥは、この場所に進入する２分前に追加メディアコンテンツセグメントを要求するとしてよい。一の構成によると、予め定められた期間は、予定ルート上の無線ネットワークチャネル状況に基づき、動的に更新されるとしてよい。予め定められた期間は、この場所の面積が大きくなるほど（つまり、ＵＥがネットワークチャネル状況が悪い領域にとどまる時間が長くなると予想される場合）、長くなるとしてよい。例えば、ネットワークチャネル状況が悪いと予想される５分間の領域にＵＥが近づいている場合、ＵＥは、この領域に進入する２０分前に追加メディアコンテンツセグメントを要求するとしてよい。

ＵＥは、ＵＥに対応付けられているバッファまたはキャッシュに追加メディアコンテンツセグメントを格納するとしてよい。 ＵＥは、予定ルート上の決定された場所に進入すると、バッファまたはキャッシュに格納されている追加メディアコンテンツセグメントを用いてメディアコンテンツ再生を実行するとしてよい。言い換えると、ＵＥは、ネットワークチャネル状況が悪い可能性が高い場所においてメディアコンテンツをストリーミングする必要はない。このため、ＵＥがネットワークチャネル状況が悪い場所を通過する場合であっても、予定ルートでは連続的なメディアコンテンツ再生がＵＥにおいて実質的に可能になるとしてよい。これに代えて、ＵＥは、バッファに格納するべきメディアコンテンツセグメントを新たに同時に受信しつつ、バッファに格納されている追加メディアコンテンツセグメントを用いてメディアコンテンツ再生を実行するとしてもよい。この場合、新しいメディアコンテンツセグメントは、ＵＥがネットワーク状況が悪い場所にあるので、ビットレートを下げて受信されるとしてよい。

ＵＥは、予定ルート上の決定された場所から退出すると、旧式のビットレート適応化バッファリングメカニズムに戻るとしてよい。言い換えると、ＵＥは、決定された場所から退出すると（ネットワークチャネル状況が定められたしきい値未満である別の場所にＵＥが近づいていない限り）、追加メディアコンテンツセグメントを要求しないとしてよい。一例を挙げると、ＵＥの旧式のバッファリングメカニズムは、予め定められたサイズのメディアコンテンツセグメント（例えば、約３メガバイト（ＭＢ）のメディアコンテンツセグメント）を格納するとしてよく、予定ルート上の決定された場所における再生のための追加メディアコンテンツセグメントを格納しない。ＵＥは、ＤＡＳＨまたは他の同様のメディアコンテンツストリーミング技術が実現する帯域幅節約の恩恵を受けるべく、決定された場所を退出すると旧式のビットレート適応化に戻るとしてよい。

一の構成によると、ＵＥは、ネットワークチャネル状況が比較的悪い場所に進入した場合でもメディアコンテンツストリームの品質レベルが実質的に変わらないように追加メディアコンテンツセグメントを要求するとしてよい。例えば、ＵＥは、常に１００メガビット毎秒（Ｍｂｉｔｓ／ｓ）のビットレートでのメディアコンテンツのストリーミングを希望しているとしてよい。しかし、予定ルートの一部分では、ネットワーク状況が比較的悪い場合があり、この部分での予想ビットレートは７０Ｍｂｉｔｓ／ｓである可能性がある。このため、ＵＥは、メディアコンテンツストリームが予定ルートの全長にわたって１００Ｍｂｉｔｓ／ｓを実質的に維持できるよう、追加メディアコンテンツセグメントを要求するとしてよい。

ＵＥは、ＵＥの予定ルート上の決定された場所に進入する前にＵＥに提供される追加セグメントの数に応じて、バッファのサイズまたは容量を調整するとしてよい。例として、バッファの容量は、ＵＥに提供される追加セグメントの数に応じて３メガバイト（ＭＢ）から１ギガバイト（ＧＢ）の間で動的に変化するとしてよい。バッファに格納される追加セグメントの数は、ネットワークチャネル状況が悪くなることに応じて、増加するとしてよい。バッファのサイズは予め定められた最大値（例えば、２ＧＢ）に設定されるとしてよい。

一例において、ＵＥに提供中のメディアコンテンツストリームのビデオ品質は、予定経路上でネットワークチャネル状況が悪い場所に到着することを予測してＵＥが同時に追加メディアコンテンツセグメントを受信している場合、わずかに劣化する場合がある。例として、ストリーミング中のメディアコンテンツのビデオ品質は、決定された場所に進入する１分前にわずかに劣化するとしてよい。これは、ＵＥが、決定された場所に到着した場合にも連続的なメディア再生を可能とするべく、追加メディアコンテンツセグメントを受信して格納しているためである。

図４に示すように、ＵＥは、予定経路のうちネットワークチャネル状況が定められたしきい値未満になると予想される部分に到着する前に追加メディアコンテンツセグメントを受信するとしてよい。言い換えると、予定ルートのうちこの期間または距離は、「事前キャッシュ」フェーズとして知られているとしてよい。予定経路のうちネットワークチャネル状況が定められたしきい値未満になる部分にＵＥが到着すると、ＵＥはキャッシュに格納されているメディアコンテンツセグメントを用いてメディアコンテンツ再生を実行するとしてよい。言い換えると、予定ルートのうちこの期間または距離は、「事前キャッシュコンテンツ再生」期間として知られているとしてよい。「事前キャッシュコンテンツ再生」期間は、ＳＮＲ値が低い場所、または、フレームドロップレートが高い場所に対応するとしてよい。ＵＥがネットワークチャネル状況が定められたしきい値未満である場所を退出した後、ＵＥは、旧式のビットレート適応化バッファリングメカニズムに戻るとしてよい。予定ルートのうちこの期間または距離は、「通常復活」期間として知られているとしてよい。

別の例では、図５のフローチャートに図示されているように、アダプティブメディアストリーミングを実行するよう動作可能なユーザ機器（ＵＥ）のコンピュータ回路の機能５００を実現している。当該機能は方法として実装されるとしてもよいし、または、当該機能は機械で命令として実行されるとしてもよい。この場合、命令は少なくとも１つのコンピュータ可読媒体または１つの非一時的機械可読記憶媒体に含まれている。コンピュータ回路は、ブロック５１０に示すように、ＵＥについて予定ルートを選択するよう構成され得る。コンピュータ回路はさらに、ブロック５２０に示すように、予定ルートについて無線チャネル情報をサーバから受信するよう構成され得る。当該サーバは、チャネル情報データベース（ＣＩＤ）を含む。コンピュータ回路はさらに、ブロック５３０に示すように、無線チャネル情報に基づき、無線ネットワークチャネル状況が定められたしきい値未満になる予定ルート上の場所を決定するよう構成され得る。さらに、コンピュータ回路は、ブロック５４０に示すように、予定ルート上の決定された場所に進入する前に、ＵＥにおけるバッファに格納するべく、アダプティブメディアストリームの追加セグメントをメディアサーバに対して要求するよう構成され得る。これによって、予定ルートにおいてメディアストリームの連続的なメディア再生を可能とする。

一の構成によると、コンピュータ回路はさらに、予定ルート上の決定された場所にＵＥが進入するとバッファに格納されているアダプティブメディアストリームの追加セグメントを再生するよう構成され得る。 さらに、コンピュータ回路はさらに、ＵＥの予定ルート上の決定された場所に進入する前にＵＥに提供される追加セグメントの数に応じて、ＵＥにおけるバッファの容量を調整するよう構成され得る。さらに、コンピュータ回路はさらに、ＵＥの予定ルート上の信号ノイズ比（ＳＮＲ）予想値に基づき、無線ネットワークチャネル状況が定められたしきい値未満になる、予定ルート上の場所を決定するよう構成され得る。

一の構成において、コンピュータ回路はさらに、ＵＥの予定ルート上のフレームドロップレート予想値に基づき、無線ネットワークチャネル状況が定められたしきい値未満になる、予定ルート上の場所を決定するよう構成され得る。一例を挙げると、予定ルートのための無線チャネル情報は、過去の無線ネットワークチャネル状況、現在の無線ネットワークチャネル状況、または、クラウドソーシングされた無線ネットワーク状況のうち少なくとも１つに基づいて決まる。さらに、無線チャネル情報は、予定ルートの無線ネットワークチャネル状況の変化に基づいて、予定ルートについて周期的に更新される。一例を挙げると、ＵＥは、アンテナ、タッチセンシティブディスプレイスクリーン、スピーカ、マイクロフォン、グラフィクスプロセッサ、アプリケーションプロセッサ、内部メモリまたは不揮発性メモリポートを含む。

別の例は、図６のフローチャートで示すように、ハイパーテキストトランスファープロトコルでの動的アダプティブストリーミング（ＤＡＳＨ）を実行する方法６００を提供する。当該方法は、機械において命令として実行されるとしてよい。当該命令は、少なくとも１つのコンピュータ可読媒体または１つの非一時的機械可読記憶媒体に含まれているとしてよい。当該方法は、ブロック６１０に示すように、モバイルデバイスのために予定ルートを選択する処理を含む。当該方法は、ブロック６２０に示すように、予定ルートについての無線チャネル情報をサーバから受信することを含むとしてよい。当該サーバは、チャネル情報データベース（ＣＩＤ）を含む。当該方法はさらに、ブロック６３０に示すように、無線チャネル情報に基づき、無線ネットワークチャネル状況が定められたしきい値未満になる予定ルート上の地理的な場所を決定することを含むとしてよい。さらに、当該方法は、ブロック６４０に示すように、予定ルート上の決定された場所に進入する前に、メディアファイルの追加セグメントをメディアサーバに要求することを含むとしてよい。

一例を挙げると、当該方法はさらに、モバイルデバイスにおけるバッファに格納するべくメディアファイルの追加セグメントを受信することを含むとしてよい。これに加えて、当該方法はさらに、無線ネットワークチャネル状況が定められたしきい値未満になる予定ルート上の地理的な場所を通過する間のメディアファイルの連続的なメディア再生を可能とするべく、メディアファイルの追加セグメントを受信することを含むとしてよい。さらに、当該方法は、予定ルート上の決定された場所に進入する前にモバイルデバイスに提供されるメディアファイルの追加セグメントの数に応じて、モバイルデバイスのバッファ容量を調整することを含むとしてよい。

一の構成において、当該方法はさらに、モバイルデバイスの予定ルート上の信号ノイズ比（ＳＮＲ）予想値に基づき、予定ルート上の地理的な場所における無線ネットワークチャネル状況が定められたしきい値未満であると判断することを含むとしてよい。また、当該方法は、モバイルデバイスの予定ルート上のフレームドロップレート予想値に基づき、予定ルート上の地理的な場所における無線ネットワークチャネル状況が定められたしきい値未満であると判断することを含むとしてよい。一例を挙げると、当該方法はさらに、サーバを介してＣＩＤから、予定ルートについての無線ネットワークチャネル状況の過去データに基づく無線チャネル情報を受信することを含むとしてよい。さらに、当該方法は、サーバを介してＣＩＤから、予定ルートについての現在の無線ネットワークチャネル状況に基づく無線チャネル情報を受信することを含むとしてよい。さらに別の例によると、当該方法は、予定ルート上の決定された場所を退出した後、旧式のＤＡＳＨレート適応化バッファリングメカニズムを復活させることを含むとしてよい。

別の例は、図７のフローチャートに示すように、ハイパーテキストトランスファープロトコルでの動的アダプティブストリーミング（ＤＡＳＨ）を実行するよう動作可能なユーザ機器（ＵＥ）のコンピュータ回路の機能７００を提供する。当該機能は方法として実装されるとしてもよいし、または、当該機能は機械で命令として実行されるとしてもよい。この場合、命令は少なくとも１つのコンピュータ可読媒体または１つの非一時的機械可読記憶媒体に含まれる。コンピュータ回路は、ブロック７１０に示すように、ＵＥの予定ルートについて無線チャネル情報を受信するよう構成され得る。コンピュータ回路は、ブロック７２０に示すように、無線チャネル情報に基づき、無線ネットワークチャネル状況が定められたしきい値未満になる予定ルート上の場所を決定するよう構成され得る。コンピュータ回路はさらに、ブロック７３０に示すように、予定ルート上の決定された場所に進入する前に、ＵＥにおけるキャッシュに格納するべく、アダプティブメディアストリームの追加セグメントをメディアサーバに対して要求するよう構成され得る。これによって、予定ルートにおいてメディアストリームの連続的なメディア再生を可能とする。 ＵＥは、予定ルート上の決定された場所を退出した後、旧式のＤＡＳＨレート適応化バッファリングメカニズムに戻る。

一の構成において、コンピュータ回路はさらに、予定ルート上の決定された場所にＵＥが進入するとキャッシュに格納されているアダプティブメディアストリームの追加セグメントを再生するよう構成され得る。これに加えて、コンピュータ回路はさらに、ＵＥの予定ルート上の決定された場所に到着する前にＵＥに提供される追加セグメントの数に応じて、ＵＥにおけるキャッシュの容量を調整するよう構成され得る。さらに、コンピュータ回路は、ＵＥの予定ルート上の信号ノイズ比（ＳＮＲ）予想値またはフレームドロップレート予想値に基づき、無線ネットワークチャネル状況が定められたしきい値未満になる予定ルート上の場所を決定するよう構成され得る。一例を挙げると、コンピュータ回路はさらに、チャネル情報データベース（ＣＩＤ）を含むサーバから、予定ルートの無線チャネル情報を受信するよう構成され得る。無線チャネル情報は、予定ルートの無線ネットワークチャネル状況の過去のデータ、または、予定ルートの現在の無線ネットワークチャネル状況に基づいて決まる。

図８は、ユーザ機器（ＵＥ）、移動局（ＭＳ）、モバイル無線デバイス、モバイル通信デバイス、タブレット、ハンドセット、コンピューティングデバイス、または、その他の種類の無線デバイス等の無線デバイスの一例を図示している。無線デバイスは、ノードまたは基地局（ＢＳ）等の送信局、エボルブドＮｏｄｅＢ（ｅＮＢ）、ベースバンドユニット（ＢＢＵ）、リモートラジオヘッド（ＲＲＨ）、リモートラジオイクイップメント（ＲＲＥ）、中継局（ＲＳ）、ラジオイクイップメント（ＲＥ）、リモートラジオユニット（ＲＲＵ）、中央処理モジュール（ＣＰＭ）またはその他の種類のワイヤレスワイドエリアネットワーク（ＷＷＡＮ）アクセスポイント等と通信するよう構成されている一または複数のアンテナを備えるとしてよい。無線デバイスは、３ＧＰＰ ＬＴＥ、ＷｉＭＡＸ（登録商標）、Ｈｉｇｈ Ｓｐｅｅｄ Ｐａｃｋｅｔ Ａｃｃｅｓｓ（ＨＳＰＡ）、Ｂｌｕｅｔｏｏｔｈ（登録商標）およびＷｉＦｉ（登録商標）を含む、少なくとも１つの無線通信規格を用いて通信するよう構成されているとしてよい。無線デバイスは、無線通信規格毎に別個のアンテナを利用して、または、複数の無線通信規格で共有されているアンテナを利用して通信するとしてもよい。無線デバイスは、ワイヤレスローカルエリアネットワーク（ＷＬＡＮ）、ワイヤレスパーソナルエリアネットワーク（ＷＰＡＮ）および／またはＷＷＡＮにおいて通信するとしてよい。

図８はさらに、無線デバイスとの間のオーディオ入出力に利用され得るマイクロフォンおよび一または複数のスピーカを図示している。ディスプレイスクリーンは、液晶ディスプレイ（ＬＣＤ）スクリーン、または、有機発光ダイオード（ＯＬＥＤ）ディスプレイ等のその他の種類のディスプレイスクリーンであってよい。ディスプレイスクリーンはタッチスクリーンとして構成され得る。タッチスクリーンは、静電容量方式、抵抗膜方式または他の種類のタッチスクリーン技術を利用するとしてよい。アプリケーションプロセッサおよびグラフィクスプロセッサは、処理機能および表示機能を実現するべく内部メモリに結合されるとしてよい。さらに、不揮発性メモリポートを用いてユーザにデータ入出力の選択肢を与えるとしてよい。不揮発性メモリポートはさらに、無線デバイスのメモリ機能を拡張するために用いられるとしてよい。キーボードは、無線デバイスと一体化するか、または、無線デバイスに無線方式で接続して追加でユーザ入力を実現するとしてもよい。また、タッチスクリーンを用いて仮想キーボードを実現するとしてよい。

さまざまな技術、または、その特定の態様あるいは一部は、有形の媒体で具現化されるプログラムコード（つまり、命令）として実現されるとしてよい。有形の媒体としては、フロッピー（登録商標）ディスケット、コンパクトディスクリードオンリーメモリ（ＣＤ−ＲＯＭ）、ハードドライブ、非一時的コンピュータ可読記憶媒体または任意のその他の機械可読記憶媒体が挙げられる。プログラムコードがコンピュータ等の機械にロードされて実行されると、当該機械はさまざまな技術を実施する装置となる。回路は、ハードウェア、ファームウェア、プログラムコード、実行コード、コンピュータ命令および／またはソフトウェアを含むとしてよい。非一時的コンピュータ可読記憶媒体は、信号を含まないコンピュータ可読記憶媒体であってよい。プログラミング可能なコンピュータにおいてプログラムコードを実行する場合、コンピューティングデバイスは、プロセッサ、プロセッサが読み出すことが可能な記憶媒体（揮発性および不揮発性のメモリおよび／または記憶素子を含む）、少なくとも１つの入力デバイス、および、少なくとも１つの出力デバイスを含むとしてよい。揮発性および不揮発性のメモリおよび／または記憶素子は、ランダムアクセスメモリ（ＲＡＭ）、消去可能プログラミング可能リードオンリーメモリ（ＥＰＲＯＭ）、フラッシュドライブ、光ドライブ、磁気ハードドライブ、ソリッドステートドライブ、または、電子データを格納する他の媒体であってよい。ノードおよび無線デバイスはさらに、送受信モジュール（つまり、送受信機）、カウンタモジュール（つまり、カウンタ）、処理モジュール（つまり、プロセッサ）、および／または、クロックモジュール（つまり、クロック）あるいはタイマモジュール（つまり、タイマ）を含むとしてよい。本明細書で説明したさまざまな技術を実装または利用する一または複数のプログラムは、アプリケーションプログラミングインターフェース（ＡＰＩ）、リユーザブルコントロール等を利用するとしてよい。このようなプログラムは、コンピュータシステムと通信させるべく高級プロシージャプログラミング言語またはオブジェクト指向型プログラミング言語で実装されるとしてよい。しかし、プログラムは、所望される場合、アセンブリ言語または機械語で実装されるとしてもよい。いずれの場合も、言語はコンパイラ型言語またはインタプリタ型言語であってよく、ハードウェア実装と組み合わせられるとしてよい。

本明細書で説明する機能部の多くは、実現する際の独立性をより強く強調するためにモジュールという名称を付与したと理解されたい。例えば、一のモジュールは、カスタマイズされた超大規模集積（ＶＬＳＩ）回路あるいはゲートアレイ、ロジックチップ、トランジスタまたはその他のディスクリートコンポーネント等の市販の半導体素子を備えるハードウェア回路として実現されるとしてよい。一のモジュールはまた、複数のプログラミング可能なハードウェアデバイス、例えば、フィールドプログラマブルゲートアレイ、プログラマブルアレイロジック、プログラマブルロジックデバイス等で実現されるとしてもよい。

モジュールはさらに、さまざまな種類のプロセッサで実行されるソフトウェアで実現されるとしてもよい。実行コードのうち特定のモジュールは、例えば、コンピュータ命令の一または複数の物理ブロックまたは論理ブロックを含むとしてよい。これらは、例えば、オブジェクト、プロシージャまたは関数に編成されるとしてよい。しかし、特定のモジュールの複数の実行ファイルは、物理的に同じ位置にある必要はなく、複数の異なる位置に格納されている複数の別個の命令を含むとしてよい。これらの命令は、論理的に一緒に集められることで、モジュールを構成し、当該モジュールについて記述した目的を実現する。

実際、実行コードの一のモジュールは、一の命令であってもよいし、または、多くの命令であってもよい。複数の異なるコードセグメント、複数の異なるプログラム、および、複数のメモリデバイスに分割されていたとしてもよい。同様に、動作データは、複数のモジュール内にあるものとして本明細書で特定および図示されており、任意の適切な形態で具現化されるとしてよく、任意の適切な種類のデータ構造で整理されるとしてよい。動作データは、一のデータセットとして集めるとしてもよく、または、複数の異なる記憶デバイス等の複数の異なる位置に分散しているとしてもよく、少なくとも一部分がシステムまたはネットワーク上の電子信号として単に存在するとしてもよい。モジュールは、受動型または能動型であってよく、所望の機能を実行するよう動作可能なエージェントを含む。

本明細書において「例」または「〜の例」と言及する場合、当該例に関連付けて説明している具体的な特徴、構造または特性は本発明の少なくとも１つの実施形態に含まれることを意味する。このため、本明細書において「例において」または「〜の例」という表現が繰り返し見られるが、必ずしも全てが同じ実施形態を意味するものではない。

本明細書で用いる場合、複数のアイテム、構造要素、構成要素、および／または、材料は、便宜上、一般的なリストの形式で提示されるとしてよい。しかし、これらのリストは、当該リストの各要素はそれぞれ別個且つ一意的な要素として特定されるものと解釈されるべきである。したがって、これらのリストに記載する各要素は、特段の記載なく、一の一般的なグループに含まれていることのみを根拠として、同じリストの任意の他の要素の事実上の均等物として解釈されるべきでない。さらに、本発明のさまざまな実施形態および例は、本明細書において、それらのさまざまな構成要素の代替例と共に記載されているとしてよい。このような実施形態、例および代替例は、互いの事実上の均等物と解釈されるべきではなく、別個且つ独立した本発明の形態として解釈されるべきと理解されたい。

さらに、記載した特徴、構造または特性は、一または複数の実施形態において、任意の適切な方法で組み合わせるとしてよい。以下の説明では、本発明の実施形態を徹底的に理解できるよう、レイアウトの例、距離、ネットワークの例等など、具体的且つ詳細な内容を数多く記載する。しかし、当業者であれば、本発明はそのような具体的且つ詳細な記載事項のうち一または複数を採用することなく、他の方法、コンポーネント、レイアウト等で実施し得ることを認めるであろう。また、公知の構造、材料または処理は、本発明の態様をあいまいにしないよう、詳細な説明または図示を省略している。

上述した例は本発明の原理を一または複数の特定の適用例で例示するものであるが、発明力を発揮することなく、そして、本発明の原理および概念から逸脱することなく、実装の形態、利用方法および詳細な内容を数多くの点で変形し得ることは当業者には明らかであろう。したがって、以下に記載する請求項以外で本発明が限定されることを意図したものではない。

Claims (21)

1. アダプティブメディアストリーミングを実行し、コンピュータ回路を備えるユーザ機器（ＵＥ）であって、前記コンピュータ回路は、
   前記ＵＥの予定ルートを選択し、
   チャネル情報データベース（ＣＩＤ）を有するサーバから、前記予定ルートについての無線チャネル情報を受信し、
   前記無線チャネル情報に基づき、複数の無線ネットワークチャネル状況が定められたしきい値未満である前記予定ルート上の複数の場所を決定し、
   前記予定ルート上の決定された前記複数の場所に進入する前に前記ＵＥにおけるバッファに格納するべくアダプティブメディアストリームの複数の追加セグメントをメディアサーバに対して要求することで、前記予定ルートにおいて前記メディアストリームの連続的なメディア再生を可能とし、
   前記予定ルート上の前記決定された複数の場所を退出した後、旧式のビットレート適応化バッファリングメカニズムに戻る
   ＵＥ。
2. 前記コンピュータ回路はさらに、
   前記予定ルート上の前記決定された複数の場所に前記ＵＥが進入すると前記バッファに格納されている前記アダプティブメディアストリームの前記複数の追加セグメントを再生する
   請求項１に記載のＵＥ。
3. 前記コンピュータ回路はさらに、
   前記ＵＥの前記予定ルート上の前記決定された複数の場所に進入する前に前記ＵＥに提供される追加セグメントの数に応じて、前記ＵＥにおける前記バッファの容量を調整する
   請求項１または２に記載のＵＥ。
4. 前記コンピュータ回路はさらに、
   前記ＵＥの前記予定ルート上の複数の信号ノイズ比（ＳＮＲ）予想値に基づき、前記複数の無線ネットワークチャネル状況が前記定められたしきい値未満になる前記予定ルート上の前記複数の場所を決定する
   請求項１から３のいずれか一項に記載のＵＥ。
5. 前記コンピュータ回路はさらに、
   前記ＵＥの前記予定ルートにおける複数のフレームドロップレート予想値に基づき、前記複数の無線ネットワークチャネル状況が前記定められたしきい値未満になる前記予定ルート上の前記複数の場所を決定する
   請求項１から４のいずれか一項に記載のＵＥ。
6. 前記予定ルートのための前記無線チャネル情報は、複数の過去の無線ネットワークチャネル状況、複数の現在の無線ネットワークチャネル状況、または、複数のクラウドソーシングされた無線ネットワーク状況のうち少なくとも１つに基づいて決まる
   請求項１から５のいずれか一項に記載のＵＥ。
7. 前記無線チャネル情報は、前記予定ルートの前記複数の無線ネットワークチャネル状況の複数の変化に応じて、前記予定ルートについて周期的に更新される
   請求項１から６のいずれか一項に記載のＵＥ。
8. 前記ＵＥは、アンテナ、タッチセンシティブディスプレイスクリーン、スピーカ、マイクロフォン、グラフィクスプロセッサ、アプリケーションプロセッサ、内部メモリまたは不揮発性メモリポートを備える
   請求項１から７のいずれか一項に記載のＵＥ。
9. ハイパーテキストトランスファープロトコルでの動的アダプティブストリーミング（ＤＡＳＨ）を実行するための方法であって、
   モバイルデバイスの予定ルートを選択することと、
   チャネル情報データベース（ＣＩＤ）を有するサーバから、前記予定ルートについて無線チャネル情報を受信することと、
   前記無線チャネル情報に基づき、複数の無線ネットワークチャネル状況が定められたしきい値未満になる前記予定ルート上の複数の地理的な場所を決定することと、
   前記予定ルート上の決定された前記複数の地理的な場所に進入する前にメディアファイルの複数の追加セグメントをメディアサーバに要求することと、
   前記予定ルート上の前記決定された複数の地理的な場所を退出した後、旧式のＤＡＳＨレート適応化バッファリングメカニズムを復活させることと
   を備える方法。
10. 前記モバイルデバイスにおけるバッファに格納するべく前記メディアファイルの前記複数の追加セグメントを受信することをさらに備える
    請求項９に記載の方法。
11. 前記複数の無線ネットワークチャネル状況が前記定められたしきい値未満になる前記予定ルート上の前記複数の地理的な場所を通過する間の前記メディアファイルの連続的なメディア再生を可能とするべく、前記メディアファイルの前記複数の追加セグメントを受信することをさらに備える
    請求項９または１０に記載の方法。
12. 前記予定ルート上の前記決定された複数の地理的な場所に進入する前に前記モバイルデバイスに提供される前記メディアファイルの追加セグメントの数に応じて、前記モバイルデバイスのバッファ容量を調整することをさらに備える
    請求項９から１１のいずれか一項に記載の方法。
13. 前記モバイルデバイスの前記予定ルート上の複数の信号ノイズ比（ＳＮＲ）予想値に基づき、前記予定ルート上の前記複数の地理的な場所における前記複数の無線ネットワークチャネル状況が前記定められたしきい値未満であると判断することをさらに備える
    請求項９から１２のいずれか一項に記載の方法。
14. 前記モバイルデバイスの前記予定ルート上の複数のフレームドロップレート予想値に基づき、前記予定ルート上の前記複数の地理的な場所における前記複数の無線ネットワークチャネル状況が前記定められたしきい値未満であると判断することをさらに備える
    請求項９から１３のいずれか一項に記載の方法。
15. 前記サーバを介して前記ＣＩＤから、前記予定ルートの複数の無線ネットワークチャネル状況の過去のデータに基づく前記無線チャネル情報を受信することをさらに備える
    請求項９から１４のいずれか一項に記載の方法。
16. 前記サーバを介して前記ＣＩＤから、前記予定ルートの複数の現在の無線ネットワークチャネル状況に基づく前記無線チャネル情報を受信することをさらに備える
    請求項９から１５のいずれか一項に記載の方法。
17. ハイパーテキストトランスファープロトコルでの動的アダプティブストリーミング（ＤＡＳＨ）を実行し、コンピュータ回路を備えるユーザ機器（ＵＥ）であって、前記コンピュータ回路は、
    前記ＵＥの予定ルートの無線チャネル情報を受信し、
    前記無線チャネル情報に基づき、複数の無線ネットワークチャネル状況が定められたしきい値未満である前記予定ルート上の複数の場所を決定し、
    前記予定ルート上の決定された前記複数の場所に進入する前に前記ＵＥにおけるキャッシュに格納するべくアダプティブメディアストリームの複数の追加セグメントをメディアサーバに対して要求することで、前記予定ルートにおいて前記メディアストリームの連続的なメディア再生を可能とし、
    前記ＵＥは、前記予定ルート上の前記決定された複数の場所から退出した後で旧式のＤＡＳＨレート適応化バッファリングメカニズムに戻る
    ＵＥ。
18. 前記コンピュータ回路はさらに、
    前記予定ルート上の前記決定された複数の場所に前記ＵＥが進入すると、前記キャッシュに格納されている前記アダプティブメディアストリームの前記複数の追加セグメントを再生する
    請求項１７に記載のＵＥ。
19. 前記コンピュータ回路はさらに、
    前記ＵＥの前記予定ルート上の前記決定された複数の場所に進入する前に前記ＵＥに提供される追加セグメントの数に応じて、前記ＵＥにおける前記キャッシュの容量を調整する
    請求項１７または１８に記載のＵＥ。
20. 前記コンピュータ回路はさらに、
    前記ＵＥの前記予定ルート上の複数の信号ノイズ比（ＳＮＲ）予想値または複数のフレームドロップレート予想値に基づき、前記複数の無線ネットワークチャネル状況が前記定められたしきい値未満になる前記予定ルート上の前記複数の場所を決定する
    請求項１７から１９のいずれか一項に記載のＵＥ。
21. 前記コンピュータ回路はさらに、
    チャネル情報データベース（ＣＩＤ）を含むサーバから、前記予定ルートについて前記無線チャネル情報を受信し、前記無線チャネル情報は、前記予定ルートの複数の無線ネットワークチャネル状況の過去のデータ、または、前記予定ルートについての複数の現在の無線ネットワークチャネル状況に基づいて決まる
    請求項１７から２０のいずれか一項に記載のＵＥ。

Images