(57)【特許請求の範囲】
【請求項１】
ブロードキャスティング及び／又は通信システムにおける送信装置がフォワードエラー訂正（ＦＥＣ）符号化を実行する方法であって、
ｍ個のソースパケットを含むソースパケットブロックを使用してｎ個のソースシンボルを含むソースシンボルブロックを生成するステップであって、各ソースシンボルは同一の長さを有するステップと、
前記ソースシンボルブロックに対するフォワードエラー訂正（ＦＥＣ）符号化を実行することにより、一つ以上のリペアシンボルを生成するステップと、を含み、
前記ソースシンボルブロックに含まれる各ソースシンボルは、同一の数の複数のシンボルエレメントを含み、各シンボルエレメントは同一の長さを有し、
前記ソースシンボルブロックを生成するステップは、
前記ｍ個のソースパケットの各々を一つ以上のシンボルエレメントに割り当てるステップを含み、前記ｍ個のソースパケットの各々は、各ソースパケットが割り当てられる一つ以上のシンボルエレメントの最初のシンボルエレメントの開始位置から割り当てられ、
前記方法は、
前記ソースパケットブロックに対する長さシンボルブロックを生成するステップと、
前記長さシンボルブロックに対するＦＥＣ符号化を実行することにより、１つ以上の長さリペアシンボルを生成するステップと、をさらに有し、
前記長さシンボルブロックはｎ個のシンボルを含み、前記ｎ個のシンボルは、ｍ個の長さシンボル及び（ｎ−ｍ）個のゼロ−パディング（zero-padding）シンボルを含み、前記ｍ個の長さシンボルの各々は、前記ｍ個のソースパケットのそれぞれの長さを指示することを特徴とする方法。
【請求項２】
ブロードキャスティング及び／又は通信システムにおいてフォワードエラー訂正（ＦＥＣ）符号化（encoding）を実行する送信装置であって、
ｍ個のソースパケットを含むソースパケットブロックを使用してｎ個の同一の長さを有するソースシンボルを含むソースシンボルブロックを生成し、前記ソースシンボルブロックに対するフォワードエラー訂正（ＦＥＣ）符号化を実行することにより、一つ以上のリペアシンボルを生成するように構成されたフォワードエラー訂正（ＦＥＣ）符号化部を含み、
前記ソースシンボルブロックに含まれる各ソースシンボルは、同一の数の複数のシンボルエレメントを含み、各シンボルエレメントは同一の長さを有し、
前記ソースシンボルブロックを生成することは、
前記ｍ個のソースパケットの各々を一つ以上のシンボルエレメントに割り当てることを含み、前記ｍ個のソースパケットの各々は、各ソースパケットが割り当てられる一つ以上のシンボルエレメントの最初のシンボルエレメントの開始位置から割り当てられ、
前記ＦＥＣ符号化部は、
前記ソースパケットブロックに対する長さシンボルブロックを生成し、前記長さシンボルブロックに対するＦＥＣ符号化を実行することにより１つ以上の長さリペアシンボルを生成するようにさらに構成され、
前記長さシンボルブロックはｎ個のシンボルを含み、前記ｎ個のシンボルは、ｍ個の長さシンボル及び（ｎ−ｍ）個のゼロ−パディング（zero-padding）シンボルを含み、前記ｍ個の長さシンボルの各々は、前記ｍ個のソースパケットのそれぞれの長さを指示することを特徴とする装置。
【請求項３】
ブロードキャスティング及び／又は通信システムにおける受信装置がフォワードエラー訂正（ＦＥＣ）復号化（decoding）を実行する方法であって、
一つ以上のソースパケット及び一つ以上のリペアパケットを受信するステップと、
前記一つ以上のリペアパケットに基づいて前記一つ以上のソースパケットに対するＦＥＣ復号化を実行するステップと、を含み、
前記一つ以上のリペアパケットは、一つ以上のリペアシンボルのデータを含み、前記一つ以上のリペアシンボルは、ｎ個の同一の長さを有するソースシンボルを含むソースシンボルブロックに対するＦＥＣ符号化を実行することにより生成され、前記ソースシンボルブロックは、ｍ個のソースパケットを含むソースパケットブロックを利用して生成され、
前記ソースシンボルブロックに含まれる各ソースシンボルは、同一の数の複数のシンボルエレメントを含み、前記ｍ個のソースパケットの各々は、一つ以上の同一の長さを有するシンボルエレメントに割り当てられ、そして、前記ｍ個のソースパケットの各々は、各ソースパケットが割り当てられる一つ以上のシンボルエレメントの最初のシンボルエレメントの開始位置から割り当てられ、
前記一つ以上のリペアパケットは、一つ以上の長さリペアシンボルのデータをさらに含み、前記一つ以上のリペアシンボルは、ｎ個のシンボルを含む長さシンボルブロックに対するＦＥＣ符号化を実行することにより生成され、前記ｎ個のシンボルは、ｍ個の長さシンボル及び（ｎ−ｍ）個のゼロ−パディング（zero-padding）シンボルを含み、前記ｍ個の長さシンボルの各々は、前記ｍ個のソースパケットのそれぞれの長さを指示することを特徴とする方法。
【請求項４】
ブロードキャスティング及び／又は通信システムにおいてフォワードエラー訂正（ＦＥＣ）復号化（decoding）を実行する受信装置であって、
一つ以上のソースパケット及び一つ以上のリペアパケットを受信する受信部と、
前記一つ以上のリペアパケットに基づいて前記一つ以上のソースパケットに対するＦＥＣ復号化を実行する制御部と、を含み、
前記一つ以上のリペアパケットは、一つ以上のリペアシンボルのデータを含み、前記一つ以上のリペアシンボルは、ｎ個の同一の長さを有するソースシンボルを含むソースシンボルブロックに対するＦＥＣ符号化を実行することにより生成され、前記ソースシンボルブロックは、ｍ個のソースパケットを含むソースパケットブロックを利用して生成され、
前記ソースシンボルブロックに含まれる各ソースシンボルは、同一の数の複数のシンボルエレメントを含み、前記ｍ個のソースパケットの各々は、一つ以上の同一の長さを有するシンボルエレメントに割り当てられ、そして、前記ｍ個のソースパケットの各々は、各ソースパケットが割り当てられる一つ以上のシンボルエレメントの最初のシンボルエレメントの開始位置から割り当てられ、
前記一つ以上のリペアパケットは、一つ以上の長さリペアシンボルのデータをさらに含み、前記一つ以上のリペアシンボルは、ｎ個のシンボルを含む長さシンボルブロックに対するＦＥＣ符号化を実行することにより生成され、前記ｎ個のシンボルは、ｍ個の長さシンボル及び（ｎ−ｍ）個のゼロ−パディング（zero-padding）シンボルを含み、前記ｍ個の長さシンボルの各々は、前記ｍ個のソースパケットのそれぞれの長さを指示することを特徴とする装置。
【請求項５】
前記ソースパケットのそれぞれは、ＭＰＥＧメディアトランスポート（ＭＭＴ）パケットヘッダに前記ソースパケットを他のソースパケットと識別するための識別情報を含むことを特徴とする請求項１又は請求項３に記載の方法。
【請求項６】
前記ソースパケットの配列順序は、パケット識別子（ＩＤ）、パケットシーケンス番号、及びパケットカウンタのうちの少なくとも１つを用いて決定されることを特徴とするとする請求項１又は請求項３に記載の方法。
【請求項７】
ＦＥＣコンフィギュレーション情報は、前記ソースシンボルブロック及び前記長さシンボルブロックの生成に関する情報を含むことを特徴とする請求項３に記載の方法。
【請求項８】
前記ソースパケットのそれぞれは、ＭＰＥＧメディアトランスポート（ＭＭＴ）パケットヘッダに前記ソースパケットを他のソースパケットと識別するための識別情報を含むことを特徴とする請求項２又は請求項４に記載の装置。
【請求項９】
前記ソースパケットの配列順序は、パケット識別子（ＩＤ）、パケットシーケンス番号、及びパケットカウンタのうちの少なくとも１つを用いて決定されることを特徴とする請求項２又は請求項４に記載の装置。
【請求項１０】
ＦＥＣコンフィギュレーション情報は、前記ソースシンボルブロック及び前記長さシンボルブロックの生成に関する情報を含むことを特徴とする請求項４に記載の装置。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、一般的に、ブロードキャスティング及び／又は通信システムにおけるパケットの生成及び復元を行うための技術に関し、より詳細には、エラー訂正符号を使用して損失されたパケットを効率的に復元する装置及び方法に関するものである。
【背景技術】
【０００２】
近来の通信システムでは、様々なコンテンツの消費傾向の変化及び高解像度（High Definition：ＨＤ）コンテンツ及び超高解像度（Ultra High Definition：ＵＨＤ）コンテンツのような高容量コンテンツの増加の結果として、通信システムにおけるネットワークを通したデータ輻輳（data Congestion）は、さらに悪化している。結果的に、信号送信装置（例えば、ホストＡ）により送信されたコンテンツは、信号受信装置（例えば、ホストＢ）に正常に配信されず、信号送信装置が送信したコンテンツの一部又は全部は、経路上で損失される状況が発生する場合がある。
【０００３】
一般的に、データは、パケット単位で送信されるので、データ損失は、パケットの単位で発生する。したがって、ネットワーク上で送信パケットが損失する場合には、信号受信装置は、損失した送信パケットを受信することができないために、損失した送信パケットが含むデータを認識できない。したがって、オーディオの品質の低下、ビデオの画質の劣化、画面破れ、字幕欠落、ファイルの損失のような様々な理由でユーザの不便をもたらす。
【０００４】
ネットワーク上で損失したデータを復元するために、所定数のパケットを含むソースブロックにフォワードエラー訂正（ＦＥＣ）方式を使用するＦＥＣ符号化により生成されるリペアシンボルを付加する。一般的に、パケット内に送信されるデータ（すなわち、ソースペイロード）のサイズ又は長さは、固定されることもあり、又は可変することもある。すなわち、ソースペイロードは、固定されたパケットサイズを有することもあり、可変パケットサイズを有することもある。例えば、ムービングピクチャーエクスパーツグループ２（MovingPictureExpertsGroup 2：ＭＰＥＧ２）トランスポートストリーム（TransportStream：ＴＳ）は、４バイトのヘッダ及び１８４バイトのペイロードを含む１８８バイトの固定されたパケットサイズを有する。しかしながら、リアルタイムトランスポートプロトコル（Real-TimeTransportProtocol：以下、‘ＲＴＰ’と称する）パケットサイズ又はＭＰＥＧメディアトランスポート（MPEG MediaTransport：以下、‘ＭＭＴ'と称する）パケットサイズは、常に固定されていない。
【０００５】
したがって、可変パケットサイズが適用される場合に、信号送信装置は、実際に送信されるパケットのサイズを同一にするためにパディングデータ（paddingdata）をデータに付加することによりソースブロックを生成した後に、生成されたソースブロックに対してＦＥＣ符号化動作を実行する。
【０００６】
しかしながら、このように、パディングデータをデータに付加することによりソースブロックを生成した後に、生成されたソースブロックに対してＦＥＣ符号化動作を実行する場合において、ＦＥＣデコーダがＦＥＣ復号化中にネットワーク(チャネル)上で損失したパケットを復元するとき、ＦＥＣデコーダは、ソースブロック（すなわち、パディングデータを含むソースブロック）を復元する。これに関連して、実際の送信パケットを復元するためには、ＦＥＣデコーダは、パディングデータがデータにパディングされる前のパケットのサイズを正確に検出する必要がある。
【発明の概要】
【発明が解決しようとする課題】
【０００７】
本発明の目的は、少なくとも上述した問題点及び／又は不都合に取り組み、少なくとも以下の利便性を提供することにある。すなわち、本発明の目的は、ブロードキャスティング及び／又は通信システムにおけるパケットの生成及び復元のための方法及び装置を提供することにある。
【０００８】
本発明の別の目的は、ブロードキャスティング及び／又は通信システムにおけるデータ復元効率性を増加させるパケットの生成及び復元のための方法及び装置を提供することにある。
【０００９】
本発明のさらに別の目的は、ブロードキャスティング及び／又は通信システムにおける効率的な送信信頼度を取得できるパケットの生成及び復元のための方法及び装置を提供することにある。
【００１０】
本発明のさらにまた別の目的は、ブロードキャスティング及び／又は通信システムにおけるソースパケットが受信されるか否かに関係なく、受信器がソースパケットに対応するソースシンボルをソースブロックで特定できるようにするパケットの生成及び復元のための方法及び装置を提供することにある。
【００１１】
本発明のさらなる別の目的は、ブロードキャスティング及び／又は通信システムにおける復元されたソースブロックの復元されたソースシンボルで損失されたパケットの開始点を検出できるパケットの生成及び復元のための方法及び装置を提供することにある。
【００１２】
本発明のさらなる別の１つの目的は、ブロードキャスティング及び／又は通信システムにおける全体又は一部が復元されたソースブロックの復元されたソースシンボルでパディングデータを除去できるパケットの生成及び復元のための方法及び装置を提供することにある。
【００１３】
本発明のさらにその別の目的は、ブロードキャスティング及び／又は通信システムにおける全体又は一部が復元されたソースブロックの復元されたソースシンボルに含まれたすべてのソースパケットを復元できるパケットの生成及び復元のための方法及び装置を提供することにある。
【課題を解決するための手段】
【００１４】
上記のような目的を達成するために、本発明の実施形態の一態様によれば、ブロードキャスティング及び／又は通信システムにおける送信装置がパケットを生成する方法は、１つ以上のソースパケットを含むソースパケットブロックを使用して１つ以上の同一の長さを有するソースシンボルを含む第１のソースシンボルブロックを生成するステップと、上記第１のソースシンボルブロックにフォワードエラー訂正（ＦＥＣ）符号化動作を実行するステップと、上記ソースパケットブロックを構成するそれぞれのソースパケットに関する情報を含む第２のソースシンボルブロックを生成するステップと、上記第２のソースシンボルブロックにＦＥＣ符号化動作を実行することにより１つ以上のリペアシンボルを含む第２のリペアシンボルブロックを生成するステップとを含む。１つのソースシンボルは、上記第１のソースシンボルブロックにおいて１つ以上のシンボルエレメントを含み、上記第２のソースシンボルブロックは、上記ソースパケットブロックに含まれた少なくとも１つのソースパケットの長さに関する情報を含むことを特徴とする。
【００１５】
本発明の実施形態の他の態様によれば、ブロードキャスティング及び／又は通信システムにおいてパケットを生成する送信装置は、１つ以上のソースパケットを含むソースパケットブロックを使用して１つ以上の同一の長さを有するソースシンボルを含む第１のソースシンボルブロックを生成し、上記第１のソースシンボルブロックにフォワードエラー訂正（ＦＥＣ）符号化動作を実行する第１のフォワードエラー訂正（ＦＥＣ）符号化部と、上記ソースパケットブロックを構成するそれぞれのソースパケットに関する情報を含む第２のソースシンボルブロックを生成し、上記第２のソースシンボルブロックにＦＥＣ符号化動作を実行することにより１つ以上のリペアシンボルを含む第２のリペアシンボルブロックを生成する第２のＦＥＣ符号化部とを含む。１つのソースシンボルは、上記第１のソースシンボルブロックにおいて１つ以上のシンボルエレメントを含み、上記第２のソースシンボルブロックは、上記ソースパケットブロックに含まれた少なくとも１つのソースパケットの長さに関する情報を含むことを特徴とする。
【００１６】
本発明の実施形態のさらに他の態様によれば、ブロードキャスティング及び／又は通信システムにおける受信装置がパケットを復元する方法は、送信装置から受信された信号の復調及び処理を行うことによりパケットを受信するステップと、上記受信されたパケットからフォワードエラー訂正（ＦＥＣ）コンフィギュレーション情報を取得するステップと、上記ＦＥＣコンフィギュレーション情報に基づいて第２の受信シンボルブロックを構成するステップと、第２のソースシンボルブロックを復元するステップと、上記第２のソースシンボルブロックの復元に成功したら、第１の受信シンボルブロックを構成するステップと、１つ以上の同一の長さを有するソースシンボルを含む第１のソースシンボルブロックを復元するステップとを含む。上記第１のソースシンボルブロックは、１つ以上のソースパケットを含むソースパケットブロックを使用して上記１つ以上の同一の長さを有するソースシンボルで構成され、１つのソースシンボルは、上記第１のソースシンボルブロックで１つ以上のシンボルエレメントを含み、上記第２のソースシンボルブロックは、上記ソースパケットブロックに含まれた少なくとも１つのソースパケットの長さに関する情報を含むことを特徴とする。
【００１７】
本発明の実施形態のさらなる他の態様によれば、ブロードキャスティング及び／又は通信システムにおいてパケットを復元する受信装置は、送信装置から受信された信号の復調及び処理を行うことによりパケットを受信する受信部と、上記受信されたパケットからフォワードエラー訂正（ＦＥＣ）コンフィギュレーション情報を取得し、上記ＦＥＣコンフィギュレーション情報に基づいて第２の受信シンボルブロックを構成し、第２のソースシンボルブロックを復元し、上記第２のソースシンボルブロックの復元に成功したら、第１の受信シンボルブロックを構成し、１つ以上の同一の長さを有するソースシンボルを含む第１のソースシンボルブロックを復元する制御部とを含む。上記第１のソースシンボルブロックは、１つ以上のソースパケットを含むソースパケットブロックを使用して上記１つ以上の同一の長さを有するソースシンボルで構成され、１つのソースシンボルは、上記第１のソースシンボルブロックにおいて１つ以上のシンボルエレメントを含み、上記第２のソースシンボルブロックは、上記ソースパケットブロックに含まれた少なくとも１つのソースパケットの長さに関する情報を含むことを特徴とする。
【発明の効果】
【００１８】
本発明の実施形態によると、ブロードキャスティング／通信システムにおけるパケットを効率的に送受信する装置及び方法を提供でき、ブロードキャスティング／通信システムにおいて効率的にエラーを訂正できる。
【図面の簡単な説明】
【００１９】
【図１】本発明の一実施形態による上位レイヤエラー訂正符号を使用する送信器及び受信器の構成を示すブロック図である。
【図２】本発明の一実施形態によるＭＰＥＧメディアトランスポート（ＭＭＴ）システムのアプリケーションレイヤーフォワードエラー訂正（ＡＬ−ＦＥＣ）アーキテクチャーを概略的に示す図である。
【図３】本発明の一実施形態によるソースパケットブロックを示す図である。
【図４】本発明の一実施形態による第１のソースシンボルブロックの構成例を示す図である。
【図５】本発明の一実施形態による第２のソースシンボルブロックの構成例を示す図である。
【図６】本発明の一実施形態による第１のパケット配列方式により構成されたソースパケットブロックの例を示す図である。
【図７】本発明の一実施形態による第２のパケット配列方式により構成されたソースパケットブロックの例を示す図である。
【図８】本発明の一実施形態による第１のパケット配列方式を使用する場合のリペアＦＥＣペイロード識別子（ＩＤ）の例を示す図である。
【図９】本発明の一実施形態による第１のパケット配列方式を使用する場合のリペアＦＥＣペイロードＩＤの例を示す図である。
【図１０】本発明の一実施形態によるＦＥＣ復号化ブロックの動作を示すフローチャートである。
【図１１】本発明の一実施形態によるＦＥＣ符号化ブロックの動作を示すフローチャートである。
【発明を実施するための形態】
【００２０】
以下、本発明を実施するための形態を、図面を参照しながら詳細に説明する。下記の説明において、明瞭性と簡潔性の観点から、本発明に関連した公知の機能や構成に関する具体的な説明が本発明の要旨を不明瞭にすると判断される場合には、その詳細な説明を省略する。また、後述する用語は、本発明の機能を考慮して定義されたものであって、ユーザ、運用者の意図、又は慣例によって変わり得る。したがって、上記用語は、本明細書の全体内容に基づいて定義されなければならない。
【００２１】
本発明を説明するにあたり、通信システムは、例えば、ムービングピクチャーエクスパーツグループ−Ｈ（Motion Picture Experts Group：ＭＰＥＧ−Ｈ）パーツ１メディアトランスポート（MPEG Media Transport：ＭＭＴ）システムであると仮定し、ＭＭＴシステムだけでなく、進化したパケットシステム（EvolvedPacketSystem：ＥＰＳ）と、ロングタームエボリューション（Long Term Evolution：ＬＴＥ）移動通信システムと、ロングタームエボリューション−アドバンスド（Long Term Evolution-Advanced：ＬＴＥ−Ａ）移動通信システムと、米国電気電子技術者協会（Institute of Electrical and Electronics Engineers：ＩＥＥＥ）８０２．１６ｍ通信システムなどのような通信システムに適用可能であることは明確に理解できる。
【００２２】
本発明の実施形態は、ネットワークを通して高解像度（HighDefinition：ＨＤ）コンテンツ及び超高解像度（UltraHighDefinition：ＵＨＤ）コンテンツのような高容量コンテンツだけでなく、映像会議／通話などのような様々なマルチメディアサービスを提供できる携帯電話、テレビジョン（ＴＶ）、コンピュータ、電子掲示板、タブレット、及び電子ブックなどのようなすべての電子デバイスでデータパケットの損失を効率的に復旧するパケットの生成及び復元のための装置及び方法を提案する。
【００２３】
本発明の実施形態では、具体的なＦＥＣ符号化方式について説明していないが、ＦＥＣ符号化方式は、リード−ソロモン（Reed-Solomon：ＲＳ）符号、低密度パリティ検査（LowDensityParityCheck：ＬＤＰＣ）符号、ターボ符号、ラプター（Raptor）符号、排他的論理和（eXclusiveOR：ＸＯＲ）、Ｐｒｏ−ＭＰＥＧ（MovingPictureExpertsGroup）ＦＥＣ符号のような特定のＦＥＣ符号化方式に限定されないことに留意すべきである。
【００２４】
本発明の実施形態及び実施形態を説明するために使用される用語は、ネットワーク上で損失したパケットをリペアシンボルを使用して復元するという仮定に基づく。しかしながら、ネットワーク上で損失したパケットだけでなく、送信経路上でエラーが発生したパケットのエラー訂正及び損失したパケットとエラーが発生したパケットとが混在した状況でも本発明が適用されることができることに留意する。
【００２５】
一方、１つ以上のソースパケットを含むソースパケットブロックのＦＥＣ符号化を通してリペアパケットを生成する動作は、次のように実行される。同一の長さを有するソースシンボルを含むソースシンボルブロックは、所定の規則でソースパケットブロックから構成される。リペアシンボルを含むリペアシンボルブロックは、入力として使用されるソースシンボルブロックのＦＥＣ符号化により生成され、生成されたリペアシンボルは、送信のためにＦＥＣリペアパケットに変換された後に送信される。通常、ソースシンボル及びリペアシンボルは、同一の長さを有する。
【００２６】
上述したように、ソースシンボルは同一の長さを有する一方、ソースパケットはその長さが可変であってもよい。したがって、１つのソースパケットを、ソースパケットの長さに従って複数のソースシンボルに割り当てることができ、パディングデータは、ソースシンボルの長さを保持するために必要である。したがって、復元されたソースシンボルブロックを使用して損失したソースパケットを復元するためには、受信器は、損失したソースパケットを形成するソースシンボルを特定し、パディングデータを除去しなければならない。
【００２７】
以下では、本発明の様々な実施形態を説明するために使用される用語及び定義について整理する。
【００２８】
−  ＦＥＣ符号：エラーシンボル又は削除シンボルを訂正するために使用されるエラー訂正符号であり、符号化されたデータフローがデータ損失に対して回復性を有するようにする符号化データのためのアルゴリズム。
【００２９】
−  ソースシンボル：ＦＥＣ符号化過程で使用されるデータのユニット。
【００３０】
−  リペアシンボル：ソースシンボルでない符号化シンボル。
【００３１】
−  ソースパケット：ＦＥＣ符号化方式により保護されるパケット。
【００３２】
−  ソースパケットブロック：単一のブロックとして保護されるＦＥＣソースフローのソースパケットのセグメントされた集合。
【００３３】
−  ソースシンボルブロック：単一のソースパケットブロックから生成されるソースシンボルの集合。
【００３４】
−  リペアシンボルブロック：損失したソースシンボルを復元するために使用され得るリペアシンボルの集合。
【００３５】
−  符号化シンボルブロック：ソースシンボルブロックの符号化過程で生成される符号化シンボルの集合。
【００３６】
−  符号化シンボル：符号化過程により生成されるデータのユニット。ここで、ソースシンボルは、符号化シンボルの一部であり得る。
【００３７】
−  ＦＥＣリペアパケット：リペアシンボルブロックの１つ又はそれ以上のリペアシンボルを配信するためにリペアＦＥＣペイロード識別子（ＩＤ）を有するパケット。
【００３８】
−  ＦＥＣリペアパケットブロック：リペアシンボルブロックを配信するためのＦＥＣリペアパケットの集合。
【００３９】
−  ＦＥＣペイロードＩＤ：ＦＥＣ方式に従ってパケットのコンテンツを識別するためのＩＤ。
【００４０】
−  リペアＦＥＣペイロードＩＤ：エラー訂正リペアパケットと共に使用するためのエラー訂正ペイロードＩＤ。
【００４１】
−  ＭＭＴ(ＭＰＥＧメディアトランスポート)：ＭＰＥＧデータを効率的に配信するために設計された国際標準。
【００４２】
−  ＦＥＣソースフロー：ＭＭＴ  ＦＥＣ方式の一例により保護されるソースパケットのフロー。
【００４３】
−  ＦＥＣ方式：ＦＥＣ符号を使用するために要求される追加のプロトコルアスペクトを定義する規格。
【００４４】
−  ＦＥＣリペアフロー：ソースフローを保護するリペアシンボルを運搬するデータフロー。
【００４５】
−  ＦＥＣ符号化されたフロー：ＦＥＣソースフロー及び１つ又はそれ以上の関連ＦＥＣリペアフローで構成されたフローの論理的な集合。
【００４６】
−  アセット：同一のアセットＩＤを有する１つ又はそれ以上のメディア処理単位（ＭＰＵ）で構成された同一のトランスポート特性を有するデータを含むデータエンティティ。
【００４７】
−  メディア処理単位（ＭＰＵ）：メディアコーデックに依存しない（agnostic）、独立して復号可能な同期型データ又は非同期型データのための一般コンテナ（genericcontainer）。
【００４８】
−  パッケージ：１つ以上のアセット及びそれらに関連したアセット配信特性及びコンフィギュレーション情報で構成されたデータの論理的なコレクション。
【００４９】
−  ＭＭＴパケット：ＭＭＴプロトコルにより生成されるか又は消費されるデータのフォーマット化されたユニット。
【００５０】
−  ＭＭＴペイロード：ＭＭＴプロトコル又はインターネットアプリケーションレイヤートランスポートプロトコルを使用してパッケージ及び／又はシグナリングメッセージを運搬するデータのフォーマット化されたユニット。
【００５１】
−  ＭＭＴプロトコル：インターネットプロトコル（ＩＰ）ネットワークを通してＭＭＴペイロードを配信するためのアプリケーションレイヤートランスポートプロトコル。
【００５２】
図１を参照して、本発明の一実施形態による通信システムの構成について説明する。
【００５３】
図１は、本発明の一実施形態による上位レイヤエラー訂正符号を使用する送信器及び受信器の構成を示すブロック図である。
【００５４】
図１を参照すると、送信器１００は、ＦＥＣ上位プロトコルに対応するプロトコルＡブロック１０１、ＦＥＣ符号化ブロック１０２、ＦＥＣ下位プロトコルに対応するプロトコルＢブロック１０３、及び送信器物理レイヤーブロック１０４を含む。
【００５５】
プロトコルＡブロック１０１から出力される送信パケットは、ソースパケット１３０に変換され、ソースパケット１３０は、ＦＥＣ符号化ブロック１０２に伝達される。一般的に、ソースパケットは、送信パケットとは異なる形式を有することもあるが、図１では、送信パケットとソースパケットとが同一の形式を有すると仮定する。
【００５６】
ＦＥＣ符号化ブロック１０２は、ソースパケットのコレクションであるソースパケットブロックを構成し、ＦＥＣ符号化を通してリペアシンボルを生成し、１つ以上のリペアシンボルを含むリペアペイロード１３１にリペアエラー訂正ペイロードＩＤ１３２を付加し、リペアエラー訂正ペイロードＩＤ１３２を有するリペアペイロード１３１をプロトコルＢブロック１０３に提供する。このとき、リペアＦＥＣペイロードＩＤと結合されたリペアペイロードは、ＦＥＣリペアパケットと呼ばれる。リペアＦＥＣペイロードＩＤは、ソースパケットブロックに含まれるソースパケットの長さに関する情報を含む。
【００５７】
図１において、ＦＥＣ符号化ブロック１０２は、プロトコルＡブロック１０１とプロトコルＢブロック１０３との間に介在されるが、一部の実施形態では、プロトコルＡブロック１０１がＦＥＣ符号化ブロック１０２を含むこともある。この場合に、ＦＥＣリペアパケットは、プロトコルＡブロック１０１の機能を実行するためのプロトコルヘッダを含み得る。ＦＥＣ符号化ブロック１０２を含むプロトコルＡブロック１０１は、ソースパケット及びＦＥＣリペアパケットを１つのパケットフローに多重化するマルチプレクサを含み得る。
【００５８】
より具体的に、ＦＥＣ符号化ブロック１０２は、第１のＦＥＣ符号化部及び第２のＦＥＣ符号化部を含む。
【００５９】
第１のＦＥＣ符号化部は、１つ以上のソースパケットを含むソースパケットブロックを使用して１つ以上の同一の長さを有するソースシンボルを含む第１のソースシンボルブロックを生成し、第１のソースシンボルブロックにＦＥＣ符号化動作を実行する。
【００６０】
第２のＦＥＣ符号化部は、ソースパケットブロックに含まれるそれぞれのソースパケットに関する情報を含む第２のソースシンボルブロックを生成し、第２のソースシンボルブロックにＦＥＣ符号化動作を実行することにより１つ以上のリペアシンボルを含む第２のリペアシンボルブロックを生成する。ここで、第１のソースシンボルブロック内の１つのソースシンボルは、１つ以上のシンボルエレメントを含み、第２のソースシンボルブロックは、ソースパケットブロックに含まれる少なくとも１つのソースパケットの長さに関する情報を含む。
【００６１】
送信器物理レイヤーブロック１０４は、ソースパケット及びＦＥＣリペアパケットを送信に適合した信号に変換し、この信号を送信する。プロトコルＢブロック１０３と送信器物理レイヤーブロック１０４との間には、様々なレイヤーが存在し得る。様々なレイヤーは本発明の要旨とは関係しないので、ここでは、様々なレイヤーの具体的な構成についての説明を省略する。
【００６２】
受信器１１０は、受信器物理レイヤーブロック１１１、ＦＥＣ下位プロトコルに対応するプロトコルＢブロック１１２、ＦＥＣ復号化ブロック１１３、及びＦＥＣ上位プロトコルに対応するプロトコルＡブロック１１４を含む。
【００６３】
受信器物理レイヤーブロック１１１は、送信チャネル１２０を通して受信された信号を解釈し、解釈された信号をプロトコルＢブロック１１２に伝達する。送信器１００の場合と同様に、プロトコルＢブロック１１２と受信器物理レイヤーブロック１１１との間には、様々なレイヤーが存在してもよいが、様々なレイヤーの具体的な構成については、本発明の要旨とは関係ないので説明を省略する。
【００６４】
プロトコルＢブロック１１２は、受信された信号又はパケットを解釈し、受信されたＦＥＣパケットをＦＥＣ復号化ブロック１１３に伝達する。このとき、送信器により送信されたＦＥＣパケットのうちの一部は、ネットワークの混雑及び物理レイヤーで発生したエラーのために損失され、それにより、ＦＥＣ復号化ブロック１１３に伝達されないことがある。
【００６５】
ＦＥＣ復号化ブロック１１３は、受信されたＦＥＣパケットに対するＦＥＣ復号化を実行し、受信されたソースパケットとともに復元されたソースパケットを上位プロトコルＡブロック１１４に伝達する。本発明がＭＭＴシステムに適用される場合には、ソースパケットは、ＭＭＴパケットであり、ＦＥＣリペアパケットは、リペアＦＥＣペイロードＩＤとリペアシンボルとを含むＭＭＴパケットである。
【００６６】
ＦＥＣ復号化ブロック１１３(又は制御部）は、送信器から受信されたパケットからＦＥＣコンフィギュレーション情報を取得し、ＦＥＣコンフィギュレーション情報に基づいて第２の受信シンボルブロックを構成し、第２のソースシンボルブロックを復元し、第２のソースシンボルブロックの復元に成功したら、第１の受信シンボルブロックを構成し、１つ以上の同一の長さを有するソースシンボルを含む第１のソースシンボルブロックを復元する。第１のソースシンボルブロックは、１つ以上のソースパケットを含むソースパケットブロックを使用して１つ以上の同一の長さを有するソースシンボルを含み、第１のソースシンボルブロック内の１つのソースシンボルは、１つ以上のシンボルエレメントを含む。第２のソースシンボルブロックは、ソースパケットブロックに含まれた少なくとも１つのソースパケットの長さに関する情報を含み得る。
【００６７】
図２は、本発明の一実施形態によるＭＭＴシステムにおけるアプリケーションレイヤーフォワードエラー訂正（ＡＬ−ＦＥＣ）アーキテクチャーを概略的に示す図である。
【００６８】
ＭＭＴアプリケーション２１０は、ＡＬ−ＦＥＣ保護で送信されるＭＭＴアセットを決定し、決定されたＭＭＴアセットをＭＭＴプロトコル２２０に提供する。また、ＭＭＴアプリケーション２１０は、ＡＬ−ＦＥＣ関連コンフィギュレーション情報（すなわち、ＦＥＣコンフィギュレーション情報）をＭＭＴ  ＦＥＣ方式２３０に提供する。
【００６９】
ＭＭＴプロトコル２２０は、受信されたアセットをＭＭＴペイロード(ＭＭＴＰｓ)にパケット化し、ＭＭＴパケットヘッダをＭＭＰＴｓに付加することによりソースパケットを生成し、所定数のソースパケットを有するソースパケットブロックをＭＭＴ  ＦＥＣ方式２３０に提供する。本発明の一実施形態において、ソースパケットは、後述するＦＥＣリペアパケットと多重化され、ユーザデータグラムプロトコル(UserDatagramProtocol：ＵＤＰ)のようなトランスポートレイヤー２５０を通してＩＰ２６０に送信され得る。
【００７０】
ＭＭＴ  ＦＥＣ方式２３０は、与えられたソースシンボルブロック生成方式でＭＭＴアプリケーション２１０から受信されたＦＥＣコンフィギュレーション情報に基づいて受信されたそれぞれのソースパケットブロックから第１のソースシンボルブロック及び第２のソースシンボルブロックを生成する。このとき、本発明の実施形態によるソースシンボルブロック生成方式は、ＦＥＣコンフィギュレーション情報で示される。ＭＭＴ  ＦＥＣ方式２３０は、ＦＥＣコンフィギュレーション情報が本発明の実施形態によるソースシンボルブロック生成方式を示す場合に、本発明の実施形態によるソースシンボルブロックを生成する。
【００７１】
ＦＥＣコンフィギュレーション情報は、個別のフォーマットを有するＭＭＴパケット又は個別のプロトコルで受信器に送信されてもよい。
【００７２】
第１のソースシンボルブロック及び第２のソースシンボルブロックを生成した後に、ＭＭＴ  ＦＥＣ方式２３０は、第１のソースシンボルブロック及び第２のソースシンボルブロックをＦＥＣ符号２４０に提供する。ＦＥＣ符号２４０は、第１のソースシンボルブロック及び第２のソースシンボルブロックから第１のリペアシンボルブロック及び第２のリペアシンボルブロックをそれぞれ生成し、第１のリペアシンボルブロック及び第２のリペアシンボルブロックをＭＭＴ  ＦＥＣ方式２３０に提供する。ＭＭＴ  ＦＥＣ方式２３０は、ＦＥＣ符号２４０から受信されたリペアシンボルとともにリペアＦＥＣペイロードＩＤを生成してＭＭＴプロトコル２２０に提供する。このとき、第２のリペアシンボルブロックに含まれるリペアシンボルは、ソースパケットブロックに含まれるソースパケットの長さに関する情報を復元するために使用される情報を含む。情報は、リペアＦＥＣペイロードＩＤの一部として含まれるか又は個別の構成要素として構成され、ＭＭＴプロトコル２２０に提供されてもよい。
【００７３】
ＭＭＴプロトコル２２０は、受信された第１のリペアシンボルブロックに含まれるリペアシンボルにリペアＦＥＣペイロードＩＤを付加し、ＭＭＴペイロードヘッダ及びＭＭＴパケットヘッダをさらに付加することによりＦＥＣリペアパケットを生成した後に、ＦＥＣリペアパケットをＵＤＰのようなトランスポートレイヤー２５０を通してＩＰ２６０に送信する。本発明の実施形態において、ＦＥＣパケット生成過程の間に付加されたデータユニットは、部分的に統合された形態で付加され得る。例えば、第２のリペアシンボルブロックのリペアシンボルがリペアＦＥＣペイロードＩＤの一部として含まれる場合に、第２のリペアシンボルに含まれる複数のシンボルブロックを付加する動作は、省略されてもよい。他の例において、ＭＭＴペイロードヘッダも省略されてもよい。
【００７４】
説明の便宜上、ソースパケットブロック単位でＦＥＣソースパケット及びＦＥＣリペアパケットが生成され送信されることを説明したが、実際のネットワーク環境では、ＭＭＴプロトコル２２０が生成されたソースパケットをＭＭＴ  ＦＥＣ方式２３０に提供すると同時にトランスポートレイヤー２５０に出力し、ＭＭＴ  ＦＥＣ方式２３０は、ソースパケットをその内部メモリに記憶させ、ソースパケットブロックの最後のソースパケットを受信した瞬間に、ソースパケットブロックから第１のソースシンボルブロック及び第２のソースシンボルブロックを生成し、その結果、ＦＥＣ符号２４０が第１のリペアシンボルブロック及び第２のリペアシンボルブロックを生成するようにし、生成されたリペアシンボルブロックに含まれるリペアシンボルをＦＥＣリペアペイロードＩＤとともにＭＭＴプロトコル２２０に提供することにより、ＦＥＣリペアパケットを生成した後に送信することが好ましい。
【００７５】
本発明の一実施形態による通信システムは、ソースパケットを他のソースパケットと区別するための情報をソースパケットのヘッダに含ませる。例えば、ＭＭＴパケットヘッダは、次のような３つのフィールドを含み得る。
【００７６】
packet_id（１６ビット）−このフィールドは、１つのアセットを他のものと識別するために使用することができる整数値である。このフィールドの値は、パケットが属しているアセットのasset_idから導出される。packet_idとasset_idとのマッピングは、シグナリングメッセージの一部分であるＭＭＴパッケージテーブルによりシグナリングされる。個別の値は、シグナリングメッセージ及びＦＥＣリペアフローに割り当てられる。packet_idは、配信セッションのライフタイムを通して固有であり、同一のＭＭＴ送信部により配信されるすべてのＭＭＴフローに対して固有である。ＡＬ−ＦＥＣの場合に、packet_idとＦＥＣリペアフローとの間のマッピングは、ＡＬ−ＦＥＣメッセージで提供される。
【００７７】
packet_sequence_number（３２ビット）：同一のpacket_idを有するパケットを識別するために使用する整数値。このフィールドの値は、任意の値から開始され、受信された各ＭＭＴＰパケットに対して１だけ増加する。最大値に到達した後に‘０’に戻る。
【００７８】
packet_counter（３２ビット）：ＭＭＴＰパケットをカウントするための整数値。そのpacket_id値に関係なくＭＭＴＰパケットが送信される場合に１だけ増加する。このフィールドは、任意の値から開始され、最大値に到達した後に‘０’に戻る。
【００７９】
ＦＥＣ方式は、後述するソースシンボル生成方式を含む複数のソースシンボル生成方式のうちの１つを選択し、選択されたソースシンボル生成方式に従って第１のソースシンボルブロックを構成し、第１のソースシンボルブロックのＦＥＣ符号化を実行する。このとき、ＦＥＣコンフィギュレーション情報及びＦＥＣペイロードＩＤは、使用されたソースシンボル生成方式を示す情報及びリペアシンボルの長さに関する情報を含む使用されたソースシンボル生成方式を受信器で実行するために必要とされる情報を含む。
【００８０】
図３は、本発明の一実施形態によるソースパケットブロックを示す図である。図３を参照すると、ソースパケットブロック３１０は、可変長を有するソースパケット３２０を含み、ソースパケット３２０のそれぞれは、パケットグループ化のためのpacket_idフィールド３２１と、同一のグループに属する(同一のpacket_idを有する)パケットを識別するためのpacket_sequence_numberフィールド３２２と、packet_idに関係なくパケットを識別するためのpacket_counterフィールド３２３とを含む。ソースパケット３２０は、上述した３つのフィールドに加えて、他の送信関連機能を実行するためのフィールドをＭＭＴパケットヘッダ内にさらに有するが、これは、本発明の要旨とは関連ないので、その詳細な説明を省略する。３つのフィールドのうちで、packet_idフィールド３２１とpacket_sequence_numberフィールド３２２だけでもパケットの識別が可能である。また、packet_counterフィールド３２３だけでもパケットを特定できるので、３つのフィールドのすべては、常に必要とされるのではない。
【００８１】
本発明の実施形態によると、図３に示すソースパケットブロック３１０内でソースパケット３２０の順序は、上述した３つのフィールドの値を使用して決定される。説明の便宜のために、ソースパケットブロック内のソースパケットの順序を決定する方法については後述する。
【００８２】
本発明の一実施形態によると、第１のソースシンボルブロックは、下記の方法で構成される。
【００８３】
ソースシンボルの長さがＴである場合に、第１のソースシンボルブロックは、Ｔ／ｍのサイズを有するｍ個の領域に分割された２次元配列として見なされる。ここで、ｍは、シンボルエレメントの個数を示す。Ｔがｍの倍数でない場合には、各領域は、［Ｔ／ｍ］＋１の長さを有する領域と［Ｔ／ｍ］の長さを有する領域とに分割される。その後に、必要な場合に、与えられたソースパケットは、付加情報が加えられた後に、各ソースパケットがシンボルサイズを超過しない方法で２次元アレイ内に順次に配列される。他の実施形態において、ｍが与えられる場合に、Ｔは、ｍの倍数であるように定義される。
【００８４】
各ソースパケットは、常にｍ個の領域が開始される行で列方向に配列され始めなければならず、付加情報が加えられた任意のソースパケットが配列される最後の行で対応するソースパケットの最後のデータが割り当てられている領域内の残りの部分には、常に０のような所定の値が割り当てられる。
【００８５】
システムの要求に従って配列されたソースパケットの間にＴ／ｍバイト以上のゼロパディングが適用される場合もあり得る。しかしながら、通常、ゼロパディング比率を最小化するために、最大ゼロパディングの長さは、Ｔ／ｍより小さく設定される。したがって、付加情報が加えられた１つのソースパケットが配列された後に配列されるソースパケットは、通常、ソースパケットが配列される最後の行に最後のデータが割り当てられている領域の次の領域の開始点から配列されてもよい。最後のデータが最後のｍ番目の領域に割り当てられている場合には、次のソースパケットは、次の行の１番目の領域で開始される。
【００８６】
図４は、Ｔ＝８であり、ｍ＝２に設定された場合に、長さがそれぞれ１３、６、１０、及び１４である４つのソースパケットを使用して第１のソースシンボルブロック４００を構成する例を示す図である。
【００８７】
図４において、第１のソースシンボルブロックのそれぞれのエントリーＢ［ｉ，ｊ］は、バイト単位データ、特に、（ｉ＋１）番目のソースパケットの（ｊ＋１）番目のバイトを示す。
【００８８】
第１のソースシンボルブロック４００において、各列は、１つのソースシンボルに対応する。分割されたそれぞれの領域で各ソースシンボルをＴ／ｍで細分化することによりシンボルエレメントが定義される場合には、第１のソースシンボルブロックの各ソースシンボルは、長さが４である２つのシンボルエレメントを含む。すなわち、第１のソースシンボルブロック４００は、７個のソースシンボル、言い換えれば、１４個のシンボルエレメントを含む。
【００８９】
Ｋ’個のソースパケットを有するソースパケットブロックに上述した第１のソースシンボルブロック構成方法を適用して、Ｋ個のソースシンボルを有する第１のソースシンボルブロックを構成すると仮定する。また、ソースパケットの最大長さが６５５３５（２１６−１）バイトであると仮定する。ＫがＫ’と同一であるか又は大きい場合には、すなわち、第１のソースシンボルブロックを構成するソースシンボルの個数がソースパケットブロックを構成するソースパケットの個数と同一であるか又は大きい場合に、本発明の一実施形態による第２のソースシンボルブロック構成方法は、以下のようになる。第２のソースシンボルブロックは、２バイトの長さをそれぞれ有するＫ個のソースシンボルを含む。１番目のソースシンボルからＫ番目のソースシンボルのそれぞれは、対応する順序のソースパケットの長さをその値として有し、Ｋ番目のソースシンボルの後ろのソースシンボルのそれぞれは、０の値を有する。
【００９０】
図５は、長さがそれぞれ１３、６、１０、及び１４である４つのソースパケットを使用して図４に示す第１のソースシンボルブロック４００を構成する場合の第２のソースシンボルブロックの例を示す図である。
【００９１】
上述した方法を通して生成された第２のソースシンボルブロックは、第１のソースシンボルブロックに含まれるシンボルの個数と同数のシンボルを含む。しかしながら、第２のソースシンボルブロックは、所定の値（０）を有するソースシンボルを含み、これは、ＦＥＣ符号の符号化率を減少させる。したがって、同一のＦＥＣ符号が使用される場合には、第２のソースシンボルブロックは、第１のソースシンボルブロックに比べてネットワークで発生するパケット損失に強い特性を有する。
【００９２】
本発明の実施形態において、送信器は、第１のソースシンボルブロックにＦＥＣ符号化を適用することにより第１のリペアシンボルブロックを生成し、第２のソースシンボルブロックにＦＥＣ符号化を適用することにより第２のリペアシンボルブロックを生成し、第１のリペアシンボルブロックの少なくとも1つのリペアシンボル及び第２のリペアシンボルブロックの少なくとも1つのリペアシンボルを含むＦＥＣリペアパケットをソースパケットとともに送信する。また、ＦＥＣリペアパケットは、リペアＦＥＣペイロードＩＤを含む。
【００９３】
リペアＦＥＣペイロードＩＤは、ソースパケットをソースパケットブロックに配列する順序により変わってもよい。本発明の実施形態において、予め約束された１つ以上のパケット配列方式のうちの１つを用いてパケットが配列され、使用されたパケット配列方式は、ＦＥＣコンフィギュレーション情報を通して受信器に示される。
【００９４】
本発明の実施形態によると、第１のパケット配列方式は、次のように行われる。第１のパケット配列方式において、ソースパケットは、packet_idフィールド３２１及びpacket_sequence_numberフィールド３２２を用いて配列される。より具体的には、同一のpacket_id値を有するソースパケットは、packet_sequence_number値が増加する順に配列され、packet_id値の順序は、ＦＥＣコンフィギュレーション情報を通して受信器に示される。
【００９５】
図６は、上述した第１のパケット配列方式に従って配列されたソースパケットブロック６００の例を示す図である。
【００９６】
図６を参照すると、ソースパケットブロック６００は、７個のソースパケット６１０を含み、各ソースパケット６１０は、packet_idフィールド６１１及びpacket_sequence_numberフィールド６１２をヘッダに含ませる。
【００９７】
本発明の実施形態による第２のパケット配列方式において、ソースパケットは、packet_counterフィールド３２３に基づいて配列される。より具体的には、ソースパケットは、packet_idフィールドに無関係にpacket_counterフィールドの値が増加する順に配列される。
【００９８】
図７は、上述した第２のパケット配列方式で配列されたソースパケットブロック７００の例を示す図である。図７を参照すると、ソースパケットブロック７００は、７個のソースパケット７１０を含み、それぞれのソースパケットは、packet_idフィールド７１１、packet_sequence_numberフィールド７１２、及びpacket_counterフィールド７１３をヘッダに含ませる。
【００９９】
ソースパケットブロック７００のソースパケットは、packet_idフィールド７１１に無関係にpacket_counterフィールド７１３の値が増加する順に配列される。
【０１００】
図８は、第１のパケット配列方式で使用されるリペアＦＥＣペイロードＩＤの例を示す図である。
【０１０１】
図８を参照すると、ＦＥＣソースフローがＮ個のpacket_idを有するソースパケットで構成される場合に、SP_start_seq_nr[i]８０１は、ｉ番目のpacket_idを有するソースパケットのうちでソースパケットブロックに配列される１番目のソースパケットのpacket_sequence_numberと同一の値を有し、SPB_length[i]８０２は、ソースパケットブロックに含まれたｉ番目のpacket_idを有するソースパケットの個数を示す。SSB_lengthフィールド８０３は、ソースパケットブロックに対応する第１のソースシンボルブロックのシンボルの個数を示す値を有し、RSB_lengthフィールド８０４は、第１のソースシンボルブロックを保護する第１のリペアシンボルブロックに含まれたリペアシンボルの個数を示す。RS_IDフィールド８０５は、リペアＦＥＣ  ＩＤを含むＦＥＣリペアパケットに含まれたリペアシンボルのＩＤを提供し、RS_LP（長さ保護のためのリペアシンボル）フィールド８０６は、第２のリペアシンボルブロックに属するリペアシンボルのうちでRS_IDフィールド８０５を使用して特定され得るリペアシンボルである。
【０１０２】
図９は、第２のパケット配列方式で使用されたリペアＦＥＣペイロードＩＤの例を示す図である。
【０１０３】
図９において、SP_start_counterフィールド９０１は、ソースパケットブロックのソースパケットのうちで、ソースパケットブロックに配列された１番目のソースパケットのpacket_count値と同一の値を有し、SPB_lengthフィールド９０２は、ソースパケットブロックに含まれたソースパケットの個数を示す。SSB_lengthフィールド９０３は、ソースパケットブロックに対応する第１のソースシンボルブロックのシンボルの個数を示し、RSB_lengthフィールド９０４は、第１のソースシンボルブロックを保護する第１のリペアシンボルブロックに含まれたリペアシンボルの個数を示す。RS_IDフィールド９０５は、リペアＦＥＣ  ＩＤを有するＦＥＣリペアパケットに含まれたリペアシンボルのＩＤを提供し、RS_LP（長さ保護のためのリペアシンボル）フィールド９０６は、第２のリペアシンボルブロックに属するリペアシンボルのうちでRS_IDフィールド９０５を使用して特定され得るリペアシンボルである。
【０１０４】
図８及び図９に示す実施形態において、それぞれのフィールドが固定された長さを有するとしても、リペアＦＥＣペイロードＩＤは、送信効率の増大のためにフィールドが可変長を有するように再構成され、これは、明白に本発明の範囲内にある。また、図８及び図９に示す実施形態において、リペアＦＥＣペイロードＩＤは、RS_LPフィールド８０６及び９０６に第２のリペアシンボルブロックに属するリペアシンボルのうちの１つのリペアシンボルを含ませるものと説明されたが、リペアＦＥＣペイロードＩＤを有するリペアＦＥＣパケットが第１のリペアシンボルブロックのＭ個のリペアシンボルを伝達する場合には、Ｍ個のRS_IDフィールドが存在する。このとき、Ｍは、ＦＥＣコンフィギュレーション情報を通して受信器に示される。
【０１０５】
また、図８及び図９に示す実施形態において、第２のリペアシンボルブロックのリペアシンボルがリペアＦＥＣペイロードＩＤの一部として説明されたが、全ＦＥＣリペアパケットの構造に関連して第２のリペアシンボルブロックのリペアシンボルが独立した構成要素として取り扱われることができることは自明である。
【０１０６】
上述した実施形態は、同一のＦＥＣ符号が第１のソースシンボルブロック及び第２のソースシンボルブロックの符号化のときに使用されるという仮定に基づく。しかしながら、実施形態によっては、異なるＦＥＣ符号を、第１のソースシンボルブロック及び第２のソースシンボルブロックの符号化のときに使用してもよい。このとき、ＦＥＣコンフィギュレーション情報は、２個のＦＥＣ符号に関する情報をすべて含まなければならず、ＦＥＣコンフィギュレーション情報の実施に従い異なるフォーマットを有する。
【０１０７】
図１０は、本発明の一実施形態によるＦＥＣ復号化ブロック１１３の動作を示すフローチャートである。
【０１０８】
ＦＥＣ復号化ブロック１１３(又は、制御部）は、ステップ１０１０において、ＦＥＣコンフィギュレーション情報、受信されたソースパケット、及び受信されたＦＥＣリペアパケットを使用して復号化を開始する。まず、ＦＥＣ復号化ブロック１１３(又は、制御部）は、ステップ１０２０において、ＦＥＣリペアパケットからリペアＦＥＣペイロードＩＤを抽出し、ステップ１０３０において、抽出されたリペアＦＥＣペイロードＩＤ及び受信されたソースパケットの長さに関する情報を使用して第２の受信シンボルブロックを構成する。ＦＥＣ復号化ブロック１１３(又は、制御部）は、ステップ１０４０において、第２の受信シンボルブロックにＦＥＣ復号化を実行することにより第２のソースシンボルブロックの復元を試みる。その後に、ＦＥＣ復号化ブロック１１３(又は、制御部）は、ステップ１０５０において、第２のソースシンボルブロックが完全に復元されたか否かを判定する。第２のソースシンボルブロックが完全に復元された場合には、ＦＥＣ復号化ブロック１１３(又は、制御部）は、損失したソースパケットを含むすべてのソースパケットの長さが分かる。したがって、ＦＥＣ復号化ブロック１１３(又は、制御部）は、ステップ１０６０において、第１の受信シンボルブロックを構成する。ステップ１０７０において、ＦＥＣ復号化ブロック１１３(又は、制御部）は、第１の受信シンボルブロックを使用してＦＥＣ符号の復号化を試みた後に、符号化ブロックの復元された部分から損失したソースパケットを抽出する。その後に、ＦＥＣ復号化ブロック１１３(又は、制御部）は、ステップ１０８０において、受信されたソースパケットとともに復元されたソースパケットを上位レイヤーに送信し、手順を終了する。他方、第２のソースシンボルブロックが完全には復元されなかった場合には、ＦＥＣ復号化ブロック１１３(又は、制御部）は、ステップ１０８０において、損失されたソースパケットの長さが分かるので、第１の受信シンボルブロックを構成せず、受信されたソースパケットだけを上位レイヤーに送信し、処理を終了する。
【０１０９】
図１１は、本発明の一実施形態によるＦＥＣ符号化ブロック１０２の動作を示すフローチャートである。
【０１１０】
ＦＥＣ符号化ブロック１０２(又は、制御部）は、ステップ１１０１において、１つ以上のソースパケットを含むソースパケットブロックを使用して１つ以上の同一の長さを有するソースシンボルを有する第１のソースシンボルブロックを構成する。１つのソースシンボルは、第１のソースシンボルブロックで１つ以上のシンボルエレメントを含む。
【０１１１】
ＦＥＣ符号化ブロック１１２(又は、制御部）は、ステップ１１０３において、第１のソースシンボルブロックに対して予め設定されているＦＥＣ方式に対応する第１のＦＥＣ符号化動作を実行する。
【０１１２】
ＦＥＣ符号化ブロック１１２(又は、制御部）は、ステップ１１０５において、ソースパケットブロックのそれぞれのソースパケットの長さに関する情報を含む第２のソースシンボルブロックを構成する。第２のソースシンボルブロックは、図５に示したソースシンボルを意味し、パディングシンボルを含み得る。
【０１１３】
ＦＥＣ符号化ブロック１１２(又は、制御部）は、ステップ１１０７において、第２のソースシンボルブロックに対して予め設定されているＦＥＣ方式に対応する第２のＦＥＣ符号化動作を実行する。
【０１１４】
以上、本発明を具体的な実施形態を参照して詳細に説明してきたが、本発明の範囲及び趣旨を逸脱することなく様々な変更が可能であるということは、当業者には明らかであり、本発明の範囲は、上述の実施形態に限定されるべきではなく、特許請求の範囲の記載及びこれと均等なものの範囲内で定められるべきである。
【０１１５】
このとき、フローチャートのブロック及びフローチャートの組み合せは、コンピュータプログラム指示により示され実行されることを当該技術分野では容易に理解できる。これらのコンピュータプログラム指示は、汎用コンピュータ、特定の用途のコンピュータ、又はプログラム可能なデータ処理装置のプロセッサに格納できるので、コンピュータ又はプログラム可能なデータ処理装置のプロセッサを通して実行されるその指示がフローチャートで説明された機能を実行する手段を生成する。これらのコンピュータプログラム指示は、特定の方式で機能を実現するためにコンピュータ又はプログラム可能なデータ処理装置を指向できるコンピュータにて使用可能な又はコンピュータにて読み取り可能なメモリに記憶できるので、そのコンピュータにて使用可能な又はコンピュータにて読み取り可能なメモリに記憶される指示は、フローチャートで説明された機能を実行する指示手段を含む製造の品目を生産することも可能である。コンピュータプログラム指示は、コンピュータ又はプログラム可能なデータ処理装置上に搭載できるので、コンピュータ又はプログラム可能なデータ処理装置上で一連の動作ステップが実行され、コンピュータで実行されるプロセスを生成してコンピュータ又はプログラム可能なデータ処理装置を実行する指示は、フローチャートで説明された機能を実行するためのステップを提供することも可能である。
【０１１６】
また、フローチャートの各ブロックは、特定の論理的な機能を実行するための１つ以上の実行可能な指示を含むモジュール、セグメント、又はコードの一部を示すことができる。幾つかの場合において、ブロックにより説明された機能は、リストされた順序とは異なる順序で実行され得る。例えば、連続して図示されている２つのブロックは、実質に同時に実行されることも可能であり、又はそのブロックが対応する機能により逆順に実行されることも可能である。
【０１１７】
本実施形態で使用される用語“部”、“モジュール”などは、機能又は動作を実行できるソフトウェアコンポーネントまたはＦＰＧＡ又はＡＳＩＣのようなハードウェアコンポーネントを意味する。しかしながら、“部”などは、ソフトウェア又はハードウェアに限定されるのではない。“部”は、アドレッシングできる記憶媒体にあるように構成されてもよく、１つ又はそれ以上のプロセッサを再生させるように構成されてもよい。したがって、例えば、“部”は、ソフトウェアコンポーネント、オブジェクト指向ソフトウェアコンポーネント、クラスコンポーネント、及びタスクコンポーネントのようなコンポーネント、プロセス、関数、属性、プロシージャ、サブルーチン、プログラムコードセグメント、ドライバ、ファームウェア、マイクロコード、回路、データ、データベース、データ構造、テーブル、アレイ、又は変数を意味する。コンポーネント及び“部”により提供される機能は、より小さな数のコンポーネント及び“部”に結合されるか又は追加のコンポーネント及び“部”にさらに分離されることができる。コンポーネント及び“部”は、デバイス又は保安マルチメディアカード内のデバイス又は１つ又はそれ以上のプロセッサを駆動させるように構成されてもよい。
【０１１８】
本発明の範囲及び趣旨を逸脱することなく、ここに説明する実施形態の様々な変更及び修正が可能であるということは、当該技術分野における通常の知識を有する者には明らかである。したがって、上述した実施形態は、但し例示に過ぎず、本発明の範囲を限定することと解釈されてはいけない。本発明の範囲は、上述の実施形態に限定されるべきではなく、特許請求の範囲の記載及びこれと均等なものの範囲内で定められるべきである。
【０１１９】
本発明の好適な実施形態は、明細書及び添付図面に基づいて開示されている。特定の用語が使用されるが、これは、本発明を容易に説明し、本発明のさらなる理解を助けるために一般的な意味で使用され、本発明の範囲を限定するのではない。したがって、本発明の範囲及び趣旨を逸脱することなく、ここに説明された実施形態の様々な変更及び変形が可能であるということは、当該技術分野における通常の知識を有する者には明らかである。
【図１】
0006511472.tif 000002
【図２】
0006511472.tif 000003
【図３】
0006511472.tif 000004
【図４】
0006511472.tif 000005
【図５】
0006511472.tif 000006
【図６】
0006511472.tif 000007
【図７】
0006511472.tif 000008
【図８】
0006511472.tif 000009
【図９】
0006511472.tif 000010
【図１０】
0006511472.tif 000011
【図１１】
0006511472.tif 000012