JP6178523B2 - 要求マネージャおよび接続マネージャの機能を実装するトランスポートアクセラレータ - Google Patents

要求マネージャおよび接続マネージャの機能を実装するトランスポートアクセラレータ Download PDF

Info

Publication number
JP6178523B2
JP6178523B2 JP2016557585A JP2016557585A JP6178523B2 JP 6178523 B2 JP6178523 B2 JP 6178523B2 JP 2016557585 A JP2016557585 A JP 2016557585A JP 2016557585 A JP2016557585 A JP 2016557585A JP 6178523 B2 JP6178523 B2 JP 6178523B2
Authority
JP
Japan
Prior art keywords
chunk
content
request
size
connections
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
JP2016557585A
Other languages
English (en)
Other versions
JP2017516188A (ja
JP2017516188A5 (ja
Inventor
マイケル・ジョージ・ルビー
ロレンツ・クリストフ・ミンダー
イニアン・マオ
Original Assignee
クアルコム，インコーポレイテッド
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by クアルコム，インコーポレイテッド filed Critical クアルコム，インコーポレイテッド
Publication of JP2017516188A publication Critical patent/JP2017516188A/ja
Publication of JP2017516188A5 publication Critical patent/JP2017516188A5/ja
Application granted granted Critical
Publication of JP6178523B2 publication Critical patent/JP6178523B2/ja
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/14—Session management
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/60—Network streaming of media packets
    • H04L65/61—Network streaming of media packets for supporting one-way streaming services, e.g. Internet radio
    • H04L65/612—Network streaming of media packets for supporting one-way streaming services, e.g. Internet radio for unicast
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/60—Network streaming of media packets
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/60—Network streaming of media packets
    • H04L65/61—Network streaming of media packets for supporting one-way streaming services, e.g. Internet radio
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/80—Responding to QoS
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/02—Protocols based on web technology, e.g. hypertext transfer protocol [HTTP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/10—Protocols in which an application is distributed across nodes in the network

Description

優先権および関連出願の陳述
本出願は、同時係属の、2014年3月18日に出願された「TRANSPORT ACCELERATOR IMPLEMENTING REQUEST MANAGER AND CONNECTION MANAGER FUNCTIONALITY」と題する米国仮特許出願第61/954,970号、および2014年5月28日に出願された「TRANSPORT ACCELERATOR IMPLEMENTING REQUEST MANAGER AND CONNECTION MANAGER FUNCTIONALITY」と題する米国特許出願第14/289,403号の優先権を主張し、これらの開示は、参照により本明細書に組み込まれる。本出願は、同一出願人による、2014年5月28日に出願された「TRANSPORT ACCELERATOR IMPLEMENTING EXTENDED TRANSMISSION CONTROL FUNCTIONALITY」と題する米国特許出願第14/289,016号、2014年5月28日に出願された「TRANSPORT ACCELERATOR IMPLEMENTING EXTENDED TRANSMISSION CONTROL FUNCTIONALITY」と題する出願第14/289,181号、2014年5月28日に出願された「TRANSPORT ACCELERATOR IMPLEMENTING ENHANCED SIGNALING」と題する第14/289,348号、2014年5月28日に出願された「TRANSPORT ACCELERATOR IMPLEMENTING SELECTIVE UTILIZATION OF REDUNDANT ENCODED CONTENT DATA FUNCTIONALITY」と題する第14/289,458号、2014年5月28日に出願された「TRANSPORT ACCELERATOR IMPLEMENTING A MULTIPLE INTERFACE ARCHITECTURE」と題する第14/289,476号、および2014年5月28日に出願された「TRANSPORT ACCELERATOR IMPLEMENTING CLIENT SIDE TRANSMISSION FUNCTIONALITY」と題する第14/289,499号に関係し、これらの各々は、本出願と同時に出願され、これらの開示は、全体が参照により明示的に本明細書に組み込まれる。
ますます多くのコンテンツが、利用可能な通信ネットワークを介して転送されている。多くの場合、コンテンツは、たとえば、オーディオデータ、ビデオデータ、画像データなどを含む、多くのタイプのデータを含む。ビデオコンテンツ、特に高解像度ビデオコンテンツは、しばしば、比較的大きいデータファイルまたは他のデータ集合を含む。したがって、そのようなコンテンツを消費しているエンドユーザデバイスまたは他のクライアントデバイス上のユーザエージェント(UA)はしばしば、所望のビデオコンテンツを含むコンテンツの一連のフラグメントを要求し、受信する。たとえば、UAは、さらなる処理のために、また場合によってはユーザデバイス上での表示のために、データ、多くの場合にマルチメディアデータを要求し、要求したデータを受信する、ユーザデバイス上で実行されているクライアントアプリケーションまたはプロセスを含むことができる。
今日では多くのタイプのアプリケーションが、上記のコンテンツ配信のためにHTTPに依存している。多くのそのようなアプリケーションでは、HTTPトランスポートのパフォーマンスは、アプリケーションによるユーザのエクスペリエンスにとって重要である。たとえば、ライブストリーミングには、ビデオストリーミングクライアントのパフォーマンスを妨げ得るいくつかの制約がある。2つの制約が特に目立つ。第一に、メディアセグメントが経時的に次々に入手可能になる。この制約は、クライアントがデータの大きい部分を連続的にダウンロードすることを妨げ、ひいては、ダウンロードレート推定の精度に影響を与える。大半のストリーミングクライアントは、「要求-ダウンロード-推定」ループで動作するので、一般に、ダウンロード推定が不正確であるときには良好に機能しない。第二に、ライブイベントストリーミングを見ているとき、ユーザは一般に、実際のライブイベントタイムラインからの長い遅延に直面することを望まない。そのような行為は、ストリーミングクライアントが大きいバッファを作り上げるのを妨げ、結果的にさらなるリバッファリングが生じ得る。
3GPP TS.26.346 IETF RFC 5053 IETF RFC 6330
本開示の実施形態に従って、クライアントデバイスのトランスポートアクセラレータ(TA)によって、コンテンツサーバからクライアントデバイスのユーザエージェント(UA)へのコンテンツの配信を加速するための方法が提供される。実施形態の方法は、TAの要求マネージャ(RM)によって、それぞれUAによって提供されたフラグメント要求を、コンテンツのチャンクを要求するための複数のチャンク要求に再分割するステップであって、チャンク要求のコンテンツチャンクのサイズが、コンテンツサーバのネットワーク輻輳回避動作に関係なくネットワーク転送レートを上昇させるように決定される、ステップを含む。実施形態の方法は、RMによってTAの接続マネージャ(CM)に、コンテンツのチャンクを要求するための複数のチャンク要求のチャンク要求を提供するステップと、CMによって、CMとコンテンツサーバとの間で確立された複数の接続を介してコンテンツサーバにコンテンツのチャンクを要求するステップとをさらに含む。
本開示の実施形態に従って、クライアントデバイスのトランスポートアクセラレータ(TA)によって、コンテンツサーバからクライアントデバイスのユーザエージェント(UA)へのコンテンツの配信を加速するように構成された装置が提供される。実施形態の装置は、TAの要求マネージャ(RM)によって、それぞれUAによって提供されたフラグメント要求を、コンテンツのチャンクを要求するための複数のチャンク要求に再分割するための手段であって、チャンク要求のコンテンツチャンクのサイズが、コンテンツサーバのネットワーク輻輳回避動作に関係なくネットワーク転送レートを上昇させるように決定される、手段を含む。実施形態の装置は、RMによってTAの接続マネージャ(CM)に、コンテンツのチャンクを要求するための複数のチャンク要求のチャンク要求を提供するための手段と、CMによって、CMとコンテンツサーバとの間で確立された複数の接続を介してコンテンツサーバにコンテンツのチャンクを要求するための手段とをさらに含む。
本開示の実施形態に従って、クライアントデバイスのトランスポートアクセラレータ(TA)によって、コンテンツサーバからクライアントデバイスのユーザエージェント(UA)へのコンテンツの配信を加速するためのコンピュータプログラム製品が提供される。実施形態のコンピュータプログラム製品は、プログラムコードを記録した非一時的コンピュータ可読媒体を含む。実施形態のプログラムコードは、TAの要求マネージャ(RM)によって、それぞれUAによって提供されたフラグメント要求を、コンテンツのチャンクを要求するための複数のチャンク要求に再分割するためのプログラムコードであって、チャンク要求のコンテンツチャンクのサイズが、コンテンツサーバのネットワーク輻輳回避動作に関係なくネットワーク転送レートを上昇させるように決定される、プログラムコードを含む。実施形態のプログラムコードは、RMによってTAの接続マネージャ(CM)に、コンテンツのチャンクを要求するための複数のチャンク要求のチャンク要求を提供するためのプログラムコードと、CMによって、CMとコンテンツサーバとの間で確立された複数の接続を介してコンテンツサーバにコンテンツのチャンクを要求するためのプログラムコードとをさらに含む。
本開示の実施形態に従って、クライアントデバイスのトランスポートアクセラレータ(TA)によって、コンテンツサーバからクライアントデバイスのユーザエージェント(UA)へのコンテンツの配信を加速するように構成された装置が提供される。実施形態の装置は、少なくとも1つのプロセッサと、少なくとも1つのプロセッサに結合されたメモリとを含む。実施形態の少なくとも1つのプロセッサは、TAの要求マネージャ(RM)によって、それぞれUAによって提供されたフラグメント要求を、コンテンツのチャンクを要求するための複数のチャンク要求に再分割することであって、チャンク要求のコンテンツチャンクのサイズが、コンテンツサーバのネットワーク輻輳回避動作に関係なくネットワーク転送レートを上昇させるように決定される、再分割することを行うように構成される。実施形態の少なくとも1つのプロセッサは、RMによってTAの接続マネージャ(CM)に、コンテンツのチャンクを要求するための複数のチャンク要求のチャンク要求を提供することと、CMによって、CMとコンテンツサーバとの間で確立された複数の接続を介してコンテンツサーバにコンテンツのチャンクを要求することとを行うようにさらに構成される。
本開示の実施形態による、トランスポート加速動作に適合されたシステムを示す図である。 本開示の実施形態による、トランスポートアクセラレータの構成に関して実装され得るような要求マネージャおよび接続マネージャの実施形態に関する詳細を示す図である。 本開示の実施形態による、トランスポートアクセラレータ構成に関する詳細を示す図である。 本開示の実施形態による、要求マネージャおよび接続マネージャの機能を提供するトランスポートアクセラレータの動作を示すフロー図である。 接続においてデータの別のチャンクが要求され得るときを判断するためのしきい値パラメータを採用する接続マネージャの例示的な実施形態を示す図である。 接続マネージャがチャンク要求を即時に行うことが現在可能であるときを判断するためのしきい値パラメータを採用する接続マネージャの例示的な実施形態を示す図である。 本開示の実施形態による、クライアントデバイスのためのコンテンツの転送のために複数のコンテンツサーバに関して使用される複数の接続を利用することを示す図である。 本開示の実施形態による、要求マネージャが複数の接続マネージャとインターフェースされる構成を示す図である。 本開示の実施形態による、ダウンロードチャンクレートディスカウントを示す図である。 本開示の実施形態による、エポックへのチャンク要求の分類を示す図である。 本開示の実施形態による、ダウンロードパイプラインレートディスカウントを示す図である。 本開示の実施形態による、T値選択の結果を示す図である。 本開示の実施形態による、T値選択の結果を示す図である。 本開示の実施形態による、T値選択の結果を示す図である。 本開示の実施形態による、様々なダウンロードチャンクレートおよびダウンロードパイプラインレートの組合せの平均的ギャップを示す図である。 本開示の実施形態による、並べ替え層のための論理を示す図である。 本開示の実施形態による、要求マネージャと接続マネージャとの間のアルゴリズム実行のための高レベル呼出しフローを示す図である。 本開示の実施形態による、要求マネージャと接続マネージャとの間のアルゴリズム実行のための高レベル呼出しフローを示す図である。 本開示の実施形態による、要求マネージャと接続マネージャとの間のアルゴリズム実行のための高レベル呼出しフローを示す図である。 本開示の実施形態による、トランスポートアクセラレータを使用して単一のオリジンサーバに接続する単一のユーザエージェントに関して生成されたグラフを示す図である。 本開示の実施形態による、トランスポートアクセラレータを使用して単一のオリジンサーバに接続する単一のユーザエージェントに関して生成されたグラフを示す図である。 本開示の実施形態による、トランスポートアクセラレータを使用して単一のオリジンサーバに接続する単一のユーザエージェントに関して生成されたグラフを示す図である。
「例示的」という言葉は、「例、事例、または例示として働く」ことを意味するように本明細書において使用される。「例示的」として本明細書で説明するいずれの態様も、必ずしも他の態様よりも好ましいか、または有利であると解釈されるとは限らない。
本説明では、「アプリケーション」という用語は、オブジェクトコード、スクリプト、バイトコード、マークアップ言語ファイル、およびパッチなど、実行可能なコンテンツを有するファイルを含む場合もある。加えて、本明細書で言及される「アプリケーション」は、開封されることが必要な場合があるドキュメント、またはアクセスされる必要がある他のデータファイルなどの、本質的に実行可能ではないファイルを含む場合もある。
本説明において使用する「コンテンツ」という用語は、ビデオ、オーディオ、ビデオとオーディオの組合せを有するデータ、または1つもしくは複数の品質レベル、ビットレート、解像度もしくは他の要素によって決定された品質レベルの他のデータを含む場合がある。コンテンツは、オブジェクトコード、スクリプト、バイトコード、マークアップ言語ファイル、およびパッチなど、実行可能なコンテンツを含む場合もある。加えて、「コンテンツ」は、開封されることが必要な場合があるドキュメント、またはアクセスされる必要がある他のデータファイルなどの、本質的に実行可能でないファイルを含む場合もある。
本説明において使用する「フラグメント」という用語は、ユーザデバイスによって要求されること、および/またはユーザデバイスにおいて受信されることがあるコンテンツの1つまたは複数の部分を指す。
本説明において使用する「ストリーミングコンテンツ」という用語は、コンテンツのリアルタイム転送またはある時間期間におけるコンテンツの転送を可能にする1つまたは複数の規格に従って、サーバデバイスから送られること、およびユーザデバイスにおいて受信されることがあるコンテンツを指す。ストリーミングコンテンツ規格の例としては、デインターリーブされた(または複数の)チャネルをサポートする規格、およびデインターリーブされた(または複数の)チャネルをサポートしない規格がある。
本説明において使用する「構成要素」、「データベース」、「モジュール」、「システム」などの用語は、ハードウェア、ファームウェア、ハードウェアとソフトウェアの組合せ、ソフトウェア、または実行中のソフトウェアのいずれかであるコンピュータ関連エンティティを指すことが意図される。たとえば、構成要素は、限定はされないが、プロセッサ上で実行されているプロセス、プロセッサ、オブジェクト、実行可能ファイル、実行スレッド、プログラム、および/またはコンピュータであってもよい。実例として、コンピューティングデバイス上で実行されているアプリケーションと、コンピューティングデバイスの両方が、構成要素であり得る。1つまたは複数の構成要素は、プロセスおよび/または実行スレッド内に存在する場合があり、構成要素は、1つのコンピュータに局在する場合および/または2つ以上のコンピュータ間に分散される場合がある。加えて、これらの構成要素は、様々なデータ構造を記憶した様々なコンピュータ可読媒体から実行されてもよい。構成要素は、1つまたは複数のデータパケット(たとえば、ローカルシステム、分散システム内の別の構成要素と対話する、および/または、信号によってインターネットなどのネットワークにわたって他のシステムと対話する、1つの構成要素からのデータ)を有する信号に従ってなど、ローカルプロセスおよび/またはリモートプロセスによって通信してもよい。
本明細書で使用する「ユーザ機器」、「ユーザデバイス」、および「クライアントデバイス」という用語は、コンテンツをウェブサーバに要求し、ウェブサーバから受信すること、およびウェブサーバに情報を送信することが可能なデバイスを含む。そのようなデバイスは、静止デバイスまたはモバイルデバイスであり得る。「ユーザ機器」、「ユーザデバイス」、および「クライアントデバイス」という用語は、互換的に使用され得る。
本明細書で使用する「ユーザ」という用語は、ユーザデバイス上またはクライアントデバイス上でコンテンツを受信し、ウェブサイトに情報を送信する個人を指す。
図1Aは、通信ネットワークを介してオーディオデータ、ビデオデータ、画像データ、ファイルデータなどを含み得るようなコンテンツの転送をもたらすように本明細書における概念に従って適合されたシステム100を示す。したがって、クライアントデバイス110は、ネットワーク150を介してサーバ130と通信しているものとして示されており、ネットワーク150によってサーバ130は、本開示の概念に従って、データベース140に記憶された様々なコンテンツをクライアントデバイス110に転送することができる。たった1つのクライアントデバイスと1つのサーバおよびデータベースとが図1Aに表されているが、システム100は複数の任意またはすべてのそのようなデバイスを含み得ることを諒解されたい。たとえば、サーバ130は、サーバファームのサーバを含むことができ、サーバファームでは、コンテンツ転送に対する高レベルの需要に対応するために、複数のサーバが集中的に、かつ/または分散された構成で配置され得る。代替的に、サーバ130がトランスポートアクセラレータ120と同じデバイス上に配置される(たとえば、ネットワーク150を介する代わりに、I/O要素113を介してトランスポートアクセラレータ120に直接接続される)ことがあり、これは、コンテンツの一部または全部が、同じくそのデバイス上に配置されたデータベース140(キャッシュ)に存在し、サーバ130を介してトランスポートアクセラレータ120に提供される場合などにあり得る。同様に、ユーザが複数のクライアントデバイスを持っていることがあり、かつ/または複数のユーザが1つもしくは複数のクライアントデバイスをそれぞれ持っていることがあり、それらのいずれかまたはすべては、本明細書における概念に従ってコンテンツ転送に適合されている。
クライアントデバイス110は、ネットワーク150を介してコンテンツの転送を受信するように動作可能なデバイスの様々な構成を含むことができる。たとえば、クライアントデバイス110は、ワイヤードデバイス、ワイヤレスデバイス、パーソナルコンピューティングデバイス、タブレットコンピューティングデバイスもしくはパッドコンピューティングデバイス、ポータブルセルラー電話、WiFi対応デバイス、Bluetooth（登録商標）対応デバイス、テレビ、ディスプレイを有するメガネ、拡張現実メガネ、または任意の利用可能な方法もしくは基盤を使用してサーバ130と通信することができるネットワーク150に接続された任意の他の通信デバイス、コンピューティングデバイスもしくはインターフェースデバイスを含むことができる。クライアントデバイス110は、サーバ130のクライアントとして機能するデバイスとして機能すること、またはサーバ130のクライアントとして機能するデバイスに接続されることが可能であるので、「クライアントデバイス」と呼ばれる。
図示の実施形態のクライアントデバイス110は、複数の機能ブロックを含み、ここでは、プロセッサ111、メモリ112、および入力/出力(I/O)要素113を含むものとして示されている。簡単にするために図1Aの表現には示されていないが、クライアントデバイス110は、ユーザインターフェース、無線周波数(RF)モジュール、カメラ、センサアレイ、ディスプレイ、ビデオプレーヤ、ブラウザなどのような、追加の機能ブロックを含むことができ、それらの一部または全部は、本明細書における概念に従った動作によって利用され得る。上記の機能ブロックは、バス114のような1つまたは複数のバスを介して動作可能に接続され得る。バス114は、接続された要素、モジュールおよび構成要素が通信し相互動作することを可能にする論理接続および物理接続を含むことができる。
メモリ112は、任意のタイプの揮発性メモリまたは不揮発性メモリであってよく、一実施形態では、フラッシュメモリを含むことができる。メモリ112は、クライアントデバイス110に恒久的に設置されてよく、または取外し可能なメモリカードなど、取外し可能なメモリ要素であってもよい。メモリ112は、単一要素として示されているが、複数の個別のメモリおよび/またはメモリタイプを含むことができる。
メモリ112は、アプリケーション、オペレーティングシステム、ファイル、電子文書、コンテンツなどを形成し得るような、様々なコンピュータ可読コードセグメントを記憶すること、またはさもなければ含むことができる。たとえば、図示の実施形態のメモリ112は、プロセッサ(たとえば、プロセッサ111)によって実行されたときに本明細書で説明するように動作可能な論理回路を提供する、トランスポートアクセラレータ(TA)120およびUA129を定義するコンピュータ可読コードセグメントを含む。メモリ112によって記憶されたコードセグメントは、前述のTA120およびUA129に加えてアプリケーションを提供することができる。たとえば、メモリ112は、本明細書における実施形態に従ってサーバ130からコンテンツにアクセスする際に有用な、ブラウザなどのアプリケーションを記憶することができる。そのようなブラウザは、ウェブコンテンツにアクセスしウェブコンテンツを見るための、またサーバ130がウェブサーバである場合に、接続151および152により、ネットワーク150を介して、サーバ130との間でハイパーテキスト転送プロトコル(HTTP)を介して通信するためのHTTPウェブブラウザなどのウェブブラウザであり得る。一例として、クライアントデバイス110におけるブラウザから、接続151および152により、ネットワーク150を介して、サーバ130にHTTP要求が送られ得る。サーバ130から、接続152および151により、ネットワーク150を介して、クライアントデバイス110におけるブラウザにHTTP応答が送られ得る。
UA129は、コンテンツをサーバ130などのサーバに要求し、かつ/またはそのサーバから受信するように動作可能である。UA129は、たとえば、さらなる処理のために、また場合によってはクライアントデバイス110のディスプレイ上での表示のために、マルチメディアデータなどのデータを要求し、要求したデータを受信する、ブラウザ、DASHクライアント、HTTPライブストリーミング(HLS)クライアントなどのようなクライアントアプリケーションまたはプロセスを含むことができる。たとえば、クライアントデバイス110は、スタンドアロンメディア再生アプリケーションまたはインターネットブラウザにおいて作動するように構成されたブラウザベースのメディアプレーヤなど、メディアを再生するためのUA129を含むコードを実行することができる。実施形態による動作中、UA129は、ストリーミングコンテンツセッション中の様々な時点に転送のためにコンテンツファイルのどのフラグメントまたは一連のフラグメントを要求すべきかを決定する。たとえば、UA129のDASHクライアント構成は、たとえば最近のダウンロード状況に基づいて、各時点にコンテンツのどの表現(たとえば、高解像度表現、中解像度表現、低解像度表現など)からのどのフラグメントを要求すべきかを決定するように動作することができる。同様に、UA129のウェブブラウザ構成は、ウェブページまたはその一部分などについての要求を行うように動作することができる。一般に、UAはHTTP要求を使用してそのようなフラグメントを要求する。
TA120は、所望のコンテンツのフラグメントまたは一連のフラグメント(たとえば、ビデオストリーミング、ファイルダウンロード、ウェブベースのアプリケーション、一般的なウェブページなどをもたらす際に使用され得るような前述のコンテンツフラグメント)の向上した配信をもたらすために、本明細書における概念に従って適合される。実施形態のTA120は、標準化されたTCP伝送プロトコルを実装するHTTP 1.1インターフェースなどの標準インターフェースをサポートするだけである一般的UAまたはレガシーUA(すなわち、TAと対話するように事前設計されていないUA)が、それでもフラグメント要求を実行しているTAを使用することから恩恵を受けるためにそれらの要求を行うことができるように適合される。追加または代替として、実施形態のTA120は、向上したインターフェースの機能を利用するように設計されたUAにさらなる恩恵をもたらすことを促進するための向上したインターフェースを提供する。実施形態のTA120は、標準化されたTCP伝送プロトコルを実装するHTTPインターフェースを介してTCPを使用することなど、既存のコンテンツ転送プロトコルに従ってフラグメント要求を実行するように適合され、それによって、一般的メディアサーバまたはレガシーメディアサーバ(すなわち、TAと対話するように事前設計されていないメディアサーバ)が、UAおよびクライアントデバイスへのフラグメントの向上した配信をもたらす一方で、要求に対応することが可能になる。
上記の向上したフラグメント配信機能を提供するにあたり、本明細書における実施形態のTA120は、本明細書で説明するアーキテクチャの構成要素およびプロトコルを含む。たとえば、図1Aに示す実施形態のTA120は、以下でさらに説明するように、様々な向上したフラグメント配信機能を提供するために協調する要求マネージャ(RM)121および接続マネージャ(CM)122を含む。
アプリケーション、オペレーティングシステム、ファイル、電子文書、コンテンツなどを形成する前述のコードセグメントに加えて、メモリ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と通信する。したがって、UA129は、クライアントデバイス110においてコンテンツ再生環境を確立するためにプロセッサ111によって実行されるコンテンツプレーヤアプリケーションを含むことができる。特定のコンテンツファイルの再生を開始するとき、UA129は、コンテンツ識別子(たとえば、所望のコンテンツの、1つまたは複数のリスト、マニフェスト、構成ファイル、またはメディアセグメントもしくはフラグメント、およびそれらのタイミング境界を識別する他の識別子)を取得するために、サーバ130のコンテンツ配信プラットフォームと通信することができる。メディアセグメントおよびそれらのタイミングに関する情報は、UA129のストリーミングコンテンツ論理によって、コンテンツの再生のためのフラグメントを要求することを制御するために使用される。
サーバ130は、クライアントデバイスに所望のコンテンツを供給するように動作可能な1つまたは複数のシステムを含む。たとえば、サーバ130は、ネットワーク150を介して様々なクライアントデバイスにコンテンツをストリーミングするように動作可能な標準HTTPウェブサーバを含むことができる。サーバ130は、ユーザデバイス110にコンテンツを配信することができる任意のシステムまたは方法を含むコンテンツ配信プラットフォームを含むことができる。コンテンツは、図示の実施形態のデータベース140など、サーバ130と通信する1つまたは複数のデータベースに記憶され得る。データベース140はサーバ130に記憶されてよく、またはサーバ130に通信可能に結合された1つもしくは複数のサーバに記憶されてもよい。データベース140のコンテンツは、様々な形式のデータ、たとえば、ビデオ、オーディオ、ストリーミングテキスト、ならびにサーバ130によってある時間期間にわたってクライアントデバイス110に転送され得る任意の他のコンテンツ、たとえば、ライブウェブキャストコンテンツおよび記憶されたメディアコンテンツを含むことができる。
データベース140は、複数の異なるソースもしくはコンテンツファイルおよび/または特定のコンテンツの複数の異なる表現(たとえば、高解像度表現、中解像度表現、低解像度表現など)を含むことができる。たとえば、コンテンツファイル141は、特定のマルチメディア編集物(multimedia compilation)の高解像度表現、したがって転送されたときに高ビットレート表現を含むことができ、コンテンツファイル142は、その同じ特定のマルチメディア編集物の低解像度表現、したがって転送されたときに低ビットレート表現を含むことができる。追加または代替として、特定のコンテンツの異なる表現は、コンテンツファイル143によって提供され得るような、前方誤り訂正(FEC)表現(たとえば、コンテンツデータの冗長な符号化を含む表現)を含むことができる。ユニフォームリソースロケータ(URL)、ユニフォームリソース識別子(URI)、および/またはユニフォームリソースネーム(URN)が、本明細書における実施形態に従ってこれらのコンテンツファイルのすべてに関連付けられ、したがって、そのようなURL、URIおよび/またはURNは、場合によりバイト範囲などの他の情報とともに、要求されたデータを識別し、要求されたデータにアクセスするために、利用され得る。
ネットワーク150は、ワイヤレスネットワーク、ワイヤードネットワーク、ワイドエリアネットワーク(WAN)、ローカルエリアネットワーク(LAN)、または本明細書で説明するようなコンテンツの転送に適した任意の他のネットワークであり得る。一実施形態では、ネットワーク150は、インターネットの少なくともいくつかの部分を含むことができる。クライアントデバイス110は、ネットワーク接続151によって表されるような双方向接続を介してネットワーク150に接続され得る。代替的に、クライアントデバイス110は、マルチメディアブロードキャストマルチメディアシステム(MBMS)対応ネットワークによって提供されるような単方向接続を介して接続され得る(たとえば、接続151、152およびネットワーク150は、MBMSネットワークを含むことができ、サーバ130はブロードキャストマルチキャストサービスセンター(BM-SC)サーバを含むことができる)。接続はワイヤード接続であってよく、またはワイヤレス接続であってもよい。一実施形態では、接続151は、セルラー4G接続、ワイヤレスフィデリティー(WiFi)接続、Bluetooth（登録商標）接続、または別のワイヤレス接続などのワイヤレス接続であり得る。サーバ130は、ネットワーク接続152によって表されるような双方向接続を介してネットワーク150に接続され得る。サーバ130は、単方向接続(たとえば、3GPP TS.26.346において説明されるプロトコルおよびサービスを使用するMBMSネットワークまたはATSC 3.0ネットワーク)を介してネットワーク150に接続され得る。接続はワイヤード接続であってよく、またはワイヤレス接続であってもよい。
図1Aに示す実施形態のクライアントデバイス110は、本明細書における概念に従って所望のコンテンツのフラグメントまたは一連のフラグメントの向上した配信をもたらすように動作可能なTA120を含む。上記で説明したように、図示の実施形態のTA120は、様々な向上したフラグメント配信機能を提供するために協調するRM121およびCM122を含む。実施形態のUA129とRM121との間のインターフェース124およびRM121とCM122との間のインターフェース123は、HTTP様の接続を提供する。たとえば、上記のインターフェースは、標準HTTPプロトコルを採用すること、ならびに本明細書における実施形態に従って向上したフラグメント配信のいくつかの機能的態様をサポートするための(たとえば、HTTPの場合と同様のシグナリング技法を使用して提供される)追加のシグナリングを含むことができる。
図1Bは、図1Aに示すようなTA120の構成に関して実装され得るようなRM121およびCM122の実施形態に関する詳細を示す。特に、RM121は、要求キュー(RQ)191a〜191c、要求スケジューラ192(要求チャンキングアルゴリズム193を含む)、および並べ替え層194を含むものとして示されている。CM122は、Tvalueマネージャ195、準備計算機196、および要求受信機/モニタ197を含むものとして示されている。図1Bに示すRM121およびCM122の実施形態に関して特定の機能ブロックが示されているが、本明細書で説明する実施形態に従って機能を実行するために、追加または代替の機能ブロックが実装されてよいことを諒解されたい。
RQ191a〜191cは、1つまたは複数のUA(たとえば、UA129)によって、TA120によって受信される要求のキューイングをもたらすために、図1Bに示すRM121の実施形態において提供される。図示の実施形態に示す複数のRQの異なるRQは、様々な要求に関してキューイングをもたらすために利用され得る。たとえば、RQのうちの異なるものはそれぞれ、異なるレベルの要求優先度に関連付けられ得る(たとえば、ライブストリーミングメディア要求が最高優先度を受け取ることがある一方、ストリーミングメディアはより低い優先度を受け取り、ウェブページコンテンツはさらに低い優先度を受け取る)。同様に、RQのうちの異なるものはそれぞれ、異なるUA、異なるタイプのUAなどに関連付けられ得る。3つのそのようなキューが図示の実施形態において表されているが、本明細書における実施形態は任意の数のそのようなRQを含み得ることを諒解されたい。
実施形態の要求スケジューラ192は、本明細書における概念に従ってフラグメント要求および/またはチャンク要求をスケジュールするための1つまたは複数のスケジューリングアルゴリズムを実装する。たとえば、要求スケジューラ192の論理は、RMによって現在要求されているフラグメントについて受信されたか、または要求されたがまだ受信されていないデータの量が何らかのしきい値量を割り込むとき、RMが別のチャンク要求を行うことができる受信済みのフラグメント要求をRMが有していないときなどに基づいて、RMがUAからのフラグメント要求に対する準備ができているかどうかを判断するように動作することができる。追加または代替として、要求スケジューラ192の論理は、現在のネットワーク状態を踏まえて可能な最大ダウンロードレートに近い接続の総ダウンロードレートをもたらすこと、ネットワークにバッファリングされるデータの量ができるだけ小さくなるようにすること、などのためにチャンク要求が行われるべきかどうかを判断するように動作することができる。要求スケジューラ192は、たとえば、RMがUAから新しいデータダウンロード要求を受信したときはいつでも、同じまたは異なるオリジンサーバ向けのさらなる要求を発信する継続的準備についてチェックするためにRMがCMにチャンク要求を無事発信したときはいつでも、すでに発信されたチャンク要求についてデータダウンロードが完了したときはいつでも、などのように、チャンク要求準備についてCMに問い合わせるように動作することができる。
実施形態による動作中、要求スケジューラ192は、次のチャンク要求を発信する次のRQを選択するためのクレジットシステムを(たとえば、RQ191a〜191cの各要求キューに関連する論理クレジットを維持するために)使用することができる。新しいチャンク要求が発信されるごとに、要求スケジューラは、各RQに関連する既存のクレジットに一定量のクレジットを加算すること、ならびに新しいチャンク要求が生成されるRQに関連する既存のクレジットから一定量のクレジットを減算することができる。追加または代替として、実施形態の要求スケジューラ192は、各RQの優先度を、次のチャンク要求が発信される次のRQを選択するときに、考慮することができる。同様に、要求スケジューラ192は、並べ替えバッファのサイズ(たとえば、RQ191a〜191cの各要求キューに関連するチャンク要求への一部または全部の応答からバッファリングされるデータの量)を監視することができ、それによって要求スケジューラは、所与のRQからチャンク要求を発信するのを、並べ替えバッファにおけるそのRQに関連するバッファリングされたデータの量が一定のしきい値を上回るときに、減速または停止するように動作することができる。実施形態の要求スケジューラ192は、バッファリングされたデータの量がしきい値を割り込んだときに、そのRQから通常の要求を発信するのを再開するように動作することができる。
図示の実施形態の要求スケジューラ192は、要求チャンキングアルゴリズム193の形式にフラグメント要求チャンキング機能を含むように示されている。実施形態の要求チャンキングアルゴリズム193は、要求されたフラグメントを、複数の対応するより小さいデータ要求を提供するために再分割するために利用される論理を提供する。「TRANSPORT ACCELERATOR IMPLEMENTING REQUEST MANAGER AND CONNECTION MANAGER FUNCTIONALITY」と題する上記の特許出願は、要求チャンキングアルゴリズム193によって実装され得るような実施形態に従って適切なチャンクサイズを計算することに関するさらなる詳細を提示している。
実施形態の並べ替え層194は、前述のチャンク要求に応答して提供されたチャンクから、要求されたフラグメントを再構成するための論理を提供する。チャンク要求に応答して提供されたデータのチャンクは、順が狂った形でTA120によって受信されることがあり、したがって並べ替え層194の論理は、データを並べ替え、場合によっては欠落データについての要求を行い、それによって、要求側TAに提供するための要求されたデータフラグメントを提供するように動作することができることを諒解されたい。
CM122の図示の実施形態のTvalueマネージャ195は、チャンク要求に関する制御を行う(たとえば、いつチャンク要求が行われるべきかを判断する)ための1つまたは複数のパラメータ(たとえば、しきい値パラメータなど)を決定し、かつ/または管理するための論理を提供する。同様に、CM122の図示の実施形態の準備計算機196は、チャンク要求に関する制御を行う(たとえば、CM122とRM121との間で次のチャンク要求に対する準備をシグナリングする)ための1つまたは複数のパラメータ(たとえば、ダウンロードレートパラメータ)を決定し、かつ/または管理するための論理を提供する。実施形態に従ったそのようなパラメータの計算およびそれらの使用に関する詳細は、「TRANSPORT ACCELERATOR IMPLEMENTING REQUEST MANAGER AND CONNECTION MANAGER FUNCTIONALITY」と題する上記の特許出願において提示されている。
実施形態の要求受信機/モニタ197は、チャンク要求を管理するように動作可能な論理を提供する。たとえば、要求受信機/モニタ197は、RM121からチャンク要求を受信し、1つまたは複数のコンテンツサーバに対して行われたチャンク要求のステータスを監視し、チャンク要求に応答して提供されたデータチャンクを受信するように動作することができる。
実施形態による動作中、図2のフロー200によって示されるように、RM121はUA129からフラグメントについての要求を受信する(ブロック201)。本明細書における実施形態によれば、RM121は、一般的UAまたはレガシーUA(すなわち、RMと対話するように事前設計されていないUA)からフラグメント要求を受信し、フラグメント要求に応答し、それによってそのようなレガシーUAとの互換性をもたらすように適合される。したがって、RM121は、TA120の拡張型伝送プロトコル動作からUA129を隔離するように動作することができる。ただし、以下の記述からより十分に理解されるように、UA129は、拡張型伝送プロトコル動作に適合されてよく、それによってRM121およびUA129は協調して、拡張型伝送プロトコル動作の1つまたは複数の特徴を、そのような特徴を実施するためのRM121とUA129との間のシグナリングの使用などにより実施する。
実施形態による動作中、要求受信機/モニタ197は、各チャンク要求に関連するダウンロード時間および/またはダウンロードレートに関する統計を収集し、そのような統計を使用して、ダウンロードされているチャンク要求があまりにも遅いかどうかを判断することができる。チャンク要求のダウンロードが遅い(たとえば、一定のしきい値よりも遅い)と見なされたとき、要求受信機/モニタ197は、進行が遅いチャンク要求の受信されていない部分についての1つまたは複数のチャンク要求を発信することができる。さらに、要求受信機/モニタ197は、進行が遅いチャンク要求を取り消すことができ、随意に、進行が遅いチャンク要求に使用されている(たとえば、伝送制御プロトコルまたは拡張型伝送プロトコルのいずれかを使用する)下部トランスポート接続を閉じて、新しい接続を開くことができる。
図1Cは、実施形態のトランスポートアクセラレータ構成に関するさらなる詳細を示す。図1Cの例示的な実施形態は、クライアントデバイス110に関するトランスポートアクセラレータのプロキシ動作を容易にするように適合されたTA120の構成を含む。図1Cに示すTA120の実施形態は、本明細書で説明するように、所望のコンテンツについての1つまたは複数のサーバに対して行われるチャンク要求を生成し、要求を管理するように動作可能なRM121およびCM122を含む。その上、図示の実施形態のTA120は、本明細書における概念に従って1つまたは複数のUAに代わるプロキシされたトランスポートアクセラレータ動作を容易にする追加の機能を含む。たとえば、TA120は、UA129a〜129cに対するプロキシサーバインターフェースを提供するプロキシサーバ1021を含むように示されている。図示の実施形態のTA120はまた、UA129dに対するウェブサーバインターフェースを提供するブラウザアダプタ1022を含むように示されており、UA129dは、ブラウザタイプのユーザエージェント(たとえば、ウェブコンテンツにアクセスしてウェブコンテンツを見るための、またウェブサーバとの間でHTTPを介して通信するためのHTTPウェブブラウザ)として示されている。UAに対するプロキシインターフェースを提供する前述の機能ブロックに加えて、図1Cに示すTA120の実施形態は、本明細書における概念に従ってコンテンツのトランスポートの加速を容易にする際に有用な追加の機能ブロックを含むように示されている。特に、TA120は、スタック処理1023、TA要求ディスパッチャ1024、スタック処理1025、およびソケット層1026を含むものとして示されている。TAプロキシ構成の実施形態に関するさらなる詳細が、「TRANSPORT ACCELERATOR IMPLEMENTING A MULTIPLE INTERFACE ARCHITECTURE」と題する上記の特許出願において提示されている。
実施形態のTA120は、UAによって要求されたコンテンツフラグメントよりも通常小さいコンテンツの部分を要求するデータ転送を実施する。したがって、実施形態のRM121は、要求されたフラグメントを、複数の対応するより小さいデータ要求(本明細書では「チャンク要求」と呼び、要求されたデータは「チャンク」を含む)を提供するために再分割する(ブロック202)ように動作する。実施形態のTA120によって要求されるチャンクのサイズは、UA129によって要求されるフラグメントのサイズよりも通常小さい。したがって、UA129からの各フラグメント要求は、そのフラグメントを回復するためにCM122に対する複数のチャンク要求を生成して行うようにRM121をトリガすることができる。そのようなチャンク要求は、フラグメントコンテンツまたはそれのある部分を含むデータオブジェクトの何らかの形式のコンテンツ識別子(たとえば、URL、URI、URNなど)を含み、場合により所望のコンテンツチャンクを含むバイト範囲などの他の情報を伴うことがあり、それによってチャンクが集まって、要求されたフラグメントが提供される。
TA120によって要求されるチャンクのサイズは、いくつかの考慮事項のいずれかに基づき得る。一般に、CM122は、ターゲットチャンクサイズまたはチャンクサイズ選択に関係する情報を決定し、これらをRM121に提供することができ、RM121は、提供されたターゲットチャンクサイズまたはチャンクサイズ選択に関係する情報を使用して、フラグメントが区分される実際のチャンクサイズを決定する。CM122は、ターゲットチャンクサイズまたはチャンクサイズ選択に関係する情報を、CM122が別のチャンク要求に対する準備ができていることをシグナリングするときに、RM121に提供する。したがって、フロー200の図示の実施形態は、CM122によってRM121に提供されたターゲットチャンクサイズまたはチャンクサイズ選択に関係する情報に基づくなどして、ブロック209においてRM121がチャンクサイズを決定することを示している。実施形態のCM122は、要求されるべきチャンクのターゲットサイズを決定し、チャンクサイズ選択に関係する情報を決定するための1つまたは複数のアルゴリズムを実装することができる。そのような実施形態による動作中、CM122は、CMが提供しているトランスポートに適しているチャンク要求のターゲットサイズをRM121にシグナリングすることができ、RMは、UAから受信されたフラグメント要求に基づいてCMに対して行う要求を形成しているときに、その実際のチャンクサイズを決定するために、供給されたターゲットサイズを使用することができる。
チャンクサイズを決定するための動作の一例として、次のチャンク要求が行われ得る所与の接続に関して、CMは、その接続を介してサーバ130が即時に送ることができるデータの量の正確なサイズまたはおおよそのサイズであるWを有し得る(この例におけるチャンクサイズは、フラグメントサイズとは無関係であり、さらにはRMによって使用され得るフラグメント組立アルゴリズムとも無関係であることが諒解されている)。CM122は、たとえば、WおよびCmaxのうちの小さい方によるターゲットチャンク要求サイズなど、次のチャンク要求にとって適切なターゲットチャンクサイズを決定することができ、Cmaxは、所望のチャンクサイズ要求の上限である(たとえば、Cmaxは、チャンク要求のコンテンツチャンクの所定の最大サイズであり得、フラグメントが、最大サイズ以下のサイズを有するチャンク要求に区分される)。このようにして所望のターゲットチャンク要求サイズを設定するための理由は、サーバがその接続を介してこのサイズの要求を受信するとすぐに、サーバがその接続を介して応答全体を即時に送ることができることである。このようにして、サーバに対する要求を行うときにすべてのチャンク要求サイズが選択される場合、およびサーバからCMに送られるすべてのパケットが受信され、順序どおりに受信される場合、CMによって要求されたすべてのデータは、CMが要求を行ったときの、さらにはCMが複数の接続を介してデータを要求しているときの順序で到着する。
しかしながら、特定の状況におけるチャンクサイズの選択は、システムの様々な態様に依存し得るが、それでもチャンクサイズは、要求を行うアップリンクトラフィックの割合が、要求に応答して提供されるダウンリンクトラフィックの量に対して許容できるものとなるように設定され得ることを諒解されたい。CMが要求をパイプライン化する(たとえば、単一のTCP接続でいくつかのHTTP要求をパイプライン化する)場合、比較的小さいチャンクサイズで満足できることがある。そのような場合、CM122の論理は、比較的小さいターゲットチャンクサイズを選択するように動作することができ、それでもターゲットチャンクサイズは、チャンクごとの要求および応答ヘッダオーバーヘッドが法外にならないように十分に大きい。パイプライン化がサポートもしくは許容されていないとき、または限られた量のパイプライン化のみがサポートもしくは許容されるとき、CM122の論理は、より大きいターゲットチャンクサイズを選択するように動作することができ、その理由は、さもなければ、全リンク容量を利用することが可能ではない場合があることである(たとえば、ターゲットチャンクサイズは、使用される接続の数とチャンクサイズとの積が帯域幅遅延積(BDP:bandwidth-delay product)を上回るように選択され得る)。
実施形態によって実装されるチャンクサイズは、データチャンクをトランスポートする際に使用される接続(たとえば、TCP接続)の輻輳ウィンドウに比例して、または輻輳ウィンドウよりも少なくとも小さくなるように選択されるのが理想であり得る。しかしながら、実施形態のTA120は、受信側(たとえば、クライアントデバイス110)において実装され、したがって一般的には、輻輳ウィンドウ情報を有しない。それでもTA120の論理は、特定の接続に関して輻輳ウィンドウの近似値を決定するように動作し得る。たとえば、実施形態のTA120は、サーバ130が直面する接続の輻輳ウィンドウを推定するために、受信側において、TCP送信側行為をシミュレートするように動作し得る。
以下では、本明細書における実施形態の、CM122およびRM121の論理によって実装され得るような、チャンクサイズを計算するための例示的な技法を提供する。CM122は、本技法に従って、RM121にチャンクサイズ選択に関係する以下の情報を提供することができる。
Figure 0006178523
チャンクサイズ選択に関係するこの情報に基づいて、RM121は、サイズFのフラグメントを区分するために、チャンクの数Pを決定することができ、それによってフラグメントは、(たとえば、IETF RFC 5053またはIETF RFC 6330に指定された区分関数を使用して)できるだけ等しいサイズのP個のチャンクに区分され、次いで計算され得る。たとえば、RM121は、以下に示すように上記のパラメータを使用してチャンクサイズを計算することができる。
Pmax=max{1,floor(F/Cmin)}
Pmin=max{1,floor(F/Cmax)}
P=max{Pmin,min{Pmax,N}}(すなわち、P=min{Pmax,max{Pmin,N}})
チャンクサイズを決定するための上記の技法は、FがP個の等しいサイズのチャンクに分割されるときに、最小チャンクサイズが少なくともmin{F,Cmin}になるようにする。そのような技法を使用して計算されたチャンクサイズは、CMがパイプライン化(たとえば、HTTPパイプライン化)を最大限使用し得る状況において使用するのに特に好適である。
CMがパイプライン化を使用することができないとき、実施形態に従って、チャンクサイズを計算する異なる方法が利用され得る。たとえば、CM122は、たとえばCM122がRM121に、CMが別のチャンク要求に対する準備ができていることをシグナリングするときに、ターゲットチャンクサイズTを動的に決定し、TをRM121に提供することができる。各時点のTの値は、現在のネットワーク状態、現在のダウンロード速度、および本明細書の他の箇所で説明する他のメトリクスを含む、いくつかの要素に基づき得る。
RM121は、実施形態のCM122から受信されたTの値を使用して、下に示すように次の要求のチャンクサイズを計算することができ、Nは、RM121が次のチャンク要求を生成すべきフラグメントにおける要求されていないバイトの数である。
ChunkSize:=min(N,T)
実施形態による動作中、すべてのチャンクを同じサイズにすることが望まれてはいないことがある。たとえば、実施形態は、サーバに要求を最初に送るときに、より小さいチャンクサイズを利用し、経時的に、チャンク要求のサイズを拡大することができる(たとえば、接続の輻輳ウィンドウは通常、経時的に拡大するので、チャンクサイズはこの予想に従って拡大され得る)。より小さいチャンクサイズを最初に使用することによって、TA120は、ストリーミングセッションの最初にデータ転送に対する所望の応答性を経験し、その後、チャンクサイズを拡大することによって、アップリンク帯域幅利用とダウンリンク帯域幅利用との間のより良いトレードオフを得ることができる。
すべて同じサイズのチャンクの使用も同様に望ましくないことがあり、その理由は、そのような均一のチャンクサイズの使用により、TAとサーバとの間のすべての接続が同時にアイドル状態になり、それによって非効率的なチャネル使用が生じ得ることである。その上、(たとえば、Nが小さいことに起因して)極めて小さいチャンクが要求される状況では、以前のチャンク要求がより大きいことが望まれ得る。以下の技法は、RM122によってチャンクサイズを計算するために以下のパラメータを使用して上記の考慮事項に対処するように適合されている。
Figure 0006178523
チャンクサイズはRM122によって、以下に示すように上記パラメータを使用して計算され得る。
P=T*(1+A*revbits(I)/232)
P*X>Nの場合、ChunkSize:=Pを設定する
それ以外の場合、ChunkSize:=Nを設定する
I=(I+1)mod232
上記の計算において、revbits(I)は、Iが32ビット値として表されるときに生成される値であり、Iの32ビットは逆順で記載され、次いで、反転された32ビットが整数値として扱われる。たとえば、I=7の場合、32ビット値として表されるIは00000000000000000000000000000111であり、したがってrevbits(I)は11100000000000000000000000000000の整数値であり、これは3,758,096,384であるので、revbits(7)/232=0.875である。本明細書における実施形態に従って行われ得るようなチャンクサイズ決定は、1つまたは複数のコンテンツ転送セッション(たとえば、ストリーミングメディアセッション)に対して事前に、コンテンツ転送セッションの開始と同時に、1つまたは複数のコンテンツ転送セッション中に動的になど、およびそれらの組合せで実行され得ることを諒解されたい。したがって、図2のブロック209において実行されるようにチャンクサイズを決定することは、フロー200に表される他の動作に関する様々な時間に、上記の技法のうちの1つまたは複数を実施することなどによって、実行され得る。
その上、実施形態について、本明細書ではチャンクサイズ決定を行うためのCM122およびRM121の論理の相互運用性に関して説明しているが、実施形態は、チャンクサイズ決定のための他の論理を利用してもよい。たとえば、実施形態は、CM122内でのみ、もしくはRM121内でのみチャンクサイズを決定すること、またはチャンクサイズを決定するために他のモジュールもしくは論理もしくは情報を使用することがある。たとえば、RM121は、様々なチャンク要求のチャンクサイズを動的に決定するために、CM122によって提供され得るようなダウンロード統計を利用し得る。
チャンクサイズ決定のタイミングおよび決定を行うための論理が配置され得る場所に関係なく、実施形態のRM121は、要求されたフラグメントを確実に受信し回復するために、CM122にどのデータを要求すべきかを決定するように動作する。したがって、実施形態のRM121は随時、UA129によって行われた1つまたは複数のフラグメント要求に関連し得るような1つまたは複数の選択されたチャンク要求をCM122に提供する(図2のブロック203)。
実施形態による動作中、RM121は、CM122からの、CMが次のチャンク要求を行う準備ができていることを示すチャンク準備シグナリングを受信し得る。たとえば、TA120(たとえば、CM122)は、図示の実施形態のブロック210によって示されるように、チャンク要求に関する制御を行う(たとえば、いつチャンク要求が行われるべきかを判断する、および/またはCM122とRM121との間で次のチャンク要求に対する準備をシグナリングする)ための1つまたは複数のパラメータ(たとえば、ダウンロードレートパラメータ、しきい値パラメータなど)を決定するための論理を実装することができる。実施形態に従ったそのようなパラメータの計算およびそれらの使用に関する詳細は、以下で提示する。
RM121によってCM122に対して行われたチャンク要求の一部は、すでに要求されたがまだ到着していないデータ、および決して到着しない可能性またはあまりにも遅く到着する可能性があるとRM121が判断したデータについてのものであり得る。追加または代替として、RM121によってCM122に対して行われたチャンク要求の一部は、元のフラグメントから生成されたFEC符号化されたデータについてのものであることがあり、それによってRM121は、CM122から受信されたデータをFEC復号して、フラグメントまたはそれのある部分を回復することができる。RM121は、回復されたフラグメントをUA129に配信する。したがって、FECデータを使用せず、したがって元のソースフラグメントからのデータのいくつかの部分を要求するだけである基本RM構成(RM-基本)、および元のソースフラグメントからのデータのいくつかの部分を要求することのほか、ソースフラグメントから生成されたFECフラグメントをマッチングすることもできるFEC RM構成(RM-FEC)を含み得るような、本発明の実施形態によるRMの様々な構成があり得る。
実施形態のRM121は、タイミングおよび/または帯域幅利用可能性の制約を認識していないことがあり、それによって、RM121とCM122との間の比較的単純なインターフェースを円滑にすることができ、したがってRM121は、RM121によるそのような制約の考慮なしに、チャンク要求を行うように動作し得る。代替的に、RM121は、CM122またはクライアントデバイス110内の他のモジュールによってRM121にもたらされ得るような、タイミングおよび/または帯域幅利用可能性の制約を認識するように適合され得、したがってRM121は、そのような制約に基づいてチャンク要求を行うように動作し得る。
実施形態のRM121は、複数の異なるCM構成による動作に適合される。その上、いくつかの実施形態のRM121は、複数のCMに同じフラグメントまたは一連のフラグメントのデータチャンクを要求するなどのために、2つ以上のCMと同時にインターフェースすることができる。そのような各CMは、たとえば、異なるネットワークインターフェースをサポートすることができる(たとえば、第1のCMは、オンデバイスキャッシュへのローカルインターフェースを有することができ、第2のCMは、3GネットワークインターフェースへのHTTP/TCP接続を使用することができ、第3のCMは、4G/LTEネットワークインターフェースへのHTTP/TCP接続を使用することができ、第4のCMは、WiFiネットワークインターフェースへのHTTP/TCP接続を使用することができる、など)。
実施形態による動作中、CM122は、RM121とインターフェースしてチャンク要求を受信し、それらの要求をネットワーク150を介して送る(図2のブロック204)。CM122は、チャンク要求への応答を受信し(ブロック205)、応答をRM121に戻し(ブロック206)、ここにおいて、UA129によって要求されたフラグメントは、RM121によって受信されたチャンクから解決され(ブロック207)、UA129に提供される(ブロック208)。CM122の機能は、RM121によって行われたチャンク要求のデータをいつ要求するかを決定するように動作する。本明細書における実施形態によれば、CM122は、チャンクを一般的サーバまたはレガシーサーバ(すなわち、CMと対話するように事前設計されていないサーバ)に要求し、当該サーバから受信するように適合される。たとえば、CM122がデータを要求する際の要求先のサーバは、標準HTTPウェブサーバを含むことがある。代替的に、CM122がデータを受信する際の送信元のサーバは、MBMSサービス展開において使用されるBM-SCサーバを含むことがある。
上記で説明したRM121の場合と同様に、本発明の実施形態によるCMの様々な構成があり得る。たとえば、複数接続CM構成(たとえば、CM-mHTTP)が提供されることがあり、それによってCMが、複数のTCP接続を介してHTTPを使用するように適合される。複数接続CM構成は、たとえば、ネットワーク状態、データに対する需要、輻輳ウィンドウなどに応じて、接続(たとえば、TCP接続)の数を動的に変えるように動作することができる。別の例として、拡張型伝送プロトコルCM構成(たとえば、CM-xTCP)が提供されることがあり、ここにおいてCMは、(本明細書ではxTCPと呼ばれる)TCP接続の拡張された形式の上にHTTPを使用する。そのような拡張型伝送プロトコルは、本明細書における概念に従ってTA120によるフラグメントの向上した配信を促進するように適合された動作をもたらすことができる。たとえば、xTCPの実施形態は、(パケットが失われているときのTCPの重複確認応答方式とは対照的に)送られたパケットが失われているときでも、サーバに確認応答を戻す。そのようなxTCPデータパケット確認応答方式は、TA120によって、データパケットが欠落していると判断したことに応答してデータパケットが送信されるレートをサーバが低下させるのを回避するために利用され得る。さらに別の例として、専有プロトコルCM構成(たとえば、CM-rUDP)では、CMは、専有ユーザデータグラムプロトコル(UDP)プロトコルを使用し、サーバから応答データを送るレートは、一定の事前設定されたレートであってよく、またはネットワークを望ましくない形で輻輳させることなく送信レートができるだけ高くなるようにするレート管理がプロトコル内にあり得る。そのような専有プロトコルCMは、専有プロトコルをサポートする専有サーバと協調して動作することができる。
図示の実施形態について、サーバ130にソースファイルからのデータを要求しているCM122に関して述べてきたが、データにアクセスするためにCMが有するインターフェースのタイプに応じて、ソースファイルがサーバ上で入手可能であり得るか、またはクライアントデバイス上でローカルに記憶され得ることを諒解されたい。いくつかの実施形態では、マッチするソースファイルからFEC符号化を使用して生成された修復シンボルを含むFECファイルが、サーバ上で入手可能なこともある。そのような実施形態では、たとえば、ソースファイルごとに1つのFECファイルがあり得、各FECファイルは、データを要求するために使用されるCMの特定の実施形態とは無関係に、当技術分野で知られているFEC符号化技法を使用してソースファイルから生成される。
さらに、実施形態によれば、クライアントデバイス110は、(たとえば、WiFiまたはBluetooth（登録商標）インターフェースを介して)本明細書ではヘルパーデバイスと呼ばれる1つまたは複数の他のデバイス(たとえば、近くに配置された様々な構成のデバイス)に接続することが可能であり得、そのようなヘルパーデバイスは、3GまたはLTE接続を介した、場合によってはヘルパーデバイスごとに異なるキャリアを介した、サーバ130などの1つまたは複数のサーバへの接続を有し得る。したがって、クライアントデバイス110は、サーバ130などの1つまたは複数のサーバにチャンク要求を送るために、ヘルパーデバイスの接続を使用することが可能であり得る。この場合、ヘルパーデバイスの各々に接続し、チャンク要求を送り、応答を受信するCMがTA120内にあり得る。そのような実施形態では、ヘルパーデバイスは、同じフラグメントについての異なるチャンク要求を同じまたは異なるサーバに送ることができる(たとえば、同じフラグメントは、複数のサーバ上でヘルパーデバイスが入手可能であり得、その場合に、たとえば、異なるサーバが、同じまたは異なるコンテンツ配信ネットワーク事業者によって提供される)。
複数のチャンクとしてコンテンツの所望のフラグメントを転送するために、データオブジェクト識別子(たとえば、URL、URI、URNなど)およびチャンクコンテンツについてのデータオブジェクト内のバイト範囲を使用するなどして、複数のチャンク要求が行われる実施形態について上記で説明した。しかしながら、コンテンツサーバ(たとえば、サーバ130)構成によっては、そのようなバイト範囲要求をサポートしないものもあり、したがって、バイト範囲のコンテンツのチャンクではなくデータオブジェクト全体を、チャンク要求に応答して戻すように動作することがある。したがって、それでも複数のチャンク要求が行われた場合、データオブジェクト全体の複数のインスタンスがクライアントデバイスに転送される。本明細書におけるトランスポートアクセラレータの実施形態は、コンテンツのソースとして動作しているサーバによってバイト範囲要求がサポートされるかどうかを検出するように動作する。たとえば、実施形態のTA120は、最初にHTTPバイト範囲要求を発信し、応答コードを分析して、バイト範囲要求がサポートされるかどうかを判断することができる(たとえば、206応答コードを受信することが、バイト範囲要求がサポートされると判断するために利用され得、200応答コードを受信することが、バイト範囲要求がサポートされないと判断するために利用され得る)。バイト範囲要求がサポートされると判断された(たとえば、ホスト(オリジン)サーバに送られた1つまたは複数のチャンク要求に応答してHTTP206が受信された)場合、TA120はそれの論理を続行して、フラグメント要求を、そのホストサーバに送るためにチャンク要求に区分することができる。一方、バイト範囲要求がホストサーバによってサポートされないと判断された(たとえば、ホスト(オリジン)サーバに送られた1つまたは複数のチャンク要求に応答してHTTP200が受信された)場合、TA120は、そのホストサーバに送られたバイト範囲を指定したすべての残存要求を取り消すことができる。サーバがバイト範囲要求をサポートしない(たとえば、サーバはHTTP 1.1準拠ではない)と判断された場合、TA120は、同じデータオブジェクトの複数のインスタンスが転送されることになる複数のチャンク要求の使用を回避するために、それの動作を変更するように動作することができる。たとえば、RM121は、CM122にデータオブジェクト全体(たとえば、コンテンツファイル)についての要求を行い、それによってCM122は相応して、サーバ130にファイル全体を要求する。そのような動作は、チャンク要求がサポートされるトランスポートアクセラレータ動作と比較して最適なパフォーマンスをもたらさないことがあるが、コンテンツサーバがバイト範囲要求をサポートしない状況では、そのような動作は、コンテンツの二重の転送を回避する。
バイト範囲要求がサポートされる場合でも、様々なクライアントデバイスおよび/またはサーバの構成に起因して最適なパフォーマンスが生じないことがあることを諒解されたい。たとえば、CM122によってサーバ130に対して行われるチャンク要求のサイズは、極めて小さいことがあり、そのようなチャンク要求が行われる接続に関して実装される通信プロトコルは、ネットワークを介して送られるパケットの数を減らすことによってネットワーク効率を改善するためのいくつかの技法を実装し得る。そのような技法は、本明細書におけるチャンク要求に、望ましくない形で影響(たとえば、遅延)をもたらすことがある。たとえば、Nagleアルゴリズムは、いくつかの小さい発信メッセージを組み合わせ、それらをすべて一度に送るようにTCP接続に関して実装され得る(たとえば、送信側が確認応答を受信していない送信済みパケットがある限り、送信側は、出力が一緒に送られ得るように、パケット全体分の出力を有するまで、それの出力をバッファリングし続けることがある)。Nagleアルゴリズムの動作は、一般にネットワーク効率を改善するが、チャンク要求を遅延させることがある。チャンク要求のそのような遅延は、たとえば、ストリーミングコンテンツの失速、ライブストリーミングの許されない遅延などをもたらすことによって、許容できないユーザエクスペリエンスを生じさせることがある。したがって、実施形態は、ネットワークを介して送られるパケットの数を減らすように動作するNagleアルゴリズムなどのネットワーク効率技法を無効化するように動作する。
バイト範囲要求がコンテンツサーバによってサポートされる場合でも、クライアントデバイスは、コンテンツファイルのサイズおよび/または要求されるべきフラグメントのサイズに関する情報を有しないことがある。しかしながら、本明細書における実施形態によるトランスポート加速の利点を提供するために、実施形態のTA120の動作は、上記で説明したようにコンテンツのチャンクについての要求を行う。コンテンツファイル、ひいてはそれのフラグメントのサイズに関する情報を取得するために、TA120は、最初に1つまたは複数の小さいチャンク要求(たとえば、16KBの要求)を行うように動作することができ、それによって、それらの要求に対する応答は、サーバからの実際のコンテンツサイズを含むことになる。TA120の論理(たとえば、RM121および/またはCM122の論理)は、その後、その情報を使用して、フラグメントをチャンクに分割する方法および残存要求をスケジュールする方法を決定することができる。実施形態のTA120は、コンテンツファイルのサイズが知られていないときに、上記の方法と同様の代替方法で動作することができる。たとえば、TA120が既知のサイズのコンテンツファイルの場合に複数のチャンク要求を行うのであれば、TA120は、第1のチャンク要求の時点でコンテンツファイルのサイズが知られていないときに、同様の数のチャンク要求を同様の要求タイミングで行うことができる。フラグメントサイズが知られていない場合、RM121は、サイズが含まれるチャンク要求からの応答を受信するまで、フラグメントサイズが無限大(または無限)であると仮定することができる。この実施形態により、フラグメントの終わりを越えるフラグメントのバイト範囲についてのチャンク要求が生じる可能性がある。したがって、実施形態によれば、バイト範囲要求をサポートするサーバからのチャンク要求に対する応答は、以下のとおりであり得る。(a)要求されたバイト範囲とフラグメントの実際のバイト範囲との間に完全な重複がある場合、HTTP206OK応答であり、したがって、応答してサーバからチャンク要求のバイト範囲が返される、(b)チャンク要求における要求されたバイト範囲とフラグメントの実際のバイト範囲との間に重複がない場合、HTTP404エラー応答であり、応答してサーバによってフラグメントのバイトが提供されることはない。(c)チャンク要求におけるバイト範囲とフラグメントのバイト範囲との間に部分的重複があることを示すHTTP応答であり、応答してサーバから、チャンク要求のバイト範囲とフラグメントのバイト範囲との間の重複が返される。これらの場合の一部または全部では、応答は、フラグメントのサイズも含む。応答のいずれかにおいて受信されたこの情報に基づいて、RM121は、さらなる応答または処理のために、フラグメントの実際のサイズを設定することができる。
上記のことから、実施形態のRM121は、未知のサイズのフラグメントのチャンク要求に対する考えられる応答を適切に処理するように適合されることが諒解され得る。たとえば、エラーコードまたは警告を伴うHTTP応答は、RM121によってシームレスに処理されるべきであり、その理由は、応答して実際のフラグメントサイズをRMが取得したときにRMが判断し得るように、これらの応答は当然ながらフラグメントの無効または部分的に無効なバイト範囲を要求したためだとRMが判断し得ることにある。
未知のサイズのフラグメントを処理するための上記の技法は、たいていの状況において良好に機能し得る。たとえば、フラグメントは、HTTPプログレッシブダウンロードストリーミングの場合に単一のRTTにおいて要求されるものよりもはるかに長くなる可能性が高く、したがって、フラグメントのサイズは、チャンク要求においてフラグメント全体が要求される前に応答して取得されることになるので、一般に、フラグメントサイズが知られる前に行われたチャンク要求におけるバイト範囲のすべては、有効なバイト範囲となる。同様に、DASHストリーミングの場合、フラグメントの再生時間は、持続時間においていくつかのRTTとなる可能性が高く、したがって、ダウンロードレートが現在の再生レートを大幅に上回る場合を除いて同じ分析が有効であり、前記の場合には、フラグメントの重複のないバイト範囲を伴って送られたいくつかのチャンク要求があり得るが、これは通常、選択された再生がダウンロードレートを大幅に下回るときに発生し、その場合にフラグメントの重複のないバイト範囲を伴ってチャンク要求を行うことの影響は、大幅に低減される。
したがって、トランスポートアクセラレータは、チャンク要求を最適に実施するには不十分な情報が利用可能な場合でも、コンテンツを即時に要求し、後で、チャンクサイズを決定し、適切なチャンク要求をスケジュールするために利用可能な情報を使用するように動作可能であり得る。
上記で説明したように、複数接続CM構成(たとえば、CM-mHTTP)が提供され得、それによってCMが、本明細書における概念に従ってコンテンツを1つまたは複数のコンテンツサーバに要求し、当該コンテンツサーバから受信するために複数の接続を使用するように適合される。複数の接続が使用中である場合、互いに公平になるように(たとえば、接続のダウンロードレートが、2倍以内など、互いに合理的に近いところにとどまるようにするために)異なる接続をCMが強制する方法に関する公平性の側面が生じる。
複数の接続に関して公平性のレベルを提供するための比較的単純な技法は、CMが接続の各々の受信ウィンドウサイズを制御する実装を含む。たとえば、CM122は、すべてのTCP接続の受信ウィンドウサイズを等しく、かつ、利用可能帯域幅がTCP接続によってほぼ完全に利用され得るほど十分に大きく、ただし、一部のTCP接続が時には他のTCP接続よりもはるかに速くダウンロードするほど大きくならないように、設定することができる。そのような実装形態は、そのような各TCP接続について、ほぼ等しいダウンロードレートを達成することができる。
受信ウィンドウサイズを制御することを回避する、複数の接続に関して公平性をもたらすための代替技法は、各接続を介して要求されたがまだ配信されていないデータの量を制御するように適合された実装を含む。この技法の目的は、接続がほぼ同じレートでダウンロードするように、またネットワークにおいてバッファリングされるデータの量を減らすように、接続の総ダウンロードレートを上げることである。この技法を実装する実施形態は、複数の接続のうちの特定の接続においてデータの別のチャンクがいつ要求されるべきかを決定するために、1つまたは複数のしきい値パラメータを利用する。実施形態に従って、複数の接続の各接続に関して、上記のしきい値パラメータの同じ値が利用され得る。代替実施形態は、所望される場合、1つまたは複数の接続に関して、上記のしきい値パラメータの異なる値を利用することができる。
各接続を介して要求されたがまだ配信されていないデータの量を制御する接続公平性実装の実施形態に従って、しきい値パラメータThreshが、いくつかのオクテットとなるように定義され、その値をCMが制御し、Threshは、接続においてデータの別のチャンクが要求され得るときを判断するために使用される。たとえば、TCP接続において要求されたがまだ受信されていないデータの量がThreshを下回るとき、その接続において別のデータチャンク要求が行われ得る。一方、TCP接続において要求されたがまだ受信されていないデータの量がThresh以上であるとき、そのTCP接続において別のデータチャンク要求は行われない。
図3は、接続においてデータの別のチャンクが要求され得るときを判断するためのしきい値パラメータThreshを採用する実施形態による動作を示す。図示の例では、現在の要求すべてについての受信予定の残されたデータの量がThreshを割り込んだときに、CMが特定の接続において別のチャンク要求に対する準備ができていると仮定される。たとえば、CM122は、上記のCM-mHTTP構成を含むことができ、図3に示すように3つのTCP接続を利用していることがあり、ここにおいて、CMは、3つの接続すべてにおいてデータについてのHTTPチャンク要求をすでに行っており、その結果、3つのTCP接続の各々において受信される予定の残存データの量が、依然としてしきい値量Threshを上回っている。このシナリオでは、CMは現在、これら3つの接続のいずれにおいてもそれ以上のHTTP要求を行うことができない。したがって、CMがRMから別のチャンク要求を受信したとしても、CMはそのチャンクについての要求を即時に行うことができないので、CMは、RMからの別のチャンク要求に対する準備ができていない。
図4は、CMがチャンク要求を即時に行うことが現在可能であるときを判断するためのしきい値パラメータThreshを採用する実施形態による動作を示す。この例でも、現在の要求すべてについての受信予定の残されたデータの量がしきい値量Threshを割り込んだときに、CM122が特定の接続において別のチャンク要求に対する準備ができていると仮定される。図4の例では、接続のうちの少なくとも1つ(たとえば、TCP接続2およびTCP接続3)において十分なデータが受信されており、その結果、別の要求を行うことができる。
しきい値パラメータThreshの値の選択の目的は、接続の総ダウンロードレートが現在のネットワーク状態で可能な最大ダウンロードレートの近くになるほど値を十分に大きくする一方で、同時に、異なる接続がほぼ同じレートでデータをダウンロードするように値をできるだけ小さくし、ネットワークにバッファリングされるデータの量ができるだけ小さくなるように、値を選択することである。Threshの値は、個々のTCP接続においてHTTPパイプライン化が使用されるときに、本明細書で説明する方法に基づいて動的に決定され得る。チャンクサイズCをできるだけ小さくなるように選択することは、上記を容易にする。しかしながら、前に説明したように、チャンクサイズは、チャンクを要求するオーバーヘッドが、チャンク応答を受信するために使用されるダウンロード帯域幅のごく一部になるほど十分に大きいものであるべきである。たとえば、Cが8KBに設定され、HTTP要求が200バイトのサイズを有する場合、Cのこの値に対するチャンク要求の相対オーバーヘッドは約2.5%である。これは、TCP確認応答トラフィックが通常はTCPダウンロードトラフィックの数パーセントであることを踏まえると、妥当なトレードオフである。
パイプライン化が実施されていないとき、上で説明したような上記のしきい値パラメータの直接使用は問題となるが、それでも、本明細書における接続公平性をもたらすために、しきい値ベースのアルゴリズムが実施され得ることを諒解されたい。たとえば、固定数N個のTCP接続が使用されている場合に、各チャンク要求がサイズThreshを有する場合、ネットワーク上の残存バイトの総量は、せいぜいN*Threshとなる。したがって、サーバへのリンクの帯域幅遅延積が大きい場合に、Threshの大きい値が望ましいことがある一方、帯域幅遅延積が大きくない場合に、Threshの小さい値が好ましいことがある。そのような実装形態では、トレードオフは概して、上述したパイプライン化される場合と同じである(すなわち、しきい値パラメータThreshの値は、できるだけ最大に近いレートでデータを受信することを可能にするほど十分に大きく、一方でネットワーク上での不要なバッファリングを回避するほど十分に小さいものであるべきである)ことを諒解されたい。ただし、パイプライン化される場合と比較して、パイプライン化されない例におけるしきい値パラメータThreshの値は、約N/2〜N倍だけ小さくなるべきである。
本明細書における実施形態のトランスポートアクセラレータによって利用される複数の接続に関する公平性を実施するためのしきい値パラメータの使用について概して説明してきたが、そのようなしきい値パラメータの適切な値を計算することに関する詳細を以下で提示する。以下に記載する技法は、しきい値パラメータThreshの値を反復的に計算し、パイプライン化される場合およびパイプライン化されない場合に適用され得ることを理解されたい。
実施形態による動作中、Threshの最適な値はネットワーク状態により変わり得るので、CM122は、現在のネットワーク状態に基づいてThreshの値を動的かつ継続的に調整する。本明細書における実施形態に従って、Threshの値を決定する(たとえば、図2のブロック210における動作)ための技法を実施する際に、複数のダウンロードレートパラメータ(たとえば、DR、DFRおよびDCR)が利用され得る。そのようなダウンロードレートパラメータは、サーバからクライアントにダウンロードされているデータ、データのフラグメント、および/またはデータのチャンクの速度の測定値を提供し、時間ウィンドウに受信されているバイトの数によって決定され得る。たとえば、接続(たとえば、TCP接続)の(たとえば、適切な時間ウィンドウにおいて測定された、または加重移動平均を使用して平均化された)総平均ダウンロードレートとしてDR(ダウンロードレート)が定義される。接続の総平均ダウンロードレートとしてDFR(ダウンロードフラグメントレート)が同様に定義されるが、異なる点として、DFRの場合には、各フラグメントの第1のパケット、およびフラグメントの第1のパケットの受信と(TCP接続のいずれかを介した、任意のフラグメントからの)先行パケットの受信との間の時間が平均に含まれない(すなわち、「ディスカウントされる」)。同様に、接続の総平均ダウンロードレートとしてDCR(ダウンロードチャンクレート)が定義されるが、異なる点として、DCRの場合には、各チャンクの第1のパケット、およびチャンクの第1のパケットの受信と(TCP接続のいずれかを介した、任意のチャンクからの)先行パケットの受信との間の時間が平均に含まれない(すなわち、「ディスカウントされる」)。
DCRは通常、比較的高く(すなわち、第1のパケットチャンクのバイトを含み、第1のパケットと以前のパケットとの間の時間を含む、時間ウィンドウ全体でダウンロードレートが平均化される場合よりも高く)なり、ある意味でそれは、例としてネットワーク状態、使用されるTCP接続の数および他の要素に応じたインターフェースでの真の利用可能帯域幅を表し得る。一般に、DCRはDFR以上となるが、常にそうなるとは限らず、DFRがDCRよりも大きいときもある。一般に、DCR計算の目的は、サーバまたは他の外部ネットワーク要素からの明示的なフィードバックを必要とすることなく、データのパイプライン化を制御する方法を示す値を与えることである。
しきい値パラメータThreshは、以下に従うなどして、そのようなダウンロードレートパラメータを使用して決定および/または調整され得る。
DCR>DFR*1.05の場合、Threshの値を増やす。
そうではなくDCR≦DFR*1.05の場合、Threshの値を減らす。
ここにおいて、Threshの増減値は、所定の値(たとえば、2KB)であり得、DCR対DFRの相対比率などに依存し得る。
しきい値パラメータThreshを決定するためのそのような技法は、随時採用され得る。たとえば、Threshの値は、所定の時間期間経過後(たとえば、2秒ごとに)、事象が発生したとき(たとえば、10などのいくつかのRTTの後、またはCMによってチャンク要求が受信されるたびに)などに調整され得る。
実施形態は、追加または代替として、ダウンロードレートパラメータのうちの1つまたは複数を動的に測定し、それに応じてしきい値パラメータを決定/調整するように動作することができる。たとえば、Threshを決定/調整した後、実施形態は、Threshの調整が発生した後に発信されたチャンクに基づいてDCRおよびDFRを測定することができる。その後、Threshの値は、これらの更新されたダウンロードレートパラメータを使用して調整され得る。DCRおよびDFRの上記の動的に更新された測定値は、たとえば、発信された固定数T個のチャンク要求に基づき得る。そのような技法は、DFRおよびDCRの測定の期間がRTTに依存する(これは望ましい)が、明示的にRTTを測定することを必要としないという利点を有する。別の利点として、それは、前回Threshが調整される前に発生し、そのため現在のネットワーク状態をもはや反映していないDCRおよびDFRの測定に基づいて後続の調製が行われる可能性を回避する。
本発明の実施形態は、前述のダウンロードレートパラメータ(すなわち、DR、DFRおよびDCR)の追加または代替としてのダウンロードレートパラメータを利用することができる。たとえば、上記のThresh決定においてDFRを使用することの代替として、実施形態のCM122は、接続の総平均ダウンロードレートとして定義されるDDDR(ダウンロードディスカウント遅延レート)を使用することができるが、異なる点として、DDDRの場合には、以下で詳述するように、DDDRを計算するときに、遅延している各チャンク要求の第1のパケットのバイト、および遅延している各チャンク要求の第1のパケットと以前受信されたパケットとの間の時間がカウントされない(すなわち、「ディスカウントされる」)。
DDDRダウンロードレートパラメータを利用する実施形態を実施しているとき、CM122は、次のチャンク要求に対する準備ができていることをCMがシグナリングしたときにチャンク要求がRM121によってCMに即時に提供された場合に、チャンク要求を「遅延していない」に分類するように動作することができる。同様に、CM122は、次のチャンク要求に対する準備ができていることをCMがシグナリングしたときにチャンク要求がRM121によってCMに即時に提供されなかった(たとえば、次のチャンク要求に対する準備ができていることをCMがシグナリングしたときに、RMが行うことのできるチャンク要求を有していないことに起因するなどして、ある程度の遅延がある)場合、チャンク要求を「遅延している」に分類することができる。したがって、CM122は、ダウンロードレートとしてDDDRを計算することができるが、異なる点として、CMは、DDDRの分子を計算するときに、遅延している各チャンク要求の第1のパケットのバイトをカウントせず、DDDRの分母を計算するときに、遅延している各チャンク要求の第1のパケットと以前受信されたパケットとの間の時間をカウントしない。実施形態のCMは、一貫性のために、遅延しているチャンク要求として真っ先に受信する第1のチャンク要求を考えるように動作することができる。
上記のことから、DDDRを使用する実装形態は、CM122とRM121との間に、他の実装形態(たとえば、DFRが使用される実装形態)とは多少異なるAPIを採用することができることが諒解される。たとえば、チャンク要求に対する準備ができていることをCMがRMに対しシグナリングしたとき、RMは、(RMが行うことのできるチャンク要求を有すると仮定した場合)チャンク要求により即時に応答することができ、その場合にチャンク要求はCMによって、DDDRの計算において遅延していないチャンク要求に分類される。代替的に、RMが、チャンク要求に対する準備ができていることのCMからの信号に応答したものではないチャンク要求をCMに提供した場合、CMはチャンク要求を、DDDRの計算において「遅延している」に分類する。RMとUAとの間に同様のAPIが定義され得る。
実施形態のDDDRダウンロードレートパラメータは、以下に記載するように計算され得る。
Figure 0006178523
Z=0
Tr=0
パケットPが(Bバイトのサイズで、壁時計時間Twに)受信されるたびに:
Pが、遅延しているチャンクの第1のパケットである場合、{S=Tw}
そうではなく、Pが、遅延しているチャンクの第1のパケットではない場合、
{Tr=Tr+(Tw-S);
Z=Z+B;
S=Tw
}
DDDR=Z/Tr
実施形態による動作中、DDDRは、ダウンロードの時間全体ではない時間ウィンドウにおいて計算または平均化され得る。たとえば、DDDRが最後の持続時間ウィンドウW秒において計算される場合、分子Z_Wおよび分母Tr_Wが最後のW秒において計算され得、それによってDDDR=Z_W/Tr_Wとなる。Wの半減期(half-life)に指数加重移動平均(EWMA:exponential weighted moving average)を使用するなどして、DDDRの他の変形形態を計算するために同様の技法が使用され得ることを、当業者は認識しよう。
DFRの代わりにDDDRを使用する利点は、DDDRを計算することが、RMからCMに渡されるいかなる特別な知識も利用しないことであることを諒解されたい。特に、どのチャンクが新しいフラグメントに属するかについてRMがCMにシグナリングすることなく、CMはDDDR値を計算することができる。その上、DDDRの使用は、特別な場合でなくてもCMが実際にダウンロードしている時間をCMが正確に測定することを可能にする。対照的に、DFRの使用は、フラグメントごとに1つのチャンクしかないときに、DFRとDCRとの間に差がないことに関する問題を提起する。DDDRの使用はこの問題を有しないので、DDDRを利用する実施形態は、フラグメントごとに1つのチャンクしかないときの特別な例外なしに使用され得る。さらなる利点として、DDDRは、フラグメントがまだ入手できないためにRMが必ずしもフラグメントの第1のチャンク要求をCMに供給できるとは限らないライブの場合の適切な測定値であるが、次のチャンク要求に対する準備をCMがシグナリングしたときに次のフラグメントの第1のチャンクが作られ得る場合に、より適切に対処する。対照的に、DFRを利用する実施形態は、この新しいフラグメントの第1のパケットをディスカウントするが、CMが次のチャンク要求に対する準備ができている場合に、この第1のパケットをディスカウントする理由はない。同様に、DDDRは、上記の同じ理由で低/高ウォーターマーク戦略を使用するダウンロードの場合の適切な測定値である(すなわち、低ウォーターマークと高ウォーターマークとの間のバッファフィルとしてダウンロードするときに即時に要求されたフラグメントの最初のパケットはディスカウントされるべきではないが、高ウォーターマークに到達し、低ウォーターマークへの排出(drain)まで待った後に要求されたフラグメントの最初のパケットは、DDDRとDFRの両方でディスカウントされるべきである)。
実施形態は、ダウンロードレートパラメータDFRに関して上記で説明したすべての方法においてダウンロードレートパラメータDDDRを使用する。たとえば、実施形態のCM122は、しきい値Threshの調整方法に関する決定を行うためにDDDRを利用することができ、Threshは、それを下回ると新しい要求が行われるTCP接続のバッファレベルである。すなわち、Bが、TCP接続において要求されたがまだ受信されていないデータの量である場合、B<Threshのとき、CMによって新しいチャンク要求が行われ得る。
ダウンロードレートパラメータDPR(ダウンロードパイプラインレート)は、上記のダウンロードレートパラメータ(すなわち、DR、DFR、DCRおよびDDDR)の追加または代替として使用され得るダウンロードレートパラメータの別の例である。DPRは、たとえば、上記のThresh決定においてDFRまたはDDDRを使用することの代替として使用され得る。DPRは、DFR、DCRおよびDDDRと同様の実施形態に従って利用されるが、以下で説明するように相違がある。
DPRは、接続(たとえば、TCP接続)の総平均ダウンロードレートとして定義されるが、異なる点として、DPRの計算は、チャンク要求が行われたときに残存データを有しない接続において行われたチャンク要求の第1のパケットをディスカウントする。DPRの計算において、チャンク要求が遅延している場合、チャンクのいくつかの最初のパケットはディスカウントされる(たとえば、CMが次のチャンク要求に対する準備ができていることをRMが通知されたとき、チャンク要求は行われない)。したがって、DPRは、真のダウンロードレートとほぼ同じであり、最初の時間期間に、DPRとDCRとの間に差はないことがある。たとえば、セッションの真っ先に異なる接続において行われた最初の数個のチャンク要求は、以下でさらに詳細に説明するように、「パイプライン化されていない」に分類され(したがって、これらのチャンクの最初のパケットは、DPRまたはDCRによってカウントされない)、同様に、ライブシナリオにおけるフラグメント要求に関する最初のチャンク要求は、そのようなフラグメントが所与のタイムラインでのみ入手可能であり、次のフラグメントが入手可能になる前に以前のフラグメントが完全にダウンロードされた場合に、「パイプライン化されていない」に分類され得る。同様に、高-低ウォーターマークダウンロード方法を使用するときに、低ウォーターマークにメディアバッファを排出した直後にオンデマンドコンテンツについて行われたチャンク要求は、これらのチャンク要求が行われたときにすべてのTCP接続が使用中ではないので、「パイプライン化されていない」に分類され得る。
DPRを利用する実施形態の場合、接続において次のチャンク要求が行われたときに、その接続に関して要求されたがまだ受信されていないデータの量は、ネットワークバッファリング済みデータBuffと呼ばれ得る。しきい値パラメータThreshは、その接続の現在のパイプラインしきい値を表す。したがって、上記で説明したように、Buff<Threshのときに接続において新しいチャンク要求が発信され得る。
CMがすべての接続においてパイプライン化を使用すると仮定する。実施形態による動作中、CMは、Buff≧alpha*Threshのときにチャンク要求が受信された場合にDPRを決定するために特定の接続についてのチャンク要求を「パイプライン化されている」(遅延していない/時間どおり)に分類することができ、CMは、Buff<alpha*Threshのときにチャンク要求が受信された場合にDPRを決定するためにチャンク要求を「パイプライン化されていない」(遅延している/時間どおりではない)に分類することができ、ここにおいて、alphaは定数<1(たとえば、alpha=1/2またはalpha=2/3)である。
パイプライン化が使用されない場合、DPRを決定するためのチャンク要求の遅延分類のための技法は、上記とは異なり得る。実施形態の遅延分類技法では、当該チャンク要求に対する応答の第1の部分が返された時点に部分応答をすでに受信している、発信された不完全なチャンク要求の数Rが計算される。Rが固定定数fminよりも大きい場合に、実施形態のCMは要求を「時間どおり」に分類し、そうでない場合にそれを「遅延している」に分類することができる。
追加または代替として、パイプライン化が使用されない場合にDPRを決定するためのチャンク要求の遅延分類のための技法は、コンテンツサーバへのアイドル接続を分析することを含む。たとえば、要求が発信された時点に、CM122の論理は、サーバ130へのアイドルTCP接続の数をカウントすることができる。アイドル接続の数が所与のしきい値(たとえば、利用可能な接続の半分)を上回る場合、要求は「遅延している」に分類され得る。そうでない場合、要求は「時間どおり」に分類され得る。
要求を「パイプライン化されている」または「遅延している」に分類する際に利用される特定の技法に関係なく、DPRは、「パイプライン化されている」/「遅延している」分類を利用して計算され得る。実施形態によるDPRの計算では、チャンク要求が「パイプライン化されている」に分類される場合にチャンク要求の第1のパケットはディスカウントされず、チャンク要求が「パイプライン化されていない」に分類される場合にチャンク要求の第1のパケットはディスカウントされる。上記において使用される「ディスカウントされる」は、その第1のパケットにおいて受信されたバイトがカウントされず、その第1のパケットの受信と以前受信されたパケットの受信との間の時間がカウントされないことを意味し、「ディスカウントされない」は、その第1のパケットにおいて受信されたバイトがカウントされ、その第1のパケットの受信と以前受信されたパケットの受信との間の時間がカウントされることを意味する。
実施形態のDPRダウンロードレートパラメータが、以下に記載するように計算され得る(以下の例は、「パイプライン化されている」(遅延していない/時間どおり)および「パイプライン化されていない」(遅延している、または時間どおりではない)分類を決定する際に前述のネットワークバッファリング済みデータBuffおよびしきい値パラメータThreshの分析技法を利用するが、他の実施形態は、これらの分類のために上述したような代替技法を利用し得ることが諒解される)。
Figure 0006178523
要求されたがまだ受信されていないデータのBuffオクテットを伴うTCP接続においてチャンク要求が行われ、ThreshはこのTCP接続のオクテットによる現在のパイプラインしきい値である。
(Buff≧alpha*Thresh)の場合、このチャンク要求を「パイプライン化されている」に分類する。
そうではなく(Buff<alpha*Thresh)の場合、このチャンク要求を「パイプライン化されていない」に分類する。
チャンク要求に応答してTCP接続においてチャンクが受信される。
Z=0
Tr=0
パケットPが(Bバイトのサイズで、壁時計時間Twに)受信されるたびに:
Pが、「パイプライン化されていない」に分類されるチャンクの第1のパケットである場合、{S=Tw}
そうでない場合
{Tr=Tr+(Tw-S);
Z=Z+B;
S=Tw
}
DPR=Z/Tr
実施形態による動作中、DPRは、ダウンロードの時間全体ではない時間ウィンドウにおいて計算または平均化され得る。たとえば、DPRが最後の持続時間ウィンドウW秒において計算される場合、分子Z_Wおよび分母Tr_Wが最後のW秒において計算され得、それによってDPR=Z_W/Tr_Wとなる。Wの半減期にEWMAを使用するなどして、DCRまたはDPRの他の変形形態を計算するために同様の技法が使用され得ることを、当業者は認識しよう。
本明細書における実施形態によるEWMAを使用するDCRおよびDPRの計算の例として、ディスカウントされるべきではない(チャンクの第1のパケットではない)パケットが受信されると仮定すると、パケットは、Bビットのデータを含み、パケットの到着と(任意のタイプの)以前のパケットの到着との間の時間はdtである。DCRは、次のように更新され得る。
DCR=DCR*exp(-alpha*dt)
DCR=TDCR+B/alpha
上記のalphaの値は、たとえば、1/alphaに比例する時間期間にわたって平均化が減衰するように選択され得る。alphaの時間単位は、実施形態のdtの時間単位と整合される。たとえば、dtが上記においてミリ秒で表され、ターゲットが1秒に1/eの減衰である場合、実施形態に従って、alpha=1/1000である。別の例として、dtが秒で表され、ターゲットが1秒に1/eの減衰である場合、実施形態に従って、alpha=1である。上記の例示的な実施形態をさらに進めると、場合によっては数秒、たとえば5秒に1/eのターゲット減衰では、本明細書における実施形態によれば、dtがミリ秒で表される場合にalpha=1/5000であり、dtが秒で表される場合にalpha=1/5である。
EWMAを使用してDCRを計算するための上記の概念は、(十分にパイプライン化されていないチャンクの最初のパケットをディスカウントする)EWMAを使用するDPRの計算に適用され得る。たとえば、EWMAを使用してDCRを計算するための実施形態は、DCRとDPRの両方に同じ値のalphaを使用することができる。ただし、代替実施形態は、DCRおよびDPRに異なる平均化定数(たとえば、DCRにalphaCおよびDPRにalphaP)を使用することができる。
ダウンロードレートパラメータのDCRおよびDPRを計算するための技法について説明してきたが、以下では、しきい値Thresh(すなわち、それを下回ると、新しいチャンク要求が行われる、接続のバッファレベル)を調整する際のそれらの使用の例を提示する。本明細書における概念に従って、DCRおよびDPRを使用してThreshの値が取得され得る多くの技法があることを諒解されたい。
しきい値パラメータThreshの値を調整するためのDCRおよびDPRの使用の例示的な一例として、Rを、HTTPチャンク要求がCMによって行われたときと要求に対する第1の応答がCMによって受信されたときとの間の平均応答時間とする。チャンク要求ごとに、RTTを、要求が行われた時間と第1の応答が受信された時間との間の応答時間とする。上記を使用すると、R=(1-a1)*R+a1*RTTとなる。測定済みRTTを、EWMAを使用して時間ウィンドウにおいて、またはいくつかのRTT測定値において平均化するような、固定された以前の時間ウィンドウにおいて、または固定された以前の数のRTT測定値において平均化することなどによって、Rを計算するための多くの方法があることが諒解され得る。
実施形態に従ってThreshを調整するためにDCRおよびDPRを利用する際に、Threshを、しきい値に割り振られるすべての接続にわたるバイトの総量とする。Threshの値は周期的に、たとえば2*R秒ごとに、次のように更新され得る。
(DCR*a3>DPR)の場合、Thresh=min{Thmax,Thresh(1+a4)}
そうではなく(DCR*a5>DPR≧DCR*a3)の場合、Thresh=min{Thmax,Thresh*(1+a6)}
そうではなく(DCR*a5≦DPR)の場合、Thresh=max{Thmin,Thresh*(1-a7)}
ここにおいて、定数a1、a2、a3、a4、a5、a6およびa7の例示的な値、ならびにしきい値の最低Thminおよび最高Thmaxは次のとおりである。
a1=0.05
a2=2
a3=0.7
a4=0.5
a5=0.95
a6=0.1
a7=0.05
Thmin=32KB
Thmax=1MB
上記のことから、DCRがDPR以上になることが諒解され得る。DPRがDCRよりも著しく小さい場合、それは、チャンクの第1のパケットと以前のパケットとの間に大きいギャップがある(たとえば、チャンク要求が十分に早く行われていない)ことの表れである。DCRとDPRとが同じまたはほぼ同じ値である場合、実施形態は、しきい値パラメータThreshをそれの現在の値に維持するか、または場合によっては値をゆっくりと上昇させるように動作することができる。
本明細書における実施形態に従ってしきい値パラメータThreshを調整する際、目標は、チャンク内の任意の他のパケット間の間隔とほぼ同じである、チャンクの第1のパケットと以前のチャンクのパケットとの間のパケット間の間隔(すなわち、パケット間の間隔≒パケット内の間隔)を取得することである。そのような条件が達成されたとき、十分なデータがパイプライン化されており、要求が十分に前もって行われていて、帯域幅効率が最適化されている。したがって、異なる接続がほぼ同じレートでデータをダウンロードし、結果的に、ネットワークにバッファリングされるデータの量ができるだけ小さくなるように、小さいしきい値パラメータを実装することが望まれ得るが、実施形態は、パケット間の間隔の著しいギャップを回避するほど十分に大きいしきい値を実装するように動作する。
本明細書における概念に従って、上記に関して様々な代替が利用され得ることを諒解されたい。たとえば、DCRおよびDPRの値によっては、Threshの値を調整する決定が行われたときにThreshの値は変化しないことがある(たとえば、DPR/DCRの値が間隔(0.9,0.95)の範囲内にあるときなど、DPRがDCRの値よりも小さいがDCRの値に実質的に等しいとき)。したがって、代替実施形態は、Thresh=Thresh*(DCR/DPR)を設定することによって、Threshの値を調整するように動作することができる。本技法は上記で説明した手法に類似しているが、適用され得る調整の量に関してより柔軟であり、そのため、構成パラメータの数を減らすことができる。代替実施形態の別の例として、Threshの値は、Thresh=Thresh+delta*(1-DPR/DCR)を設定することによって調整され得、delta=32KBである。この代替技法は、付加的増加(additive increase)に基づいており、よりゆっくりと収束し得る。しきい値パラメータThreshを調整するための上記の代替技法のいずれかを実装する実施形態は、しきい値の最低Thminおよび最高Thmaxの制約を適用し続けることができることを諒解されたい。
要求されたがまだ受信されていないデータをどれほどの量、考慮に入れるべきか判断するために、また各接続における要求されたがまだ受信されていないデータの量の管理のために、様々なダウンロードレートパラメータ(たとえば、DPR、DCRおよびDFR)が使用され得ることが諒解され得る。その上、本明細書において提示するダウンロードレートパラメータ(たとえば、DPRおよびDFR)は、いつおよび/またはどのフラグメントを要求すべきかを判断するためなどのダウンロード統計をUAに提供するために利用され得る。
しきい値パラメータ値Threshを計算するためにDPRおよびDFRを使用する様々な利点は、上記のことから諒解され得る。たとえば、DPRの値は、パイプライン化値Threshが、ダウンロードレートDCRを達成するために十分なパイプライン化をもたらすかどうかを見分けるものであり、DPRとDCRとの間の差異は、DPRがダウンロードレートの一部として、パイプライ化されているチャンクの最初のパケットを含み、DCRが含まないことである。したがって、Threshが十分に大きい場合、DCRの値とDPRの値との間には小さい差のみがあるべきであり、Threshが十分に大きくはない場合、DPRの値とDCRの値との間にはより大きい差があるべきであり、一般にDCRの値はDPRの値よりも大きい。さらなる利点として、CMは、RMからのシグナリングまたは入力なしにDPRを計算することができる。
前述のように、上記のダウンロードレートパラメータおよびしきい値パラメータは、複数接続CM構成(たとえば、CM-mHTTP)の接続に関してチャンク要求が行われるべきときを判断する際に利用され得、複数接続CM構成によってCMが、本明細書における概念に従ってコンテンツを1つまたは複数のコンテンツサーバに要求し、当該コンテンツサーバから受信するために複数の接続を使用するように適合される。たとえば、Bが、すべての接続において要求されたが受信されていないバイトの数である場合、新しいチャンク要求が発信され得るかどうかに関する判断が、BとThreshとの比較に基づいて行われ得る(たとえば、B<Threshの場合、新しいチャンク要求が発信され得る)。
複数接続(たとえば、CM-mHTTP)構成において新しい要求が発信される場合、複数の接続のうちで新しい要求に適した接続が選択され得る。たとえば、実施形態に従って新しい要求のために、最も少ない数の残存バイト(たとえば、要求されたがまだ受信されていないバイト)を有する接続が選択され得る。一方、代替実施形態は、接続ごとに個別に、新しい要求に関する決定を行うことができる。実施形態は、たとえば、負荷分散をもたらすようにチャンク要求のための接続を選択することができ、それによって、特定の接続についてのチャンク要求は、それの1つまたは複数のダウンロードレートパラメータに基づいて重み付けされ得る。1つの接続においてコンテンツサーバによって完全には対応されていないチャンク要求が再送される場合、チャンク要求は、チャンク要求の完了時間があまりにも遅くなる可能性を低下させるために、全体的か部分的かを問わず、1つまたは複数の異なる接続を介して再送され得る。
新しいチャンク要求を行うかどうかについての決定は、たとえば、以下に従って、N個のアクティブ接続の各々に関して行われ得る。
(B<Thresh/N)の場合、この接続は別のチャンク要求を受け取ることができる。
上式でBは、接続において要求されたが受信されていないバイトの数である。
使用される接続(たとえば、TCP接続)の数Nは、複数接続構成(たとえば、CM-mHTTP)を提供するCMによって動的に調整され得る。たとえば、CMの場合の接続の最小数および最大数(たとえば最小接続=2および最大数=8)が事前選択され得、それによって、特定の時間に使用される接続の特定の数が、1つまたは複数の動作メトリクスに基づいて動的に調整され得る。接続の追加は、たとえば、パケット誤り率がRTTに関係し、そのため追加の接続がサポートされ得る場合などに、追加のスループットをもたらすために使用され得る。
一般に、実施形態は、特定の接続に関する要求されたがまだ受信されていないデータを、その特定の接続の輻輳ウィンドウ未満の量で有するように動作する。輻輳ウィンドウが小さい場合、輻輳ウィンドウが大きい場合よりも多くの接続が勧められ得る。残念ながら、クライアントデバイス110などのクライアントデバイスは、一般に輻輳ウィンドウ情報にアクセスできない。したがって、本明細書における実施形態は、CMによって使用される接続の数を動的に調整する際に、上記で説明したように、ダウンロードパラメータおよび/またはしきい値パラメータを利用するように動作することができる。
実施形態に従って接続の数を動的に調整するにあたり、X_i=min{CWND_i,RWIN_i,SWIN_i}とし、CWND_iは送信側の現在の輻輳ウィンドウサイズであり、RWIN_iは受信側ウィンドウサイズであり、SWIN_iは送信側ウィンドウサイズであり、それぞれ、接続iの場合である。さらにRTTを、たとえば、その接続を介して、チャンク要求が行われたときと、そのチャンク要求への第1の応答が受信されたときとの間の平均時間として測定された、平均RTTとする。DPRは一般に、せいぜいX_i/RTTのiにおける合計であり、同様にDPRは一般に、せいぜいBuffAvg/RTTであり、BuffAvgは、すべての接続の範囲内における要求されたがまだ受信されていないデータの平均量である。実施形態のCMは、RTTおよびDPRの測定値を有しており、しきい値パラメータThreshおよび(上記で説明したように)チャンク要求サイズを制御するように動作可能であり、したがってBuffAvgを制御する。そのようなCMは、X_iのiごとの値を直接知ってはいないことがあるが、CMはそれでも、以下に従って接続の数Nを調整することができる。
DPRがBuffAvg/RTTよりも小さい場合、接続の数Nは増やされ得る。
DPRがBuffAvg/RTTにほぼ等しい場合、接続の数Nは減らされ得る。
実施形態について、クライアントデバイスのためのコンテンツの転送に複数の接続を利用するCM構成に関して上記で説明してきた。そのような接続は、1つまたは複数のコンテンツサーバ(たとえば、図1Aに示すようなコンテンツサーバ130または図5に示すようなコンテンツサーバ130aおよび130b)に関して行われ得る。したがって、本明細書における概念は、実施形態のトランスポートアクセラレータを使用してコンテンツの転送をもたらす1つまたは複数のコンテンツサーバに対して適用され得ることを諒解されたい。
実施形態による動作中、CMは、1つまたは複数のインターフェース(たとえば、LTEインターフェース、Wifiインターフェースなど)による1つまたは複数のコンテンツサーバへのすべての接続を確立および管理し、CMが接続のうちの1つにおいて行われる別のチャンク要求に対する準備ができていることをRMに示すことを担う。Threshを、CMによって管理されるインターフェースのオクテット(バイト)によるしきい値とし、DPRの定義が以下のように変更されることを除いて、上記で説明したように、DCRおよびDPRに基づいて、Threshの値は増減調整される。Bを、CMによって管理されるインターフェースのすべての接続にわたる、CMによって要求されたがまだ受信されていないオクテット(バイト)の総数とする。チャンク要求がCMによって行われたとき、B<alpha*Threshの場合には、チャンク要求は、DPR計算において遅延していると見なされ、B≧alpha*Threshの場合には、チャンク要求は、DPR計算において遅延していないと見なされる。NDを、アクティブな各コンテンツサーバへの1つの接続に加えてCMが使用することができる接続のターゲット総数とする。NDの値は、CMによって動的に決定され得るか、または定数値(たとえば、ND=8)に設定され得る。NOは、CMがチャンク要求に現在対処しているコンテンツサーバ(オリジンサーバ)の数とする。その場合、CMが維持する接続の総ターゲット数は、おおよそN=ND+NOであり、これは以下に基づく。
B_Iを、CMによって管理されるインターフェースのオリジンサーバIへのすべての接続にわたる、CMによって要求されたがまだ受信されていないオクテット(バイト)の総数とする。
N_I=ND*(floor(sum_J≦I{B_J}/sum_I{B_I})-floor(sum_J<I{B_J}/sum_I{B_I}))+1を、CMによって管理されるインターフェースを介したオリジンサーバIへの接続のターゲット数とし、したがって、sum_I{N_I}=ND+NOとなる。
B<Threshのとき、CMは、チャンク要求に対する準備ができていることをRMにシグナリングする。
CMがRMからチャンク要求を受信したとき、
チャンク要求がどのオリジンサーバI向けかを判断する
上記で説明したようにN_Iを決定する
A_I=Iへのアクティブ*接続の数を決定する
A_I≧N_Iの場合、要求されたがまだ受信されていないデータの最小量を有するIへのアクティブ接続において、チャンクについてのHTTP要求を行う
A_I<N_Iの場合、Iへの新しい接続を開始し、その接続においてチャンクについてのHTTP要求を行う
チャンク要求を、チャンクについてのHTTP要求が行われたときにB<alpha*Threshの場合に「遅延している」に分類する(DPRを計算するときに、チャンクの第1のパケットおよびチャンクの第1のパケットと以前のパケットとの間の時間をカウントしない)。
上記の例示的な実施形態による動作中、接続が、要求されたがまだ配信されていないデータを有する場合、接続が、要求されたデータを有しないが、クライアントによる測定によりタイムアウトになっていない場合、または接続が、サーバによってシグナリングされタイムアウトになった場合、接続はアクティブと見なされる。
前に説明したように、図1Bは、TA120のRM121およびCM122の構成要素の高レベルアーキテクチャを提供する。TA120のそのような実施形態を実装する構成要素のコンテキストを提供するために、図1Cのトランスポートアクセラレータ構成を参照して、TA120の例示的な実施形態に関するさらなる詳細を以下に提示する。
この例示的な実施形態のRM121は、好ましくは、TA120内に以下の機能を提供するように構成される。RM121はTA要求ディスパッチャ1024から、加速されるべき、データダウンロードについてのUA129からの要求を受け取る。実施形態による動作中、RM121はTA要求ディスパッチャ1024に、加速されるべき別のデータ要求を受け取る準備をシグナリングすることができる。RM121は、データ要求をチャンク要求に分割する。実施形態による動作中、オリジンサーバI向けの各チャンク要求の好ましいサイズCTarget(I)が、CM122によって示される。実施形態のRM121は、チャンク要求サイズを、好ましいサイズの付近で均等に拡散する。RM121は、CM122にチャンク要求を発信する。実施形態による動作中、CM122が新しい要求に対する準備ができていることを示したときに、チャンク要求が発信される。RM121は、異なるUA129からの要求キューの間で公平性を確保しつつ、適切な要求優先度付けを確保するために、スケジューリングアルゴリズムの制約内でチャンク要求をスケジュールすることができる。RM121は、チャンク要求に対する応答を、UA129からの要求に対する応答に組み立てる。次いでRM121は、データが順序どおりに、かつ連続的に上位層に配信されるように、これらの応答をUA129に戻すことができる。
この例示的な実施形態のCM122は、好ましくは、TA120内に以下の機能を提供するように構成される。CM122は、各オリジンサーバへのHTTPチャンク要求の数を管理する。実施形態のCM122は、複数のオリジンサーバ向けのチャンク要求を発信する。実施形態による動作中、チャンク要求の数は、定義された構成パラメータの間で変わる。たとえば、実施形態のCM122は、DCRおよびDPRを計算し、DCRおよびDPRは、RM121による要求チャンキングのための好ましいチャンクサイズCTarget(I)を計算するために使用される総合値Tを計算するために使用される。実施形態によるそのような動作の目標は、チャンクを、良好なレートを得るほど十分に大きくする一方で、要求されるデータの全体量をできるだけ小さくしておくことである。実施形態のCM122は、スタック処理1025に新しいチャンク要求を発信する準備ができていると判断する。実施形態による動作中、CM122は、RM121にチャンク要求準備を通信する。実施形態によるそのような動作の目標は、スタック処理1025において接続を使用中に保つ一方で、チャンク要求をあまりにも早くキューイングしないようにすることである。CM122は、スタック処理1025に対するチャンクについての要求(たとえば、HTTP要求)を行い、データ応答をRM121に提供することができる。
この例示的な実施形態のTA120ならびにそれのRM121およびCM122の一般的機能について説明してきたが、例示的な実施形態に従ってTA120のRMおよびCMの構成要素内に実装され得るアルゴリズムを、以下で提示する。
実施形態による動作中、CM122は、DCRおよび/または平均DCRの測定を維持する。CM122はそれを、たとえば、ダウンロードレートを測定する一方でチャンク応答間のギャップをディスカウントすることによって行う。チャンク間のギャップをディスカウントするために、実施形態のCM122は、各チャンクの受信された第1のデータのバイトをディスカウントし、チャンクの第1のデータの到着と受信された先行チャンクの受信された最後のデータとの間の時間もディスカウントする。DCRディスカウントの一例が図7に示されており、ここにおいて、ディスカウントされた時間およびデータがXで指定されている。通常、図7に示すように、HTTP要求に対して受信された応答データのブロックは、TCPネットワークパケットのペイロードである。ただし、送信エラーおよび他の不完全性に起因して、単一のTCPセグメントはすべて、別個にではなくより大きいブロックで(たとえば、特に、小さいRTTを伴う高速リンクを介してダウンロードしているとき)受信されることがある。したがって、一度に受信される個別のデータブロックは、CM122によって一度に受信されるデータの複数TCPパケットを含む格段に大きいブロックであるので、一度に受信される個別のデータブロックは、TCPパケットの良好な概算をもたらさないことがある。以下で説明するCM122によるDCR計算は、一度にデータの大きいブロックを受信する可能性を考慮し、同様に、以下で説明するCM122によるDPR計算は、一度にデータの大きいブロックを受信する可能性を考慮する。
DCRは、チャンク要求が恣意的に大きかった場合に所与の条件において達成され得るダウンロードレートの推定値である。チャンク要求が小さい場合、各チャンク要求を送り出してから応答を受信し始めるまでの間のアイドル時間は、全体的なダウンロードレートに悪影響を与えることに留意されたい。したがって、チャンクサイズを拡大すると、実効ダウンロードレートがある程度上昇する。DCR推定値は、この点で訂正され、したがって、選択されたチャンクサイズとは実質的に無関係である。
DCRを計算するために、データの受信に費やされた時間の累積量および各チャンクの第1の受信されたブロックが処分されたときに受信されたデータの量に対応する連続変数(running variable)TDCRおよびZDCRが、実施形態に従って計算される。チャンクIDを含み、要求が送り出されているがデータがまだ受信されていないチャンクIDを追跡する、ヘルパーデータ構造unseen_chunk_idsも、実施形態に従って利用される。
実施形態による上記の変数およびデータ構造の初期化は、以下に示すとおりであり、ここにおいて、MSSは、TCPパケットの最大サイズに近くなるように設定されるのが好ましい定数(たとえば、MSS=1500バイト)であり、Cmultは、1未満の定数(たとえば、Cmult=2/3)である。
TDCR=0を設定する
ZDCR=0を設定する
unseen_chunk_ids=empty_set()を設定する
Tlast_data_recv=現在(ms単位)を設定する
実施形態による動作中、新しいチャンク要求CがRMから来たとき、それのIDが、以下に示すように未発見チャンクID(unseen chunk ID)のセットに加えられる。
unseen_chunk_ids.add(chunk_idC)
次いで、実施形態に従ってスタック処理1025にチャンク要求Cが発信される。
チャンク要求Cのデータが到着したとき、実施形態に従ってTDCR、ZDCRおよびunseen_chunk_idsを更新するために以下のステップが実行される。
current_timeを現在時間(ms単位)とする
deltaT=current_time-Tlast_data_recv(任意のチャンクの任意のデータが最後に受信されてからの時間)とする
Tlast_data_recv=current_time
deltaZ=(HTTPヘッダオーバーヘッドを含む)受信されたデータの量とする
unseen_chunk_idsにおけるchunk_idCが以下の場合、
deltaZ>MSSの場合、
TDCR=TDCR+deltaT*Cmult*(deltaZ-MSS)/deltaZ
ZDCR=ZDCR+deltaZ-MSS
unseen_chunk_idsからchunk_idCを除去する
それ以外の場合、
TDCR=TDCR+deltaT
ZDCR=ZDCR+deltaZ
上記のことから、deltaZ≦MSSが、以前のデータが受信されていないチャンクについて受信されたデータの量である場合、deltaTおよびdeltaZのすべてがディスカウントされる(すなわち、TDCRおよびZDCRに何も加えられない)ことが諒解され得る。一方、deltaZ>MSSが、以前のデータが受信されていないチャンクについて受信されたデータの量である場合、deltaTおよびdeltaZのすべてをディスカウントする代わりに、上記による動作は、deltaTをCmult*(deltaZ-MSS)/deltaZ倍だけディスカウントし、ディスカウントされた値をTDCRに加算し、さらにdeltaZを(deltaZ-MSS)/deltaZ倍だけディスカウントし、ディスカウントされた値をZDCRに加算する。したがって、基本的に、受信されたデータの第1のMSSのみがディスカウントされ、残りはDCRパラメータのZDCRおよびTDCRにカウントされる。Cmult倍だけdeltaTをさらにディスカウントすることで、ディスカウントされたdeltaZ値をディスカウントされたdeltaT値で割った比率が、deltaZをdeltaTで割った比率よりも大きくなり、ひいては、Cmult<1のため、deltaZ>MSSのときに以前のデータが受信されていないチャンクについて受信されたデータの受信に起因して、DCRに対する全体的影響が総じて、DPRに対する影響よりも好ましくなる。
TDCRおよびZDCRは単調に増加する数である。実施形態のCM122はさらに、DCRの何らかの履歴を追跡するように動作し、したがって、CMは、時間的順序で記憶され得るような、(TDCR,ZDCR)ペアのアレイを維持する。このアレイは、本明細書ではマップTDCRZDCRと呼ばれる。マップTDCRZDCRの更新は、新しいデータが受信されたときはいつでも、実施形態に従って発生する。実際には、履歴が無制限に増えないようにマップTDCRZDCRから古いエントリを除去することが望まれ得、したがって、マップTDCRZDCRは、本明細書の実施形態に従って巡回キューに記憶される。
例示的な実施形態の説明の残りでは、DCR(dcr_dpr_estimate_win)は、以前の持続時間ウィンドウdcr_dpr_estimate_winにおいて推定されたDCRを示し、dcr_dpr_estimate_winは、構成パラメータである。
HTTPクライアントの達成されるダウンロードレートは、クライアントがデータをどのくらい積極的に要求するかに依存する。たとえば、大きいファイルがダウンロードされている場合には、要求される必要のあるものが前もって明らかであるので、高いダウンロードレートが達成され得、したがって、TA120は、発信すべきチャンク要求が不足することのないように動作し得る。一方、クライアントが、たとえば、ライブコンテンツを再生しているDASHクライアントである場合、(かなり先のビデオを入手することはできないので)事前にデータの小さい断片を要求することが可能なだけであり得、したがって、非常に高いダウンロードレートを達成するのは不可能なことがある。
実施形態に従って利用されるダウンロードパイプラインレート(DPR)は、現在の状態(たとえば、チャンクサイズ、並行処理)において達成可能な飽和ダウンロードレートの推定値である。言い換えれば、DPRは、現在のTA120設定で大型ファイルダウンロードの場合に達成されるレートを推定する。
本明細書における実施形態に従ってDPRを計算するために、チャンク要求がエポックにグループ化される。たとえば、チャンク要求が遅延しているときはいつでも(たとえば、TA120がチャンク要求を送る準備ができてからかなりの時間が経過し、次のチャンク要求が発信されたとき)、新しいエポックが開始され得る。ダウンロードレートを測定する一方で、チャンクについてダウンロードされた第1のデータまたは新しいエポックからのサブ要求の間のギャップをディスカウントすることによって、DPRは計算され得る。
CM122においてRM121から受信されたチャンク要求は、エポックに分類される。実施形態による動作中、「遅延している」チャンク要求ごとに新しいエポックが開始される。チャンク要求のエポックへの分類の図が図8に示されており、ここにおいて、チャンク要求は通常、以下の条件のうちの1つまたは複数に基づいて「遅い」または「遅延している」と指定される。ダウンロードセッションの第1の発信されたチャンク要求、UA129からRM121への要求が遅いとき、バッファの高/低ウォーターマーク排出を伴うオンデマンドストリーミングの際、および固定タイムラインにおいてフラグメントが入手可能なときのライブストリーミングの際。エポックの第1のデータが到着したとき、それは「遅延している」としてカウントされ、DPR計算からディスカウントされる。DPRディスカウントの一例が図9に示されており、ここにおいて、Xで指定された時間およびデータがディスカウントされる。通常、図9に示すように、HTTP要求に対して受信された応答データのブロックは、TCPネットワークパケットのペイロードである。しかしながら、上記で説明したDCR技法と同様に、以下で説明するDPR技法は、2つ以上のTCPネットワークパケットが一度に受信される可能性を考慮する。
DPRは、以下で説明するアルゴリズムに従って計算され得る。DPRの計算に関して採用される手法は、上記で説明したDCRの計算と同様であることを諒解されたい。前述のように、MSSを、TCPパケットの最大サイズに近くなるように設定されるのが好ましい定数(たとえば、MSS=1500バイト)とする。上記で使用されたCmultと同様に、Pmultを1未満の定数(たとえば、Pmult=2/3)とする。CmultおよびPmultの値は、実施形態によれば、同じ値または異なる値に設定され得る。実施形態に従って利用されるDPR計算アルゴリズムは、構成パラメータepoch_time_thresholdに依存し、これは、新しいエポックをトリガする要求準備と要求発信との間の最小時間量(ミリ秒単位)である(たとえば、epoch_time_threshold=20が、このパラメータの妥当な設定である)。実施形態のDPRアルゴリズムは、TDPRおよびZDPRの変数を追跡することができ、ここにおいて、タイマーTDPRは、エポック間のギャップをディスカウントして、TAがデータのダウンロードに費やした時間の累積量をカウントし、カウンターZDPRは、エポック開始時に受信された最初のバーストをディスカウントして、受信されたバイトの累積数をカウントする。アルゴリズムは、current_epoch_id(すなわち、新しいチャンク要求に割り当てられる現在のエポック番号)、awaited_epoch_id(すなわち、第1の受信されたデータペイロードがまだディスカウントされていない次のエポックID)、ready_flag(すなわち、CMが新しい要求を受け取る準備ができているかどうかを示すフラグ)、およびlast_ready_time(すなわち、ready_flagが設定された場合に、CMが新しいチャンク要求を受け取る準備ができた時点を示す(ready_flagが設定されない場合、値は使用されない))など、いくつかの他の変数も追跡することができる。
実施形態によるDPR計算アルゴリズムの開始時に、上記の変数が次のように設定され得る。
TDPR=0を設定する
ZDPR=0を設定する
current_epoch_id=0を設定する
awaited_epoch_id=0を設定する
ready_flag=真を設定する
last_ready_time=現在(ms単位)-epoch_time_threshold-1を設定する
Tlast_data_recv=現在(ms単位)を設定する
チャンク要求CがRM121から来たとき、実施形態のDPR計算アルゴリズムが次のように演算する。
delta=現在(ms単位)-last_ready_timeを設定する
ready_flag==真およびdelta>epoch_time_thresholdの場合、
current_epoch_id=current_epoch_id+1を設定する
C.epoch_id=current_epoch_id
ready_flag=偽
内部準備更新アルゴリズムを呼び出す
次いで、スタック処理1025にチャンク要求Cが発信され得る。
チャンク要求Dのデータが到着したとき、実施形態のDPR計算アルゴリズムが次のように演算する。
current_time=現在(ms単位)とする
deltaT=current_time-Tlast_data_recv(任意のチャンクの任意のデータが最後に受信されてからの時間)とする
Tlast_data_recv=current_time
deltaZ=HTTPヘッダオーバーヘッドを含む、受信されたデータの量とする
D.epoch_id≧awaited_epoch_idの場合、
//データは新しいエポックを開始する、ディスカウント。
deltaZ>MSSの場合、
TDPR=TDPR+deltaT*Pmult*(deltaZ-MSS)/deltaZ
ZDPR=ZDPR+deltaZ-MSS
awaited_epoch_id=D.epoch_id+1を設定する
それ以外の場合、
TDPR=TDPR+deltaT
ZDPR=ZDPR+deltaZ
実施形態による動作中、deltaZは、HTTPヘッダオーバーヘッドを含み、DCR計算における対応する断片も同様である。(たとえば、チャンクサイズが小さい場合に)ヘッダがアルゴリズムに影響を与えるほど十分に大きいことがあるので、ヘッダオーバーヘッドを含まないことは、重要であることが多い。
上記の説明では、DCRに使用される変数Tlast_data_recvは、DPRに使用される変数とは別個のものである。同じ時点に両方のアルゴリズムが呼び出されるので、共通の変数が、DPRおよびDCRの呼出しごとに2回更新されないという条件で使用されることもある。
TDPRおよびZDPRは単調に増加する数である。CMは、それらの値の何らかの履歴を追跡することができ、そのため、実施形態のCM122は、本明細書ではマップTDPRZDPRと呼ばれる巡回キューにこれらの変数を記憶する。その巡回キューのサイズは、DCRの場合とほとんど同じように選択され得る。
例示的な実施形態の説明の残りでは、DPR(dcr_dpr_estimate_win)は、以前の持続時間ウィンドウdcr_dpr_estimate_winにおいて推定されたDPRを示し、dcr_dpr_estimate_winは一般に、DCRの場合と同じ持続時間となる。
実施形態のCM122は、アクティブなチャンク要求のサイズ全体の近似値であるT値の測定を維持する。実施形態による動作中、要求がチャンクされ、CM122は、T値に関するそれの現在の測定に基づいて新しいチャンク要求を発信する準備を示す。実施形態によるT値調整アルゴリズムの目標は、Tができるだけ最大ダウンロードレートに近くなるよう十分に大きくなるべきである一方で、上記に従い、Tができるだけ小さくなるべきであることである。T値があまりにも小さい場合、CM122は、現在のHTTPチャンク要求が完了したときと次のHTTPチャンク要求からの第1の応答が始まったときとの間の、平均を上回る「ギャップ」に直面する。これは図10Aに示されている。T値が適性である場合、次のHTTPチャンク要求に対する第1の応答が、現在のHTTPチャンク要求が完了した後、チャンクのすべての他のパケットと同じペースで来る。これは図10Bに示されている。T値があまりにも大きい場合、多くのHTTPチャンク要求が必要以上に早く行われる。これは図10Cに示されている。
実施形態のCM122は、T値の測定を周期的に調整するために、以前の持続時間ウィンドウdcr_dpr_estimate_winにおいて平均化されたDPRおよびDCRの現在の値を使用する。DCRとDPRとの間の以下の関係が一般に成り立つ。DCRは一般に、少なくともDPRと同じくらいの大きさである、チャンクの第1のデータブロックと以前受信されたデータブロックとの間に平均を上回るギャップがあるときに、DCRは一般に、DPRよりも大きい(これは、リンク上でさらなるデータが要求されるべきであるため、Tは増やされるべきであることを示唆する)、チャンクの第1のデータブロックと以前受信されたデータブロックとの間に平均的なギャップがあるときに、DCRは一般に、DPRにほぼ等しい(これは、要求が早く、かつ十分に大きかったため、Tは十分に大きく、減らされ得ることを示唆する)。DCR=DPRのときの平均的ギャップおよびDCR>DPRのときの平均を上回るギャップの概念が図11に示されている。
実施形態による動作中、T値調整アルゴリズムが上記の観測を使用して、T値を周期的に調整し、所与のリンク状態に最適なTを維持する。実施形態のCM122によって使用される構成パラメータおよびT値調整アルゴリズムを以下に記載する。
Figure 0006178523
実施形態のT値調整アルゴリズムの開始時に、変数が次のように初期化され得る。
TInit=CInit*sminTotalを設定する(またはそれを、入手可能な場合に履歴ファイルからロードする)
last_tvalue_update_time=現在(ms単位)
Tmin=Cmin*sminTotalを設定する
w=dcr_dpr_estimate_winを設定する
実施形態による動作中、データが受信されたか、またはアクティブなCMに関して100msのタイムアウトが発生した(すなわち、要求された残存データをCMが有する)ときはいつでも、
DCR(w)が無効であるか、またはDPR(w)が無効である場合、
戻る
current_time=現在(ms単位)
current_time-last_tvalue_update_time>tMinTAdjIntervalの場合、
DCR(w)>DPR(w)*cm_cp_ratio_maxの場合、
ratio=cm_cp_ratio_max
そうではなくDCR(w)<DPR(w)*cm_cp_ratio_minの場合、
ratio=cm_cp_ratio_min
それ以外の場合、
ratio=DCR(w)/DPR(w)
z=1+cm_step_alpha*(cm_target_delta*ratio-1)
T=min(Tmax,max(T*z,Tmin))を設定する
last_tvalue_update_time=current_time
上記の関数の計算は、浮動小数点演算の実施形態に従って実行される。終了時に、実施形態のCM122は、構成を通じてTAhistory_filenameが設定されている場合に、履歴ファイルにTの最終値を書き込むように動作する。
実施形態による動作中、RM121はCM122に、オリジンサーバI向けの新しいチャンク要求を発信する準備について問い合わせる。そしてCM122は、準備アルゴリズムを使用して、オリジンサーバIに新しいチャンク要求を発信する準備ができているかどうかを判断することができる。内部的に、実施形態のCM122は、ネットワークスタックに対して異なるオリジンサーバ向けにすでに発信されたチャンク要求を追跡する。CMは、この情報を、ネットワークスタックによってオリジンサーバごとに許された接続の最大数に関する構成情報とともに使用して、スタックへのチャンク要求を調節しスケジュールする。CMは、T値のそれの測定も使用して、必要以上に早く要求を過剰に行うことなく、リンクが最大限使用されるようにする。
実施形態のCM122によって使用される構成パラメータおよび準備アルゴリズムを以下に記載する。
Figure 0006178523
実施形態のCM122は、CMがRM121によって特定のオリジンサーバ向けの準備について問合せを受けたときに、以下を実行する。
QI=オリジンサーバIへのアクティブなチャンク要求の現在の数
Q=すべてのオリジンサーバへのアクティブなチャンク要求の現在の数=sumI(QI)
RAvg=すべてのオリジンサーバからの受信チャンク要求の現在の数の平均(Ravg計算アルゴリズムを使用する)。
//以下であるQallowを発見する
// max{Z: T≧Cmin*(Z+1)
// および(ready_threshold*Z≦1000*RAvgまたはZ<sminTotal)
// およびZ-Q+QI<smaxOrg
// およびZ<smaxTotal}
bound1=floor(T/Cmin)-1
bound2=max(floor(1000*Ravg/ready_threshold),sminTotal-1)
bound3=smaxOrg+Q-QI-1
bound4=smaxTotal-1
QallowI=min{bound1,bound2,bound3,bound4}
QallowI≧Qにおいて、CMは、任意のオリジンサーバIに対するチャンク要求の準備ができている。
実施形態によって実装される準備アルゴリズムを理解するために、deltaIを、特定のオリジンサーバI向けに発信される可能性のある追加のチャンク要求とする。その場合、QallowI(準備に関して計算される)は、deltaIチャンク要求の発信に成功した場合のシステムにおけるアクティブなチャンク要求の総数である(すなわち、QallowI=deltaI+Q)。
実施形態による動作中、CM122は、準備アルゴリズムにおいて使用するデータを受信するアクティブなチャンク要求(R)の平均数の測定を維持する。実施形態のCM122によってRAvgを計算するための構成パラメータおよびアルゴリズムを以下に記載する。
Figure 0006178523
RAvgを計算するためのアルゴリズムの開始時に、実施形態に従って次のように変数が初期化され得る。
RAvg=0を設定する(またはそれを、入手可能な場合に履歴ファイルからロードする)
last_Ravg_value_update_time=現在(ms単位)
実施形態による動作中、データが受信されたか、またはアクティブなCM122に関して100ミリ秒のタイムアウトが発生した(すなわち、いくつかの要求された残存データをCM122が有する)ときはいつでも、
current_time=現在(ms単位)
R=すべてのオリジンサーバにわたるデータを受信するアクティブなチャンク要求の現在の数
current_time-last_Ravg_value_update_time>tMinRAvgAdjIntervalの場合、
R>RAvgの場合、
RAvg=R
それ以外の場合、
RAvg=((1-receive_req_avg_const)*RAvg)+(receive_req_avg_const*R)
last_Ravg_value_update_time=current_time
終了時に、実施形態のCM122は、構成を通じてTAhistory_filenameが設定されている場合に、履歴ファイルにRAvgを書き込むことができる。
実施形態に従って実装される内部準備アルゴリズムの目的は、CM122内でready_flagおよびlast_ready_timeを更新することである。これらはCM122によって、DPR計算のために前述のエポックに着信要求を分類するために使用され得る。
実施形態による動作中、内部準備アルゴリズムはCM122によって、RM121からチャンク要求が受信された直後、およびすでに発信されたチャンク要求のいずれかに関してスタックからデータが受信された後、実行される。以下では、本明細書における実施形態に従って利用される内部準備更新アルゴリズムを提示する。
ready_flag==真の場合、
戻る//準備がすでに完了している場合にはスキップする
Aを、アクティブなオリジンサーバ(少なくとも1つのアクティブなチャンク要求を有するサーバ)のリストとする
Aにおけるiに関して:
オリジンサーバi向けの準備を判断する
CMがオリジンサーバi向けに準備できている場合、
ready_flag=真
last_ready_time=現在(ms単位)
特定のオリジン向けの要求準備について問い合わせた後、かつ要求をチャンクする前、実施形態のRM121はCM122に、特定のオリジンサーバ向けのチャンク要求の好ましいチャンクサイズについて問い合わせる。実施形態による動作中、CM122は、好ましいチャンクサイズ計算アルゴリズムを使用して、オリジンサーバ向け要求の好ましいチャンクサイズをRM121に通信する。以下のパラメータは、好ましいチャンクサイズを計算する際に利用され得る。
Figure 0006178523
オリジンサーバI向けの好ましいチャンクサイズについて問合せを受けたとき、実施形態のCM122は、次のように演算する。
QallowIを計算する
T=現在のT値
CTarget(I)=max(T/(QallowI+1),Cmin)
実施形態による動作中、RM121は、CM122からの好ましいチャンクサイズ(CTarget(I))値を使用して、CM122に発信するオリジンサーバI向けのUA129からの次のスケジュールされる要求をチャンクする。したがって、RMは、チャンキングアルゴリズムを使用して、要求のチャンキングを行うことができる。実施形態のRM121によって使用されるチャンキングアルゴリズムの目標は、以下を含む。チャンクサイズを、RM121がCM122から取り出すCTarget(I)値の近くにすること、要求完了時間の同期化を回避するために異なるチャンク要求のチャンクサイズを拡散すること(たとえば、チャンクサイズは、好ましいチャンクサイズ(CTarget(I))に比例して拡散され得る)、および/または非常に小さいチャンク要求を回避すること。実施形態のRM121によって使用されるチャンキングのための構成パラメータを以下に記載する。
Figure 0006178523
実施形態による動作中、RM121はまた、開始時に0に初期化された持続的(たとえば、TA120の実行中)カウンターctrを使用する。カウンターctrは、最も便利に32ビットの符号なし整数として実装され得る。
N=チャンクされるべき要求における残りの要求されていないバイト
または無制限バイト範囲要求の場合、なし
p=ceil(CTarget(I)*(1+chunk_spread*(reverse_bits(ctr)/2**32)))を計算する
//注:reverse_bits()は、ワード中のビットを反転させる。
//下記参照。
if Nがなしではない
if chunk_hysteresis*p<N、
ChunkSize=pを設定する
else
ChunkSize=Nを設定する
else
ChunkSize=pを設定する
ctr=(ctr+1)%(2**32)
ChunkSizeを戻す
reverse_bits()関数は、32ビットの符号なしint中のビットを反転させ、それによって、最上位ビットが最下位ビットとなり、2番目の最上位ビットが2番目の最下位ビットとなり、以下同様である。関数は、0から2^32-1の範囲内で整数を拡散する性質を有し、ランダム拡散の場合よりも大きい距離により、短いシーケンスを拡散する。参照のために、関数は次のように実装され得る。
uint32_t reverse_bits(uint32_t x)
{
#define flip(x,mask,shift) ＼
((((x)&mask)<< shift)^(((x)&〜mask)>>shift))
x=flip(x,0x55555555,1);
x=flip(x,0x33333333,2);
x=flip(x,0x0f0f0f0f,4);
x=flip(x,0x00ff00ff,8);
x=flip(x,0x0000ffff,16);
return x;
#undef flip
}
実施形態による動作中、ブラウザを含む、ユーザエージェントから受信されたHTTP要求がRM121において分割され、チャンク要求がCM122に送られる。実施形態のCM122は、いつ新しいチャンク要求が送られ得るか、またどのオリジンサーバが新しいチャンク要求を処理することができるかを判断する。実施形態のRM121は、以下の条件に基づいてCM122に発信するチャンク要求をスケジュールする機会を得る。RM121がUA129から新しいデータダウンロード要求を受信したときはいつでも、すでに発信されたチャンク要求に関してデータが受信されたときはいつでも、および、CM122が同じまたは異なるオリジンサーバ向けにさらなる要求を発信する準備ができている可能性がある中、RM121がCM122にチャンク要求を無事発信したときはいつでも。実施形態による動作中、RM121は、UA129からの次の要求を選択して、チャンク要求を分割し、CM122にハンドオーバし、それによってRMは、要求スケジューリングアルゴリズムを使用してこれを達成することができる。実施形態の要求スケジューリングアルゴリズムの目標は、以下のとおりである。TA120が存在しないときにUA129からの接続が不足しない場合に、TA120が存在するときにUA129からの接続が不足しないようにする、(UA129とプロキシサーバとの間の)接続にわたる、またはオリジンサーバにわたる公平性を達成する、および作業維持のため(たとえば、少なくとも1つのフローがスケジューリング機会に処理され得る場合、少なくとも1つの要求が対応される)。実施形態のRM121によって異なるキューにわたって単純なラウンドロビンスケジューリングが使用され得る。実施形態の要求スケジューラは、対応される最後のキューを追跡し、別のチャンク要求をスケジュールする機会を与えられたとき、次のキューからヘッド要求を取り出し、その要求に対するオリジンサーバ向けの準備についてCM122をテストする。所望される場合、RM121によって採用されるより精巧なスケジューリングアルゴリズムが使用されることもある。
開始時に、要求スケジューラによって使用されるパラメータが、次のように初期化され得る。
current_queue_id=0を設定する。//対応される最後のキューを追跡する
CM122により要求をスケジュールする機会を与えられたとき、実施形態のRM121は、偽が戻されるまで、ループ中で以下を実行する。
//***ステップ1:アクティブなキューの順序付きリストを取得する。
//以下を有するキューのキューidのリストを作成する
//スケジュールされる必要のある残存要求。
ordered_queues=sort(get_active_queues())
if len(ordered_queues)==0
偽を戻す//スケジュールすべき要求なし
//***ステップ2:キューリストを処理順にする
// (すなわち、要求のために、その順序でキューをチェックする)
//以下になるように、ordered_queuesへの最小インデックスiを発見する
//ordered_queues[i]≧current_queue_id、または設定する
//そのようなiがない場合、i:=len(ordered_queues)
for i =0,...、len(ordered_queues):
if ordered_queues[i]≧current_queue_id、
中断する
//ordered_queuesを処理順に配列する
ordered_queues=ordered_queues[i:]+ordered_queues[:i]
//***ステップ3:発信すべき次の要求を発見する
//発信すべき要求のために、処理順にキューをチェックする
for ordered_queuesにおけるq
if CMがキューqのヘッドにおけるチャンク要求rを発信する準備ができている、
CMにチャンク要求rを発信する
current_queue_id=q+1
真を戻す
偽を戻す
実施形態のRM121内の並べ替え層194の目的は、上の構成要素への連続的な順序どおりのデータの配信を行うことである。UA129からの着信データダウンロード要求は、オリジンサーバに複数の接続を通じて送られる複数のチャンク要求にチャンクされるので、RM121に返信されるデータは順序どおりではないことがある。実施形態による動作中、並べ替え層194は、RM121内で内部的に受信されたデータをバッファリングし、上の層/構成要素に連続的データのみを配信する。実施形態の並べ替え層194は、データが順序どおりに配信され得るように各キューをバッファリングする。ただし、本明細書における実施形態によれば、1つのキューにおける欠落データが別のキューをブロックすべきではない。並べ替え層194のための論理が図12に示されている。
上記の例示的な実施形態によるRM121とCM122との間のアルゴリズム実行のための高レベル呼出しフローが、図13A、図13Bおよび図13Cに示されている。特に、図13Aは、本明細書における実施形態による、開始および終了の呼出しフローを示している。図13Bは、本明細書における実施形態による、トランスポートアクセラレータディスパッチャから加速された要求が受信されたときの呼出しフローを示している。図13Cは、本明細書における実施形態による、チャンクデータがスタックから受信されたとき、またはタイムアウトのときの呼出しフローを示している。
図14A、図14Bおよび図14Cは、smin=4およびsmaxOrg=20を使用する本明細書における実施形態のTA120を使用して単一のオリジンサーバに接続する単一のUAに関して生成されたグラフを示している。図14Aに示すエミュレーションでは、利用可能帯域幅は6656キロビット毎秒であり、パケット損失率は0.1%であり、往復時間は50ミリ秒である。このエミュレーションでは、Tの平均値は約80キロバイトであり、使用されるTCP接続の平均数は約4であり、達成される提示レートは約5000キロビットであり、これは利用可能帯域幅未満で可能な最高提示レートである。図14Bに示すエミュレーションでは、利用可能帯域幅は6656キロビット毎秒であり、パケット損失率は1%であり、往復時間は50ミリ秒である。このエミュレーションでは、Tの平均値は約120キロバイトであり、使用されるTCP接続の平均数は約7または8であり、達成される提示レートは約5000キロビットであり、これは利用可能帯域幅未満で可能な最高提示レートである。したがって、図14Bのエミュレーションを図14Aのエミュレーションと比較すると、同じ利用可能帯域幅および往復時間を有するが、図14Bでは図14Aと比較して損失率が高く、使用される接続の平均数がより高く、Tの値がより高いが、依然として妥当であり、依然として最高提示レートが達成されている。図14Cに示すエミュレーションでは、利用可能帯域幅は12288キロビット毎秒であり、パケット損失率は1%であり、往復時間は200ミリ秒である。このエミュレーションでは、Tの平均値は約1メガバイトであり、使用されるTCP接続の平均数は約20であり、達成される提示レートは約9500キロビットであり、これは利用可能帯域幅未満で可能な最高提示レートである。したがって、図14Cのエミュレーションを図14Bのエミュレーションと比較すると、利用可能帯域幅は2倍、往復時間は4倍であり、損失率は同じであり、使用される接続の平均数はより高く、Tの値は、増加した往復時間と利用可能帯域幅の積に比例してより高く、依然として最高提示レートは達成されている。
トランスポートアクセラレータの動作が、特定のインターフェースに関する使用のために変更または適合され得ることを諒解されたい。たとえば、本明細書における概念に従って実装されるCMの実施形態は、ネットワークインターフェースが3G/4G/LTEであるときに、ボトルネックが通常、ネットワークを使用する他のユーザ機器(UE)にとって有害とはならないPFAIR(Proportionate FAIRness)キューイングポリシーが適用される無線アクセスネットワークであることを知って、チャンク要求に関して非常に積極的になるように動作することができる。相応して、実施形態は、ネットワークインターフェースが、ネットワークを使用する他のさほど積極的ではないUEにとって有害となる可能性があるFIFOキューイングポリシーを使用する共有WiFiパブリックアクセスネットワークを介するときに、さほど積極的ではないCMを実装する。データが、コンテンツサーバへのネットワーク接続を通じて取得されるのではなく、ローカルストレージからアクセスされる場合(たとえば、以前のブロードキャストからキューイングされている場合)、トランスポートアクセラレータの実施形態は、ネットワーク接続に関して使用されるものとは非常に異なる設計であるローカルキャッシュからデータにアクセスするように適合されたCMを実装することができる。
図1Aに示す実施形態のRM121は、CM122の単一のインスタンスとインターフェースされるものとして示されているが、いくつかの実施形態のRM121は、図6の実施形態に示すような2つ以上のCMとインターフェースすることができる。そのようなCMは、たとえば、異なるネットワークインターフェースをサポートすることができる(たとえば、CM122aは、オンデバイスキャッシュ622へのローカルインターフェースを有することができ、CM122bは、WiFiネットワークインターフェースへのHTTP/TCP接続を使用することができ、CM122cは、4G/LTEネットワークインターフェースへのHTTP/TCP接続を使用することができる、などである)。追加または代替として、そのようなCMは、本質的に類似するネットワークインターフェース(たとえば、異なるWiFiリンク)を提供することができる。したがって、RM121は、複数のCMと同時にインターフェースすることができ、それによりRM121は、たとえば、複数のCMに同じフラグメントまたは一連のフラグメントのデータチャンクを要求するように動作可能であり得る(たとえば、データ要求の一部は、4G/LTEインターフェースへのHTTP/TCP接続を使用する第1のCM-xTCPに送られ、データ要求の一部は、WiFiインターフェースへのHTTP/TCP接続を使用する第2のCM-mHTTPに送られる)。RMは、CMの各々から受信されたデータを集めて、UAによって要求されたフラグメントを再構成し、UAに応答を返信することができる。
追加または代替として、図1Aに示す実施形態のCM122は、RM121の単一のインスタンスとインターフェースされるものとして示されているが、いくつかの実施形態のCM122は、2つ以上のそのようなRMと同時にインターフェースすることができる。たとえば、複数のRMは、各々がクライアントデバイス110の異なるUAのためのものであり、同じ1つまたは複数のCMを使用するように適合され得、それによってCMは、RMの同時動作から生じる接続の競合を解決するように適合され得る。代替的に、単一のRMは、複数のUAに関して使用するように適合され得、それによってRMは、UAの同時動作から生じる接続の競合を解決するように適合される。
選択された態様が詳細に示され説明されてきたが、以下の特許請求の範囲によって定義されるような本発明の趣旨および範囲から逸脱することなく、本明細書において様々な置換および改変を実施できることが理解されよう。
100 システム
110 クライアントデバイス、ユーザデバイス
111 プロセッサ
112 メモリ
113 入力/出力(I/O)要素
114 バス
120 トランスポートアクセラレータ(TA)
121 要求マネージャ(RM)
122 接続マネージャ(CM)
122a CM
122b CM
122c CM
123 インターフェース
124 インターフェース
129 UA
129a UA
129b UA
129c UA
129d UA
130 サーバ
130a コンテンツサーバ
130b コンテンツサーバ
140 データベース
141 コンテンツファイル
142 コンテンツファイル
143 コンテンツファイル
150 ネットワーク
151 接続、リンク
152 接続、リンク、ネットワーク接続
191a 要求キュー(RQ)
191b 要求キュー(RQ)
191c 要求キュー(RQ)
192 要求スケジューラ
193 要求チャンキングアルゴリズム
194 並べ替え層
195 Tvalueマネージャ
196 準備計算機
197 要求受信機/モニタ
200 フロー
622 オンデバイスキャッシュ
1021 プロキシサーバ
1022 ブラウザアダプタ
1023 スタック処理
1024 TA要求ディスパッチャ
1025 スタック処理
1026 ソケット層

Claims (58)

  1. クライアントデバイスのトランスポートアクセラレータ(TA)によって、コンテンツサーバから前記クライアントデバイスのユーザエージェント(UA)へのコンテンツの配信を加速するための方法であって、
    前記TAの接続マネージャ(CM)によって、前記コンテンツサーバから前記CMへの前記コンテンツの配信に使用される前記コンテンツのチャンクに関するターゲットコンテンツチャンクサイズ情報を決定するステップと、
    前記CMから前記TAの要求マネージャ(RM)に、前記決定されたターゲットコンテンツチャンクサイズ情報をシグナリングするステップであって、前記シグナリングは、前記CMが前記RMからの別のチャンク要求に対する準備ができていることをシグナリングすることに関連する、ステップと、
    前記UAによって提供されたフラグメント要求を、前記RMによって受信するステップと、
    前記CMから前記RMにシグナリングされた前記ターゲットコンテンツチャンクサイズ情報に基づいて、前記UAによって提供された前記フラグメント要求のコンテンツについてのチャンク要求の１つまたは複数のコンテンツチャンクのサイズを、前記RMによって決定するステップと、
    前記CMから前記RMにシグナリングされた前記ターゲットコンテンツチャンクサイズ情報に基づいて、前記RMによって決定されたサイズのコンテンツチャンクを要求するための複数のチャンク要求に、前記UAによって提供された前記フラグメント要求のそれぞれを、前記RMによって再分割するステップと、
    前記CMが前記コンテンツサーバに前記コンテンツのチャンクを要求するために、前記CMから前記RMにシグナリングされた前記ターゲットコンテンツチャンクサイズ情報に基づいて、前記RMによって決定された前記サイズを有するコンテンツチャンクのチャンク要求を、前記RMによって前記CMに提供するステップと、
    前記CMによって、前記CMと前記コンテンツサーバとの間で確立された複数の接続を介して前記コンテンツサーバに、前記RMによって決定された前記サイズを有する前記コンテンツの前記チャンクを要求するステップと
    を含む方法。
  2. 前記チャンク要求の１つまたは複数のコンテンツチャンクのサイズを前記RMによって決定するステップは、前記コンテンツサーバによって提供されたチャンク要求に対する応答に基づく、請求項1に記載の方法。
  3. 前記CMによって前記ターゲットコンテンツチャンクサイズ情報を決定するステップは、その接続を介して前記コンテンツサーバが即時に送ることができるデータの量に基づく、請求項1に記載の方法。
  4. 前記CMによって前記ターゲットコンテンツチャンクサイズ情報を決定するステップは、前記TAによって前記コンテンツサーバに提供されたアップストリームデータのオーバーヘッドに基づく、請求項1に記載の方法。
  5. 前記チャンク要求の前記コンテンツチャンクの最小サイズを決定するステップであって、前記最小サイズ未満のサイズのフラグメントが、1つのチャンク要求を使用して要求される、ステップをさらに含む、請求項1に記載の方法。
  6. 前記チャンク要求の前記コンテンツチャンクの最大サイズを決定するステップであって、フラグメントが、前記最大サイズ以下のサイズであるチャンク要求に区分される、ステップ
    をさらに含む、請求項1に記載の方法。
  7. 前記フラグメント要求の対応するフラグメントのサイズを取得する前に、少なくとも第1のチャンク要求を決定するステップ
    をさらに含む、請求項1に記載の方法。
  8. 前記CMによって前記ターゲットコンテンツチャンクサイズ情報を決定するステップは、前記フラグメント要求のフラグメントのサイズとは無関係である、請求項1に記載の方法。
  9. 前記CMによって前記ターゲットコンテンツチャンクサイズ情報を決定するステップは、前記コンテンツサーバがハイパーテキスト転送プロトコル(HTTP)チャンク要求を受信するとすぐに、前記コンテンツサーバが前記CMと前記コンテンツサーバとの間の伝送制御プロトコル(TCP)接続を介してHTTP応答全体を即時に送るのを容易にするサイズに基づく、請求項1に記載の方法。
  10. 前記CMによって前記ターゲットコンテンツチャンクサイズ情報を決定するステップは、前記CMによって行われたチャンクについての前記要求の順序による前記TAにおけるコンテンツのチャンクの到着を容易にするように適合されたサイズに基づく、請求項1に記載の方法。
  11. 前記CMによって、前記CMと前記コンテンツサーバとの間で確立された前記複数の接続のうちのいくつかの接続を動的に調整するステップ
    をさらに含む、請求項1に記載の方法。
  12. 複数の接続を介して前記コンテンツサーバに前記複数のチャンクのうちの前記チャンクを前記要求するステップは、前記複数の接続を介して並行して前記複数のチャンクを要求するステップを含む、請求項1に記載の方法。
  13. 前記複数のチャンクの連続するチャンク要求のサイズは、チャンク要求が同時に完了する可能性を低下させるために異なるように選択される、請求項12に記載の方法。
  14. 前記複数の接続のうちの第1の接続において前記コンテンツサーバによって完全には対応されていないチャンク要求は、少なくとも部分的に、前記複数の接続のうちの1つまたは複数の異なる接続を使用して再送される、請求項12に記載の方法。
  15. 前記CMによって、前記複数の接続の各接続の受信ウィンドウサイズを、前記接続の各々にほぼ同じダウンロードレートをもたらすように制御するステップ
    をさらに含む、請求項12に記載の方法。
  16. 前記CMによって、前記CMが別のチャンク要求を行う前に、前記複数の接続のうちの1つまたは複数の接続において考慮に入れるべき、要求されたがまだ受信されていないデータの最大量を計算するステップ
    をさらに含む、請求項1に記載の方法。
  17. 要求されたがまだ受信されていないデータの前記最大量を前記計算するステップは、
    要求された残存データ(B)が残っているときに、さらなるデータを要求するためのしきい値(Thresh)を決定するために、ダウンロードパイプラインレート(DPR)メトリックおよびダウンロードチャンクレート(DCR)メトリックを利用するステップ
    を含む、請求項16に記載の方法。
  18. 前記CMによって前記ターゲットコンテンツチャンクサイズ情報を決定するステップは、
    前記CMによって、ターゲットチャンクサイズを計算するステップ
    を含む、請求項1に記載の方法。
  19. 前記ターゲットチャンクサイズを前記計算するステップは、
    要求するチャンクのサイズを決定する際に使用されるターゲットチャンクサイズ(T)を決定するために、ダウンロードパイプラインレート(DPR)メトリックおよびダウンロードチャンクレート(DCR)メトリックを利用するステップ
    を含む、請求項18に記載の方法。
  20. 前記複数のチャンクのうちの前記チャンクを前記要求するステップは、
    前記複数の接続のうちの特定の接続においてコンテンツのチャンクについての次の要求を行うことを、その接続における以前の要求がすべて完了するまで控えるステップ
    を含む、請求項1に記載の方法。
  21. 前記複数のチャンクのうちの前記チャンクを前記要求するステップは、
    前記複数の接続のうちの特定の接続においてコンテンツのチャンクについての次の要求を、その接続における1つまたは複数の以前の要求がまだ完了していないときに行うステップ
    を含む、請求項1に記載の方法。
  22. クライアントデバイスのトランスポートアクセラレータ(TA)によって、コンテンツサーバから前記クライアントデバイスのユーザエージェント(UA)へのコンテンツの配信を加速するように構成された装置であって、
    前記TAの接続マネージャ(CM)によって、前記コンテンツサーバから前記CMへの前記コンテンツの配信に使用される前記コンテンツのチャンクに関するターゲットコンテンツチャンクサイズ情報を決定するための手段と、
    前記CMから前記TAの要求マネージャ(RM)に、前記決定されたターゲットコンテンツチャンクサイズ情報をシグナリングするための手段であって、前記シグナリングは、前記CMが前記RMからの別のチャンク要求に対する準備ができていることをシグナリングすることに関連する、手段と、
    前記UAによって提供されたフラグメント要求を、前記RMによって受信するための手段と、
    前記CMから前記RMにシグナリングされた前記ターゲットコンテンツチャンクサイズ情報に基づいて、前記UAによって提供された前記フラグメント要求のコンテンツについてのチャンク要求の１つまたは複数のコンテンツチャンクのサイズを、前記RMによって決定するための手段と、
    前記CMから前記RMにシグナリングされた前記ターゲットコンテンツチャンクサイズ情報に基づいて、前記RMによって決定されたサイズのコンテンツチャンクを要求するための複数のチャンク要求に、前記UAによって提供された前記フラグメント要求のそれぞれを、前記RMによって再分割するための手段と、
    前記CMが前記コンテンツサーバに前記コンテンツのチャンクを要求するために、前記CMから前記RMにシグナリングされた前記ターゲットコンテンツチャンクサイズ情報に基づいて、前記RMによって決定された前記サイズを有するコンテンツチャンクのチャンク要求を、前記RMによって前記CMに提供するための手段と、
    前記CMによって、前記CMと前記コンテンツサーバとの間で確立された複数の接続を介して前記コンテンツサーバに、前記RMによって決定された前記サイズを有する前記コンテンツの前記チャンクを要求するための手段と
    を含む装置。
  23. 前記チャンク要求の前記１つまたは複数のコンテンツチャンクのサイズを前記RMによって決定するための前記手段は、前記コンテンツサーバによって提供されたチャンク要求に対する応答に基づいて前記サイズを決定する、請求項22に記載の装置。
  24. 前記CMによって前記ターゲットコンテンツチャンクサイズ情報を決定するための前記手段は、その接続を介して前記コンテンツサーバが即時に送ることができるデータの量に基づいて前記ターゲットコンテンツチャンクサイズ情報を決定する、請求項22に記載の装置。
  25. 前記CMによって前記ターゲットコンテンツチャンクサイズ情報を決定するための前記手段は、前記TAによって前記コンテンツサーバに提供されたアップストリームデータのオーバーヘッドに基づいて前記前記ターゲットコンテンツチャンクサイズ情報を決定する、請求項22に記載の装置。
  26. 前記チャンク要求の前記コンテンツチャンクの最小サイズを決定するための手段であって、前記最小サイズ未満のサイズのフラグメントが、1つのチャンク要求を使用して要求される、手段
    をさらに含む、請求項22に記載の装置。
  27. 前記チャンク要求の前記コンテンツチャンクの最大サイズを決定するための手段であって、フラグメントが、前記最大サイズ以下のサイズであるチャンク要求に区分される、手段
    をさらに含む、請求項22に記載の装置。
  28. 前記フラグメント要求の対応するフラグメントのサイズを取得する前に、少なくとも第1のチャンク要求を決定するための手段
    をさらに含む、請求項22に記載の装置。
  29. 前記CMによって前記ターゲットコンテンツチャンクサイズ情報を決定するための前記手段は、前記フラグメント要求のフラグメントのサイズとは無関係に前記ターゲットコンテンツチャンクサイズ情報を決定する、請求項22に記載の装置。
  30. 前記CMによって前記ターゲットコンテンツチャンクサイズ情報を決定するための前記手段は、前記コンテンツサーバがハイパーテキスト転送プロトコル(HTTP)チャンク要求を受信するとすぐに、前記コンテンツサーバが前記CMと前記コンテンツサーバとの間の伝送制御プロトコル(TCP)接続を介してHTTP応答全体を即時に送るのを容易にするサイズに基づいて、前記ターゲットコンテンツチャンクサイズ情報を決定する、請求項22に記載の装置。
  31. 前記CMによって前記ターゲットコンテンツチャンクサイズ情報を決定するための前記手段は、前記CMによって行われたチャンクについての前記要求の順序による前記TAにおけるコンテンツのチャンクの到着を容易にするように適合されたサイズに基づいて、前記ターゲットコンテンツチャンクサイズ情報を決定する、請求項22に記載の装置。
  32. 前記CMによって、前記CMと前記コンテンツサーバとの間で確立された前記複数の接続のうちのいくつかの接続を動的に調整するための手段
    をさらに含む、請求項22に記載の装置。
  33. 複数の接続を介して前記コンテンツサーバに前記複数のチャンクのうちの前記チャンクを要求するための前記手段は、前記複数の接続を介して並行して前記複数のチャンクを要求するための手段を含む、請求項22に記載の装置。
  34. 前記複数のチャンクの連続するチャンク要求のサイズは、チャンク要求が同時に完了する可能性を低下させるために異なるように選択される、請求項33に記載の装置。
  35. 前記複数の接続のうちの第1の接続において前記コンテンツサーバによって完全には対応されていないチャンク要求は、少なくとも部分的に、前記複数の接続のうちの1つまたは複数の異なる接続を使用して再送される、請求項33に記載の装置。
  36. 前記CMによって、前記複数の接続の各接続の受信ウィンドウサイズを、前記接続の各々にほぼ同じダウンロードレートをもたらすように制御するための手段
    をさらに含む、請求項33に記載の装置。
  37. 前記CMによって、前記CMが別のチャンク要求を行う前に、前記複数の接続のうちの1つまたは複数の接続において考慮に入れるべき、要求されたがまだ受信されていないデータの最大量を計算するための手段
    をさらに含む、請求項22に記載の装置。
  38. 要求されたがまだ受信されていないデータの前記最大量を計算するための前記手段は、
    要求された残存データ(B)が残っているときに、さらなるデータを要求するためのしきい値(Thresh)を決定するために、ダウンロードパイプラインレート(DPR)メトリックおよびダウンロードチャンクレート(DCR)メトリックを利用するための手段
    を含む、請求項37に記載の装置。
  39. 前記ターゲットコンテンツチャンクサイズ情報を決定するための前記手段は、
    前記CMによってターゲットチャンクサイズを計算するための手段
    を含む、請求項22に記載の装置。
  40. 前記ターゲットチャンクサイズを計算するための前記手段は、
    要求するチャンクのサイズを決定する際に使用されるターゲットチャンクサイズ(T)を決定するために、ダウンロードパイプラインレート(DPR)メトリックおよびダウンロードチャンクレート(DCR)メトリックを利用するための手段
    を含む、請求項39に記載の装置。
  41. 前記複数のチャンクのうちの前記チャンクを要求するための前記手段は、
    前記複数の接続のうちの特定の接続においてコンテンツのチャンクについての次の要求を行うことを、その接続における以前の要求がすべて完了するまで控えるための手段
    を含む、請求項22に記載の装置。
  42. 前記複数のチャンクのうちの前記チャンクを要求するための前記手段は、
    前記複数の接続のうちの特定の接続においてコンテンツのチャンクについての次の要求を、その接続における1つまたは複数の以前の要求がまだ完了していないときに行うための手段
    を含む、請求項22に記載の装置。
  43. クライアントデバイスのトランスポートアクセラレータ(TA)によって、コンテンツサーバから前記クライアントデバイスのユーザエージェント(UA)へのコンテンツの配信を加速するためのコンピュータプログラムであって、
    前記TAの接続マネージャ(CM)によって、前記コンテンツサーバから前記CMへの前記コンテンツの配信に使用される前記コンテンツのチャンクに関するターゲットコンテンツチャンクサイズ情報を決定するためのプログラムコードと、
    前記CMから前記TAの要求マネージャ(RM)に、前記決定されたターゲットコンテンツチャンクサイズ情報をシグナリングするためのプログラムコードであって、前記ターゲットコンテンツチャンクサイズ情報の前記シグナリングは、前記CMが前記RMからの別のチャンク要求に対する準備ができていることをシグナリングすることに関連する、プログラムコードと、
    前記UAによって提供されたフラグメント要求を、前記RMによって受信するためのプログラムコードと、
    前記CMから前記RMにシグナリングされた前記ターゲットコンテンツチャンクサイズ情報に基づいて、前記UAによって提供された前記フラグメント要求のコンテンツについてのチャンク要求の１つまたは複数のコンテンツチャンクのサイズを、前記RMによって決定するためのプログラムコードと、
    前記CMから前記RMにシグナリングされた前記ターゲットコンテンツチャンクサイズ情報に基づいて、前記RMによって決定されたサイズのコンテンツチャンクを要求するための複数のチャンク要求に、前記UAによって提供された前記フラグメント要求のそれぞれを、前記RMによって再分割するためのプログラムコードと、
    前記CMが前記コンテンツサーバに前記コンテンツのチャンクを要求するために、前記CMから前記RMにシグナリングされた前記ターゲットコンテンツチャンクサイズ情報に基づいて、前記RMによって決定された前記サイズを有するコンテンツチャンクのチャンク要求を、前記RMによって前記CMに提供するためのプログラムコードと、
    前記CMによって、前記CMと前記コンテンツサーバとの間で確立された複数の接続を介して前記コンテンツサーバに、前記RMによって決定された前記サイズを有する前記コンテンツの前記チャンクを要求するためのプログラムコードと
    を含む、コンピュータプログラム。
  44. 前記チャンク要求の１つまたは複数のコンテンツチャンクの前記サイズを、前記RMによって決定するための前記プログラムコードは、前記コンテンツサーバによって提供されたチャンク要求に対する応答に基づいて前記サイズを決定する、請求項43に記載のコンピュータプログラム。
  45. 前記CMによって前記ターゲットコンテンツチャンクサイズ情報を決定するための前記プログラムコードは、その接続を介して前記コンテンツサーバが即時に送ることができるデータの量に基づいてターゲットコンテンツチャンクサイズを決定する、請求項43に記載のコンピュータプログラム。
  46. 前記フラグメント要求の対応するフラグメントのサイズを取得する前に、少なくとも第1のチャンク要求を決定するためのプログラムコード
    をさらに含む、請求項43に記載のコンピュータプログラム。
  47. 前記CMによって前記ターゲットコンテンツチャンクサイズ情報を決定するための前記プログラムコードは、前記フラグメント要求のフラグメントのサイズとは無関係にターゲットコンテンツチャンクサイズを決定する、請求項43に記載のコンピュータプログラム。
  48. 前記CMによって前記ターゲットコンテンツチャンクサイズ情報を決定するための前記プログラムコードは、前記コンテンツサーバがハイパーテキスト転送プロトコル(HTTP)チャンク要求を受信するとすぐに、前記コンテンツサーバが前記CMと前記コンテンツサーバとの間の伝送制御プロトコル(TCP)接続を介してHTTP応答全体を即時に送るのを容易にするサイズに基づいて、前記ターゲットコンテンツチャンクサイズ情報を決定する、請求項43に記載のコンピュータプログラム。
  49. 前記CMによって前記ターゲットコンテンツチャンクサイズ情報を決定するための前記プログラムコードは、前記CMによって行われたチャンクについての前記要求の順序による前記TAにおけるコンテンツのチャンクの到着を容易にするように適合されたサイズに基づいて、前記ターゲットコンテンツチャンクサイズ情報を決定する、請求項43に記載のコンピュータプログラム。
  50. 前記CMによって、前記CMと前記コンテンツサーバとの間で確立された前記複数の接続のうちのいくつかの接続を動的に調整するためのプログラムコード
    をさらに含む、請求項43に記載のコンピュータプログラム。
  51. 複数の接続を介して前記コンテンツサーバに前記複数のチャンクのうちの前記チャンクを要求するための前記プログラムコードは、前記複数の接続を介して並行して前記複数のチャンクを要求するためのプログラムコードを含み、前記複数のチャンクの連続するチャンク要求のサイズは、チャンク要求が同時に完了する可能性を低下させるために異なるように選択される、請求項43に記載のコンピュータプログラム。
  52. 前記CMによって、前記CMが別のチャンク要求を行う前に、前記1つまたは複数の接続において考慮に入れるべき、要求されたがまだ受信されていないデータの最大量を計算するためのプログラムコード
    をさらに含む、請求項43に記載のコンピュータプログラム。
  53. 要求されたがまだ受信されていないデータの前記最大量を計算するための前記プログラムコードは、
    要求された残存データ(B)が残っているときに、さらなるデータを要求するためのしきい値(Thresh)を決定するために、ダウンロードパイプラインレート(DPR)メトリックおよびダウンロードチャンクレート(DCR)メトリックを利用するためのプログラムコード
    を含む、請求項52に記載のコンピュータプログラム。
  54. ターゲットチャンクサイズ(T)を決定するために、ダウンロードパイプラインレート(DPR)メトリックおよびダウンロードチャンクレート(DCR)メトリックを使用して、前記CMによってターゲットチャンクサイズを計算するためのプログラムコード
    をさらに含む、請求項43に記載のコンピュータプログラム。
  55. クライアントデバイスのトランスポートアクセラレータ(TA)によって、コンテンツサーバから前記クライアントデバイスのユーザエージェント(UA)へのコンテンツの配信を加速するように構成された装置であって、
    少なくとも1つのプロセッサと、
    前記少なくとも1つのプロセッサに結合されたメモリと
    を含み、
    前記少なくとも1つのプロセッサは、
    前記TAの接続マネージャ(CM)によって、前記コンテンツサーバから前記CMへの前記コンテンツの配信に使用される前記コンテンツのチャンクに関するターゲットコンテンツチャンクサイズ情報を決定することと、
    前記CMから前記TAの要求マネージャ(RM)に、前記決定されたターゲットコンテンツチャンクサイズ情報をシグナリングすることであって、前記ターゲットコンテンツチャンクサイズ情報のシグナリングは、前記CMが前記RMからの別のチャンク要求に対する準備ができていることをシグナリングすることに関連する、シグナリングすることと、
    前記UAによって提供されたフラグメント要求を、前記RMによって受信することと、
    前記CMから前記RMにシグナリングされた前記ターゲットコンテンツチャンクサイズ情報に基づいて、前記UAによって提供された前記フラグメント要求のコンテンツについてのチャンク要求の１つまたは複数のコンテンツチャンクのサイズを、前記RMによって決定することと、
    前記CMから前記RMにシグナリングされた前記ターゲットコンテンツチャンクサイズ情報に基づいて、前記RMによって決定されたサイズのコンテンツチャンクを要求するための複数のチャンク要求に、前記UAによって提供された前記フラグメント要求のそれぞれを、前記RMによって再分割することと、
    前記CMが前記コンテンツサーバに前記コンテンツのチャンクを要求するために、前記CMから前記RMにシグナリングされた前記ターゲットコンテンツチャンクサイズ情報に基づいて、前記RMによって決定された前記サイズを有するコンテンツチャンクのチャンク要求を、前記RMによって前記CMに提供することと、
    前記CMによって、前記CMと前記コンテンツサーバとの間で確立された複数の接続を介して前記コンテンツサーバに、前記RMによって決定された前記サイズを有する前記コンテンツの前記チャンクを要求することと
    を行うように構成される、装置。
  56. 前記少なくとも1つのプロセッサは、
    前記CMと前記コンテンツサーバとの間で確立された前記複数の接続のうちのいくつかの接続を動的に調整すること
    を行うようにさらに構成される、請求項55に記載の装置。
  57. 前記少なくとも1つのプロセッサは、
    前記CMが別のチャンク要求を行う前に、前記複数の接続のうちの1つまたは複数の接続において考慮に入れるべき、要求されたがまだ受信されていないデータの最大量を計算することであって、要求されたがまだ受信されていないデータの前記最大量の計算が、要求された残存データ(B)が残っているときに、さらなるデータを要求するためのしきい値(Thresh)を決定するために、ダウンロードパイプラインレート(DPR)メトリックおよびダウンロードチャンクレート(DCR)メトリックを利用する、計算することを行うようにさらに構成される、請求項55に記載の装置。
  58. 前記少なくとも1つのプロセッサは、
    要求するチャンクのサイズを決定する際に使用されるターゲットチャンクサイズ(T)を決定するために、ダウンロードパイプラインレート(DPR)メトリックおよびダウンロードチャンクレート(DCR)メトリックを利用してターゲットチャンクサイズを計算するようにさらに構成される、請求項55に記載の装置。
JP2016557585A 2014-03-18 2015-03-17 要求マネージャおよび接続マネージャの機能を実装するトランスポートアクセラレータ Active JP6178523B2 (ja)

Applications Claiming Priority (5)

Application Number Priority Date Filing Date Title
US201461954970P 2014-03-18 2014-03-18
US61/954,970 2014-03-18
US14/289,403 US9596281B2 (en) 2014-03-18 2014-05-28 Transport accelerator implementing request manager and connection manager functionality
US14/289,403 2014-05-28
PCT/US2015/021056 WO2015142913A1 (en) 2014-03-18 2015-03-17 Transport accelerator implementing request manager and connection manager functionality

Publications (3)

Publication Number Publication Date
JP2017516188A JP2017516188A (ja) 2017-06-15
JP2017516188A5 JP2017516188A5 (ja) 2017-07-27
JP6178523B2 true JP6178523B2 (ja) 2017-08-09

Family

ID=54143213

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2016557585A Active JP6178523B2 (ja) 2014-03-18 2015-03-17 要求マネージャおよび接続マネージャの機能を実装するトランスポートアクセラレータ

Country Status (6)

Country Link
US (1) US9596281B2 (ja)
EP (1) EP3120521A1 (ja)
JP (1) JP6178523B2 (ja)
KR (1) KR101746056B1 (ja)
CN (1) CN106134147A (ja)
WO (1) WO2015142913A1 (ja)

Families Citing this family (29)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10237334B2 (en) * 2013-01-07 2019-03-19 Akamai Technologies, Inc. Connected-media end user experience using an overlay network
US9819648B1 (en) 2014-10-21 2017-11-14 Amazon Technologies, Inc. Secure content delivery
US10708331B1 (en) * 2014-12-19 2020-07-07 Amazon Technologies, Inc. Generating requests for streaming media
WO2017081673A1 (en) * 2015-11-12 2017-05-18 Giraffic Technologies Ltd. Download acceleration using dynamic number of connections and dynamic chunk size
US10554761B2 (en) * 2015-12-12 2020-02-04 At&T Intellectual Property I, Lp Methods and apparatus to improve transmission of a field data set to a network access point via parallel communication sessions
US9813299B2 (en) * 2016-02-24 2017-11-07 Ciena Corporation Systems and methods for bandwidth management in software defined networking controlled multi-layer networks
US9866459B1 (en) * 2016-03-04 2018-01-09 Amazon Technologies, Inc. Origin failover for live streaming
DE102016214671B3 (de) 2016-08-08 2017-12-21 Audi Ag Verfahren zum Übertragen einer Datei zwischen einer Steuervorrichtung eines Kraftfahrzeugs und einer fahrzeugexternen Servervorrichtung, Steuervorrichtung und Kraftfahrzeug
US10264044B2 (en) * 2016-08-29 2019-04-16 Comcast Cable Communications, Llc Apparatus and method for sending content as chunks of data to a user device via a network
US10225161B2 (en) * 2016-10-31 2019-03-05 Accedian Networks Inc. Precise statistics computation for communication networks
US10423632B2 (en) * 2017-07-19 2019-09-24 Facebook, Inc. Systems and methods for incrementally downloading augmented-reality effects
US10303384B1 (en) * 2017-11-28 2019-05-28 Western Digital Technologies, Inc. Task readiness for queued storage tasks
US10887387B2 (en) * 2018-01-05 2021-01-05 Barrett Adams Digital media synchronization system and method
US10277924B1 (en) 2018-03-22 2019-04-30 Amazon Technologies, Inc. Stitching content streams together
CN110519553B (zh) * 2018-05-22 2021-02-26 杭州海康威视数字技术股份有限公司 视频流转发控制方法、装置、电子设备及可读存储介质
US11595456B2 (en) * 2018-05-31 2023-02-28 Microsoft Technology Licensing, Llc Modifying content streaming based on device parameters
US11204909B2 (en) * 2018-07-26 2021-12-21 Sap Se Internal tables for accessing data stored in a database
KR102323763B1 (ko) * 2019-01-04 2021-11-08 바이두닷컴 타임즈 테크놀로지(베이징) 컴퍼니 리미티드 호스트 시스템과 데이터 처리 가속기 사이의 보안 통신을 제공하기 위한 방법 및 시스템
CN111835683B (zh) * 2019-04-19 2021-10-15 上海哔哩哔哩科技有限公司 连接控制方法、系统、设备及计算机可读存储介质
CN111835682B (zh) 2019-04-19 2021-05-11 上海哔哩哔哩科技有限公司 连接控制方法、系统、设备及计算机可读存储介质
KR102622252B1 (ko) * 2019-05-27 2024-01-08 삼성에스디에스 주식회사 콘텐츠 전송 장치 및 방법
CN110149560B (zh) * 2019-06-05 2021-11-16 亦非云互联网技术（上海）有限公司 基于hls协议的播放器优化方法及系统、存储介质及终端
CN110535853B (zh) * 2019-08-28 2021-06-22 北京奇艺世纪科技有限公司 一种视频请求调度方法、装置、服务器及存储介质
US11256423B2 (en) * 2019-10-14 2022-02-22 Western Digital Technologies, Inc. Efficiently identifying command readiness based on system state and data spread in multi queue depth environment
US11140060B2 (en) * 2019-11-12 2021-10-05 Hulu, LLC Dynamic variation of media segment durations for optimization of network round trip times
CN111131019B (zh) * 2019-12-12 2021-06-22 华为技术有限公司 一种多路http通道复用的方法及终端
US11102289B2 (en) * 2020-01-03 2021-08-24 Wangsu Science & Technology Co., Ltd. Method for managing resource state information and system for downloading resource
CN111988235B (zh) * 2020-08-13 2023-05-09 暨南大学 一种基于多http/3连接的并行传输方法
US20220212100A1 (en) * 2021-01-04 2022-07-07 Microsoft Technology Licensing, Llc Systems and methods for streaming interactive applications

Family Cites Families (48)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6990069B1 (en) 1997-02-24 2006-01-24 At&T Corp. System and method for improving transport protocol performance in communication networks having lossy links
AU2001238419A1 (en) * 2000-02-16 2001-08-27 Microsoft Corporation System and method for transferring data over a network
EP1313318A1 (en) 2000-08-25 2003-05-21 Matsushita Electric Industrial Co., Ltd. Data transmission method and data relay method
US20020107971A1 (en) * 2000-11-07 2002-08-08 Bailey Brian W. Network transport accelerator
US7502860B1 (en) 2001-07-09 2009-03-10 Cisco Technology, Inc. Method and apparatus for client-side flow control in a transport protocol
EP1671424B1 (en) 2003-10-08 2012-06-06 Digital Fountain, Inc. Fec-based reliability control protocols
US7818444B2 (en) * 2004-04-30 2010-10-19 Move Networks, Inc. Apparatus, system, and method for multi-bitrate content streaming
US8868772B2 (en) 2004-04-30 2014-10-21 Echostar Technologies L.L.C. Apparatus, system, and method for adaptive-rate shifting of streaming content
CN101014947A (zh) * 2004-04-30 2007-08-08 移动网络有限公司 一种关于流内容的自适应速率切换的装置、系统和方法
US7487353B2 (en) * 2004-05-20 2009-02-03 International Business Machines Corporation System, method and program for protecting communication
CN101005371A (zh) * 2006-01-19 2007-07-25 思华科技（上海）有限公司 流媒体的缓存方法及系统
US8676882B2 (en) 2007-02-27 2014-03-18 Sony Corporation System and method for preloading content segments to client devices in an electronic network
US9178535B2 (en) * 2006-06-09 2015-11-03 Digital Fountain, Inc. Dynamic stream interleaving and sub-stream based delivery
US9209934B2 (en) * 2006-06-09 2015-12-08 Qualcomm Incorporated Enhanced block-request streaming using cooperative parallel HTTP and forward error correction
KR101366803B1 (ko) * 2007-04-16 2014-02-24 삼성전자주식회사 Ｈｔｔｐ를 이용한 통신 방법 및 장치
US9655003B2 (en) 2009-03-19 2017-05-16 Georgia Tech Research Corporation Systems and methods for improved wireless interface aggregation
US20120327779A1 (en) 2009-06-12 2012-12-27 Cygnus Broadband, Inc. Systems and methods for congestion detection for use in prioritizing and scheduling packets in a communication network
US9015564B2 (en) 2009-08-19 2015-04-21 Qualcomm Incorporated Content delivery system with allocation of source data and repair data among HTTP servers
US9917874B2 (en) * 2009-09-22 2018-03-13 Qualcomm Incorporated Enhanced block-request streaming using block partitioning or request controls for improved client-side handling
CN101719809B (zh) 2009-11-25 2012-10-10 中兴通讯股份有限公司 一种媒体数据包丢包恢复的方法及系统
EP2362651A1 (en) * 2010-02-19 2011-08-31 Thomson Licensing Multipath delivery for adaptive streaming
US8396126B2 (en) 2010-06-18 2013-03-12 Cisco Technology, Inc. Systems and methods for video coding and transmission
CN102143137A (zh) 2010-09-10 2011-08-03 华为技术有限公司 媒体流发送及接收方法、装置和系统
US8750188B2 (en) 2010-12-01 2014-06-10 Deutsche Telekom Ag System support for accessing and switching among multiple wireless interfaces on mobile devices
US8873385B2 (en) 2010-12-07 2014-10-28 Microsoft Corporation Incast congestion control in a network
US11025962B2 (en) 2011-02-28 2021-06-01 Adobe Inc. System and method for low-latency content streaming
US9203892B2 (en) * 2011-04-19 2015-12-01 Accenture Global Services Limited Content transfer accelerator
KR20130005873A (ko) 2011-07-07 2013-01-16 삼성전자주식회사 방송 시스템에서 컨텐츠 수신 방법 및 장치
US9172659B1 (en) * 2011-07-12 2015-10-27 Marvell Israel (M.I.S.L.) Ltd. Network traffic routing in a modular switching device
US9253233B2 (en) 2011-08-31 2016-02-02 Qualcomm Incorporated Switch signaling methods providing improved switching between representations for adaptive HTTP streaming
EP2566172A1 (en) 2011-09-02 2013-03-06 Thomson Licensing Method and apparatus for adaptive transcoding of multimedia stream
US9182935B2 (en) 2011-09-27 2015-11-10 Z124 Secondary single screen mode activation through menu option
US8897753B2 (en) 2011-10-12 2014-11-25 Motorola Mobility Llc Method for retrieving content by a wireless communication device having first and second radio access interfaces, wireless communication device and communication system
KR101591238B1 (ko) 2011-11-01 2016-02-18 퀄컴 인코포레이티드 Ｈｔｔｐ 서버들 사이의 소스 데이터 및 리페어 데이터의 할당에 의한 컨텐츠 전달 시스템
CN104094561B (zh) * 2011-12-01 2017-12-12 汤姆逊许可公司 通过根据可用带宽选择传输协议来获得内容的设备
EP2615790A1 (en) 2012-01-12 2013-07-17 Alcatel Lucent Method, system and devices for improved adaptive streaming of media content
US9401968B2 (en) 2012-01-20 2016-07-26 Nokia Techologies Oy Method and apparatus for enabling pre-fetching of media
US9386058B2 (en) 2012-02-27 2016-07-05 Qualcomm Incorporated DASH client and receiver with playback rate selection
US9374406B2 (en) * 2012-02-27 2016-06-21 Qualcomm Incorporated Dash client and receiver with a download rate estimator
US20130227102A1 (en) 2012-02-29 2013-08-29 Alcatel-Lucent Usa Inc Chunk Request Scheduler for HTTP Adaptive Streaming
US9009260B2 (en) 2012-05-10 2015-04-14 Blackberry Limited Method, system and apparatus for transferring data via more than one communications interface
US20130311614A1 (en) * 2012-05-21 2013-11-21 Motorola Mobility, Inc. Method for retrieving content and wireless communication device for performing same
US10009445B2 (en) 2012-06-14 2018-06-26 Qualcomm Incorporated Avoiding unwanted TCP retransmissions using optimistic window adjustments
US9363132B2 (en) * 2013-04-24 2016-06-07 International Business Machines Corporation Maximizing throughput of streaming media by simultaneously connecting to streaming media server over multiple independent network connections
KR102164457B1 (ko) 2013-04-25 2020-10-14 삼성전자주식회사 다중 무선 억세스를 위한 전자 장치 및 그 방법
EP2833640A1 (en) * 2013-08-02 2015-02-04 British Telecommunications public limited company Video caching
US9800638B2 (en) * 2013-11-04 2017-10-24 At&T Intellectual Property I, L.P. Downstream bandwidth aware adaptive bit rate selection
US9699236B2 (en) * 2013-12-17 2017-07-04 At&T Intellectual Property I, L.P. System and method of adaptive bit-rate streaming

Also Published As

Publication number Publication date
KR20160134680A (ko) 2016-11-23
JP2017516188A (ja) 2017-06-15
KR101746056B1 (ko) 2017-06-12
US9596281B2 (en) 2017-03-14
EP3120521A1 (en) 2017-01-25
US20150271232A1 (en) 2015-09-24
CN106134147A (zh) 2016-11-16
WO2015142913A1 (en) 2015-09-24

Similar Documents

Publication Publication Date Title
JP6178523B2 (ja) 要求マネージャおよび接続マネージャの機能を実装するトランスポートアクセラレータ
US9930097B2 (en) Transport accelerator systems and methods
US10700995B2 (en) System and method for improving an aggregated throughput of simultaneous connections
US8717890B2 (en) Application, usage and radio link aware transport network scheduler
KR102050816B1 (ko) 통신 네트워크에서 강화된 체감 품질을 위해 클라이언트 측 비디오 버퍼 점유율을 사용하기 위한 방법 및 시스템
US9596323B2 (en) Transport accelerator implementing client side transmission functionality
US9203888B2 (en) Server-side class-of-service-based bandwidth management in over-the-top video delivery
JP2019520745A5 (ja)
US20150271226A1 (en) Transport accelerator implementing a multiple interface architecture
Kim et al. Multipath-based HTTP adaptive streaming scheme for the 5G network
Kim et al. Collective Segment Request Policy of HTTP Adaptive Streaming in Multipath Environments

Legal Events

Date Code Title Description
A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20170529

A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20170529

A871 Explanation of circumstances concerning accelerated examination

Free format text: JAPANESE INTERMEDIATE CODE: A871

Effective date: 20170529

A975 Report on accelerated examination

Free format text: JAPANESE INTERMEDIATE CODE: A971005

Effective date: 20170609

TRDD Decision of grant or rejection written
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20170619

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20170713

R150 Certificate of patent or registration of utility model

Ref document number: 6178523

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R150

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250