(57)【要約】  放送及び通信システムにおけるパケット送受信方法及び装置を提供する。この方法は、あらかじめ設定されたシンボルサイズ（Ｔ）の幅を有する２次元アレイの各行に対応する各シンボルを所定数（ｍ）の領域に分割するステップと、２次元アレイの１番目の行の１番目の列からシンボルサイズＴ内で送信されるソースパケットを順次に配列するステップと、１つのソースパケットが配列された最後の行で、ソースパケットの最後のデータが割り当てられている領域内の残りの部分を所定の値に設定するステップと、ソースパケットが配列された後、次のソースパケットをソースパケットが配列された最後の行で最後のデータが割り当てられた領域の次の領域の開始点から配列するステップと、ソースパケットのすべてを２次元アレイに配列することによりソースブロックを構成するステップと、ソースブロックの順方向誤り訂正（ＦＥＣ）符号化を実行するステップと、順方向誤り訂正符号化が実行されたソースブロックを送信するステップとを有する。
2015520990.tif 000002
【特許請求の範囲】
【請求項１】
放送及び通信システムにおけるパケット送信方法であって、
あらかじめ設定されたシンボルサイズ（Ｔ）の幅を有する２次元アレイの各行に対応する各シンボルを所定数（ｍ）の領域に分割するステップと、
前記２次元アレイの１番目の行の１番目の列から、前記シンボルサイズＴ内で送信されるソースパケットを前記２次元アレイに順次に配列するステップと、
１つのソースパケットが配列された最後の行で、前記ソースパケットの最後のデータが割り当てられている領域内の残りの部分を所定の値に設定するステップと、
前記ソースパケットが配列された後、次のソースパケットを前記ソースパケットが配列された最後の行で、前記最後のデータが割り当てられた領域の次の領域の開始点から配列するステップと、
前記ソースパケットのすべてを前記２次元アレイに配列することによりソースブロックを構成するステップと、
前記ソースブロックの順方向誤り訂正（ＦＥＣ）符号化を実行するステップと、
前記順方向誤り訂正符号化が実行されたソースブロックを送信するステップと
を有することを特徴とするパケット送信方法。
【請求項２】
前記２次元アレイの各行は、Ｔ／ｍ個の列をそれぞれ有するｍ個の領域に分割することを特徴とする請求項１に記載のパケット送信方法。
【請求項３】
前記Ｔ及び前記ｍに関する情報を順方向誤り訂正オブジェクト送信情報（ＦＥＣ  ＯＴＩ）を通して送信するステップをさらに有することを特徴とする請求項２に記載のパケット送信方法。
【請求項４】
前記ソースパケットのそれぞれは、前記ソースブロックを識別するソースブロック番号（ＳＢＮ）と、対応するソースパケットのシンボルを識別する符号化シンボル識別子（ＥＳＩ）とを含むことを特徴とする請求項１に記載のパケット送信方法。
【請求項５】
前記符号化シンボル識別子は、ソースパケットごとに領域の個数だけ増加するように設定されることを特徴とする請求項４に記載のパケット送信方法。
【請求項６】
前記ソースパケットのそれぞれは、前記領域の所定数（ｍ）を示す領域の個数（ＮＯＲ）、前記符号化シンボル識別子で示される行内で対応するソースパケットの開始領域を示すパケット開始位置（ＰＳＰ）、及び前記ソースブロック内の総行の個数を示すソースブロック長さ（ＳＢＬ）の中の少なくとも１つをさらに含むことを特徴とする請求項４に記載のパケット送信方法。
【請求項７】
前記ソースブロックの順方向誤り訂正符号化により生成されたリペアパケットを送信するステップをさらに有し、
前記リペアパケットのそれぞれは、前記ソースブロックを識別するソースブロック番号（ＳＢＮ）と、前記リペアパケットに対応するソースパケットのシンボルを識別する符号化シンボル識別子（ＥＳＩ）とを含むことを特徴とする請求項１に記載のパケット送信方法。
【請求項８】
前記リペアパケットのそれぞれは、前記領域の所定数（ｍ）を示す領域の個数（ＮＯＲ）、前記符号化シンボル識別子で示される行内で対応するソースパケットの開始領域を示すパケット開始位置（ＰＳＰ）、及び前記ソースブロック内の総行の個数を示すソースブロック長さ（ＳＢＬ）の中の少なくとも１つをさらに含むことを特徴とする請求項７に記載のパケット送信方法。
【請求項９】
放送及び通信システムにおけるパケット送信装置であって、
請求項１乃至請求項８のうちのいずれか１つの方法を実行するように構成されることを特徴とするパケット送信装置。
【請求項１０】
放送及び通信システムにおけるパケット受信方法であって、
ソースブロックで受信されたデータを解析するステップと、
前記ソースブロックの順方向誤り訂正（ＦＥＣ）復号化を実行するステップとを有し、
前記ソースブロックは、
あらかじめ設定されたシンボルサイズ（Ｔ）の幅を有する２次元アレイの各行に対応する各シンボルを所定数（ｍ）の領域に分割し、
前記２次元アレイの１番目の行の１番目の列から前記シンボルサイズＴ内で送信されるソースパケットを前記２次元アレイに順次に配列し、
１つのソースパケットが配列された最後の行で、前記ソースパケットの最後のデータが割り当てられている領域内の残りの部分を所定の値に設定し、
前記ソースパケットが配列された後、次のソースパケットを前記ソースパケットが配列された最後の行で前記最後のデータが割り当てられた領域の次の領域の開始点から配列し、
前記ソースパケットのすべてを前記２次元アレイに配列することにより前記ソースブロックを構成することを特徴とするパケット受信方法。
【請求項１１】
前記２次元アレイの各行は、Ｔ／ｍ個の列をそれぞれ有するｍ個の領域に分割されることを特徴とする請求項１０に記載のパケット受信方法。
【請求項１２】
前記Ｔ及び前記ｍに関する情報を順方向誤り訂正オブジェクト送信情報（ＦＥＣ  ＯＴＩ）を通して受信するステップをさらに有することを特徴とする請求項１１に記載のパケット受信方法。
【請求項１３】
前記ソースパケットのそれぞれは、前記ソースブロックを識別するソースブロック番号（ＳＢＮ）と、対応するソースパケットのシンボルを識別する符号化シンボル識別子（ＥＳＩ）とを含むことを特徴とする請求項１０に記載のパケット受信方法。
【請求項１４】
前記符号化シンボル識別子は、ソースパケットごとに領域の個数だけ増加するように設定されることを特徴とする請求項１３に記載のパケット受信方法。
【請求項１５】
前記ソースパケットのそれぞれは、前記領域の所定数（ｍ）を示す領域の個数（ＮＯＲ）、前記符号化シンボル識別子で示される行内で対応するソースパケットの開始領域を示すパケット開始位置（ＰＳＰ）、及び前記ソースブロック内の総行の個数を示すソースブロック長さ（ＳＢＬ）の中の少なくとも１つをさらに含むことを特徴とする請求項１３に記載のパケット受信方法。
【請求項１６】
前記ソースブロックの順方向誤り訂正符号化により生成されたリペアパケットを受信するステップをさらに有し、
前記リペアパケットのそれぞれは、前記ソースブロックを識別するソースブロック番号（ＳＢＮ）と、前記リペアパケットに対応するソースパケットのシンボルを識別する符号化シンボル識別子（ＥＳＩ）とを含むことを特徴とする請求項１０に記載のパケット受信方法。
【請求項１７】
前記リペアパケットのそれぞれは、前記領域の所定数（ｍ）を示す領域の個数（ＮＯＲ）、前記符号化シンボル識別子で示される行内で対応するソースパケットの開始領域を示すパケット開始位置（ＰＳＰ）、及び前記ソースブロック内の総行の個数を示すソースブロック長さ（ＳＢＬ）の中の少なくとも１つをさらに含むことを特徴とする請求項１６に記載のパケット受信方法。
【請求項１８】
放送及び通信システムにおけるパケット受信装置であって、
請求項１０乃至請求項１７のうちのいずれか１つの方法を実行するように構成されることを特徴とするパケット受信装置。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、放送又は通信システムにおけるデータの送受信に関し、特に、チャネル又はネットワークを通してデータの損失が発生する時にデータを効率的に復元するための装置及び方法に関するものである。
【背景技術】
【０００２】
最近の放送及び通信環境において、様々なコンテンツの増加及び高解像度（High Definition：ＨＤ）コンテンツ及び超高解像度（Ultra High Definition：ＵＨＤ）コンテンツのような高容量コンテンツの増加の結果として、ネットワーク上でデータ輻輳（data Congestion）がさらに悪化している。結果的に、送信器（Sender）（例えば、ホストＡ）により送信されたコンテンツは、受信器（Receiver）（例えば、ホストＢ）に正常に配信されず、コンテンツの一部は、経路上で損失される状況が発生する。多くの場合に、データは、パケット単位で送信されるために、データ損失は、パケット単位で発生する。したがって、受信器は、ネットワーク上のデータ損失によりパケットを受信できないために、損失されたパケットと関連したデータを認識できない。その結果、オーディオ信号品質劣化、動画像画質劣化、動画像クラック、字幕欠落、ファイル損失などのような様々な形態でユーザの不便さをもたらす。このような理由で、ネットワークを通して送信する間に発生したデータ損失を復元するための技術が必要である。
【０００３】
ネットワークを通してデータが損失された時に、受信器で損失されたデータの復元をサポートする方法の中の１つは、ソースパケットと呼ばれる様々な長さを有する所定数のデータパケットでソースブロックを構成し、順方向誤り訂正（Forward Error Correction：ＦＥＣ）符号化によりパリティデータ又はリペアパケット（Repair packet）のようなリペア情報をソースブロックに付加する。受信器で損失されたデータがある場合に、リペア情報を用いてデータの復号（decoding）を実行する。
【０００４】
このとき、リペア情報が加えられたそれぞれのソースパケットは、所望する長さを有しないためにゼロパディング（zero padding）され得る。これは、従来、構成されたソースブロックがパケットの長さに従う相当の量のゼロパディングを含む可能性が高いことを意味する。ゼロパディングされたデータが送信器で送信しない無意味なデータであるが、ソースブロックを構成するシンボルの個数の増加に影響を及ぼし、パリティデータの生成に関連する。したがって、ゼロパディングされたデータは、実際には、不必要な情報に対するパリティデータの生成及び送信を引き起こす。
【０００５】
このような問題点を減少させるためには、ソースパケットの所望する長さを短縮させることにより相対的にゼロパディングの量を減少させることができる。しかしながら、ソースブロックを構成するシンボルの個数が大きく増加するために、非常に長い長さを有するＦＥＣ符号が必要とされる。システムに使用可能なＦＥＣ符号の長さが限定され、符号の長さが長くなるほど最大ログ尤度（maximum log-likelihood：ＭＬ）復号を行う時複雑度が大きく増加するために、復号待機時間（latency）が長くなるおそれがある。
【０００６】
したがって、ゼロパディングされたデータを減少させることにより符号化シンボルの個数を減少させ、誤り訂正能力を向上させることができる効率的なソースブロックを構成する方法に対する必要性が高まっている。
【発明の概要】
【発明が解決しようとする課題】
【０００７】
本発明は、上述した課題もしくは不都合な点を解決し、少なくとも以下に示す優位性を提供する。すなわち、本発明の目的は、放送又は通信システムにおけるパケットデータを送受信するための方法及び装置を提供することにある。
【０００８】
本発明の別の目的は、放送又は通信システムにおけるデータ損失が発生する時にデータを効率的に復元するための方法及び装置を提供することにある。
【０００９】
本発明のさらに別の目的は、放送又は通信システムにおけるゼロパディングデータの量を減少させつつ誤り訂正能力を改善できるより効率的にソースブロックを構成するための方法及び装置を提供することにある。
【課題を解決するための手段】
【００１０】
上記のような目的を達成するために、本発明の一態様によれば、放送及び通信システムにおけるパケット送信方法を提供する。この方法は、あらかじめ設定されたシンボルサイズ（Ｔ）の幅を有する２次元アレイの各行に対応する各シンボルを所定数（ｍ）の領域に分割するステップと、２次元アレイの１番目の行の１番目の列からシンボルサイズＴ内で送信されるソースパケットを順次に配列するステップと、１つのソースパケットが配列された最後の行で、ソースパケットの最後のデータが割り当てられている領域内の残りの部分を所定の値に設定するステップと、ソースパケットが配列された後、次のソースパケットをソースパケットが配列された最後の行で最後のデータが割り当てられた領域の次の領域の開始点から配列するステップと、ソースパケットのすべてを２次元アレイに配列することによりソースブロックを構成するステップと、ソースブロックの順方向誤り訂正（ＦＥＣ）符号化を実行するステップと、順方向誤り訂正符号化が実行されたソースブロックを送信するステップとを含むことを特徴とする。
【００１１】
本発明の別の態様によれば、放送及び通信システムにおけるパケット送信装置を提供する。この装置は、あらかじめ設定されたシンボルサイズ（Ｔ）の幅を有する２次元アレイの各行に対応する各シンボルを所定数（ｍ）の領域に分割するように構成され、２次元アレイの１番目の行の１番目の列からシンボルサイズＴ内で送信されるソースパケットを順次に配列し、１つのソースパケットが配列された最後の行で、ソースパケットの最後のデータが割り当てられている領域内の残りの部分を所定の値に設定し、ソースパケットが配列された後、次のソースパケットをソースパケットが配列された最後の行で最後のデータが割り当てられた領域の次の領域の開始点から配列し、ソースパケットのすべてを２次元アレイに配列することによりソースブロックを構成するソースブロック構成器と、ソースブロックの順方向誤り訂正（ＦＥＣ）符号化を実行し、順方向誤り訂正符号化が実行されたソースブロックを送信するＦＥＣ符号化器とを含むことを特徴とする。
【００１２】
本発明のさらに別の態様によれば、放送及び通信システムにおけるパケット受信方法を提供する。この方法は、ソースブロックで受信されたデータを解析するステップと、ソースブロックの順方向誤り訂正（ＦＥＣ）復号化を実行するステップとを含む。ソースブロックは、あらかじめ設定されたシンボルサイズ（Ｔ）の幅を有する２次元アレイの各行に対応する各シンボルを所定数（ｍ）の領域に分割し、２次元アレイの１番目の行の１番目の列からシンボルサイズＴ内で送信されるソースパケットを２次元アレイに順次に配列し、１つのソースパケットが配列された最後の行で、ソースパケットの最後のデータが割り当てられている領域内の残りの部分を所定の値に設定し、ソースパケットが配列された後、次のソースパケットをソースパケットが配列された最後の行で最後のデータが割り当てられた領域の次の領域の開始点から配列し、ソースパケットのすべてを２次元アレイに配列することによりソースブロックを構成することを特徴とする。
【００１３】
本発明のさらなる別の態様によれば、放送及び通信システムにおけるパケット受信装置を提供する。この装置は、ソースブロックで受信されたデータを解析するソースブロック解析器と、ソースブロックの順方向誤り訂正（ＦＥＣ）復号化を実行するＦＥＣ復号化器とを含む。ソースブロックは、あらかじめ設定されたシンボルサイズ（Ｔ）の幅を有する２次元アレイの各行に対応する各シンボルを所定数（ｍ）の領域に分割し、２次元アレイの１番目の行の１番目の列からシンボルサイズＴ内で送信されるソースパケットを２次元アレイに順次に配列し、１つのソースパケットが配列された最後の行で、ソースパケットの最後のデータが割り当てられている領域内の残りの部分を所定の値に設定し、ソースパケットが配列された後、次のソースパケットをソースパケットが配列された最後の行で最後のデータが割り当てられた領域の次の領域の開始点から配列し、ソースパケットのすべてを２次元アレイに配列することによりソースブロックを構成することを特徴とする。
【００１４】
本発明の他の目的、利点、及び顕著な特徴は、添付の図面及び本発明の実施形態からなされた以下の詳細な説明から、この分野の当業者に明確になるはずである。
【００１５】
本発明の実施形態の上述した及び他の様相、特徴、及び利点は、以下の添付図面が併用された後述の詳細な説明から、より一層明らかになるだろう。
【図面の簡単な説明】
【００１６】
【図１】本発明の一実施形態による送信器及び受信器の構造を示すブロック図である。
【図２】本発明の一実施形態による一般的なソースブロックの構成を示す図である。
【図３Ａ】本発明の一実施形態によるソースブロックの構成を示す図である。
【図３Ｂ】本発明の一実施形態によるソースブロックの構成を示す図である。
【図４】本発明の一実施形態によるソースパケット及びリペアパケットに付加されるシグナリング情報を示す図である。
【図５】本発明の一実施形態によるソースパケットに付加されるシグナリング情報を示す図である。
【図６】本発明の一実施形態によるリペアパケットに付加されるシグナリング情報を示す図である。
【図７】本発明の他の実施形態によるソースパケットに付加されるシグナリング情報を示す図である。
【図８】本発明のまた他の実施形態によるソースパケットに付加されるシグナリング情報を示す図である。
【図９】本発明の一実施形態によるソースブロックの構成を示す図である。
【図１０Ａ】本発明の一実施形態による順方向誤り訂正（ＦＥＣ）オブジェクト送信情報（ＯＴＩ）を示す図である。
【図１０Ｂ】本発明の一実施形態による順方向誤り訂正（ＦＥＣ）オブジェクト送信情報（ＯＴＩ）を示す図である。
【図１１】本発明の一実施形態によるシグナリング情報の１つのセットを示す図である。
【図１２】本発明の一実施形態によるシグナリング情報の１つのセットを示す図である。
【図１３Ａ】本発明の一実施形態によるＦＥＣ  ＯＴＩの構成を示す図である。
【図１３Ｂ】本発明の一実施形態によるＦＥＣ  ＯＴＩの構成を示す図である。
【発明を実施するための形態】
【００１７】
図面中、同一の図面参照符号が同一の構成要素、特性、又は構造を意味することは、容易に理解できるであろう。
【００１８】
添付の図面を参照した下記の説明は、特許請求の範囲の記載及びこれと均等なものの範囲内で定められるような本発明の実施形態の包括的な理解を助けるために提供され、この理解を助けるための様々な特定の詳細を含むが、単なる実施形態にすぎない。従って、本発明の範囲及び趣旨を逸脱することなく、ここに説明した実施形態の様々な変更及び修正が可能であるということは、当該技術分野における通常の知識を有する者には明らかであろう。また、明瞭性と簡潔性の観点から、当業者に良く知られている機能や構成に関する具体的な説明を省略する。
【００１９】
以下の説明及び特許請求の範囲で使用する用語及び単語は、辞典的意味に限定されるものではなく、本発明の理解を明確且つ一貫性があるようにするために使用される。従って、本発明の実施形態の説明が単に実例を提供するためのものであって、特許請求の範囲とこれと均等なものに基づいて定義される発明をさらに限定する目的で提供されるものでないことは、本発明の技術分野における通常の知識を持つ者には明らかであろう。
【００２０】
本願明細書に記載の各要素は、文脈中に特に明示しない限り、複数形を含むことは、当業者には理解できるであろう。従って、例えば、“コンポーネント表面（a component surface）”との記載は、１つ又は複数の表面を含む。
【００２１】
“実質的に(substantially)”という用語は、提示された特徴、パラメータ、又は値が正確に設定される必要はないが、許容誤差、測定誤り、測定精度限界及び当業者に知られているか、あるいは当業者によって実験なしに得られる要素を含む偏差又は変化が、これら特性が提供しようとする効果を排除しない範囲内で発生することを意味する。
【００２２】
本発明の実施形態は、上述した本発明の技術的な側面を達成するために提供されるのであろう。本発明の実施形態の具現において、定義されているエンティティは、同一の名称を有し得、これらが本発明の範囲を限定するのではない。したがって、本発明の実施形態は、類似した技術的背景を有する任意のシステムにおいても同一であるか又は容易な変更で具現されることができる。
【００２３】
本発明の実施形態は、ネットワークを通して高品質（ＨＤ）コンテンツ又は超高品質（ＵＨＤ）コンテンツのような高容量コンテンツだけでなく、映像会議／通話などのような様々なマルチメディアサービスを送受信できる携帯電話、ＴＶ、コンピュータ、電子黒板、タブレット、及び電子ブックなどのすべての電子デバイスでデータパケットの損失を効率的に復元する方法を提案する。特に、ＦＥＣをデータパケットに適用する時にソースブロックを効率的に構成することにより復号性能を改善するか又は送信効率（transmission efficiency）を高めることができる方法を提案する。本明細書において、具体的なＦＥＣ符号化方法について言及していないが、本発明は、リードソロモン（Reed-Solomon：ＲＳ）符号、低密度パリティチェック（Low Density Parity Check：ＬＤＰＣ）符号、ターボ符号、ラプター（Raptor）符号、ラプターＱ（Raptor Q）符号、ＸＯＲ（Single Parity-Check Code）、ｐｒｏ−ＭＰＥＧ（Moving Picture Experts Group）ＦＥＣ符号などの特定のＦＥＣ符号化方式に限定されないことに留意すべきである。
【００２４】
図１は、本発明の一実施形態による送信器及び受信器の構造を示すブロック図である。
【００２５】
図１を参照すると、送信器１００は、ソースブロック構成器１０２及びＦＥＣ符号化器１０３を含む。ソースブロック構成器１０２は、ソースパケット１０１と呼ばれる可変長さをそれぞれ有する所定数のデータパケットでソースブロックを構成する。ＦＥＣ符号化器１０３は、ＦＥＣ符号化をソースブロックに適用することによりパリティデータ又はリペアパケットのようなリペア情報１０４を付加した後に、このソースブロックを送信する。
【００２６】
受信器１１０は、ソースブロック解析器１１２及びＦＥＣ復号化器１１３を含む。ソースブロック解析器１１２は、ソースブロックで受信されたデータ１１１をリペアブロックが付加されたソースシンボルに区分する。ＦＥＣ復号化器１１３は、ソースシンボルに対するＦＥＣ復号化を実行することによりソースパケット１１４を復元する。ソースブロック解析器１１２は、データ１１１とともに又は個別に受信されたシグナリング情報１１５を用いて損失されたデータを復元する。
【００２７】
図２は、本発明の一実施形態による一般的なソースブロックの構成を示す図である。
【００２８】
図２を参照すると、与えられたソースパケットは、所定の幅Ｔを有する２次元アレイに順次に配列される。この配列の各行は、シンボルであり、Ｔは、シンボルサイズである。このシンボルサイズは、通常、バイト（byte）又はビット（bit）単位で表現される。通常、ＦＥＣは、シンボルに基づいて適用される。
【００２９】
ソースブロック構成器１０２は、フロー識別子（ＩＤ）２０１及びパケット長さ情報２０２をそれぞれのソースパケット２０３に付加した後に、１番目の行（row）の１番目の列からシンボルサイズＴ内で順次に配列する。ここで、特別な言及がない場合には、パケット長さ情報は、通常、バイト単位で表現される。
【００３０】
付加情報２０１及び２０２が付加されたすべてのそれぞれのソースパケット２０３は、常に各行の１番目の列から順次に配列される。付加情報２０１及び２０２を有するソースパケットの長さがシンボルサイズＴの倍数でない場合には、ゼロパディング２０４で示されるように、ソースパケットを有する最後の行でソースパケットのデータが配置された後の残りの部分は、すべて０の値でパディングされる。与えられたソースパケット２０３が上記のような方法ですべて配列される場合に、Ｋ個の行を有する配列をソースブロック２０６と称する。
【００３１】
ソースブロック２０６内のＫ個の行は、ＦＥＣ符号化を適用するためのＫ個のソースシンボルと見なされる。Ｋ個のソースシンボルにＦＥＣ符号化を適用することによりリペアシンボル（例えば、パリティシンボル）２０５又は２０７を生成する。このソースシンボル及びリペアシンボルを符号化シンボルと通称する。
【００３２】
以上のように、ソースブロックを構成する場合には、ゼロパディングの長さを増加させ得る。したがって、本発明の実施形態は、ゼロパディングデータの量を減少させつつ誤り訂正能力を改善するための効率的なソースブロックの構成方法を提供する。
【００３３】
図３Ａ及び図３Ｂは、本発明の一実施形態によるソースブロックの構成を示す図である。
【００３４】
図３Ａを参照すると、ソースブロック構成器１０２は、シンボルサイズＴを有する２次元アレイの列をシンボル単位でｍ個の領域に分割する。図３Ａに示す例において、ｍ＝４である。Ｔがｍの倍数ではない場合に、ｍ個の領域は、［Ｔ／ｍ］＋１個の列をそれぞれ有する領域と［Ｔ／ｍ］個の列をそれぞれ有する領域とを含む。ここで、［Ａ］は、任意の実数Ａより小さいか又は同一の最大整数を示す。［Ｔ／ｍ］＋１個の列をそれぞれ有する領域及び［Ｔ／ｍ］個の列をそれぞれ有する領域は、事前に定められた規則に従って、送信器１００と受信器１１０との間であらかじめ定義されるか又はそれぞれの領域に対する列の個数で示され得る。事前に定められた規則は、ＴをＭで割った残りがｎ（ｎ＜ｍ）である場合に、はじめのｎ個の領域は、［Ｔ／ｍ］＋１個の列を有し、残りの（ｍ−１）個の領域のそれぞれは、［Ｔ／ｍ］個の列を有し得る。また、上記した規則的な領域の分割の他にも、各領域内の列の個数は、送信器１００と受信器１１０との間の相互約束に従って異なって設定され得る。
【００３５】
必要であれば、フローＩＤ（例えば、ユーザデータグラムプロトコル（User Datagram Protocol：ＵＤＰ）フローＩＤ）のようなフィーチャー情報３０１及びパケット長さ情報３０２は、各ソースパケットに付加される。情報３０１及び３０２を有するソースパケットは、１番目の行の１番目の列からシンボルサイズＴ内で順次に配列される。
【００３６】
このとき、付加情報が付加された任意のソースパケットが配列された最後の行で対応するソースパケットの最後のデータが割り当てられている領域内の残りの部分は、所定の値で満たされる。この所定の値は、説明の便宜上、０の値に設定され得るが、これに限定されない。例えば、図３Ａにおいて、１番目のパケットの最後のデータが４個の領域の中で２番目の領域に割り当てられているので、２番目の領域の残りの部分３０５は、０の値で満たされる。
【００３７】
また、付加情報を有する１つのソースパケットが配列された後に、次のソースパケットは、前のソースパケットを有する最後の行で前のソースパケットの最後のデータを有する領域のその次の領域の開始点から配列される。言い換えれば、すべてのソースパケットは、任意の領域の開始点から配列される。例えば、２番目のソースパケットは、ゼロパディングされたデータ３０５の次の３番目の領域の開始点から配列される。４番目のソースパケットのゼロパディングされたデータ３０６のように、ゼロパディングされたデータが最後の領域に割り当てられる場合、５番目のソースパケットは、次の行のはじめの領域から開始される。
【００３８】
与えられたソースパケットのすべてが上記のような方法で配列される場合に、完成された配列３０７は、ソースブロックである。
【００３９】
図３Ｂは、Ｔ＝１６であり、ｍ＝２である場合に、長さ１８、３２、５９、２０、及び２４を有する５個のユーザデータグラムプロトコル（ＵＤＰ）パケットで構成されるソースブロック３０８を示す図である。最初の２個のパケットは、ＵＤＰフロー０から生成され、３番目及び４番目のパケットは、ＵＤＰフロー１から生成され、５番目のパケットは、ＵＤＰフロー２から生成される。図３Ｂに示すように、ＵＤＰフローＩＤ及びＵＤＰパケット長さ情報をそれぞれのソースパケットに付加することによりソースブロックを構成する。ここで、ソースブロック内のそれぞれのエントリーＢｉ，ｊは、バイト単位のデータであり、（ｉ＋１）番目のＵＤＰパケットの（ｊ＋１）番目のバイトを意味する。
【００４０】
ソースブロック３０８の各行は、１個のソースシンボルに対応する。各ソースシンボルが分割された領域に従ってＴ／ｍだけ細分化され、細分化されたフラグメントのそれぞれがサブシンボル（細分化されたシンボル（sub-divided symbol））又はシンボル単位（symbol element）として定義される場合に、各ソースシンボルは、参照符号３０９で示すように、ソースブロック３０８内の長さが８である２個のサブシンボルを含む。したがって、ソースブロック３０８は、１２個のソースシンボル、すなわち、２４個のサブシンボル３０９を含む。
【００４１】
次いで、本発明の実施形態によるソースブロックの最後の行（又は最後のソースシンボル）の構成の実施形態について説明する。
【００４２】
ソースブロックがソースパケットで構成される場合に、ソースブロックの長さＫは、システムにおいて、処理時間（processing time）又はメモリ容量の制限により限定され得る。例えば、ソースブロックの最大許容長さがＫｍａｘである場合に、１つのソースブロックに含まれる最大のデータサイズがＴ×Ｋｍａｘバイトであることは自明である。しかしながら、ソースパケットを配列する間にゼロパディングが発生し得るので、このソースブロックの実際のデータは、Ｔ×Ｋｍａｘバイトより小さい場合がある。
【００４３】
ソースブロックが、ソースブロック構成器に入力された特定のパケットの付加により許容される最大ソースブロック長さＫｍａｘより多くの数のソースシンボルを必要とする場合に、入力パケットは、ソースブロックから除外される。すなわち、最大データ容量Ｔ×Ｋｍａｘを超過しないソースブロックが、最大データサイズ内のソースパケットを順次に割り当てることにより構成される。
【００４４】
この場合に、ソースブロックの最後のパケットの一部は、常に、ソースブロックの最後の行（又は最後のソースシンボル）に位置する。所定の値は、領域の分割に関係なく、常に、最後のパケットが割り当てられた後の最後の行（又は最後のソースシンボル）の残りの部分で割り当てられる（又は設定される）。例えば、５番目のソースパケットがソースブロック３０８の最後のパケットである場合に、図３Ｂにおいて、最後のパケットのデータの一部は、ソースブロック３０８の最後の１２番目の行（又はソースシンボル）の１番目の領域（又は１番目に細分化されたシンボル）に位置する。このとき、１番目の領域（又は１番目のサブシンボル）の残りの部分だけではなく最後の２番目の領域（又は２番目のサブシンボル）も、ゼロパディング３１０で示すように、すべて０で満たされる。
【００４５】
以下では、本発明の他の実施形態によるソースブロックの最後の行（又はソースシンボル）の構成について説明する。
【００４６】
システムの設定条件によりソースブロックの最後の行（又は最後のソースシンボル）の構成に対する制限条件は、様々な形態で表現されることができる。例えば、ソースブロックの最後の行（又は最後のソースシンボル）には、常に１個のソースパケットのデータの一部だけが割り当てられるように特定される。言い換えれば、２個以上のパケットの一部のデータは、ソースブロックの最後の行（又はソースシンボル）に同時に割り当てられない。
【００４７】
この制限条件の下での具体的なソースブロックの構成動作の例について説明する。ソースブロックの最大許容長さがＫｍａｘであり、ソースブロックの最後の行（又は最後のソースシンボル）には、常に、１個のソースパケットのデータの一部だけが割り当てられる制限条件を適用する場合に、ソースブロックは、次のように構成される。
【００４８】
特定のソースパケットの付加によりＫｍａｘより多くの数のソースシンボルを必要とするソースブロックが構成される場合に、ソースブロック構成器は、最後に受信されたソースパケットを除く以前に受信されたソースパケットだけでソースブロックを構成する。説明の便宜のために、最後に受信されたソースパケットは、パケット−０で示され、前のソースパケットは、逆順にＰａｃｋｅｔ−１、Ｐａｃｋｅｔ−２，．．．で順次に示される。
【００４９】
ソースブロック構成器は、パケット−０の以前に受信されたソースパケットの中で２個以上のソースパケットの一部のデータがソースブロックの最後の行（又はソースシンボル）に同時に割り当てられるか否かを判定する。最後のソースパケットＰａｃｋｅｔ−１のデータだけがソースブロックの最後の行（又はソースシンボル）に割り当てられる場合に、ソースブロック構成器は、ソースブロックを最終のソースブロックとして決定する。
【００５０】
他方、２個以上のソースパケットの一部のデータが最後の行（又はソースシンボル）に含まれる場合に、１つ又はそれ以上のソースパケットは、１個のソースパケットの一部のデータだけが最後の行（又はソースシンボル）に含まれるまで、ソースブロック構成器に入力された順序と逆順にソースブロックから除去される。例えば、Ｐａｃｋｅｔ−１及びＰａｃｋｅｔ−２の一部のデータがソースブロックの最後の行（又はソースシンボル）に含まれている場合に、Ｐａｃｋｅｔ−１は、ソースブロックから除去される。他の例において、Ｐａｃｋｅｔ−１、Ｐａｃｋｅｔ−２、及びＰａｃｋｅｔ−３の一部のデータがソースブロックの最後の行（又はソースシンボル）に含まれている場合に、Ｐａｃｋｅｔ−１及びＰａｃｋｅｔ−２は、ソースブロックから除去される。このように与えられた制限条件を満足する方法でソースパケットが適切に配列されると、ソースブロックを最終のソースブロックとして決定する。
【００５１】
ソースブロックの最後の行（又はソースシンボル）の構成の本発明のもう１つの実施形態によると、ソースブロック長さに対する推薦される基準値が、Ｋｂに設定される。この場合に、１つのソースブロック内に含まれることができる推薦されるデータサイズは、Ｔ×Ｋｂバイトである。しかしながら、ソースパケットを配列する間にゼロパディングが発生し得るので、ソースブロック内の実際のデータは、Ｔ×Ｋｂバイトより小さい場合がある。
【００５２】
ソースブロックが特定のパケットの入力によりソースブロック長さＫｂより多い量のソースシンボルを要求する場合に、入力されたパケットは、ソースブロックの最後のパケットとなる。すなわち、ソースパケットがソースブロックに順次に割り当てられる場合に、推薦されるデータサイズＫｂを超過するはじめのソースパケット（すなわち、最後に入力されたパケット）までソースブロックの構成に使用される。しかしながら、最後に入力されたパケットの付加によりソースブロックがシステムで設定した最大メモリサイズ又はバッファサイズを超過する場合には、最後に入力されたパケットは、ソースブロックから除外される。
【００５３】
上述した実施形態において、ソースシンボルの個数（すなわち、ソースブロック長さ）がＫｂより少し増加することがあるが、最後のパケットのサイズがあまり大きく、したがって、最後のパケットの付加により、ソースブロックがシステムで設定しておいた最大メモリ又はバッファサイズを超過することにより、ソースブロックの構成を不可能にする場合を除いては、1個のソースパケットのデータの一部だけがソースブロックの最後の行（又は最後のソースシンボル）に割り当てられるように制限する条件を自然に満足させることができる。
【００５４】
本発明の一実施形態で提案するソースブロックは、下記のように構成される。
【００５５】
シンボルサイズＴを有する２次元アレイの列は、サイズＴ／ｍをそれぞれ有するｍ個の領域に分割される。Ｔがｍの倍数でない場合には、ｍ個の領域は、［Ｔ／ｍ］＋１個の列をそれぞれ有する領域及び［Ｔ／ｍ］個の列をそれぞれ有する領域を含む。必要とされる場合に、付加情報がソースパケットに付加された後に、ソースパケットは、２次元アレイにおいて、シンボルサイズ内で順次に配列される。他の実施形態によると、ｍが定められた後に、Ｔは、ｍの倍数として定義され得る。
【００５６】
各ソースパケットは、常に、ｍ個に分割された領域が開始される列から配列されなければならず、付加情報が加えられた任意のソースパケットが配列された最後の行で対応するソースパケットの最後のデータが割り当てられている領域内の残りの部分に０のような所定の値が割り当てられる。
【００５７】
システムの要求により配列されたソースパケットの間には、Ｔ／ｍバイト以上のゼロパディングが挿入される場合もあるが、通常、ゼロパディングの比率を最小化するために、ゼロパディングの最大長さは、Ｔ／ｍより小さく設定される。したがって、付加情報が加えられた１つのソースパケットが配列された後に、次のソースパケットは、通常、ソースパケットが配列された最後の行で最後のデータが割り当てられている領域のその次の領域の開始点から配置されることができる。ソースパケットの最後のデータが最後のｍ番目の領域に割り当てられる場合には、次のソースパケットは、次の行のはじめの領域から開始される。
【００５８】
図３Ａ及び図３Ｂに示すソースブロック構成は、図２に示したソースブロック構成に比べて、ゼロパディングの量を効率的に減少させることができる。特に、各ソースパケットの長さが可変的に変わる場合には、ゼロパディングの量は、２次元アレイをｍ個の領域に分割することにより平均的に１／ｍだけ減少する効果を期待することができる。このような結果として、ＦＥＣ符号化が適用されるソースシンボルの個数が減少する効果もある。
【００５９】
従来の方法を通して与えられたシンボルサイズＴ、Ｋ１個のソースシンボルがソースパケットから生成され、Ｎｐ個のリペアシンボルがソースシンボルのＦＥＣ符号化を行うことにより生成されると仮定する。また、同一の方法で、与えられたシンボルサイズＴ、Ｋ１個のソースシンボルが同一のソースパケットから生成され、同一のリペアシンボルの個数、すなわち、Ｎｐ個のリペアシンボルがソースシンボルのＦＥＣ符号化を行うことにより生成されると仮定する。同一の数のリペアシンボルが同一の数のソースパケットから生成されるので、２通りの場合は、同一のオーバーヘッドを有する。しかしながら、ＦＥＣ符号化率Ｋ１／（Ｋ１＋Ｎｐ）とＫ２／（Ｋ２＋Ｎｐ）とを比較すると、Ｋ１＞Ｋ２が自明である。したがって、Ｋ１／（Ｋ１＋Ｎｐ）＞Ｋ２／（Ｋ２＋Ｎｐ）が成立する。通常、同一のＦＥＣ方式で同一のパリティ情報の量に対して符号化率が低い場合はより強固な（robust）保護性能を有することがよく知られている。 
【００６０】
したがって、本発明の実施形態は、従来の方法に比べて、ゼロパディングの量を効率的に減少させることにより追加のオーバーヘッドをほとんど必要とせず、よりよい誤り訂正性能を提供できる。
【００６１】
従来技術によるソースブロック構成では、１つのソースパケットが損失する場合に、ソースブロック内の対応するソースパケットが配列されたすべての行（すなわち、ソースパケットのすべての符号化シンボル）が損失されたものと見なされる。他方、本発明の実施形態によるソースブロック内の行又は符号化シンボルがｍ個の領域に分割されるので、損失された部分と損失されない部分とに識別されることができ、したがって、ｍ個の領域内の損失されない部分が復号のために使用されることにより、本発明の実施形態による復号性能を向上させることができる。
【００６２】
本発明の実施形態に従って構成されたソースブロックにＦＥＣを適用する場合に、送信器１００は、ソースブロック内の分割された領域の個数を示す情報及び各ソースパケットの開始領域を示す情報を受信器１１０に送信しなければならない。受信器１１０がこの情報を取得できず、任意のソースパケットが損失される場合には、受信器１１０がソースブロック内の損失されたパケットの位置を認識できないので、受信器１１０は、ＦＥＣ復号化の実行に難しさがある。
【００６３】
シンボルサイズＴ及び分割された領域の個数ｍに関するシグナリング情報は、各ソースパケットに付加され送信されるか又は付加のパケットを通して送信される。付加のパケットを通してシグナリング情報を送信する１つの実施形態によると、Ｔ及びｍは、セッションディスクリプションプロトコル（Session Description Protocol：ＳＤＰ）のようなコンテンツデリバリプロトコル（Content Delivery Protocol：ＣＤＰ）によりＦＥＣ関連情報とともに送信される。Ｔがｍの倍数でない場合に、受信器１１０は、予め定められた規則（例えば、各上位領域は、［Ｔ／ｍ］＋１個の列を含み、各下位領域は、［Ｔ／ｍ］個の列を含む）に従ってＴ及びｍに基づいて各領域の列の個数を判定することができる。
【００６４】
本発明の他の実施形態によると、受信器１１０がソースブロック内のソースパケットのレイアウトを把握できるように、各ソースパケットの配列が開始される行を示す情報（すなわち、符号化シンボルの順序及びソースパケットの開始符号化シンボル内のソースパケットの開始領域を示す情報）は、各ソースパケットに付加され、受信器１１０に送信される。
【００６５】
図４は、本発明の一実施形態によるソースパケット及びリペアパケットに付加されるシグナリング情報を示す図である。
【００６６】
図４を参照すると、ソースパケット及びリペアパケットのそれぞれは、次のパラメータの中の少なくとも１つを含む。ソースブロック番号（Source Block Number：ＳＢＮ）４０１は、ソースパケットに関連するソースブロックを識別し、符号化シンボル識別子（Encoding Symbol ID：ＥＳＩ）４０２は、ソースパケットの開始符号化シンボル（すなわち、ソースブロック内のソースパケットの開始行）を示し、パケット開始位置（Packet Start Position：ＰＳＰ）４０３は、ソースブロック内のソースパケットの開始領域を示す。ＳＢＮ４０１は、ソースブロックが開始されるソースシンボルの識別子を示す情報フィールドと、ソースブロック内のソースシンボルの個数を示す情報フィールドとを含む。
【００６７】
例えば、図３Ａに示すように、ｍ＝４である場合に、はじめのソースパケットのＥＳＩ及びＰＳＰは、（０，０）であり、２番目のソースパケットのＥＳＩ及びＰＳＰは、（２，２）であり、３番目のソースパケットのＥＳＩ及びＰＳＰは、（４，３）であり、４番目のソースパケットのＥＳＩ及びＰＳＰは、（７，１）であり得る。
【００６８】
ソースブロック内の総行の個数を示す選択的なソースブロック長さ（Source Block Length：ＳＢＬ）４０６を送信することにより、正確なソースブロック構成を特定することができる。また、符号化シンボル識別子（ＥＳＩ）４０５は、リペアパケットに付加される。
【００６９】
ソースブロックがＫ個のソースシンボルを含む場合に、値０，１，２，．．．，（Ｋ−１）は、Ｋ個のソースシンボルのＥＳＩ４０２として順次に割り当てられることにより、ＦＥＣソースパケット内のソースシンボルを識別する。ＥＳＩ４０２がＦＥＣソースパケット内の各ソースシンボルを識別するという観点で、各ソースシンボルのＥＳＩ４０２は、ソースＦＥＣペイロードＩＤと称される。
【００７０】
選択可能な実施形態において、リペアパケットのＥＳＩ４０５は、システムの要求事項により様々な方式で割り当てられる。例えば、リペアパケットのＥＳＩ４０５も、ソースパケットのＥＳＩ４０２のように、それぞれのリペアシンボルに対して、０，１，２，．．．のように順次に割り当てられる。この場合に、リペアパケットのＥＳＩ４０５のために必要なオクテットサイズ（octet size）を最小化することができる。
【００７１】
他の実施形態において、リペアシンボルをソースシンボルの次にくる符号化シンボルと見なし、それぞれのリペアシンボルに対して、ＥＳＩ４０５は、インデックスＫ，（Ｋ＋１），（Ｋ＋２），．．．の順序に割り当てられる。
【００７２】
もう１つの実施形態において、ソースブロックがｍ個の領域に分割され、各ソースシンボルがｍ個のサブシンボルと見なされる場合に、ソースブロックは、総ｍ×ｋ個のサブシンボルを含む。したがって、それぞれのリペアシンボルに対して、リペアパケットのＥＳＩ４０５は、値ｍ×ｋ，（ｍ×ｋ＋１），（ｍ×ｋ＋２），．．．のように順次に割り当てられる。
【００７３】
シグナリングフィールド４０１乃至４０６のサイズは、システムの要求事項により決定される。一実施形態において、ＳＢＮ４０１は、１又は２バイトであり、ＥＳＩ４０２は、２又は３バイトであり、ＰＳＰ４０３は、１又は２バイトであり、ＳＢＬ４０６は、２又は３バイトであり得る。
【００７４】
受信器１１０は、それぞれのソースパケットからＳＢＮ４０１、ＥＳＩ４０２、及びＰＳＰ４０３を取得する。１個以上のソースパケットが損失される場合、つまり、ＦＥＣ復号化を必要とする場合に、受信器１１０は、最小１個以上のリペアパケットを受信し、リペアパケットからＳＢＬ４０６を取得する。受信器１１０は、追加のパケットから送信されたソースブロック内の領域の個数に関する情報を取得すると、ＳＢＮ４０１に対応するソースブロックの構成を完璧に把握できる。追加で、受信器１１０は、それぞれのリペアパケットからＳＢＮ４０４及びＥＳＩ４０５を取得し、ＳＢＮ４０４及びＥＳＩ４０５を用いてＳＢＮ４０４に対応するソースブロックに対するＦＥＣ復号化を行うことにより損失されたソースパケットを復元できる。
【００７５】
図５は、本発明の一実施形態によるソースパケットに付加されるシグナリング情報を示す図である。
【００７６】
図５を参照すると、細分化された符号化シンボルＩＤ（ＳＥＳＩ）５０２は、分割されたそれぞれの領域に従って符号化シンボルを細分化し、すなわち、符号化されたシンボルを所定の長さをそれぞれ有する所定数のサブシンボルに細分化し、シンボル番号を各領域に割り当てることにより、図４に示したＥＳＩ４０２及びＰＳＰ４０３に代わる。ＳＥＳＩ５０２は、ＥＳＩ４０２と同様に、ＦＥＣソースパケット内のサブシンボルを識別し、各ＦＥＣソースパケットのＳＥＳＩ５０２は、前のＦＥＣソースパケットのＳＥＳＩ５０２からサブシンボルの個数だけ増加される。分割された領域の個数がｍである場合に、サブシンボルの個数は、符号化シンボルの総数のｍ倍であり、サブシンボルのサイズは、平均的に符号化シンボルサイズの１／ｍに減少する。一実施形態において、ＳＥＳＩは、２バイトと４バイトとの間の値を有する。
【００７７】
例えば、図３Ａに示したように、ｍ＝４である場合に、各符号化シンボルは、サイズＴ／４を有する４個のサブシンボルに分割される。したがって、サブシンボルの総数は、符号化シンボルの総数より４倍大きい。図３Ａに示したように、１番目乃至４番目のソースパケットのＳＥＳＩの値は、それぞれ０、１０、１９、及び２９として示すことができる。
【００７８】
上記のような本発明の実施形態において、ＳＥＳＩ＝ｍ×ＥＳＩ＋ＰＳＰの関係を適用したが、システムの設定により様々な方式で修正され得る。受信器１１０は、ＳＥＳＩ＝ｍ×ＥＳＩ＋ＰＳＰという関係に基づいて、ＥＳＩ及びＰＳＰからＳＥＳＩを導出することができ、また、ＥＳＩ＝［ＳＥＳＩ／ｍ］及びＰＳＰ＝ＳＥＳＩ−ｍ×［ＳＥＩ／ｍ］によりＳＥＳＩからＥＳＩ及びＰＳＰをそれぞれ取得することができる。受信器１１０は、ＦＥＣ復号化器１１３の構成に従ってＦＥＣ復号過程で取得された値を活用できる。
【００７９】
分割された領域の個数ｍに関するシグナリング情報をＳＤＰによる追加のパケットで送信することがオーバーヘッドの観点で効率的であるが、本発明の他の実施形態において、シグナリング情報は、ソースパケット又はリペアパケットに付加され得る。
【００８０】
図６は、本発明の一実施形態によるリペアパケットに付加されるシグナリング情報を示す図である。
【００８１】
図６を参照すると、ＳＢＮ４０４、ＥＳＩ４０５、ＳＢＬ４０６、及び分割された領域の個数ｍを示す領域の個数（Number of Regions：ＮＯＲ）４０７は、リペアパケットに付加される。
【００８２】
ＦＥＣ復号化が必要とされる場合に、受信器１１０は、リペアパケットのＳＢＬ４０６からソースブロックのサイズを理解する。また、受信器１１０は、ＮＯＲ４０７から、ソースブロックが幾つの領域に分割されるかを判定できるので、ソースブロックを領域別に個別に復号化できる。
【００８３】
受信器１１０がネットワーク又はチャネル状態がよくないので、ＦＥＣ復号化の必要性を予想する場合に、受信器１１０は、ソースパケットを受信すると同時にソースブロック内の領域の個数を好ましく判定できる。したがって、本発明の実施形態では、ソースパケットに付加され送信されるＮＯＲについて説明する。
【００８４】
図７及び図８は、本発明の実施形態によるソースパケットに付加されるシグナリング情報を示す図である。
【００８５】
図７に示すように、ソースパケットに付加されるシグナリング情報は、ＳＢＮ７０１、ＥＳＩ７０２、ＮＯＲ７０３、及びＰＳＰ７０４を含む。図８に示すように、ソースパケットに付加されるシグナリング情報は、ＳＢＮ８０１、ＮＯＲ８０２、及びＳＥＳＩ８０３を含む。本発明の例示的な実施形態に従って他の配列が可能であり得る。
【００８６】
上述したように、送信器１００は、ソースブロックの構成に関する情報を受信器１１０に提供するために、ソースブロック内の各ソースパケットの開始領域を示すシグナリング情報をソースパケットに付加し送信する。このシグナリング情報は、ＳＥＳＩ又はＰＳＰを含む。また、ソースブロックから分割された領域の個数を示すＮＯＲは、ソースパケット又はリペアパケット又は追加のパケットを通して送信されることができる。
【００８７】
受信器１１０は、ＳＢＮ、ＳＢＬ、及びＮＯＲを受信し、したがって、受信されたＳＢＮ、ＳＢＬ、及びＮＯＲからＥＳＩ及びＰＳＰを取得するか又はＳＥＳＩを取得することによりソースブロックの構成を正確に分かり、これにより、ＦＥＣ復号化を実行することができる。
【００８８】
第３世代パートナーシッププロジェクト（3rd Generation Partnership Project）ＳＡ４（Service Aspects 4）マルチメディアブロードキャスト及びマルチキャストサービス（Multimedia Broadcast and Multicast Service）（３ＧＰＰ  ＳＡ４  ＭＢＭＳ）標準は、ラプター符号を使用する。ラプター符号に使用可能な最大ソースシンボルサイズは、８１９２である。したがって、与えられたソースパケットの個数が所定数又はそれ以上である場合に、ソースブロックを構成するにあたりにパディングされたバイトの数を減少させるためにＴを小さくするのに限界がある。
【００８９】
これに関連して、本発明の実施形態が３ＧＰＰ  ＳＡ４  ＭＢＭＳ標準に従って具現される場合に、ラプター符号の使用可能な最大ソースシンボルサイズ８１９２内で与えられたソースパケットに対してＴをｍで割ってソースブロックを構成すると、パディングバイトの数を減少させ、これにより、符号化シンボルの数を減少させ、誤り訂正能力を改善させることができる。
【００９０】
例えば、１，０００個のソースパケットが存在し、各ソースパケットの長さが５１２バイトと１０２４バイトとの間でランダムに選択される場合に、ソースパケットの平均長さは、７６８バイトである。したがって、全データの量は、ほぼ７６８，０００バイトである。Ｔが１２８バイトに設定される場合に、ソースパケット当たりの平均パディングは、６４バイトであるので、総パディング量は、６４，０００バイトである。したがって、ソースブロックの全体量は、８３２，０００バイトである。Ｔが１２８バイトであるので、ソースシンボルの個数は、６５００個である。
【００９１】
本発明に従って、Ｍ＝４である場合に、サブソースシンボルサイズが３２（＝Ｔ／４）であり、ソースパケット当たりの１６バイトパディングが発生する。したがって、総パディング量は、１６，０００バイトであり、これにより、ソースブロックの全サイズは、７８４，０００バイトである。Ｔ／４＝３２であるので、サブソースシンボルの個数は、２４５００個であり、したがって、ソースシンボルの個数は、６１２５個である。結果的に、本発明の実施形態は、従来の方法に比べて、ソースシンボルの個数を３７５（＝６，５００−６，１２５）個だけ減少させることができる。ｍ＝８、１６などである場合に効果をさらに向上させることができる。
【００９２】
送信器１００がアプリケーションレイヤー−ＦＥＣ（ＡＬ−ＦＥＣ）を適用する場合に、送信器１００は、与えられたソースパケットを所定数のソースパケットだけ順次に分割する。ソースブロック構成器１０２は、所定数のソースパケットを受信し、ＵＤＰフローＩＤ及びソースパケット長さ情報を各ソースパケットに付加し、つまり、与えられたＴ及びｍ値に従ってＫ個のソースシンボルを含むソースブロックを構成する。ＦＥＣ符号化器１０３は、ソースブロックを用いて所定数のリペアシンボルを生成する。送信器１００のシグナリング情報生成器（図示せず）は、図４又は図５に示すような方法で、ＳＢＮ及びＳＥＳＩを各ソースパケットに付加し、１つ又はそれ以上のリペアシンボルを各ソースパケットに接続することによりリペアパケットを生成し、ＳＢＮ、ＥＳＩ、及びＳＢＬを対応するリペアパケットの先頭に付加する。リペアパケットのはじめのリペアシンボルのＥＳＩは、リペアパケットのＥＳＩとして割り当てられる。ＵＤＰヘッダーは、各パケットの先頭に付加され、ソースパケット及びリペアパケットは、異なるポートを有するので、異なるＵＤＰパケットとして構成される。Ｔ及びｍを含むＦＥＣシグナリング情報は、パケットの送信の前にＳＤＰにより送信され得る。
【００９３】
受信器１１０のソースブロック解析器１１２は、受信されたパケットが受信されたパケットに含まれるＵＤＰヘッダーのポートによりソースパケットであるか又はリペアパケットであるかを識別する。ソースパケットである場合には、受信器１１０は、ソースパケットの末尾からＳＢＮ及びＳＥＳＩを取得する。リペアパケットである場合には、受信器１１０は、ＳＢＮ、ＥＳＩ、及びＳＢＬをリペアパケットから取得する。その後に、受信器１１０は、予め受信されたＴ及びｍ値に基づいて受信されたパケットからソースブロック及びリペアシンボルを再構成する。ＦＥＣ復号化器１１３は、ｍ個のサブソースシンボルのそれぞれを復号化する。あるいは、ＦＥＣ復号化器１１３は、サイズＴを有する各ソースシンボルを復号化することも可能である。この場合に、サイズＴを有するソースシンボルのサブソースシンボルが損失される場合に、対応するソースシンボルが損失されたものと見なされて復号化される。
【００９４】
本発明の他の実施形態で提案するソースブロックの構成は、次の通りである。
【００９５】
特定のＦＥＣ符号が与えられる場合に、通常、ソースシンボルの個数は、限定されている。与えられたＦＥＣ符号に対する最大使用可能なソースシンボルの個数がＫｍａｘである場合に、ソースブロック構成器は、Ｋｍａｘの値に関係なく、与えられたソースパケットのＦＥＣ符号の符号化／復号化複雑度又はソースブロックの構成の間に発生し得るパディングバイトの個数を考慮してＴ値を決定し、シンボルサイズＴをそれぞれ有するＫ個のソースシンボルを生成した後に、［Ｋ／ｍ］＋１又は［Ｋ／ｍ］個のソースシンボルをそれぞれ有するｍ個のソースブロックを構成できる。例えば、Ｋ個のソースシンボルが０、１、２、．．．、（Ｋ−１）の順序を有する場合に、１番目のソースブロックは、０、ｍ、２ｍ、３ｍ、．．．、｛（［Ｋ−１］）／ｍ｝×ｍ番目のソースシンボルで構成された［Ｋ／ｍ］個のソースシンボルを含み、２番目のソースブロックは、１、ｍ＋１、２ｍ＋１、３ｍ＋１、．．．、｛（［Ｋ−１］／ｍ）×ｍ＋１番目のソースシンボルで構成された［Ｋ／ｍ］個のソースシンボルを含む。このような方法で、ｍ個のソースブロックを構成できる。説明の便宜上、Ｋがｍの倍数であると仮定する。
【００９６】
ｍ×Ｋｍａｘ＝Ｋである場合に、Ｋ／ｍ（＝Ｋｍａｘ）個のソースシンボルを有するソースブロックは、従来の方法に比べて、パディングの量を減少させることができる。従来の方法では、ｍ×Ｔ／２バイトだけのパディングがソースパケットごとに発生し、他方、上述した方法では、Ｔ／２バイトだけのパディングが発生する。したがって、ソースパケット当たり平均的に（ｍ−１）×Ｔ／２だけのパディングバイトを減少させ、したがって、最終的に符号化シンボルの個数を減少させることができる。
【００９７】
本発明の拡張された実施形態では、Ｋ／ｍ個のソースシンボルをそれぞれ有するｍ個のソースブロックは、１つの大きなソースブロックに結合され得る。この場合に、シンボルサイズは、ｍ×Ｔであり、図４乃至図８に示すＳＢＮは、より大きなソースブロックを示す。
【００９８】
理解を助けるために、ｍ＝４である場合の簡単な例を図９に示す。
【００９９】
図９は、本発明の一実施形態によるソースブロックの構成を示す図である。
【０１００】
図９を参照すると、ソースブロック構成器は、Ｋ個のソースシンボル９０１を生成した後に、Ｋ個のソースシンボルの中で、Ｋ／４個のソースシンボル、すなわち、０、４、８、１２、．．．、（Ｋ−４）番目のソースシンボルを有する１番目のソースブロック９０２を構成し、Ｋ個のソースシンボルの中で、Ｋ／４個の１、５、９、１３、．．．、（Ｋ−３）番目のソースシンボルを有する２番目のソースブロック９０３を構成し、Ｋ個のソースシンボルの中でＫ／４個の２、６、１０、１４、．．．、（Ｋ−２）番目のソースシンボルを有する３番目のソースブロック９０４を構成し、Ｋ個のソースシンボルの中で、Ｋ／４個の３、７、１１、１５、．．．、（Ｋ−１）番目のソースシンボルを有する４番目のソースブロック９０５を構成する。
【０１０１】
送信器１００又は受信器１１０は、それぞれのソースブロック９０２乃至９０５を個別のソースブロックとして取り扱ってＦＥＣ符号化／復号化を実行するか、又はソースブロック９０２乃至９０５を１つのソースブロック９０６に結合し、結合されたソースブロック９０６に対してＦＥＣ符号化／復号化を実行することができる。各ソースシンボル９０１のサイズがＴである場合に、結合されたソースブロック９０６のシンボルサイズは、４Ｔである。結合されたソースブロック９０６が図３Ａに示したソースブロックの構成と同一であることに留意する。
【０１０２】
図９に示すソースブロックに対応するＦＥＣ符号化及び復号化、シグナリング方法は、図３Ａ、図３Ｂ、及び図４に示したソースブロックの構成と同様に具現されることができる。
【０１０３】
本発明のもう１つの実施形態によると、シンボルサイズＴ及び分割された領域の個数ｍに関する情報は、追加のパケット又は経路を通して送信される。以下では、理解の便宜のために、３ＧＰＰ  ＴＳ  ２６．３４６でＳＤＰによりシンボルサイズＴを運搬するＦＥＣオブジェクト送信情報（FEC Object Transmission Information：ＦＥＣ  ＯＴＩ）について説明する。
【０１０４】
ＦＥＣ  ＯＴＩは、シンボル単位の最大ソースブロック長さ及びバイト単位のシンボルサイズを特定する。シンボルサイズ及び最大ソースブロック長さは、４オクテットフィールドに符号化され得る。ソースブロック長さは、特定のストリームに対するＦＥＣ  ＯＴＩにより示された最大ソースブロック長さを超過しない特定のパケットのリペアＦＥＣペイロード識別子（Repair FEC payload ID）によりシグナリングされる。ＦＥＣ  ＯＴＩは、ＳＤＰを通して送信される。ここで、リペアＦＥＣペイロードＩＤは、ソースブロック構成を示すためにリペアパケットに付加されるシグナリング情報を意味する。
【０１０５】
ソースブロック内の分割された領域の個数ｍ又は１つの符号化されたシンボル内のサブシンボルの個数ｍを示すために、所定のサイズを有するシグナリング情報は、ＦＥＣ  ＯＴＩに付加され得る。送信器１００は、ＦＥＣ  ＯＴＩの送信のために、シグナリング情報生成器（図示せず）をさらに含み得、受信器１１０は、ＦＥＣ  ＯＴＩの受信のために、シグナリング情報受信器（図示せず）をさらに含み得る。シグナリング情報生成器は、ソースブロック構成器１０２で使用されるものと同一のシグナリング情報であらかじめ定められたフォーマットのＦＥＣ  ＯＴＩを構成し、ＦＥＣ  ＯＴＩをあらかじめ定められた送信プロトコル、例えば、ＳＤＰにより受信器１１０に送信する。シグナリング情報受信器は、送信器１００から受信されたＦＥＣ  ＯＴＩからシグナリング情報を抽出し、抽出されたシグナリング情報をソースブロック解析器１１２に提供する。
【０１０６】
図１０Ａ及び図１０Ｂは、本発明の一実施形態によるＦＥＣ  ＯＴＩを示す図である。
【０１０７】
図１０Ａを説明すると、１つの符号化シンボル内のサブシンボルの個数ｍを示すサブシンボルの個数（Number of Sub-Symbols：ＮＳＳ）１００２は、シンボルサイズ（Ｔ）１００１及び最大ソースブロック長さ１００３とともにＦＥＣ  ＯＴＩに含まれる。ここで、シンボルサイズ（Ｔ）１００１は、符号化シンボルの長さをバイト単位で示し、ソースシンボル又はリペアシンボルの長さとして定義され得る。また、ＮＳＳ１００２は、ソースシンボル当りのサブシンボルの個数又は１つのソースシンボルに含まれたシンボル単位の個数を示す。
【０１０８】
図１０Ｂは、本発明の一実施形態による図１０ＡのＮＳＳ１００２がＮＯＲ１００４に置き換えられるＦＥＣ  ＯＴＩの構成を示す図である。
【０１０９】
図１０Ｂを参照すると、ＮＳＳ１００２は、１つのシンボル内のサブシンボルの個数を示し、他方、ＮＯＲ１００４は、ソースブロック内の分割された領域の個数を示す。しかしながら、ＮＳＳ１００２及びＮＯＲ１００４は、同一の機能を有する同一の値を有し得る。
【０１１０】
ＮＳＳ１００２又はＮＯＲ１００４は、何の特定の制限の無しにシステムの要求条件により様々なサイズを有する。本発明の一実施形態によると、ＮＳＳ１００２又はＮＯＲ１００４は、１バイト又は２バイトを有する。図１０Ａ及び図１０Ｂにおいて、最大ソースブロックサイズ１００３は、システムに従って送信される場合もあり、送信されないこともある。
【０１１１】
シンボルサイズＴとＮＳＳ又はＮＯＲに対応するｍとの関係に従って各サブシンボルのサイズを決定する実施形態について説明する。
【０１１２】
Ｔをｍで割った商及び余りがそれぞれａ及びｂである場合に（すなわち、Ｔ＝ｍ×ａ＋ｂ、０≦ｂ＜ｍである関係が成立する場合に）、１番目のサブシンボルは、サイズ（ａ＋１）を有し、余り（ｍ−１）サブシンボルのそれぞれは、サイズａを有する。サイズ（ａ＋１）のサブシンボル及び及びサイズａのサブシンボルの順序は、逆順であり得る。Ｔがｍの倍数である場合に、各サブシンボルは、ａを有する。
【０１１３】
シンボルサイズＴとＮＳＳ又はＮＯＲに対応するｍとの間の関係に従って各サブシンボルのサイズを決定するもう１つの実施形態について説明する。
【０１１４】
Ｔをｍで割った商及び余りがそれぞれａ及びｂである場合に、すなわち、Ｔ＝ｍ×ａ＋ｂ、０≦ｂ＜ｍである関係が成立する場合に、１番目のサブシンボルは、サイズ（ａ＋１）を有し、余り（ｍ−１）サブシンボルのそれぞれは、サイズａを有する。サイズ（ａ＋ｂ）のサブシンボル及び及びサイズａのサブシンボルの順序は、逆順であり得る。
【０１１５】
上述したように、各サブシンボルのサイズは、様々な方法で設定され得る。また、各サブシンボルのサイズは、サブシンボルに対応する領域内の列の個数として表現され得る。
【０１１６】
放送又は通信システムにおいて、受信器１１０が損失されたパケットを復旧するようにするために、ソースブロックを構成しＦＥＣ符号化を適用する場合に、ソースブロック構成を示すために、ソースパケットに付加されるシグナリング情報（すなわち、ソースパケット付加情報）であるソースＦＥＣペイロード識別子（Source FEC Payload ID）、リペアパケットに付加されるシグナリング情報（すなわち、リペアパケット付加情報）であるリペアＦＥＣペイロード識別子（Repair FEC Payload ID）、及びＦＥＣ  ＯＴＩの１セット（set）（又はスーツ（suite））の具体的な例について図１１及び図１２を参照して説明する。
【０１１７】
図１１は、本発明の一実施形態によるシグナリング情報の１つのセットを示す図である。
【０１１８】
図１１を参照すると、送信されたソースパケットの一部が損失される場合、つまり、ＦＥＣ復号化を必要とする場合に、受信器１１０は、１つ以上のリペアパケットを用いて復号化する間に、ＦＥＣ  ＯＴＩからシンボルサイズ（Ｔ）１００１及びＮＳＳ（ｍ）１００２を取得し、ソースパケット付加情報からＳＢＮ５０１及びＳＥＳＩ５０２を取得し、リペアパケット付加情報からＳＢＬ４０６を取得し、ソースブロック構成を判定し、受信されたソースパケットを適切に配列することによりソースブロックを再構成する。各ソースパケットのＳＥＳＩ５０２がソースパケットの開始サブシンボルを示すので、受信器１１０は、各ソースパケットのレイアウトを正確に判定できる。損失されたソースパケットに対応する位置は、消去（erasure）として処理される。
【０１１９】
受信器１１０は、ソースパケット付加情報から取得したＳＢＮ５０１及びリペアパケット付加情報から取得したＳＢＮ４０４及びＥＳＩ４０５から任意のソースブロックとリペアパケットとの間の対応関係に基づいてＦＥＣ復号化を実行する。このとき、ＦＥＣ復号化器１１３は、ＦＥＣ  ＯＴＩからＮＳＳ（すなわち、ｍ）を取得し、ソースブロックをｍ個の領域に分割し、個々のｍ個の領域を復号化する。本発明の他の実施形態によると、ＦＥＣ復号化器１１３は、ソースブロックをｍ個の領域に分割せず、シンボルサイズＴの１つの領域として見なしてＦＥＣ復号化を実行することができる。ここで、シンボルサイズＴの１つの領域として見なしてＦＥＣ復号化を実行する場合に、損失されたソースパケット及びその付加情報を含むすべての行を消去として処理する。
【０１２０】
図１２は、本発明の一実施形態によるシグナリング情報の１つのセットを示す図である。
【０１２１】
図１２を参照すると、シグナリング情報セットは、ソースパケット付加情報、リペアパケット付加情報、及びＦＥＣ  ＯＴＩを含む。
【０１２２】
図１１とは異なり、ＦＥＣ  ＯＴＩは、図１０Ｂに示すように構成される。ソースパケット付加情報は、ＳＥＳＩ５０２の代わりに、ＥＳＩ４０５及びＰＳＰ４０６をシグナリングする。
【０１２３】
送信されたソースパケットの一部が損失され、したがって、ＦＥＣ復号化を必要とする場合に、受信器１１０は、１つ以上のリペアパケットを用いて復号化する間に、ＦＥＣ  ＯＴＩからシンボルサイズ（Ｔ）１００１及びＮＳＳ（ｍ）１００４を取得し、ソースパケット付加情報からＳＢＮ４０１、ＥＳＩ４０２、及びＰＳＰ４０３を取得し、リペアパケット付加情報からＳＢＬ４０６を取得する。受信器１１０は、ソースブロック構成を判定し、受信されたソースパケットを適切に配列することによりソースブロックを再構成する。各ソースパケットのＥＳＩ４０２がソースパケットの開始行又はソースシンボルを示し、各ソースパケットのＰＳＰ４０３がソースパケットの開始領域を示すので、受信器１１０は、ソースブロックで各ソースパケットのレイアウトを正確に判定できる。損失されたソースパケットに対応する位置は、消去として処理される。
【０１２４】
また、受信器１１０は、ソースパケット付加情報から取得したＳＢＮ４０１及びリペアパケット付加情報から取得したＳＢＮ４０４及びＥＳＩ４０５に従って任意のソースブロックとリペアパケットとの間の対応関係に基づいてＦＥＣ復号を実行する。このとき、ＦＥＣ復号化器１１３は、ＦＥＣ  ＯＴＩからＮＯＲ１００４（すなわち、ｍ）を取得し、ソースブロックをｍ個の領域に分割し、個々のｍ個の領域を復号化する。他の実施形態によると、ＦＥＣ復号化器１１３は、ソースブロックをｍ個の領域に分割せず、シンボルサイズＴの１つの領域として見なしてＦＥＣ復号化を実行することができる。ここで、シンボルサイズＴの１つの領域として見なしてＦＥＣ復号化を実行する場合に、損失されたソースパケット及びその付加情報を含むすべての行を消去として処理する。
【０１２５】
図１１及び図１２に示すシグナリング情報のセットは、受信器１１０が損失されたソースパケットを復旧するために必要とされるすべての情報を含む。図１１及び図１２において、最大ソースブロック長さ１００３は、システム状況により送信されることもあり、又は送信されないこともある。
【０１２６】
図１３Ａ及び図１３Ｂは、本発明の一実施形態によるＦＥＣ  ＯＴＩの構成を示す図である。
【０１２７】
図１３Ａ及び図１３Ｂを参照すると、サブシンボルサイズ（Ｔｓｕｂ）１３０１は、図１０Ａ及び図１０Ｂに比べて、シンボルサイズＴの代わりにＦＥＣ  ＯＴＩに含まれる。シンボルサイズＴ、サブシンボルサイズＴｓｕｂ、及び、ＮＳＳ１００２又はＮＯＲ１００４により示されるｍの間には、Ｔ／ｍ＝Ｔｓｕｂの関係が成立するので、３個の値のうちのいずれか２個の値に基づいて他のパラメータが定められ得る。例えば、図１３Ａ及び図１３Ｂにおいて、送信器１００がＴｓｕｂ及びｍを送信するので、受信器１１０は、Ｔｓｕｂ及びｍを受信した後に、Ｔ＝ｍ×Ｔｓｕｂを通してシンボルサイズを計算し、シンボルサイズに基づいてソースブロックを再構成する。上述した実施形態と同様に、最大ソースブロックサイズ１００３は、送信されないこともある。
【０１２８】
以下では、ソースブロックとソースパケットとの間の関係に基づいてソースブロックのサイズ（すなわち、ソースブロック内のデータの総量）を計算する動作について、次の定義に基づいて説明する。
【０１２９】
ｎ：ソースブロック内のＵＤＰパケットの個数。ソースブロックを構成する際に可変的に決定される。
Ｒ（ｉ）：ソースブロック内に挿入されるｉ番目のＵＤＰパケットのＵＤＰペイロードのオクテット
ｌ（ｉ）：オクテット単位のＲ（Ｉ）の長さ
Ｌ（ｉ）：ｌ（ｉ）の値を示す２オクテット
ｆ（ｉ）：ｉ番目のＵＤＰパケットのＵＤＰフローＩＤを示す整数
Ｆ（ｉ）：ｆ（ｉ）の値を示す1オクテット
Ｔ：バイト単位のソースシンボルサイズ
ｍ：ソースシンボル（又は符号化シンボル）内のサブシンボルの個数。Ｔ／ｍ＝ Ｔ’である場合に、Ｔ’は、サブシンボルの長さである。
ｓ（ｉ）：ｓ（ｉ）×Ｔ／ｍ＝ｓ（ｉ）×Ｔ’≧（ｌ（ｉ）＋３）を満足する最小整数
Ｐ（ｉ）：ｓ（ｉ）× Ｔ’−（ｌ（ｉ）＋３）ゼロオクテット。Ｐ（ｉ）は、各ＵＤＰパケットの開始部をサブシンボルの開始部に一致させるパディングオクテットである。
ここで、ｉ＝１，２，．．．，ｎに対してｓ（ｉ）×Ｔ’値の総計がＳである場合に、Ｋ（＝ｃｅｉｌ（Ｓ／Ｔ））は、ソースブロックの長さであり、ＳＳＢ（＝Ｔ×ｃｅｉｌ（Ｓ／Ｔ））は、ソースブロックのサイズである。実数ｘに対して、ｃｅｉｌ（ｘ）は、ｘより大きいか又は同一の最小整数を意味する。
結果的に、ソースブロックは、ｉ＝１，２，．．．，ｎに対してＦ（ｉ）、Ｌ（ｉ）、Ｒ（ｉ）、及びＰ（ｉ）をＳＳＢ（＝Ｔ×ｃｅｉｌ（Ｓ／Ｔ））値に接続することにより構成されることができることをわかる。ここで、Ｓは、ｉ＝１，２，．．．，ｎに対してｓ（ｉ）×Ｔ’値の総計である。
【０１３０】
上記した本発明による実施形態は、コンピュータ読み取り可能な記録媒体上でコンピュータ読み取り可能なコードとして実現することもできる。コンピュータ読み取り可能な記録媒体は、コンピュータシステムにより読出し可能なデータを記憶できる任意のデータ記憶装置である。コンピュータ読み取り可能な記録媒体の例としては、読出し専用メモリ（ＲＯＭ）、ランダムアクセスメモリ（ＲＡＭ）、ＣＤ−ＲＯＭ、磁気テープ、フロッピー（登録商標）ディスク、光学データ記憶装置が含まれる。また、本発明を実行するための機能（function）プログラム、コード及びコードセグメントは、本発明が属する技術分野で熟練したプログラマーにより本発明の範囲内で容易に解析することができるであろう。
【０１３１】
以上、本発明を具体的な実施形態を参照して詳細に説明してきたが、本発明の範囲及び趣旨を逸脱することなく様々な変更が可能であるということは、当業者には明らかであり、本発明の範囲は、上述の実施形態に限定されるべきではなく、特許請求の範囲の記載及びこれと均等なものの範囲内で定められるべきである。
【符号の説明】
【０１３２】
１００  送信器
１０１  ソースパケット
１０２  ソースブロック構成器
１０３  符号化器
１０４  リペア情報、パリティデータ
１１０  受信器
１１１  受信データ
１１２  ソースブロック解析器
１１３  ＦＥＣ復号化器
１１４  ソースパケット
１１５  シグナリング情報
２０１  ＵＤＰフロー識別子（ＩＤ）
２０２  パケット長さ情報
２０３  ソースパケット
２０４  ゼロパディング
２０５，２０７  リペアシンボル（例えば、パリティシンボル）
２０６  ソースブロック
３０１  フィーチャー情報
３０２  パケット長さ情報
３０５，３０６  ゼロパディングされたデータ
３０７  配列
３０８  ソースブロック
３０９  参照符号
３０９  サブシンボル
３１０  ゼロパディング
４０１  ソースブロック番号（Source Block Number:SBN）
４０１  シグナリングフィールド
４０２  符号化シンボル識別子（Encoding Symbol ID:ESI）
４０３  パケット開始位置（Packet Start Position:PSP）
４０５  符号化シンボル識別子（ESI）
４０６  ソースブロック長さ（Source Block Length:SBL）
４０７  分割された領域の個数を示す領域の個数（Number Of Regions:NOR）
５０２  細分化された符号化シンボルＩＤ（SESI）
【図１】
2015520990.tif 000003
【図２】
2015520990.tif 000004
【図３Ａ】
2015520990.tif 000005
【図３Ｂ】
2015520990.tif 000006
【図４】
2015520990.tif 000007
【図５】
2015520990.tif 000008
【図６】
2015520990.tif 000009
【図７】
2015520990.tif 000010
【図８】
2015520990.tif 000011
【図９】
2015520990.tif 000012
【図１０Ａ】
2015520990.tif 000013
【図１０Ｂ】
2015520990.tif 000014
【図１１】
2015520990.tif 000015
【図１２】
2015520990.tif 000016
【図１３Ａ】
2015520990.tif 000017
【図１３Ｂ】
2015520990.tif 000018
【国際調査報告】
2015520990.tif 000019
2015520990.tif 000020
2015520990.tif 000021