(57)【要約】  ＴＣＰ経路をセグメント化し、独自プロトコル（ＤＰＲ（ＴＭ））をネットワークを通じて実施することによって、データネットワークのパフォーマンスを向上させる方法及び装置である。消去符号化アルゴリズムを使用して、失われたデータパケットを再構築するために使用される予測された数の冗長符号化パケットを生成することによって、帯域幅が低減され、信頼性が向上される。符号化パケットは送信側において生成され、チャネルを通じて成功裏に送られた符号化パケットと生データパケットとが、失われた生データパケットを再構築するために使用される。本発明に係る方法論は、１又は複数のプロキシサーバにおいて実施されてよい。リアルタイムプロトコルにおけるパケット損失について調整するＤＰＲ（ＴＭ）消去符号化は、クライアントからクラウドプロキシへのＴＣＰセッションの多重性のために、多重化されたトンネルを提供する。ＤＰＲ（ＴＭ）は、輻輳制御、フロー制御、信頼性及び及びリンク監視を実施する。他のネットワークプロトコル（ＵＤＰなど）が、送信信頼性を向上させるネットワーク符号化に基づいた信頼性プロトコルを用いてサポートされる。パフォーマンス強化プロキシの使用と消去符号化トラフィック処理強化の追加とが、レガシープロトコルに見られるような送信損失を減少させ、ゆえに、より効率的な処理とかなり良好なリンクキャパシティ利用とを可能にする。
2016501464.tif 000002
【特許請求の範囲】
【請求項１】
デジタルデータシーケンスにおいて複数のブロックのデータパケットを送信する方法であって、
（ａ）第１のトランシーバにおいて、データ通信チャネルの他端における第２のトランシーバに対する前記データ通信チャネルを通した送信のために、第１のブロックのＮ個のデータパケットを受信するステップと、
（ｂ）前記第１のブロックのパケットを複製し、前記パケットを記憶して前記第１のブロックのパケットの記憶されたコピーを作るステップと、
（ｃ）前記第１のブロックのＮＴ個のデータパケットを、前記第１のトランシーバから、前記データ通信チャネルを通して、前記データ通信チャネルの他端における前記第２のトランシーバに送信するステップと、
（ｄ）送信トランシーバにおいて、前記第２のトランシーバにより受信されたデータパケットの数ＮＲを示す情報を受信し、失われたパケットを再構築するために前記第２のトランシーバにおいて必要とされる消去符号化パケットの数ＭＴをＭＴ＝ＮＴ−ＮＲとして定義するステップと、
（ｅ）ＭＴがゼロより大きい場合、少なくともＭＴ個の消去符号化パケットを、前記第１のブロックのパケットの前記記憶されたコピーから生成するステップと、
（ｆ）少なくともＭＴ個の消去符号化パケットを、前記第１のトランシーバから、前記データ通信チャネルを通して、前記データ通信チャネルの他端における前記第２のトランシーバに送信するステップと、
（ｇ）前記の受信トランシーバにより受信された消去符号化パケットが前記ＮＲ個の受信されたデータパケットと合わせて失われたデータパケットを再構築するほど十分であるかの指標を受信するステップと、
（ｈ）前記受信トランシーバにより受信された前記消去符号化パケットが前記ＮＲ個の受信されたデータパケットと合わせて失われたデータパケットを再構築するほど十分である場合、前記受信トランシーバによって前記失われたデータパケットを再構築するステップと、
（ｉ）前記受信トランシーバにより受信された前記消去符号化パケットが前記ＮＲ個の受信されたデータパケットと合わせて失われたデータパケットを再構築するほど十分でない場合、前記受信トランシーバにより受信された前記消去符号化パケットが前記ＮＲ個の受信されたデータパケットと合わせて失われたデータパケットを再構築するほど十分になるまで、ステップ（ｄ）、（ｅ）、（ｆ）及び（ｇ）を繰り返し、それから、前記受信トランシーバによって前記失われたデータパケットを再構築するステップと、
を含む方法。
【請求項２】
デジタルデータシーケンスにおいて複数のブロックのデータパケットを送信する方法であって、
（ａ）第１のトランシーバにおいて、データ通信チャネルの他端における受信トランシーバに対する前記データ通信チャネルを通した送信のために、第１のブロックのＮ個のデータパケットを受信するステップと、
（ｂ）前記ブロックのＮ個のデータパケットの中で前記受信トランシーバにより成功裏に受信されることになるデータパケットの予期数について、最初の値Ｖを設定するステップと、
（ｃ）前記のＮ−Ｖ個の予期される失われたパケットを置換するために必要とされる数の消去符号化パケットＭ個を生成するように前記第１のブロックのデータパケットを処理するステップと、
（ｄ）前記第１のブロックのＮ個のデータパケットと前記Ｍ個の消去符号化パケットとを、前記第１のトランシーバから、前記データ通信チャネルを通して、前記データ通信チャネルの他端における前記の第２のトランシーバに送信するステップと、
（ｅ）前記第２のトランシーバからパケット損失情報を受信するステップと、
（ｆ）パケット損失が予期したより大きい場合、失われたパケットの数がＮ−Ｖより大きい場合にＭをＭｉに増加させることによってＭの予測値を生成し、追加の消去符号化パケットを送信するステップと、
（ｇ）パケット損失が予期したより大きい場合、前記ブロックの中の任意の及びすべての失われたデータパケットを再生成するほど十分なパケットが前記受信トランシーバによって受信されたと前記受信トランシーバが示すまで、ステップ（ｅ）及び（ｆ）を繰り返すステップと、
（ｈ）前記第１のブロックのデータパケットの中の任意の及びすべての失われたデータパケットを再生成するほど十分なパケットが前記受信トランシーバによって受信された後、前記第１のトランシーバにおいて、前記データ通信チャネルの他端における前記受信トランシーバに対する前記データ通信チャネルを通した送信のために、第２のブロックのＮ個のデータパケットを受信するステップと、
（ｉ）前記パケット損失情報に基づいて、前記ブロックのＮ個のデータパケットの中で前記第２のトランシーバにより成功裏に受信されることになるデータパケットの予期数について、補正値Ｖａを算定するステップと、
（ｊ）Ｖの代わりにＶａを用いてステップ（ａ）乃至（ｇ）を繰り返すステップと、
を含む方法。
【請求項３】
前記データ通信チャネルはインターネットである、請求項１又は２に記載の方法。
【請求項４】
Ｍ＝Ｖである、請求項２に記載の方法。
【請求項５】
前記第１のブロックのデータパケットの処理は、消去符号化を用いて実行される、請求項１又は２に記載の方法。
【請求項６】
前記第１のブロックのデータパケットの処理は、前方誤り訂正を用いて実行される、請求項１又は２に記載の方法。
【請求項７】
パケット損失が予期したより大きい場合、Ｍｉ−Ｍ個の追加の消去符号化パケットが送信される、請求項２に記載の方法。
【請求項８】
パケット損失が予期した損失に等しい場合、Ｍの予測値は、Ｍの以前の値を用いることによって生成され、失われたパケットの数がＮ−Ｖより小さい場合、Ｍの予測値は、ＭをＭｄに減少させることによって生成される、請求項２に記載の方法。
【請求項９】
（ｋ）前記受信トランシーバで、前記第１のブロックのＮ個のデータパケットと前記Ｍ個の消去符号化パケットとのうちすべて又はいくつかを、前記第１のトランシーバから受信するステップと、
（ｌ）前記第１のブロックのＮ個のデータパケットと前記Ｍ個の消去符号化パケットとの中で前記の受信されたパケットを数えて前記パケット損失情報を生成するステップと、
（ｍ）前記パケット損失情報を、前記受信トランシーバから、前記データ通信チャネルを通して、前記データ通信チャネルの他端における前記第１のトランシーバに送信するステップと、
をさらに含む請求項１又は２に記載の方法。
【請求項１０】
前記データ通信チャネルは全二重通信チャネルである、請求項２に記載の方法。
【請求項１１】
順序付けられた一連のデータパケットの形式においてデータを通信する方法であって、
（ａ）一連のＮ個のデータパケットを含む第１のブロックのデータパケットを送信するステップと、
（ｂ）電気通信チャネルの品質を表すように機能する値を有する品質係数に基づいて、Ｍ個の消去符号化パケットを生成するステップであり、消去符号化パケットの数Ｍは、前記電気通信チャネルの品質に反比例し、前記消去符号化パケットは、エンコードアルゴリズムとデコードアルゴリズムとを有する消去符号化スキームを用いて生成され、前記消去符号化パケットは、前記データパケットを前記消去符号化スキームの前記エンコードアルゴリズムに入力することによって生成される、ステップと、
（ｃ）前記Ｍ個の消去符号化パケットを発信トランシーバから送信するステップと、
（ｄ）受信トランシーバにおいて、前記電気通信チャネルを通じてデータパケットと消去符号化パケットとを受信するステップと、
（ｅ）Ｎ個のデータパケットとＭ個の消去符号化パケットとのうち前記発信トランシーバから前記受信トランシーバへの前記電気通信チャネルを通じた送信の間に失われた数を決定するステップと、
（ｆ）前記受信トランシーバから、前記の失われたパケットの数に基づいて、いくつかの追加の消去符号化パケットのための要求を送信するステップと、
（ｇ）前記の送信トランシーバにおいて、いくつかの追加の消去符号化パケットのための前記要求を受信するステップと、
（ｈ）前記失われたパケットの数に応答して、前記品質係数の値を更新するステップと、
（ｉ）前記電気通信チャネルを通じて、前記送信トランシーバから、前記受信トランシーバに、追加の消去符号化パケットを送信するステップと、
（ｊ）前記受信トランシーバにおいて、追加の消去符号化パケットを受信するステップと、
（ｋ）前記消去符号化スキームに関連付けられたデコードアルゴリズムを実行することによって、失われたデータパケットを再構築するステップと、
（ｌ）後続ブロックのデータパケットを送信するステップと、
（ｍ）前記後続ブロックのデータパケットについて、前記品質係数の前記の更新された値を用いて、前記後続ブロックのデータパケットについて、ステップ（ｂ）乃至（ｌ）を繰り返すステップと、
を含む方法。
【請求項１２】
いくつかの追加の消去符号化パケットのための前記要求は、失われたパケットの数に等しいいくつかの消去符号化パケットを目的とする、請求項１１に記載の方法。
【請求項１３】
前記品質係数の値の更新は、前記送信トランシーバにより送られる消去符号化パケットの数を断続的に低減させて、より少ない消去符号化パケットがデータパケットのブロックの成功裏の送信に必要とされ、これにより向上された電気通信チャネルパフォーマンスが利用されることができるかを判定することを含む、請求項１１に記載の方法。
【請求項１４】
システムはプロキシサーバを含む、請求項１又は２に記載の方法。
【請求項１５】
前記消去符号化パケットは、下記の、リードソロモン（ＲＳ）符号化、ＬＤＰＣ（低密度パリティ検査）符号化、ルビー変換（ＬＴ）符号化、ラプタ符号化、ネットワーク符号化及びオンライン符号から成る群から選択された消去符号化方法を用いて生成される、請求項１、２又は１１に記載の方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、概して、通信ネットワークに関する。より詳細には、本発明は、向上させた通信パフォーマンスを損失のあるリンクを通じて提供する。
【０００２】
本発明は、パケット送信装置、通信システム及びプログラムの態様を含む。
【背景技術】
【０００３】
ワイヤレスチャネルを通じたデータ通信が、ますます一般的になってきている。例えば、ＷｉＦｉは、ＩＥＥＥ８０２．１１標準に基づいた接続のワイヤレス通信に使用される。他の多くのワイヤレスチャネルが使用されることもあり、いくつか例を挙げると、ＷｉＭＡＸ、３Ｇ、メッシュネットワーク又はコミュニティネットワークなどである。ワイヤレスチャネルは損失のあることがあり、したがって、データは様々な条件のうち任意の１つに起因して、送信の間、しばしば失われることがある。例えば、天候条件が、通信データの送信が害され得るようなものであることがある。同様にして、データ送信に対して様々な原因からの干渉があることがあり、例えば、同一チャネル上で送信している他のデバイスからの干渉である。こうした要因のいずれかが、データパケット送信におけるさらなる損失又はデータパケット消去レートの増大の一因となることがある。エンドツーエンドのトランスポートプロトコル（例えば、トランスミッションコントロールプロトコル（ＴＣＰ））において、データ通信は、相互接続されたネットワーク又はデバイスにわたって提供される。トランスミッションコントロールプロトコル（ＴＣＰ）は、通信ネットワークにおいて利用されて、信頼性、フロー制御及び輻輳制御のためのメカニズムを提供する。
【０００４】
こうしたトランスポートプロトコルにおいて、ＴＣＰはトランスポートプロトコルの一例であり、送信されるデータはパケットに分けられる。データパケットは受信器に送信され、受信器において、パケットは検証され、元のメッセージに再組み立てされる。肯定応答（ＡＣＫ）が受信器から返されて、データパケットが受信されたことを示す。ＡＣＫが返らない場合、データパケットは再送信されなければならないことがある。さらに、送信器が指定時間内にＡＣＫを受信しないとき、送信器におけるトランスポートプロトコルがタイムアウトすることがある。このことは、パケットの送信レートの低減をもたらす。通信ネットワークは、定義上、実際は統計的であり、パケットは一般に失われ、「消去損失」と「異常配信」とを引き起こす。ＴＣＰは、いかなる失われたパケットも再送信し、異常パケット配信シーケンスを再配置し、送信レートを調節して、把握された輻輳損失を最小化することになる。
【０００５】
ＴＣＰは、送信レイテンシを最小化すること又はネットワークの「良好なスループット（good-put）」を最大化することよりも、信頼性のある送信に向けて最適化される。ＴＣＰは、輻輳的な損失を最小化するアルゴリズム（ＴＣＰ  Ｔａｈｏｅ、Ｖｅｇａｓ及びＲｅｎｏなど）を包含し、エンドツーエンドの肯定応答を頼りにし、このことは、通信リンクのラウンドトリップタイムに基づいて最大送信レートを制限する。通信リンクのラウンドトリップタイムが、利用可能な帯域幅と直接の相互関係を有さないため、セッションの最大ＴＣＰ送信レートは、利用可能な通信帯域幅に結び付けられない。
【０００６】
下層のＴＣＰ接続におけるたった１個の失われたパケットが、その接続を通じて多重化されたＨＴＴＰストリームの全体を失速させる。輻輳制御の問題は、通常、ＴＣＰの領域である。しかしながら、ＴＣＰ自体が、十分に良好ではない。第１に、ＴＣＰが仮定すべきものと目指すべきものとに関するコンセンサスが、争われている。データセンターが、スロースタートを止め、あるいはデータセンターＴＣＰ又はより風変わりなスキームを実行している。衛星オペレータは、ＴＣＰ接続を分割し、その独自のプロトコルを衛星リンク上で実行している。映画スタジオは、大きいファイルの映画映像をヨーロッパからハリウッドに送るとき、ＴＣＰを回避する。ＴＣＰは、高遅延（high-delay）リンクを十分活用しないからである。
【０００７】
第２に、ＴＣＰのもろさが、より低いレイヤを制約している。ＴＣＰが、パケット損失及び異常配信に十分に反応しないため、ネットワークは、確率的な損失をマスクし、異常配信又はマルチパスルーティングを回避する。トランスポートレイヤが必要に応じて進化することができるという確信と共に、ＴＣＰの仮定を明示的にし、より低いレイヤが自身が合うと考えるとおりに革新できるようにすることが好ましいであろう。
【０００８】
最後に、ＴＣＰを使用するアプリケーションでさえもが、しばしば、実際には従来の意味でＴＣＰを使用していない。ウェブブラウザは、ウェブ１ページを単にロードするために、百を超えるＴＣＰ接続を開くことがある！Ｎｅｔｆｌｉｘなどのアプリケーションは、符号化ビデオの４／２（four-second）チャンクのダウンロードにおけるＴＣＰのパフォーマンスに基づいて、その独自のレート制御をＴＣＰの最上部に構築している。このことは、文書で十分に立証されたひねくれた結果につながる。
【０００９】
損失及びレイテンシに関連する論点は、通信スタックにおける他のプロトコルに影響する可能性がある（例えば、メディアストリーミング若しくはＶｏＩＰに統合されたＵＤＰ、又は任意のワイヤレスリンクレイヤ設計）。輻輳は、ネットワークにおいて、通信リンク又は経路上のトラフィックの量が該リンク又は経路のキャパシティを超えたときに生じることがある。こうした場合、過剰データは破棄されることがあり、あるいは、過剰データは輻輳が緩和されるまでバッファされることがある。しかしながら、輻輳が存続する場合、輻輳は、パケット交換ネットワークにおいて、バッファの中のデータパケットを破棄してバッファをクリアすることによって制御される。さらに、チャネル障害又は干渉が、信号雑音比（ＳＮＲ）劣化とビット誤りとをもたらすこともあり、上記劣化と誤りとが、同様に、パケット誤り又は消去をもたらすことがある。
【００１０】
ユーザデータグラムプロトコル（ＵＤＰ）は、通信ネットワークにおいて、遅延に基づく信頼性メカニズム（再送信）に悩まされるリアルタイムアプリケーションに主に利用される。ＵＤＰは、通常、損失回復メカニズムなしの固定レート送信である。したがって、損失のある環境において、ＶｏＩＰ及びビデオなどのＵＤＰに基づく通信は、感知できるほどに劣化し、知覚できるくらいの忠実度の損失を引き起こす。
【００１１】
ＦＥＣ（前方誤り訂正）システムにおいて、１パケットでもＦＥＣブロックの中で消失しているときにデコードは実行することができないため、信頼性のあるトランスポートプロトコルシステムのパケット回復レートに等しいパケット回復レートを実現するために、信頼性のあるトランスポートプロトコル再送信によって必要とされるよりも多くの冗長パケットを送信することが必要である。
【００１２】
したがって、データパケットのブロックが、前方誤り訂正アルゴリズムによって生成される十分な数の冗長パケットと共に受信されない場合、この冗長パケットと一緒に上記ブロックを再送信することが必要である。このことは、ネットワーク輻輳の増大をもたらす。さらに、元のデータの送信レートが不必要に低減されるという問題がある。
【００１３】
近年、マルチメディアデータは、インターネットなどのベストエフォート型通信ネットワークを通してしばしば伝達される。このタイプのデータ伝送において、ダウンロード送信システム又はストリーム送信システムが使用される。マルチメディアデータには、例えば、ビデオファイル、オーディオファイル、これらの組み合わせ、及びこれらを部分として含むデータを含むことができる。本発明のシステムにおいて、用語のマルチメディアデータは、時間情報又は再生（play-out）順序に関する情報を含むデータの意味で使用される。
【００１４】
ダウンロードベースの再生システムの場合、データファイルは、配信サーバから受信器における記録領域にダウンロードされ、伝送が完全に終了した時点において、その再生が開始される。したがって、ダウンロードベースの再生システムは、再生に長時間かかるマルチメディアデータの再生やリアルタイム再生が必要とされるマルチメディアデータの再生に不向きである。一方、ストリーミングベースの再生システムの場合、データファイルの再生は、部分的なデータだけが送信器から受信器に伝送された時点において開始される。ゆえに、これは、インターネット電話、遠隔ビデオ会議開催、ビデオオンデマンド、ネットワークカメラ監視、インターネットテレビ及び他のサービスに使用される。
【００１５】
上記のアプリケーションはすべて、万人向けのＴＣＰという発想から離脱して、インターネットにおける公平性を遂行している。上記の異なるスキームをすべて、パケット損失が最小化され、かつ送信が向上される共通フレームワーク下に一体化させる必要性が存在する。
【００１６】
インターネットの発展は、いくつかの独特なインフラストラクチャ要素を生み出しており、そのシームレスな、安全な、十分な機能を可能にしている。１つのこうした要素がプロキシであり、プロキシは、情報ソースから情報受信側を分離し、（プロキシタイプに依存して）セキュリティゲートウェイ又はパフォーマンス強化エンティティとして、要求集約器並びにロードバランサ、ファイヤウォール及び暗号化／復号ポイントのいずれかとしてサービスを提供し、グローバルに使用されるプロトコルよりも多くの効率的なインターネットトラフィックサービスを提供する。パフォーマンス強化プロキシ（Performance  Enhancing  Proxies）（ＰＥＰ）は、いくつかの通信プロトコルのエンドツーエンドのパフォーマンスを向上させるように設計されたネットワークエージェントである。パフォーマンス強化プロキシ標準は、ＲＦＣ３１３５（Ｐｅｒｆｏｒｍａｎｃｅ  Ｅｎｈａｎｃｉｎｇ  Ｐｒｏｘｉｅｓ  Ｉｎｔｅｎｄｅｄ  ｔｏ  Ｍｉｔｉｇａｔｅ  Ｌｉｎｋ‐Ｒｅｌａｔｅｄ  Ｄｅｇｒａｄａｔｉｏｎｓ）及びＲＦＣ３４４９（ＴＣＰ  Ｐｅｒｆｏｒｍａｎｃｅ  Ｉｍｐｌｉｃａｔｉｏｎｓ  ｏｆ  Ｎｅｔｗｏｒｋ  Ｐａｔｈ  Ａｓｙｍｍｅｔｒｙ）に定義されている。
【００１７】
標準プロキシは、大抵、トラフィックにわたってより多くの制御を要し、あるいは集中型処理のために特定のトラフィックタイプの集約を要する状況において配置される。クライアント側において、クライアントのマシンからのすべての（又は特定の）トラフィックが、クライアントマシンのルーティングテーブルを構成することによってプロキシサーバにリダイレクトされる。このトラフィックは、既存のデータ配信メカニズムについての損失保護、スピード向上又は任意の他の強化について、特別な考慮なくインターネットを通じて伝搬される。データは、プロキシサーバによって受信されると、処理されて、ブロックされ、あるいは送信器のために元の形式又は修正された形式で宛先に送信される。反対方向において、プロキシサーバは、インターネットからデータを受信し、これを必要に応じた前処理の後、特定クライアントに配信する。
【発明の概要】
【発明が解決しようとする課題】
【００１８】
輻輳に関連するとの損失の誤解釈に起因して、ワイヤレス通信ネットワークにおけるパフォーマンス損失の低減と損失のある通信チャネルにおけるトランスポートレイヤプロトコルパフォーマンスの強化とのための方法及びシステムの必要性が存在する。ビット又はパケット消去に対するネットワーク回復力を増大させる方法及びシステムの必要性もある。
【課題を解決するための手段】
【００１９】
発明者は、前述のパケット損失問題に対処するシステム及び方法を開発した。本システム及び方法は、消去符号化手法と発明者独自のパケット回復方法とを用いて新規のパフォーマンス強化プロキシサーバを利用する。好適な実施形態において、米国特許第７，７０６，３１５号及び第８，０６８，４２６号に開示されるものなどのネットワーク符号化（Network  Coding）（ＮＣ）が、好適な消去符号化方法である。本発明の好適な実施形態に従い、以下に明記されるとおり、上記タイプの消去符号化が使用される。
【００２０】
発明者の新規の消去符号化パフォーマンス強化プロキシ（Erasure  Coding  Performance  Enhancing  Proxy）（ＥＣＰＥＰ）を利用するシステムは、レガシープロトコルに見られるような送信損失を減少させ、ゆえに、より効率的なデータ伝送とかなり良好なリンクキャパシティ利用とを可能にする。
【００２１】
本発明の好適な実施形態は、レイヤ５（セッションレイヤ）、レイヤ６（プレゼンテーションレイヤ）又はレイヤ７（アプリケーションレイヤ）ローカルプロキシなどのコンストラクタを使用し、上記コンストラクタは、情報データフローを、カーネル空間の中のオペレーティングシステムネットワークスタックのカーネル空間からユーザ空間に接続する。コンピュータネットワークにおいて、プロキシサーバは、他のサーバからのリソースを求めるクライアントからの要求のために媒介の役割を果たすサーバ（コンピュータシステム又はアプリケーション）である。クライアントは、プロキシサーバに接続し、別のサーバから利用可能なファイル、接続、ウェブページ又は他のリソースなどのいくつかのサービスを要求し、プロキシサーバは、サービスの複雑度を簡素化し、制御する方法として要求を評価する。
【００２２】
好適な実施形態は、クライアントデバイス上に透過型（transparent）プロキシＳＷ（ソフトウェア）モジュールを含み、該プロキシＳＷモジュールは、対応するプロキシサーバＳＷコンポーネントと通信する。透過型プロキシは、横取り型（intercepting）プロキシ又は強制型（forced）プロキシとしても知られ、いかなる特別なクライアントデバイス構成も必要とすることなく、ネットワークレイヤにおいて通常の通信を横取りする。クライアントデバイスに常駐するアプリケーションは、プロキシの存在に気付く必要がない。透過型プロキシモジュールは、通常、クライアントデバイスのアプリケーション空間とインターネットインタフェースとの間に位置し、プロキシサーバが、ゲートウェイ又はルータの機能のいくつかを実行する。透過型プロキシは、データトラフィックをプロキシ認証及び承認に必要とされることを超えて修正しないプロキシである。
【００２３】
現在の業界標準プロキシに関して、本発明は、プロキシクライアントとプロキシサーバとにおける損失回復を可能にする特別な機能性を追加する。ゆえに、本発明のプロキシは、データ送信の品質を強化し、ハードウェア又はオペレーティングシステムに対するいかなる変更もなく、低減された伝送時間、低減されたレイテンシ、及びかなり向上された品質の経験をエンドユーザにもたらす。
【００２４】
本発明は、
１）ユーザプログラミング空間におけるアプリケーションと消去符号化モジュールとにおける接続
２）送信元及び宛先アドレスに基づいてトラフィックを分離する選択器
３）信頼性のあるデータ送信プロトコル（ＴＣＰ）と信頼性のないデータ送信プロトコル（ＵＤＰ）との双方について、ネットワーク損失を補正する消去符号化方法
４）標準のシステム通信手段を用いて情報を送信する／受信する方法
を提供する。
【００２５】
パケット送信システムは、ベストエフォート型ネットワークを通して、特定の到着期限を有し、あるいは有さないことがあるパケットを送信する。好適な実施形態のパケット送信システムは、必要とされる再送信を制御する自動パケット再送信機能と、データパケットのブロックに（１又は複数の）冗長データパケットを場合により、あるいは義務的に追加する消去符号化機能と、監視されるネットワーク状態変化に基づいて必要とされる量の冗長情報（符号化パケット）を動的に決定する冗長度決定機能とを含み、したがって、下記でさらに十分に詳述されるとおり、受信器における損失補償が、追加の冗長情報（符号化パケット）だけを用いた（１又は複数の）配信されていないパケット（失われたパケット）の回復によって達成される。このことは、データパケット再送信の必要性を除去する。本願システムは、好適な方法及び装置を含む。
【００２６】
特定の到着期限を有するデータブロックを送信する方法が提供される。データブロックは、ある設定数のパケットＮ個を含む。上記方法は、損失推定値Ｍを設定するステップと、パケットの数を、第１の数のパケットＮ個に設定するステップと、Ｎ個のパケットを消去符号化して、元のＮ個のパケットの線形結合（linear  combination）である一組のＭ個の線形結合（符号化パケット）を作成するステップと、元のＮ個のパケットについてのＭ個の線形結合を追加し、データブロックとＭ個の線形結合とを送信するステップとを含み、したがって、送信されるパケットは、Ｎ個の元のパケットとＭ個の線形結合パケットとを含む。最後に、このブロックのための（１又は複数の）任意の追加の符号化パケットが生成され、（１又は複数の）後続のパケット送信において送られる。好適な実施形態において、Ｍは、パケット損失があるまで設定されない。
【００２７】
前述の発明方法は、（失われたパケットを破棄して不完全な受信をもたらすであろうタイプの）特定の到着期限を有するデータを伝送する従来のシステムと比較して、特定の期限までに達成され得る冗長情報からの失われたパケットの回復を可能にし、ゆえに、実質的に向上されたパフォーマンスを備えたデータ受信をもたらす。
【００２８】
固定期限なしで保証された配信を有するパケット化されたデータストリームを送信する方法が提供される。ブロックサイズに関して上限も下限もないが、データブロックは、いくつかのパケットＮ個を、典型的には５〜３０個のパケットの範囲の中で含む。上記方法は、
ａ）Ｍ個の消去回復パケットの値を最初の損失推定に設定するステップであり、Ｍは任意の数又は予期されるチャネル特性に基づく数である、ステップと、
ｂ）選択されたブロックサイズのＮに対応する第１の数のパケットＮ個になるようにパケットの数ｎを選択するステップと、
ｃ）元々受信したパケットを送信し、さらなる処理のためにコピーを残すステップと、
ｄ）Ｎ個の現在の元の生データパケットを送信すると、現時点までに累積されたパケットにわたって消去符号化して、累積された元のパケットの線形結合である一組のＭ個の線形結合を作成するステップと、
ｅ）Ｎ個の元のパケットを送信すると、元のＮ個のパケットについてのＭ個の新しい線形結合を送信するステップであり、送信されたパケットの総計は、Ｍ個の線形結合パケットとＮ個の元のパケットと（Ｍ＋Ｎ）を含む、ステップと、
ｆ）失われたデータパケットを回復するために受信器側において必要とされる場合、追加の符号化パケットを送信するステップと、
ｇ）現在のデータブロックの最初の送信後に観察されたネットワーク状態変化とパケット送信レートとに基づいて冗長度の量を動的に決定して、最初の損失推定値をＭからＭ’に改め、更新された損失推定値Ｍ’に基づいて消去回復パケットの数を再算定するステップと、
ｈ）Ｎ個の元の生データパケットと更新された数Ｍ’個の消去回復パケットとを含む後に続くデータブロックを送信するステップであり、消去回復パケットの数Ｍ’は、推定された更新されたパケット損失推定に基づき、損失値の最初の推定は、数又はブロックサイズのパーセンテージとして表すことができる、ステップと、
ｉ）データが配信されるまで、後続ブロックの新しい生データパケットの送信サイクルを繰り返すステップと、
を含む。
【００２９】
好適な実施形態において、Ｍは、パケット損失があるまで設定されない。符号化パケットを生成する代替的方法の多くの他の例があり、該方法は、リードソロモン（ＲＳ）符号化、ＬＤＰＣ（低密度パリティ検査）符号化、ルビー変換（Luby  transform）（ＬＴ）符号化、ラプタ（Raptor）符号化、ネットワーク符号化、オンライン符号又は他のタイプの消去符号を含み、本発明はこれらに適用されてよい。
【００３０】
本発明システムは、デジタルデータシーケンスにおいて複数のデータブロックのデータパケットを送信する方法を提供する。本発明システムは、第１のトランシーバを有し、第１のトランシーバは、データ通信チャネルの他端における第２のトランシーバへのデータ通信チャネルを通した送信のために、第１のブロックのＮ個のデータパケットを受信する。それから、システムは、第１のブロックのパケットを複製し、パケットを記憶して、第１のブロックのパケットの記憶されたコピーを作る。第１のブロックのデータパケットは、第１のトランシーバから、データ通信チャネルを通して、全二重データ通信チャネルの他端における第２のトランシーバに送信される（ＮＴ）。送信トランシーバは、第２のトランシーバにより受信されたデータパケットの数ＮＲを示す情報を受信し、失われたパケットを再構築するために第２のトランシーバにおいて必要とされる消去符号化パケットの数ＭＴをＭＴ＝ＮＴ−ＮＲとして定義する。ＭＴがゼロより大きい場合、システムは、第１のブロックのパケットの記憶されたコピーから、少なくともＭＴ個の消去符号化パケットを生成する。システムは、少なくともＭＴ個の消去符号化パケットを、第１のトランシーバから、データ通信チャネルを通して、データ通信チャネルの他端における第２のトランシーバに送信する。システムは、第２のトランシーバにより受信された消去符号化パケットがＮＲ個の受信されたデータパケットと合わせて失われたデータパケットを再構築するほど十分であるかの指標を受信する。第２のトランシーバにより受信された消去符号化パケットがＮＲ個の受信されたデータパケットと合わせて失われたデータパケットを再構築するほど十分である場合、第２のトランシーバは、失われたデータパケットを再構築する。第２のトランシーバにより受信された消去符号化パケットがＮＲ個の受信されたデータパケットと合わせて失われたデータパケットを再構築するほど十分でない場合、システムは、第２のトランシーバにより受信された消去符号化パケットがＮＲ個の受信されたデータパケットと合わせて失われたデータパケットを再構築するほど十分であって第２のトランシーバが失われたデータパケットを再構築することが可能になるまで、上記ステップを繰り返す。
【００３１】
本発明システムの別の実施形態において、デジタルデータシーケンスにおいて複数のブロックのデータパケットを送信する第２の方法が説明される。第１のトランシーバが、全二重データ通信チャネルの他端における第２のトランシーバへの全二重データ通信チャネルを通した送信のために、第１のブロックのＮ個のデータパケットを受信する。システムは、ブロックのＮ個のデータパケットの中で第２のトランシーバにより成功裏に受信されるであろうデータパケットの予期数について、最初の値Ｖを設定する。第１のブロックのデータパケットは、Ｎ−Ｖ個の予期される失われるパケットを置換するために必要とされるの数の符号化パケットＭを生成するように処理される。第１のブロックのＮ個のデータパケットとＭ個の符号化パケットとは、第１のトランシーバから、全二重データ通信チャネルを通して、全二重データ通信チャネルの他端における第２のトランシーバに送信される。パケット損失情報が、第２のトランシーバによって生成される。パケット損失が予期したより大きい場合、システムは、失われたパケットの数がＮ−Ｖより大きい場合にＭをＭｉに増加させることによってＭの予測値を生成し、追加の符号化パケットを送信する。パケット損失が予期したより大きい場合、システムは、ブロックの中の任意の及びすべての失われたデータパケットを再生成するほど十分なパケットが第２のトランシーバにより受信されたと第２のトランシーバが示すまで、上記ステップを繰り返す。第１のブロックのデータパケットの中の任意の及びすべての失われたデータパケットを再生成するほど十分なパケットが第２のトランシーバにより受信された後、第１のトランシーバは、全二重データ通信チャネルの他端における第２のトランシーバへの全二重データ通信チャネルを通した送信のために、第２のブロックのＮ個のデータパケットを受信する。システムは、パケット損失情報に基づいて、ブロックのＮ個のデータパケットの中で第２のトランシーバにより成功裏に受信されるであろうデータパケットの予期数について、補正値Ｖａを算定し、Ｖの代わりにＶａを用いて上記ステップを繰り返す。
【００３２】
符号化パケットＭ個は、上記ブロックのＮ個のデータパケットの中で第２のトランシーバにより成功裏に受信されるであろう予期されるデータパケットの最初の設定値Ｖに等しくてよい。
【００３３】
第１のブロックのデータパケットの処理は、消去符号化を用いて実行されてよい。第１のブロックのデータパケットの処理は、前方誤り訂正を用いて実行されてよい。
【００３４】
パケット損失が予期したより大きい場合、Ｍ−Ｍｉ個の追加の符号化パケットが送信されてよい。
【００３５】
パケット損失が予期したものに等しい場合、Ｍの予測値は、Ｍの以前の値を用いることによって生成されてよく、失われたパケットの数がＮ−Ｖより小さい場合、Ｍの予測値は、ＭをＭｄに減少させることによって生成されてよい。
【００３６】
第２のトランシーバは、第１のブロックのＮ個のデータパケットとＭ個の符号化パケットとのすべて又はいくつかを第１のトランシーバから受信してよい。第１のブロックのＮ個のデータパケットとＭ個の符号パケットとの中で受信されたパケットが、パケット損失情報を生成するために数えられてよい。パケット損失情報は、第２のトランシーバから、二重データ通信チャネルを通して、二重データ通信チャネルの他端における第１のトランシーバに送信されてよい。
【００３７】
本発明システムの別の実施形態が、順序付けられた一連のデータパケットの形式においてデータを通信する方法を含む。システムは、一連のＮ個のデータパケットを含む第１のブロックのデータパケットを送信し、電気通信チャネルの品質を表すように機能する値を有する品質係数に基づいて、Ｍ個の符号化パケットを生成する。これにおいて、符号化パケットの数Ｍは、電気通信チャネルの品質に反比例し、符号化パケットは、エンコードアルゴリズムとデコードアルゴリズムとを有する消去符号化スキームを用いて生成される。符号化パケットは、データパケットを消去符号化スキームのエンコードアルゴリズムに入力することによって生成される。Ｍ個の符号化パケットは、発信（originating）トランシーバから送信される。受信トランシーバが、電気通信チャネルを通じてデータパケットと符号化パケットとを受信する。システムは、Ｎ個のデータパケットとＭ個の符号化パケットとのうち、発信トランシーバから受信トランシーバへの電気通信チャネルを通じた送信の間に失われた数を決定する。要求が、失われたパケットの数に基づいていくつかの追加の符号化パケットのために受信トランシーバから送信される。送信トランシーバは、いくつかの追加の符号化パケットのための要求を受信し、失われたパケットの数に応答して品質係数の値を更新する。追加の符号化パケットが、送信トランシーバから受信トランシーバに、電気通信チャネルを通じて送信される。受信トランシーバは、追加の符号化パケットを受信し、消去符号化スキームに関連付けられたデコードアルゴリズムを実行することによって失われたデータパケットを再構築する。それから、システムは、後続ブロックのデータパケットを送信し、後続ブロックのデータパケットについて品質係数の更新値を用いて、後続ブロックのデータパケットについて上記ステップを繰り返す。
【００３８】
いくつかの追加の符号化パケットのための要求は、失われたパケットの数に等しいいくつかの符号化パケットを目的としてよい。品質係数の値は、送信トランシーバにより送られる符号化パケットの数を断続的に低減させて、より少ない符号化パケットがデータパケットのブロックの成功裏の送信に必要とされ、これにより向上された電気通信チャネルパフォーマンスが利用されることができるかを判定することによって、さらに更新されてよい。
【００３９】
いずれにせよ、順序が問題でないため、前方誤り訂正の「シーケンスを感知しない（sequence-agnostic）」性質が、パケットフローを再構築することに使用されてよい。さらに、トランスポートレイヤは、自身がブロックを再構築するためにさらなる符号化パケットを待つときでさえ、アプリケーションに順序正しいデータセグメントを配信することができる。
【００４０】
本発明の好適な実施形態に従い、元のデータストリームに追加される冗長度の量は、ネットワーク輻輳を除去するように最適化された先行技術において知られる態様で行われる送信レート調整から独立して、今度はネットワークの状態に従って最適化されることができる。ゆえに、受信器における誤り訂正後の損失レートは、所望される範囲内に保持されることができる。
【００４１】
本発明に従い、第１のパケット送信装置が提供される。第１の送信装置は、ベストエフォート型ネットワークを通して固定期限配信制約なしで保証された配信を有するパケットを送信する。パケット送信装置は、配信されていないパケットの再送信を制御する自動パケット再送信セクションと、冗長情報の送信を制御する消去符号化セクションと、監視されるネットワーク状態に基づいて損失のない接続を維持するために必要な冗長度のレベルを動的に決定する損失推定セクションとを含む。ネットワーク状態は、パケット損失レート、パケット間（inter-packet）到着時間（２個のパケットの到着時間におけるデルタを示す、２個のパケットのタイムスタンプ間のデルタ）及び接続ラウンドトリップタイムを含む収集された情報に基づいて算定される。より長いパケット到着間（inter-arrival）時間と接続ラウンドトリップタイムとは、より遅いネットワークを示唆する。
【００４２】
ゆえに、損失推定セクションは、受信したネットワーク状態に基づいて損失のない接続を維持するために必要な冗長度のレベルを動的に決定するように構成される。好適な実施形態において、ネットワーク状態情報はラウンドトリップタイム情報を含むが、同じものが必要とはされない。
【００４３】
本発明に従い、第２のパケット送信装置が提供される。第２のパケット送信装置は、ベストエフォート型ネットワークを通して固定期限で保証された配信を有するパケットを送信する。好適な実施形態におけるパケット送信装置は、配信されていないパケットの再送信を制御する自動パケット再送信セクションと、冗長情報の送信を制御する消去符号化セクションと、監視されるネットワーク状態情報に基づいて損失のない接続を維持するために必要な冗長度のレベルを動的に決定する損失推定セクションとを含む。ネットワーク状態情報は、パケット損失レートを含むであろう。損失推定セクションは、受信したネットワーク状態に基づいて損失のない接続を維持するために必要な冗長度のレベルを動的に決定するように構成される。好適な実施形態において、ネットワーク状態は、ラウンドトリップタイム情報を含む。
【００４４】
好適な実施形態において、１）受信したネットワーク状態情報、２）データパケットブロックの送信に割り当てられた送信レートの上限値、及び、３）受信器における誤り訂正後、再送信について、指定された損失レートをもたらす冗長パケットに基づいて、送信元トランシーバは、受信器において、再送信について、指定された損失レートをもたらす冗長パケットの数を動的に決定する。
【００４５】
好適な実施形態において、装置は、第１及び第２のパケット送信装置を単一の装置に結合して、固定期限の有無にかかわらずデータトラフィックを扱うであろう。
【００４６】
本発明方法は、パケット送信装置において下記の処理機能を提供し、該パケット送信装置は、ベストエフォート型ネットワークを通して到着期限において限定されたパケットを送信する：
（ａ）ユーザプログラム空間に配置され、配信されていないパケットの再送信を制御するパケット自動再送信機能の制御メカニズム、
（ｂ）ユーザプログラム空間に配置され、冗長パケットをデータパケットブロックに追加する消去符号化機能、
（ｃ）ユーザプログラム空間に配置され、受信器における誤り訂正後の損失レートがほぼ再送信なしで配信されていないパケットを回復することを介して達成され、誤り訂正後の許容可能な損失レートを満たすように、監視されるネットワーク状態情報に基づいて冗長データパケットの必要数を動的に決定する冗長度決定機能。
【００４７】
好適な実施形態に従い、各ブロックに追加される冗長度の量は、ネットワークの状態に従って変調されてよい。ゆえに、受信器における誤り訂正後の損失レートは、ネットワークの輻輳を不必要に増加させ、あるいはデータパケットブロックの送信量を不必要に低減させることなく、許容可能な範囲内で保持されることができる。
【００４８】
さらなる特徴及び利点が本明細書に説明され、下記の詳細な説明及び図から明らかになるであろう。
【図面の簡単な説明】
【００４９】
本発明及びその利点のより完全な理解は、下記の説明を添付の図面を考慮して参照することによって得られるであろう。図面において、同様の参照番号は同様の特徴を示す。
【図１】出願人のパケット回復プロトコルを用いたシステムの好適な実施形態を示す。
【図２】図１に示されるタイプのトランシーバのペアを用いて実施される出願人のパケット回復プロトコルを用いたデータ通信システムの好適な実施形態を示す。
【図３】図１の装置において実施することができる本発明方法の好適な実施形態を示す。
【図３ａ】本発明の別の送信スキームを示す。
【図４】図１の装置において実施することができる本発明方法の別の実施形態を示す。
【図４ａ】図３のデータ送信方法論と関連して実施することができるデータ受信方法論の別の実施形態を示す。
【図５】プロキシサーバが使用される典型的なネットワーク構成／システムアーキテクチャを示す。
【図６】出願人の独自ＤＰＲ（ＴＭ）プロトコル送信メカニズムを示す。
【図７】出願人の独自ＤＰＲ（ＴＭ）プロトコル受信メカニズムを示す。
【図８】ＤＰＲソフトウェアローカルアーキテクチャを用いた現在のネットワーク構成の好適な実施形態の概観を、ローカル及びリモートのＤＰＲソフトウェアエンティティそれぞれについて示す。
【図９】ローカルのクライアント側における高レベルＤＰＲソフトウェアアーキテクチャの図８の好適な実施形態を示す。
【図１０】リモートのプロキシ側における高レベルＤＰＲソフトウェアアーキテクチャの図８の好適な実施形態を示す。
【図１１】ＤＰＲ（ＴＭ）接続プロトコルの図式的概観を示す。
【発明を実施するための形態】
【００５０】
図１を参照すると、本発明に従い構築された送信トランシーバ１が示され、送信トランシーバ１は、例えば、図２におけるトランシーバ１ａなどの受信トランシーバとの全二重通信を可能にする。トランシーバ１は選択器２を含み、選択器２は、インターネットなどのデジタルチャネルを通じて送信すべき連続的なパケットストリームを含む入力を受信する。パケットストリームは、一連のデータパケットを含む。こうしたデータパケットが選択器２によって受信され、選択器２は、消去符号化（erasure  coding）に必要な時間に適応するように調整された任意的な最小レイテンシ間隔後、下記に説明されるとおり、所定数のパケットＮを含む最初のブロックのデータパケットを、デジタルチャネルを通じた送信のために送信器３に渡す。
【００５１】
本発明の好適な実施形態に従い、Ｎ個のデータパケットのブロックが、送信トランシーバから受信トランシーバに送られる。上記システムは、いくつかの符号化されたパケット（符号化パケット）も送信する。概して、Ｎ個のデータパケットは、送信される特定のブロックの中のすべての情報を包含し、それから、上記ブロックの全体が、任意の所与のセグメントの間に送信すべきトータル情報を全体で表し、上記セグメントは、例えばインターネットに接続されたあるポイントから別のポイントに移動すべき音楽トラック、ビデオ、文書、画像又は他のアイテムを表し得る。
【００５２】
データパケットのブロックの中のすべてのデータパケットが受信トランシーバにおいて損失なく受信された場合、明らかに、さらなる方策を採用する必要性がない。しかしながら、通常、１又は複数のデータパケットが、特定の送信サイクルの間に失われる可能性が高い。
【００５３】
ゆえに、本発明に従う消去符号化の適用に従い、さらなる符号化パケットが、Ｎ個の生（raw）データパケットと連動して送信される。符号化パケットは、使用される特定の消去符号化方法のエンコードアルゴリズムに従い、送信すべきＮ個の生データパケットから生成されるパケットである。したがって、データ通信チャネルの送信側において、Ｎ個のデータパケットのブロックがエンコードアルゴリズムに入力され、エンコードアルゴリズムは所望数の符号化パケットを生成する。
【００５４】
データ通信チャネルの受信側における受信トランシーバにおいて、受信した生データパケットと受信した符号化パケットとは、符号化方法が使用された場合、デコードアルゴリズムに入力される。それから、このアルゴリズムは、Ｎ個の生データパケットの送信の間に失われた元の生データパケットの再構築を出力する。それから、受信トランシーバにより受信された、受信した生データパケットＮｒが、送信トランシーバにより送信されたＮ個の生データパケットの元のストリームの忠実な複製を組み立てるように、デコードアルゴリズムにより生成された、再構築したデータパケットＮａとインタリーブされる。
【００５５】
消去符号化の形態における前方誤り訂正は、生パケットＮの最初のブロックを図１に示されるトランシーバのメモリ４に記憶することによって容易にされる。消去符号化はエンコーダ５によって実施され、エンコーダ５はＭ０個の符号化パケットを生成する。Ｍ０は、データパケットと連動して送るべき符号化パケットの最初の数であり、Ｍのデフォルト値に等しい。このＭ０は任意であってよいが、好ましくは、予期される品質障害又は予期される送信チャネルのありそうな脆弱性の範囲に基づいて設定される。符号化パケットは、使用される特定の消去符号化スキームによって回復されるパケットに関連して、失われたパケットの置換を可能にするように生成される。下記で参照されるタイプの消去符号化方法論を用いて、符号化パケットは、失われたパケットを生成するために使用される。
【００５６】
リードソロモンエンコードなどの他の前方誤り訂正スキームが本発明に従い使用されてもよいことにも留意されたい。他の適切な消去符号化スキームが、当分野において周知であり、本発明に採用されてよい。
【００５７】
図１のシステムを用いたあり得る適用において、生パケットの数Ｎは、例えば、１００であってよい。こうした適用において、通常、チャネルにおける９８％の信頼度のレベルに直面することがある。これは、２個の符号化パケット（Ｍ＝２）を１００個のデータパケットと共に送信することによって、１００個すべてのデータパケットの成功裏の送信をおそらく提供するであろう。２個の符号化パケットの各々はエンコーダ５によって生成され、送信すべき合計１０２個のパケットをもたらす。しかしながら、信頼性のある受信の側における誤りに対して、（送信が始まるときに採用される）Ｍ０のデフォルト値は、比較的高く、例えば５個の符号化パケットに設定されてよく、これは、５％（Ｍ／Ｎ）の損失に対応する。
【００５８】
このデフォルト値はエンコーダ５によって使用され、エンコーダ５は５個の符号化パケットを生成し、この５個の符号化パケットは送信器３に出力される。本発明の好適な実施形態に従い、５個の符号化パケットがエンコーダ５によって生成されると、任意的な最小レイテンシ遅延を用いて、送信器３による１００個のデータパケットの送信に続いて、上記の５個の符号化パケットが送信器３を介して送信される。ゆえに、システムは、１００個のデータパケットと５個の符号化パケットとを含む１０５個のパケットを送信している。
【００５９】
デジタルチャネル（例えば、ＴＣＰ／ＩＰチャネル）の性質は、良好な使用可能なデータパケットだけが受信されるというものである。したがって、誤りは、消失パケットの形をとる。１００個のデータパケットの送信ラインの受信端において、受信したすべてのデータパケットが数えられ、デジタル通信チャネルの他端において受信したデータパケットの数は、トランシーバ１の受信器部分６に返信される。この情報は、例えば、コンピューティングデバイス７に送られ、コンピューティングデバイス７は、１００個すべてのデータパケットの送信が成功する可能性が非常に高い状態にするために必要な符号化パケットの数Ｍの推定を決定するようにプログラムされる。この情報は、さらに十分に下記に現れるとおり、２つの目的に使用される。第１は、Ｍの改訂値Ｍ１を提供することである。次のブロックのデータパケットの送信の間、Ｍ１が使用され、Ｍ０（デフォルト値）は破棄される。第２に、この情報は、すべてのデータパケットが受信されていない場合、どれほど多くの追加パケットがパケットのブロックを成功裏に送信するために必要とされるのかをシステムに教える。さらに十分に下記に現れるとおり、上記の追加パケットは、システムが次のブロックのデータパケットに進む前に、システムによって送信される。上記の追加符号化パケットの各々はすべて、符号化パケットの最初の組の中の符号化パケットの各々とは異なることにも留意されたい。このことは、十分な種々の符号化パケットが、失われたデータパケットを再構築するために受信トランシーバにおいて利用可能であることを確保する。
【００６０】
上記のパケット損失情報を取得し、これを使用してＭ０の値（又は、Ｍの任意の後続値）が増加されるべきか、減少されるべきか、あるいは変更されないままとされるべきかを判定するために、様々なアルゴリズムが使用されてよい。本発明に従い、Ｍの値の再推定とその値の可能な調整とが、データパケットの各ブロックの送信に関連して行われる。このことは、下記の例から理解することができる。
【００６１】
例えば、最初のシステム設定がブロック＝１００及びＭ０＝５であり、１００個すべてのデータパケットが成功裏に受信されたと仮定する場合、デジタル通信チャネルの予期される品質を考慮すると、コンピューティングデバイス７は、Ｍの値を５（Ｍ０）から４（Ｍ１）に低減してよい。ゆえに、次の周回において、１００個のデータパケットの第２のブロックとエンコーダ５により消去符号化によって生成された４個の符号化パケットとが送信されることになる。
【００６２】
コンピューティングデバイス７に常駐するアルゴリズムに従い、選択器２に入力される連続的なデータパケットストリームからの継続的なデータのブロックにおける１００個すべてのデータパケットの継続的な成功裏の送信が、Ｍが例えば２に到達するまで、数Ｍの継続的な低減をもたらしてよい。上記例は、例えば、送信器部分３によりアクセスされるデジタル通信チャネルの特性がよく知られており、１個の符号化パケットだけでブロックを成功裏に送信する品質にしばしばなるとは予期されない場合である。通信チャネルが、より良好な信頼性が時折生じることがあるものである場合、コンピューティングデバイス７は、所与のブロックの中の１００個のデータパケットを成功裏に送信することの度重なる失敗があるまで、Ｍを１に低減し、Ｍをその値において保持することによってチャネルを周期的にテストするようにプログラムされてよい。このようなものとして、度重なる失敗は、これを引き起こし得る様々な要因のいずれか、例えば輻輳、天候などに起因した、通信チャネルにおけるより長い期間の劣化を示すであろう。
【００６３】
同様にして、同じ方法論を用いて、コンピューティングデバイス７は、Ｍを増加させ、Ｍ１を６、７若しくはより大きい値に等しくし、これを延長された時間の間そこで保持し、再度、チャネルを周期的にテストしてチャネル信頼性が増しているかを判定することによって、低減された通信チャネルパフォーマンス（例えば、通信チャネルの他端におけるリモートトランシーバからの、９４個のデータパケットだけが受信されたという報告）を受け入れてもよい。受信器６が、あらゆる送信について、連続的なパケットストリームの中で１００個より少ないデータパケットが選択器２に入力されたときを示すことになるため、当然ながら、非信頼性を判定するためのチャネルのテストは必要とされない。
【００６４】
本発明に従い、受信したデータパケットの数は、送信器３により利用されるデジタル通信チャネルの他端において数えられ、この情報は、通信チャネルを通じて受信器６に送られ、受信器６は、この情報をコンピューティングデバイス７に送る。
【００６５】
同様にして、トランシーバ１の受信側を考えると、トランシーバ１は、さらに、通信チャネルの他端におけるリモートポイントから上記と同様の態様で送信されたデータを受信するため、デコーダ８が、リモート送信ポイントから受信器６が受信した良好なデータパケットの数を数えるように提供される。それから、さらに十分に下記に現れるとおり、受信したデータパケットの数は、デコーダ８によって送信器３に伝えられ、送信器３は、この情報を、送信器３及び受信器６により使用される例えば全二重デジタル通信チャネルの他端におけるリモート送信ポイントにおけるリモートトランシーバに送る。
【００６６】
本発明は、双方の通信トランシーバにより送信される情報において完全な対称性があり、あるいはデータ負荷がかなり非対称であるシステムに適用されてよいことに留意されたい。
【００６７】
本明細書において言及されるとおり、エンコーダ５は、消去符号化を実施する。デコーダ８は、データパケットとエンコーダ５により生成されたタイプの符号化パケットとを受信し、消失データパケットの内容について解決するようにプログラムされる。開示される実施形態に従い、エンコーダ５と同一の特性を有するエンコーダが、全二重通信チャネルの他端において、トランシーバ１と全二重通信するリモートトランシーバの中に位置することが考えられる。
【００６８】
全二重デジタル通信チャネルの他端においてリモートトランシーバから受信した、成功裏に送信されたデータパケットは、デコーダ８によって検出され、メモリ９に送られる。デコーダ８は、データパケットの完全なブロックが受信されたと判定したとき、この情報をメモリ９に伝える。メモリ９はこの情報を、メモリの中の別の、場合によりさらに永続的な場所に、あるいは下流のデバイスにダウンロードするように指示されてよい。
【００６９】
送信方法論に戻ると、上記に示唆されたとおり、時折、ことにより頻繁に、選択器２に入力される連続的なパケットストリームからの１００個のデータパケットの特定のブロックにおける１００個未満のデータパケットが受信されることになる。このことが生じたとき、従来技術、例えばＵＤＰシステムとは対照的に、データパケットは再送信されない。ＴＣＰシステムにおいては、生データパケットが再送信される。
【００７０】
むしろ、本発明に従い、消失データパケットの数が受信器６からコンピューティングデバイス７に伝えられ、追加の時間、データパケットを送信することに代わって、符号化パケットが送信される。同様にして、必要とされる場合、消失パケットを再生成するために符号化パケットが送信される。
【００７１】
失われたパケットの数がＭ０より大きい場合、最初の損失推定値Ｍ０と消失パケットの実際の数Ｍ１とにおけるデルタが算定される。消失パケットのすべてを再生成するようにメッセージがエンコーダに送られ、したがって、Ｍ１−Ｍ０個の追加の符号化パケットが生成されることができる。
【００７２】
上記に示唆されたとおり、多数のデータパケットがチャネルの他端において消失している場合、Ｍは、デフォルト推定の５から、比較的大きい数に変更されるであろう。例えば、Ｍ０が５に最初設定され、８個のデータパケットが消失したと判定された場合、最低でも、３個のさらなる符号化パケットを送信することが必要であり、ゆえに、最初の例において、合計８個の符号化パケットを作ることになるであろう。こうした例において、Ｍ１は、８に設定されるであろうし、エンコーダ５により生成されるであろう追加の３個の符号化パケットが送信されるであろう。
【００７３】
しかしながら、上記システムは、最初、過度に補償していることがあり、例えば、Ｍを１２に設定し、７個の追加の符号化パケットを送信することがある。消去符号化スキームに従い、消失データパケットを生成するために、追加の符号化パケットと元の符号化パケットとは、対象ブロックの１００個のデータパケットからの成功裏に送信され及び受信されたデータパケットと一緒に使用されるであろう。
【００７４】
消去符号化スキームに従い、消失データパケットを生成し、必要な１００個のデータパケットをデコーダ８から記憶装置９に再作成するために、受信した生パケットと受信した消去符号化されたパケット（消去符号化パケット）（erasure  coded  packets）とが一緒に使用されるであろう。上記必要な１００個のデータパケットは、元のデータパケットと符号化パケットとのいくつかの部分の組み合わせである。
【００７５】
この態様において、大きいブロックのデータパケットの再送信は複数回回避される。
【００７６】
先へ進めると、Ｍ１は現在、新しい損失推定値である。上記の例において、Ｍ１は８であった。Ｍｎは、次の組のパケットのための損失推定値がＭｎの最新値に基づくように調整され続ける。
【００７７】
損失レート値Ｍの連続的な調整は好適な実施形態であるが、Ｍの最初の値とＭの値の調整とはユーザ必要性に従って変えられてよいことが理解される。所望される場合、最初の損失推定はゼロパケットに設定されてよく、したがって、最初の損失推定は、パケット損失があるまで設定されない。
【００７８】
符号化パケットは成功裏に受信されないことがあり、それから、置換符号化パケットを生成し、送信することが必要になることにさらに留意されたい。置換符号化パケットの生成は、使用される特定の前方誤り訂正又は消去符号化スキームによって決定される。したがって、デコーダ８は、全二重通信チャネルの他端におけるトランシーバの部分によって受信器６に提供される情報に基づいて、データパケット又は符号化パケットが消失しているかを判定するように機能し、上記トランシーバの部分は、デコーダ８の機能を実行している。
【００７９】
図２を参照すると、トランシーバ１とリモートトランシーバ１ａとを含むデータ通信システムが示されている。トランシーバ１ａは、トランシーバ１と実質的に同一である。トランシーバ１ａは、選択器２ａ、送信器３ａ、メモリ４ａ、エンコーダ５ａ、受信器６ａ、コンピューティングデバイス７ａ、デコーダ８ａ及びメモリ９ａを含み、これらはそれぞれ、トランシーバ１における選択器２、送信器３、メモリ４、エンコーダ５、受信器６、コンピューティングデバイス７、デコーダ８及びメモリ９の態様において動作し、互いに協働する。トランシーバ１とトランシーバ１ａとは、トランシーバ１により送信される信号を受信するトランシーバ１ａとトランシーバ１ａにより送信される信号を受信するトランシーバ１とで示されるとおり、デジタルチャネルを通じて互いに結合される。
【００８０】
図３を参照すると、本発明方法１０が、汎用目的コンピュータ上のソフトウェアとして実施することができる処理ステップの観点から理解されるであろう。システムへの入力は、各々Ｎ個のデータパケットのウィンドウに形作られることができるデータパケットの連続的なシーケンスである。これらＮ個のデータパケットが、方法１０を実施するシステムにおいて、ステップ１２において受信される。本発明に従い、これらＮ個のデータパケットは、デジタルデータ通信チャネルを通じてリモートポイントに送信される。
【００８１】
本発明方法が開始されると、本発明方法を実施するシステムは、Ｎ個のデータパケットのうちＭ０個のデータパケットが失われることになると仮定するデフォルト損失推定を最初採用する。Ｍは、ゼロ、又は３若しくは５などのより大きい整数で表されてよく、あるいは、パケットのブロックのパーセンタイル部分として規定され、ソフトウェアによりパケットの数を算定した後に整数に丸められてもよい。ステップ１４において、この推定は、採用される消去符号化アルゴリズムのエンコードアルゴリズムに提供される。より具体的に、ステップ１６において、特定の消去符号化スキームに関連付けられた消去符号化アルゴリズムをプログラムされたコンピューティングデバイスが、符号化パケットを生成するように実施され、この符号化パケットは、受信トランシーバにおいて、失われたパケットを再構築する機能を実行するために使用されてよい。より具体的に、好適な実施形態に従い、受信したデータパケットと関連する符号化パケットとは、失われたデータパケットを生成するために、受信トランシーバにおいてデコードアルゴリズムに入力される。ステップ１６において、消去符号化が、選択された消去符号化スキームに従い実行され、符号化パケットの生成をもたらす。この符号化パケットは、十分な符号化パケットとデータパケットとが受信されていて上記の再構築を可能にするならば、送信の間に失われた任意のデータパケットを再構築することに使用されてよい。
【００８２】
符号化パケットが生成されているとき、ステップ１８において、データパケットは、一時記憶のために一時メモリセクタに伝送される。Ｎ個のデータパケットのブロックのコピーが、好ましくはステップ１９において記憶される。パケット損失が、送信されるデータを受信するリモートトランシーバにおける消去符号化デコードアルゴリズムによってすべての失われたパケットを回復させるのに十分な失われたパケットの数を超える事象において、将来使用されてよい。同様にして、ステップ１６において生成された符号化パケットは、ステップ２０において、同様に一時記憶のために一時メモリセクタに伝送される。データパケットと符号化パケットとは、ステップ２２において、一時メモリからダウンロードされ、ステップ２４において、受信のリモートポイントにおける受信トランシーバにすべて送信される。好適な実施形態に従い、データパケットと符号化パケットとがステップ２４において送信されるとき、各々のデータパケットと符号化パケットとは、それ自体がデータパケットであるか、あるいは符号化パケットであるかを示す識別子を有する。
【００８３】
ステップ２６において、トランシーバは、Ｎ個のデータパケットのうちいくつが失われたか（ＮＬ）を示す報告を受信する。
【００８４】
下記に論じられるとおり、ＮＲがＮより小さい場合、いくつかの補足的な符号化パケットＰＳを送信することが必要であり、ここで、ＰＳは、式：
ＰＳ＝ＮＬ−Ｍ０
によって定義される。
【００８５】
本発明に従い、補足的なパケットＰＳの合計数は、失われたパケットがデータパケットであるか、あるいは符号化パケットであるかにかかわらず、失われたパケットの合計数によって決定されることに留意されたい。しかしながら、損失がデータパケットであるか、符号化パケットであるか、あるいはデータパケットと符号化パケットとの組み合わせであるかにかかわらず、符号化パケットだけがリモートトランシーバに送信される。それから、受信トランシーバに関連付けられ、使用される特定の消去符号化スキームのためのデコードアルゴリズムを備えたコンピューティングデバイスが、受信したデータパケットと必要数の符号化パケットとを取得し、デコードアルゴリズムを実行して、受信されなかったデータパケットを再構築する。デコードアルゴリズムは、受信したデータパケットと受信した符号化パケットとを処理することによって、失われたデータパケットの情報内容を算定する。
【００８６】
図３に示されるデータ通信送信方法論に戻ると、ステップ２８において、失われたパケットの数を伝える報告が送信トランシーバによって受信され、さらなる符号化パケットが必要とされるかについて、判断が行われる。より具体的に、すべてのデータパケットとすべての符号化パケットとが受信されている場合（あるいは、リモートトランシーバが、失われたデータパケットを再構築するほど十分なデータパケットと符号化パケットとを受信している場合）、システムはステップ３０に進み、ここで、Ｍは、パケット損失の履歴と場合により送信チャネル特性とを考慮して推定され、更新される。上記に示唆されたとおり、Ｍは、増加し、減少し、あるいは同じままであってよい。Ｍの新しい値Ｍｊがステップ３０において算定され、ステップ３２において、Ｍのいかなる以前の値もが、Ｍの新しい値で置換される。
【００８７】
それから、システムはステップ３４に進み、ステップ３４において、次のブロックのＮ個のパケットがシステムに入力される。ステップ１６において、上記次のブロックのＮ個のパケットは、（ステップ３２において更新されたとおりの）いくつかの符号化パケットＭｊを生成するために、エンコード消去符号アルゴリズムを用いて処理され、上記符号化パケットは、次の組の符号化パケットを構成する。それから、次の組の符号化パケットと次のブロックのＮ個のパケットとが、上記で説明された方法論に従い送信される。
【００８８】
しかしながら、判断ステップ２８において、すべてのデータパケットを再構築するほど十分なデータパケットと符号化パケットとがリモートトランシーバによって全体的に受信されていない場合、追加の符号化パケットがリモートトランシーバに送られる必要がある。したがって、システムはステップ３６に進み、ステップ３６において、必要数の置換データパケット（ステップ２６の報告に基づく）が生成される。補足的な符号化パケットは、ステップ１９において記憶された元の生データパケットを用いて生成される。補足的な符号化パケットはすべて、現在のデータパケットブロックに関連付けられた以前の符号化パケットから異なる。置換データパケットの数は、受信したデータパケットから失われたデータを再構築するために必要とされる符号化パケットの数に等しい。好適な実施形態に従い、符号化パケットの数が、失われたデータパケットの数に等しく、あるいはより大きくなければならない消去符号化スキームが使用される。
【００８９】
上記に示唆されたとおり、失われたパケットＰＬの数がＭの以前の推定値（Ｍｐｒｅｖｉｏｕｓ）より大きい場合、いくつかの補足的な符号化パケットＰＳを送信することが必要であり、ここで、ＰＳは、式：
ＰＳ＝ＰＬ−Ｍｐｒｅｖｉｏｕｓ
によって定義される。
【００９０】
したがって、システムはステップ３０に戻り、ステップ３０において、システムはＭの推定値をＭ＋ＰＳに増加させる。
【００９１】
システムはステップ３８にも進み、ステップ３８において、ステップ３６において生成された補足的な符号化パケットがリモートトランシーバに送信される。それから、システムは、リモートトランシーバから、パケットが成功裏に受信されたかを示す報告を受信し、それから、判断ステップ２８において同じことを判定した後、システムは、現在のブロックのＮ個のパケットがすべて十分に受信され、あるいは再構築されるまで、上記で説明されたとおりに進む。この条件が合ったとき、システムはステップ３４に進み、ステップ３４において、システムは、上記で説明されたとおり、次のブロックのＮ個のデータパケットに進む。
【００９２】
システムは、送信すべきデータパケットシーケンスの中のすべてのデータパケットが送信されて、成功裏に受信され、あるいは再構築されるまで、上記で説明されたとおり、Ｎ個のデータパケットの継続的なブロックを送り続ける。
【００９３】
図３ａを参照すると、本発明に係る方法に従う別の送信スキーム（これは、本明細書に説明される他の方法と同様に、汎用目的コンピュータ上で実行されるソフトウェアにおいて具現化される）が、示されている。ステップ５０において、システムは、個々のパケット、例えば、連続的なパケットストリームの中の最初のパケット又は後続のパケットを受信する。ステップ５２において、ステップ５０において受信されたパケットが記憶される。ステップ５４において、記憶されたパケットはリモートトランシーバに送信され、カプセル化もされる。上記カプセル化は、例えば、消去符号化スキームのエンコードアルゴリズムに入力されることによってなされ、任意の失われたパケットを再構築するために使用すべきカプセル化された生パケット又はカプセル化された冗長符号化パケットの生成に後に使用される。
【００９４】
ステップ５６において、システムは、ブロックの中のＮ個のパケットすべてが入力され、記憶され、送信され、カプセル化されたかを判定する。上記が当てはまる場合、Ｎ個のデータパケットの完全なブロックがシステムに入力されており、符号化パケットの生成が始まってよい。
【００９５】
しかしながら、ステップ５６において、Ｎ個のパケットすべてが受信されていない場合、システムは、ステップ５０に戻り、次のパケットを受信し、Ｎ個のデータパケットの完全なブロックがシステムに入力されるまで上記シーケンスを繰り返す。
【００９６】
Ｎ個のデータパケットの完全なブロックがシステムに入力されると、システムはステップ５８に進む。ステップ５８において、好適な消去符号化アルゴリズムに従い、システムは、Ｎ個の元のデータパケットの内容を直線的に結合することよって、結合（「符号化」ともいう）パケットを生成する。ステップ６０において、ステップ５８において生成された結合パケットが送信され、システムはステップ６２に進み、ステップ６２において、Ｍのデフォルト値が、単一ブロックのデータパケットに対して予期される数のパケット損失に同等に、あるいはより大きく設定される。それから、ステップ６４において、システムは、Ｍ個の符号化パケットすべてが生成され、送信されたかを判定する。すべてのＭ個のデータパケットがステップ６４において設定されていない場合、システムはステップ５８に進み、ステップ５８において、別の符号化パケットが、リモートトランシーバに対する送信のために計算される。
【００９７】
Ｍ個のデータパケットが生成されている場合、十分な情報が受信トランシーバによって受信されていることが合理的に明白である。しかしながら、ステップ６６において、システムは、システムにより送信されたＮ個のデータパケットすべての再構築を可能にするほど十分な数のパケットが受信されているというリモート受信トランシーバからの報告を待つことによって、信頼性を提供する。受信されているパケットの数Ｋが、送られた生パケットの数Ｎより小さい場合、Ｎ個の元のデータパケットのすべてを再構築するほど十分なパケットが受信トランシーバになく、上記Ｎ個の元のデータパケットは、送信の間に失われている可能性がある。したがって、システムはステップ７０に進み、ステップ７０において、Ｍがより大きい数、例えばＭの元の値プラス１に更新される（１個の結合パケット又は符号化パケットだけが失われたデータパケットを生成するために必要である場合であり、あるいは、必要とされる場合、より大きい数による）。例えば、５個の追加の符号化パケットが必要とされる場合、Ｍは５まで増加されてよい。ゆえに、Ｍは、Ｍ＋（Ｎ−Ｋ）に等しい値に更新されてよい。
【００９８】
使用されているデジタルチャネルについて経験した十分でない送信特性を反映するようにＭの値を設定することに加えて、失われたデータパケットを再構築するほど十分な数の符号化（すなわち、結合された）パケットを生成し、送信することが必要である。このことは、システムがステップ５８に戻ることによって行われ、ステップ５８において、追加の符号化パケットが生成され、それから送信され、上記追加の符号化パケットが受信された場合、受信トランシーバによってその受信を確認される。
【００９９】
ステップ６８において、受信トランシーバにより受信されたパケットの合計数がＮより少なくない場合、すべての消失データパケットを再構築するほど十分な数のパケットが受信されており、システムはステップ５０に進んでよく、ステップ５０において、次のブロックのデータパケット送信が、上記で詳述されたとおりに進む。このことは、送信におけるすべてのブロックのデータパケットとそのすべての組成データパケットとが送信されて、成功裏に受信され、あるいは再構築されるまで、繰り返される。
【０１００】
本発明に従い採用することができる受信方法論に従い、図４に概して示されるとおり、ステップ１１０において、パケットが送信トランシーバから受信される。ステップ１１２において、受信したパケットが記憶される。それから、システムはステップ１１４に進み、ステップ１１４において、受信したパケットは、上記ダウンロードを受信するアプリケーションに伝送される。それから、システムはステップ１１６に進み、ステップ１１６において、Ｎ個のパケット（すなわち、ブロック全体）が受信されている場合、システムはステップ１１８に進み、ステップ１１８において、記憶されたパケットが解放される。Ｎ個のパケットが受信されているため、ステップ１２４において判定されるとおり、損失回復は必要とされず、ステップ１２２において、システムは、パケットの受信数ＫがＮに等しいことを報告する。
【０１０１】
ステップ１１６において、Ｎ個のパケットが受信されていない場合、システムはステップ１２０に進み、ステップ１２０において、Ｎ個のパケットのブロックの受信部分のうち最後のパケットが受信されているかが判定される。Ｎ個未満のパケットが受信されているが、ブロックの中の最後のパケットが受信されている場合、パケットは失われており、これが、Ｎ個より少ないパケットが受信されている理由である。それから、パケットの受信数Ｋが、ステップ１２２において送信トランシーバに報告され、置換符号化パケットが、送信トランシーバによって送られる。
【０１０２】
置換符号化パケットは、ステップ１１０において受信され、再構築を可能にするほど十分なパケットが受信されているとシステムがステップ１１６において判定するまで、上記方法論に従い処理される。それから、システムはステップ１１８に進み、ステップ１１８において、パケットは記憶装置から解放される。ステップ１２４において、システムは、失われたパケットが回復されるべきであるか、及び回復されることができるかを判定するであろう。回復は、ステップ１２６において実行される。このことは、ステップ１２２において送信トランシーバに報告される。
【０１０３】
ステップ１２０において、ブロックの最後のパケットが受信されていない場合、受信したパケットは、別の、例えば、現在のブロックの中のパケットであり、あるいは新しいブロックのデータパケットからのパケットである。新しいブロックからのパケットでない場合、ステップ１２７において、システムはステップ１２２に進み、ステップ１２２において、受信したパケットの合計数Ｋが上記のとおり報告される。しかしながら、パケットが新しいブロックのデータパケットからである場合、システムはステップ１１０に進み、ステップ１１０において、システムは新しいブロックのパケットを受信し続ける。
【０１０４】
図４ａを参照すると、本発明方法に従うデータ受信方法論１００ａの一例示的な別の実施形態が示されている。ステップ１１０ａにおいて、（例えば、図３の方法により提供されるとおりの）Ｎ個のデータパケットとＭ個の符号化パケットとのブロックの、インターネットなどのデジタル通信チャネルを通じた送信に応答して、受信トランシーバが、送信トランシーバ（例えば、図３の方法論に従い動作する送信トランシーバ）により元々送信されたＮ個のデータパケットとＭ個の符号化パケットとのブロックのうちいくつか又はすべてを構成するＮｒ個のデータパケットとＭｒ個の符号化パケットとを受信する。
【０１０５】
システムにより使用される特定の消去符号化アルゴリズムに従い消失データパケットを置換するために使用されるように送信トランシーバシステムにより生成された符号化パケットは、受信されると、ステップ１１２ａにおいて記憶される。同様にして、データパケットもまた、受信されると、ステップ１１４ａにおいて記憶されてよい。符号化パケットとデータパケットとは双方、それ自体が符号化パケットであるかデータパケットであるかを示す指標を有するようにヘッダにおいて符号化される。
【０１０６】
ステップ１１６ａにおいて、受信トランシーバシステムは、受信しているデータパケットの数Ｎｒと受信している符号化パケットの数Ｍｒとを数える。ステップ１１８ａにおいて、受信トランシーバは、すべてのデータパケットが受信されているかを判定する。上記が当てはまる場合、システムはステップ１２０ａに進み、ステップ１２０ａにおいて、ステップ１１４ａにおいて記憶されたＮ個のデータパケットは、これらが受信されたか、あるいはこれらがデータパケットのブロックの最初の送信の間にまず失われ、それから、例えば受信したデータパケットと符号化パケットとを用いて例えば上記で規定されたアルゴリズム又は別の消去符号化方法論に従い再構築されたかにかかわらず、すべてのデータパケットを蓄積する機能を実行するメモリにダウンロードされる。
【０１０７】
それから、ステップ１２２ａにおいて、システムは、第１のブロックのＮ個のデータパケットの受信及び／又は再構築を確認し、この情報を送信トランシーバに送ることによって次のブロックのＮ個のデータパケットを要求する。
【０１０８】
送信されたＮ個のデータパケットのすべてが受信されなかった場合、ステップ１１８ａにおいて、システムはステップ１２４ａに進み、ステップ１２４ａにおいて、受信したデータパケットの数と合わせた受信した符号化パケットの数が、使用される特定の消去符号化方法に従う失われたデータパケットの再構築を可能にするかどうかが判定される。より具体的に、受信したデータパケットの数と受信した符号化パケットの数との加算が、現在のブロックの中のデータパケットの数より大きく、あるいは等しい場合、システムは、上記で規定された消去符号化アルゴリズムを使用して、採用される特定の消去符号化方法論に関連付けられたデコードアルゴリズムを用いて失われたデータパケットを再構築するための、十分な情報を有する。
【０１０９】
それから、このデコードアルゴリズムがステップ１２６ａにおいて実行され、Ｎ個のデータパケットのブロックの最初の送信の間に失われたデータパケットすべての生成をもたらす。より具体的に、ステップ１１４ａにおいて記憶された元の生データパケットとステップ１１２ａにおいて記憶された符号化パケットとが、受信トランシーバにおいてデコードアルゴリズムに入力される。それから、デコードアルゴリズムが使用されて、失われたパケットの内容を計算し、同じものの再構築を生成する。
【０１１０】
それから、ステップ１２６ａにおいて実行される消去符号化スキームのデコードアルゴリズムを用いて生成された再構築データパケットは、ステップ１１４ａにおいて記憶されたデータパケットと結合されて、デジタルデータ通信チャネルの他端における送信トランシーバにより元々送られたＮ個のデータパケットのブロックの情報内容を有するＮ個のデータパケットの完全な組を形成する。それから、システムは進んで、ステップ１２０ａにおいて、Ｎ個のデータパケットの再組み立てされたブロック（うまく受信されたデータパケットと消去符号化スキームに関連付けられたデコードアルゴリズムを用いて再構築されたデータパケットとを含む）を記憶し、ステップ１２２ａにおいて、データシーケンスの中の次のブロックのデータパケットを要求する。
【０１１１】
ステップ１２４ａにおいて、受信トランシーバが、失われたデータパケットを再構築するほど十分な符号化パケットを有していないと自身が判定した場合、システムはステップ１２７ａに進んで、追加の符号化パケットを要求する。この要求は送信トランシーバに送られ、送信トランシーバにおいて、消去符号化及び符号化アルゴリズムが使用されて追加の符号化パケットを生成する。この追加の符号化パケットは、すべての以前に生成された、現在のブロックのＮ個のデータパケットに関連付けられた符号化パケットとは、異なる。
【０１１２】
ステップ１２８ａにおいて送信トランシーバから受信トランシーバが受信した補足的なパケットは、ステップ１２４ａにおいて十分性について再度テストされ、ステップ１２４ａにおいて、システムは、すべてのうまく受信したデータパケット及び受信した符号化パケット（現在のブロックの中の情報の最初の伝送におけるＮｒ個の受信データパケットと共に最初の送信において受信したものを含む）が失われたデータパケットの再構築を可能にするほど十分であるかを判定する。上記が当てはまる場合、システムは、ステップ１２６ａに進んでよく、そうでない場合、システムは、必要とされるデータパケットを受信するために要求し、試行するサイクル（ステップ１２７ａ及び１２８ａ）を繰り返さなければならない。
【０１１３】
図３に示される送信方法論の実施形態に従い、送るべき符号化パケットの数に関する判断は送信トランシーバにおいて行われるが、この判断は受信トランシーバにおいて行われることも可能である。
【０１１４】
図１乃至図４に関連して説明された、データパケット再送信なしで完全なパケットブロック受信を確保する出願人の独自ＤＰＲ（ＴＭ）プロトコルの好適な実施形態は、プロキシベースのシステムにおいてＤＰＲ（ＴＭ）プロトコルを使用することである。
【０１１５】
透過型プロキシが、いかなる特別なクライアント構成も必要とすることなく、ネットワークレイヤにおける通常の通信を横取りする。クライアントは、プロキシの存在に気付く必要がない。透過型プロキシは、通常、クライアントとインターネットとの間に位置し、このプロキシは、ゲートウェイ又はルータの機能のうちいくらかを実行する。透過型プロキシは、要求又は応答をプロキシ認証及び識別に必要とされることを超えて修正しないプロキシである。非透過型プロキシは、いくらかの追加サービス、例えば、グループアノテーションサービス、メディアタイプ変換、プロトコル低減又は匿名性フィルタリングなどをユーザに提供するために要求又は応答を修正するプロキシである。使用され得るタイプの非透過型プロキシは、ＳＯＣＫＳプロキシである。ＳＯＣＫｅｔ  Ｓｅｃｕｒｅ（ＳＯＣＫＳ）は、プロキシサーバを通してクライアントとサーバとの間のネットワークパケットのルートを決定するインターネットプロトコルである。ＳＯＣＫＳ５は認証をさらに提供し、ゆえに、承認されたユーザだけがサーバにアクセスすることができる。実際には、ＳＯＣＫＳサーバは、任意のＩＰアドレスに対するＴＣＰ接続と、ＵＤＰパケットが転送される手段の提供とをプロキシする（proxy）ことになる。ＳＯＣＫＳは、ＯＳＩモデルのレイヤ５  −  セッションレイヤ（プレゼンテーションレイヤとトランスポートレイヤとの間の中間レイヤ）において機能する。
【０１１６】
１．通常のトポロジ
図５は、ネットワークプロキシが使用されるシステム２００の通常のネットワーク構成を示す。システム２００は、１又は複数のクライアントデバイス２０２を含み、クライアントデバイス２０２は、インターネットインフラストラクチャのどこかに位置付けられたプロキシサーバに論理的に接続されてインターネットと通信する。各クライアントデバイス２０２は、データパケット２０８をＴＣＰ／ＵＤＰソケット２１０を介してＩＰレイヤ２１２を通して送る１又は複数のアプリケーション２０６を含み／含有し、それから、ＩＰレイヤ２１２は、データパケット２１４をシステムスタック（Ｌ２‐Ｌ１）２１６を通して送り、これにおいて、Ｌ４はＴＣＰ／ＵＤＰであり、Ｌ３はＩＰである。クライアントデバイス２０２上で実行されるアプリケーション２０６は、要素２０８、２１０及び２１６を含む標準のシステムスタック（Ｌ４‐Ｌ１）を介してプロキシサーバ２０４と通信する。
【０１１７】
プロキシサーバ２０４もまた標準のシステムスタック２２０を含み、標準のシステムスタック２２０は、データパケット２０８を受信し、これらをプロキシサーバプロセッサ２２２を通してインターネント２２６への外向けの（outgoing）フルのシステムスタック２２４に送る。すべての接続及び機能は、双方向性である。プロキシサーバ２０４の場所について、特別な要件はない。プロキシサーバ２０４は、フォワードプロキシ又はリバースプロキシとして位置付けられてよく、すなわち、多数のクライアントのための機能を実行するもの若しくは多数のサーバに特別な機能性を届けるもの、又は上記の任意の組み合わせとして位置付けられてよい。
【０１１８】
本発明の好適な実施形態において、ＵＤＰトラフィックについて、パケットは、固定の「生成（generation）」サイズの範囲内で符号化される。生パケットが送信され、符号化パケットが後に続く。フィードバックが、１）タイマ信号、２）到来した現在の生成の最後のパケット、又は、３）新しい生成のパケットによって引き起こされる。
【０１１９】
図６は、出願人の独自のＤＰＲ（ＴＭ）プロトコル送信メカニズム３００の好適な実施形態を示す。符号化は、「生成」と呼ばれる固定サイズグループ３０２の生パケット３０４にわたって実行される。各生成は、「生成ＩＤ」として参照されるシーケンス番号Ｇｉを割り当てられる。Ｎｂは一生成の中のパケットの数を表し、Ｎｒは各生成について生成される固定量の冗長パケットを表す。
【０１２０】
生パケット３０２の生成は、機能ブロック３０６において、各到来パケットの複製生成３０８を作るためにコピーされる。それから、生パケット生成３０２は、固定サイズ生成バッファ（Ｇｉ）３１０を通して渡され、送信器フロー制御３１８に転送される。Ｎｂ個のパケットが累積された後、所定数の冗長パケット（Ｎｒ）３１２が生成３０８に関して消去符号化を用いて計算され、送信器フロー制御３１８に転送される。送信器フロー制御３１８は、Ｎｂ個の生パケット３１０を送り、Ｎｒ個の符号化パケット３１２が後に続き、このことが、受信器３１４に対するデジタル通信チャネル３２０を形成する。生成Ｇｉの生パケット３０８は、受信器３１４がＮｂ個のパケットの受信３１６を確認するまで、保有される。受信器３１４は、ブロック終結（end-of-block）パケット又は異なるブロックに属するパケットが受信されるときまでに受信したＮｂ個のパケット３１６の受信をＡＣＫする（肯定応答する）。Ｎｂ個未満のパケットがＡＣＫされた場合、送信器３１８は、生成Ｇｉのパケットを完全に送るために必要とされる符号化パケット３１２の残り（balance）を計算し、これらを宛先に送る。
【０１２１】
図７は、通信チャネル３２０との接続に使用されるパケット受信メカニズム４００を示す。パケット４０２が、チャネル３２０から受信される。パケット４０２は、フロー制御ブロック４０８によって分離され、生パケット４０４と符号化パケット４０６とに分割される。パケット４０４と符号化パケット４０６とは、消去デコードブロック４１０に送られる。３つのあり得るケースが存在する。第１のケースにおいて、Ｎｂ個の生パケットが受信された場合、生パケット４０４は、さらなる処理なしで機能出力４１２に送られる。第２のケースにおいて、Ｎｒ個未満又はこれに等しいパケットが失われ、すなわちＮＲＡＷ＋Ｎｒ＞＝Ｎｂである場合、生パケット４０４と符号化パケット４０６との組み合わせが消去デコードブロック４１０を介してデコードされ、それから、機能出力４１２に送られる。第３のケースにおいて、Ｎｒ個より多くのパケットが失われ、すなわちＮＲＡＷ＋Ｎｒ＜Ｎｂである場合、ＡＣＫがフロー制御４０５から送信器フロー制御３１８に送られ、追加の符号化パケットを要求する。追加のパケット４０２がチャネル３２０によって受信されたとき、フロー制御４０８は追加の符号化パケット４０６を消去デコードブロック４１０に送ることになる。フルの生成サイズＧｉが回復されたとき、生パケット４０４と符号化パケット４０６との組み合わせは、消去デコードブロック４１０を介してデコードされ、それから、機能出力４１２に送られる。
【０１２２】
図８乃至図１０は、ローカルＤＰＲクライアント５０２とリモートＤＰＲ強化プロキシサーバ５０４との高レベルのソフトウェアアーキテクチャを示す。図５に示されたシステムと同様に、システム５００は、１又は複数のクライアントデバイス５０２を含み、クライアントデバイス５０２は、インターネットインフラストラクチャのどこかに位置付けられたプロキシサーバ５０４に論理的に接続されてインターネット５０５と通信する。各クライアントデバイスは、１又は複数のアプリケーション５０６を含み、あるいは含有し、アプリケーション５０６は、クライアントデバイス５０２内に位置するＤＰＲプロキシクライアント５１０にデータパケット５０８を送る。クライアント５１０は、ＤＰＲエンコードされたデータ５１２をＵＤＰソケット５１４にＩＰレイヤ５１６を通して送ることになり、それから、ＩＰレイヤ５１６は、ＩＰデータパケット５１８をシステムスタック（Ｌ２‐Ｌ１）を通して送ってパケット５２１を生み出す。クライアントデバイス５０２上で実行されるアプリケーション５０６は、上記で説明されたとおり、ＤＰＲプロキシサーバ５０４と通信し、パケット５２１をＤＰＲ保護されたセグメントを通してＤＰＲプロトコルを用いて送る。
【０１２３】
ＤＰＲ強化プロキシサーバ５０４もまた標準のシステムスタック５２２を含み、標準のシステムスタック５２２は、ＤＰＲデータパケット５２１を受信し、これらをプロキシサーバプロセッサ５２４（下記に詳細に説明される）を通してインターネット５０５への外向けのフルのシステムスタック５２６に送る。すべての接続及び機能は、双方向性である。
【０１２４】
プロキシサーバ５２４の場所について、特別な要件はない。プロキシサーバ５２４は、フォワードプロキシ又はリバースプロキシとして位置付けられてよく、すなわち、多数のクライアントのための機能を実行するもの若しくは多数のサーバに特別な機能性を届けるもの、又は上記の任意の組み合わせとして位置付けられてよい。
【０１２５】
しかしながら、クライアントレベル５０２及びプロキシレベル５０４において、データ配信を強化する固有の機能性が存在する。ゆえに、各クライアント５０２は、上記で説明され、図１乃至図４に、好ましくは図６及び図７に示されたとおりのローカルＤＰＲ（ＴＭ）メカニズム５１０を含む。
【０１２６】
図９に詳述されるとおり、ローカルのＤＰＲ（ＴＭ）プロキシクライアント５０２は、ＤＰＲ（ＴＭ）プロキシクライアント５０２がインストールされている同じハードウェアプラットフォーム上で実行されるローカルアプリケーション５０６からデータを受信し、該ローカルアプリケーション５０６にデータを返す。一方、図１０に示されるとおり、ＤＰＲ（ＴＭ）プロキシサーバ５０４は、リモートＤＰＲプロキシサーバがインストールされているハードウェアプラットフォームから離れたデバイス上で実行されるクライアント５０２からデータを受信し、該クライアント５０２にデータを返す。このリモートＤＰＲプロキシと成功裏に接続を確立した複数のローカルＤＰＲプロキシエンティティに対応する複数のＤＰＲ（ＴＭ）セッションを作成し、サービスすることが、さらに必要とされる。
【０１２７】
図９を参照すると、ローカルＤＰＲクライアント５２０について、システム５００のさらに詳細なビューが示される。クライアントデバイス５０２は、アプリケーション５０６を含む。アプリケーションデータ５０８の詳細なビューを見ると、アプリケーションデータ５０８は、内部ループバックソケット５３２に送られるＴＣＰデータ５３０を含み、それから、データ５３４が、ソケット５３２からＤＰＲプロキシクライアントブロック５１０に送られる。
【０１２８】
ＤＰＲプロキシクライアントブロック５１０の詳細なビューを見ると、データ５３４は、ＤＰＲ送信マルチプレクサ５４０に、それからエンコーダ５４２に送られて、ＤＰＲエンコードされたデータ５４４を生み出す。データ５４４は、ＤＰＲプロキシクライアント５１０とＤＰＲプロキシサーバプロセッサ５２４とにおける現在処理されているＤＰＲセッションの数を記録する（keeps  track）ＤＰＲセッションブロック５４６に送られる。
【０１２９】
エンコードされたデータ５４４がＤＰＲセッションブロック５４６によって処理されるとき、ＤＰＲセッションデータ５４４は、（図８において５１２、５１４及び５２０として示された）システムスタック５４８に送られてＤＰＲデータパケット５２１を生み出す。
【０１３０】
反対の経路において、ＤＰＲエンコードされたデータ５２１が、システムスタック５４８によって受信され、それからセッションブロック５４６に送られ、セッションブロック５４６は、ＤＰＲエンコードされたデータ５５０を生み出し、ＤＰＲエンコードされたデータ５５０は、ＤＰＲデコーダ５５２に送られる。デコード後、上記は、生ＴＣＰパケット５５６を生み出すＤＰＲ  Ｒｘ  デマルチプレクサ５５４に送られ、それから、生ＴＣＰパケット５５６は、ループバックＴＣＰソケット５３２に送られ、それからアプリケーション５０６に送られる。
【０１３１】
同様にして、図１０に、ＤＰＲプロキシサーバ５０４の詳細なビューが示される。ＤＰＲプロセッサ５２４が、マルチプレキシング／デマルチプレキシングＴＣＰセッション制御部を含み、該制御部は、送信に関して、後続のＤＰＲ（ＴＭ）処理のために、ローカルアプリケーションにより開始されたＴＣＰセッションのローカル管理と個々のＴＣＰセッションを単一のデータストリームに多重化することとの責任を負う。上記制御部は、受信に関して、ＤＰＲ（ＴＭ）デコードされたデータストリームを複数の個々のＴＣＰストリームに逆多重化する（de-multiplexing）ことの責任も負う。
【０１３２】
到来データ５２１は、システムスタック５２２を介して処理され、ＤＰＲプロキシサーバプロセッサ５２４に送られる。ＤＰＲセッション管理は、ＤＰＲエンコードされたデータ５６２を渡すセッション制御部ブロック５６０において扱われ、ＤＰＲエンコードされたデータ５６２は、ＤＰＲデコーダブロック５６４に、それからＤＰＲ  Ｒｘ（受信）Ｄｅｍｕｘ（デマルチプレクサ）５６６に送られ、それからフルの出力システムスタック５２６に送られ、それからインターネット５０５に送られる。セッション制御部５６０は、クライアント５０２とそのサーバ５０４とにおけるセッションを確立し、あるいは切断することの責任も負う。
【０１３３】
反対の経路において、インターネット５０５からシステムスタック５２６を介してデータを受信すると、それから、ＴＣＰデータ５７０は、ＤＰＲプロセッサ５２４に対してＤＰＲ  Ｔｘ（送信）ＭＵＸ（マルチプレクサ）５７２へと送られ、それから、ＤＰＲエンコードされたデータ５７６を生み出すＤＰＲエンコーダ５７４に送られる。データ５７６は、ＤＰＲセッション制御部ブロック５６０に送られる。それから、ブロック５６０は、ＤＰＲエンコードされたデータ５７６をシステムスタック５２２に送って、ＤＰＲエンコードされたパケットストリーム５２１を生み出す。
【０１３４】
図１１を参照すると、ＤＰＲ（ＴＭ）装備エンティティ又はクライアント５０２（これは、中でも、モバイルデバイス、アプリケーションプロセスであってよい）がＤＰＲ（ＴＭ）チャネル５２１を確立したい場合、ネットワークの中の別のＤＰＲ（ＴＭ）装備デバイス５０４（又はプロキシ）との接続を作ることが必要とされる。接続は、ＴＣＰ接続要求と同様の３ウェイハンドシェイクを用いて確立される。要求６００が、クライアント５０２からサーバ５０４に送られる。確認６０２が、サーバ５０４からクライアント５０２に送られ、リンクパラメータを返す。それから、クライアント５０２は「リンク確立」応答６０４をサーバ５０４に送る。接続は、クライアント５０２又はサーバ５０４の要求ごとに終了される。
【０１３５】
例
下記は、データパケット伝送データフォーマットの２つの例である
ａ）ＤＰＲ（ＴＭ）セッション制御部
【０１３６】
【表１】
2016501464.tif 000003
バイト０は、下記の割り当てテーブルに従いメッセージタイプを定義するフラグを含む：
【０１３７】
【表２】
2016501464.tif 000004
ローカル及びリモートのＤＰＲエンティティが、図１１において上記で説明されたとおり、スリーウェイハンドシェークを交換した後、セッションが確立されたと考えられる。
１．クライアントが、ビット６設定（ＥＳＴＡＢＬＩＳＨ）とＳｅｓｓｉｏｎ＿ＩＤ＝０とを有するパケットを送る。
２．サーバが、ビット６設定と新しく生成されたＳｅｓｓｉｏｎ＿ＩＤ！＝０とで応答する。
３．クライアントが、ビット６＆ビット０設定とサーバからまさに受信したＳｅｓｓｉｏｎ＿ＩＤとで応答する。
【０１３８】
セッションを終了するために、参加エンティティの１つ、ローカル又はリモートのいずれかが、ビット５設定を有するパケットを送ることによってクローズ（closure）を開始し、その他端は、ビット６＆ビット０設定と終了すべきセッションのＳｅｓｓｉｏｎ＿ＩＤとで応答する。
【０１３９】
本発明に従い、下記のセッション制御部データフォーマットが使用される。
【０１４０】
【表３】
2016501464.tif 000005
フラグは、下記のとおり定義される：
【０１４１】
【表４】
2016501464.tif 000006
セッションは、ＳＲＣ／ＤＳＴポート番号をＣＯＮＮＥＣＴフラグ（ビット＃３）設定と共に有するパケットを送るクライアントによって常時開始される。サーバは、フラグのＣＯＮＮＥＣＴ（ビット＃３）及びＡＣＫ（ビット＃０）の設定と共に、同一ポート番号を返す。セッションを閉じるために、どちらかの側が、ＣＬＯＳＥ（ビット＃２）設定を有するメッセージを送る必要がある。
【０１４２】
前述の実施形態に関して、本発明の主旨の範囲内で、様々な修正例が考えられる。さらに、本明細書の開示に基づいて作成され、あるいは組み合わせられた様々な修正例及び適用例も考えられる。様々な変更、組み合わせ、副次的組み合わせ及び変形が、設計要件と他の要因とに依存して行われてよいことを当業者は理解すべきである。本明細書に説明された現在好適な実施形態に対する様々な変更及び修正が当業者に明らかになるであろうことが理解されるべきである。こうした変更及び修正は、本発明の主旨及び範囲から逸脱することなく、その意図される利点を弱めることなく行われる可能性がある。
【０１４３】
関連出願の相互参照／参照による援用
本特許出願は、“ＭＥＴＨＯＤ  ＡＮＤ  ＡＰＰＡＲＡＴＵＳ  ＦＯＲ  ＩＭＰＲＯＶＩＮＧ  ＴＨＥ  ＰＥＲＦＯＲＭＡＮＣＥ  ＯＦ  ＴＣＰ  ＡＮＤ  ＯＴＨＥＲ  ＮＥＴＷＯＲＫ  ＰＲＯＴＯＣＯＬＳ  ＩＮ  Ａ  ＣＯＭＭＵＮＩＣＡＴＩＯＮＳ  ＮＥＴＷＯＲＫ”と題され２０１２年１１月８日に申請された米国仮特許出願第６１／７２４，２７５号と、“ＭＥＴＨＯＤ  ＆  ＡＰＰＡＲＡＴＵＳ  ＦＯＲ  ＩＭＰＲＯＶＩＮＧ  ＴＨＥ  ＰＥＲＦＯＲＭＡＮＣＥ  ＯＦ  ＴＣＰ  ＡＮＤ  ＯＴＨＥＲ  ＮＥＴＷＯＲＫ  ＰＲＯＴＯＣＯＬＳ  ＩＮ  Ａ  ＣＯＭＭＵＮＩＣＡＴＩＯＮＳ  ＮＥＴＷＯＲＫ  ＵＳＩＮＧ  ＰＲＯＸＹ  ＳＥＲＶＥＲＳ”と題され２０１３年８月１９日に申請された米国仮特許出願第６１／８６７，５８３号とを参照し、これらに対して優先を主張し、かつこれらからの利益を主張する。上記出願の各々が、その全体を本明細書において参照により援用される。
【図１】
2016501464.tif 000007
【図２】
2016501464.tif 000008
【図３】
2016501464.tif 000009
【図３ａ】
2016501464.tif 000010
【図４】
2016501464.tif 000011
【図４ａ】
2016501464.tif 000012
【図５】
2016501464.tif 000013
【図６】
2016501464.tif 000014
【図７】
2016501464.tif 000015
【図８】
2016501464.tif 000016
【図９】
2016501464.tif 000017
【図１０】
2016501464.tif 000018
【図１１】
2016501464.tif 000019
【国際調査報告】
2016501464.tif 000020