(57)【要約】  クライアントデバイスのユーザエージェント(UA)へのコンテンツの配信を加速するためのトランスポートアクセラレータ(TA)のシステムおよび方法が、本開示の実施形態に従って提供される。諸実施形態は、接続マネージャ(CM)および要求マネージャ(RM)を実施するTAアーキテクチャを含む。諸実施形態のCMは、コンテンツサーバにコンテンツのチャンクを要求し、コンテンツのチャンクを要求することに応答してデータを受信し(受信されるデータは、コンテンツの要求されたチャンクからの欠落データである)、欠落データの受信肯定応答(ACK)を提供する。コンテンツのチャンクの要求されたチャンクからの欠落データである受信されたデータは、1つまたは複数のコンテンツオブジェクトへの組立のために、通信プロトコルスタックを介してアプリケーションに渡され得る。
2017516336.tif 000002
【特許請求の範囲】
【請求項１】
クライアントデバイスのトランスポートアクセラレータ(TA)によって、前記クライアントデバイスのユーザエージェント(UA)へのコンテンツの配信を加速するための方法であって、
前記UAとコンテンツを提供するように動作可能なコンテンツサーバとの間の通信経路内に配置された前記TAを使用して前記UAのためのメディアトランスポート動作を開始するステップであって、前記TAは、前記コンテンツのどのデータが前記コンテンツサーバに要求されるかを制御するように動作可能である要求マネージャ(RM)と、前記コンテンツの前記データが前記コンテンツサーバにいつ要求されるかを制御するように動作可能である接続マネージャ(CM)とを含み、前記RMは、前記UAと、前記コンテンツの受信されたデータを前記UAに渡すために前記CMによって使用される通信プロトコルスタックとの間の通信経路内に配置される、開始するステップと、
前記CMによって前記RMに、前記CMによって前記コンテンツサーバに要求されたコンテンツの1つまたは複数のチャンクの受信されたデータを渡すステップであって、前記受信されたデータは、コンテンツの前記1つまたは複数のチャンクのうちのチャンクからの欠落データであり、コンテンツストリームへの組立のために前記CMによって前記通信プロトコルスタックを介して前記RMに渡され、前記RMは、前記UAを前記欠落データに関するTA動作から分離するように動作する、渡すステップと、
コンテンツの前記1つまたは複数のチャンクの前記データを前記UAによって要求されたコンテンツのフラグメントに組み立てるステップと、
前記RMによって前記UAに、コンテンツストリームの一部としてコンテンツの前記フラグメントを渡すステップであって、前記RMによって前記UAに渡されるコンテンツの前記フラグメントは、前記欠落データを完成させるコンテンツデータを含む、渡すステップと
を含む方法。
【請求項２】
前記通信プロトコルスタックを介して前記RMに、コンテンツの前記1つまたは複数のチャンクの前記要求されたチャンクからの欠落データである前記受信されたデータを渡す前記ステップは、
前記データが欠落しているところにダミーデータを挿入するステップ
を含む、請求項1に記載の方法。
【請求項３】
前記受信されたデータが、前記1つまたは複数のチャンクのうちの要求されたチャンクからの欠落データであることを前記RMにシグナリングするステップ
をさらに含む、請求項1に記載の方法。
【請求項４】
前記CMによって前記コンテンツサーバに、前記データが欠落していないかのように、少なくとも前記欠落データの受信肯定応答(ACK)を提供するステップ
をさらに含む、請求項1に記載の方法。
【請求項５】
少なくとも前記欠落データのACKを提供する前記ステップは、
前記CMによって前記コンテンツサーバに、少なくとも前記欠落データの前記ACKを選択的に提供するステップであって、前記CMは、クライアントベースのネットワーク輻輳制御を実施するために、前記欠落データのACKを前記コンテンツサーバに提供すべきか否かを選択的に判定するように適合される、選択的に提供するステップ
を含む、請求項4に記載の方法。
【請求項６】
前記RMによって前記CMに、前記欠落データを入手するための1つまたは複数の要求を提供するステップ
をさらに含む、請求項1に記載の方法。
【請求項７】
前記RMによって、前記欠落データを入手するために要求すべき誤り訂正符号化されたデータの量を判定するステップであって、前記誤り訂正符号化されたデータのソースは、前記受信されたデータを提供するのに使用された前記コンテンツサーバ以外のソースを含む、判定するステップ
をさらに含む、請求項6に記載の方法。
【請求項８】
前記コンテンツサーバは、前記TAによって提供されるコンテンツの加速された配信をサポートする動作に関して事前に設計されていないコンテンツサーバを含む、請求項1に記載の方法。
【請求項９】
前記コンテンツサーバは、標準化された伝送制御プロトコル(TCP)動作に従うコンテンツの要求に応答してデータを提供するように動作可能であり、前記受信されたデータは、TCPデータとして受信され、前記通信プロトコルスタックは、TCPスタックを含む、請求項8に記載の方法。
【請求項１０】
クライアントデバイスのトランスポートアクセラレータ(TA)によって、前記クライアントデバイスのユーザエージェント(UA)へのコンテンツの配信を加速するように構成された装置であって、
前記UAとコンテンツを提供するように動作可能なコンテンツサーバとの間の通信経路内に配置された前記TAを使用して前記UAのためのメディアトランスポート動作を開始するための手段であって、前記TAは、前記コンテンツのどのデータが前記コンテンツサーバに要求されるかを制御するように動作可能である要求マネージャ(RM)と、前記コンテンツの前記データが前記コンテンツサーバにいつ要求されるかを制御するように動作可能である接続マネージャ(CM)とを含み、前記RMは、前記UAと、前記コンテンツの受信されたデータを前記UAに渡すために前記CMによって使用される通信プロトコルスタックとの間の通信経路内に配置される、開始するための手段と、
前記CMによって前記RMに、前記CMによって前記コンテンツサーバに要求されたコンテンツの1つまたは複数のチャンクの受信されたデータを渡すための手段であって、受信されたデータは、コンテンツの前記1つまたは複数のチャンクのうちのチャンクからの欠落データであり、コンテンツストリームへの組立のために前記CMによって前記通信プロトコルスタックを介して前記RMに渡され、前記RMは、前記UAを前記欠落データに関するTA動作から分離するように動作する、渡すための手段と、
コンテンツの前記1つまたは複数のチャンクの前記データを前記UAによって要求されたコンテンツのフラグメントに組み立てるための手段と、
前記RMによって前記UAに、コンテンツストリームの一部としてコンテンツの前記フラグメントを渡すための手段であって、前記RMによって前記UAに渡されるコンテンツの前記フラグメントは、前記欠落データを完成させるコンテンツデータを含む、渡すための手段と
を含む装置。
【請求項１１】
前記通信プロトコルスタックを介して前記RMに、コンテンツの前記1つまたは複数のチャンクのうちの要求されたチャンクからの欠落データである前記受信されたデータを渡すための前記手段は、
前記データが欠落しているところにダミーデータを挿入するための手段
を含む、請求項10に記載の装置。
【請求項１２】
前記受信されたデータが、前記1つまたは複数のチャンクのうちの要求されたチャンクからの欠落データであることを前記RMにシグナリングするための手段
をさらに含む、請求項10に記載の装置。
【請求項１３】
前記CMによって前記コンテンツサーバに、前記データが欠落していないかのように、少なくとも前記欠落データの受信肯定応答(ACK)を提供するための手段
をさらに含む、請求項10に記載の装置。
【請求項１４】
少なくとも前記欠落データのACKを提供するための前記手段は、
前記CMによって前記コンテンツサーバに、少なくとも前記欠落データの前記ACKを選択的に提供するための手段であって、前記CMは、クライアントベースのネットワーク輻輳制御を実施するために、前記欠落データのACKを前記コンテンツサーバに提供すべきか否かを選択的に判定するように適合される、選択的に提供するための手段
を含む、請求項13に記載の装置。
【請求項１５】
前記RMによって前記CMに、前記欠落データを入手するための1つまたは複数の要求を提供するための手段
をさらに含む、請求項10に記載の装置。
【請求項１６】
前記RMによって、前記欠落データを入手するために要求すべき誤り訂正符号化されたデータの量を判定するための手段であって、前記誤り訂正符号化されたデータのソースは、前記受信されたデータを提供するのに使用された前記コンテンツサーバ以外のソースを含む、判定するための手段
をさらに含む、請求項15に記載の装置。
【請求項１７】
前記コンテンツサーバは、前記TAによって提供されるコンテンツの加速された配信をサポートする動作に関して事前に設計されていないコンテンツサーバを含む、請求項10に記載の装置。
【請求項１８】
前記コンテンツサーバは、標準化された伝送制御プロトコル(TCP)動作に従うコンテンツの要求に応答してデータを提供するように動作可能であり、前記受信されたデータは、TCPデータとして受信され、前記通信プロトコルスタックは、TCPスタックを含む、請求項17に記載の装置。
【請求項１９】
クライアントデバイスのトランスポートアクセラレータ(TA)によって、前記クライアントデバイスのユーザエージェント(UA)へのコンテンツの配信を加速するためのコンピュータプログラム製品であって、
プログラムコードを記録した非一時的コンピュータ可読媒体を含み、前記プログラムコードは、
前記UAとコンテンツを提供するように動作可能なコンテンツサーバとの間の通信経路内に配置された前記TAを使用して前記UAのためのメディアトランスポート動作を開始するためのプログラムコードであって、前記TAは、前記コンテンツのどのデータが前記コンテンツサーバに要求されるかを制御するように動作可能である要求マネージャ(RM)と、前記コンテンツの前記データが前記コンテンツサーバにいつ要求されるかを制御するように動作可能である接続マネージャ(CM)とを含み、前記RMは、前記UAと、前記コンテンツの受信されたデータを前記UAに渡すために前記CMによって使用される通信プロトコルスタックとの間の通信経路内に配置される、開始するためのプログラムコードと、
前記CMによって前記RMに、前記CMによって前記コンテンツサーバに要求されたコンテンツの1つまたは複数のチャンクの受信されたデータを渡すためのプログラムコードであって、前記受信されたデータは、コンテンツの前記1つまたは複数のチャンクのうちのチャンクからの欠落データであり、コンテンツストリームへの組立のために前記CMによって前記通信プロトコルスタックを介して前記RMに渡され、前記RMは、前記UAを前記欠落データに関するTA動作から分離するように動作する、渡すためのプログラムコードと、
コンテンツの前記1つまたは複数のチャンクの前記データを前記UAによって要求されたコンテンツのフラグメントに組み立てるためのプログラムコードと、
前記RMによって前記UAに、コンテンツストリームの一部として前記UAにコンテンツの前記フラグメントを渡すためのプログラムコードであって、前記RMによって前記UAに渡されるコンテンツの前記フラグメントは、前記欠落データを完成させるコンテンツデータを含む、渡すためのプログラムコードと
を含む、コンピュータプログラム製品。
【請求項２０】
前記受信されたデータが、前記1つまたは複数のチャンクのうちの要求されたチャンクからの欠落データであることを前記RMにシグナリングするためのプログラムコード
をさらに含む、請求項19に記載のコンピュータプログラム製品。
【請求項２１】
前記CMによって前記コンテンツサーバに、前記データが欠落していないかのように、少なくとも前記欠落データの受信肯定応答(ACK)を提供するためのプログラムコード
をさらに含む、請求項19に記載のコンピュータプログラム製品。
【請求項２２】
少なくとも前記欠落データのACKを提供する前記プログラムコードは、
前記CMによって前記コンテンツサーバに、少なくとも前記欠落データの前記ACKを選択的に提供するためのプログラムコードであって、前記CMは、クライアントベースのネットワーク輻輳制御を実施するために、前記欠落データのACKを前記コンテンツサーバに提供すべきか否かを選択的に判定するように適合される、選択的に提供するためのプログラムコード
を含む、請求項21に記載のコンピュータプログラム製品。
【請求項２３】
クライアントデバイスのトランスポートアクセラレータ(TA)によって、前記クライアントデバイスのユーザエージェント(UA)へのコンテンツの配信を加速するように構成された装置であって、
少なくとも1つのプロセッサと、
前記少なくとも1つのプロセッサに結合されたメモリと
を含み、前記少なくとも1つのプロセッサは、
前記UAとコンテンツを提供するように動作可能なコンテンツサーバとの間の通信経路内に配置された前記TAを使用して前記UAのためのメディアトランスポート動作を開始することであって、前記TAは、前記コンテンツのどのデータが前記コンテンツサーバに要求されるかを制御するように動作可能である要求マネージャ(RM)と、前記コンテンツの前記データが前記コンテンツサーバにいつ要求されるかを制御するように動作可能である接続マネージャ(CM)とを含み、前記RMは、前記UAと、前記コンテンツの受信されたデータを前記UAに渡すために前記CMによって使用される通信プロトコルスタックとの間の通信経路内に配置される、開始することと、
前記CMによって前記コンテンツサーバに要求されたコンテンツの1つまたは複数のチャンクの受信されたデータを渡すことであって、前記受信されたデータは、コンテンツの前記1つまたは複数のチャンクのうちのチャンクからの欠落データであり、コンテンツストリームへの組立のために前記CMによって前記通信プロトコルスタックを介して前記RMに渡され、前記RMは、前記UAを前記欠落データに関するTA動作から分離するように動作する、渡すことと、
コンテンツの前記1つまたは複数のチャンクの前記データを前記UAによって要求されたコンテンツのフラグメントに組み立てることと、
コンテンツストリームの一部として前記RMによって前記UAにコンテンツの前記フラグメントを渡すことであって、前記RMによって前記UAに渡されるコンテンツの前記フラグメントは、前記欠落データを完成させるコンテンツデータを含む、渡すことと
を行うように構成される、装置。
【発明の詳細な説明】
【技術分野】
【０００１】
優先権および関連出願の説明
本願は、その開示が参照によって本明細書に組み込まれる、2014年3月18日に出願した同時係属の米国特許仮出願第61/954,936号、名称「TRANSPORT ACCELERATOR IMPLEMENTING EXTENDED TRANSMISSION CONTROL FUNCTIONALITY」、および2014年5月28日に出願した米国特許出願第14/289,181号、名称「TRANSPORT ACCELERATOR IMPLEMENTING EXTENDED TRANSMISSION CONTROL FUNCTIONALITY」の優先権を主張するものである。本願は、それぞれが本願と同時に出願され、その開示全体が参照によって本明細書に明確に組み込まれる、本願と同一の譲受人に譲渡された、2014年5月28日に出願した米国特許出願[整理番号]第14/289,016号、名称「TRANSPORT ACCELERATOR IMPLEMENTING EXTENDED TRANSMISSION CONTROL FUNCTIONALITY」、2014年5月28日に出願した米国特許出願第14/289,348号、名称「TRANSPORT ACCELERATOR IMPLEMENTING ENHANCED SIGNALING」、2014年5月28日に出願した米国特許出願第14/289,403号、名称「TRANSPORT ACCELERATOR IMPLEMENTING REQUEST MANAGER AND CONNECTION MANAGER FUNCTIONALITY」、2014年5月28日に出願した米国特許出願第14/289,458号、名称「TRANSPORT ACCELERATOR IMPLEMENTING SELECTIVE UTILIZATION OF REDUNDANT ENCODED CONTENT DATA FUNCTIONALITY」、2014年5月28日に出願した米国特許出願第14/289,476号、名称「TRANSPORT ACCELERATOR IMPLEMENTING A MULTIPLE INTERFACE ARCHITECTURE」、および2014年5月28日に出願した米国特許出願第14/289,499号、名称「TRANSPORT ACCELERATO
R IMPLEMENTING CLIENT SIDE TRANSMISSION FUNCTIONALITY」に関する。
【背景技術】
【０００２】
ますます多くのコンテンツが、使用可能な通信ネットワークを介して転送されるようになっている。しばしば、これらのコンテンツは、たとえばオーディオデータ、ビデオデータ、イメージデータなどを含む多数のタイプのデータを含む。ビデオコンテンツ、特に高解像度ビデオコンテンツは、相対的に大きいデータファイルまたはデータの他のコレクションをしばしば含む。したがって、そのようなコンテンツを消費しているエンドユーザデバイスまたは他のクライアントデバイス上のユーザエージェント(UA)は、しばしば、所望のビデオコンテンツを含むコンテンツのフラグメントのシーケンスを要求し、受信する。たとえば、UAは、データ、しばしばマルチメディアデータを要求し、さらなる処理およびおそらくはユーザデバイス上での表示のために要求されたデータを受信する、ユーザデバイス上で実行するクライアントアプリケーションまたはクライアントプロセスを含み得る。
【０００３】
多数のタイプのアプリケーションが、現在、前述のコンテンツ配信のためにHTTPに頼る。多くのそのようなアプリケーションにおいて、HTTPトランスポートの性能は、アプリケーションに関するユーザの体験にとって極めて重要である。たとえば、ライブストリーミングは、ビデオストリーミングクライアントの動作を妨げる可能性がある複数の制約を有する。2つの制約が、特に顕著である。第1に、メディアセグメントは、経時的に1つずつ使用可能になる。この制約は、クライアントが、データの大きい部分を継続的にダウンロードするのを妨げ、これは、ダウンロードレート推定の正確さに影響する。ほとんどのストリーミングクライアントは、「要求-ダウンロード-推定」ループ上で動作するので、一般に、ダウンロード推定が不正確であるときは、良好には動作しない。第2に、ライブイベントストリーミングを見るときに、ユーザは、一般に、実際のライブイベントタイムラインからの長い遅延をこうむることを望まない。そのような挙動は、ストリーミングクライアントが大きいバッファを構築するのを妨げ、これは、より多くの再バッファリングを引き起こす可能性がある。
【０００４】
ストリーミングクライアントが、伝送制御プロトコル(TCP)上で動作する(たとえば、ほとんどのDynamic Adaptive Streaming over HTTP(DASH)クライアントと同様に)場合には、前述の厳密なライブイベントタイムラインは、欠落パケットまたは並べ変えられたパケットがあるときに低速化する通常のTCP挙動に反する。組込みTCP輻輳制御機構は、その間にライブイベントを見る人が再バッファリングをスキップし、最新のイベントタイムラインにジャンプすることを望む可能性がより高い、ライブストリーミング中の再バッファリングの効果を悪化させる。
【０００５】
同じ問題が、ダウンロードの完了に関するデッドラインがあり、さもなければペナルティをこうむる、HTTPベースのファイルダウンロードに関しても存在する。たとえば、あるユーザが、ウェブページ、写真にアクセスするか、ウェブベースのアプリケーションを使用することを試みている場合に、長いダウンロード待ち時間は、そのユーザが、そのウェブページまたはウェブベースのアプリケーションの使用を止めることをもたらす可能性がある。
【０００６】
オンデマンドストリーミングも、同様の制約という欠点がある。たとえば、オンデマンドストリーミングにおいて、クライアントデバイスは、ユーザに再生を提供するために、正しい順序でできる限り高速にオンデマンドストリームを受信することを望む。ストリーミングオンデマンドコンテンツの性能は、欠落パケットおよび並べ変えられたパケット、再バッファリングなどによって影響される。
【発明の概要】
【課題を解決するための手段】
【０００７】
クライアントデバイスのトランスポートアクセラレータ(TA)によって、クライアントデバイスのユーザエージェント(UA)へのコンテンツの配信を加速するための方法が、本開示の実施形態に従って提供される。諸実施形態による方法は、TAの接続マネージャ(CM)によって、コンテンツサーバにコンテンツの1つまたは複数のチャンクを要求するステップと、CMによって、コンテンツの1つまたは複数のチャンクを要求するステップに応答して送られたデータを受信するステップであって、受信されたデータは、コンテンツの1つまたは複数のチャンクのうちの要求されたチャンクからの欠落データである、受信するステップと、CMによって、少なくとも欠落データの受信肯定応答(ACK)をコンテンツサーバに提供するステップとを含む。諸実施形態による方法は、1つまたは複数のコンテンツオブジェクトへの組立のために、通信プロトコルスタックを介してアプリケーションに、コンテンツの1つまたは複数のチャンクのうちの要求されたチャンクからの欠落データである受信されたデータを渡すステップをさらに含む。
【０００８】
クライアントデバイスのトランスポートアクセラレータ(TA)によって、クライアントデバイスのユーザエージェント(UA)へのコンテンツの配信を加速する装置が、本開示の実施形態に従って提供される。諸実施形態による装置は、TAの接続マネージャ(CM)によって、コンテンツサーバにコンテンツの1つまたは複数のチャンクを要求するための手段と、CMによって、コンテンツの1つまたは複数のチャンクを要求するための手段に応答して送られたデータを受信するための手段であって、受信されたデータは、コンテンツの1つまたは複数のチャンクのうちの要求されたチャンクからの欠落データである、受信するための手段と、CMによって、少なくとも欠落データの受信肯定応答(ACK)をコンテンツサーバに提供するための手段とを含む。諸実施形態による装置は、1つまたは複数のコンテンツオブジェクトへの組立のために、通信プロトコルスタックを介してアプリケーションに、コンテンツの1つまたは複数のチャンクのうちの要求されたチャンクからの欠落データである受信されたデータを渡すための手段をさらに含む。
【０００９】
クライアントデバイスのトランスポートアクセラレータ(TA)によって、クライアントデバイスのユーザエージェント(UA)へのコンテンツの配信を加速するコンピュータプログラム製品が、本開示の実施形態に従って提供される。諸実施形態によるコンピュータプログラム製品は、プログラムコードを記録した非一時的コンピュータ可読媒体を含む。諸実施形態のプログラムコードは、TAの接続マネージャ(CM)によって、コンテンツサーバにコンテンツの1つまたは複数のチャンクを要求するためのコードと、CMによって、コンテンツの1つまたは複数のチャンクを要求するためのコードに応答して送られたデータを受信するためのコードであって、受信されたデータは、コンテンツの1つまたは複数のチャンクのうちの要求されたチャンクからの欠落データである、受信するためのコードと、CMによって、少なくとも欠落データの受信肯定応答(ACK)をコンテンツサーバに提供するためのコードとを含む。諸実施形態のプログラムコードは、1つまたは複数のコンテンツオブジェクトへの組立のために、通信プロトコルスタックを介してアプリケーションに、コンテンツの1つまたは複数のチャンクのうちの要求されたチャンクからの欠落データである受信されたデータを渡すためのコードをさらに含む。
【００１０】
クライアントデバイスのトランスポートアクセラレータ(TA)によって、クライアントデバイスのユーザエージェント(UA)へのコンテンツの配信を加速するように構成された装置が、本開示の実施形態に従って提供される。諸実施形態の装置は、少なくとも1つのプロセッサと、少なくとも1つのプロセッサに結合されたメモリとを含む。少なくとも1つのプロセッサは、諸実施形態に従って、TAの接続マネージャ(CM)によって、コンテンツサーバにコンテンツの1つまたは複数のチャンクを要求し、CMによって、コンテンツの1つまたは複数のチャンクの要求に応答して送られたデータを受信することであって、受信されたデータは、コンテンツの1つまたは複数のチャンクのうちの要求されたチャンクからの欠落データである、受信することと、CMによって、少なくとも欠落データの受信肯定応答(ACK)をコンテンツサーバに提供することとを行うように構成される。少なくとも1つのプロセッサは、諸実施形態に従って、1つまたは複数のコンテンツオブジェクトへの組立のために、通信プロトコルスタックを介してアプリケーションに、コンテンツの1つまたは複数のチャンクのうちの要求されたチャンクからの欠落データである受信されたデータを渡すようにさらに構成される。
【００１１】
本開示のさらなる実施形態は、クライアントデバイスのトランスポートアクセラレータ(TA)によって、クライアントデバイスのユーザエージェント(UA)へのコンテンツの配信を加速するための方法を提供する。諸実施形態の方法は、UAとコンテンツを提供するように動作可能なコンテンツサーバとの間の通信経路内に配置されたTAを使用してUAのためのメディアトランスポート動作を開始するステップであって、TAは、コンテンツのどのデータがコンテンツサーバに要求されるかを制御するように動作可能である要求マネージャ(RM)と、コンテンツのデータがコンテンツサーバにいつ要求されるかを制御するように動作可能である接続マネージャ(CM)とを含み、RMは、UAと、コンテンツの受信されたデータをUAに渡すためにCMによって使用される通信プロトコルスタックとの間の通信経路内に配置される、開始するステップを含む。この方法は、CMによってRMに、CMによってコンテンツサーバに要求されたコンテンツの1つまたは複数のチャンクの受信されたデータを渡すステップであって、受信されたデータは、コンテンツの1つまたは複数のチャンクのうちのチャンクからの欠落データであり、コンテンツストリームへの組立のためにCMによって通信プロトコルスタックを介してRMに渡され、RMは、UAを欠落データに関するTA動作から分離するように動作する、渡すステップと、コンテンツの1つまたは複数のチャンクのデータをUAによって要求されたコンテンツのフラグメントに組み立てるステップと、RMによってUAに、コンテンツストリームの一部としてコンテンツのフラグメントを渡すステップであって、RMによってUAに渡されるコンテンツのフラグメントは、欠落データを完成させるコンテンツデータを含む、渡すステップとをさらに含む。
【００１２】
本開示の実施形態は、クライアントデバイスのトランスポートアクセラレータ(TA)によって、クライアントデバイスのユーザエージェント(UA)へのコンテンツの配信を加速するように構成された装置を提供する。諸実施形態の装置は、UAとコンテンツを提供するように動作可能なコンテンツサーバとの間の通信経路内に配置されたTAを使用してUAのためのメディアトランスポート動作を開始するための手段であって、TAは、コンテンツのどのデータがコンテンツサーバに要求されるかを制御するように動作可能である要求マネージャ(RM)と、コンテンツのデータがコンテンツサーバにいつ要求されるかを制御するように動作可能である接続マネージャ(CM)とを含み、RMは、UAと、コンテンツの受信されたデータをUAに渡すためにCMによって使用される通信プロトコルスタックとの間の通信経路内に配置される、開始するための手段を含む。この装置は、CMによってRMに、CMによってコンテンツサーバに要求されたコンテンツの1つまたは複数のチャンクの受信されたデータを渡すための手段であって、受信されたデータは、コンテンツの1つまたは複数のチャンクのうちのチャンクからの欠落データであり、コンテンツストリームへの組立のためにCMによって通信プロトコルスタックを介してRMに渡され、RMは、UAを欠落データに関するTA動作から分離するように動作する、渡すための手段と、コンテンツの1つまたは複数のチャンクのデータをUAによって要求されたコンテンツのフラグメントに組み立てるための手段と、RMによってUAに、コンテンツストリームの一部としてコンテンツのフラグメントを渡すための手段であって、RMによってUAに渡されるコンテンツのフラグメントは、欠落データを完成させるコンテンツデータを含む、渡すための手段とをさらに含む。
【００１３】
本開示の実施形態は、クライアントデバイスのトランスポートアクセラレータ(TA)によって、クライアントデバイスのユーザエージェント(UA)へのコンテンツの配信を加速するコンピュータプログラム製品を提供する。このコンピュータプログラム製品は、プログラムコードを記録した非一時的コンピュータ可読媒体を含む。諸実施形態のプログラムコードは、UAとコンテンツを提供するように動作可能なコンテンツサーバとの間の通信経路内に配置されたTAを使用してUAのためのメディアトランスポート動作を開始するためのプログラムコードであって、TAは、コンテンツのどのデータがコンテンツサーバに要求されるかを制御するように動作可能である要求マネージャ(RM)と、コンテンツのデータがコンテンツサーバにいつ要求されるかを制御するように動作可能である接続マネージャ(CM)とを含み、RMは、UAと、コンテンツの受信されたデータをUAに渡すためにCMによって使用される通信プロトコルスタックとの間の通信経路内に配置される、開始するためのプログラムコードを含む。プログラムコードは、CMによってRMに、CMによってコンテンツサーバに要求されたコンテンツの1つまたは複数のチャンクの受信されたデータを渡すためのプログラムコードであって、受信されたデータは、コンテンツの1つまたは複数のチャンクのうちのチャンクからの欠落データであり、コンテンツストリームへの組立のためにCMによって通信プロトコルスタックを介してRMに渡され、RMは、UAを欠落データに関するTA動作から分離するように動作する、渡すためのプログラムコードと、コンテンツの1つまたは複数のチャンクのデータをUAによって要求されたコンテンツのフラグメントに組み立てるためのプログラムコードと、RMによってUAに、コンテンツストリームの一部としてコンテンツのフラグメントを渡すためのプログラムコードであって、RMによってUAに渡されるコンテンツのフラグメントは、欠落データを完成させるコンテンツデータを含む、渡すためのプログラムコードとをさらに含む。
【００１４】
本開示の実施形態は、クライアントデバイスのトランスポートアクセラレータ(TA)によって、クライアントデバイスのユーザエージェント(UA)へのコンテンツの配信を加速するように構成された装置を提供する。この装置は、少なくとも1つのプロセッサと、少なくとも1つのプロセッサに結合されたメモリとを含む。諸実施形態の少なくとも1つのプロセッサは、UAとコンテンツを提供するように動作可能なコンテンツサーバとの間の通信経路内に配置されたTAを使用してUAのためのメディアトランスポート動作を開始するように構成され、TAは、コンテンツのどのデータがコンテンツサーバに要求されるかを制御するように動作可能である要求マネージャ(RM)と、コンテンツのデータがコンテンツサーバにいつ要求されるかを制御するように動作可能である接続マネージャ(CM)とを含み、RMは、UAと、コンテンツの受信されたデータをUAに渡すためにCMによって使用される通信プロトコルスタックとの間の通信経路内に配置される。少なくとも1つのプロセッサは、CMによってコンテンツサーバに要求されたコンテンツの1つまたは複数のチャンクの受信されたデータを渡し、受信されたデータは、コンテンツの1つまたは複数のチャンクのうちのチャンクからの欠落データであり、コンテンツストリームへの組立のためにCMによって通信プロトコルスタックを介してRMに渡され、RMは、UAを欠落データに関するTA動作から分離するように動作し、コンテンツの1つまたは複数のチャンクのデータをUAによって要求されたコンテンツのフラグメントに組み立て、コンテンツストリームの一部としてRMによってUAにコンテンツのフラグメントを渡し、RMによってUAに渡されるコンテンツのフラグメントは、欠落データを完成させるコンテンツデータを含むようにさらに構成される。
【図面の簡単な説明】
【００１５】
【図１】本開示の実施形態による拡張された伝送プロトコル動作に適合されたシステムを示す図である。
【図２】本開示の実施形態に従って適応され得る、欠落データを有するコンテンツストリームの表現を示す図である。
【図３】本開示の実施形態のトランスポートアクセラレータの動作を示すはしご図である。
【図４】本開示の実施形態のトランスポートアクセラレータの要求マネージャの動作を示す流れ図である。
【図５】本開示の実施形態のトランスポートアクセラレータの接続マネージャの動作を示す流れ図である。
【発明を実施するための形態】
【００１６】
「例示的」という単語は、本明細書では、「例、実例、または例証として働く」を意味するのに使用される。本明細書で「例示的」として説明されるすべての態様は、必ずしも、他の態様より好ましいまたは有利と解釈されるべきものではない。
【００１７】
この説明において、「アプリケーション」という用語は、オブジェクトコード、スクリプト、バイトコード、マークアップ言語ファイル、およびパッチなど、実行可能なコンテンツを有するファイルをも含むことができる。さらに、本明細書で参照される「アプリケーション」は、開かれる必要がある可能性がある文書またはアクセスされる必要がある他のデータファイルなど、性質において実行可能ではないファイルをも含むことができる。
【００１８】
この説明内で使用されるときに、「コンテンツ」という用語は、1つまたは複数の品質レベルでのビデオ、オーディオ、ビデオおよびオーディオの組合せ、または他のデータを有するデータを含むことができ、品質レベルは、ビットレート、解像度、または他の要因によって決定される。コンテンツは、オブジェクトコード、スクリプト、バイトコード、マークアップ言語ファイル、およびパッチなど、実行可能なコンテンツをも含むことができる。さらに、「コンテンツ」は、開かれる必要がある可能性がある文書またはアクセスされる必要がある他のデータファイルなど、性質において実行可能ではないファイルをも含むことができる。
【００１９】
この説明内で使用されるときに、「フラグメント」という用語は、ユーザデバイスによって要求され、かつ/またはユーザデバイスにおいて受信される可能性がある、コンテンツの1つまたは複数の部分を指す。
【００２０】
この説明内で使用されるときに、「ストリーミングコンテンツ」という用語は、コンテンツのリアルタイム転送またはある時間期間にわたるコンテンツの転送を可能にする1つまたは複数の標準規格に従ってサーバデバイスから送られ、ユーザデバイスにおいて受信され得るコンテンツを指す。ストリーミングコンテンツ標準規格の例は、デインターリーブされた(または複数の)チャネルをサポートする標準規格およびデインターリーブされた(または複数の)チャネルをサポートしない標準規格を含む。
【００２１】
この説明内で使用されるときに、「コンポーネント」、「データベース」、「モジュール」、「システム」、および同様の用語は、ハードウェア、ファームウェア、ハードウェアとソフトウェアとの組合せ、ソフトウェア、または実行中のソフトウェアのいずれであれ、コンピュータ関連のエンティティを指すことが意図されている。たとえば、コンポーネントは、プロセッサ上で走行するプロセス、プロセッサ、オブジェクト、実行可能ファイル、実行のスレッド、プログラム、および/またはコンピュータとすることができるが、これらであることに限定はされない。実例として、コンピューティングデバイス上で走行するアプリケーションとコンピューティングデバイスとの両方を、コンポーネントとすることができる。1つまたは複数のコンポーネントが、1つのプロセスおよび/または実行のスレッド内に存在することができ、1つのコンポーネントが、1つのコンピュータ上に局所化され、かつ/または複数のコンピュータの間で分散され得る。さらに、これらのコンポーネントは、その上に様々なデータ構造を記憶された様々なコンピュータ可読媒体から実行することができる。コンポーネントは、1つまたは複数のデータパケット(たとえば、ローカルシステム内、分散システム内の別のコンポーネントと相互作用するコンポーネントからのデータ、および/または信号によってインターネットなどのネットワークを介して他のシステムと相互作用するコンポーネントからのデータ)を有する信号に従ってなど、ローカルプロセスおよび/またはリモートプロセスによって通信することができる。
【００２２】
本明細書で使用されるときに、「ユーザ機器」、「ユーザデバイス」、および「クライアントデバイス」という用語は、ウェブサーバにコンテンツを要求し、ウェブサーバからコンテンツを受信し、ウェブサーバに情報を送信することができるデバイスを含む。そのようなデバイスは、静止デバイスまたはモバイルデバイスとされ得る。「ユーザ機器」、「ユーザデバイス」、および「クライアントデバイス」という用語は、交換可能に使用され得る。
【００２３】
本明細書で使用されるときに、「ユーザ」という用語は、ユーザデバイスまたはクライアントデバイス上でコンテンツを受信し、ウェブサイトに情報を送信する個人を指す。
【００２４】
図1に、オーディオデータ、ビデオデータ、イメージデータ、ファイルデータなどを含むことができるなどのコンテンツの、通信ネットワークを介する転送を提供するように本明細書の概念に従って適合されたシステム100を示す。したがって、クライアントデバイス110は、ネットワーク150を介してサーバ130と通信して図示され、これによって、サーバ130は、本開示の概念に従って、データベース140内に記憶された様々なコンテンツをクライアントデバイス110に転送することができる。単一のクライアントデバイスと単一のサーバおよびデータベースとのみが図1に表されているが、システム100が、複数の任意のまたはすべてのそのようなデバイスを含むことができることに留意されたい。たとえば、サーバ130は、サーバファームのサーバを含むことができ、ここで、複数のサーバが、コンテンツ転送に関する高水準の需要にサービスするために、中央におよび/または分散構成で配置され得る。代替案では、サーバ130は、コンテンツの一部またはすべてが、デバイス上でやはり同一位置に配置されるデータベース140(キャッシュ)内に存在し、サーバ130を介してトランスポートアクセラレータ120に提供されるときなどに、トランスポートアクセラレータ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およびUA 129を定義するコンピュータ可読コードセグメントを含む。メモリ112によって記憶されたコードセグメントは、前述のTA 120およびUA 129に加えて、アプリケーションを提供することができる。たとえば、メモリ112は、本明細書の実施形態に従ってサーバ130からのコンテンツにアクセスする際に有用なブラウザなどのアプリケーションを記憶することができる。そのようなブラウザは、サーバ130がウェブサーバである場合に、接続151および152を介しネットワーク150を介してウェブコンテンツにアクセスし、これを見、ハイパーテキスト転送プロトコル(HTTP)を介してサーバ130と通信するための、HTTPウェブブラウザなどのウェブブラウザとすることができる。一例として、HTTP要求は、クライアントデバイス110内のブラウザから、接続151および152を介し、ネットワーク150を介してサーバ130に送られ得る。HTTP応答は、サーバ130から、接続152および151を介し、ネットワーク150を介してクライアントデバイス110内のブラウザに送られ得る。
【００２９】
UA 129は、サーバ130などのサーバにコンテンツを要求し、かつ/またはそのサーバからコンテンツを受信するように動作可能である。UA 129は、たとえば、マルチメディアデータなどのデータを要求し、さらなる処理およびおそらくはクライアントデバイス110のディスプレイ上での表示のために要求されたデータを受信する、ブラウザ、DASHクライアント、HTTPライブストリーミング(HLS)クライアントなどのクライアントアプリケーションまたはクライアントプロセスを含むことができる。たとえば、クライアントデバイス110は、スタンドアローンメディア再生アプリケーションまたはインターネットブラウザ内で走行するように構成されたブラウザベースのメディアプレイヤなど、メディアを再生するためのUA 129を含むコードを実行することができる。諸実施形態による動作において、UA 129は、コンテンツファイルのどのフラグメントまたはフラグメントのシーケンスを、ストリーミングコンテンツセッション中の様々な時点に転送のために要求すべきかを判断する。たとえば、UA 129のDASHクライアント構成は、最近のダウンロード条件に基づくなど、各時点に、コンテンツのどの表現(たとえば、高解像度表現、中解像度表現、低解像度表現など)からのどのフラグメントを要求すべきかを判断するように動作することができる。同様に、UA 129のウェブブラウザ構成は、ウェブページまたはその一部などに関する要求を行うように動作することができる。通常、UAは、HTTP要求を使用してそのようなフラグメントを要求する。
【００３０】
TA 120は、所望のコンテンツのフラグメントまたはフラグメントのシーケンス(たとえば、ビデオストリーミング、ファイルダウンロード、ウェブベースのアプリケーション、全般的なウェブページなどを提供する際に使用され得る前述のコンテンツフラグメント)の向上された配信を提供するために、本明細書の概念に従って適合される。諸実施形態のTA 120は、フラグメント要求を行うために、標準化されたTCP伝送プロトコルを実施するHTTP 1.1インターフェースなどの標準インターフェースのみをサポートする包括的UAまたはレガシUA (すなわち、TAと相互作用するように事前に設計されてはいないUA)が、これらの要求を実行するTAを使用することからそれでも利益を得ることを可能にするように適合される。それに加えてまたはその代わりに、諸実施形態のTA 120は、向上されたインターフェースの機能性を利用するように設計されているUAにさらなる利益を提供するのを容易にするために、向上されたインターフェースを提供する。諸実施形態のTA 120は、標準化されたTCP伝送プロトコルを実施するHTTPインターフェースを介してTCPを使用するなど、既存のコンテンツ転送プロトコルに従ってフラグメント要求を実行するように適合され、これによって、包括的なコンテンツサーバまたはレガシコンテンツサーバ(すなわち、TAと相互作用するように事前に設計されてはいないコンテンツサーバ)が、UAおよびクライアントデバイスにフラグメントの向上された配信を提供すると同時に要求にサービスすることを可能にする。
【００３１】
前述の向上されたフラグメント配信機能性を提供する際に、本明細書の実施形態のTA 120は、本明細書で説明されるアーキテクチャ的コンポーネントおよびプロトコルを含む。たとえば、図1に示された実施形態のTA 120は、下でさらに説明されるように、様々な向上されたフラグメント配信機能性を提供するために協力する要求マネージャ(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と通信する。したがって、UA 129は、クライアントデバイス110内でコンテンツ再生環境を確立するためにプロセッサ111によって実行されるコンテンツプレイヤアプリケーションを含むことができる。特定のコンテンツファイルの再生を開始するときに、UA 129は、コンテンツ識別子(たとえば、1つまたは複数のリスト、マニフェスト、構成ファイル、または、所望のコンテンツのメディアセグメントもしくはフラグメントとそのタイミング境界とを識別する他の識別子)を入手するために、サーバ130のコンテンツ配信プラットフォームと通信することができる。メディアセグメントとそのタイミングとに関する情報は、コンテンツの再生に関するフラグメントの要求を制御するために、UA 129のストリーミングコンテンツ論理によって使用される。
【００３６】
サーバ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は、単一方向接続(たとえば、3GPP TS.26.346に記載されたプロトコルおよびサービスを使用するMBMSネットワークまたはATSC 3.0ネットワーク)を介してネットワーク150に接続され得る。接続は、有線接続とすることができ、あるいは、ワイヤレス接続とすることができる。
【００３９】
図1に示された実施形態のクライアントデバイス110は、本明細書の概念に従って所望のコンテンツのフラグメントまたはフラグメントのシーケンスの向上された配信を提供するように動作可能なTA 120を含む。上で論じたように、図示の実施形態のTA 120は、様々な向上されたフラグメント配信機能を提供するために協力するRM 121およびCM 122を含む。諸実施形態のUA 129とRM 121との間のインターフェース124およびRM 121とCM 122との間のインターフェース123は、HTTP様接続を提供する。たとえば、前述のインターフェースは、本明細書の実施形態による向上されたフラグメント配信のある種の機能的態様をサポートするために、標準HTTPプロトコルを使用し、また追加シグナリングを含むことができる(たとえば、HTTPに類似するシグナリング技法を使用して提供される)。
【００４０】
諸実施形態による動作において、RM 121は、UA 129からフラグメントの要求を受信し、要求されたフラグメントを信頼できる形で受信し、回復するために、CM 122にどのデータを要求すべきかを判断する。本明細書の実施形態によれば、RM 121は、包括的UAまたはレガシUA(すなわち、RMと相互作用するように事前に設計されてはいないUA)からフラグメント要求を受信し、これに応答するように適合され、これによって、そのようなレガシUAとの互換性を提供する。したがって、RM 121は、TA 120の拡張された伝送プロトコル動作からUA 129を分離するように動作することができる。しかしながら、以下の議論からより十分に理解されるように、UA 129は、拡張された伝送プロトコル動作のために適合され得、これによって、RM 121およびUA 129は、拡張された伝送プロトコル動作の特徴を実施するためのRM 121とUA 129との間でのシグナリングの使用を介するなど、拡張された伝送プロトコル動作の1つまたは複数の特徴を実施するために協力する。
【００４１】
諸実施形態のRM 121によってCM 122に対して行われるデータ要求(本明細書では「チャンク要求」と称し、要求されるデータは、「チャンク」を含む)のサイズは、UA 129によって要求され、RM 121が回復しているフラグメントのサイズよりはるかに小さくすることができる。したがって、UA 129からの各フラグメント要求は、そのフラグメントを回復するために複数のチャンク要求を生成し、CM 122に対してそれらの要求を行うためにRM 121をトリガすることができる。
【００４２】
CM 122に対してRM 121によって行われるチャンク要求の一部は、すでに要求されたがまだ到着しておらず、絶対に到着しないか到着が遅すぎる可能性があるとRM 121が考えたデータに関するものである可能性がある。それに加えてまたはその代わりに、CM 122に対してRM 121によって行われるチャンク要求の一部は、オリジナルフラグメントから生成されたFEC符号化されたデータに関するものである可能性があり、これによって、RM 121は、フラグメントまたはその一部を回復するために、CM 122から受信されたデータをFEC復号することができる。RM 121は、回復されたフラグメントをUA 129に配信する。したがって、FECデータを使用せず、したがってオリジナルソースフラグメントからのデータの一部を要求するのみである基本RM構成(RM-basic)と、オリジナルソースフラグメントからのデータの一部ならびにソースフラグメントから生成された一致するFECフラグメントを要求することができるFEC RM構成(RM-FEC)とを含むことができるなど、本明細書の実施形態によるRMの様々な構成があり得る。
【００４３】
諸実施形態のRM 121は、タイミング制約および/または帯域幅可用性制約を知らない可能性があり、これによって、RM 121とCM 122との間の相対的に単純なインターフェースを容易にし、したがって、RM 121は、RM 121によるそのような制約の考慮なしで、チャンク要求を行うように動作することができる。代替案では、RM 121は、CM 122またはクライアントデバイス110内の他のモジュールによってRM 121に供給され得るなど、タイミング制約および/または帯域幅可用性制約を知るように適合され得、したがって、RM 121は、そのような制約に基づいてチャンク要求を行うように動作することができる。
【００４４】
諸実施形態のRM 121は、複数の異なるCM構成と共に動作するように適合される。その上、いくつかの実施形態のRM 121は、複数のCMに同一のフラグメントまたはフラグメントのシーケンスのデータチャンクを要求するためなど、複数のCMと同時にインターフェースすることができる。各そのようなCMは、たとえば、異なるネットワークインターフェースをサポートすることができる(たとえば、第1のCMは、オンデバイスキャッシュへのローカルインターフェースを有することができ、第2のCMは、3GネットワークインターフェースへのHTTP/TCP接続を使用することができ、第3のCMは、4G/LTEネットワークインターフェースへのHTTP/TCP接続を使用することができ、第4のCMは、WiFiネットワークインターフェースへのHTTP/TCP接続を使用することができるなど)。
【００４５】
諸実施形態による動作において、CM 122は、チャンク要求を受信するためにRM 121とインターフェースし、これらの要求をネットワーク150を介して送信する。CM 122は、チャンク要求に対する応答を受信し、その応答をRM 121に戻って渡し、UA 129によって要求されたフラグメントは、受信されたチャンクから解決される。CM 122の機能性は、RM 121によって行われたチャンク要求のデータをいつ要求すべきかを判断するように動作する。本明細書の実施形態によれば、CM 122は、包括的サーバまたはレガシサーバ(すなわち、TAと相互作用するように事前に設計されてはいないサーバ)にチャンクを要求し、これからチャンクを受信するように適合される。たとえば、CM 122がそれにデータを要求するサーバは、標準HTTPウェブサーバを含むことができる。代替案では、CM 122がそれからデータを受信するサーバは、マルチメディア放送マルチメディアシステム(MBMS)サービス展開内で使用されるBM-SCサーバを含むことができる。
【００４６】
上で論じたRM 121と同様に、諸実施形態によるCMの様々な構成があり得る。たとえば、複数接続CM構成(たとえば、CM-mHTTP)が提供され得、これによって、CMは、複数のTCP接続を介してHTTPを使用するように適合される。複数接続CM構成は、ネットワーク条件、データの需要、輻輳ウィンドウなどに依存するなど、接続(たとえば、TCP接続)の個数を動的に変更するように動作することができる。別の例として、拡張された伝送プロトコルCM構成(たとえば、CM-xTCP)が提供され得、ここで、CMは、TCP接続の拡張された形(本明細書ではxTCPと称する)の上でHTTPを使用する。そのような拡張された伝送プロトコルは、本明細書の概念に従うTA 120によるフラグメントの向上された配信を容易にするように適合された動作を提供することができる。たとえば、xTCPの実施形態は、送信されたパケットが失われたときであっても、サーバに戻って肯定応答を提供する(パケットが失われたときのTCPの重複肯定応答方式とは対照的に)。そのようなxTCPデータパケット肯定応答方式は、データパケットが欠落しているとの判定に応答してデータパケットが送信されるレートをサーバが下げることを回避するために、TA 120によって利用され得る。さらに別の例として、プロプライエタリプロトコルCM構成(たとえば、CM-rUDP)が提供され得、CMは、プロプライエタリユーザデータグラムプロトコル(UDP)プロトコルを使用し、サーバから応答データを送信するレートは、一定の事前に構成されたレートとされ得、あるいは、ネットワークを望ましくなく輻輳させることなく、送信レートができる限り高いことを保証するために、プロトコル内にレート管理があるものとすることができる。そのようなプロプライエタリプロトコルCMは、そのプロプライエタリプロトコルをサポートするプロプライエタリサーバと協力して動作することができる。
【００４７】
図示の実施形態が、CM 122がソースファイルからのデータをサーバ130に要求することに関して議論されたが、CMがデータにアクセスするために有するインターフェースのタイプに依存して、ソースファイルが、サーバ上で使用可能である可能性があり、あるいは、クライアントデバイス上でローカルに記憶される可能性があることを了解されたい。いくつかの実施形態において、一致するソースファイルからFEC符号化を使用して生成された修復シンボルを含むFECファイルも、サーバ上で使用可能である場合がある。そのような実施形態において、たとえば、ソースファイルごとに1つのFECファイルがある可能性があり、各FECファイルは、データを要求するのに使用されるCMの特定の実施形態とは独立の、当技術分野で既知のFEC符号化技法を使用してソースファイルから生成される。
【００４８】
さらに、諸実施形態によれば、クライアントデバイス110は、本明細書でヘルパデバイスと称する1つまたは複数の他のデバイス(たとえば、近くに配置された様々な構成のデバイス)に接続できる(たとえば、WiFiインターフェースまたはBluetooth(登録商標)インターフェースを介して)場合があり、そのようなヘルパデバイスは、3G接続またはLTE接続を介し、潜在的には異なるヘルパデバイスに関して異なる搬送波を介して、サーバ130などの1つまたは複数のサーバへの接続性を有することができる。したがって、クライアントデバイス110は、サーバ130などの1つまたは複数のサーバにチャンク要求を送るのに、ヘルパデバイスへの接続性を使用できる場合がある。この場合に、それに接続し、チャンク要求を送り、ヘルパデバイスの各々への応答を受信すべき、TA 120内のCMがある場合がある。そのような実施形態において、ヘルパデバイスは、同一のサーバまたは異なるサーバに同一のフラグメントに関する異なるチャンク要求を送ることができる(たとえば、同一のフラグメントが、複数のサーバ上でヘルパデバイスから使用可能である場合があり、たとえば、異なるサーバが、同一のまたは異なるコンテンツ配信ネットワークプロバイダによって提供される)。
【００４９】
諸実施形態による動作において、RM 121からの要求に応答して一般にフルデータを供給するが、CM 122は、それでも、いくつかの状況においてRM 121に部分的応答を供給することができる。そのような部分的応答は、要求されたデータのすべてではなく、データのうちでRMによって要求された部分をRM 121に提供するためのものであり得る(すなわち、CM 122によって提供される1つまたは複数の応答内にデータギャップまたは穴がある場合がある)。諸実施形態のCM 122は、できる限り早く(たとえば、おそらくは、各応答内で一時に2〜3バイトのみをRMに提供することを控えるために応答を集約するのに十分な遅延を含む)、RM 121に応答を提供するように動作する。たとえば、CM 122は、コンテンツの要求されたチャンクのいくつかの部分がまだCM 122によって受信されていないのに、インターフェース123のTCPスタックを介してRM 121にデータを渡すことができる。したがって、前述の部分的応答は、それらが使用可能になるや否や、諸実施形態に従ってRM 121に提供され得る。
【００５０】
前述の部分的応答を容易にする際に、諸実施形態のCM 122によってRM 121に提供される応答は、返されるデータのバイト範囲の表示を含むことができる。たとえば、CMによって提供されるフラグメントのバイト0〜15999に関するRM要求に対する応答は、バイト0〜3599、バイト4500〜7699、およびバイト9000〜14999を含むことができ(すなわち、バイト3600〜4499、バイト7700〜8999、およびバイト15000〜15999のデータは、応答から欠落している)、したがって、諸実施形態のCM 122からの応答は、部分的応答を示し、かつ/または返されるデータのバイト範囲を示すために増補され、たとえば、バイト範囲は、HTTP応答ヘッダまたはその同等物内で搬送される。返されるデータのバイト範囲を示すように動作可能な実施態様のさらなる例として、諸実施形態のCM 122とRM 121との間のインターフェースは、別々のソフトウェアAPIを含むことができ、「良い」バイト範囲および/または「悪い」バイト範囲が、実際のデータストリームとは別々にシグナリングされる。それに加えてまたはその代わりに、シグナリングは、CMからRMに返されるデータが、受信された実際のデータと、ダミーデータと、どの部分が正しく受信され、どの部分が正しく受信されなかったのかを指定するための特殊なマーカーとの両方を含むという意味において、「ストリーム内で」実行され得る。たとえば、そのようなシグナリングのために追加のインターフェースを利用することなく、特殊なビットパターンが、データの受信側(たとえば、この場合にはRM)がデータストリームを解析し、正しく受信されたデータだけを抽出するのを容易にするためのマーカーとして利用され得る。したがって、諸実施形態のRM 121とCM 122との間に設けられるTA 120のインターフェース123は、前述の通信を容易にするための向上されたインターフェース(たとえば、HTTP 1.1インターフェースプロトコルに基づく向上されたインターフェース)を提供する。
【００５１】
諸実施形態のCM 122は、それに加えてまたはその代わりに、本明細書の概念に従って、他の有用な情報をRM 121に提供する。たとえば、CM 122は、おそらくは測定が行われたときを示すタイムスタンプと組み合わされた、ダウンロードされたデータの集約量の表示をRM 121に提供し得る。RM 121は、RMが複数のCMとインターフェースしているときに、チャンク要求のどの部分を特定のCMに送るべきかを判断することを含む様々な目的のために、そのような情報を利用することができる。別の例として、RM 121は、この情報を集約し、UAが将来にどのフラグメント要求をRMに提供すべきかを判定するのにこの情報を使用できるようにするために、これをUA 129に提供することができる。たとえば、RM 121が、ダウンロード速度が最後の5秒にわたって平均1Mbpsになることを示す情報をUA 129に戻って渡す場合に、UAは、次のフラグメント要求が、750Kbpsで符号化されるビデオフラグメントに関するものでなければならないと判断するのにこの情報を使用することができるが、この情報が、ダウンロード速度が最後の5秒にわたって平均2Mbpsになることを示す場合に、UAは、次のフラグメント要求が、1.5Mbpsで符号化されるビデオフラグメントに関するものでなければならないと判断することができる。したがって、諸実施形態のUA 129とRM 121との間に設けられるTA 120のインターフェース124は、前述の通信を容易にするための向上されたインターフェース(たとえば、HTTP 1.1インターフェースプロトコルに基づく向上されたインターフェース)を提供する。
【００５２】
前に述べたように、諸実施形態のTA 120は、HTTPインターフェースを介してTCPを使用することなど、既存のコンテンツ転送プロトコルに従ってフラグメント要求を実行するように適合される。したがって、諸実施形態のCM 122は、そのTCP受信器を利用することなど、TCPに従うシグナリングを使用してチャンク要求をサーバ130に提供するように適合される。しかし、既存のTCP実施態様は、欠落パケットまたは並べ変えられたパケットがストリーム内で検出されるときに低速化するように動作する。したがって、本明細書の実施形態のCM 122は、したがってTA 120は、拡張された伝送プロトコルを実施するように適合される。たとえば、CM 122は、本明細書でCM-xTCPと呼ばれる拡張された伝送プロトコル構成を含むことができ、これによって、CM 122は、本明細書でxTCPと呼ばれる、TCP接続の拡張された形の上でHTTPを使用する。CM 122は、本明細書で説明されるように、xTCP動作のために適合されたTCP受信器(すなわち、xTCP受信器)を含むことができる。xTCPの実施形態は、パケットが失われるときであってもサーバ130に戻って肯定応答を提供することによって、TA 120によるUA 129へのフラグメントの向上された配信を容易にする。すなわち、諸実施形態のxTCPは、欠落パケットの再送信のための重複ACKなどの挙動をバイパスする、変更されたTCPを提供する。本明細書の概念に従うxTCPの実施態様は、ネットワーク内で過度な輻輳を引き起こさずに高速ダウンロードを達成するように適合される。動作において、xTCPプロトコルは、データが要求のプレフィックスではない(すなわち、要求に応答してCMに返されるデータ内に穴がある可能性がある)場合であっても、サーバ130から受信されたすべてのデータを即座に提供することができる。前述のxTCPデータパケット肯定応答は、データパケットが欠落していることの判定に応答してデータパケットが送信されるレートをサーバが下げることを回避するのに利用される。
【００５３】
xTCPの前述の動作を理解する際に、既存のTCPに従って提供される動作を再検討することが役に立つ。通常のTCP受信器は、NextByteExpectedおよびLastByteReceivedを含む、ストリーミングコンテンツに関する複数の重要な内部パラメータを使用する。これらのパラメータは、図2のコンテンツストリーム200内にNextByteExpected 210およびLastByteReceived 220として図示されている。NextByteExpectedの前のすべてのデータは、完全に受信され、したがって、アプリケーションによって読み取られ得、その後にTCPレイヤによって破棄され得る。しかし、NextByteExpectedとLastByteReceivedとの間には、欠落データ(たとえば、受信されたデータ内の欠落データパケットまたは「穴」)がある場合とない場合とがある。欠落データ230によって表されるように、データ内に穴があるときには、LastByteReceivedの値は、NextByteExpectedの値より大きくなり、この2つのバイトオフセットの間のデータは、TCPレイヤによってバッファリングされなければならず、アプリケーションによって読み取られ得ない。受信ウィンドウ(RWND)の左エッジを、NextByteExpectedより先に進めることもできない。
【００５４】
既存のTCP実施態様において、受信器は、NextByteExpectedまでのデータ受信肯定応答(ACK)だけを提供する。その後、順序が乱れたパケットが、NextByteExpectedに対応するデータのバイトを含まない、NextByteExpectedとLastByteReceivedとの間の欠落データと共に受信される(すなわち、NextByteExpectedから始まる欠落データの穴がまだある)場合に、受信器は、NextByteExpectedに対応する重複ACKを送出する。送信側(たとえば、コンテンツサーバ)は、そのような重複ACKを、ネットワーク内の輻輳のしるしと解釈し、輻輳ウィンドウを縮小する目的で送出レートを低速化することによって反応し、輻輳ウィンドウは、任意の時に未解決とされ得るバイト数を決定する係数である。たとえば、コンテンツサーバは、3つなどの所定の個数の重複ACKを受信した後に、2倍だけ輻輳ウィンドウを縮小することができ、これによってTCPの送出レートを低速化する。輻輳ウィンドウは、ラウンドトリップ時間(RTT)(すなわち、データの要求に対する応答に必要な時間)に比例して拡大されるのみである。たとえば、さらなる重複ACKが検出されない場合に、コンテンツサーバは、1RTTあたり1パケットだけ輻輳ウィンドウを拡大することができる。したがって、TCPの送出レートは、しばしば、特に長いRTTが経験される場合に、増加が非常に遅い。
【００５５】
本明細書の実施形態のCM 122によるxTCPの実施態様は、パケット消失またはある種のシナリオでのパケット消失が、サーバ130による送出レートの低速化をもたらさない形でTCPの動作を変更する。諸実施形態による動作において、xTCPは、パケットがサーバ130からクライアントデバイス110への伝送において失われるときであっても、サーバ130に戻って肯定応答を提供することによって、TA 120によるUA 129へのフラグメントの向上された配信を容易にする。その上、諸実施形態は、本明細書で説明されるように、xTCP動作を容易にするように適合された要求送出技法を実施することができる。たとえば、チャンク要求が時宜を得て送られることを保証するために、TA 120は、そうでなければ要求を送出するときに追加の遅延(たとえば、RTT程度の)を導入する可能性がある、ネーグル(Nagle)のアルゴリズムを使用不能にするように動作することができる(たとえば、通常のTCP受信器の一部としてしばしば実施され得るように)。これは、CM 122がTCP_NODELAYソケットオプションをセットすることによって、諸実施形態に従って達成され得る。本明細書の実施形態によって実施される要求送出技法のさらなる適合は、チャンクに関する要求のサイズを小さく(たとえば、これらが1つのパケットにおさまるように、1最大セグメントサイズ(MSS)未満に)することと、チャンク要求が複数のパケット内で送られることに起因してチャンク要求の一部が失われる危険性を低下させるためなど、チャンク要求を1つのsend()システム呼出し内で送ることとを含むことができる。
【００５６】
TCPなどの多数のコンテンツ転送プロトコルによれば、アップリンクは、相対的にわずかなデータだけを送り、したがって、入手されていないパケットの高速再送信を入手することは、むずかしい可能性がある。したがって、アップリンク消失を軽減するように動作可能な技法が、諸実施形態に従うTA 120によるフラグメントの向上された配信を容易にするために実施され得る。たとえば、各チャンク要求が1パケット内で送られ、TA 120が、2つの要求を1つの接続上でパイプライン化する場合に、2つのパイプライン化されたチャンク要求のうちの第1の要求が失われる場合に、TA 120は単一の重複ACKを提供される。そのような重複ACKの受信は、しばしば、再送信をトリガするのに十分ではなく、したがって、第1のチャンク要求は、一般に、再送信タイムアウトが発生した後になるまで再送されず、この再送信タイムアウトは、比較的長い時間になる可能性がある。第1のチャンク要求に対する応答は、同様に、大幅に遅延される。したがって、アップリンク消失軽減のための技法が、本明細書の実施形態のTA 120によって実施される。
【００５７】
アップリンク消失軽減技法を実施する際に、いくつかのコンテンツ転送プロトコル実施態様(たとえば、TCP)が、前述のアップリンクなど、データをほとんど送信しないストリームのためのアルゴリズムを有することを了解されたい。たとえば、Linux(登録商標)において、「薄ストリーム」最適化は、飛行中のデータがほとんどない状況において、単一の重複ACK(たとえば、3つの重複ACKではなく)の後の再送信を提供する。本明細書のxTCP動作を実施する実施形態は、xTCPコンテンツ転送アクセラレーションに対するアップリンク消失の影響を軽減するために、チャンクの要求に使用される制御ストリームに関して、おそらくは他の特徴または技法(たとえば、下で説明される)と組み合わせて、そのような特徴を使用可能にすることができる。
【００５８】
諸実施形態は、要求セグメントが失われるときに、重複ACKをトリガするために、各チャンク要求の後にプロトコルデータユニット(たとえば、TCPセグメント)を追加するように適合され得る。そのような技法を実施する際に、HTTP GET要求が、不変のプレフィックス「GET」を有し、これによって、TA 120が、まず投機的にそのプレフィックスを送り、次いで、送るべき要求が実際にあるときなど、後刻に要求の残りを送るように適合され得ることを了解されたい。次いで、TA 120は、次の要求の投機的な「GET」をもう一度送ることができる。要求の関連部分が失われる場合には、DUP ACKが、サーバ130が受信する「GET」部分によってトリガされ、失われたチャンク要求を再送信するようにTA 120に促す。同様に、投機的プレフィックスが、同一の形で再送信され得る。この技法の実施態様を介して、ワーストケース遅延(たとえば、タイムアウトに起因する再送信)が、1要求当たりに使用されるより多数のパケットに起因する、よりいくらか多数の再送信を犠牲にして、回避され得る。
【００５９】
図3のはしご図(UA 129とRM 121とCM 122とサーバ130との間の相互作用を表すシーケンスチャート300)、図4の流れ図(RM 121による処理を表すフロー400)、および図5(CM 122による処理を表すフロー500)は、本明細書の概念によるこの動作を示す。
【００６０】
UA 129は、たとえば、ストリーミングコンテンツセッションに関連して、コンテンツのフラグメントの要求(たとえば、図3のフラグメント要求301)を発行することができる。UA 129によって発行されるフラグメント要求は、標準通信プロトコル(たとえば、TCP)または本明細書の概念による拡張された通信プロトコル(たとえば、xTCP)を利用することができる。たとえば、下の議論から了解されるように、諸実施形態のRM 121は、UA 129に完全なフラグメント応答を提供するように動作し、これによって、トランスポートアクセラレータの利益を受け取るためのレガシUAの変更を必要とせずに、TA 120の向上された動作を容易にする。
【００６１】
図3〜図5に示された例は、単純さのために単一のフラグメントと単一のチャンク要求/応答とを示すが、複数のそのような要求および応答が、並列におよび/または直列にのいずれであれ、実行され得ることを了解されたい。たとえば、UA 129は、任意の特定の時点に、RM 121に関して保留中の複数のフラグメント要求を有することができる。その上、RM 121は、UA 129によって要求された1つまたは複数のフラグメントの、CM 122に関して保留中の複数のチャンク要求を有することができ、同様に、CM 122は、任意の特定の時点に、サーバ130に関して保留中の複数のチャンク要求を有することができる。
【００６２】
RM 121は、標準通信プロトコル(たとえば、TCP)または本明細書の概念による拡張された通信プロトコル(たとえば、xTCP)を利用するなど、フラグメント要求を、直列および/または並列でCM 122に次のチャンク要求として発行され得る(たとえば、図3のチャンク要求302および図4のブロック401)複数のチャンク要求に分解することができる。チャンク要求302などのチャンク要求は、諸実施形態によるファイルまたはファイルのバイトレンジに関するHTTPリクエストを含み得る。
【００６３】
RM 121からチャンク要求を受信したことに応答して、CM 122は、ストリーミングコンテンツのコンテンツデータの次のチャンクに関する要求(たとえば、図3のチャンク要求303)をサーバ130に発行する(図5のブロック501)ことができる。CM 122とRM 121との間で提供されるシグナリングは、チャンク要求レディネスシグナリングに加えてまたはその代わりに、チャンクサイズシグナリングなどの情報を含むことができる。諸実施形態のCM 122は、サーバ130に発行されるチャンク要求に関して、拡張された通信プロトコル(たとえば、xTCP)を使用する。そのような拡張された通信プロトコルの動作が、サーバ130の挙動を制御することができるが、サーバ130は、それでも、本発明の実施形態に従って、拡張された通信プロトコルによる動作のために特に適合されてはいない標準レガシサーバを含むことができることを了解されたい。しかし、以下の議論からよりよく理解されるように、諸実施形態のCM 122の動作は、拡張された通信プロトコルに従って適合される。
【００６４】
CM 122は、要求されたコンテンツデータまたはその何らかの部分(たとえば、図2のコンテンツストリーム200)を含む複数のデータパケット(たとえば、図3のパケット304)を受信する(図5のブロック502)ことができる。コンテンツストリームが、穴または欠落データを全く含まない(たとえば、遅れたデータまたは順序が乱れたデータが図5のブロック503で検出されない)場合には、CM 122は、通常の通信プロトコル(たとえば、TCP)動作に従ってサーバ130に適当な1つまたは複数のACK(たとえば、図3のACK 305)を送出し(図5のブロック504)、データパケットを、RM 121への提供のために要求されたチャンクに組み立てる(図5のブロック505)ことができる。
【００６５】
しかしながら、拡張された通信プロトコル(たとえば、xTCP)に従うCM 122の動作において、CMは、欠落データ(たとえば、図2の欠落データ230)があるか否かにかかわりなく、受信された最後のバイト(たとえば、図2のLastByteReceived 220)までのACKをサーバ130に送出することができ、これによって、サーバ130が、レガシ通信プロトコル(たとえば、通常のTCP)技法に従って動作可能である場合であっても、輻輳ウィンドウを縮小するサーバ130の動作を防ぐ。したがって、コンテンツストリームが、穴または欠落データを含む(たとえば、遅れたデータまたは順序が乱れたデータが図5のブロック503で検出される)場合に、CM 122は、LastByteReceived 220に関する適当な1つまたは複数のACKをサーバ130に送出することができる(たとえば、図3のACK 305および図5のブロック506)。たとえば、CM 122は、欠落データがCMに到着したかのように、コンテンツサーバに受信肯定応答を送信するためにxTCP受信器をトリガするために、オプションとして下で説明されるダミーデータを含む受信されたデータを、そのxTCP受信器または他の形でCMによって制御されるxTCP受信器に渡すように動作することができる。したがって、コンテンツストリーム内に欠落データがあるにもかかわらず、サーバ130がギャップなしで継続的にACKを受信することができるので、欠落パケットは、送信側(たとえば、レガシTCP送信側)を低速化しない。
【００６６】
諸実施形態のCM 122は、ネットワーク輻輳を防ぐように適合された動作を提供するためなど、欠落データが検出された場合に1つまたは複数のACKが送信側に提供されるべきときを判定するための論理を使用することができる。たとえば、欠落データが繰り返して検出される(たとえば、指定された時間期間内の所定の個数の欠落パケット、所定の個数の連続する欠落データパケットなど)場合に、CM 122は、ネットワーク輻輳を回避するための制御を提供するために、1つまたは複数の重複ACKをサーバ130に送るように動作することができる。TCP接続が、CM 122とサーバ130との間で利用され、サーバ130が、欠落パケットまたは並べ変えられたパケットがあるときにデータパケットの送信を低速化する通常のTCP挙動を実施する場合に、CM 122のxTCP受信器は、サーバ130によるデータ送信のレートの低下(たとえば、輻輳ウィンドウの縮小)を呼び出すことがわかっている、複数の重複ACKを送るように動作することができる。それに加えてまたはその代わりに、諸実施形態のCM 122は、ネットワーク輻輳を回避するための制御を提供するためのサーバ130への1つまたは複数のACKの送出を差し控えるように動作することができる(たとえば、CMは、サーバによるデータ送信のレートの削減を呼び出すことがわかっている複数のACKを差し控えるように動作することができる)。
【００６７】
それに加えてまたはその代わりに、CM 122が、ネットワーク輻輳を検出するときに、送出レートの低速化が、有益であるはずである場合に、CM 122は、データ送信を低速化させるために重複ACKを送ることができる(たとえば、必ずしも欠落データに応答してではなく、一般にレート制御機構として)。たとえば、CM 122は、欠落データがないときであっても重複ACKを送ることができ、これは、CM 122が潜在的にサーバ130からデータの何らかの小さい部分を2回受信することを犠牲にして、送信側輻輳ウィンドウを縮小し、したがって送出レートを低速化するようにサーバ130にシグナリングする。別の例として、CM 122は、必ずしもすべての欠落データに関してではなく、欠落データの一部に関して重複ACKを送り、CM 122によって受信されなかったデータの少なくとも一部の消失をシグナリングし、それと同時に、送信側輻輳ウィンドウを縮小し、したがって送出レートを低速化するようにサーバ130にシグナリングし、また、前の送信において失われた欠落データの一部をサーバ130から受信することができる。
【００６８】
前述から了解され得るように、CM 122の論理は、ネットワーク輻輳回避のためのクライアント側制御を提供することができる。そのようなクライアント側制御は、サーバ130が、本明細書の拡張された通信プロトコルの機能を実施するように適合されてはいないレガシコンテンツサーバを含む場合であっても、提供され得る。
【００６９】
その上、欠落データの検出に応答して、本明細書の実施形態のCM 122の拡張された通信プロトコル受信器は、データの受信を容易にするため、および/またはネットワーク輻輳を回避するために、受信ウィンドウを調整することができる。たとえば、CM 122の拡張された通信プロトコル受信器が、欠落パケットおよび/またはRTT変動を発見するときに、CM 122は、上で論じたようにLastByteReceivedまでのACKを送出するように動作できるだけではなく、ネットワーク内の輻輳を制御するために受信ウィンドウサイズを調整するように動作することもできる。受信ウィンドウスケーリングは、欠落データを伴わずにデータパケットを連続して受信することが、受信ウィンドウを拡大する(たとえば、所定の最大受信ウィンドウサイズまで)方式に従って行われ得、より多くの欠落パケットの検出は、CM 122の拡張された通信プロトコル受信器に、受信ウィンドウをスケールダウンさせる(たとえば、所定の最小受信ウィンドウサイズまで)。諸実施形態に従って実施される受信ウィンドウスケーリングは、それに加えてまたはその代わりに、RTTが相対的に長い場合によりいくらか大きい受信ウィンドウスケーリングを、RTTが相対的に短い場合によりいくらか小さい受信ウィンドウスケーリングを実施するためなど、RTTを考慮に入れることができる。したがって、諸実施形態による受信ウィンドウスケーリング動作は、ネットワーク内に激しい輻輳を導入することなく、適当なレベルの積極性において送信側挙動を制御するのに受信ウィンドウを使用することができる。
【００７０】
受信ウィンドウサイズの前述の調整は、受信バッファサイズの変更なしで、諸実施形態に従って実施され得る。すなわち、受信ウィンドウスケーリングは、受信ウィンドウ調整について送信側(たとえば、サーバ130)に通知し、したがって送信側挙動を制御するための技法として実施され得る。したがって、諸実施形態のCM 122の拡張された通信プロトコル受信器は、受信バッファサイズを変更せずに、調整された受信ウィンドウサイズをサーバ130に送るように動作することができる。
【００７１】
図示の実施形態のCM 122は、LastByteReceived 220までの受信されたデータをRM 121に提供する(図3のチャンクデータ306および図5のブロック507)。RM 121は、データ分析技法、帯域外シグナリング(たとえば、CM 122によってセットされる外部レジスタまたはフラグ)などを使用して、CM 122によって提供されたチャンク内の欠落データを検出するように動作することができるが、諸実施形態は、CM 122とRM 121との間の通信において、欠落データの範囲(たとえば、開始バイトオフセットおよびバイト数)を示すデータを提供するように動作する。たとえば、RM 121とCM 122との間の通信インターフェースが、標準通信プロトコルを利用する場合に、RM 121の論理は、チャンクデータ自体、ヘッダデータ、CM 122によってセットされるレジスタまたはフラグ、その他を分析することを介するなど、チャンク要求に応答して提供された不完全なデータを有するチャンクを識別するように適合され得る。RM 121とCM 122との間の通信インターフェースが、拡張された通信プロトコルを利用する場合には、下でさらに論ずるように、チャンク要求に応答して返された不完全なデータを有するチャンクに関して、シグナリングが提供され得る。
【００７２】
欠落データ(すなわち、前述の穴)を有するチャンクデータ306をRM 121に提供するときに、CM 122は、RM 121の通信プロトコルスタックに完全に見えるデータを提供するために、穴にダミーデータ(たとえば、0)を充てんするように動作することができる。たとえば、CM 122のxTCP受信器は、CMが受信されたデータ(ダミーデータを伴う)をRM 121に渡す前に、欠落データにダミーデータを充てんするように動作することができる。欠落データの範囲に関する前述の情報は、後にデータを完成させる際ならびに不完全である間にデータがUA 129に提供されるのを防ぐ際の両方において、RM 121によって利用され得る。すなわち、RM 121の論理は、欠落データの範囲に関する情報の参照を介するなど、CM 122によって提供されたデータが不完全であることを認識し、したがって、要求されたフラグメントのすべてのデータが受信されるまで、そのデータをUA 129に提供することを差し控えることができる。諸実施形態による動作において、CM 122は、欠落データの範囲に関する情報と共に、ダミーデータを有する受信されたデータをRM 121に渡すためにxTCP受信器を制御することができる。
【００７３】
RM 121は、UA 129によって要求されたフラグメントを回復するためのチャンクデータの処理のために、チャンク要求に応答してCM 122によって提供されたチャンクデータ(たとえば、チャンクデータ306)を受信する(図4のブロック402)。チャンクデータ306として提供されるコンテンツのチャンクは、たとえば、HTTPアドレス可能ファイルまたはファイルのバイト範囲を含むことができる。図示の実施形態のRM 121は、CM 122によって提供されたチャンクデータが、データが欠落しているかどうかを判定するように動作する(ブロック403)。チャンクデータが、穴または欠落データを含まない場合には、RM 121は、特定のフラグメントのすべてのチャンクが受信されたかどうかを判定するために進行し(図4のブロック404)、すべてのチャンクが受信された場合に、フラグメントを組み立て、フラグメントをUA 129に提供するために進行し(ブロック405)、フラグメントのチャンクのすべてが受信されたのではない場合に、フラグメントに関する次のチャンク要求を発行するために進行する(ブロック401)ことができる。しかしながら、チャンクデータが、穴または欠落データを含む場合には、RM 121は、データ分析技法、帯域外シグナリング、CM 122とRM 121との間の通信における欠落データの範囲(たとえば、開始バイトオフセットおよびバイト数)を示すデータなどを使用して、CM 122によって提供されたチャンク内の欠落データを検出するように動作することができる。チャンクデータ内で欠落データを検出したときに、図示の実施形態のRM 121は、要求されたフラグメントのすべてのデータが受信されるまで、そのデータをUA 129に提供することを差し控え、したがって、チャンクデータを含むフラグメントをUA 129に提供する前に、欠落データを完成させまたは充てんするための動作(ブロック406)を実施するために進行する。
【００７４】
たとえば、RM 121は、遅いデータがCM 122によって受信され、その後にRM 121に提供されるのを、ある時間期間だけ待つように動作することができる。それに加えてまたはその代わりに、RM 121は、CM 122への欠落データの再送信の要求(たとえば、欠落データ要求307)を提供するように動作することができる。諸実施形態による動作において、欠落データの再送信の要求は、すでにネットワークに出されたチャンク要求の背後で行われる(潜在的にパイプライン化される)。したがって、本明細書でチャンク要求によって提供されるコンテンツのチャンクのサイズは、任意の特定の時刻にどれほどの量のデータが未解決であり、再送信の要求がどれほどすばやくサービスされ得るのかを制御するために、相対的に小さくされ得る(たとえば、16キロバイトから128キロバイトの範囲内)。
【００７５】
諸実施形態は、欠落データの再送信の前述の要求に関して優先順位付け技法を実施することができる。たとえば、RM 121は、CM 122によってすでに処理されている1つまたは複数のチャンク要求(たとえば、初期チャンク要求、低優先順位または低品質のサービスストリームに関連するチャンク要求など、より低い優先順位の要求)の前に、CM 122にサーバ130へ要求を送信させるために、要求内または他の形でこれに関連して(たとえば、帯域外シグナリング)のいずれであれ、CM 122にシグナリングを提供できる。
【００７６】
諸実施形態による動作において、RM 121によって提供される欠落データ要求は、欠落データの特定のバイト範囲の要求を含むことができる。それに加えてまたはその代わりに、欠落データ要求は、受信されたパケット(たとえば、パケット304)を提供する際に使用されるコンテンツの異なる表現によって提供され得るなど、誤り訂正符号化された(たとえば、FEC)データの要求を含むことができる。欠落データのバイト範囲に関する情報を待たずに(たとえば、欠落データバイト範囲情報を要求するための追加のRTTを回避する)要求を開始するのを容易にするために、諸実施形態に従って、データの最初に要求された誤り訂正符号化されていない表現ではなく、誤り訂正符号化されたデータが、要求され得る。そのような実施態様は、非常に短い時間遅れ(たとえば、1秒)が、コンテンツの作成とクライアントデバイスによるそのコンテンツの消費との間に期待されるライブストリーミング状況において特に有利である可能性がある。
【００７７】
誤り訂正符号化されたデータが、本明細書の実施形態に従って、単独でまたは誤り訂正符号化されていないデータと組み合わせて要求され得ることを了解されたい。誤り訂正符号化されたデータが、誤り訂正符号化されていないデータと組み合わせて要求される場合に、諸実施形態は、十分なデータ(誤り訂正符号化された、誤り訂正符号化されていない、またはその組合せのいずれであれ)がデータ回復のための要求に応答して受信されるや否や、欠落データを回復するように動作することができる。やはりRM 121によって要求され得るように、すでに受信されたデータおよび/または欠落データの一部のいずれと組み合わされてであれ、欠落データを回復するのに適切な量の誤り訂正符号化されたデータが、十分な量のデータがRM 121によって受信されるや否や欠落データの回復を容易にするために要求され得る。たとえば、RM 121は、誤り訂正符号化されない、受信されたデータおよび/または再要求されたデータに基づいて、欠落データを入手するために要求すべき誤り訂正符号化されたデータの量を判定するように動作することができる。
【００７８】
RM 121から欠落データ要求を受信したことに応答して、CM 122は、適当なコンテンツに関する対応する要求(たとえば、欠落データ要求308)をサーバ130に発行することができる。前述のチャンク要求と同様に、諸実施形態のCM 122は、サーバ130に発行される欠落データ要求に関して、xTCP、標準TCP、その他などの通信プロトコルを使用する。CM 122は、要求された欠落データまたはその何らかの部分を含む1つまたは複数のデータパケット(たとえば、パケット309)を受信することができる。CM 122は、上で論じたように適当な1つまたは複数のACK(たとえば、ACK 310)をサーバ130に送出し、データをRM 121に提供する(たとえば、欠落データ311として)ことができる。
【００７９】
欠落データを完成させまたは充てんする動作(ブロック406)を実行し終えて、図4に示された実施形態のRM 121は、データが完全であるかどうかを判定するために進行する(ブロック407)。データが完全ではない(たとえば、データ内の穴が充てんされないまま残っている)場合には、図示の実施形態による処理は、欠落データを完成させまたは充てんするためにさらなる動作(ブロック406)を実行するためにリターンする。たとえば、RM 121は、さらなる欠落データ要求を送出することができる。しかし、データが完全であると判定される場合には、図示の実施形態による処理は、特定のフラグメントのすべてのチャンクが受信されたかどうかを判定する(ブロック404)ために進行する。フラグメントのすべてのチャンクが受信済みである(または、FECが要求されるときに、チャンク要求からの十分なデータが受信済みである)場合に、RM 121は、フラグメントを組み立て(ブロック405)、そのフラグメントをUA 129に提供する(たとえば、フラグメント312として)ために進行することができる。その上、諸実施形態による動作において、RMは、十分なデータ/チャンクが到着し、先頭からの応答の連続する部分が構成され得るようになるや否や、フラグメントの組立を開始することができる(たとえば、ブロック405において)。諸実施形態のRMは、応答の先頭から連続する(すなわち、データ内に穴がない)再構成されたデータが十分になるや否や、部分的応答をUAに提供するように動作することができる。前述から了解され得るように、RM 121は、したがって、UAによって要求されたフラグメントまたはその連続する部分を回復するのに十分なデータが到着するや否や、適時複数の応答からデータを集約し、完全なフラグメント応答を、または、いくつかの実施形態においては部分的フラグメント応答をUA 129に提供するように動作することができる。対応して、ストリーミングコンテンツの別のフラグメントの次のチャンク要求が、適宜、発行され得る(ブロック401)。
【００８０】
前述の例示的な動作は、拡張された伝送プロトコルCM動作(たとえば、xTCP動作)を提供するが、諸実施形態は、そのような動作を選択的に実施することができる。諸実施形態による動作において、ある種のバイトまたは要求は、標準TCP動作を使用して入手されるためなど、拡張された伝送プロトコルの使用なしでの獲得のために指定され得る。たとえば、ある種のバイト(たとえば、伝統的に拡張された伝送プロトコル実施態様の前にストリームを確立するためのストリームの初期フレーム、信頼できる受信を保証するためのストリーミングマニフェスト情報など)が、TA 120による拡張された伝送プロトコルの実施を伴わない伝送のために選択され得る。CM 122は、たとえば、RM 121によって要求される各チャンク内の第1の個数(SB)のバイトに関して、CM 122によって実施されるxTCP受信器が伝統的なTCPモードで動作し、その後にxTCP動作を介する積極的モードにおいて動作する場合など、伝統的なTCP動作とxTCP動作との間でその挙動を交番させるように構成され得る。積極的な挙動は、チャンク要求の完了まで実施され得る。パラメータ値SBは、デフォルト値0(たとえば、非保守的モード)を有することができ、チャンク要求ごとにRM 121によって供給される値によってオーバーライドされ得る。伝統的なTCPからの十分に信頼できるトランスポート挙動が期待されることを示すために、SBが「-1」と等しい場合など、特殊なケースを定義することができる。前述から、拡張された伝送プロトコル動作のそのような選択的実施が、TA 120を使用して転送される複数のコンテンツストリームのコンテンツの1つもしくは複数のストリームに関するもの、および/またはTA 120を使用して転送されるコンテンツのストリームの1つもしくは複数の部分に関するものとされ得ることを了解されたい。
【００８１】
CM 122の拡張された伝送プロトコル受信器動作が、欠落データが検出されるときに必ずACKを発行するように適合される場合に、サーバ130は、諸実施形態による動作において、失われたパケットまたは遅延されたパケットに起因してコンテンツストリームの送出レートを低速化しないものとすることができる。同様に、諸実施形態のCM 122は、ACKの送出において低速化しないものとすることができ、受信ウィンドウの前進を継続することができる。
【００８２】
しかし、本明細書の実施形態の拡張された伝送プロトコル構成の動作は、ネットワーク内で過度の輻輳を引き起こさずにストリーミングコンテンツの高速ダウンロードを達成することを目指す。したがって、拡張された伝送プロトコル受信器動作の積極性は、欠落パケットの個数および/または推定されたRTTに基づくなど、ネットワーク条件などに関してチューニングされ得る。そのような拡張された伝送プロトコル構成を実施する実施形態は、適応ストリーミングクライアント内のアプリケーションレイヤレート要求論理など、レート適合機構を用いてUA 129を適合させることができる。それに加えてまたはその代わりに、CM 122は、本明細書の実施形態によるレート適合機構を用いて適合され得る。
【００８３】
伝送レートおよび/またはネットワーク輻輳に関するクライアント側制御を提供するように動作可能なレート適合機構を提供する際に、諸実施形態のCM 122は、欠落データが検出されるときに必ずACKを発行するとは限らない拡張された伝送プロトコル受信器(たとえば、xTCP受信器)構成を実施するように適合され得る。たとえば、CM 122は、ネットワーク条件または他の要因が、サーバ130によるデータの送出を低速化しなければならない(たとえば、ネットワーク輻輳を回避するか軽減するために)ことを示すかどうかを判定する論理を実施することができ、これによって、データ送出レート制御が受信器によって提供される実施形態を提供する。そのような実施形態において、xTCP受信器動作は、コンテンツストリーム送出レートを制御するための適当なシグナリングを提供する(たとえば、重複ACKを選択的に提供する)ために、TCP送信側の挙動(たとえば、重複ACKの受信に対する反応)の知識を活用することができる。そのようなxTCP受信器の積極性は、欠落パケットの個数、推定されたRTTなどに基づいてチューニングされ得る。
【００８４】
それに加えてまたはその代わりに、CM 122の拡張された伝送プロトコル受信器が、データ送出レート制御を提供するように適合される場合に、拡張された伝送プロトコル受信器が、欠落パケットおよび/またはRTT変動を発見するときに、CM 122は、受信された最後のバイト(たとえば、LastByteReceived 220)までのACKを送出すると同時に、ネットワーク内の輻輳を制御するために受信ウィンドウサイズを調整する(たとえば、より少ない要求されるデータがネットワーク内で未解決になるようにするために、受信ウィンドウサイズを縮小する)ように動作することができる。受信ウィンドウスケーリングは、受信ウィンドウサイズが伝統的なTCP、RTTなどによって作られたはずの推定された輻輳ウィンドウサイズに基づくようにするためなど、式に従って行われ得る。動作において、受信ウィンドウは、欠落データなしでデータパケットを連続して受信することに応答して拡大され得、受信ウィンドウは、より多くの欠落パケットを検出する(たとえば、時間の所定のウィンドウ内で)ことに応答してさらに縮小され得る。したがって、受信ウィンドウは、ネットワーク内に激しい輻輳を導入することなく、正しいレベルの積極性において送信側挙動を制御するのに使用され得る。受信バッファサイズの変化が、受信ウィンドウ調整に関連して実施され得るが、本明細書の実施形態に従って実施される受信ウィンドウ調整は、受信バッファサイズの変化を使用するのではなく、受信ウィンドウ調整について送信側に通知するように動作することができる。そのために、CM 122の拡張された伝送プロトコル受信器は、受信バッファサイズの対応する変化を実施せずに、所望の制御を実施するために、調整された受信ウィンドウサイズをサーバ130に送ることができる。
【００８５】
上で説明されたTA 120の実施形態は、拡張された伝送プロトコル(たとえば、例示的実施形態のxTCP)を使用して所望のコンテンツのフラグメントまたはフラグメントのシーケンスの向上された配信を提供するように適合されるが、コンテンツの向上された配信は、他の実施態様および/または技法を使用して、本明細書の概念に従ってトランスポートアクセラレータによって提供され得る。たとえば、TA 120の実施形態は、変更されない伝送プロトコルCM構成(たとえば、CM-yTCP)を含むことができ、CMは、変更されないセマンティクスを有するTCP(本明細書ではyTCPと称する)の上でHTTPを使用する。諸実施形態のyTCP構成において、TCPのover-the-wireプロトコルは、変更されないままになるが、CMは、順序が乱れて受信されたデータストリームを覗き見、これをRMに配信するように適合され、RMは、UAがデータの、順序が乱れた配信を処理する備えを有する場合に、順序が乱れて受信されたセグメントをUAに配信することができる。CMが、諸実施形態のyTCP動作に従って、順序が乱れて配信されるデータを含むTCPスタックのバッファを覗き見、これをRMに配信することを介して、セグメントが失われる場合には、そのセグメントだけが遅延を伴ってRMに到着し、それに続く、順序が乱れたセグメントは、定時にRMに到着し、これらの順序が乱れたセグメントは、RMに到着するときに、RMからUAに渡され得る。yTCPを実施するそのような実施形態自体は、通常のTCP輻輳制御の対象になり得るが、yTCPの実施態様は、ネットワーク輻輳を、したがってパケット消失確率自体を膨張させる可能性が低い。したがって、CM-yTCP構成は、全体的な受信レートを高めることなく、時折のパケット消失に起因するストール確率を低下させる(順序が乱れて受信されたデータに先行する欠落しているデータの到着を待つのではなく、順序が乱れて受信されたデータをRMおよび/またはUAにすばやく提供することによって)のに利用され得る。
【００８６】
諸実施形態のyTCPの実施態様において、CM 122のyTCP受信器は、順序が乱れて受信器によって受信され、したがって順序が乱れてUA 129には普通に配送されないセグメントを覗き見、これをRM 121およびUA 129に配信するように適合される。変更されないTCP動作において、パケット消失が発生する場合に、クライアントは、失われたセグメントが送信側によって再送信され、クライアントによって受信されない限り、かつ、そうなるまで、通常は失われたセグメントの先のデータを全く受信しないことを了解されたい。したがって、遅延を伴って受信されるデータの量は、どちらかといえばかなりのものになり得る。たとえば、データが、2Mビット/秒のレートで受信され、RTTが、200msである場合に、再送信されるセグメントは、約40KBの順序が乱れたデータが受信された後に受信されるはずである。このデータの消失は、この40KBのデータが遅延を伴って配信されることを引き起こす(たとえば、前述の例において、データは、単一の遅延されたセグメントより約20倍遅延される)。その上、実際には、RTTは、通常、キューイング遅延に起因して数秒程度まで増加し、したがって、単一のパケット消失が、非常に長い時間にわたって接続をストールさせることができる。CM 122が、すべての受信されたセグメントを含むTCP受信バッファを覗き見、これらをRM 121に配信する(それらが順序通りに受信されようと順序が乱れて受信されようと)ことを介して入手される情報は、パケット消失を軽減するための1つまたは複数の技法を実施するのに利用され得る。
【００８７】
おそらくは1つまたは複数の他の技法と組み合わされる、yTCP動作の実施態様は、前述の問題を軽減するのに利用され得る。たとえば、RM 121は、フラグメント要求ごとに何らかのFECデータを要求するように動作することができる。動作において、RM 121は、RMによって処理され得る誤り確率(たとえば、1%)を仮定し、より多くのセグメントが失われない場合に高い確率の訂正を容易にする量のFECデータを要求することができる。それに加えてまたはその代わりに、RM 121は、ヒストリカル情報から誤り確率を推定することができる(たとえば、yTCP動作がTCP配信内の穴を見ることに基づいて誤り確率を判定する)。そのようなFECデータは、帯域幅利用を受け入れられないほど増加させることなく、欠落データを回復するのに利用され得る。そのようなCM-yTCP構成は、遅延されたデータの量の削減と要求され送信されるFECデータの量の削減との両方を容易にすることができる。
【００８８】
選択された態様が、図示され、詳細に説明されたが、以下の特許請求の範囲によって定義される本開示の趣旨および範囲から逸脱せずに、様々な置換および変更をその中で行うことができることを理解されたい。
【符号の説明】
【００８９】
100  システム
110  クライアントデバイス
111  プロセッサ
112  メモリ
113  I/O要素
114  バス
120  トランスポートアクセラレータ(TA)
121  要求マネージャ(RM)
122  接続マネージャ(CM)
123  インターフェース
124  インターフェース
129  UA
130  サーバ
140  データベース
141  コンテンツファイル
142  コンテンツファイル
143  コンテンツファイル
150  ネットワーク
151  接続
152  接続
200  コンテンツストリーム
210  NextByteExpected
220  LastByteReceived
230  欠落データ
300  シーケンスチャート
301  フラグメント要求
302  チャンク要求
303  チャンク要求
304  パケット
305  ACK
306  チャンクデータ
307  欠落データ要求
308  欠落データ要求
309  パケット
310  ACK
311  欠落データ
312  フラグメント
400  フロー
500  フロー
【図１】
2017516336.tif 000003
【図２】
2017516336.tif 000004
【図３】
2017516336.tif 000005
【図４】
2017516336.tif 000006
【図５】
2017516336.tif 000007
【手続補正書】
【提出日】平成28年9月21日(2016.9.21)
【手続補正１】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項１】
クライアントデバイスのトランスポートアクセラレータ(TA)によって、前記クライアントデバイスのユーザエージェント(UA)へのコンテンツの配信を加速するための方法であって、
前記UAとコンテンツを提供するように動作可能なコンテンツサーバとの間の通信経路内に配置された前記TAを使用して前記UAのためのメディアトランスポート動作を開始するステップであって、前記TAは、前記コンテンツのどのデータが前記コンテンツサーバに要求されるかを制御するように動作可能である要求マネージャ(RM)と、前記コンテンツの前記データが前記コンテンツサーバにいつ要求されるかを制御するように動作可能である接続マネージャ(CM)とを含み、前記RMは、前記UAと、前記コンテンツの受信されたデータを前記UAに渡すために前記CMによって使用される通信プロトコルスタックとの間の通信経路内に配置される、開始するステップと、
前記RMによって、前記UAによって提供されるフラグメント要求のそれぞれを、前記コンテンツのチャンクを要求するための複数のチャンク要求に再分割するステップと、
前記RMによって前記CMに、前記コンテンツのチャンクを要求するための前記複数のチャンク要求のうちのチャンク要求を提供するステップと、
前記CMによって、前記CMと前記コンテンツサーバとの間で確立された1つまたは複数の接続を介して前記コンテンツサーバに前記コンテンツの前記チャンクを要求するステップと、
前記CMによって前記RMに、前記CMによって前記コンテンツサーバに要求されたコンテンツの1つまたは複数のチャンクの受信されたデータを渡すステップであって、前記受信されたデータは、コンテンツの前記1つまたは複数のチャンクのうちのチャンクからの欠落データであり、コンテンツストリームへの組立のために前記CMによって前記通信プロトコルスタックを介して前記RMに渡される、渡すステップと、
コンテンツの前記1つまたは複数のチャンクの前記データを前記UAによって要求されたコンテンツのフラグメントに組み立てるステップと、
前記チャンクからの前記欠落データを検出すると、前記RMによって、前記欠落データを完成させる前記コンテンツのデータが前記RMによって前記CMから受信されるまで前記UAへのコンテンツの前記フラグメントの提供を差し控えるステップと、
前記RMによって前記UAに、コンテンツストリームの一部としてコンテンツの前記フラグメントを渡すステップであって、前記RMによって前記UAに渡されるコンテンツの前記フラグメントは、前記欠落データを完成させる前記コンテンツの前記データを含み、前記RMは、前記UAを前記欠落データに関するTA動作から分離するように動作する、渡すステップと
を含む方法。
【請求項２】
前記通信プロトコルスタックを介して前記RMに、コンテンツの前記1つまたは複数のチャンクの前記要求されたチャンクからの欠落データである前記受信されたデータを渡す前記ステップは、
前記データが欠落しているところにダミーデータを挿入するステップ
を含む、請求項1に記載の方法。
【請求項３】
前記受信されたデータが、前記1つまたは複数のチャンクのうちの要求されたチャンクからの欠落データであることを前記RMにシグナリングするステップ
をさらに含む、請求項1に記載の方法。
【請求項４】
前記CMによって前記コンテンツサーバに、前記データが欠落していないかのように、少なくとも前記欠落データの受信肯定応答(ACK)を提供するステップ
をさらに含む、請求項1に記載の方法。
【請求項５】
少なくとも前記欠落データのACKを提供する前記ステップは、
前記CMによって前記コンテンツサーバに、少なくとも前記欠落データの前記ACKを選択的に提供するステップであって、前記CMは、クライアントベースのネットワーク輻輳制御を実施するために、前記欠落データのACKを前記コンテンツサーバに提供すべきか否かを選択的に判定するように適合される、選択的に提供するステップ
を含む、請求項4に記載の方法。
【請求項６】
前記RMによって前記CMに、前記欠落データを完成させる前記コンテンツの前記データを入手するための1つまたは複数の要求を提供するステップ
をさらに含む、請求項1に記載の方法。
【請求項７】
前記RMによって、前記欠落データを完成させる前記コンテンツの前記データを入手するために要求すべき誤り訂正符号化されたデータの量を判定するステップであって、前記誤り訂正符号化されたデータのソースは、前記受信されたデータを提供するのに使用された前記コンテンツサーバ以外のソースを含む、判定するステップ
をさらに含む、請求項6に記載の方法。
【請求項８】
前記コンテンツサーバは、前記TAによって提供されるコンテンツの加速された配信をサポートする動作に関して事前に設計されていないコンテンツサーバを含む、請求項1に記載の方法。
【請求項９】
前記コンテンツサーバは、標準化された伝送制御プロトコル(TCP)動作に従うコンテンツの要求に応答してデータを提供するように動作可能であり、前記受信されたデータは、TCPデータとして受信され、前記通信プロトコルスタックは、TCPスタックを含む、請求項8に記載の方法。
【請求項１０】
クライアントデバイスのトランスポートアクセラレータ(TA)によって、前記クライアントデバイスのユーザエージェント(UA)へのコンテンツの配信を加速するように構成された装置であって、
前記UAとコンテンツを提供するように動作可能なコンテンツサーバとの間の通信経路内に配置された前記TAを使用して前記UAのためのメディアトランスポート動作を開始するための手段であって、前記TAは、前記コンテンツのどのデータが前記コンテンツサーバに要求されるかを制御するように動作可能である要求マネージャ(RM)と、前記コンテンツの前記データが前記コンテンツサーバにいつ要求されるかを制御するように動作可能である接続マネージャ(CM)とを含み、前記RMは、前記UAと、前記コンテンツの受信されたデータを前記UAに渡すために前記CMによって使用される通信プロトコルスタックとの間の通信経路内に配置される、開始するための手段と、
前記RMによって、前記UAによって提供されるフラグメント要求のそれぞれを、前記コンテンツのチャンクを要求するための複数のチャンク要求に再分割するための手段と、
前記RMによって前記CMに、前記コンテンツのチャンクを要求するための前記複数のチャンク要求のうちのチャンク要求を提供するための手段と、
前記CMによって、前記CMと前記コンテンツサーバとの間で確立された1つまたは複数の接続を介して前記コンテンツサーバに前記コンテンツの前記チャンクを要求するための手段と、
前記CMによって前記RMに、前記CMによって前記コンテンツサーバに要求されたコンテンツの1つまたは複数のチャンクの受信されたデータを渡すための手段であって、受信されたデータは、コンテンツの前記1つまたは複数のチャンクのうちのチャンクからの欠落データであり、コンテンツストリームへの組立のために前記CMによって前記通信プロトコルスタックを介して前記RMに渡される、渡すための手段と、
コンテンツの前記1つまたは複数のチャンクの前記データを前記UAによって要求されたコンテンツのフラグメントに組み立てるための手段と、
前記チャンクからの前記欠落データを検出すると、前記RMによって、前記欠落データを完成させる前記コンテンツのデータが前記RMによって前記CMから受信されるまで前記UAへのコンテンツの前記フラグメントの提供を差し控えるための手段と、
前記RMによって前記UAに、コンテンツストリームの一部としてコンテンツの前記フラグメントを渡すための手段であって、前記RMによって前記UAに渡されるコンテンツの前記フラグメントは、前記欠落データを完成させる前記コンテンツの前記データを含み、前記RMは、前記UAを前記欠落データに関するTA動作から分離するように動作する、渡すための手段と
を含む装置。
【請求項１１】
前記通信プロトコルスタックを介して前記RMに、コンテンツの前記1つまたは複数のチャンクのうちの要求されたチャンクからの欠落データである前記受信されたデータを渡すための前記手段は、
前記データが欠落しているところにダミーデータを挿入するための手段
を含む、請求項10に記載の装置。
【請求項１２】
前記受信されたデータが、前記1つまたは複数のチャンクのうちの要求されたチャンクからの欠落データであることを前記RMにシグナリングするための手段
をさらに含む、請求項10に記載の装置。
【請求項１３】
前記CMによって前記コンテンツサーバに、前記データが欠落していないかのように、少なくとも前記欠落データの受信肯定応答(ACK)を提供するための手段
をさらに含む、請求項10に記載の装置。
【請求項１４】
少なくとも前記欠落データのACKを提供するための前記手段は、
前記CMによって前記コンテンツサーバに、少なくとも前記欠落データの前記ACKを選択的に提供するための手段であって、前記CMは、クライアントベースのネットワーク輻輳制御を実施するために、前記欠落データのACKを前記コンテンツサーバに提供すべきか否かを選択的に判定するように適合される、選択的に提供するための手段
を含む、請求項13に記載の装置。
【請求項１５】
前記RMによって前記CMに、前記欠落データを完成させる前記コンテンツの前記データを入手するための1つまたは複数の要求を提供するための手段
をさらに含む、請求項10に記載の装置。
【請求項１６】
前記RMによって、前記欠落データを完成させる前記コンテンツの前記データを入手するために要求すべき誤り訂正符号化されたデータの量を判定するための手段であって、前記誤り訂正符号化されたデータのソースは、前記受信されたデータを提供するのに使用された前記コンテンツサーバ以外のソースを含む、判定するための手段
をさらに含む、請求項15に記載の装置。
【請求項１７】
前記コンテンツサーバは、前記TAによって提供されるコンテンツの加速された配信をサポートする動作に関して事前に設計されていないコンテンツサーバを含む、請求項10に記載の装置。
【請求項１８】
前記コンテンツサーバは、標準化された伝送制御プロトコル(TCP)動作に従うコンテンツの要求に応答してデータを提供するように動作可能であり、前記受信されたデータは、TCPデータとして受信され、前記通信プロトコルスタックは、TCPスタックを含む、請求項17に記載の装置。
【請求項１９】
クライアントデバイスのトランスポートアクセラレータ(TA)によって、前記クライアントデバイスのユーザエージェント(UA)へのコンテンツの配信を加速するためのコンピュータプログラムであって、前記コンピュータプログラムはプログラムコードを含み、
前記プログラムコードは、
前記UAとコンテンツを提供するように動作可能なコンテンツサーバとの間の通信経路内に配置された前記TAを使用して前記UAのためのメディアトランスポート動作を開始するためのプログラムコードであって、前記TAは、前記コンテンツのどのデータが前記コンテンツサーバに要求されるかを制御するように動作可能である要求マネージャ(RM)と、前記コンテンツの前記データが前記コンテンツサーバにいつ要求されるかを制御するように動作可能である接続マネージャ(CM)とを含み、前記RMは、前記UAと、前記コンテンツの受信されたデータを前記UAに渡すために前記CMによって使用される通信プロトコルスタックとの間の通信経路内に配置される、開始するためのプログラムコードと、
前記RMによって、前記UAによって提供されるフラグメント要求のそれぞれを、前記コンテンツのチャンクを要求するための複数のチャンク要求に再分割するためのプログラムコードと、
前記RMによって前記CMに、前記コンテンツのチャンクを要求するための前記複数のチャンク要求のうちのチャンク要求を提供するためのプログラムコードと、
前記CMによって、前記CMと前記コンテンツサーバとの間で確立された1つまたは複数の接続を介して前記コンテンツサーバに前記コンテンツの前記チャンクを要求するためのプログラムコードと、
前記CMによって前記RMに、前記CMによって前記コンテンツサーバに要求されたコンテンツの1つまたは複数のチャンクの受信されたデータを渡すためのプログラムコードであって、前記受信されたデータは、コンテンツの前記1つまたは複数のチャンクのうちのチャンクからの欠落データであり、コンテンツストリームへの組立のために前記CMによって前記通信プロトコルスタックを介して前記RMに渡される、渡すためのプログラムコードと、
コンテンツの前記1つまたは複数のチャンクの前記データを前記UAによって要求されたコンテンツのフラグメントに組み立てるためのプログラムコードと、
前記チャンクからの前記欠落データを検出すると、前記RMによって、前記欠落データを完成させる前記コンテンツのデータが前記RMによって前記CMから受信されるまで前記UAへのコンテンツの前記フラグメントの提供を差し控えるためのプログラムコードと、
前記RMによって前記UAに、コンテンツストリームの一部として前記UAにコンテンツの前記フラグメントを渡すためのプログラムコードであって、前記RMによって前記UAに渡されるコンテンツの前記フラグメントは、前記欠落データを完成させる前記コンテンツの前記データを含み、前記RMは、前記UAを前記欠落データに関するTA動作から分離するように動作する、渡すためのプログラムコードと
を含む、コンピュータプログラム。
【請求項２０】
前記受信されたデータが、前記1つまたは複数のチャンクのうちの要求されたチャンクからの欠落データであることを前記RMにシグナリングするためのプログラムコード
をさらに含む、請求項19に記載のコンピュータプログラム。
【請求項２１】
前記CMによって前記コンテンツサーバに、前記データが欠落していないかのように、少なくとも前記欠落データの受信肯定応答(ACK)を提供するためのプログラムコード
をさらに含む、請求項19に記載のコンピュータプログラム。
【請求項２２】
少なくとも前記欠落データのACKを提供する前記プログラムコードは、
前記CMによって前記コンテンツサーバに、少なくとも前記欠落データの前記ACKを選択的に提供するためのプログラムコードであって、前記CMは、クライアントベースのネットワーク輻輳制御を実施するために、前記欠落データのACKを前記コンテンツサーバに提供すべきか否かを選択的に判定するように適合される、選択的に提供するためのプログラムコード
を含む、請求項21に記載のコンピュータプログラム。
【請求項２３】
クライアントデバイスのトランスポートアクセラレータ(TA)によって、前記クライアントデバイスのユーザエージェント(UA)へのコンテンツの配信を加速するように構成された装置であって、
少なくとも1つのプロセッサと、
前記少なくとも1つのプロセッサに結合されたメモリと
を含み、前記少なくとも1つのプロセッサは、
前記UAとコンテンツを提供するように動作可能なコンテンツサーバとの間の通信経路内に配置された前記TAを使用して前記UAのためのメディアトランスポート動作を開始することであって、前記TAは、前記コンテンツのどのデータが前記コンテンツサーバに要求されるかを制御するように動作可能である要求マネージャ(RM)と、前記コンテンツの前記データが前記コンテンツサーバにいつ要求されるかを制御するように動作可能である接続マネージャ(CM)とを含み、前記RMは、前記UAと、前記コンテンツの受信されたデータを前記UAに渡すために前記CMによって使用される通信プロトコルスタックとの間の通信経路内に配置される、開始することと、
前記RMによって、前記UAによって提供されるフラグメント要求のそれぞれを、前記コンテンツのチャンクを要求するための複数のチャンク要求に再分割することと、
前記RMによって前記CMに、前記コンテンツのチャンクを要求するための前記複数のチャンク要求のうちのチャンク要求を提供することと、
前記CMによって、前記CMと前記コンテンツサーバとの間で確立された1つまたは複数の接続を介して前記コンテンツサーバに前記コンテンツの前記チャンクを要求することと、
前記CMによって前記コンテンツサーバに要求されたコンテンツの1つまたは複数のチャンクの受信されたデータを渡すことであって、前記受信されたデータは、コンテンツの前記1つまたは複数のチャンクのうちのチャンクからの欠落データであり、コンテンツストリームへの組立のために前記CMによって前記通信プロトコルスタックを介して前記RMに渡される、渡すことと、
コンテンツの前記1つまたは複数のチャンクの前記データを前記UAによって要求されたコンテンツのフラグメントに組み立てることと、
前記チャンクからの前記欠落データを検出すると、前記RMによって、前記欠落データを完成させる前記コンテンツのデータが前記RMによって前記CMから受信されるまで前記UAへのコンテンツの前記フラグメントの提供を差し控えることと、
コンテンツストリームの一部として前記RMによって前記UAにコンテンツの前記フラグメントを渡すことであって、前記RMによって前記UAに渡されるコンテンツの前記フラグメントは、前記欠落データを完成させる前記コンテンツの前記データを含み、前記RMは、前記UAを前記欠落データに関するTA動作から分離するように動作する、渡すことと
を行うように構成される、装置。
【国際調査報告】
2017516336.tif 000008
2017516336.tif 000009