JP2004015551A - Repeating device, repeating program, and autonomous error correction network - Google Patents
Repeating device, repeating program, and autonomous error correction network Download PDFInfo
- Publication number
- JP2004015551A JP2004015551A JP2002167692A JP2002167692A JP2004015551A JP 2004015551 A JP2004015551 A JP 2004015551A JP 2002167692 A JP2002167692 A JP 2002167692A JP 2002167692 A JP2002167692 A JP 2002167692A JP 2004015551 A JP2004015551 A JP 2004015551A
- Authority
- JP
- Japan
- Prior art keywords
- data
- relay device
- redundancy
- fec
- packet
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
Images
Abstract
Description
【０００１】
【発明の属する技術分野】
本発明は、１つ又は複数のネットワーク相互の接続点に設けられている中継装置、中継用プログラム及び自律型誤り訂正ネットワークに関する。
【０００２】
【従来の技術】
近年、インターネットやイントラネットにおいて、ブロードバンドの加入者が急速に増大している。そのブロードバンドのアプリケーションとしては、音楽や映像のダウンロード配信やストリーミング配信のような一定の帯域や品質を要求するもの、実時間通信等の大容量で高速のコンテンツ配信サービスの実現を要求するものが増えつつある。これらのアプリケーションが、ＦＴＴＨ［Ｆｉｂｅｒ Ｔｏ Ｔｈｅ Ｈｏｍｅ］のような更なる高速のブロードバンドサービスの市場を牽引することが期待されている。この高速のブロードバンドサービスではダウンロードにおいては１分以内にダウンロードできる高速性、また、ストリーミングにおいては途中で停止したりあるいはマクロブロックエラー等を発生させないサービスレベルの実現が、優良なコンテンツの確保やデジタル著作権管理技術の標準化等と合わせて、我が国のブロードバンド市場発展の鍵とさえ言われている。
【０００３】
このような大容量な情報を高速かつリアルタイムに処理し、それぞれの用途に応じた品質要求に答える技術としては、コアネットワークにおいてはＭＰＬＳ［Ｍｕｌｔｉ Ｐｒｏｔｏｃｏｌ Ｌａｂｅｌ Ｓｗｉｔｃｈｉｎｇ］を用いたレイヤ２におけるハードウエアレベルでの高速スイッチング技術等が開発され、また、エッジネットワークにおいてはコンテンツを分割し、キャッシュする技術等が実用化されている。
【０００４】
しかし、さまざまな時代のネットワーク技術の集合体であるインターネットにおけるＥｎｄ−ｔｏ−Ｅｎｄで高速性やサービスレベルを確保する技術は、今だに目処がたっていないのが現状である。インターネットの基礎をなすＴＣＰ／ＩＰ［Ｔｒａｎｓｍｉｓｓｉｏｎ Ｃｏｎｔｒｏｌ Ｐｒｏｔｏｃｏｌ／Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ］では、フロー制御とロスパケットの再送要求によって信頼性の高い通信を実現している。しかし、ロスパケットの再送は、アクセスの集中による輻輳が再送によって更なる輻輳を呼び、広帯域メディアのサービスレベルを確保する上で、本質的な解決策とはなっていない。
【０００５】
また、ダウンロードに使用するプロトコルとして普及しているＦＴＰ［Ｆｉｌｅ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ］では、再送によるネットワークの混雑を防止するために、個々の受け手側の受信能力を伝送帯域と遅延時間の積で定義し、これを一定とすることによりフロー制御が行われている。そのため、パケットの再送が発生し、遅延時間が増大すると、伝送帯域が低下し、ブロードバンドに見合った高速のダウンロードが行えない。
【０００６】
また、ストリーミングにおいて普及している様々なメディアフォーマットでは、ＱｏＳ［Ｑｕａｌｉｔｙ ｏｆ Ｓｅｒｖｉｃｅ］の乏しいネットワーク上でも画質を維持するために各種工夫が施されているが、０．１〜１％程度のパケットロスによって再生映像にマクロブロックエラーやフレームスキップが発生する場合がある。これらのストリーミング配信では、スループットを確保するため、フロー制御とロスパケットの再送を行わないＵＤＰ［Ｕｓｅｒ Ｄａｔａｇｒａｍ Ｐｒｏｔｏｃｏｌ］を用いている場合が多い。ＵＤＰは、ネットワークの輻輳に対してネットワークへの負担を軽減するスキームを持たないため、各アプリケーションの中には自律学習的に解像度を低下させ、個々のフローのサービスレベルを低下させるスキームを専用プロトコルで実現しているものである。ところが、ネットワークの輻輳に対する追従感度は十分なものではなく、特に、輻輳解消後のサービスレベルの復帰は極めて遅く、僅かな時間の輻輳で番組全体の品質の低下するといった問題がある。
【０００７】
そのため、ＡＤＳＬ［Ａｓｙｍｍｅｔｒｉｃ Ｄｉｇｉｔａｌ Ｓｕｂｓｃｒｉｂｅｒ Ｌｉｎｅ］等によるブロードバンドの爆発的な普及にもかかわらず、インターネット上での本格的なブロードバンドＣＤＳ［Ｃｉｒｃｕｉｔ Ｄｅｓｉｇｎ Ｓｅｒｖｉｃｅ］の普及は難しい。これにより、日本国内でのＦＴＴＨの需要の増加の重要な律速要因の一つとなっているのが現状である。
【０００８】
一方、ＴＣＰ／ＩＰのフロー制御やロスパケットの再送に依存しないＱｏＳの実現手段としては、ＵＤＰと順方向誤り訂正（以下、ＦＥＣ［Ｆｏｒｗａｒｄ Ｅｒｒｏｒ Ｃｏｒｒｅｃｔｉｏｎ］と記載する）を用いる方法がある。
【０００９】
【課題を解決しようとする課題】
しかしながら、従来のＦＥＣは、主として、ＯＳＩ［Ｏｐｅｎ Ｓｙｓｔｅｍｓ Ｉｎｔｅｒｃｏｎｎｅｃｔｉｏｎ］モデルのレイヤ１においてＳ／Ｎの改善に用いられてきたが、バースト的なエラーへの耐性を高めるには送信データに予めランダム性を持たせる工夫が必要である。そのため、バースト的なエラーへの耐性と送信データの遅延時間にトレードオフの関係を生じることから、電話等に利用されるＶｏＩＰ［Ｖｏｉｃｅ Ｏｖｅｒ Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ］のような遅延時間に厳しいアプリケーションで用いるには必ずしも適切ではなかった。
【００１０】
また、ＦＥＣは、Ｅｎｄ−ｔｏ−Ｅｎｄのエラーレートやパケットロスレートを予め想定してエンコーダを行うが、本質的に自立したネットワークの集合体であるインターネットにおいてＥｎｄ−ｔｏ−Ｅｎｄのエラーレートやパケットロスレートを予め想定することは困難であった。Ｅｎｄ−ｔｏ−Ｅｎｄのエラーレートやパケットロスレートを予め想定できた場合でも、送信元においてその分の冗長度レベルを大きくしたＦＥＣデータを送信するので、ネットワークの伝送帯域の使用効率が低下するとともに伝送時間も増大する。特に、公衆回線を利用したネットワークを介して個人が個人にデータを送受信する場合、ネットワーク途中におけるエラーレートやパケットロスレートを考慮して冗長度レベルを大きくすると、送信するデータ量が増加するため、個人のコスト負担が増加する。つまり、個人が、ネットワーク途中におけるエラーレートやパケットロスレート等に対するコスト負担をしなければならない。
【００１１】
図６を参照して、ＡＳＰ等の送信元１００から個人のパーソナルコンピュータ（以下、パソコンと記載する）等の受信先１０１にネットワーク１０２，１０３，１０４，１０５を介してストリーミングコンテンツを送信した場合の一例を説明する。送信元１００から受信先１０１へ４つのネットワーク１０２，１０３，１０４，１０５を介してストリーミングコンテンツのデータを送信する場合、ネットワーク１０２，１０３，１０４，１０５の接続点には３つの中継装置１０６，１０７，１０８が存在する。ここで、ストリーミングコンテンツのデータ容量を０．３Ｍｂｐｓとし、ネットワーク１０２，１０３，１０４，１０５における最大パケットロスレートを各々１％、１５％、２５％、１％とし、パケットオーバヘッドを１０８６／１０２４とし、ＦＥＣのオーバヘッドを１．０５とする。この場合、送信元１００から送信したＦＥＣデータを受信先１０１でロスパケット無しで復号化するためには、ストリーミングコンテンツのデータに対して最大パケットロスレート、パケットオーバヘッド及びＦＥＣのオーバヘッドを加味しなければならない。そのため、送信元１００では、これらのＱｏＳ情報を考慮して冗長度レベル（約７７％）を設定し、ＦＥＣを実施してストリーミングコンテンツ（０．３Ｍｂｐｓ）のデータを符号化すると、伝送帯域としては０．５３Ｍｂｐｓが必要となる。しかし、送信元１００に接続されているネットワーク１０２の実効帯域は０．５Ｍｂｐｓなので、伝送帯域が０．５３ＭｂｐｓのＦＥＣデータを送信することはできない。したがって、送信元１００から０．５ＭｂｐｓのＦＥＣデータを送信したとすると、受信先１０１においてロスパケットが発生し、ストリーミングコンテンツを完全に再生することはできない。ちなみに、この例では、データの伝送途中であるネットワーク１０３，１０４におけるパケットロスを考慮して冗長度レベルを設定しているので、送信元１００あるいは受信先１０１では、これらのネットワーク１０３，１０４におけるパケットロスも伝送コストとして負担しなければならない。
【００１２】
さらに、ＣＤ−ＲＯＭやＤＶＤ等のＦＥＣに広く用いられているリードソロモン符号等の既存のＦＥＣ技術では、そもそも演算処理時間がコンテンツレートや誤り訂正の対象とするパケットロスのバースト長に対してほぼ二乗に比例する傾向があるため、映像や音楽等のリッチコンテンツと呼ばれる広帯域データをバースト的なパケットロスが発生するインターネット上で配信するアプリケーションに対して適用することはこれまで容易ではなかった。
【００１３】
上記した技術については、特開２００１−１８９６６５号公報、ＵＳＰ６３０７４８７等に開示されていが、上記問題点を解決手段については開示されていない。
【００１４】
そこで、本発明は、ネットワークの伝送帯域の使用効率及びデータ送信時の遅延並びにＱｏＳに優れる中継装置、中継用プログラム及びネットワークを提供することを課題とする。
【００１５】
【課題を解決するための手段】
本発明に係る中継装置は、送信部から受信部にデータを送信する際に利用される１つ又は複数のネットワーク相互の接続点に設けられている中継装置であって、中継装置の下流側に位置する１つ又は複数のネットワークのサービス品質情報又はサービス品質情報の二次情報に基づいて、データの冗長度の改善の要否並びに冗長度レベルを決定する決定手段と、データの冗長度を改善する冗長度改善手段とを備えることを特徴とする。
【００１６】
この中継装置によれば、データを送信するネットワークの途中において、下流側の位置する１つ又は複数のネットワークのサービス品質情報に基づいて冗長度を改善することできる。そのため、送信部において小さな冗長度レベルによって順方向誤り訂正を実施したデータを送信した場合にネットワークの途中で冗長度レベルが低下しても、ネットワークの途中の中継装置で冗長度を改善でき、受信部においてパケットロスが発生しない。したがって、データを小さな冗長度で送信できるととともにパケットロスを無くすことができるので、伝送帯域の使用効率が向上するとともに伝送時間を短縮でき、さらに、Ｅｎｄ−ｔｏ−ＥｎｄにおけるＱｏｓやサービスレベルも向上する。
【００１７】
ちなみに、あるフローが経由するｍ個の部分ネットワーク（ｎ）の最大パケットロスレートをＬ（ｎ）％とすると、このフローのネットワーク全体のパケットロスレートは、１−（（１−Ｌ（１））×（１−Ｌ（２））×・・・×（１−Ｌ（ｍ）））で表される。これを考慮してＦＥＣを行うと、送信元の送信するデータの冗長度レベルは膨大となり、送信元付近の部分ネットワークあるいは中継装置におけるトラフィックが膨大となる。そのため、従来、経済的にリッチコンテンツを配信することは不可能であり、想定以上のパケットロスが発生するとサービスレベルが低下した。しかし、本発明に係る中継装置によれば、ネットワークの区間毎に失った冗長性を回復しながら次のネットワークに中継するので、各ネットワークで有効に伝送帯域を利用しながら、サービスレベルも低下しない。
【００１８】
なお、送信部は、ネットワークを介してデータを送信する送信元であり、例えば、個人（パーソナルコンピュータ等の送信装置を含む）、ＩＳＰ［Ｉｎｔｅｒｎｅｔ Ｓｅｒｖｉｃｅ Ｐｒｏｖｉｄｅｒ］（サーバ等の送信装置を含む）、ＡＳＰ［Ａｐｐｌｉｃａｔｉｏｎ Ｓｅｒｖｉｃｅ Ｐｒｏｖｉｄｅｒ］（サーバ等の送信装置を含む）等である。受信部は、ネットワークを介してデータを受信する受信先であり、例えば、個人や法人（パーソナルコンピュータ等の受信装置を含む）等である。ネットワークは、例えば、インターネット、イントラネット等である。中継装置は、ネットワーク間における接続点に設けられ、データを上流側から下流側に中継する装置あり、例えば、ＩＳＰやＡＳＰにおかれたルータ、ゲートウエイ等である。ちなみに、送信部も、中継装置における処理を行う場合がある。サービス品質情報は、ネットワークにおけるＱｏＳに関する情報であり、例えば、パケットロスレート、エラーレート、遅延、ジッタ等である。サービス品質情報の二次情報は、サービス品質情報の中のある１つの情報あるいは複数の情報に対して四則演算等を施した情報である。上流側は、データが送信される際の送信部側である。下流側は、データが送信される際の受信部側である。
【００１９】
本発明の上記中継装置は、フロー毎のアプリケーション及び／又はサービスレベルに応じて、順方向誤り訂正の実施の要否の決定、順方向誤り訂正の種類の決定、冗長度レベルの決定及び／又は順方向誤り訂正のパラメータの設定を行うようにしてもよい。
【００２０】
この中継装置によれば、アプリケーション及び／又はサービスレベルに応じてＦＥＣの実施の要否の決定やＦＥＣの種類の決定等を行うので、様々なアプリケーションに要求されるＱｏＳに応じてＦＥＣによって冗長度を改善することができる。つまり、ＶｏＩＰ等の遅延に敏感なアプリケーションあるいはＶＯＤ等の遅延には鈍感であるがパケットロスにシビアなアプリケーションが存在するが、従来の技術では、ＦＥＣがＯＳＩの下位レイヤで実施されていたため、アプリケーション毎のＱｏＳの要求に対応できなかった。しかし、この中継装置によれば、利用時間、許容遅延、許容パレットロスレート、許容パケットロスバースト数等のＱｏＳの要求の異なるアプリケーション毎に適切なＦＥＣを実施することができる。
【００２１】
なお、フローは、コンテンツ等の送信データの全部又は一部からなる一つ又は複数のブロックで構成されるネットワークを流れるデータの流れを意味する。ＦＥＣの種類としては、ハミング符号、ＢＣＨ［Ｂｏｓｅ Ｃｈａｕｄｈｕｒｉ−Ｈｏｃｑｕｅｎｇｈｅｍ］符号、リードソロモン符号、トルネード符号、ＬＴ［Ｌｕｂｙ Ｔｒａｎｓｆｏｒｍ］符号等がある。
【００２２】
本発明の上記中継装置は、フローのブロック毎に復号化及び再符号化を連続的に実施することによって冗長度を改善するようにしてもよい。
【００２３】
この中継装置によれば、送信されてくるデータを復号化することによって送信部における元データに戻し、その元データを再符号化することによって冗長度レベルを変更することができる。
【００２４】
本発明の上記中継装置は、上流側に位置する送信部又は中継装置から順方向誤り訂正が施されたパケットを追加送信させることによって冗長度を改善するようにしてもよい。
【００２５】
この中継装置によれば、冗長度が不足してパケットロスが発生した場合でも、上流側に位置する送信部又は中継装置からＦＥＣが施されたパケットを追加送信させることによって、その送信されたＦＥＣデータによってパケットロスを解消して完全に復号化することができる。
【００２６】
本発明の上記中継装置は、フローのブロックに対する復号化の途中で、該途中の復号化したパケット単位のデータを順次再符号化することによって冗長度を改善するようにしてもよい。
【００２７】
この中継装置によれば、データの任意のブロックの途中まで復号化したパレット単位の復号化データから順次再符号化することによって、効率的に、ＦＥＣデータを元データに戻すとともにその元データから冗長度を改善したＦＥＣデータを生成することができる。
【００２８】
本発明の上記中継装置は、パケットの固定長のデータ領域にアプリケーション及び／又はサービスレベルを設定するようにしてもよい。
【００２９】
この中継装置によれば、パケットヘッドの予め決められた領域に格納されているデータを参照することによって、ハードウエアにより高速にアプリケーション及び／又はサービスレベルを判別できる。ちなみに、従来のパケット構造ではパケットの可変長のペイロードのＦＥＣヘッダにアプリケーション及び／又はサービスレベルが設定されているので、ソフトウエア処理によってアプリケーション及び／又はサービスレベルを判別していたので、処理時間を要した。
【００３０】
本発明の上記中継装置は、フローの各ブロックのパケット単位のデータを下流側に位置する中継装置又は受信部に転送するとともに該パケット単位のデータを順次復号化し、データを完全に復号化できない場合には上流側に位置する送信部又は中継装置から順方向誤り訂正によって再符号化されたパケット単位のデータを受信してこのデータにより復号化し、データを完全に復号化できた場合には上流側に位置する送信部又は中継装置からのデータの送信を中止させるようにしてもよい。
【００３１】
この中継装置によれば、パケットロス等が発生して転送されたデータによって元データに１００％復号化できない場合でも、上流側に位置する送信部又は中継装置からＦＥＣが施されたパケットを受信することによって、元データに１００％復号化することができる。さらに、この中継装置では、元データに１００％復号化することができた場合には、上流側に位置する送信部又は中継装置に送信中断要求等を送信して送信を中止させるので、上流側の送信部又は中継装置に無駄な処理をさせない。
【００３２】
ちなみに、従来のＦＥＣでは、バースト的なパケットロスやエラーに対する耐性を向上させるためにデータのスクランブルとＦＥＣを組み合わせる必要があり、スクランブル幅を長くするとバースト的なエラーに対する耐性は向上するが、遅延が大きくなった。したがって、従来のＦＥＣを用いて中継装置で復号化と再符号化を繰り返すと、中継装置を経由する毎に遅延が累積し、電話等のＶｏＩＰや対話型ゲーム等に利用できないのは勿論のこと、ＶＯＤやライブ放送等の用途でも遅延が大きくなりすぎて問題が発生する。しかし、本発明に係る中継装置によれば、中継時にデータを全て復号化及び再符号化することなく、不足する冗長分を追加して復号化及び再符号化することができるので、遅延の増加を最低限に抑えることできる。
【００３３】
本発明に係る中継用プログラムは、送信部から受信部にデータを送信する際に利用される１つ又は複数のネットワーク相互の接続点に設けられている中継装置で実行される中継用プログラムであって、コンピュータに、中継装置の下流側に位置する１つ又は複数のネットワークのサービス品質情報又はサービス品質情報の二次情報に基づいて、データの冗長度の改善の要否並びに冗長度レベルを決定する決定手段と、データの冗長度を改善する冗長度改善手段と、して機能させることを特徴とする。
【００３４】
本発明の上記中継用プログラムは、フロー毎のアプリケーション及び／又はサービスレベルに応じて、順方向誤り訂正の実施の要否の決定、順方向誤り訂正の種類の決定、冗長度レベルの決定及び／又は順方向誤り訂正のパラメータの設定を行うようにしてもよい。
【００３５】
本発明の上記中継用プログラムは、フローのブロック毎に復号化及び再符号化を連続的に実施することによって冗長度を改善するようにしてもよい。
【００３６】
本発明の上記中継用プログラムは、上流側に位置する送信部又は中継装置から順方向誤り訂正が施されたパケットを追加送信させることによって冗長度を改善するようにしてもよい。
【００３７】
本発明の上記中継用プログラムは、フローのブロックに対する復号化の途中で、該途中の復号化したパケット単位のデータを順次再符号化することによって冗長度を改善するようにしてもよい。
【００３８】
本発明の上記中継用プログラムは、パケットの固定長のデータ領域にアプリケーション及び／又はサービスレベルを設定するようにしてもよい。
【００３９】
本発明の上記中継用プログラムは、フローの各ブロックのパケット単位のデータを下流側に位置する中継装置又は受信部に転送するとともに該パケット単位のデータを順次復号化し、データを完全に復号化できない場合には上流側に位置する送信部又は中継装置から順方向誤り訂正によって再符号化されたパケット単位のデータを受信してこのデータにより復号化し、データを完全に復号化できた場合には上流側に位置する送信部又は中継装置からのデータの送信を中止させるようにしてもよい。
【００４０】
この中継用プログラムによれば、このプログラムをコンピュータに実行させることによって、上記中継装置の作用及び効果を奏する。
【００４１】
本発明に係る自律型誤り訂正ネットワークは、送信部、受信部、及び、１つ又は複数のネットワーク相互の接続点に設けられている１つ又は複数の中継装置からなる自律型誤り訂正ネットワークであって、中継装置において、下流側に位置する１つ又は複数のネットワークのサービス品質情報に基づいて冗長度の改善の要否を決定し、冗長度の改善が必要な場合には順方向の誤り訂正によりデータの冗長度を改善することを特徴とする。
【００４２】
この自律型誤り訂正ネットワークによれば、データの中継時に冗長度を改善することができるので、各ネットワークで有効に伝送帯域を利用でき、サービスレベルも低下しない。
【００４３】
【発明の実施の形態】
以下、図面を参照して、本発明に係る中継装置、中継用プログラム及び自律型誤り訂正ネットワークの実施の形態を説明する。
【００４４】
本発明は、ネットワークを介したデータの伝送における伝送帯域、遅延時間及びＱｏＳを考慮した最適な伝送を実現するために、伝送途中で冗長度レベルが低下してきた場合には、送信部、ネットワーク、受信部の接続点に設けられている中継装置において下流側のネットワークのＱｏＳ情報に基づいて冗長度を改善する。さらに、本発明は、許容遅延、許容パレットロスレート等のＱｏＳの要求の異なるアプリケーションやサービス契約等で設定されているサービスレベルに応じて最適な伝送を実現するために、アプリケーションやサービスレベルに基づいてＦＥＣの実施の要否の決定、ＦＥＣの種類の決定、冗長度レベルの決定及び／又はＦＥＣのパラメータの設定を行う。特に、本発明では、遅延を最小限に抑えるために、中継装置において受信したデータをそのまま下流側に転送するとともにそのデータを復号化し、冗長度が不足して完全に復号化できない場合には上流側の送信部又は中継装置からその不足分だけ符号化したデータを送信してもらう。
【００４５】
本実施の形態では、２つの実施の形態があり、第１の実施の形態では中継装置において冗長度を改善するための復号化及びＦＥＣによる再符号化を送信データの中継とシリアルに行い、第２の実施の形態では中継装置において冗長度を改善するための復号化及びＦＥＣによる再符号化を送信データの中継とパラレルに行う。本実施の形態では、ＦＥＣとしてＬＴ符号を用いる。
【００４６】
まず、第１の実施の形態について説明する。図１を参照して、第１の実施の形態に係るネットワークの全体構成について説明する。図１は、第１の実施の形態に係るネットワーク全体の構成図である。
【００４７】
第１の実施の形態では、送信元１から受信先２にストリーミングコンテンツを、４つのネットワーク３，４，５，６を介して配信し、この４つのネットワーク３，４，５，６の接続点に設けられた中継装置７，８，９でデータを中継している。
【００４８】
送信元１は、ＡＳＰ等のコンテンツを配信するプロバイダであり、データをネットワークを介して配信するために配信サーバ（図示せず）を備えている。また、送信元１は、配信サーバ内あるいは別体でＦＥＣエンコーダ１ａを備えている。送信元１では、ストリーミングコンテンツの元データをＦＥＣエンコーダ１ａでＦＥＣデータに符号化し、ＦＥＣデータをパケット単位で配信する。ちなみに、送信元１では、受信先２（例えば、個人のユーザ）と契約を結んでおり、この契約おいて送信元１から配信するコンテンツのサービスレベル（サービス種別）やアプリケーションの種類及び配信料等を設定している。サービスレベルとしては、図４に示すような、誤り率優先度、遅延優先度、ＳＬＡ［Ｓｅｒｖｉｃｅ Ｌｅｖｅｌ Ａｇｒｅｅｍｅｎｔ］情報等がある。
【００４９】
ＦＥＣエンコーダ１ａでは、ＬＴ符号によるＦＥＣによって、ストリーミングコンテンツの元データを所定の冗長度レベルでＦＥＣデータに符号化する。このＦＥＣデータは、パケットのペイロードに分割されて格納され、送信される。所定の冗長度レベルは、パケットオーバヘッド（例えば、１０８６／１０２４）、ＦＥＣのオーバヘッド（例えば、１．０５）及び送信元１に接続されるネットワーク（Ｓ）３の最大パケットレート（１％）に基づいて設定され、例えば、１５％程度に設定される。冗長度レベルを１５％で０．３Ｍｂｐｓのストリーミングコンテンツを送信する場合、０．３４５Ｍｂｐｓの伝送帯域が必要であるが、ネットワーク（Ｓ）３の実効帯域０．５Ｍｂｐｓで十分に送信可能である。ちなみに、送信元１では、従来のようにネットワーク１０３，１０４，１０５の最大パケットレートを加味する必要はない。なお、ストリーミングコンテンツは、多数のブロックから構成され、各ブロックは多数のパケットから構成されている。
【００５０】
図２を参照して、パケットの構成について説明しておく。図２は、パケットの説明図であり、（ａ）はパケットの構成図であり、（ｂ）はＩＰヘッダのデータ構成図である。
【００５１】
パケットは、固定長のネット用ヘッダ、ＩＰヘッダ、ＵＤＰヘッダ、及び、可変長のペイロードから構成されている。このペイロードに、ＦＥＣデータが分割されて格納されている。また、ＩＰヘッダは、図２（ｂ）に示すようなデータ構成を有しており、ＩＰヘッダの先頭から２バイト目にサービス種別が格納されている。そのため、各パケットのＩＰヘッドの２バイト目の８ビットデータを参照することにより、このストリーミングコンテンツのサービス種別を判別することができる。また、ネット用ヘッダ又はＵＤＰヘッドには、アプリケーション（ストリーミングコンテンツ等）の種別を示すデータが格納されており、ネット用ヘッダ又はＵＤＰヘッドのデータを参照することにより、アプリケーションの種別を判別することができる。
【００５２】
図３を参照して、ＦＥＣエンコーダ１ａ等で行うＬＴ符号によるＦＥＣについて説明しておく。なお、このＬＴ符号によるＦＥＣは、中継装置７，８，９でも実施される。
【００５３】
図３では、ストリーミングコンテンツの元データに相当する入力データがａ〜ｈの１０個ある例を示している。ＬＴ符号によるＦＥＣでは、各入力データに対して乱数を発生させる。そして、出力データとして各列に対して排他的論理和により方程式（例えば、一列目の場合にはａＸＯＲｇ）をたて、この方程式がＦＥＣデータとなる。基本的には、入力データの個数分の方程式（出力データ）が有れば、方程式を解くことができる。しかし、データのネットワーク伝送中におけるパケットロスを考慮して、入力データの個数分より方程式（出力データ）の数を増やす（つまり、冗長度レベルを大きくする）。例えば、冗長度レベルを１０％とすると、１０個の入力データに対して１１個の出力データ（方程式）を生成しておく。つまり、送信元から１１個の出力データ（ＦＥＣデータ）を送信し、ネットワークで１個出力データ（ＦＥＣデータ）をロスしたとしても、受信先では１０個の出力データ（ＦＥＣデータ）によって方程式を解くことができる。
【００５４】
図１に戻って、受信先２は、個人のユーザ等であり、ネットワークを介してデータを受信するためにパソコン（図示せず）等を備えている。また、受信先２は、パソコン内あるいは別体でＦＥＣデコーダ２ａ及びストリーミングビュワ２ｂを備えている。受信先２では、パケット単位でＦＥＣデータを受信し、ＦＥＣデコーダ２ａで復号化する。そして、受信先２では、ストリーミングビュワ２ｂでパケット単位の復号化データを繋げ、ストリーミングコンテンツとして再生する。
【００５５】
ネットワーク３，４，５，６は、インターネット、イントラネット等のネットワークであり、ＱｏＳ情報を各々有している。Ｑｏｓ情報としては、図４に示すように、パケットロスレート、実効帯域、エラーレート、遅延、最大バースト長、ジッタ等があり、ネットワーク３，４，５，６によって異なる特性を有している。例えば、最大パケットロスレートの場合、ネットワーク（Ｓ）３では１％、ネットワーク（Ｎ−１）４では１５％、ネットワーク（Ｎ）５では２５％、ネットワーク（Ｄ）６では１％である。また、実効帯域の場合、ネットワーク（Ｓ）３では０．５Ｍｂｐｓ、ネットワーク（Ｎ−１）４では１０００Ｍｂｐｓ、ネットワーク（Ｎ）５では１００Ｍｂｐｓ、ネットワーク（Ｄ）６では８Ｍｂｐｓである。
【００５６】
中継装置７，８，９は、ネットワーク間のデータを中継する装置であり、例えば、ＩＳＰ等に設けられているルータ、ゲートウエイ等である。特に、中継装置７，８，９では、受信したＦＥＣデータの冗長度レベルが低下している場合、冗長度レベルを上げるために受信したＦＥＣデータを復号化するとともにその復号化データを再符号化して下流側に送信する。そのために、中継装置７，８，９は、パケットスイッチ７ａ，８ａ，９ａ、ＦＥＣデコーダ７ｂ，８ｂ，９ｂ、バッファメモリ７ｃ，８ｃ，９ｃ及びＦＥＣエンコーダ７ｄ，８ｄ，９ｄを備えている。ちなみに、これらの中継装置７，８，９の構成手段は、ハードウエアで構成してもよいし、専用プログラムをコンピュータで実行することによってソフトウエアで構成してもよい。ＦＥＣ中継装置７，８，９は、同様の構成を有するので、ここでは、中継装置（ｎ）８についてのみ詳細に説明する。
【００５７】
中継装置（ｎ）８では、ネットワーク（Ｎ−１）４からパケット単位でＦＥＣデータを受信し、ネットワーク（Ｎ）５のプロトコル等を考慮してネットワーク（Ｎ）５を介して中継装置（ｎ＋１）９にパケット単位でＦＥＣデータを送信する。また、中継装置（ｎ）８では、受信したＦＥＣデータの冗長度レベルを監視し、冗長度レベルが低下しているために中継装置（ｎ＋１）９で冗長度が不足する可能性がある場合には受信したＦＥＣデータを復号化及び冗長度レベルを上げるために再符号化する。
【００５８】
パケットスイッチ８ａでは、受信したＦＥＣデータの冗長度レベルを調べる。そして、パケットスイッチ８ａでは、受信したＦＥＣデータの冗長度レベルと下流側のネットワーク（Ｎ）５のＱｏｓ情報（パケットロスレート等）とに基づいて、そのまま受信したＦＥＣデータをネットワーク（Ｎ）５で伝送すると、中継装置（ｎ＋１）９で冗長度が不足するか否かを判定する。冗長度が不足しないと判定した場合、パケットスイッチ８ａでは、ＦＥＣを行わないと決定し、受信したＦＥＣデータをそのままネットワーク（Ｎ）５を介して中継装置（ｎ＋１）９にパケット単位で送信する。一方、冗長度が不足すると判定した場合、パケットスイッチ８ａでは、ＦＥＣを行うと決定し、受信したＦＥＣデータをＦＥＣデコーダ８ｂに送る。なお、パケットスイッチ８ａは、ネットワーク（Ｎ）５のみならず、更に下流側のネットワーク（Ｎ＋Ｉ）のＱｏｓ情報を考慮して、受信先２で冗長度が不足するか否かを判定してもよい。
【００５９】
ＦＥＣデコーダ８ｂでは、パケット単位のＦＥＣデータを復号化し、ストリーミングコンテンツの元データに復号化する。そして、ＦＥＣデコーダ８ｂでは、この元データをバッファメモリ８ｃに一時記憶させる。
【００６０】
ＦＥＣエンコーダ８ｄでは、ＦＥＣパラメータを設定する。そして、ＦＥＣエンコーダ８ｄでは、設定したＦＥＣパラメータに基づいて、ＬＴ符号によるＦＥＣによって、バッファメモリ８ｃに一時記憶されている元データをＦＥＣデータに再符号化する。そして、ＦＥＣエンコーダ８ｄでは、再符号化したＦＥＣデータをパケット単位でパケットスイッチ８ａに送り、パケットスイッチ８ａから下流のネットワーク（Ｎ）５を介して中継装置（ｎ＋１）９にそのパケット単位のＦＥＣデータを送信する。なお、この符号化では、ブロックの全てのパケットが復号化されてからブロック単位で復号化してもよいし、ブロックに対する復号化の途中でパケット単位で順次再符号化してもよい。
【００６１】
図４を参照して、ＦＥＣパラメータの設定方法について説明する。図４は、ＦＥＣのパラメータの説明図である。
【００６２】
ＦＥＣパラメータは、ＦＥＣによる符号化を行う際に必要なパラメータであり、想定最大パケットロス（冗長度レベル）、目標パケット再生誤り率、ＦＥＣオーバヘッド、ブロック長、パケット長等がある。これらのＦＥＣパラメータは、受信したＦＥＣデータの冗長度レベルと、受信したＦＥＣデータのパケットヘッダ情報、下流側のネットワークのＱｏＳ情報、ネットワーク全体の装置（送信元、受信先、中継装置）のリソース情報及び下流の中継装置（ｎ＋ｉ）の受信情報等とに基づいて設定する。
【００６３】
パケットヘッダ情報としては、サービスレベル情報として誤り率優先度、遅延優先度、ＳＬＡ情報等があり、アプリケーションタイプとしてストリーミングコンテンツ、電話、対話型ゲーム等がある。サービスレベル情報を考慮することによって、設定されているサービスレベルより低下しないように、ＦＥＣパラメータを設定する。アプリケーションタイプを考慮することにより、遅延に敏感なアプリケーションやパケットロスに敏感なアプリケーション等の各アプリケーションが要求するＱｏＳを満たすように、ＦＥＣパラメータを設定する。ちなみに、サービスレベル情報やアプリケーションタイプは、パケットの固定長の領域に設定されているので、高速に認識することができる。
【００６４】
下流側のネットワークのＱｏＳ情報としては、パケットロスレート、実効帯域、エラーレート、遅延、最大バースト長、ジッタ等がある。例えば、受信したＦＥＣデータの冗長度レベルが低下していると、下流側のネットワークのパケットロスレートによって下流の中継装置や受信先において冗長度レベルが０％未満になってしまう（冗長度が不足してしまう）と予測できる場合には、冗長度レベルを上げるように、ＦＥＣパラメータを設定する。その際、送信データの伝送帯域が下流側のネットワークの実効帯域を越えない範囲で、ＦＥＣパラメータを設定する。
【００６５】
装置のリソース情報としては、ＣＰＵ［Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ ｕｎｉｔ］の利用率、空きメモリ等がある。ネットワーク全体を見渡して、ＣＰＵの演算能力に余裕のある装置やメモリに余裕のある装置において復号化及び再符号化を行うように、ＦＥＣパラメータを設定する。
【００６６】
下流の中継装置の受信情報としては、受信パケットレートあるいはパケット充足情報、遅延、バッファメモリ等がある。下流側でパケットロスが発生しないかとかあるいは遅延時間が長くなっていないか等の下流の中継装置の受信情報も考慮して、ＦＥＣパラメータを設定する。
【００６７】
図１乃至図４を参照して、中継装置（ｎ）８の動作について説明する。前提として、送信元１において０．３ＭｂｐｓのストリーミングコンテンツがＦＥＣデータに符号化され、パケット単位のＦＥＣデータがネットワーク（Ｓ）３で伝送される。そして、パケット単位のＦＥＣデータは、ネットワーク（Ｓ）３を介して中継装置（ｎ−１）７で受信される。中継装置（ｎ−１）７では、パケット単位のＦＥＣデータの冗長度レベル及びネットワーク（Ｎ−１）４のＱｏＳ情報等に基づいてＦＥＣを実施するか否かを判定し、ＦＥＣを実施しない場合には受信したパケット単位のＦＥＣデータをそのままネットワーク（Ｎ−１）４を介して中継装置（ｎ）８に送信し、ＦＥＣを実施する場合には受信したパケット単位のＦＥＣデータを復号化及び再符号化して冗長度を改善したＦＥＣデータをネットワーク（Ｎ−１）４を介して中継装置（ｎ）８に送信する。そして、そのパケット単位のＦＥＣデータは、中継装置（ｎ）８で受信される。
【００６８】
中継装置（ｎ）８では、受信したパケット単位のＦＥＣデータの冗長度レベルを調べ、その冗長度レベルとネットワーク（Ｎ）５のＱｏＳ情報とに基づいて、ＦＥＣを実施するか否かを判定する。例えば、パケット単位のＦＥＣデータの冗長度レベルが５％まで低下している場合、ネットワーク（Ｎ）５の最大パケットロスレートが２５％であるため、ネットワーク（Ｎ）５でパケットロスが発生して、中継装置（ｎ−１）９では冗長度レベルが０％未満に低下してしまう。このような場合、中継装置（ｎ）８では、ＦＥＣを実施して、冗長度の改善を図る。
【００６９】
ＦＥＣを実施しないと判定した場合、中継装置（ｎ）８では、受信したパケット単位のＦＥＣデータを、そのままネットワーク（Ｎ）５を介して中継装置（ｎ＋１）９に送信する。
【００７０】
一方、ＦＥＣを実施すると判定した場合、中継装置（ｎ）８では、受信したパケット単位のＦＥＣデータを復号化する。さらに、中継装置（ｎ）８では、ネットワーク（Ｎ）５のＱｏＳ情報やアプリケーション及びサービスレベル等に基づいて、ＦＥＣパラメータを設定する（図４参照）。例えば、ネットワーク（Ｎ）５の最大パケットロスレートが２５％であるため、冗長度レベルとして３０％程度を設定する。そして、中継装置（ｎ）８では、設定したＦＥＣパラメータに基づいて、復号化したデータをＬＴ符号によるＦＥＣによってＦＥＣデータに再符号化する。続いて、中継装置（ｎ）８では、再符号化したパケット単位のＦＥＣデータをネットワーク（Ｎ）５を介して中継装置（ｎ＋１）９に送信する。
【００７１】
その後、パケット単位のＦＥＣデータは、ネットワーク（Ｎ）５を介して中継装置（ｎ＋１）９で受信される。中継装置（ｎ＋１）９では、パケット単位のＦＥＣデータの冗長度レベル及びネットワーク（Ｄ）６のＱｏＳ情報等に基づいてＦＥＣを実施するか否かを判定し、ＦＥＣを実施しない場合には受信したパケット単位のＦＥＣデータをそのままネットワーク（Ｄ）６を介して受信先２に送信し、ＦＥＣを実施する場合には受信したパケット単位のＦＥＣデータを復号化及び再符号化して冗長度を改善したＦＥＣデータをネットワーク（Ｄ）６を介して受信先２に送信する。そして、そのパケット単位のＦＥＣデータは、受信先２で受信される。受信先２では、受信したパケット単位のＦＥＣデータを順次復号化し、ストリーミングコンテンツとして再生する。この復号化では、中継装置７，８，９において冗長度が改善されているので、ストリーミングコンテンツにロスパケットの発生やマクロブロックエラー等のエラーが発生しない。
【００７２】
中継装置７，８，９によれば、ネットワーク全体における途中で冗長度を改善することができるので、送信元１でネットワーク全体のＱｏＳ情報を考慮して大きな冗長度レベルを設定する必要がなく、送信データの伝送帯域を抑えることができる。また、中継装置７，８，９によれば、下流側のネットワークのＱｏＳ情報が考慮されて冗長度を改善しているので、受信先２においてＦＥＣデータを完全に元データに復号化できる。
【００７３】
さらに、中継装置７，８，９によれば、アプリケーションやサービスレベルに応じてＦＥＣパラメータを設定しているので、各アプリケーションが要求するＱｏＳを満足させてアプリケーションを伝送することができ、サービスレベルも維持することができる。
【００７４】
次に、第２の実施の形態について説明する。図５を参照して、第２の実施の形態に係るネットワークの全体構成について説明する。図５は、第２の実施の形態に係るネットワーク全体の構成図である。第２の実施の形態では、第１の実施の形態に係る構成と同様の構成について同一の符号を付し、その説明を省略する。
【００７５】
第２の実施の形態では、送信元１から受信先２にストリーミングコンテンツを、４つのネットワーク３，４，５，６を介して配信し、この４つのネットワーク３，４，５，６の接続点に設けられた中継装置１７，１８，１９でデータを中継している。
【００７６】
中継装置１７，１８，１９は、ネットワーク間のデータを中継する装置であり、例えば、ＩＳＰ等に設けられているルータ、ゲートウエイ等である。特に、中継装置１７，１８，１９では、受信したパケット単位のＦＥＣデータをそのまま下流の中継装置１８，１９又は受信先２に転送するとともに、同時に、受信したパケット単位のＦＥＣデータを復号化する。そして、中継装置１７，１８，１９（又は受信先２）では、ＦＥＣデータを完全に復号化できない場合、不足している冗長度分を補うために、上流の中継装置１７，１８，１９又は送信元１から符号化されたパケット単位のＦＥＣデータを送信してもらう。そして、中継装置１７，１８，１９（又は受信先２）では、その送信してもらったパケット単位のＦＥＣデータによって完全に復号化できた場合、上流の中継装置１７，１８，１９又は送信元１からの送信を停止させる。また、中継装置１７，１８，１９（又は送信元１）では、下流の中継装置１７，１８，１９又は受信先２に符号化したパケット単位のＦＥＣデータを送信するために、復号化したデータを再符号化する。そのために、中継装置１７，１８，１９は、パケットコピー１７ａ，１８ａ，１９ａ、ＦＥＣデコーダ１７ｂ，１８ｂ，１９ｂ、バッファメモリ１７ｃ，１８ｃ，１９ｃ及びＦＥＣエンコーダ１７ｄ，１８ｄ，１９ｄを備えている。ちなみに、これらの中継装置１７，１８，１９の構成手段は、ハードウエアで構成してもよいし、専用プログラムをコンピュータで実行することによってソフトウエアで構成してもよい。ＦＥＣ中継装置１７，１８，１９は、同様の構成を有するので、ここでは、中継装置（ｎ）１８についてのみ詳細に説明する。
【００７７】
中継装置（ｎ）１８では、ネットワーク（Ｎ−１）４からパケット単位でＦＥＣデータを受信し、ネットワーク（Ｎ）５のプロトコル等を考慮して、そのパケット単位でＦＥＣデータをそのままネットワーク（Ｎ）５を介して中継装置（ｎ）１９に転送する。同時に、中継装置（ｎ）１８では、受信したＦＥＣデータを復号化する。そして、中継装置（ｎ）１８では、受信したＦＥＣデータを完全に復号化できない場合、上流の中継装置（ｎ−１）１７から送信された再符号化されたＦＥＣデータを受信し、その再符号化されたＦＥＣデータに基づいてＦＥＣデータを完全に復号化する。ＦＥＣデータを完全に復号化できると、中継装置（ｎ）１８では、中継装置（ｎ−１）１７からの送信を中止させる。また、中継装置（ｎ）１８では、下流の中継装置（ｎ＋１）１９においてＦＥＣデータを完全に復号化できない場合に対応するために、復号化したデータを再符号化し、再符号化したパケット単位のＦＥＣデータを下流の中継装置（ｎ＋１）１９に送信する。そして、中継装置（ｎ）１８では、下流の中継装置（ｎ＋１）１９からの送信中止要求に応じて、ＦＥＣデータの送信を中止するとともに復号化及び再符号化も中止する。
【００７８】
パケットコピー１８ａでは、ネットワーク（Ｎ−１）４からパケット単位のＦＥＣデータを受信すると、そのパケット単位のＦＥＣデータをそのままネットワーク（Ｎ）を介して中継装置（ｎ＋１）１９に送信するとともに、ＦＥＣデコーダ１８ｂに送る。
【００７９】
ＦＥＣデコーダ１８ｂでは、パケット単位のＦＥＣデータを復号化し、ストリーミングコンテンツの元データに復号化する。そして、ＦＥＣデコーダ１８ｂでは、この元データをバッファメモリ１８ｃに一時記憶させる。また、ＦＥＣデコーダ１８ｂでは、ＦＥＣデータを元データに１００％復号化できたか否かを判定する。元データに１００％復号化できない場合、ＦＥＣデコーダ１８ｂでは、上流の中継装置（ｎ−１）１７に対して、中継装置（ｎ−１）１７で再符号化したＦＥＣデータを送信してもらう送信要求を送信する。そして、ＦＥＣデコーダ１８ｂでは、元データに１００％復号化できるまで、中継装置（ｎ−１）１７からの再符号化したＦＥＣデータを復号化する。この際、中継装置（ｎ−１）１７からは、同じ再符号化したＦＥＣデータが繰り返し送信されてくる。一方、元データに１００％復号化できた場合、ＦＥＣデコーダ１８ｂでは、上流の中継装置（ｎ−１）１７に対して、中継装置（ｎ−１）１７で再符号化したＦＥＣデータの送信を中止する送信中止要求を送信するとともに、復号化を終了する。
【００８０】
ＦＥＣエンコーダ１８ｄでは、下流の中継装置（ｎ＋１）１９からの送信要求を受信すると、設定したＦＥＣパラメータに基づいて、ＬＴ符号によるＦＥＣによって、バッファメモリ１８ｃに一時記憶されている元データをＦＥＣデータに再符号化する。この際、ＦＥＣエンコーダ１８ｄでは、ＦＥＣパラメータを設定するが、ＦＥＣパラメータの設定方法については第１の実施の形態と同様である。そして、ＦＥＣエンコーダ１８ｄでは、再符号化したＦＥＣデータをパケット単位でパケットコピー１８ａに送り、パケットコピー１８ａから下流のネットワーク（Ｎ）５を介して中継装置（ｎ＋１）１９にその再符号化したパケット単位のＦＥＣデータを送信する。この際、ＦＥＣエンコーダ１８ｄでは、中継装置（ｎ＋１）１９から送信中止要求が送信されるまで、同じパケット単位のＦＥＣデータを繰り返し送信し続ける。また、ＦＥＣエンコーダ１８ｄでは、下流の中継装置（ｎ＋１）１９からの送信中止要求を受信すると、バッファメモリ１８ｃに一時記憶させていた復号化データを消去するとともに、再符号化を終了する。なお、ＦＥＣエンコーダ１８ｄでは、冗長度レベルを変えずに符号化する場合もある。
【００８１】
なお、第２の実施の形態では、送信元１及び受信先２では、第１の実施の形態の処理に加えて以下の処理も行う。送信元１では、中継装置（ｎ−１）１７の送信要求に応じてパケット単位のＦＥＣデータを繰り返し送信し、送信中止要求に応じて送信を中止する。受信先２では、ＦＥＣデータを元データに完全に復号化できな場合には中継装置（ｎ＋１）１９に対して送信要求を送信して再符号化したパケット単位のＦＥＣデータを送信してもらい、その再符号化したＦＥＣデータによって元データに完全に復号化できた場合には中継装置（ｎ＋１）１９に対して送信中止要求を送信する。
【００８２】
図５を参照して、中継装置（ｎ）１８の動作について説明する。前提として、送信元１において０．３ＭｂｐｓのストリーミングコンテンツがＦＥＣデータに符号化され、パケット単位のＦＥＣデータがネットワーク（Ｓ）３で伝送される。そして、パケット単位のＦＥＣデータは、ネットワーク（Ｓ）３を介して中継装置（ｎ−１）１７で受信される。中継装置（ｎ−１）１７では、パケット単位のＦＥＣデータをそのままネットワーク（Ｎ−１）４を介して中継装置（ｎ）１８に送信する。さらに、中継装置（ｎ−１）１７では、パケット単位のＦＥＣデータを復号化するとともに、中継装置（ｎ）１８からの送信要求に応じて復号化データを再符号化し、この再符号化したＦＥＣデータをネットワーク（Ｎ−１）４を介して中継装置（ｎ）１８に送信する。そして、そのパケット単位のＦＥＣデータ及び再符号化されたＦＥＣデータは、中継装置（ｎ）１８で受信される。
【００８３】
中継装置（ｎ）１８では、パケット単位のＦＥＣデータを受信すると、パケット単位のＦＥＣデータをそのままネットワーク（Ｎ）５を介して中継装置１９に送信するとともに、パケット単位のＦＥＣデータを復号化する。
【００８４】
そして、中継装置（ｎ）１８では、ＦＥＣデータを元データに完全に復号化できたか否かを判定する。完全に復号化できないと判定した場合、中継装置（ｎ）１８では、中継装置（ｎ−１）１７に対して再符号化したＦＥＣデータを送信してもらう送信要求を送信し、元データに完全に復号化できるまで中継装置（ｎ−１）１７からの再符号化したＦＥＣデータを用いて復号化する。一方、完全に復号化できたと判定した場合、中継装置（ｎ）１８では、中継装置（ｎ−１）１７に対して再符号化したＦＥＣデータの送信を中止する送信中止要求を送信し、復号化を終了する。
【００８５】
さらに、中継装置（ｎ）１８では、中継装置（ｎ＋１）１９からの送信要求を受信すると、ＬＴ符号によるＦＥＣによって復号化したデータをＦＥＣデータに再符号化する。そして、中継装置（ｎ）１８では、再符号化したＦＥＣデータをパケット単位でネットワーク（Ｎ）５を介して中継装置（ｎ＋１）１９を送信する。また、中継装置（ｎ）１８では、中継装置（ｎ＋１）１９からの送信中止要求を受信すると、バッファメモリ１８ｃに一時記憶させていた復号化データを消去するとともに、再符号化を終了する。
【００８６】
その後、パケット単位のＦＥＣデータ及び中継装置（ｎ＋１）１９からの要求に応じた再符号化したＦＥＣデータは、ネットワーク（Ｎ）５を介して中継装置（ｎ＋１）１９で受信される。中継装置（ｎ＋１）１９では、パケット単位のＦＥＣデータをそのままネットワーク（Ｄ）６を介して受信先２に送信する。さらに、中継装置（ｎ＋１）１９では、パケット単位のＦＥＣデータを復号化するとともに、受信先２からの送信要求に応じて復号化データを再符号化し、この再符号化したＦＥＣデータをネットワーク（Ｄ）６を介して受信先２に送信する。そして、そのパケット単位のＦＥＣデータ及び再符号化されたＦＥＣデータは、受信先２で受信される。受信先２では、受信したパケット単位のＦＥＣデータを順次復号化するが、このＦＥＣデータで完全に復号化できない場合には再符号化されたＦＥＣデータを用いて復号化する。そして、受信先２では、復号化したデータによりストリーミングコンテンツとして再生する。この復号化では、中継装置１７，１８，１９においてＦＥＣデータを完全に復号化して冗長度を改善しているので、ストリーミングコンテンツにロスパケットの発生やマクロブロックエラー等のエラーが発生しない。
【００８７】
中継装置１７，１８，１９によれば、ＦＥＣデータをそのまま下流に転送するとともにそのＦＥＣデータを復号化しているので、遅延を極力抑えることができる。また、中継装置１７，１８，１９では、ＦＥＣデータを元データに１００％復号化できるまで上流から再符号化したＦＥＣデータを補充するので、元データに１００％復号化することができ、ひいては受信先２で元データに１００％復号化することができる。そのため、送信元１でネットワーク全体のＱｏＳ情報を考慮して冗長度レベルを設定する必要がなく、送信データの伝送帯域を抑えることができる。
【００８８】
以上、本発明に係る実施の形態について説明したが、本発明は上記実施の形態に限定されることなく様々な形態で実施される。
【００８９】
例えば、本実施の形態ではＩＳＰ等から個人等にストリーミングコンテンツを配信する場合に適用したが、個人と個人との場合、アプリケーションとしても電話や対戦型ゲーム等の場合における様々なネットワークを介して通信に適用可能である。
【００９０】
また、本実施の形態ではネットワーク上の全ての中継装置において本発明に係る処理を行う構成としたが、ネットワーク上の一部の中継装置において本発明に係る処理を行う構成としてもよいし、ネットワーク上の全ての中継装置において処理を行う場合でも処理能力に余裕のある中継装置が優先的に処理を行うように構成してもよい。
【００９１】
また、本実施の形態ではＦＥＣとしてＬＴ符号を用いたが、ハミング符号、ＢＣＨ符号、リードソロモン符号、トルネード符号等の他のＦＥＣを用いてもよい。
【００９２】
また、本実施の形態では送信元から受信先まで１本の経路の場合で説明したが、中継装置又は受信元において複数の経路（ネットワーク）に分岐する場合でも適用可能であり、この場合には分岐する各経路（ネットワーク）のＱｏＳ情報等に基づいて最適な経路も決定する。
【００９３】
また、本実施の形態ではサービスレベル（サービス種別）をＩＰヘッダに設定したが、ＵＤＰヘッダ等の他の固定長のデータ領域に設定してよいし、ヘッダのデータ構成も他の構成としてもよい。
【００９４】
また、本実施の形態ではネットワークのＱｏＳ情報を直接用いたが、ＱｏＳ情報のうちの任意の情報に対して四則演算する等の二次情報を用いてよい。
【００９５】
【発明の効果】
本発明は、データを送信するネットワークの途中で冗長度が低下しても、ネットワーク間の中継時に、下流側のネットワークのサービス品質情報に基づいて冗長度を改善することができる。そのため、データを小さな冗長度で送信できるのでネットワークの伝送帯域の使用効率が向上するとともに伝送時間を短縮でき、さらに、パケットロスを全く無くすあるいは極力無くすことができるのでＥｎｄ−ｔｏ−ＥｎｄにおけるＱｏｓやサービスレベルも向上する。
【００９６】
さらに、本発明は、アプリケーション及び／又はサービスレベルに応じてＦＥＣの実施の要否の決定やＦＥＣの種類の決定等を行うので、様々なアプリケーションに要求されるＱｏＳに応じてＦＥＣによって冗長度を改善することができ、サービスレベルも満たすことができる。
【００９７】
また、本発明は、任意のブロックの復号化の途中で、途中まで復号化したパレット単位のデータから順次再符号化することによって、効率的に、送信データを元データに戻すとともにその元データから冗長度を改善したデータを再符号化することができる。
【００９８】
さらに、本発明では、パケットロス等が発生して転送されたデータによって元のデータに１００％復号化できない場合でも、上流側に位置する送信部又は中継装置からＦＥＣが施されたパケットを受信することによって、元のデータに１００％復号化することができる。この際、データの転送とデータの複合化及び再符号化をパラレルで行っているので、遅延を極力抑えることができる。
【図面の簡単な説明】
【図１】本発明の第１の実施の形態に係るネットワーク全体の構成図である。
【図２】本発明の実施の形態に係るパケットの説明図であり、（ａ）はパケットの構成図であり、（ｂ）はＩＰヘッダのデータ構成図である。
【図３】ＦＥＣのＬＴ符号の概念図である。
【図４】本発明の実施の形態に係るＦＥＣのパラメータの説明図である。
【図５】本発明の第２の実施の形態に係るネットワーク全体の構成図である。
【図６】従来のネットワーク全体の構成図である。
【符号の説明】
１…送信元、１ａ…ＦＥＣエンコーダ、２…受信先、２ａ…ＦＥＣデコーダ、２ｂ…ストリーミングビュワ、３，４，５，６…ネットワーク、７，８，９，１７，１８，１９…中継装置、７ａ，８ａ，９ａ…パケットスイッチ、７ｂ，８ｂ，９ｂ，１７ｂ，１８ｂ，１９ｂ…ＦＥＣデコーダ、７ｃ，８ｃ，９ｃ，１７ｃ，１８ｃ，１９ｃ…バッファメモリ、７ｄ，８ｄ，９ｄ，１７ｄ，１８ｄ，１９ｄ…ＦＥＣエンコーダ、１７ａ，１８ａ，１９ａ…パケットコピー[0001]
TECHNICAL FIELD OF THE INVENTION
The present invention relates to a relay device, a relay program, and an autonomous error correction network provided at one or more connection points between networks.
[0002]
[Prior art]
In recent years, the number of broadband subscribers on the Internet and intranet has been rapidly increasing. Broadband applications that require fixed bandwidth and quality, such as music and video download distribution and streaming distribution, and those that require realization of large-capacity, high-speed content distribution services such as real-time communication, are increasing. It is getting. These applications are expected to drive the market for higher speed broadband services such as FTTH [Fiber To The Home]. With this high-speed broadband service, the speed of downloading within one minute for downloading and the realization of a service level that does not stop during streaming or generate macroblock errors etc. are required to secure excellent contents and digital writing Together with the standardization of rights management technology, it is even said to be the key to the development of Japan's broadband market.
[0003]
As a technology for processing such a large amount of information in a high-speed and real-time manner and responding to a quality requirement according to each application, in a core network, a hardware level in a layer 2 using MPLS [Multi Protocol Label Switching] is used. High-speed switching technology and the like have been developed, and a technology for dividing and caching content in an edge network has been put to practical use.
[0004]
However, at present, technologies for securing high speed and service level by end-to-end in the Internet, which is a collection of network technologies of various eras, have not yet been established. In TCP / IP (Transmission Control Protocol / Internet Protocol), which forms the basis of the Internet, highly reliable communication is realized by flow control and loss packet retransmission request. However, retransmission of lost packets is not an essential solution in securing the service level of broadband media because congestion due to access concentration causes further congestion due to retransmission.
[0005]
Also, in FTP (File Transfer Protocol), which is widely used as a protocol used for downloading, in order to prevent network congestion due to retransmission, the receiving capability of each receiver is defined by the product of a transmission band and a delay time. By keeping this constant, flow control is performed. For this reason, when packet retransmission occurs and the delay time increases, the transmission bandwidth decreases, and high-speed downloading corresponding to broadband cannot be performed.
[0006]
Further, in various media formats popularized in streaming, various measures have been taken to maintain image quality even on a network where QoS (Quality of Service) is poor, but a packet loss of about 0.1 to 1% has been adopted. This may cause a macroblock error or frame skip in the reproduced video. In these streaming distributions, in order to secure a throughput, a UDP (User Datagram Protocol) that does not perform flow control and retransmission of lost packets is often used. Since UDP does not have a scheme to reduce the load on the network due to network congestion, some applications use a dedicated protocol to reduce the resolution by autonomous learning and lower the service level of each flow. It is realized in. However, the following sensitivity to network congestion is not sufficient, and in particular, there is a problem that the service level is very slowly restored after the congestion is resolved, and the quality of the entire program is deteriorated by a short time of congestion.
[0007]
Therefore, despite the explosive spread of broadband by ADSL (Asymmetric Digital Subscriber Line) and the like, it is difficult to spread full-scale broadband CDS [Circuit Design Service] on the Internet. This has become one of the important rate-limiting factors for the increase in demand for FTTH in Japan.
[0008]
On the other hand, as a means for realizing QoS that does not depend on TCP / IP flow control or loss packet retransmission, there is a method using UDP and forward error correction (hereinafter, referred to as FEC [Forward Error Correction]).
[0009]
[Problem to be solved]
However, the conventional FEC has been mainly used to improve the S / N in
[0010]
Further, the FEC performs an encoder by assuming an end-to-end error rate and a packet loss rate in advance, but the end-to-end error rate and the packet rate in the Internet, which is essentially a collection of independent networks. It was difficult to estimate the loss rate in advance. Even if an end-to-end error rate or a packet loss rate can be assumed in advance, the transmission source transmits FEC data with a correspondingly increased redundancy level, so that the use efficiency of the network transmission band decreases and The transmission time also increases. In particular, when an individual transmits and receives data to and from an individual via a network using a public line, increasing the redundancy level in consideration of an error rate or a packet loss rate in the middle of the network increases the amount of data to be transmitted. Personal cost burden increases. That is, the individual must bear a cost for an error rate, a packet loss rate, and the like in the middle of the network.
[0011]
Referring to FIG. 6, when streaming content is transmitted from a
[0012]
Furthermore, in the existing FEC technology such as Reed-Solomon code widely used for FEC such as CD-ROM and DVD, the operation processing time is almost equal to the content rate and the burst length of packet loss to be corrected. Since it tends to be proportional to the square, it has not been easy to apply broadband data called rich content such as video and music to an application that is distributed on the Internet where burst packet loss occurs.
[0013]
The above technique is disclosed in Japanese Patent Application Laid-Open No. 2001-189665, US Pat. No. 6,307,487, but no means for solving the above problem is disclosed.
[0014]
Therefore, an object of the present invention is to provide a relay device, a relay program, and a network that are excellent in the use efficiency of a transmission band of a network, the delay in data transmission, and the QoS.
[0015]
[Means for Solving the Problems]
A relay device according to the present invention is a relay device provided at one or a plurality of connection points between networks used when transmitting data from a transmission unit to a reception unit, and is provided downstream of the relay device. Determining means for determining whether data redundancy needs to be improved and a redundancy level based on service quality information or secondary information of service quality information of one or more located networks, and improving data redundancy And means for improving redundancy.
[0016]
According to this relay device, it is possible to improve redundancy in the middle of a network for transmitting data based on service quality information of one or a plurality of networks located on the downstream side. Therefore, even when the transmission unit transmits data on which forward error correction has been performed with a small redundancy level and the redundancy level decreases in the middle of the network, the redundancy can be improved in the relay device in the middle of the network. No packet loss occurs in the section. Therefore, since data can be transmitted with a small degree of redundancy and packet loss can be eliminated, the use efficiency of the transmission band can be improved and the transmission time can be reduced, and the QoS and the service level in End-to-End are also improved. I do.
[0017]
Incidentally, assuming that the maximum packet loss rate of m partial networks (n) through which a certain flow passes is L (n)%, the packet loss rate of the entire network of this flow is 1-((1-L (1) ) × (1-L (2)) ×... × (1-L (m))). When FEC is performed in consideration of this, the redundancy level of the data transmitted from the transmission source becomes enormous, and the traffic in the partial network or the relay device near the transmission source becomes enormous. For this reason, conventionally, it has been impossible to distribute rich contents economically, and the service level has been lowered when a packet loss that is larger than expected occurs. However, according to the relay device of the present invention, the network is relayed to the next network while restoring the redundancy lost for each section of the network, so that the service level does not decrease while effectively using the transmission bandwidth in each network. .
[0018]
Note that the transmission unit is a transmission source that transmits data via a network, and includes, for example, an individual (including a transmission device such as a personal computer), an ISP [Internet Service Provider] (including a transmission device such as a server), and an ASP. [Application Service Provider] (including a transmission device such as a server). The receiving unit is a receiving destination that receives data via a network, and is, for example, an individual or a corporation (including a receiving device such as a personal computer). The network is, for example, the Internet, an intranet, or the like. The relay device is a device that is provided at a connection point between networks and relays data from the upstream side to the downstream side, and is, for example, a router or a gateway provided in an ISP or an ASP. Incidentally, the transmission unit may also perform processing in the relay device. The service quality information is information on QoS in the network, and includes, for example, a packet loss rate, an error rate, a delay, and a jitter. The secondary information of the service quality information is information obtained by performing four arithmetic operations on one piece of information or a plurality of pieces of information in the service quality information. The upstream side is the transmitting unit side when data is transmitted. The downstream side is the receiving side when data is transmitted.
[0019]
The relay apparatus according to the present invention determines whether or not to perform forward error correction, determines the type of forward error correction, determines a redundancy level, and / or determines according to an application and / or service level for each flow. The setting of the forward error correction parameter may be performed.
[0020]
According to this relay device, the necessity of implementing FEC is determined or the type of FEC is determined according to the application and / or service level. Therefore, the redundancy is determined by the FEC according to the QoS required for various applications. Can be improved. In other words, there are applications that are sensitive to delays such as VoIP and applications that are insensitive to delays such as VOD but are severe in packet loss. However, in the conventional technology, since FEC is implemented in a lower layer of OSI, application It could not respond to every QoS requirement. However, according to the relay device, it is possible to perform an appropriate FEC for each application having a different QoS requirement such as a use time, an allowable delay, an allowable pallet loss rate, and an allowable packet loss burst number.
[0021]
The flow means a flow of data flowing through a network including one or a plurality of blocks composed of all or a part of transmission data such as contents. The types of FEC include a Hamming code, a BCH [Bose Chaudhuri-Hocquenghem] code, a Reed-Solomon code, a tornado code, and an LT [Luby Transform] code.
[0022]
The relay apparatus of the present invention may improve the redundancy by continuously performing decoding and re-encoding for each block of the flow.
[0023]
According to this relay device, it is possible to return the original data in the transmitting unit by decoding the transmitted data and change the redundancy level by re-encoding the original data.
[0024]
The relay device of the present invention may improve redundancy by additionally transmitting a packet subjected to forward error correction from a transmission unit or a relay device located on the upstream side.
[0025]
According to this relay device, even when a packet loss occurs due to insufficient redundancy, the transmission unit or the relay device located on the upstream side additionally transmits the FEC-executed packet, so that the transmitted FEC is transmitted. Data can eliminate packet loss and completely decode.
[0026]
The relay device of the present invention may improve the redundancy by sequentially re-encoding the decoded packet unit data in the middle of the decoding of the block of the flow.
[0027]
According to this relay device, by sequentially re-encoding the decoded data in units of pallets decoded to the middle of an arbitrary block of data, the FEC data can be efficiently returned to the original data and the redundant data can be efficiently restored from the original data. FEC data with an improved degree can be generated.
[0028]
The relay device of the present invention may set an application and / or service level in a fixed-length data area of a packet.
[0029]
According to this relay device, by referring to the data stored in the predetermined area of the packet head, the application and / or service level can be determined at high speed by hardware. Incidentally, in the conventional packet structure, since the application and / or service level is set in the FEC header of the variable-length payload of the packet, the application and / or service level is determined by software processing. Cost me.
[0030]
The above-described relay device of the present invention transfers packet-based data of each block of a flow to a relay device or a receiving unit located on the downstream side and sequentially decodes the packet-based data, so that the data cannot be completely decoded. Receives data in packet units re-encoded by forward error correction from a transmitting unit or a relay device located on the upstream side, decodes the data, and if the data is completely decoded, the upstream side The transmission of the data from the transmission unit or the relay device located at may be stopped.
[0031]
According to this relay device, even when packet transfer or the like cannot be performed to 100% of the original data by the transferred data due to a packet loss or the like, the FEC-received packet is received from the transmission unit or the relay device located on the upstream side. As a result, 100% decoding can be performed on the original data. Further, in this relay device, when 100% decoding can be performed on the original data, a transmission interruption request or the like is transmitted to the transmission unit or the relay device located on the upstream side to stop the transmission. Of the transmission unit or the relay device.
[0032]
By the way, in the conventional FEC, it is necessary to combine data scrambling and FEC in order to improve resistance to bursty packet loss and errors. If the scrambling width is increased, resistance to bursty errors is improved, but delay is increased. It has grown. Therefore, if decoding and re-encoding are repeated in the relay device using the conventional FEC, delays accumulate every time the relay device is passed, and it cannot be used for VoIP such as telephones and interactive games. Also, in applications such as VOD and live broadcasting, the delay becomes too large, which causes a problem. However, according to the relay device of the present invention, it is possible to decode and re-encode by adding insufficient redundancy without decoding and re-encoding all data at the time of relay, so that delay is increased. Can be minimized.
[0033]
The relay program according to the present invention is a relay program executed by a relay device provided at one or a plurality of connection points between networks used when transmitting data from a transmission unit to a reception unit. The computer determines the necessity of data redundancy improvement and the redundancy level based on service quality information or secondary information of service quality information of one or more networks located downstream of the relay device. And a redundancy improving means for improving data redundancy.
[0034]
The relay program according to the present invention determines whether or not to perform forward error correction, determines the type of forward error correction, determines a redundancy level, and / or determines, according to an application and / or service level for each flow. Alternatively, parameters for forward error correction may be set.
[0035]
The above-described relay program of the present invention may improve redundancy by continuously performing decoding and re-encoding for each block of a flow.
[0036]
The relay program of the present invention may improve the redundancy by causing a transmission unit or a relay device located on the upstream side to additionally transmit a packet subjected to forward error correction.
[0037]
The above-mentioned relay program of the present invention may improve redundancy by sequentially re-encoding the decoded packet unit data in the course of decoding the flow block.
[0038]
The relay program of the present invention may set an application and / or service level in a fixed-length data area of a packet.
[0039]
The relay program of the present invention transfers the packet data of each block of the flow to the relay device or the receiving unit located on the downstream side, sequentially decodes the packet data, and cannot completely decode the data. In such a case, data in a packet unit re-encoded by forward error correction is received from a transmitting unit or a relay device located on the upstream side and decoded by this data, and when the data can be completely decoded, the upstream The transmission of data from the transmitting unit or the relay device located on the side may be stopped.
[0040]
According to this relaying program, the functions and effects of the above-described relaying device are exhibited by causing the computer to execute this program.
[0041]
An autonomous error correction network according to the present invention is an autonomous error correction network including a transmission unit, a reception unit, and one or a plurality of relay devices provided at one or a plurality of connection points between networks. In the relay device, the necessity of the improvement of the redundancy is determined based on the service quality information of one or a plurality of networks located on the downstream side, and when the improvement of the redundancy is necessary, the forward error correction is performed. To improve data redundancy.
[0042]
According to this autonomous error correction network, the redundancy can be improved at the time of data relay, so that the transmission bandwidth can be effectively used in each network and the service level does not decrease.
[0043]
BEST MODE FOR CARRYING OUT THE INVENTION
Hereinafter, embodiments of a relay device, a relay program, and an autonomous error correction network according to the present invention will be described with reference to the drawings.
[0044]
The present invention provides a transmission unit, a network, and a data transmission method in which a redundancy level decreases during transmission in order to realize optimal transmission in consideration of a transmission band, delay time, and QoS in data transmission through a network. The redundancy is improved based on the QoS information of the downstream network in the relay device provided at the connection point of the receiving unit. Further, the present invention is based on applications and service levels in order to realize optimum transmission in accordance with service levels set in applications and service contracts or the like having different QoS requirements such as allowable delay and allowable pallet loss rate. To determine whether or not to perform FEC, determine the type of FEC, determine the redundancy level, and / or set the FEC parameters. In particular, in the present invention, in order to minimize the delay, the data received by the relay device is forwarded to the downstream side as it is and the data is decoded. The transmission unit on the side or the relay device transmits the encoded data corresponding to the shortage.
[0045]
In the present embodiment, there are two embodiments, and in the first embodiment, decoding and re-encoding by FEC for improving redundancy in the relay device are performed serially with relay of transmission data, and In the second embodiment, decoding for improving redundancy in the relay device and re-encoding by FEC are performed in parallel with transmission data relaying. In the present embodiment, an LT code is used as the FEC.
[0046]
First, a first embodiment will be described. The overall configuration of the network according to the first embodiment will be described with reference to FIG. FIG. 1 is a configuration diagram of the entire network according to the first embodiment.
[0047]
In the first embodiment, a streaming content is distributed from a
[0048]
The
[0049]
The
[0050]
The configuration of the packet will be described with reference to FIG. 2A and 2B are explanatory diagrams of a packet, FIG. 2A is a diagram of a packet structure, and FIG. 2B is a data structure diagram of an IP header.
[0051]
The packet includes a fixed-length net header, an IP header, a UDP header, and a variable-length payload. FEC data is divided and stored in this payload. The IP header has a data configuration as shown in FIG. 2B, and the service type is stored in the second byte from the head of the IP header. Therefore, the service type of the streaming content can be determined by referring to the second byte 8-bit data of the IP head of each packet. Further, data indicating the type of the application (streaming content or the like) is stored in the net header or the UDP head, and it is possible to determine the type of the application by referring to the data of the net header or the UDP head. it can.
[0052]
With reference to FIG. 3, the FEC using the LT code performed by the
[0053]
FIG. 3 shows an example in which there are ten pieces of input data a to h corresponding to the original data of the streaming content. In the FEC using the LT code, a random number is generated for each input data. Then, an equation (for example, aXORg in the case of the first row) is set by exclusive OR for each column as output data, and this equation becomes FEC data. Basically, if there are equations (output data) for the number of input data, the equations can be solved. However, in consideration of packet loss during data transmission through the network, the number of equations (output data) is increased (that is, the redundancy level is increased) from the number of input data. For example, if the redundancy level is 10%, 11 output data (equations) are generated for 10 input data. That is, even if 11 output data (FEC data) are transmitted from the transmission source and one output data (FEC data) is lost on the network, the equation is solved by the 10 output data (FEC data) at the reception destination. be able to.
[0054]
Returning to FIG. 1, the receiving destination 2 is an individual user or the like, and includes a personal computer (not shown) or the like for receiving data via a network. The receiving destination 2 includes an
[0055]
The
[0056]
The relay devices 7, 8, and 9 are devices that relay data between networks, and are, for example, routers, gateways, and the like provided in ISPs and the like. In particular, when the redundancy level of the received FEC data is reduced, the relay devices 7, 8, and 9 decode the received FEC data to increase the redundancy level and re-encode the decoded data. To the downstream side. For this purpose, the relay devices 7, 8, 9 include
[0057]
The relay device (n) 8 receives the FEC data in packet units from the network (N-1) 4 and takes into consideration the protocol of the network (N) 5 and the like via the network (N) 5 in consideration of the relay device (n + 1). 9, the FEC data is transmitted in packet units. Also, the relay device (n) 8 monitors the redundancy level of the received FEC data, and if the redundancy level is reduced, the relay device (n + 1) 9 may have insufficient redundancy. Decodes and re-encodes the received FEC data to increase the redundancy level.
[0058]
The
[0059]
The FEC decoder 8b decodes the FEC data in packet units and decodes it into the original data of the streaming content. Then, the FEC decoder 8b temporarily stores the original data in the
[0060]
The
[0061]
With reference to FIG. 4, a method of setting FEC parameters will be described. FIG. 4 is an explanatory diagram of FEC parameters.
[0062]
The FEC parameter is a parameter required when performing encoding by FEC, and includes an assumed maximum packet loss (redundancy level), a target packet reproduction error rate, an FEC overhead, a block length, a packet length, and the like. These FEC parameters include the redundancy level of the received FEC data, the packet header information of the received FEC data, the QoS information of the downstream network, and the resource information of the devices (source, destination, and relay device) of the entire network. And the received information of the downstream relay device (n + i).
[0063]
The packet header information includes error rate priority, delay priority, SLA information, and the like as service level information, and streaming content, telephone, interactive game, and the like as application types. By considering the service level information, the FEC parameter is set so as not to be lower than the set service level. By considering the application type, the FEC parameter is set so as to satisfy the QoS required by each application such as a delay-sensitive application and a packet loss-sensitive application. Incidentally, since the service level information and the application type are set in the fixed length area of the packet, it can be recognized at high speed.
[0064]
The QoS information of the downstream network includes a packet loss rate, an effective bandwidth, an error rate, a delay, a maximum burst length, a jitter, and the like. For example, if the redundancy level of the received FEC data is low, the redundancy level becomes less than 0% at the downstream relay device or the receiving destination due to the packet loss rate of the downstream network (the redundancy is insufficient). If it can be predicted that the FEC parameter will be set, the FEC parameter is set so as to increase the redundancy level. At this time, the FEC parameter is set within a range where the transmission band of the transmission data does not exceed the effective band of the downstream network.
[0065]
The resource information of the device includes a utilization rate of a CPU [Central Processing Unit], a free memory, and the like. Over the entire network, the FEC parameters are set so that decoding and re-encoding are performed in a device having a sufficient computing capacity of the CPU or a device having a sufficient memory.
[0066]
The reception information of the downstream relay device includes a reception packet rate or packet sufficiency information, a delay, a buffer memory, and the like. The FEC parameter is set in consideration of reception information of the downstream relay device such as whether a packet loss occurs on the downstream side or whether the delay time is long.
[0067]
The operation of the relay device (n) 8 will be described with reference to FIGS. As a premise, the
[0068]
The relay device (n) 8 checks the redundancy level of the received FEC data in packet units, and determines whether or not to perform the FEC based on the redundancy level and the QoS information of the network (N) 5. . For example, when the redundancy level of the FEC data in packet units is reduced to 5%, since the maximum packet loss rate of the network (N) 5 is 25%, a packet loss occurs in the network (N) 5. In the relay device (n-1) 9, the redundancy level is reduced to less than 0%. In such a case, the relay device (n) 8 performs the FEC to improve the redundancy.
[0069]
When it is determined that the FEC is not performed, the relay device (n) 8 transmits the received FEC data in packet units to the relay device (n + 1) 9 via the network (N) 5 as it is.
[0070]
On the other hand, if it is determined that the FEC is to be performed, the relay device (n) 8 decodes the received FEC data in packet units. Further, the relay device (n) 8 sets FEC parameters based on the QoS information of the network (N) 5, applications, service levels, and the like (see FIG. 4). For example, since the maximum packet loss rate of the network (N) 5 is 25%, a redundancy level of about 30% is set. Then, the relay device (n) 8 re-encodes the decoded data into FEC data by the FEC using the LT code based on the set FEC parameters. Subsequently, the relay device (n) 8 transmits the re-encoded FEC data in packet units to the relay device (n + 1) 9 via the network (N) 5.
[0071]
Thereafter, the FEC data in packet units is received by the relay device (n + 1) 9 via the network (N) 5. The relay device (n + 1) 9 determines whether or not to perform the FEC based on the redundancy level of the FEC data in packet units, the QoS information of the network (D) 6, and the like. The FEC data in packet units is transmitted to the destination 2 via the network (D) 6 as it is, and when FEC is performed, the received FEC data in packet units is decoded and re-encoded to improve the redundancy. The data is transmitted to the destination 2 via the network (D) 6. Then, the FEC data in the packet unit is received by the destination 2. The receiving destination 2 sequentially decodes the received FEC data in packet units and reproduces it as streaming content. In this decoding, since the redundancy is improved in the relay devices 7, 8, and 9, errors such as occurrence of lost packets and macroblock errors do not occur in the streaming content.
[0072]
According to the relay devices 7, 8, and 9, since the redundancy can be improved in the middle of the entire network, there is no need to set a large redundancy level in the
[0073]
Further, according to the relay devices 7, 8, and 9, since the FEC parameters are set according to the application and the service level, the application can be transmitted while satisfying the QoS required by each application, and the service level is also improved. Can be maintained.
[0074]
Next, a second embodiment will be described. The overall configuration of the network according to the second embodiment will be described with reference to FIG. FIG. 5 is a configuration diagram of the entire network according to the second embodiment. In the second embodiment, the same components as those in the first embodiment are denoted by the same reference numerals, and description thereof is omitted.
[0075]
In the second embodiment, a streaming content is distributed from a
[0076]
The
[0077]
The relay device (n) 18 receives the FEC data in packet units from the network (N-1) 4 and takes the FEC data in packet units as it is in the network (N) in consideration of the protocol of the network (N) 5 and the like. 5 to the relay device (n) 19. At the same time, the relay device (n) 18 decodes the received FEC data. If the relay device (n) 18 cannot completely decode the received FEC data, the relay device (n) 18 receives the re-encoded FEC data transmitted from the upstream relay device (n-1) 17, and re-codes the re-encoded FEC data. The FEC data is completely decoded based on the converted FEC data. When the FEC data can be completely decoded, the relay device (n) 18 stops the transmission from the relay device (n-1) 17. Further, in order to cope with a case where the FEC data cannot be completely decoded in the downstream relay device (n + 1) 19, the relay device (n) 18 re-encodes the decoded data, and The FEC data is transmitted to the downstream relay device (n + 1) 19. Then, the relay device (n) 18 stops the transmission of the FEC data and also stops the decoding and the re-encoding in response to the transmission stop request from the downstream relay device (n + 1) 19.
[0078]
In the
[0079]
The
[0080]
Upon receiving the transmission request from the downstream relay device (n + 1) 19, the
[0081]
Note that, in the second embodiment, the
[0082]
The operation of the relay device (n) 18 will be described with reference to FIG. As a premise, the
[0083]
When receiving the FEC data in packet units, the relay device (n) 18 transmits the FEC data in packet units to the
[0084]
Then, the relay device (n) 18 determines whether or not the FEC data has been completely decoded into the original data. If it is determined that the data cannot be completely decoded, the relay device (n) 18 transmits a transmission request for transmitting the re-encoded FEC data to the relay device (n-1) 17, and completes the original data. The decoding is performed using the re-encoded FEC data from the relay device (n-1) 17 until decoding can be performed. On the other hand, when it is determined that the decoding has been completed completely, the relay device (n) 18 transmits a transmission stop request to stop the transmission of the re-encoded FEC data to the relay device (n-1) 17, and performs decoding. End the conversion.
[0085]
Further, when receiving the transmission request from the relay device (n + 1) 19, the relay device (n) 18 re-encodes the data decoded by the FEC using the LT code into the FEC data. Then, the relay device (n) 18 transmits the re-encoded FEC data to the relay device (n + 1) 19 via the network (N) 5 in packet units. Further, upon receiving the transmission stop request from the relay device (n + 1) 19, the relay device (n) 18 deletes the decoded data temporarily stored in the
[0086]
Thereafter, the FEC data in packet units and the FEC data re-encoded according to the request from the relay device (n + 1) 19 are received by the relay device (n + 1) 19 via the network (N) 5. The relay device (n + 1) 19 transmits the FEC data in packet units to the destination 2 via the network (D) 6 as it is. Further, the relay device (n + 1) 19 decodes the FEC data in packet units, re-encodes the decoded data in response to a transmission request from the reception destination 2, and transmits the re-encoded FEC data to the network (D ) 6 to the destination 2. Then, the FEC data in the packet unit and the re-encoded FEC data are received by the reception destination 2. The receiver 2 sequentially decodes the received FEC data in packet units. If the FEC data cannot be completely decoded with this FEC data, the FEC data is decoded using the re-encoded FEC data. Then, the receiving destination 2 reproduces the decrypted data as streaming content. In this decoding, since the FEC data is completely decoded in the
[0087]
According to the
[0088]
As described above, the embodiments according to the present invention have been described, but the present invention is not limited to the above embodiments, but may be embodied in various forms.
[0089]
For example, in this embodiment, the present invention is applied to a case where streaming contents are distributed from an ISP or the like to an individual or the like. However, in the case of an individual and an individual, communication is performed via various networks in the case of a telephone or a competitive game as an application. Applicable to
[0090]
Further, in the present embodiment, the processing according to the present invention is performed in all the relay devices on the network, but the processing according to the present invention may be performed in some of the relay devices on the network, Even when processing is performed in all of the above relay devices, a configuration may be adopted in which a relay device having sufficient processing capacity performs processing with priority.
[0091]
In this embodiment, the LT code is used as the FEC. However, another FEC such as a Hamming code, a BCH code, a Reed-Solomon code, and a tornado code may be used.
[0092]
Also, although the present embodiment has been described with reference to a single path from the transmission source to the reception destination, the present invention is also applicable to a case where the relay device or the reception source branches to a plurality of paths (networks). The optimum route is also determined based on the QoS information of each branching route (network).
[0093]
In this embodiment, the service level (service type) is set in the IP header. However, the service level (service type) may be set in another fixed-length data area such as a UDP header, or the header may have another data configuration. .
[0094]
Further, although the QoS information of the network is directly used in the present embodiment, secondary information such as four arithmetic operations on arbitrary information of the QoS information may be used.
[0095]
【The invention's effect】
The present invention can improve the redundancy based on the service quality information of the downstream network at the time of relaying between networks, even if the redundancy decreases in the middle of a network that transmits data. Therefore, data can be transmitted with a small degree of redundancy, so that the use efficiency of the transmission band of the network is improved and the transmission time can be shortened. Further, since the packet loss can be eliminated or minimized as much as possible, QoS and End-to-End can be improved. Service levels also improve.
[0096]
Further, since the present invention determines the necessity of implementing FEC or determines the type of FEC according to the application and / or service level, the redundancy is determined by the FEC according to the QoS required for various applications. It can be improved and service levels can be met.
[0097]
Also, the present invention efficiently re-transmits transmission data to original data and sequentially re-encodes transmitted data by sequentially re-encoding data in units of pallets partially decoded during the decoding of an arbitrary block. Data with improved redundancy can be re-encoded.
[0098]
Further, according to the present invention, even when 100% of the original data cannot be decoded by the transferred data due to a packet loss or the like, the FEC-received packet is received from the transmission unit or the relay device located on the upstream side. Thus, the original data can be 100% decoded. At this time, since the data transfer and the compounding and re-encoding of the data are performed in parallel, the delay can be minimized.
[Brief description of the drawings]
FIG. 1 is a configuration diagram of an entire network according to a first embodiment of the present invention.
FIGS. 2A and 2B are explanatory diagrams of a packet according to the embodiment of the present invention, wherein FIG. 2A is a diagram illustrating the configuration of a packet, and FIG. 2B is a diagram illustrating the data configuration of an IP header.
FIG. 3 is a conceptual diagram of an FEC LT code.
FIG. 4 is an explanatory diagram of FEC parameters according to the embodiment of the present invention.
FIG. 5 is a configuration diagram of an entire network according to a second embodiment of the present invention.
FIG. 6 is a configuration diagram of an entire conventional network.
[Explanation of symbols]
DESCRIPTION OF
Claims (15)
前記中継装置の下流側に位置する１つ又は複数のネットワークのサービス品質情報又はサービス品質情報の二次情報に基づいて、データの冗長度の改善の要否並びに冗長度レベルを決定する決定手段と、
データの冗長度を改善する冗長度改善手段と、
を備えることを特徴とする中継装置。A relay device provided at a connection point between one or more networks used when transmitting data from a transmission unit to a reception unit,
Determining means for determining whether data redundancy needs to be improved and a redundancy level based on service quality information or secondary information of service quality information of one or more networks located downstream of the relay device; ,
Redundancy improving means for improving data redundancy;
A relay device comprising:
コンピュータに、
前記中継装置の下流側に位置する１つ又は複数のネットワークのサービス品質情報又はサービス品質情報の二次情報に基づいて、データの冗長度の改善の要否並びに冗長度レベルを決定する決定手段と、
データの冗長度を改善する冗長度改善手段と、
して機能させることを特徴とする中継用プログラム。A relay program executed by a relay device provided at one or more connection points between networks used when transmitting data from a transmission unit to a reception unit,
On the computer,
Determining means for determining whether data redundancy needs to be improved and a redundancy level based on service quality information or secondary information of service quality information of one or more networks located downstream of the relay device; ,
Redundancy improving means for improving data redundancy;
A relay program characterized by functioning as a relay.
前記中継装置において、下流側に位置する１つ又は複数のネットワークのサービス品質情報に基づいて冗長度の改善の要否を決定し、冗長度の改善が必要な場合には順方向の誤り訂正によりデータの冗長度を改善することを特徴とする自律型誤り訂正ネットワーク。A transmission unit, a reception unit, and an autonomous error correction network including one or more relay devices provided at one or more network connection points,
In the relay device, the necessity of the improvement of the redundancy is determined based on the service quality information of one or more networks located on the downstream side. An autonomous error correction network characterized by improving data redundancy.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2002167692A JP2004015551A (en) | 2002-06-07 | 2002-06-07 | Repeating device, repeating program, and autonomous error correction network |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2002167692A JP2004015551A (en) | 2002-06-07 | 2002-06-07 | Repeating device, repeating program, and autonomous error correction network |
Related Child Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2007234339A Division JP4577341B2 (en) | 2007-09-10 | 2007-09-10 | Relay device and autonomous error correction network |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| JP2004015551A true JP2004015551A (en) | 2004-01-15 |
Family
ID=30434863
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2002167692A Pending JP2004015551A (en) | 2002-06-07 | 2002-06-07 | Repeating device, repeating program, and autonomous error correction network |
Country Status (1)
| Country | Link |
|---|---|
| JP (1) | JP2004015551A (en) |
Cited By (12)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| WO2005086436A1 (en) * | 2004-03-03 | 2005-09-15 | Mitsubishi Denki Kabushiki Kaisha | Packet transfer method, packet transfer network system, and terminal device |
| WO2006106841A1 (en) * | 2005-03-31 | 2006-10-12 | Mitsubishi Denki Kabushiki Kaisha | Error correction encoder |
| JP2006325113A (en) * | 2005-05-20 | 2006-11-30 | Nhk Engineering Services Inc | Packet relay device, contents transmission device and reproduction device, packet relay program and packet relaying method |
| WO2008139882A1 (en) * | 2007-05-08 | 2008-11-20 | Nec Corporation | Communication system, communication method, and program |
| JP2009521833A (en) * | 2005-12-22 | 2009-06-04 | テレフオンアクチーボラゲット エル エム エリクソン（パブル） | Network processing node and packet processing method |
| JP2011234415A (en) * | 2004-05-19 | 2011-11-17 | Agere Systems Inc | System and method for increasing range or bandwidth of wireless digital communication network |
| JP2012513689A (en) * | 2008-07-25 | 2012-06-14 | ノーテル ネットワークス リミテッド | Multi-segment loss protection |
| JP2014225900A (en) * | 2008-12-23 | 2014-12-04 | ロックスター コンソーシアム ユーエス エルピーＲｏｃｋｓｔａｒ Ｃｏｎｓｏｒｔｉｕｍ Ｕｓ Ｌｐ | Multi-segment loss protection |
| JP2015529044A (en) * | 2012-07-17 | 2015-10-01 | サムスン エレクトロニクス カンパニー リミテッド | Method and apparatus for distributing transfer characteristic information of multimedia data |
| JP2016027698A (en) * | 2014-06-27 | 2016-02-18 | 日本電信電話株式会社 | Data transfer system, relay node, and data transfer method |
| JP2017135665A (en) * | 2016-01-29 | 2017-08-03 | 日本電信電話株式会社 | Data transfer system |
| WO2021060406A1 (en) * | 2019-09-26 | 2021-04-01 | 日本電気株式会社 | Transmission-side relay device, system, method, and non-transitory computer-readable medium |
-
2002
- 2002-06-07 JP JP2002167692A patent/JP2004015551A/en active Pending
Cited By (20)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| WO2005086436A1 (en) * | 2004-03-03 | 2005-09-15 | Mitsubishi Denki Kabushiki Kaisha | Packet transfer method, packet transfer network system, and terminal device |
| JP2011234415A (en) * | 2004-05-19 | 2011-11-17 | Agere Systems Inc | System and method for increasing range or bandwidth of wireless digital communication network |
| WO2006106841A1 (en) * | 2005-03-31 | 2006-10-12 | Mitsubishi Denki Kabushiki Kaisha | Error correction encoder |
| US8122324B2 (en) | 2005-03-31 | 2012-02-21 | Mitsubishi Electric Corporation | Error correction coding apparatus |
| JP2006325113A (en) * | 2005-05-20 | 2006-11-30 | Nhk Engineering Services Inc | Packet relay device, contents transmission device and reproduction device, packet relay program and packet relaying method |
| JP4580278B2 (en) * | 2005-05-20 | 2010-11-10 | 財団法人エヌエイチケイエンジニアリングサービス | Packet relay device, content transmission device, packet relay program, and packet relay method |
| JP2009521833A (en) * | 2005-12-22 | 2009-06-04 | テレフオンアクチーボラゲット エル エム エリクソン（パブル） | Network processing node and packet processing method |
| US8315238B2 (en) | 2005-12-22 | 2012-11-20 | Telefonaktiebolaget L M Ericsson (Publ) | Network processing node and method for manipulating packets |
| WO2008139882A1 (en) * | 2007-05-08 | 2008-11-20 | Nec Corporation | Communication system, communication method, and program |
| JP2012513689A (en) * | 2008-07-25 | 2012-06-14 | ノーテル ネットワークス リミテッド | Multi-segment loss protection |
| JP2014225900A (en) * | 2008-12-23 | 2014-12-04 | ロックスター コンソーシアム ユーエス エルピーＲｏｃｋｓｔａｒ Ｃｏｎｓｏｒｔｉｕｍ Ｕｓ Ｌｐ | Multi-segment loss protection |
| JP2015529044A (en) * | 2012-07-17 | 2015-10-01 | サムスン エレクトロニクス カンパニー リミテッド | Method and apparatus for distributing transfer characteristic information of multimedia data |
| US10135666B2 (en) | 2012-07-17 | 2018-11-20 | Samsung Electronics Co., Ltd. | Apparatus and method for delivering transport characteristics of multimedia data |
| US10728082B2 (en) | 2012-07-17 | 2020-07-28 | Samsung Electronics Co., Ltd. | Apparatus and method for delivering transport characteristics of multimedia data |
| US11528315B2 (en) | 2012-07-17 | 2022-12-13 | Samsung Electronics Co., Ltd. | Apparatus and method for delivering transport characteristics of multimedia data |
| JP2016027698A (en) * | 2014-06-27 | 2016-02-18 | 日本電信電話株式会社 | Data transfer system, relay node, and data transfer method |
| JP2017135665A (en) * | 2016-01-29 | 2017-08-03 | 日本電信電話株式会社 | Data transfer system |
| WO2021060406A1 (en) * | 2019-09-26 | 2021-04-01 | 日本電気株式会社 | Transmission-side relay device, system, method, and non-transitory computer-readable medium |
| JP2021052353A (en) * | 2019-09-26 | 2021-04-01 | 日本電気株式会社 | Sender relay device, system, method, and program |
| EP4037269A4 (en) * | 2019-09-26 | 2022-10-19 | NEC Corporation | Transmission-side relay device, system, method, and non-transitory computer-readable medium |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US9537611B2 (en) | Method and apparatus for improving the performance of TCP and other network protocols in a communications network using proxy servers | |
| Subramanian et al. | OverQoS: An Overlay Based Architecture for Enhancing Internet QoS. | |
| Apostolopoulos et al. | Path diversity for enhanced media streaming | |
| JP7292411B2 (en) | Data stream transmission method and device | |
| JP2007504694A (en) | Congestion control based on transmission rate for packet networks | |
| Li et al. | A framework for qualitative communications using big packet protocol | |
| Liang et al. | TCP-RTM: Using TCP for real time multimedia applications | |
| Darabkh et al. | Improving UDP performance using intermediate QoD‐aware hop system for wired/wireless multimedia communication systems | |
| JP2004015551A (en) | Repeating device, repeating program, and autonomous error correction network | |
| JP4737615B2 (en) | Apparatus for connecting between a first network and a second network and a method for transmitting a stream of packets transferred in multipoint mode by the apparatus | |
| Han et al. | {RPT}: Re-architecting Loss Protection for {Content-Aware} Networks | |
| JP4577341B2 (en) | Relay device and autonomous error correction network | |
| US20090313673A1 (en) | Method and System for Protecting MPEG Frames During Transmission Within An Internet Protocol (IP) Network | |
| JP5169226B2 (en) | Relay device and program | |
| Becke et al. | Alternative transmission strategies for multipath transport of multimedia streams over wireless networks | |
| Afzal et al. | System design options for video broadcasting over wireless networks. | |
| JP2006067075A (en) | Method and system for data transmission/reception | |
| Liu et al. | Network coding for p2p live media streaming | |
| Hayasaka et al. | An efficient loss recovery scheme for on-demand video streaming over the internet | |
| Ngo et al. | Error spreading: Reducing bursty errors in continuous media streaming | |
| Nguyen et al. | Internet media streaming using network coding and path diversity | |
| Hayasaka et al. | Peer-to-peer multimedia streaming with guaranteed QoS for future real-time applications | |
| Cui et al. | Joint source-network coding optimization for video streaming over wireless multi-hop networks | |
| Brennan et al. | Split-layer video multicast protocol: A new receiver-based rate-adaptation protocol | |
| Prins et al. | Fast rtp retransmission for iptv-implementation and evaluation |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20050606 |
|
| A977 | Report on retrieval |
Effective date: 20070115 Free format text: JAPANESE INTERMEDIATE CODE: A971007 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20070123 |
|
| A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20070326 |
|
| A02 | Decision of refusal |
Effective date: 20070710 Free format text: JAPANESE INTERMEDIATE CODE: A02 |
|
| A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20070910 |