JP2017538987A - トランスポートアクセラレータによるユーザエージェントシグナリング要求加速のためのシステムおよび方法 - Google Patents

Abstract

ユーザエージェント(UA)シグナリングの使用を通じてトランスポートアクセラレータ動作を実現するように適合されるシステムおよび方法が開示される。実施形態による動作では、トランスポートアクセラレータ(TA)が、コンテンツ要求を解析して、トランスポート加速機能が提供されるべきであるという指示をコンテンツ要求が含むかどうかを判定する。そのような指示が存在する場合、TAは、コンテンツ要求をさらに解析して、トランスポート加速機能が提供されるかどうかを判定する。

Description

関連出願の相互参照
本願は、2014年9月30日に出願された「SYSTEMS AND METHODS FOR USER AGENT SIGNALING REQUEST ACCELERATION BY TRANSPORT ACCELERATOR」という名称の同時係属の米国仮特許出願第62/057412号、および2015年2月6日に出願された「SYSTEMS AND METHODS FOR USER AGENT SIGNALING REQUEST ACCELERATION BY TRANSPORT ACCELERATOR」という名称の米国実用特許出願第14/616233号の優先権を主張し、これらは、参照によりその全体が本明細書に明白に組み込まれる。

ますます多くのコンテンツが、利用可能な通信ネットワークを介して転送されている。多くの場合、このコンテンツは、たとえば、オーディオデータ、ビデオデータ、イメージデータなどを含む多数のタイプデータを含む。ビデオコンテンツ、特に高解像度ビデオコンテンツは多くの場合、比較的大きいデータファイルまたは他のデータの集合を含む。したがって、そのようなコンテンツを消費するエンドユーザデバイスまたは他のクライアントデバイス上のユーザエージェント(UA)は多くの場合、所望のビデオコンテンツを含むコンテンツのフラグメントのシーケンスを要求し、受信する。たとえば、UAは、データ、多くの場合はマルチメディアデータを要求し、さらなる処理のため、および場合によってはユーザデバイス上に表示するために、要求したデータを受信する、ユーザデバイス上で実行中のクライアントアプリケーションまたはプロセスを含み得る。

今日の多くのタイプのアプリケーションは、上記のコンテンツ配信のためにHTTPに依拠する。多くのそのようなアプリケーションでは、HTTPトランスポートの性能は、アプリケーションに伴うユーザの体験にとって肝要である。たとえば、ライブストリーミングは、ビデオストリーミングクライアントの性能を妨げ得るいくつかの制約を有する。2つの制約が特に際立っている。第1に、メディアセグメントが経時的に次々と利用可能になる。この制約は、クライアントがデータの大部分を継続的にダウンロードすることを妨げ、そのことは、ダウンロードレート推定の精度に影響を及ぼす。ほとんどのストリーミングクライアントは「要求-ダウンロード-推定」ループ上で動作するので、ダウンロード推定が不正確であるとき、コンテンツダウンロードは一般にうまくいかない。第2に、ライブイベントストリーミングを閲覧するとき、ユーザは一般に、実際のライブイベントタイムラインからの長い遅延を受けることを望まない。そのような挙動は、ストリーミングクライアントが大きいバッファを構築することを妨げ、そのことは、より多くの再バッファリングを引き起こし得る。

ストリーミングクライアントが(たとえば、ほとんどのDynamic Adaptive Streaming over HTTP (DASH)クライアントと同様に)伝送制御プロトコル(TCP)を介して動作する場合、上記の厳しいライブイベントタイムラインは、欠落パケットまたはリオーダーされたパケットがあるときにスローダウンすべきである典型的なTCP挙動と相反する。組込みTCP輻輳制御機構は、ライブストリーミング中の再バッファリング効果を悪化させ、一方、ライブイベントの閲覧者は、再バッファリングをスキップし、最新のイベントタイムラインにジャンプしようとする可能性がより高い。

同じ問題がHTTPベースのファイルダウンロードについても存在し、その場合、ダウンロードの完了のための期限があり、さもなければペナルティを受けることになる。たとえば、ユーザがウェブページ、ピクチャにアクセスすること、またはウェブベースのアプリケーションを使用することを試みている場合、大きいダウンロード待ち時間の結果、ユーザは、ウェブページまたはウェブベースのアプリケーションから立ち去り得る。

オンデマンドストリーミングも同様の制約を受ける。たとえば、オンデマンドストリーミングでは、クライアントデバイスは、ユーザに再生を提供するために、正しい順序で可能な限り早くオンデマンドストリームを受信することを望む。ストリーミングオンデマンドコンテンツの性能は、欠落パケットまたはリオーダーされたパケット、再バッファリングなどによって影響を受ける。

トランスポートアクセラレータの実装を使用してコンテンツの配信に関する加速を実現するために、様々な技法が開発された。そのようなトランスポートアクセラレータ実装は、たとえば、クライアントデバイスへのデータの優先配信を容易にしようとして、データのキャッシング、データ要求および/またはデータ要求に対する応答の処理などを実現するように動作し得る。いくつかの状況、さらには多くの状況でクライアントデバイスへのデータの優先配信を実現するものの、多くのトランスポートアクセラレータ実装は、いくつかの状況では望ましくない動作となる。たとえば、トランスポートアクセラレータの動作の結果、ネットワーク輻輳の増大、通信プロトコルまたはその部分の非互換性が生じ得る。

トランスポートアクセラレータは、たとえば、いくつかのアプリケーションに関するトランスポート加速動作を容易にするためにシステムフレームワーク(たとえば、ANDROID（登録商標）モバイルデバイスオペレーティングシステムで提供されるSTAGEFRIGHTメディアプレーヤアーキテクチャ)内で実装され得る。たとえば、オペレーティングシステム(OS)はシステムフレームワークを提供し得、それによって、HTTPレイヤトランザクション、ネットワークレイヤトランザクション、メディア再生エンジンなどのいくつかの下位レベル機能が、アプリケーションプログラミングインターフェース(API)の使用などによって、アプリケーションによる使用のために提供される。OS上で動作する潜在的に多数のアプリケーションに対して共通に利用可能であるそのようなフレームワークはまた、トランスポートアクセラレータの要求およびデータ配信加速などの機能を、フレームワークサービスを利用するアプリケーションにとって同様に利用可能にするために活用され得る。

しかしながら、いくつかのアプリケーションは、そのようなシステムフレームワークの機能を使用しないことがある。たとえば、いくつかのアプリケーションは、HTTPレイヤトランザクション、ネットワークトランザクション、メディア再生などの、アプリケーション自体の下位レベル機能を、アプリケーションの動作に対してそれらの機能を最適化するために実装し得る。たとえば、比較的高いネットワークインパクトアプリケーション(たとえば、NETFLIXおよびYOUTUBE（登録商標）クライアント)は、システムが提供するフレームワーク(たとえば、STAGEFRIGHT)の使用を控え、その代わりにアプリケーション自体の下位レベル機能を実装し得る。したがって、より複雑なアプリケーションソフトウェア構成を必要とするが、それでも、そのようなアプリケーションは、特定のアプリケーションによる使用のために特に適合された下位レベル機能の使用を通じて、改善された性能、さらにはより予測可能な性能から恩恵を受け得る。

本明細書の実施形態によれば、トランスポート加速要求通信のための方法が提供される。方法は、トランスポートアクセラレータ(TA)によって、第1のユーザエージェント(UA)からTAの第1の要求加速ポートを介してコンテンツ要求を受信することを含み、コンテンツ要求は、コンテンツサーバによってUAに配信されるべきコンテンツデータを求める要求を含む。方法は、コンテンツ要求を解析して、コンテンツ要求に対してトランスポート加速機能が提供されるべきであることを示すシグナリングをコンテンツ要求が含むかどうかを判定すること、およびトランスポート加速機能が提供されるべきであることを示すシグナリングをコンテンツ要求が含むという判定に少なくとも部分的に基づいて、コンテンツ要求に対してトランスポート加速動作を実施することをさらに含み、トランスポート加速動作は、コンテンツを求める複数の要求にコンテンツ要求を細分すること、およびTAによってコンテンツサーバにコンテンツを要求することを制御して、要求されたコンテンツデータの、TAに対する加速配信を実現することを含む。

本明細書の別の実施形態によれば、トランスポート加速要求通信のための装置が提供される。装置は、第1のユーザエージェント(UA)からTAの第1の要求加速ポートを介してコンテンツ要求を受信するトランスポートアクセラレータ(TA)のための手段を含み、コンテンツ要求は、コンテンツサーバによってUAに配信されるべきコンテンツデータを求める要求を備える。装置は、コンテンツ要求を解析して、コンテンツ要求に対してトランスポート加速機能が提供されるべきであることを示すシグナリングをコンテンツ要求が含むかどうかを判定するための手段と、トランスポート加速機能が提供されるべきであることを示すシグナリングをコンテンツ要求が含むという判定に少なくとも部分的に基づいて、コンテンツ要求に対してトランスポート加速動作を実施するための手段とをさらに含み、トランスポート加速動作は、コンテンツを求める複数の要求にコンテンツ要求を細分すること、およびTAによってコンテンツサーバにコンテンツを要求することを制御して、要求されたコンテンツデータの、TAに対する加速配信を実現することを含む。

本明細書のさらに別の実施形態によれば、トランスポート加速要求通信のためのコンピュータ実行可能コードを記憶するコンピュータ可読媒体が提供され、コンピュータ可読媒体は、プログラムコードが記録された有形コンピュータ可読媒体を含む。プログラムコードは、トランスポートアクセラレータ(TA)によって、第1のユーザエージェント(UA)からTAの第1の要求加速ポートを介してコンテンツ要求を受信するためのプログラムコードを含み、コンテンツ要求は、コンテンツサーバによってUAに配信されるべきコンテンツデータを求める要求を含む。プログラムコードは、コンテンツ要求を解析して、コンテンツ要求に対してトランスポート加速機能が提供されるべきであることを示すシグナリングをコンテンツ要求が含むかどうかを判定するためのプログラムコードと、トランスポート加速機能が提供されるべきであることを示すシグナリングをコンテンツ要求が含むという判定に少なくとも部分的に基づいて、コンテンツ要求に対してトランスポート加速動作を実施するためのプログラムコードとをさらに含み、トランスポート加速動作は、コンテンツを求める複数の要求にコンテンツ要求を細分すること、およびTAによってコンテンツサーバにコンテンツを要求することを制御して、要求されたコンテンツデータの、TAに対する加速配信を実現することを含む。

本明細書の別の実施形態によれば、トランスポート加速要求通信のための装置が提供される。装置は、少なくとも1つのプロセッサと、前記少なくとも1つのプロセッサに結合されたメモリとを備える。少なくとも1つのプロセッサは、トランスポートアクセラレータ(TA)によって、第1のユーザエージェント(UA)からTAの第1の要求加速ポートを介してコンテンツ要求を受信するように構成され、コンテンツ要求は、コンテンツサーバによってUAに配信されるべきコンテンツデータを求める要求を含む。少なくとも1つのプロセッサは、コンテンツ要求を解析して、コンテンツ要求に対してトランスポート加速機能が提供されるべきであることを示すシグナリングをコンテンツ要求が含むかどうかを判定し、トランスポート加速機能が提供されるべきであることを示すシグナリングをコンテンツ要求が含むという判定に少なくとも部分的に基づいて、コンテンツ要求に対してトランスポート加速動作を実施するようにさらに構成され、トランスポート加速動作は、コンテンツを求める複数の要求にコンテンツ要求を細分すること、およびTAによってコンテンツサーバにコンテンツを要求することを制御して、要求されたコンテンツデータの、TAに対する加速配信を実現することを含む。

本開示の実施形態による、トランスポートアクセラレータ動作のために適合されたシステムを示す図である。 本開示の実施形態による、トランスポートアクセラレータ動作を提供するためのトランスポートアクセラレータ制御論理の動作を示す高レベルフローチャートである。 本開示の実施形態による、トランスポートアクセラレータ論理の機能を選択的に起動するための動作を示す高レベルフローチャートである。

「例示的」という語は、本明細書では「一例、事例、または例示として働くこと」を意味するために使用される。「例示的」なものとして本明細書で説明されるどんな態様も、必ずしも他の態様よりも好ましい、または有利であると解釈されるべきではない。

この説明では、「アプリケーション」という用語は、オブジェクトコード、スクリプト、バイトコード、マークアップ言語ファイル、パッチなどの実行可能コンテンツを有するファイルをも含み得る。さらに、本明細書で参照される「アプリケーション」はまた、開く必要のあり得る文書、アクセスする必要のある他のデータファイルなどの、実行可能な性質ではないファイルをも含み得る。

この説明では、「コンテンツ」という用語は、1つまたは複数の品質レベルのビデオ、オーディオ、ビデオとオーディオの組合せ、または他のデータを有するデータを含み得、品質レベルは、ビットレート、解像度、または他の要素によって決定される。コンテンツはまた、オブジェクトコード、スクリプト、バイトコード、マークアップ言語ファイル、パッチなどの実行可能コンテンツをも含み得る。さらに、「コンテンツ」はまた、開く必要のあり得る文書、アクセスする必要のある他のデータファイルなどの、実行可能な性質ではないファイルをも含み得る。

この説明では、「フラグメント」という用語は、ユーザデバイスによって要求され、かつ/またはユーザデバイスで受信され得るコンテンツの1つまたは複数の部分を指す。

この説明では、「ストリーミングコンテンツ」という用語は、コンテンツのリアルタイム転送、または期間にわたるコンテンツの転送を可能にする1つまたは複数の規格に従ってサーバデバイスから送られ、ユーザデバイスで受信され得るコンテンツを指す。ストリーミングコンテンツ規格の例には、デインターリーブされた(または複数の)チャネルをサポートするもの、およびデインターリーブされた(または複数の)チャネルをサポートしないものが含まれる。

この説明では、「構成要素」、「データベース」、「モジュール」、「システム」などの用語は、ハードウェア、ファームウェア、ハードウェアとソフトウェアの組合せ、ソフトウェア、または実行中のソフトウェアのいずれかの、コンピュータ関連エンティティを指すものとする。たとえば、構成要素は、限定はしないが、プロセッサ上で実行中のプロセス、プロセッサ、オブジェクト、実行可能ファイル、実行スレッド、プログラム、および/またはコンピュータであり得る。例として、コンピューティングデバイス上で実行中のアプリケーションとコンピューティングデバイスの両方が構成要素であり得る。1つまたは複数の構成要素は、プロセスおよび/または実行スレッド内に常駐し得、構成要素は、1つのコンピュータ上に局在化され、かつ/または2つ以上のコンピュータ間に分散し得る。さらに、これらの構成要素は、様々なデータ構造が記憶された様々なコンピュータ可読媒体から実行され得る。構成要素は、1つまたは複数のデータパケット(たとえば、ローカルシステム、分散システム内の別の構成要素、および/またはインターネットなどのネットワークを介して、信号によって他のシステムと対話するある構成要素からのデータ)を有する信号などに従って、ローカルおよび/またはリモートプロセスによって通信し得る。

本明細書では、「ユーザ機器」、「ユーザデバイス」、および「クライアントデバイス」という用語は、ウェブサーバにコンテンツを要求し、ウェブサーバからコンテンツを受信し、ウェブサーバに情報を送信することのできるデバイスを含む。そのようなデバイスは、静止デバイスまたはモバイルデバイスであり得る。「ユーザ機器」、「ユーザデバイス」、および「クライアントデバイス」という用語は、互換的に使用され得る。

本明細書では、「ユーザ」という用語は、ユーザデバイス上またはクライアントデバイス上のコンテンツを受信し、ウェブサイトに情報を送信する個人を指す。

図1は、オーディオデータ、ビデオデータ、イメージデータ、ファイルデータなどを含み得るようなコンテンツの、通信ネットワークを介する転送を実現するように本明細書の概念に従って適合されたシステム100の一実施形態を示す。したがって、ネットワーク150を介してサーバ130と通信しているクライアントデバイス110が示されており、それによって、サーバ130は、本開示の概念に従って、データベース140内に記憶された様々なコンテンツをクライアントデバイス110に転送し得る。単一のクライアントデバイスと、単一のサーバおよびデータベースとが図1に表されているが、システム100は、複数の任意またはすべてのそのようなデバイスを備え得ることを理解されたい。たとえば、サーバ130はサーバファームのサーバを備え得、複数のサーバは、コンテンツ転送を求める高レベルの要求にサービスするために、中央に、かつ/または分散構成で配設され得る。あるいは、コンテンツの一部またはすべてが、トランスポートアクセラレータ(TA)120と同一のデバイス(たとえば、ネットワーク150を通じてではなく、I/O要素113を通じて直接的にTA120に接続されたデバイス)上にともに配置され、サーバ130を通じてTA120に提供されるデータベース140(キャッシュ)内に常駐するときなどに、サーバ130は、そのデバイス上にともに配置され得る。同様に、ユーザが複数のクライアントデバイスを所有し得、かつ/または複数のユーザがそれぞれ1つまたは複数のクライアントデバイスを所有し得、そのいずれかまたはすべてが、本明細書の概念に従ってコンテンツ転送のために適合される。

クライアントデバイス110は、ネットワーク150を介してコンテンツの転送を受信するように動作可能なデバイスの様々な構成を含み得る。たとえば、クライアントデバイス110は、ワイヤードデバイス、ワイヤレスデバイス、パーソナルコンピューティングデバイス、タブレットまたはパッドコンピューティングデバイス、ポータブルセルラー電話、WiFi対応デバイス、Bluetooth（登録商標）対応デバイス、テレビジョン、ディスプレイを有する眼鏡、拡張現実眼鏡、または任意の利用可能な方法またはインフラストラクチャを使用してサーバ130と通信し得る、ネットワーク150に接続された任意の他の通信、コンピューティング、もしくはインターフェースデバイスを含み得る。クライアントデバイス110は、サーバ130のクライアントとして機能するデバイスとして機能し得、またはそのデバイスに接続され得るので、クライアントデバイス110は「クライアントデバイス」と呼ばれる。

図示される実施形態のクライアントデバイス110は、ここではプロセッサ111、メモリ112、および入力/出力(I/O)要素113を含むものとして示される、複数の機能ブロックを備える。簡単のために図1の表現には図示されていないが、クライアントデバイス110は、ユーザインターフェース、無線周波数(RF)モジュール、カメラ、センサアレイ、ディスプレイ、ビデオプレーヤ、ブラウザなどの追加の機能ブロックを備え得、そのうちの一部またはすべてが、本明細書の概念による動作によって利用され得る。上記の機能ブロックは、バス114などの1つまたは複数のバスを介して動作可能に接続され得る。バス114は、接続された要素、モジュール、および構成要素が通信し、相互動作することを可能にするための論理接続および物理接続を備え得る。

実施形態のメモリ112は、任意のタイプの揮発性または不揮発性メモリであり得、一実施形態ではフラッシュメモリを含み得る。メモリ112は、クライアントデバイス110内に永続的に設置され得、または取外し可能メモリカードなどの取外し可能メモリ要素であり得る。単一の要素として示されているが、メモリ112は、複数の別個のメモリおよび/またはメモリタイプを備え得る。

メモリ112は、アプリケーション、オペレーティングシステム、ファイル、電子的文書、コンテンツなどを形成し得るような、様々なコンピュータ可読コードセグメントを記憶し、あるいは含み得る。たとえば、図示される実施形態のメモリ112は、TA120、トランスポートアクセラレータ(TA)制御125、ならびにUA129aおよび129bを定義するコンピュータ可読コードセグメントを備え、それらは、プロセッサ(たとえば、プロセッサ111)によって実行されるとき、本明細書で説明するように動作可能な論理回路を提供する。メモリ112によって記憶されるコードセグメントは、前述のTA120、TA制御125、ならびにUA129aおよび129bに加えて、アプリケーションを提供する。たとえば、メモリ112は、本明細書の実施形態に従ってサーバ130からのコンテンツにアクセスする際に有用な、ブラウザなどのアプリケーションを記憶し得る。そのようなブラウザは、サーバ130がウェブサーバである場合、ウェブコンテンツにアクセスし、ウェブコンテンツを閲覧するため、およびネットワーク150を介して、接続151および152を介して、サーバ130とHTTPを介して通信するための、ハイパーテキスト転送プロトコル(HTTP)ウェブブラウザなどのウェブブラウザであり得る。一例として、HTTP要求は、クライアントデバイス110内のブラウザから、ネットワーク150を介して、接続151および152を介して、サーバ130に送られ得る。HTTP応答は、サーバ130から、接続152および151を介して、ネットワーク150を介して、クライアントデバイス110内のブラウザに送られ得る。

UA129aおよび129bは、サーバ130などのサーバにコンテンツを要求し、サーバからコンテンツを受信するように動作可能である。UA129aと129bのどちらかまたは両方は、たとえば、マルチメディアデータなどのデータを要求し、さらなる処理のために、場合によってはクライアントデバイス110のディスプレイ上に表示するために、要求したデータを受信する、ブラウザ、DASHクライアント、HTTPライブストリーミング(HLS)クライアントなどのクライアントアプリケーションまたはプロセスを含み得る。たとえば、クライアントデバイス110は、スタンドアロンメディア再生アプリケーション、またはインターネットブラウザ内で実行するように構成されたブラウザベースのメディアプレーヤなどの、メディアを再生するためのUA129aまたは129bのどちらかを含むコードを実行し得る。実施形態による動作では、UA129aおよび129bは、ストリーミングコンテンツセッション中の様々な時点において、転送のためにどのコンテンツファイルのフラグメントまたはフラグメントのシーケンスを要求するかを決定する。たとえば、UAのDASHクライアント構成は、最近のダウンロード条件などに基づいて、各時点でコンテンツのどの表現(たとえば、高解像度表現、中解像度表現、低解像度表現など)にどのフラグメントを要求するかを決定するように動作し得る。同様に、UAのウェブブラウザ構成は、ウェブページ、またはその部分などを求める要求を行うように動作し得る。通常、UAは、HTTP要求を使用してそのようなフラグメントを要求する。

UAの2つの例が図1に示されるクライアントデバイス110の実施形態に関して示されるが、システム100のクライアントデバイスは任意の数のUAを備え得ることを理解されたい。たとえば、特定のクライアントデバイス構成は単一のUAを備え得るのに対して、別のクライアントデバイス構成は、複数の(すなわち、2つ以上)UAを備え得る。

TA120は、所望のコンテンツのフラグメントまたはフラグメントのシーケンス(たとえば、ビデオストリーミング、ファイルダウンロード、ウェブベースのアプリケーション、一般のウェブページなどを提供する際に使用され得る前述のコンテンツフラグメント)の拡張配信を提供するように、シーケンスの本明細書の概念に従って適合される。たとえば、TA120は、クライアントデバイス110へのコンテンツの加速配信を実現する目的で、コンテンツのチャンクをサーバ130に制御可能に要求するために、UA129aおよび129bによって行われたコンテンツを求める要求を複数のチャンク要求に細分するように動作し得る。実施形態のTA120は、標準化されたTCP伝送プロトコルを実装するHTTP1.1インターフェースなどの標準インターフェースのみをサポートする汎用またはレガシーUA(すなわち、TAと対話するようにあらかじめ設計されていないUA)が、フラグメント要求を行うために、それでもそれらの要求を実行するTAを使用することから恩恵を受けることを可能にするように適合される。追加または代替として、実施形態のTA120は、拡張インターフェースの機能の利点を利用するように設計されるUAに別の恩恵を与えることを容易にするために拡張インターフェースを提供する。実施形態のTA120は、標準化されたTCP伝送プロトコルを実装するHTTPインターフェースを介してTCPを使用することなど、既存のコンテンツ転送プロトコルに従ってフラグメント要求を実行するように適合され、それによって、汎用またはレガシーコンテンツサーバ(すなわち、TAと対話するようにあらかじめ設計されていないコンテンツサーバ)が、UAおよびクライアントデバイスにフラグメントの拡張配信を提供しながら、要求にサービスすることを可能にする。

上記の拡張フラグメント配信機能を提供する際に、本明細書の実施形態のTA120は、本明細書で説明されるアーキテクチャ上の構成要素およびプロトコルを備える。たとえば、図1に示される実施形態のTA120は、様々な拡張フラグメント配信機能を提供するように協働する、要求マネージャ(RM)121および1つまたは複数の接続マネージャ(CM)122を備える。RM121は、UA129aおよび129bからフラグメント要求を受信し、フラグメント要求に応答し、要求されたフラグメントを細分し、複数の対応するより小さいデータ要求(本明細書では「チャンク要求」と呼ばれ、要求されたデータは「チャンク」を含む)を提供し、チャンク要求をCM122に向けて送るように動作し得る。したがって、CM122は、RM121とインターフェースして、チャンク要求を受信し、ネットワーク150を介してそれらのチャンク要求に対応する要求(たとえば、HTTP要求)を送り、そのチャンク要求に対する応答を受信し、応答をRM121に渡し得、UAによって要求されるフラグメントは、受信されたチャンクからRM121によって解決され、要求側UAに提供される。実施形態のCM122の機能は、RM121によって行われたチャンク要求のデータをいつ要求するかを決定するように動作する。

図示される実施形態のクライアントデバイス110が、1つまたは複数の通信セッションについての同時マルチポート通信サポート、通信セッションに関する通信ポート回復などを提供するために利用されるような、複数のインターフェースアーキテクチャを実装するように示されていることを理解されたい。具体的には、TA120は、CM122a〜122dを含むものとして示されている。それに対応して、I/O要素113は、インターフェース161a〜161dとして示される、データ通信を容易にするように動作可能な複数のインターフェースを含むものとして示されている。同様に、RM121は、複数の異なるCM構成とともに動作し、かつ/またはCM122a〜122dのうちの2つ以上のCMに同一のフラグメントまたはフラグメントのシーケンスのデータチャンクを要求するなどのために、複数のCMと同時にインターフェースするように適合され得る。そのような各CMは、たとえば、異なるネットワークインターフェースをサポートし得る(たとえば、第1のCMが、デバイス上キャッシュに対するローカルインターフェースを有し得、第2のCMが、3Gネットワークインターフェースに対するHTTP/TCP接続を使用し得、第3のCMが、4G/LTEネットワークインターフェースに対するHTTP/TCP接続を使用し得、第4のCMが、WiFiネットワークインターフェースに対するHTTP/TCP接続を仕様し得、以下同様である)。それに対応して、I/O要素113のインターフェースは、いくつかの通信プロトコルに従って動作可能な様々な構成を備え得る。たとえば、インターフェース161a〜161dは、それぞれ3Gネットワーク、4G/LTEネットワーク、異なる4G/LTEネットワーク、およびWiFi通信に対するインターフェースを提供し得、TA120は、たとえば、HTTP/TCP、HTTP/xTCP、ユーザデータグラムプロトコル(UDP)を使用して構築されたプロトコルなどのトランスポートプロトコルを使用して、これらのインターフェースを介してデータを転送する。そのような各インターフェースは、I/O要素113のインターフェースをネットワーク150の構成要素とリンクする、図示される接続151a〜151dなどの関連する通信リンクなどを介して、通信セッションを実装するために1つまたは複数の通信ポートを提供するように動作可能であり得る。

本明細書の実施形態に従って利用されるインターフェースの数および構成は、図示されるものに限定されないことを理解されたい。たとえば、より少ない、または多くのインターフェースが、トランスポートアクセラレータの実施形態に従って利用され得る。さらに、1つまたは複数のそのようなインターフェースは、図示されるネットワークリンク(たとえば、接続151〜152)以外を介するデータ通信、および/またはネットワーク構成要素(たとえば、サーバ130)以外のデバイスとのデータ通信を提供し得る。

前述のコードセグメント形成アプリケーション、オペレーティングシステム、ファイル、電子的文書、コンテンツなどに加えて、メモリ112は、クライアントデバイス110の機能ブロックによって使用される様々なレジスタ、バッファ、および記憶セルを含み、あるいは提供し得る。たとえば、メモリ112は、サーバ130からのストリーミングおよびクライアントデバイス110による再生のために、フラグメントのデータをスプールするための先入れ先出し(FIFO)メモリを提供し得るようなプレイアウトバッファを備え得る。

実施形態のプロセッサ111は、クライアントデバイス110の動作および機能を制御するための命令を実行することのできる任意の汎用または専用プロセッサであり得る。単一の要素として示されているが、プロセッサ111は、複数のプロセッサ、または分散処理アーキテクチャを備え得る。

I/O要素113は、様々な入力/出力構成要素を含み、かつ/またはそれに結合され得る。たとえば、I/O要素113は、ディスプレイ、スピーカ、マイクロフォン、キーパッド、ポインティングデバイス、タッチ検知画面、ユーザインターフェース制御要素、およびユーザが入力コマンドを与え、クライアントデバイス110から出力を受け取ることを可能にする任意の他のデバイスまたはシステムを含み得、かつ/またはそれに結合され得る。任意の、またはすべてのそのような構成要素は、クライアントデバイス110のユーザインターフェースを提供するために利用され得る。追加または代替として、I/O要素113は、ディスクコントローラ、ネットワークインターフェースカード(NIC)、無線周波数(RF)トランシーバ、およびクライアントデバイス110の入力および/または出力機能を容易にする任意の他のデバイスまたはシステムを含み得、かつ/またはそれに結合され得る。

ストリーミングコンテンツにアクセスし、ストリーミングコンテンツを再生する動作では、クライアントデバイス110は、接続151および152を使用して、ネットワーク150を介してサーバ130と通信し、コンテンツデータを(たとえば、前述のフラグメントとして)取得し得、コンテンツデータは、レンダンリングされるとき、コンテンツの再生を実現する。したがって、UA129aと129bのどちらかまたは両方は、クライアントデバイス110内のコンテンツ再生環境を確立するために、プロセッサ111によって実行されるコンテンツプレーヤアプリケーションを備え得る。特定のコンテンツファイルの再生を開始するとき、UAは、サーバ130のコンテンツ配信プラットフォームと通信して、コンテンツ識別子(たとえば、所望のコンテンツの1つまたは複数のリスト、マニフェスト、構成ファイル、またはメディアセグメントもしくはフラグメントを特定する他の識別子、およびそのタイミング境界)を取得し得る。メディアセグメントおよびそのタイミングに関する情報は、実施形態のUAのストリーミングコンテンツ論理によって使用され、コンテンツの再生のためにフラグメントを要求することが制御される。

本明細書の実施形態に従って利用されるインターフェースの数および構成は、図1に示されるものに限定されないことを理解されたい。たとえば、より少ない、または多くのインターフェースが、トランスポートアクセラレータの実施形態に従って利用され得る。さらに、1つまたは複数のそのようなインターフェースは、図示されるネットワークリンク(たとえば、接続151a〜151d)以外を介するデータ通信、および/またはネットワーク構成要素(たとえば、サーバ130)以外のデバイスとのデータ通信を提供し得る。

サーバ130は、クライアントデバイスに所望のコンテンツをサービスするように動作可能な1つまたは複数のシステムを備える。たとえば、サーバ130は、ネットワーク150を介して様々なクライアントデバイスにコンテンツをストリーミングするように動作可能な標準HTTPウェブサーバを備え得る。サーバ130は、クライアントデバイス110にコンテンツを配信し得る任意のシステムまたは方法を含むコンテンツ配信プラットフォームを含み得る。コンテンツは、図示される実施形態のデータベース140などの、サーバ130と通信している1つまたは複数のデータベース内に記憶され得る。データベース140は、サーバ130上に記憶され得、サーバ130に通信可能に結合される1つまたは複数のサーバ上に記憶され得る。データベース140のコンテンツは、ビデオ、オーディオ、ストリーミングテキストなどの様々な形態のデータ、およびライブウェブキャストコンテンツや記憶されたメディアコンテンツなどの、サーバ130によって時間期間にわたってクライアントデバイス110に転送され得る任意の他のコンテンツを含み得る。

データベース140は、複数の異なるソースまたはコンテンツファイル、および/または任意の特定のコンテンツの複数の異なる表現(たとえば、高解像度表現、中解像度表現、低解像度表現など)を含み得る。たとえば、コンテンツファイル141は、特定のマルチメディアコンパイルの高解像度表現、すなわち転送されるときは高ビットレート表現を含み得、一方、コンテンツファイル142は、同一の特定のマルチメディアコンパイルの低解像度表現、すなわち転送されるときは低ビットレート表現を含み得る。追加または代替として、任意の特定のコンテンツの異なる表現は、コンテンツファイル143によって提供され得るような、前方誤り訂正(FEC)表現(たとえば、コンテンツデータの冗長符号化を含む表現)を含み得る。ユニフォームリソースロケータ(URL)、ユニフォームリソース識別子(URI)、および/またはユニフォームリソース名(URN)が、本明細書の実施形態に従ってこれらのコンテンツファイルのすべてに関連付けられ、したがってそのようなURL、URI、および/またはURNは、要求されたデータを識別し、それにアクセスするために、恐らくはバイト範囲などの他の情報とともに利用され得る。

ネットワーク150は、ワイヤレスネットワーク、ワイヤードネットワーク、広域ネットワーク(WAN)、ローカルエリアネットワーク(LAN)、または本明細書で説明されるコンテンツの転送に適した任意の他のネットワークであり得る。ネットワーク150は、たとえば、3Gネットワーク、4G/LTEネットワーク、WiFiネットワークなど、ならびにそれらの組合せを含み得る。さらに、単一のネットワーククラウドとして図示されるが、実施形態に従って利用されるネットワーク150は、クライアントデバイス110とサーバ130との間の通信を実現する、そのいずれかまたはすべてが同一の、または異なるネットワーク技術を含み得る、異なる、または別々のネットワークを含み得ることを理解されたい。一実施形態では、ネットワーク150は、インターネットの少なくとも部分を含み得る。クライアントデバイス110は、ネットワーク接続151によって表されるような2方向接続を介してネットワーク150に接続され得る。あるいは、クライアントデバイス110は、マルチメディアブロードキャストマルチメディアシステム(MBMS)対応ネットワークによって提供されるような1方向接続を介して接続され得る(たとえば、接続151、152、およびネットワーク150は、MBMSネットワークを含み得、サーバ130は、ブロードキャストマルチキャストサービスセンタ(BS-MC)サーバを含み得る)。接続はワイヤード接続であり得、またはワイヤレス接続であり得る。一実施形態では、接続151は、セルラー3G接続(たとえば、インターフェース161aによって提供される接続151a)、セルラー4G接続(たとえば、インターフェース161bおよび161cによってそれぞれ提供される接続151bおよび151c)、ワイヤレスフィデリティ(WiFi)接続(インターフェース161dによって提供される接続151dなど)、Bluetooth（登録商標）接続などのワイヤレス接続、または別のワイヤレス接続を含み得る。サーバ130は、接続152によって表されるような2方向接続を介してネットワーク150に接続され得る。サーバ130は、1方向接続(たとえば、3GPP TS.26.346またはATSC 3.0ネットワークにおいて記述されるプロトコルおよびサービスを使用するMBMSネットワーク)を介してネットワーク150に接続され得る。接続はワイヤード接続であり得、またはワイヤレス接続であり得る。

図1に示される実施形態のクライアントデバイス110は、UA129aと129bのどちらかまたは両方などのUAによって要求された所望のコンテンツのフラグメントまたはフラグメントのシーケンスの拡張配信を実現するように動作可能なTA120を備える。たとえば、上記で論じられたように、図示される実施形態のTA120は、クライアントデバイス110のUAへのデータの優先配信を容易にするように動作可能な様々な拡張フラグメント配信機能を提供するように協働するRMおよびCM機能を備える。しかしながら、伝統的に提供されるトランスポート加速機能は、UAのすべての構成にとって、またはすべての状況において利用可能ではないことがある。したがって、本明細書の実施形態は、様々なUAによるトランスポートアクセラレータ動作の要求を容易にするように適合される。たとえば、UAが、特定のコンテンツまたは特定のコンテンツ要求に関してトランスポート加速が望まれるTAにシグナリングを提供する場合、TAは、シグナリングを検出し、それに応答してトランスポート加速機能を提供し得る。しかしながら、すべてのコンテンツ要求がトランスポートアクセラレータ動作から恩恵を受けるわけではないことがあるので、それでも、実施形態は、様々なUAによるそのような要求に応答して、トランスポートアクセラレータ動作を選択的に実装する(たとえば、それによって、トランスポートアクセラレータ動作の1つまたは複数の機能が選択的に迂回され、または特定の基準に基づかない)。たとえば、特定のコンテンツまたは特定のコンテンツ要求に関してトランスポート加速が望まれることを要求するUAからのシグナリングを検出するが、TAは、シグナリングされた要求に応答してトランスポート加速機能の実装が実際に実装されるべきかどうかを判定するように動作し得る。

本明細書の概念を理解するのを助けるために、UA129aおよび129bは、実施形態に従って適合されたTA120によってサービスされ得るのとは異なる構成を有し、または有さないUAを備える。以下の議論から理解されるであろうが、UA129は、システムフレームワーク127のリソースまたは機能を利用しないが、それでもTA120の機能を利用するように適合されるアプリケーションまたは他のユーザエージェントを備える。一方、UA129bは、システムフレームワーク127の機能を利用するアプリケーションまたは他のユーザエージェントを備え、その対話を通じて、TA120の機能も提供され得る。

具体的には、UA129bは、システムフレームワーク127を介して、コンテンツを求める要求を通信するように適合され、システムフレームワーク127は、リンク128cを通じて、UA129bなどの様々なUAによって使用される一定の低レベル機能を提供する。たとえば、システムフレームワーク127は、公表されたAPIを介してUAに文書化された機能(たとえば、HTTPレイヤトランザクション、ネットワークレイヤトランザクション、メディア再生エンジンなど)を提供するANDROID（登録商標）モバイルデバイスオペレーティングシステムによって提供されるSTAGEFRIGHTメディアプレーヤアーキテクチャを備え得る。したがって、実施形態のTA120は、システムフレームワーク127と相互動作し、システムフレームワーク127APIを実装するアプリケーションによる使用のためにトランスポート加速機能を提供するように適合され得る。たとえば、システムフレームワーク127は、リンク128dを介してTA120と対話して、UA129bによって行われたコンテンツ要求をトランスポート加速動作のためにTA120に提供し得る。TA120は、たとえば、リンク128dに関連して「常時加速」ポートを提供し得、それによって、リンク128dを介して受信されたコンテンツ要求が、システムフレームワーク127を通じて提供され、したがって本明細書で説明される概念よるトランスポート加速動作の対象となることが知られる。

しかしながら、UA129aは、普通ならシステムフレームワーク127を通じて利用可能である、それ自体の低レベル機能またはサービス(たとえば、HTTPレイヤトランザクション、ネットワークトランザクション、メディア再生など)を、UA129aの動作のためにそれらの機能を最適化するなどのために実装するように適合され得る。たとえば、UA129aは、システムフレームワーク127を利用するのではなく、それ自体のHTTPレイヤ、ネットワークレイヤ、メディア再生エンジンなどを実装する、比較的高いネットワークインパクトアプリケーション(たとえば、NETFLIXまたはYOUTUBE（登録商標）クライアント)を備え得る。したがって、UA129aは、I/O要素113によって提供される1つまたは複数のポートとリンク128aを介して直接的に対話し、サーバ130と通信するように動作し得、それによって、TA120によって提供されるトランスポートアクセラレータ機能を迂回する。

UA129aは、システムフレームワーク127を通じて利用可能でもある一定の機能をそれ自体で提供するように適合され得るが、それでも、UA129aは、TA120のトランスポート加速機能などの、他の機能の可用性および実装から恩恵を受け得る。たとえば、トランスポート加速機能の実装は、複雑で、UAの開発者の専門知識の分野の外にあり得、あるいはUA129a内に直接的に含めるための理想的な機会を提示しないことがあり得る。したがって、UA129aはシステムフレームワーク127の機能を利用しないことがあるにもかかわらず、本明細書の実施形態のTA120のトランスポート加速機能へのアクセスをUA129aに提供することが望まれることがあり得る。

図1に示される実施形態のUA129aは、TA120のトランスポートアクセラレータ機能がUAによって行われたコンテンツ要求に関して実装される動作を容易にするように適合される。たとえば、UA129aは、リンク128bを介してTA120と対話し、UA129aによって行われたコンテンツ要求を、トランスポート加速動作のためにTA120に提供するように適合され得る。実施形態のUA129aは、I/O要素113のポートに向けて直接的にコンテンツ要求を送り、それによってTA120のトランスポート加速機能を迂回することによって、またはTA120のポートに向けてコンテンツ要求を送り、TA120のトランスポート加速機能を起動することなどによって、トランスポート加速の選択的に実装するように適合される。TA120は、たとえば、リンク128bに関連して「選択的加速」ポートを提供し得、それによって、UA129aは、トランスポート加速機能が提供されることが望まれる要求を、リンク128bを介してTA120の選択的加速ポートに向けて送り得る。それによって、リンク128bを介して受信されるコンテンツ要求は、本明細書で説明される概念に従ってトランスポート加速動作の対象となる。本明細書の概念によるトランスポート加速機能のUAの使用を可能にするためのUAの修正は、比較的小さいものであり得ることを理解されたい。たとえば、UAには、特定の動作、コンテンツなどに関してトランスポート加速が望まれるどうかを判定するための論理、および/またはUAによって行われた要求に関してトランスポート加速サービスを提供するために、適切な要求をトランスポートアクセラレータポート(たとえば、TA120の実施形態の選択的加速ポート)に向けて送るための論理が提供され得る。

上記から、実施形態による動作では、UA129aは、それについてトランスポート加速機能が望まれるコンテンツ要求を、TA120に関連するポートに向けて(たとえば、リンク128bを介して)送るように適合される。たとえば、UA129aの論理は、要求されたコンテンツが大きいファイル、特定のタイプのメディア、ストリーミングメディアコンテンツなどを含み、それについてトランスポート加速動作が望まれる(たとえば、ダウンロード性能改善を実現することが知られる、または期待される)と判定し得る。したがって、UA129aは、それに関連するコンテンツ要求を、リンク128bを介してTA120に向けて選択的に送るように動作し得る。実施形態によれば、比較的小さいファイル、それについてのトランスポート加速が実際的ではなく、または一般には性能の改善とはならない特定のタイプのメディアなどを求めるコンテンツ要求などの他のコンテンツ要求は、リンク128aを介してI/O要素113のポートに向けて送られ得、それによってTA120を迂回する。

本明細書の実施形態に従ってトランスポート加速動作を容易にするために、TA120の選択的加速ポートに対して行われるコンテンツ要求は、要求がトランスポート加速動作を受信することが望まれることを示すため、トランスポート加速動作を容易にするのに有用な情報を提供するためなどのシグナリングを含む。たとえば、実施形態のUA129aは、コンテンツ要求がトランスポートアクセラレータ機能に提供されるという要求を示すヘッダ情報(たとえば、本明細書のトランスポートアクセラレータ動作に固有のHTTPヘッダ)をコンテンツ要求とともに含むように動作し得る。そのようなヘッダ情報はさらに、所望の方式または最適な方式でUAへのコンテンツの配信を実現するのに有用な、優先順位情報、タイミング情報、スケジューリング情報、ビットレート情報、ファイルサイズ情報などのデータを含み得る。

実施形態による動作では、TA120の選択的加速ポートにおいて受信されたコンテンツ要求に対するデフォルト挙動がトランスポート加速機能を提供すべきではなく、加速処理なしにそれらの要求を渡す(たとえば、I/O要素113のポートにコンテンツ要求を提供する)。そのようなデフォルト挙動は、システムフレームワーク127を利用することを望まず、特定の要求を加速することも望まないUAが、特別なヘッダなしにTA120の選択的加速ポートに要求を送り、したがってその要求についてトランスポート加速動作を迂回することを容易にする。たとえば、コンテンツ要求が加速されるべきであることを示す特別なヘッダが、UA129aによってTA120に送られたコンテンツ要求内に存在しない場合、コンテンツ要求は、実施形態のTA120によって加速されない。したがって、UAは、前述の特別なヘッダを仕様して提供され得るようなシグナリングを使用して、コンテンツ要求がトランスポートアクセラレータ機能に提供されるべきであることを示し、トランスポートアクセラレータが要求を分割し、それをスケジューリングする際に利用し得る追加のメタ情報を提供し得る。このシグナリング(たとえば、特別なヘッダ)は、コンテンツサーバにコンテンツ要求を転送する前に、実施形態のトランスポートアクセラレータによってコンテンツ要求から除去され得る。このシグナリングは、様々な適切な方式のいずれかでコンテンツ要求内に含まれ得、たとえば、シグナリングは、HTTP要求の特別なヘッダであり得、HTTP要求のヘッダのフィールド値として含まれ得、HTTP要求のURIまたはURLの照会文字列内の1つまたは複数のパラメータ内に含まれ得、かつ/またはコンテンツ要求の任意の他の適切な特徴として含まれ得る。

前述のシグナリングは、要求されたトランスポートアクセラレータ機能の実装に関するTA120からUA129aへのシグナリングを含めるなどのために、2方向であり得る。たとえば、実施形態のTA120は、コンテンツ要求が加速されたか否かを示し、(たとえば、UAによる互換動作または最適化された動作を容易にするために)提供される加速の詳細に関する情報を提供するなどのヘッダ(たとえば、本明細書のトランスポートアクセラレータ動作に固有のHTTPヘッダ)を、UA129aに対する1つまたは複数の応答内に含めるように動作し得る。

前述のトランスポートアクセラレータシグナリングを実装する際に、本明細書の実施形態は、本明細書で説明される情報を搬送するためにUA/TA特殊要求ヘッダ(本明細書では「QC-STAヘッダ」と呼ばれる)を提供するように適合され得る。実施形態のQC-STAヘッダはUA-TA接続だけに関係するので、QC-STAヘッダは、本明細書の実施形態によるトランスポートアクセラレータによるコンテンツ要求の転送前に除去され得る。もちろん、QC-STAヘッダまたは他のシグナリングは、それが無視され得るように構成され得、したがってその除去は任意選択であり得る。本明細書の実施形態のQC-STAヘッダがその中に含まれるHTTP要求ヘッダの一例は、「Connection: close, QC-STA」である。本明細書の概念によるQC-STAヘッダは、セパレータ(たとえば、HTTPヘッダ内で一般的に使用されるセパレータ「;」)を用いるキー-値対のリストを含み得る。各キー-値対は、たとえばフォーマット「キー=値」で提供され得る。実施形態のQC-STAヘッダの一般的形態は「QC-STA:key1=value1;key2=value2b;...;keyN=valueN;」を含み得、ヘッダトークン文字列自体はセパレータ「;」で終了する。実施形態による動作では、QC-STAヘッダがコンテンツ要求内に存在しない場合、コンテンツ要求はトランスポートアクセラレータによって加速されない。

QC-STAヘッダ内に含まれるキーは、様々な異なるタイプの情報を提供し得る。たとえば、QC-STAヘッダに関して利用されるキーは、限定はしないが、fileType、priority、streamingBitRate、streamingPlaybackBuffer、およびrequestExpirationTimeを含み得る。キーのうちの特定のものは、追加のデータを含み得、またはそれに関連する追加のデータを有し得る。たとえば、実施形態によれば、すべてのfileTypeについてapproxFileSize情報が提供され得る。しかしながら、キーのいずれも、実施形態のQC-STAヘッダ内に存在する必要はないことを理解されたい。すなわち、UAは、デフォルトパラメータ/設定を使用するトランスポート加速機能を開始するなどのために、その中にトークンのないQC-STAヘッダとともにコンテンツ要求を送り得る。しかしながら、本明細書の実施形態のTA120の選択的加速ポートに対するコンテンツ要求では、すべての上記のキーが、必要に応じて、または適切に使用され得る。

以下のTable 1(表1)は、本明細書の実施形態のQC-STAヘッダに関して利用され得る、キー、値のタイプ、およびキーの可能な値の例を与える。

本明細書のQC-STAヘッダの実施形態に従って利用され得る、前述のキーの別の説明として、「fileType」キーは、コンテンツ要求が関係する特定のタイプのファイルに関する情報を含み得る。この情報は、たとえば、コンテンツ要求に関連する使用のためにトランスポートアクセラレータ機能の実装が実際的であり、または有利であるかどうかを判定するために、トランスポートアクセラレータによって使用され得る。追加または代替として、そのような情報は、加速の1つまたは複数の態様がどのように実装されるべきかを決定する(たとえば、チャンクサイズ、ビットレート、誤り訂正などを決定する)際にトランスポートアクセラレータによって利用され得る。

「requestPriority」キーは、UA内の与えられたコンテンツ要求の優先順位に関する情報を提供し得る。実施形態による動作では、下にある、または下位のレベルの通信レイヤに対する優先順位の一貫したマッピングがある。たとえば、実施形態は、UAによって行われるコンテンツ要求に適合するチャンク要求優先順位を確立するなどのために、この優先順位情報を低レベルネットワークライブラリ(たとえば、CHROMIUM)に渡すように動作し得る。追加または代替として、実施形態は、コンテンツ要求とともに与えられる優先順位情報に従ってコンテンツ要求のチャンク要求をスケジューリングする、トランスポートアクセラレータ内のスケジューリングアルゴリズムを実装し得る。

「streamingBitRate」キーは、要求されたデータをクライアントが再生または処理することが期待されるレートを示す情報を提供し得る。したがって、実施形態に従ってストリーミングレートを指定することは、トランスポートアクセラレータが、競合する要求ストリームに帯域幅の適切な配分を割り振るように動作することを容易にし、その結果、UAへのデータの配信が、示される再生またはデータ処理レートに合致する。

「streamingPlaybackBuffer」キーは、UAの現再生バッファの長さを示し得る。実施形態のstreamingPlaybackBufferキーは、加速の1つまたは複数の態様がどのように実装されるべきかを決定する(たとえば、チャンクサイズ、ビットレート、誤り訂正などを決定する)際に、トランスポートアクセラレータによって利用され得る。たとえば、再生バッファのサイズは、近い将来にダウンロードされるべきデータ量(たとえば、発行するチャンク要求のサイズおよび数)を決定するために、TA120によって使用され得る。

「requestExpirationTime」キーは、コンテンツ要求がそれまでに完了されるべき時刻を示し得る。ターゲット時刻は、たとえば、分数秒とともに、UNIX（登録商標）エポック以来の秒で与えられ得る。実施形態による動作では、タイムスタンプは、注目のデバイスのシステム時刻に対するものであり得、システム時刻は、この実装が正確な満了時刻を可能にするために正確である必要はない(たとえば、TA120およびUA129aが同一のクロックを使用する場合、実際の満了は所望の時点で生じることになる)。満了時刻に達したとき、実施形態のトランスポートアクセラレータは、コンテンツ要求を取り消すように動作し得る(たとえば、その後で受信されるどんなコンテンツデータも、適時でないので、使用不能であり、または望ましくないものであり得る)。

「approxFileSize」キーは、要求されるリソースの近似ファイルサイズを示し得る。そのような情報は、たとえば、(たとえば、厳密なファイルサイズが知られる前に)発行する適切なチャンク要求数を選ぶためにトランスポートアクセラレータによって使用され得る。実施形態による近似ファイルサイズ情報の利用の一例として、チャンクサイズがCである場合、TA120のRM121は、第1の応答を受信し、実際にファイルサイズを決定し、別の要求を発行する前に、max(floor(approxFileSize/C), 1)個のチャンク要求を発行し得る。

「preferredNetworkInterface」キーは、要求が特定のネットワークインターフェース(たとえば、WiFi)上で送信されるというプリファレンスを示し得る。たとえば、セルラーデータプラン制限のためにセルラーインターフェースよりも、利用可能であるときはWiFiネットワークインターフェースの使用が好ましいことがある。好ましいネットワークインターフェースのそのような選択は、たとえば、動作可能なインターフェースを認識する接続性マネージャに対するUAによるアクセスを通じて容易にされ得る。

「fastStartSize」キーは、要求されたコンテンツの配信に対する高速スタートアップが実現されるという要望を示すためにUAによって使用され得る。それに応答して、トランスポートアクセラレータは、この初期コンテンツ量をダウンロードするために複数のインターフェースを使用し、複数のインターフェースの使用から1つのインターフェースの使用に切り替わるなどのために後に通常のフェッチング動作に切り替わり、要求されたコンテンツの残りをフェッチするなどのために、要求を満たすためにそのベストエフォートを使用し得る。

「useHTTPS」キーは、トランスポートアクセラレータが(たとえば、HTTPSプロトコルによって提供される)セキュア通信経路を使用してコンテンツ要求を送信すべきであることを示すために、UAによって使用され得る。

キー、値のタイプ、およびキーの可能な値の上記の例を使用して、キーおよびその値を伴う例示的QC-STAヘッダは以下のように見え得る。
QC-STA:fileType="streaming";priority=1;streamingBitRate=7500;streamingPlaybackBuffer=10000;approxFileSize=300000;preferredNetworkInterface="WiFi";fastStartSize=1000;

上記は、本明細書の実施形態に従って実装され得るシグナリングの例を与え、したがって特定の実装は、本明細書の概念に従って様々な異なる情報を提供するようにシグナリングを実装し得ることを理解されたい。

実施形態に従って利用され得るシグナリングの別の例として、本明細書の概念によるQC-STAヘッダに関して利用され得る以下のTable 2(表2)に記述されるキー、値のタイプ、およびキーの可能な値。

本明細書のQC-STAヘッダの実施形態に従って利用され得る前述のキーの別の満了として、「uniqueUAinstanceID」キーは、いくつかの接続上でトランスポートアクセラレータに対する要求を行うUAの動作を容易にし得る。たとえば、uniqueUAinstanceIDキーは、どの接続がどのUAに属するかをトランスポートアクセラレータが知ることができるように、アプリオリ情報を提供し得る。そのような情報は、UA間で公平となるための能力をトランスポートアクセラレータに与えるために、実施形態のTA120によって利用され得る。

実施形態の「uniqueUAinstanceID」キーは、一意となるように選択される。たとえば、UAは128ビット乱数を作成し、乱数の16進数表記をその一意IDとして使用し得る。あるいは、実施形態は、その一意性を保証する一意IDを作成するための規則を定義し得る。たとえば、一意IDは、プロセスPIDとその開始時刻の組合せであり得、それによって、そのような組合せは通常、所与のホスト上のすべてのプロセス間で一意となる。

実施形態の「UAPriority」キーは、UAについての優先順位を確立するためのものである。実施形態に従って実装される、可能な優先順位値のセットは、異なるUAにわたる優先順位値の一貫した使用を容易にするなどのために、意図的に低い数(たとえば、0から7の値の範囲の8個の別個の設定)に保たれる。いくつかの実施形態によれば、優先順位キーについてのより高い値は、より高い優先順位を示す。動作の際に、より高い優先順位のUAの要求は、個々のストリームに与えられた優先順位値の如何にかかわらず、優先的な待遇を有し得る。本明細書の実施形態によれば、個々のストリームの優先順位値が同一のUAのストリーム上で比較されるが、UAにわたっては比較されない。たとえば、あるUAは、すべてのそのコンテンツ要求をデフォルト値2^31に保つように動作し得るが、他の(たとえば、ライブストリーミングクライアント)は、経時的に潜在的にはすべての2^32の可能な値を使用する細密な方式を有し得、その結果、実施形態による動作で優先順位を割り当てるための異なる方式のために、あるUAが他のUAより優位に立つことにはならないはずである。しかしながら、いくつかの実施形態では、たとえば、UAが優先順位値を割り当てるための類似のアルゴリズムを有する場合、かつ/またはUAが一緒に働くように設計されている場合、個々のストリームの優先順位値が、複数のUAにわたってストリーム上で比較され得る。

多くのUAはそのデフォルト優先順位を変更しないことが予想されるが(たとえば、UAPriority=3)、それでも、様々なストリームは異なる優先順位を利用し得る。たとえば、非対話式ソフトウェア更新プロセスは、それ自体により低い優先順位を割り当てることによって(UAPriority=0)、潜在的に実行中のストリーミングクライアントの方式から移り得る。

実施形態による動作では、UAは、新しいコンテンツ要求において新しい値を提供することによって、それに関連する優先順位を更新し得る。UAがその優先順位を更新するように動作し得るアプリケーションの一例は、非常に大きいバッファを有するビデオストリーミングクライアントである(たとえば、前もってムービー全体をダウンロードするように動作するGOOGLE PLAY)。バッファが低いとき、UAは、利用可能なバッファリングされるデータを増大させるなどのために高優先順位を示すが、バッファレベルが何らかのしきい値(たとえば、数分のバッファリングされるデータ)に達すると、それ自体の優先順位を下げ得る。バッファが低くなる場合、UAはその優先順位を再び増加させ得る。しかしながら、そのような優先順位更新は、競争状態の危険を導入することを理解されたい。競争状態を回避するために、実施形態のUAは、UAがその要求優先順位を更新した前のコンテンツ要求に対する少なくとも部分的な応答をUAが受信した後、その優先順位を更新し得る。

「uniqueStreamID」キーは、コンテンツ要求が属するストリームの識別を提供し得る。同一のuniqueStreamIDを有するコンテンツ要求は、同一のストリームに属すると考えられ得、したがって実施形態によるキー間で1つまたは複数のプロパティを共有し得る。実施形態による動作では、ストリームIDは、コンテンツ要求を行うUA内で一意となることが必要であるだけである(たとえば、トランスポートアクセラレータは、そのIDとそれに関連するUA IDの両方によってストリームを識別し得る)。

実施形態による明示的なストリーム識別子を有することは、UAによる単一のストリームについてのトランスポートアクセラレータに対するいくつかの接続の使用を容易にし、トランスポートアクセラレータは、どの接続のセットがそのストリームを形成するかを依然として知り得る。そのような構成は、様々な状況で有用であり得る。たとえば、UAがDASHクライアントを備える場合、別々のストリームが、オーディオおよびビデオについて実装され得る。UAがネットワーキングライブラリ(たとえば、クロムスタック)を使用する場合、UAからトランスポートアクセラレータへの接続は、ストリームを忠実に表さないことがある(たとえば、任意の接続上の任意のコンテンツ要求が、2つのストリームのどちらかに属し得る)。したがって、本明細書の概念に従って動作するDASHクライアントは、そのコンテンツ要求をストリーム識別子でタグ付け得、それによって、トランスポートアクセラレータが、異なるストリームについてチャンク要求を正しく優先順位付けすることを可能にする。

「streamPriority」キーは、ストリームについての優先順位値(たとえば、0から2^32-1の範囲内)を提供し得る。UAおよびトランスポートアクセラレータは、より大きい範囲のストリーム優先順位を有する、より小さい優先順位値のセットに関して、前述と同様のアルゴリズムを使用し得る。実施形態による動作では、同一のUAのストリームに関して、トランスポートアクセラレータは、より高い優先順位を有するストリームからのコンテンツ要求を、より低い優先順位を有するものよりも前に処理する。streamPriority値は、後続のコンテンツ要求において更新されるまで、それを求めるコンテンツ要求が行われたストリームのために定位置にとどまり得る。streamPriority値が更新されるとき、優先順位の変更前に発行されたそのストリームのコンテンツ要求についてであっても、ストリーム全体について変更されたとみなされ得る。

「streamBitRate」キーは、それを求めるコンテンツ要求が行われるストリームについて想定されるべきビットレート(たとえば、kbps単位)を示し得る。そのようなビットレート情報は、別のUAにおいてデータ配信が窮乏することなく、UAにおいて所望の性能を容易にするなどのために、満足の行く帯域幅共有ポリシーを実装するためにトランスポートアクセラレータによって使用され得る。実施形態による動作では、streamBitRateは、同一のストリームを求める後続のコンテンツ要求において新しい値に置換されるまで、所与のストリームについて設定されたままであり得る。実施形態のstreamBitRateキーによって与えられるビットレート「hint」をクリアするために、所定のビットレート値(たとえば、-1)が使用され得る。

「streamPlaybackBuffer」キーは、現在ストリーム内にある再生バッファ量を(たとえば、ミリ秒単位で)示し得る。実施形態のstreamPlaybackBufferキーは、加速の1つまたは複数の態様がどのように実装されるべきかを決定する(たとえば、チャンクサイズ、ビットレート、誤り訂正などを決定する)際に、トランスポートアクセラレータによって利用され得る。たとえば、streamPlaybackBufferが大きいとき、トランスポートアクセラレータは、アップリンクトラフィックおよびサーバ負荷を低減するために、より大きいサイズのチャンク内のデータを要求し得る。小さいstreamPlaybackBufferでは、トランスポートアクセラレータは、より大きいサイズのチャンク内のデータを要求しないことを選び得る。これは、このケースではhead-of-lineブロッキングの危険を増大させるからである(たとえば、遅延チャンクがストリームを中断させ得る)。いくつかのトランスポートアクセラレータ実装は、streamPlaybackBuffer値Xを、X+Tに設定されたrequestSoftExpirationTimeを有する要求と大まかには同一として扱い得、ただしTは、要求がUAによって受信された時刻である。

「requestExpirationTime」キーは、コンテンツ要求が満了することになる時刻、したがってUAがもはやコンテンツ要求に対するどんな応答も受信することに関心がない時刻を与え得る。実施形態のトランスポートアクセラレータは、たとえば、コンテンツ要求が満了し、時間内に終了され得ないとき、UAに対する接続を閉じ得る。

「requestSoftExpirationTime」キーは、トランスポートアクセラレータがそれまでにコンテンツ要求に対する応答を受信しようと試みるべきであるソフト満了時刻を与え得る。実施形態による動作では、requestSoftExpirationTime期限が守られない場合、トランスポートアクセラレータは、たとえば、コンテンツ要求をドロップさせないことがあり得る。たとえば、コンテンツは、トランスポートアクセラレータによって引き続きフェッチされ得、それによって、トランスポートアクセラレータが、要求されたコンテンツをrequestSoftExpirationTimeの満了前に得るために、そのベストエフォートを実装した可能性があることを除いて、すべてのものは、コンテンツ要求に関連する満了時刻がないかのようになる。実施形態による動作では、トランスポートアクセラレータは、適切な要求方策に関して決定するためにそのようなソフト満了時刻を利用し得る。たとえば、トランスポートアクセラレータがFEC修理データを要求し得る場合、トランスポートアクセラレータは、間もなくソフト満了するコンテンツ要求のためにかなり大きいFECデータ量を要求するように動作し得る。それらのコンテンツ要求は、個々のチャンク要求を遅延させるパケット損失が生じる場合、普通なら期限を守らない可能性が高くなるからである。しかしながら、ずっと将来にソフト満了する別のコンテンツ要求では、トランスポートアクセラレータは、それらのコンテンツ要求についてより少ないFECデータを要求し、またはFECデータを要求しないように動作し得る。それらのケースでは、データ再送信が十分高速に動作し得、それによって、不要なFECオーバヘッドのために帯域幅を使用することを回避するからである。実施形態に従って使用される特定のソフト満了時刻は、以下でさらに論じられるように、要求前提条件とともに変化し得る。

追加または代替として、実施形態のrequestSoftExpirationTimeキーのソフト満了時刻は、様々な他のアルゴリズムに関して使用され得る。たとえば、トランスポートアクセラレータは、行き詰まっているように見えるチャンク要求を取り消し、再発行し得る。したがって、関係するコンテンツ要求のソフト満了時刻が間もなくであるとき、トランスポートアクセラレータは、チャンク要求のそのような取消しおよび再発行を積極的に利用し得、満了時刻がずっと将来である場合、より寛大となり得る。

「requestUniqueID」キーは、コンテンツ要求の一意識別を実現し得る。そのような要求IDは、たとえば、単に1つのUAストリーム内ではなく、(たとえば、各UAにわたってではなく)注目のUA内で一意となるように選ばれ得る。一意IDは、以下で論じられるrequestPrerequisitesキーに関して使用するなどのために、UAが後に発行した特定のコンテンツ要求をUAが参照することができるように、実施形態に従って提供され得る。

「requestPrerequisites」キーは、特定のコンテンツ要求の前提条件である要求IDの区切られたリストを提供し得る。たとえば、requestPrerequsitesキーは、発行されるコンテンツ要求の前提条件である要求IDのカンマ区切りリストを含み得る。ビデオストリーミングアプリケーションでは、たとえば、Iフレームからは始まらず、独立して復号化可能ではなく、先行するフラグメントAとともに復号化可能なだけであるフラグメントBを求める要求は、フラグメントAを求めるその要求を、フラグメントBを求める要求の前提条件とし得、それによってフラグメントBの前にフラグメントAが必要であることをトランスポートアクセラレータに示す。そのような要求前提条件の利用についての別の例は、スケーラブル高効率ビデオコーディング(SHEVC)ビデオストリーミングアプリケーションであり、ベースレイヤを求める要求は、第1のエンハンスメントレイヤを求める要求の前提条件となり得、以下同様である。

前提条件情報は、いくつかの目的で本明細書の実施形態に従って利用され得ることを理解されたい。たとえば、上記の例に示されるように、前提条件情報は、ストリーム内の個々のコンテンツ要求の好ましい順序付けを通信するために利用され得る。たとえば、クライアントは、HTTPのような要求の順次処理を実装し得、それは、各要求をその先行要求に依存させることによって達成され得る。同じことは、ストリーム優先順位などの他の情報を使用して達成可能ではないことがある。そのような他の情報は、個々のコンテンツ要求に関係しないことがあるからである(たとえば、ストリーム優先順位は、個々の要求にではなくストリーム全体に対して作用する)。DASHクライアントが、たとえばビデオ要求のストリームを有することを望み得る。クライアントがHTTPパイプライニングをサポートしないHTTPライブラリを使用するが、クライアント自体が時間的に重複する要求を発行する場合、トランスポートアクセラレータは、異なるTCP接続上で異なるストリームを求める要求を受信し得る。本明細書の実施形態に従って提供される要求前提条件は、それらの要求を互いに対してどのように順序付けるかをトランスポートアクセラレータに通知するために利用され得、それによって、クライアント内の潜在的に無限のデータ量をバッファリングし、リオーダーする必要を回避する。この問題を解決するための代替技法は、ストリーム優先順位およびUA優先順位に加えて要求優先順位を提供することであり得、それによって、本願にとって要求依存関係が不要となる。

実施形態の前提条件情報が利用され得る別の目的は、1つまたは複数のハードまたはソフト満了時刻が満たされ得ない場合にどのように動作するかに関する情報をトランスポートアクセラレータに提供することである。実施形態による動作の際に、ハード満了のための挙動は、ソフト満了のための挙動とは異なり得る。

要求Aが(直接的または間接的に)要求Bの前提条件であり、要求Aがハード満了の対象である場合、実施形態によれば、要求Aのハード満了時刻の満了は、要求Bが後の満了時刻を有する(または満了時刻を全く有さない)場合であっても、要求Bについての満了時刻も満了させる。要求Aのハード満了時刻に達し、要求Aが利用可能ではない場合、要求Aは決して利用可能とはならないので、上記の関係が実装され得る。要求Aが、この例では決して利用可能とはならない要求Bの前提条件であるので、将来のある時点で要求Bが利用可能である場合であっても、要求Bは有用なものとはならない。

上記の状況が生じ得る一例は、SHEVCライブビデオプレーヤに関するものである。SHEVCデコーダは、規定の時刻に(たとえば、SHEVCデコーダがビデオデータの次の秒を受信する各秒ごとに)、その200ms後に再生される、いくつかのエンハンスメントレイヤを伴うベースレイヤなどの次のビデオ区間を受信し得る。したがって、プレーヤに与えられるデータは、ベースレイヤと、いくつかのエンハンスメントレイヤである。しかしながら、多くても各秒は、そのビデオデータがデコーダに送られた前後の以前の時刻に使用されたのと同数の、使用され得るエンハンスメントレイヤを有するという制限がある。これは、次のフルリフレッシュセグメントが訪れるまで反復し、その時点で、任意の数のレイヤがデコーダに与えられ得る(たとえば、5つごとのセグメントがそのようなリフレッシュであり得る)。ストリーミングモジュールは、秒1.2に再生されるべきベースレイヤB1およびエンハンスメントレイヤE1を要求し、したがってハード満了時刻を1に設定し得る。次いで、後に、ストリーミングモジュールは、秒2.2に再生されるべきベースレイヤB2およびエンハンスメントレイヤE2を要求し、したがってそれらのハード満了時刻を2.0に設定し得る。E2がE1なしでは有用ではないこと、およびE1が時間内に受信されない場合、トランスポートアクセラレータがE2をフェッチすべきではないことをトランスポートアクセラレータに伝達するために、要求依存関係が使用され得る。このことは、E1に依存するものとしてE2をタグ付けすることによって、本明細書の実施形態に従って達成され得る(E2を求める要求が発行される時刻に、E1が成功するか否かは既知ではないことがあることを理解されたい)。

そのような要求依存関係は、上記の例で示されるようにハード満了に関して有用であるだけではなく、ソフト満了に関連しても有用である。ソフト満了に関する要求依存関係の有用性の一例として、UAは、要求Aが要求Bのソフト満了時刻の前のソフト満了時刻を有する、2つの要求AおよびBを発行していることがある。要求Bが要求Aに依存する場合、トランスポートアクセラレータが要求Aのソフト満了時刻までに要求Aをダウンロードすることに失敗する場合、それでも、トランスポートアクセラレータは、要求Aを要求Bとともに完了するように試み得る(たとえば、要求Bのソフト満了時刻の後にのみ、要求Bのソフト満了期限を満たすことになるので、要求Bのソフト満了時刻まで)。より一般的に述べると、実施形態のトランスポートアクセラレータ内の要求Aのために使用される実際の有効なソフト満了時刻は、要求Aとその直接的および間接的に依存する要求(たとえば、上記の例では要求B)のタグ付けされたソフト満了時刻の最小値であり得る。

ソフト満了に関する要求依存関係の使用をさらに例示するために、SHEVCビデオクライアントが再び考慮される。時刻1において、UAは、ベースレイヤB1のみ、またはベースレイヤとエンハンスメントレイヤの組合せB1+E1のどちらかである、セグメント1を再生し得る。したがって、B1を求める要求は、ソフト満了時刻1とともに発行され得、E1を求める別の要求も時刻1にソフト満了し、B1はE1の前提条件として宣言される。時刻2において、UAは、ベースレイヤB2のみ、またはベースレイヤとエンハンスメントレイヤの組合せB2+E2のどちらかである、セグメント2を再生し得る。したがって、B2を求める要求は、ソフト満了時刻2とともに発行され得、E2を求める別の要求もソフト満了時刻2であり、B2はB1を前提条件として有するものとして宣言され、E2はB2とE1の両方を前提条件として有するものとして宣言される(たとえば、この例でのE2は、再生可能となるためにB2とE1の両方を必要とする)。B1が時刻1に受信されるが、E1が受信されない場合、プレーヤは、エンハンスメントレイヤE1なしに時刻1にベースレイヤB1を再生し得る。したがって、実施形態のトランスポートアクセラレータは、すべての有効なソフト満了時刻がそのとき2であるので、時刻2までにE1、B2、およびE2のすべてをダウンロードするように試み得る。トランスポートアクセラレータがE1、B2、およびE2のすべてをダウンロードに成功する場合、これらのレイヤを正しく復号化するためのすべての前提条件が利用可能となるので、プレーヤは、時刻2にB2+E2の組合せを再生することができ得る。

ハード満了時刻の前の例と、ソフト満了時刻の例との間の違いは、ハード満了の例では、デコーダが再生時刻に「追いつき」得ないと想定されることである(たとえば、プレーヤは、時間内に受信する任意のレイヤを利用し得るだけである)。一方、ソフト満了例では、そのソフト満了時刻の後に受信される要求は、それでも従属要求を復号化するために使用され得ることが想定される(たとえば、E1がそれ自体の再生のために時間内に受信されなかった場合であっても、E2の再生時刻の直前にE1およびE2が受信される限り、E1は、E2を復号化するために使用され得る)。

上記のTable 2(表2)に記述される例示的シグナリングは、いくつかの形でTable 1(表1)のものとは異なることを理解されたい。1つの顕著な違いは、ストリームの概念がTable 2(表2)のシグナリングで明白に提供されることである。個々の要求ではなく、多くのプロパティがストリームに関連し、したがってストリームごとに設定され得る。たとえば、ビットレートは、単一の短い要求に関して正確に設定することが難しいことがあるが、要求のストリームに関して実施する方が、より容易で意味のあることがある。

Table 2(表2)のシグナリングで提供される別の違いでは、コンテンツ要求が「ソフトに」満了し得、それによって、満了時刻がコンテンツ要求を無効にしない。任意選択の要求依存関係情報が、Table 2(表2)のシグナリングの別の違いとして追加されている。そのような依存関係情報は、たとえば、ビデオストリーミングアプリケーションにとって有用であり得る。

Table 1(表1)の例示的シグナリングと比較して、以下のキーが、実施形態に従って、Table 2(表2)の例で与えられるシグナリング内の異なるキーによって置換され、または取り替えられ得る。(streamBitrateによって取り替えられた)streamingBitrateおよび(streamPlaybackBufferによって取り替えられた)streamingPlaybackBuffer。Table 1(表1)の例示的シグナリングのrequestPriorityキーが、実施形態のTable 2(表2)の例示的シグナリングのstreamPriorityキーによって置換され、またはそれに加えて使用され得る。

UAによってトランスポートアクセラレータに提供されるシグナリングを参照して上記のシグナリング例が説明されたが、本明細書の実施形態のトランスポートアクセラレータ機能に関して実装されるシグナリングは、トランスポートアクセラレータからUAへのシグナリングを含む。たとえば、実施形態のTA120は、UA129aに対する1つまたは複数の応答内に、本明細書の概念に従って様々なシグナリングを示す特別な応答ヘッダ(本明細書では「QC-STA-responseヘッダ」と呼ばれる)を含み得る。QC-STA-responseヘッダの形式は、前述のコンテンツ要求のQC-STAヘッダの形式と同一であり得る。

以下のTable 3(表3)は、本明細書の実施形態のQC-STA-responseヘッダに関して利用され得るキー、値のタイプ、およびキーの可能な値の例を与える。

本明細書のQC-STA-responseヘッダの実施形態に従って利用され得る前述のキーの別の説明として、「requestAccelerated」キーは、コンテンツ要求が加速されているか否かを示し得る。そのような情報は、どの要求の結果として加速され得、または加速され得ないかを「学習」し、要求されたデータの加速/非加速配信に関する適切な、または最適化された動作のために1つまたは複数の属性を調節するなどのために、UAによって利用され得る。

「requestEstimatedReceiveRate」キーは、(たとえば、十分に多量のデータが要求されているとき)コンテンツ要求が行われたサーバに対して達成され得るレートの推定を示し得る。たとえば、適応ストリーミングクライアントが、この情報を利用して、再生のために選ぶ良好な表現を決定し得る。実施形態による動作では、トランスポートアクセラレータが、このサーバ上で過去に達成することができたレートの履歴に基づいて、そのような受信レートの推定を計算し得る。追加または代替として、トランスポートアクセラレータは、使用されているネットワークインターフェースを介して達成可能なレートの推定を使用し得る。したがって、そのような推定は、実施形態に従って、達成可能なレートについての履歴情報とともに取得され得る。

「numberOfSupportedPriorities」キーは、トランスポートアクセラレータがサポートする別個の優先順位値の数を示すために使用され得る。そのような情報は、トランスポートアクセラレータによってサポートされる範囲内に含まれるようにUAのコンテンツ要求に割り当てられた優先順位を調節する際にUAによって利用され得、それによって、そのような各コンテンツ要求に関する適切な相対的優先順位処置が保証される。

コンテンツ要求に関してコンテンツサーバに対するセキュアリンクを確立する際にトランスポートアクセラレータが成功したかどうかを示すために、「usedHTTPS」キーが使用され得る。トランスポートアクセラレータが、I/O要素113を通じて直接的にセキュア通信を確立することを試みるなどのために、セキュア通信の確立に成功しなかったことをレポートする場合、UAは、たとえば、TA120の選択的加速ポートではなく、I/O要素113のポートにコンテンツ要求を送信すること選び得る。

本明細書の概念による、UAによって要求される所望のコンテンツのフラグメントまたはフラグメントのシーケンスの拡張配信を提供するためにUAとトランスポートアクセラレータとの間で提供され得る様々なシグナリングの例を与えたので、本明細書の実施形態による、そのようなシグナリングの例示的使用に関するさらなる詳細が以下で説明される。しかしながら、与えられる例は、本明細書の概念による、そのようなシグナリングの利用の網羅的なものではないことを理解されたい。

上記のstreamingBitRateおよび/またはstreamBitRateキーによって提供されるようなビットレート情報を利用する際に、TA120のスケジューリングアルゴリズムが、異なるビットレートストリームを公平に共有することを可能にするようにチャンク要求をスケジューリングするために適合され得る(たとえば、400Kbpsストリームは、100Kbpsストリームの約4倍のチャンク要求を受信し得る)。したがって、そのようなスケジューリングアルゴリズムは、所与のストリームのビットレートを制限し得、それによって、より低い優先順位のストリームに帯域幅の一部を得る機会を与える。

requestExpirationTimeおよびrequestSoftExpirationTimeキーによって提供されるような前述の満了時刻情報は、以下のアルゴリズムのうちの1つまたは複数に従ってチャンク要求をスケジューリングするために実施形態のTA120によって使用され得る。トランスポートアクセラレータチャンク要求制限アルゴリズムが、たとえば、低待ち時間ライブストリーミング状況で使用され得る。実施形態によるそのようなアルゴリズムの利用の背後にある概念は、コンテンツ要求がある時刻Teに満了することが知られている場合、Teに近すぎるチャンク要求に対する応答は、Teによって返される可能性が低くなるので、そのコンテンツ要求を求める新しいチャンク要求を発行することを、Teの前の短い時間、停止することが有利であり得るということである。そのようなアルゴリズムの実装の効果は、満了時刻の直前に、トランスポートアクセラレータが次いで別のコンテンツ要求の処理に移り、それによって、満了するコンテンツ要求を求めるチャンク要求の浪費が少なくなることである。

そのようなトランスポートアクセラレータチャンク要求制限アルゴリズムは、以下に従って表現され得る。
現在時刻をTとする、
考慮中のUA要求の満了時刻をTeとする、
チャンク要求が発行されたときから、応答の開始が受信されるまでの平均時間をTstartとする(これは、キューイング遅延を含むラウンドトリップ時間(RTT)の推定である)、
チャンク要求発行時間から、チャンク応答が完了するまでの平均時間をTendとする(RM121内の指数重み付き移動平均(EWMA)推定器などでTstartおよびTendが測定され得る)、
構成定数をcsおよびceとする、
T+cs*Tstart+ce*Tend≧Teである場合、与えられたUAコンテンツ要求を求めるさらなるチャンク要求を発行しない。
上記の例では、csおよびceは通常、cs,ce≧0およびcs+ce=1となるように選ばれ得る。csおよびceについてのいくつかの可能な選択肢が、以下のTable 4(表4)に記載される。

上記のトランスポートアクセラレータチャンク要求制限アルゴリズムに関する変形形態では、F(t)は、チャンク要求が完了するのにかかる時間がt以下である確率である。したがって、F(0)=F(負の値)=0、F(無限大)=1であり、Fは単調増加する。Fは通常は既知ではないことがあるが、Fのパラメトリックまたはノンパラメトリック推定が行われ得る。トランスポートアクセラレータチャンク要求制限アルゴリズムに関するこの変形形態は、以下のように表現され得る。
現在時刻をTとする、
考慮中のUA要求の満了時刻をTeとする、
構成定数をpthreshとする、
(Te-T)<pthreshである場合、与えられたUAコンテンツ要求を求めるさらなるチャンク要求を発行しない。
上記のpthresh構成定数は、0から1の間の何らかの適切な値となるように選ばれ得、Fがどのように推定されるかに応じて、制限値0および1もかなりのものとなり得る。

動作の際に、例で与えられたトランスポートアクセラレータチャンク要求制限アルゴリズムは、コンテンツ要求がハード満了しようとするまで、コンテンツ要求を求めるチャンク要求を送り続ける。チャネルレートが近似的に既知であるとき、本明細書の実施形態に従って動作可能であるトランスポートアクセラレータは、コンテンツ要求がそのハード満了時刻前に成功しないことをずっと早期に結論付け得、したがって、それを求める何らかの(またはさらなる)チャンク要求を要求することによって帯域幅を浪費しない。したがって、そのようなトランスポートアクセラレータ実施形態は、そのハード満了期限が満たされ得ない要求を断念するためのアルゴリズムを実装し得る。要求ハード満了に基づくそのようなアルゴリズムは、以下で表され得る。
考慮中の要求についての満了時刻をTeとする、
考慮中の要求のサイズをSとする(サイズが既知ではない場合、推定が使用され得る)、
考慮中の要求についてすでに要求されたバイト数をVとする、
構成定数をcaとする(たとえば、ca=1)、
(考慮中のコンテンツ要求についての)ダウンロードレートの推定をRとする、
チャンク要求発行時刻から、応答が到着し始めるまでの時間の推定をTstartとする(これは、上記の例示的アルゴリズムからのTstartと同一であり得る)、
d:=Te-(T+Tstart)とする、
ca*d*R<S-Vである場合、考慮中のコンテンツ要求を求めるチャンク要求を発行しない。
caについてのいくつかの可能な選択肢が、以下のTable 5(表5)に記載される。要求を断念することは一般には望ましくないので、ca≧1の選択肢が通常は好ましい。

レートRは経時的に変化し得る。それでも、上記のアルゴリズムが所与の時点に発行されるべきチャンク要求を妨げる場合、後の時刻にはそれを妨げないことがある。

実施形態は、requestSoftExpirationTimeキーによって提供されるようなソフト満了時刻に関連するFECアルゴリズムを実装し得る。たとえば、コンテンツ要求についてのFECデータが利用可能である場合、実施形態は、ソフト満了時刻が近いとき、FECデータをより積極的に要求するように動作し得る。そのようなアルゴリズムは、基礎となるチャネル条件に対して調節し得る(たとえば、誤り確率が低いとき、満了が近い場合であっても、オーバヘッドがほとんど要求されないことがある)。

streamPriorityキーなどを通じて、実施形態に従って提供され得る別個のストリーム優先順位の数は、かなり大きいことがあり得る(たとえば2^32)。そのような大きい数の優先順位は、各コンテンツ要求を異なる優先順位で送ることを可能にするなどのために、いくつかのアプリケーションに関して有用であり得る。そのようなケースにおいて、利用可能な優先順位値のセットを使い果たさないために、多数の異なる優先順位値が、トランスポートアクセラレータに通信され得る。さらに、トランスポートアクセラレータがHTTP/2.0をバックエンドとして使用するとした場合、クライアントは、HTTP/2.0によってサポートされる優先順位の完全なセットを使用することが可能となり得る。したがって、本明細書の実施形態は、より小さいセットへの優先順位マッピングを実現するためのアルゴリズムを実装し、それによって、そのような大きい別個の優先順位の使用に対処し、相互操作性を容易にする。様々な技術的理由で、いくつかのトランスポートアクセラレータの実装は、すべての可能な優先順位値(たとえば、2^32)を内部でサポートしないことがある。そのようなケースでは、内部でサポートされる優先順位のより小さいセットに値をマッピングするための優先順位マッピングアルゴリズムが提供され得る。そのような優先順位マッピングが行われ得る多くの方式があるが、例示的実施形態が以下で与えられる。以下の議論からより良く理解するであろうが、以下の例は一見すると複雑であり得るが、実装され得る他のマッピング技法に勝る利点を有することを理解されたい。

トランスポートアクセラレータがN個の別個の内部優先順位0、...、N-1をサポートする場合、以下のアルゴリズムは、所与の32ビット優先順位Pについて内部優先順位へのマッピングを実現する。
s_small=floor(2^32/N)
s_large=s_small+1
n_large=2^32-N*S_small
n_small=N-n_large
#注:s_small*n_small+s_large*n_large=2^32
If P>=n_small*s_small,
internalPriority=n_small+floor((P-n_small*s_small)/s_large)
Else,
internalPriority=floor(P/s_small)

ほとんどのクライアントは、2^32個の別個の優先順位を必要とせず、したがって恐らくはM個の別個の優先順位のずっと小さいセットを利用し得る。そのケースでは、クライアントは、可能な要求優先順位0、...、M-1を有し得る。0、...、M-1の範囲内の所与の優先順位clientInternalPriorityについての2^32ビット精度優先順位p'を計算するために、以下のアルゴリズムが使用され得る。
s_small_c=floor(2^32/M)
s_large_c=s_small_c+1
n_large_c=2^32-M*S_small_c
n_small_c=M-n_large_c
#注:s_small_c*n_small_c+s_large_c*n_large_c=2^32
If clientInternalPriority >= n_small_c,
P'=n_small_c*s_small_c+(clientInternalPriority-n_small_c)*s_large_c
Else,
P'=clientInternalPriority*s_small_c

上記の優先順位マッピング技法は、相互操作性を実現するだけではなく、他の可能な優先順位マッピング技法に勝る利点ももたらす。たとえば、上記の例示的実施形態の優先順位マッピングは、トランスポートアクセラレータが少なくともアプリケーションが必要とするだけの別個の優先順位をサポートする限り(すなわち、N≧Mである限り)、別個のクライアント優先順位が別個のトランスポートアクセラレータ優先順位にマッピングされ、優先順位順序付けが正しく保持されることを保証し得る。この優先順位マッピングは、クライアントがトランスポートアクセラレータの内部値Nを知ることなく、トランスポートアクセラレータがクライアントの値Mを知ることなく機能することに留意されたい。さらに、クライアントが、優先順位を割り当てるための別の方式を使用する場合(たとえば、割当てP'=floor(clientInternalPriority*2^32/M)を使用することによって)、それでも、例示的実施形態による優先順位マッピングは、選ばれる割当てが値2^32の範囲に拡散する限り、比較的良好に機能する。

上記から理解できるように、特定のコンテンツ、特定のコンテンツ要求などに関してトランスポートアクセラレータ動作を要求するために、シグナリングがUAとTAとの間で実装され得る。いくつかの実施形態による動作では、TAは、トランスポート加速機能の希望を示すそのようなシグナリングの存在を検出し、したがってトランスポート加速機能を提供し得る。しかしながら、コンテンツ要求に関するトランスポート加速動作を容易にするために使用され得るシグナリングが、本明細書の実施形態に従ってTAに対して行われるが、それでも、本明細書での実施形態は、そのようなコンテンツ要求に関するトランスポート加速動作を選択的に提供するように動作し得ることを理解されたい。すなわち、特定のコンテンツまたは特定のコンテンツ要求に関してトランスポート加速が望まれることを要求するUAからのシグナリングを検出するが、実施形態のTAは、シグナリングされた要求に応答してトランスポート加速機能の実装が実際に実装されるべきかどうかを判定するように動作し得る。たとえば、選択的加速ポートに送られるコンテンツ要求は、コンテンツ要求が加速されるか否かを決定するために、トランスポートアクセラレータによる規則の別のセットの対象となり得る。

TA制御125の論理によって実装され得るような要求ディスパッチャは、いつコンテンツ要求を加速するか、またはコンテンツ要求の加速を迂回するかを決定するために使用される1つまたは複数の規則を生成するために、コンテンツ要求、またはその側面を解析する(たとえば、コンテンツ要求および/または応答メッセージのrequest-URI、ヘッダフィールド、および他の要素を解析する)ように動作し得る。そのような規則は、たとえば、一定のキーワード/フレーズパターンの存在についてチェックを実現し得る。実施形態による動作では、そのような規則は、除外リストを提供するために使用され、それによって、除外リストは、満たされるときに、コンテンツ要求が加速されないという決定を引き起こすブラックリスト規則のセット(たとえば、HTTPバージョン、メッセージ方法、要求されるファイルサフィックス、ヘッダ、および(サーバ、リソース)タプルなどに関するチェックのセットを含む)を含む。

上記によれば、図1に示される実施形態は、通信セッションに関して選択的トランスポートアクセラレータ動作を実現するように、本明細書の概念に従って適合されたTA制御125を含む。前述のように、TA制御125は、プロセッサ(たとえば、プロセッサ111)によって実行されるとき、本明細書で説明されるように動作可能な論理回路を提供する、メモリ112内に記憶され得るようなコンピュータ可読コードセグメントとして実装され得る。TA制御125は、本明細書で説明される動作のための必須機能を提供するように動作可能な、図示される実施形態の解析/制御論理126などの1つまたは複数の機能ブロックを含み得る。クライアントデバイス110内に配設されるように示されているが、実施形態は、TA制御機能の異なる構成を利用し得ることを理解されたい。たとえば、TA制御125のいくつかの部分は、サーバ130に配設された解析/制御論理126、および/またはクライアントデバイス110と通信する別のプロセッサベースのシステムなど、クライアントデバイス110の外部に配設され得、別の部分はクライアントデバイス110に配設される。同様に、TA制御125、またはその部分は、図示される実施形態に示される以外のクライアントデバイス110内に配設され得る。たとえば、TA制御125、またはそのある部分(たとえば、解析/制御論理126)は、実施形態のTA120内に配設され得る。

実施形態のTA制御125は、トランスポート加速がそれについて実現されるべきであるメッセージと、トランスポート加速がそれについて実現されるべきではないメッセージとの間を区別するように動作し、それによって選択的トランスポートアクセラレータ動作を実現する。たとえば、上記で論じられたように、トランスポート加速を容易にするために、TA120は、フラグメント要求をチャンク要求に細分するように動作し得る(たとえば、HTTP要求を、適切な時にサーバに送られるべき、より小さい要求に分解する)。しかしながら、そのようなより小さいチャンク要求の使用は、すべての状況で所望の動作を提供するわけではないことがある。要求をより小さい要求に分解し、それらのより小さい要求をサービスする動作は、それに関連するオーバヘッドを有する。要求されたコンテンツを記憶するファイル自体が小さい場合などのいくつかのケースでは、オーバヘッドの増大の結果、データのトランスポートが加速されないことがあり得る。同様に、後でダウンロードされると予想されるコンテンツに対する前提条件である小さいファイルがある場合など、要求間の特定の依存関係がある場合、細分された要求を行うための動作は、この相互依存コンテンツに関して要求を分割し得、それによって、加速を試みたために、依存関係グラフ内で重要な時間が失われ、コンテンツがより低速に再構築される(たとえば、得られるウェブページがレンダリングされる)。別の例として、バイト範囲要求を使用してチャンク要求が行われ得るのに対して、サーバはバイト範囲要求をサポートしないことがある(たとえば、要求内のサポートされないバイト範囲情報を無視し、各チャンク要求に応答して完全なファイルを返す)。そのような状況の結果、ネットワーク輻輳が増大するとともに、トランスポート加速を実現することに失敗する。

したがって、TA制御125の論理は、TA120の選択的加速ポートに対して行われたコンテンツ要求(たとえば、それについてのQC-STAヘッダが含まれ、それによってUAがコンテンツ要求を加速させることを望むことを示すコンテンツ要求)を解析するように動作し得る。たとえば、解析/制御論理126は、コンテンツ要求から、またはコンテンツ要求に関連して1つまたは複数の加速選択属性を取得し、特定のメッセージまたは通信セッションに関してTA120によってトランスポート加速が実現されるべきかどうかを判定し得る。したがって、解析/制御論理126は、TA制御125などを介してTA120(および/またはそれに関連するルーティングブロック)にシグナリングを提供し得、上記の判定に基づいて、そのメッセージまたは通信セッションを求める要求を、TA120によってトランスポート加速動作に提供し、またはトランスポート加速動作に実現しない。どちらの状況でも、TA120は、要求を渡す前に、トランスポート加速シグナリングのコンテンツ要求(たとえば、前述のQC-STAヘッダ)、またはその部分(たとえば、チャンク)をサーバ130上にストリッピングするように動作し得る。さらに、TA120は、加速決定のステータスを示すためにUA129aにシグナリングを提供し、かつ/またはその動作に関する情報を提供するように動作し得る。

図2Aのフローチャートは、本明細書の実施形態による、選択的トランスポートアクセラレータ動作を提供するためのTA制御125の動作を示すフロー200を示す。図示される実施形態のブロック201において、TA120の選択的加速ポートに対して行われるコンテンツ要求が解析され、要求がトランスポート加速動作を受信すべきであることを示すシグナリングが存在するかどうかが判定される。たとえば、解析/制御論理126は、コンテンツ要求がトランスポートアクセラレータ機能に提供されるべきであることを示すコンテンツ要求とともに含まれるヘッダ情報(たとえば、本明細書のトランスポートアクセラレータ動作に固有のHTTPヘッダ)を解析するように動作し得る。要求がトランスポート加速動作を受信すべきであることを示すシグナリングが、様々な適切な方式のいずれかでコンテンツ要求内に含められ得、たとえば、シグナリングは、HTTP要求の特別なヘッダであり得、HTTP要求のヘッダのフィールド値として含められ得、HTTP要求のURIまたはURLの照会文字列内の1つまたは複数のパラメータ内に含められ得、かつ/または本明細書の実施形態によるコンテンツ要求の任意の他の適切な特徴として含められ得る。コンテンツ要求に関するトランスポート加速が望まれることを示すためのシグナリングが存在しない場合、図示される実施形態による処理はブロック202に進み、要求(TA120の選択的加速ポートに提供されているが)が、TA120によって実現されている加速動作なしにサーバ130に渡される。

しかしながら、コンテンツ要求に関するトランスポート加速が望まれることを示すためのシグナリングが存在する場合、そのようなトランスポート加速処理は、実施形態に従って提供され、または提供されないことがある。したがって、このケースでは、図示される実施形態による処理はブロック203に進み、1つまたは複数の加速選択属性が、TA120の1つまたは複数の機能を選択的に実装する際に使用するために、TA制御125の論理によって取得される。たとえば、TA制御125の論理は、要求(たとえば、フラグメントおよび/またはチャンク要求)自体から1つまたは複数の加速選択属性を取得し得る。加速選択属性は、コンテンツサーバからのコンテンツを求めるユーザエージェントの要求の属性、コンテンツサーバの属性などを含み得る。

要求から1つまたは複数の加速選択属性を取得する際に、TA制御125の論理は、要求の様々な側面、要求に関して利用される通信プロトコル、要求内のデータなどを解析し、加速選択属性に関する情報を識別するように動作し得る。たとえば、TA制御論理は、そのような情報を、URI、ユーザエージェントフィールド、バイト範囲、またはコンテンツ長さフィールドなどとして解析し、加速選択属性を識別するために有用な情報を識別するように動作し得る。実施形態による動作では、TA制御論理は、要求を解析し、要求のプロトコルタイプ(たとえば、HTTPS、HTTP1.0、HTTP2.0など)、要求に関連する通信セッションのプロパティ(たとえば、spdy_enabled、qulc_enabled、upstream_proxy_configuredなど)、行われている要求のタイプ(たとえば、HTTP GET、PUT、POST、TRACE、OPTIONSなど)、要求内のヘッダ情報(たとえば、複数の範囲を有するバイト範囲ヘッダが存在、許可ヘッダが存在など)などを決定し得る。実施形態による動作では、加速可能なトラフィックを識別するように、ユーザエージェントフィールドに特別な値がポピュレートされ得る。追加または代替として、TA制御125の論理は、前述のシグナリング内で提供され、または前述のシグナリングに関連して提供される情報を解析するように動作し得る。たとえば、fileType、priority、streamingBitRate、streamingPlaybackBuffer、およびrequestExpirationTimeなどの、QC-STAヘッダ内で提供される前述のキーのうちの1つまたは複数によって提供される情報が、本明細書の実施形態に従って加速選択のために解析され得る。

1つまたは複数の加速選択属性を取得すると、図示される実施形態のフロー200による動作はブロック204に進み、TA制御125の論理が、TA制御論理によって取得された1つまたは複数の加速選択属性に基づいて、TA120の機能の選択的呼出し(たとえば、トランスポート加速動作を選択的に呼び出す)を制御する。TA制御125の論理の制御下のTA120の機能の選択的呼出しは、トランスポートアクセラレータの論理に、前述の機能を使用してコンテンツサーバからコンテンツを取得させ、またはトランスポートアクセラレータの論理に、前述の機能を迂回してコンテンツサーバからコンテンツを取得させるように動作し得る。たとえば、TA120(具体的にはそのRM121)は、クライアントデバイスへのコンテンツの加速配信を実現するために、コンテンツを求めるユーザエージェントの要求を、コンテンツサーバにコンテンツのチャンクを要求するための複数のチャンク要求に細分することを実現するように動作し得る。トランスポート加速のためのこの要求「チャンキング」機能は、加速選択属性に基づいてTA制御125の論理の制御下で選択的に呼び出され得る(たとえば、RM121および/またはTA120の他の論理を制御可能に迂回することなどによって、迂回され、または迂回されない)。

実施形態に従ってトランスポートアクセラレータの機能が呼び出されるべきかどうかを判定するための、TA制御論理による加速選択属性の解析は、いくつかの一般的規則および/または仮定を利用し得る。たとえば、本明細書の実施形態による動作では、コンテンツ要求が加速されるべきか否かを判定するために、除外リスト規則の1つまたは複数のセットが、TA120の選択的加速ポート内で受信されるコンテンツ要求に適用される。実施形態は、たとえば、ブラックリストに入れられたサーバリスト(たとえば、除外リスト126a)および要求属性除外リスト(たとえば、除外リスト126b)を含み得るような、除外リスト規則の複数のセットを実装する。

本明細書の実施形態に従って利用されるブラックリストに入れられたサーバリストは、何らかの理由で、要求加速が実際的ではなく、または不可能であると判定されたサーバのリストを含み得る。たとえば、UA129aは、TA120によってトランスポート加速動作と互換性がないとすでに判定されており、したがって除外リスト126aのブラックリストに入れられたサーバリスト上に含められている特定のサーバにコンテンツ要求を提供し得る。したがって、フロー200のブロック204における解析/制御論理126の動作は、要求がトランスポート加速機能に提供されるべきではないと判定し得る。ブラックリストに入れられたサーバリストの一例が、以下のTable 6(表6)で与えられる。

そのようなブラックリストに入れられたサーバリストは、(たとえば、Table 6(表6)の「リソース」列によって指定される)特定のリソースに関してブラックリストに入れることを実現し得ることを理解されたい。したがって、他のリソースを求める要求は、普通ならブラックリストに入れられたサーバに対するものであっても、異なるリソースに関するブラックリストに入れられたサーバリスト内にリストされたサーバのために、トランスポート加速機能が拒否されないことがある。Table 6(表6)の「タイマ値」(以下で説明)などの他の情報が、適宜に、または必要に応じて、実施形態に従ってブラックリストに入れられたサーバリスト内に含められ得る。

本明細書による実施形態に従って利用される要求属性除外リストは、コンテンツ要求についてのトランスポート加速の実装に関して決定が行われ得るコンテンツ要求の様々な属性、またはコンテンツ要求に関連する様々な属性を含み得る。以下のTable 7(表7)は、本明細書の実施形態に従って利用され得る要求属性除外リスト(たとえば、除外リスト126b)の一例を与える。この例示的表は、要求の特定のプロトコルタイプ、要求に関連する通信セッションのプロパティ、行われている要求のタイプ、要求内のヘッダ情報を特定し、要求に関連してヘッダ情報が存在する場合、要求は、トランスポート加速動作から除外されるべきである(たとえば、トランスポート加速機能が迂回されるべきである)。

本明細書の除外リスト内の特定のエントリは、いくつかの技法を通じて決定され得る。たとえば、トランスポート加速動作とは非互換であり、あるいはトランスポート加速動作には適していないことが事前に知られているいくつかのリソースについてエントリが作成され得る(たとえば、サフィックス、経路、または領域によるコンテンツファイル、識別情報によるユーザエージェント、識別情報または経路によるコンテンツサーバなど)。追加または代替として、トランスポート加速動作に対する互換性または適合性を経験的に決定するために、コンテンツ転送が監視され得る(たとえば、トランスポートアクセラレータ動作、ネットワーク輻輳、ユーザエージェント動作、ユーザ体験メトリックなどを監視する)。さらに、除外リスト内のエントリについてのリソースが、要求に対する応答などに基づいて、経時的に学習され得る。たとえば、TA制御125の学習論理が、バイト範囲要求についてのサポート/非サポート、禁じられ、または範囲が満たされない応答となる要求などに基づいて、特定のコンテンツサーバおよび/または他のリソースに関する情報で、除外リストおよび/または包含リストのどちらか、または両方をポピュレートするように動作し得る。TA制御125の学習論理の実施形態は、恐らくは監視動作と組み合わせて、コンテンツサーバによって提供される応答コードを解析し、要求にサービスし、どの応答コードがトランスポート加速動作についてのコンテンツサーバ互換性または適合性を示すかを学習するように動作し得る。

図2Bのフローチャートは、1つまたは複数の除外リスト(たとえば、ブラックリストに入れられたサーバリストおよび要求属性除外リスト)に基づくトランスポートアクセラレータ論理の機能の選択的呼出しを実現するための、ブロック204の一実施形態によるTA制御125の動作を示す。図示される実施形態のブロック221において、除外リスト(たとえば、除外リスト126aおよび/または除外リスト126b)が、コンテンツ要求に関して適用される。実施形態による動作では、複数の除外リストが階層的に適用され得る。たとえば、サーバ除外リストは、比較的容易に実装され得、コンテンツ要求がブラックリストに入れられたコンテンツサーバに向けて送られるかどうかを判定するために、ほとんど処理能力を必要としない。したがって、そのような除外リストは、(たとえば、実装するのにより多くの処理能力を必要とし得る要求属性除外リストの前に)階層内の上位で適用され得る。本明細書の除外リストの階層的実装の別の例として、除外リスト(たとえば、上記で示されるTable 7(表7)の除外リストを含み得る)が列ごとに(たとえば、左から右に)適用され、動作を容易にするなどのために、階層的に除外規則が実装され得る。たとえば、文字列探索は、属性合致よりも一般に低速であり、かつ/またはより多くのコンピューティングリソースを利用し、したがって合致が実施形態による除外規則の適用で早期に見つかった場合、「spdy_enabled」などの属性探索が、性能の改善を実現し、かつ/またはリソース利用を低減するために、どんな文字列マッチングよりも前に実施され得る。ブロック222において、除外規則のいずれかが満たされる(たとえば、要求が送られるコンテンツサーバまたは加速選択属性が、除外リスト内のエントリに合致する)かどうかに関して判定が行われる。

除外条件のうちのいずれか1つが満たされる場合、図示される実施形態による処理はブロック224に進み、トランスポート加速機能が迂回される。たとえば、TA制御125の論理は、TA120のルーティングブロックを制御して、要求にトランスポート加速機能を迂回させるように動作し得、好ましくは、そこからのトランスポート加速動作に関して任意のシグナリング(たとえば、前述のQC-STAヘッダ)をストリッピングする。TA120は、トランスポート加速機能が実装されるべきではないと判定したとき、またはその後に、トランスポート加速を実装しないことに関して(たとえば、前述のQC-STA-responseヘッダを使用して)UAにシグナリングを提供し得る。

しかしながら、除外条件のいずれも満たされない場合、図示される実施形態による処理はブロック223に進む。図示される実施形態のブロック223において、トランスポート加速機能が要求に関して実装される。たとえば、TA制御125の論理は、TA120のルーティングブロックを制御して、要求をトランスポート加速機能に提供させように動作し得、好ましくは、そこからのトランスポート加速動作に関して任意のシグナリング(たとえば、前述のQC-STAヘッダ)をストリッピングする。(たとえば、前述のQC-STAヘッダ内に含まれる)前述のシグナリングキーのうちの1つまたは複数によって提供される情報などの、UAからシグナリング内で提供される情報は、UA動作に対して適切なトランスポート加速機能を実装するためにトランスポートアクセラレータによって利用され得る。TA120は、トランスポート加速機能を実装するとき、かつ/またはそれに関連して、トランスポート加速の開始および/または動作に関して(たとえば、前述のQC-STA-responseヘッダを使用して)UAにシグナリングを提供し得る。

コンテンツサーバがトランスポート加速動作をサポートしないと判定される場合(たとえば、上記の例示的条件のいずれも失敗したとき)、実施形態による動作は、除外リスト126aなどの除外リストにコンテンツサーバを動的に追加する(たとえば、(hostname, file_extension)タプルなどの{server, resource}タプルを除外リストに追加する)ように動作する。その後で、前述のように、トランスポート加速機能の選択的実装が、そのようなコンテンツサーバに関して、除外リスト内のその包含に基づいて行われ得る。

トランスポート加速のサポートを示す条件はリソースごとに変化し得るので、実施形態は、除外リスト内のトランスポート加速動作をサポートしないように決定された特定のコンテンツサーバを一時的に含むように動作し得る。たとえば、上記に従って除外リストにコンテンツサーバを追加するとき、実施形態は、除外リスト内のこのエントリについてのタイムスタンプまたはタイマ値(たとえば、上記のTable 6(表6)内の「タイマ値」)にさらに留意し得る。実施形態による動作では、特定のタプルが除外リスト上にある間、そのコンテンツサーバに対する要求は加速されない(すなわち、トランスポート加速機能は迂回される)。しかしながら、除外リストタイマが満了すると、コンテンツサーバに対する要求が(たとえば、それに対して適用されるトランスポート加速制御解析に応じて)加速され得る。

選択された態様が詳細に図示され、説明されたが、以下の特許請求の範囲で定義される本発明の精神および範囲から逸脱することなく、その中で様々な置換および変更が行われ得ることを理解されよう。

110 クライアントデバイス
111 プロセッサ
112 メモリ
113 入力/出力(I/O)要素
114 バス
120 トランスポートアクセラレータ(TA)
121 要求マネージャ(RM)
122 接続マネージャ(CM)
125 トランスポートアクセラレータ(TA)制御
126 解析/制御論理
127 システムフレームワーク
128 リンク
129 ユーザエージェント(UA)
130 サーバ
140 データベース
141 コンテンツファイル
142 コンテンツファイル
143 コンテンツファイル
150 ネットワーク
151 接続
152 接続
161 インターフェース

Claims (30)

1. トランスポート加速要求通信のための方法であって、
   トランスポートアクセラレータ(TA)によって、第1のユーザエージェント(UA)から前記TAの第1の要求加速ポートを介してコンテンツ要求を受信するステップであって、前記コンテンツ要求が、コンテンツサーバによって前記UAに配信されるべきコンテンツデータを求める要求を含む、ステップと、
   前記コンテンツ要求を解析して、前記コンテンツ要求に対してトランスポート加速機能が提供されるべきであることを示すシグナリングを前記コンテンツ要求が含むかどうかを判定するステップと、
   トランスポート加速機能が提供されるべきであることを示すシグナリングを前記コンテンツ要求が含むという判定に少なくとも部分的に基づいて、前記コンテンツ要求に対してトランスポート加速動作を実施するステップであって、前記トランスポート加速動作が、コンテンツを求める複数の要求に前記コンテンツ要求を細分するステップと、前記TAによって前記コンテンツサーバに前記コンテンツを要求することを制御して、前記要求されたコンテンツデータの、前記TAに対する加速配信を実現するステップとを含む、ステップと
   を含む方法。
2. 別のコンテンツ要求に対してトランスポート加速機能が提供されるべきであることを示すシグナリングを前記別のコンテンツ要求が含まないと判定されるとき、トランスポート加速動作を実現することなく、前記TAによって前記コンテンツサーバに対して前記別のコンテンツ要求を渡すステップ
   をさらに含む請求項1に記載の方法。
3. 前記コンテンツ要求を解析して、前記コンテンツ要求に対してトランスポート加速機能が前記TAによって提供されるかどうかを判定するステップであって、前記コンテンツ要求に対してトランスポート加速動作を実施する前記ステップが、前記コンテンツ要求に対してトランスポート加速機能が前記TAによって提供されるという判定にさらに少なくとも部分的に基づく、ステップ
   をさらに含む請求項1に記載の方法。
4. 前記別のコンテンツ要求に対してトランスポート加速機能が提供されるべきであることを示すシグナリングを前記別のコンテンツ要求が含むと判定されるが、前記別のコンテンツ要求について、前記トランスポート加速機能が前記別のコンテンツ要求に対して前記TAによって提供されないと判定されるとき、トランスポート加速動作を実現することなく、前記TAによって前記コンテンツサーバに対して前記別のコンテンツ要求を渡すステップ
   をさらに含む請求項3に記載の方法。
5. 前記コンテンツサーバに対して前記別のコンテンツ要求を渡す前記ステップが、前記別のコンテンツ要求に対してトランスポート加速機能が提供されるべきであるという前記指示をストリッピングするステップを含む請求項4に記載の方法。
6. 前記コンテンツ要求を解析して、トランスポート加速機能が前記TAによって提供されるかどうかを判定する前記ステップが、前記コンテンツ要求の1つまたは複数の属性に規則のセットを適用するステップを含む請求項3に記載の方法。
7. 規則の前記セットが除外リストを含み、前記除外リストが、ブラックリストに入れられたサーバリストまたは要求属性除外リストの少なくとも一方を含む請求項6に記載の方法。
8. 前記除外リストが、所定の階層内で適用される複数のブラックリストを含む請求項7に記載の方法。
9. 前記トランスポート加速機能が提供されるべきであることを示す前記シグナリングが、トランスポート加速動作を実現することに関して前記TAによって利用されるメタデータを含む請求項1に記載の方法。
10. 前記メタデータが、コンテンツを求める前記複数の要求に前記コンテンツ要求を細分する前記ステップにおいて前記TAが利用する情報、コンテンツを求める前記複数の要求をスケジューリングする際に前記TAが利用する情報、前記トランスポート加速機能の実装が前記コンテンツ要求に関して有利であるかどうかを判定するために前記TAが利用する情報、前記トランスポート加速機能の1つまたは複数の側面がどのように実装されるべきかを決定するために前記TAが利用する情報、コンテンツを求める前記複数の要求のうちのコンテンツを求める1つまたは複数の要求を取り消す時刻を決定するために前記TAが利用する情報、コンテンツを求める前記複数の要求のうちのコンテンツを求める1つまたは複数の要求に関して使用するための好ましいネットワークインターフェースを選択するために前記TAが利用する情報、または前記UAによる単一のコンテンツストリームについて前記トランスポートアクセラレータに対する複数の接続をサポートするために前記TAが利用する情報のうちの少なくとも1つを含む請求項9に記載の方法。
11. 前記メタデータが、前記トランスポート加速機能の1つまたは複数の側面がどのように実装されるべきかを決定するために前記TAが利用する前記情報を含み、前記トランスポート加速機能の前記1つまたは複数の側面が、前記複数の要求のチャンクサイズ、前記要求されたコンテンツデータについてのビットレート、および誤り訂正実装からなるグループから選択された側面を含む請求項9に記載の方法。
12. 前記TAが、前記第1の要求加速ポートおよび第2の加速ポートを備え、前記第2の加速ポートが、トランスポート加速を含む1つまたは複数のサービスをUAに提供するシステムフレームワークと通信しており、前記第1の要求加速ポートと通信している前記第1のUAが、前記システムフレームワークを利用しておらず、前記コンテンツ要求に対するトランスポート加速動作を要求するために前記シグナリングを実装する請求項1に記載の方法。
13. 前記トランスポート加速機能が提供されるべきであることを示す前記シグナリングが、トランスポート加速を要求するための所定のヘッダを含み、前記所定のヘッダが、要求されたトランスポート加速の1つまたは複数の属性についての情報を提供する1つまたは複数のキーを含む請求項1に記載の方法。
14. 前記1つまたは複数のキーが、
    fileType、
    requestPriority、
    streamingBitRate、
    streamingPlaybackBuffer、
    requestExpirationTime、
    approxFileSize、
    preferredNetworkInterface、
    fastStartSize、
    useHTTPS、
    uniqueUAinstanceID、
    UAPriority、
    uniqueStreamID、
    streamPriority、
    streamBitRate、
    streamPlaybackBuffer、
    requestSoftExpirationTime、
    requestUniqueID、および
    requestPrerequisites
    からなるグループから選択される請求項13に記載の方法。
15. トランスポート加速動作を実施する前記ステップが、前記1つまたは複数のキー内に含まれる情報の少なくとも一部に従って前記トランスポート加速機能を実装するステップを含む請求項13に記載の方法。
16. トランスポート加速機能が前記コンテンツ要求に対して提供されているか否かを示すシグナリングを前記第1のUAに提供するステップ
    をさらに含む請求項1に記載の方法。
17. トランスポート加速機能が提供されているか否かを示す前記シグナリングが、トランスポート加速を求める要求に応答するための所定のヘッダを含み、前記所定のヘッダが、前記トランスポート加速機能の実装に関する情報を提供する1つまたは複数のキーを含む請求項16に記載の方法。
18. 前記1つまたは複数のキーが、
    requestAccelerated、
    requestEstimatedReceiveRate、
    numberOfSupportedPriorities、および
    usedHTTPS
    からなるグループから選択される請求項17に記載の方法。
19. 前記トランスポート加速動作が、前記コンテンツ要求に対してトランスポート加速機能が提供されるべきであるという前記指示をストリッピングするステップをさらに含む請求項1に記載の方法。
20. トランスポート加速要求通信のための装置であって、
    第1のユーザエージェント(UA)からトランスポートアクセラレータ(TA)の第1の要求加速ポートを介してコンテンツ要求を受信する前記TAのための手段であって、前記コンテンツ要求が、コンテンツサーバによって前記UAに配信されるべきコンテンツデータを求める要求を含む、手段と、
    前記コンテンツ要求を解析して、前記コンテンツ要求に対してトランスポート加速機能が提供されるべきであることを示すシグナリングを前記コンテンツ要求が含むかどうかを判定するための手段と、
    トランスポート加速機能が提供されるべきであることを示すシグナリングを前記コンテンツ要求が含むという判定に少なくとも部分的に基づいて、前記コンテンツ要求に対してトランスポート加速動作を実施するための手段であって、前記トランスポート加速動作が、コンテンツを求める複数の要求に前記コンテンツ要求を細分すること、および前記TAによって前記コンテンツサーバに前記コンテンツを要求することを制御して、前記要求されたコンテンツデータの、前記TAに対する加速配信を実現することを含む、手段と
    を備える装置。
21. トランスポート加速機能が提供されるべきであることを示す前記シグナリングが、トランスポート加速動作を実現することに関して前記TAによって利用されるメタデータを含む請求項20に記載の装置。
22. 前記メタデータが、コンテンツを求める前記複数の要求に前記コンテンツ要求を前記細分する際に前記TAが利用する情報、コンテンツを求める前記複数の要求をスケジューリングする際に前記TAが利用する情報、前記トランスポート加速機能の実装が前記コンテンツ要求に関して有利であるかどうかを判定するために前記TAが利用する情報、前記トランスポート加速機能の1つまたは複数の側面がどのように実装されるべきかを決定するために前記TAが利用する情報、コンテンツを求める前記複数の要求のうちのコンテンツを求める1つまたは複数の要求を取り消す時刻を決定するために前記TAが利用する情報、コンテンツを求める前記複数の要求のうちのコンテンツを求める1つまたは複数の要求に関して使用するための好ましいネットワークインターフェースを選択するために前記TAが利用する情報、または前記UAによる単一のコンテンツストリームについて前記トランスポートアクセラレータに対する複数の接続をサポートするために前記TAが利用する情報のうちの少なくとも1つを含む請求項21に記載の装置。
23. 前記メタデータが、前記トランスポート加速機能の1つまたは複数の側面がどのように実装されるべきかを決定するために前記TAが利用する前記情報を含み、前記トランスポート加速機能の前記1つまたは複数の側面が、前記複数の要求のチャンクサイズ、前記要求されたコンテンツデータについてのビットレート、および誤り訂正実装からなるグループから選択された側面を含む請求項21に記載の装置。
24. 前記TAが、前記第1の要求加速ポートおよび第2の加速ポートを備え、前記第2の加速ポートが、トランスポート加速を含む1つまたは複数のサービスをUAに提供するシステムフレームワークと通信しており、前記第1の要求加速ポートと通信している前記第1のUAが、前記システムフレームワークを利用しておらず、前記コンテンツ要求に対するトランスポート加速動作を要求するために前記シグナリングを実装する請求項20に記載の装置。
25. トランスポート加速要求通信のためのコンピュータ実行可能コードを記憶するコンピュータ可読媒体であって、
    プログラムコードが記録された有形コンピュータ可読媒体であって、前記プログラムコードが、
    トランスポートアクセラレータ(TA)によって、第1のユーザエージェント(UA)から前記TAの第1の要求加速ポートを介してコンテンツ要求を受信するためのプログラムコードであって、前記コンテンツ要求が、コンテンツサーバによって前記UAに配信されるべきコンテンツデータを求める要求を含む、プログラムコードと、
    前記コンテンツ要求を解析して、前記コンテンツ要求に対してトランスポート加速機能が提供されるべきであることを示すシグナリングを前記コンテンツ要求が含むかどうかを判定するためのプログラムコードと、
    トランスポート加速機能が提供されるべきであることを示すシグナリングを前記コンテンツ要求が含むという判定に少なくとも部分的に基づいて、前記コンテンツ要求に対してトランスポート加速動作を実施するためのプログラムコードであって、前記トランスポート加速動作が、コンテンツを求める複数の要求に前記コンテンツ要求を細分すること、および前記TAによって前記コンテンツサーバに前記コンテンツを要求することを制御して、前記要求されたコンテンツデータの、前記TAに対する加速配信を実現することを含む、プログラムコードと
    を含む、有形コンピュータ可読媒体
    を含む非一時的コンピュータ可読媒体。
26. トランスポート加速機能が提供されるべきであることを示す前記シグナリングが、トランスポート加速動作を実現することに関して前記TAによって利用されるメタデータを含む請求項25に記載のコンピュータ可読媒体。
27. 前記メタデータが、コンテンツを求める前記複数の要求に前記コンテンツ要求を前記細分する際に前記TAが利用する情報、コンテンツを求める前記複数の要求をスケジューリングする際に前記TAが利用する情報、前記トランスポート加速機能の実装が前記コンテンツ要求に関して有利であるかどうかを判定するために前記TAが利用する情報、前記トランスポート加速機能の1つまたは複数の側面がどのように実装されるべきかを決定するために前記TAが利用する情報、コンテンツを求める前記複数の要求のうちのコンテンツを求める1つまたは複数の要求を取り消す時刻を決定するために前記TAが利用する情報、コンテンツを求める前記複数の要求のうちのコンテンツを求める1つまたは複数の要求に関して使用するための好ましいネットワークインターフェースを選択するために前記TAが利用する情報、または前記UAによる単一のコンテンツストリームについて前記トランスポートアクセラレータに対する複数の接続をサポートするために前記TAが利用する情報のうちの少なくとも1つを含む請求項26に記載のコンピュータ可読媒体。
28. 前記メタデータが、前記トランスポート加速機能の1つまたは複数の側面がどのように実装されるべきかを決定するために前記TAが利用する前記情報を含み、前記トランスポート加速機能の前記1つまたは複数の側面が、前記複数の要求のチャンクサイズ、前記要求されたコンテンツデータについてのビットレート、および誤り訂正実装からなるグループから選択された側面を含む請求項26に記載のコンピュータ可読媒体。
29. トランスポート加速要求通信のための装置であって、
    少なくとも1つのプロセッサと、
    前記少なくとも1つのプロセッサに結合されたメモリと
    を備え、
    前記少なくとも1つのプロセッサが、
    トランスポートアクセラレータ(TA)によって、第1のユーザエージェント(UA)から前記TAの第1の要求加速ポートを介してコンテンツ要求を受信することであって、前記コンテンツ要求が、コンテンツサーバによって前記UAに配信されるべきコンテンツデータを求める要求を含むこと、
    前記コンテンツ要求を解析して、前記コンテンツ要求に対してトランスポート加速機能が提供されるべきであることを示すシグナリングを前記コンテンツ要求が含むかどうかを判定すること、および
    トランスポート加速機能が提供されるべきであることを示すシグナリングを前記コンテンツ要求が含むという判定に少なくとも部分的に基づいて、前記コンテンツ要求に対してトランスポート加速動作を実施することであって、前記トランスポート加速動作が、コンテンツを求める複数の要求に前記コンテンツ要求を細分すること、および前記TAによって前記コンテンツサーバに前記コンテンツを要求することを制御して、前記要求されたコンテンツデータの、前記TAに対する加速配信を実現することを含むこと
    を行うように構成される装置。
30. トランスポート加速機能が提供されるべきであることを示す前記シグナリングが、トランスポート加速動作を実現することに関して前記TAによって利用されるメタデータを含む請求項29に記載の装置。

Images