(57)【特許請求の範囲】
【請求項１】
オンデマンドファイル修復のための方法であって、
トラフィックソースにより、トラフィックシンクへ、データファイルの全てのデータパケットを送信するステップと、
前記トラフィックソースにより、前記トラフィックシンクへ、指示を送信するステップであって、前記指示は、データファイルの全てのデータパケットの前記送信が完了したことを示す、ステップと、
前記トラフィックソースにより、前記トラフィックシンクから、前記全てのデータパケットからの損失パケットの再送の要求を受信するステップであって、前記要求は前記損失パケットに関する情報を含む、ステップと、
前記要求を受信した後に、前記トラフィックソースにより、噴水符号化パケットを生成するために前記損失パケットにのみ噴水符号化を適用するステップと、
前記トラフィックソースにより、前記トラフィックシンクへ、前記噴水符号化パケットを送信するステップと、
を含む方法。
【請求項２】
前記再送の要求は、前記全てのデータパケットの前記送信が完了したことの前記指示を送信した後の時間期間の間に受信される、請求項１に記載の方法。
【請求項３】
噴水符号化パケットを送信する前記ステップは、前記噴水符号化パケットのサブセットを送信するステップを含む、請求項１又は２に記載の方法。
【請求項４】
前記サブセットは、前記損失パケットの全てを復号するために必要な最小数の噴水化パケットである、請求項３に記載の方法。
【請求項５】
前記トラフィックシンクからの前記損失パケットの前記再送の要求は、前記損失パケットのパケット番号を含むペイロードを有する単一のプロトコル制御パケットである、請求項１乃至４のいずれか一項に記載の方法。
【請求項６】
前記ペイロードに含まれる前記パケット番号は圧縮される、請求項５に記載の方法。
【請求項７】
オンデマンドファイル修復のための方法であって、
トラフィックシンクにより、トラフィックソースから、データファイルのデータパケットを受信するステップと、
前記トラフィックシンクにより、前記トラフィックソースから、指示を受信するステップであって、前記指示は、前記データファイルの全てのデータパケットが送信されたことを示す、ステップと、
前記指示を受信した後に、前記データファイルの全てのデータパケットが受信されたかどうかを決定するステップと、
全てのデータパケットが受信されていないと決定した後に、前記トラフィックシンクにより、前記トラフィックソースへ、前記データパケットからの損失パケットの再送の要求を送信するステップと、
前記トラフィックシンクにより、前記トラフィックソースから、前記損失パケットの噴水コードを受信するステップと、
を含む方法。
【請求項８】
前記指示を受信した後に、前記データファイルの全てのデータパケットが受信されたかどうかを決定するまで、時間期間の間、待つステップ、を更に含む請求項７に記載の方法。
【請求項９】
前記時間期間は、前記データファイルの前記データパケットが受信される平均データレートに基づき計算される、請求項８に記載の方法。
【請求項１０】
前記トラフィックソースへ送信される前記要求は、前記損失パケットのパケット番号を含むペイロードを有するプロトコル制御パケットである、請求項７乃至９のいずれか一項に記載の方法。
【請求項１１】
前記損失パケットのパケット番号を圧縮し、前記圧縮した損失パケット番号を前記プロトコル制御パケットの前記ペイロードに含めるステップ、を更に含む請求項１０に記載の方法。
【請求項１２】
オンデマンドファイル修復を提供するネットワークトラフィックソースであって、前記ネットワークトラフィックソースは、
プロセッサと、
前記プロセッサによる実行のためのプログラミングを格納する非一時的コンピュータ可読記憶媒体と、
を含み、前記プログラミングは、前記ネットワークトラフィックソースに請求項１乃至６のいずれか一項に記載の方法を実行させるための命令を含む、ネットワークトラフィックソース。
【請求項１３】
オンデマンドファイル修復を提供するネットワークトラフィックシンクであって、
プロセッサと、
前記プロセッサにより実行されると、前記ネットワークトラフィックシンクに請求項７乃至１１のいずれか一項に記載の方法を実行させるためのプログラミングを格納する非一時的コンピュータ可読記憶媒体と、
を含むネットワークトラフィックシンク。
【発明の詳細な説明】
【技術分野】
【０００１】
本願は、米国仮出願番号第６２／１０７,８１９号、２０１５年１月２６日出願、名称「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、ＵＳＢ）のようなシリアルインターフェース（図示しない）は、プリンタのためのインタフェースを提供するために用いられて良い。
【００２９】
処理ユニットは、ノード又は異なるネットワークにアクセスするためにＥｔｈｅｒｎｅｔケーブル等のような有線リンク、又は無線リンクを有して良い１又は複数のネットワークインタフェース３１６も有する。ネットワークインタフェース３１６は、処理ユニットがネットワークを介してリモートユニットと通信できるようにする。例えば、ネットワークインタフェースは、１又は複数の送信機／送信アンテナ及び１又は複数の受信機／受信アンテナにより無線通信を提供して良い。一実施形態では、処理ユニットは、データ処理、及び他の処理ユニット、インターネット、リモート記憶設備、等のようなリモート装置との通信のために、ローカルエリアネットワーク又はワイドエリアネットワーク１２に結合される。
【００３０】
図６のシステムは、例えば、オンデマンドファイル修復を提供するネットワークトラフィックシンクを実装するために使用されて良い。ネットワークトラフィックシンクは、ＣＰＵ３０４のようなプロセッサ、及びプロセッサによる実行のためのプログラミングを格納する大容量記憶装置３０８のような非一時的コンピュータ可読記憶媒体を含んで良い。プログラミングは、トラフィックソースから、データフィアルのデータパケットを受信し、トラフィックソースから、データパケットの送信が完了したことの指示を受信し、トラフィックソースへ、データパケットからの損失パケットの再送の要求を送信し、トラフィックソースから損失パケットの噴水コードを受信するための命令を含んで良い。ネットワークトラフィックシンクは、データパケットの送信が完了したことの指示を受信した後の時間期間の間、再送の要求を送信するための命令を有して良い。時間期間は、データパケットがトラフィックシンクにより受信されるレート及び残りデータ量から計算されて良い。更なる実施形態では、再送の要求は、全てのデータパケットの送信が完了したことの指示を送信した後の時間期間の間、遅延される。更なる実施形態では、噴水コードの受信は、可能な噴水コードのサブセットの受信を含む。更なる実施形態では、サブセットは、損失パケットの全てを復号するために必要な最小数の噴水コードである。更なる実施形態では、ネットワークトラフィックシンクは、無線ネットワークの部分であり、トラフィックシンクは、モバイル端末である。更なる実施形態では、無線ネットワークはセルラ無線ネットワークである。
【００３１】
更なる実施形態では、オンデマンドファイル修復の方法は、トラフィックシンクにより、トラフィックソースから、データファイルのデータパケットを受信するステップと、前記トラフィックシンクにより、前記トラフィックソースから指示を受信するステップであって、前記指示は、前記データファイルの全てのデータパケットが送信されたことを示す、ステップと、前記トラフィックシンクにより、前記データパケットからの損失パケットの再送の要求を送信するステップと、前記トラフィックシンクにより、前記トラフィックソースから前記損失パケットの噴水コードを受信するステップと、を含む。前述の開示の態様と結合できる更なる態様では、方法は、再送の要求を送信するステップが、データパケットの前記送信が完了したことの前記指示を受信した後の時間期間の間、遅延されることを含む。前述の開示の態様と結合できる更なる態様では、前記時間期間は、前記データパケットが前記トラフィックシンクにより受信されるレート及び残りデータ量から計算される。前述の開示の態様と結合できる更なる態様では、前記噴水コードを受信する前記ステップは、可能な噴水コードのサブセットを受信するステップを含む。更なる態様では、前記サブセットは、全ての前記損失パケットを復号するために必要な最小数の噴水コードである。
本発明は説明のための実施形態を参照して記載されたが、本記載は限定的な意味で解釈されることを意図しない。説明のための実施形態の種々の変形及び組合せ、並びに本発明の他の実施形態は、本記載を参照することにより当業者に明らかになるだろう。したがって、添付の請求の範囲はこのような変更又は実施形態を包含することが意図される。
【図１】
0006487562.tif 000002
【図２】
0006487562.tif 000003
【図３】
0006487562.tif 000004
【図４】
0006487562.tif 000005
【図５】
0006487562.tif 000006
【図６】
0006487562.tif 000007