特許 6553119 放送及び通信システムにおけるパケット送受信装置及び方法

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】特許公報(B2)

(11)【特許番号】6553119

(24)【登録日】2019年7月12日

(45)【発行日】2019年7月31日

(54)【発明の名称】放送及び通信システムにおけるパケット送受信装置及び方法

(51)【国際特許分類】

   H04L 1/00 20060101AFI20190722BHJP

   H03M 13/47 20060101ALI20190722BHJP

【ＦＩ】

   H04L1/00 B

   H03M13/47

【請求項の数】2

【全頁数】34

(21)【出願番号】特願2017-101626(P2017-101626)

(22)【出願日】2017年5月23日

(62)【分割の表示】特願2014-515715(P2014-515715)の分割

【原出願日】2012年6月8日

(65)【公開番号】特開2017-163602(P2017-163602A)

(43)【公開日】2017年9月14日

【審査請求日】2017年5月23日

(31)【優先権主張番号】10-2011-0056562

(32)【優先日】2011年6月11日

(33)【優先権主張国】KR

(31)【優先権主張番号】10-2011-0071187

(32)【優先日】2011年7月18日

(33)【優先権主張国】KR

(31)【優先権主張番号】10-2011-0104889

(32)【優先日】2011年10月13日

(33)【優先権主張国】KR

(31)【優先権主張番号】10-2011-0114186

(32)【優先日】2011年11月3日

(33)【優先権主張国】KR

(73)【特許権者】

【識別番号】503447036

【氏名又は名称】サムスン エレクトロニクス カンパニー リミテッド

(74)【代理人】

【識別番号】100133400

【弁理士】

【氏名又は名称】阿部 達彦

(74)【代理人】

【識別番号】100110364

【弁理士】

【氏名又は名称】実広 信哉

(74)【代理人】

【識別番号】100154922

【弁理士】

【氏名又は名称】崔 允辰

(74)【代理人】

【識別番号】100140534

【弁理士】

【氏名又は名称】木内 敬二

(72)【発明者】

【氏名】スン−ヘ・ファン

(72)【発明者】

【氏名】セ−ホ・ミュン

(72)【発明者】

【氏名】スン−オ・ファン

(72)【発明者】

【氏名】キュン−モ・パク

(72)【発明者】

【氏名】ヒュン−ク・ヤン

【審査官】 谷岡 佳彦

(56)【参考文献】

【文献】 特表２０１１−５０３９４７（ＪＰ，Ａ）

【文献】 米国特許出願公開第２００７／０３００１２７（ＵＳ，Ａ１）

【文献】 特表２００８−５０８７５７（ＪＰ，Ａ）

【文献】 特表２００７−５０９５５７（ＪＰ，Ａ）

【文献】 特表２０１１−５２３８０６（ＪＰ，Ａ）

【文献】 Youngkwon Lim，Review of w11792[online]， JCTVC-E JCTVC-E360-v3，２０１１年 ３月

(58)【調査した分野】（Int.Cl.，ＤＢ名）

Ｈ０４Ｌ １／００

Ｈ０３Ｍ １３／４７

(57)【特許請求の範囲】

【請求項1】

放送システムにおける順方向エラー訂正（Forward Error Correction：ＦＥＣ）パケットを受信する方法であって、
ＦＥＣパケットを受信するステップであって、前記ＦＥＣパケットは、入力ソースパケットブロックを少なくとも２つのサブブロックに分割し、前記分割された少なくとも２つのサブブロックの各々を情報ペイロードを含む一つの情報サブブロックにそれぞれ変換することにより複数の情報サブブロックを生成し、前記複数の情報サブブロックの各々を第１のコードで符号化することにより一つの第１のリペアシンボルブロックをそれぞれ生成し、前記複数の情報サブブロックを第２のコードで符号化することにより一つの第２のリペアシンボルブロックを生成することによって生成される、ステップと、
関連入力ソースパケットブロックに対して適用される符号化構造を指示する符号化構造情報を含むＦＥＣ構成情報を受信するステップと、
前記ＦＥＣパケットを復号化するステップと、を含み、
前記符号化構造は、1)符号化が適用されない構造と、2)前記第１のコードのみが適用される１ステージＦＥＣ符号化構造と、3)前記第２のコードのみが適用される１ステージＦＥＣ符号化構造と、4)前記第１のコードおよび前記第２のコードが適用される２ステージＦＥＣ符号化構造と、の４つの構造を含み、
前記ＦＥＣ構成情報は、前記複数の情報サブブロックに適用されたコードを特定する情報を含むことを特徴とする方法。

【請求項2】

放送システムにおける順方向エラー訂正（Forward Error Correction：ＦＥＣ）パケットを受信する装置であって、
ＦＥＣパケットを受信し、関連入力ソースパケットブロックに対して適用される符号化構造を指示する符号化構造情報を含むＦＥＣ構成情報を受信する受信器であって、前記ＦＥＣパケットは、入力ソースパケットブロックを少なくとも２つのサブブロックに分割し、前記分割された少なくとも２つのサブブロックの各々を情報ペイロードを含む一つの情報サブブロックにそれぞれ変換することにより複数の情報サブブロックを生成し、前記複数の情報サブブロックの各々を第１のコードで符号化することにより一つの第１のリペアシンボルブロックをそれぞれ生成し、前記複数の情報サブブロックを第２のコードで符号化することにより一つの第２のリペアシンボルブロックを生成することによって生成される、受信器と、
前記ＦＥＣパケットを復号化する復号器と、
を有し、
前記符号化構造は、1)符号化が適用されない構造と、2)前記第１のコードのみが適用される１ステージＦＥＣ符号化構造と、3)前記第２のコードのみが適用される１ステージＦＥＣ符号化構造と、4)前記第１のコードおよび前記第２のコードが適用される２ステージＦＥＣ符号化構造と、の４つの構造を含み、
前記ＦＥＣ構成情報は、前記複数の情報サブブロックに適用されたコードを特定する情報を含むことを特徴とする装置。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は、放送及び通信システムに関し、特に、パケット送受信装置及び方法に関する。

【背景技術】

【0002】

様々なコンテンツの増加及び高解像度（High Definition：ＨＤ）コンテンツ及び超高解像度（Ultra High Definition：ＵＨＤ）コンテンツのような高容量コンテンツの増加の結果として、ネットワークトラフィックと関連したデータ輻輳（data Congestion）は、さらに悪化している。結果的に、送信器（Sender）（例えば、ホストＡ）により送信されたコンテンツは、受信器（Receiver）（例えば、ホストＢ）に正常に配信されず、コンテンツの一部は、経路上で損失される状況が発生する場合がある。

【0003】

一般的に、データは、パケット単位で送信される。このように、データ損失は、パケット単位で発生する場合がある。したがって、受信器は、ネットワーク上でデータの損失によりパケットを受信することができないので、損失されたパケット内のデータがわからない。したがって、オーディオの品質劣化、ビデオの画質劣化、画面クラック、字幕欠落、ファイル損失などのような様々な形態でユーザの不便さをもたらす。このような理由で、ネットワーク上で発生し得るデータ損失を復旧するための方法が要求される。

【0004】

したがって、コンピュータ又はユーザインターフェースで自己診断項目を選択する時に、装置の自己診断を快適に実行するためのシステム及び方法に対する必要性が存在する。

【0005】

上記情報は、本発明の理解を助けるために背景情報だけが提示される。本発明についての先行技術として適用することができるか否かについては、何らの決定及び何らの主張もするものではない。

【発明の概要】

【発明が解決しようとする課題】

【0006】

本発明の目的は、少なくとも上述した問題点及び／又は不都合に取り組み、少なくとも以下の利便性を提供することにある。すなわち、本発明の目的は、ネットワーク上で発生するデータ損失を復旧する放送及び通信システムにおけるパケット送受信装置及び方法を提供することにある。

【0007】

本発明の他の目的は、第１の順方向エラー訂正（Forward Error Correction：ＦＥＣ）及び第２のＦＥＣのそれぞれの適用／不適用を表示する情報又は他の符号化構成（Encoding Configuration）関連情報をシグナリングする放送及び通信システムにおけるパケット送受信装置及び方法を提供することにある。

【0008】

本発明のまた他の目的は、ネットワーク状況又はコンテンツのサービス品質（ＱｏＳ）に基づいて選択的にＦＥＣを適用する放送及び通信システムにおけるパケット送受信装置及び方法を提供することにある。

【0009】

本発明のさらにまた他の目的は、サービスがすでに進行している間に新たな受信器がＦＥＣ関連情報を予め認識するようにする放送及び通信システムにおけるパケット送受信装置及び方法を提供することにある。

【課題を解決するための手段】

【0010】

上記のような目的を達成するために、本発明の一態様によれば、インターネットプロトコルに基づいてマルチメディアサービスをサポートする放送システムにおけるパケット構成方法が提供される。上記方法は、入力されたソースブロックを少なくとも１つのサブブロックに分割するステップと、上記少なくとも１つのサブブロックの各々を同一の長さを有する情報ペイロードを含む情報ブロックに変換するステップと、上記少なくとも１つのサブブロックの各々の情報ブロックを符号化することにより第１のパリティブロックを生成するステップと、上記少なくとも１つのサブブロック全体を含むソースブロックに第２のパリティブロックを付加するステップとを有することを特徴とする。

【0011】

本発明の他の態様によれば、インターネットプロトコルに基づいてマルチメディアサービスをサポートする放送システムにおけるパケット構成装置が提供される。上記装置は、入力されたソースブロックを少なくとも１つのサブブロックに分割し、上記少なくとも１つのサブブロックの各々を同一の長さを有する情報ペイロードを含む情報ブロックに変換するトランスポートプロトコルパケタイザと、上記少なくとも１つのサブブロックの各々の情報ブロックを符号化することにより第１のパリティブロックを生成する第１のエンコーダと、上記少なくとも１つのサブブロック全体を含むソースブロックに第２のパリティブロックを付加する第２のエンコーダとを有することを特徴とする。

【0012】

本発明のさらに他の態様によれば、インターネットプロトコルに基づいてマルチメディアサービスをサポートする放送システムにおけるパケット受信方法が提供される。上記方法は、送信器から送信された信号を復調するステップと、上記復調された信号から第２のパリティビットブロックを抽出するステップと、上記抽出された第２のパリティビットブロックに基づいてパケットを復号化するステップとを有し、上記第２のパリティビットブロックは、入力されたソースブロックを少なくとも１つのサブブロックに分割し、上記少なくとも１つのサブブロックの各々を同一の長さを有する情報ペイロードを含む情報ブロックに変換し、上記少なくとも１つのサブブロックの各々の情報ブロックを符号化することにより第１のパリティブロックを生成し、上記少なくとも１つのサブブロック全体を含むソースブロックに第２のパリティブロックを付加することにより生成されることを特徴とする。

【0013】

本発明のさらなる他の態様によれば、インターネットプロトコルに基づいてマルチメディアサービスをサポートする放送システムにおけるパケット受信装置が提供される。上記装置は、送信器から送信された信号を復調する復調部と、上記復調された信号から第２のパリティビットブロックを抽出する制御部と、上記抽出された第２のパリティビットブロックに基づいてパケットを復号化する復号部とを有し、上記第２のパリティビットブロックは、入力されたソースブロックを少なくとも１つのサブブロックに分割し、上記少なくとも１つのサブブロックの各々を同一の長さを有する情報ペイロードを含む情報ブロックに変換し、上記少なくとも１つのサブブロックの各々の情報ブロックを符号化することにより第１のパリティブロックを生成し、上記少なくとも１つのサブブロック全体を含むソースブロックに第２のパリティブロックを付加することにより生成されることを特徴とする。

【0014】

本発明によれば、第１のＦＥＣ及び第２のＦＥＣのそれぞれの適用／不適用を示す情報を含むＦＥＣ構成関連情報又は他の符号化構成関連情報をシグナリングし受信器に送信することにより、送信器は、選択的にＦＥＣが適用されたコンテンツを配信することができる。

【0015】

また、本発明によれば、ネットワーク状況又はコンテンツのサービス品質（ＱｏＳ）に基づいて選択的にＦＥＣを適用することができる。

【0016】

さらに、本発明によれば、第１のＦＥＣ及び第２のＦＥＣのそれぞれの適用／不適用を示す情報を含むＦＥＣ構成関連情報又は他の符号化構成関連情報を含むＦＥＣ制御情報を周期的に反復して送信するか、又は提案されたイン−バンドシグナリング方法でＦＥＣ構成関連情報を送信することにより、サービスがすでに進行中である状況で新たな受信器にもＦＥＣ構成関連情報を予め認識するようにすることができるので、新たな受信器もＦＥＣ復号化を実行することにより損失されたデータを復旧し、これにより、良質のサービスをユーザに提供することができる。

【0017】

本発明の他の目的、利点、及び顕著な特徴は、添付の図面及び本発明の実施形態からなされた以下の詳細な説明から、この分野の当業者に明確になるはずである。

【図面の簡単な説明】

【0018】

【図1】本発明の実施形態によるネットワークトポロジー（Network Topology）及びデータフローを示す図である。

【図2A】Ｍ＝１及びＭ＝８の場合に本発明の実施形態による順方向エラー訂正（ＦＥＣ）符号化方法を図式化する図である。

【図2B】Ｍ＝１及びＭ＝８の場合に本発明の実施形態による順方向エラー訂正（ＦＥＣ）符号化方法を図式化する図である。

【図3】本発明の実施形態によるアウト−バンドシグナリング（Out-band Signaling）のためのＦＥＣ制御パケットの構造を示す図である。

【図4】本発明の実施形態によるイン−バンドシグナリング（In-band signaling）のためのＦＥＣ制御パケットの構造を示す図である。

【図5】本発明の実施形態によるアウト−バンドシグナリングのためのシステム構成を示す図である。

【図6】本発明の実施形態によるイン−バンドシグナリングのためのシステム構成を示す図である。

【図7】本発明の実施形態による送信方法を示すフローチャートである。

【図8】本発明の実施形態による受信方法を示すフローチャートである。

【図9】本発明の実施形態によるＭＰＥＧメディアトランスポート（MPEG Media Transport：ＭＭＴ）システム構成を示す図である。

【図10】本発明の実施形態によるイン−バンドシグナリングのためのＦＥＣ制御パケットの構造を示す図である。

【図11】本発明の実施形態による２ステート（Two-State）ギルバート−エリオット消去チャネル（Gilbert-Elliot Erasure Channel：ＧＥＥＣ）モデルの一例を示す図である。

【図12A】本発明の実施形態による１ステージ及び２ステージＦＥＣ符号化構造を示す図である。

【図12B】本発明の実施形態による１ステージ及び２ステージＦＥＣ符号化構造を示す図である。

【図13】本発明の実施形態によるランダム＋反復電気インパルス雑音（Repetitive Electric Impulse Noise：ＲＥＩＮ）チャネル上で２ステージＦＥＣ符号化構造及び１ステージＦＥＣ符号化構造に対するシミュレーション結果を示す図である。

【図14】本発明の実施形態によるランダム＋ＲＥＩＮチャネル上で２ステージＦＥＣ符号化構造及び１ステージＦＥＣ符号化構造に対するシミュレーション結果を示す図である。

【図15】本発明の実施形態によるランダム＋ＲＥＩＮチャネル上で２ステージＦＥＣ符号化構造及び１ステージＦＥＣ符号化構造に対するシミュレーション結果を示す図である。

【図16】本発明の実施形態によるランダム＋ＲＥＩＮチャネル上で２ステージＦＥＣ符号化構造及び１ステージＦＥＣ符号化構造に対するシミュレーション結果を示す図である。

【図17】本発明の実施形態によるランダム＋ＲＥＩＮチャネル上で２ステージＦＥＣ符号化構造及び１ステージＦＥＣ符号化構造に対するシミュレーション結果を示す図である。

【図18】本発明の実施形態によるランダム＋ＲＥＩＮチャネル上で２ステージＦＥＣ符号化構造及び１ステージＦＥＣ符号化構造に対するシミュレーション結果を示す図である。

【図19】本発明の実施形態によるＭＰＥＧメディアトランスポート（ＭＭＴ）システムが適用されるアプリケーションレイヤー順方向エラー訂正（ＡＬ−ＦＥＣ）符号化／復号化フローに対する概念を示す図である。

【図20A】本発明の実施形態による１ステージ及び２ステージＦＥＣ符号化構造を示す図である。

【図20B】本発明の実施形態による１ステージ及び２ステージＦＥＣ符号化構造を示す図である。

【図21】本発明の実施形態によるＦＥＣ配信ブロック及びＦＥＣ配信クラスター（Delivery Cluster）の構成を示す図である。

【図22】本発明の実施形態によるソースブロックを情報ブロックにマッピングする過程の例を示す図である。

【図23】本発明の実施形態によるソースブロックを情報ブロックにマッピングする過程の例を示す図である。

【図24】本発明の実施形態によるソースブロックを情報ブロックにマッピングする過程の例を示す図である。

【図25】本発明の実施形態によるＲＳフレームの構造を示す図である。

【図26】本発明の実施形態による低密度パリティ検査（ＬＤＰＣ）フレームの構造を示す図である。

【図27】本発明の実施形態によるリードソロモン（ＲＳ）パリティシンボルのためのパリティブロックマッピングを示す図である。

【図28】本発明の実施形態によるＬＤＰＣパリティシンボルのためのパリティブロックマッピングを示す図である。

【図29】本発明の実施形態によるＨマトリックスの構造を示す図である。

【図30】本発明の実施形態によるＦＥＣパケットブロック及びＦＥＣパケットクラスターの構成を示す図である。

【発明を実施するための形態】

【0019】

本発明の上述した及び他の様相、特徴、及び利点は、以下の添付図面が併用された後述の詳細な説明から、より一層明らかになるだろう。図面中、同一の図面参照符号は、同一の構成要素、特性、及び構造を意味することが分かるはずである。

【0020】

添付の図面を参照した下記の説明は、特許請求の範囲の記載及びこれと均等なものの範囲内で定められるような本発明の実施形態の包括的な理解を助けるために提供されるものであり、この理解を助けるために様々な特定の詳細を含むが、単なる１つの実施形態に過ぎない。従って、本発明の範囲及び趣旨を逸脱することなく、ここに説明する実施形態の様々な変更及び修正が可能であるということは、当該技術分野における通常の知識を有する者には明らかである。また、明瞭性と簡潔性の観点から、当業者に良く知られている機能や構成に関する具体的な説明は、省略する。

【0021】

次の説明及び請求項に使用する用語及び単語は、辞典的意味に限定されるものではなく、発明者により本発明の理解を明確且つ一貫性があるようにするために使用する。従って、本発明の実施形態の説明が単に実例を提供するためのものであって、特許請求の範囲とこれと均等なものに基づいて定義される発明を限定する目的で提供するものでないことは、本発明の技術分野における通常の知識を持つ者には明らかである。

【0022】

英文明細書に記載の“ａ”、“ａｎ”、及び“ｔｈｅ”、すなわち単数形は、コンテキスト中に特記で明示されない限り、複数形を含むことは、当業者には理解されることである。したがって、例えば、“コンポーネント表面（a component surface）”との記載は、１つ又は複数の表面を含む。

【0023】

下記では、順方向エラー訂正（ＦＥＣ）符号化方法について説明するが、このような方法によって、リードソロモン（ＲＳ）コード、低密度パリティ検査（ＬＤＰＣ）コード、ターボコード、ラプターコード（Raptor code）、ＸＯＲ、Ｐｒｏ−ＭＰＥＧ ＦＥＣコードを使用する符号化方法が限定されるものではない。

【0024】

本発明の実施形態は、ネットワーク状況又はコンテンツのサービス品質（Quality of Service：ＱｏＳ）に基づいて選択的にＦＥＣを適用することができる方法を提供する。一例として、ここで使用する用語‘ネットワーク状況’は、パケット損失が多いか又は少ないか（例えば、パケット損失率が高いか又は低いか）、又はパケット損失がランダムに発生するか又はバースト形態で発生するかを意味する。

【0025】

ファイルデータについて、送信の間にデータの一部が損失されてはいけない。例えば、オーディオ／ビデオ（Audio/Video：ＡＶ）データについて、送信の間にＡＶデータと関連したデータの一部が損失されるとしても、ＡＶデータを再生することができる。ここで使用される用語‘ＱｏＳ’は、ファイルデータ及びＡＶデータで要求される特性が相互に異なる場合を意味する。したがって、ファイルデータは、一般的にＡＶデータより高いＦＥＣ性能を要求する。

【0026】

図１は、本発明の実施形態によるネットワークトポロジー及びデータフローを示す図である。

【0027】

図１のネットワークトポロジーを参照すると、送信器（例えば、ホストＡ）１０５は、インターネットプロトコル（ＩＰ）パケットを幾つかのルータ１２０及び１３０を通して最終受信器（ホストＢ）１１０に送信する。この時に、送信器１０５により送信されたＩＰパケットは、送信器１０５が送信した順序で最終受信器１１０に常に到達するものではない。このために、ＡＶコンテンツストリーミングの間に送信順序（例えば、 送信器１０５によりＩＰパケットが送信される順序）を示すことは重要である。また、このような送信順序は、データフローで表現される。

【0028】

図１のデータフローを参照すると、アプリケーションステージ１４０において、図１のデータ１５０は、実時間プロトコル（Real Time Protocol：ＲＴＰ）（ＩＥＴＦ ＲＦＣ３５５０及びＲＦＣ３９８４を参照）を使用してＡＶコーデックステージで圧縮されたデータをパケット化することにより生成されたＲＴＰパケットデータとして見なされるか、又は図９を参照して後述するＭＰＥＧメディアトランスポート（MPEG Media Transport：ＭＭＴ）トランスポートパケットデータのようにアプリケーションステージ１４０でのトランスポートプロトコルによりパケット化されたデータを意味する。

【0029】

ここで使用される用語は、次のようにまとめられることができる。
− ＦＥＣ：エラー又は消去シンボルを訂正するためのエラー訂正コード
− ＦＥＣフレーム：保護されるＦＥＣ符号化情報により生成されたコードワードであり、ＦＥＣフレームは、情報パート（information part）及びパリティ（リペア）パートを含む。
− シンボル：データの単位であり、複数のビットでのビットのサイズは、シンボルサイズと呼ばれる。
− ソースシンボル：ＦＥＣフレームの情報パートに含まれる保護されないデータシンボル（Unprotected data Symbol）
− 符号化シンボル：ソースシンボルをＦＥＣ符号化することにより生成されるＦＥＣフレーム
− リペアシンボル：ＦＥＣ符号化によりソースシンボルから生成されるＦＥＣフレームのパリティパートであり、例えば、ＦＥＣにより符号化する間にソースシンボルがそのまま保持されるシステマティック符号化の場合に、符号化シンボル＝ソースシンボル＋リペアシンボルである。
− パケット：ヘッダ及びペイロードを含む送信単位
− ペイロード：送信器から送信されるユーザデータのピース（piece）であり、パケット内に置かれる。
− パケットヘッダ：ペイロードを含むパケットのためのヘッダ
− ソースブロック：１つ以上のソースシンボルを含むシンボルの集合
− リペアブロック：１つ以上のリペアシンボルを含むシンボルの集合
− ＦＥＣブロック：ＦＥＣフレームの集合
− ＦＥＣパケット：ＦＥＣブロックの送信のためのパケット
− ソースパケット：ソースブロックの送信のためのパケット − リペアパケット：リペアブロックの送信のためのパケット
− ＦＥＣ制御パケット：ＦＥＣパケットを制御するためのパケット

【0030】

図２Ａ及び図２Ｂは、Ｍ＝１及びＭ＝８の場合について本発明の実施形態によるＦＥＣ符号化方法を図式化する図である。特に、図２Ａは、Ｍ＝１の場合の符号化構造を示し、図２Ｂは、Ｍ＝８の場合の符号化構造を示す。

【0031】

図２Ｂを参照すると、ネットワーク上で損失されたデータを復旧するためのＦＥＣ符号化方法及びそれによるイン−バンドシグナリング方法は、所定数のシンボルをＭ（ここで、Ｍは、１以上の整数）個の第１のソースシンボルに分割し、第１のソースシンボルのそれぞれに対して第１のＦＥＣ符号化を実行することにより生成される第１のリペアシンボルを含む第１の符号化シンボルを生成する。その後に、この方法は、Ｍ個の符号化シンボルを第２のソースシンボル２０２に分割し、第２のＦＥＣ符号化を実行することにより生成される第２のリペアシンボル２０１を含む第２の符号化シンボル２０３を生成する。

【0032】

本発明の実施形態によれば、第１のＦＥＣ及び第２のＦＥＣは、同一のエラー訂正コード又は異なるエラー訂正コードを使用することができる。これらの候補は、ＲＳコード、ＬＤＰＣコード、ターボコード、ラプターコード、及びＸＯＲのような特定のコードに限定されない。

【0033】

ＦＥＣが適用されたコンテンツを送信器が受信器に送信する場合に、受信器は、ＦＥＣ構成関連情報（例えば、送信器が適用したＦＥＣのタイプ及び構造のような）を有しなければならず、復号化を実行する場合に、送信器が適用したＦＥＣ符号化方式に基づいて復号化を実行することにより損失されたデータを復旧することができる。したがって、本発明の実施形態は、ＦＥＣ構成関連情報を送信するための方法を含む。また、本発明の実施形態は、受信器が、受信されたパケットがソースシンボルのためのペイロードであるか、又はリペアシンボルのためのペイロードであるかを判定することができるようにするパケット識別方法を含む。

【0034】

このために、本発明の実施形態は、ＦＥＣ構成関連情報、第１のＦＥＣ符号化構成、及び第２のＦＥＣ符号化構成を含むＦＥＣ制御情報を定義する。例えば、ＦＥＣ制御情報は、パケット内に含まれることもあり、又はパケットを制御するためのＦＥＣ制御パケットに含まれることもある。アウト−バンドシグナリングの場合に、ＦＥＣが適用されたコンテンツは、実時間トランスポートプロトコル（Real-time Transport Protocol：ＲＴＰ）プロトコルを使用して送信され、この時に、ＦＥＣ制御情報は、ＲＴＰ制御プロトコル（RTP Control Protocol：ＲＴＣＰ）プロトコルを使用して送信されるためにコンテンツ配信のためのプロトコルとは異なる。しかしながら、イン−バンドシグナリングの場合に、ＦＥＣ制御情報は、ＦＥＣが適用されたコンテンツのためのＲＴＰパケット内に記憶されて送信されることにより、異なるプロトコルを使用して送信されない。

【0035】

本発明の実施形態によるＦＥＣ構成関連情報については、次のように説明される。

【0036】

（１）符号化構造
− ＦＥＣ構造：第１のＦＥＣ及び／又は第２のＦＥＣの適用／不適用
− ＦＥＣブロック境界−関連情報（以下、“ＦＥＣブロック境界情報”と呼ばれる）：ＦＥＣブロックの開始位置情報／終了位置情報を示す。

【0037】

アウト−バンドシグナリングの場合に、ＦＥＣブロック境界情報は、ＦＥＣ構成関連情報の送信の後に第１のＦＥＣブロックの開始位置情報／終了位置情報を意味する。ここで使用される用語‘位置’は、ネットワークでの位置を意味する。言い換えれば、ネットワーク上でパケット別に送信順序が番号で決定される場合に、その番号は、この位置に対応する。

【0038】

イン−バンドシグナリングの場合に、ＦＥＣブロック境界情報は、ＦＥＣブロックを運搬するパケットの中の少なくとも１つのパケットに記憶されるか、又はロバスト性（Robustness）のためにすべてのパケットに記憶される。具体的に、ＦＥＣブロック境界情報は、図１０に示すように、下記に説明するパケットヘッダに送信されることが好ましい。

【0039】

（２）第１のＦＥＣ符号化（符号化シンボル１）構成
− ＦＥＣタイプ関連情報（以下、ＦＥＣタイプ情報と称する）：ＧＦ（２^ｎ）上のＲＳ（Ｎ，Ｋ）コード、ＧＦ（２^ｎ）上のＬＤＰＣ（Ｎ，Ｋ）コード、ＧＦ（２^ｎ）上のターボ（Ｎ，Ｋ）コード又はＧＦ（２^ｎ）上のラプター（Ｎ，Ｋ）コードのようなＦＥＣコード（ここで、Ｎは、コード長さを示し、Ｋは、情報長さを示し、２^ｎは、シンボルサイズを示す）を示すか、又は、ＸＯＲ方法を示す。本発明の実施形態によれば、ＦＥＣタイプ情報は、ＦＥＣコードのタイプを示すＩＤ情報（例えば、０＝ＲＳ、１＝ＬＤＰＣ、及び２＝ラプター）とＮ及びＫに関する情報とを含むことができる。

【0040】

− 短縮関連情報：短縮されたシンボルの個数、短縮パターン（短縮されたシンボルの位置情報）に関する情報を示す。短縮パターンが固定される場合に、短縮パターンに関する情報は省略される。実際に送信される情報の長さがＫ−ｓである場合に、ｓ個のパッディングシンボルを追加した後に符号化され、符号化されたＮ個のシンボルの中で、パッディングされたｓ個のシンボルは、送信される必要がないので、（Ｎ−ｓ）個のシンボルだけが送信される。この場合に、ｓ個のシンボルの短縮が発生する。本発明の実施形態によれば、受信器は、ＦＥＣタイプ関連情報、ＦＥＣタイプ関連情報に基づいて実際に送信される情報の長さに関する情報、及びコード内での短縮された位置に関する情報を有することができる。他方、本発明の実施形態によれば、短縮関連情報は、実際に送信される情報の長さＫ−ｓ、及び短縮パターン（例えば、短縮されたシンボルの位置情報）に関する情報を示す。一例として、短縮パターンが固定される場合に、短縮パターンに関する情報は省略される。

【0041】

− パンクチャーリング関連情報：パンクチャーリングされたシンボルの個数、パンクチャーリングパターン（例えば、パンクチャーリングされたシンボルの位置情報）に関する情報を示す。パンクチャーリングパターンが固定される場合に、パンクチャーリングパターンに関する情報は省略される。符号化されたコードワードのＮ−Ｋパリティ内のｐ個のシンボルが送信の間に抜けている場合に、ｐ個のシンボルのパンクチャーリングが発生した。本発明の実施形態によれば、受信器は、ＦＥＣタイプ関連情報と、ＦＥＣタイプ関連情報に基づいて実際に送信されるパリティ（例えば、リペア）シンボルの個数に関する情報と、コード内のパンクチャーリング位置に関する情報とを有することができる。他方、本発明の実施形態によれば、パンクチャーリング関連情報は、実際に送信されるパリティの長さＮ−Ｋ−ｐ、パンクチャーリングパターン（パンクチャーリングされたシンボルの位置情報）に関する情報を示す。一例として、パンクチャーリングパターンが固定される場合に、パンクチャーリングパターンに関する情報は省略される。

【0042】

ＦＥＣタイプ関連情報のコード長さ、情報長さ、及び短縮／パンクチャーリング関連情報から、実際に送信される符号化シンボル、ソースシンボル、及びリペアシンボルの個数をそれぞれ確認することができる。ＦＥＣタイプ関連情報及び短縮／パンクチャーリング関連情報は、コードワードの見方から説明されたが、ここに限定されない。好ましくは、ＦＥＣタイプ関連情報及び短縮／パンクチャーリング関連情報は、本発明の実施形態の趣旨に基づく情報として解釈されることができる。例えば、ＦＥＣタイプ関連情報及び短縮／パンクチャーリング関連情報は、ＦＥＣブロックのソースブロックを運搬するパケットの個数（＝Ｋ−ｓ）及びパリティブロックを運搬するパケットの個数（＝Ｎ−Ｋ−ｐ）として解釈されることができる。

【0043】

− リフティング関連情報：ＦＥＣコードでの拡張又は縮小を示す値である。ここで使用される用語‘リフティング’は、ＱＣ−ＬＤＰＣの置換ブロック（permutation block）のサイズを調節することによりコードの長さの拡張又は縮小を意味する。本発明の実施形態によれば、一般的なパリティチェックマトリックス（Parity Check Matrix）Ｈにおいて、各エントリー（entry）を置換ブロックに変更することによりマトリックスを拡張することもリフティングに含まれる。ここで、Ｎ個の符号化シンボル１のそれぞれに適用された第１のＦＥＣの符号化構成関連情報が異なる場合に、符号化シンボル１のそれぞれに対して第１のＦＥＣ符号化構成が必要とされる。

【0044】

この場合に、‘ｆｏｒ（ｉ＝１；ｉ＜＝Ｎ；ｉ＋＋）｛ｉ番目の符号化シンボル１構成｝’として示すことができる。

【0045】

（３）第２のＦＥＣ符号化（符号化シンボル２）構成
本発明の実施形態によれば、第２のＦＥＣ符号化構成は、第１のＦＥＣ符号化構成と同一である。

【0046】

下記では、本発明の実施形態によるパケット識別方法について説明する。

【0047】

ＲＴＰプロトコルのヘッダは、ペイロードタイプフィールド及びシーケンス番号フィールドを含む。ペイロードタイプフィールド及びシーケンス番号フィールドを有するＲＴＰプロトコル又はこれと類似したトランスポートプロトコルを使用する場合に、このシーケンス番号が１ずつ増加することができるように連続的にかつ順次的に番号を各ＦＥＣパケットに割り当てる。したがって、ＦＥＣ構成関連情報及び受信されたパケットのシーケンス番号に基づいて、パケットがソースパケットであるか、リペア１パケットであるか、又はリペア２パケットであるかを確認することができるだけでなく、損失されたパケットがどんなパケットであるかを正確に確認することができる。他方、図１０のＦＥＣパケットヘッダ１０１０内のペイロードタイプ情報フィールド１０１２に基づいて、ＦＥＣパケット内のペイロードがソースペイロードであるか、リペア１パケットであるか、又はリペア２パケットであるかを確認することができる。

【0048】

図１０のＦＥＣパケットヘッダ１０１０のパケット長さフィールド１０１５は、パケットにより実際に運搬されるパケットデータのサイズを示すように構成されることができる。パケット長さフィールド１０１５を用いてパケット間の境界を確認することができるので、連続したパケットストリームを正確に受信することができる。また、パケットが損失されるとしても、ＦＥＣ復号化により損失されたパケットのヘッダ情報をまず復旧することにより対応するパケットの長さを把握することができ、これにより、対応するパケットの長さを正確に把握することができる。

【0049】

下記では、本発明の実施形態によるアウト−バンドシグナリング方法について説明する。

【0050】

送信器と受信器間のコンテンツ配信において、コンテンツを配信するためのパケットとこれらのパケットを制御するための制御パケットとに区分される。アウト−バンドシグナリングは、ＦＥＣブロックを送信するためのパケット（以下、ＦＥＣパケットと称する）を制御するためのＦＥＣ制御パケットを用いてＦＥＣパケットに関するＦＥＣ構成関連情報を配信することを意味する。送信器がコンテンツを受信器に配信する前に、送信器は、コンテンツに適用されたＦＥＣ構成関連情報を受信器があらかじめ認識することができるようにするためにＦＥＣ構成関連情報を送信する。このような情報は、ＦＥＣ構成関連情報の変更の時に送信されなければならない。また、マルチキャスティング（Multicasting）又はブロードキャスティング（Broadcasting）のような複数の受信器がある場合に、ＦＥＣ構成関連情報は、ＦＥＣ制御パケットを通して送信されるので、すべての受信器は、コンテンツに適用されたＦＥＣ構成関連情報を認識することによりＦＥＣ復号化を実行することができる。他方、ＦＥＣ構成関連情報は、ロバスト性のために周期的に反復して送信されることができる。

【0051】

本発明の実施形態によるアウト−バンドシグナリングの主な目的は、受信器がＦＥＣブロックの復号化のための最小の情報である第１のＦＥＣの適用／不適用及び／又は第２のＦＥＣの適用／不適用をＦＥＣ制御情報（例えば、ＦＥＣ構成関連情報又は符号化構成関連情報）に基づいて判定することができるようにする。したがって、送信器は、４つの場合、すなわち、ＦＥＣの不適用、第１のＦＥＣだけの適用、第２のＦＥＣだけの適用、及び第１及び第２のＦＥＣの適用の中の１つを決定するか又は選択し、これをＦＥＣ制御情報を通して受信器に送信した後に、この決定されたＦＥＣ方法を適用することによりコンテンツを配信する。

【0052】

本発明の実施形態によれば、ＦＥＣ制御情報は、ＦＥＣブロックの開始／終了位置のようなブロック境界情報を追加で含むことができる。ＦＥＣ方法が予め定められた場合に、受信器は、ＦＥＣブロックのサイズ又は長さを分かるために、開始／終了位置情報だけでも十分に全ＦＥＣブロック境界情報を把握することができる。

【0053】

本発明の実施形態によれば、様々なタイプの第１のＦＥＣが存在する場合又は様々なタイプの第２のＦＥＣが存在する場合に、ＦＥＣ制御情報は、第１のＦＥＣタイプ情報及び第２のＦＥＣタイプ情報を含むことが好ましい。

【0054】

送信器が効率的な送信のために短縮又はパンクチャーリングを実行すべきである場合に、ＦＥＣ制御情報は、短縮及び／又はパンクチャーリング関連情報を含むことが好ましい。

【0055】

また、ＦＥＣ制御情報は、周期的に送信されることが好ましい。例えば、ＦＥＣ制御情報は、周期的に反復して送信されることが好ましい。

【0056】

図３は、本発明の実施形態によるアウト−バンドシグナリングのためのＦＥＣ制御パケットの構造を示す図である。

【0057】

図３に示すように、ＦＥＣ制御パケット３００は、符号化構成関連情報のためのＦＥＣ制御パケット（例えば、ペイロード）及びこのためのヘッダ（図示せず）を含む。

【0058】

ＦＥＣ制御情報は、セッションディスクリプションプロトコル（Session Description Protocol：ＳＤＰ）に基づく送信器報告が受信器に送信される時に含まれるか、又はＲＴＰを使用する場合にＲＴＣＰプロトコルに基づいてＲＴＰ制御情報を送信する時に含まれることができる。また、ＦＥＣ制御情報は、電子サービスガイド（Electric Service Guide：ＥＳＧ）の送信の間に含まれるか、又は送信の間に、ＩＳＯ基盤メディアファイルフォーマット（ISO Base Media File Format）を使用する場合に“ｆｐａｒ”ボックス及び“ｆｅｃｒ”ボックスに含まれることができ、配信されたコンテンツのタイプ、ネットワーク環境、及び使用中のトランスポートプロトコルにより可能なタイプが様々である。また、ＦＥＣ制御情報は、図３に示すように、ＦＥＣ制御ペイロードに含まれることもあるが、これに限定されない。アウト−バンドシグナリングの場合に、ＦＥＣ制御情報は、符号化構造フィールド３１０に含まれたＦＥＣ構成関連情報、第１のＦＥＣ符号化構成３２０、及び第２のＦＥＣ符号化構成３３０を含む。

【0059】

ＦＥＣ構成関連情報は、第１のＦＥＣ及び／又は第２のＦＥＣの適用／不適用を示す情報３１０ａを含む。ＦＥＣ構成関連情報は、ＦＥＣ構造＝００（例えば、符号化なしの場合）、ＦＥＣ構造＝０１（例えば、第１のＦＥＣだけ適用される場合）、ＦＥＣ構造＝１０（例えば、第２のＦＥＣだけ適用される場合）、及びＦＥＣ構造＝１１（第１及び第２のＦＥＣの両方とも適用される場合）で示される。２つのＦＥＣ（第１及び第２のＦＥＣ）の中の１つのみ適用される場合は、１つのフィールド値で示されることもある。

【0060】

ＦＥＣ構成関連情報は、ＦＥＣブロック境界情報３１０ｂを含む。

【0061】

第１のＦＥＣ符号化構成３２０は、ＦＥＣタイプ関連情報３２０ａ、リフティング関連情報３２０ｂ、パンクチャーリング関連情報３２０ｃ、及び短縮関連情報３２０ｄを含む。

【0062】

リフティング関連情報は、コードの拡張又は縮小を可能にし、短縮／パンクチャーリング関連情報は、与えられたコード内で様々な長さのソースシンボル及びパリティシンボルの対応を可能にする。

【0063】

第２のＦＥＣ符号化構成３３０は、第１のＦＥＣ符号化構成３２０と同一である。

【0064】

下記では、本発明の実施形態によるイン−バンドシグナリング方法について説明する。

【0065】

図４は、本発明の実施形態によるイン−バンドシグナリングのためのＦＥＣ制御パケットの構造を示す図である。

【0066】

ＦＥＣ制御パケットは、ＦＥＣペイロード４００及びヘッダ４１０を含む。図４には、リペアパケットが示されるが、ＦＥＣ制御パケットは、これに限定されない。言い換えれば、図４のＦＥＣ制御パケット構造は、ロバスト性のためにＦＥＣパケットに適用されることができる。図４では、ＦＥＣ制御情報がヘッダ４１０に含まれるが、ＦＥＣ制御パケットは、これに限定されない。言い換えれば、イン−バンドシグナリングのためのＦＥＣ制御情報は、ロバスト性のために、送信の間にＦＥＣブロックの送信のためのすべてのパケットに記憶されることができる。また、ＦＥＣ構造のために必要とされる情報だけが送信効率を向上させるように含まれることができる。

【0067】

コンテンツ配信のためのパケットとは識別可能な個別の制御パケット内にＦＥＣ構成関連情報を送信するアウト−バンドシグナリングとは異なり、イン−バンドシグナリングは、コンテンツ配信のためのパケット内にＦＥＣ構成関連情報を送信することにより、反復的なかつ周期的なＦＥＣ制御パケットによるオーバーヘッドを最小にすることができる。また、イン−バンドシグナリングは、受信器がＦＥＣ制御パケット送信期間の中間にもコンテンツに適用されたＦＥＣ構成関連情報を迅速に把握することができるという長所がある。

【0068】

本発明によるイン−バンドシグナリングの主な目的は、ＦＥＣブロックの復号化のための最小情報である第１のＦＥＣの適用／不適用及び／又は第２のＦＥＣの適用／不適用を示すＦＥＣ構成関連情報を送信の間にＦＥＣパケット内に記憶させ、これにより、受信器がその情報を把握することができることにある。したがって、４つの場合、すなわち、ＦＥＣの不適用、第１のＦＥＣだけの適用、第２のＦＥＣだけの適用、及び第１及び第２のＦＥＣの適用の中の１つを決定するか又は選択し、この決定されたＦＥＣ方法に基づいてコンテンツをＦＥＣ符号化した後に、ＦＥＣパケットを送信する場合に、送信器は、図４の例に示すように、送信されるＦＥＣパケット内にＦＥＣ構成関連情報を記憶する。

【0069】

本発明の実施形態によれば、ＦＥＣ構成関連情報は、シーケンス番号４１１、符号化構造フィールド４１２、及びＦＥＣ符号化構成フィールド４１３を含む。

【0070】

ＦＥＣ構成関連情報は、第１のＦＥＣ及び／又は第２のＦＥＣの適用／不適用を示す情報４１２ａを含む。ＦＥＣ構成関連情報は、ＦＥＣ構造＝００（例えば、符号化なしの場合）、ＦＥＣ構造＝０１（例えば、第１のＦＥＣだけ適用される場合）、ＦＥＣ構造＝１０（例えば、第２のＦＥＣだけ適用される場合）、及びＦＥＣ構造＝１１（第１及び第２のＦＥＣの両方とも適用される場合）で示される。具体的に、ＦＥＣ構成関連情報は、送信の間に、ＦＥＣブロックのためのＦＥＣパケットの中の少なくとも１つのパケットに記憶される。より具体的に、パケット損失に対するロバスト性のために、ＦＥＣ構成関連情報は、送信の間に、すべてのパケットに記憶されるか、又はリペアパケット又はソースパケットに記憶されることができる。例えば、ＦＥＣ構成関連情報は、送信の間に、パケットヘッダに記憶されるか、又は、もっと具体的に、リペアパケットヘッダに記憶されることができる。ＦＥＣ構成関連情報が送信の間にリペアパケットヘッダに記憶される場合に、ソースパケットは、ＦＥＣが適用されない場合と同一にソースシンボルを送信するための既存のパケット形態で送信されることができるので、ＦＥＣが適用されないシステムとの互換性を保持することができる。

【0071】

好ましくは、ＦＥＣ構成関連情報は、ＦＥＣブロックの開始／終了位置のようなＦＥＣブロック境界情報４１２ｂを追加で含むことができる。ＦＥＣ方法が予め定められる場合に、受信器は、ＦＥＣブロックのサイズ又は長さを分かるために、ＦＥＣブロックの開始／終了位置情報だけでも十分に全ＦＥＣブロック境界情報を把握することができる。

【0072】

好ましくは、ＦＥＣ構成関連情報は、符号化構造フィールド４１２に含まれ、次のＦＥＣブロックに関するＦＥＣ構成関連情報が現在のＦＥＣブロックに基づいて変更されるか否かを示すＦＥＣ構成連続フラグ４１２ｃを含むことができる。

【0073】

本発明の実施形態によれば、ＦＥＣ符号化構成関連情報４１３は、ＦＥＣ符号化構成フィールドに含まれ、幾つかの第１のＦＥＣタイプ又は幾つかの第２のＦＥＣタイプが存在する場合に、第１のＦＥＣタイプ情報及び第２のＦＥＣタイプ情報を含むＦＥＣタイプ情報４１３ａを含むことができる。

【0074】

本発明の実施形態によれば、ＦＥＣ符号化構成関連情報は、与えられたＦＥＣタイプ情報に対して、送信の間にコードを拡張するか又は縮小するためにリフティング関連情報４１３ｂを含むことができる。

【0075】

本発明の実施形態によれば、ＦＥＣ符号化構成関連情報は、送信器が効率的な送信のために短縮又はパンクチャーリングを実行する場合に、短縮関連情報４１３ｃ及び／又はパンクチャーリング関連情報４１３ｄを含むことができる。

【0076】

リフティング関連情報４１３ｂは、コードの拡張又は縮小を可能にし、短縮／パンクチャーリング関連情報は、与えられたコード内で様々な長さのソースシンボル及びパリティシンボルの対応を可能にする。

【0077】

図５は、本発明の実施形態によるアウト−バンドシグナリングのためのシステム構成を示す図である。

【0078】

ディジタルカメラを用いて撮影したロー（Raw）ＡＶストリーム１は、ローＡＶコンテンツ５０１として有効に記憶される。ローＡＶコンテンツ５０１（例えば、ローＡＶストリーム１）は、ＡＶコーデックエンコーダ５０３に送信される。

【0079】

ＡＶコーデックエンコーダ５０３は、オーディオコーデックエンコーダ及びビデオコーデックエンコーダを使用して入力されるローＡＶストリーム１を圧縮することによりＡＶストリーム２を生成し、ＡＶストリーム２をトランスポートプロトコルパケタイザ（Transport Protocol Packetizer）５０５に出力する。

【0080】

トランスポートプロトコルパケタイザ５０５は、圧縮されたＡＶストリーム２をペイロード単位に分け、パケットヘッダをペイロードのそれぞれに付加することによりパケット化されたストリームを作る。ＦＥＣを適用する場合に、トランスポートプロトコルパケタイザ５０５は、関連する符号化構造及び／又は符号化構成関連情報によりパケットストリームを所定数のソースパケットに分ける。その後に、トランスポートプロトコルパケタイザ５０５は、ソースパケットのヘッダを除外したソースペイロードを含むソースブロック３をＦＥＣエンコーダ５０７に入力する。

【0081】

ＦＥＣエンコーダ５０７は、符号化構造及び／又は符号化構成関連情報に合うようにソースブロック３を符号化し、ＦＥＣブロック４をトランスポートプロトコルパケタイザ５０５に出力する。

【0082】

トランスポートプロトコルパケタイザ５０５は、入力されたＦＥＣブロック４内の各ペイロードにパケットヘッダを付加することによりＦＥＣ符号化されたパケットストリーム７を送信し、図３で説明したように、ＦＥＣ制御パケット（ペイロード又はヘッダ）内にアウト−バンドシグナリングのためのＦＥＣ構成関連情報を記憶する。

【0083】

コンテンツに適用された符号化構造及びＦＥＣ符号化構成関連情報は、ＦＥＣ制御パケット５に記憶され、コンテンツの配信の前に受信器にあらかじめ送信され、したがって、受信器がコンテンツに適用されるＦＥＣ構造及び／又はＦＥＣ符号化構成関連情報を把握することができるようにする。

【0084】

本発明の実施形態によれば、ＦＥＣ制御パケット内のＦＥＣ構造及びリペアパケットヘッダ内のＦＥＣ構造のための２ビットを割り当てることにより、ｂ０は、第１のＦＥＣの適用／不適用を示し、ｂ１は、第２のＦＥＣの適用／不適用を示す。言い換えれば、ビットは、符号化なしに対応するＦＥＣ構造＝００、第１のＦＥＣだけの適用に対応するＦＥＣ構造＝０１、第２のＦＥＣだけの適用に対応するＦＥＣ構造＝１０、及び第１及び第２のＦＥＣの適用に対応するＦＥＣ構造＝１１で示す。

【0085】

送信の間に、ＦＥＣブロック境界情報は、ＦＥＣ制御パケットの送信の直後に送信されるＦＥＣ符号化ブロックの第１のペイロードのためのパケットのシーケンス番号を指定する。

【0086】

トランスポートプロトコルデパケタイザパケタイザ（Transport Protocol De-packetizer）５０９は、ＦＥＣ制御パケット６を受信し、受信されるコンテンツのＦＥＣ構成関連情報に基づいてＦＥＣ復号化を準備する。コンテンツのサービスの間にサービングに参加した受信器は、受信されたパケットのリペアパケットヘッダからＦＥＣ構成関連情報を取得し、これに基づいてＦＥＣ復号化を実行する。

【0087】

トランスポートプロトコルデパケタイザ５０９は、受信されたパケットストリームからパケットを送信順序で再配列した後に、パケットからヘッダを除去することによりペイロードストリームを作る。ＦＥＣが適用される場合に、トランスポートプロトコルデパケタイザ５０９は、コンテンツに適用されたＦＥＣ構成関連情報に基づいて受信されたＦＥＣ符号化されたパケットストリーム８から損失されたパケットの位置情報及びＦＥＣブロック境界情報を把握する。また、トランスポートプロトコルデパケタイザ５０９は、この損失されたパケットの位置情報及びＦＥＣブロック境界情報に基づいて、各ＦＥＣブロックに対応する損失されたペイロードの位置情報及び受信されたＦＥＣブロック９をＦＥＣデコーダ５１１に入力する。

【0088】

また、パケット識別方法のように、シーケンス番号フィールドがトランスポートパケットのヘッダ内に構成され、パケット送信の間に、番号がパケット送信順序に合うように連続して割り当てられる場合に、トランスポートプロトコルデパケタイザ５０９は、受信の間に、シーケンス番号に基づいて送信パケットの順序に合うように再配列し、損失されたパケットの位置（例えば、番号）を把握することができる。

【0089】

ＦＥＣデコーダ５１１は、ＦＥＣ復号化を通して損失されたペイロードの位置情報及び受信されたＦＥＣブロックから損失されたペイロードを復旧することによりソースブロック１０を復元し、これをトランスポートプロトコルデパケタイザ５０９に入力する。

【0090】

トランスポートプロトコルデパケタイザ５０９は、入力されたソースブロックをストリーム１１に変換し、ストリーム１１をＡＶコーデックデコーダ５１３に入力する。

【0091】

ＡＶコーデックデコーダ５１３は、オーディオコーデックデコーダ及びビデオコーデックデコーダを用いてＡＶコンテンツを復号化し、この復号化されたＡＶコンテンツをストリーム１２としてディスプレー５１５に入力する。

【0092】

ディスプレー５１５は、復号化されたＡＶコンテンツをディスプレーする。

【0093】

本発明の実施形態によれば、ＦＥＣが適用されない（すなわち、ＦＥＣ構造＝“符号化なし”）場合に、トランスポートプロトコルパケタイザ５０５がソースブロック３をＦＥＣエンコーダ５０７に入力する過程１と、ＦＥＣエンコーダ５０７が符号化構造及び／又は符号化構成関連情報に合うようにソースブロックを符号化し、ＦＥＣブロック４をトランスポートプロトコルパケタイザ５０５に出力する過程２と、受信器での過程１及び過程２の逆過程が省略される。

【0094】

ＦＥＣ制御パケット５及び６は、コンテンツ配信の間に周期的に反復して送信される。ＦＥＣが適用される場合に、ＦＥＣ構成関連情報に含まれたＦＥＣブロック境界情報は、ＦＥＣ制御パケットの送信の直後に送信されるＦＥＣ符号化ブロックの第１のペイロードのためのパケットのシーケンス番号を指定する。

【0095】

パケットヘッダ７及び８内のＦＥＣブロック境界情報は、送信の間に、対応するＦＥＣブロックの第１のペイロードのためのパケットのシーケンス番号を指定する。

【0096】

ＦＥＣブロック境界情報及びＦＥＣ符号化構成関連情報は、送信器と受信器間で相互に約束されている場合に（例えば、ＦＥＣのＦＥＣタイプが送信器と受信器間で相互に約束されており、リフティング値、送信情報シンボルの長さ、及びリペアシンボルの長さが固定される場合に）、省略されて送信される。

【0097】

本発明の実施形態によれば、ＦＥＣタイプ情報に基づく各コードがパリティチェックマトリックスを使用する場合に、そのマトリックスは予め約束されており、ＲＳコードを使用する場合に、その生成多項式（Generator Polynomial）は、予め定められているものと仮定する。例えば、ＦＥＣタイプ情報が“ＧＦ（２）上のＬＤＰＣ（８０００，６４００）コード”を示す場合に、送信器及び受信器は、コードのマトリックスＨを共有するものと仮定する。ＦＥＣタイプ情報が“ＧＦ（２^８）上のＲＳ（２５５，５１）コード”を示す場合に、送信器及び受信器は、ＲＳコードの生成多項式ｇ（ｘ）を共有するものと仮定する。このような仮定は、送信器と受信器間の約束又は仕様で定められることにより可能である。

【0098】

図６は、本発明の実施形態によるイン−バンドシグナリングのためのシステム構成を示す図である。

【0099】

本発明の実施形態によれば、図６のイン−バンドシグナリングのためのシステムにおいて、過程５及び６は省略され、図５の過程７乃至１２は、図６の過程５乃至１０にそれぞれ対応し、この過程と同一である。しかしながら、図６の過程５及び６において、提案されたＦＥＣ構成情報は、送信の間にＦＥＣパケットのパケットヘッダに記憶される。

【0100】

本発明の実施形態は、ソースパケットのペイロードがＦＥＣ保護されているという仮定に基づいて説明されたが、これに限定されず、ソースパケットに対するＦＥＣ符号化を実行した後にヘッダをリペアブロックに付加することによりＦＥＣパケットを生成し、ＦＥＣパケットを送信することを含む。例えば、この場合に、トランスポートパケタイザは、ソースブロックのためのパケットヘッダにＦＥＣ制御情報を保存した後に符号化を実行し、リペアブロックのためのパケットのヘッダにも同一の情報を保存するか又は必要な情報を保存する。

【0101】

図５及び図６を参照してＡＶデータが説明されたが、本発明の実施形態は、これに限定されない。本発明の実施形態は、ハイブリッドコンテンツ配信（Hybrid Content Delivery）のようにＡＶデータ及びファイルデータがともに送信される場合も適用されることができる。この場合に、ソースブロックは、ＡＶデータ及びファイルデータを含む。

【0102】

図７は、本発明の実施形態による送信方法を示すフローチャートである。

【0103】

ステップ７０１において、送信器は、本発明の実施形態によるＦＥＣ制御情報を生成する。本発明の実施形態に従って、ＦＥＣ制御情報は、ＦＥＣ構成関連情報、第１のＦＥＣ符号化構成関連情報、及び第２のＦＥＣ符号化構成関連情報を含む。しかしながら、本発明の実施形態は、これに限定されない。アウト−バンドシグナリングの場合に、ＦＥＣ構成関連情報、第１のＦＥＣ符号化構成関連情報、及び第２のＦＥＣ符号化構成関連情報は、図３に示すように、ＦＥＣ制御パケット３００に含まれる。しかしながら、イン−バンドシグナリングの場合に、ＦＥＣ構成関連情報、第１のＦＥＣ符号化構成関連情報、及び第２のＦＥＣ符号化構成関連情報は、図４に示すように、リペアパケット（例えば、ヘッダ及びリペアペイロードのすべて）に含まれる。

【0104】

ステップ７０３において、送信器は、生成されたＦＥＣ構成関連情報、第１のＦＥＣ符号化構成関連情報、及び第２のＦＥＣ符号化構成関連情報を含むパケットを生成し、このパケットを受信器に送信する。

【0105】

図８は、本発明の実施形態による受信方法を示すフローチャートである。

【0106】

ステップ８０１において、受信器は、送信器からパケットを受信し、受信されたパケットを復調する。ステップ８０３において、受信器は、復調されたパケット（ＦＥＣ制御パケット又はリペアパケット）からＦＥＣ構成関連情報、第１のＦＥＣ符号化構成関連情報、及び第２のＦＥＣ符号化構成関連情報を取得し、受信されたパケット関連情報を認識する。パケット関連情報は、それぞれのＦＥＣブロックに対応する損失されたペイロードの位置情報及び受信されたＦＥＣブロック情報を含む。したがって、受信器は、パケット情報に基づいて、受信されたパケットがソースシンボルのためのパケットであるか、又はリペアシンボルのためのパケットであるかを判定することができる。また、受信器は、送信器により適用されたＦＥＣのタイプ及び構造を把握することができる。ステップ８０５において、受信器は、このパケットを復号する。

【0107】

本発明の実施形態は、配信されるコンテンツ（ＡＶデータ、ファイル、テキストなどを含む）に第１のＦＥＣの適用／不適用及び第２のＦＥＣの適用／不適用を示すＦＥＣ構成関連情報を含む。アウト−バンドシグナリングの場合に、ＦＥＣ構成関連情報のためのプロトコルは、コンテンツ配信のためのプロトコルとは識別されることが好ましい。ＦＥＣが適用されたコンテンツがＲＴＰプロトコルを使用して配信される場合に、ＦＥＣ制御情報は、ＲＴＣＰプロトコルを使用して送信されるためにコンテンツ配信のためのＲＴＰプロトコルとは異なる。しかしながら、イン−バンドシグナリングの場合に、ＦＥＣ制御情報は、送信の間にＦＥＣが適用されたコンテンツのためのＲＴＰパケット内に記憶され、これにより、異なるプロトコルを使用して送信されない。ＭＭＴトランスポートプロトコルを使用して送信される場合に、アウト−バンドシグナリングのためのＦＥＣ制御情報は、ＭＭＴトランスポート制御プロトコルにより送信される。

【0108】

本発明の実施形態によれば、ＦＥＣ構成関連情報は、コンテンツをペイロードに分け、これをＦＥＣ符号化することにより得られたＦＥＣブロックのブロック境界情報を含むことができる。アウト−バンドシグナリングの場合に、ブロック境界情報は、ＦＥＣ構成情報の送信の直後に１番目のＦＥＣブロックの開始パケット／終了パケットの番号を含む。ＦＥＣ構成関連情報は、ＦＥＣタイプ関連情報、リフティング関連情報、短縮関連情報、及びパンクチャーリング関連情報の中の少なくとも１つを含む。第１のＦＥＣのためのＦＥＣタイプ情報及び第２のＦＥＣのためのＦＥＣタイプ情報の中の１つは、ＧＦ（２^ｎ）上のＲＳ（Ｎ，Ｋ）コード、ＧＦ（２）上のＬＤＰＣ（Ｎ，Ｋ）コード、ＧＦ（２）上のターボ（Ｎ，Ｋ）コード、ＧＦ（２）上のラプター（Ｎ，Ｋ）コード、及びＧＦ（２^ｍ）上のラプターＱ（Ｎ，Ｋ）コードの中の少なくとも１つを含み、ここで、ｎ及びｍは、１より大きい整数である。

【0109】

イン−バンドシグナリングの場合に、ＦＥＣ構成関連情報は、送信の間に、ＦＥＣ保護（‘符号化なし’を含む）が行われたコンテンツの配信のためのパケット内に記憶される。第１のＦＥＣが配信されるコンテンツに適用されるか又は第２のＦＥＣがコンテンツに適用されるかを示すＦＥＣ構成関連情報のためのプロトコルがコンテンツに適用されるために、ＦＥＣが適用されたコンテンツ（‘符号化なし’を含む）のためのプロトコルとは識別可能なプロトコルを使用するか又は同一のプロトコルを使用することができる。また、ＦＥＣ構成関連情報は、ＦＥＣが適用されたコンテンツの配信のためのパケット内に送信される。

【0110】

図９は、本発明の実施形態によるＭＭＴシステム構造を示す図である。

【0111】

図９の左側は、ＭＭＴシステム構造を示し、図９の右側は、配信機能の詳細構造を示す図である。

【0112】

メディアコーディングレイヤー９０５は、オーディオ及び／又はビデオデータを圧縮し、圧縮されたデータをカプセル化機能レイヤー９１０に送信する。

【0113】

カプセル化機能レイヤー９１０は、圧縮されたオーディオ／ビデオデータをファイルフォーマットと類似した形態でパッケージとして生成し、パケット化されたデータを配信機能９２０に出力する。

【0114】

配信機能９２０は、カプセル化機能レイヤー９１０の出力をＭＭＴペイロードフォーマットに変換した後に、ＭＭＴトランスポートパケットヘッダを付加し、これをＭＭＴトランスポートパケットの形態でトランスポートプロトコル９３０に出力するか、又は、カプセル化機能レイヤー９１０の出力を既存のＲＴＰプロトコルを使用してＲＴＰパケットの形態でトランスポートプロトコル９３０に出力する。その後に、トランスポートプロトコル９３０は、その入力をＵＤＰ及びＴＣＰトランスポートプロトコルの中の１つに変換した後に、これをインターネットプロトコル９４０に送信する。

【0115】

最終的に、インターネットプロトコル９４０は、トランスポートプロトコル９３０の出力をＩＰパケットに変換する。

【0116】

提案されたＦＥＣパケットは、ＭＭＴペイロードフォーマット、ＭＭＴトランスポートパケット、及びＲＴＰパケットの中の少なくとも１つの形態で送信されることができる。

【0117】

図１０は、本発明の実施形態によるイン−バンドシグナリングのためのＦＥＣ制御パケットの構造を示す図である。

【0118】

イン−バンドシグナリングの場合に、ＦＥＣ制御情報は、ＦＥＣブロックを運搬するパケットの中の少なくとも１つのパケットに記憶されるか、又はロバスト性のためにすべてのパケットに記憶される。図１０に示すように、ＦＥＣ制御情報は、パケットヘッダ１０１０を通して送信されることが好ましいが、これに限定されない。

【0119】

ＦＥＣ制御パケットは、図１０に示すように、符号化構成関連情報の符号化のためのＦＥＣ制御ペイロード１０００及びヘッダ１０１０を含む。

【0120】

パケットヘッダ１０１０は、ペイロードタイプ１０１２、シーケンス番号１０１４、パケット長さ１０１５、符号化構造フィールド１０１６、及びＦＥＣ符号化構成フィールド１０１８を含む。

【0121】

ペイロードタイプ１０１２は、ＦＥＣパケット内のペイロードがソースペイロードであるか、リペア−１パケットであるか、又はリペア−２パケットであるかを示す。

【0122】

シーケンス番号１０１４は、１ずつ増加するように各ＦＥＣパケットに連続的にかつ順次的に割り当てられる番号を示す。

【0123】

パケット長さ１０１５は、対応するパケットが実際に運搬するパケットデータのサイズを示す。イン−バンドシグナリングの場合に、アウト−バンドシグナリングの場合とは異なり、ＦＥＣパケットヘッダのパケット長さフィールド１０１５が追加される。パケット長さ１０１５を使用してパケット間の境界を分かるために、連続したパケットストリームを正確に受信することができる。また、パケット長さ１０１５を使用してパケットが損失されるとしても、ＦＥＣ復号化により損失されたパケットのヘッダ情報をまず復旧し、このヘッダ情報により対応するパケットの長さを把握した後に、対応するパケットの長さ情報を正しく得ることができる。

【0124】

符号化構造フィールド１０１６は、第１のＦＥＣの適用／不適用及び／又は第２のＦＥＣの適用／不適用を示すＦＥＣ構成関連情報１０１６ａ、ＦＥＣブロック境界関連情報１０１６ｂ、及びＦＥＣ構成連続フラグ１０１６ｃを含む。

【0125】

ＦＥＣ符号化構成フィールド１０１８は、ＦＥＣタイプ関連情報１０１８ａ、リフティング関連情報１０１８ｂ、短縮関連情報１０１８ｃ、及びパンクチャーリング関連情報１０１８ｄを含む。

【0126】

下記では、本発明の実施形態によるアプリケーションレイヤー順方向エラー訂正（ＡＬ−ＦＥＣ）シグナリング方法について説明する。

【0127】

１．損失モデル
ＡＬ−ＦＥＣのためのチャネルモデルについて、２種類の損失モデルは、下記のように仮定することができる。

【0128】

通常、ネットワークでの消去は、ランダムにだけでなくバースト方式でも発生するために、ランダム＋バースト消去チャネルモデルを仮定することが好ましい。

【0129】

ＤＶＢ ＡＬ−ＦＥＣブルーブック（Bluebook）に明示されたＲＥＩＮ消去チャネルは、ランダム消去チャネルと結合されることができる。反復電気インパルス雑音（ＲＥＩＮ）チャネルは、ディジタル加入者回線（Digital Subscriber Line：ＤＳＬ）ラインで８ｍｓの固定されたタイムバースト消去（fixed time burst erasure）を引き起こすことがある。

【0130】

１．１ ランダム＋ＲＥＩＮ消去チャネルモデル
− 反復電気インパルス雑音（ＲＥＩＮ）：固定されたタイムバースト消去（８ｍｓ）

【0131】

図１１は、本発明の実施形態による２状態ギルバート−エリオット消去チャネル（Gilbert-Elliot Erasure Channel：ＧＥＥＣ）モデルの一例を示す図である。

【0132】

２状態ギルバート−エリオット消去チャネルモデルは、図１１に示すように、良い状態１１００及び悪い状態１２００を含む。図１１において、良い状態１１００は、低い損失状態を示し、悪い状態１２００は、バースト消去を誘発させる高い損失状態を示す。

【0133】

１．２ ２状態ギルバート−エリオット消去チャネル（ＧＥＥＣ）モデル
− 良い状態：ランダム消去チャネル（低い損失状態）
− 悪い状態：バースト消去チャネル（高い損失状態）

【0134】

２．２ステージＦＥＣ符号化構造でのシミュレーション
図１２Ａ及び図１２Ｂは、本発明の実施形態による１ステージ及び２ステージＦＥＣ符号化構造を示す図である。特に、図１２Ａは、１ステージＦＥＣ符号化構造を示し、図１２Ｂは、２ステージＦＥＣ符号化構造を示す。

【0135】

１ステージＦＥＣ符号化構造は、Ｐ＝Ｐ１＋Ｐ２に対応するＦＥＣパリティを各サブブロックに付加する。

【0136】

他方、２ステージＦＥＣ符号化構造は、Ｐ１ ＦＥＣパリティを各サブブロックに付加し、Ｐ２ ＦＥＣパリティをＭ個のサブブロック全体を含むソースブロックに付加する。

【0137】

図１３乃至図１８は、本発明の実施形態によるランダム＋ＲＥＩＮチャネル上で２ステージＦＥＣ符号化構造及び１ステージＦＥＣ符号化構造に対するシミュレーション結果を示す図である。

【0138】

ハイブリッド配信サービス、例えば、ＡＶストリーミング及びファイル配信を同一のストリーム内で送信する場合に、図面に示すように、それぞれのＡＶデータ及びファイルデータが共に送信される。通常、Ｐ１に対応するＦＥＣパリティがＡＶデータのために必要とされる場合に、ファイルデータは、ＡＶデータより高いＦＥＣ性能を要求するので、ＡＶデータ及びファイルデータを同時にストリーミングする場合に、ファイルデータの要求性能に合うようにＰ＝Ｐ１＋Ｐ２に対応するＦＥＣパリティを要求する。しかしながら、これは、ランダム消去が発生するチャネル環境では有効であるが、バースト消去が発生するチャネル環境では有効でないために、さらに効率的な方法が要求される。通常に、バースト消去を訂正するための方法では、非常に長いコードを使用するか、又はインターリービングを通してバースト消去をランダム消去にスイッチングすることにより復号化性能を向上させることができる。しかしながら、上記の通りに、長いコードを使用するか又はインターリービングを通してバースト消去を訂正する場合には、ＡＶデータの増加を引き起こすことがある。したがって、バースト消去が発生する環境でハイブリッド配信サービスが行われる場合には、効率的な方法が要求される。

【0139】

図１３乃至図１８は、１ステージＦＥＣ符号化構造のためにＰ＝Ｐ１＋Ｐ２に対応するＦＥＣパリティを各サブブロックに付加し、２ステージＦＥＣ符号化構造のためにＰ１ ＦＥＣパリティを各サブブロックに付加し、Ｐ２ ＦＥＣパリティをＭ個のサブブロックを含むソースブロックに付加した後に、ランダム＋ＲＥＩＮチャネル環境の下で実行されたシミュレーションの結果を示す図である。

【0140】

以下は、シミュレーションパラメータを整理したものである。
２．１ シミュレーションパラメータ
− データレート：８Ｍｂｐｓ
− ペイロードサイズ：１０００バイト
− コード：アイデアルコード
− 全オーバーヘッド（Overall overhead）：２０％（Ｐ＝Ｐ１＋Ｐ２）
− １ステージＰ：２０％
− ２ステージＰ１−Ｐ２：１５％−５％
− サブブロック長さ（Ｋ）：２００、４００
− サブブロックの個数（Ｍ）：Ｋ＝２００の場合に３２であり、Ｋ＝４００の場合に１６である。
− ブロック期間：サブブロック長さ２００の場合に２００ｍｓであり、サブブロック長さ４００の場合に４００ｍｓである。
− ランダム消去：パケット消去率（ＰＥＲ）＝０〜２０％
− バースト消去：パケット消去率（ＰＥＲ）を有するＲＥＩＮ（８ｍｓ）＝０．０００１、０．００１、０．０１

【0141】

ここで使用される‘サブブロック長さ’は、サブブロックを構成するペイロードの個数を意味する。ペイロードのサイズが１０００バイトとして設定される場合に、サブブロック長さ２００は、８Ｍｂｐｓのデータレートを要求するサービスで約２００ｍｓのＦＥＣブロック期間を有し、サブブロック長さ４００は、４００ｍｓのＦＥＣブロック期間を有する。これらの状況から、ＲＥＩＮ（８ｍｓ）バースト消去が１回発生する時に、どれくらいのペイロードがＦＥＣブロックから消去されるかを計算することができる。このような方式でシミュレーションを実行する。

【0142】

図１３乃至図１５は、本発明の実施形態によるＫ＝２００の場合に２ステージＦＥＣ符号化構造の効果を示す図である。

【0143】

図１３は、Ｐ１＝１５％（Ｐ２＝０）のバーストが割り当てられる時に１ステージＦＥＣ復号化構造のＦＥＣ復号化が行われた後にＦＥＣ−１ブロック（サブブロック２００＋Ｐ１ １５％パリティブロック）のフレームエラーレート（ＦＥＲ）を示す。バースト消去がない場合に、略４．４％のランダム消去で略１０^（−７）のＦＥＲ性能が示される。しかしながら、バースト長さが８パケットであるバースト消去が１０^（−４）、１０^（−３）、１０^（−２）のＰＥＲで付加されることにより、ランダム消去環境において、略Ｐ１＝１５％でよく動作するが、バースト消去の発生により急激な性能劣化が発生する。

【0144】

図１４は、Ｐ２＝５％が付加される時に、すなわち、Ｐ＝Ｐ１＋Ｐ２（２０％）が１ステージＦＥＣ符号化構造に付加される時のＦＥＲ性能を示す。図示するように、 バースト消去１０^（-４）を除外した１０^（−３）、１０^（−２）バーストによるＰＥＲが追加される場合に性能劣化が発生することがある。これは、バースト消去が発生するチャネル環境で１ステージＦＥＣ符号化構造で目標性能を達成し難いことを示す。通常、ＡＶデータのためのＦＥＲ性能は、１０^（−７）に設定される。この場合に、ファイルデータは、これよりさらに低いＦＥＲ性能を要求する。これは、ＡＶデータが一定の程度のパケット損失を許容するが、ファイルデータは、そのパケット損失の時に役に立たないためである。したがって、バースト消去が発生する場合に、ファイルデータの損失は、１ステージＦＥＣ符号化構造で防止されないことがある。

【0145】

図１５は、２ステージＦＥＣ符号化構造のために、Ｐ１＝１５％のオーバーヘッドが各サブブロックに付加され、Ｐ２＝５％のオーバーヘッドが３２個のサブブロック（すなわち、ソースブロック）に付加される場合のＦＥＣ−１ブロックに対するＦＥＲ性能を示す図である。図示するように、バースト消去１０^（−４）、１０^（−３）、及び１０^−２）を有するすべての領域で優秀な性能を示す。

【0146】

これらの結果に基づいて、略Ｐ１＝１５％のバーストを各サブブロックに割り当てることによりサブブロック期間に対応する遅延（本実験の場合に２００ｍｓ）でＡＶデータを再生し、ＡＶデータをユーザに提供することが好ましい。遅延が相対的に大きい問題でないファイルデータの再生において、ＦＥＣ−１ブロック復号化の失敗の時にＦＥＣ−２ブロックに基づく復号化を実行することが好ましい。このようにすることにより、バースト消去が発生する環境でもＡＶデータの再生だけでなくファイルデータの再生も保証することができる。通常、バースト消去は、予測不可能にかつまれに発生するために、ある程度パケット損失を許容するＡＶデータには致命的でない。しかしながら、バースト消去がまれに発生するとしても一旦バースト消去が発生すると、パケット損失を許容しないファイルデータは、再生されないことがある。これにより、ユーザに不便さを引き起こし、システム効率を低下させる。しかしながら、本発明の実施形態によれば、ＡＶデータは、遅延に敏感であるためにサブブロックのように小さな遅延を誘発するように設計されることは好ましくない。例えば、全ソースブロックが１ステージＦＥＣ符号化構造でＦＥＣ符号化が行われる場合に、ＦＥＲ性能は、２ステージＦＥＣ符号化構造でＦＥＣ符号化が行われる場合に比べてよりよいこともある。しかしながら、１ステージＦＥＣ符号化構造でＦＥＣ符号化が行われる場合に、ＡＶデータの遅延は、２００ｍｓ ｘ ３２＝６．４秒に達することがあるので、過度の遅延を引き起こす。したがって、特にライブストリームの場合に好ましくない。

【0147】

図１６乃至図１８は、本発明の実施形態によるＫ＝４００の場合の２ステージＦＥＣ符号化構造及び１ステージＦＥＣ符号化構造の性能を示す図である。図１６乃至図１８は、Ｋ＝２００の場合と同一の傾向を示す。言い換えれば、図１８での２ステージＦＥＣ符号化構造は、バースト消去が発生する環境において、図１６及び図１７での１ステージＦＥＣ符号化構造に比べてＦＥＲ性能に優れる。

【0148】

図１９は、本発明の実施形態によるＭＭＴシステムが適用されるＡＬ−ＦＥＣ符号化／復号化フローに対する概念を示す図である。

【0149】

図１９を参照すると、ＭＭＴシステムは、ＭＭＴ Ｄ．１レイヤー１９００、ＭＭＴ Ｅ．１レイヤー１９３０、及びＭＭＴ Ｄ．２レイヤー／ＩＥＴＦアプリケーションプロトコルレイヤー１９２０を含む。

【0150】

ＭＭＴ Ｄ．１レイヤー１９００は、ペイロードフォーマット生成器１９０１と、ＡＬ−ＦＥＣモジュール変換器１９０３と、ＦＥＣエンコーダ／デコーダ１９０５とを含む。

【0151】

符号化の間に、ＭＭＴ Ｄ．１レイヤー１９００は、ＭＭＴパッケージ（例えば、ＡＶデータ、ファイル、テキストなどをストレージに保存するか又は送信を考慮する目的で作られたフォーマット）をＭＭＴ Ｅ．１レイヤー１９３０から受信し、ペイロードフォーマット生成器１９０１により送信のためのソースペイロードに分割することによりソースブロックを生成する。ＡＬ−ＦＥＣモジュール変換器１９０３は、ソースブロックを同一の長さを有する情報ペイロードを含む２次元アレイである情報ブロックに変換する。ＦＥＣエンコーダ１９０５は、与えられたＦＥＣコードで情報ブロックのＦＥＣ符号化を実行することによりパリティブロックを情報ブロックから生成し、パリティブロックをペイロードフォーマット生成器１９０１に送信する。ペイロードフォーマット生成器１９１０は、パケット化するために、パリティブロックをソースブロックに付加し、ペイロードヘッダ（ＰＬＨ）を各ペイロードに付加することによりＭＭＴペイロードフォーマットを生成し、ＭＭＴペイロードフォーマットをＭＭＴ Ｄ．２レイヤー／ＩＥＴＦアプリケーションプロトコルレイヤー１９２０に送信する。ＵＤＰヘッダは、送信の間に、ＵＤＰのようなトランスポートプロトコルにより付加され、さらにＩＰヘッダが付加される。

【0152】

次いで、ＲＳコード及びＬＤＰＣ（又はラプター／ラプターＱ）コードのようなＦＥＣコードが使用される時の２ステージＦＥＣ符号化構造の一例について説明する。

【0153】

所定数のソースペイロードを含むソースブロックは、送信の間にその損失を復旧するために２ステージＦＥＣ符号化方式により次のような４つのケースで保護される。
− ケース０：符号化ない構造に対応する
− ケース１：ＦＥＣ−１符号化構造に対応する（例えば、１ステージＦＥＣ符号化構造）
− ケース２：ＦＥＣ−２符号化構造に対応する（例えば、１ステージＦＥＣ符号化構造）
− ケース３：ＦＥＣ−１及びＦＥＣ−２符号化構造に対応する（例えば、２ステージＦＥＣ符号化構造）
ＲＳコード及びＬＤＰＣ（又はラプター／ラプターＱ）は、ＦＥＣ−１コード及びＦＥＣ−２コードのために使用される。

【0154】

ケース０のためには、ＦＥＣ−１及びＦＥＣ−２符号化がスキップされ、１ステージＦＥＣ符号化構造の場合に、Ｍは、１に設定される。ケース１のためには、ＦＥＣ−１符号化がスキップされ、ケース２のためには、ＦＥＣ−２符号化がスキップされる。

【0155】

２ステージＦＥＣ符号化構造のために、ソースブロックは、Ｍ個のサブブロックを含み、各サブブロックは、ＦＥＣ−１コードにより符号化され、ソースブロックは、ＦＥＣ−２コードにより符号化される。

【0156】

下記の表１は、２ステージＦＥＣ符号化構造のためのＲＳコードとＬＤＰＣコードとの可能な組合せを示す。本発明の実施形態によれば、ＬＤＰＣは、ラプター又はラプターＱに置き換えられることができる。

【0157】

【表1】

【0158】

したがって、１ステージＦＥＣ符号化構造を含む２ステージＦＥＣ符号化方式で使用可能なＦＥＣ符号化構造の場合には、次のような６つのケースが可能である。本発明の実施形態によれば、ＬＤＰＣは、ラプター又はラプターＱに置き換えられることができる。
− 符号化なし
− ＲＳ符号化（１ステージ）
− ＬＤＰＣ符号化（１ステージ）
− ＲＳ−ＲＳ符号化（２ステージ）
− ＲＳ−ＬＤＰＣ符号化（２ステージ）
− ＬＤＰＣ−ＬＤＰＣ符号化（２ステージ）

【0159】

ケース１は、相対的に小さな個数のソースペイロードを含むソースブロックのためであり、ケース２は、相対的に大きな個数のソースペイロードを含むソースブロックのためであることに留意すべきである。ソース／サブブロックのためのソースペイロードの個数及びＦＥＣコードにより付加されるパリティペイロードの個数が２５５個より小さいか又は同一である場合に、ＲＳコードが使用される。そうでない場合には、ＬＤＰＣが使用される。単純に、ソース／サブブロックのためのソースペイロードの個数が２００又はそれ以下、４００、８００、１６００、３２００、及び６４００に分類され、これに対応する場合に、２００又はそれ以下は、ソースペイロードがＲＳコードで符号化され、４００又はそれ以上は、ソースペイロードがＬＤＰＣコード（又は、ラプター／ラプターＱ）で符号化される。

【0160】

図２０Ａ及び図２０Ｂは、本発明の実施形態による１ステージ及び２ステージＦＥＣ符号化構造を示す図である。特に、図２０Ａは、１ステージＦＥＣ符号化構造を示し、図２０Ｂは、２ステージＦＥＣ符号化構造を示す。

【0161】

図２０Ａを参照すると、１ステージＦＥＣ符号化構造は、Ｐ１に対応するＦＥＣパリティを１つのサブブロックに付加する。

【0162】

その一方、図２０Ｂを参照すると、２ステージＦＥＣ符号化構造は、Ｐ１ ＦＥＣパリティを各サブブロックに付加し、Ｐ２ ＦＥＣパリティをＭ個のサブブロックの全体を含むソースブロックに付加する。

【0163】

図２１は、本発明の実施形態によるＦＥＣ配信ブロック及びＦＥＣ配信クラスターの構成を示す図である。

【0164】

図２１を参照すると、図２１でのソースブロックのソースペイロードは、その長さがすべて同一であることもあり、又は図２１に示すように相互に異なることもある。相互に異なる場合に、同一の長さを有する２次元アレイ（例えば、情報ブロック）は、図２２に示すように、パディングデータを各ソースペイロードに付加することにより生成される。

【0165】

図２２乃至図２４は、本発明の実施形態によるソースブロックを情報ブロックにマッピングする過程の例を示す図である。

【0166】

特に、図２２は、ソースブロックを情報ブロックにマッピングする過程を示す図である。

【0167】

Ｋが情報ブロックから２００又はそれ以下である場合に、ソースブロックを情報ブロックにマッピングさせることにより、図２３に示すように、ＲＳ符号化のための情報シンボルを生成することもあり、図２４に示すように、ＬＤＰＣ符号化のための情報シンボルを生成することもある。

【0168】

図２５は、本発明の実施形態によるＲＳフレームの構造を示す図である。図２６は、本発明の実施形態による低密度パリティ検査（ＬＤＰＣ）フレームの構造を示す図である。

【0169】

図２５及び図２６にそれぞれ示すように、パリティシンボルは、情報シンボルのＲＳ及びＬＤＰＣ符号化を実行することにより生成される。図２６の場合には、短縮及びパンクチャーリングが図示されていないが、パリティシンボルは、様々なＫ及びＰに対して、所定の長さを有するＬＤＰＣコードを用いて図２５の場合のように短縮及びパンクチャーリングを実行することにより生成されることができる。選択的に、短縮だけを実行することもあり、パンクチャーリングだけを実行することもある。

【0170】

図２７は、本発明の実施形態によるリードソロモン（ＲＳ）パリティシンボルのためのパリティブロックマッピングを示す図である。図２８は、本発明の実施形態によるＬＤＰＣパリティシンボルのためのパリティブロックマッピングを示す図である。

【0171】

図２７及び図２８に示すように、ＲＳパリティブロック及びＬＤＰＣパリティブロックは、この生成されたパリティシンボルから生成される。

【0172】

次は、ＲＳコード及びＬＤＰＣコードの説明を示す。

【0173】

有限フィールドＧＦ（２^８）上のＲＳ（Ｎ，Ｋ）コードの原始多項式は、ｐ（ｘ）＝ｘ^８＋ｘ^４＋ｘ^３＋ｘ^２＋１で定義される。

【0174】

ＧＦ（２^８）でのシンボルは、（α^７、α^６、α^５、α^４、α^３、α^２、α、１）で示すことができ、ここで、α＝００００００１０（２進）である。

【0175】

各ＲＳコードワード（ｒｓｃ）は、ベクトルで示す場合に、ｒｓｃ＝（ｅ０、ｅ１、．．．、ｅ１９９、ｐ２００，．．．，ｐ２３９）で示す２００バイトの情報及び４０バイトのパリティを有する有限フィールドＧＦ（２^８）上のＲＳ（２４０，４０）コードである。

【0176】

有限フィールドＧＦ（２）上のＬＤＰＣ（Ｋ＋Ｐ，Ｋ）コードは、Ｋ個の情報ビット及びＰ個のパリティビットを含むＱＣ−ＬＤＰＣ構造を有する。ここで、Ｋ＝Ｌｘ４００及びＰ＝Ｌｘ８０、Ｌ＝１、２、４、８又は１６である。

【0177】

特に、ＬＤＰＣコードのパリティパートは、図２９に示すように、ほぼ三角形のマトリックス（approximately triangular matrix）の形態を有する。

【0178】

図２９は、本発明の実施形態によるＨマトリックスの構造を示す図である。図３０は、本発明の実施形態によるＦＥＣパケットブロック及びＦＥＣパケットクラスターの構成を示す図である。

【0179】

図２９を参照すると、Ｋ＝４００及びＰ＝Ｌｘ８０（Ｌ＝１、２、４、８、又は１６）である。

【0180】

下記は、ＦＥＣパケットブロックを示す。

【0181】

図３０を参照すると、ＦＥＣパケットヘッダ（ペイロードヘッダ（ＰＬＨ））は、ソース／サブブロック及びパリティブロックを含むＦＥＣ配信ブロック／クラスターの各ペイロードの先頭に割り当てられ、ＦＥＣパケットを含むＦＥＣパケットブロック／クラスターで送信される。

【0182】

次いで、ＦＥＣ構成情報を保存し運搬するＦＥＣパケットヘッダフォーマットについて説明する。

【0183】

特に、送信器によりＡＬ−ＦＥＣが適用される符号化構造のタイプを示す。

【0184】

すなわち、ＦＥＣパケットヘッダフォーマットは、ｆｅｃ＿ｓｔｒｕｃｔｕｒｅフィールドを含み、その定義は、次のようである。
ｆｅｃ＿ｓｔｒｕｃｔｕｒｅ：ＦＥＣブロック（又はパリティブロック）を生成するために選択された符号化構造を示す。
ｆｅｃ＿ｓｔｒｕｃｔｕｒｅの１番目の場合は、次のようである。
ｂ０００：符号化ない構造
ｂ００１：ＲＳ符号化構造
ｂ０１０：ＬＤＰＣ符号化構造
ｂ０１１：ＲＳ−ＲＳ２ステージ符号化構造
ｂ１００：ＲＳ−ＬＤＰＣ２ステージ符号化構造
ｂ１０１：ＬＤＰＣ−ＬＤＰＣ２ステージ符号化構造
その他：予備
ｆｅｃ＿_ｓｔｒｕｃｔｕｒｅの２番目の場合は、次のようである。
ｂ０００：符号化ない構造
ｂ００１：ＲＳ符号化構造
ｂ０１０：ＬＤＰＣ符号化構造
ｂ１０１：ＲＳ−ＲＳ２ステージ符号化構造
ｂ１１０：ＬＤＰＣ−ＬＤＰＣ２ステージ符号化構造
ｂ１１１：ＲＳ−ＬＤＰＣ２ステージ符号化構造
その他：予備

【0185】

２番目の場合に、ｂ２＝１は、２ステージ符号化構造の適用を示し、ｂ１＝１は、ＬＤＰＣコードの適用を示し、ｂ０＝１は、ＲＳコードの適用を示す。ＬＤＰＣは、ラプター又はラプターＱに置き換えられることができる。

【0186】

ｆｅｃ＿ｓｔｒｕｃｔｕｒｅに対する信号は、送信の間に、ＦＥＣパケットヘッダに記憶され、インーバンド信号として送信されることもあり、又は、ＦＥＣ制御パケット又はＲＴＣＰのようなＲＴＰ制御パケットのヘッダ又はペイロードに記憶されることにより、受信器がｆｅｃ＿ｓｔｒｕｃｔｕｒｅ情報を分かるようにする。

【0187】

以上、本発明を具体的な実施形態を参照して詳細に説明してきたが、本発明の範囲及び趣旨を逸脱することなく様々な変更が可能であるということは、当業者には明らかであり、本発明の範囲は、上述の実施形態に限定されるべきではなく、特許請求の範囲の記載及びこれと均等なものの範囲内で定められるべきものである。

【符号の説明】

【0188】

５０１ コンテンツ
５０３ コーデックエンコーダ
５０５ トランスポートプロトコルパケタイザ
５０７ エンコーダ
５０９ トランスポートプロトコルデパケタイザ
５１１ デコーダ
５１３ コーデックデコーダ
５１５ ディスプレー
１９００ レイヤー
１９０１ ペイロードフォーマット生成器
１９０３ ＡＬ−ＦＥＣモジュール変換器
１９０５ エンコーダ/デコーダ
１９１０ ペイロードフォーマット生成器
１９２０ アプリケーションプロトコルレイヤー
１９３０ レイヤー

【図1】

【図2A】

【図2B】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】

【図10】

【図11】

【図12A】

【図12B】

【図13】

【図14】

【図15】

【図16】

【図17】

【図18】

【図19】

【図20A】

【図20B】

【図21】

【図22】

【図23】

【図24】

【図25】

【図26】

【図27】

【図28】

【図29】

【図30】