JP6476197B2 - 輻輳制御ビットレート・アルゴリズム - Google Patents

Description

本開示は、ネットワーク経由のデータ転送に関する。特に、本開示の態様は、パケット交換網で信頼性の低いトランスポート・プロトコルを使用する輻輳制御のためのシステム及び方法に関する。

デジタル・ストリーミング・サービス及びさまざまなクラウド・ベースのコンピューティング・ソリューションの普及率の増加とともに、リモート・デバイス間で大量のデータを迅速かつ正確に転送する能力は、重要な課題である。インターネット、ワイド・エリア・ネットワーク（ＷＡＮ）、またはローカル・エリア・ネットワーク（ＬＡＮ）のような、ネットワークの共有リソースを介する宛先システムへデジタル・データを送信することは、固定長または可変長を有することができる、パケットとして知られる、フォーマット済のブロックへのデータの配置を典型的に伴う。各データ・パケットは、宛先へ配信される基本のユーザ・データを含むペイロード、すなわち本体、ならびに少なくとも部分的にデータ・パケットのヘッダ内に一般的に含まれる、ルーティング及び制御目的のために使用される、ある特定の補足情報を典型的に含む。概して、ネットワーク、送信システム、及び受信システムは、この補足情報を使用して意図された宛先へのペイロードの適切なルーティング及び配信を確保することができる。

この方式でパケット交換網を介してデータを転送することによる、多くの場合に避けられない結果は、パケット損失であり、これは１つ以上のデータ・パケットが適切にそれらの宛先へ到着しないときに発生する。パケット損失は、チャネル輻輳、信号劣化、及び他の理由を含む、さまざまな要因により発生する可能性がある。パケット損失を発生させる特定のネットワーク状態を防ぎ、また同時にネットワーク・チャネルで利用可能な帯域幅を効率的に使用するために、さまざまな輻輳制御技術が開発されている。さらに、パケット損失に対処するツールを組み込むことができる様々なトランスポート・プロトコルがあり、パケット損失を、発生時に処理するために用いられる特定の方法は、データ転送中に使用される特定のトランスポート・プロトコルに依存する。概して、これらのトランスポート・プロトコルは、信頼性の高いプロトコル及び信頼性の低いプロトコルの２種類に分類することが可能であり、それぞれ、ある特定のトレードオフを示し、任意のインスタンスで使用されるプロトコルの特定の選択は、データ転送の性質に依存し得る。

信頼性の高いプロトコルは、シーケンス中のその宛先へ各データ・パケットを配信する保証を組み込み、パケット損失が発生した場合にはドロップしたパケットを再送信する。信頼性の高いプロトコルは、常にではないが、多くの場合に接続指向のプロトコルであり、ある種の受取承認を送信するために受信側が使用し、パケットを正常に配信したことを検証することができる、特定の通信セッションのために受信側から送信側へ戻されるバックチャネルを確立することで通常達成される。送信側は、これらの承認を使用して、データ・パケットが正常にそれらの宛先に到着しなかったことを示すときに、再送信プロセスを導くことができる。信頼性の高いプロトコルの一般的で周知の例は、また接続指向である、伝送制御プロトコル（ＴＣＰ）である。ＴＣＰのような、信頼性の高いプロトコルは、データの正確な転送が主な懸案事項であり、テキスト・ベースの電子メールを送信することや、デジタル・コンテンツのダウンロード、及びオーディオ／ビデオを宛先システムでバッファリング可能であるメディア・ストリーミング・サービスのような、データ・パケットを正常に配信することを検証する利益のために、ある遅延量を許容可能である作業に非常に適している。残念ながら、データ検証特性及びデータの再送信は比較的大きなオーバーヘッドを導入し、多くの信頼性の高いプロトコルが、ライブ・オーディオ及び／またはビデオ・ストリーミング、オンライン・ビデオ・ゲーム、及びインターネット電話のような、実時間データ転送を含む、タイムクリティカル・アプリケーションのためには望ましくないものとなる。

それに反して、信頼性の低いプロトコルは、上述のような種類の、特定のパケットのためのデータ配信検証を一般的にせず、各パケットがその宛先に到着することをそれらが保証せず、また適切なシーケンスでパケットを配信することを保証しない事実により一般的に特徴付けられる。信頼性の低いプロトコルは、常にではないが、多くの場合にコネクションレスであり、典型的には、任意の特定の通信セッション中に固定チャネルを確立しない。各データ・パケットは、その代わりに、各データ・パケットに含まれる補足情報に基づき独立してルーティングされ得る。信頼性の低いプロトコルの一般的で周知の例は、ユーザ・データグラム・プロトコル（ＵＤＰ）であり、これもまたコネクションレスである。ＵＤＰのような信頼性の低いプロトコルは上記の信頼性の特性を有さないことによりオーバーヘッドを比較的減少させるので、それらは、上記の実時間アプリケーションのような、待ち時間を最小化することが主な懸案事項である時間依存アプリケーションにより適している。

一般的に信頼性の低いプロトコルはデータ・パケットの再送信をしないので、前方誤り訂正（ＦＥＣ）として知られる技術が、信頼性の低いサービスを使用してデータを転送するときのパケット損失に対処するために一般的に使用される。ＦＥＣは、正常に配信されないソース・パケットを送信側が再送信する必要性なしに損失したデータを独立して再構築する能力を受信側デバイスに提供する。前方誤り訂正を使用するときに、元のソース・データは、典型的にソース・パケットと同時に受信側に送信される、ＦＥＣパケット形式で送信側に冗長的に符号化される。ソース・パケット損失が生じると、受信側デバイスは、ＦＥＣパケットに含まれる冗長的に符号化されたデータを利用して、再送信を待たずに損失したデータを再構築することができる。

重要なことには、ネットワーク状態は、多くの場合に経時的に変化し、ネットワーク・チャネル経由で送信側に利用可能な最大ビットレートをこのチャネル上での現在の負荷に基づき変化させる。チャネルの現在利用可能な帯域幅を超えるビットレートで送信側システムがデータ・パケットを送信しようとすると、それは、応答での深刻なパケット損失を誘発する輻輳状態を引き起こす可能性がある。これは、損失したデータの再送信が保証されているので、ＴＣＰのような信頼性の高いデータ転送を伴うより低い時間依存アプリケーションで許容可能であり得るが、これは、信頼性の低い転送を伴う多くの実時間アプリケーション及び他のアプリケーションにおいて、パケット損失が、損失データを受信側が再構築不可能であり信号のドロップアウトのような望ましくない結果を引き起こす程度となり得るので、許容できない場合がある。一方で、利用可能な最大ビットレートが送信側により提供されるビットレートを代わりにはるかに超えるときには、ネットワーク・チャネルの完全な伝送能力が非効率的に活用され、受信側で信号の品質が結果として不必要に悪い可能性があるので、これもまた望ましくない。

残念ながら、許容不可能なパケット損失をもたらす輻輳状態を引き起こさないでネットワーク・チャネルの利用可能な帯域幅を効率的に利用する方式で信頼性の低いプロトコルを使用してデータを転送することは、大きな課題である。従来の輻輳制御技術は、多くの場合、トランスポート層に組み込まれた送信側へフィードバックを有する、ＴＣＰのような、信頼性の高いプロトコルにのみ適しているが、ユーザによりトランスポート層上に独立して追加されない限り、必要なフィードバックを典型的に欠く、ＵＤＰのような、多くの信頼性の低いプロトコルには効果的ではない。さらに、ＴＣＰまたは他の信頼性の高いプロトコルのために設計された輻輳制御または輻輳回避アルゴリズムは、一般的に高速リアルタイム・ストリーミング・アプリケーションではなく、または及び信頼性の低いプロトコルを伴う多くのデータ転送アプリケーションに適さない可能性がある。それは輻輳に応答するビットレートの指数関数的な減少がリアルタイム信号の品質を結果として過度に損なわせる可能性があるからである。さらに、輻輳までビットレートを増加させることに起因するパケット損失は、ＴＣＰまたは他の信頼性の高いプロトコルを使用してデータを再送信する、より低い時間依存のアプリケーションで許容でき得るが、それは、結果として受信側がデータを再構築することができないために多くの実時間アプリケーションでは許容できない場合がある。

したがって、ＵＤＰ及び他の信頼性の低いトランスポート・プロトコルで使用するのに適している効果的な輻輳制御及び輻輳回避技術に対する必要性が当該技術分野において存在する。この文脈内で本開示の態様が生じる。

本開示のある特定の実施に従い、送信側コンピューティング・システムにより実行される方法は、信頼性の低いプロトコルを介してネットワーク経由で少なくとも１つの受信側デバイスへデータ・パケット・ストリームを送信することを含むことができる。このデータ・パケット・ストリームは、ソース・パケット及び前方誤り訂正（ＦＥＣ）パケットを含むことができる。方法は、この送信中に、少なくとも１つの受信側デバイスから１つ以上のフィードバック・レポートを受信し、それぞれの定期的なフィードバック・レポートは対応する期間中のパケット損失を特徴付けることを含むことができる。また方法は、この送信中に、フィードバック・レポートの内の少なくとも１つに応答してストリームにデータ・パケットを送信する速度を調整することを含むことができる。この速度を調整することは、許容レベル内としてパケット損失を特徴付けるフィードバック・レポートの１つに応答してソース・パケットを送信するソース・レートを維持しながらＦＥＣパケットを送信するＦＥＣレートを増加させることを含むことができる。

本開示のある特定の実施に従い、送信側コンピューティング・システムは、少なくとも１つのプロセッサ・ユニット、及びこの少なくとも１つのプロセッサ・ユニットに連結された少なくとも１つのメモリ・ユニットを含むことができる。少なくとも１つのプロセッサ・ユニット及び少なくとも１つのメモリ・ユニットは、方法を実行するように構成することができる。この方法は、信頼性の低いプロトコルを介してネットワーク経由で少なくとも１つの受信側デバイスへデータ・パケット・ストリームを送信することを含むことができる。このデータ・パケット・ストリームは、ソース・パケット及び前方誤り訂正（ＦＥＣ）パケットを含むことができる。方法は、この送信中に、少なくとも１つの受信側デバイスから１つ以上のフィードバック・レポートを受信し、それぞれの定期的なフィードバック・レポートは対応する期間中のパケット損失を特徴付けることを含むことができる。また方法は、送信中に、フィードバック・レポートの内の少なくとも１つに応答してストリームにデータ・パケットを送信する速度を調整することを含むことができる。この速度を調整することは、許容レベル内としてパケット損失を特徴付けるフィードバック・レポートの内の１つに応答してソース・パケットを送信するソース・レートを維持しながらＦＥＣパケットを送信するＦＥＣレートを増加させることを含むことができる。

本開示のある特定の実施に従い、非一時的なコンピュータ可読媒体が、その中で具現化されたコンピュータ可読命令を含むことができる。このコンピュータ可読命令は、実行時に方法を実施するように構成することができる。この方法は、信頼性の低いプロトコルを介してネットワーク経由で少なくとも１つの受信側デバイスへデータ・パケット・ストリームを送信することを含むことができる。このデータ・パケット・ストリームは、ソース・パケット及び前方誤り訂正（ＦＥＣ）パケットを含むことができる。方法は、この送信中に、少なくとも１つの受信側デバイスから１つ以上のフィードバック・レポートを受信し、それぞれの定期的なフィードバック・レポートは対応する期間中のパケット損失を特徴付けることを含むことができる。また方法は、この送信中に、フィードバック・レポートの内の少なくとも１つに応答してストリームにデータ・パケットを送信する速度を調整することを含むことができる。この速度を調整することは、許容レベル内としてパケット損失を特徴付けるフィードバック・レポートの内の１つに応答してソース・パケットを送信するソース・レートを維持しながらＦＥＣパケットを送信するＦＥＣレートを増加させることを含むことができる。

本開示の教示は、以下の添付の図面と併せて以下の発明を実施するための形態を考慮することで容易に理解することができる。

本開示のある特定の態様に従う例示的なデータ転送及び前方誤り訂正技術の概略図である。 本開示のある特定の態様に従う例示的な輻輳制御技術の流れ図である。 本開示のある特定の態様に従う、少なくとも１つの受信側デバイスからのフィードバックに応答して送信側デバイスでビットレートを調整する詳細な実施例の流れ図である。 本開示のある特定の態様に従う例示的なシステムのブロック図である。

以下の発明を実施するための形態が例示の目的のために多くの具体的な詳細を含むが、いかなる当業者も、以下の詳細への多くの変形及び変更が本発明の範囲内であることを理解するであろう。したがって、以下に記載する本開示の例示的な実施は、請求項に係る発明への一般性を失うことなく、請求項に係る発明に制限を課すことなく示される。

序説
本開示の態様は、ＵＤＰのような、信頼性の低いトランスポート・プロトコルと共に使用することができる輻輳制御及び／または輻輳回避技術に関する。

ある特定の態様に従い、１つ以上の送信側デバイスは、ＵＤＰのような、信頼性の低いトランスポート・プロトコルを使用して、１つ以上の受信側デバイスへデータ・パケットを送信することができる。このデータ・パケットは、所望のソース・データを含むソース・パケット、及びソース・パケットの内の１つ以上が１つ以上の受信側デバイスに到着できない場合の誤り訂正のためのソース・データの冗長情報を含むＦＥＣパケットの両方を含むことができる。定期的なフィードバック・レポートを、１つ以上の受信側デバイスから１つ以上の送信側デバイスへ送信することができる。このフィードバック・レポートは、対応する期間中のパケット損失を識別することができ、送信側はこのフィードバック・レポートを使用して期間中にパケット損失が発生したかどうかを識別すること、及び／または対応する期間中のパケット損失の程度を識別することができる。このパケット損失は、たとえば、データ・ストリーム中のビットレートを過度に高く提示する送信側の結果として、発生する可能性がある。

ある特定の態様に従い、１つ以上の送信側デバイスは、定期的なフィードバック・レポートを使用して、１つ以上の受信側デバイスへ送信されたストリームでのデータ・パケットのビットレートの様相を調整することができる。ビットレートの様相は、ソース・データを取得する受信側デバイスの能力を最適化する方式で調整することができる。ある特定の態様において、パケット損失が許容レベル内にあることを示すフィードバック・レポートに応答して、ＦＥＣパケットのビットレートは、最初のフィードバック・レポートに応答してストリームでソース・パケットの同時ビットレートを維持しながら、増加することができる。ある特定の態様に従うと、ビットレートを誤り訂正のために使用されるＦＥＣパケットの数のみを増加させることで調整することができるので、１つ以上の受信側デバイスは、ビットレートでの増加が輻輳をもたらし、パケット損失を増加させたとしても、ソース・データを再構築可能であり得る。たとえば、ソース・パケットに対するＦＥＣパケットの割合が増加することができるので、ＦＥＣパケットは、配信中のソース・パケットの損失により損失したデータを再構築するのに十分な数で正常に配信される可能性が高い。

詳細
図１を参照すると、データ転送及び前方誤り訂正（ＦＥＣ）技術の例示的な実施例が、本開示のある特定の態様に従い描写される。図１の実施例において、１つ以上の送信側デバイス１０２は、ネットワーク１０６経由で１つ以上の受信側デバイス１０４へデータを送信することができ、このデータは、複数のデータ・パケット１０８の形式で伝送され得る。データ・パケット１０８は、各パケット１０８の配信も、複数のパケット１０８の順序正しい配信もプロトコルにより保証されない、ＵＤＰのような、信頼性の低いプロトコルを使用して送信されたデータグラムであってもよい。したがって、パケット損失の場合に、送信側デバイス１０２は損失したパケットを再送信しないで、受信側デバイス１０４は、使用された特定のＦＥＣ技術によりデータ・ストリームで符号化された冗長情報を使用して損失したソース・データを再構築しようとすることができる。

図１で示されるように、データ・パケット１０８は、受信側デバイス１０４へ配信される元のソース・データ１１０を含むソース・パケット（図１の網掛けボックス）、及び十分に利用可能な他のソースまたはパリティ・パケットがある限りそれが任意の損失したソース・パケットの代わりをすることを可能にする情報を含むパリティ・パケットである、ＦＥＣパケット（図１の白／黒ボックス）の両方を含むことができる。ＦＥＣパケットは、元のソース・データ１１０の冗長情報を含むことができ、ソース・パケットの内の１つ以上が、たとえばそれらがネットワーク１０６によりドロップされたために受信側１０４に適切に到着しない場合にソース・データ１１０を再構築するために受信側デバイス１０４により使用され得る。伝送されるデータがオーディオ及びビデオ・ストリームを含むある特定の実施において、データ・パケット１０８は、前述の種類の両方のオーディオ・パケット及びビデオ・パケットの両方をさらに含むことができ、たとえば、データ・パケット１０８は、オーディオ・ソース・パケット、オーディオＦＥＣパケット、ビデオ・ソース・パケット、及びビデオＦＥＣパケットを含むことができ、オーディオ・パケットは、ビデオ・パケットより一般的に小さくあり得る（すなわち、より少ないデータ量を含む）。

ある特定の実施において、ソース・データ１１０は、リアルタイムで受信側デバイス１０４へ伝送されるデータ・ストリームであってもよく、ソース・データ１１０は、送信側デバイス１０２上で動作するアプリケーションにより生成することができる。そのような実施において、リアルタイム・ソース・データ１１０は、シーケンスで出力されるデータの複数のフレームで構成され得、それらのフレームは、ソース・データを生成するアプリケーションにより定義され得る。たとえば、ソース・データ１１０は、ビデオ・ゲーム、ビデオ・テレフォニィ・プログラム、または他のＡ／Ｖソース・プログラムのような、送信側デバイス１０２上で動作するアプリケーションから出力されるリアルタイム・オーディオ／ビデオ（Ａ／Ｖ）・ストリームであってもよく、このアプリケーションは各フレームを定義することができる。

図１の実施例において、ソース・データ１１０の図示されたブロックは、複数のソース・パケット及びＦＥＣパケットを受信側デバイス１０４へネットワーク１０６経由で生成して伝送する、たとえば単一のＡ／Ｖフレームのような、単一のフレームに対応することができる。データ・ストリームは、複数のフレーム１１０で構成することができフレームは、送信側デバイス１０２で、ある順序で生成することができ、複数のデータ・パケット１０８は、受信側デバイス１０４への伝送用の各フレームのために形成することができる。

ＵＤＰまたは別の信頼性の低いプロトコルを使用してデータを伝送するときに、データグラムのような、データ・パケット１０８は、異なるそれぞれの経路を介してネットワーク１０６によりルーティングされ得、順序を外れて受信側デバイスに到着し得ることに留意する。受信側デバイス１０４でのデータの再構築を促進するために、データ・パケット１０８の各々は、ある特定の識別情報が送信側デバイスにより付され得る。たとえば、シーケンスのどのフレームにデータ・パケットが属するかを示す、フレーム番号のようなフレーム識別子、ならびに各フレーム内（及び／またはフレーム全体）のシーケンスのどこにデータ・パケットが属するかを示す、シーケンス番号のようなシーケンス識別子を各データ・パケット１０８に付けることができる。それに応じて、送信側デバイス１０２は、形成された各新規のデータ・パケットのシーケンス番号をインクリメントすることができ、形成された各新規のフレームのデータ・パケットのフレーム番号をインクリメントすることができる。任意選択で、データ・パケット１０８は、たとえば、データ・ストリームがオーディオ及びビデオ・コンポーネントの両方を含むリアルタイム・データ・ストリームである実施において、パケットがオーディオまたはビデオ・パケットであるかどうかを識別するタイプ識別子のような、識別情報をさらに付すことができる。受信側デバイス１０４は、各パケットへ付けられたこの補足情報に従いデータを組み立てることができ、たとえば、受信側でエンドユーザへの提示用に、それに応じてデータを復号することができる。

ソース・パケットの内の１つ以上がネットワーク１０６によってドロップされる、またはその他の方法でそれらの宛先に到着できないパケット損失が発生した場合、受信側デバイス１０４は、図１で示されるように、冗長的に符号化されたＦＥＣパリティ・パケットを利用して、送信側デバイス１０２による再送信なしでソース・データ１１０を再構築することができる。任意の数のＦＥＣパリティ・パケットを異なるアルゴリズムを使用して１つ以上のソース・パケットから生成することが可能であることに留意する。ある特定の実施において、ＦＥＣデータは消失訂正符号を使用して生成することができる。ある特定の実施において、この消失訂正符号は、リードソロモン符号であってもよい。とりわけ、消失訂正符号化を支援して本開示の実施で使用することができるオープン・ソース・ライブラリの、１つの非限定的な例は、Ｊｅｒａｓｕｒｅとして知られている。ある特定の実施において、誤り訂正スキームは、受信側に到着しない各ソース・パケットについて、特定のセットのデータを再構築するために１つのＦＥＣパケットを必要し得るようなものであることができる。たとえば、受信側デバイスへ配信されるデータの特定のフレームについて、ＦＥＣ技術は、パケット損失の場合にフレームを完全に再構築するために、受信側デバイスに適切に到着するＦＥＣパケットの数が損失したソース・パケットの数に少なくとも等しい必要があるものであってもよい。そうでなければ、このフレームは、破損している可能性がある。換言すれば、Ｎ個のソース・パケットが存在してＭ個のパリティ・パケットが生成されたとすると、少なくともＮ個の合計パケット（ソース及びパリティ）を受信するときにソース・データを回復することが可能である。図１の説明において、送信側により送信されるソース・パケットの数は、送信されるＦＥＣパケットの数に等しい、すなわち、送信側１０２により伝送されるＦＥＣパケットに対するソース・パケットの割合は、説明を簡単にするために、単に１：１である。しかしながら、以下で説明されるように、多くの他の割合を使用できること、及び本開示のある特定の態様に従い、ＦＥＣパケットに対するソース・パケットの割合は動的であってもよく、ストリーム中で経時変化することができることに留意する。

データ転送中に利用可能な帯域幅を効率的に活用する方式を最適化するために、及び許容不可能なパケット損失を誘発する方式でネットワーク・チャネルを過負荷とすることを回避するために、送信側デバイス１０２及び／または受信側デバイス１０４は、本開示の態様に従い、輻輳制御アルゴリズムを実施するように構成することができる。

ここで図２を参照すると、１つ以上の送信側デバイス２０２及び１つ以上の受信側デバイス２０４間の輻輳制御技術の例示的な実施例の流れ図が示される。ある特定の実施において、輻輳制御技術は、図１で描写されるデータ転送及び誤り訂正技術の少なくともいくつかの態様への類似性を有し得る。

本開示のさまざまな態様に従い、送信側デバイス２０２は、ネットワーク２０６経由で少なくとも１つの受信側デバイス２０４へ元のソース・データ２１２を送信するように構成することができる。限定するものとしてではなく、例として、ネットワーク２０６は、パケット・スイッチングを使用してデータ・パケットをそれらの宛先へルーティングする、インターネット、ＷＡＮ、ＬＡＮ、または別のネットワークであってもよい。ある特定の実施において、送信側デバイス２０２は、送信側デバイス上で動作していることができる、アプリケーションからソース・データ２１２を受信することができ、送信側デバイスは、ＵＤＰのような、信頼性の低いトランスポート・プロトコルを使用して受信側デバイス２０４へリアルタイムでソース・データ２１２を伝送するように構成することができる。

ある特定の実施において、ソース・データ２１２は、２１４で示されるように、ネットワーク経由の伝送前に圧縮される必要がある種類のものであり得、送信側デバイスは、このソース・データを圧縮するように構成することができる。限定するものとしてではなく、例として、ソース・データは、リアルタイム・オーディオ・ストリーム、リアルタイム・ビデオ・ストリーム、または両方（すなわち、リアルタイム・オーディオ／ビデオ・ストリーム）を含むことができ、送信側デバイスは、オーディオ及び／またはビデオ・エンコーダを使用して、さまざまな圧縮フォーマットのうちのいずれかでデータを圧縮することができる。ある特定の実施において、ソース・データは、低遅延コーデックを使用して符号化することができる。たとえば、ソース・データは、低遅延ビデオ・コーデックの例であるｈ．２６４フォーマットにより符号化されたリアルタイム・ビデオ・ストリームを含むことができる。さらに例として、ソース・データは、ＣＥＬＴフォーマットにより符号化されたリアルタイム・オーディオ・ストリーム、及び低遅延オーディオ・コーデックの例を含むことができる。

次に送信側デバイス２０２は、２１６及び２１８で示されるように、複数のデータ・パケットを形成することにより、伝送のための、たとえば、圧縮または非圧縮形式のアプリケーションから受信されるような、ソース・データを作成することができる。データ・パケットを形成することは、ソース・データのセットを複数の個別のペイロードに分割すること、及び各ペイロードへ補足データを加えてデータ・パケットを形成することを伴うことができる。送信側デバイス２０２により形成されたデータ・パケットは、ソース・データ２１２（図２の図示される実施例のための圧縮フォーマットに）を含む、２１６で示されるようなソース・パケット、及びソース・データ２１２の冗長情報を有し、いくつかの誤り訂正符号により形成することができる、２１８で示されるようなＦＥＣパケットを含むことができる。

本開示のある特定の態様により、ソース・データ２１２は、送信側デバイス２０２上で動作するアプリケーションにより定義することができる、複数のフレームで構成されることができ、送信側デバイスは、各フレームについて、ソース・パケット及びＦＥＣパケットを含む、複数のデータ・パケットを形成することができる。本開示のある特定の実施において、データ・パケットを送信する前に、送信側デバイス２０２は、伝送プロセスで使用するために特定の識別情報をデータ・パケットの各々に付けることができる。ある特定の態様に従い、２１６及び２１８で示されるような、各データ・パケットに加えられたスタンプ情報は、各データ・パケットがどのフレームに属するかを示す、フレーム番号のようなフレーム識別子、ならびに各データ・パケットがフレーム内及び全体に拡張するシーケンス内のどこに属するかを示すシーケンス番号のようなシーケンス識別子を含むことができる。それに応じて、送信側デバイスは、各個別のデータ・パケットでシーケンス番号をインクリメントし、データの各個別のフレームでフレーム番号をインクリメントするように構成することができる。ソース・データがリアルタイム・オーディオ及びビデオ・ストリームを含むような、ある特定の実施において、任意選択で、スタンプ情報は、特定のデータ・パケットがオーディオ・データまたはビデオ・データを含むかどうかを識別することができる、メディア・タイプ識別子をも含むことができる。次に送信側デバイスは、ネットワーク２０６経由で１つ以上の受信側デバイス２０４への配信のために、２２０で示されるように、それらを形成してスタンプ情報付けた後にデータ・パケットを送信することができる。

シーケンス番号は、各新規のパケットのために所定量で（たとえば、１で）インクリメントすることができる。受信側デバイス２０４は、受信したパケットのシーケンス番号を使用して、いくつのパケットが欠落しているかを判定することができる。またスタンプ情報は、たとえば、いくつのパケットがフレームにあり、所与のパケットがフレーム内のどのパケット・インデックスであるかを判定する追加情報をも含むことができる。

受信側デバイス２０４は、これらがネットワーク２０６によりドロップされないように、適切に配信されるデータ・パケットを受信することができ、受信側デバイス２０４は、２２２で示されるように、それらが到着するとデータ・パケットを蓄積することができる。受信側デバイス２０４は、たとえば、フレーム及びシーケンス識別子情報を含む、各パケットに含まれた補足情報を使用して、それに応じて受信したデータを組み立てることができる。また受信側デバイス２０４は、使用された特定の誤り訂正技術により、ＦＥＣパケットを使用して任意の損失したソース・パケットを再構築することができる。

ある特定の態様に従い、受信側デバイス２０４は、２２４で示されるように、各パケットに含まれるスタンプ情報から所与の期間のパケット損失を定期的に判定するように構成することができる。ある特定の実施において、受信側デバイス２０４は、ある期間中に受信したデータ・パケットの総数を、その期間中に受信したパケットに付けられたシーケンス情報と比較し、その特定の期間のパケット損失の割合を決定することができる。たとえば、シーケンス識別子は各新規のパケットでインクリメントすることができるので、それらは、データ・パケットのすべてを適切に配信した場合に特定の期間中に受信しているべきであるデータ・パケットの総数を示すことができる。受信側デバイス２０４は、シーケンス識別子から判定された所期のパケットのこの数を期間中に実際に受信したパケット数と比較し、その期間のパケット損失を把握することができる。次に受信側デバイス２０４は、２２６で示されるように、特定の期間のフィードバック情報として送信側デバイス２０２へパケット損失を送信することができる。

受信側デバイスから送信側デバイスに戻されるフィードバック情報を送信するために使用されるトランスポート・プロトコルが送信側から受信側へデータ・パケットを転送するために使用された信頼性の低いプロトコルと同じプロトコルであってもよい、またはそれが異なるプロトコルであってもよいことに留意する。たとえば、送信側から受信側へデータ・パケットを転送するために使用された信頼性の低いプロトコルは、ＵＤＰのような、コネクションレス・プロトコルであってもよい。ある特定の実施において、受信側デバイスから送信側デバイスへ信頼性の高いチャネルを、ＵＤＰ上で作成することができる。本開示のある特定の実施で使用されることができ、ＵＤＰ上で信頼性の高いチャネルを作成するためのオープン・ソース・ソリューションの例は、ｕｓｒｓｃｔｐである。他の実施において、受信側デバイスから送信側デバイスへ戻されるフィードバック・レポートを送信するための信頼性の高いバックチャネルは、ＴＣＰのような別個の信頼性の高いプロトコルまたはいくつかの他の信頼性の高いプロトコルを使用して確立された信頼性の高いチャネルのような、完全に別個の接続を使用して確立することができる。ある特定の実施において、このデータの異なる性質及び目的に起因して、送信側から受信側へ送信されるソース・データと比較して、フィードバック情報を確実に送信することが好ましくあり得る。

ある特定の実施において、送信側デバイス２０２は、２２８で示されるように、受信側デバイスから受信したフィードバック情報でのパケット損失を正規化することができる。これは、通常のストリーミング期間中に送信されるパケットの所期の量に対応することができる、パケットの所定の量に対してパケット損失を正規化することで達成することができる。たとえば、受信側デバイスがシーケンス情報から決定されるような、所期のパケットに対する受信したパケットの割合としてパケット損失を判定する場合に、実際に送信されたデータ・パケット量が送信側デバイスにより送信可能なものよりはるかに少ないなら、この割合は、パケット損失を過大評価する傾向がある。より詳細な例として、送信側デバイスが４個のパケットを送信するが、受信側デバイスが特定の期間に３個のパケットのみ受信する場合に、受信側デバイスは、２５％のパケット損失を判定することができる。しかしながら、送信側デバイスがこの期間中に１００個のパケットを送信することが可能であるが、４個が送信される必要があるすべてのデータであるので４個のみを送信するなら、真のパケット損失は、４個の内の１個の損失したパケットの代わりに、１００個の内の１個の損失したパケット、すなわち２５％の代わりに１％としてより正確に表することができる。より一般的な例として、通常のストリーミング中に、Ｎ個のパケットを期間Ｘ中に受信することを予め決定することができる。Ｘ中に受信側デバイスが、Ｎ／２個のパケットに基づき、たとえば、データ・パケットのシーケンス番号に基づき、パケット損失を報告するならば、任意の損失は、Ｎ／２個からではなく、Ｎ個から損失したパケット数へ送信側により正規化されるべきである。それに応じて、送信側デバイスは、１つ以上の受信側デバイス２０４から、期間中に転送されることを期待されるデータ・パケットの所定量に対して受信したパケット損失を正規化するように構成することができる。

ある特定の態様に従い、受信側デバイス２０４（任意選択で、さらに送信側で正規化された）から受信したフィードバック情報に応答して、送信側デバイス２０２は、本明細書に記載された輻輳制御の特定の原則に従い、２３０で示されるように、それがデータ・パケットを送信する速度を調整することができる。ある特定の場合において、パケット損失が対応する期間中の許容レベル内であったことを示す１組のフィードバック情報に応答して、送信側デバイスは、ストリームのビットレートを増加させるように構成することができるが、それは、ソース・パケットを送信するビットレートを維持しながら、またはその他の方法でこれを増加させないで、ＦＥＣパケットを送信するビットレートのみを最初に増加させることで、そうすることができる。さらにフィードバック情報に応答してビットレートを調整することができる方式に関する態様は、本開示の他の箇所で説明される。

図２で描写された例示的な方法が連続した、または繰り返されたプロセスであってもよく、ソース・データ２１２が伝送されている限り、継続してもよいことに留意することは、重要である。ある特定の実施において、送信側デバイス２０２がフィードバック情報に直接応答してデータ・パケットを送信するビットレートを定期的に調整することができるように、フィードバック情報は、データ伝送中に定期的に送信側デバイス２０２へ受信側デバイス２０４により送信することができる。より頻繁にフィードバック情報を送信することにより、ストリームの応答性を増加させることができるが、フィードバック情報を考慮してアップストリーム（すなわち、受信側から送信側への）帯域幅を減少させるトレードオフでそれが行われることに留意する。ある特定の実施において、フィードバック・レポートは、１秒に５回、すなわち２００ミリ秒（ｍｓ）毎に送信することができる。さらなる実施において、フィードバック・レポートは、１００ｍｓ毎及び１秒毎の範囲内で送信することができる。フィードバックを過度に頻繁に、たとえば、１００ｍｓ毎に１回より多く送信すると、受信側は、パケット損失を判定するために有用なパケット数を蓄積するのに十分な時間を有さなかった可能性があり、それはサンプル・サイズとして小さすぎる可能性がある。それに反して、フィードバックが十分に頻繁に送信されない、たとえば、１秒毎に１回より少ない場合に、次にそれは有用であるのに十分に頻繁ではない可能性がある。

ある特定の実施において、送信側デバイスは、データ・パケットを複数の受信側デバイスへ送信することができ、複数の異なる宛先システムからのフィードバック・レポートに応答してビットレートを調整することができることに留意する。ある特定の実施において、これは、各それぞれの受信側デバイスのために送信側デバイス上でそれぞれのエンコーダを介して達成することができ、その場合、送信側デバイスは、それぞれの受信側デバイスのためのビットレートを、それらのそれぞれのフィードバック情報に基づき独立して調整するように構成することができる。他の実施において、送信側デバイスは、複数の受信側デバイスに対応する１つのエンコーダを含むことができ、その場合、最も低い質の転送に基づき受信側デバイスのすべてのためにビットレートを調整することができる。

受信側デバイスから受信したフィードバック情報に応答して送信側デバイスによりビットレートを調整する方式は、任意の特定のフィードバック・レポートのパケット損失の性質に依存し得ることに留意する。本開示のある特定の態様によりフィードバックに応答してビットレートを調整することができる方式のある特定の例示的な態様を図３で描写する。具体的には、図３は、本開示のある特定の実施に従い、フィードバック情報に応答して信頼性の低いプロトコルを介してデータを転送するビットレートを調整するための例示的なプロセス・フローを描写する。図３で描写されるビットレートを調整する例示的な方法３３０は、図２の２３０で示されたビットレートの調整と共通の１つ以上の態様を有することができることに留意する。また、図３の実施例は、本開示に従い速度を調整することができる方式のある特定の態様のみを説明する目的の、簡略化した実施例にすぎないことに留意することは、重要である。

最初に、送信側がすべてのデータ・パケットを送信する速度により定義される、ストリームの総ビットレートが、ソース・パケットを送信する速度により定義されるソース・ビットレート、及びＦＥＣパケットを送信する速度で定義されたＦＥＣビットレートの両方を含むことに留意することは、重要である。図３で示されるように、一般に、１つ以上の受信側デバイスから送信側が受信するフィードバック情報３３２に応答してビットレートを調整する方式は、３３４で示されるように、パケット損失がそれぞれの期間中に許容レベル内であったことをフィードバック情報３３２が示すか否かに依存し得る。３３４で示される許容レベルが前の状態に関連して定義され得ることに留意する。たとえば、示されたパケット損失は、それが前の状態に対して定常である、たとえば、パケット損失レベルが、前のフィードバック・レポートで示されたパケット損失に対して比較的一定であり変動していない場合に、許容レベル内であることができる。ビットレートを調整する方式は、３４４で示されるように、フィードバック情報がある所定の総パケット損失閾値を超えるパケット損失を示すかどうかに依存し得る。

ある特定の態様に従うと、パケット損失がそれぞれの期間中に許容レベル内であったことを受信側デバイスからの特定のフィードバック・レポート３３２が示す場合、これは、たとえば、ネットワーク・チャネルの利用可能な最大帯域幅が伝送されたストリームで満たされていないので、送信側が伝送した総ビットレートを増加させることができることを示し得る。ある特定の実施において、示されたパケット損失は、それが直前のフィードバック・レポートと比較して、同じ許容可能な変化量である、または許容可能な変化量内にあるときに許容レベル内であることができる。したがって、ある特定の実施において、損失が変動していない限り、パケット損失を増加させることができる。しかしながら、盲目的に、インクリメンタルでも、ビットレートを増加させることは、パケット損失を誘発し得、受信側デバイスでフレームの破損または信号のドロップアウトのような許容できない結果を通常引き起こす可能性がある。

したがって、本開示のある特定の実施は、パケット損失が、それが定常として示されるときのような、増加しなかった、あるいは、ある許容レベル内にあったことを示すフィードバック・レポートに応答して、３３８で示されるように、最初は、ソース・ビットレートを維持しながら、ＦＥＣビットレートのみ増加させることでビットレートを増加させることによりこれらの課題に対処することができる。重要なことには、結果がより多いＦＥＣパケット数となるので、ビットレートの増加が、チャネル輻輳によるような、パケット損失を引き起こすとしても、受信側デバイスは、ストリーム内のＦＥＣパケットの結果として生じるより多くの量により、いかなる損失したソース・パケットをも再構築することができる、またはこのことができる可能性が少なくとも非常に高い。たとえば、適切に配信されるＦＥＣパケット数が転送中に損失したソース・パケット数より多い、または少なくともこれに等しい可能性がはるかに高い。さらに、そのようなデータ転送速度の増加は、送信側デバイスが受信する後続のフィードバック・レポート３３２がストリームでより大きな総ビットレートを反映し、チャネル輻輳によるような、パケット損失を変動させられた総ビットレートでそれが増加するかどうかを示すので、送信側デバイスへ必要なフィードバックを提供することができる。

パケット損失が増加したビットレートに応答して定常であり続ける、たとえば、それが１つ以上の後続のフィードバック・レポート３３２により示されるような提供されたデータ・パケットに応答して、変動または増加しない場合に、ビットレートに対する次の調整は、３４２で示されるように、前のＦＥＣ増加と同じ量でのような、ＦＥＣビットレートの前の増加へのステップでソース・ビットレートでの増加であってもよい。ある特定の実施において、これは、フィードバック３３２で示されるように、時間間隔中でパケット損失が許容可能なままである限り、直後のフィードバック・レポートに応答してであってもよい、またはそれは、１つより多いフィードバック・レポートを有するある他の時間間隔の後にあってもよい。換言すれば、３４０で示されるように、最新の変更が、ソース・ビットレートを維持しながらのＦＥＣビットレートへの増加であったならば、この次の調整は、パケット損失が許容可能であり続ける場合に、前のＦＥＣ増加と同じ量によるソース・ビットレートでの増加であってもよい。次にこの総ビットレートは、パケット損失が定常であることをフィードバック３３２が示す限りインクリメンタルに増加し続けることができる。

限定としてではなく、例として、３４０で示されるように、最新の調整が総ビットレートの増加ではないならば、ストリームの利用可能な帯域幅は、３３８で示されるように、１００ｋｂ／ｓだけＦＥＣビットレートを増加させることにより検査することができる。３３４で示されるように、パケット損失がないことを１つ以上の後続のフィードバック・レポートが示すならば、次の調整は、３４２で示されるように、１００ｋｂ／ｓだけソース・ビットレートを増加させることであってもよく、ＦＥＣビットレートは、この方式でソース・ビットレートを増加させるときに維持することができ、総ビットレートでの別の増加をもたらす。この総ビットレートは、パケット損失が増加ビットレートに応答して変動するまで、この方式で増加し続けることができる。総ビットレートでの初期増加により誘発されたパケット損失が発生する場合に、受信側デバイスが損失したソース・データを再構築することが可能であることを確保するためにＦＥＣパケットで導く。さらに、ＦＥＣパケットでの増加を導くことは、ソース・ビットレートが増加可能であるかどうかを判定するために所望のフィードバックを生成することができる。

限定としてではなく、例として、たとえばストリームの総ビットレートが２０００ｋｂ／ｓであり、そのうちの１００ｋｂ／ｓがＦＥＣパケットであり、ソース・パケットは１９００ｋｂ／ｓとなるとする。帯域幅を検査するために、最初にＦＥＣレートを２００ｋｂ／ｓへ増加させることができる。ここで、総帯域幅は、２１００ｋｂ／ｓである。追加の損失がないと判定するときに、ソース・レートは、前のＦＥＣレート増加量だけ増加することができる。そこでソース・レートは、総レートは１９００ｋｂ／ｓ＋１００ｋｂ／ｓ＝２０００ｋｂ／ｓとなり、（２０００ｋｂ／ｓのソース）＋（ＦＥＣの１００ｋｂ／ｓ）＝２１００ｋｂ／ｓの合計であるが、帯域幅は、再びＦＥＣを２００ｋｂ／ｓにすることで直ちに検査することができ得る。このようにして、２０００ｋｂ／ｓのソース＋２００ｋｂ／ｓのＦＥＣがある。次の反復は、次の反復で２１００ｋｂ／ｓのソース＋２００ｋｂ／ｓのＦＥＣであり得、次にパケット損失が提示されたデータに応答して増加するまで、２２００ｋｂ／ｓのソース＋２００ｋｂ／ｓのＦＥＣなどが続く。

ある特定の態様に従い、３３８でＦＥＣビットレートが増加するような、ビットレートが増加する方式がさまざまな考慮事項に依存し得ることに留意する。たとえば、それが増加する量は、所望のとおり変化することができる。さらに、ソース及びＦＥＣパケットの別個の種類をもたらす、ソース・データの別個の種類を含む実施において、ビットレートでの増加を分配する方式は、これらのパケットの性質により、たとえば、パケットの各別個の種類の相対的なサイズに基づいて変化することができる。

たとえば、オーディオ／ビデオ・ストリームのリアルタイム伝送を伴うある特定の実施において、総ビットレートは、オーディオ・パケットを送信する速度により定義されるオーディオ・ビットレート、及びビデオ・パケットを送信する速度で定義されるビデオ・ビットレートにより定義することもできる。これらの実施において、総ビットレートは、４つの別個の種類のビットレート種類、すなわちオーディオ・ソース・ビットレート、ビデオ・ソース・ビットレート、オーディオＦＥＣビットレート、及びオーディオ・ソース・ビットレートを含むことができる。一般的に各ビデオ・パケットは各オーディオ・パケットよりはるかに大きくあり得るので、ビデオＦＥＣパケットの速度を増加させることのみでビットレートを増加させることで、比較的少ないパケット数に対しても過度な増加を引き起こし、この増加により誘発される過度な輻輳をもたらし得る。したがって、そのような実施において、たとえば３３８で示されるような、ビットレートの各増加は、フレームあたりのビデオＦＥＣパケット数、及びフレームあたりのオーディオＦＥＣパケット数の両方での増加を含むことができる。重要なことには、パケットのこれら２個の別個の種類のビットレートが増加する割合は、たとえば、オーディオ・パケットがより小さく、したがって総帯域幅へのより細かい調整が容易である事実を考慮するため等、所望により、それらの相対的なサイズにより調整することができる。限定としてではなく、例として、各反復で増加させるビデオＦＥＣビットレートに対する増加させるオーディオＦＥＣビットレートの割合は、２：１から１０：１の範囲にあることができる。換言すれば、３３８でＦＥＣビットレートを増加させること、または３４２でソース・ビットレートを増加させることは、フレームあたり、追加のビデオ・パケットすべての各々１つについて２〜１０個の追加のオーディオ・パケットを送信することを含むことができる。

本開示のさらなる態様に従い、３３４で示されるように、たとえば、前の状態に対して変動または増加しているので、パケット損失がもはや許容可能ではないことをフィードバック・レポートが代わりに示すときに、パケット損失が許容可能であったときと異なる方式でストリームのビットレートを調整することができる。ある特定の実施において、パケット損失が存在したことを示すフィードバック・レポートに応答して、初期調整は、３４６で示されるように、総ビットレートを維持しながら、ソース・パケットに対するＦＥＣパケットの割合を増加させることを伴うことができる。この例示的な初期ステップは送信側デバイスにより送信される総ビットレートでの減少を伴わず、ソース・パケットに対するＦＥＣパケットの割合での変化のみであるので、これは、このような損失がチャネルでの輻輳によるものである場合にパケット損失を減少させない可能性がある。しかしながら、ストリームでのより多くのＦＥＣパケット数のために、受信側デバイスは、パケット損失に対処するより良い能力を有し得る。さらに、これは、パケット損失を引き起こす状態が一過性であった場合に、総ビットレートを減少させる前に、送信側が追加のフィードバックを取得し続けることを可能にする。

３４４で示されるように、パケット損失が問題であり続け、それがある合計の所定閾値を超えると、３４８で示されるように、総ビットレートを低減させることでビットレートを調整することができる。この総ビットレートは、ある所定量で低減させることができるか、またはそれは、ビットレート、たとえば、パケット損失が許容可能であったことを示したフィードバック３３２をもたらしたビットレートが直前に動作した任意のものを低減させることができる。

いくつかの場合において、ネットワーク経由で伝送するために送信側で利用可能なソース・データ量が現在利用可能な帯域幅の量を満たすのに不十分である可能性があることに留意する。限定としてではなく、例として、リアルタイム・ビデオが黒い画面を現在生成している場合に、アプリケーションが利用可能ビットレートを満たすのに十分なデータを単に生成していないので、ソース・データのビットレートは低くあり得る。しかしながら、それでも、利用可能な帯域幅の効率的な量が必要なときに利用可能であるように、ストリームで利用可能な最大ビットレートについてフィードバックを取得し続けることは、輻輳制御アルゴリズムにとって望ましくあり得る。これらの場合において、システムは、上記のように、帯域幅で次のステップを検査するために総ビットレートへ加えるだけでなく、ＦＥＣパケットでソース・データのために使用されなかった残りの利用可能な帯域幅を埋めるように構成することができる。

これは、以下の例により説明することができる。たとえば、プロセスが６ＭＢ／ｓでデータ・パケットを現在伝送していて、受信側デバイスからのフィードバックが、依然としてパケット損失が許容範囲内にあることを示し、伝送される帯域幅を増加させることができるとする。次のステップは、追加の１００ｋｂ／ｓだけＦＥＣビットレートを増加させて、総帯域幅を６．１ＭＢ／ｓとすることであることができる。しかしながら、ソース・データは、たとえば、アプリケーションが黒い画面であるビデオを現在生成しているので、１ＭＢ／ｓでのみ生成されている可能性がある。そのような場合において、プロセスは、５．１ＭＢ／ｓのビットレートでＦＥＣパケットを伝送することによって、検査される帯域幅の残りをＦＥＣパケットで埋めるように構成することができる。したがって、たとえば、ビデオが黒い画面からライブ映像に再び変化するので、現在生成されているソース・データのビットレートが再び増加するときに、ソース・ビットレートが一時的に低減したが、アルゴリズムはフィードバックを取得し続け、伝送された帯域幅をインクリメンタルに増加させ続けるので、システムは、依然として利用可能な最大ビットレートを効率的に活用することができる。

本開示のある特定の態様を際立たせるために、図３で描写された例示的な技術が説明目的のみのために提供されることを強調する。実際には、本開示の実施は、図３の実施例が描写しない追加または代替の検討事項を考慮することができ、図３で描写された簡略化スキームより複雑であり得る。

本開示のある特定の態様が少なくとも１つの受信側デバイスからのフィードバック・レポートに応答してソース・パケットに対するＦＥＣパケットの割合を増加させることを含むことを図３の実施例から理解するであろう。これは、それぞれの期間中にパケット損失が許容可能であったことを示すフィードバックに応答して、たとえば、３３８で示されるように、総ビットレートを増加させるためにソース・パケット量を維持しながら、ＦＥＣパケット量を増加させる方式によるものであってもよい。またこれは、パケット損失が変動した、または別様に許容できないことを示すフィードバック・レポートに応答して、３４６で示されるように、現在の総ビットレートを維持するためにＦＥＣビットレートを増加させソース・ビットレートを減少させることでソース・レートに対するＦＥＣを増加させる方式によるものであってもよい。いずれの場合においても、ストリーム中のＦＥＣパケットの相対量での増加は、受信側デバイスにパケット損失に対処するより良い能力を提供することができ、また同時に、送信側デバイスへ、ネットワークで利用可能な帯域幅の使用がより効率的に活用されることが可能であるかどうかを判定することを可能にすることができるフィードバックを提供する。

本開示のある特定の実施は、図４で示されるように、本開示のある特定の態様により輻輳制御及び／またはデータ転送方法を実施するように構成されたシステムを含む。図４は、少なくとも１つの送信側コンピューティング・システム４０２及び少なくとも１つの受信側コンピューティング・システム４０４を含む分散コンピューティング・システムを描写し、コンピューティング・システム４０２及び４０４は、本開示のある特定の態様に従いネットワーク経由でデータを転送するように構成される。ある特定の実施において、送信側コンピューティング・システム４０２は、図１〜３の送信側の内の１つ以上と共通の１つ以上の態様を含むことができる。ある特定の実施において、受信側コンピューティング・システム４０４は、図１〜３の受信側の内の１つ以上と共通の１つ以上の態様を含むことができる。送信側システム４０２及び受信側システム４０４のいずれか一方または両方は、本明細書で記載された方法のさまざまな態様を実施するのに適切なソフトウェア及び／またはハードウェアで構成することができる。送信側システム４０２及び受信側システム４０４のいずれか一方または両方は、サーバ、組み込みシステム、携帯電話、パーソナル・コンピュータ、ラップトップ・コンピュータ、タブレット・コンピュータ、携帯型ゲーム機、ワークステーション、ゲーム・コンソール、スマート・ウオッチのようなウェアラブル・デバイス等であってもよい。

ある特定の実施に従い、送信側システム４０２は、クラウド・コンピューティング・サーバであってもよく、受信側デバイス４０４は、サーバ４０２のクラウド・コンピューティング・クライアントであってもよく、送信側４０２は、信頼性の低いプロトコルを使用してネットワーク４９９経由でクライアント・デバイスへデータ・ストリームを提供するように構成することができる。限定としてではなく、例として、送信側４０２は、インターネットのような、ネットワーク４９９経由で少なくとも１つのクライアント・デバイス４０４へ、リアルタイム・オーディオ・ストリーム、リアルタイム・ビデオ・ストリーム、またはリアルタイム・オーディオ／ビデオ・ストリームのような、リアルタイム・データ・ストリームを提供するように構成されるサーバであってもよい。送信側システム４０２は、受信側システム４０４へ配信される基本的なユーザ・データを含む、ソース・パケット４５２、及びソース・パケットに含まれるソース・データの冗長情報を有するＦＥＣパケット４５４の形式で受信側システムへデータを送信するように構成することができる。送信側システム４０２は、本開示のさまざまな態様に従い受信側デバイス４０４へソース・パケットと同時にこれらのＦＥＣパケットを送信することができる。受信側システム４０４は、これらのデータ・パケットを蓄積し、ネットワーク４９９経由でフィードバック・レポート４５６を定期的に送信して送信側システム４０２へ戻すように構成することができる。送信側システム４０２は、本明細書に記載されたさまざまな態様に従い、これらのフィードバック・レポート４５６に応答してデータ・パケット４５２，４５４を送信する速度を調整するように構成することができる。

システム４０２及び４０４のいずれも（すなわち、送信側システム４０２、受信側システム４０４、または両方）は、たとえば、シングルコア、デュアルコア、クアッドコア、マルチコア、プロセッサコプロセッサ、セル・プロセッサ等のような、周知のアーキテクチャにより構成することができる、１つ以上のプロセッサ・ユニット４７０を含むことができる。またシステム４０２及び４０４のいずれも、１つ以上のメモリ・ユニット４７２（たとえば、ＲＡＭ、ＤＲＡＭ、ＲＯＭ等）を含むことができる。プロセッサ・ユニット４７０は、メモリ４７２に格納することができる、１つ以上のプログラム４７４を実行することができ、プロセッサ４７０は、たとえば、データ・バス４７６経由でメモリにアクセスすることで、メモリ４７２へ操作可能に連結することができる。メモリ・ユニット４７２は、データ４７７を含むことができ、プロセッサ・ユニット４７０は、プログラム４７４を実施する際にデータ４７７を利用することができる。システム４０２及び４０４のいずれのデータ４７７も、たとえば、本開示のさまざまな態様により、送信側システム４０２から受信側システム４０４へ伝送されたソース・データ、及び受信側４０４から送信側４０２へ伝送されたフィードバック情報を含むことができる。プログラム４７４は、プロセッサによる実行時に、たとえば、図２及び／または３の方法と共通の１つ以上の特徴を有する方法のような、有名人のビデオ・ゲーム・セッションと関連した１つ以上の操作を実行する命令を含むことができる。たとえば、送信側システム４０２のプログラム４７４は、プロセッサ４７０による実行時に送信側システムに、図２で描写された送信側の方法及び／または図３で描写された速度調整技術の態様に従い、少なくとも１つの受信側デバイス４０４へデータを送信させる、及び／または受信側デバイス４０４から受信したフィードバックに応答して輻輳を制御させる命令を含むことができる。受信側システム４０４のプログラム４７４は、図２で描写された方法の受信側の態様に従い、プロセッサ４７０による実行時に受信側システムに、データ・パケットを蓄積させる、パケット損失を判定させる、及び／または送信側４０２へフィードバック情報を送信させる命令を含むことができる。

またシステム４０２及び４０４のいずれも、たとえば、バス４７６経由で、システムの他の構成要素と通信することができる、入力／出力（Ｉ／Ｏ）回路４７９、電源（Ｐ／Ｓ）４８０、クロック（ＣＬＫ）４８１、及びキャッシュ４８２のような、周知のサポート回路４７８を含むことができる。システム４０２及び４０４のいずれも、ディスク・ドライブ、ＣＤ−ＲＯＭドライブ、テープ・ドライブ、フラッシュ・メモリ、または同様のもののようなマス・ストレージ・デバイス４８４を任意選択で含むことができ、マス・ストレージ・デバイス４８４は、プログラム及び／またはデータを格納することができる。またシステム４０２及び４０４のいずれも、表示ユニット４８６を任意選択で含むことができる。表示ユニット４８６は、陰極線管（ＣＲＴ）、フラット・パネル・スクリーン、タッチ・スクリーン、またはテキスト、数字、グラフィカル・シンボル、もしくは他の視覚オブジェクトを表示する他のデバイスの形式であってもよい。システム４０２及び４０４のいずれも、システム４０２／４０４及びユーザの間のやりとりを促進するためのユーザ・インタフェース４８８をも含むことができる。ユーザ・インタフェース４８８は、キーボード、マウス、ライト・ペン、ゲーム・コントロール・パッド、タッチ・インタフェース、または他のデバイスを含むことができる。ユーザ・インタフェースは、スピーカ及び／またはマイクロフォンのような、オーディオＩ／Ｏデバイスをも含むことができる。

ユーザは、ユーザ・インタフェース４８８を介してコンピュータ・システムのいずれともやりとりすることができる。実施例として、送信側４０２は、クラウド・ゲーミング・サーバであってもよく、受信側システム４０４は、クラウド・ゲーミング・クライアントであってもよく、ビデオ・ゲーム・ユーザは、ユーザ・インタフェース４８８を介して、サーバ４０２により実行されクライアント４０４へストリーミング配信されるビデオ・ゲームとやりとりすることができる。サーバからクライアントへデータを伝送する速度は、ユーザ・エクスペリエンスを強化してクライアント側で受信した信号品質を維持するように、本開示の態様に従い最適化することができる。ユーザ・インタフェース４８８の部分は、システム４０２／４０４とのユーザのやりとりを促進するために、表示ユニット４８６上に表示されることが可能であるグラフィカル・ユーザ・インタフェース（ＧＵＩ）を含むことができる。システム４０２／４０４は、Ｗｉ−Ｆｉ、イーサネット（登録商標）・ポート、または他の通信方法の使用を有効にするように構成された、ネットワーク・インタフェース４９０を含むことができる。ネットワーク・インタフェース４９０は、電気通信網を介する通信を促進する、適切なハードウェア、ソフトウェア、ファームウェアまたはそれらのいくつかの組み合わせを組み込むことができ、本開示のある特定の態様に従い信頼性の低いプロトコルを使用してデータ転送を支援することができる。ネットワーク・インタフェース４９０は、ローカル・エリア・ネットワーク、及びインターネットのようなワイド・エリア・ネットワーク経由で有線または無線通信を実施するように構成することができる。システム４０２及び４０４のいずれも、ネットワーク経由で１つ以上のデータ・パケット４９９を介してファイルへのデータ及び／または要求を送受信することができる。

上記の構成要素は、ハードウェア、ソフトウェア、ファームウェア、またはいくつかのそれらの組み合わせで実現することができる。

上記は本開示のさまざまな例示的な実現形態の完全な説明であるが、さまざまな代替形態、修正形態及び均等物を使用することが可能である。したがって、本発明の範囲は、上の説明により限定されると解釈されるべきではなく、代わりに、それらの均等物の全範囲と併せて、添付の特許請求の範囲を参照して決定されるべきである。好ましいかどうかにかかわらず、本明細書に記載される任意の特長は、好ましいかどうかにかかわらず、本明細書に記載される任意の他の特長と組み合わせることができる。以下の特許請求の範囲において、不定冠詞「ａ」または「ａｎ」は、明示的に別段の定めがある場合を除き、この不定冠詞の次の項目の１つ以上の数量を指す。添付の特許請求の範囲は、このような制限が語句「ｍｅａｎｓ ｆｏｒ」（の手段）または「ｓｔｅｐ ｆｏｒ」（のステップ）を使用して明示的に所与の請求項に記載されていない限り、ミーンズまたはステップ・プラス・ファンクションの制限を含むように解釈されるべきではない。

Claims (27)

1. 送信側コンピューティング・システムによる方法であって、
   信頼性の低いプロトコルを介してネットワーク経由で少なくとも１つの受信側デバイスへ、ソース・パケット及び前方誤り訂正（ＦＥＣ）パケットを含むデータ・パケット・ストリームを送信するステップと、
   前記送信中に、前記少なくとも１つの受信側デバイスから、それぞれの期間中のパケット損失を特徴付ける１つ以上の定期的なフィードバック・レポートを受信するステップと、
   前記フィードバック・レポートの内の少なくとも１つにおいて、前記それぞれの期間中に前記送信側コンピューティング・システムによって送信されたデータ・パケットの数が所定量よりも少ない場合に前記パケット損失をデータ・パケットの前記所定量に対して正規化するステップであって、前記所定量はデータ・パケットの期待量であり、データ・パケットの前記期待量は、通常のそれぞれの期間中に送信されるデータ・パケットの量である、前記正規化するステップと、
   前記送信中に、前記フィードバック・レポートの内の少なくとも１つに応答して前記ストリームにおいて前記データ・パケットを送信する速度を調整するステップとを備える、方法。
2. 前記信頼性の低いプロトコルは、ユーザ・データグラム・プロトコル（ＵＤＰ）である、請求項１の方法。
3. 前記送信側コンピューティング・システムにより、各前記データ・パケットにシーケンス番号を付けるステップをさらに備える、請求項１の方法。
4. 前記送信側コンピューティング・システムにより、各前記データ・パケットにシーケンス番号を付けるステップをさらに備え、
   前記少なくとも１つの受信側デバイスは、前記それぞれの期間中に前記データ・パケットを蓄積することにより、ならびに、前記それぞれの期間中に前記受信側デバイスにより受信した前記データ・パケットの前記シーケンス番号から、実際に受信した前記データ・パケットの数及び受信することを期待される前記データ・パケットの数を決定することにより、各前記フィードバック・レポートにおいて前記パケット損失を特徴付ける、請求項１の方法。
5. 前記送信側コンピューティング・システムにより、各前記データ・パケットにシーケンス番号を付けるステップと、
   前記受信側デバイスにより、前記それぞれの期間中に前記データ・パケットを蓄積することにより、ならびに、前記それぞれの期間中に前記受信側デバイスにより受信した前記データ・パケットの前記シーケンス番号から、実際に受信した前記データ・パケットの数及び受信することを期待される前記データ・パケットの数を決定することにより、各前記フィードバック・レポートにおいて前記パケット損失を特徴付けるステップとをさらに備える、請求項１の方法。
6. 前記速度を前記調整するステップは、
   前記フィードバック・レポートの内の特定の１つに応答して、前記データ・パケットを送信する合計速度を維持しながら、前記ソース・パケットを送信するソース・レートに対する前記ＦＥＣパケットを送信するＦＥＣレートの割合を増加させるステップをさらに備える、請求項１の方法。
7. 前記データ・パケットは、オーディオ・パケット及びビデオ・パケットを含み、
   前記データ・パケットを送信する前記速度を調整するステップは、ＦＥＣオーディオ・パケットを送信するＦＥＣオーディオ・レート及びＦＥＣビデオ・パケットを送信するＦＥＣビデオ・レートの両方を増加させるステップを含み、
   前記ＦＥＣオーディオ・レート及び前記ＦＥＣビデオ・レートの両方を前記増加させるステップは、前記ＦＥＣビデオ・レートより大きい程度で前記ＦＥＣオーディオ・レートを増加させるステップを含む、請求項１の方法。
8. 前記データ・パケットは、オーディオ・パケット及びビデオ・パケットを含み、
   前記データ・パケットを送信する前記速度を調整するステップは、ＦＥＣオーディオ・パケットを送信するＦＥＣオーディオ・レート及びＦＥＣビデオ・パケットを送信するＦＥＣビデオ・レートの両方を増加させるステップを含み、
   前記ＦＥＣオーディオ・レート及び前記ＦＥＣビデオ・レートの両方を前記増加させるステップは、前記ＦＥＣビデオ・レートの増加より２〜１０倍で前記ＦＥＣオーディオ・レートを増加させるステップを含む、請求項１の方法。
9. 前記１つ以上のフィードバック・レポートは、前記フィードバック・レポートの各々の生成間で所定の時間間隔を有する複数の定期的なフィードバック・レポートである、請求項１の方法。
10. 前記１つ以上のフィードバック・レポートは、前記フィードバック・レポートの各々の生成間で所定の時間間隔を有する複数の定期的なフィードバック・レポートであり、
    前記時間間隔は、１００ミリ秒から１秒の間である、請求項１の方法。
11. 前記少なくとも１つの受信側デバイスは、複数の受信側デバイスである、請求項１の方法。
12. 前記信頼性の低いプロトコルは、コネクションレスである、請求項１の方法。
13. 前記フィードバック・レポートの内の特定の１つは、前記フィードバック・レポートの前の１つに関して定常として前記パケット損失を示す、請求項１の方法。
14. 少なくとも１つのプロセッサ・ユニットと、
    前記少なくとも１つのプロセッサ・ユニットに連結された少なくとも１つのメモリ・ユニットと、を備え、
    前記少なくとも１つのプロセッサ・ユニット及び前記少なくとも１つのメモリ・ユニットは、方法を実行するように構成され、前記方法は、
    信頼性の低いプロトコルを介してネットワーク経由で少なくとも１つの受信側デバイスへ、ソース・パケット及び前方誤り訂正（ＦＥＣ）パケットを含むデータ・パケット・ストリームを送信するステップと、
    前記送信中に、前記少なくとも１つの受信側デバイスから、それぞれの期間中のパケット損失を特徴付ける１つ以上の定期的なフィードバック・レポートを受信するステップと、
    前記フィードバック・レポートの内の少なくとも１つにおいて、前記それぞれの期間中に送信側コンピューティング・システムによって送信されたデータ・パケットの数が所定量よりも少ない場合に前記パケット損失をデータ・パケットの前記所定量に対して正規化するステップであって、前記所定量はデータ・パケットの期待量であり、データ・パケットの前記期待量は、通常のそれぞれの期間中に送信されるデータ・パケットの量である、前記正規化するステップと、
    前記送信中に、前記フィードバック・レポートの内の少なくとも１つに応答して前記ストリームにおいて前記データ・パケットを送信する速度を調整するステップとを備える、送信側コンピューティング・システム。
15. 前記少なくとも１つのメモリ・ユニットで具現化されるコンピュータ可読命令をさらに備え、
    前記命令は、前記コンピューティング・システムに前記方法を実行させるように、前記少なくとも１つのプロセッサ・ユニットにより実行可能である、請求項１４のコンピューティング・システム。
16. 前記信頼性の低いプロトコルは、ＵＤＰである、請求項１４のコンピューティング・システム。
17. 前記方法は、
    各前記データ・パケットにシーケンス番号を付けるステップをさらに備える、請求項１４のコンピューティング・システム。
18. 前記方法は、
    各前記データ・パケットにシーケンス番号を付けるステップをさらに備え、
    前記少なくとも１つの受信側デバイスは、前記それぞれの期間中に前記データ・パケットを蓄積することにより、ならびに、前記それぞれの期間中に前記受信側デバイスにより受信した前記データ・パケットの前記シーケンス番号から、実際に受信した前記データ・パケットの数及び受信することを期待される前記データ・パケットの数を決定することにより、各前記フィードバック・レポートにおいて前記パケット損失を特徴付ける、請求項１４のコンピューティング・システム。
19. 前記速度を前記調整するステップは、
    前記フィードバック・レポートの内の特定の１つに応答して、前記データ・パケットを送信する合計速度を維持しながら、前記ソース・パケットを送信するソース・レートに対する前記ＦＥＣパケットを送信するＦＥＣレートの割合を増加させるステップをさらに備える、請求項１４のコンピューティング・システム。
20. 前記データ・パケットは、オーディオ・パケット及びビデオ・パケットを含み、
    前記データ・パケットを送信する前記速度を調整するステップは、ＦＥＣオーディオ・パケットを送信するＦＥＣオーディオ・レート及びＦＥＣビデオ・パケットを送信するＦＥＣビデオ・レートの両方を増加させるステップを含み、
    前記ＦＥＣオーディオ・レート及び前記ＦＥＣビデオ・レートの両方を前記増加させるステップは、前記ＦＥＣビデオ・レートより大きい程度で前記ＦＥＣオーディオ・レートを増加させるステップを含む、請求項１５のコンピューティング・システム。
21. 前記データ・パケットは、オーディオ・パケット及びビデオ・パケットを含み、
    前記データ・パケットを送信する前記速度を調整するステップは、ＦＥＣオーディオ・パケットを送信するＦＥＣオーディオ・レート及びＦＥＣビデオ・パケットを送信するＦＥＣビデオ・レートの両方を増加させるステップを含み、
    前記ＦＥＣオーディオ・レート及び前記ＦＥＣビデオ・レートの両方を前記増加させるステップは、前記ＦＥＣビデオ・レートの増加より２〜１０倍で前記ＦＥＣオーディオ・レートを増加させるステップを含む、請求項１５のコンピューティング・システム。
22. 前記１つ以上のフィードバック・レポートは、前記フィードバック・レポートの各々の生成間で所定の時間間隔を有する複数の定期的なフィードバック・レポートである、請求項１４のコンピューティング・システム。
23. 前記１つ以上のフィードバック・レポートは、前記フィードバック・レポートの各々の生成間で所定の時間間隔を有する複数の定期的なフィードバック・レポートであり、
    前記時間間隔は、１００ミリ秒から１秒間である、請求項１４のコンピューティング・システム。
24. 前記少なくとも１つの受信側デバイスは、複数の受信側デバイスである、請求項１４のコンピューティング・システム。
25. 前記信頼性の低いプロトコルは、コネクションレスである、請求項１４のコンピューティング・システム。
26. 前記フィードバック・レポートの内の特定の１つは、前記フィードバック・レポートの前の１つに関して定常として前記パケット損失を示す、請求項１４のコンピューティング・システム。
27. コンピュータ可読命令が格納された非一時的なコンピュータ可読記録媒体であって、前記コンピュータ可読命令が実行時に方法を実施するように構成され、前記方法は、
    信頼性の低いプロトコルを介してネットワーク経由で少なくとも１つの受信側デバイスへ、ソース・パケット及び前方誤り訂正（ＦＥＣ）パケットを含むデータ・パケット・ストリームを送信するステップと、
    前記送信中に、前記少なくとも１つの受信側デバイスから、それぞれの期間中にパケット損失を特徴付ける１つ以上の定期的なフィードバック・レポートを受信するステップと、
    前記フィードバック・レポートの内の少なくとも１つにおいて、前記それぞれの期間中に送信側コンピューティング・システムによって送信されたデータ・パケットの数が所定量よりも少ない場合に前記パケット損失をデータ・パケットの前記所定量に対して正規化するステップであって、前記所定量はデータ・パケットの期待量であり、データ・パケットの前記期待量は、通常のそれぞれの期間中に送信されるデータ・パケットの量である、前記正規化するステップと、
    前記送信中に、前記フィードバック・レポートの内の少なくとも１つに応答して前記ストリームにおいて前記データ・パケットを送信する速度を調整するステップとを備える、非一時的なコンピュータ可読記録媒体。