(57)【特許請求の範囲】
【請求項１】
送信部から受信部にデータを送信する際に利用される１つ又は複数のネットワーク相互の接続点に設けられ、上流側装置からデータを受信して下流側装置にデータを送信する中継装置であって、
前記上流側装置からの順方向誤り訂正符号化されたパケット単位の受信データを復号化し、該復号化したデータを再符号化し、該再符号化したデータを前記下流側装置に送信する第１転送手段と、
前記上流側装置からの順方向誤り訂正符号化されたパケット単位の受信データをそのまま前記下流側装置に転送する第２転送手段
を備え、
前記上流側装置からの順方向誤り訂正符号化されたパケット単位のデータを受信すると、前記第２転送手段による転送を実行するとともに、前記第１転送手段による復号化を開始することを特徴とする中継装置。
【請求項２】
前記下流側装置からの前記第１転送手段に対する送信中止要求を受信する受信手段を備え、
前記第１転送手段は、前記下流側装置からの送信中止要求を受信するまで、前記再符号化したデータの前記下流側装置への送信を実行することを特徴とする請求項１に記載する中継装置。
【請求項３】
前記下流側装置は、前記第２転送手段により転送された前記受信データを完全に復号化できる場合、前記第１転送手段に対する送信中止要求を送信することを特徴とする請求項２に記載する中継装置。
【請求項４】
前記下流側装置は、前記第２転送手段により転送された前記受信データを完全に復号化できず、該受信データに続いて、前記第１転送手段により送信された前記再符号化データを受信した場合、該再符号化データを完全に復号化できるときに、前記第１転送手段に対する送信中止要求を送信することを特徴とする請求項３に記載する中継装置。
【請求項５】
前記第１転送手段は、復号化したデータを一時的に記憶するバッファを有し、前記送信中止要求を受信するまで、復号化したデータを前記バッファに保持し、前記送信中止要求を受信すると、前記バッファに保持している復号化したデータを消去することを特徴とする請求項２〜請求項４のいずれか１項に記載する中継装置。
【請求項６】
前記上流側装置から受信した順方向誤り訂正符号化されたパケット単位の受信データを完全に復号化できるか否かを判定する判定手段を備え、
前記判定手段で上流側装置から受信した順方向誤り訂正符号化されたパケット単位の受信データを完全に復号化できると判定した場合、該受信データに続いて、該受信データよりも冗長度が改善されたデータの送信中止要求を前記上流側装置に送信することを特徴とする請求項１〜請求項５のいずれか１項に記載する中継装置。
【請求項７】
前記中継装置の下流側に位置する１つ又は複数のネットワークのサービス品質情報又はサービス品質情報の二次情報に基づいて、データの冗長度の改善の要否並びに冗長度レベルを決定する決定手段を備え、
フロー毎のアプリケーション及び／又はサービスレベルに応じて、順方向誤り訂正の実施の要否の決定、順方向誤り訂正の種類の決定、冗長度レベルの決定及び／又は順方向誤り訂正のパラメータの設定を行うことを特徴とする請求項１〜請求項６のいずれか１項に記載する中継装置。
【請求項８】
フローのブロックに対する復号化の途中で、データを全て復号化することなく、不足する冗長分を追加して再符号化することによりデータの冗長度を改善することを特徴とする請求項７に記載する中継装置。
【請求項９】
パケットの固定長のデータ領域にアプリケーション及び／又はサービスレベルを設定することを特徴とする請求項７又は請求項８に記載する中継装置。
【請求項１０】
パケットの固定長のデータ領域にアプリケーション及び／又はサービスレベルが設定されたパケットを扱うことを特徴とする請求項７又は請求項８に記載する中継装置。
【請求項１１】
順方向誤り訂正データの種類は、ＬＴ符号であることを特徴とする請求項１〜請求項１０のいずれか１項に記載する中継装置。
【請求項１２】
送信部、受信部、及び、１つ又は複数のネットワーク相互の接続点に設けられている１つ又は複数の中継装置からなる自律型誤り訂正ネットワークであって、
前記中継装置は、前記送信部又は上流側の前記中継装置からの順方向誤り訂正符号化されたパケット単位の受信データを復号化し、該復号化したデータを再符号化し、該再符号化したデータを下流側の前記中継装置又は前記受信部に送信する第１転送手段と、前記送信部又は上流側の前記中継装置からの順方向誤り訂正符号化されたパケット単位の受信データをそのまま下流側の前記中継装置又は前記受信部に転送する第２転送手段を備え、前記送信部又は上流側の前記中継装置からの順方向誤り訂正符号化されたパケット単位のデータを受信すると、前記第２転送手段による転送を実行するとともに、前記第１転送手段による復号化を開始することを特徴とする自律型誤り訂正ネットワーク。
【請求項１３】
前記中継装置は、下流側の前記中継装置又は前記受信部からの前記第１転送手段に対する送信中止要求を受信する受信手段を備え、前記第１転送手段は、下流側の前記中継装置又は前記受信部からの送信中止要求を受信するまで、前記再符号化したデータの下流側の前記中継装置又は前記受信部への送信を実行することを特徴とする請求項１２に記載する自律型誤り訂正ネットワーク。
【請求項１４】
前記中継装置において、フロー毎のアプリケーション及び／又はサービスレベルに応じて、順方向誤り訂正の実施の要否の決定、順方向誤り訂正の種類の決定、冗長度レベルの決定及び／又は順方向誤り訂正のパラメータの設定を行うことを特徴とする請求項１２又は請求項１３に記載する自律型誤り訂正ネットワーク。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、１つ又は複数のネットワーク相互の接続点に設けられている中継装置及び自律型誤り訂正ネットワークに関する。
【背景技術】
【０００２】
近年、インターネットやイントラネットにおいて、ブロードバンドの加入者が急速に増大している。そのブロードバンドのアプリケーションとしては、音楽や映像のダウンロード配信やストリーミング配信のような一定の帯域や品質を要求するもの、実時間通信等の大容量で高速のコンテンツ配信サービスの実現を要求するものが増えつつある。これらのアプリケーションが、ＦＴＴＨ[Fiber To The Home]のような更なる高速のブロードバンドサービスの市場を牽引することが期待されている。この高速のブロードバンドサービスではダウンロードにおいては１分以内にダウンロードできる高速性、また、ストリーミングにおいては途中で停止したりあるいはマクロブロックエラー等を発生させないサービスレベルの実現が、優良なコンテンツの確保やデジタル著作権管理技術の標準化等と合わせて、我が国のブロードバンド市場発展の鍵とさえ言われている。
【０００３】
このような大容量な情報を高速かつリアルタイムに処理し、それぞれの用途に応じた品質要求に答える技術としては、コアネットワークにおいてはＭＰＬＳ[Multi Protocol Label Switching]を用いたレイヤ２におけるハードウエアレベルでの高速スイッチング技術等が開発され、また、エッジネットワークにおいてはコンテンツを分割し、キャッシュする技術等が実用化されている。
【０００４】
しかし、さまざまな時代のネットワーク技術の集合体であるインターネットにおけるＥｎｄ−ｔｏ−Ｅｎｄで高速性やサービスレベルを確保する技術は、今だに目処がたっていないのが現状である。インターネットの基礎をなすＴＣＰ／ＩＰ[Transmission Control Protocol/Internet Protocol]では、フロー制御とロスパケットの再送要求によって信頼性の高い通信を実現している。しかし、ロスパケットの再送は、アクセスの集中による輻輳が再送によって更なる輻輳を呼び、広帯域メディアのサービスレベルを確保する上で、本質的な解決策とはなっていない。
【０００５】
また、ダウンロードに使用するプロトコルとして普及しているＦＴＰ[File Transfer Protocol]では、再送によるネットワークの混雑を防止するために、個々の受け手側の受信能力を伝送帯域と遅延時間の積で定義し、これを一定とすることによりフロー制御が行われている。そのため、パケットの再送が発生し、遅延時間が増大すると、伝送帯域が低下し、ブロードバンドに見合った高速のダウンロードが行えない。
【０００６】
また、ストリーミングにおいて普及している様々なメディアフォーマットでは、ＱｏＳ[Quality of Service]の乏しいネットワーク上でも画質を維持するために各種工夫が施されているが、０．１〜１％程度のパケットロスによって再生映像にマクロブロックエラーやフレームスキップが発生する場合がある。これらのストリーミング配信では、スループットを確保するため、フロー制御とロスパケットの再送を行わないＵＤＰ[UserDatagram Protocol]を用いている場合が多い。ＵＤＰは、ネットワークの輻輳に対してネットワークへの負担を軽減するスキームを持たないため、各アプリケーションの中には自律学習的に解像度を低下させ、個々のフローのサービスレベルを低下させるスキームを専用プロトコルで実現しているものである。ところが、ネットワークの輻輳に対する追従感度は十分なものではなく、特に、輻輳解消後のサービスレベルの復帰は極めて遅く、僅かな時間の輻輳で番組全体の品質の低下するといった問題がある。
【０００７】
そのため、ＡＤＳＬ[Asymmetric Digital Subscriber Line]等によるブロードバンドの爆発的な普及にもかかわらず、インターネット上での本格的なブロードバンドＣＤＳ[CircuitDesign Service]の普及は難しい。これにより、日本国内でのＦＴＴＨの需要の増加の重要な律速要因の一つとなっているのが現状である。
【０００８】
一方、ＴＣＰ／ＩＰのフロー制御やロスパケットの再送に依存しないＱｏＳの実現手段としては、ＵＤＰと順方向誤り訂正（以下、ＦＥＣ[Forward Error Correction]と記載する）を用いる方法がある。
【特許文献１】特開２００１−１８９６６５号公報
【特許文献２】米国特許第６３０７４８７号明細書
【発明の開示】
【発明が解決しようとする課題】
【０００９】
しかしながら、従来のＦＥＣは、主として、ＯＳＩ[OpenSystems Interconnection]モデルのレイヤ１においてＳ／Ｎの改善に用いられてきたが、バースト的なエラーへの耐性を高めるには送信データに予めランダム性を持たせる工夫が必要である。そのため、バースト的なエラーへの耐性と送信データの遅延時間にトレードオフの関係を生じることから、電話等に利用されるＶｏＩＰ[VoiceOver Internet Protocol]のような遅延時間に厳しいアプリケーションで用いるには必ずしも適切ではなかった。
【００１０】
また、ＦＥＣは、Ｅｎｄ−ｔｏ−Ｅｎｄのエラーレートやパケットロスレートを予め想定してエンコーダを行うが、本質的に自立したネットワークの集合体であるインターネットにおいてＥｎｄ−ｔｏ−Ｅｎｄのエラーレートやパケットロスレートを予め想定することは困難であった。Ｅｎｄ−ｔｏ−Ｅｎｄのエラーレートやパケットロスレートを予め想定できた場合でも、送信元においてその分の冗長度レベルを大きくしたＦＥＣデータを送信するので、ネットワークの伝送帯域の使用効率が低下するとともに伝送時間も増大する。特に、公衆回線を利用したネットワークを介して個人が個人にデータを送受信する場合、ネットワーク途中におけるエラーレートやパケットロスレートを考慮して冗長度レベルを大きくすると、送信するデータ量が増加するため、個人のコスト負担が増加する。つまり、個人が、ネットワーク途中におけるエラーレートやパケットロスレート等に対するコスト負担をしなければならない。
【００１１】
図６を参照して、ＡＳＰ等の送信元１００から個人のパーソナルコンピュータ（以下、パソコンと記載する）等の受信先１０１にネットワーク１０２，１０３，１０４，１０５を介してストリーミングコンテンツを送信した場合の一例を説明する。送信元１００から受信先１０１へ４つのネットワーク１０２，１０３，１０４，１０５を介してストリーミングコンテンツのデータを送信する場合、ネットワーク１０２，１０３，１０４，１０５の接続点には３つの中継装置１０６，１０７，１０８が存在する。ここで、ストリーミングコンテンツのデータ容量を０．３Ｍｂｐｓとし、ネットワーク１０２，１０３，１０４，１０５における最大パケットロスレートを各々１％、１５％、２５％、１％とし、パケットオーバヘッドを１０８６／１０２４とし、ＦＥＣのオーバヘッドを１．０５とする。この場合、送信元１００から送信したＦＥＣデータを受信先１０１でロスパケット無しで復号化するためには、ストリーミングコンテンツのデータに対して最大パケットロスレート、パケットオーバヘッド及びＦＥＣのオーバヘッドを加味しなければならない。そのため、送信元１００では、これらのＱｏＳ情報を考慮して冗長度レベル（約７７％）を設定し、ＦＥＣを実施してストリーミングコンテンツ（０．３Ｍｂｐｓ）のデータを符号化すると、伝送帯域としては０．５３Ｍｂｐｓが必要となる。しかし、送信元１００に接続されているネットワーク１０２の実効帯域は０．５Ｍｂｐｓなので、伝送帯域が０．５３ＭｂｐｓのＦＥＣデータを送信することはできない。したがって、送信元１００から０．５ＭｂｐｓのＦＥＣデータを送信したとすると、受信先１０１においてロスパケットが発生し、ストリーミングコンテンツを完全に再生することはできない。ちなみに、この例では、データの伝送途中であるネットワーク１０３，１０４におけるパケットロスを考慮して冗長度レベルを設定しているので、送信元１００あるいは受信先１０１では、これらのネットワーク１０３，１０４におけるパケットロスも伝送コストとして負担しなければならない。
【００１２】
さらに、ＣＤ−ＲＯＭやＤＶＤ等のＦＥＣに広く用いられているリードソロモン符号等の既存のＦＥＣ技術では、そもそも演算処理時間がコンテンツレートや誤り訂正の対象とするパケットロスのバースト長に対してほぼ二乗に比例する傾向があるため、映像や音楽等のリッチコンテンツと呼ばれる広帯域データをバースト的なパケットロスが発生するインターネット上で配信するアプリケーションに対して適用することはこれまで容易ではなかった。
【００１３】
上記した技術については、特許文献１、特許文献２等に開示されているが、上記問題点の解決手段については開示されていない。
【００１４】
そこで、本発明は、ネットワークの伝送帯域の使用効率及びデータ送信時の遅延並びにＱｏＳに優れる中継装置及びネットワークを提供することを課題とする。
【課題を解決するための手段】
【００１５】
本発明に係る中継装置は、送信部から受信部にデータを送信する際に利用される１つ又は複数のネットワーク相互の接続点に設けられ、上流側装置からデータを受信して下流側装置にデータを送信する中継装置であって、上流側装置からの順方向誤り訂正符号化されたパケット単位の受信データを復号化し、該復号化したデータを再符号化し、該再符号化したデータを下流側装置に送信する第１転送手段と、上流側装置からの順方向誤り訂正符号化されたパケット単位の受信データをそのまま下流側装置に転送する第２転送手段を備え、上流側装置からの順方向誤り訂正符号化されたパケット単位のデータを受信すると、第２転送手段による転送を実行するとともに、第１転送手段による復号化を開始することを特徴とする。
【００１６】
この中継装置によれば、データを送信するネットワークの途中において、冗長度を改善することできる。そのため、送信部において小さな冗長度レベルによって順方向誤り訂正を実施したデータを送信した場合にネットワークの途中で冗長度レベルが低下しても、ネットワークの途中の中継装置で冗長度を改善でき、受信部においてパケットロスが発生しない。したがって、データを小さな冗長度で送信できるととともにパケットロスを無くすことができるので、伝送帯域の使用効率が向上するとともに伝送時間を短縮でき、さらに、Ｅｎｄ−ｔｏ−ＥｎｄにおけるＱｏｓやサービスレベルも向上する。特に、この中継装置によれば、順方向誤り訂正データをそのまま下流に転送するとともにその順方向誤り訂正データを復号化しているので、遅延を極力抑えることができる。
【００１７】
ちなみに、あるフローが経由するｍ個の部分ネットワーク（ｎ）の最大パケットロスレートをＬ（ｎ）％とすると、このフローのネットワーク全体のパケットロスレートは、１−（（１−Ｌ（１））×（１−Ｌ（２））×・・・×（１−Ｌ（ｍ）））で表される。これを考慮して順方向誤り訂正を行うと、送信元の送信するデータの冗長度レベルは膨大となり、送信元付近の部分ネットワークあるいは中継装置におけるトラフィックが膨大となる。そのため、従来、経済的にリッチコンテンツを配信することは不可能であり、想定以上のパケットロスが発生するとサービスレベルが低下した。しかし、本発明に係る中継装置によれば、ネットワークの区間毎に失った冗長性を回復しながら次のネットワークに中継するので、各ネットワークで有効に伝送帯域を利用しながら、サービスレベルも低下しない。
【００１８】
なお、送信部は、ネットワークを介してデータを送信する送信元であり、例えば、個人（パーソナルコンピュータ等の送信装置を含む）、ＩＳＰ[Internet Service Provider]（サーバ等の送信装置を含む）、ＡＳＰ[Application ServiceProvider]（サーバ等の送信装置を含む）等である。受信部は、ネットワークを介してデータを受信する受信先であり、例えば、個人や法人（パーソナルコンピュータ等の受信装置を含む）等である。ネットワークは、例えば、インターネット、イントラネット等である。中継装置は、ネットワーク間における接続点に設けられ、データを上流側から下流側に中継する装置あり、例えば、ＩＳＰやＡＳＰにおかれたルータ、ゲートウエイ等である。ちなみに、送信部も、中継装置における処理を行う場合がある。上流側は、データが送信される際の送信部側である。下流側は、データが送信される際の受信部側である。
【００１９】
本発明の上記中継装置では、下流側装置からの第１転送手段に対する送信中止要求を受信する受信手段を備え、第１転送手段は、下流側装置からの送信中止要求を受信するまで、再符号化したデータの下流側装置への送信を実行する構成としてもよい。
【００２０】
本発明の上記中継装置では、下流側装置は、第２転送手段により転送された受信データを完全に復号化できる場合、第１転送手段に対する送信中止要求を送信する構成としてもよい。さらに、本発明の上記中継装置では、下流側装置は、第２転送手段により転送された受信データを完全に復号化できず、該受信データに続いて、第１転送手段により送信された再符号化データを受信した場合、該再符号化データを完全に復号化できるときに、第１転送手段に対する送信中止要求を送信する構成としてもよい。
【００２１】
本発明の上記中継装置では、第１転送手段は、復号化したデータを一時的に記憶するバッファを有し、送信中止要求を受信するまで、復号化したデータをバッファに保持し、送信中止要求を受信すると、バッファに保持している復号化したデータを消去する構成としてもよい。また、本発明の上記中継装置では、上流側装置から受信した順方向誤り訂正符号化されたパケット単位の受信データを完全に復号化できるか否かを判定する判定手段を備え、判定手段で上流側装置から受信した順方向誤り訂正符号化されたパケット単位の受信データを完全に復号化できると判定した場合、該受信データに続いて、該受信データよりも冗長度が改善されたデータの送信中止要求を上流側装置に送信する構成としてもよい。
【００２２】
本発明の上記中継装置では、中継装置の下流側に位置する１つ又は複数のネットワークのサービス品質情報又はサービス品質情報の二次情報に基づいて、データの冗長度の改善の要否並びに冗長度レベルを決定する決定手段を備え、フロー毎のアプリケーション及び／又はサービスレベルに応じて、順方向誤り訂正の実施の要否の決定、順方向誤り訂正の種類の決定、冗長度レベルの決定及び／又は順方向誤り訂正のパラメータの設定を行う構成としてもよい。さらに、本発明の上記中継装置では、フローのブロックに対する復号化の途中で、データを全て復号化することなく、不足する冗長分を追加して再符号化することによりデータの冗長度を改善する構成としてもよい。
【００２３】
この中継装置によれば、アプリケーション及び／又はサービスレベルに応じて順方向誤り訂正の実施の要否の決定や順方向誤り訂正の種類の決定等を行うので、様々なアプリケーションに要求されるＱｏＳに応じて順方向誤り訂正によって冗長度を改善することができる。つまり、ＶｏＩＰ等の遅延に敏感なアプリケーションあるいはＶＯＤ等の遅延には鈍感であるがパケットロスにシビアなアプリケーションが存在するが、従来の技術では、順方向誤り訂正がＯＳＩの下位レイヤで実施されていたため、アプリケーション毎のＱｏＳの要求に対応できなかった。しかし、この中継装置によれば、利用時間、許容遅延、許容パレットロスレート、許容パケットロスバースト数等のＱｏＳの要求の異なるアプリケーション毎に適切な順方向誤り訂正を実施することができる。
【００２４】
なお、サービス品質情報は、ネットワークにおけるＱｏＳに関する情報であり、例えば、パケットロスレート、エラーレート、遅延、ジッタ等である。サービス品質情報の二次情報は、サービス品質情報の中のある１つの情報あるいは複数の情報に対して四則演算等を施した情報である。フローは、コンテンツ等の送信データの全部又は一部からなる一つ又は複数のブロックで構成されるネットワークを流れるデータの流れを意味する。順方向誤り訂正の種類としては、ハミング符号、ＢＣＨ[Bose Chaudhuri-Hocquenghem]符号、リードソロモン符号、トルネード符号、ＬＴ[Luby Transform]符号等がある。
【００２５】
本発明の上記中継装置では、パケットの固定長のデータ領域にアプリケーション及び／又はサービスレベルを設定してもよい。また、本発明の上記中継装置では、パケットの固定長のデータ領域にアプリケーション及び／又はサービスレベルが設定されたパケットを扱ってもよい。
【００２６】
この中継装置によれば、パケットヘッドの予め決められた領域に格納されているデータを参照することによって、ハードウエアにより高速にアプリケーション及び／又はサービスレベルを判別できる。ちなみに、従来のパケット構造ではパケットの可変長のペイロードの順方向誤り訂正ヘッダにアプリケーション及び／又はサービスレベルが設定されているので、ソフトウエア処理によってアプリケーション及び／又はサービスレベルを判別していたので、処理時間を要した。
【００２７】
本発明の上記中継装置では、順方向誤り訂正データの種類は、ＬＴ符号であると好適である。
【００２８】
ちなみに、従来の順方向誤り訂正では、バースト的なパケットロスやエラーに対する耐性を向上させるためにデータのスクランブルと順方向誤り訂正を組み合わせる必要があり、スクランブル幅を長くするとバースト的なエラーに対する耐性は向上するが、遅延が大きくなった。したがって、従来の順方向誤り訂正を用いて中継装置で復号化と再符号化を繰り返すと、中継装置を経由する毎に遅延が累積し、電話等のＶｏＩＰや対話型ゲーム等に利用できないのは勿論のこと、ＶＯＤやライブ放送等の用途でも遅延が大きくなりすぎて問題が発生する。しかし、本発明に係る中継装置によれば、中継時にデータを全て復号化及び再符号化することなく、不足する冗長分を追加して復号化及び再符号化することができるので、遅延の増加を最低限に抑えることできる。
【００２９】
本発明に係る自律型誤り訂正ネットワークは、送信部、受信部、及び、１つ又は複数のネットワーク相互の接続点に設けられている１つ又は複数の中継装置からなる自律型誤り訂正ネットワークであって、中継装置は、送信部又は上流側の中継装置からの順方向誤り訂正符号化されたパケット単位の受信データを復号化し、該復号化したデータを再符号化し、該再符号化したデータを下流側の中継装置又は受信部に送信する第１転送手段と、送信部又は上流側の中継装置からの順方向誤り訂正符号化されたパケット単位の受信データをそのまま下流側の中継装置又は受信部に転送する第２転送手段を備え、送信部又は上流側の中継装置からの順方向誤り訂正符号化されたパケット単位のデータを受信すると、第２転送手段による転送を実行するとともに、第１転送手段による復号化を開始することを特徴とする。
【００３０】
この自律型誤り訂正ネットワークによれば、データの中継時に冗長度を改善することができるので、各ネットワークで有効に伝送帯域を利用でき、サービスレベルも低下しない。
【００３１】
本発明の上記自律型誤り訂正ネットワークでは、中継装置は、下流側の中継装置又は受信部からの第１転送手段に対する送信中止要求を受信する受信手段を備え、第１転送手段は、下流側の中継装置又は受信部からの送信中止要求を受信するまで、再符号化したデータの下流側の中継装置又は受信部への送信を実行する構成としてもよい。
【００３２】
本発明の上記自律型誤り訂正ネットワークでは、中継装置において、フロー毎のアプリケーション及び／又はサービスレベルに応じて、順方向誤り訂正の実施の要否の決定、順方向誤り訂正の種類の決定、冗長度レベルの決定及び／又は順方向誤り訂正のパラメータの設定を行う構成としてもよい。
【発明の効果】
【００３３】
本発明は、データを送信するネットワークの途中で冗長度が低下しても、ネットワーク間の中継時に、冗長度を改善することができる。そのため、データを小さな冗長度で送信できるのでネットワークの伝送帯域の使用効率が向上するとともに伝送時間を短縮でき、さらに、パケットロスを全く無くすあるいは極力無くすことができるのでＥｎｄ−ｔｏ−ＥｎｄにおけるＱｏｓやサービスレベルも向上する。
【００３４】
特に、本発明では、データの転送とデータの復号化及び再符号化をパラレルで行っているので、遅延を極力抑えることができる。また、本発明では、パケットロス等が発生して転送されたデータによって元のデータに１００％復号化できない場合でも、上流側装置から再符号化されて順方向誤り訂正が施されたパケットを受信することによって、元のデータに１００％復号化することができる。
【００３５】
さらに、本発明は、アプリケーション及び／又はサービスレベルに応じて順方向誤り訂正の実施の要否の決定や順方向誤り訂正の種類の決定等を行うので、様々なアプリケーションに要求されるＱｏＳに応じて順方向誤り訂正によって冗長度を改善することができ、サービスレベルも満たすことができる。
【発明を実施するための最良の形態】
【００３６】
以下、図面を参照して、本発明に係る中継装置及び自律型誤り訂正ネットワークの実施の形態を説明する。
【００３７】
本発明は、ネットワークを介したデータの伝送における伝送帯域、遅延時間及びＱｏＳを考慮した最適な伝送を実現するために、伝送途中で冗長度レベルが低下してきた場合には、送信部、ネットワーク、受信部の接続点に設けられている中継装置において下流側のネットワークのＱｏＳ情報に基づいて冗長度を改善する。さらに、本発明は、許容遅延、許容パレットロスレート等のＱｏＳの要求の異なるアプリケーションやサービス契約等で設定されているサービスレベルに応じて最適な伝送を実現するために、アプリケーションやサービスレベルに基づいてＦＥＣの実施の要否の決定、ＦＥＣの種類の決定、冗長度レベルの決定及び／又はＦＥＣのパラメータの設定を行う。特に、本発明では、遅延を最小限に抑えるために、中継装置において受信したデータをそのまま下流側に転送するとともにそのデータを復号化し、冗長度が不足して完全に復号化できない場合には上流側の送信部又は中継装置からその不足分だけ符号化したデータを送信してもらう。
【００３８】
本実施の形態では、２つの実施の形態があり、第１の実施の形態では中継装置において冗長度を改善するための復号化及びＦＥＣによる再符号化を送信データの中継とシリアルに行い、第２の実施の形態では中継装置において冗長度を改善するための復号化及びＦＥＣによる再符号化を送信データの中継とパラレルに行う。本実施の形態では、ＦＥＣとしてＬＴ符号を用いる。
【００３９】
まず、第１の実施の形態について説明する。図１を参照して、第１の実施の形態に係るネットワークの全体構成について説明する。図１は、第１の実施の形態に係るネットワーク全体の構成図である。
【００４０】
第１の実施の形態では、送信元１から受信先２にストリーミングコンテンツを、４つのネットワーク３，４，５，６を介して配信し、この４つのネットワーク３，４，５，６の接続点に設けられた中継装置７，８，９でデータを中継している。
【００４１】
送信元１は、ＡＳＰ等のコンテンツを配信するプロバイダであり、データをネットワークを介して配信するために配信サーバ（図示せず）を備えている。また、送信元１は、配信サーバ内あるいは別体でＦＥＣエンコーダ１ａを備えている。送信元１では、ストリーミングコンテンツの元データをＦＥＣエンコーダ１ａでＦＥＣデータに符号化し、ＦＥＣデータをパケット単位で配信する。ちなみに、送信元１では、受信先２（例えば、個人のユーザ）と契約を結んでおり、この契約おいて送信元１から配信するコンテンツのサービスレベル（サービス種別）やアプリケーションの種類及び配信料等を設定している。サービスレベルとしては、図４に示すような、誤り率優先度、遅延優先度、ＳＬＡ[Service Level Agreement]情報等がある。
【００４２】
ＦＥＣエンコーダ１ａでは、ＬＴ符号によるＦＥＣによって、ストリーミングコンテンツの元データを所定の冗長度レベルでＦＥＣデータに符号化する。このＦＥＣデータは、パケットのペイロードに分割されて格納され、送信される。所定の冗長度レベルは、パケットオーバヘッド（例えば、１０８６／１０２４）、ＦＥＣのオーバヘッド（例えば、１．０５）及び送信元１に接続されるネットワーク（Ｓ）３の最大パケットレート（１％）に基づいて設定され、例えば、１５％程度に設定される。冗長度レベルを１５％で０．３Ｍｂｐｓのストリーミングコンテンツを送信する場合、０．３４５Ｍｂｐｓの伝送帯域が必要であるが、ネットワーク（Ｓ）３の実効帯域０．５Ｍｂｐｓで十分に送信可能である。ちなみに、送信元１では、従来のようにネットワーク１０３，１０４，１０５の最大パケットレートを加味する必要はない。なお、ストリーミングコンテンツは、多数のブロックから構成され、各ブロックは多数のパケットから構成されている。
【００４３】
図２を参照して、パケットの構成について説明しておく。図２は、パケットの説明図であり、（ａ）はパケットの構成図であり、（ｂ）はＩＰヘッダのデータ構成図である。
【００４４】
パケットは、固定長のネット用ヘッダ、ＩＰヘッダ、ＵＤＰヘッダ、及び、可変長のペイロードから構成されている。このペイロードに、ＦＥＣデータが分割されて格納されている。また、ＩＰヘッダは、図２（ｂ）に示すようなデータ構成を有しており、ＩＰヘッダの先頭から２バイト目にサービス種別が格納されている。そのため、各パケットのＩＰヘッドの２バイト目の８ビットデータを参照することにより、このストリーミングコンテンツのサービス種別を判別することができる。また、ネット用ヘッダ又はＵＤＰヘッドには、アプリケーション（ストリーミングコンテンツ等）の種別を示すデータが格納されており、ネット用ヘッダ又はＵＤＰヘッドのデータを参照することにより、アプリケーションの種別を判別することができる。
【００４５】
図３を参照して、ＦＥＣエンコーダ１ａ等で行うＬＴ符号によるＦＥＣについて説明しておく。なお、このＬＴ符号によるＦＥＣは、中継装置７，８，９でも実施される。
【００４６】
図３では、ストリーミングコンテンツの元データに相当する入力データがａ〜ｈの１０個ある例を示している。ＬＴ符号によるＦＥＣでは、各入力データに対して乱数を発生させる。そして、出力データとして各列に対して排他的論理和により方程式（例えば、一列目の場合にはａＸＯＲｇ）をたて、この方程式がＦＥＣデータとなる。基本的には、入力データの個数分の方程式（出力データ）が有れば、方程式を解くことができる。しかし、データのネットワーク伝送中におけるパケットロスを考慮して、入力データの個数分より方程式（出力データ）の数を増やす（つまり、冗長度レベルを大きくする）。例えば、冗長度レベルを１０％とすると、１０個の入力データに対して１１個の出力データ（方程式）を生成しておく。つまり、送信元から１１個の出力データ（ＦＥＣデータ）を送信し、ネットワークで１個出力データ（ＦＥＣデータ）をロスしたとしても、受信先では１０個の出力データ（ＦＥＣデータ）によって方程式を解くことができる。
【００４７】
図１に戻って、受信先２は、個人のユーザ等であり、ネットワークを介してデータを受信するためにパソコン（図示せず）等を備えている。また、受信先２は、パソコン内あるいは別体でＦＥＣデコーダ２ａ及びストリーミングビュワ２ｂを備えている。受信先２では、パケット単位でＦＥＣデータを受信し、ＦＥＣデコーダ２ａで復号化する。そして、受信先２では、ストリーミングビュワ２ｂでパケット単位の復号化データを繋げ、ストリーミングコンテンツとして再生する。
【００４８】
ネットワーク３，４，５，６は、インターネット、イントラネット等のネットワークであり、ＱｏＳ情報を各々有している。Ｑｏｓ情報としては、図４に示すように、パケットロスレート、実効帯域、エラーレート、遅延、最大バースト長、ジッタ等があり、ネットワーク３，４，５，６によって異なる特性を有している。例えば、最大パケットロスレートの場合、ネットワーク（Ｓ）３では１％、ネットワーク（Ｎ−１）４では１５％、ネットワーク（Ｎ）５では２５％、ネットワーク（Ｄ）６では１％である。また、実効帯域の場合、ネットワーク（Ｓ）３では０．５Ｍｂｐｓ、ネットワーク（Ｎ−１）４では１０００Ｍｂｐｓ、ネットワーク（Ｎ）５では１００Ｍｂｐｓ、ネットワーク（Ｄ）６では８Ｍｂｐｓである。
【００４９】
中継装置７，８，９は、ネットワーク間のデータを中継する装置であり、例えば、ＩＳＰ等に設けられているルータ、ゲートウエイ等である。特に、中継装置７，８，９では、受信したＦＥＣデータの冗長度レベルが低下している場合、冗長度レベルを上げるために受信したＦＥＣデータを復号化するとともにその復号化データを再符号化して下流側に送信する。そのために、中継装置７，８，９は、パケットスイッチ７ａ，８ａ，９ａ、ＦＥＣデコーダ７ｂ，８ｂ，９ｂ、バッファメモリ７ｃ，８ｃ，９ｃ及びＦＥＣエンコーダ７ｄ，８ｄ，９ｄを備えている。ちなみに、これらの中継装置７，８，９の構成手段は、ハードウエアで構成してもよいし、専用プログラムをコンピュータで実行することによってソフトウエアで構成してもよい。ＦＥＣ中継装置７，８，９は、同様の構成を有するので、ここでは、中継装置（ｎ）８についてのみ詳細に説明する。
【００５０】
中継装置（ｎ）８では、ネットワーク（Ｎ−１）４からパケット単位でＦＥＣデータを受信し、ネットワーク（Ｎ）５のプロトコル等を考慮してネットワーク（Ｎ）５を介して中継装置（ｎ＋１）９にパケット単位でＦＥＣデータを送信する。また、中継装置（ｎ）８では、受信したＦＥＣデータの冗長度レベルを監視し、冗長度レベルが低下しているために中継装置（ｎ＋１）９で冗長度が不足する可能性がある場合には受信したＦＥＣデータを復号化及び冗長度レベルを上げるために再符号化する。
【００５１】
パケットスイッチ８ａでは、受信したＦＥＣデータの冗長度レベルを調べる。そして、パケットスイッチ８ａでは、受信したＦＥＣデータの冗長度レベルと下流側のネットワーク（Ｎ）５のＱｏｓ情報（パケットロスレート等）とに基づいて、そのまま受信したＦＥＣデータをネットワーク（Ｎ）５で伝送すると、中継装置（ｎ＋１）９で冗長度が不足するか否かを判定する。冗長度が不足しないと判定した場合、パケットスイッチ８ａでは、ＦＥＣを行わないと決定し、受信したＦＥＣデータをそのままネットワーク（Ｎ）５を介して中継装置（ｎ＋１）９にパケット単位で送信する。一方、冗長度が不足すると判定した場合、パケットスイッチ８ａでは、ＦＥＣを行うと決定し、受信したＦＥＣデータをＦＥＣデコーダ８ｂに送る。なお、パケットスイッチ８ａは、ネットワーク（Ｎ）５のみならず、更に下流側のネットワーク（Ｎ＋Ｉ）のＱｏｓ情報を考慮して、受信先２で冗長度が不足するか否かを判定してもよい。
【００５２】
ＦＥＣデコーダ８ｂでは、パケット単位のＦＥＣデータを復号化し、ストリーミングコンテンツの元データに復号化する。そして、ＦＥＣデコーダ８ｂでは、この元データをバッファメモリ８ｃに一時記憶させる。
【００５３】
ＦＥＣエンコーダ８ｄでは、ＦＥＣパラメータを設定する。そして、ＦＥＣエンコーダ８ｄでは、設定したＦＥＣパラメータに基づいて、ＬＴ符号によるＦＥＣによって、バッファメモリ８ｃに一時記憶されている元データをＦＥＣデータに再符号化する。そして、ＦＥＣエンコーダ８ｄでは、再符号化したＦＥＣデータをパケット単位でパケットスイッチ８ａに送り、パケットスイッチ８ａから下流のネットワーク（Ｎ）５を介して中継装置（ｎ＋１）９にそのパケット単位のＦＥＣデータを送信する。なお、この符号化では、ブロックの全てのパケットが復号化されてからブロック単位で復号化してもよいし、ブロックに対する復号化の途中でパケット単位で順次再符号化してもよい。
【００５４】
図４を参照して、ＦＥＣパラメータの設定方法について説明する。図４は、ＦＥＣのパラメータの説明図である。
【００５５】
ＦＥＣパラメータは、ＦＥＣによる符号化を行う際に必要なパラメータであり、想定最大パケットロス（冗長度レベル）、目標パケット再生誤り率、ＦＥＣオーバヘッド、ブロック長、パケット長等がある。これらのＦＥＣパラメータは、受信したＦＥＣデータの冗長度レベルと、受信したＦＥＣデータのパケットヘッダ情報、下流側のネットワークのＱｏＳ情報、ネットワーク全体の装置（送信元、受信先、中継装置）のリソース情報及び下流の中継装置（ｎ＋ｉ）の受信情報等とに基づいて設定する。
【００５６】
パケットヘッダ情報としては、サービスレベル情報として誤り率優先度、遅延優先度、ＳＬＡ情報等があり、アプリケーションタイプとしてストリーミングコンテンツ、電話、対話型ゲーム等がある。サービスレベル情報を考慮することによって、設定されているサービスレベルより低下しないように、ＦＥＣパラメータを設定する。アプリケーションタイプを考慮することにより、遅延に敏感なアプリケーションやパケットロスに敏感なアプリケーション等の各アプリケーションが要求するＱｏＳを満たすように、ＦＥＣパラメータを設定する。ちなみに、サービスレベル情報やアプリケーションタイプは、パケットの固定長の領域に設定されているので、高速に認識することができる。
【００５７】
下流側のネットワークのＱｏＳ情報としては、パケットロスレート、実効帯域、エラーレート、遅延、最大バースト長、ジッタ等がある。例えば、受信したＦＥＣデータの冗長度レベルが低下していると、下流側のネットワークのパケットロスレートによって下流の中継装置や受信先において冗長度レベルが０％未満になってしまう（冗長度が不足してしまう）と予測できる場合には、冗長度レベルを上げるように、ＦＥＣパラメータを設定する。その際、送信データの伝送帯域が下流側のネットワークの実効帯域を越えない範囲で、ＦＥＣパラメータを設定する。
【００５８】
装置のリソース情報としては、ＣＰＵ[Central Processing unit]の利用率、空きメモリ等がある。ネットワーク全体を見渡して、ＣＰＵの演算能力に余裕のある装置やメモリに余裕のある装置において復号化及び再符号化を行うように、ＦＥＣパラメータを設定する。
【００５９】
下流の中継装置の受信情報としては、受信パケットレートあるいはパケット充足情報、遅延、バッファメモリ等がある。下流側でパケットロスが発生しないかとかあるいは遅延時間が長くなっていないか等の下流の中継装置の受信情報も考慮して、ＦＥＣパラメータを設定する。
【００６０】
図１乃至図４を参照して、中継装置（ｎ）８の動作について説明する。前提として、送信元１において０．３ＭｂｐｓのストリーミングコンテンツがＦＥＣデータに符号化され、パケット単位のＦＥＣデータがネットワーク（Ｓ）３で伝送される。そして、パケット単位のＦＥＣデータは、ネットワーク（Ｓ）３を介して中継装置（ｎ−１）７で受信される。中継装置（ｎ−１）７では、パケット単位のＦＥＣデータの冗長度レベル及びネットワーク（Ｎ−１）４のＱｏＳ情報等に基づいてＦＥＣを実施するか否かを判定し、ＦＥＣを実施しない場合には受信したパケット単位のＦＥＣデータをそのままネットワーク（Ｎ−１）４を介して中継装置（ｎ）８に送信し、ＦＥＣを実施する場合には受信したパケット単位のＦＥＣデータを復号化及び再符号化して冗長度を改善したＦＥＣデータをネットワーク（Ｎ−１）４を介して中継装置（ｎ）８に送信する。そして、そのパケット単位のＦＥＣデータは、中継装置（ｎ）８で受信される。
【００６１】
中継装置（ｎ）８では、受信したパケット単位のＦＥＣデータの冗長度レベルを調べ、その冗長度レベルとネットワーク（Ｎ）５のＱｏＳ情報とに基づいて、ＦＥＣを実施するか否かを判定する。例えば、パケット単位のＦＥＣデータの冗長度レベルが５％まで低下している場合、ネットワーク（Ｎ）５の最大パケットロスレートが２５％であるため、ネットワーク（Ｎ）５でパケットロスが発生して、中継装置（ｎ−１）９では冗長度レベルが０％未満に低下してしまう。このような場合、中継装置（ｎ）８では、ＦＥＣを実施して、冗長度の改善を図る。
【００６２】
ＦＥＣを実施しないと判定した場合、中継装置（ｎ）８では、受信したパケット単位のＦＥＣデータを、そのままネットワーク（Ｎ）５を介して中継装置（ｎ＋１）９に送信する。
【００６３】
一方、ＦＥＣを実施すると判定した場合、中継装置（ｎ）８では、受信したパケット単位のＦＥＣデータを復号化する。さらに、中継装置（ｎ）８では、ネットワーク（Ｎ）５のＱｏＳ情報やアプリケーション及びサービスレベル等に基づいて、ＦＥＣパラメータを設定する（図４参照）。例えば、ネットワーク（Ｎ）５の最大パケットロスレートが２５％であるため、冗長度レベルとして３０％程度を設定する。そして、中継装置（ｎ）８では、設定したＦＥＣパラメータに基づいて、復号化したデータをＬＴ符号によるＦＥＣによってＦＥＣデータに再符号化する。続いて、中継装置（ｎ）８では、再符号化したパケット単位のＦＥＣデータをネットワーク（Ｎ）５を介して中継装置（ｎ＋１）９に送信する。
【００６４】
その後、パケット単位のＦＥＣデータは、ネットワーク（Ｎ）５を介して中継装置（ｎ＋１）９で受信される。中継装置（ｎ＋１）９では、パケット単位のＦＥＣデータの冗長度レベル及びネットワーク（Ｄ）６のＱｏＳ情報等に基づいてＦＥＣを実施するか否かを判定し、ＦＥＣを実施しない場合には受信したパケット単位のＦＥＣデータをそのままネットワーク（Ｄ）６を介して受信先２に送信し、ＦＥＣを実施する場合には受信したパケット単位のＦＥＣデータを復号化及び再符号化して冗長度を改善したＦＥＣデータをネットワーク（Ｄ）６を介して受信先２に送信する。そして、そのパケット単位のＦＥＣデータは、受信先２で受信される。受信先２では、受信したパケット単位のＦＥＣデータを順次復号化し、ストリーミングコンテンツとして再生する。この復号化では、中継装置７，８，９において冗長度が改善されているので、ストリーミングコンテンツにロスパケットの発生やマクロブロックエラー等のエラーが発生しない。
【００６５】
中継装置７，８，９によれば、ネットワーク全体における途中で冗長度を改善することができるので、送信元１でネットワーク全体のＱｏＳ情報を考慮して大きな冗長度レベルを設定する必要がなく、送信データの伝送帯域を抑えることができる。また、中継装置７，８，９によれば、下流側のネットワークのＱｏＳ情報が考慮されて冗長度を改善しているので、受信先２においてＦＥＣデータを完全に元データに復号化できる。
【００６６】
さらに、中継装置７，８，９によれば、アプリケーションやサービスレベルに応じてＦＥＣパラメータを設定しているので、各アプリケーションが要求するＱｏＳを満足させてアプリケーションを伝送することができ、サービスレベルも維持することができる。
【００６７】
次に、第２の実施の形態について説明する。図５を参照して、第２の実施の形態に係るネットワークの全体構成について説明する。図５は、第２の実施の形態に係るネットワーク全体の構成図である。第２の実施の形態では、第１の実施の形態に係る構成と同様の構成について同一の符号を付し、その説明を省略する。
【００６８】
第２の実施の形態では、送信元１から受信先２にストリーミングコンテンツを、４つのネットワーク３，４，５，６を介して配信し、この４つのネットワーク３，４，５，６の接続点に設けられた中継装置１７，１８，１９でデータを中継している。
【００６９】
中継装置１７，１８，１９は、ネットワーク間のデータを中継する装置であり、例えば、ＩＳＰ等に設けられているルータ、ゲートウエイ等である。特に、中継装置１７，１８，１９では、受信したパケット単位のＦＥＣデータをそのまま下流の中継装置１８，１９又は受信先２に転送するとともに、同時に、受信したパケット単位のＦＥＣデータを復号化する。そして、中継装置１７，１８，１９（又は受信先２）では、ＦＥＣデータを完全に復号化できない場合、不足している冗長度分を補うために、上流の中継装置１７，１８，１９又は送信元１から符号化されたパケット単位のＦＥＣデータを送信してもらう。そして、中継装置１７，１８，１９（又は受信先２）では、その送信してもらったパケット単位のＦＥＣデータによって完全に復号化できた場合、上流の中継装置１７，１８，１９又は送信元１からの送信を停止させる。また、中継装置１７，１８，１９（又は送信元１）では、下流の中継装置１７，１８，１９又は受信先２に符号化したパケット単位のＦＥＣデータを送信するために、復号化したデータを再符号化する。そのために、中継装置１７，１８，１９は、パケットコピー１７ａ，１８ａ，１９ａ、ＦＥＣデコーダ１７ｂ，１８ｂ，１９ｂ、バッファメモリ１７ｃ，１８ｃ，１９ｃ及びＦＥＣエンコーダ１７ｄ，１８ｄ，１９ｄを備えている。ちなみに、これらの中継装置１７，１８，１９の構成手段は、ハードウエアで構成してもよいし、専用プログラムをコンピュータで実行することによってソフトウエアで構成してもよい。ＦＥＣ中継装置１７，１８，１９は、同様の構成を有するので、ここでは、中継装置（ｎ）１８についてのみ詳細に説明する。
【００７０】
中継装置（ｎ）１８では、ネットワーク（Ｎ−１）４からパケット単位でＦＥＣデータを受信し、ネットワーク（Ｎ）５のプロトコル等を考慮して、そのパケット単位でＦＥＣデータをそのままネットワーク（Ｎ）５を介して中継装置（ｎ）１９に転送する。同時に、中継装置（ｎ）１８では、受信したＦＥＣデータを復号化する。そして、中継装置（ｎ）１８では、受信したＦＥＣデータを完全に復号化できない場合、上流の中継装置（ｎ−１）１７から送信された再符号化されたＦＥＣデータを受信し、その再符号化されたＦＥＣデータに基づいてＦＥＣデータを完全に復号化する。ＦＥＣデータを完全に復号化できると、中継装置（ｎ）１８では、中継装置（ｎ−１）１７からの送信を中止させる。また、中継装置（ｎ）１８では、下流の中継装置（ｎ＋１）１９においてＦＥＣデータを完全に復号化できない場合に対応するために、復号化したデータを再符号化し、再符号化したパケット単位のＦＥＣデータを下流の中継装置（ｎ＋１）１９に送信する。そして、中継装置（ｎ）１８では、下流の中継装置（ｎ＋１）１９からの送信中止要求に応じて、ＦＥＣデータの送信を中止するとともに復号化及び再符号化も中止する。
【００７１】
パケットコピー１８ａでは、ネットワーク（Ｎ−１）４からパケット単位のＦＥＣデータを受信すると、そのパケット単位のＦＥＣデータをそのままネットワーク（Ｎ）を介して中継装置（ｎ＋１）１９に送信するとともに、ＦＥＣデコーダ１８ｂに送る。
【００７２】
ＦＥＣデコーダ１８ｂでは、パケット単位のＦＥＣデータを復号化し、ストリーミングコンテンツの元データに復号化する。そして、ＦＥＣデコーダ１８ｂでは、この元データをバッファメモリ１８ｃに一時記憶させる。また、ＦＥＣデコーダ１８ｂでは、ＦＥＣデータを元データに１００％復号化できたか否かを判定する。元データに１００％復号化できない場合、ＦＥＣデコーダ１８ｂでは、上流の中継装置（ｎ−１）１７に対して、中継装置（ｎ−１）１７で再符号化したＦＥＣデータを送信してもらう送信要求を送信する。そして、ＦＥＣデコーダ１８ｂでは、元データに１００％復号化できるまで、中継装置（ｎ−１）１７からの再符号化したＦＥＣデータを復号化する。この際、中継装置（ｎ−１）１７からは、同じ再符号化したＦＥＣデータが繰り返し送信されてくる。一方、元データに１００％復号化できた場合、ＦＥＣデコーダ１８ｂでは、上流の中継装置（ｎ−１）１７に対して、中継装置（ｎ−１）１７で再符号化したＦＥＣデータの送信を中止する送信中止要求を送信するとともに、復号化を終了する。
【００７３】
ＦＥＣエンコーダ１８ｄでは、下流の中継装置（ｎ＋１）１９からの送信要求を受信すると、設定したＦＥＣパラメータに基づいて、ＬＴ符号によるＦＥＣによって、バッファメモリ１８ｃに一時記憶されている元データをＦＥＣデータに再符号化する。この際、ＦＥＣエンコーダ１８ｄでは、ＦＥＣパラメータを設定するが、ＦＥＣパラメータの設定方法については第１の実施の形態と同様である。そして、ＦＥＣエンコーダ１８ｄでは、再符号化したＦＥＣデータをパケット単位でパケットコピー１８ａに送り、パケットコピー１８ａから下流のネットワーク（Ｎ）５を介して中継装置（ｎ＋１）１９にその再符号化したパケット単位のＦＥＣデータを送信する。この際、ＦＥＣエンコーダ１８ｄでは、中継装置（ｎ＋１）１９から送信中止要求が送信されるまで、同じパケット単位のＦＥＣデータを繰り返し送信し続ける。また、ＦＥＣエンコーダ１８ｄでは、下流の中継装置（ｎ＋１）１９からの送信中止要求を受信すると、バッファメモリ１８ｃに一時記憶させていた復号化データを消去するとともに、再符号化を終了する。なお、ＦＥＣエンコーダ１８ｄでは、冗長度レベルを変えずに符号化する場合もある。
【００７４】
なお、第２の実施の形態では、送信元１及び受信先２では、第１の実施の形態の処理に加えて以下の処理も行う。送信元１では、中継装置（ｎ−１）１７の送信要求に応じてパケット単位のＦＥＣデータを繰り返し送信し、送信中止要求に応じて送信を中止する。受信先２では、ＦＥＣデータを元データに完全に復号化できな場合には中継装置（ｎ＋１）１９に対して送信要求を送信して再符号化したパケット単位のＦＥＣデータを送信してもらい、その再符号化したＦＥＣデータによって元データに完全に復号化できた場合には中継装置（ｎ＋１）１９に対して送信中止要求を送信する。
【００７５】
図５を参照して、中継装置（ｎ）１８の動作について説明する。前提として、送信元１において０．３ＭｂｐｓのストリーミングコンテンツがＦＥＣデータに符号化され、パケット単位のＦＥＣデータがネットワーク（Ｓ）３で伝送される。そして、パケット単位のＦＥＣデータは、ネットワーク（Ｓ）３を介して中継装置（ｎ−１）１７で受信される。中継装置（ｎ−１）１７では、パケット単位のＦＥＣデータをそのままネットワーク（Ｎ−１）４を介して中継装置（ｎ）１８に送信する。さらに、中継装置（ｎ−１）１７では、パケット単位のＦＥＣデータを復号化するとともに、中継装置（ｎ）１８からの送信要求に応じて復号化データを再符号化し、この再符号化したＦＥＣデータをネットワーク（Ｎ−１）４を介して中継装置（ｎ）１８に送信する。そして、そのパケット単位のＦＥＣデータ及び再符号化されたＦＥＣデータは、中継装置（ｎ）１８で受信される。
【００７６】
中継装置（ｎ）１８では、パケット単位のＦＥＣデータを受信すると、パケット単位のＦＥＣデータをそのままネットワーク（Ｎ）５を介して中継装置１９に送信するとともに、パケット単位のＦＥＣデータを復号化する。
【００７７】
そして、中継装置（ｎ）１８では、ＦＥＣデータを元データに完全に復号化できたか否かを判定する。完全に復号化できないと判定した場合、中継装置（ｎ）１８では、中継装置（ｎ−１）１７に対して再符号化したＦＥＣデータを送信してもらう送信要求を送信し、元データに完全に復号化できるまで中継装置（ｎ−１）１７からの再符号化したＦＥＣデータを用いて復号化する。一方、完全に復号化できたと判定した場合、中継装置（ｎ）１８では、中継装置（ｎ−１）１７に対して再符号化したＦＥＣデータの送信を中止する送信中止要求を送信し、復号化を終了する。
【００７８】
さらに、中継装置（ｎ）１８では、中継装置（ｎ＋１）１９からの送信要求を受信すると、ＬＴ符号によるＦＥＣによって復号化したデータをＦＥＣデータに再符号化する。そして、中継装置（ｎ）１８では、再符号化したＦＥＣデータをパケット単位でネットワーク（Ｎ）５を介して中継装置（ｎ＋１）１９を送信する。また、中継装置（ｎ）１８では、中継装置（ｎ＋１）１９からの送信中止要求を受信すると、バッファメモリ１８ｃに一時記憶させていた復号化データを消去するとともに、再符号化を終了する。
【００７９】
その後、パケット単位のＦＥＣデータ及び中継装置（ｎ＋１）１９からの要求に応じた再符号化したＦＥＣデータは、ネットワーク（Ｎ）５を介して中継装置（ｎ＋１）１９で受信される。中継装置（ｎ＋１）１９では、パケット単位のＦＥＣデータをそのままネットワーク（Ｄ）６を介して受信先２に送信する。さらに、中継装置（ｎ＋１）１９では、パケット単位のＦＥＣデータを復号化するとともに、受信先２からの送信要求に応じて復号化データを再符号化し、この再符号化したＦＥＣデータをネットワーク（Ｄ）６を介して受信先２に送信する。そして、そのパケット単位のＦＥＣデータ及び再符号化されたＦＥＣデータは、受信先２で受信される。受信先２では、受信したパケット単位のＦＥＣデータを順次復号化するが、このＦＥＣデータで完全に復号化できない場合には再符号化されたＦＥＣデータを用いて復号化する。そして、受信先２では、復号化したデータによりストリーミングコンテンツとして再生する。この復号化では、中継装置１７，１８，１９においてＦＥＣデータを完全に復号化して冗長度を改善しているので、ストリーミングコンテンツにロスパケットの発生やマクロブロックエラー等のエラーが発生しない。
【００８０】
中継装置１７，１８，１９によれば、ＦＥＣデータをそのまま下流に転送するとともにそのＦＥＣデータを復号化しているので、遅延を極力抑えることができる。また、中継装置１７，１８，１９では、ＦＥＣデータを元データに１００％復号化できるまで上流から再符号化したＦＥＣデータを補充するので、元データに１００％復号化することができ、ひいては受信先２で元データに１００％復号化することができる。そのため、送信元１でネットワーク全体のＱｏＳ情報を考慮して冗長度レベルを設定する必要がなく、送信データの伝送帯域を抑えることができる。
【００８１】
以上、本発明に係る実施の形態について説明したが、本発明は上記実施の形態に限定されることなく様々な形態で実施される。
【００８２】
例えば、本実施の形態ではＩＳＰ等から個人等にストリーミングコンテンツを配信する場合に適用したが、個人と個人との場合、アプリケーションとしても電話や対戦型ゲーム等の場合における様々なネットワークを介して通信に適用可能である。
【００８３】
また、本実施の形態ではネットワーク上の全ての中継装置において本発明に係る処理を行う構成としたが、ネットワーク上の一部の中継装置において本発明に係る処理を行う構成としてもよいし、ネットワーク上の全ての中継装置において処理を行う場合でも処理能力に余裕のある中継装置が優先的に処理を行うように構成してもよい。
【００８４】
また、本実施の形態ではＦＥＣとしてＬＴ符号を用いたが、ハミング符号、ＢＣＨ符号、リードソロモン符号、トルネード符号等の他のＦＥＣを用いてもよい。
【００８５】
また、本実施の形態では送信元から受信先まで１本の経路の場合で説明したが、中継装置又は受信元において複数の経路（ネットワーク）に分岐する場合でも適用可能であり、この場合には分岐する各経路（ネットワーク）のＱｏＳ情報等に基づいて最適な経路も決定する。
【００８６】
また、本実施の形態ではサービスレベル（サービス種別）をＩＰヘッダに設定したが、ＵＤＰヘッダ等の他の固定長のデータ領域に設定してよいし、ヘッダのデータ構成も他の構成としてもよい。
【００８７】
また、本実施の形態ではネットワークのＱｏＳ情報を直接用いたが、ＱｏＳ情報のうちの任意の情報に対して四則演算する等の二次情報を用いてよい。
【図面の簡単な説明】
【００８８】
【図１】本発明の第１の実施の形態に係るネットワーク全体の構成図である。
【図２】本発明の実施の形態に係るパケットの説明図であり、（ａ）はパケットの構成図であり、（ｂ）はＩＰヘッダのデータ構成図である。
【図３】ＦＥＣのＬＴ符号の概念図である。
【図４】本発明の実施の形態に係るＦＥＣのパラメータの説明図である。
【図５】本発明の第２の実施の形態に係るネットワーク全体の構成図である。
【図６】従来のネットワーク全体の構成図である。
【符号の説明】
【００８９】
１…送信元、１ａ…ＦＥＣエンコーダ、２…受信先、２ａ…ＦＥＣデコーダ、２ｂ…ストリーミングビュワ、３，４，５，６…ネットワーク、７，８，９，１７，１８，１９…中継装置、７ａ，８ａ，９ａ…パケットスイッチ、７ｂ，８ｂ，９ｂ，１７ｂ，１８ｂ，１９ｂ…ＦＥＣデコーダ、７ｃ，８ｃ，９ｃ，１７ｃ，１８ｃ，１９ｃ…バッファメモリ、７ｄ，８ｄ，９ｄ，１７ｄ，１８ｄ，１９ｄ…ＦＥＣエンコーダ、１７ａ，１８ａ，１９ａ…パケットコピー
【図１】
0004577341.tif 000002
【図２】
0004577341.tif 000003
【図３】
0004577341.tif 000004
【図４】
0004577341.tif 000005
【図５】
0004577341.tif 000006
【図６】
0004577341.tif 000007