図面 (/)

技術 輻輳制御ビットレート・アルゴリズム

出願人 ソニーインタラクティブエンタテインメントアメリカリミテッドライアビリテイカンパニー
発明者 リッケビー、クリスチャンヤング、ケルヴィン
出願日 2015年1月28日 (4年5ヶ月経過) 出願番号 2016-550269
公開日 2017年3月23日 (2年3ヶ月経過) 公開番号 2017-508372
状態 特許登録済
技術分野 エラーの検出、防止
主要キーワード 実時間アプリケーション リアルタイム信号 タイムクリティカル 損失データ データ転送アプリケーション ECビット 再送信プロセス 消失訂正符号
関連する未来課題
重要な関連分野

この項目の情報は公開日時点(2017年3月23日)のものです。
また、この項目は機械的に抽出しているため、正しく解析できていない場合があります

図面 (5)

解決手段

当該方法は、信頼性の低いプロトコルを介してネットワーク経由で少なくとも1つの受信側デバイスへデータ・パケットストリームを送信することを含む。データ・パケット・ストリームは、ソース・パケット及び前方誤り訂正(FEC)パケットを含む。当該方法は、この送信中に、受信側デバイスから1つ以上のフィードバックレポートを受信することを含む。各定期的なフィードバック・レポートは、対応する期間中のパケット損失特徴付ける。当該方法は、この送信中に、フィードバック・レポートの内の少なくとも1つに応答してストリームにデータ・パケットを送信する速度を調整することを含む。速度を調整することは、許容レベル内としてパケット損失を特徴付けるフィードバック・レポートの1つに応答してソース・パケットを送信するソース・レートを維持しながら、FECパケットを送信するFECレートを増加させる。

概要

背景

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

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

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

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

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

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

概要

当該方法は、信頼性の低いプロトコルを介してネットワーク経由で少なくとも1つの受信側デバイスへデータ・パケット・ストリームを送信することを含む。データ・パケット・ストリームは、ソース・パケット及び前方誤り訂正(FEC)パケットを含む。当該方法は、この送信中に、受信側デバイスから1つ以上のフィードバックレポートを受信することを含む。各定期的なフィードバック・レポートは、対応する期間中のパケット損失を特徴付ける。当該方法は、この送信中に、フィードバック・レポートの内の少なくとも1つに応答してストリームにデータ・パケットを送信する速度を調整することを含む。速度を調整することは、許容レベル内としてパケット損失を特徴付けるフィードバック・レポートの1つに応答してソース・パケットを送信するソース・レートを維持しながら、FECパケットを送信するFECレートを増加させる。

目的

デジタル・ストリーミング・サービス及びさまざまなクラウド・ベースのコンピューティング・ソリューションの普及率の増加とともに、リモート・デバイス間で大量のデータを迅速かつ正確に転送する能力は、重要な課題である

効果

実績

技術文献被引用数
0件
牽制数
0件

この技術が所属する分野

ライセンス契約や譲渡などの可能性がある特許掲載中! 開放特許随時追加・更新中 詳しくはこちら

請求項1

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

請求項2

前記信頼性の低いプロトコルは、ユーザ・データグラム・プロトコル(UDP)である、請求項1の方法。

請求項3

前記送信側コンピューティング・システムにより、各前記データ・パケットにシーケンス番号を付けるステップをさらに備える、請求項1の方法。

請求項4

前記送信側コンピューティング・システムにより、各前記データ・パケットにシーケンス番号を付けるステップをさらに備え、前記少なくとも1つの受信側デバイスは、前記それぞれの期間中に前記データ・パケットを蓄積することにより、ならびに、前記それぞれの期間中に前記受信側デバイスにより受信した前記データ・パケットの前記シーケンス番号から、実際に受信した前記データ・パケットの数及び受信することを期待される前記データ・パケットの数を決定することにより、各前記フィードバック・レポートにおいて前記パケット損失を特徴付ける、請求項1の方法。

請求項5

前記送信側コンピューティング・システムにより、各前記データ・パケットにシーケンス番号を付けるステップと、前記受信側デバイスにより、前記それぞれの期間中に前記データ・パケットを蓄積することにより、ならびに、前記それぞれの期間中に前記受信側デバイスにより受信した前記データ・パケットの前記シーケンス番号から、実際に受信した前記データ・パケットの数及び受信することを期待される前記データ・パケットの数を決定することにより、各前記フィードバック・レポートにおいて前記パケット損失を特徴付けるステップとをさらに備える、請求項1の方法。

請求項6

前記送信側コンピューティング・システムにより、前記フィードバック・レポートの内の少なくとも1つにおいて、前記パケット損失を、前記それぞれの期間中に転送されることを期待される前記データ・パケットの所定量に対して正規化するステップをさらに備える、請求項1の方法。

請求項7

前記速度を前記調整するステップは、許容レベル外として前記パケット損失を特徴付ける前記フィードバック・レポートの内の特定の1つに応答して、前記データ・パケットを送信する合計速度を維持しながら、前記ソース・レートに対する前記FECレートの割合を増加させるステップをさらに備える、請求項1の方法。

請求項8

前記データ・パケットは、オーディオ・パケット及びビデオ・パケットを含み、前記FECパケットを送信するFECレートを前記増加させるステップは、前記FECオーディオ・パケットを送信するFECオーディオ・レート及び前記FECビデオ・パケットを送信するFECビデオ・レートの両方を増加させるステップを含み、前記FECオーディオ・レート及び前記FECビデオ・レートの両方を前記増加させるステップは、前記FECビデオ・レートより大きい程度で前記FECオーディオ・レートを増加させるステップを含む、請求項1の方法。

請求項9

前記データ・パケットは、オーディオ・パケット及びビデオ・パケットを含み、前記FECパケットを送信するFECレートを前記増加させるステップは、前記FECオーディオ・パケットを送信するFECオーディオ・レート及び前記FECビデオ・パケットを送信するFECビデオ・レートの両方を増加させるステップを含み、前記FECオーディオ・レート及び前記FECビデオ・レートの両方を前記増加させるステップは、前記FECビデオ・レートの増加より2〜10倍で前記FECオーディオ・レートを増加させるステップを含む、請求項1の方法。

請求項10

前記1つ以上のフィードバック・レポートは、前記フィードバック・レポートの各々の生成間で所定の時間間隔を有する複数の定期的なフィードバック・レポートである、請求項1の方法。

請求項11

前記1つ以上のフィードバック・レポートは、前記フィードバック・レポートの各々の生成間で所定の時間間隔を有する複数の定期的なフィードバック・レポートであり、前記時間間隔は、100ミリ秒から1秒の間である、請求項1の方法。

請求項12

前記少なくとも1つの受信側デバイスは、複数の受信側デバイスである、請求項1の方法。

請求項13

前記信頼性の低いプロトコルは、コネクションレスである、請求項1の方法。

請求項14

前記許容レベル内として前記パケット損失を示す前記フィードバック・レポートの前記特定の1つは、前記フィードバック・レポートの前の1つに関して定常として前記パケット損失を示す、請求項1の方法。

請求項15

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

請求項16

前記少なくとも1つのメモリ・ユニットで具現化されるコンピュータ可読命令をさらに備え、前記命令は、前記コンピューティング・システムに前記方法を実行させるように、前記少なくとも1つのプロセッサ・ユニットにより実行可能である、請求項15のコンピューティング・システム。

請求項17

前記信頼性の低いプロトコルは、UDPである、請求項15のコンピューティング・システム。

請求項18

前記方法は、各前記データ・パケットにシーケンス番号を付けるステップをさらに備える、請求項15のコンピューティング・システム。

請求項19

前記方法は、各前記データ・パケットにシーケンス番号を付けるステップをさらに備え、前記少なくとも1つの受信側デバイスは、前記それぞれの期間中に前記データ・パケットを蓄積することにより、ならびに、前記それぞれの期間中に前記受信側デバイスにより受信した前記データ・パケットの前記シーケンス番号から、実際に受信した前記データ・パケットの数及び受信することを期待される前記データ・パケットの数を決定することにより、各前記フィードバック・レポートにおいて前記パケット損失を特徴付ける、請求項15のコンピューティング・システム。

請求項20

前記方法は、前記フィードバック・レポートの内の少なくとも1つにおいて、前記パケット損失を前記それぞれの期間中に転送されることを期待されるデータ・パケットの所定量に対して正規化するステップをさらに備える、請求項15のコンピューティング・システム。

請求項21

前記速度を前記調整するステップは、許容レベル外として前記パケット損失を特徴付ける前記フィードバック・レポートの内の特定の1つに応答して、前記データ・パケットを送信する合計速度を維持しながら、前記ソース・レートに対する前記FECレートの割合を増加させるステップをさらに備える、請求項15のコンピューティング・システム。

請求項22

前記データ・パケットは、オーディオ・パケット及びビデオ・パケットを含み、前記FECパケットを送信するFECレートを前記増加させるステップは、前記FECオーディオ・パケットを送信するFECオーディオ・レート及び前記FECビデオ・パケットを送信するFECビデオ・レートの両方を増加させるステップを含み、前記FECオーディオ・レート及び前記FECビデオ・レートの両方を前記増加させるステップは、前記FECビデオ・レートより大きい程度で前記FECオーディオ・レートを増加させるステップを含む、請求項15のコンピューティング・システム。

請求項23

前記データ・パケットは、オーディオ・パケット及びビデオ・パケットを含み、前記FECパケットを送信するFECレートを前記増加させるステップは、前記FECオーディオ・パケットを送信するFECオーディオ・レート及び前記FECビデオ・パケットを送信するFECビデオ・レートの両方を増加させるステップを含み、前記FECオーディオ・レート及び前記FECビデオ・レートの両方を前記増加させるステップは、前記FECビデオ・レートの増加より2〜10倍で前記FECオーディオ・レートを増加させるステップを含む、請求項15のコンピューティング・システム。

請求項24

前記1つ以上のフィードバック・レポートは、前記フィードバック・レポートの各々の生成間で所定の時間間隔を有する複数の定期的なフィードバック・レポートである、請求項15のコンピューティング・システム。

請求項25

前記1つ以上のフィードバック・レポートは、前記フィードバック・レポートの各々の生成間で所定の時間間隔を有する複数の定期的なフィードバック・レポートであり、前記時間間隔は、100ミリ秒から1秒間である、請求項15のコンピューティング・システム。

請求項26

前記少なくとも1つの受信側デバイスは、複数の受信側デバイスである、請求項15のコンピューティング・システム。

請求項27

前記信頼性の低いプロトコルは、コネクションレスである、請求項15のコンピューティング・システム。

請求項28

前記許容レベル内として前記パケット損失を示す前記フィードバック・レポートの前記特定の1つは、前記フィードバック・レポートの前の1つに関して定常として前記パケット損失を示す、請求項15のコンピューティング・システム。

請求項29

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

技術分野

0001

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

背景技術

0002

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

0003

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

0004

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

0005

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

0006

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

0007

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

発明が解決しようとする課題

0008

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

0009

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

課題を解決するための手段

0010

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

0011

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

0012

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

0013

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

図面の簡単な説明

0014

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

実施例

0015

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

0016

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

0017

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

0018

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

0019

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

0020

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

0021

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

0022

図1の実施例において、ソース・データ110の図示されたブロックは、複数のソース・パケット及びFECパケットを受信側デバイス104へネットワーク106経由で生成して伝送する、たとえば単一のA/Vフレームのような、単一のフレームに対応することができる。データ・ストリームは、複数のフレーム110で構成することができフレームは、送信側デバイス102で、ある順序で生成することができ、複数のデータ・パケット108は、受信側デバイス104への伝送用の各フレームのために形成することができる。

0023

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

0024

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

0025

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

0026

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

0027

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

0028

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

0029

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

0030

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

0031

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

0032

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

0033

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

0034

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

0035

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

0036

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

0037

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

0038

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

0039

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

0040

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

0041

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

0042

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

0043

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

0044

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

0045

限定としてではなく、例として、たとえばストリームの総ビットレートが2000kb/sであり、そのうちの100kb/sがFECパケットであり、ソース・パケットは1900kb/sとなるとする。帯域幅を検査するために、最初にFECレートを200kb/sへ増加させることができる。ここで、総帯域幅は、2100kb/sである。追加の損失がないと判定するときに、ソース・レートは、前のFECレート増加量だけ増加することができる。そこでソース・レートは、総レートは1900kb/s+100kb/s=2000kb/sとなり、(2000kb/sのソース)+(FECの100kb/s)=2100kb/sの合計であるが、帯域幅は、再びFECを200kb/sにすることで直ちに検査することができ得る。このようにして、2000kb/sのソース+200kb/sのFECがある。次の反復は、次の反復で2100kb/sのソース+200kb/sのFECであり得、次にパケット損失が提示されたデータに応答して増加するまで、2200kb/sのソース+200kb/sのFECなどが続く。

0046

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

0047

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

0048

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

0049

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

0050

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

0051

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

0052

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

0053

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

0054

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

0055

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

0056

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

0057

またシステム402及び404のいずれも、たとえば、バス476経由で、システムの他の構成要素と通信することができる、入力/出力(I/O)回路479、電源(P/S)480、クロック(CLK)481、及びキャッシュ482のような、周知のサポート回路478を含むことができる。システム402及び404のいずれも、ディスクドライブCD−ROMドライブ、テープ・ドライブ、フラッシュ・メモリ、または同様のもののようなマスストレージ・デバイス484を任意選択で含むことができ、マス・ストレージ・デバイス484は、プログラム及び/またはデータを格納することができる。またシステム402及び404のいずれも、表示ユニット486を任意選択で含むことができる。表示ユニット486は、陰極線管(CRT)、フラットパネルスクリーンタッチ・スクリーン、またはテキスト、数字グラフカルシンボル、もしくは他の視覚オブジェクトを表示する他のデバイスの形式であってもよい。システム402及び404のいずれも、システム402/404及びユーザの間のやりとりを促進するためのユーザ・インタフェース488をも含むことができる。ユーザ・インタフェース488は、キーボードマウスライトペン、ゲーム・コントロールパッド、タッチ・インタフェース、または他のデバイスを含むことができる。ユーザ・インタフェースは、スピーカ及び/またはマイクロフォンのような、オーディオI/Oデバイスをも含むことができる。

0058

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

0059

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

0060

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

ページトップへ

この技術を出願した法人

この技術を発明した人物

ページトップへ

関連する挑戦したい社会課題

関連する公募課題

ページトップへ

技術視点だけで見ていませんか?

この技術の活用可能性がある分野

分野別動向を把握したい方- 事業化視点で見る -

ページトップへ

おススメ サービス

おススメ astavisionコンテンツ

新着 最近 公開された関連が強い技術

  • 富士通株式会社の「 通信装置および通信方法」が 公開されました。( 2019/05/09)

    【課題】通信断しなくてもリンクの復旧を行うこと。【解決手段】通信部111は、可変の数のレーンを使用して第2の通信装置120へのデータ送信を行う。制御部112は、第1の数のレーンを使用するデータ送信から... 詳細

  • 日本放送協会の「 送信装置、受信装置、及びチップ」が 公開されました。( 2019/05/09)

    【課題】LDPC符号にビットインターリーブ処理を組み合わせて従来よりも誤り訂正能力を向上させる。【解決手段】送信装置30は、LDPC符号を生成するLDPC符号化部324a,324bと、LDPC符号に対... 詳細

  • 日本放送協会の「 送信装置、受信装置及びチップ」が 公開されました。( 2019/05/09)

    【課題】次世代の地上デジタル放送伝送方式においてQAMが適用された場合の適切なビットインターリーブ処理を規定する。【解決手段】本発明に係る送信装置1は、入力されたLDPC符号のLDPCパリティのみに対... 詳細

この 技術と関連性が強い技術

関連性が強い 技術一覧

この 技術と関連性が強い人物

関連性が強い人物一覧

この 技術と関連する社会課題

関連する挑戦したい社会課題一覧

この 技術と関連する公募課題

関連する公募課題一覧

astavision 新着記事

サイト情報について

本サービスは、国が公開している情報(公開特許公報、特許整理標準化データ等)を元に構成されています。出典元のデータには一部間違いやノイズがあり、情報の正確さについては保証致しかねます。また一時的に、各データの収録範囲や更新周期によって、一部の情報が正しく表示されないことがございます。当サイトの情報を元にした諸問題、不利益等について当方は何ら責任を負いかねることを予めご承知おきのほど宜しくお願い申し上げます。

主たる情報の出典

特許情報…特許整理標準化データ(XML編)、公開特許公報、特許公報、審決公報、Patent Map Guidance System データ