JP6147939B1 - 冗長符号化コンテンツデータ機能の選択的な利用を実施するトランスポートアクセラレータ - Google Patents

Abstract

クライアントデバイスのユーザエージェント(UA)へのコンテンツの配信のためのトランスポートアクセラレータ(TA)システムおよび方法が、本開示の実施形態に従って提供される。実施形態は、コンテンツサーバにコンテンツを要求するためにUAによって提供されるフラグメントリクエストを、TAのリクエストマネージャ(RM)によって受信し、フラグメントを復元する際にRMによって使用するために、フラグメントリクエストのうちのフラグメントリクエストに対して要求するための、冗長符号化コンテンツデータの量を決定する。

Description

優先権および関連出願の陳述
本出願は、同時係属の、2014年3月18日に出願された「TRANSPORT ACCELERATOR IMPLEMENTING SELECTIVE UTILIZATION OF REDUNDANT ENCODED CONTENT DATA FUNCTIONALITY」という名称の米国仮特許出願第61/954,987号、および2014年5月28日に出願された「TRANSPORT ACCELERATOR IMPLEMENTING SELECTIVE UTILIZATION OF REDUNDANT ENCODED CONTENT DATA FUNCTIONALITY」という名称の米国特許出願第14/289,458号の優先権を主張し、それらの開示は参照により本明細書に組み込まれる。本出願は、同一出願人による、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 REQUEST MANAGER AND CONNECTION MANAGER FUNCTIONALITY」という名称の第14/289,403号、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つの制約が顕著である。第1に、メディアのセグメントが、時間とともに次々に利用可能になる。この制約は、クライアントがデータの大きい部分を継続的にダウンロードすることを妨げ、そのことがダウンロードレート推定の精度に影響を及ぼす。ほとんどのストリーミングクライアントが「リクエストダウンロード推定」ループで動作するので、ダウンロード推定が不正確であるとき、それは概してうまく行われない。第2に、ライブイベントストリーミングを閲覧しているとき、ユーザは、一般に、実際のライブイベントタイムラインからの長い遅延を受けることを望まない。そのような挙動は、ストリーミングクライアントが大きいバッファを増強させることを妨げ、そのことがより多くのリバッファリングを引き起こす場合がある。

ストリーミングクライアントがトランスポート制御プロトコル(TCP)の上で動作する場合(ほとんどの動的適応ストリーミングオーバーHTTP(DASH)クライアントが行うように)、クライアントは、通常、推定される利用可能性スケジュールに基づいてフラグメントを要求する。フラグメントのパケットが受信されない場合、データの送信を遅らせるために既存のTCPプロトコルが利用され、パケットの中で搬送された消失データを再要求する。たとえば、受信機は、NextByteExpectedまで確認応答(ACK)するだけであり、ここで、NextByteExpectedは、消失パケットの中で搬送されたフラグメントのデータの最初のバイトを指す。その後、NextByteExpectedを超えるデータを搬送するがフラグメントのバイトNextByteExpectedを含まず順序が乱れたパケットが受信された場合、受信機はNextByteExpectedに対応する重複ACKを送り出し、送信側はそのような重複ACKをネットワークでの輻輳のサインとして解釈し、したがって、輻輳ウィンドウを縮小することにより送信レートを減速する。したがって、そのようなデータの再送信に関係する遅延に起因するだけでなく、送信レートがネットワーク輻輳の関連した検出に応答してよく遅くされることにも起因して、コンテンツデータの消失したまたは遅延した部分の復元は問題を抱えることがある。

冗長符号化データ技法(たとえば、前方誤り訂正(FEC)コーディング)を使用すると、少なくともいくつかのレベルのコンテンツデータがクライアントによって受信されないことに事前に対処することが可能であり得るが、ストリーミングコンテンツに適用されるときにそのような技法を使用する場合、注意されなければならない。プロトコルの設計に応じて、冗長符号化データを事前に送ることは、潜在的に消失したデータの復元をサポートするためのデータ符号化の冗長性に起因してさらなる帯域幅を消費し得る。しかしながら、そのような冗長性を有しないストリーミングコンテンツは、特に、ライブストリーミングに適用され、下位配信プロトコルとしてTCPを使用するとき、望ましくないエンドツーエンドのレイテンシを受ける場合がある。上記のことは、具体的には、データの配信を保証するためのプロトコルの動作に起因してストリーミングクライアントがTCPを介して(たとえば、DASHクライアントとして)動作する場合であるが、おそらくは、遅延した配信またはレートが低減された配信を伴う。

クライアントデバイスのユーザエージェント(UA)へのコンテンツの配信を、クライアントデバイスのトランスポートアクセラレータ(TA)によって加速するための方法が、本開示の実施形態に従って提供される。実施形態の方法は、コンテンツサーバにコンテンツを要求するためにUAによって提供されるフラグメントリクエストを、TAのリクエストマネージャ(RM)によって受信することと、フラグメントを復元する際にRMによって使用するためのフラグメントリクエストのうちのフラグメントリクエストに対して、要求するべき冗長符号化コンテンツデータの量を決定することとを含む。

クライアントデバイスのユーザエージェント(UA)へのコンテンツの配信を、クライアントデバイスのトランスポートアクセラレータ(TA)によって加速するために構成された装置が、本開示の実施形態に従って提供される。実施形態の装置は、コンテンツサーバにコンテンツを要求するためにUAによって提供されるフラグメントリクエストを、TAのリクエストマネージャ(RM)によって受信するための手段と、フラグメントを復元する際にRMによって使用するためのフラグメントリクエストのうちのフラグメントリクエストに対して、要求するべき冗長符号化コンテンツデータの量を決定するための手段とを含む。

クライアントデバイスのユーザエージェント(UA)へのコンテンツの配信を、クライアントデバイスのトランスポートアクセラレータ(TA)によって加速するためのコンピュータプログラム製品が、本開示の実施形態に従って提供される。コンピュータプログラム製品は、プログラムコードを記録した非一時的コンピュータ可読媒体を含む。実施形態のプログラムコードは、コンテンツサーバにコンテンツを要求するためにUAによって提供されるフラグメントリクエストを、TAのリクエストマネージャ(RM)によって受信するためのプログラムコードと、フラグメントを復元する際にRMによって使用するためのフラグメントリクエストのうちのフラグメントリクエストに対して、要求するべき冗長符号化コンテンツデータの量を決定するためのプログラムコードとを含む。

クライアントデバイスのユーザエージェント(UA)へのコンテンツの配信を、クライアントデバイスのトランスポートアクセラレータ(TA)によって加速するために構成された装置が、本開示の実施形態に従って提供される。装置は、少なくとも1つのプロセッサ、および少なくとも1つのプロセッサに結合されたメモリを含む。実施形態の少なくとも1つのプロセッサは、コンテンツサーバにコンテンツを要求するためにUAによって提供されるフラグメントリクエストを、TAのリクエストマネージャ(RM)によって受信し、フラグメントを復元する際にRMによって使用するためのフラグメントリクエストのうちのフラグメントリクエストに対して、要求するべき冗長符号化コンテンツデータの量を決定するように構成される。

本開示の実施形態による、冗長符号化コンテンツデータの選択的な利用を実施するトランスポートアクセラレータによるコンテンツの転送を提供するように適合されたシステムを示す図である。 本開示の実施形態のトランスポートアクセラレータの固定冗長符号化コンテンツデータ構成リクエストマネージャの動作を示すフロー図である。 本開示の実施形態のトランスポートアクセラレータの自動冗長符号化コンテンツデータ構成リクエストマネージャの動作を示すフロー図である。 本開示の実施形態による、受信された保留中の遅れたデータを示すタイムラインを示す図である。 本開示の実施形態のリクエストマネージャとユーザエージェントとの間に実装され得るようなアプリケーションプログラミングインターフェースを示す図である。 本開示の実施形態による、別個のソースまたはプロバイダによって冗長符号化コンテンツデータが提供される、冗長符号化コンテンツデータの選択的な利用を実施するトランスポートアクセラレータによるコンテンツの転送を提供するように適合されたシステムを示す図である。

「例示的」という言葉は、「例、事例、または例示として働く」ことを意味するように本明細書において使用される。「例示的」として本明細書で説明するいずれの態様も、必ずしも他の態様よりも好ましいか、または有利であると解釈されるとは限らない。

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

この説明で使用されるとき、「コンテンツ」という用語は、ビデオ、オーディオ、ビデオとオーディオの組合せ、または1つまたは複数の品質レベルにおける他のデータを有するデータを含み得、品質レベルは、ビットレート、解像度、または他のファクタによって決定される。コンテンツはまた、オブジェクトコード、スクリプト、バイトコード、マークアップ言語ファイル、およびパッチなどの、実行可能コンテンツを含み得る。加えて、「コンテンツ」はまた、オープンされることが必要な場合があるドキュメント、またはアクセスされる必要がある他のデータファイルなどの、本質的に実行可能でないファイルを含み得る。

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

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

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

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

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

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

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

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

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

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

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

TA120は、所望のコンテンツのフラグメント(たとえば、ビデオストリーミング、ファイルダウンロード、ウェブベースのアプリケーション、一般のウェブページなどを提供する際に使用され得るような、上述のコンテンツフラグメント)、またはフラグメントのシーケンスの拡張配信を提供するように、本明細書の概念に従って適合される。実施形態のTA120は、標準化されたTCP伝送プロトコルを実装するHTTP1.1インターフェースなどの標準インターフェースのみをサポートする汎用UAまたはレガシーUA(すなわち、TAと相互作用するように事前設計されていないUA)が、それにもかかわらず、そのリクエストを実行するTAを使用することから利益を得るためのフラグメントリクエストを行うことを可能にするように適合される。付加的または代替的には、実施形態のTA120は拡張インターフェースを備えて、拡張インターフェースの機能性を利用するように設計されているUAにさらなる利点をもたらすことを容易にする。実施形態のTA120は、標準化されたTCP伝送プロトコルを実装するHTTPインターフェースを介してTCPを使用するような既存のコンテンツ転送プロトコルに従って、フラグメントリクエストを実行するように適合され、それによって、フラグメントの拡張配信をUAおよびクライアントデバイスに提供しながら、汎用メディアサーバまたはレガシーメディアサーバ(すなわち、TAと相互作用するように事前設計されていないメディアサーバ)がリクエストをサービスすることを可能にする。

上記の拡張フラグメント配信機能を提供する際に、本明細書の実施形態のTA120は、本明細書で説明するような構造上の構成要素およびプロトコルを備える。たとえば、図1に示す本実施形態の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を使用してサーバ130とネットワーク150経由で通信して、描画されるときにコンテンツの再生をもたらすコンテンツデータ(たとえば、上述のフラグメントのような)を取得する。したがって、UA129は、コンテンツ再生環境をクライアントデバイス110の中に確立するために、プロセッサ111によって実行されるコンテンツプレーヤアプリケーションを備え得る。特定のコンテンツファイルの再生を開始するとき、UA129は、サーバ130のコンテンツ配信プラットフォームと通信して、コンテンツ識別子(たとえば、1つまたは複数のリスト、マニフェスト、構成ファイル、または所望のコンテンツのメディアセグメントもしくはフラグメント、およびそれらのタイミング境界を識別する他の識別子)を取得し得る。メディアセグメントおよびそれらのタイミングに関する情報がUA129のストリーミングコンテンツ論理によって使用されて、コンテンツの再生用のフラグメントの要求を制御する。

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

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

ネットワーク150は、ワイヤレスネットワーク、有線ネットワーク、ワイドエリアネットワーク(WAN)、ローカルエリアネットワーク(LAN)、または本明細書で説明するようなコンテンツの転送にとって好適な任意の他のネットワークであってよい。一実施形態では、ネットワーク150は、インターネットの少なくとも部分を備えることができる。クライアントデバイス110は、ネットワーク接続151によって表されるような双方向接続を介してネットワーク150に接続され得る。あるいは、クライアントデバイス110は、マルチメディアブロードキャストマルチメディアシステム(MBMS)対応のネットワークによって提供されるものなどの単方向接続によって接続されてよい(たとえば、接続151、152およびネットワーク150がMBMSネットワークを備えてよく、サーバ130がブロードキャストマルチキャストサービスセンター(BM-SC)サーバを備えてよい)。接続は有線接続であってよく、またはワイヤレス接続であってもよい。一実施形態では、接続151は、セルラー4G接続、ワイヤレスフィデリティー(WiFi)接続、Bluetooth(登録商標)接続、または別のワイヤレス接続などの、ワイヤレス接続であってよい。サーバ130は、ネットワーク接続152によって表されるような双方向接続を介してネットワーク150に接続され得る。サーバ130は、単方向接続を介してネットワーク150(たとえば、3GPP TS.26.346に記載されるようなプロトコルおよびサービスを使用するMBMSネットワークまたはATSC 3.0ネットワーク)に接続されてよい。接続は有線接続であってよく、またはワイヤレス接続であってもよい。

図1に示す本実施形態のクライアントデバイス110は、本明細書の概念による所望のコンテンツのフラグメントまたはフラグメントのシーケンスの拡張配信を提供するように動作可能なTA120を備える。上記で説明したように、図示の実施形態のTA120は、様々な拡張フラグメント配信機能を提供するように協働するRM121およびCM122を備える。実施形態のUA129とRM121との間のインターフェース124およびRM121とCM122との間のインターフェース123は、HTTPのような接続を提供する。たとえば、上記のインターフェースは、標準的なHTTPプロトコルを採用し得るだけでなく、本明細書の実施形態による拡張フラグメント配信のいくつかの機能的態様をサポートするための追加のシグナリング(たとえば、HTTPのものと類似のシグナリング技法を使用して提供される)を含む。

実施形態による動作の際には、RM121は、フラグメントを得るためのリクエストをUA129から受信し、要求されているフラグメントを確実に受信および復元するためにどのデータをCM122に要求するべきかを決定する。本明細書の実施形態によれば、RM121は、汎用UAまたはレガシーUA(すなわち、RMと相互作用するように事前設計されていないUA)からのフラグメントリクエストを受信しそれに応答するように適合され、それによって、そのようなレガシーUAとの互換性をもたらす。したがって、RM121は、TA120の拡張された伝送プロトコル動作からUA129を分離するように動作し得る。しかしながら、以下の説明からより完全に理解されるように、UA129は、拡張された伝送プロトコル動作のために適合され得、それにおいて、RM121およびUA129は、そのような機能を実施するためにRM121とUA129との間でのシグナリングの使用などを通じて、拡張された伝送プロトコル動作の1つまたは複数の機能を実施するように協働する。

実施形態のRM121によってCM122に対して行われるデータリクエスト(本明細書で「チャンクリクエスト」と呼ばれ、要求されるデータは「チャンク」を備える)のサイズは、UA129によって要求されるフラグメントのサイズよりもずっと小さくてよく、そのフラグメントをRM121が復元している。したがって、UA129からの各フラグメントリクエストは、複数のチャンクリクエストを生成しそれをCM122に対して行って、そのフラグメントを復元するように、RM121をトリガし得る。

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に要求することなどのために、同時に1つを超えるCMとインターフェースし得る。そのような各CMは、たとえば、異なるネットワークインターフェースをサポートし得る(たとえば、第1のCMがオンデバイスキャッシュへのローカルインターフェースを有してよく、第2のCMが3GネットワークインターフェースへのHTTP/TCP接続を使用してよく、第3のCMが4G/LTEネットワークインターフェースへのHTTP/TCP接続を使用してよく、第4のCMがWiFiネットワークインターフェースへのHTTP/TCP接続使用してよく、以下同様である)。

実施形態による動作の際には、CM122は、RM121とインターフェースしてチャンクリクエストを受信し、それらのリクエストをネットワーク150を介して送る。CM122は、チャンクリクエストへのレスポンスを受信するとともにレスポンスをRM121に伝え戻し、UA129によるフラグメントリクエストは、受信されたチャンクから解決される。CM122の機能は、RM121によって行われたチャンクリクエストのデータをいつ要求するべきかを決定するように動作する。本明細書の実施形態によれば、CM122は、チャンクを汎用サーバまたはレガシーサーバ(すなわち、TAと相互作用するように事前設計されていないサーバ)に要求し、チャンクを受信するように適合される。たとえば、CM122がデータを要求するサーバは、標準的なHTTPウェブサーバを備え得る。あるいは、CM122がデータを受信するサーバは、MBMSサービス配置において使用されるBM-SCサーバを備え得る。

上記で説明したRM121と同じく、実施形態による様々な構成のCMがあり得る。たとえば、複数接続CM構成(たとえば、CM-mHTTP)が形成されてよく、それにおいて、CMは複数のTCP接続を介してHTTPを使用するように適合される。複数接続CM構成は、ネットワーク状態、データに対する要求、輻輳ウィンドウなどに応じて、接続(たとえば、TCP接続)の数を動的に変化させるように動作し得る。別の例として、拡張された伝送プロトコルCM構成(たとえば、CM-xTCP)が形成されてよく、CMはTCP接続の拡張された形式(本明細書で、xTCPと呼ばれる)の上部でHTTPを使用する。そのような拡張された伝送プロトコルは、本明細書の概念によるTA120によるフラグメントの拡張配信を容易にするように適合された動作を提供し得る。たとえば、xTCPの一実施形態は、送られたパケットが失われたときでさえ、確認応答をサーバに戻して提供する(パケットが失われたときのTCPの重複確認応答方式と対照的に)。データパケットが消失していると決定することに応答して、データパケットが送信されるレートをサーバが低減することを回避するために、そのようなxTCPデータパケット確認応答方式がTA120によって利用され得る。さらに別の例として、独自プロトコルCM構成(たとえば、CM-rUDP)が提供されてよく、ここにおいて、CMは独自のユーザデータグラムプロトコル(UDP)プロトコルを使用し、レスポンスデータをサーバから送るレートは事前構成された一定のレートであってよく、または、ネットワークを望ましくなく輻輳させずに確実に送信レートをできるだけ速くするためのレート管理がプロトコル内にあってもよい。そのような独自プロトコルCMは、独自プロトコルをサポートする独自サーバと協働して動作し得る。

図示の実施形態はCM122がソースファイルからのデータをサーバ130に要求することに関して説明されたが、CMがデータにアクセスしなければならないインターフェースのタイプに応じて、ソースファイルは、サーバ上で利用可能であってよく、またはクライアントデバイス上で局所的に記憶されてもよいことを諒解されたい。

さらに、実施形態によれば、クライアントデバイス110は、本明細書でヘルパーデバイスと呼ばれる1つまたは複数の他のデバイス(たとえば、近くに配置された様々な構成のデバイス)に接続することができる場合があり(たとえば、WiFiまたはBluetooth(登録商標)インターフェースを介して)、ここにおいて、そのようなヘルパーデバイスは、3GまたはLTE接続を通じて、場合によっては、異なるヘルパーデバイス用の異なるキャリアを通じて、サーバ130などの1つまたは複数のサーバへの接続性を有し得る。したがって、クライアントデバイス110は、チャンクリクエストをサーバ130などの1つまたは複数のサーバへ送るためにヘルパーデバイスの接続性を使用できる場合がある。この場合、ヘルパーデバイスの各々に接続し、ヘルパーデバイスの各々へチャンクリクエストを送りレスポンスを受信するために、CMがTA120内にあり得る。そのような実施形態では、ヘルパーデバイスは、同じフラグメント向けの異なるチャンクリクエストを、同じまたは異なるサーバに送り得る(たとえば、複数のサーバ上のヘルパーデバイスにとって同じフラグメントが利用可能であり得、その場合、たとえば、異なるサーバが、異なるコンテンツ配信ネットワークプロバイダのうちの同じものによって提供される)。

いくつかの実施形態では、整合するソースファイルから冗長符号化技法を使用して生成された修復シンボルを含む冗長符号化コンテンツデータファイル(たとえば、FEC符号化データファイル)も利用可能にされ得る(たとえば、1つまたは複数のコンテンツサーバ上で)。たとえば、ソースファイルごとに1つのそのようなファイルがあってよく、ここにおいて、各冗長符号化コンテンツデータファイルは、当技術分野で知られているFEC符号化技法などの冗長符号化技法を使用してソースファイルから生成される。そのような実施形態では、たとえば、コンテンツファイル141がコンテンツの低ビットレート(低解像度)バージョンを備えることがあり、コンテンツファイル142がコンテンツの高ビットレート(高解像度)バージョンを備えることがあり、コンテンツファイル143がコンテンツファイル142のFEC符号化されたバージョンを備えることがある。送信されるすべてのデータが誤り訂正のために符号化される冗長符号化データ送信の実装形態は、いくつかのストリーミングユースケースにとって著しい利点をもたらさない場合があるが、本明細書の概念によるそのような冗長符号化コンテンツデータを(たとえば、前の送信において失われたコンテンツデータの転送を優先させるために)使用することは、多くのストリーミングユースケースにとって有利であり得る。たとえば、ライブストリーミングの場合、コンテンツが生成され、利用可能にされ、または作り出されたときと、その同じコンテンツがクライアントデバイス110上での再生および閲覧のために利用可能となるときとの間に、短い時間間隔があるという要件がよくある。たとえば、時間間隔は1秒以下であり得る。したがって、以下でさらに詳細に説明されるように、RM121によってCM122に対して行われるチャンクリクエストのうちのいくつかは、冗長符号化コンテンツデータ向けであってよい。

上記のことと一致して、冗長符号化コンテンツデータを使用せず、そのように元のソースフラグメントからのデータの部分だけを要求する基本RM構成(RM基本)と、元のソースフラグメントからのデータの部分、およびソースフラグメントから生成される整合冗長符号化コンテンツデータフラグメントとを要求することができる冗長符号化コンテンツデータRM構成(RM-FEC)とを備え得るような、実施形態によるRMの様々な構成があり得る。冗長符号化コンテンツデータのために適合された実施形態のRM121は、CM122から受信されたそのようなデータを、フラグメントまたはそのいくつかの部分を復元するための適切な冗長符号化コンテンツデータ復号(たとえば、FEC復号)技法を使用して、そのように復号し得る。RM121は、その後、復元されたフラグメントをUA129に配信し得る。

以下の説明からより完全に理解されるように、実施形態のTA120は、フラグメントを復元する助けとなるための冗長符号化コンテンツデータリクエストを利用し、ここにおいて、任意のフラグメントに対して要求するためのデータの総量、および任意のフラグメントに対して冗長符号化コンテンツデータをいつ要求するべきかが変化し得、フラグメントに対してどれくらいのデータおよびどのデータがすでに受信されているかなどのファクタに依存し得る。すなわち、一般的であるようにデータ伝送から得られた破損データを訂正するために冗長符号化データを利用するのではなく、実施形態は、要求されているデータ単位(たとえば、フラグメント、チャンク、パケットなど)がどこで失われまたは遅延したかなどの、要求されているフラグメントの復元を優先させるための追加データとして冗長符号化データを利用する。実施形態による動作の際には、任意の特定のフラグメントに関して要求される冗長符号化データの量は(または、任意の冗長符号化データが要求されるかどうかは)、そのような冗長符号化データがフラグメントの配信および復元をスピードアップする必要に基づいて制御される。たとえば、フラグメントリクエストに応答して受信されている高レベルの遅れたデータがない場合、フラグメントリクエストの非冗長符号化データに対するリクエストに加えて、少量の冗長符号化データが要求されてよい。

TA120の論理は、任意のフラグメント(冗長符号化コンテンツデータを含まない)に対してどれくらいの冗長符号化コンテンツデータを使用するべきかを自動的に決定し得る。たとえば、RM121は、要求される冗長符号化コンテンツデータの量を、各フラグメントを適時に復元するのに必要とされる冗長符号化コンテンツデータの量に自動的に調整し得る。実施形態による動作の際には、任意の特定のチャンクに対してRM121によって要求される冗長符号化データの量は、フラグメントをダウンロードする過程の間に遭遇する遅れたデータの総量に依存し得る。冗長符号化コンテンツデータを要求および復号するための論理が実施形態のトランスポートアクセラレータ(たとえば、RM121)によって実施されるので、任意の構成のUA129は(すなわち、冗長符号化コンテンツデータの使用のために適合されないものでさえ)、いかなる冗長符号化コンテンツデータのセマンティクスまたは論理も用いることなく、自動RM FEC方法を使用することができる(たとえば、そのようなFECデータが利用可能であるときに自動RM FEC方法がFECデータを利用するように動作するために、UAがFECデータが利用可能であるかどうかの知識を有する必要がない)。実施形態のトランスポートアクセラレータは、フラグメントまたはフラグメントのシーケンスなどごとに、(たとえば、そのRMおよびCMの協働を通じて)冗長符号化コンテンツデータが使用されるべきか否か、いつ使用されるべきか、またどれくらい使用されるべきかを自動的に決定するように動作し得る。

冗長符号化コンテンツデータを使用してコンテンツの転送の加速をもたらすための、本明細書の概念に従って適合されたシステムの実施形態に関する詳細が、以下に提供される。読者が理解するためにより簡単な具体例を提供するために、例示的な冗長符号化コンテンツデータとしてFEC符号化データが参照されるが、本明細書の概念が任意の数の適切な冗長符号化コンテンツデータタイプに関して適用可能であることを諒解されたい。たとえば、パケット損失に対して保護するためにアプリケーションレベルにおいて使用される前方誤り訂正の代わりに、またはそれに加えて、誤り訂正が使用されてよい。別の例として、各フラグメントは、通常の順方向の順序だけでなく逆順で要求するように利用可能にされてよく、その場合、先頭から末尾への通常のリクエストシーケンスに加えて、チャンクリクエストがフラグメントの末尾から先頭に向かって行われてよく、次いで、場合によっては、2つのリクエスト順序において要求されているデータのいくつかのオーバーラップを伴って、逆順でのフラグメント復元が順方向の順序でのフラグメント復元に遭遇するとすぐに、フラグメントが復元可能となる。

TA120の実施形態は、要求されるコンテンツのいずれかまたはすべてのフラグメントに関して、FECデータを利用するように動作し得る。フラグメントFのサイズを超えるどれくらいの余剰データが、実施形態によるフラグメントに対して要求され得るのかは、所定の量(たとえば、すべてのフラグメントに対して、または余剰データの量が別のやり方で規定されていないフラグメントに対して使用されるデフォルト量)として提供されてよく、動的に決定されてもよく(たとえば、現在のネットワーク状態に応じて)、以下同様である。実施形態による動作の際には、各フラグメントに対して使用するためのFECデータおよびFECデータを含む対応するFECフラグメントの量に関する情報は、UAによってRMに提供され得る。したがって、UA129および/またはTA120(たとえば、RM121)は、本開示の実施形態によるFECデータを利用するために適合され得る。

上記のことから諒解され得るように、基本RM構成の代替例では、実施形態のRM121が、フラグメントを復元する助けとなるためのFECデータを使用するように適合され得る。たとえば、一構成のRM121は、本明細書でRM固定FECと呼ばれるFECデータ技法を実施し得、それにおいて、各フラグメントに対して使用するためのFECデータおよびFECデータを含む対応するFECフラグメントの量が、UAによってRMに提供される。

したがって、要求されている元のソースフラグメントと整合するFECフラグメントに関する情報を提供することなどのためのUA129とRM121との間でのシグナリング、緊急性ファクタ(X)のシグナリングなどが、実施形態に従って利用され得る。FECデータを使用するように適合されたTA120の実施形態による動作の際には、以下でより詳細に説明するように、UA129は、ソースフラグメントリクエスト、整合FECフラグメントリクエスト、およびソースフラグメントを復元するのに必要とされる最小値を超えるデータをRMがどれくらい積極的に要求するのかを制御する緊急性ファクタX(たとえば、規定された値を有する)を、RM121に提供する。それに応答して、実施形態のRM121は、ソースフラグメントデータだけをUA129に提供し、整合FECフラグメントデータを提供しない。そのような実施形態のUA129は、ソースフラグメントリクエストの配信を加速する助けとなるためのこの情報をRMが使用できるように、整合FECフラグメントリクエストおよび緊急性ファクタをRM121に提供する。上記のことの変形形態では、以下でより詳細に説明するように、FECデータを使用するように適合されたTA120とともに動作可能なUA129が、ソースフラグメントリクエストだけをRM121に提供し得、対応する整合FECフラグメントリクエストをRMが自動的に導出し得、フラグメントごとにどれくらいのFECを要求するべきかをRMが自動的に算出し得る。上記の構成のうちのいずれかでは、RM121だけが、FEC復号を提供することを含むFECのセマンティクスを理解する必要がある、クライアントデバイス110の構成要素であることを諒解されたい。

実施形態のRM固定FEC技法による動作が、フロー200として図2に示される。実施形態のRM固定FEC技法の動作を理解するにあたって、フラグメントFを求めるリクエストがUAによって行われたばかりであり(ブロック201)、したがって、Fが最初にアクティブかつ適格であると想定する。図示の実施形態のUA129は、フラグメントリクエストに関連するFECデータの量を要求するための情報を、RM121にさらに提供する(ブロック202)。そのような情報は、要求されるフラグメントのコンテンツデータに対応するFECデータのソースの識別、ならびにFECデータのRM121による使用のための他の情報を備え得る。

どのフラグメントが識別されるのか、およびどのようにそれらが識別されるのかが、概してUAに特有であることを諒解されたい。しかしながら、概して、フラグメントは、メディアファイルもしくはバイナリファイル、またはリソース識別情報(たとえば、URL、URI、またはURN)によって識別されるようなファイルのバイト範囲、および、場合によっては、HTTPプロトコルまたはそのようなプロトコルを使用して要求され得るようなバイト範囲である。したがって、実施形態による動作の際には、UA129は、リソース識別情報(たとえば、URL)、関連したバイト範囲、およびフラグメントサイズをRM121に与える。同様に、UA129は、対応するFECフラグメントに関するリソース識別情報、関連したバイト範囲、フラグメントサイズ、およびシンボルサイズを与え得る。たとえば、フラグメントFを求めるリクエストに関連する整合FECフラグメントR、およびバイト単位でのシンボルサイズTが、UA129によってRM121に提供され、UA129はまた、フラグメントFのバイト単位でのサイズFB、およびFECフラグメントRのバイト単位でのサイズRBを、RM121に提供し得る。実施形態のデータリクエストサイズは、それだけには限らないが、FBがTの倍数でないときにFの最後の部分を求めるリクエストを除いて、Tバイトの倍数であることが好ましい。場合によっては、たとえば、Tとしての値が知られる前にリクエストが行われるべきであるとき、Tバイトの倍数であるデータリクエストを行うことが可能でない場合がある。これらの場合では、本明細書で説明するように、通常、シンボル境界に位置合わせされていないリクエストまたはリクエストへのレスポンスに起因する部分的シンボルの受信が、受信されるデータの小さい部分だけになるように、Tとしての値が選ばれる。

UA129がDASHクライアントであるとき、FECファイルの生成は、その開示がこれによって参照により本明細書に組み込まれる「ENHANCED BLOCK-REQUEST STREAMING USING COOPERATIVE PARALLEL HTTP」という名称の米国特許出願第12/887,495号に図示および記載されるような技法を使用して提供され得る。そのような実施形態では、これらのFECファイルがどのように生成されるのかという論理は、DASHクライアントに特有である。したがって、実施形態のUA129は、FECファイルを生成する際に使用される論理に関する情報をRM121に与えてよく、それにおいて、RMはこの論理について独立に知っている必要がない。たとえば、整合FECフラグメントに関してUA129によってRM121に提供されるリソース識別情報は、最後にサフィックス「.raptorq.$T$」が追加されたフラグメントに関するURLを備え得、ここで、「raptorQ」は、FECコードがインターネットエンジニアリングタスクフォース(IETF)RFC6330で規定されたRAPTORQコードであることを示し、「$T$」としての値は、フラグメントから整合FECフラグメントを符号化するために使用されるシンボルサイズである。別の例では、Tとしての値は、フラグメントのサイズFBに基づいてフラグメントごとに自動的に決定され得る。

実施形態のRM固定FEC技法による動作の際には、UA129は、付加的または代替的には、要求されているフラグメントFのサイズを超えるどれくらいの余剰データが、フラグメントに対してRM121によって要求されるべきかを決定する(ブロック206)際に使用される、上述の緊急性ファクタXを提供する(また、ブロック202において)。緊急性ファクタに関する値は、フラグメントリクエストと同時に、フラグメントリクエストの前に、フラグメントリクエストが行われるべきストリーミングコンテンツセッションの前になど、様々な方法で決定されてよい。たとえば、Xに関する所定のデフォルト値(たとえば、X=0.1)は、いくつかのフラグメント(たとえば、Xとしての値が別段に提供されないフラグメント)向けに、またはすべてのフラグメント向けに使用され得る。実施形態による動作の際には、UA129の論理は、一部または全部のフラグメントリクエストに関する使用のための緊急性ファクタXの値を決定するように適合される。たとえば、本開示の実施形態に従って利用され得るような緊急性ファクタの値は、その開示がこれによって参照により本明細書に組み込まれる「FEC BASED RELIABILITY CONTROL PROTOCOLS」という名称の米国特許第7,447,235号に記載されるようなアルゴリズムを使用して決定され得る。

要求されているフラグメントのデータを超える適切な量のFECデータが、上記の緊急性ファクタXを使用してRM121によって要求され得る(ブロック203)。たとえば、RM121は、リクエストを行うことが適切であるとRM121が見なす時点などにおいて、CM122による別のリクエストの準備ができていることをシグナリングすることなどに応答して、それと関連して要求された追加データを有する1つまたは複数のチャンクリクエストを行ってよい。同様に、RM121は、リクエストを行うことが適切であるとRM121が見なす時点などにおいて、CM122による別のリクエストの準備ができていることをシグナリングすることなどに応答して、追加データのうちの一部または全部を求める別個のリクエストをCM122に対して行ってよい。

RM121によってCM122に対して行われるとき、かつ/またはCM122によってサーバ130に対して行われるとき、UA129によって要求されるフラグメントがより小さいリクエスト(たとえば、上述のチャンクリクエスト)に再分割され得ることを諒解されたい。特定のフラグメントに関して要求される追加データの量は、そのようにそのフラグメントリクエストのチャンクリクエストに関する追加データの総計した量であり得る(すなわち、追加データのいくつかの部分は、フラグメントに対するいずれかまたはすべてのチャンクリクエストに関連して要求され得る)。同様に、要求される追加データは、元のコンテンツフラグメントからのデータに対するチャンクリクエストに加えて、またはその代わりに、FECデータを求める1つまたは複数のリクエストを備えてよい。たとえば、全データリクエストの量がフラグメントのサイズまたはフラグメントのサイズを超えるサイズであろうとなかろうと、すべてのデータリクエストは、FECデータだけのためであってよい。

RM固定FEC技法を実施するRM121の一実施形態は、たとえば、フラグメントFに対して合計(1+X)・FBバイトを要求し得る。したがって、追加のX・FBバイトのデータが、FECフラグメントRから要求され得る(たとえば、フラグメントFからのデータのすべてが要求された後)。RM121がFECを使用しない場合、実施形態は、RM固定FEC技法動作を無効にするためにT=1およびX=0を設定し得る。

本明細書のRM固定FEC技法の実施形態による動作の際には、フラグメントFのサイズを超えてどれくらいの余剰データが要求されるのかは、現在のネットワーク状態に依存することなどのために動的に変化し得る(たとえば、ブロック206において決定されるとき)。データの余分な量は、たとえば、実施形態による帯域幅遅延積の関数であってよい。たとえば、現在のダウンロードレートがDRであり、現在のラウンドトリップ時間がRTTである場合、要求されるFを超えるデータの余分な量はX・DR・RTTであり得、ここで、この実施形態によればXは固定の分数(たとえば、X=1/2またはX=0.29)であってよい。上記のことの近似として、要求されることが許されるデータの余分な量は、X・Recwindowに設定され得、ここで、CM122がその下位トランスポートプロトコルとしてTCPを使用するとき、Recwindowは、現在のTCP受信ウィンドウサイズ、またはクライアントデバイスにおけるTCP受信バッファの中に平均していくつのオクテット(バイト)もしくはデータが存在しているのかとしての測定値、または複数のTCP接続を使用する場合のすべてのTCP受信ウィンドウサイズの集合もしくはTCP受信バッファの平均の集合バイト占有率である。そのような実施形態では、CM122は、これらのパラメータをRM121にシグナリングし得る(たとえば、CMは、DRおよびRTTの現在の推定値、またはRecwindowの現在の推定値を、RMに提供してもよい)。

本明細書の概念から逸脱することなくRM固定FEC技法を提供する際に様々な代案が利用され得ることを諒解されたい。たとえば、要求されているフラグメントに関して使用されるべきFECデータの量を、UAが(たとえば、上述の緊急性ファクタを使用して)決定するように動作する(たとえば、ブロック206において)実施形態が上記で説明されたが、冗長符号化コンテンツデータを使用してコンテンツの転送の加速をもたらすように本明細書の概念に従って適合されたシステムの他の構成要素が、使用されるFECデータの量を決定するように動作してもよい。使用されるべきFECデータの量をUA以外の構成要素が決定するように動作する実装形態の一例として、実施形態のCMがschunkを決定およびシグナリングしてよく、その場合、schunkは、チャンクリクエストごとにCMにとって好適なターゲットデータチャンクリクエストサイズである。CMは、チャンクリクエストを受信した後のある時間においてTCP送信者が送ることを許容され得るデータの量にschunkを基づかせてよく、この場合、schunkの値は、チャンクリクエストがTCP送信者によって受信される時間における、そのTCP接続に関する現在のTCP輻輳ウィンドウサイズの推定値に基づき得る。schunkに関する値は、フラグメントリクエストに関連して要求され得るデータの各チャンクのサイズを確立する際に、そのようにRMによって利用され得る。

付加的または代替的には、要求されているフラグメントを超えるどれくらいのデータが要求されるべきかを決定する際に、適切な冗長符号化コンテンツデータに関する情報の1つまたは複数のパラメータが(たとえば、RM121によって)利用され得ることを諒解されたい。したがって、図2に示すフロー200の実施形態は、ブロック202と206との間に随意のデータ経路を含み、それにおいて、そのような情報が、本明細書で説明するような1つまたは複数の決定の際に使用するために伝えられ得る。

実施形態に従って、FECフラグメントRを使用し、UA129およびCM122によってRM121に提供され得るようなパラメータを使用する、フラグメントFに対してロバストなRM固定FEC技法を実施するための詳細を示す擬似コードが、以下に提供される。
FがUAによって最初に要求されるときの初期化
Set status of F to be active and eligible (Fのステータスをアクティブかつ適格であるものと設定する。)
Obtain the value of T from the UA (Tとしての値をUAから取得する。)
/*シンボルサイズTは、フラグメントの中のソースシンボルの数が100と10,000との範囲の中にあるように設定されるべきである。FECが使用されない場合、T=1である。*/
Obtain the value of schunk from the CM (schunkとしての値をCMから取得する。)
/*schunkは、データリクエスト当たりのバイトのターゲット数である-バイト単位でのデータリクエストサイズがフラグメントサイズとは無関係に設定されてよく、たとえば、schunkはフラグメントサイズとは無関係に16キロバイトに設定される。*/
nsym = ceil(schunk / T)
/*nsymは、リクエスト当たりのシンボルのターゲット数である-バイト単位でのデータリクエストサイズnsym×Tは、ほぼschunkである。*/
RK=0
/*RKは、フラグメントFに対してCMから受信されるシンボルの数である。*/
UK=0
/*UKは、まだ受信されておらず、かつそれらが配信されないとまだ認識されていない、CMに要求されているシンボルの数であり、すなわち、それらが配信されるか否か、またそれらがいつ配信されるのかは現在知られていない。*/
QK=0
/*QKは、ここまでにFから要求されているシンボルの総数である*/
QK'=0
/*QK'は、ここまでにRから要求されているシンボルの総数である。*/
フラグメントFのサイズFBが決定されるとき、/*FBは、UAによって提供されてよく、またはフラグメントFの部分に対するデータリクエストへのレスポンスの中で戻ってきてもよい。*/
K=ceil(FB/T)
/*Kは、FEC符号化および復号のためにFのソースデータがそれに区分されるソースシンボルの数である。FのサイズFBは、FまたはRとしての一部のデータが受信された後にのみ知られ得、したがって、当初はKとしての値は知られ得ない。*/
When size RB of FEC fragment R is determined (FECフラグメントRのサイズRBが決定されるとき)/*RBは、UAによって提供されてよく、またはフラグメントRの部分に対するデータリクエストへのレスポンスの中で戻ってきてもよい。*/
K'=floor(RB/T)
/*K'は、Rの中の修復シンボルの数である。RのサイズRBは、FまたはRとしての一部のデータが受信された後にのみ知られ得、したがって、当初はK'としての値は知られ得ない。*/
XK=ceil(X・FB/T)
/*Xとしての値は、デフォルトによって、たとえば、X=0.1に設定されてよく、またはXとしての値は、UAによって提供されてもよい。XKは、任意の時点において要求され得る、Kを超える追加のシンボルの数である。*/
if CM indicates time to request and F is the earliest active and eligible fragment then (要求するべき時間をCMが示し、Fが最も早いアクティブかつ適格のフラグメントである場合)
if not all of fragment F has been requested then (フラグメントFのすべてが要求されているとは限らない場合)
if value of FB has not yet been determined then (FBとしての値がまだ決定されていない場合)
dK=nsym /*dKは、Fのリクエストまでのシンボルの数である。*/
elseif the value of FB has been determined then (そうでなく、FBとしての値が決定されている場合)
remK=K=-QK /*remKは、まだ要求されていないソースシンボルの数である。*/
if (remK ≦ nsym) then ((remK≦nsym)の場合)
dK=remK */残りのすべてのソースシンボルを要求する。*/
elseif (remK ≦ 2・nsym) then (そうでなく、(remK≦2・nsym)の場合)
dK=ceil(remK/2) /*半分を要求する-残りは次のリクエストの中で要求される*/
else (そうでない場合) /*remK>2・nsym*/
dK=nsym /*ターゲット数のシンボルを要求する。*/
Request bytes [QK×T,...,min{QK・T+dK・T,FB}-1 (Fとしてのバイト[QK×T,...,min{QK・T+dK・T,FB}-1を要求する)
QK=QK+dK
UK=UK+dK
If all of fragment F has been requested (フラグメントFのすべてが要求されている場合)/*修復フラグメントRからのリクエスト*/
remK'=K+XK-RK-UK /*Fが適格であるのでremK'>0となる。*/
if (K'-QK'>0) ((K'-QK'>0)の場合) /*Rの中に要求するべき残されたシンボルがある。*/
dK=min{K'-QK',nsym,remK'}
Request bytes [QK'・T,...,(QK'+dK)・T-1] (Rとしてのバイト[QK'・T,...,(QK'+dK)・T-1]を要求する)
QK'=QK'+dK
UK=UK+dK
If (K+XK-RK-UK<0) then change status of F to ineligible ((K+XK-RK-UK≦0)の場合、Fのステータスを不適格に変更する)
Else “error recovery”(そうでない場合、「誤り復元」) /*要求するべきシンボルはこれ以上なく、まだ他のシンボルが復元することを必要とされ、この場合、おそらくいくつかの消失シンボルを再要求する。
If CM indicates that L requested not yet received symbols for F will fail to be delivered (Fに対して要求されておりまだ受信されていないL個のシンボルが配信されないことをCMが示す場合)
UK=UK-L
If (K+XK-RK-UK>0) then set status of F to eligible ((K+XK-RK-UK>0)の場合、Fのステータスを適格に設定する)
If CM delivers L symbols for fragment F (フラグメントFに対してL個のシンボルをCMが配信する場合)
RK=RK+L
UK=UK-L
If (RK≧K) ((RK≧K)の場合)
If enough symbols have been received to recover F then (Fを復元するのに十分なシンボルが受信されている場合)
FEC decode F from the received symbols and respond with F to the UA (受信されたシンボルからFをFEC復号し、Fを伴ってUAに応答する) /*通常、RAPTORQ符号化を用いると、K、K-+-1またはK-+-2シンボル*/
Change status of F from active to recovered (Fのステータスをアクティブから復元済みに変更する)

フラグメントデータを超えるデータの量を決定し(ブロック206)、フラグメントおよび余剰データリクエストを行うと(ブロック203)、適宜に、本明細書のRM固定FEC技法に従って動作しているRM121は、要求されているフラグメントのコンテンツデータ、ならびに要求されているフラグメントを超えるFECデータを受信し得る(ブロック204)。図2に記載される動作が、他のブロックからの他の部分的なステップと時間的に密接な関係にあるブロックと関連した、部分的なステップを実行することを潜在的に伴うことを諒解されたい。たとえば、ブロック206の部分的なサブステップを実行することは、ブロック203、204、および205の部分的なサブステップを実行することと時間的に密接な関係にあり得る。

要求されているフラグメントのデータを超えるFECデータを要求することは、ネットワークを介して転送されるデータの量を増加させ得るが、データの様々なパケットが異なる時間において到達し得る(たとえば、遅延し得るデータパケットもあれば、より適時に配信されるパケットもある)。要求されるフラグメントデータおよびFECデータの様々な組合せが、フラグメントを復元するために使用され得る。したがって、本明細書のRM固定FEC技法を実施するRM121の実施形態は、フラグメントの復元をもたらすのに十分な、最も早く受信されたデータ(フラグメントデータであろうと、フラグメントデータとFECデータの組合せであろうと)を使用してフラグメントを復元し得る。フラグメントは、そのようにRM121によって迅速に復元され得るとともに、コンテンツの消費のためにUA129に提供され得る(ブロック205)。

追加または代替として、実施形態のRMは、要求されているフラグメントに関してどれくらいのFECデータを使用するべきかを自動的に決定するように適合され得る。したがって、RM固定FEC構成の代替として、実施形態のRM121は、フラグメントを復元する助けとなるためのFECデータを使用するだけでなく、フラグメントに関してどれくらいのFECを使用するべきかを自動的に決定するように適合され得、それによって、本明細書でRM自動FECと呼ばれるFECデータ技法を実施する構成のRM121を提供する。RM自動FEC技法の実装形態は、いくつかの理由で、いくつかの状況においてRM固定FEC技法より優れて望ましくあり得る。具体的には、実施形態のRM自動FEC技法は、要求されるFECデータの量を、各フラグメントを復元するのに必要とされるFECデータの量に自動的に調整する。したがって、フラグメントに対してダウンロードされるデータの量は最小限に抑えられ、概して、使用するべきFECの量がUAによって決定されるRM固定FECの場合よりも、ダウンロードされる全データが平均してより少量ですむ。要求されるフラグメントの適時の配信はRM自動FECを使用して最大化され得、概して、RM固定FECの場合と同じくらい、またはそれより良好な適時の配信をもたらす。その上、要求するべきFECデータの量がRMによって自動的に決定されるので、UAは、任意のFEC論理を使用または内蔵するためにFECの量を規定する必要がない。このことは、UAに対する要件を簡単化および低減し、概して、RM自動FEC方法を様々なUA構成(たとえば、FECデータを要求するためであろうと復号するためであろうと、いかなるFEC論理も含まないUA構成を含む)に対してより広く適用可能にさせる。

実施形態のRM自動FEC技法による動作が、フロー300として図3に示される。本明細書の実施形態のRM自動FEC技法の概念を理解する際の助けとなるために、上記で提供されたRM固定FEC技法の説明の拡張としてRM自動FEC技法が説明される。したがって、上記で説明したRM固定FEC技法と同じく、本明細書で説明するRM自動FEC技法の場合、フラグメントFを求めるリクエストがUA129によって行われたばかりであり(ブロック301)、したがって、Fが最初にアクティブかつ適格であると想定する。

図示の実施形態による動作の際には、RM121は、フラグメントリクエストに関連する適切な量の冗長符号化コンテンツデータを使用するための情報を取得する(ブロック302)。そのような情報は、要求されるフラグメントのコンテンツデータに対応するFECデータのソースの識別、ならびにFECデータのRM121による使用のための他の情報を備え得る。たとえば、フラグメントFを求めるリクエストがRM121に提供されるとき、整合FECフラグメントR、およびシンボルサイズTに関する情報が利用可能であり得、または別のやり方で決定可能であり得る。UA129は、FECデータの使用に関して有用ないくつかの情報をRM121に提供し得るが(たとえば、ブロック301において)、実施形態のRM121は、FECデータを利用するための情報を決定または別のやり方で取得するように動作し得る。たとえば、UA129は、フラグメントFのバイト単位でのサイズであるFBを提供し得、対応するFECフラグメントRのバイト単位でのサイズRBは、RMによってFBから自動的に導出され得る(たとえば、その開示がこれによって参照により本明細書に組み込まれる「ENHANCED BLOCK-REQUEST STREAMING USING COOPERATIVE PARALLEL HTTP」という名称の米国特許出願第12/887,495号に図示および記載されるような技法を使用して)。

あるいは、FBの値は、FまたはRの少なくとも一部分を求めるリクエストに応答して取得されてもよい。FをFEC符号化およびFEC復号するために使用するべきシンボルのサイズTは、FのサイズFBから自動的に決定され得る。たとえば、FECエンコーダとFECデコーダの両方においてT=max{4,floor(FB/2,048)}としてTを導出することは、同じシンボルサイズが符号化および復号するために使用されること、またFBが少なくとも8キロバイトである場合、Fが区分されるソースシンボルの数が少なくとも2,048であることを確実にする。このことは、FEC復号にとって有用であり得ない部分的シンボルを受信することに起因して、データを受信することへの各レスポンスにおける受信データの中に、多くて0.1%の無駄があることを確実にし得る。たとえば、Fのバイト範囲に対するチャンクリクエストへのレスポンスは、これらの部分的シンボルの残りが他のレスポンスの中で受信されない場合、FEC復号にとって有用であり得ない多くて2つの部分的シンボルをレスポンスの中に備えることがあり(レスポンスの先頭における1つ、末尾における1つであり、ここにおいて、すべての中間のレスポンスデータは完全なシンボルを備える)、レスポンス当たり2つの無駄な部分的シンボルは、FBが少なくとも8キロバイトである場合、フラグメントFの多くて2/2,048=0.1%を備える。

FECフラグメントRに関するURL、またはFECデータを識別しそれにアクセスするのに好適な他の情報は、実施形態によるUA129からのいかなる入力も必要とすることなくRM121によって自動的に生成され得る。上記で説明した本実施形態におけるように、FBがTの倍数でないときにFの最後の部分を求めるリクエストを除いて、またはシンボルサイズTが知られるまで、たとえば、フラグメントFに対して送られたデータリクエストに応答してFBが決定されるとTがFBに基づいて決定されるまで、データリクエストサイズはTバイトの倍数にされてよい。RM121がFECを使用しない場合、実施形態は、Tとしての値が知られるまでT=1を設定し得る。代替として、Tバイトの位置合わせに基づかないすべてのリクエストが行われてよく、すなわち、すべてのデータリクエストに対して事実上T=1が使用され、次いで、フラグメントを復元するためにFEC復号が使用される場合、FEC復号のために、レスポンスの中で受信されたデータがRM121によって内部的にシンボルに区分される。

本明細書のRM自動FEC技法による動作の際には、RM121は、要求されているフラグメントを超えるどれくらいのデータを要求するべきかを動的かつ自動的に決定するように動作する(ブロック303)。そのような決定は、それによって、相対的にフラグメントリクエストと同時に起こるネットワーク状態および/または他の事情に関して適時となる余剰データに関する決定を動的にもたらすフラグメントリクエストの時間において、またはそうした時間の近くで行われる。しかしながら、実施形態は、付加的または代替的には、望ましいと決定されるとき、他の時間においてそのような決定を行うように動作してよい。要求されているフラグメントを超えるどれくらいのデータが要求されるべきかを動的に決定する際に、適切な冗長符号化コンテンツデータに関する情報の1つまたは複数のパラメータが、RM121によって利用され得ることを諒解されたい。

本明細書のRM自動FEC技法の実施形態は、要求されているフラグメントを超えるどれくらいのデータが要求されるべきかを決定するための1つまたは複数のプロセスを実施し、そうしたプロセスは、上記で説明した(たとえば、所定のデフォルト値、ネットワーク状態などに応じて変化するファクタXを使用する)RM固定FEC技法を実施したものと同じかまたは類似である。実施形態のRM自動FEC技法による、そのような追加データがフラグメントに対していつ要求されるべきかに対する条件は、RM固定FEC技法の条件と異なり得る。具体的には、RM固定FEC技法の実施形態は、要求されているフラグメントのデータを超えるデータを一様に要求するように動作し(たとえば、フラグメントごとにそのような追加データを要求する)、他方で、RM自動FEC技法の実施形態は、要求されているフラグメントのデータを超えるどれくらいのデータが、いつ要求されるべきかを動的に決定するように動作する(たとえば、ネットワーク状態に基づいてそのような追加データを要求する)。

実施形態のRM121は、フラグメントデータ(たとえば、1つまたは複数のチャンクリクエストのような)を要求し得、適切であると決定すると、RM121は、フラグメントデータを超える余剰データをCM122に要求し得る(ブロック303)。実施形態のRM自動FEC技法による動作の際には、要求されているフラグメントに加えてどれくらいのデータがいつ要求されるべきかに関する決定は、ネットワーク状態(たとえば、ネットワーク上での遅れたデータの量および/または要求されているデータの遅延の測定値)に少なくとも部分的に依存する。

任意の特定のフラグメントに関して追加データをいつ要求するのが適切であるか、またどれくらいのそのようなデータを要求するべきかを動的かつ自動的に決定するための、実施形態のRM121に関する例示的なプロセスによる。遅延したまたは遅れたデータパケットを識別する際に使用するために、RM121からCM122へのデータリクエストの順序付けが規定される。たとえば、RMからCMへのデータリクエストの順序付けは、RMがCMにデータを要求する順序として規定され得、それにおいて、より早く要求されたデータのチャンクが、データのチャンクを求める後続のリクエストよりも順序付けにおいてより早い。そのような実施形態では、チャンクリクエスト内でのデータの順序付けは、自然順序付けとして定義され得る(すなわち、チャンクリクエストの最初のバイトが、チャンクリクエストの後続のバイトよりも順序付けにおいてより早い)。

上記のデータの順序付けを使用すると、データの第1の部分が要求された後にRMによって要求されたデータの第2の部分が受信されたとき、データの第1の部分をRMが要求しているが依然としてそれがまだ受信されていない場合、実施形態のRM121はデータの第1の部分が遅れている(また、場合によっては失われた)と見なすように動作し得る。たとえば、RMによって要求されているがまだ受信されていないデータの一部分に対して、
データの部分に続いて要求されているデータがRMによってまだ受信されていない場合、データのその部分を「保留中」として規定する。
RMによって受信されたデータの部分に続いて要求されているデータがある場合、データのその部分を「遅れている」と認識されるものとして規定する。

RM固定FEC技法に関して上記で規定された変数に加えて、フラグメントに対して保留中であるデータの量である変数PK、フラグメントに対して遅れているデータの量である変数LKが、本明細書の実施形態のRM自動FEC技法に関する使用のために規定され得る。上記のことから、フラグメントに対して要求されているが認識されていないデータの総量であるUKが、UK=PK+LKとして表現され得ることが諒解され得る。フラグメントに対して受信されたデータの量である変数RK(フラグメントに対して全く同じデータが2回受信された場合、RKでは1回だけ計数される)が、実施形態のRM自動FEC技法に関する使用のためにさらに規定され得る。本明細書で提供される例の場合、上記の量のすべてがシンボル単位で測定されるものと想定されるが、他の単位(たとえば、データの量をバイト単位またはオクテット単位で測定すること)が実施形態に従って利用されてよい。

さらに、実施形態のRM121は、フラグメントに対して任意の時点において見られる遅れたデータの最大量を追跡し得る(たとえば、変数maxLKが0に初期化されてよく、次いで、LKの値がフラグメントに対して変化するたびにmaxLK=maximum{LK,maxLK}が再計算されてよい)。実施形態によれば、そのようなフラグメント最大遅れデータ変数は、たとえば、遅延変数LKの潜在的に極めて変わりやすい性質を和らげるために利用され得る。代替として、maxLKは、フラグメントのうちのS個としての、いくつかの前のウィンドウにわたる任意の時点において遅れたデータの最大量として規定されてよく、ここで、Sは設定可能なパラメータ、たとえば、S=10である。別の変形態として、そこにわたって最大値が計算されるウィンドウは、前の時間の設定可能な継続時間、またはRTTなどの他の測定に依存する前の時間の継続時間、または設定可能な数の前のチャンクリクエストにわたってよい。別の代替として、LKの値は、その下にあるフラグメント構造とは無関係に、たとえば、RMによって行われ、各チャンクリクエストがそこから生成されるフラグメントとは無関係となるチャンクリクエストの順序付けに基づいて保持されてよい。

実施形態による動作の際には、RM121がフラグメントに対してデータを受信するたびに、RKの値が受信されたデータの量だけ増大され(それが同じフラグメントに対して前に受信された全く同じデータでない限り)、UKの値がこの量だけ減少され、PKの値が前に保留中であったこのデータの量だけ減少され、LKの値が前に遅れていたこのデータの量だけ減少される。また、RM121によってデータが受信されたとき、前に要求されており依然として保留中であるデータがある場合、前に要求されたこのデータは、保留中であるものから遅れているものへ再分類され、前に要求されたこのデータのサイズがPKから減算されるとともにLKに加算される。

図4は、受信された保留中の遅れたデータを示すタイムラインおよび上記の変数の対応する値を示す。図4のタイムラインでは、RM121がフラグメントのデータチャンクを求めるCM122へのリクエストを行い、すなわち、最初にデータチャンク1(C1)を求めるリクエストを行い、次いで、データチャンク2(C2)を求めるリクエストを行い、次いで、データチャンク3(C3)を求めるリクエストを行う。図示の例では、データチャンクの各々はサイズが8KBであり、各データチャンクは、それぞれ4KBの2つの個別部分をなして受信される(データチャンクiのj番目の部分を示すために、表記法Ci.jが使用される)。図4のタイムラインにおいて以下に示す情報が、データチャンクに対するRMによる新しいリクエスト、または前に要求されたチャンクに対するデータのRMによる受信のいずれかに起因して、RK、PK、LK、およびmaxLKの値がいつ変化するのかを示すことを諒解されたい。

図4に表されるシナリオに示されるように、RM121がデータチャンク1(C1)を要求するとき、RK=0であり(受信されたデータがまだないので)、PK=8KBであり(サイズ8KBのデータチャンク1が現在保留中であるので)、LK=0であり(遅れたデータがまだないので)、maxLK=0である。データチャンク1(C1.1)の第1の部分がRM121によって受信された直後のタイムライン上の点において、RK=4KBであり(C1.1が受信されているので)、PK=4KBであり(C1.2が現在保留中であるので)、LK=0であり(遅れたデータがまだないので)、maxLK=0である。RM121がデータチャンク2(C2)を要求するとき、RK=4KBであり(C1.1が受信されているので)、PK=12KBであり(C1.2、C2.1、およびC2.2が保留中であるので)、LK=0であり(遅れたデータがまだないので)、maxLK=0である。データチャンク2(C2.1)の第1の部分がRM121によって受信された直後のタイムライン上の点において、RK=8KBであり(C1.1およびC2.1が受信されているので)、PK=4KBであり(C2.2が依然として保留中であるので)、LK=4KBであり(C1.2が遅れていることがC2.2の到達によりトリガされるので)、maxLK=4KBである。RM121がデータチャンク3(C3)を要求するとき、RK=8KBであり(C1.1およびC2.1が受信されているので)、PK=12KBであり(C2.2が依然として保留中であり、また現在C3.1およびC3.2が保留中であるので)、LK=4KBであり(C1.2が依然として遅れているので)、maxLK=4KBである。データチャンク3(C3.1)の第1の部分がRM121によって受信された直後のタイムライン上の点において、RK=12KBであり(C1.1、C2.1、およびC3.1が受信されているので)、PK=4KBであり(C3.2が保留中であるので)、LK=8KBであり(現在C1.2とC2.2の両方が遅れているので)、maxLK=8KBである。データチャンク1(C1.2)の第2の部分がRM121によって受信された直後のタイムライン上の点において、RK=16KBであり(C1.1、C1.2、C2.1、およびC3.1が受信されているので)、PK=4KBであり(C3.2が保留中であるので)、LK=4KBであり(現在C2.2だけが遅れているので)、maxLK=8KBである。データチャンク2(C2.2)の第2の部分がRM121によって受信された直後のタイムライン上の点において、RK=20KBであり(C1.1、C1.2、C2.1、C2.2、およびC3.1が受信されているので)、PK=4KBであり(C3.2が依然として保留中であるので)、LK=0KBであり(C2.2が現在到達し、他の遅れたデータがないため)、maxLK=8KBである。データチャンク3(C3.2)の第2の部分がRM121によって受信された直後のタイムライン上の点において、RK=24KBであり(C1.1、C1.2、C2.1、C2.2、C3.1、およびC3.2が受信されているので)、PK=0KBであり(保留中のデータがないので)、LK=0KBであり(遅れたデータがないので)、maxLK=0KBである。

上記の例ではすべてのデータチャンクが単一のフラグメントに対するものであったが、表される概念は複数のフラグメントに適用されることを諒解されたい。たとえば、複数のフラグメントがあるとき、RK、UK、PK、LK、およびmaxLKとしての値は、フラグメントごとに保持されてよく、または代替的に、チャンクリクエストがそこから生成されるフラグメントとは無関係のチャンクリクエストに基づいて保持されてよい(たとえば、設定可能な数の前のチャンクのウィンドウ、または設定可能な数の前のバイトのウィンドウ、または前の時間の設定可能な継続時間のウィンドウにわたって計算される)。しかしながら、RMが第1のフラグメントに対して第1のデータチャンクを要求し、次いで、RMが第2のフラグメントに対して第2のデータチャンクを要求する場合、第2のデータチャンクの部分の到達により、第1のデータチャンクのまだ到達していない部分が遅れているものとしてRMによって分類され得る。

上記のパラメータを使用して、データ(たとえば、要求されているフラグメントのデータ、ならびに要求されているフラグメントを超えるデータ)を求めるリクエストがいつ行われ得るのか、およびどれくらいのデータを要求するべきかに関する決定である。追加データが、(たとえば、初期チャンクリクエストであろうとチャンクデータを求める再リクエストであろうと、チャンクリクエストの一部としての、またはチャンクリクエストに関連する)フラグメントデータを求めるリクエストと組み合わせて、またはデータを求める別個のリクエストとして(たとえば、追加データを求める独立したリクエストとして、または遅れたもしくは消失したデータに応答する独立したリクエストとして)要求されてよいことを諒解されたい。しかしながら、RM121がデータチャンクを求めるリクエストを行うときはいつでも、規定された(たとえば、4KB、8KBなど)最小サイズのデータチャンクがあり得、そのことは、たとえば、フラグメントのサイズまたはschunk(schunkはCM122にとって好適なターゲットデータチャンクリクエストサイズである)の値に依存し得る。

基本RM自動FECの実装形態による動作の際には、条件RK+PK<K+XKが満たされる限り、任意の特定のフラグメントに対するより多くのデータが、(たとえば、図3のブロック303において)上記のネットワーク状態パラメータに従ってRM121によって要求され得る(すなわち、フラグメントに対して受信されたまたは保留中のデータの量が、せいぜいフラグメントのサイズ+XKである限り、別のデータチャンクリクエストが行われてよい)。RM121は、たとえば、ネットワーク状態、およびCM122によるRM121へのデータの配信の全パターンとは無関係となる、XKとしての値を設定し得る。実施形態のRM自動FEC技法の場合、XKとしての値は、RM121によって小さい値に自動的に設定され得る(たとえば、XKは{4KB,0.004・K}としての最小値に設定されてよく、XKはschunkに設定されてよく、XKは0に設定されてよく、以下同様である)。

よりロバストなRM自動FECの実装形態による動作の際には、上記の不等式の両側にLKを追加すると(UK=PK+LKであることを再表示する)、条件はRK+UK<K+XK+LKとして書くことができ(すなわち、フラグメントに対して受信または要求されたデータの量が、せいぜいフラグメントKのサイズ+フラグメントのサイズXKの付加定数分のバイト+フラグメントに対して遅れたデータの量LKである限り、別のデータチャンクリクエストが行われ得る)、それにおいて、LKとしての値は、要求されており遅れているデータの量に起因してどれくらいの余剰データが要求されることを許容されるのかを与える(たとえば、ブロック303において)。上記のことの変形形態では、RM自動FEC実装の実施形態は、条件RK+UK<K+XK+α・LKが満たされる限り、RM121がフラグメントに対して追加データを要求することを許容する動作を提供し得、ここで、αは適切に選ばれた定数である(たとえば、α=0.5、α=1、またはα=3)。上記の条件において、フラグメントに対して任意の時点において見られる遅れたデータの最大量maxLKを使用することは、遅延変数LKの潜在的に極めて変わりやすい性質を和らげるために利用され得る。そのような実施形態では、条件RK+UK<K+XK+α・maxLKが満たされる限り、RM121はフラグメントに対する追加データを要求することが許容されてよく、ここで、αは適切に選ばれた定数である(たとえば、α=0.5、α=1、またはα=1.5)。あるいは、条件RK+UK<K+XK+α・FB・maxLK/Wが満たされる限り、RM121はフラグメントに対して追加データを要求することが許容されてよく、ここで、FBはフラグメントのサイズであり、WはmaxLKがそこにわたって測定されるバイトのウィンドウである。

上記のことに関して、遅れているとして分類されるデータ、したがって、LKにおいて計数されたサイズのデータは、本質的に、失われたデータとして一時的に計数されているデータであることを諒解されたい。保留中のデータが遅れているデータになると、このデータのサイズがPKから減算されるとともにLKに加算され、そのことが、上記に記載した特定の条件に従って、このフラグメントに対してより多くのデータが要求されることを潜在的に可能にし得る。しかしながら、要求されており遅れている任意のデータが受信されるとすぐに、そのサイズがRKに加算されるとともにLKから減算され、したがって、短い時間期間の間、遅れていると分類されている任意のデータは、この短い時間期間の間のみRK+PKから消失している(この短い時間期間の間のみLKに寄与する)。LKを使用する上記の条件によれば、いくぶん遅れただけで受信されたデータは、短い持続時間の間のみLKに寄与する(たとえば、データがいくつかの時間tにおいて遅れていると最初に決定され、次いで、データが時間t+Xにおいて到達した場合、このデータは、tとt+Xとの間の時間期間の間のみLKに寄与する)。たとえば、RTTを現在のラウンドトリップ時間として、X=RTTの場合、データはRTTの間のみLKに寄与する。したがって、DRがデータを受信することの現在のレートであり、多くて1つのRTTだけ順序が乱れてデータが受信される場合、LKは時間の任意の点において多くてDR・RTTである。したがって、LKとしての値は、任意の時間において、実施形態による遅れたデータに起因してどれくらいの余剰データが要求されることを許容されるのかを定量化する。具体的には、LKを使用する条件を実施する上記の実施形態では、LKとしての値は、どれくらいの余剰データがRM自動FEC技法を使用して要求されることを許容されるのかがRM固定FEC技法との間で比較された、要求されており遅れているデータに対する量の自動調整に起因する差分である。

要求されているデータが短い時間期間の間のみ遅れている場合、それが受信されるまでの(それがこれまでに受信されている場合)少なくともいくらかの時間期間の間、ほとんどのデータが遅れていると分類されている場合でも、そのようにわずかに順序が乱れて受信される。実施形態による遅れたデータに起因して要求されるデータの余分な量は、概して少ない(すなわち、LKとしての値は概して小さい)。しかしながら、要求されているデータが依然として遅れたままである時間の量が多くなるにつれて、未処理の、要求されているが遅れたデータが各時点においてより多くなり、したがって、LKとしての値は概して大きくなり(すなわち、受信されるデータの順序により著しい差分があるとき、LKとしての値は概してより大きい)、したがって、遅れたデータに起因して許容される、要求されるデータの量は多くなる。実施形態による動作の際には、遅れたデータの到達が遅延すればするほど、追加の要求されるデータが要求されるのを許容することへの遅れたデータが及ぼす影響がより大きくなる。要求されているデータが永続的に失われる場合、そのデータのサイズは、それが遅れているとして分類された時間から依然としてLKに寄与したままであり(または、LKが計算される時間のウィンドウ、またはバイトのウィンドウ、またはチャンクのウィンドウ、またはフラグメントのウィンドウにわたって存続し)、その後、余剰データが、実施形態によるこの失われたデータに対してその後要求されることが許容される。

XKとしての値は、それが異なる目的に応えているので、概して、RM自動FEC技法の場合はRM固定FEC技法の場合よりもはるかに小さい値に設定される。実施形態のRM固定FEC技法の場合、XKとしての値は、受信されているもの(RK)またはすでに要求されているがまだ受信されていないもの(UK)を超えて要求され得る、余剰データの量を決定する。したがって、そのようなRM固定FEC技法の場合、XKとしての値は、概して、順序が乱れたどれくらいのデータが受信されると予期されるのか、データのうちのいくつかが他のデータに比較してどれくらい遅く到達しようとしているのか、どれくらいのデータが失われるのかなどという考慮に従って設定される。したがって、XKとしての値は、通常、RM固定FEC技法のためのいくつかの追加情報を使用して設定される(上記の擬似コードに示すように)。しかしながら、実施形態のRM自動FEC技法の場合、順序が乱れたデータ、他のデータよりも遅く到達するいくつかのデータ、および失われたデータの原因を明らかにすることは、LKとしての値によってもたらされる(PKとしての値は、UKとしての値よりもLKとしての値だけ小さい)。したがって、実施形態のRM自動FEC技法にとってのXKの役割は、フラグメントに対して最後に要求されたデータのうちのいくつかが到達するのが遅れている場合、遅れているとして確実に分類されるために、フラグメントを復元するのに実際に必要とされるものを超えていくつかのデータが要求されるのを確実にすることである。すなわち、データの最後のXKバイトを要求することによって、遅れて到達するかまたは失われた、前に要求された任意のデータが到達したとき、次いで、それは遅れていると分類され、したがって、この遅れて到達するかまたは失われたデータに対して追加のリクエストを潜在的にトリガする。この理由のため、XKとしての値は、実施形態のRM自動FEC技法の場合、小さい固定値に自動的に設定され得る。

RMがフラグメントのシーケンスを要求している状況では、実施形態のRM121は、フラグメントごとにどれくらいのデータを要求するべきかを決定するためにRMによって使用され得る、複数のフラグメントにわたる統計量を計算し得る。たとえば、複数の連続したフラグメントのウィンドウにわたる、フラグメントごとの平均の最大限に遅れたデータを、avgmaxLKとする。実施形態による動作の際には、条件RK+UK<K+XK+α・avgmaxLKが満たされる限り、RM121はフラグメントに対する追加データを要求することが許容されてよく、ここで、αは適切に選ばれた定数である(たとえば、α=0.5、α=1、またはα=1.5)。avgmaxLKとしての値は、実施形態によれば、maxLKの加重移動平均を使用して更新されてよく、ここで、maxLKは現在のフラグメントに関する値である(たとえば、avgmaxLKはavgmaxLK=β・avgmaxLK+(1-β)・maxLKとして更新され、ここで、βは適切に選ばれた定数である(たとえば、β<1))。あるいは、実施形態のavgmaxLKの値の更新は、maxLK>avgmaxLKの場合、avgmaxLK=β1・avgmaxLK+(1-β1)・maxLKであり、他方で、maxLK≦avgmaxLKの場合、avgmaxLK=β2・avgmaxLK+(1-β2)・maxLKという論理を実施してもよく、ただし、0<β2<β1<1とする。本明細書の実施形態に従って実施され得る平均値算出論理の他の例は、現在のフラグメントに対して、過去の連続したフラグメントの移動ウィンドウにわたるmaxLKとしての値の95パーセンタイル(または、任意の他の適切なパーセンタイル)を使用することである。

データがいつ要求されるべきか、および要求されるべきデータの量を決定するためのRM121の動作の別の例として、遅れたデータに対してRMがそのデータの遅延を追跡し得、それにおいて、RMは、データの遅延に少なくとも部分的に基づいて、もっと多くのデータがフラグメントに対して要求され得るか否かにその決定を基づかせてよい。たとえば、データの遅延は、データが遅れているものとして分類された時点に続いて受信されたデータのバイト数として計算され得る。別の例として、データの遅延は、受信されているそのデータに続いて要求されたデータのバイト数として計算され得る。遅れたデータの部分ごとにその遅延に基づいて、重み係数が計算され得る。たとえば、遅れたデータの部分の遅延がLBバイトである場合、データのその遅れた部分の重みは1+LB/Kとして計算され得る。別の例として、データのその遅れた部分の重みは、e^LB/Kとして計算されてもよい。さらに別の例として、データのその遅れた部分の重みは、2-e^-LB/UKとして計算されてもよい。重みを計算するために使用される特定の技法にかかわらず、全部の重みwtLは、すべての遅れたデータの重みの合計として計算され得る。実施形態による動作の際には、条件RK+UK<K+XK+wtLが満たされる限り、RM121はフラグメントに対する追加データを要求することが許容されてよい。フラグメントにわたるwtLのここまでの最大値は、代替実施形態による上記の条件におけるwtLで置換され得る。

データがいつ要求されるべきか、また要求されるべきデータの量を決定する際に採用される特定の論理にかかわらず、図3に示すフロー300の実施形態によるRM自動FEC技法の動作の際には、RM121は、要求されているフラグメントのコンテンツデータ、ならびにフラグメントに応答して要求されたフラグメントを超えるFECデータおよび余剰データリクエストを受信する(ブロック304)。上記のRM固定FEC技法と同じく、本明細書のRM自動FEC技法を実施するRM121の実施形態は、フラグメントの復元をもたらすのに十分な最も早く受信されたデータ(フラグメントデータであろうと、フラグメントデータとFECデータの組合せであろうと)を使用してフラグメントを復元し得る。その上、ネットワーク状態(たとえば、遅れたデータの量および要求されているデータの遅延)に基づいて任意の特定のフラグメントに関して、FECデータが要求されるかどうか、およびどれくらいのFECデータが要求されるのかを動的に調整することを通じて、ネットワークを介して転送されるデータの量の増加が、最小化または最適化され得る。フラグメントは、ネットワーク輻輳への影響を最小にして、そのようにRM121によって迅速に復元され得、コンテンツの消費のためにUA129に提供され得る(ブロック305)。

RM自動FEC構成の変形形態では、実施形態のRM121は、フラグメントに関してどれくらいのFECを使用するべきかを自動的に決定するようにも適合され得るだけでなく、FECフラグメントに関するURLを自動的に決定するようにも動作し、それによって、本明細書でRM自動FEC+URLと呼ばれるFECデータ技法を実施する構成のRM121を提供する。RM自動FEC+URL技法の実施形態による動作の際には、RM121は、ソースフラグメントのURLが提供されるUAから、FECフラグメントに関するURLを自動的に決定する。実施形態のRM自動FEC+URL技法はまた、FEC符号化および復号に対して使用するためのシンボルのサイズを決定するRM121を備える(たとえば、RMは、フラグメントのサイズに基づいて、使用するべきシンボルサイズを自動的に決定し、RMはFECフラグメントの第1の部分を読み取り、シンボルサイズはFECフラグメントのプリアンブルの中などで入手可能である)。RM自動FEC+URL技法が、UAによって使用されるいかなるFECセマンティクスまたは論理も有しないUAを含む、いかなるUA構成によっても使用され得ることを諒解されたい(たとえば、FECフラグメントが、UAによって要求されているソースフラグメントに対して利用可能である限り)。RM自動FEC+URL動作のために構成されたUA129とRM121との間に実装され得るような基本APIが、図5に示される。

RM自動FEC+URL構成の変形形態は、冗長符号化データを使用するべきかどうかを実施形態のRM121が自動的に決定するようにさらに適合される構成を提供し、それによって、本明細書でRM完全自動と呼ばれるFECデータ技法を実施する構成のRM121を提供する。RM完全自動技法の実施形態による動作の際には、本明細書の実施形態のRM121が、FECデータを使用するべきか否かを自動的に決定するように動作する。動作の際には、RM121およびCM122が、FECフラグメントが(たとえば、フラグメントまたはフラグメントのシーケンスごとに)利用可能であるか否かを自動的に決定するように協働し得る。たとえば、CM122は、FECフラグメントを求める1つまたは複数のリクエストを送ってよく、それにおいて、RM121がレスポンスに応じてそれらの利用可能性を決定する(たとえば、FECフラグメントが利用可能でないことを示すために、FECフラグメントの一部分を求めるHTTPリクエストへの「404 not found」というレスポンスが利用され得る)。FECフラグメントが利用可能でない場合、RM121およびCM122は、FECデータを使用しない技法による動作に進んでよい。しかしながら、FECフラグメントが利用可能であると決定された場合、RM121およびCM122は、本明細書の概念によるフラグメントリクエストに関連する(たとえば、RM自動FEC+URL技法を実施する)FECデータ技法を利用し得る。したがって、要求されているフラグメントに対してFECデータが利用可能であるとき、FECデータはRM121およびCM122によって自動的に使用され得、FECデータが利用可能でないとき、RM121およびCM122は、それにもかかわらず、FECデータを使用せずに動作し得る。したがって、FECフラグメントが利用可能であろうとなかろうと、任意の構成のUA129が、UAによって使用されるいかなるFECセマンティクスまたは論理も用いることなく、RM完全自動方法を使用することができる。

本明細書で説明するようなRM自動FEC技法の実装形態に関して可能性がある1つのユースケースは、DASHまたはHLSを使用して低レイテンシのライブストリーミングを得るために、RM自動FEC動作用に構成されたRM121が、複数接続動作(たとえば、CM-mHTTP構成)用に構成されたCM122と一緒に実装されることである。

そのようなライブストリーミングの状況では、ビデオカメラによってイベントがキャプチャされるときと、対応するイベントがエンドユーザデバイス上で表示されるときとの間のエンドツーエンドのレイテンシが、最小限に抑えられるべきである。ライブストリームはビデオフラグメントのシーケンスに符号化され、その場合、たとえば、各フラグメントが1秒のビデオストリームを含む。各ビデオフラグメントは、生成されているとき、DASHクライアントまたはHLSクライアントが標準的なHTTP/TCPを使用するフラグメントにそこからアクセスできるHTTPウェブサーバに対して利用可能にされている。より困難なネットワーク状態では、ビデオフラグメントをダウンロードするために単一のHTTP/TCP接続を使用して可能であり得るよりも良好な品質のビデオストリームを提供することができるように、DASHクライアントまたはHLSクライアントが複数のHTTP/TCP接続を使用することが有益である。

重要性の1つの基準は、ビデオのフラグメントがHTTPウェブサーバ上で利用可能であるときから、そのビデオのフラグメントがエンドデバイス上で再生の準備ができたときまでの間の時間として定義される、受信機側のレイテンシである。通常、受信機側のレイテンシは、エンドツーエンドのレイテンシに寄与する主要なものである。したがって、受信機側のレイテンシを最小化することは、エンドツーエンドのレイテンシを最小化することにとって非常に重要であり得る。本明細書の実施形態の実装では、DASHクライアントまたはHLSクライアントがUA129であり、UAは、再生用のフラグメントを提供するためにTA120(RM121およびCM122を備える)を使用しており、それにおいて、フラグメントを復元するのに十分なデータ(フラグメントデータ単独であろうと、フラグメントデータと追加データの組合せであろうと)が受信されるとすぐにフラグメントの復元を容易にするために、複数の接続を使用してFECデータが動的に要求され得る。

上記のことから、トランスポートアクセラレータの実施形態が、ソースフラグメントリクエストの配信を加速させる助けとなるためのソースコンテンツデータ(すなわち、非冗長符号化データ)に加えて、FECデータなどの冗長符号化データを利用することが諒解され得る。そのような冗長符号化データは、冗長符号化データファイルを生成するためのいくつかの知られている技法のいずれかを使用して生成され得る。たとえば、よく知られているFECデータファイル生成技法が、本明細書の実施形態に従って利用され得る。UAがDASHクライアントを備える場合では、たとえば、適切なFECデータファイルは、その開示がこれによって参照により本明細書に組み込まれる「ENHANCED BLOCK-REQUEST STREAMING USING COOPERATIVE PARALLEL HTTP」という名称の米国特許出願第12/887,495号に図示および記載されるような技法を使用して生成され得る。

ソースフラグメントファイルおよび対応する冗長符号化データファイルが同じサーバまたはサーバファーム(たとえば、サーバ130)によって供給される実施形態が本明細書で説明されてきたが、本明細書の概念がそのような実装形態に限定されないことを諒解されたい。たとえば、本明細書の実施形態のTA120は、本明細書の概念に従ってデータのトランスポートの加速をもたらすために、冗長符号化データとは無関係のソースまたはプロバイダに対して動作するように適合され得る。たとえば、コンテンツプロバイダは、そのコンテンツに関するFECデータを提供するという要望、または提供するためのリソースを有しない場合がある。そのような状況では、RM121の一実施形態は、独立したサードパーティFECプロバイダとともに動作するように適合され得る。図6に示すシステム600の構成はこの概念を示し、FECサーバ630が、サーバ130によって提供されるコンテンツに対応する冗長符号化データを提供する。

システム600などの冗長符号化データの独立したソースまたはプロバイダを利用する構成は、本明細書では、コンテンツを転送するように様々な方法で動作し得る。たとえば、実施形態のRM121は、ソースリクエストをコンテンツプロバイダ(サーバ130)に、およびFECリクエストをFECプロバイダ(FECサーバ630)に発行するように動作する。そのような実施形態では、FECプロバイダは、そのようにコンテンツをコンテンツプロバイダから独立にフェッチし得、それをFEC符号化し得、FEC符号化シンボルをRM121へ送り返し得る。したがって、RM121は、すべてのソースデータを最初にフェッチするのではなく、それが要求する任意のリソースに対するFECデータのフェッチを直ちに開始するように動作して、それによって、FECプロバイダが最初にソースセグメント自体をフェッチする必要があり、次いで、符号化されたシンボルをソースへ送る前にデータを符号化しなければならないことの結果として生じるレイテンシを回避し得る。

冗長符号化データとは無関係となるソースまたはプロバイダを利用する構成の別の例では、RM121は、ソースデータと追加データの両方をFECプロバイダ(たとえば、FECサーバ630)経由でフェッチするように動作する。そのような実施形態におけるFECプロバイダは、そのようにプロキシのように動作し得、ソースデータ自体をソースプロバイダ(たとえば、サーバ130)からフェッチし、FECデータをオンザフライで算出する。この実施形態の利点は、コンテンツプロバイダが、FECデータの使用に起因して増大するトラフィックに対処する必要がないことである(たとえば、上記の例では、RM121がソースデータをコンテンツプロバイダに、または追加データをFECプロバイダに要求しており、コンテンツプロバイダは、各データセグメントをFECサーバ630(FEC符号化のために)とUA129の両方へ送る)。

実施形態による動作の際には、FECプロバイダ(たとえば、FECサーバ630)は、簡単かつ一般的な冗長符号化を提供してよい。たとえば、符号化されているデータ単位(たとえば、フラグメント)は、固定であってよくコンテンツによって単独で決定されてよい。FECシンボルサイズも、同様に、固定であってよくコンテンツによって決定されてよい。FECプロバイダが、異なるクライアントのために同じデータを繰り返しFEC符号化する必要性を低減するために、そのような実施形態が利用され得る(たとえば、FECプロバイダは、よくあるコンテンツをキャッシュしてよく、そのようにネットワークトラフィックおよび計算コストをメモリストレージと交換する)。

本明細書の実施形態によれば、FECプロバイダはUAに対して汎用的であってよく、それにおいて、UAは、UAが要求するコンテンツのリソース、すなわち、バイト範囲、シンボルサイズなどを(たとえば、URIを使用して)規定し得、FECプロバイダが、次いで、要求されたFECコーディングをオンザフライでもたらし得る(たとえば、上記の情報がURLクエリストリングの中でFECコンテンツプロバイダに伝えられ得る)。そのような実施形態による動作の際には、FECプロバイダは、要求されたFECデータを正確に提供し得る(または、実行することが実際的でない場合はエラーコードを返し得る)。そのような実施形態の利点は、UAがそのユースケースにとって最もふさわしいパラメータを選択できるようになることである(たとえば、極めて短いエンドツーエンドのレイテンシを提供するUAは、短いエンドツーエンドのレイテンシに関係しないUAと比較して短い保護期間を選択してよい)。

本明細書で説明する技法は、FECプロバイダがなく、したがってFECデータが使用され得ない場合の実施形態に従って適合され得る。たとえば、UAは、FECデータを要求することではなく、検出された遅れている部分に対する重複チャンクリクエストを再発行するためにこの情報を使用することのような、どのリクエストが「遅れている」のかを識別するための、説明されたものと同じかまたは類似のアルゴリズムを使用し得る。したがって、実施形態による動作の際には、TCP接続が極めて遅くデータを受信したか、または新しいデータを本当に受信しなくなった場合、重複リクエストが、消失した部分を取得する際の助けとなり得る。

そのような重複リクエストは、デフォルトでギャップが2つの端部から満たされることになるように、記憶されているセグメントを通常とは逆順で参照してよい。あるいは、UAは、通常のセグメントを参照し得るが、複数のバイト範囲を使用してレスポンスの順序の近似的な逆転を実現してよい(たとえば、6KBから10KBまでのすき間が満たされる必要があることになる場合、クライアントは、9KB〜10KB、8KB〜9KB、7KB〜8KB、6KB〜7KBとしてのHTTPバイト範囲を使用してよく、したがって、ブロックを逆順で受信することになる)。そのような手法にとって良好なブロックサイズは、近似的にTCP MSSのはずである。

クライアントが実施形態に従って適用し得る類似の趣旨におけるさらなる技法は、事前対応方式で、完全にばらばらのチャンクを要求するのでなくデータのオーバーラップした部分を有するチャンクを要求することである。たとえば、ストリームにおける200KBの部分が2つのチャンクの中に要求されるべき場合、第1のチャンクの中の0〜100KBから、および第2のチャンクの中の100KB〜200KBから要求する代わりに、UAは、第1のチャンクの中の0〜100KB、および、たとえば、第2のチャンクの中の94KB〜200KBを要求してよく、その結果、6KBのオーバーラップが得られる。この方策は、チャンクの最後の部分が、レスポンスの中のもっと早い部分よりも大幅な遅延にはるかに遭遇しやすいという事実を考慮に入れる。何らかの早いTCPセグメントが失われた場合、送信者によって受信された重複確認応答は、通常、かなり迅速に再送信をトリガする。送信の末尾に向かうTCPセグメントにとって、同じことが当てはまらない(たとえば、それらの場合、送信者は、再送信をトリガするのに十分な重複ACKを受信しないことがあり、したがって、タイムアウトが起きたときのみデータを再送信することになり、それは通常、ずっと長い時間である)。そのことに加えて、チャンクの中間における任意の遅延は、チャンクの末尾の受信にも遅延を引き起こしやすい。

UAの論理は、必要とされるオーバーラップの量を低減するための方策を実施し得る。たとえば、UAは、チャンクレスポンスの末尾に対する「遅延したACK」を無効化してよく、それによって、最後の少数のTCPセグメントに対してサーバによって見られている重複ACKの尤度を増大させる。

必要とされるオーバーラップの量をさらに低減するために、スマートサーバが使用され得る。たとえば、実施形態のサーバは、送信の最後の部分に対して、一般に使用するものよりもずっと小さいTCPセグメントを送ってよい。

選択された態様が詳細に示され説明されてきたが、以下の特許請求の範囲によって定義されるような本発明の趣旨および範囲から逸脱することなく、本明細書において様々な置換および改変を実施できることが理解されよう。

100 システム
110 クライアントデバイス、ユーザデバイス
111 プロセッサ
112 メモリ
113 入出力(I/O)要素
114 バス
120 トランスポートアクセラレータ
121 リクエストマネージャ
122 コネクションマネージャ
123 インターフェース
124 インターフェース
129 ユーザエージェント
130 サーバ
140 データベース
141 コンテンツファイル
142 コンテンツファイル
143 コンテンツファイル
150 ネットワーク
151 接続、リンク
152 接続、リンク
600 システム
630 FECサーバ

Claims (52)

1. クライアントデバイスのユーザエージェント(UA)へのコンテンツの配信を、前記クライアントデバイスのトランスポートアクセラレータ(TA)によって加速させるための方法であって、
   コンテンツサーバにコンテンツを要求するために前記UAによって提供されるフラグメントリクエストを、前記TAのリクエストマネージャ(RM)によって受信するステップと、
   前記フラグメントリクエストに対応するフラグメントの前記コンテンツを復元する際に前記RMによって使用するための前記フラグメントリクエストのうちのフラグメントリクエストに対して、要求するべき冗長符号化コンテンツデータの量を決定するステップと、
   前記フラグメントリクエストに対して前記量の冗長符号化コンテンツデータがいつ要求されるべきかを、前記RMによって決定するステップとを備え、前記量の冗長符号化コンテンツデータがいつ要求されるべきかを決定する前記ステップが、前に要求されたデータが遅れていると前記RMが見なすステップを備える、
   方法。
2. 前記冗長符号化コンテンツデータが前方誤り訂正(FEC)符号化データを備える、請求項1に記載の方法。
3. 前記UAによって行われている前記フラグメントリクエストのコンテンツを復元するとともに、対応する復元されたフラグメントを前記UAに提供するために、前記RMによって受信されたデータに対して前記RMがFEC復号を採用する、請求項2に記載の方法。
4. 前記コンテンツおよび前記冗長符号化コンテンツデータを要求する際に、また前記要求することに応答して前記コンテンツサーバからコンテンツを送信する際に、ハイパーテキスト転送プロトコル/伝送制御プロトコル(HTTP/TCP)が利用される、請求項1に記載の方法。
5. 前記冗長符号化コンテンツデータの少なくとも一部分を提供するために使用される冗長符号化コンテンツフラグメントの一部分を求めるHTTPリクエストを決定するために、前記フラグメントリクエストと関連したリソース識別情報が使用される、請求項4に記載の方法。
6. 前記フラグメントリクエストのうちの前記フラグメントリクエストに基づいて、複数のチャンクリクエストを前記RMによって決定するステップをさらに備え、前記複数のチャンクリクエストのうちの少なくとも1つのチャンクリクエストが、前記フラグメントリクエストに対応する前記フラグメントの一部分を求めるリクエストを備え、前記複数のチャンクリクエストのうちの少なくとも1つの別のチャンクリクエストが、前記フラグメントリクエストに対応する前記フラグメントと関連した冗長符号化コンテンツフラグメントの一部分を求めるリクエストを備える、
   請求項1に記載の方法。
7. 前記TAのコネクションマネージャ(CM)によって管理されている複数の接続を介して、前記RMによって前記複数のチャンクリクエストのうちの2つ以上を並行して前記コンテンツサーバに要求するステップ
   をさらに備える、請求項6に記載の方法。
8. 前記UAによって要求されている前記フラグメントの一部分を求める前記リクエストが、前記複数の接続の第1の接続を介してコンテンツサーバに対して行われ、前記冗長符号化コンテンツフラグメントの一部分を求める前記リクエストが、前記複数の接続の第2の接続を介して冗長符号化コンテンツデータサーバに対して行われ、前記コンテンツサーバおよび前記冗長符号化コンテンツデータサーバが、別個の独立したサーバである、請求項7に記載の方法。
9. フラグメントに対して要求するべき冗長符号化コンテンツデータの前記量が、前記フラグメントに関するチャンクの受信の間の前記フラグメントに関する同時に遅れているデータの最大量に基づき、第1のデータが前記RMによって要求されているがまだ受信されておらず、かつ少なくともいくつかの第2のデータが前記第1のデータの後に要求されて受信されている場合、チャンク内の前記第1のデータが、特定の時点において遅れているとして分類される、請求項6に記載の方法。
10. 前記フラグメントに対して受信されたデータの総量に、前記フラグメントに対して要求されているがまだ受信されていないデータの量を加えたものが、前記フラグメントのサイズの付加定数分のバイトに、ある時点までの前記フラグメントに関する同時に遅れている前記データの最大量を加えたものを超えない限り、前記RMが、前記フラグメントを求める追加のチャンクリクエストを行うように適合される、請求項9に記載の方法。
11. フラグメントに対して要求するべき冗長符号化コンテンツデータの量を決定する前記ステップが、
    前記フラグメントに対して前に要求されたデータを十分速く受信していないことに基づいて、前記フラグメントに対して要求されるべき追加の冗長符号化コンテンツデータを決定するステップを備え、前に要求されたデータの量が、前に要求された前記データが到達するときに前記RMが前記フラグメントを完全に復元するのに十分であっても、また前に要求された前記データのすべてが前記RMによって受信されるとしても、前記追加の冗長符号化コンテンツデータが要求されるべきと決定される、
    請求項1に記載の方法。
12. フラグメントリクエストに対して要求するべき冗長符号化コンテンツデータの量を決定する前記ステップが、現在のネットワーク状態に少なくとも部分的に基づく、請求項1に記載の方法。
13. 前記現在のネットワーク状態が、現在のダウンロードレート(R)および現在のラウンドトリップ時間(RTT)の関数として決定される帯域幅遅延積を備える、請求項12に記載の方法。
14. フラグメントリクエストに対して要求するべき冗長符号化コンテンツデータの量を決定する前記ステップが、
    前記フラグメントリクエストに対して要求するべきデータの総量を決定するステップを備え、データの前記総量が、冗長符号化コンテンツデータの前記量および誤り訂正符号化されていないコンテンツデータの量を含む、
    請求項1に記載の方法。
15. 複数のフラグメントリクエストの各々に関連して要求するべき冗長符号化コンテンツデータの量を、前記RMによって動的に調整するステップ
    をさらに備える、請求項1に記載の方法。
16. 冗長符号化コンテンツデータが、前記UAによって提供される前記フラグメントリクエストの任意の特定のフラグメントリクエストに関連して要求されるべきかどうかを、前記RMによって決定するステップ
    をさらに備える、請求項1に記載の方法。
17. 冗長符号化コンテンツデータが要求されるべきかどうかを決定する前記ステップが、
    冗長符号化コンテンツデータが、前記UAによって提供される前記フラグメントリクエストのうちの1つまたは複数のフラグメントにとって利用可能であることを、前記TAによって決定するステップを備える、
    請求項16に記載の方法。
18. 前記UAが、冗長符号化コンテンツデータを利用するための論理手段を含まない、請求項1に記載の方法。
19. 前記冗長符号化コンテンツデータが、前方誤り訂正(FEC)符号化データを備える、請求項18に記載の方法。
20. クライアントデバイスのユーザエージェント(UA)へのコンテンツの配信を、前記クライアントデバイスのトランスポートアクセラレータ(TA)によって加速させるために構成された装置であって、
    コンテンツサーバにコンテンツを要求するために前記UAによって提供されるフラグメントリクエストを、前記TAのリクエストマネージャ(RM)によって受信するための手段と、
    前記フラグメントリクエストに対応するフラグメントの前記コンテンツを復元する際に前記RMによって使用するための前記フラグメントリクエストのうちのフラグメントリクエストに対して、要求するべき冗長符号化コンテンツデータの量を決定するための手段と、
    前記フラグメントリクエストに対して前記量の冗長符号化コンテンツデータがいつ要求されるべきかを、前記RMによって決定するための手段とを備え、前記量の冗長符号化コンテンツデータがいつ要求されるべきかを決定するための前記手段が、前に要求されたデータが遅れていると前記RMが見なすための手段を備える、
    装置。
21. 前記冗長符号化コンテンツデータが、前方誤り訂正(FEC)符号化データを備える、請求項20に記載の装置。
22. 前記UAによって行われている前記フラグメントリクエストのコンテンツを復元するとともに前記復元されたフラグメントを前記UAに提供するために、前記RMによって受信されたデータに対して前記RMがFEC復号を採用する、請求項21に記載の装置。
23. 前記コンテンツおよび前記冗長符号化コンテンツデータを要求する際に、また前記要求することに応答して前記コンテンツサーバからコンテンツを送信する際に、ハイパーテキスト転送プロトコル/伝送制御プロトコル(HTTP/TCP)が利用される、請求項20に記載の装置。
24. 前記冗長符号化コンテンツデータの少なくとも一部分を提供するために使用される冗長符号化コンテンツフラグメントの一部分を求めるHTTPリクエストを決定するために、前記フラグメントリクエストと関連したリソース識別情報が使用される、請求項23に記載の装置。
25. 前記フラグメントリクエストのうちの前記フラグメントリクエストに基づいて、複数のチャンクリクエストを前記RMによって決定するための手段をさらに備え、前記複数のチャンクリクエストのうちの少なくとも1つのチャンクリクエストが、前記フラグメントリクエストに対応する前記フラグメントの一部分を求めるリクエストを備え、前記複数のチャンクリクエストのうちの少なくとも1つの別のチャンクリクエストが、前記フラグメントリクエストに対応する前記フラグメントと関連した冗長符号化コンテンツフラグメントの一部分を求めるリクエストを備える、
    請求項20に記載の装置。
26. 前記TAのコネクションマネージャ(CM)によって管理されている複数の接続を介して、前記RMによって前記複数のチャンクリクエストのうちの2つ以上を並行して前記コンテンツサーバに要求するための手段
    をさらに備える、請求項25に記載の装置。
27. 前記UAによって要求されている前記フラグメントの一部分を求める前記リクエストが、前記複数の接続の第1の接続を介してコンテンツサーバに対して行われ、前記冗長符号化コンテンツフラグメントの一部分を求める前記リクエストが、前記複数の接続の第2の接続を介して冗長符号化コンテンツデータサーバに対して行われ、前記コンテンツサーバおよび前記冗長符号化コンテンツデータサーバが、別個の独立したサーバである、請求項26に記載の装置。
28. フラグメントに対して要求するべき冗長符号化コンテンツデータの前記量が、前記フラグメントに関するチャンクの受信の間の前記フラグメントに関する同時に遅れているデータの最大量に基づき、第1のデータが前記RMによって要求されているがまだ受信されておらず、かつ少なくともいくつかの第2のデータが前記第1のデータの後に要求されて受信されている場合、チャンク内の前記第1のデータが、特定の時点において遅れているとして分類される、請求項25に記載の装置。
29. 前記フラグメントに対して受信されたデータの総量に、前記フラグメントに対して要求されているがまだ受信されていないデータの量を加えたものが、前記フラグメントのサイズの付加定数分のバイトに、ある時点までの前記フラグメントに関する同時に遅れている前記データの最大量を加えたものを超えない限り、前記RMが、前記フラグメントを求める追加のチャンクリクエストを行うように適合される、請求項28に記載の装置。
30. フラグメントに対して要求するべき冗長符号化コンテンツデータの量を決定するための前記手段が、
    前記フラグメントに対して前に要求されたデータを十分速く受信していないことに基づいて、前記フラグメントに対して要求されるべき追加の冗長符号化コンテンツデータを決定するための手段を備え、前に要求されたデータの量が、前に要求された前記データが到達するときに前記RMが前記フラグメントを完全に復元するのに十分であっても、また前に要求された前記データのすべてが前記RMによって受信されるとしても、前記追加の冗長符号化コンテンツデータが要求されるべきと決定される、
    請求項20に記載の装置。
31. フラグメントリクエストに対して要求するべき冗長符号化コンテンツデータの量を決定するための前記手段が、
    現在のネットワーク状態に少なくとも部分的に基づいて冗長符号化コンテンツデータの量を決定するための手段を備える、
    請求項20に記載の装置。
32. 前記現在のネットワーク状態が、現在のダウンロードレート(R)および現在のラウンドトリップ時間(RTT)の関数として決定される帯域幅遅延積を備える、請求項31に記載の装置。
33. フラグメントリクエストに対して要求するべき冗長符号化コンテンツデータの量を決定するための前記手段が、
    前記フラグメントリクエストに対して要求するべきデータの総量を決定するための手段を備え、データの前記総量が、冗長符号化コンテンツデータの前記量および誤り訂正符号化されていないコンテンツデータの量を含む、
    請求項20に記載の装置。
34. 複数のフラグメントリクエストの各々に関連して要求するべき冗長符号化コンテンツデータの量を、前記RMによって動的に調整するための手段
    をさらに備える、請求項20に記載の装置。
35. 冗長符号化コンテンツデータが、前記UAによって提供される前記フラグメントリクエストの任意の特定のフラグメントリクエストに関連して要求されるべきかどうかを、前記RMによって決定するための手段
    をさらに備える、請求項20に記載の装置。
36. 冗長符号化コンテンツデータが要求されるべきかどうかを決定するための前記手段が、
    冗長符号化コンテンツデータが、前記UAによって提供される前記フラグメントリクエストのうちの1つまたは複数のフラグメントにとって利用可能であることを、前記TAによって決定するための手段を備える、
    請求項35に記載の装置。
37. 前記UAが、冗長符号化コンテンツデータを利用するための論理手段を含まない、請求項20に記載の装置。
38. 前記冗長符号化コンテンツデータが、前方誤り訂正(FEC)符号化データを備える、請求項37に記載の装置。
39. クライアントデバイスのユーザエージェント(UA)へのコンテンツの配信を、前記クライアントデバイスのトランスポートアクセラレータ(TA)によって加速させるためのコンピュータプログラムであって、
    コンテンツサーバにコンテンツを要求するために前記UAによって提供されるフラグメントリクエストを、前記TAのリクエストマネージャ(RM)によって受信するためのプログラムコードと、
    前記フラグメントリクエストに対応するフラグメントの前記コンテンツを復元する際に前記RMによって使用するための前記フラグメントリクエストのうちのフラグメントリクエストに対して、要求するべき冗長符号化コンテンツデータの量を決定するためのプログラムコードと、
    前記フラグメントリクエストに対して前記量の冗長符号化コンテンツデータがいつ要求されるべきかを、前記RMによって決定するためのプログラムコードとを含み、前記量の冗長符号化コンテンツデータがいつ要求されるべきかを決定するための前記プログラムコードが、前に要求されたデータが遅れていると前記RMが見なすためのプログラムコードを備える、
    コンピュータプログラム。
40. 前記フラグメントリクエストのうちの前記フラグメントリクエストに基づいて、複数のチャンクリクエストを前記RMによって決定するためのプログラムコードをさらに備え、前記複数のチャンクリクエストのうちの少なくとも1つのチャンクリクエストが、前記フラグメントリクエストに対応する前記フラグメントの一部分を求めるリクエストを備え、前記複数のチャンクリクエストのうちの少なくとも1つの別のチャンクリクエストが、前記フラグメントリクエストに対応する前記フラグメントと関連した冗長符号化コンテンツフラグメントの一部分を求めるリクエストを備える、
    請求項39に記載のコンピュータプログラム。
41. フラグメントに対して要求するべき冗長符号化コンテンツデータの前記量が、前記フラグメントに関するチャンクの受信の間の前記フラグメントに関する同時に遅れているデータの最大量に基づき、第1のデータが前記RMによって要求されているがまだ受信されておらず、かつ少なくともいくつかの第2のデータが前記第1のデータの後に要求されて受信されている場合、チャンク内の前記第1のデータが、特定の時点において遅れているとして分類される、請求項40に記載のコンピュータプログラム。
42. フラグメントに対して要求するべき冗長符号化コンテンツデータの量を決定するための前記プログラムコードが、
    前記フラグメントに対して前に要求されたデータを十分速く受信していないことに基づいて、前記フラグメントに対して要求されるべき追加の冗長符号化コンテンツデータを決定するためのプログラムコードを備え、前に要求されたデータの量が、前に要求された前記データが到達するときに前記RMが前記フラグメントを完全に復元するのに十分であっても、また前に要求された前記データのすべてが前記RMによって受信されるとしても、前記追加の冗長符号化コンテンツデータが要求されるべきと決定される、
    請求項39に記載のコンピュータプログラム。
43. 冗長符号化コンテンツデータの量を決定するために、フラグメントリクエストに対して要求するべき冗長符号化コンテンツデータの量を前記プログラムコードによって決定することが、現在のネットワーク状態に少なくとも部分的に基づく、請求項39に記載のコンピュータプログラム。
44. 複数のフラグメントリクエストの各々に関連して要求するべき冗長符号化コンテンツデータの量を、前記RMによって動的に調整するためのプログラムコード
    をさらに備える、請求項39に記載のコンピュータプログラム。
45. 冗長符号化コンテンツデータが、前記UAによって提供される前記フラグメントリクエストの任意の特定のフラグメントリクエストに関連して要求されるべきかどうかを、前記RMによって決定するためのプログラムコード
    をさらに備える、請求項39に記載のコンピュータプログラム。
46. クライアントデバイスのユーザエージェント(UA)へのコンテンツの配信を、前記クライアントデバイスのトランスポートアクセラレータ(TA)によって加速させるために構成された装置であって、
    少なくとも1つのプロセッサと、
    前記少なくとも1つのプロセッサに結合されたメモリとを備え、前記少なくとも1つのプロセッサが、
    コンテンツサーバにコンテンツを要求するために前記UAによって提供されるフラグメントリクエストを、前記TAのリクエストマネージャ(RM)によって受信し、
    前記フラグメントリクエストに対応するフラグメントの前記コンテンツを復元する際に前記RMによって使用するための前記フラグメントリクエストのうちのフラグメントリクエストに対して、要求するべき冗長符号化コンテンツデータの量を決定し、
    前記フラグメントリクエストに対して前記量の冗長符号化コンテンツデータがいつ要求されるべきかを、前記RMによって決定するように構成され、前記量の冗長符号化コンテンツデータがいつ要求されるべきかを決定するように構成された前記少なくとも1つのプロセッサが、前に要求されたデータが遅れていると前記RMが見なすようにさらに構成される、
    装置。
47. 前記少なくとも1つのプロセッサが、
    前記フラグメントリクエストのうちの前記フラグメントリクエストに基づいて、複数のチャンクリクエストを決定するようにさらに構成され、前記複数のチャンクリクエストのうちの少なくとも1つのチャンクリクエストが、前記フラグメントリクエストに対応する前記フラグメントの一部分を求めるリクエストを備え、前記複数のチャンクリクエストのうちの少なくとも1つの別のチャンクリクエストが、前記フラグメントリクエストに対応する前記フラグメントと関連した冗長符号化コンテンツフラグメントの一部分を求めるリクエストを備える、
    請求項46に記載の装置。
48. フラグメントに対して要求するべき冗長符号化コンテンツデータの前記量が、前記フラグメントに関するチャンクの受信の間の前記フラグメントに関する同時に遅れているデータの最大量に基づき、第1のデータが前記RMによって要求されているがまだ受信されておらず、かつ少なくともいくつかの第2のデータが前記第1のデータの後に要求されて受信されている場合、チャンク内の前記第1のデータが、特定の時点において遅れているとして分類される、請求項47に記載の装置。
49. フラグメントに対して要求するべき冗長符号化コンテンツデータの量を決定するように構成された前記少なくとも1つのプロセッサが、
    前記フラグメントに対して前に要求されたデータを十分速く受信していないことに基づいて、前記フラグメントに対して要求されるべき追加の冗長符号化コンテンツデータを決定するようにさらに構成され、前に要求されたデータの量が、前に要求された前記データが到達するときに前記RMが前記フラグメントを完全に復元するのに十分であっても、また前に要求された前記データのすべてが前記RMによって受信されるとしても、前記追加の冗長符号化コンテンツデータが要求されるべきと決定される、
    請求項46に記載の装置。
50. フラグメントリクエストに対して要求するべき冗長符号化コンテンツデータの量を前記少なくとも1つのプロセッサによって決定することが、現在のネットワーク状態に少なくとも部分的に基づく、請求項46に記載の装置。
51. 前記少なくとも1つのプロセッサが、
    複数のフラグメントリクエストの各々に関連して要求するべき冗長符号化コンテンツデータの量を、前記RMによって動的に調整するようにさらに構成される、
    請求項46に記載の装置。
52. 前記少なくとも1つのプロセッサが、
    冗長符号化コンテンツデータが、前記UAによって提供される前記フラグメントリクエストの任意の特定のフラグメントリクエストに関連して要求されるべきかどうかを、前記RMによって決定するようにさらに構成される、
    請求項46に記載の装置。

Images