JP2016502794A - 通信ネットワークにおいてｔｃｐ及び他のネットワークプロトコルのパフォーマンスを向上させる方法及び装置 - Google Patents

Abstract

ＴＣＰ経路をセグメント化し、ネットワークを通じて独自プロトコル（ＤＰＲＴＭ）を実施することによって、データネットワークにおけるＴＣＰ（及び他のプロトコル）のパフォーマンスを向上させる方法及び装置である。ＤＰＲＴＭプロトコルは、クライアントからクラウドプロキシへのＴＣＰセッションの多重性のために多重化されたトンネルを提供する。ＤＰＲＴＭは、輻輳管理、フロー制御、信頼性、及びリンクモニタリングを実施する。他のネットワークプロトコル（ＵＤＰなど）が、送信信頼性を向上させるネットワーク符号化に基づいた信頼性プロトコルを用いてサポートされる。ネットワークにおいてプロセスを送信するネットワーク及び方法が開示され、ネットワーク符号化原理に基づいてパケットをエンコードする決定的係数が用いられる。ネットワーク符号化原理に基づいてパケットをエンコードするための決定的係数を使用する方法及び実装が開示される。決定的係数の使用は、失われたパケットを回復するために送信すべき余分な情報の必要性を低減させ、かなり低減されたオーバヘッドと増大されたパフォーマンス、セキュリティ及び信頼性とをもたらす。

Description

本発明は、概して、通信ネットワークに関する。より詳細には、本発明は、向上させた通信パフォーマンスを損失のあるリンクを通じて提供する。新しい消去符号化方法も開示される。

本願開示は、パケット送信装置、通信システム及びプログラムの態様を含む。

ワイヤレスチャネルを通じたデータ通信が、ますます一般的になってきている。例えば、ＷｉＦｉは、ＩＥＥＥ８０２．１１標準に基づいた接続のワイヤレス通信に使用される。他の多くのワイヤレスチャネルが使用されることもあり、いくつか例を挙げると、ＷｉＭＡＸ、３Ｇ、メッシュネットワーク又はコミュニティネットワークなどである。ワイヤレスチャネルは損失のあることがあり、したがって、データは様々な条件のうち任意の１つに起因して、送信の間、しばしば失われることがある。例えば、天候条件が、通信データの送信が害され得るようなものであることがある。同様にして、データ送信に対して様々な原因からの干渉があることがあり、例えば、同一チャネル上で送信している他のデバイスからの干渉である。有線通信チャネルもまた、ワイヤレスチャネルと同様にして損失のあることがある。有線チャネルの送信媒体は外部干渉の影響をより受けにくいが、有線ネットワークに配置されたアクティブなデバイスは有限のリソースを占有し、このことは、複数の、相互に関連しない送信元により圧倒された場合に、送信損失の一因となる。こうした要因のいずれかが、データパケット送信におけるさらなる損失又はデータパケット消去レートの増大の一因となることがある。

エンドツーエンドのトランスポートプロトコル（例えば、トランスミッションコントロールプロトコル（ＴＣＰ））において、データ通信は、相互接続されたネットワーク又はデバイスにわたって提供される。トランスミッションコントロールプロトコル（ＴＣＰ）は、通信ネットワークにおいて利用されて、信頼性、フロー制御及び輻輳制御のためのメカニズムを提供する。

こうしたトランスポートプロトコルにおいて、ＴＣＰはトランスポートプロトコルの一例であり、送信されるデータはパケットに分けられる。データパケットは受信器に送信され、受信器において、パケットは検証され、元のメッセージに再組み立てされる。肯定応答（ＡＣＫ）が受信器から返されて、データパケットが受信されたことを示す。ＡＣＫが返らない場合、データパケットは再送信されなければならないことがある。さらに、送信器が指定時間内にＡＣＫを受信しないとき、送信器におけるトランスポートプロトコルがタイムアウトすることがある。このことは、トランスポートプロトコルがＡＣＫの欠如をネットワークにおける輻輳として解釈するとき、パケットの送信レートの低減をもたらす。通信ネットワークは、定義上、実際は統計的であり、パケットは一般に、失われて「消去損失」を引き起こし、あるいは送信された順序とは異なって受信されて「異常配信」を引き起こす。ＴＣＰは、失われたパケットを再送信し、受信された異常パケットシーケンスを再配置し、送信レートを調節して、把握された輻輳損失を最小化することになる。

ＴＣＰは、送信レイテンシを最小化すること又はネットワークの「良好なスループット（good-put）」を最大化することよりも、信頼性のある送信に向けて最適化される。ＴＣＰは、有効な輻輳管理のためのアルゴリズムを包含するが、輻輳的な損失を最小化するためではなく（ＴＣＰ Ｔａｈｏｅ、Ｖｅｇａｓ及びＲｅｎｏなど）、エンドツーエンドの肯定応答を頼りにし、このことは、通信リンクのラウンドトリップタイムに基づいて最大送信レートを制限する。通信リンクのラウンドトリップタイムが、利用可能な帯域幅と直接の相互関係を有さないため、セッションの最大ＴＣＰ送信レートは、利用可能な通信帯域幅に結び付けられない。

データパケット損失が輻輳に起因しないとき（例えば、パケット損失は、パケット消去又は損失のあるワイヤレスリンクにおけるパケットの損失／衝突に起因する）、ＴＣＰパフォーマンスが、上記の損失を輻輳として解釈すること及びその輻輳回避メカニズムを呼び出すことによって、損害を被ることがある。こうした輻輳制御は、ＴＣＰにリンクキャパシティを過小評価させることがあり、このことは、輻輳ウィンドウの低減と利用可能キャパシティの過少利用とをもたらす。ＴＣＰは、ほんの１％の見逃し誤り率でも有する長いレイテンシチャネルで、実質的なパフォーマンス劣化に悩まされる。輻輳と非輻輳的損失とにおける混同は、他のトランスポートプロトコルについても同様に存在する。

こうして、その便益のすべてについて、ＴＣＰは、特にワイヤレスリンクにおいて、高いビット誤り率、パケット消去又は間欠的な接続性などの問題に起因して、パフォーマンス劣化などのいくつかの論点に悩まされる。さらに、データパケット消去及び損失は、ＴＣＰタイムアウトを通してパフォーマンスに悪影響を与えることがある。

損失及びレイテンシに関連する論点は、通信スタックにおける他のプロトコル、例えば、メディアストリーミング若しくはＶｏＩＰに統合されたＵＤＰ、又は任意のワイヤレスリンクレイヤ設計に影響する可能性がある。輻輳は、ネットワークにおいて、通信リンク又は経路上のトラフィックの量が該リンク又は経路のキャパシティを超えたときに生じることがある。こうした場合、過剰データは破棄されることがあり、あるいは、過剰データは輻輳が緩和されるまでバッファされることがある。しかしながら、輻輳が存続する場合、輻輳は、パケット交換ネットワークにおいて、バッファの中のデータパケットを破棄してバッファをクリアすることによって制御される。さらに、チャネル障害又は干渉が、信号雑音比（ＳＮＲ）劣化とビット誤りとをもたらすこともあり、上記劣化と誤りとが、同様に、パケット誤り又は消去をもたらすことがある。

ユーザデータグラムプロトコル（ＵＤＰ）は、通信ネットワークにおいて、遅延に基づく信頼性メカニズム（再送信）から恩恵を受けないリアルタイムアプリケーションに主に利用される。ＵＤＰは、通常、信頼性メカニズムなしの固定レート送信である。損失のある環境において、ＶｏＩＰ及びビデオなどのＵＤＰに基づく通信は、感知できるほどに劣化し、知覚できるくらいの忠実度の損失を引き起こす可能性がある。

近年、マルチメディアデータは、インターネットなどのベストエフォート型通信ネットワークを通してしばしば伝達される。このタイプのデータ伝送において、ダウンロード送信システム又はストリーム送信システムが使用される。

マルチメディアデータには、例えば、ビデオファイル、オーディオファイル、これらの組み合わせ、及びこれらを部分として含むデータを含むことができる。本願開示において、マルチメディアデータは、時間情報又は再生（play-out）順序に関する情報を含むデータの意味で使用される。

ダウンロード送信システムの場合、データファイルは、配信サーバから受信器における記録領域にダウンロードされ、伝送が完全に終了した時点において、その再生が開始される。したがって、ダウンロード送信システムは、再生に長時間かかるマルチメディアデータの再生やリアルタイム再生が必要とされるマルチメディアデータの再生に不向きである。

一方、ストリーミング送信システムの場合、データファイルの再生は、部分的なデータが送信器から受信器に伝送されるだけで開始される。ゆえに、これは、インターネット電話サービス、遠隔ビデオ会議開催、ビデオオンデマンドストリーミング、ネットワークカメラストリーミング、インターネットテレビ及び他のサービスに使用される。

ゆえに、輻輳に関連するとの損失の誤解釈に起因して、ワイヤレス通信ネットワークにおけるパフォーマンス損失の低減と損失のある通信チャネルにおけるトランスポートレイヤプロトコルパフォーマンスの強化とのための方法及びシステムの必要性が存在する。ビット又はパケット消去に対するネットワーク回復力を増大させる方法及びシステムの必要性もある。

Ａｈｌｓｗｅｄｅらにより２００３年に開示されたネットワーク符号化（ＮＣ）は、情報フローを向上させ、ネットワークにおいてより良好なパフォーマンスを届ける保証を示している。ネットワーク符号化において、ネットワークにおけるパケットフローは、代数的エンティティとみなされる。したがって、パケットは、送信器によって使用されて、余分な情報を含む線形式の組を形成して、送信において失われたパケットの受信器による回復を助けることができる。

Ｅｆｆｒｏｓらに対する米国特許第７，７０６，３６５号（２０１０年４月２７日）は、ランダム化された分散型ネットワーク符号化を開示している。上記特許は、ランダム化された符号化アプローチが提供されるところのネットワークにおいてプロセスを送信するネットワーク及び方法を開示している。ネットワークノードは、各々の外向けリンクにおいて、有限体から独立して及びランダムに選ばれる符号係数により規定される線形結合の到来信号を送信する。

Ｅｆｆｒｏｓらにおいて開示された方法は、経路決定に基づくアプローチを超えて有利である可能性があるが、ランダム化された符号化の使用は、バンド内の係数の送信に起因して、オーバヘッドとより大きいペイロードとを追加する。

ＴＣＰ又はＵＤＰなどのプロトコルを配置している損失のある通信インフラストラクチャにおいて、コンピュータオペレーティングシステムは、誤り訂正を用いて修正されて非常に有用でタイムリーなデータスループットを維持する必要がある。

発明者は、受信器又は送信器デバイスのオペレーティングシステム内で修正を必要としない、ＴＣＰなどの保証されたデータ送信プロトコルとＵＤＰなどの保証されないデータ送信プロトコルとの双方についての損失回復を提供するシステムを提案している。

本発明は、１）オペレーティングシステムネットワークスタックとユーザプログラミング空間との間の接続、２）保証されるデータ送信プロトコルを保証されないデータ送信プロトコルから分離する選択器、３）保証されるデータ送信プロトコルから保証されないデータ送信プロトコルの双方についてのネットワーク損失を補正する消去符号化方法、及び、４）標準のＵＤＰ／ＩＰプロトコルスタックを通じて情報を送信／受信する方法、を提供する。

本願開示は、配信されていないパケット（ＴＣＰ）の再送信システムと効率的に動作する消去符号化システムとをもたらす送信手法を提供する。

本発明のパケット送信システムは、ベストエフォート型ネットワークを通して、限られた到着期限を有し又は有さないことがあるパケットを送信する。本発明のパケット送信システムは、
ａ）配信されていないパケットの再送信を制御する自動パケット再送信部、
ｂ）各々が複数の生データパケットを運ぶ結合パケットを作成し、１又は複数のデータパケットのブロックに冗長データパケットを追加する消去符号化部、及び
ｃ）すでに受信した結合された冗長パケットからの配信されていないパケットの回復だけによって達成される受信器における誤り訂正後の損失レートが許容可能な損失レートを満たすように、監視されるネットワーク状態情報に基づいて必要な冗長度のレベルを動的に決定する冗長度決定部、を含む。上記システムは、好適な方法及び装置を含む。

限られた到着期限を有するデータブロック（ＵＤＰなど）を送信する方法が提供される。データブロックは、ある設定されたＮ個のパケットについてのデータウィンドウを包含する。上記方法は、損失推定値Ｍを設定するステップと、データウィンドウにおけるパケットの数を、ウィンドウサイズのＮに対応する第１の数のパケットＮ個に設定するステップと、Ｎ個のパケットを消去符号化して、各々が元のＮ個のパケットについての１つの線形結合を包含する一組のＭ個のパケットを作成するステップと、送信されるデータブロックがＮ個の元のパケットに続いて、各々がＮ個の元のパケットの線形結合を包含するＭ個のパケットを包含するように、データブロックを送信するステップと、を含む。

固定期限なしに保証される配信を有するパケットを送信する方法が提供される。データブロックは、複数のパケットのデータウィンドウを包含し、上記方法は、Ｍ個の消去回復パケットの最初の損失推定値を設定するステップと、データウィンドウにおけるパケットの数を、ウィンドウサイズのＮに対応する第１の数のパケットＮ個に設定するステップと、Ｎ個のパケットにわたって消去符号化して一組のＭ個の線形結合を作成するステップであり、上記Ｍ個の線形結合は、元のＮ個のパケットの線形結合である、ステップと、元のＮ個のパケットについての新しい線形結合を追加し、データブロックを送信するステップであり、データブロックは、Ｎ個の元のパケット＋Ｍ個の消去回復パケットを包含する、ステップと、受信したネットワーク状態情報とデータパケットブロックの送信レートとに基づいて冗長度の量を動的に決定して、受信器における誤り訂正後、失われたパケットの回復についての最初の損失推定値を調整し、更新された損失推定値に基づいて消去回復冗長パケットの数を再算定するステップと、Ｎ個の線形結合パケットと更新された数の冗長消去回復パケットとを含む第２のデータブロックを送信するステップと、を含み、データウィンドウのための先取的な（proactive）消去回復パケットの数が、推定されたパケット損失レートに基づく。

符号化パケットを生成する代替的方法の多くの他の例があり、該方法は、リードソロモン（ＲＳ）符号化、ＬＤＰＣ（低密度パリティ検査）符号化、ルビー変換（Luby transform）（ＬＴ）符号化、ラプタ（Raptor）符号化、ネットワーク符号化又は他のタイプの消去符号を含み、これらが使用されてもよい。

いずれにせよ、順序が問題でないため、ＦＥＣの「シーケンスを感知しない（sequence-agnostic）」性質が、パケットフローを再構築することに使用されてよい。さらに、トランスポートレイヤは、自身が損失を回復するためにさらなる符号化パケットを待つときでさえ、アプリケーションに順序正しいデータセグメントを配信することができる。

好適な実施形態が、カーネル空間の中のオペレーティングシステムネットワークスタックのカーネル空間からユーザ空間への情報データフローを接続するＴＵＮ、ＴＡＰ又はプロキシなどのコンストラクタ（constructor）を使用する。ＴＵＮ仮想デバイスは、ネットワークスタックのインターネットプロトコル（ＩＰ）レイヤからユーザ空間への接続を提供する。ＴＡＰ仮想デバイスは、ネットワークスタックのメディアアクセス制御（ＭＡＣ）レイヤからユーザ空間への接続を提供する。

好適な一実施形態に従い、追加される冗長性パケットの数は、ネットワークの輻輳を不必要に増加させ、あるいはデータパケットブロックの送信レートを不必要に低減させることなく、ネットワークの状態に従って最適化されることができる。ゆえに、受信器における誤り訂正後の損失レートは、所望される範囲内に保持されることができる。

第１のパケット送信装置が提供される。このパケット送信装置は、ベストエフォート型ネットワークを通して固定期限なしに保証される配信を有するパケットを送信する。上記パケット送信装置は、配信されていないパケットの再送信を制御する自動パケット再送信部と、冗長情報の送信を制御する消去符号化部と、監視されるネットワーク状態情報に基づいて損失のない接続を維持するために必要な冗長度のレベルを動的に決定する損失推定部と、を含む。ネットワーク状態情報は、パケット損失レートを含むであろう。損失推定部は、受信したネットワーク状態に基づいて損失のない接続を維持するために必要な冗長度のレベルを動的に決定するように構成される。複数の好適な実施形態において、ネットワーク状態情報は、ラウンドトリップタイム情報を含む。

第２のパケット送信装置が提供される。このパケット送信装置は、ベストエフォート型ネットワークを通して固定期限と共に保証された配信を有するパケットを送信する。パケット送信装置は、配信されていないパケットの再送信を制御する自動パケット再送信部と、冗長情報の送信を制御する消去符号化部と、監視されるネットワーク状態情報に基づいて損失のない接続を維持するために必要な冗長度のレベルを動的に決定する損失推定部と、を含む。ネットワーク状態情報は、パケット損失レートを含むであろう。損失推定部は、受信したネットワーク状態に基づいて損失のない接続を維持するために必要な冗長度のレベルを動的に決定するように構成される。複数の好適な実施形態において、ネットワーク状態情報は、ラウンドトリップタイム情報を含む。複数の好適な実施形態において、ネットワーク状態情報は、データ通信チャネルの受信端におけるパケット到着間（inter-arrival）時間情報も含む。

複数の好適な実施形態において、受信器における誤り訂正後、配信されていないパケットの再送信に関して指定された損失レートをもたらすために、受信したネットワーク状態情報と、データパケットブロック及び冗長パケットの送信に割り当てられる送信レートの上限値とに基づいて、システムは、データパケットブロックに追加すべき冗長パケットの数を、受信したネットワーク状態情報とデータパケットブロック及び上記数の冗長パケットの送信に割り当てられる送信レートの上限値とに基づいて動的に決定して、受信器における消去符号化を用いた配信されていないパケットの回復後、指定された損失レートをもたらす。

複数の好適な実施形態において、装置は、第１及び第２の双方のパケット送信装置を含んで、固定期限の有無にかかわらずデータトラフィックを扱うであろう。本発明方法は、ベストエフォート型ネットワークを通して到着期限の限られたパケットを送信するパケット送信装置において、下記の処理機能：
（ａ）配信されていないパケットの再送信を制御するパケット自動再送信機能のための制御メカニズム
（ｂ）冗長パケットをデータパケットブロックに追加するユーザ又はカーネル空間消去符号化機能
（ｃ）配信されていないパケットの冗長パケットからの回復だけで達成される受信器における誤り訂正後の損失レートが許容可能な損失レートを満たすように、監視されるネットワーク状態情報に基づいてデータパケットブロックに追加される冗長パケットの冗長度を動的に決定するユーザ又はカーネル空間冗長度決定機能、及び
（ｄ）カーネル空間からユーザ空間へネットワークスタック情報を接続する方法
を提供する。

好適な一実施形態に従い、冗長パケットの数は、ネットワークの状態に従って最適化されることができる。ゆえに、受信器における誤り訂正後の損失レートは、ネットワークの輻輳を不必要に増加させ、あるいはデータパケットの送信レートを不必要に低減させることなく、許容可能な範囲内に保持されることができる。

ＲＬＮＣが消去符号化の好適な一方法であるが、発明者は、パフォーマンスとオーバヘッド及びペイロードの考慮とのバランスをとる第２の消去符号化方法を見出している。

ネットワークにおいてソースノードから受信器ノードに符号化ノードを経由してデータパケットのブロックを送信する方法が開示され、この方法は、
（ａ）ソースノードから、ソースプロセスを送信するステップ
（ｂ）符号化ノードにおいて、受信器ノードによりソースノードから受信されるソースプロセスを、ソースプロセスのダウンストリーム受信を実施する目的で受信するステップ
（ｃ）ランダム性、不確定性又は多義性なしに予測可能シーケンス生成アルゴリズムを用いて符号化係数のベクトルを決定的に選ぶステップであり、入力信号の全体的な線形結合が係数のベクトルとして規定される、ステップ
（ｄ）ソースプロセスと符号化係数のベクトルとの線形結合を算定するステップ
（ｅ）ソースプロセスと符号化係数のベクトルとの線形結合を送信するステップ
（ｆ）受信ノードにおいて、ソースプロセス及び符号化係数の線形結合を受信するステップ
（ｇ）符号化係数のベクトルとソースプロセス及び符号化係数の線形結合とを用いてソースプロセスを再構築するステップであり、ネットワークを通して符号化係数のベクトルの送信がなく、１又は複数の受信器ノードがあり、受信器プロセスは、受信器ノードにおいて観察可能である、ステップ
を含む。

好適な一実施形態において、既知の関数が、上記符号化ノードから上記受信器ノードに送信され、符号化係数の上記ベクトルは、上記所定の関数を用いて上記符号化ノードにおいて及び上記受信器ノードにおいて算定される。好適な一実施形態において、複数の係数スキームを含むコードブックが、上記符号化ノード及び上記受信器ノードにおいて常駐し、上記係数スキームのうち１つについての指定が、上記符号化ノードから上記受信器ノードに送信され、符号化係数の上記ベクトルが、上記係数スキームのうち上記の指定された１つを用いて上記符号化ノードにおいて及び上記受信器ノードにおいて算定される。

新しい消去符号化方法が、非ランダムの、決定的な（予め決定された）態様において線形式の組の係数を生成する。第１の好適な実施形態における方法は、中間ノードを含むすべての通信ネットワーク参加者に知られたコードブックを利用する。生成関数又は「コードブック」のいずれかに関する情報は、新しいユーザがネットワークに加わるときに１回だけ提供される。したがって、係数は予測可能であり、送信の両端におけるコードブックの知識は、係数送信又は再生成のためのオーバヘッドを除去する。第２の好適な方法は、係数が情報の伝送に関わる各ノードとやりとりされる必要がないように、予め定義された多項式、例えば、階乗、フィボナッチ数列を使用する。

いずれかの好適な係数生成方法を用いて、各送信機会において、パケットの線形結合が、予め決定された組の係数を用いて送られる。ソース及びデスティネーションの双方が、使用されるシーケンスの事前知識を有するため、情報を端から端に送信するためにいかなる他のプロトコルも、すなわちヘッダも使用する必要がない。さらに、シーケンスを再使用することを合図する必要がなく、これは、あらゆる送信されるブロックの始めにおいて自動的に再開される。

好適な一実施形態において、消去符号化方法は、ネットワークと関連して使用され、このネットワークは、
ａ）１又は複数のソースノードであり、ソースプロセスがソースノードにおいて観察可能である、ソースノード、
ｂ）１又は複数の受信器ノードであり、受信器プロセスが受信器ノードにおいて観察可能である、受信器ノード、及び
ｃ）エンコードし又はデコードするための１又は複数の符号化ノードであり、ソースプロセスの各受信器ノードに対する通信を可能にし、符号化ノードは、符号化ノードに対する入力信号の通信のための入力リンクと符号化ノードから受信器ノードへの出力信号の通信のための出力リンクとに接続され、出力信号は入力信号の線形結合であり、線形結合の係数は予め決定される、符号化ノード
を含む。

好適な一実施形態において、ネットワークにおいて各信号に存在するソースプロセスの全体的な線形結合は、係数として規定され、各係数はソースプロセスに対応する。好適な一実施形態において、係数は、係数線形結合に適用することによって、各符号化ノードにおいて更新される。好適な一実施形態において、係数に適用される線形結合は、ネットワークを通して送信されるデータに適用される線形結合と同じである。

別の一実施形態において、一組の通信ノードを含むネットワークが開示され、これにおいて、各ノードは、情報のソース、情報の受信器、又は同時にソース及び受信器の双方であってよい。ネットワークの各ノードは、情報ユニットを形成し、ディスパッチして、ネットワークの他のノードと通信する能力があり、ネットワークの中の各ノードは、決定的線形ネットワーク符号化（Deterministic Linear Network Coding）（ＤＬＮＣ）機能エンティティであり、ここで、ネットワークの各ノード内のＤＬＮＣ機能は、こうしたノードによって部分的にあるいはその全体を生成され又は受信された情報にアクセスする能力がある。さらに、ネットワークの各ノード内のＤＬＮＣ機能は、異なるノード上の別のＤＬＮＣ機能との論理的通信リンクを確立する能力がある。各ノードにおけるＤＬＮＣ機能は、エンコード及びデコード機能性を持ち、ここで、ソースノードにおけるＤＬＮＣは、「コードブック」、又は係数生成プロセスからランダム性、不確定性及び多義性を除去する予測可能シーケンス生成器を用いることによって、一組の係数を生成する。ソースノードにおけるＤＬＮＣは、ソースノードにより生成された元の情報ユニットを係数を用いて線形結合することによって新しい情報ユニットを形成する。ここで、結果的な新しいエンコードされた情報ユニットは、ソースノードにおけるＤＬＮＣ機能によって、ネットワークの単一の又は多数の受信器ノードに伝えられる。

好適な一実施形態において、ネットワークは、非制限的なトポロジネットワークである。

好適な一実施形態において、生成される係数の組は、有限体に属する。

好適な一実施形態において、一アルゴリズムがネットワークにおいて使用されて、順序付けられたリストにおいて元の行ベクトルを１ポジションずつシフトすることによって係数を係数の行ベクトルにおいて１ポジションずつ回転すること及び必要とされるとおりに余分な係数を生成することに基づいて、ＮｘＮ符号化行列を生成する。

好適な一実施形態において、一アルゴリズムがネットワークにおいて使用されて、追加的に生成される線形式の線形独立性を確保するように一組の係数を再順序付けする。

好適な一実施形態において、リンクの両端が初期化されて、シーケンスを予め決定することと受信器に上記選択を制御パケットヘッダの中のフィールドによって知らせることとにおける適切なオペレーションを確保する。ＤＬＮＣは、柔軟性及び低オーバヘッドを含む利点を提供する。

さらなる特徴及び利点が本明細書に説明され、下記の詳細な説明及び図から明らかになるであろう。

本発明及びその利点のより完全な理解は、下記の説明を添付の図面を考慮して参照することによって得られるであろう。図面において、同様の参照番号は同様の特徴を示す。
出願人のパケット回復プロトコルを用いたシステムの好適な実施形態を示す。 図１に示されるタイプのトランシーバのペアを用いて実施される出願人のパケット回復プロトコルを用いたデータ通信システムの好適な実施形態を示す。 図１の装置において実施することができる本発明方法の好適な実施形態を示す。 本発明の別の送信スキームを示す。 図１の装置において実施することができる本発明方法の別の実施形態を示す。 図３のデータ送信方法論と関連して実施することができるデータ受信方法論の別の実施形態を示す。 消去符号化モジュールの構成要素の概略図である。 消去符号化モジュールの別の実施形態の構成要素の概略図である。 クライアント側実装のブロック図である。 クラウドプロキシ実装のブロック図である。 透過モード実装におけるＴＣＰスプーファについての接続確立状態機械の状態図である。 透過モード実装におけるＴＣＰスプーファについての接続クローズ状態機械の状態図である。 図１乃至図４に示されるＤＰＲプロトコルと関連して使用することができるランダム線形ネットワーク符号化を用いた好適なネットワーク符号化エンコード演算を示す。 図１乃至図４に示されるＤＰＲプロトコルと関連して使用することができる一組の線形式を解くランダム線形ネットワーク符号化を用いたネットワーク符号化デコード演算を示す。 図１乃至図４に示されるＤＰＲプロトコルと関連して使用することができるランダム線形ネットワーク符号化を用いたフルの係数送信でのネットワーク符号化パケットフォーマットを示す。 図１乃至図４に示されるＤＰＲプロトコルと関連して使用することができる本発明のネットワーク符号化パケットフォーマットの一実施形態の概略図である。 ＲＬＮＣ対ＤＬＮＣのＤＰＲプロトコルオーバヘッド比較を示すグラフである。 ＤＬＮＣ消去符号化を用いたＤＰＲ接続をセットアップする接続シーケンスの図式的概観を示す。

本発明は、ＴＣＰ及びＵＤＰなどの別のトランスポートプロトコルのいくつかの技術的欠点を改良し、送信品質とネットワークの良好なスループットとを向上させる独自プロトコルを用いて、ＵＤＰのカプセル化された通信トンネルを提供する。好ましくは、ＴＣＰ実装は、通信スタックにおけるＴＣＰレイヤにより見られるものとしてかなり短い有効なＲＴＴを作り出し、ゆえにＴＣＰのうちその輻輳管理メカニズムに主に関連付けられる非効率性を改善させることによって、より大きい達成可能な最大帯域幅とより小さいレイテンシとを提供する。ＴＣＰトラフィックは、消去符号化モジュールによって処理され、消去符号化モジュールは、消去保護に加えて、接続管理、信頼性、輻輳制御、フロー制御及び多重化をさらに提供する。消去符号化モジュールを介して通信チャネルを通じてサポートされるカスタムプロトコルは、本願開示において、動的パケット回復（Dynamic Packet Recovery）（ＤＰＲ^ＴＭ）と呼ばれる。ＵＤＰ実装は、信頼性サポート及び輻輳回避メカニズムを包含する。

図１を参照すると、本発明に従い構築された送信トランシーバ１が示され、送信トランシーバ１は、例えば、図２におけるトランシーバ１ａなどの受信トランシーバとの二重通信を可能にする。トランシーバ１は選択器２を含み、選択器２は、インターネットなどのデジタルチャネルを通じて送信すべき連続的なパケットストリームを含む入力を受信する。パケットストリームは、一連のデータパケットを含む。こうしたデータパケットが選択器２によって受信され、選択器２は、消去符号化（erasure coding）に必要な時間に適応するように調整された任意的な最小レイテンシ間隔後、下記に説明されるとおり、所定数のパケットＮを含む最初のブロックのデータパケットを、デジタルチャネルを通じた送信のために送信器３に渡す。

本発明の好適な実施形態に従い、Ｎ個のデータパケットのブロックが、送信トランシーバから受信トランシーバに送られる。上記システムは、いくつかの符号化されたパケット（符号化パケット）も送信する。概して、Ｎ個のデータパケットは、送信される特定のブロックの中のすべての情報を包含し、それから、上記ブロックの全体が、任意の所与のセグメントの間に送信すべきトータル情報を全体で表し、上記セグメントは、例えばインターネットに接続されたあるポイントから別のポイントに移動すべき音楽トラック、ビデオ、文書、画像又は他のアイテムを表し得る。

データパケットのブロックの中のすべてのデータパケットが受信トランシーバにおいて損失なく受信された場合、明らかに、さらなる方策を採用する必要性がない。しかしながら、通常、１又は複数のデータパケットが、特定の送信サイクルの間に失われる可能性が高い。

ゆえに、本発明に従う消去符号化の適用に従い、さらなる符号化パケットが、Ｎ個の生（raw）データパケットと連動して送信される。符号化パケットは、使用される特定の消去符号化方法のエンコードアルゴリズムに従い、送信すべきＮ個の生データパケットから生成されるパケットである。したがって、データ通信チャネルの送信側において、Ｎ個のデータパケットのブロックがエンコードアルゴリズムに入力され、エンコードアルゴリズムは所望数の符号化パケットを生成する。

データ通信チャネルの受信側における受信トランシーバにおいて、受信した生データパケットと受信した符号化パケットとは、符号化方法が使用された場合、デコードアルゴリズムに入力される。それから、このアルゴリズムは、Ｎ個の生データパケットの送信の間に失われた元の生データパケットの再構築を出力する。それから、受信トランシーバにより受信された、受信した生データパケットＮ_ｒが、送信トランシーバにより送信されたＮ個の生データパケットの元のストリームの忠実な複製を組み立てるように、デコードアルゴリズムにより生成された、再構築したデータパケットＮ_ａとインタリーブされる。

消去符号化の形態における前方誤り訂正は、図１に示されるとおり、生パケットＮの最初のブロックをトランシーバのメモリ４に記憶することによって容易にされる。消去符号化はエンコーダ５によって実施され、エンコーダ５はＭ_０個の符号化パケットを生成する。Ｍ_０は、データパケットと連動して送るべき符号化パケットの最初の数であり、Ｍのデフォルト値に等しい。このＭ_０は任意であってよいが、好ましくは、予期される品質障害又は予期される送信チャネルのありそうな脆弱性の範囲に基づいて設定される。符号化パケットは、使用される特定の消去符号化スキームによって回復されるパケットに関連して、失われたパケットの置換を可能にするように生成される。下記で参照されるタイプの消去符号化方法論を用いて、符号化パケットは、失われたパケットを生成するために使用される。

リードソロモンエンコードなどの他の前方誤り訂正スキームが本発明に従い使用されてもよいことにも留意されたい。他の適切な消去符号化スキームが、当分野において周知であり、本発明に採用されてよい。

図１のシステムを用いたあり得る適用において、生パケットの数Ｎは、例えば、１００であってよい。こうした適用において、通常、チャネルにおける９８％の信頼度のレベルに直面することがある。これは、２個の符号化パケット（Ｍ＝２）を１００個のデータパケットと共に送信することによって、１００個すべてのデータパケットの成功裏の送信をおそらく提供するであろう。２個の符号化パケットの各々はエンコーダ５によって生成され、送信すべき合計１０２個のパケットをもたらす。しかしながら、信頼性のある受信の側における誤りに対して、（送信が始まるときに採用される）Ｍ_０のデフォルト値は、比較的高く、例えば５個の符号化パケットに設定されてよく、これは、５％（Ｍ／Ｎ）の損失に対応する。

このデフォルト値はエンコーダ５によって使用され、エンコーダ５は５個の符号化パケットを生成し、この５個の符号化パケットは送信器３に出力される。本発明の好適な実施形態に従い、５個の符号化パケットが任意的な最小レイテンシ遅延を用いてエンコーダ５によって生成されると、送信器３による１００個のデータパケットの送信に続いて、上記の５個の符号化パケットが送信器３を介して送信される。ゆえに、システムは、１００個のデータパケットと５個の符号化パケットとを含む１０５個のパケットを送信している。

デジタルチャネル、例えばＴＣＰ／ＩＰチャネルの性質は、良好な使用可能なデータパケットだけが受信されるというものである。したがって、誤りは、消失パケットの形をとる。１００個のデータパケットの送信ラインの受信端において、受信したすべてのデータパケットが数えられ、デジタル通信チャネルの他端において受信したデータパケットの数は、トランシーバ１の受信器部分６に返信される。この情報は、例えば、コンピューティングデバイス７に送られ、コンピューティングデバイス７は、１００個すべてのデータパケットの送信が成功する可能性が非常に高い状態にするために必要な符号化パケットの数Ｍの推定を決定するようにプログラムされる。この情報は、さらに十分に下記に現れるとおり、２つの目的に使用される。第１は、Ｍの改訂値Ｍ_１を提供することである。次のブロックのデータパケットの送信の間、Ｍ_１が使用され、デフォルト値のＭ_０は破棄される。第２に、この情報は、すべてのデータパケットが受信されていない場合、どれほど多くの追加パケットがパケットのブロックを成功裏に送信するために必要とされるのかをシステムに教える。さらに十分に下記に現れるとおり、上記の追加パケットは、システムが次のブロックのデータパケットに進む前に、システムによって送信される。上記の追加符号化パケットの各々はすべて、符号化パケットの最初の組の中の符号化パケットの各々とは異なることにも留意されたい。このことは、十分な種々の符号化パケットが、失われたデータパケットを再構築するために受信トランシーバにおいて利用可能であることを確保する。

上記のパケット損失情報を取得し、これを使用してＭ_０の値（又は、Ｍの任意の後続値）が増加されるべきか、減少されるべきか、あるいは変更されないままとされるべきかを判定するために、様々なアルゴリズムが使用されてよい。本発明に従い、Ｍの値の再推定とその値の可能な調整とが、データパケットの各ブロックの送信に関連して行われる。このことは、下記の例から理解することができる。

例えば、最初のシステム設定がブロック＝１００及びＭ_０＝５であり、１００個すべてのデータパケットが成功裏に受信されたと仮定する場合、デジタル通信チャネルの予期される品質を考慮すると、コンピューティングデバイス７は、Ｍの値を５（Ｍ_０）から４（Ｍ_１）に低減してよい。ゆえに、次の周回において、１００個のデータパケットの第２のブロックとエンコーダ５により消去符号化によって生成された４個の符号化パケットとが送信されることになる。

コンピューティングデバイス７に常駐するアルゴリズムに従い、選択器２に入力される連続的なデータパケットストリームからの継続的なデータのブロックにおける１００個すべてのデータパケットの継続的な成功裏の送信が、Ｍが例えば２に到達するまで、数Ｍの継続的な低減をもたらしてよい。上記例は、例えば、送信器部分３によりアクセスされるデジタル通信チャネルの特性がよく知られており、１個の符号化パケットだけでブロックを成功裏に送信する品質にしばしばなるとは予期されない場合である。通信チャネルが、より良好な信頼性が時折生じることがあるものである場合、コンピューティングデバイス７は、所与のブロックの中の１００個のデータパケットを成功裏に送信することの度重なる失敗があるまで、Ｍを１に低減し、Ｍをその値において保持することによってチャネルを周期的にテストするようにプログラムされてよい。このようなものとして、度重なる失敗は、これを引き起こし得る様々な要因のいずれか、例えば輻輳、天候などに起因した、通信チャネルにおけるより長い期間の劣化を示すであろう。

同様にして、同じ方法論を用いて、コンピューティングデバイス７は、Ｍを増加させ、Ｍ_１を６、７若しくはより大きい値に等しくし、これを延長された時間の間そこで保持し、再度、チャネルを周期的にテストしてチャネル信頼性が増しているかを判定することによって、低減された通信チャネルパフォーマンス、例えば、通信チャネルの他端におけるリモートトランシーバからの、９４個のデータパケットだけが受信されたという報告を受け入れてもよい。受信器６が、あらゆる送信について、連続的なパケットストリームの中で１００個より少ないデータパケットが選択器２に入力されたときを示すことになるため、当然ながら、非信頼性を判定するためのチャネルのテストは必要とされない。

本発明に従い、受信したデータパケットの数は、送信器３により利用されるデジタル通信チャネルの他端において数えられ、この情報は、通信チャネルを通じて受信器６に送られ、受信器６は、この情報をコンピューティングデバイス７に送る。

同様にして、トランシーバ１の受信側を考えると、トランシーバ１は、さらに、通信チャネルの他端におけるリモートポイントから上記と同様の態様で送信されたデータを受信するため、デコーダ８が、リモート送信ポイントから受信器６が受信した良好なデータパケットの数を数えるように提供される。それから、さらに十分に下記に現れるとおり、受信したデータパケットの数は、デコーダ８によって送信器３に伝えられ、送信器３は、この情報を、送信器３及び受信器６により使用される例えば全二重デジタル通信チャネルの他端におけるリモート送信ポイントにおけるリモートトランシーバに送る。

本発明は、双方の通信トランシーバにより送信される情報において完全な対称性があり、あるいはデータ負荷がかなり非対称であるシステムに適用されてよいことに留意されたい。

本明細書において言及されるとおり、エンコーダ５は、消去符号化を実施する。デコーダ８は、データパケットとエンコーダ５により生成されたタイプの符号化パケットとを受信し、消失データパケットの内容について解決するようにプログラムされる。開示される実施形態に従い、エンコーダ５と同一の特性を有するエンコーダが、全二重通信チャネルの他端において、トランシーバ１と二重通信するリモートトランシーバの中に位置することが考えられる。

二重デジタル通信チャネルの他端においてリモートトランシーバから受信した、成功裏に送信されたデータパケットは、デコーダ８によって検出され、メモリ９に送られる。デコーダ８は、データパケットの完全なブロックが受信されたと判定したとき、この情報をメモリ９に伝える。メモリ９はこの情報を、メモリの中の別の、場合によりさらに永続的な場所に、あるいは下流のデバイスにダウンロードするように指示されてよい。

送信方法論に戻ると、上記に示唆されたとおり、時折、ことにより頻繁に、選択器２に入力される連続的なパケットストリームからの１００個のデータパケットの特定のブロックにおける１００個未満のデータパケットが受信されることになる。このことが生じたとき、従来技術、例えばＵＤＰシステムとは対照的に、データパケットは再送信されない。ＴＣＰシステムにおいては、生データパケットが再送信される。

むしろ、本発明に従い、消失データパケットの数が受信器６からコンピューティングデバイス７に伝えられ、追加の時間、データパケットを送信することに代わって、符号化パケットが送信される。同様にして、必要とされる場合、消失パケットを再生成するために符号化パケットが送信される。

失われたパケットの数がＭ_０より大きい場合、最初の損失推定値Ｍ_０と消失パケットの実際の数Ｍ_１とにおけるデルタが算定される。Ｍ_１−Ｍ_０個の追加の符号化パケットを生成するようにメッセージがエンコーダに送られ、したがって、消失パケットのすべてが再生成されることができる。

上記に示唆されたとおり、多数のデータパケットがチャネルの他端において消失している場合、Ｍは、デフォルト推定の５から、比較的大きい数に変更されるであろう。例えば、Ｍ_０が５に最初設定され、８個のデータパケットが消失したと判定された場合、最低でも、３個のさらなる符号化パケットを送信することが必要であり、ゆえに、最初の例において、合計８個の符号化パケットを作ることになるであろう。こうした例において、Ｍ_１は、８に設定されるであろうし、エンコーダ５により生成されるであろう追加の３個の符号化パケットが送信される。

しかしながら、上記システムは、最初、過度に補償していることがあり、例えば、Ｍを１２に設定し、７個の追加の符号化パケットを送信することがある。消去符号化スキームに従い、消失データパケットを生成するために、追加の符号化パケットと元の符号化パケットとは、対象ブロックの１００個のデータパケットからの成功裏に送信され及び受信されたデータパケットと一緒に使用されるであろう。

消去符号化スキームに従い、消失データパケットを生成し、必要な１００個のデータパケットをデコーダ８から記憶装置９に再作成するために、受信した生パケットと受信した消去符号化されたパケット（消去符号化パケット）（erasure coded packets）とが一緒に使用されるであろう。上記必要な１００個のデータパケットは、元のデータパケットと符号化パケットとのいくつかの部分の組み合わせである。

この態様において、大きいブロックのデータパケットの再送信は複数回回避される。

先へ進めると、Ｍ_１は現在、新しい損失推定値である。上記の例において、Ｍ_１は８であった。Ｍ_ｎは、次の組のパケットのための損失推定値がＭ_ｎの最新値に基づくように調整され続ける。

損失レート値Ｍの連続的な調整は好適な実施形態であるが、Ｍの最初の値とＭの値の調整とはユーザ必要性に従って変えられてよいことが理解される。所望される場合、最初の損失推定はゼロパケットに設定されてよく、したがって、最初の損失推定は、パケット損失があるまで設定されない。

符号化パケットは成功裏に受信されないことがあり、それから、置換符号化パケットを生成し、送信することが必要になることにさらに留意されたい。置換符号化パケットの生成は、使用される特定の前方誤り訂正又は消去符号化スキームによって決定される。したがって、デコーダ８は、二重通信チャネルの他端におけるトランシーバの部分によって受信器６に提供される情報に基づいて、データパケット又は符号化パケットが失われているかを判定するように機能し、上記トランシーバの部分は、デコーダ８の機能を実行している。

図２を参照すると、トランシーバ１とリモートトランシーバ１ａとを含むデータ通信システムが示されている。トランシーバ１ａは、トランシーバ１と実質的に同一である。トランシーバ１ａは、選択器２ａ、送信器３ａ、メモリ４ａ、エンコーダ５ａ、受信器６ａ、コンピューティングデバイス７ａ、デコーダ８ａ及びメモリ９ａを含み、これらはそれぞれ、トランシーバ１における選択器２、送信器３、メモリ４、エンコーダ５、受信器６、コンピューティングデバイス７、デコーダ８及びメモリ９の態様において動作し、互いに協働する。トランシーバ１とトランシーバ１ａとは、トランシーバ１により送信される信号を受信するトランシーバ１ａとトランシーバ１ａにより送信される信号を受信するトランシーバ１とで示されるとおり、デジタルチャネルを通じて互いに結合される。

図３を参照すると、本発明方法１０が、汎用目的コンピュータ上のソフトウェアとして実施することができる処理ステップの観点から理解されるであろう。システムへの入力は、各々Ｎ個のデータパケットのウィンドウに形作られることができるデータパケットの連続的なシーケンスである。これらＮ個のデータパケットが、方法１０を実施するシステムにおいて、ステップ１２において受信される。本発明に従い、これらＮ個のデータパケットは、デジタルデータ通信チャネルを通じてリモートポイントに送信される。

本発明方法が開始されると、本発明方法を実施するシステムは、Ｎ個のデータパケットのうちＭ_０個のデータパケットが失われることになると仮定するデフォルト損失推定を最初採用する。Ｍは、ゼロ、又は３若しくは５などのより大きい整数で表されてよく、あるいは、パケットのブロックのパーセンタイル部分として規定され、ソフトウェアによりパケットの数を算定した後に整数に丸められてもよい。ステップ１４において、この推定は、採用される消去符号化アルゴリズムのエンコードアルゴリズムに提供される。より具体的に、ステップ１６において、特定の消去符号化スキームに関連付けられた消去符号化アルゴリズムをプログラムされたコンピューティングデバイスが、符号化パケットを生成するように実施され、この符号化パケットは、受信トランシーバにおいて、失われたパケットを再構築する機能を実行するために使用されてよい。より具体的に、好適な実施形態に従い、受信したデータパケットと関連する符号化パケットとは、失われたデータパケットを生成するために、受信トランシーバにおいてデコードアルゴリズムに入力される。ステップ１６において、消去符号化が、選択された消去符号化スキームに従い実行され、符号化パケットの生成をもたらす。この符号化パケットは、十分な符号化パケットとデータパケットとが受信されていて上記の再構築を可能にするならば、送信の間に失われた任意のデータパケットを再構築することに使用されてよい。

符号化パケットが生成されているとき、ステップ１８において、データパケットは、一時記憶のために一時メモリセクタに伝送される。Ｎ個のデータパケットのブロックのコピーが、好ましくはステップ１９において記憶される。パケット損失が、送信されるデータを受信するリモートトランシーバにおける消去符号化デコードアルゴリズムによってすべての失われたパケットを回復させるのに十分な失われたパケットの数を超える事象において、将来使用されてよい。同様にして、ステップ１６において生成された符号化パケットは、ステップ２０において、同様に一時記憶のために一時メモリセクタに伝送される。データパケットと符号化パケットとは、ステップ２２において、一時メモリからダウンロードされ、ステップ２４において、受信のリモートポイントにおける受信トランシーバにすべて送信される。好適な実施形態に従い、データパケットと符号化パケットとがステップ２４において送信されるとき、各々のデータパケットと符号化パケットとは、それ自体がデータパケットであるか、あるいは符号化パケットであるかを示す識別子を有する。

ステップ２６において、トランシーバは、Ｎ個のデータパケットのうちいくつが失われたか（Ｎ_Ｌ）を示す報告を受信する。

下記に論じられるとおり、Ｎ_ＲがＮより小さい場合、いくつかの補足的な符号化パケットＰ_Ｓを送信することが必要であり、ここで、Ｐ_Ｓは、式：
Ｐ_Ｓ＝Ｎ_Ｌ−Ｍ_０
によって定義される。

本発明に従い、補足的なパケットＰ_Ｓの合計数は、失われたパケットがデータパケットであるか、あるいは符号化パケットであるかにかかわらず、失われたパケットの合計数によって決定されることに留意されたい。しかしながら、損失がデータパケットであるか、符号化パケットであるか、あるいはデータパケットと符号化パケットとの組み合わせであるかにかかわらず、符号化パケットだけがリモートトランシーバに送信される。それから、受信トランシーバに関連付けられ、使用される特定の消去符号化スキームのためのデコードアルゴリズムを備えたコンピューティングデバイスが、受信したデータパケットと必要数の符号化パケットとを取得し、デコードアルゴリズムを実行して、受信されなかったデータパケットを再構築する。デコードアルゴリズムは、受信したデータパケットと受信した符号化パケットとを処理することによって、失われたデータパケットの情報内容を算定する。

図３に示されるデータ通信送信方法論に戻ると、ステップ２８において、失われたパケットの数を伝える報告が送信トランシーバによって受信され、さらなる符号化パケットが必要とされるかについて、判断が行われる。より具体的に、すべてのデータパケットとすべての符号化パケットとが受信されている場合（あるいは、リモートトランシーバが、失われたデータパケットを再構築するほど十分なデータパケットと符号化パケットとを受信している場合）、システムはステップ３０に進み、ここで、Ｍは、パケット損失の履歴と場合により送信チャネル特性とを考慮して推定され、更新される。上記に示唆されたとおり、Ｍは、増加し、減少し、あるいは同じままであってよい。Ｍの新しい値Ｍ_ｊがステップ３０において算定され、ステップ３２において、Ｍのいかなる以前の値もが、Ｍの新しい値で置換される。

それから、システムはステップ３４に進み、ステップ３４において、次のブロックのＮ個のパケットがシステムに入力される。ステップ１６において、上記次のブロックのＮ個のパケットは、（ステップ３２において更新されたとおりの）いくつかの符号化パケットＭ_ｊを生成するために、エンコード消去符号アルゴリズムを用いて処理され、上記符号化パケットは、次の組の符号化パケットを構成する。それから、次の組の符号化パケットと次のブロックのＮ個のパケットとが、上記で説明された方法論に従い送信される。

しかしながら、判断ステップ２８において、すべてのデータパケットを再構築するほど十分なデータパケットと符号化パケットとがリモートトランシーバによって全体的に受信されていない場合、追加の符号化パケットがリモートトランシーバに送られる必要がある。したがって、システムはステップ３６に進み、ステップ３６において、必要数の置換データパケット（ステップ２６の報告に基づく）が生成される。補足的な符号化パケットは、ステップ１９において記憶された元の生データパケットを用いて生成される。補足的な符号化パケットはすべて、現在のデータパケットブロックに関連付けられた以前の符号化パケットから異なる。置換データパケットの数は、受信したデータパケットから失われたデータを再構築するために必要とされる符号化パケットの数に等しい。好適な実施形態に従い、符号化パケットの数が、失われたデータパケットの数に等しく、あるいはより大きくなければならない消去符号化スキームが使用される。

上記に示唆されたとおり、失われたパケットＰ_Ｌの数がＭの以前の推定値（Ｍ_{ｐｒｅｖｉｏｕｓ}）より大きい場合、いくつかの補足的な符号化パケットＰ_Ｓを送信することが必要であり、ここで、Ｐ_Ｓは、式：
Ｐ_Ｓ＝Ｐ_Ｌ−Ｍ_{ｐｒｅｖｉｏｕｓ}
によって定義される。

したがって、システムはステップ３０に戻り、ステップ３０において、システムはＭの推定値をＭ＋Ｐ_Ｓに増加させる。

システムはステップ３８にも進み、ステップ３８において、ステップ３６において生成された補足的な符号化パケットがリモートトランシーバに送信される。それから、システムは、リモートトランシーバから、パケットが成功裏に受信されたかを示す報告を受信し、それから、判断ステップ２８において同じことを判定した後、システムは、現在のブロックのＮ個のパケットがすべて十分に受信され、あるいは再構築されるまで、上記で説明されたとおりに進む。この条件が合ったとき、システムはステップ３４に進み、ステップ３４において、システムは、上記で説明されたとおり、次のブロックのＮ個のデータパケットに進む。

システムは、送信すべきデータパケットシーケンスの中のすべてのデータパケットが送信されて、成功裏に受信され、あるいは再構築されるまで、上記で説明されたとおり、Ｎ個のデータパケットの継続的なブロックを送り続ける。

図３ａを参照すると、本発明に係る方法に従う別の送信スキーム（これは、本明細書に説明される他の方法と同様に、汎用目的コンピュータ上で実行されるソフトウェアにおいて具現化される）が、示されている。ステップ５０において、システムは、個々のパケット、例えば、連続的なパケットストリームの中の最初のパケット又は後続のパケットを受信する。ステップ５２において、ステップ５０において受信されたパケットが記憶される。ステップ５４において、記憶されたパケットはリモートトランシーバに送信され、カプセル化もされる。上記カプセル化は、例えば、消去符号化スキームのエンコードアルゴリズムに入力されることによってなされ、任意の失われたパケットを再構築するために使用すべきカプセル化された生パケット又はカプセル化された冗長符号化パケットの生成に後に使用される。

ステップ５６において、システムは、ブロックの中のＮ個のパケットすべてが入力され、記憶され、送信され、カプセル化されたかを判定する。上記が当てはまる場合、Ｎ個のデータパケットの完全なブロックがシステムに入力されており、符号化パケットの生成が始まってよい。

しかしながら、ステップ５６において、Ｎ個のパケットすべてが受信されていない場合、システムは、ステップ５０に戻り、次のパケットを受信し、Ｎ個のデータパケットの完全なブロックがシステムに入力されるまで上記シーケンスを繰り返す。

Ｎ個のデータパケットの完全なブロックがシステムに入力されると、システムはステップ５８に進む。ステップ５８において、好適な消去符号化アルゴリズムに従い、システムは、Ｎ個の元のデータパケットの内容を直線的に結合することよって、結合（「符号化」ともいう）パケットを生成する。ステップ６０において、ステップ５８において生成された結合パケットが送信され、システムはステップ６２に進み、ステップ６２において、Ｍのデフォルト値が、単一ブロックのデータパケットに対して予期される数のパケット損失に同等に、あるいはより大きく設定される。それから、ステップ６４において、システムは、Ｍ個の符号化パケットすべてが生成され、送信されたかを判定する。すべてのＭ個のデータパケットがステップ６４において設定されていない場合、システムはステップ５８に進み、ステップ５８において、別の符号化パケットが、リモートトランシーバに対する送信のために計算される。

Ｍ個のデータパケットが生成されている場合、十分な情報が受信トランシーバによって受信されていることが合理的に明白である。しかしながら、ステップ６６において、システムは、システムにより送信されたＮ個のデータパケットすべての再構築を可能にするほど十分な数のパケットが受信されているというリモート受信トランシーバからの報告を待つことによって、信頼性を提供する。受信されているパケットの数Ｋが、送られた生パケットの数Ｎより小さい場合、Ｎ個の元のデータパケットのすべてを再構築するほど十分なパケットが受信トランシーバになく、上記Ｎ個の元のデータパケットは、送信の間に失われている可能性がある。したがって、システムはステップ７０に進み、ステップ７０において、Ｍがより大きい数、例えばＭの元の値プラス１に更新される（１個の結合パケット又は符号化パケットだけが失われたデータパケットを生成するために必要である場合であり、あるいは、必要とされる場合、より大きい数による）。例えば、５個の追加の符号化パケットが必要とされる場合、Ｍは５まで増加されてよい。ゆえに、Ｍは、Ｍ＋（Ｎ−Ｋ）に等しい値に更新されてよい。

使用されているデジタルチャネルについて経験した十分でない送信特性を反映するようにＭの値を設定することに加えて、失われたデータパケットを再構築するほど十分な数の符号化（すなわち、結合された）パケットを生成し、送信することが必要である。このことは、システムがステップ５８に戻ることによって行われ、ステップ５８において、追加の符号化パケットが生成され、それから送信され、上記追加の符号化パケットが受信された場合、受信トランシーバによってその受信を確認される。

ステップ６８において、受信トランシーバにより受信されたパケットの合計数がＮより少なくない場合、すべての消失データパケットを再構築するほど十分な数のパケットが受信されており、システムはステップ５０に進んでよく、ステップ５０において、次のブロックのデータパケット送信が、上記で詳述されたとおりに進む。このことは、送信におけるすべてのブロックのデータパケットとそのすべての組成データパケットとが送信されて、成功裏に受信され、あるいは再構築されるまで、繰り返される。

本発明に従い採用することができる受信方法論に従い、図４に概して示されるとおり、ステップ１１０において、パケットが送信トランシーバから受信される。ステップ１１２において、受信したパケットが記憶される。それから、システムはステップ１１４に進み、ステップ１１４において、受信したパケットは、上記ダウンロードを受信するアプリケーションに伝送される。それから、システムはステップ１１６に進み、ステップ１１６において、Ｎ個のパケット（すなわち、ブロック全体）が受信されている場合、システムはステップ１１８に進み、ステップ１１８において、記憶されたパケットが解放される。Ｎ個のパケットが受信されているため、ステップ１２４において判定されるとおり、損失回復は必要とされず、ステップ１２２において、システムは、パケットの受信数ＫがＮに等しいことを報告する。

ステップ１１６において、Ｎ個のパケットが受信されていない場合、システムはステップ１２０に進み、ステップ１２０において、Ｎ個のパケットのブロックの受信部分のうち最後のパケットが受信されているかが判定される。Ｎ個未満のパケットが受信されているが、ブロックの中の最後のパケットが受信されている場合、パケットは失われており、これが、Ｎ個より少ないパケットが受信されている理由である。それから、パケットの受信数Ｋが、ステップ１２２において送信トランシーバに報告され、置換符号化パケットが、送信トランシーバによって送られる。

置換符号化パケットは、ステップ１１０において受信され、再構築を可能にするほど十分なパケットが受信されているとシステムがステップ１１６において判定するまで、上記方法論に従い処理される。それから、システムはステップ１１８に進み、ステップ１１８において、パケットは記憶装置から解放される。ステップ１２４において、システムは、失われたパケットが回復されるべきであるか、及び回復されることができるかを判定するであろう。回復は、ステップ１２６において実行される。このことは、ステップ１２２において送信トランシーバに報告される。

ステップ１２０において、ブロックの最後のパケットが受信されていない場合、受信したパケットは、別の、例えば、現在のブロックの中のパケットであり、あるいは新しいブロックのデータパケットからのパケットである。新しいブロックからのパケットでない場合、ステップ１２７において、システムはステップ１２２に進み、ステップ１２２において、受信したパケットの合計数Ｋが上記のとおり報告される。しかしながら、パケットが新しいブロックのデータパケットからである場合、システムはステップ１１０に進み、ステップ１１０において、システムは新しいブロックのパケットを受信し続ける。

図４ａを参照すると、本発明方法に従うデータ受信方法論１００ａの一例示的な別の実施形態が示されている。ステップ１１０ａにおいて、例えば図３の方法により提供されるとおり、Ｎ個のデータパケットとＭ個の符号化パケットとのブロックの、インターネットなどのデジタル通信チャネルを通じた送信に応答して、受信トランシーバが、送信トランシーバ、例えば図３の方法論に従い動作する送信トランシーバにより元々送信されたＮ個のデータパケットとＭ個の符号化パケットとのブロックのうちいくつか又はすべてを構成するＮ_ｒ個のデータパケットとＭ_ｒ個の符号化パケットとを受信する。

システムにより使用される特定の消去符号化アルゴリズムに従い消失データパケットを置換するために使用されるように送信トランシーバシステムにより生成された符号化パケットは、受信されると、ステップ１１２ａにおいて記憶される。同様にして、データパケットもまた、受信されると、ステップ１１４ａにおいて記憶されてよい。符号化パケットとデータパケットとは双方、それ自体が符号化パケットであるかデータパケットであるかを示す指標を有するようにヘッダにおいて符号化される。

ステップ１１６ａにおいて、受信トランシーバシステムは、受信しているデータパケットの数Ｎ_ｒと受信している符号化パケットの数Ｍ_ｒとを数える。ステップ１１８ａにおいて、受信トランシーバは、すべてのデータパケットが受信されているかを判定する。上記が当てはまる場合、システムはステップ１２０ａに進み、ステップ１２０ａにおいて、ステップ１１４ａにおいて記憶されたＮ個のデータパケットは、これらが受信されたか、あるいはこれらがデータパケットのブロックの最初の送信の間にまず失われ、それから例えば受信したデータパケットと符号化パケットとを用いて例えば上記で規定されたアルゴリズム又は別の消去符号化方法論に従い再構築されたかにかかわらず、すべてのデータパケットを蓄積する機能を実行するメモリにダウンロードされる。

それから、ステップ１２２ａにおいて、システムは、第１のブロックのＮ個のデータパケットの受信及び／又は再構築を確認し、この情報を送信トランシーバに送ることによって次のブロックのＮ個のデータパケットを要求する。

送信されたＮ個のデータパケットのすべてが受信されなかった場合、ステップ１１８ａにおいて、システムはステップ１２４ａに進み、ステップ１２４ａにおいて、受信したデータパケットの数と合わせた受信した符号化パケットの数が、使用される特定の消去符号化方法に従う失われたデータパケットの再構築を可能にするかどうかが判定される。より具体的に、受信したデータパケットの数と受信した符号化パケットの数との加算が、現在のブロックの中のデータパケットの数より大きく、あるいは等しい場合、システムは、上記で規定された消去符号化アルゴリズムを使用して、採用される特定の消去符号化方法論に関連付けられたデコードアルゴリズムを用いて失われたデータパケットを再構築するための、十分な情報を有する。

それから、このデコードアルゴリズムがステップ１２６ａにおいて実行され、Ｎ個のデータパケットのブロックの最初の送信の間に失われたデータパケットすべての生成をもたらす。より具体的に、ステップ１１４ａにおいて記憶された元の生データパケットとステップ１１２ａにおいて記憶された符号化パケットとが、受信トランシーバにおいてデコードアルゴリズムに入力される。それから、デコードアルゴリズムが使用されて、失われたパケットの内容を計算し、同じものの再構築を生成する。

それから、ステップ１２６ａにおいて実行される消去符号化スキームのデコードアルゴリズムを用いて生成された再構築データパケットは、ステップ１１４ａにおいて記憶されたデータパケットと結合されて、デジタルデータ通信チャネルの他端における送信トランシーバにより元々送られたＮ個のデータパケットのブロックの情報内容を有するＮ個のデータパケットの完全な組を形成する。それから、システムは進んで、ステップ１２０ａにおいて、Ｎ個のデータパケットの再組み立てされたブロック（うまく受信されたデータパケットと消去符号化スキームに関連付けられたデコードアルゴリズムを用いて再構築されたデータパケットとを含む）を記憶し、ステップ１２２ａにおいて、データシーケンスの中の次のブロックのデータパケットを要求する。

ステップ１２４ａにおいて、受信トランシーバが、失われたデータパケットを再構築するほど十分な符号化パケットを自身が有していないと判定した場合、システムはステップ１２７ａに進んで、追加の符号化パケットを要求する。この要求は送信トランシーバに送られ、送信トランシーバにおいて、消去符号化及び符号化アルゴリズムが使用されて追加の符号化パケットを生成する。この追加の符号化パケットは、すべての以前に生成された、現在のブロックのＮ個のデータパケットに関連付けられた符号化パケットとは、異なる。

ステップ１２８ａにおいて送信トランシーバから受信トランシーバが受信した補足的なパケットは、ステップ１２４ａにおいて十分性について再度テストされ、ステップ１２４ａにおいて、システムは、すべてのうまく受信したデータパケット及び受信した符号化パケット（現在のブロックの中の情報の最初の伝送におけるＮ_ｒ個の受信データパケットと共に最初の送信において受信したものを含む）が失われたデータパケットの再構築を可能にするほど十分であるかを判定する。上記が当てはまる場合、システムは、ステップ１２６ａに進んでよく、そうでない場合、システムは、必要とされるデータパケットを受信するために要求し、試行するサイクル（ステップ１２７ａ及び１２８ａ）を繰り返さなければならない。

図３に示される送信方法論の実施形態に従い、送るべき符号化パケットの数に関する判断は送信トランシーバにおいて行われるが、この判断は受信トランシーバにおいて行われることも可能である。

図１乃至図４に関連して説明された、データパケット再送信なしで完全なパケットブロック受信を確保する出願人の独自ＤＰＲ（^ＴＭ）プロトコルの好適な実施形態は、以下に説明されるシステムなどの通信システムにおいてＤＰＲ（^ＴＭ）プロトコルを使用することである。

本発明は、アプリケーションＡとアプリケーションＢとの間のデータ通信ネットワークにわたって通信経路を確立する方法及び装置に向けられる。アプリケーションＡ及びアプリケーションＢは、（レイヤ４における）ＴＣＰと（レイヤ３における）ＩＰとを含む標準のＯＳＩスタックの実装を有する。ＤＰＲ^ＴＭプロトコルにより統制されるトンネルが確立されて、ローカルのスプーファ（spoofers）を用いて管理されるＴＣＰフロー制御でトラフィックを運び、消去符号化モジュールが、（有限体を通じた代数的演算を用いた）損失補償、接続管理、レート制御、フロー制御及び多重化を提供する。

図５は、システム１０１０がある通信エンドポイント１０１２（クライアント）と第２の通信エンドポイント１０１４（サーバ）との間でＵＤＰパケットを確実に送信するために使用している構成要素の概略図である。クライアント側における信頼可能消去符号化モジュール（Reliable Erasure Coding Modules）１０１６ａとサーバ側における１０１６ｂとが、以下に説明される本発明プロトコルにおいて使用される。図５を参照すると、信頼可能消去符号化モジュール１０１６ａ及び１０１６ｂの主な目的は、ＵＤＰ／ＩＰを通じてＤＰＲ^ＴＭプロトコルによって統制される双方向性通信チャネルを作成し、管理することである。信頼可能消去符号化モジュール１０１６ａ及び１０１６ｂは、接続管理、レート制御、フロー制御及び信頼性のある送信と共に、消去符号化、フラグメンテーション及び再組み立て、多数のＴＣＰセッションを多重化することを提供する。ＤＰＲ^ＴＭ接続確立及び終了は、モジュール１０１８ａ及び１０１８ｂによって管理される。（ＤＰＲ^ＴＭクライアントごとに）単一の、対応ＤＰＲ^ＴＭサーバとのＤＰＲ^ＴＭ接続が作成され、このクライアントにより開始され、あるいは終了されるすべてのＴＣＰセッションが、ＴＣＰセッション多重化モジュール１０２０ａ及び１０２０ｂにおいて、そのＤＰＲ^ＴＭ接続へと多重化される。トンネルが上がっており、動作可能であることを検証するために、周期的な「キープアライブ」メッセージがトンネル１０２１にわたって送られる。さらに、上記メッセージは、ＲＴＴ（ラウンドトリップタイム）及び損失レートなどのネットワークパフォーマンスに関する情報を提供する。消去符号化モジュール１０１６ａ又は１０１６ｂに対する入力はデータストリームであり、このデータストリームは、（方向に依存して）生データ又はＤＰＲ^ＴＭエンコードされたパケットであってよい。データストリームは、消去符号化処理を可能にするように固定サイズブロックのＮ個のパケットに区分される。ＩＰレイヤによるさらなるパケットフラグメンテーションを防止するために、ＭＴＵ（最大伝送ユニット）値がさらに固定される。ＤＰＲ^ＴＭの好適な消去符号化スキーマは、本明細書において十分に参照により援用される米国特許第７，０７６，３１５号に説明されるとおりの系統的なランダム線形ネットワーク符号化である。上記スキーマにおいて、Ｎ個のパケットを包含する各ブロックについて、生パケットは到着順に送られ、推定される損失レート（ＥＬＲ）に依存して、余分な（extra）符号化パケットが生成され、送られる。消去符号化モジュール１０２４ａ及び１０２４ｂは、有限体にわたってランダムに又は決定的に生成される乗算係数を用いて符号化パケットを生成することができる。乗算係数がランダムに生成される場合、これらは、ＤＰＲ^ＴＭのヘッダに組み込まれて、符号化パケットを構築することに使用された線形結合（linear combination）と共に送信される。乗算係数が決定的アルゴリズム、例えば特定次数のガロア体にわたる多項式の順次的なリストを用いて選択される場合、上記生成アルゴリズムを、接続作成の時点で１回、及びその後、送信器が現在使用されているアルゴリズムを別のもので置換する判断を行うたびに受信器に伝えることによって、パケットヘッダにおける乗算係数の送信を回避することが可能である。全体的なレイテンシ及びジッタが、実際のパケットフローに並行して消去符号化／デコード演算を実行することによって低減されることができる。トンネル１０２１にわたるフローは、フロー制御モジュール１０２６ａ及び１０２６ｂによって管理される。消去符号化モジュール１０１６ａ及び１０１６ｂにより送られるパケットの各ブロックについて、ＡＣＫパケットが受信器により生成され、トンネルをわたって返される。ＡＣＫパケットは、フローを管理し、チャネル特性（例えば：ＲＴＴ、ジッタ、損失レート）を推定し、輻輳制御をサポートし、フロー制御をサポートし、信頼性スキーマをサポートするために、フロー制御モジュール１０２６ａ及び１０２６ｂによって使用される。輻輳管理モジュール１０２８ａ及び１０２８ｂは、標準のＴＣＰ Ｖｅｇａｓアルゴリズムを使用することができる。

図６は、ある通信エンドポイント１１１２（クライアント）と第２の通信エンドポイント１１１４（サーバ）との間でＵＤＰパケットを送信することに使用されるシステム１１００の構成要素の概略図である。クライアント側における汎用的消去符号化（ＥＣ）モジュール（Generic Erasure Coding (EC) Module）１１１６ａとサーバ側における１１１６ｂとが、以下に説明される本発明プロトコルにおいて使用される。図６を参照すると、汎用的消去符号化モジュール１１１６ａ及び１１１６ｂの主な目的は、ＤＰＲ^ＴＭプロトコルを用いてＵＤＰエンコードされたＩＰ接続を通じて双方向性接続を作成し、管理することである。汎用的消去符号化モジュール１１１６ａ及び１１１６ｂは、消去符号化、フラグメンテーション及び再組み立て、並びに接続管理を提供する。接続確立及びクローズ１１１８ａ及び１１１８ｂが、標準のＵＤＰ状態機械を用いて実施される。クライアントごとの単一のＤＰＲ^ＴＭ接続が作成され、上記クライアントについてのＵＤＰデータグラムがその接続へと送られる。トンネルが上がっており、動作可能であることを検証するために、周期的な「キープアライブ」メッセージがトンネル１１２１にわたって送られる。さらに、上記メッセージは、ＲＴＴ（ラウンドトリップタイム）及び損失レートなどのネットワークパフォーマンスに関する情報を提供する。汎用的消去符号化モジュール１１１６ａ又は１１１６ｂに対する入力（方向に依存する）は、バイトストリームであり、このバイトストリームは、生データ又はＩＰパケットであってよい。バイトストリーム（又はパケットストリーム）は、所定サイズのブロックサイズパケットに分割され、ネットワークＭＴＵ（最大送信ユニット）が超過されないことを確保する。フラグメンテーション及び再組み立て１１２２ａ及び１１２２ｂは、それぞれの汎用的消去符号化モジュール１１１６ａ及び１１１６ｂ内で行われる。ＤＰＲ^ＴＭの好適な消去符号化スキーマは、系統的な符号化である。上記スキーマにおいて、長さＮの各ブロックについて、生パケットは到着順に送られ、推定される損失レート（ＥＬＲ）に依存して、余分な符号化パケットが生成され、送られる。消去符号化モジュール１１２４ａ及び１１２４ｂは、有限体においてランダムの又は決定的な符号を用いて符号化パケットを生成することができる。符号化係数がランダムに生成される場合、これらは、ＤＰＲ^ＴＭパケットのヘッダに組み込まれる。決定的な符号については、予め決定されたルックアップテーブルを使用し、符号化係数に対するポインタを送ることによって、ヘッダに符号化係数を含むことを回避することが可能である。全体的なレイテンシ及びジッタが、実際のパケットフローに並行して消去符号化／デコード演算を実行することによって低減されることができる。

図７は、本発明の好適な一実施形態のクライアント側実装の高レベルの概略図を示し、これにおいて、ＴＣＰトラフィックとＵＤＰトラフィックとの双方が管理される。アプリケーション１２１０は、通常、携帯電話、タブレット、コンピュータ又は組み込み型システムなどの物理デバイス上に常駐する。アプリケーション１２１０は、図７に示されるとおり、クラウドプロキシ実装に対する通信ネットワークを通してデータリンク１２１２をわたって通信する。好適な一実施形態において、アプリケーション１２１０は、オペレーティングシステムのユーザ空間１２１１に存在する。例えば、長い遅延又は高い誤りレートに起因して、既存のプロトコルが高帯域幅遅延プロダクトに対して理想的でない状況においてパフォーマンスを向上させるために、プロトコルスプーフィングがデータ通信に使用される。ＴＣＰ接続は、長い遅延のリンクなどの高帯域幅遅延プロダクトを用いたリンクに対する不十分なウィンドウサイズに起因して、パフォーマンス制限を被るおそれがある。こうしたタイプの遅延は、ＧＥＯ衛星、セルラーネットワーク、Ｗｉ‐Ｆｉネットワーク及び他の通信ネットワークなどの通信ネットワークにおいて見られる。ＴＣＰのスロースタートアルゴリズムは、接続送信スピードを有意に遅延させる。スプーフィングルータは、ＴＣＰ輻輳ループを低減させる。このことは、ＴＣＰをＸＴＰと同様のプロトコルに変換する。

ＯＳＩスタックのＴＣＰ／ＵＤＰ１２１４及びＩＰ１２１６部分は、オペレーティングシステムのカーネル空間１２１７にある。ＯＳＩスタックは、オペレーティングシステムを修正することなく修正されることができない。パケットストリームへのアクセスを得るために、ＴＵＮデバイス１２１８が使用される。ＴＵＮデバイス１２１８は、パケットストリームがユーザ空間１２１１からアクセスされることを可能にする標準の仮想デバイスドライバである。このポイントにおいて、アップストリームパケットフローとダウンストリームパケットフローとが分離される。アップストリームパケットフローに続いて、パケットは、ＴＣＰ／非ＴＣＰスプリッタ分配器１２２０に配信される。ＴＣＰ／非ＴＣＰ分配器１２２０は、ＩＰヘッダのプロトコルフィールドを調べ、ＴＣＰパケットをＴＣＰスプーファモジュール１２２２に送る。

すべての他のパケットタイプ（ＵＤＰなど）は、汎用的消去符号化（ＥＣ）エンコーダ１２２４に送られる。符号化トンネル１２１２について、消去符号化エンコーダ１２２４と（図８に示される）サーバ１３３０との間の、汎用的ＥＣモジュール１１２４ａと１１２４ｂとの間で（図６）、開ループ制御が使用される。クライアントが、ネットワーク損失に起因してパケットを再構築するほど十分な情報を受信しないとき、クライアントは、発信した汎用的ＥＣエンコーダ１２２４に損失情報を送ることになる。ＥＣエンコーダ１２２４は、損失情報に関してリンクをモニターすることになり、更新される損失情報に基づいて符号化パケットの数を増加させ、あるいは減少させることになる。

汎用的ＥＣエンコーダ１２２４は、ネットワーク符号化を非ＴＣＰパケットに提供して信頼性レイヤを実施する。汎用的ＥＣエンコーダ１２２４からのパケットフローは、送信の前に、ＵＤＰヘッダ１２２６及びＩＰヘッダ１２２８を用いてカプセル化される。ＴＣＰスプーファモジュール１２２２からのパケットは、ＥＣエンコーダ１２２４に送られる。クライアント側におけるＥＣエンコーダ１２２４と（図８に示される）サーバ側におけるＥＣデコーダ１３３０との間で、レート適応が実行される。ＥＣエンコーダ１２２４からのパケットストリームが、ＵＤＰモジュール１２２６及びＩＰモジュール１２２８からの適切な情報を用いてカプセル化され、リンク１２１２をわたって送信される。サーバ側からリンク１２１２から到着するパケットは、ＩＰレイヤ１２２８及びＵＤＰレイヤ１２２６において終端される。それから、すべてのパケットはＥＣデコーダ１２３０に向けられる。

ＥＣデコーダ１２３０は、消去符号化チャネルについて、サーバ１３２４とクライアント１２３０との間で閉ループフロー制御を使用する。ＴＣＰフロー制御は、消去符号化チャネルにおいて明確に使用されない。ＥＣデコーダ１２３０が、ネットワーク損失に起因してパケットを再構築するほど十分な情報を受信しない場合、ＥＣデコーダは、サーバ１３２４に、再構築を可能にするほど十分なパケットを送るように要求を送ることになる。求められるパケットの数は、消失パケットの数に等しくてよく、あるいはより大きくてよい。ＥＣデコーダ１２３０は、リンク１２１２をわたるローカル通信のすべてを扱い、（適切にデコードされた）ダウンリンクＴＣＰパケットをＴＣＰスプーファ１２２２とカーネルベースのＴＵＮデバイス１２２８とに渡すことになり、上記パケットは、アプリケーション１２１０に対するプロトコルスタックへと渡されることになる。

ＴＣＰスプーファ１２２２が、図７に示されている。ＴＣＰスプーファ１２２２は、（１又は複数の）ローカルのアプリケーション１２１０のために肯定応答を作成することの責任を負う。実装者がＴＣＰ状態機械設計の技術を経験していることが仮定される。従来のＴＣＰ状態機械実装において、アプリケーションは、パッシブサーバ（リッスンする）又はアクティブクライアント（開始する）として動作することができる。ＴＣＰスプーファの役割は、受動的に動作し、クライアント又はサーバいずれかの通信を検出して、ＴＣＰ状態セッションの通常の反対側によって見られるであろうとおりに適切なマッチする状態挙動を実施することである。本発明の部分として実施され得る２つの好適なＴＣＰスプーファの実施形態がある。第１の実施形態は、透過（transparent）モードにおいて動作する。透過モードにおいて、ＳＹＮ、ＳＹＮ＿ＡＣＫなどの特定の制御メッセージがＴＣＰスプーファを通して渡され、したがって、エンドツーエンドのＴＣＰ接続が２つのアプリケーションの間で直接確立される。このモードにおいて、ＴＣＰスプーファは、ＴＣＰセグメントのすべてのヘッダ情報、例えば、シーケンス番号、タイムスタンプなどをさらに渡す。第２のモードは、不透明（opaque）モードである。不透明モードにおいて、ＴＣＰスプーファは、フルの（標準の）ＴＣＰ状態機械を作成することによってＴＣＰセッションを完全に終了させる。

図８は、クラウドプロキシ実装の高レベル図である。これは、図３のクライアント側実装に対して対になる実装である。クラウドプロキシ実装は、概念的に、アプリケーション又はその関連ＴＣＰスタックなしの、クライアント側の直接的なミラーである。むしろ、パケットは、図７に説明されるとおり、クライアントアプリケーション１２１０から、クライアントデバイスからのリンク１２１２を通じて入って来る。図８を参照すると、データが、クライアントデバイス１２１０からリンク１３１２を介して受信され、ネットワークスタックのＩＰレイヤ１３２８によって、次いでネットワークスタックのＵＤＰレイヤ１３２６によって処理される。リンク１３１２から到着するパケットは、ＩＰレイヤ１３２８及びＵＤＰレイヤ１３２６において終端される。それから、すべてのアップリンクトラフィックは、ＥＣデコーダ１３３０に移動される。ＥＣデコーダ１３３０は、リンク１３１２をわたるローカル通信のすべてを扱い、（適切にデコードされた）アップリンクパケットをＴＣＰスプーファ１３２２とカーネルベースのＴＵＮデバイス１３１８とに渡し、上記パケットは、リンク１３１７を介してＩＰスタック１３１６へと渡され、それからネットワークに対して転送されることになる。レート適応が、ＥＣデコーダモジュール１３３０とＴＣＰスプーファ１３２２との間で実行され、ＥＣデコーダモジュール１３３０は、アップリンク方向において、消去デコード、接続管理、輻輳制御、フロー制御及び逆多重化（de-multiplexing）を実施する。

図９は、透過的なスプーフィングモードにおいてクライアントからサーバへＴＣＰ接続を確立するためのＴＣＰ状態シーケンスを示す。これまでに述べられたとおり、ＴＣＰスプーファ１３２２は、パッシブモードにおいて動作する。ＴＣＰ接続状態機械の開始ポイントは、ＣＬＯＳＥＤ状態１４０１である。状態機械は問合せループ１４０２に入って、トンネルがリンク１３１２をわたって確立されているかを判定する。そうである場合、状態機械は、ＬＩＳＴＥＮ状態１４０３に移る。ローカルのアプリケーションから、あるいはトンネルからのいずれかのＳＹＮパケットの受信に基づいて、ＬＩＳＴＥＮ状態１４０３から起こり得る遷移が２つある。遷移１４０４は、ローカルのアプリケーションからのＳＹＮパケットの受信を示す。上記パケットを受信すると、スプーファ１３２２は、新しいセッションハンドラを作成し、そのカウンターパートに対するトンネルにＳＹＮパケットを転送し、ＳＹＮ＿ＲＣＶＤ状態１４０６に入る。別法として、スプーファ１３２２は、トンネルからＳＹＮパケットを受信し、遷移１４０５を介してＳＹＮ＿ＳＥＮＴ状態１４０７に進むこともある。遷移１４０５は、スプーファ１３２２に、新しいセッションハンドラを作成させ、トンネルからのＳＹＮパケットをローカルのアプリケーションに転送させ、ＳＹＮ＿ＳＥＮＴ状態１４０７に入らせる。ＳＹＮ＿ＲＣＶＤ状態１４０６からの遷移は、１４０８で示される。この遷移は、ＳＹＮ／ＡＣＫがトンネルから返されたとき、引き起こされる。状態機械は、ＳＹＮ／ＡＣＫをローカルのアプリケーションに転送し、ＳＹＮ＿ＡＣＫ＿ＲＣＶＤ状態１４０９に入る。ローカルのアプリケーションが、そのＳＹＮ／ＡＣＫを返すとき、状態機械は、１４１０を介してＥＳＴＡＢＬＩＳＨＥＤ状態１４１１に遷移する。ＥＳＴＡＢＬＩＳＨＥＤ状態１４１１は、エンドツーエンドのＴＣＰセッションが作成されていることを示す。別法として、状態機械は、ＳＹＮ／ＡＣＫがトンネルを介して受信されたとき、ＳＹＮ＿ＳＥＮＴ状態１４０７からＥＳＴＡＢＬＩＳＨＥＤ状態１４１１に遷移することができる（１４１２）。同時的な開放条件は接続確立状態機械に明確に示されていないことが留意されるべきである。さらに、例外遷移はここで明示的に論じられないが、図７及び図８に示されている。

図１０は、図９に示されたように確立された接続をクローズするための状態シーケンスを示す。エントリポイントは、これまでに説明された接続状態機械の最終結果であるＥＳＴＡＢＬＩＳＨＥＤ状態１５０１である。ＥＳＴＡＢＬＩＳＨＥＤ状態１５０１からの出口遷移が２つある。ＦＩＮメッセージがローカルのアプリケーションから受信された場合、状態機械は遷移１５０９を介してＣＬＯＳＥ＿ＷＡＩＴ状態１５０３に移る。状態機械は、トンネルに対してＦＩＮメッセージを、アプリケーションに対してＡＣＫメッセージを送ることになる。状態機械が（ＥＳＴＡＢＬＩＳＨＥＤ状態１５０１にあるときに）トンネルからＦＩＮメッセージを受信した場合、状態機械は遷移１５０８を介してＦＩＮ＿ＷＡＩＴ１状態１５０２に移る。状態機械はＦＩＮメッセージをアプリケーションに送ることになる。ＦＩＮ＿ＷＡＩＴ１状態１５０２から続けると、潜在的な出口遷移が２つある。状態機械がアプリケーションからＦＩＮメッセージを受信した場合、このことは、同時的なクローズがあることを示す。ローカルのアプリケーションとトンネルの向こう側におけるアプリケーションとは、ＴＣＰセッションを同時にクローズしようとする。これは非常に可能性の低い事象であるが、状態機械はＣＬＯＳＩＮＧ状態１５０４に移り、トンネルに対してＦＩＮメッセージを、ローカルのアプリケーションに対してＡＣＫメッセージを送ることになる。ＡＣＫがローカルのアプリケーションから受信されたとき、状態機械は遷移１５１４を介してＣＬＯＳＥＤ状態１５０７に移り、ローカルのアプリケーションにＡＣＫメッセージを送ることになる。ＣＬＯＳＥＤ状態は、この状態機械の最終的な状態である。ＦＩＮ＿ＷＡＩＴ１状態１５０２からの第２の出口経路は、ＡＣＫがローカルのアプリケーションから受信されたときに生じる。これは通常の経路であり、状態機械は遷移１５１２を介してＦＩＮ＿ＷＡＩＴ２状態１５０６に移る。状態機械はＡＣＫをローカルのアプリケーションに送ることになる。状態機械は、ローカルのアプリケーションからＦＩＮを受信したとき、遷移１５１３を介してＦＩＮ＿ＷＡＩＴ２状態１５０６からＣＬＯＳＥＤ状態１５０７に遷移することになる。状態機械は、ローカルのアプリケーションに対してＡＣＫメッセージを、トンネルに対してＦＩＮメッセージを送ることになる。ＣＬＯＳＥ＿ＷＡＩＴ状態１５０３に戻ると、状態機械は、トンネルからＦＩＮを受信したとき、遷移１５１０を介してＬＡＳＴ＿ＡＣＫ状態１５０５に遷移することになる。状態機械は、ＦＩＮメッセージをローカルのアプリケーションに送ることになる。状態機械は、ローカルのアプリケーションからＡＣＫを受信したとき、遷移１５１１を介してＬＡＳＴ＿ＡＣＫ状態１５０５からＣＬＯＳＥＤ状態１５０７に遷移することになる。ＲＬＮＣが消去符号化の好適な一方法であるが、発明者は、パフォーマンスとオーバヘッド及びペイロードの考慮とのバランスをとる第２の消去符号化方法を見出している。

ネットワーク符号化（ＮＣ）原理は、データの代わりの表現として代数式を用いることに基づく。例えば、ＩＰパケットペイロードが、２進数を表す（９，１０，２，４）の表現を包含してよく、上記表現は（１００１，１０１０，００１０，０１００）であろう。パケット自体は、ＩＰパケット１、ＩＰパケット２、ＩＰパケット３及びＩＰパケット４が一組の線形式として表されるであろうように変数として表されることができ、したがって、４つ（４）の線形式が４つ（４）の変数について解くことを必要とされるであろう。上記式自体は、上記４つ（４）の変数について一意的に解くために線形独立でなければならない。

最先端のメカニズムは、乱数生成手法を使用することである。このことの一例は、Ｓａｉｔｏに対する米国特許第６，８５７，００３号に開示されており、第２の例は、Ｆｏｒｔｕｎａの暗号アルゴリズムである。Ｆｏｒｔｕｎａは、暗号論的に安全な疑似乱数生成器（ＰＲＮＧ）である。Ｎｉｅｌｓ Ｆｅｒｇｕｓｏｎ及びＢｒｕｃｅ Ｓｃｈｎｅｉｅｒの“Ｐｒａｃｔｉｃａｌ Ｃｒｙｐｔｏｇｒａｐｈｙ”（２００３年）を参照されたい。

ノードは、情報についてのソースポイント、デスティネーションポイント、又はソース及びデスティネーションポイントとして定義される。ノードは、情報配信に係る最初のポイント、最後のポイント、及び任意の中間ポイントを含む。ノードは、自身が受信したパケットのランダムな線形結合を、ガロア体から選ばれた係数と共に送信する。上記体のサイズが十分に大きい場合、（１又は複数の）受信器が線形に独立な結合を得る（そして、ゆえに革新的な情報を得る）ことになる確率は１に近付き、この１は１００％の確率である。

符号化ヘッダが使用されるようなプロトコルを作成するメカニズムが、米国特許第８，０６８，４２６号（Ｓｕｎｄａｒａｊａｎら）及び第７，７０６，３１５号（Ｅｆｆｒｏｓら）、Ｓｕｎｄａｒａｊａｎらの“Ｎｅｔｗｏｒｋ Ｃｏｄｉｎｇ ｍｅｅｔｓ ＴＣＰ：Ｔｈｅｏｒｙ ａｎｄ Ｉｍｐｌｅｍｅｎｔａｔｉｏｎ”、Ｐｒｏｃｅｅｄｉｎｇ
ｏｆ ｔｈｅ ＩＥＥＥ、Ｖｏｌ．９９、Ｎｏ．３、２０１１年３月に開示されている（３つすべてが本明細書において十分に参照により援用される）。

ヘッダは、様々なフィールドとソース及びデスティネーションポートとを含む。ポート情報は、符号化パケットのセッションを識別するために必要とされる。これは、ＴＣＰヘッダから取り出される。第２のフィールドは、ベース（base）である。これは、ＴＣＰバイトシーケンス番号である。その次のフィールドは、線形結合に関わるパケットの数であるＮである。その次のフィールドは開始であり、これは、線形結合に関わるｉ番目のパケットの開始バイトであり、ここでｉは１からＮへ進む。終了は、線形結合に関わるｉ番目のパケットの最後のバイトである。最後のフィールドは、線形結合に関わるｉ番目のパケットに使用される係数であるａ_ｉである。基本的に、ｉ番目のパケットの開始バイトと終了バイトとがそのパケットを定義する。

ＲＬＮＣを用いると、符号化パケットは、符号化パケットについての中間パケット及びヘッダの各々の場所に対するポインタと共に、線形結合を作成することに使用された係数を包含する必要がある。パケットの数は変化することがあるため、ソースからデスティネーションへの係数伝送に使用されるオーバヘッドの量は可変であり、大きい値のＮに関してかなり大きくなる可能性がある。実際には、ＴＣＰ／ＩＰネットワークについて、高パフォーマンスシステムのための最大のＮは、３０より小さいか又は等しい。このことは、パケット結合が１００より大きく、１０Ｋに近づくことがあるところの大きなファイル伝送における使用に関して、ＲＬＮＣの有用性を低減させる。

発明者は、予め算定された係数を使用することによって線形独立の式を作成し、それから、係数をコードブックにおいて配信し、コードブックを情報の伝送に関わる各ノードに送ることができることを見出した。上記式を作成する別の一方法には、係数が情報の伝送に関わる各ノードとやりとりされる必要がなく、単に最初及び最後のノードとやりとりされる必要があるような予め定義された多項式（例えば、階乗）を送ることを伴う。推測的に（a priori）知られるコードブック又は多項式は、適切な係数が何であるかをデスティネーションポイントが理解することを可能にして、伝送される線形式のデコードを可能にし、元の変数（すなわち、パケット）の再作成を可能にする。

システム設計者は、１又は複数の予め決定されたコードブックに関連してＤＬＮＣを実施することを選んでもよい。このシステムの便益の１つは、コードブックが暗号メカニズムと同様に再セットアップされることができることであり、したがって、伝送の途中において、コードブックは変更されることができる。このことは、ポリシーに基づく情報の管理（例えば、セキュリティ）に対して望まれることがある。

予測可能シーケンス生成式は、より少ないメモリを必要とし、かなり低コストのデバイス上で実施されることができる。

通常のランダム線形ネットワーク符号化スキーム（ＲＬＮＣ）は、一組のＮ＋ｋ個の線形式の構築プロセスを含み、ここで“ｋ”は、通信チャネルにおける推定されるパケット損失レート（ＰＬＲ）であり、下記の：
１）次元“Ｎ”のランダム係数のベクトルを選択するステップ
２）パケットベクトル（順序付けられた一組のＮ個のパケット）と係数のベクトルとを乗算して結合されたパケット（結合パケット）を得るステップ
３）ステップ（１）‐（２）を繰り返して“Ｎ＋ｋ”個の結合パケットを生成するステップ
を含む。

結果的な一組の“Ｎ＋ｋ”個のパケットは、チャネルを通じて送信され、受信端によって行列代数を用いてデコードされる。デコード可能であるために、係数がランダムに選択されると仮定すると、ＲＬＮＣは、デスティネーションにおいて係数のエンコードベクトルを知られるように内部的な情報交換を必要とする。それゆえに、受信器に対して送信器は、下記の情報、すなわち、
１）各々の結合パケットを構成することに使用された係数の組
２）結合パケットの中のパケットの数
３）結合パケットの中の各パケットのパケット長
を伝えるべきである。

図１１は、従来のＲＬＮＣの通常のエンコードプロセスを示し、図１２は、従来のＲＮＬＣデコードプロセスを表す。

図１１を参照すると、エンコードプロセスは、パケットベクトルと係数ベクトルとの行列乗算であり、パケット_ｉが係数ａ_ｉによって乗算されることを意味する。ここで、ｉは１からＮ（ウィンドウの中のパケットの数）へ進む。それから、中間値が合計されて符号化パケットが作成される。

通常、例えばＮＣ−ＴＣＰなどの現在のＲＬＮＣ実装において、ＮＣサポート情報が、パケットヘッダに対してオーバレイとして追加される。言い換えると、ａ_１１乃至ａ_ｎｎが、毎回、ランダムに生成される。ＲＬＮＣにおいて、Ｎ個のパケットについて、ソースノードは、Ｎ個のパケットを送り、ＮＣノードにおいてランダム符号化を追加することになり、符号化パケットＮＣ_１乃至ＮＣ_ｎを送出することになる。符号化パケットは、デコードノードにおいてデコードされ、それから、受信ノードによって受信されることになる。いずれかのパケットが失われた場合、追加のパケットがＮＣ_ｎ＋１乃至ＮＣ_ｍ＋ｎであり、ここで、ｍは失われたパケットの数である。こうして、ｍ＋ｎ個の符号化パケットが合計で送出される。

上記は、低減されたペイロードサイズをもたらし、このことが今度は、特に、ＴＣＰ／ＩＰなどの現代のトランスポートプロトコルに関して重ね合わせられたとき、より低い効率につながる。ＲＬＮＣにおいて使用されるとおりのランダム係数の選択を、本発明により提案される非ランダムの、決定的プロセスで置換することは、送信器と受信器との間の余分な情報伝送の必要性を除去し、それゆえに、通信効率及び信頼性を劇的に向上させる。このことは、図１３と図１４とにおける比較に示される。

図１３は、ＲＬＮＣにおいて使用されるような、バンド内で送信されるＮＣ係数を用いた汎用的パケットフォーマットを示す。図１３は、ＲＬＮＣが使用されるときのバンド内での係数の送信に起因した、追加されるオーバヘッド及びより大きいペイロードを示す。ひとまとまりのｎ個のデータパケットをデコードする（例えば、式を解くために行列反転をする）とき、式の次数（order）はｎ^３である。

図１４を参照すると、行列の中の予め決定された値を用いて本発明システムに関連して使用されるとき（ＤＬＮＣ）、上記値は、デコードすることがより容易である。本発明システムにおいて、符号化パケットは、常に符号化ノードにおいて作成されるが、送出されない。生パケットだけが送られる。受信側において、非符号化パケットが受信されたとき、該パケットは、行列上の該パケットのスポットに行く。生パケットは、ちょうど対角線上に非ゼロ値を有することになる。失われたパケットがあるとき、信号が符号化ノードに送り返され、符号化ノードは符号化パケットＮＣ_１乃至ＮＣ_ｍを生成する。ここで、ｍは失われたパケットの数である。それゆえに、パケットが必要とされるときに限り、ｍ個の線形結合パケットだけが送出される。符号化パケットがデコーダに送り返されたとき、行列の非対角線空間に非ゼロ値が存在することになるが、通常、行列の完全なサイズより小さく、こうして、行列式を解くことはかなり容易になり、より少ないパワーで済む。

本発明の好適な一実施形態は、下記の例示的なアルゴリズムにより具現化される既知のシーケンスを用いたＤＬＮＣ係数の生成である。

図１６を参照すると、ＤＰＲ（^ＴＭ）装備エンティティ又はクライアント５０２（これは、中でも、モバイルデバイス、アプリケーションプロセスであってよい）が、ＤＰＲ（^ＴＭ）チャネル５２１を確立したい場合、ＤＬＮＣを用いて、ネットワークの中の別のＤＰＲ（^ＴＭ）装備デバイス５０４（又はプロキシ）と接続をすることが必要とされる。接続は、ＴＣＰ接続要求と同様のスリーウェイハンドシェイクを用いて確立される。要求７００が、クライアント５０２からサーバ５０４に送られる。確認７０２が、サーバ５０４からクライアント５０２に送られ、コードブック又はシーケンス生成式のいずれかを含むリンクパラメータを返す。それから、クライアント５０２は「リンク確立」応答７０４をサーバ５０４に送る。接続は、終了要求７０６を用いて、クライアント５０２又はサーバ５０４の要求ごとに終了される。

上記アプローチは、リンクが複数のセグメントから成るところの条件を包含する。この手順の一例は、下記の通り説明されることができる。ＮＣに対して選ばれたガロア体（ＧＦ）がＧＦ（２５６）である場合、すべての係数は０乃至２５５から選ばれる。ＧＦ（２５６）内で係数を選択するためのいくつかの潜在的なメカニズムが存在する：
ａ）素数についての順序付けられたリストが使用されてよく、ここで、該数＜２５６であり（選ばれたＮＣフィールドがＧＦ（２５６）である場合）、最低数がシーケンス番号０ ＳＮ（０）に、その次がシーケンス番号１ ＳＮ（１）に割り当てられるなどする
ｂ）ＮｘＮ符号化行列の第１の行について、Ｎ個の係数が順次選択される。ＳＮ（０）で始まり、すなわち、１，２，３，５，７，１１，．．．，ＳＮ（ｋ），．．．，ＳＮ（Ｎ−１）である。このことは、Ｎ個のパケットを一緒に符号化することを可能にする
ｃ）ＮｘＮ行列について、同じ行列の次の行が、第１の行のベクトルを１か所ずつ右に回転することによって形成され、ゆえに、ＳＮ（Ｎ）で始まってＳＮ（Ｎ−１）で終わる
ｄ）ＮｘＮ行列のＮ行すべてが、行ｉ、１≦ｉ≦Ｎについての係数のベクトルによって形成され、ここで、ｉは、行ｉ−１の係数のベクトルを１ポジションずつ右に回転することによって生成され、ＳＮ（Ｎ−ｉ＋１）で始まってＳＮ（Ｎ−ｉ）で終わる
ｅ）（送信損失に起因して）Ｎ個より多くの式が必要とされる場合、次のベクトルは、ＳＮ（０）に代わってＳＮ（１）で始まる同じシーケンスからのＮ個の新しいエントリを選択することによって形成される。換言すると、元の生成ベクトルが１，２，３，５，７である場合、追加される情報ベクトルは２，３，５，７，１１であり、上記アルゴリズムが繰り返される。このことは、元の情報を再構築するために必要とされる十分な線形独立のベクトルが迅速に受信されることを保証する
ｆ）サイズＮのパケット生成を考えると、Ｎ個の係数についての各々の選択されるシーケンスは、Ｎ個の式を生成するのに十分である。一組の５０個の素数は、５０ｘＮ個の違ったベクトルを生み出すことになる。より多くのベクトルが必要とされる場合、上記組を再順序付けすれば、次の５０Ｎ個のベクトルを生み出すのに十分であろう。５０個の数字についての５０！（５０の階乗）の順列が存在するため、この方法は、実質的に無限数の係数ベクトルを生成するのに十分である。このアルゴリズムは、リンクの両端が追加の情報の必要なく同期的に動作することを可能にする。このことは、通信プロトコルを大いに簡素化し、パケットオーバヘッドをかなり低減させる。

上記で定義されたアルゴリズムをサポートするための簡素化されたパケットフォーマットは、送信された符号化パケットの成功裏のデコードを可能にするために下記のヘッダフィールドを必要とする：
１バイトのフレームタイプ ‐ ＮＣデータ及びサービスパケット間の区別を可能にする
２バイトのフレーム長 ‐ パケット処理を可能にする
１バイトのペイロードタイプ ‐ 様々なタイプのＮＣデータパケット、例えば生パケット及び結合パケット間の差別化を可能にする
１バイトのトライ＃ ‐ 再送信シーケンス番号
３バイトの生成ＩＤ ‐ 符号化ウィンドウシーケンス番号
１バイトの、結合パケットの中のパケット数 ‐ エンコードされたパケットの数が常に知られていることを確保する
‐‐‐‐‐‐‐‐‐‐
合計：９バイト
さらに、結合される各パケットは、その係数によって乗算される前に、パケット長指標（２バイト）を先頭に付加される（pre-pended）必要がある。このことは、混在した長さのパケットの符号化を可能にする。

上記追加の２バイトは、合計オーバヘッドを１１バイトに等しくする。

提案されるパケットフォーマットの一例示が、図１４に提示されている。

追加される１１バイトのパケット情報は、通常の１５００Ｂパケットの０．７３％を、及び最も短いイーサネットパケットの６４Ｂの１７％を表す。５０の生成サイズを仮定すると、ＤＬＮＣを用いるシステムは、約３．７％のオーバヘッドを通常有するであろう。６４Ｂのパケットサイズについて、ＲＬＮＣを用いるシステムは、８５．９％のオーバヘッドを通常有するであろう。本発明の消去符号化方法は、符号化係数の又はランダム生成を再現するために必要とされる情報の直接的な送信に基づいたこれまでのＮＣ実装のオーバヘッドをかなり低減させる。損失確率に応じたオーバヘッドが、図１５においてより詳細に示されている。

本発明の一重要要素は、決定的な、予測可能な、再現可能な態様における符号化係数の生成である。このことは、いくつかの非常に望ましい特性につながる。

第１に、係数情報を符号化パケットと共に送る必要性が除去されるため、送信オーバヘッドが低減され、このことが、増加されたプロトコル効率につながる。より詳細に、現在のＲＬＮＣにおいて、あるいは一般に、ＴＣＰを通じたレートレス消去符号実装において、通常のオーバヘッドは、ブロックにおいて使用されるパケットごとに１２バイト＋６バイトである。ＤＬＮＣ方法において、これは、１１バイトに低減される。ブロックの中のパケットの数が３０である場合に、ＩＰパケットにおいて伝送される最大ペイロードは１３５０であり、最大ＩＰパケットサイズは１５００であり、ＲＬＮＣ方法は、１１バイトの固定オーバヘッドを有するＤＬＮＣに対して、１９２バイトのオーバヘッドを使用する。この例において、ＲＬＮＣは、出願人のＤＬＮＣ方法よりも１７倍大きいオーバヘッドを使用する。実際、このことは、ＤＬＮＣ方法がブロックの中で使用されるパケットの数によって制限されないことも可能にする。プロトコルオーバヘッド（１１バイト）が生成サイズを感知しない（generation size agnostic）ため、提案されるフォーマットのさらに別の便益は、より低いＩＳＯスタックレイヤによるＩＰパケットフラグメンテーションのリスクなしに任意の生成サイズを使用する能力である。

第２に、この方法は、符号化係数の予測可能性を利用する低減された複雑性のテスト方法を可能にする。

第３に、係数の適切な選択が、デコードプロセスの間に必要とされるガウス消去を実行するときの計算複雑性の低減を可能する。

第４に、コードブック又はアルゴリズム的係数選択のいずれかを用いた係数選択の方法が、送信の間、コードブック又はアルゴリズムのポリシーに基づく変更を可能にする。さらに、符号化シーケンスがソース及びデスティネーションにおいて知られているため、符号化パケットが確立されたリンクの外部で使用され得ないので、上記メカニズムは、固有の信頼性及び安全性を提供する。このことは、プレミア付きの放送テレビ番組などの高価値コンテンツに関連して使用されるとき、非常に望ましい。

前述の実施形態における送信装置の処理機能は、ハードウェア又はソフトウェアにおいて実現されることができる。上記処理機能のすべてがハードウェア又はソフトウェアによって実現されるだけでなく、その一部がハードウェア又はソフトウェアを用いることによって実現されてもよい。すなわち、ハードウェア及びソフトウェアの組み合わせが採用されてよい。

前述の実施形態に関して、本発明の主旨の範囲内で、様々な修正例が考えられる。さらに、本明細書の記述に基づいて作成され、あるいは組み合わせられた様々な修正例及び適用例も考えられる。様々な変更、組み合わせ、副次的組み合わせ及び変形が、設計要件と他の要因とに依存して行われてよいことを当業者は理解すべきである。本明細書に説明された現在好適な実施形態に対する様々な変更及び修正が当業者に明らかになるであろうことが理解されるべきである。こうした変更及び修正は、本発明の主旨及び範囲から逸脱することなく、その意図される利点を弱めることなく行われる可能性がある
関連出願の相互参照／参照による援用
本特許出願は、２０１２年１１月８日に申請され“ＭＥＴＨＯＤ ＡＮＤ ＡＰＰＡＲＡＴＵＳ ＦＯＲ ＩＭＰＲＯＶＩＮＧ ＴＨＥ ＰＥＲＦＯＲＭＡＮＣＥ ＯＦ ＴＣＰ ＡＮＤ ＯＴＨＥＲ ＮＥＴＷＯＲＫ ＰＲＯＴＯＣＯＬＳ ＩＮ Ａ ＣＯＭＵＮＩＣＡＴＩＯＮＳ ＮＥＴＷＯＲＫ”と題された米国仮特許出願第６１／７２４，２７５号、２０１３年５月７日に申請され“ＭＥＴＨＯＤ ＡＮＤ ＩＭＰＬＥＭＥＮＴＡＴＩＯＮ ＦＯＲ ＮＥＴＷＯＲＫ ＣＯＤＩＮＧ ＣＯＥＦＦＩＣＩＥＮＴＳ ＳＥＬＥＣＴＩＯＮ”と題された米国仮特許出願第６１／８２０，６８２号、及び２０１３年８月１９日に申請され“ＭＥＴＨＯＤ ＆ ＡＰＰＡＲＡＴＵＳ ＦＯＲ ＩＭＰＲＯＶＩＮＧ ＴＨＥ ＰＥＲＦＯＲＭＡＮＣＥ ＯＦ ＴＣＰ ＡＮＤ ＯＴＨＥＲ ＮＥＴＷＯＲＫ ＰＲＯＴＯＣＯＬＳ ＩＮ Ａ ＣＯＭＭＵＮＩＣＡＴＩＯＮＳ ＮＥＴＷＯＲＫ ＵＳＩＮＧ ＰＲＯＸＹ ＳＥＲＶＥＲＳ”と題された米国仮特許出願第６１／８６７，５８３号を参照し、これらに対して優先を主張し、かつこれらからの利益を主張する。上記出願の各々が、その全体を本明細書において参照により援用される。

Claims (44)

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. 複数の係数決定方法論を含むコードブックが、前記符号化ノードにおいて及び前記受信器ノードにおいて常駐し、前記係数決定方法論のうち１つの指定が、前記符号化ノードから前記受信器ノードに送信され、符号化係数の前記ベクトルは、前記係数決定方法論のうち前記の指定された１つを用いて前記符号化ノードにおいて及び前記受信器ノードにおいて決定される、請求項２３に記載の方法。
28. 生成される係数の組は、有限体に属する、請求項２３に記載の方法。
29. 順序付けられたリストにおいて元の行ベクトルを１ポジションずつシフトすることによって係数を係数の行ベクトルにおいて１ポジションずつ回転すること及び必要とされるとおりに余分な係数を生成することに基づいてＮｘＮ符号化行列を生成するために、請求項２３に記載の方法において使用されるアルゴリズム。
30. 追加的に生成される線形式の線形独立を確保するように一組の係数を再順序付けするために、請求項２３に記載の方法において使用されるアルゴリズム。
31. リンクの両端を初期化して、シーケンスを予め決定すること及び制御パケットヘッダの中のフィールドにより前記受信器ノードに前記の選択を知らせることに対する適切なオペレーションを確保する、請求項２３に記載の方法。
32. 請求項１、７又は１１に記載の装置において使用される請求項２３に記載の方法。
33. 限られた到着期限を有するＮ個のパケットを含むデータブロックを送信する方法であって、
    ａ）損失推定値Ｍを設定するステップと、
    ｂ）データウィンドウにおけるパケットの数を、ウィンドウサイズのＮに対応する第１の数のパケットＮ個に設定するステップと、
    ｃ）前記Ｎ個のパケットを消去符号化して、一組のＭ個の消去符号化パケットを作成するステップと、
    ｄ）送信されるデータブロックが前記Ｎ個の元のパケットに続いて前記Ｍ個の消去符号化パケットを包含するように、前記データブロックを送信するステップと、
    ｅ）受信端における損失レート変化を監視することによって、前記損失推定値Ｍを調整するステップと、
    ｆ）後のデータブロックを送信することに使用するために前記の調整された損失推定値Ｍを送信器に送るステップと、
    を含む方法。
34. 限られた到着期限を有するＮ個のパケットを含むデータブロックを送信する方法であって、
    ａ）損失推定値Ｍを設定するステップと、
    ｂ）データウィンドウにおけるパケットの数を、ウィンドウサイズのＮに対応する第１の数のパケットＮ個に設定するステップと、
    ｃ）前記Ｎ個のパケットを消去符号化して、一組のＮ＋Ｍ個の消去符号化パケットを作成するステップと、
    ｄ）送信されるデータブロックがＮ＋Ｍ個の消去符号化パケットを包含するように、前記データブロックを送信するステップと、
    ｅ）受信端における損失レート変化を監視することによって、前記損失推定値Ｍを調整するステップと、
    ｆ）後のデータブロックを送信することに使用するために前記の調整された損失推定値Ｍを送信器に送るステップと、
    を含む方法。
35. 当該システムは、ユーザ空間とカーネル空間とネットワークスタックとを含むソフトウェアシステムを含む、請求項４に記載のシステム。
36. 前記カーネル空間の中の前記オペレーティングシステムネットワークスタックの前記カーネル空間から前記ユーザ空間へ情報データフローを接続するＴＵＮ、ＴＡＰ又はプロキシなどのコンストラクタ、をさらに含む請求項３５に記載のシステム。
37. 前記ネットワークスタックのインターネットプロトコル（ＩＰ）レイヤから前記ユーザ空間への接続を提供するＴＵＮ仮想デバイス、をさらに含む請求項３５に記載のシステム。
38. 前記ネットワークスタックのメディアアクセス制御（ＭＡＣ）レイヤから前記ユーザ空間への接続を提供するＴＡＰ仮想デバイス、をさらに含む請求項３５に記載のシステム。
39. 前記ネットワークスタックのメディアアクセス制御（ＭＡＣ）レイヤから前記ユーザ空間への接続を提供するＬ２ＴＰ仮想デバイス、をさらに含む請求項３５に記載のシステム。
40. 前記ネットワークスタックのメディアアクセス制御（ＭＡＣ）レイヤから前記ユーザ空間への接続を提供するＴＡＰ仮想デバイスと関連するＬＮＳスタック、をさらに含む請求項３５に記載のシステム。
41. 前記ネットワークスタックのメディアアクセス制御（ＭＡＣ）レイヤから前記ユーザ空間への接続を提供するＬ２ＴＰ仮想デバイスと関連するＬＮＳスタック、をさらに含む請求項３５に記載のシステム。
42. 前記ネットワークスタックのメディアアクセス制御（ＭＡＣ）レイヤから前記ユーザ空間への接続を提供するＴＵＮ仮想デバイスと関連するＬＮＳスタック、をさらに含む請求項３５に記載のシステム。
43. 消去符号化が、請求項２３に記載の方法を用いて実行される、請求項４又は３６に記載のシステム。
44. 請求項２３に記載の消去符号化方法と関連して使用される請求項３１又は３２に記載の方法。

Images