JP2018510531A - オンデマンドファイル修復のための方法及びシステム - Google Patents

Abstract

オンデマンドファイル修復プロトコルを実施するためのシステム及び方法が開示される。当該プロトコルでは、トラフィックソースは、トラフィックシンクへ、データファイルの全てのデータパケットを送信する。トラフィックソースは、次に、全てのデータパケットの送信が完了したことの指示をトラフィックシンクへ送信する。データパケットが損失している場合、トラフィックソースから、損失パケットの再送の要求が受信される。トラフィックソースは、次に、トラフィックシンクへ、損失パケットの噴水コードを送信する。

Description

本願は、米国仮出願番号第６２／１０７,８１９号、２０１５年１月２６日出願、名称「Method and System for an On−Demand File Repair Protocol」の優先権を主張する米国非仮出願番号第１４／８５５,１８１号、２０１５年９月１５日出願、名称「Method and System for an On−Demand File Repair」の優先権を主張する。これらは、参照することによりそれらの全体が複製されるかのようにここに組み込まれる。

本発明は、ファイル修復のための方法及びシステムに関し、特定の実施形態では、オンデマンドファイル修復のための方法及びシステムに関する。

データ送信は信頼できなくなり得る。より大きなファイルでは、一部のデータが失われることがほぼ保証される。この問題は、特に無線送信において深刻である。この問題を解決するために、パケット送信が開発された。パケット送信では、ファイルは、別個に送信される小さなパケットに分解される。この種のシステムは、インターネットで使用される。送信制御プロトコル（ＴＣＰ）は、誤りチェック及びパケットを元のファイルに組み立てるために必要な情報を含むパケットのための固有フォーマット化を有する。パケットが受信されると、該パケットが破損しているかどうかを決定するために、誤り制御情報が使用される。肯定応答メッセージ（acknowledgement message、ＡＣＫ）は、次に、受信側（シンク）から送信側（ソース）へ送信され、パケットが無傷で受信されたかどうかを示す。そうでない場合、ソースはパケットを再び送信する。この処理は、非常に効率的であり、インターネットのバックボーンに残る。多くの場合に、より高度なプロトコルが元のＴＣＰを置き換えているが、この基本的処理は残っている。

しかしながら、帯域幅の限られたアプリケーションでは、ＴＣＰ及びＴＣＰに似たプロトコルは非常に大きなオーバヘッドを必要とする。これは、特に、セルラ通信のような無線ネットワークに当てはまる。モビリティにおけるパケット送信は、高いパケット損失比を免れない。最良の無線リンクによっても、データ損失は高くなり得、したがってネットワークは誤り訂正トラフィックでいっぱいになり得る。したがって、ＴＣＰ及び類似プロトコルは、これらの環境において効率的なままではない。

本開示の一実施形態は、オンデマンドファイル修復の方法を含む。第１ステップで、データファイルの全てのデータパケットが、トラフィックソース、トラフィックシンクへである。次に、全てのデータパケットの送信が完了したことの指示が、トラフィックソースからトラフィックシンクへ送信される。次に、トラフィックソースから、全てのデータパケットからの損失パケットの再送の要求が受信される。損失パケットの噴水コードは、次に、トラフィックシンクへ送信される。

本開示の別の実施形態では、オンデマンドファイル修復の方法が示される。方法は、トラフィックソースにより、トラフィックシンクへ、データファイルの全てのデータパケットを送信するステップを含む。トラフィックソースは、次に、全てのデータパケットの送信が完了したことの指示をトラフィックシンクへ送信する。トラフィックシンクは、次に、指示を受信した後の計算された時間期間の間、待機する。次に、トラフィックシンクからの、全てのデータパケットからの損失パケットの再送の要求が受信される。トラフィックソースは、トラフィックシンクが損失パケットを復号するために十分な噴水コードを受信するまで、トラフィックシンクへ、損失パケットの一連の噴水コードを送信する。

本開示の別の実施形態は、オンデマンドファイル修復を提供するネットワーク装置である。ネットワーク装置は、プロセッサと、プロセッサによる実行のためのプログラミングを格納する非一時的コンピュータ可読記憶媒体と、を有する。プログラミングは、トラフィックソースにより、トラフィックシンクへ、データファイルの全てのデータパケットを送信する命令を含む。更なる命令は、装置に、全てのデータパケットの送信が完了したことの指示をトラフィックシンクへ送信させる。次の命令は、装置に、トラフィックソースからの、全てのデータパケットからの損失パケットの再送の要求を受信させる。別の命令は、装置に、トラフィックシンクへ、損失パケットの噴水コードを送信させる。

本発明並びにその利点のより完全な理解のため、ここで、添付の図と連携して取り入れられる以下の説明を参照する。
本開示の一実施形態の適用のためのシステムモデルを示す。 本開示の一実施形態である処理を示すフローチャートである。 ファイル修復プロトコルの性能を示す。 本開示の別の実施形態である処理を示すフローチャートである。 ＮＯＲＭプロトコルによる、２個のセグメントへのファイル分割を示す。 一実施形態に従う、例えば本願明細書に記載される装置及び方法を実施するために使用され得るコンピューティングプラットフォームを示す。

現在好適な実施形態の構造、製造及び使用が、以下に詳細に議論される。しかしながら、理解されるべきことに、本発明は、広範な特定の状況で実施できる多くの適用可能な新規な概念を提供する。議論される特定の実施形態は、本発明を生成し使用する特定の方法を単に説明するものであり、本発明の範囲を制限しない。

現在のファイル配信プロトコルは賛否両論を有する。転送制御プロトコル（Transfer control protocol、ＴＣＰ）は、受信したパケットについて度重なる肯定応答（acknowledgement、ＡＣＫ）を要求する。選択的ＡＣＫ（selectiveACK、ＳＡＣＫ）では、受信側は、各々の受信データセグメントについてＡＣＫを送信し、ソースは非符号化損失パケットを送信する。ユーザデータグラムプロトコル（user datagram protocol、ＵＤＰ）では、パケット再送のためのフィードバックチャネルが存在しない。信頼できるＵＤＰでは、損失パケットの再送信のためにフィードバックチャネルが存在する。問題は、モビリティにおいてレート制御及びネットワークサポートメカニズムが存在しないことである。

噴水符号化（Fountain coding、ＦＣ）は、パケットが異なるパケット損失確率を有する複数のネットワークインタフェースを通じて送信されるとき、パケット損失を補償するための効率的方法である。最初の噴水コードは、Ｌｕｄｙ（ここで参照により本願明細書に組み込まれる米国特許第６,３０７,４８７号）により提案された。高効率噴水コードの一例は、Ｓｈｏｋｒｏｌｌａｈｉ他（ここで参照により本願明細書に組み込まれる米国特許第７,０６８,７２９号）で記載されている。噴水コードは、殆ど無制限の数のシンボルが符号化処理により生成され得るという特性を有する。しかしながら、それらは、元のファイル（シンボル）がｋ個のパケットである場合に、元のシンボルがｋ＋ｘ個（ｘは０より大きい任意の数であり得る）の符号化パケットにより復号化でき、順序を問わない、という特性も有する。現在の使用では、ＦＣは、アプリケーションレベル（ＡＬ−ＦＥＣ、アプリケーションレベル前方誤り訂正）で使用され、送信ファイルはソースにおちえ符号化される。

（噴水コードに基づく）アプリケーションレイヤ符号化プロトコルは、単方向トランスポートによるファイル配信（file delivery over unidirectional transport、ＦＬＵＴＥ）、第三世代パートナシップロジェクト（３rd Generation Partnership Project、３ＧＰＰ）マルチメディアブロードキャストマルチキャストサービス（Multimedia Broadcast Multicast Service、ＭＢＭＳ）、及びＮＡＣＫ指向の高信頼マルチキャスト（NACK−oriented reliable multicast、ＮＯＲＭ）を含む。ＦＬＵＴＥは、固定アプリケーションレイヤ符号化冗長性を有するＵＤＰに基づくマルチキャストである。３ＧＰＰ ＭＢＭＳシステムは、ファイル訂正プロトコルを有するＦＬＵＴＥに基づく。ＮＯＲＭでは、マルチキャストアプリケーションが存在し、大きなファイルはセグメント化され、各セグメントについて、前方誤り訂正（forward error correction、ＦＥＣ）修復パケットが生成される。

図１は、一実施形態が実装され得る無線ネットワークを示す。サーバ１０は、インターネット１２を介して配信されるべきデータを仮想ユーザ固有サービングゲートウェイ（virtual user−specific serving gateway、ｖ−ｕ−ＳＧＷ）１４に提供する。ｖ−ｕ−ＳＧＷ１４は、セル塔１６−１、１６−２、及び１６−３を有するローカルセルラネットワークの部分である。もちろん、セルラネットワークは、他の管理装置及び更に多くのセル塔を有し得る。図１のネットワークは、明確化のため簡略化される。ｖ−ｕ−ＳＧＷ１４は、データをセル塔１６−１、１６−２及び１６−３へ送信する。セル塔１６−１、１６−２及び１６−３は、該データを自身のカバレッジエリア（それぞれ１８−１、１８−２及び１８−３）の中で送信する。ユーザ機器２０は、本例では、携帯電話機である。モバイル装置なので、幾つかのセルをブリッジする経路２２のような経路に沿い移動することが想定される。これは、送信中のデータ損失が非常に起こりやすい環境を与える。

本開示の実施形態は、オンデマンドファイル修復ソリューションを提供する。種々の実施形態において、データファイルはセグメント化されず、ＦＣは損失パケットにのみ適用される。実施形態は、ユニキャスト通信のためのオンデマンドファイル修復プロトコルを含む。種々の実施形態において、全ての元のパケットは受信側へ送信される。受信側は、損失パケット又はデータセグメント（或いは、代替で、受信パケット又はデータセグメント）を報告し、送信側は、損失パケット又はデータセグメントを符号化し、受信側が損失パケットを復号化できるまで符号化パケットを送信する。トラフィックソース及びシンクは、互いに、損失又は受信データを報告するために使用される方法、及びデータパケット番号又はデータセグメント（例えば、開始及び終了バイト）を報告するために使用される方法を通知する。

一実施形態では、ｖ−ｕ−ＳＧＷは、フローのデータパケットを収集する。データパケットは、複数の経路を介して複数のサービング無線ノードへ送信される。無線ノードは、独立のパケットスケジューリングを実行し、全部のパケットが送信されるまで、データパケットを受信側へ送信する。複数のフローの複数の経路上のデータレートは、有線及び無線リンクの容量を考慮して、トラフィック工学（traffic engineering、ＴＥ）最適化器により共同で最適化される。ファイルの終わり（end_of_file）制御メッセージを受信した後に十分な時間を待機した後、モバイルユニットは、どのデータパケットが失われているかを返す。ｖ−ｕ−ＳＧＷは、次に、全ての損失パケットを噴水符号化し、モバイルユニットが損失パケットを復号するために十分なコードを受信したことを該モバイルユニットが示すまでに噴水コードを送信し始める。

幾つかの実施形態の利点は、より低い符号化及び復号化遅延、及びファイル送信プロトコルの簡略化を含む。別の利点は、ＴＣＰがモバイルネットワークにおいて不十分に働くために、ＴＣＰのＡＣＫパケットを回避することを含む。更なる利点は、マルチキャストのために設計されているＦＬＵＴＥ又はマルチメディアブロードキャストマルチキャストサービス（multimedia broadcast multicast service、ＭＢＭＳ）の符号化／復号化の複雑性を回避することを含む。

種々の実施形態は、送信側と受信側との間のユニキャストデータ通信プロトコル及びメッセージを含む。種々の実施形態は、ウェブ閲覧、電子メール、オンラインビデオストリーミング、等を含むユニキャストアプリケーションのために使用され得る。

オンデマンドファイル修復プロトコルの一実施形態は、以下のように図２に提示される。ステップ１０１で、トラフィックソースは、全てのデータパケットを送信し、個々のパケットに対してシンクからのＡＣＫ／ＮＡＣＫはない。ステップ１０２は、元のパケットの送信を終了することを含む。ファイルの中の全部のパケットが送信されたとき、ソースは、制御メッセージ「ファイルの終わり（end_of_file、ＥＯＦ）」を送信する。ステップ１０３で、シンクは、ファイルの終わり（end_of_file）メッセージを受信した後の「待機時間（waiting_time）」を計算する。待機時間は、平均受信データレート及び残り未受信データに基づく。データレートは、送信の最後のＸ秒の又はセッションの開始からのデータレートについて決定され得る。ステップ１０４で、シンクは、残りパケットを待つ。全ての残りパケットが、「待機時間（waiting_time）」の終了前に完全に受信された場合、セッションは終了する。その他の場合、ステップ１０５で、シンクは、存在する場合には損失パケット又は損失データセグメントの再送を要求する。パケット番号フォーマットは、インターネットプロトコルバージョン４（ＩＰｖ４）の１６ビット識別（identification、ＩＤ）又はＩＰｖ６の３２ビットＩＤより遙かに短い。損失パケット番号又はデータセグメントは、圧縮され、１つのプロトコル制御パケットのペイロードの中で送信される。ステップ１０６で、ソースは、受信側が損失パケットを復号できるまで、損失パケットの全部の噴水コードを送信する。別の実施形態では、送信される噴水コードの数は、損失パケットを復号するために必要な可能な噴水コードのサブセットに限定される。

図３は、従来のアプリケーションレイヤ噴水コードと比べて、一実施形態のオンデマンドファイル修復プロトコルのシミュレートされた性能を示す。一実施形態では、プロトコルは従来のアプリケーションレイヤ符号化プロトコルの性能の１％以内である。図３のグラフの線１５０は、噴水コードの適用されたアプリケーションレイヤを使用する線１６０に対する、記載の実施形態の性能を示す。

オンデマンドファイル修復プロトコルの別の実施形態は、図４に示される。ステップ２０１で、トラフィックソースは、全てのデータパケットを送信し、個々のパケットに対してシンクからのＡＣＫ／ＮＡＣＫはない。トラフィックシンクは、バッファを低レベルに保つために（複雑性を低減する）、最後に受信したＮ個のパケット（セットＡ）を受信バッファ内に常に保つ。トラフィックシンクは、アプリケーションレイヤへ他のパケットを送信する。ステップ２０２は、元のパケットの送信を終了することを含む。ファイルが完了すると、ソースは、制御メッセージ「ファイルの終わり（end_of_file）」を送信する。トラフィックソース（又は仮想ＵＥゲートウェイ）は、全ての送信パケットのコピーを保持する。ステップ２０３で、シンクは、「ファイルの終わり（end_of_file）」メッセージを受信すると、平均受信データレート及び残りデータに基づき「待機時間（waiting_time）」を計算する。平均データレートは、最後のＸ秒の又はセッションの開始からのものであり得る。シンクは、例えば所定の又はセッション中のパラメータであり得る所定時間期間も待機し得る。

ステップ２０４で、シンクは、残りパケットを待つ。全ての残りパケットが、「待機時間（waiting_time）」の終了前に完全に受信された場合、セッションは終了する。その他の場合、ステップ２０５で、トラフィックシンクは、Ｋ個の損失パケットの再送を要求する。残りパケットは少ないデータを含むべきなので、パケット番号フォーマットは、従来より短いＩＰｖ４の１６ビット又はＩＰｖ６の３２ビットであって良く、或いは、別の短いフォーマットが使用されて良い。損失パケット番号は圧縮され、１つのプロトコル制御パケットのペイロードの中で送信される。ステップ２０６で、ソースは、受信側が損失パケットを復号できるまで、損失パケットの噴水符号化パケットを送信する。噴水符号化は、効率的な符号化のために、可能な噴水符号化パケットＮの最小サブセットしか必要としない。Ｋ＞Ｎの場合、ソースはＫ個の損失パケットにＦＣを適用する。Ｋ≦Ｎの場合、ソースはＫ個の損失パケット及び（Ｎ−Ｋ）個の最後の受信パケットにＦＣを適用する。これは、損失パケットの数が少ない場合に、有意に多数のパケットから相当量の冗長パケットが生成されることを保証する。一実施形態では、正当化するための十分なパケットが存在する場合に、噴水コード送信が損失パケットのためにのみ使用されるように、閾も適用され得る。

本開示の実施形態は、損失パケットのみ、つまり損失パケットの符号化パケットのみ、に噴水符号化を適用する。比較してみると、ＮＯＲＭ又はＦＬＵＴＥはマルチキャストであり、受信及び損失パケットを含むデータセグメント全体に対するＦＣを含む。例えば、ＮＯＲＭでは、図５に示すようにファイルは２つのセグメントに分割される。各セグメントの中に損失パケットが存在する場合、ＮＯＲＭの送信側は、誤りのあるセグメントのために符号化データを送信する。

噴水コードの符号化及び復号化計算の複雑性は、データシンボル数にのみ比例する。しかしながら、ソース及びシンクにおけるバッファサイズのような追加の複雑性が考慮され得る。ＮＯＲＭ及びＭＢＭＳファイル配信プロトコル（図５に示す）は、大きなファイルをより小さなセグメントに分割することにより複雑性を低減するための手段を提供する。噴水符号化は、管理可能な符号化／復号化の複雑性及びユーザのメモリサイズで、データセグメントに適用される。この手順は、多数のユーザが同じデータセグメントの異なるパケットを損失し得る大規模マルチキャストファイル分配において効率的である。ユニキャストのシナリオでは、ユーザは、異なるセグメントの中の少数のパケットを損失し得る。次に、誤り訂正処理が、各セグメントに適用される。これは、全てのセグメントの中の誤りを訂正するために長時間を要することがある。

開示の実施形態は、より効率的な誤り訂正手順、つまり、損失データパケットに対してのみ噴水符号化を提供するだけであるオンデマンド噴水符号化（on−demand fountain coding、ＯＤ−ＦＣ）を提供する。トラフィックシンクは、特定数のパケットを受信すると、損失パケットを報告する。ソース及びシンクは、次に、メモリを節約するために、それぞれ送信及び受信バッファから受信パケットを除去して良い。損失パケットの数が少ない場合、多数の符号化パケットを保証することは不可能である場合がある。１つのソリューションは、損失パケット及び幾つかの最後に受信したパケットを符号化して、ＦＣエンコーダに入るパケットの合計数が大量の符号化パケットを保証するために十分になるようにすることである。ＯＤ−ＦＣプロトコルの性能は、広範なシミュレーションにより検証される。ＯＤ−ＦＣプロトコルは、従来の噴水符号化マルチパス（fountain coded multi−path、ＦＣ−ＭＰ）プロトコルと同程度に良好に働く。一方で、符号化／復号化の複雑性は大幅に低減できる。

図６は、本願明細書に開示の装置及び方法を実施するために使用され得る図１のｖ−ｕ−ＳＧＷ１４のような処理システムのブロック図である。特定の装置は、図示の全てのコンポーネントを、又はコンポーネントのうちの一部のみを用いても良く、統合のレベルは装置によって変わって良い。さらに、装置は、複数の処理ユニット、プロセッサ、メモリ、送信機、受信機、等のようなコンポーネントの複数のインスタンスを有して良い。処理システムは、スピーカ、マイクロフォン、マウス、タッチスクリーン、キーパッド、キーボード、プリンタ、ディスプレイ、等のような１又は複数の入力／出力装置３０２を備えた処理ユニットを含んで良い。処理ユニットは、バス３１４に接続される中央処理ユニット（central processing unit、ＣＰＵ）３０４、メモリ３０６、大容量記憶装置３０８、ビデオアダプタ３１０、及びＩ／Ｏインタフェース３１２を有して良い。

バス３１４は、メモリバス又はメモリ制御部、周辺機器バス、ビデオバス、等を含む任意の種類の複数のバスアーキテクチャのうちの１又は複数であって良い。ＣＰＵ３０４は、任意の種類の電子データプロセッサを有して良い。メモリ３０６は、静的ランダムアクセスメモリ（static random access memory、ＳＲＡＭ）、動的ランダムアクセスメモリ（dynamic random access memory、ＤＲＡＭ）、同期ＤＲＡＭ（synchronous DRAM、ＳＤＲＡＭ）、読み出し専用メモリ（read−only memory、ＲＯＭ）、それらの組合せ、等のような任意の種類の非一時的システムメモリを有して良い。一実施形態では、メモリは、ブートアップで使用するＲＯＭ、プログラムの実行中に使用するプログラム及びデータ記憶のためのＤＲＡＭを有して良い。

大容量記憶装置３０８は、データ、プログラム、及び他の情報を格納し及びデータ、プログラム、及び他の情報をバスを介してアクセス可能にするよう構成される任意の種類の非一時的記憶装置を有して良い。大容量記憶装置３０８は、例えば、固体ドライブ、ハードディスクドライブ、磁気ディスクドライブ、光ディスクドライブ、等のうちの１又は複数を有して良い。

ビデオアダプタ３１０及びＩ／Ｏインタフェース３１２は、外部入力及び出力装置を処理ユニットに結合するインタフェースを提供する。図示のように、入力及び出力装置の例は、ビデオアダプタに結合されるディスプレイ、及びＩ／Ｏインタフェースに結合されるマウス／キーボード／プリンタを含む。他の装置が処理ユニットに結合されて良く、追加の又はより少ないインタフェースカードが利用されて良い。例えば、ユニバーサルシリアルバス（Universal Serial Bus、ＵＳＢ）のようなシリアルインターフェース（図示しない）は、プリンタのためのインタフェースを提供するために用いられて良い。

処理ユニットは、ノード又は異なるネットワークにアクセスするためにＥｔｈｅｒｎｅｔケーブル等のような有線リンク及び／又は無線リンクを有して良い１又は複数のネットワークインタフェース３１６も有する。ネットワークインタフェース３１６は、処理ユニットがネットワークを介してリモートユニットと通信できるようにする。例えば、ネットワークインタフェースは、１又は複数の送信機／送信アンテナ及び１又は複数の受信機／受信アンテナにより無線通信を提供して良い。一実施形態では、処理ユニットは、データ処理、及び他の処理ユニット、インターネット、リモート記憶設備、等のようなリモート装置との通信のために、ローカルエリアネットワーク又はワイドエリアネットワーク１２に結合される。

図６のシステムは、例えば、オンデマンドファイル修復を提供するネットワークトラフィックシンクを実装するために使用されて良い。ネットワークトラフィックシンクは、ＣＰＵ３０４のようなプロセッサ、及びプロセッサによる実行のためのプログラミングを格納する大容量記憶装置３０８のような非一時的コンピュータ可読記憶媒体を含んで良い。プログラミングは、トラフィックソースから、データフィアルのデータパケットを受信し、トラフィックソースから、データパケットの送信が完了したことの指示を受信し、トラフィックソースへ、データパケットからの損失パケットの再送の要求を送信し、トラフィックソースから損失パケットの噴水コードを受信するための命令を含んで良い。ネットワークトラフィックシンクは、データパケットの送信が完了したことの指示を受信した後の時間期間の間、再送の要求を送信するための命令を有して良い。時間期間は、データパケットがトラフィックシンクにより受信されるレート及び残りデータ量から計算されて良い。更なる実施形態では、再送の要求は、全てのデータパケットの送信が完了したことの指示を送信した後の時間期間の間、遅延される。更なる実施形態では、噴水コードの受信は、可能な噴水コードのサブセットの受信を含む。更なる実施形態では、サブセットは、損失パケットの全てを復号するために必要な最小数の噴水コードである。更なる実施形態では、ネットワークトラフィックシンクは、無線ネットワークの部分であり、トラフィックシンクは、モバイル端末である。更なる実施形態では、無線ネットワークはセルラ無線ネットワークである。

本発明は説明のための実施形態を参照して記載されたが、本記載は限定的な意味で解釈されることを意図しない。説明のための実施形態の種々の変形及び組合せ、並びに本発明の他の実施形態は、本記載を参照することにより当業者に明らかになるだろう。したがって、添付の請求の範囲はこのような変更又は実施形態を包含することが意図される。

本開示の一態様は、オンデマンドファイル修復の方法を含む。第１ステップで、データファイルの全てのデータパケットが、トラフィックソースから、トラフィックシンクへ送信される。次に、全てのデータパケットの送信が完了したことの指示が、トラフィックソースからトラフィックシンクへ送信される。次に、トラフィックソースから、全てのデータパケットからの損失パケットの再送の要求が受信される。損失パケットの噴水コードは、次に、トラフィックシンクへ送信される。

本開示の前述の実施形態と結合できる別の実施形態では、オンデマンドファイル修復の方法が示される。方法は、トラフィックソースにより、トラフィックシンクへ、データファイルの全てのデータパケットを送信するステップを含む。トラフィックソースは、次に、全てのデータパケットの送信が完了したことの指示をトラフィックシンクへ送信する。トラフィックシンクは、次に、指示を受信した後の計算された時間期間の間、待機する。次に、トラフィックシンクからの、全てのデータパケットからの損失パケットの再送の要求が受信される。トラフィックソースは、トラフィックシンクが損失パケットを復号するために十分な噴水コードを受信するまで、トラフィックシンクへ、損失パケットの一連の噴水コードを送信する。

本開示の前述の実施形態と結合できる別の実施形態は、オンデマンドファイル修復を提供するネットワーク装置である。ネットワーク装置は、プロセッサと、プロセッサによる実行のためのプログラミングを格納する非一時的コンピュータ可読記憶媒体と、を有する。プログラミングは、トラフィックソースにより、トラフィックシンクへ、データファイルの全てのデータパケットを送信する命令を含む。更なる命令は、装置に、全てのデータパケットの送信が完了したことの指示をトラフィックシンクへ送信させる。次の命令は、装置に、トラフィックソースからの、全てのデータパケットからの損失パケットの再送の要求を受信させる。別の命令は、装置に、トラフィックシンクへ、損失パケットの噴水コードを送信させる。

現在好適な実施形態の構造、製造及び使用が、以下に詳細に議論される。しかしながら、理解されるべきことに、本発明は、広範な特定の状況で実施できる多くの適用可能な新規な特徴を提供する。議論される特定の実施形態は、本発明を生成し使用する特定の方法を単に説明するものであり、本発明の範囲を制限しない。

処理ユニットは、ノード又は異なるネットワークにアクセスするためにＥｔｈｅｒｎｅｔケーブル等のような有線リンク、又は無線リンクを有して良い１又は複数のネットワークインタフェース３１６も有する。ネットワークインタフェース３１６は、処理ユニットがネットワークを介してリモートユニットと通信できるようにする。例えば、ネットワークインタフェースは、１又は複数の送信機／送信アンテナ及び１又は複数の受信機／受信アンテナにより無線通信を提供して良い。一実施形態では、処理ユニットは、データ処理、及び他の処理ユニット、インターネット、リモート記憶設備、等のようなリモート装置との通信のために、ローカルエリアネットワーク又はワイドエリアネットワーク１２に結合される。

更なる実施形態では、オンデマンドファイル修復の方法は、トラフィックシンクにより、トラフィックソースから、データファイルのデータパケットを受信するステップと、前記トラフィックシンクにより、前記トラフィックソースから指示を受信するステップであって、前記指示は、前記データファイルの全てのデータパケットが送信されたことを示す、ステップと、前記トラフィックシンクにより、前記データパケットからの損失パケットの再送の要求を送信するステップと、前記トラフィックシンクにより、前記トラフィックソースから前記損失パケットの噴水コードを受信するステップと、を含む。前述の開示の態様と結合できる更なる態様では、方法は、再送の要求を送信するステップが、データパケットの前記送信が完了したことの前記指示を受信した後の時間期間の間、遅延されることを含む。前述の開示の態様と結合できる更なる態様では、前記時間期間は、前記データパケットが前記トラフィックシンクにより受信されるレート及び残りデータ量から計算される。前述の開示の態様と結合できる更なる態様では、前記噴水コードを受信する前記ステップは、可能な噴水コードのサブセットを受信するステップを含む。更なる態様では、前記サブセットは、全ての前記損失パケットを復号するために必要な最小数の噴水コードである。
本発明は説明のための実施形態を参照して記載されたが、本記載は限定的な意味で解釈されることを意図しない。説明のための実施形態の種々の変形及び組合せ、並びに本発明の他の実施形態は、本記載を参照することにより当業者に明らかになるだろう。したがって、添付の請求の範囲はこのような変更又は実施形態を包含することが意図される。

Claims (21)

1. オンデマンドファイル修復のための方法であって、
   トラフィックソースにより、トラフィックシンクへ、データファイルの全てのデータパケットを送信するステップと、
   前記トラフィックソースにより、前記トラフィックシンクへ、指示を送信するステップであって、前記指示は、データファイルの全てのデータパケットの前記送信が完了したことを示す、ステップと、
   前記トラフィックソースにより、前記トラフィックシンクから、前記全てのデータパケットからの損失パケットの再送の要求を受信するステップと、
   前記トラフィックソースにより、前記トラフィックシンクへ、前記損失パケットの噴水コードを送信するステップと、
   を含む方法。
2. 前記再送の要求を受信するステップは、前記全てのデータパケットの前記送信が完了したことの前記指示を送信した後の時間期間の間、遅延される、請求項１に記載の方法。
3. 前記時間期間は、前記データパケットが前記トラフィックシンクにより受信されるレート及び残りデータ量から計算される、請求項２に記載の方法。
4. 前記再送の要求を受信する前記ステップは、前記トラフィックシンクが特定数のパケットを受信した後に設けられる、請求項１に記載の方法。
5. 噴水コードを送信する前記ステップは、前記可能な噴水コードのサブセットを送信するステップを含む、請求項１に記載の方法。
6. 前記サブセットは、前記損失パケットの全てを復号するために必要な最小数の噴水コードである、請求項５に記載の方法。
7. 前記トラフィックシンクからの、前記全てのデータパケットからの損失パケットの再送の要求は、前記指示を受信した後の計算された時間期間の後に生じ、
   前記損失パケットの前記一連の噴水コードは、前記トラフィックシンクが前記損失パケットを復号するために十分な噴水コードを受信するまで、前記トラフィックシンクへ送信される、
   請求項１に記載の方法。
8. 前記計算された時間期間は、前記トラフィックシンクが全てのパケットの前記送信が完了したことの前記指示を受信した後の、前記トラフィックシンクに前記データファイルの全ての利用可能パケットを受信させる時間量である、請求項７に記載の方法。
9. 前記時間期間は、前記データパケットが前記トラフィックシンクにより受信される前記レート及び前記残りデータ量から計算される、請求項８に記載の方法。
10. 前記トラフィックシンクからの前記損失パケットの前記再送の要求は、前記損失パケットのパケット番号を含む単一ペイロードである、請求項７に記載の方法。
11. 前記単一ペイロードは圧縮される、請求項１０に記載の方法。
12. オンデマンドファイル修復のための方法であって、
    トラフィックシンクにより、トラフィックソースから、データファイルのデータパケットを受信するステップと、
    前記トラフィックシンクにより、前記トラフィックソースから、指示を受信するステップであって、前記指示は、前記データファイルの全てのデータパケットが送信されたことを示す、ステップと、
    前記トラフィックシンクにより、前記トラフィックソースへ、前記データパケットからの損失パケットの再送の要求を送信するステップと、
    前記トラフィックシンクにより、前記トラフィックソースから、前記損失パケットの噴水コードを受信するステップと、
    を含む方法。
13. 前記再送の要求を送信するステップは、前記データパケットの前記送信が完了したことの前記指示を送信した後の時間期間の間、遅延される、請求項１２に記載の方法。
14. 前記時間期間は、前記データパケットが前記トラフィックシンクにより受信されるレート及び残りデータ量から計算される、請求項１３に記載の方法。
15. 噴水コードを受信する前記ステップは、可能な噴水コードのサブセットを受信するステップを含む、請求項１２に記載の方法。
16. 前記サブセットは、前記損失パケットの全てを復号するために必要な最小数の噴水コードである、請求項１５に記載の方法。
17. オンデマンドファイル修復を提供するネットワークトラフィックソースであって、前記ネットワークトラフィックソースは、
    プロセッサと、
    前記プロセッサによる実行のためのプログラミングを格納する非一時的コンピュータ可読記憶媒体と、
    を含み、前記プログラミングは、
    トラフィックシンクへ、データファイルの全てのデータパケットを送信し、
    前記トラフィックシンクへ、前記全てのデータパケットの前記送信が完了したことの指示を送信し、
    前記トラフィックシンクから、前記全てのデータパケットからの損失パケットの再送の要求を受信し、
    前記トラフィックシンクへ、前記損失パケットの噴水コードを送信する、
    ための命令を含む、ネットワークトラフィックソース。
18. 前記プログラミングは、前記再送の要求を受信するための命令は、前記全てのデータパケットの前記送信が完了したことの前記指示を送信した後の時間期間の間、待機することを更に含む、請求項１７に記載のネットワークトラフィックソース。
19. 前記時間期間は、前記データパケットが前記トラフィックシンクにより受信されるレート及び残りデータ量から計算される、請求項１８に記載のネットワークトラフィックソース。
20. 噴水コードの前記送信は、可能な噴水コードのサブセットを送信することを含む、請求項１７に記載のネットワークトラフィックソース。
21. 前記サブセットは、前記損失パケットの全てを復号するために必要な最小数の噴水コードである、請求項２０に記載のネットワークトラフィックソース。

Images