(57)【特許請求の範囲】
【請求項１】
マルチメディアシステムにおける送信装置がフォワードエラー訂正（ＦＥＣ）構成情報を送信する方法であって、
ＦＥＣパケットのためのＦＥＣ構成情報を送信するステップを有し、
前記ＦＥＣ構成情報は、ＦＥＣパケットブロックがＦＥＣパケットを含む場合に、前記ＦＥＣパケットの中で１番目に送信される１番目のＦＥＣパケットに関連した情報を含み、
前記１番目のＦＥＣパケットに関連した情報は、前記１番目のＦＥＣパケットのヘッダに含まれたタイムスタンプの最上位ビット（ＭＳＢ）１ビットを除外した残りのビットに対する値を指示することを特徴とする方法。
【請求項２】
前記送信装置は、１段ＦＥＣコーディング構造をサポートすることを特徴とする請求項１に記載の方法。
【請求項３】
前記送信装置は、レイヤー認識フォワードエラー訂正（ＬＡ−ＦＥＣ）コーディング構造をサポートすることを特徴とする請求項１に記載の方法。
【請求項４】
前記１番目のＦＥＣパケットは、ＦＥＣソースパケット又はＦＥＣリペアパケットを含むことを特徴とする請求項１に記載の方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、マルチメディア通信システムにおけるパケットを送受信する装置及び方法に関し、特に、フォワードエラー訂正（Forward Error Correction：以下、‘ＦＥＣ’と称する）方式をサポートするマルチメディア通信システムにおけるパケットを送受信する装置及び方法に関する。
【背景技術】
【０００２】
マルチメディアに対する要求が増加するに従って様々なマルチメディア技術が提案されており、代表的なマルチメディア技術がムービングピクチャーエクスパーツグループ（Moving Picture Experts Group：ＭＰＥＧ）メディアトランスポート（MPEG Media Transport：以下、‘ＭＭＴ’と称する）技術である。
【０００３】
ＭＭＴ技術は、インターネットプロトコル（Internet Protocol：ＩＰ）ネットワーク及びディジタルブロードキャスティングネットワークを含む異種パケット−交換ネットワーク（heterogeneous packet-switched network）を通してマルチメディアサービスに対するコーディングされたメディアデータのトランスポート及び配信のための技術である。ここで、コーディングされたメディアデータは、同期型視聴覚メディアデータ（timed audiovisual media data）及び非同期型データ（non-timed data）を含む。
【０００４】
ＭＭＴ技術において、コーディングされたメディアデータは、パケット交換配信ネットワーク（packet-switched delivery network）を通して配信される。ＭＭＴ技術において、上記のような配信環境の特性、例えば、ＭＭＴ送信エンティティ（sending entity）からＭＭＴ受信エンティティ（receiving entity）への各パケットに対するノンコンスタントエンドツーエンド遅延（non-constant end-to-end delay）のような配信環境の特性が考慮される。
【０００５】
パケット−交換配信ネットワークを通したコーディングされたメディアデータの効率的であり、効果的な配信及び消費のために、ＭＭＴ技術は、次のようなエレメントを提供し、これについて説明すると、次の通りである。
【０００６】
１番目に、ＭＭＴ技術は、様々なソースからのコンポーネント、例えば、マッシュアップアプリケーション（mash-up application）のコンポーネントのような様々なソースからのコンポーネントで構成されたコンテンツを構成する論理モデルを提供する。
【０００７】
２番目に、ＭＭＴ技術は、コーディングされたメディアデータに関する情報を配信することにより、配信レイヤー処理（delivery layer processing）、例えば、パケット化のような配信レイヤー処理を可能にするフォーマットを提供する。
【０００８】
３番目に、ＭＭＴ技術は、複数のチャネルを通したメディア及びコーディング独立ハイブリッド配信（independent hybrid delivery）をサポートするパケット−交換ネットワークを通してメディアコンテンツを配信するパケット化方法及びパケットの構造を提供する。
【０００９】
４番目に、ＭＭＴ技術は、メディアコンテンツの配信及び消費を管理するシグナリングメッセージのフォーマットを提供する。
【００１０】
一方、ＭＭＴ方式をサポートするマルチメディア通信システムにおいて、コンテンツの多様化及び高解像度（High Definition：ＨＤ）コンテンツ及び超高解像度（Ultra High Definition：ＵＨＤ）コンテンツのような高容量コンテンツの増加の結果として、ネットワーク上でデータ輻輳（data Congestion）がさらに悪化している。このような状況により、信号送信装置、例えば、ホストＡにより送信されたコンテンツは、信号受信装置、例えば、ホストＢに正常に配信されず、コンテンツの一部は、経路上で損失される状況が発生する。
【００１１】
一般的に、データは、パケット単位で送信されるために、データ損失は、送信パケット単位で発生する。したがって、送信パケットがネットワーク上で損失される場合に、信号受信装置は、損失された送信パケットを受信できないので、損失された送信パケット内のデータをわからない。その結果、オーディオ信号の品質低下、ビデオの画質劣化や画面破れ、字幕欠落、ファイルの損失などのような様々な形態でユーザの不便さをもたらす。
【００１２】
このような観点で、ネットワーク上で発生したデータ損失を復旧するための方式が必要である。
【００１３】
ネットワークを通してデータが損失される場合に、信号受信装置で損失されたデータのリペアをサポートする方法の中の１つは、ソースパケットと呼ばれる様々な長さを有する所定数のデータパケットでソースブロックを構成し、フォワードエラー訂正（Forward Error Correction：以下、‘ＦＥＣ’と称する）符号化によりパリティデータ又はリペアパケット（Repair packet）のようなリペア情報をソースブロックに付加し、付加されたリペア情報をパケットブロック単位で予め設定されている所定の時間内に送信する方式である。
【００１４】
したがって、信号受信装置は、データ損失をリペアするために信号送信装置でパケットブロックを送信するために使用される所定の時間に対応するリペア遅延時間を必要とする。
【００１５】
また、ネットワークで発生するパケットジッタ（jitter）を除去するための方式であるデジッタリング（de-jittering）方式及びＦＥＣ方式を結合してデータ損失を復旧するためには、仮想の信号受信装置のバッファリングモデルである仮想受信器バッファリングモデル（Hypothetical Receiver Buffering Model：以下、'ＨＲＢＭ'と称する）が必要となり、信号受信装置は、ＨＲＢＭを使用してデータ損失復旧動作及びデジッタリング動作の実行を考慮すべき場合が発生する。
【００１６】
しかしながら、現在のＭＭＴ方式をサポートするマルチメディア通信システムでは、ＨＲＢＭを使用してデータ損失復旧動作及びデジッタリング動作を効率的に実行する方案について具体的に提案されていない。
【００１７】
上述した情報は、本発明の理解を助けるために背景情報としてのみ提示される。本発明に対する先行技術で適用されることができるか否かに関してはいかなる決定及びいかなる主張もない。
【発明の概要】
【発明が解決しようとする課題】
【００１８】
本発明の一実施形態は、ＦＥＣ方式をサポートするマルチメディア通信システムにおけるパケットを送受信する方法及び装置を提供することにある。
【００１９】
本発明の一実施形態は、ＦＥＣ方式をサポートするマルチメディア通信システムにおけるデータ復元効率性を増加させるパケット送受信方法及び装置を提供することにある。
【００２０】
本発明の一実施形態は、ＦＥＣ方式をサポートするマルチメディア通信システムにおける効率的な送信信頼度を取得できるパケット送受信方法及び装置を提供することにある。
【００２１】
本発明の一実施形態は、ＦＥＣ方式をサポートするマルチメディア通信システムにおけるパケットの特性を考慮してパケットを送受信する方法及び装置を提供することにある。
【００２２】
本発明の一実施形態は、ＦＥＣ方式をサポートするマルチメディア通信システムにおけるＦＥＣコーディング構造を考慮してパケットを送受信する方法及び装置を提供することにある。
【００２３】
本発明の一実施形態は、ＦＥＣ方式をサポートするマルチメディア通信システムにおけるパケット送信時点を考慮してパケットを送受信する方法及び装置を提供することにある。
【００２４】
本発明の一実施形態は、ＦＥＣ方式をサポートするマルチメディア通信システムにおけるパケットの分割特性を考慮してパケットを送受信する方法及び装置を提供することにある。
【００２５】
本発明の一実施形態は、ＦＥＣ方式をサポートするマルチメディア通信システムにおける信号送信装置と信号受信装置との間の遅延を考慮してパケットを送受信する方法及び装置を提供することにある。
【００２６】
本発明の一実施形態は、ＦＥＣ方式をサポートするマルチメディア通信システムにおけるバッファサイズを考慮してパケットを送受信する方法及び装置を提供することにある。
【００２７】
本発明の一実施形態は、ＦＥＣ方式をサポートするマルチメディア通信システムにおけるＦＥＣ方式に関連したＦＥＣ構成情報を送受信する方法及び装置を提供することにある。
【課題を解決するための手段】
【００２８】
本発明の実施形態の一態様によれば、マルチメディアシステムにおける送信装置がフォワードエラー訂正（ＦＥＣ）構成情報を送信する方法が提案される。上記方法は、ＦＥＣソースパケットのためのソースＦＥＣ構成情報を受信装置に送信するステップを含み、上記ソースＦＥＣ構成情報は、ＦＥＣソース又はリペアパケットブロックが少なくとも１つのＦＥＣソース又はリペアパケットを含む場合に、上記少なくとも１つのＦＥＣソース又はリペアパケットの中で１番目に送信されるＦＥＣソース又はリペアパケットに関連した情報を含むことを特徴とする。
【００２９】
本発明の実施形態の他の態様によれば、マルチメディアシステムにおける受信装置がフォワードエラー訂正（ＦＥＣ）構成情報を受信する方法が提案される。上記方法は、送信装置からＦＥＣソースパケットのためのソースＦＥＣ構成情報を受信するステップを含み、上記ソースＦＥＣ構成情報は、ＦＥＣソース又はリペアパケットブロックが少なくとも１つのＦＥＣソース又はリペアパケットを含む場合に、上記少なくとも１つのＦＥＣソース又はリペアパケットの中で１番目に送信されるＦＥＣソース又はリペアパケットに関連した情報を含むことを特徴とする。
【００３０】
本発明の実施形態のさらに他の態様によれば、マルチメディアシステムにおける送信装置が提案される。上記送信装置は、フォワードエラー訂正（ＦＥＣ）ソースパケットのためのソースＦＥＣ構成情報を受信装置に送信する送信器を含み、上記ソースＦＥＣ構成情報は、ＦＥＣソース又はリペアパケットブロックが少なくとも１つのＦＥＣソース又はリペアパケットを含む場合に、上記少なくとも１つのＦＥＣソース又はリペアパケットの中で１番目に送信されるＦＥＣソース又はリペアパケットに関連した情報を含むことを特徴とする。
【００３１】
本発明の実施形態のさらなる他の態様によれば、マルチメディアシステムにおける受信装置が提案される。上記受信装置は、フォワードエラー訂正（ＦＥＣ）ソースパケットのためのソースＦＥＣ構成情報を送信装置から受信する受信器を含み、上記ソースＦＥＣ構成情報は、ＦＥＣソース又はリペアパケットブロックが少なくとも１つのＦＥＣソース又はリペアパケットを含む場合に、上記少なくとも１つのＦＥＣソース又はリペアパケットの中で１番目に送信されるＦＥＣソース又はリペアパケットに関連した情報を含むことを特徴とする。
【発明の効果】
【００３２】
本発明の一実施形態は、ＦＥＣ方式をサポートするマルチメディア通信システムにおけるパケット符号化による遅延時間及びネットワーク上のパケット遅延時間により信号受信装置で発生し得る復旧遅延を減少させるパケットの送受信を可能にするという効果がある。
【００３３】
本発明の一実施形態は、ＦＥＣ方式をサポートするマルチメディア通信システムにおけるデータ復元効率性を増加させるパケットの送受信を可能にするという効果がある。
【００３４】
本発明の一実施形態は、ＦＥＣ方式をサポートするマルチメディア通信システムにおける効率的な送信信頼度を取得できるパケット送受信を可能にするという効果がある。
【００３５】
本発明の一実施形態は、ＦＥＣ方式をサポートするマルチメディア通信システムにおけるパケットの特性を考慮してパケットの送受信を可能にするという効果がある。
【００３６】
本発明の一実施形態は、ＦＥＣ方式をサポートするマルチメディア通信システムにおけるＦＥＣコーディング構造を考慮してパケットの送受信を可能にするという効果がある。
【００３７】
本発明の一実施形態は、ＦＥＣ方式をサポートするマルチメディア通信システムにおけるパケット送信時点を考慮してパケットの送受信を可能にするという効果がある。
【００３８】
本発明の一実施形態は、ＦＥＣ方式をサポートするマルチメディア通信システムにおけるパケットの分割特性を考慮してパケットの送受信を可能にするという効果がある。
【００３９】
本発明の一実施形態は、ＦＥＣ方式をサポートするマルチメディア通信システムにおける信号送信装置と信号受信装置との間の遅延を考慮してパケットの送受信を可能にするという効果がある。
【００４０】
本発明の一実施形態は、ＦＥＣ方式をサポートするマルチメディア通信システムにおけるバッファサイズを考慮してパケットの送受信を可能にするという効果がある。
【００４１】
本発明の一実施形態は、ＦＥＣ方式をサポートするマルチメディア通信システムにおけるＦＥＣ方式に関連したＦＥＣ構成情報の送受信を可能にするという効果がある。
【００４２】
本発明の実施形態の上述した及び他の様相、特徴、及び利点は、以下の添付図面を併用した後述の詳細な説明から、より一層明らかになる。
【図面の簡単な説明】
【００４３】
【図１】本発明の一実施形態によるＦＥＣ方式をサポートするＭＭＴシステムの構造の一例を概略的に示す図である。
【図２】本発明の一実施形態によるＦＥＣ方式をサポートするＭＭＴシステムの構造の他の例を概略的に示す図である。
【図３】本発明の一実施形態によるＦＥＣ方式をサポートするＭＭＴシステムにおけるアプリケーションレイヤーフォワードエラー訂正（ＡＬ−ＦＥＣ）アーキテクチャーを概略的に示す図である。
【図４】本発明の一実施形態によるＦＥＣ方式をサポートするＭＭＴシステムで使用される２段ＦＥＣコーディング構造を概略的に示す図である。
【図５】本発明の一実施形態によるＦＥＣ方式をサポートするＭＭＴシステムで使用されるＬＡ−ＦＥＣコーディング構造を概略的に示す図である。
【図６】本発明の一実施形態によるＦＥＣ方式をサポートするＭＭＴシステムにおいてＭＭＴパケットストリームを使用してソースパケットブロック及びソースシンボルブロックを生成する過程を概略的に示す図である。
【図７】本発明の一実施形態によるＦＥＣ方式をサポートするＭＭＴシステムにおいてソースシンボルブロックを使用してリペアシンボルブロックを生成する過程を概略的に示す図である。
【図８】本発明の一実施形態によるＦＥＣ方式をサポートするＭＭＴシステムにおいてＦＥＣソース又はリペアパケットブロックに含まれたＦＥＣソース又はリペアパケットの中で１番目に送信されるＦＥＣソース又はリペアパケットに対するタイムスタンプを設定する過程を概略的に示す図である。
【図９】本発明の一実施形態によるＦＥＣ方式をサポートするＭＭＴシステムにおいて２段ＦＥＣ構造が使用される場合のタイムスタンプを設定する過程を概略的に示す図である。
【図１０】本発明の一実施形態によるＦＥＣ方式をサポートするＭＭＴシステムで使用されるＦＥＣソースパケットの構造を概略的に示す図である。
【図１１】本発明の一実施形態によるＦＥＣ方式を使用するＭＭＴシステムで使用されるＦＥＣリペアパケットの構造を概略的に示す図である。
【図１２】本発明の一実施形態によるＦＥＣ方式をサポートするＭＭＴシステムにおいてＦＥＣソース又はリペアパケットブロックの送受信期間及びＦＥＣ復号デジッタリング過程を概略的に示す図である。
【図１３】本発明の一実施形態によるＦＥＣ方式をサポートするＭＭＴシステムにおけるＨＲＢＭの内部構造を概略的に示す図である。
【図１４】本発明の一実施形態によるＦＥＣ方式をサポートするＭＭＴシステムにおいてＦＦＲＳＴ＿ＴＳがパケットに含まれて送信される場合における信号受信装置でのＦＥＣ保護ウィンドー（ケース１）及びＦＦＲＳＴ＿ＴＳがパケットに含まれて送信されない場合における信号受信装置でのＦＥＣ保護ウィンドー（ケース２）を概略的に示す図である。
【図１５】本発明の一実施形態によるＦＥＣ方式をサポートするＭＭＴシステムにおけるＭＭＴ送信エンティティの内部構造の一例を概略的に示す図である。
【図１６】本発明の一実施形態によるＭＭＴシステムにおけるＭＭＴ送信エンティティの内部構造の他の例を概略的に示す図である。
【図１７】本発明の一実施形態によるＭＭＴシステムにおけるＭＭＴ受信エンティティの内部構造の一例を概略的に示す図である。
【図１８】本発明の一実施形態によるＭＭＴシステムにおけるＭＭＴ受信エンティティの内部構造の他の例を概略的に示す図である。
【００４４】
図面中、同一の図面参照符号が同一の構成エレメント、特性、又は構造を意味することは、容易に理解できるであろう。
【発明を実施するための形態】
【００４５】
添付の図面を参照した下記の説明は、特許請求の範囲の記載及びこれと均等なものの範囲内において定められる本発明の実施形態の包括的な理解を助けるために提供されるものであり、この理解を助けるために様々な特定の詳細な説明を含むが、単なる１つの実施形態にすぎない。従って、本発明の範囲及び趣旨を逸脱することなく、ここに説明する実施形態の様々な変更及び修正が可能であることは、当該技術分野における通常の知識を有する者には明らかである。また、明瞭性と簡潔性の観点から、当業者には既知の機能や構成に関する具体的な説明を省略する。
【００４６】
以下の説明及び請求項に使用する用語及び単語は、辞典的意味に限定されるものではなく、本発明の理解を明確且つ一貫性があるようにするために使用される。したがって、本発明の実施形態の説明が単に実例を提供するためのものであって、特許請求の範囲とこれと均等なものに基づいて定義される発明をさらに限定する目的で提供されるものでないことは、本発明の技術分野における通常の知識を持つ者には明らかであろう。
【００４７】
本願明細書に記載の各エレメントは、文脈中で特に明示しない限り、複数形を含むことは、当業者には理解できるであろう。したがって、例えば、“コンポーネント表面（a component surface）”との記載は、１つ又は複数の表面を含む。
【００４８】
“第１”及び“第２”などの序数を含む用語が様々な構成要素を説明するために使用されるが、これらの構成要素は、この用語により限定されない。この用語は、１つの構成要素を他の構成要素と区別するためにだけ使用される。例えば、本発明の権利範囲を逸脱することなく、第１の構成要素は、第２の構成要素と呼ばれてもよく、同様に、第２の構成要素は、第１の構成要素と呼ばれてもよい。ここで使用される用語“及び／又は”は、複数の関連した記載された項目の組合せ又は複数の関連して記載された項目のうちの何れかの項目を含む。
【００４９】
ここで使用する用語は、特定の実施形態だけを説明するためのもので、本発明を限定するものではない。ここで使用するように、単数の表現は、文脈上明白に異なることを必要としない限り複数の表現を含む。本明細書で使用されている“含む”及び“有する”などのような用語は、明細書上に記載された特徴、数字、ステップ、動作、構成要素、部分、又はこれらの組合せの存在を指定するものであって、１つ又はそれ以上の他の特徴、数字、ステップ、動作、構成要素、部品、又はこれらの組合せの存在又は付加の可能性を予め排除しないものと理解されるべきである。
【００５０】
或る用語が異なって定義されない限り、技術的であるか又は科学的な用語を含めてここで使用される全ての用語は、本発明が属する技術分野における通常の知識を有する者により一般的に理解されるものと同一の意味を有している。一般的に使用される予め定義されているような用語は、関連技術の文脈上有する意味と一致する意味を有するものと解釈されなければならず、本出願で明白に定義しない限り、理想的であるか又は過度に形式的な意味であると解釈されない。
【００５１】
本発明の様々な実施形態によると、電子デバイスは、通信機能を含む。例えば、電子デバイスは、スマートフォンと、タブレット個人用コンピュータ（personal computer：以下、‘ＰＣ’と称する）と、移動電話機と、画像電話機と、電子ブックリーダ（e-book reader）と、デスクトップ（desktop）ＰＣと、ラップトップ（laptop）ＰＣと、ネットブック（netbook）ＰＣと、個人用ディジタルアシスタント（personal digital assistant：以下、‘ＰＤＡ’と称する）と、携帯用マルチメディアプレーヤ（portable multimedia player：以下、‘ＰＭＰ’と称する）と、ｍｐ３プレーヤ（mp3 player）と、移動医療デバイスと、カメラと、ウェアラブルデバイス（wearable device）（例えば、ヘッドマウンテッドデバイス（Head-Mounted Device：ＨＭＤ）と、電子衣服と、電子ブレースと、電子ネックレースと、首飾りと、電子アクセサリと、電子タトゥー、又はスマートウォッチ（smart watch）などであり得る。
【００５２】
本発明の様々な実施形態によると、電子デバイスは、通信機能を有するスマート家庭用デバイス（smart home appliance）であり得る。例えば、スマート家庭用デバイスは、テレビジョンと、ディジタルビデオディスク（digital video disk：以下、‘ＤＶＤ’と称する）プレーヤと、オーディオと、冷蔵庫と、エアコンディショナと、真空掃除機と、オーブンと、マイクロウェーブオーブンと、ウォッシャーと、ドライヤーと、エアピュリファイヤと、セットトップボックス（set-top box）と、ＴＶボックス（例えば、Ｓａｍｓｕｎｇ Ｈｏｍｅ Ｓｙｎｃ（登録商標）、Ａｐｐｌｅ  ＴＶ（登録商標）、又はＧｏｏｇｌｅ  ＴＶ（登録商標））と、ゲーミングコンソール（gaming console）と、電子辞書と、カムコーダと、電子写真フレームなどであり得る。
【００５３】
本発明の様々な実施形態によると、電子デバイスは、医療デバイス（例えば、磁気共鳴アンジオグラフィ法（magnetic resonance angiography：ＭＲＡ）デバイス、磁気共鳴イメージング（magnetic resonance imaging：ＭＲＩ）デバイス、コンピュータトモグラフィー（Computed Tomography：ＣＴ）デバイス、イメージングデバイス、又は超音波デバイス）と、ナビゲーションデバイスと、全地球測位システム（Global Positioning System：ＧＰＳ）受信器と、イベントデータレコーダ（Event Data recorder：ＥＤＲ）と、フライトデータレコーダ（Flight Data Recorder：ＦＤＲ）と、オートモーチブインフォテインメントデバイス（Automotive Infotainment Device）と、航海電子デバイス（例えば、航海ナビゲーションデバイス、ジャイロスコープ、又はコンパス）と、航空電子デバイスと、セキュリティデバイスと、産業用又は消費者用ロボットなどであり得る。
【００５４】
本発明の様々な実施形態によると、電子デバイスは、通信機能を含む家具と、ビルディング／構造の一部と、電子ボードと、電子署名受信デバイスと、プロジェクターと、様々な測定デバイス（例えは、水、電気、ガス、又は電磁波測定デバイス）などであり得る。
【００５５】
本発明の様々な実施形態によると、電子デバイスは、上述したようなデバイスの任意の組み合せであってもよい。また、本発明の様々な実施形態による電子デバイスは、当該技術分野における当業者には、上述したようなデバイスに限定されないことが自明である。
【００５６】
本発明の様々な実施形態によると、信号受信装置は、例えば、電子デバイスであり得る。
【００５７】
本発明の一実施形態は、フォワードエラー訂正（Forward Error Correction：以下、‘ＦＥＣ’と称する）方式をサポートするマルチメディア通信システムにおけるパケットを送受信する方法及び装置を提案する。
【００５８】
本発明の一実施形態は、ＦＥＣ方式をサポートするマルチメディア通信システムにおけるデータ復元効率性を増加させるパケット送受信方法及び装置を提案する。
【００５９】
本発明の一実施形態は、ＦＥＣ方式をサポートするマルチメディア通信システムにおける効率的な送信信頼度を取得できるパケット送受信方法及び装置を提案する。
【００６０】
本発明の一実施形態は、ＦＥＣ方式をサポートするマルチメディア通信システムにおけるパケットの特性を考慮してパケットを送受信する方法及び装置を提案する。
【００６１】
本発明の一実施形態は、ＦＥＣ方式をサポートするマルチメディア通信システムにおけるＦＥＣコーディング構造を考慮してパケットを送受信する方法及び装置を提案する。
【００６２】
本発明の一実施形態は、ＦＥＣ方式をサポートするマルチメディア通信システムにおけるパケット送信時点を考慮してパケットを送受信する方法及び装置を提案する。
【００６３】
本発明の一実施形態は、ＦＥＣ方式をサポートするマルチメディア通信システムにおけるパケットの分割特性を考慮してパケットを送受信する方法及び装置を提案する。
【００６４】
本発明の一実施形態は、ＦＥＣ方式をサポートするマルチメディア通信システムにおける信号送信装置と信号受信装置との間の遅延を考慮してパケットを送受信する方法及び装置を提案する。
【００６５】
本発明の一実施形態は、ＦＥＣ方式をサポートするマルチメディア通信システムにおけるバッファサイズを考慮してパケットを送受信する方法及び装置を提案する。
【００６６】
本発明の一実施形態は、ＦＥＣ方式をサポートするマルチメディア通信システムにおけるＦＥＣ方式に関連したＦＥＣ構成情報を送受信する方法及び装置を提案する。
【００６７】
一方、本発明の一実施形態で提案する方法及び装置は、ディジタルマルチメディアブロードキャスティング（Digital multimedia Broadcasting：ＤＭＢ）サービスと、携帯用ディジタルビデオブロードキャスティング−ハンドヘルド（Digital Video Broadcasting-Handheld：ＤＶＰ−Ｈ）サービスと、高度テレビジョンシステム委員会−モバイル／ハンドヘルド（Advanced Television Systems Committee-Mobile/Handheld：ＡＴＳＣ−Ｍ／Ｈ）サービスなどのようなモバイルブロードキャスティングサービスと、インターネットプロトコルテレビジョン（Internet Protocol TeleVision：ＩＰＴＶ）サービスのようなディジタルビデオブロードキャスティングシステムと、ムービングピクチャーエクスパーツグループ（Moving Picture Experts Group：ＭＰＥＧ）メディアトランスポート（MPEG Media Transport：ＭＭＴ）システムと、進化したパケットシステム（Evolved Packet System：ＥＰＳ）と、ロングタームエボリューション（Long Term Evolution：ＬＴＥ）移動通信システムと、ロングタームエボリューション−アドバンスド（Long Term Evolution-Advanced：ＬＴＥ−Ａ）移動通信システムと、高速ダウンリンクパケット接続（high speed downlink packet access：ＨＳＤＰＡ）移動通信システムと、高速アップリンクパケット接続（high speed uplink packet access：ＨＳＵＰＡ）移動通信システムと、第３世代プロジェクトパートナーシップ２（3rd generation project partnership 2：３ＧＰＰ２）で提案した高速レートパケットデータ（high rate packet data：ＨＲＰＤ）移動通信システムと、３ＧＰＰ２で提案した広帯域符号分割多重接続（Wideband Code Division Multiple Access：ＷＣＤＭＡ（登録商標））移動通信システムと、３ＧＰＰ２で提案した符号分割多重接続（Code Division Multiple Access：ＣＤＭＡ）移動通信システムと、米国電気電子技術者協会（Institute of Electrical and Electronics Engineers：ＩＥＥＥ）８０２．１６ｍ通信システムなどのような通信システムと、モバイルインターネットプロトコル（Mobile Internet Protocol）システムなどのような様々な通信システムに適用可能であることはもちろんである。
【００６８】
説明の便宜のために、本発明の一実施形態で提案する方法及び装置が適用されるＦＥＣ方式をサポートするマルチメディア通信システムがＭＭＴシステムであると仮定する。
【００６９】
本発明の実施形態は、ネットワークを通して高解像度（High Definition：ＨＤ）コンテンツ及び超高解像度（Ultra High Definition：ＵＨＤ）コンテンツのような高容量コンテンツだけでなく、映像会議／通話などのような様々なマルチメディアサービスを提供できる携帯電話、テレビジョン（ＴＶ）、コンピュータ、電子掲示板、タブレット、及び電子ブックなどのようなすべての電子デバイスでデータパケットの損失を効率的に復旧するパケット送受信装置及び方法を提案する。
【００７０】
本発明の実施形態では、具体的なＦＥＣ符号化方式について説明していないが、ＦＥＣ符号化方式は、リード−ソロモン（Reed-Solomon：ＲＳ）コード、低密度パリティ検査（Low Density Parity Check：ＬＤＰＣ）コード、ターボコード、排他的論理和（eXclusive OR：ＸＯＲ）コード、Ｐｒｏ−ＭＰＥＧ（Moving Picture Experts Group）ＦＥＣコードなどの特定のＦＥＣ符号化方式に限定されないことに留意すべきである。
【００７１】
以下では、本発明の様々な実施形態を説明するために使用される用語及び定義について整理する。
【００７２】
（１）  ＦＥＣコード
ＦＥＣコードは、エラーシンボル又は削除シンボルを訂正するために使用されるエラー訂正符号を示す。また、ＦＥＣコードは、データを符号化することにより符号化されたデータフローがデータ損失に対して回復性を有するようにするアルゴリズムを示す。
【００７３】
（２）  ソースシンボル
ソースシンボルは、ＦＥＣ符号化過程で使用されるデータのユニットを示す。
【００７４】
（３）  リペアシンボル
リペアシンボルは、エラー訂正のためにリダンダンシー情報を含む符号化シンボルを示す。また、リペアシンボルは、ソースシンボルでない符号化シンボルを示す。ここで、リペアシンボルは、パリティシンボルと呼ばれる。
【００７５】
（４）  ソースパケット
ソースパケットは、ＦＥＣ符号化方式により保護されるパケットを示す。
【００７６】
（５）  ソースパケットブロック
ソースパケットブロックは、単一のブロックとして保護されるＦＥＣソースフローのセグメントされた集合を示す。
【００７７】
（６）  ソースシンボルブロック
ソースシンボルブロックは、単一のソースパケットブロックから生成されるソースシンボルの集合を示す。すなわち、ソースシンボルブロックには、少なくとも１つのソースシンボルが含まれる。
【００７８】
（７）  リペアシンボルブロック
リペアシンボルブロックは、損失されたソースシンボルを復旧するために使用され得るリペアシンボルの集合を示す。すなわち、リペアシンボルブロックには、少なくとも１つのリペアシンボルが含まれる。ここで、リペアシンボルブロックは、パリティシンボルブロックとも呼ばれる。
【００７９】
（８）  符号化シンボルブロック
符号化シンボルブロックは、符号化シンボルの集合を示す。また、符号化シンボルブロックは、ソースシンボルブロックの符号化過程で生成される符号化シンボルの集合を示す。すなわち、符号化シンボルブロックには、少なくとも１つの符号化シンボルが含まれる。
【００８０】
（９）  符号化シンボル
符号化シンボルは、符号化過程により生成されるデータのユニットを示す。ここで、ソースシンボルは、符号化シンボルの一部であり得る。
【００８１】
（１０）  ＦＥＣリペアパケット
ＦＥＣリペアパケットは、リペアシンボルブロックの１つ又はそれ以上のリペアシンボルを配信するためにリペアＦＥＣペイロード識別子（ＩＤ）を有するＭＭＴプロトコル（MMT Protocol：以下、‘ＭＭＴＰ’と称する）パケットを示す。
【００８２】
（１１）  ＦＥＣソースパケット
ＦＥＣソースパケットは、ソースＦＥＣペイロードＩＤを有するＭＭＴＰパケットを示す。
【００８３】
（１２）  ＦＥＣソース又はリペアパケット
ＦＥＣソース又はリペアパケットは、ＦＥＣリペアパケット又はＦＥＣソースパケットを通称する用語である。すなわち、ＦＥＣソース又はリペアパケットは、必要に応じて、ＦＥＣリペアパケットを示すこともでき、ＦＥＣソースパケットを示すこともでき、ＦＥＣリペアパケット及びＦＥＣソースパケットのすべてを示すこともできる。
【００８４】
（１３）  ＦＥＣソースパケットブロック
ＦＥＣソースパケットブロックは、ソースシンボルブロックを配信するためのＦＥＣソースパケットの集合を示す。すなわち、ＦＥＣソースパケットブロックには、少なくとも１つのＦＥＣソースパケットが含まれる。
【００８５】
（１４）  ＦＥＣリペアパケットブロック
ＦＥＣリペアパケットブロックは、リペアシンボルブロックを配信するためのＦＥＣリペアパケットの集合を示す。すなわち、ＦＥＣリペアパケットブロックには、少なくとも１つのＦＥＣリペアパケットが含まれる。ここで、ＦＥＣリペアパケットブロックは、ＦＥＣパリティパケットブロックとも呼ばれる。
【００８６】
（１５）  ＦＥＣソース又はリペアパケットブロック
ＦＥＣソース又はリペアパケットブロックは、ＦＥＣソースパケットブロック及びＦＥＣソースパケットブロックに関連したＦＥＣリペアパケットブロックを通称する用語である。すなわち、ＦＥＣソース又はリペアパケットブロックは、必要に応じて、ＦＥＣソースパケットブロックを示すこともでき、ＦＥＣリペアパケットブロックを示すこともでき、ＦＥＣソースパケットブロック及びＦＥＣリペアパケットブロックのすべてを示すこともできる。すなわち、ＦＥＣソース又はリペアパケットブロックは、符号化シンボルブロックを配信するためのＦＥＣソース又はリペアパケットの集合を示す。したがって、ＦＥＣソース又はリペアパケットブロックには、少なくとも１つのＦＥＣソース又はリペアパケットが含まれる。
【００８７】
（１６）  ＦＥＣペイロードＩＤ
ＦＥＣペイロードＩＤは、ＭＭＴ  ＦＥＣ方式に関するＭＭＴＰパケットのコンテンツを識別するためのＩＤを示す。ここで、ＭＭＴ  ＦＥＣ方式は、ＭＭＴシステムでサポートするＦＥＣ方式を示す。
【００８８】
（１７）  リペアＦＥＣペイロードＩＤ
リペアＦＥＣペイロードＩＤは、リペアパケットに対するＦＥＣペイロードＩＤを示す。ここで、リペアＦＥＣペイロードＩＤは、パリティＦＥＣペイロードＩＤとも呼ばれる。リペアＦＥＣペイロードＩＤは、ＦＥＣリペアパケットのためのリペアソースＦＥＣ構成情報を含み、リペアＦＥＣ構成情報は、ＦＥＣソース又はリペアパケットブロックが少なくとも１つのＦＥＣソース又はリペアパケットを含む場合に、少なくとも１つのＦＥＣソース又はリペアパケットの中で１番目に送信されるＦＥＣソース又はリペアパケットに関連した情報を含む。ここで、１番目に送信されるＦＥＣソース又はリペアパケットに関連した情報は、１番目に送信されるＦＥＣソース又はリペアパケットのタイムスタンプに関連した情報を含む。また、対応するリペアＦＥＣペイロードＩＤを送信する信号送信装置、例えば、ＭＭＴ送信エンティティが２段ＦＥＣコーディング構造をサポートする場合に、１番目に送信されるＦＥＣソース又はリペアパケットに関連した情報は、ＦＥＣでのタイムスタンプに関連した情報を示すタイムスタンプ指示子を含む。以下では、リペアＦＥＣペイロードＩＤ及びタイムスタンプについて具体的に説明するので、ここでは、その詳細な説明を省略する。
【００８９】
（１８）  ソースＦＥＣペイロードＩＤ
ソースＦＥＣペイロードＩＤは、ソースパケットに対するＦＥＣペイロードＩＤを示す。ソースＦＥＣペイロードＩＤは、ＦＥＣソースパケットのためのソースＦＥＣ構成情報を含み、ソースＦＥＣ構成情報は、ＦＥＣソース又はリペアパケットブロックが少なくとも１つのＦＥＣソース又はリペアパケットを含む場合に、少なくとも１つのＦＥＣソース又はリペアパケットの中で１番目に送信されるＦＥＣソース又はリペアパケットに関連した情報を含む。ここで、１番目に送信されるＦＥＣソース又はリペアパケットに関連した情報は、１番目に送信されるＦＥＣソース又はリペアパケットのタイムスタンプに関連した情報を含む。また、対応するソースＦＥＣペイロードＩＤを送信する信号送信装置、例えば、ＭＭＴ送信エンティティが２段ＦＥＣコーディング構造をサポートする場合に、１番目に送信されるＦＥＣソース又はリペアパケットに関連した情報は、ＦＥＣでのタイムスタンプに関連した情報を示すタイムスタンプ指示子を含む。以下では、ソースＦＥＣペイロードＩＤ、タイムスタンプ、及びタイムスタンプ指示子について具体的に説明するので、ここでは、その詳細な説明を省略する。
【００９０】
（１９）  ＭＭＴ
ＭＭＴは、ＭＰＥＧデータを効率的に配信するために研究中の国際標準を示す。
【００９１】
（２０）  ＦＥＣソースフロー
ＦＥＣソースフローは、ＭＭＴ  ＦＥＣ方式により保護されるＭＭＴＰパケットのフローを示す。
【００９２】
（２１）  ＦＥＣ方式
ＦＥＣ方式は、ＦＥＣコードを使用するために要求される追加のプロトコル側面を定義する規格を示す。
【００９３】
（２２）  ＦＥＣリペアフロー
ＦＥＣリペアフローは、ＦＥＣソースフローを保護するリペアシンボルを運搬するデータフローを示す。ここで、ＦＥＣリペアフローは、ＦＥＣパリティフローと呼ばれる。
【００９４】
（２３）  ＦＥＣ符号化されたフロー
ＦＥＣ符号化されたフローは、ＦＥＣソースフロー及び１つ又はそれ以上の関連ＦＥＣリペアフローで構成されたフローの論理的な集合を示す。
【００９５】
（２４）  アセット
アセットは、固有のＩＤと関連し、マルチメディアプレゼンテーション（multimedia presentation）を生成するために使用されるマルチメディアデータエンティティを示す。
【００９６】
（２５）  メディア処理ユニット（ＭＰＵ）
ＭＰＵは、メディアコーデックに依存しない（agnostic）、独立して復号可能な同期型データ又は非同期型データのための一般コンテナ（generic container）を示す。
【００９７】
（２６）  パッケージ
パッケージは、ＭＭＴを使用して配信されるメディアデータの論理的なコレクション（collection）を示す。
【００９８】
（２７）  ＭＭＴパケット
ＭＭＴパケットは、ＭＭＴＰを用いて配信されるメディアデータのフォーマット化されたユニット（formatted unit）を示す。
【００９９】
（２８）  ＭＭＴペイロード
ＭＭＴペイロードは、ＭＭＴＰ又はインターネットアプリケーションレイヤートランスポートプロトコルを使用してパッケージ及び／又はシグナリングメッセージを運搬するメディアデータのフォーマット化されたユニットを示す。ここで、インターネットアプリケーションレイヤートランスポートプロトコルは、例えば、リアルタイムトランスポートプロトコル（Real-Time Transport Protocol：ＲＴＰ）などであり得る。
【０１００】
（２９）  ＭＭＴＰ
ＭＭＴＰは、インターネットプロトコル（Internet Protocol：ＩＰ）ネットワークを通してＭＭＴＰペイロードを配信するためのアプリケーションレイヤートランスポートプロトコルを示す。
【０１０１】
図１を参照して本発明の一実施形態によるＦＥＣ方式をサポートするＭＭＴシステムの構造の一例について説明する。
【０１０２】
図１は、本発明の一実施形態によるＦＥＣ方式をサポートするＭＭＴシステムの構造の一例を概略的に示す図である。
【０１０３】
図１を参照すると、ＭＭＴシステムは、ＭＭＴ送信エンティティ１１１と、ＭＭＴ受信エンティティ１１３と、パッケージプロバイダ１１５と、複数のアセットプロバイダ、例えば、Ｎ個のアセットプロバイダ、すなわち、アセットプロバイダ＃１  １１７−１，．．．，アセットプロバイダ＃Ｎ  １１７−Ｎとを含む。ＭＭＴ送信エンティティ１１１とＭＭＴ受信エンティティ１１３との間には、ＭＭＴＰに基づいて通信が実行される。ここで、ＭＭＴＰについて説明すると、次の通りである。
【０１０４】
ＭＭＴＰは、ＭＭＴパッケージを効率的であり信頼できるように転送するために設計されたアプリケーションレイヤートランスポートプロトコルである。ＭＭＴＰは、メディア多重化及びネットワークジッター計算などのような向上した特性をサポートする。このような特性は、様々なタイプの符号化されたメディアデータで構成されるコンテンツを効率的に配信することを可能にする。ＭＭＴＰは、既存のネットワークプロトコル、例えば、ユーザデータグラムプロトコル（User Datagram Protocol：ＵＤＰ）又はＩＰの上位レイヤーで動作でき、様々なアプリケーションをサポートできる。
【０１０５】
ＭＭＴ送信エンティティ１１１は、１つ又はそれ以上のＭＭＴ受信エンティティにメディアデータを送信するＭＭＴエンティティであり得、例えば、ＭＭＴブロードキャスティングサーバなどであり得る。
【０１０６】
ＭＭＴ受信エンティティ１１３は、メディアデータの受信及び消費を行うＭＭＴエンティティであり得、例えば、移動端末機（Mobile Station：ＭＳ）及びユーザ端末機（User Equipment：ＵＥ）などのような無線デバイスであり得る。例えば、ＭＭＴ送信エンティティ１１１がＭＭＴブロードキャスティングサーバであり、ＭＭＴ受信エンティティ１１３がＭＳである場合に、ＭＭＴブロードキャスティングサーバは、基地局（ＢＳ）を通してメディアデータをＭＳに送信できる。図１には、基地局が図示されていないことに留意すべきである。
【０１０７】
ＭＭＴ送信エンティティ１１１は、パッケージをＭＭＴＰパケットフローとしてＭＭＴ受信エンティティ１１３に送信する。ここで、パッケージは、メディアデータの論理的なコレクションを示し、ＭＭＴ技術を使用して配信される。ＭＭＴ送信エンティティ１１１は、ＭＭＴＰパケットフローを通して、アセット、プレゼンテーション情報（Presentation Information：ＰＩ）などをＭＭＴ受信エンティティ１１３に送信する。ここで、アセット及びＰＩについての具体的な説明を省略する。ＭＭＴ送信エンティティ１１１は、パッケージプロバイダ１１５により提供されるパッケージのＰＩに基づいてコンテンツプロバイダ（図１には図示せず）からコンテンツを取得することが要求される。
【０１０８】
ＭＭＴ送信エンティティ１１１及びＭＭＴ受信エンティティ１１３は、ＭＭＴＰパケットフローを通してＭＭＴシグナリングを送受信する。
【０１０９】
パッケージプロバイダ１１５及びコンテンツプロバイダは、共に位置し得る。メディアコンテンツは、ＭＭＴＰパケットフローを形成するカプセル化されたＭＭＴ処理ユニットのシリーズでセグメントされるアセットとして提供される。
【０１１０】
メディアコンテンツのＭＭＴＰパケットフローは、関連したトランスポート特性情報を使用して生成される。シグナリングメッセージ、パッケージの配信及び消費を管理するために使用され得る。
【０１１１】
図１において、ＭＭＴ送信エンティティ１１１は、信号送信装置であり、ＭＭＴ受信エンティティ１１３は、信号受信装置である。
【０１１２】
図１を参照して本発明の一実施形態によるＦＥＣ方式をサポートするＭＭＴシステムの構造の一例について説明した。図２を参照して、本発明の一実施形態によるＦＥＣ方式をサポートするＭＭＴシステムの構造の他の例について説明する。
【０１１３】
図２は、本発明の一実施形態によるＦＥＣ方式をサポートするＭＭＴシステムの構造の他の例を概略的に示す図である。
【０１１４】
図２を参照すると、ＭＭＴシステムは、信号送信装置２００と、信号受信装置２１０とを含む。
【０１１５】
信号送信装置２００は、ＦＥＣ上位プロトコルに対応するプロトコルＡ処理動作を実行するプロトコルＡ処理ブロック２０１、ＦＥＣ符号化ブロック２０２、ＦＥＣ下位プロトコルに対応するプロトコルＢ処理動作を実行するプロトコルＢ処理ブロック２０３、及び送信器物理レイヤーブロック２０４を含む。
【０１１６】
プロトコルＡ処理ブロック２０１は、送信データに対するプロトコルＡ処理動作を実行してソースペイロード２３０を生成し、生成されたソースペイロード２３０をＦＥＣ符号化ブロック２０２に出力する。
【０１１７】
ＦＥＣ符号化ブロック２０２は、少なくとも１つのソースパケットを含むソースパケットブロックを生成し、生成されたソースパケットブロックに対して予め設定されているＦＥＣ方式に対応するＦＥＣ符号化動作を実行してパリティペイロード２３１を含むリペアシンボルを生成する。ＦＥＣ符号化ブロック２０２は、ソースパケット及びリペアシンボルにＦＥＣヘッダ２３２を付加することによりＦＥＣソースパケットを生成し、生成されたＦＥＣソースパケットをプロトコルＢ処理ブロック２０３に出力する。ＦＥＣソースパケットは、ＦＥＣヘッダをソースパケットと結合することにより生成され、ＦＥＣリペアパケットは、ＦＥＣヘッダをリペアシンボルと結合することにより生成される。
【０１１８】
図２において、ＦＥＣソースパケットは、ＦＥＣヘッダの後ろにソースペイロードが位置する形態で生成されるデータユニットである。あるいは、ＦＥＣソースパケットは、ソースペイロードの後ろにＦＥＣヘッダが位置する形態で生成されるデータユニットであり得ることはもちろんである。
【０１１９】
図２において、ＦＥＣ符号化ブロック２０２がプロトコルＡ処理ブロック２０１とプロトコルＢ処理ブロック２０３との間に位置する形態で具現されているが、これとは異なり、プロトコルＡ処理ブロック２０１がＦＥＣ符号化ブロック２０２を含む形態で具現されることができる。この場合に、プロトコルＡ処理ブロック２０１の機能を実行するためのプロトコルヘッダがＦＥＣパリティパケットに含まれることができ、ＦＥＣ符号化ブロック２０２を含むプロトコルＡ処理ブロック２０１は、ソースパケット及びパリティパケットを１つのパケットフローで生成するためのマルチプレクサを含む。
【０１２０】
プロトコルＢ処理ブロック２０３は、ＦＥＣ符号化ブロック２０２から転送されるＦＥＣソースパケット又はＦＥＣパリティパケットに対してプロトコルＢに対応するプロトコルＢ処理動作を実行することによりプロトコルＢ信号を生成し、プロトコルＢ信号を送信器物理レイヤー処理ブロック２０４に転送する。
【０１２１】
送信器物理レイヤーブロック２０４は、プロトコルＢ処理ブロック２０３から転送されたプロトコルＢ信号を物理レイヤー送信に適合した物理レイヤー信号に変換し、変換された物理レイヤー信号をトランスポートチャネル２２０を通して信号受信装置２１０に転送する。プロトコルＢ処理ブロック２０３と送信器物理レイヤーブロック２０４との間には、様々なレイヤーが存在し得、ここでは、その具体的な説明を省略する。
【０１２２】
図２では、プロトコルＡ処理ブロック２０１、ＦＥＣ符号化ブロック２０２、プロトコルＢ処理ブロック２０３、及び送信器物理レイヤーブロック２０４が個別のユニットとして図示されているが、これは、説明の便宜のためのものであることに留意すべきである。言い換えれば、プロトコルＡ処理ブロック２０１、ＦＥＣ符号化ブロック２０２、プロトコルＢ処理ブロック２０３、及び送信器物理レイヤーブロック２０４の中の２つ以上が１つのユニットに統合される形態にも具現されることができることはもちろんである。
【０１２３】
信号受信装置２１０は、受信器物理レイヤーブロック２１１、ＦＥＣ下位プロトコルに対応する動作を実行するプロトコルＢ処理ブロック２１２、ＦＥＣ復号化ブロック２１３、及びＦＥＣ上位プロトコルに対応する動作を実行するプロトコルＡ処理ブロック２１４を含む。
【０１２４】
受信器物理レイヤーブロック２１１は、トランスポートチャネル２２０を通して信号受信装置２１０で受信された物理レイヤー信号をプロトコルＢ信号に変換し、変換されたプロトコルＢ信号をプロトコルＢ処理ブロック２１２に転送する。信号送信装置２００で説明したように、プロトコルＢ処理ブロック２１２と受信器物理レイヤー処理ブロック２１１との間には、様々なレイヤーが存在し得、プロトコルＢ処理ブロック２１２と受信器物理レイヤー処理ブロック２１１との間に存在する様々な処理ブロックについては、具体的な説明を省略する。
【０１２５】
プロトコルＢ処理ブロック２１２は、プロトコルＢ処理ブロック２１２で受信された物理レイヤー信号に対してプロトコルＢ処理動作を実行することによりプロトコルＢ信号を生成した後に、プロトコルＢ信号をＦＥＣ復号ブロック２１３に配信する。プロトコルＢ信号は、ＦＥＣパケット、すなわち、ＦＥＣソースパケット又はＦＥＣパリティパケットであり得る。信号送信装置２００から送信したＦＥＣパケットの中の一部は、ネットワーク輻輳及び物理レイヤーで発生したエラーの影響により損失される。したがって、信号送信装置２００から送信したＦＥＣパケットの中の一部は、ＦＥＣ復号ブロック２１３に配信されない可能性もある。
【０１２６】
ＦＥＣ復号ブロック２１３は、プロトコルＢ処理ブロック２１２から転送されたＦＥＣパケットに対するＦＥＣ復号動作を実行することにより信号送信装置２００から送信したソースペイロードを検出し、検出されたソースペイロードをプロトコルＡ処理ブロック２１４に配信する。プロトコルＡ処理ブロック２１４は、ＦＥＣ復号化ブロック２１３から配信されたソースペイロードに対するプロトコルＡ処理動作を実行することにより送信データを検出する。
【０１２７】
上述したように、ＦＥＣヘッダは、ＦＥＣペイロードＩＤを含み、ＦＥＣソースパケットのためのＦＥＣヘッダは、ソースＦＥＣペイロードＩＤを含み、ＦＥＣパリティパケットのためのＦＥＣヘッダは、リペアＦＥＣペイロードＩＤを含む。
【０１２８】
本発明の一実施形態は、ＭＭＴシステムに適用されるので、ソースパケットは、ＭＭＴパケットとなり、ＦＥＣソースパケットは、ソースＦＥＣペイロードＩＤを有するＭＭＴパケットとなり、ＦＥＣリペアパケットは、リペアシンボルを運搬するリペアＦＥＣペイロードＩＤを有するＭＭＴパケットとなる。
【０１２９】
図２では、受信器物理レイヤーブロック２１１、プロトコルＢ処理ブロック２１２、ＦＥＣ復号化ブロック２１３、及びプロトコルＡ処理ブロック２１４が個別のユニットとして図示されているが、これは、説明の便宜のためのものであることに留意すべきである。言い換えれば、受信器物理レイヤーブロック２１１、プロトコルＢ処理ブロック２１２、ＦＥＣ復号化ブロック２１３、及びプロトコルＡ処理ブロック２１４の中の２つ以上が１つのユニットに統合される形態にも具現されることができることはもちろんである。
【０１３０】
図２を参照して、本発明の一実施形態によるＦＥＣ方式をサポートするＭＭＴシステムの構造の他の例について説明した。図３を参照して、本発明の一実施形態によるＦＥＣ方式をサポートするＭＭＴシステムにおいてアプリケーションレイヤーフォワードエラー訂正（ＡＬ−ＦＥＣ）のためのアーキテクチャーについて説明する。以下では、説明の便宜上、ＡＬ−ＦＥＣのためのアーキテクチャーをＡＬ−ＦＥＣアーキテクチャーと称する。
【０１３１】
図３は、本発明の一実施形態によるＦＥＣ方式をサポートするＭＭＴシステムにおけるＡＬ−ＦＥＣアーキテクチャーを概略的に示す図である。
【０１３２】
図３の説明に先立って、図３に示されているＡＬ−ＦＥＣアーキテクチャーは、信号送信装置に含まれているＡＬ−ＦＥＣアーキテクチャーの構造であることに留意すべきである。
【０１３３】
ＡＬ−ＦＥＣアーキテクチャーは、ＭＭＴアプリケーションユニット３１０と、ＭＭＴＰユニット３２０と、ＭＭＴ  ＦＥＣユニット３３０と、ＦＥＣコードユニット３４０と、トランスポートレイヤー処理ユニット３５０と、インターネットプロトコル（Internet Protocol：ＩＰ）処理ユニット３６０とを含む。ここで、ＭＭＴＰユニット３２０及びＭＭＴ  ＦＥＣユニット３３０は、ＡＬ−ＦＥＣプロセッサに含まれる。
【０１３４】
ＭＭＴ方式は、ＩＰネットワークにおいて安定した配信のためにＡＬ−ＦＥＣメカニズムを提供する。ＭＭＴシステムがサポートするＦＥＣ方式（説明の便宜上、'ＭＭＴ  ＦＥＣ方式’と称する）は、配信関数（delivery function）のビルディングブロック（building block）として説明される。
【０１３５】
まず、ＭＭＴアセットは、ＭＭＴアプリケーションユニット３１０からＭＭＴＰユニット３２０に配信され、ＭＭＴＰユニット３２０は、予め設定されているＭＭＴＰパケット化方式を転送されたＭＭＴＰアセットに適用することによりＭＭＴＰパケットを生成し、生成されたＭＭＴＰパケットを送受信上での保護のためにＭＭＴ  ＦＥＣユニット３３０に配信する。ＭＭＴＰユニット３２０で使用したＭＭＴＰパケット化方式は、様々な方式で具現されることができ、ここでは、その詳細な説明を省略する。
【０１３６】
ＭＭＴアプリケーションユニット３１０は、ＦＥＣ構成情報をＭＭＴ  ＦＥＣユニット３３０に提供し、ＦＥＣ構成情報は、ＦＥＣ符号化されたフローのＩＤと、ＦＥＣコーディング構造及びＦＥＣコードに関連した情報などを含む。ＦＥＣ構成情報は、信号送信装置に対応する信号受信装置に配信され、以下では、ＦＥＣ構成情報について具体的に説明するので、ここでは、その詳細な説明を省略する。
【０１３７】
ＭＭＴ  ＦＥＣユニット３３０は、予め設定されているＦＥＣ方式に対応してＭＭＴＰユニットから配信されたＭＭＴＰパケットを符号化することにより、リペアシンボル、リペアＦＥＣペイロードＩＤ、及びソースＦＥＣペイロードＩＤを生成し、生成されたリペアシンボル、リペアＦＥＣペイロードＩＤ、及びソースＦＥＣペイロードＩＤをＭＭＴＰユニット３２０に配信する。ＭＭＴＰユニット３２０は、ＭＭＴ  ＦＥＣユニット３３０から配信されたリペアシンボルをＭＭＴＰパケットとともにトランスポートレイヤー３５０に配信する。
【０１３８】
一方、ＭＭＴ送信エンティティは、保護を必要とするパッケージ内のＭＭＴアセット及びＦＥＣソースフローの個数を決定する。ＭＭＴアセットの中の１つ又はそれ以上は、単一のＦＥＣソースフローとして保護され、単一のＦＥＣソースフローは、ＭＭＴアセットの中の１つ又はそれ以上を運搬するＭＭＴＰパケットで構成される。ＦＥＣソースフロー及びＦＥＣソースフローに関するＦＥＣ構成情報は、保護のために、ＭＭＴ  ＦＥＣユニット３３０に配信される。ＭＭＴ  ＦＥＣユニット３３０は、ＦＥＣコードを使用して１つ又はそれ以上のＦＥＣリペアフローを含むリペアシンボルを生成する。リペアシンボルは、ソースＦＥＣペイロードＩＤ及びリペアＦＥＣペイロードＩＤとともにＭＭＴＰユニット３２０に配信される。ＭＭＴＰユニット３２０は、ＦＥＣソース及びリペアパケットをＭＭＴ受信エンティティに配信する。ＭＭＴ受信エンティティに含まれたＭＭＴＰユニットは、ＦＥＣソースフロー及びＦＥＣソースフローの関連したＦＥＣリペアフローを信号受信エンティティに含まれたＭＭＴ  ＦＥＣユニットに配信する。ＭＭＴ  ＦＥＣユニットは、ＭＭＴＰユニットから配信されたＦＥＣソースフロー及びＦＥＣソースフローの関連したＦＥＣリペアフローを予め設定されているＦＥＣ方式に基づいて復号することによりＭＭＴＰパケットを復旧し、復旧されたＭＭＴＰパケットをＭＭＴＰユニットに配信する。
【０１３９】
一方、ＭＭＴ  ＦＥＣユニット３３０は、ＦＥＣソースフローをソースパケットブロックに分割し、ソースシンボルブロックを生成する。ＭＭＴ  ＦＥＣユニット３３０は、ソースシンボルブロックをＦＥＣ符号化のためにＦＥＣコードブロック３４０に配信する。ここで、ＦＥＣ符号化は、ソースシンボルブロックからリペアシンボルを生成するプロセスを示す。
【０１４０】
ＦＥＣコードブロック３４０は、ＭＭＴ  ＦＥＣユニット３３０から配信されたソースシンボルブロックを予め設定されているＦＥＣコードアルゴリズムに基づいてＦＥＣ符号化を行うことによりリペアシンボルを生成する。ＦＥＣコードブロック３４０が使用するＦＥＣコードアルゴリズムは、様々な形態で具現され得る。本発明の一実施形態では、ＦＥＣコードアルゴリズムが国際標準化機構（International Organization for Standardization：ＩＳＯ）／国際電気標準会議（International Electro technical Commission：ＩＥＣ）２３００８−１０で使用された方式でソースシンボルブロックからリペアシンボルを生成するＦＥＣコードアルゴリズムであると仮定する。
【０１４１】
一方、ＡＬ−ＦＥＣアーキテクチャーは、ＦＥＣ構成情報側面を考慮して説明する。
【０１４２】
ＭＭＴアプリケーションユニット３１０は、ＡＬ−ＦＥＣ保護の後に配信されるＭＭＴアセットを決定し、決定されたＭＭＴアセットをＭＭＴＰユニット３２０に配信する。ＭＭＴアプリケーションユニット３１０は、ＡＬ−ＦＥＣ関連情報、例えば、ＦＥＣ構成情報をＭＭＴＰユニット３２０及びＭＭＴ  ＦＥＣユニット３３０、すなわち、ＡＬ−ＦＥＣプロセッサに配信する。ここで、ＦＥＣ構成情報は、ＦＥＣメッセージに含まれたＦＥＣ制御情報及びＦＥＣソース又はリペアパケットブロック送信時間期間に関連した情報などを含み得、ＦＥＣ構成情報について具体的に説明するので、ここでは、その詳細な説明を省略する。
【０１４３】
ＭＭＴＰユニット３２０は、入力されたＭＭＴアセットをパケット化することによりＭＭＴパケットを生成し、ＭＭＴパケットヘッダを生成されたＭＭＴパケットに付加することによりソースパケットを生成し、少なくとも１つのソースパケットを含むソースパケットブロックをＭＭＴ  ＦＥＣユニット３３０に出力する。ＭＭＴパケットヘッダは、ＭＭＴパケットが送信される時間に関連した情報、例えば、タイムスタンプを含む。ＭＭＴＰユニット３２０は、ＭＭＴパケットから生成されたＦＥＣソース又はパケットブロックに含まれた少なくとも１つのＦＥＣソース又はリペアパケットの中で１番目に送信されるＦＥＣソース又はリペアパケットとＦＥＣソース又はパケットブロックに含まれた少なくとも１つのＦＥＣソース又はリペアパケットの中で最後に送信されるＦＥＣソース又はリペアパケットの送信時間情報、すなわち、タイムスタンプの差がＦＥＣ構成情報に含まれたＦＥＣソース又はリペアパケットブロック送信時間期間内にあるようにスケジューリング動作を行うことにより各ＭＭＴパケットのタイムスタンプを設定する。
【０１４４】
ＭＭＴ  ＦＥＣユニット３３０は、ＭＭＴアプリケーションユニット３１０から入力されたＦＥＣ構成情報に基づいて与えられたソースシンボルブロック生成方式に従って入力された各ソースパケットブロックからソースシンボルブロックを生成する。このとき、本発明の一実施形態によるソースシンボルブロック生成方式に関する情報がＦＥＣ構成情報として与えられ、ソースシンボルブロック生成方式に関する情報がＦＥＣ構成情報に含まれる場合に、ＭＭＴ  ＦＥＣユニット３３０は、ＦＥＣ構成情報に含まれたソースシンボルブロック生成方式に従ってソースシンボルブロックを生成する。ソースシンボルブロックを生成した後に、ＭＭＴ  ＦＥＣユニット３３０は、生成されたソースシンボルブロックをＦＥＣコードユニット３４０に配信する。
【０１４５】
ＦＥＣコードユニット３４０は、ＭＭＴ  ＦＥＣユニット３３０から配信されたソースシンボルブロックからリペアシンボルブロックを生成することにより、生成されたリペアシンボルブロックをＭＭＴ  ＦＥＣユニット３３０に配信する。
【０１４６】
ＭＭＴ  ＦＥＣユニット３３０は、ソースシンボルブロック及びリペアシンボルブロックに対するＦＥＣペイロードＩＤを生成し、ＦＥＣコードユニット３４０から受信されたリペアシンボルをＭＭＴＰユニット３２０に配信する。
【０１４７】
ＭＭＴＰユニット３２０は、入力されたリペアシンボル及びＦＥＣペイロードＩＤを用いてソースＦＥＣペイロードＩＤをソースパケットに付加することによりＦＥＣソースパケットを生成し、リペアＦＥＣペイロードＩＤ、ＭＭＴＰペイロードヘッダ、及びＭＭＴパケットヘッダをリペアシンボルに付加することによりＦＥＣリペアパケットを生成する。ＭＭＴＰユニット３２０は、生成されたＦＥＣソースパケット及びＦＥＣリペアパケットをトランスポートレイヤーユニット３５０を通してＩＰユニット３６０に配信する。例えば、トランスポートレイヤーは、ユーザデータグラムプロトコル（ＵＤＰ）などであり得る。ここで、ＦＥＣソース又はリペアパケットブロックに含まれたＦＥＣソースパケットのためのＦＥＣペイロードＩＤ又はＦＥＣリペアパケットのためのＦＥＣペイロードＩＤは、ＦＥＣソース又はリペアパケットブロックに含まれた少なくとも１つのＦＥＣソース又はリペアパケットの中で１番目に送信されたＦＥＣソース又はリペアパケットの送信時間情報、例えば、‘Ｔ０’を含む。これとは異なり、送信時間情報Ｔ０は、ＦＥＣ符号化動作の後にＴ０を含むＭＭＴパケットヘッダに対してＦＥＣ符号化動作を実行し、ＦＥＣリペアパケットのためのＭＭＴパケットヘッダにＴ０を含ませて送信される。
【０１４８】
ＭＭＴＰユニット３２０は、ＭＭＴアプリケーションユニット３１０により生成されたＦＥＣ構成情報を含むＦＥＣメッセージにＭＭＴペイロードヘッダ及びＭＭＴパケットヘッダを付加することにより、ＭＭＴペイロードヘッダ及びＭＭＴパケットヘッダが付加されたＦＥＣメッセージを送信する。
【０１４９】
図３に図示していないが、ＭＭＴアプリケーションユニット３１０は、本発明の一実施形態で提案する仮想受信器バッファリングモデル（Hypothetical Receiver Buffering  Model：ＨＲＢＭ）メッセージを生成する。ここで、ＨＲＢＭメッセージは、最大バッファサイズに関連した情報、例えば、‘最大バッファサイズ’と、信号送信装置と信号受信装置との間の遅延に関連した情報、例えば、‘固定されたエンドツーエンド遅延（fixed end-to-end delay）’とを含む。ＭＭＴアプリケーションユニット３１０は、ＭＭＴペイロードヘッダ及びＭＭＴパケットヘッダを生成されたＨＲＢＭメッセージに付加することにより、ＭＭＴペイロードヘッダ及びＭＭＴパケットヘッダが付加されたＨＲＢＭメッセージを配信する。
【０１５０】
一方、固定されたエンドツーエンド遅延は、パケット送信の時にネットワーク状況を考慮してパケットが信号受信装置で受信されるまでの最大遅延時間を示し、ＦＥＣソース又はリペアパケットブロックの送信時間期間を含むこともあり、又は含まないこともある。固定されたエンドツーエンド遅延がＦＥＣソース又はリペアパケットブロックの送信時間期間を含む場合に、信号受信装置は、固定されたエンドツーエンド遅延に対応して、すなわち、パケットの送信時間（Ｔｓ）＋固定されたエンドツーエンド遅延に対応してＦＥＣ復号動作を実行した後のパケットを信号受信装置に含まれたＭＭＴアプリケーションユニット（図３に図示せず）に提供できる。これとは異なり、固定されたエンドツーエンド遅延がＦＥＣソース又はリペアパケットブロックの送信時間期間を含まない場合に、信号受信装置は、ＦＥＣメッセージのＦＥＣソース又はリペアパケット送信時間期間情報と、固定されたエンドツーエンド遅延が示す時間に対応して、すなわち、パケットの送信時間（Ｔｓ）＋固定されたエンドツーエンド遅延＋ＦＥＣソース又はリペアパケットブロック送信時間期間に対応してＦＥＣ復号動作を実行した後のパケットを信号受信装置に含まれたＭＭＴアプリケーションユニットに提供できる。また、ＦＥＣソース又はリペアパケットブロック送信時間期間は、すべてのＦＥＣソース又はリペアパケットブロックが設定されたＦＥＣソース又はリペアパケットブロック送信時間期間内に送信されるべきであることを意味する。
【０１５１】
図３において、ソースパケットブロック単位でＦＥＣソースパケットが生成され、ソースパケットブロック単位でＦＥＣリペアパケットが生成され送信される。しかしながら、実際のネットワーク環境では、ＭＭＴＰユニット３２０が生成したソースパケットがＭＭＴ  ＦＥＣユニット３３０に入力され、それと同時にソースパケットにソースＦＥＣペイロードＩＤを付加することにより、ソースパケットはＦＥＣソースパケットとして生成され、ＦＥＣソースパケットは即座に送信される。ＭＭＴ  ＦＥＣユニット３３０は、ソースパケットをＭＭＴ  ＦＥＣユニット３３０に含まれている内部のメモリに記憶され、ソースパケットブロックのための最後のソースパケットがＭＭＴ  ＦＥＣユニット３３０に入力される場合に、ソースパケットブロックからソースシンボルブロックを生成し、生成されたソースシンボルブロックをＦＥＣコードユニット３４０に配信する。その後に、ＦＥＣコードユニット３４０がＭＭＴ  ＦＥＣユニット３３０から配信されたソースシンボルブロックに基づいてパリティシンボルブロックを生成し、生成されたパリティシンボルブロックをＦＥＣペイロードＩＤとともにＭＭＴＰユニット３２０に配信し、ＭＭＴＰユニット３２０がＭＭＴ  ＦＥＣユニット３４０から配信されたパリティシンボルブロックに基づいてＦＥＣリペアパケットを生成して配信することが好ましい。
【０１５２】
ＭＭＴアプリケーションユニット３１０、ＭＭＴＰユニット３２０、ＭＭＴ  ＦＥＣユニット３３０、ＦＥＣコードユニット３４０、トランスポートレイヤー処理ユニット３５０、及びＩＰ処理ユニット３６０が個別のユニットとして説明されるが、これは、説明の便宜のためのものである。言い換えれば、ＡＬ−ＦＥＣアーキテクチャーは、ＭＭＴアプリケーションユニット３１０、ＭＭＴＰユニット３２０、ＭＭＴ  ＦＥＣユニット３３０、ＦＥＣコードユニット３４０、トランスポートレイヤー処理ユニット３５０、及びＩＰ処理ユニット３６０の中の２個以上が１個のユニットに統合される形態でも具現されることができる。
【０１５３】
図３を参照して本発明の一実施形態によるＦＥＣ方式をサポートするＭＭＴシステムにおけるＡＬ−ＦＥＣアーキテクチャーについて説明した。図４を参照してＦＥＣ方式をサポートするＭＭＴシステムで使用される２段ＦＥＣコーディング構造について説明する。
【０１５４】
図４は、本発明の一実施形態によるＦＥＣ方式をサポートするＭＭＴシステムで使用される２段ＦＥＣコーディング構造を概略的に示す図である。
【０１５５】
図４を説明すると、ＭＭＴ  ＦＥＣ方式は、ＦＥＣソースフローでＭＭＴアセットに対する適合した保護レベルのためにレイヤー化されるか又は非レイヤー化されるメディアデータに対するＭＭＴＰパケットのマルチレベル構成を提供する。例えば、マルチレベル構成は、２段ＦＥＣコーディング構造及びレイヤー認識ＦＥＣ（Layer-Aware FEC：ＬＡ−ＦＥＣ）コーディング構造などを含む。
【０１５６】
ＭＭＴ方式において、相対的に高い信頼度を要求するＭＭＴＰパケットを１つ以上のＦＥＣコードを使用して保護するための２段ＦＥＣコーディング構造を提案している。２段ＦＥＣコーディング構造は、予め定められた個数のＭＭＴＰパケットを含むソースパケットを保護するためのＡＬ−ＦＥＣに対するＦＥＣコーディング構造を示す。
【０１５７】
図４において、ｉ番目のＰ１は、ｉ番目のソースシンボルブロックに対するリペアシンボルを示し、Ｐ２は、ソースシンボルブロックに対するリペアシンボルブロックを示す。ここで、ｉ＝１，２，．．．，Ｍである。
【０１５８】
ソースパケットブロックは、複数のＦＥＣコーディング構造、すなわち、ケース０に対応するＦＥＣコーディング構造、ケース１に対応するＦＥＣコーディング構造、及びケース２に対応するコーディング構造の中の１つに従って符号化されるのであろう。ここで、ケース０に対応するＦＥＣコーディング構造、ケース１に対応するＦＥＣコーディング構造、及びケース２に対応するＦＥＣコーディング構造について説明する。
【０１５９】
（１）ケース０に対応するＦＥＣコーディング構造（ケース０）
ケース０に対応するＦＥＣコーディング構造は、ＦＥＣ符号化が適用されないことを示す。
【０１６０】
（２）ケース１に対応するＦＥＣコーディング構造（ケース１）
ケース１に対応するＦＥＣコーディング構造は、１段ＦＥＣコーディング構造を示す。
【０１６１】
（３）ケース２に対応するコーディング構造（ケース２）
ケース２に対応するコーディング構造は、２段ＦＥＣコーディング構造を示す。
【０１６２】
２段ＦＥＣコーディング構造に対して、１個のソースパケットブロックは、Ｍ個のソースパケットブロックに分割される。Ｍ個のソースパケットブロックの各々は、ソースパケットサブブロックと呼ばれる。ここで、Ｍは、１より大きい（Ｍ＞１）。分割されたｉ番目のソースパケットブロック、すなわち、ｉ番目のソースパケットサブブロックは、ソースシンボルブロック生成（Source Symbol Block Generation：ＳＳＢＧ）モードの中の１つに対応するｉ番目のソースシンボルブロックに変換される。以下では、ＳＳＢＧモードについて説明するので、ここでは、その詳細な説明を省略する。
【０１６３】
その後に、ｉ番目のソースシンボルブロックは、ＦＥＣ１コードにより符号化される。ここで、ｉ＝１，２，．．．，Ｍである。その後に、Ｍ個のソースシンボルブロックは、ＦＥＣ２コードにより単一のソースシンボルブロックを構成するように接続される。
【０１６４】
一方、Ｍ個のリペアシンボルブロックは、ＦＥＣ１コードによりＭ個のソースシンボルブロックから生成され、１個のリペアシンボルブロックは、ＦＥＣ２コードにより接続されたソースシンボルブロックから生成される。
【０１６５】
ケース０に対応するＦＥＣコーディング構造に対して、ＦＥＣ１及びＦＥＣ２符号化は、スキップされるのであろう。ケース０に対応するＦＥＣコーディング構造に対しては、リペアシンボルが生成されない。
【０１６６】
ケース１に対応するＦＥＣコーディング構造に対しては、Ｍが'１'に設定され、ＦＥＣ１符号化又はＦＥＣ２符号化がスキップされるのであろう。
【０１６７】
以下では、上述した２段ＦＥＣコーディング構造について具体的に説明すると、次の通りである。
【０１６８】
２段ＦＥＣコーディング構造によると、ＭＭＴ  ＦＥＣユニットは、予め定められた個数のソースパケットを含むソースパケットサブブロックをＭ（Ｍは、１より大きい整数である）個の第１のソースパケットサブブロック（１番目〜Ｍ番目のソースパケットブロック）に分割し、それぞれの第１のソースパケットサブブロックから第１のソースシンボルサブブロック（１番目〜Ｍ番目のソースシンボルブロック）を生成し、それぞれの第１のソースシンボルサブブロックに対して第１のＦＥＣ符号化動作を実行することにより第１のリペアシンボルブロックを含む第１の符号化シンボルを生成する。ここで、第１のＦＥＣ符号化動作は、ＦＥＣ１コードに基づく符号化動作を示す。
【０１６９】
ＭＭＴ  ＦＥＣユニットは、Ｍ個の第１のソースシンボルサブブロックを第２のソースシンボルブロックとして生成することにより第２のＦＥＣ符号化動作により生成される第２のリペアシンボルブロックを含む第２の符号化シンボルブロックを生成する。ここで、第２のＦＥＣ符号化動作は、ＦＥＣコード２に基づく符号化動作を示す。第１のＦＥＣ符号化動作及び第２のＦＥＣ符号化動作は、同一のＦＥＣコードを使用するか又は異なるＦＥＣコードを使用することができる。ここで、本発明の一実施形態で使用されるＦＥＣコードは、リードソロモン（Reed Solomon：ＲＳ）コード、低密度パリティチェック（Low Density Parity Check：ＬＤＰＣ）コード、ターボコード、ラプターコード（Raptor Code）、排他的論理和（eXclusive OR：ＸＯＲ）コードなどのような現在知られているコード、及び開発されるコードの中の１つであり得、特定のコードに限定されない。
【０１７０】
図４において、ｉ番目のＰ１は、ｉ番目のソースシンボルブロックのためのリペアシンボルブロックであり、Ｐ２は、ソースシンボルブロックのためのリペアシンボルブロックであり、ｉ＝１，２，．．．，Ｍである。
【０１７１】
図４を参照して、本発明の一実施形態によるＦＥＣ方式をサポートするＭＭＴシステムで使用される２段ＦＥＣコーディング構造について説明した。図５を参照して本発明の一実施形態によるＦＥＣ方式をサポートするＭＭＴシステムで使用されるＬＡ−ＦＥＣコーディング構造について説明する。
【０１７２】
図５は、本発明の一実施形態によるＦＥＣ方式をサポートするＭＭＴシステムで使用されるＬＡ−ＦＥＣコーディング構造を概略的に示す図である。
【０１７３】
図５を参照すると、レイヤー構造を有するメディアデータ、すなわち、レイヤー化されたメディアデータを効率的に保護するためにＬＡ−ＦＥＣコーディング構造が使用され得る。例えば、レイヤー化されたメディアデータは、スケーラブルビデオコーディング（Scalable Video Coding：ＳＶＣ）方式又はマルチビュービデオコーディング（Multi-view Video Coding：ＭＶＣ）方式を使用して符号化されたコンテンツなどであり得る。すなわち、ＬＡ−ＦＥＣコーディング構造は、任意のＦＥＣコードにも適用され得、レイヤー化されたメディアデータに特定される。
【０１７４】
ＬＡ−ＦＥＣコーディング構造は、ＦＥＣ構成に対するメディアのレイヤー間の依存性を活用し、各レイヤーに関連する幾つかのリペアフローの生成にその特徴がある。各レイヤーにおいて、各リペアフローは、各リペアフローの関連したレイヤーのデータ及びすべてのレイヤーのデータを保護し、各レイヤーは、もしあれば、依存的である。以下、説明の便宜上、各レイヤーは、‘コンプリメンタリーレイヤー（complementary layer）’と呼ばれる。
【０１７５】
まず、他のレイヤーからのＭＭＴＰパケットは、独立してソースシンボルブロックにグループ化される。ＬＡ−ＦＥＣコーディング構造が使用される場合に、リペアフローのＦＥＣ符号化のために生成されるソースシンボルブロックは、関連したレイヤーのソースシンボルブロックと、もしあれば、関連したレイヤーのすべてのコンプリメンタリーレイヤーからのソースシンボルブロックとを結合するのであろう。他のレイヤーからのソースシンボルブロックの結合は、メディアからのディペンデンシーハイアラーキ（dependency hierarchy）の後に実行されるはずである。すなわち、他のレイヤーからのソースシンボルブロックの結合は、関連したレイヤーのコンプリメンタリーレイヤーのソースシンボルブロックの後ろの各ソースシンボルブロックで実行されるはずである。
【０１７６】
図５には、ＬＡ−ＦＥＣコーディング構造のために２個のレイヤーとレイヤー化されたメディアデータに対するソースシンボルブロック生成の例が図示されている。ベースレイヤー（base layer）及びエンハンスメントレイヤー（enhancement layer）は、図５のＬＡ−ＦＥＣコーディング構造で表現され、エンハンスメントレイヤーは、レイヤー化されたメディアストリームのベースレイヤーに依存する。
【０１７７】
すなわち、図５のＬＡ−ＦＥＣコーディング構造には、メディアが２個のレイヤーを含む場合に、ＬＡ−ＦＥＣ符号化方式を適用するためのソースブロック構成が図示されている。図５において、ベースレイヤーのベース表現（Base Representation：ＢＲ）は、メディアコーデックから独立して復号可能なデータを示し、エンハンスメントレイヤーのエンハンスメント表現（Enhancement Representation：ＥＲ）は、ＢＲに従属するデータを示す。図５において、ＥＲ１のためのパリティを生成する場合にＢＲがともに使用されることに留意すべきである。
【０１７８】
図５を参照して、本発明の一実施形態によるＦＥＣ方式をサポートするＭＭＴシステムで使用されるＬＡ−ＦＥＣコーディング構造について説明した。図６を参照して、本発明の一実施形態によるＦＥＣ方式をサポートするＭＭＴシステムにおいてＭＭＴパケットストリームを使用してソースパケットブロック及びソースシンボルブロックを生成する過程について説明する。
【０１７９】
図６は、本発明の一実施形態によるＦＥＣ方式をサポートするＭＭＴシステムにおいてＭＭＴパケットストリームを使用してソースパケットブロック及びソースシンボルブロックを生成する過程を概略的に示す図である。
【０１８０】
図６を参照すると、アセットは、複数のＭＰＵを含み、それぞれのＭＰＵは、パケット化の後にＭＭＴパケットとして生成される。
【０１８１】
各ＭＰＵがＭＭＴパケットにパケット化される場合に、それぞれのＭＭＴパケットに含まれたヘッダは、関連したＭＭＴパケットに関する送信時間情報、すなわち、タイムスタンプを含む。ＭＭＴパケットは、それぞれ予め定められた個数のＭＭＴパケットを含むソースパケットブロックに分割され、それぞれのソースパケットブロックは、同一の長さ（Ｔ）を有するソースシンボルを含むソースシンボルブロックに変換される。ソースパケットブロックがソースシンボルブロックに変換される場合に、ソースパケットの長さがＴより小さいと、パディングデータ（padding data）をソースパケットに挿入することにより長さＴを有するソースシンボルブロックを生成する。このようにして、ソースパケットブロックに含まれたソースパケットの中の最後のソースパケットは、ソースシンボルブロックとして生成される。
【０１８２】
図６を参照して、本発明の一実施形態によるＦＥＣ方式をサポートするＭＭＴシステムにおいてＭＭＴパケットストリームを使用してソースパケットブロック及びソースシンボルブロックを生成する過程について説明した。図７を参照して、本発明の一実施形態によるＦＥＣ方式をサポートするＭＭＴシステムにおいてソースシンボルブロックを使用してリペアシンボルブロックを生成する過程について説明する。
【０１８３】
図７は、本発明の一実施形態によるＦＥＣ方式をサポートするＭＭＴシステムにおいてソースシンボルブロックを使用してリペアシンボルブロックを生成する過程を概略的に示す図である。
【０１８４】
図７を参照すると、符号化シンボルブロックは、ソースシンボルブロックと、ソースシンボルブロックから生成されるリペアシンボルブロックとを含む。ソースシンボルブロックは、予め設定されているＳＳＢＧモードに従ってソースパケットブロックから生成される。また、リペアシンボルブロックは、ＦＥＣ符号化方式により関連したソースシンボルブロックから生成される。ここで、符号化シンボルフォーマットは、図７に図示される。
【０１８５】
すなわち、図７には、ソースシンボルブロックからＦＥＣコードを使用してリペアシンボルブロックを生成する過程が図示されている。図７において、Ｋ個のソースシンボル、すなわち、ソースシンボル＃０、ソースシンボル＃１，．．．，ソースシンボル＃Ｋ−１を含むソースシンボルブロックは、ＦＥＣエンコーダに入力され、ＦＥＣエンコーダは、入力されたソースシンボルブロックに基づいてＰ個のリペアシンボル、すなわち、リペアシンボル＃０、リペアシンボル＃１，．．．，リペアシンボル＃Ｐ−１を含むリペアシンボルブロックを生成した後に、生成されたリペアシンボルブロックを出力する。ここで、ソースシンボル＃０、ソースシンボル＃１，．．．，ソースシンボル＃Ｋ−１、及びリペアシンボル＃０、リペアシンボル＃１，．．．，リペアシンボル＃Ｐ−１のそれぞれは、Ｔバイトの長さを有する。
【０１８６】
図７を参照して、本発明の一実施形態によるＦＥＣ方式をサポートするＭＭＴシステムにおいてソースシンボルブロックを使用してリペアシンボルブロックを生成する過程について説明した。図８を参照して、本発明の一実施形態によるＦＥＣ方式をサポートするＭＭＴシステムにおいてＦＥＣソース又はリペアパケットブロックに含まれたＦＥＣソース又はリペアパケットの中で１番目に送信されるＦＥＣソース又はリペアパケットに対するタイムスタンプを設定する過程について説明する。
【０１８７】
図８は、本発明の一実施形態によるＦＥＣ方式をサポートするＭＭＴシステムにおいてＦＥＣソース又はリペアパケットブロックに含まれたＦＥＣソース又はリペアパケットの中で１番目に送信されるＦＥＣソース又はリペアパケットに対するタイムスタンプを設定する過程を概略的に示す図である。
【０１８８】
図８を参照すると、ＡＬ−ＦＥＣプロセッサ（図８には図示せず）は、図６と同様に、生成された２０個のソースパケットを含むソースパケットブロックを、図４で説明したように２段ＦＥＣコーディング構造を適用するために１０個のソースパケットを含む各ソースパケットサブブロックに分割する。ＡＬ−ＦＥＣプロセッサは、生成された２個のソースパケットサブブロックに２段ＦＥＣコーディング構造を適用することにより、２個のソースパケットサブブロックの各々に対してＦＥＣ１コードによる３個のリペアシンボルを生成し、２０個のソースパケットを含むソースパケットブロックに対してＦＥＣ２コードによる３個のリペアシンボルを生成する。ＡＬ−ＦＥＣプロセッサは、ＦＥＣペイロードＩＤをソースパケットサブブロック及びリペアシンボルに付加することにより、ＦＥＣソース又はリペアパケットブロックを生成する。
【０１８９】
ソースパケットの各々に含まれたヘッダは、ソースパケット生成の時に関連したパケットに対するタイムスタンプを含み、リペアパケットに含まれたヘッダは、関連したパケットに対するタイムスタンプを含む。
【０１９０】
ここで、ＦＥＣペイロードＩＤは、各パケットが含まれたＦＥＣソース又はリペアパケットブロックに含まれたＦＥＣソース又はリペアパケットの中で１番目に送信されるＦＥＣソース又はリペアパケットに対するタイムスタンプを含む。この場合に、上述したように、２段ＦＥＣコーディング構造が適用される場合に、ソースパケットサブブロックのためのソースＦＥＣペイロードＩＤは、ソースパケットサブブロックのためのＦＥＣソース又はリペアパケットブロックに含まれたＦＥＣソース又はリペアパケットの中で１番目に送信されるＦＥＣソース又はリペアパケットに対するタイムスタンプと、ソースパケットサブブロックが含まれたソースパケットブロックのためのＦＥＣソース又はリペアパケットブロックに含まれたＦＥＣソース又はリペアパケットの中で１番目に送信されるＦＥＣソース又はリペアパケットに対するタイムスタンプとを含み、リペアＦＥＣペイロードＩＤは、関連したＦＥＣソース又はリペアパケットブロックに含まれたＦＥＣソース又はリペアパケットの中で１番目に送信されるＦＥＣソース又はリペアパケットに対するタイムスタンプを含む。
【０１９１】
図８に図示していないが、１段ＦＥＣコーディング構造が適用される場合に、ソースＦＥＣペイロードＩＤは、対応するＦＥＣソース又はリペアパケットブロックに含まれたＦＥＣソース又はリペアパケットの中で１番目に送信されるＦＥＣソース又はリペアパケットに対する１つのタイムスタンプだけを含み、図５で説明したようなＬＡ−ＦＥＣコーディング構造が適用される場合にも、ソースＦＥＣペイロードＩＤは、ベースレイヤー及びエンハンスメントレイヤーを含むＦＥＣソース又はリペアパケットブロックに含まれたＦＥＣソース又はリペアパケットの中で１番目に送信されるＦＥＣソース又はリペアパケットに対する１つのタイムスタンプだけを含む。
【０１９２】
図８を参照すると、ＡＬ−ＦＥＣプロセッサは、２０個のＭＭＴパケットの中で最初の１０個のＭＭＴパケットに含まれた各ヘッダには、０，１，２，．．．，８，９の形態でタイムスタンプを含ませ、３個のＦＥＣリペアパケットが生成されることを考慮して、他の１０個のＭＭＴパケットに含まれたヘッダのそれぞれには、１３，１４，１５，．．．，２１，２２の形態でタイムスタンプを含ませることによりＭＭＴパケットを生成する。
【０１９３】
その後に、合計６個のＦＥＣリペアパケットがＦＥＣ１コードにより生成され、最初の３個のＦＥＣリペアパケットに含まれたＭＭＴヘッダには、１０、１１、１２の形態でタイムスタンプが含まれ、次の３個のＦＥＣリペアパケットに含まれたＭＭＴヘッダには、２３、２４、２５の形態でタイムスタンプが含まれる。
【０１９４】
ＦＥＣ２コードにより生成される３個のＦＥＣリペアパケットに含まれたＭＭＴヘッダには、２６、２７、２８の形態でタイムスタンプが含まれ、３個のＦＥＣリペアパケットがパケット化された後に、ＦＥＣペイロードＩＤがそれぞれのパケットに付加される。すなわち、ソースＦＥＣペイロードＩＤは、ＦＥＣソースパケットに付加され、リペアＦＥＣペイロードＩＤは、ＦＥＣリペアパケットに付加される。１番目のソースパケットサブブロック（1st Source Packet Block）のためのＦＥＣソース又はリペアパケットブロックに含まれた各ＦＥＣソース又はリペアパケットに対してＦＥＣソース又はリペアパケットブロックに含まれたＦＥＣソース又はリペアパケットの中で１番目に送信されるＦＥＣソース又はリペアパケットのタイムスタンプである"０"が設定され、２番目のソースパケットサブブロック（2nd Source Packet Block）のためのＦＥＣソース又はリペアパケットブロックに含まれた各ＦＥＣソース又はリペアパケットに対してＦＥＣソース又はリペアパケットブロックに含まれたＦＥＣソース又はリペアパケットの中で１番目に送信されるＦＥＣソース又はリペアパケットのタイムスタンプである"１３"が設定される。
【０１９５】
ソースパケットブロックのためのＦＥＣソース又はリペアパケットブロックに含まれたＦＥＣソース又はリペアパケットの各々に対してＦＥＣソース又はリペアパケットブロックに含まれたＦＥＣソース又はリペアパケットの中で１番目に送信されるＦＥＣソース又はリペアパケットのタイムスタンプである"０"が設定される。
【０１９６】
例えば、タイムスタンプは、ネットワークタイムプロトコル（Network Time Protocol：ＮＴＰ）タイムスタンプであり、所定数のバイト、例えば、４バイトで具現されることができる。この場合に、上位２バイトは、セカンド（second）を示し、下位２バイトは、フラクション（fraction）を示す。ＮＴＰタイムスタンプの具体的な内容は、"short-format"in clause 6 of IETF RFC5905，NTP version 4で定義している内容に基づいており、ここでは、その詳細な説明を省略する。
【０１９７】
図８には図示していないが、ＦＥＣソース又はリペアパケットブロックに含まれたＦＥＣソース又はリペアパケットの中で１番目に送信されるＦＥＣソース又はリペアパケットのタイムスタンプを送信する方法の他の例は、各ＦＥＣソース又はリペアパケットに対するＭＭＴパケットヘッダにタイムスタンプを含ませることによりタイムスタンプを送信する方式である。
【０１９８】
これとは異なり、タイムスタンプは、ＦＥＣペイロードＩＤとは異なる個別のフィールドを通して送信されることもできる。
【０１９９】
様々なタイムスタンプ送信方式の中のいずれか１つでも、ＦＥＣソース又はリペアパケットブロックに含まれたＦＥＣソース又はリペアパケットの中で１番目に送信されるＦＥＣソース又はリペアパケットのタイムスタンプは、関連したＦＥＣソース又はリペアパケットブロックに含まれたパケットの中で少なくとも１つのＦＥＣソース又はリペアパケットを通して送信されることが好ましい。
【０２００】
通常、ネットワーク上では、パケット損失が発生し得るので、ＦＥＣソース又はリペアパケットブロックに含まれたすべてのＦＥＣソース又はリペアパケットのそれぞれでタイムスタンプが送信される場合に、信号受信装置は、１番目に受信するＦＥＣソース又はリペアパケットから関連したＦＥＣソース又はリペアパケットブロックに含まれたＦＥＣソース又はリペアパケットの中で１番目に送信されるＦＥＣソース又はリペアパケットに対するタイムスタンプを認識できる。
【０２０１】
また、信号受信装置は、ＦＥＣ復号のために少なくとも１つのＦＥＣリペアパケットを受信しなければならない。したがって、ＦＥＣリペアパケットで関連したＦＥＣソース又はリペアパケットに対するタイムスタンプが送信される場合に、信号受信装置は、１番目に受信するＦＥＣリペアパケットから関連したＦＥＣソース又はリペアパケットブロックに含まれたＦＥＣソース又はリペアパケットの中で１番目に送信されたＦＥＣソース又はリペアパケットに対するタイムスタンプを認識できる。
【０２０２】
図４で説明したような２段ＦＥＣコーディング構造の場合に、タイムスタンプが関連したＦＥＣソース又はリペアパケットブロックに含まれたすべてのＦＥＣソース又はリペアパケットの各々に含まれる場合に、ＦＥＣソースパケットは、ＦＥＣソースパケットサブブロックのためのＦＥＣソース又はリペアパケットブロック及びＦＥＣソースパケットブロックのためのＦＥＣソース又はリペアパケットブロックの各々に含まれたＦＥＣソース又はリペアパケットの中で１番目に送信されるＦＥＣソース又はリペアパケットに対するタイムスタンプを含まなければならないので、２個のタイムスタンプフィールドを必要とする。
【０２０３】
この場合に、ＦＥＣソースパケットに含まれたタイムスタンプのための１つのフィールドを使用するためには、交互的にタイムスタンプを設定することが可能である。すなわち、ＦＥＣソースパケットの中で奇数番目に送信されるＦＥＣソースパケットには、ＦＥＣソースパケットサブブロックのためのＦＥＣソース又はリペアパケットブロックに含まれたＦＥＣソース又はリペアパケットの中で１番目に送信されるＦＥＣソース又はリペアパケットのタイムスタンプ情報を含ませ、偶数番目に送信されるＦＥＣソース又はリペアパケットには、ＦＥＣソースパケットブロックのためのＦＥＣソース又はリペアパケットブロックに含まれたＦＥＣソース又はリペアパケットの中で１番目に送信されるＦＥＣソース又はリペアパケットのタイムスタンプ情報を含ませることができる。
【０２０４】
また、この場合に、タイムスタンプフィールドがＦＥＣソースパケットブロックのためのＦＥＣソース又はリペアパケットブロックに含まれたＦＥＣソース又はリペアパケットの中で１番目に送信されるＦＥＣソース又はリペアパケットに対するタイムスタンプであるか、そうでなければ、ＦＥＣソースパケットサブブロックのためのＦＥＣソース又はリペアパケットブロックに含まれたＦＥＣソース又はリペアパケットの中で１番目に送信されるＦＥＣソース又はリペアパケットに対するタイムスタンプであるかを示す情報を追加で含むことが好ましい。例えば、タイムスタンプフィールドが４バイトで実現される場合に、最上位１ビットをタイムスタンプ情報指示子として設定する。この場合に、１ビットの値が"０"である場合に、ＦＥＣソースパケットブロックのためのＦＥＣソース又はリペアパケットブロックに含まれたＦＥＣソース又はリペアパケットの中で１番目に送信されるＦＥＣソース又はリペアパケットに対するタイムスタンプが送信されることを意味する。１ビットの値が"１"である場合に、ＦＥＣソースパケットサブブロックのためのＦＥＣソース又はリペアパケットブロックに含まれたＦＥＣソース又はリペアパケットの中で１番目に送信されるＦＥＣソース又はリペアパケットに対するタイムスタンプが送信されることを意味する。この場合に、残りの３１ビットは、関連したＦＥＣソース又はリペアパケットブロックに含まれたＦＥＣソース又はリペアパケットの中で１番目に送信されるＦＥＣソース又はリペアパケットに対するタイムスタンプの中で最上位１ビットを除外した残りの３１ビットに設定される。
【０２０５】
図８では、本発明の一実施形態によるＦＥＣ方式をサポートするＭＭＴシステムにおいてＦＥＣソース又はリペアパケットブロックに含まれたＦＥＣソース又はリペアパケットの中で１番目に送信されるＦＥＣソース又はリペアパケットに対するタイムスタンプを設定する過程について説明した。図９を参照して、本発明の一実施形態によるＦＥＣ方式をサポートするＭＭＴシステムにおいて２段ＦＥＣ構造が使用される場合のタイムスタンプを設定する過程について説明する。
【０２０６】
図９は、本発明の一実施形態によるＦＥＣ方式をサポートするＭＭＴシステムにおいて２段ＦＥＣ構造が使用される場合のタイムスタンプを設定する過程を概略的に示す図である。
【０２０７】
図９を参照すると、１０個のソースパケットの各々に含まれたＭＭＴＰヘッダには、タイムスタンプが０、１、２、３、４、８、９、１０、１１、１２として設定される。これは、ＡＬ−ＦＥＣプロセッサ（図１０に図示せず）が１０個のソースパケットを含むソースパケットブロックをそれぞれ５個のソースパケットに分割し、１番目のソースパケットブロックに対して３個のリペアパケットを生成することを仮定した後にタイムスタンプ５、６、７をリペアパケットのために予約することを意味する。ＡＬ−ＦＥＣプロセッサは、ＭＭＴ送信エンティティが入力されるか又は予め定められたＦＥＣ構成関連情報に基づいてソースパケットブロックをどのように構成するか又は幾つのリペアパケットを生成するかを決定し、上述したように、各パケットの送信順序及び送信時間に従って各パケットをスケジューリングできる。
【０２０８】
ＡＬ−ＦＥＣプロセッサは、１０個のソースパケットを含むソースパケットブロックをグループ化することによりそれぞれ５個のソースパケットを含む２個のソースパケットサブブロックを生成し、２個のソースパケットブロックの各々に対してＦＥＣ１符号化により３個のＦＥＣ１リペアパケットを生成し、全体のソースパケットブロックに対してＦＥＣ２符号化により３個のＦＥＣ２リペアパケットを生成する。
【０２０９】
ＡＬ−ＦＥＣプロセッサは、ＴＳ指示子＝０及び１番目のＦＥＣソース又はリペアパケットブロックに含まれたＦＥＣソース又はリペアパケットの中で１番目に送信されるＦＥＣソース又はリペアパケットのＭＭＴＰパケットヘッダで送信されるタイムスタンプの最上位ビット（ＭＳＢ）１ビットを除外した３１ビット情報であるＦＰ＿ＴＳ（＝０）を１番目のＦＥＣソースパケットブロックに含まれた奇数番目のＦＥＣソースパケットのソースＦＥＣペイロードＩＤに含ませる。以下では、ＴＳ指示子及びＦＰ＿ＴＳについて具体的に説明するので、ここでは、その詳細な説明を省略する。
【０２１０】
ＡＬ−ＦＥＣプロセッサは、ＴＳ指示子＝１及び１番目のＦＥＣソース又はリペアパケットブロックに含まれたＦＥＣソース又はリペアパケットの中で１番目に送信されるＦＥＣソース又はリペアパケットのＭＭＴＰパケットヘッダで送信されるタイムスタンプのＭＳＢ１ビットを除外した３１ビット情報であるＦＰ＿ＴＳ（＝０）を偶数番目のＦＥＣソースパケットのソースＦＥＣペイロードＩＤに含ませる。
【０２１１】
ＡＬ−ＦＥＣプロセッサは、ＴＳ指示子＝０及び１番目のＦＥＣソース又はリペアブロックに含まれたＦＥＣソース又はリペアパケットの中で１番目に送信されるＦＥＣソース又はリペアパケットに含まれたＭＭＴＰパケットヘッダで送信されるタイムスタンプのＭＳＢ１ビットを除外した３１ビット情報であるＦＰ＿ＴＳ（＝０）を１番目のＦＥＣソースパケットブロックのための３個のＦＥＣ１リペアパケットに含ませる。
【０２１２】
ＡＬ−ＦＥＣプロセッサは、ＴＳ指示子＝０及び１番目のＦＥＣソース又はリペアパケットブロックに含まれたＦＥＣソース又はリペアパケットの中で１番目に送信されるＦＥＣソース又はリペアパケットのＭＭＴＰパケットヘッダで送信されるタイムスタンプのＭＳＢ１ビットを除外した３１ビット情報であるＦＰ＿ＴＳ（＝８）を２番目のＦＥＣソースパケットに含まれた奇数番目のＦＥＣソースパケットのソースＦＥＣペイロードＩＤに含ませる。
【０２１３】
ＡＬ−ＦＥＣプロセッサは、ＴＳ指示子＝１及びＦＥＣソース又はリペアブロックに含まれたＦＥＣソース又はリペアパケットの中で１番目に送信されるＦＥＣソース又はリペアパケットのＭＭＴＰパケットヘッダで送信されるタイムスタンプの最上位ビット（ＭＳＢ）１ビットを除外した３１ビット情報であるＦＰ＿ＴＳ（＝０）を偶数番目のＦＥＣソースパケットのソースＦＥＣペイロードＩＤに含ませる。
【０２１４】
ＡＬ−ＦＥＣプロセッサは、ＴＳ指示子＝０及び２番目のＦＥＣソース又はリペアパケットブロックに含まれたＦＥＣソース又はリペアパケットの中で１番目に送信されるＦＥＣソース又はリペアパケットのＭＭＴＰパケットヘッダで送信されるタイムスタンプのＭＳＢ１ビットを除外した３１ビット情報であるＦＰ＿ＴＳ（＝８）を２番目のＦＥＣソースパケットブロックのための３個のＦＥＣ１リペアパケットに含ませる。
【０２１５】
ＡＬ−ＦＥＣプロセッサは、ＴＳ指示子＝１及びＦＥＣソース又はリペアブロックに含まれたＦＥＣソース又はパケットの中で１番目に送信されるＦＥＣソース又はリペアパケットのＭＭＴＰパケットヘッダで送信されるタイムスタンプのＭＳＢ１ビットを除外した３１ビット情報であるＦＰ＿ＴＳ（＝０）をＦＥＣソースパケットブロックのための３個のＦＥＣ２リペアパケットに含ませる。
【０２１６】
図９では、本発明の一実施形態によるＦＥＣ方式をサポートするＭＭＴシステムにおいて２段ＦＥＣ構造が使用される場合のタイムスタンプを設定する過程について説明した。図１０を参照して、本発明の一実施形態によるＦＥＣ方式をサポートするＭＭＴシステムで使用されるＦＥＣソースパケットの構造について説明する。
【０２１７】
図１０は、本発明の一実施形態によるＦＥＣ方式をサポートするＭＭＴシステムで使用されるＦＥＣソースパケットの構造を概略的に示す図である。
【０２１８】
図１０を参照すると、ＦＥＣソースパケットは、Ｄ２ヘッダフィールド１０１０、Ｄ１ヘッダフィールド１０１１、Ｄ１ペイロードフィールド１０１２、及びＦＥＣイン−バンド信号フィールド１０１３を含む。
【０２１９】
Ｄ２ヘッダフィールド１０１０は、ＭＭＴパケットヘッダを含み、Ｄ１ヘッダフィールド１０１１は、ＭＭＴペイロードヘッダを含み、Ｄ１ペイロードフィールド１０１２は、ペイロードデータを含み、ＦＥＣイン−バンド信号フィールド１０１３は、ソースＦＥＣペイロードＩＤを含む。ここで、Ｄ２ヘッダフィールド１０１０には、関連したＭＭＴパケットが送信される送信時間に関する情報であるタイムスタンプが含まれる。
【０２２０】
図１０では、本発明の一実施形態によるＦＥＣ方式をサポートするＭＭＴシステムで使用されるＦＥＣソースパケットの構造について説明した。図１１を参照して、本発明の一実施形態によるＦＥＣ方式を使用するＭＭＴシステムで使用されるＦＥＣリペアパケットの構造を概略的に示す図である。
【０２２１】
図１１は、本発明の一実施形態によるＦＥＣ方式を使用するＭＭＴシステムで使用されるＦＥＣリペアパケットの構造を概略的に示す図である。
【０２２２】
図１１を参照すると、ＦＥＣリペアパケットは、Ｄ２ヘッダフィールド１１２０、Ｄ１ヘッダフィールド１１２１、Ｄ１ペイロード（リペアペイロード）フィールド１１２２、及びＦＥＣインーバンド信号フィールド１１２３を含む。
【０２２３】
Ｄ２ヘッダフィールド１１２０は、ＭＭＴパケットヘッダを含み、Ｄ１ヘッダフィールド１１２１は、ＭＭＴペイロードヘッダを含み、ＦＥＣイン−バンド信号フィールド１１２３は、リペアＦＥＣペイロードＩＤを含み、Ｄ１ペイロード（リペアペイロード）フィールド１１２２は、１つ又はそれ以上のリペアシンボルを含む。Ｄ２ヘッダフィールド１１２０は、関連したＭＭＴパケットが送信される送信時間に関する情報であるタイムスタンプを含む。
【０２２４】
上述したように、ＭＭＴパケットは、ＦＥＣ符号化過程などのような一連の過程を通して図１１で説明したような構造を有する。
【０２２５】
図１０では、プロトコルパケット、例えば、ＭＭＴパケットの構造の一貫性を維持し、ＦＥＣパケット内でソースパケットが継続して位置するようにするために、ＦＥＣイン−バンド信号フィールド１０１３の位置がＦＥＣソースパケットの最後の部分であると仮定する。ＦＥＣリペアパケットは、１つ又はそれ以上のリペアシンボルを含む。リペアシンボルは、ソースパケットを含むソースシンボルブロックの復元のために使用される。
【０２２６】
図１１において、信号受信装置がＦＥＣ関連情報を迅速にかつ容易に取得するようにするために、ＦＥＣイン−バンド信号フィールド１１２３の位置が送信プロトコルヘッダとリペアシンボルとの間にあると仮定する。
【０２２７】
表１及び表２を参照して、本発明の一実施形態によるＦＥＣ方式をサポートするＭＭＴシステムにおいてＦＥＣソース又はリペアパケットブロックに含まれたＦＥＣソース又はリペアパケットの中で１番目に送信されるＦＥＣソース又はリペアパケットのタイムスタンプがＦＥＣペイロードＩＤに含まれる場合について説明する。
【０２２８】
表１は、ソースＦＥＣペイロードＩＤを示し、表２は、リペアＦＥＣペイロードＩＤを示す。
【０２２９】
【表１】
0006530748.tif 000002
【０２３０】
【表２】
0006530748.tif 000003
表１及び表２の各フィールドについて説明する。
【０２３１】
（１）ＳＳ＿ＩＤフィールド
ＳＳ＿ＩＤフィールドは、ソースシンボルＩＤ（ＳＳ＿ＩＤ）を含み、ＳＳ＿ＩＤは、ＦＥＣソースパケット内のソースシンボルを識別するためのシーケンス番号である。
【０２３２】
ＳＳ＿ＩＤは、シンボルエレメントごとに予め定められた値から予め定められた値、例えば、１ずつ増加する。これは、パディングシンボルエレメントにも同一に適用され、ＳＳ＿ＩＤは、ＦＥＣソースパケットに含まれた１番目のシンボルエレメントのＳＳ＿ＩＤに設定される。現在のパケットに対するＳＳ＿ＩＤと次のパケットのＳＳ＿ＩＤとの間の差は、現在のパケットに含まれたシンボルエレメントの個数と同一である。しかしながら、現在のＦＥＣソースパケットブロックに含まれたＦＥＣソースパケットの中で最後のＦＥＣソースパケットのＳＳ＿ＩＤと次のＦＥＣソースパケットブロックに含まれたＦＥＣソースパケットの中で１番目のＦＥＣソースパケットのＳＳ＿ＩＤとの差は、パディングシンボルエレメントが現在のＦＥＣソースパケットブロックのソースシンボルブロックに含まれる場合に、現在のＦＥＣソースパケットに含まれたシンボルエレメントの個数とパディングシンボルエレメントの個数とを加えた値である。ＳＳ＿ＩＤの初期値は、ランダムに生成された任意の値から設定され、例えば、４バイト又は４バイト以上の所定の長さのバイトで表現される整数の最大値に到達した後には、さらに‘０’に戻る。
【０２３３】
以下では、ＳＳ＿ＩＤについて説明する。
【０２３４】
ＳＳ＿ＩＤは、複数のビット、例えば、３２ビットで具現され、ＦＥＣソースパケット内のソースシンボルを識別するシーケンス番号を示す。ＳＳ＿ＩＤは、任意の値から開始し、この任意の値から予め定められた値に増加し、ＳＳ＿ＩＤの値が予め設定されている最大値に到達した後に、初期値、例えば、'０'に戻る。
【０２３５】
適用されたＳＳＢＧモードを示すパラメータとしてのｓｓｂｇ＿ｍｏｄｅの値が００又は０１（ｓｓｂｇ＿ｍｏｄｅ＝＝００又はｓｓｂｇ＿ｍｏｄｅ＝＝０１）である場合に、ＳＳ＿ＩＤは、ＦＥＣソースパケットごとに、例えば、１ずつ増加する。ここで、‘ｓｓｂｇ＿ｍｏｄｅ＝＝００’は、適用されたＳＳＢＧモードが'ｓｓｂｇ＿ｍｏｄｅ０'であることを示し、‘ｓｓｂｇ＿ｍｏｄｅ＝＝０１’は、適用されたＳＳＢＧモードが'ｓｓｂｇ＿ｍｏｄｅ１'であることを示す。以下では、ｓｓｂｇ＿ｍｏｄｅ０及びｓｓｂｇ＿ｍｏｄｅ１について説明するので、ここでは、その詳細な説明を省略する。
【０２３６】
ｓｓｂｇ＿ｍｏｄｅの値が１０（ｓｓｂｇ＿ｍｏｄｅ＝＝１０）である場合に、ＳＳ＿ＩＤは、シンボルエレメントごとに、例えば、１ずつ増加し、ＳＳ＿ＩＤは、ＦＥＣソースパケットに含まれた１番目のシンボルエレメントのＳＳ＿ＩＤに設定される。ここで、シンボルエレメントが存在する場合に、シンボルエレメントは、ソースシンボルブロックの最後のソースシンボル内のパディングシンボルエレメントを含む。ここで、‘ｓｓｂｇ＿ｍｏｄｅ＝＝１０’は、適用されたＳＳＢＧモードが'ｓｓｂｇ＿ｍｏｄｅ２'であることを示す。以下では、ｓｓｂｇ＿ｍｏｄｅ２について説明するので、ここでは、その詳細な説明を省略する。
【０２３７】
ｓｓｂｇ＿ｍｏｄｅ０、ｓｓｂｇ＿ｍｏｄｅ１、及びｓｓｂｇ＿ｍｏｄｅ２について説明する。
【０２３８】
１番目に、ｓｓｂｇ＿ｍｏｄｅ０について説明する。
【０２３９】
ｓｓｂｇ＿ｍｏｄｅ０において、ソースシンボルブロックは、同一のサイズを有するすべてのＭＭＴＰパケットであるソースパケットブロックと正確に同一である。これは、ソースパケットブロックに含まれたＭＭＴＰパケットの個数がソースシンボルブロックに含まれたソースシンボルの個数と同一であり、各ＭＭＴＰパケット＃ｉは、各ソースシンボル＃ｉ（ｉ＝０，１，．．．，Ｋ−１）と正確に同一であることを示す。ｓｓｂｇ＿ｍｏｄｅ０では、１段ＦＥＣコーディング構造に対して（Ｍ＝１）、ソースシンボルブロックがパディングバイトなしにソースパケットから生成される。また、ｓｓｂｇ＿ｍｏｄｅ０では、２段ＦＥＣコーディング構造及びＬＡ−ＦＥＣコーディング構造に対して（Ｍ＞１）、ｉ番目のソースシンボルブロックは、パディングバイトなしにソースパケットブロック（ｉ＝０，１，．．．，Ｍ−１）に含まれたｉ番目のソースパケットブロック、すなわち、ｉ番目のソースパケットサブブロックから生成される。
【０２４０】
２番目に、ｓｓｂｇ＿ｍｏｄｅ１について説明する。
【０２４１】
ｓｓｂｇ＿ｍｏｄｅ１において、ソースシンボルブロックは、各ＭＭＴＰパケット＃ｉがパディングバイトを有することにより、各ＭＭＴＰパケット＃ｉの関連したパリティシンボルの長さとして使用されるＴと同一のサイズを有するように生成されるもの以外には、ｓｓｂｇ＿ｍｏｄｅ０と同一の方式でソースパケットブロックから生成される。これは、ソースパケットブロックに含まれたＭＭＴＰパケットの個数が関連したソースシンボルブロックに含まれたソースシンボルの個数と同一であり、各ソースシンボル＃ｉが対応するＭＭＴＰパケット＃ｉの可能なパディングバイト（すべて００ｈ）を付加することにより生成されることを意味する。ｓｓｂｇ＿ｍｏｄｅ１では、１段ＦＥＣコーディング構造に対して（Ｍ＝１）、ソースシンボルブロックがパディングブロック（すべて００ｈ）を有するソースパケットブロックから生成される。また、ｓｓｂｇ＿ｍｏｄｅ１において、２段ＦＥＣコーディング構造及びＬＡ−ＦＥＣコーディング構造で（Ｍ＞１）、ｉ番目のソースブロックは、パディングブロック（すべて００ｈ）を有するソースパケットブロック（ｉ＝０，１，．．．，Ｍ−１）に含まれたｉ番目のソースパケットブロックから生成される。
【０２４２】
３番目に、ｓｓｂｇ＿ｍｏｄｅ２について説明する。
【０２４３】
ｓｓｂｇ＿ｍｏｄｅ２において、ソースシンボルブロックは、１段ＦＥＣコーディング構造に対して、ソースシンボルブロックがパディングバイト（すべて００ｈ）を有するソースパケットブロックから生成される。単一のソースシンボルブロックは、パディングバイト（すべて００ｈ）を有する単一のソースパケットブロックから生成されたＫSS個のソースシンボルで構成され、各ソースシンボルは、同一のＮ（＞＝１）個のシンボルエレメントで構成される。これは、単一のソースシンボルブロックがＮ＊ＫSS個のシンボルエレメントで構成されることを意味する。ソースパケットブロックのＭＭＴＰパケット＃０は、パディングバイトを有するソースシンボルブロックに含まれた最初のｓ0個のシンボルエレメントからソースシンボルブロックに含まれた最初のｓ0個のシンボルエレメントの最後のシンボルエレメントの境界まで位置する。ソースパケットブロックのＭＭＴＰパケット＃１は、ＭＭＴＰパケット＃０と同一の方式でソースシンボルブロックに含まれた次のｓ1個のシンボルエレメントに位置する。このような方式で、ソースパケットブロックのＭＭＴＰパケット＃ＫSP−１は、ＭＭＴＰパケット＃０と同一の方式でソースシンボルブロックに含まれた次のｓKsp-1個のシンボルエレメントに位置する。ここで、ＫssＴ−ｓｕｍ｛ｓiＴ'、ｉ＝１，．．．，ＫSP｝が０でない場合に、Ｐ個のパディングバイト（すべて００ｈ）が単一のソースシンボルブロックに含まれた最後のシンボルエレメントに位置する。
【０２４４】
（２）  ＦＦＳＲＰ＿ＴＳフィールド
ＦＦＳＲＰ＿ＴＳフィールドは、１番目のＦＥＣソース又はリペアパケットタイムスタンプを含む。ＦＦＳＲＰ＿ＴＳフィールドは、ＦＥＣソースパケットのためのフィールドであり、対応するパケットを含む対応するＦＥＣソース又はリペアパケットブロックに含まれたＦＥＣソース又はリペアパケットの中で１番目に送信されるＦＥＣソース又はリペアパケットのタイムスタンプを含む。
【０２４５】
２段ＦＥＣコーディング構造が適用される（図４において、Ｍが１より大きい）場合に、ＦＦＳＲＰ＿ＴＳフィールドは、ＦＥＣソースパケットサブブロック（ｉ番目のＦＥＣソースパケットブロック、ｉ＝１，２，．．．，Ｍ）のためのＦＥＣソース又はリペアパケットブロックに含まれたＦＥＣソース又はリペアパケットの中で１番目に送信されるＦＥＣソース又はリペアパケットのタイムスタンプ及びＦＥＣソースパケットブロックのためのＦＥＣソース又はリペアパケットブロックに含まれたＦＥＣソース又はリペアパケットの中で１番目に送信されるＦＥＣソース又はリペアパケットのタイムスタンプを含む。
【０２４６】
一方、２段ＦＥＣコーディング構造が適用される（図３において、Ｍが１より大きい）場合に、ＦＥＣソースパケットサブブロック（ｉ番目のＦＥＣソースパケットブロック、ｉ＝１，２，．．．，Ｍ）のためのＦＥＣソース又はリペアパケットブロックに含まれたＦＥＣソース又はリペアパケットの中で１番目に送信されるＦＥＣソース又はリペアパケットのタイムスタンプは、ＦＥＣソースパケットブロックの中で偶数番目（又は奇数番目）に送信されるＦＥＣソースパケットのためのソースＦＥＣペイロードＩＤに含まれ、ＦＥＣソースパケットブロックのためのＦＥＣソース又はリペアパケットブロックに含まれたＦＥＣソース又はリペアパケットの中で１番目に送信されるＦＥＣソース又はリペアパケットのタイムスタンプは、ＦＥＣソースパケットブロックの中で奇数番目（又は偶数番目）に送信されるＦＥＣソースパケットのためのソースＦＥＣペイロードＩＤに含ませる形態でタイムスタンプを交互的に送信される場合に、１つのＦＦＳＲＰ＿ＴＳフィールドを使用して２段ＦＥＣコーディング構造を処理できる。この場合に、ＦＦＳＲＰ＿ＴＳフィールドは、ＴＳ指示子及びタイムスタンプフィールドを含む。ここで、ＴＳ指示子は、タイムスタンプフィールドに含まれたタイムスタンプがＦＥＣソースパケットサブブロックのためのＦＥＣソース又はリペアパケットブロックに含まれたＦＥＣソース又はリペアパケットの中で１番目に送信されるＦＥＣソース又はリペアパケットのタイムスタンプであるか又はＦＥＣソースパケットブロックのためのＦＥＣソース又はリペアパケットブロックに含まれたＦＥＣソース又はリペアパケットの中で１番目に送信されるＦＥＣソース又はリペアパケットのタイムスタンプであるかを示す。
【０２４７】
あるいは、ＬＡ−ＦＥＣコーディング構造が適用される場合には、ＦＦＳＲＰ＿ＴＳフィールドは、向上したレイヤーを含む対応するＦＥＣソース又はリペアパケットブロックに含まれたＦＥＣソース又はリペアパケットの中で１番目に送信されるＦＥＣソース又はリペアパケットの１つのタイムスタンプだけが含まれる。
【０２４８】
（３）  ＳＳ＿Ｓｔａｒｔフィールド
ＦＥＣソースパケットにおいて、ＳＳ＿Ｓｔａｒｔフィールドは、選択的に使用される。ＳＳ＿ＳｔａｒｔフィールドがＦＥＣソースパケットに含まれる場合に、ＳＳ＿Ｓｔａｒｔフィールドは、ＦＥＣソースパケットが含まれたソースパケットブロックの１番目のソースパケットのＳＳ＿ＩＤと同一の値を有し、これは、ソースパケットが属するソースシンボルブロックの境界情報に対応する。
【０２４９】
ＦＥＣパリティパケットにおいて、ＳＳ＿Ｓｔａｒｔフィールドは、関連したＦＥＣパリティパケットを含むＦＥＣパリティパケットブロックに関連したＦＥＣソースパケットブロックの１番目のＦＥＣソースパケットに設定されているＳＳ＿ＩＤと同一の値を有する。ＳＳ＿Ｓｔａｒｔフィールドに基づいて、信号受信装置は、受信されたＦＥＣパケットからＦＥＣソースパケットブロックの境界、すなわち、開始位置を認識できる。
【０２５０】
（４）  ＲＳＢ＿ｌｅｎｇｔｈフィールド
ＲＳＢ＿ｌｅｎｇｔｈフィールドは、ＦＥＣパリティパケットに含まれたパリティシンボルが含まれたパリティブロックに含まれたパリティシンボルの個数を示す。すなわち、ＦＥＣ符号化方式を使用してＫ個のソースシンボルを含むソースシンボルブロックからＰ個のリペアシンボルが生成される場合に、ＲＳＢ＿ｌｅｎｇｔｈフィールドの値は、Ｐに設定される。
【０２５１】
（５）  ＲＳ＿ＩＤフィールド
ＲＳ＿ＩＤフィールドは、ＦＥＣパリティパケットに含まれたパリティシンボルを識別するための一連番号であるＲＳ＿ＩＤを含む。ＲＳ＿ＩＤは、それぞれのパリティシンボルブロック内で、例えば、０から開始して１ずつ増加する値であり、１つのＦＥＣパリティパケットが複数のパリティシンボルを含む場合には、複数のパリティシンボルの一連番号の中で最小値を示す。
【０２５２】
（６）  ＳＳＢ＿ｌｅｎｇｔｈフィールド
ＳＳＢ＿ｌｅｎｇｔｈフィールドには、ＦＥＣパリティパケットに含まれたパリティシンボルが保護するソースシンボル（サブ）ブロックに含まれたシンボルエレメントの個数が設定される。シンボルエレメントの個数は、ソースシンボルブロックの最後のソースシンボルに含まれたパディングシンボルエレメントの個数を含まない。すなわち、ソースシンボルブロックに含まれたソースシンボルの個数がＫであり、ソースシンボルブロックに含まれたソースシンボルの中で最後のソースシンボルに含まれたパディングシンボルエレメントの個数がｐである場合に、ＳＳＢ＿ｌｅｎｇｔｈフィールドの値は、Ｋ＊ｍ−ｐに設定される。
【０２５３】
（７）  ＦＦＳＲＰ＿ＴＳフィールド
ＦＦＳＲＰ＿ＴＳフィールドは、１番目のＦＥＣソース又はリペアパケットタイムスタンプを含む。ＦＦＳＲＰ＿ＴＳフィールドは、ＦＥＣリペアパケットのためのフィールドであり、ＦＥＣリペアパケットを含む関連したＦＥＣソース又はリペアパケットブロックに含まれたＦＥＣソース又はリペアパケットの中で１番目に送信されるＦＥＣソース又はリペアパケットのタイムスタンプを含む。
【０２５４】
表３は、本発明の実施形態によるＦＥＣソース又はリペアパケットブロックに含まれたＦＥＣソース又はリペアパケットの中で１番目に送信されるＦＥＣソース又はリペアパケットのタイムスタンプが個別のフィールドに含まれ、個別のフィールドが図１０及び図１１で説明したようなＦＥＣイン−バンド信号フィールドに含まれる場合を示す。この場合に、図１０及び図１１で説明したようなＦＥＣイン−バンド信号フィールドは、ＦＥＣペイロードＩＤのためのフィールド及びＦＥＣタイムスタンプのためのフィールドを含み、ソースＦＥＣペイロードＩＤは、表１で説明したようなＳＳ＿ＩＤフィールドを含み、リペアＦＥＣペイロードＩＤは、表２で説明したようなＦＦＳＲＰ＿ＴＳフィールドを除外した形態で生成される。
【０２５５】
【表３】
0006530748.tif 000004
表２は、表３に示すようなＦＦＳＲＰ＿ＴＳフィールドがＦＥＣペイロードＩＤに含まれるものではなく、個別のフィールドとしてＦＥＣイン−バンド信号フィールド内に含まれるもの以外には、表１と同一である。すなわち、ＦＦＳＲＰ＿ＴＳフィールドがＦＥＣソースパケットに適用される場合に、ＦＦＳＲＰ＿ＴＳフィールドは、表１で説明したようなものと同一であり、ＦＦＳＲＰ＿ＴＳフィールドがＦＥＣリペアパケットに適用される場合には、ＦＦＳＲＰ＿ＴＳフィールドは、表２で説明したようなものと同一である。
【０２５６】
表４は、本発明の一実施形態によるＦＥＣソース又はリペアパケットブロックに含まれたＦＥＣソース又はリペアパケットの中で１番目に送信されるＦＥＣソース又はリペアパケットのタイムスタンプがＭＭＴパケットヘッダに含まれる場合を示す。
【０２５７】
【表４】
0006530748.tif 000005
表４において、ＴＳフィールドは、タイムスタンプを含むフィールドであり、ＴＳフィールドは、対応するパケットが送信されるタイムスタンプを含む。ここで、信号受信装置は、パケット受信の時にＴＳフィールドに記載されているタイムスタンプに基づいて受信されたパケットが送信された時間を認識できる。
【０２５８】
表４において、ＦＦＳＲＰ＿ＴＳフィールドがＭＭＴパケットヘッダに含まれることを除外しては、表１及び表２で説明したＦＦＳＲＰ＿ＴＳフィールドと同一であり、ここでは、その詳細な説明を省略する。
【０２５９】
表５は、本発明の一実施形態によるＦＥＣメッセージのフォーマットを示し、ＦＥＣメッセージは、ＦＥＣソース又はリペアパケットブロックの送信時間期間情報であるＦＥＣ保護ウィンドー時間フィールドを含む。
【０２６０】
【表５】
0006530748.tif 000006
表５において、ＦＥＣ保護ウィンドータイムフィールドは、ＦＥＣソース又はリペアパケットブロックに含まれたＦＥＣソース又はリペアパケットの中で１番目に送信されるＦＥＣソース又はリペアパケットの送信時間とＦＥＣソース又はリペアパケットブロックに含まれたＦＥＣソース又はリペアパケットの中で最後に送信されるＦＥＣソース又はリペアパケットの送信時間との間の最大値を示す。信号送信装置は、ＦＥＣ保護ウィンドータイムフィールドに設定された時間内にＦＥＣソース又はリペアパケットブロックに含まれたすべてのＦＥＣソース又はリペアパケットを送信しなければならないことを意味する。
【０２６１】
したがって、ＦＥＣソース又はリペアパケットブロックに含まれたＦＥＣソース又はリペアパケットの中で最後に送信されるＦＥＣソース又はリペアパケットのタイムスタンプが‘Ｔ１’であり、ＦＥＣソース又はリペアパケットブロックに含まれたＦＥＣソース又はリペアパケットの中で１番目に送信されるＦＥＣソース又はリペアパケットのタイムスタンプが‘Ｔ０’である場合に、Ｔ１−Ｔ０＜ＦＥＣ保護ウィンドータイムの条件を満足しなければならない。
【０２６２】
２段ＦＥＣコーディング構造が適用されるか又はＬＡ−ＦＥＣコーディング構造が適用される場合に、ＦＥＣ保護ウィンドータイムは、各ＦＥＣ符号化ステップのためのＦＥＣ保護ウィンドータイム又は各レイヤーのためのＦＥＣ保護ウィンドータイムに区分して設定される必要がある。例えば、２段ＦＥＣ符号化の場合に、ＦＥＣソースパケットサブブロックのためのＦＥＣソース及びリペアパケットブロックのＦＥＣ保護ウィンドータイム及びＦＥＣソースパケットブロックのためのＦＥＣソース又はリペアパケットブロックのＦＥＣ保護ウィンドータイムがそれぞれ必要であり得る。
【０２６３】
表６は、本発明の一実施形態によるＨＲＢＭメッセージのフォーマットを示し、最大バッファサイズフィールド及び固定されたエンドツーエンド遅延フィールドを含む。
【０２６４】
【表６】
0006530748.tif 000007
表６において、最大バッファサイズフィールドは、信号受信装置のためのＭＭＴアセットのために最大に要求されるバッファサイズを含む。バッファサイズは、（最大遅延−最小遅延）＊最大ビットレートのように計算できる。すなわち、最大バッファサイズフィールドは、マルチメディアデータに対して要求される最大バッファサイズに関連した情報を含む。
【０２６５】
表６において、固定されたエンドツーエンド遅延フィールドは、信号送信装置と信号受信装置との間の遅延値を含み、固定されたエンドツーエンド遅延フィールドは、最大送信遅延＋ＦＥＣバッファリングタイムのような値に設定される。ここで、ＦＥＣバッファリングタイムは、ＦＥＣ保護ウィンドータイムを示す。表５で説明したように、ＦＥＣ保護ウィンドータイムが符号化方式に従って個別に要求される場合に、ＨＲＢＭメッセージは、固定されたエンドツーエンド遅延情報の代わりに最大送信遅延情報を含み、ＦＥＣメッセージの符号化方式のステップ別ＦＥＣ保護ウィンドータイムとともに符号化方式のステップ別固定されたエンドツーエンド遅延情報が信号受信装置に送信される。
【０２６６】
すなわち、固定されたエンドツーエンド遅延フィールドは、信号送信装置と信号受信装置との間の遅延に関連した情報を含む。ここで、信号送信装置と信号受信装置との間の遅延に関連した情報は、信号送信装置と信号受信装置との間の最大送信遅延に関連した情報及び最大時間間隔情報に基づいて決定される。ＦＥＣソース又はリペアパケットブロックが複数のＦＥＣソース又はリペアパケットを含む場合に、最大時間間隔情報は、複数のＦＥＣソース又はリペアパケットの中で１番目に送信されるＦＥＣソース又はリペアパケットの送信時点と複数のＦＥＣソース又はリペアパケットの中で最後に送信されるＦＥＣソース又はリペアパケットの送信時点との間の最大時間間隔に関連した情報である。
【０２６７】
ＦＥＣソース又はリペアパケットブロックが複数のＦＥＣソース又はリペアパケットを含む場合に、ＦＥＣ保護ウィンドータイムは、複数のＦＥＣソース又はリペアパケットの中で１番目に送信されるＦＥＣソース又はリペアパケットの送信時点と複数のＦＥＣソース又はリペアパケットの中で最後に送信されるＦＥＣソース又はリペアパケットの送信時点との間の最大時間間隔に関連した情報を示す。ここで、複数のＦＥＣソース又はリペアパケットは、最大時間間隔内に受信装置に送信される。
【０２６８】
図１２を参照して、本発明の一実施形態によるＦＥＣ方式をサポートするＭＭＴシステムにおいてＦＥＣソース又はリペアパケットブロックの送受信期間及びＦＥＣ復号デジッタリング過程について説明する。
【０２６９】
図１２は、本発明の一実施形態によるＦＥＣ方式をサポートするＭＭＴシステムにおいてＦＥＣソース又はリペアパケットブロックの送受信期間及びＦＥＣ復号デジッタリング過程を概略的に示す図である。
【０２７０】
図１２を参照すると、ＭＭＴＰは、送信順序に基づいてＦＥＣ保護ウィンドータイム（Ｔｗ）内に１番目のＦＥＣソース又はリペアパケットをＦＥＣソース又はリペアパケットブロックに含まれた最後のＦＥＣソース又はリペアパケットに送信する。図１２では、それぞれＮ個のパケット（Ｋ個のＦＥＣソースパケット及びＮ−Ｋ個のＦＥＣリペアパケット）を含む、２個のＦＥＣソース又はリペアパケットブロックがＦＥＣメッセージに設定されたＦＥＣ保護ウィンドータイム（Ｔｗ）を使用して送信される。送信されたＮ個のパケットは、ネットワーク上の遅延により最小送信遅延（Ｄｍｉｎ）又は最大送信遅延（Ｄｍａｘ）の後に信号受信装置に到着する。
【０２７１】
したがって、送信時点のＦＥＣ保護ウィンドーは、受信時点のＦＥＣ保護ウィンドーとは異なり得る。すなわち、Ｔｓ１とＴｅ１との間に送信されたＦＥＣソース又はリペアパケットブロック＃１は、ネットワーク遅延によりＴｓ１＋ＤｍｉｎからＴｅ１＋Ｄｍａｘまでの受信ウィンドーを有する。
【０２７２】
しかしながら、ネットワーク状況により、パケットが送信順序と同一の順序で到着せず、パケット損失が発生し得るために、信号受信装置は、１番目に受信されたパケットが関連したＦＥＣソース又はリペアパケットブロックに含まれたＦＥＣソース又はリペアパケットの中で１番目に送信されたＦＥＣソース又はリペアパケットであるか否かを認識できないので、Ｔｓ１＋ＤｍｉｎからＴｅ１＋Ｄｍａｘまでの受信ウィンドーを設定できないこともある。
【０２７３】
しかしながら、信号受信装置は、ＦＥＣメッセージのＦＥＣ保護ウィンドータイム（Ｔｗ）、ＨＲＢＭメッセージの最大送信遅延（Ｄｍａｘ）、及び各ＦＥＣソース又はリペアパケットで送信されるＦＥＣソース又はリペアパケットブロックに含まれたＦＥＣソース又はリペアパケットの中で１番目に送信されたＦＥＣソース又はリペアパケットのタイムスタンプ（すなわち、ＦＦＳＲＰ＿ＴＳ＝Ｔ０＝Ｔｓ１）を使用して１番目に受信されたＦＥＣソース又はリペアパケットのＦＦＳＲＰ＿ＴＳ情報に基づく１番目に受信されたＦＥＣソース又はリペアパケットの受信時間、すなわち、ＴｒからＴ０＋Ｔｗ＋Ｄｍａｘ＝Ｔｅ１＋Ｄｍａｘまでの受信ウィンドーを設定する。
【０２７４】
したがって、信号受信装置は、ＴｒからＴｅ１＋Ｄｍａｘまでの時間の間にバッファリング動作を実行してＦＥＣ復号動作を実行する。信号受信装置が十分なＦＥＣソース又はリペアパケットを受信する場合に、信号受信装置は、ＴｒからＴｅ１＋Ｄｍａｘまでの時間の前に、ＦＥＣ復号動作を実行する。Ｔｅ１＋Ｄｍａｘは、ＨＲＢＭによるＦＥＣ復号器が復号動作を実行するために待機できる最大時間を意味する。ＦＥＣ復号器は、ＦＥＣ復号に従って復元されたＭＭＴパケットとともに関連したＦＥＣソースパケットブロックに含まれたＫ個のＭＭＴパケットをデジッタリングバッファに入力し、デジッタリングバッファは、入力されたＭＭＴパケットをＴｓ＋Δに対応して出力する。ここで、Ｔｓは、パケットのタイムスタンプを示し、△は、Ｄｍａｘ＋Ｔｗ（△＝Ｄｍａｘ＋Ｔｗ）である。
【０２７５】
図１２では、本発明の一実施形態によるＦＥＣ方式をサポートするＭＭＴシステムにおいてＦＥＣソース又はリペアパケットブロックの送受信期間及びＦＥＣ復号デジッタリング過程について説明した。図１３を参照して、本発明の一実施形態によるＦＥＣ方式をサポートするＭＭＴシステムにおけるＨＲＢＭの内部構造について説明する。
【０２７６】
図１３は、本発明の一実施形態によるＦＥＣ方式をサポートするＭＭＴシステムにおけるＨＲＢＭの内部構造を概略的に示す図である。
【０２７７】
図１３を参照すると、ＨＲＢＭは、ＦＥＣデコーディングバッファ１３１１と、デジッタリングバッファ１３１３と、ＭＭＴＰデカプセル化（De-capsulation）バッファ１３１５とを含む。以下では、ＦＥＣデコーディングバッファ１３１１、デジッタリングバッファ１３１３、及びＭＭＴＰデカプセル化バッファ１３１５について詳細に説明する。
【０２７８】
（１）  ＦＥＣデコーディングバッファ１３１１
ＦＥＣデコーディングバッファ１３１１は、１番目に受信されたＦＥＣソース又はリペアパケットに関するＦＦＲＳＰ＿ＴＳ情報、ＦＥＣメッセージのＦＥＣ保護ウィンドータイムＴｗ、ＨＲＢＭメッセージの最大送信遅延Ｄｍａｘ、及び最大バッファサイズに基づいて、１番目に受信されたＦＥＣソース又はリペアパケットの受信時点ＴｒからＦＦＲＳＰ＿ＴＳ＋Ｔｗ＋Ｄｍａｘ＝ＦＦＲＳＰ＋△までの受信ウィンドーを設定し、設定された受信ウィンドー内に受信される関連したＦＥＣソース又はリペアパケットブロックに含まれたＦＥＣソース又はリペアパケットをバッファリングする。
【０２７９】
受信ウィンドー内に十分なＦＥＣソース又はリペアパケットを受信した信号受信装置は、ＦＦＲＳＰ＋△の前に又は受信ウィンドーのＦＦＲＳＰ＋△でＦＥＣ復号動作を実行した後に、復元されたＦＥＣソースパケットブロックのすべてのパケット（ＭＭＴパケット）をデジッタリングバッファ１３１３に入力する。すなわち、復元されたＦＥＣソースパケットに含まれたすべてのパケットは、時点Ｔ＋ＦＥＣ保護ウィンドータイム（Ｔｗ）でデジッタリングバッファ１３１３に入力される。ここで、Ｔは、ＦＦＲＳＰ＿ＴＳ＋Ｄｍａｘより小さいか又は同一であり、あるいは、信号受信装置がＦＥＣ復号を行える十分なＦＥＣソース又はリペアパケットを受信した時点より大きいか又は同一である。
【０２８０】
（２）  デジッタリングバッファ１３１３
デジッタリングバッファ１３１３は、ＦＥＣデコーディングバッファ１３１１から入力されたＭＭＴパケットの各々を時点Ｔｓ＋△でＭＭＴＰデカプセル化バッファ１３１５に入力する。ここで、Ｔｓは、ＭＭＴパケットのヘッダに含まれたパケットの送信時間、すなわち、タイムスタンプである。
【０２８１】
（３）  ＭＭＴＰデカプセル化バッファ１３１５
ＭＭＴＰデカプセル化バッファ１３１５は、デジッタリングバッファ１３１３から入力されたＭＭＴパケットに対してデカプセル化動作を実行することにより、復元されたメディアフラグメントユニット（ＭＦＵ）／メディア処理ユニット（ＭＰＵ）を生成し、生成されたＭＦＵ／ＭＰＵを出力する。ここで、ＭＦＵは、ＭＰＵのフラグメントを示す。デカプセル化動作は、ＭＭＴパケットヘッダ及びＭＭＴペイロードヘッダを除去する動作、ＭＭＴペイロードを除去する動作、デフラグメンテーション（De-fragmentation）動作、及びデアグリゲーション（De-aggregation）動作を含む。
【０２８２】
図１３では、ＦＥＣデコーディングバッファ１３１１、デジッタリングバッファ１３１３、及びＭＭＴＰデカプセル化バッファ１３１５が個別のユニットとして説明されたが、これは、説明の便宜のためのものであることを理解すべきである。言い換えれば、ＦＥＣデコーディングバッファ１３１１、デジッタリングバッファ１３１３、及びＭＭＴＰデカプセル化バッファ１３１５のうちの２つ以上が１つのユニットに統合される形態にも具現されることができる。
【０２８３】
図１３では、本発明の一実施形態によるＦＥＣ方式をサポートするＭＭＴシステムにおけるＨＲＢＭの内部構造について説明した。図１４を参照して、本発明の一実施形態によるＦＥＣ方式をサポートするＭＭＴシステムにおいてＦＦＲＳＴ＿ＴＳがパケットに含まれて送信される場合における信号受信装置でのＦＥＣ保護ウィンドー（ケース１）及びＦＦＲＳＴ＿ＴＳがパケットに含まれて送信されない場合における信号受信装置でのＦＥＣ保護ウィンドー（ケース２）について説明する。
【０２８４】
図１４は、本発明の一実施形態によるＦＥＣ方式をサポートするＭＭＴシステムにおいてＦＦＲＳＴ＿ＴＳがパケットに含まれて送信される場合における信号受信装置でのＦＥＣ保護ウィンドー（ケース１）及びＦＦＲＳＴ＿ＴＳがパケットに含まれて送信されない場合における信号受信装置でのＦＥＣ保護ウィンドー（ケース２）を概略的に示す図である。
【０２８５】
図１４を参照すると、Ｔ０＋Ｄｍｉｎ〜Ｔｅ＋Ｄｍａｘとして表現される受信ＦＥＣ保護ウインドー間隔は、送信されたＦＥＣソース又はリペアパケットブロックがＤｍｉｎ、Ｄｍａｘ、及びＴｗを考慮して受信可能な間隔を意味する。
【０２８６】
図１４において、ケース１を参照すると、信号受信装置は、実際の時間ＴｒでＦＥＣソース又はリペアパケットブロックに含まれたＦＥＣソース又はリペアパケットを最初に受信する。本発明の一実施形態によると、受信されたＦＥＣソース又はリペアパケットに含まれたＦＦＲＳＰ＿ＴＳ情報（Ｔ０）からＦＥＣメッセージ及びＨＲＢＭメッセージから取得したＴｗ及びＤｍａｘを考慮してＴ０＋Ｔｗ＋Ｄｍａｘまで信号受信装置のＦＥＣ保護ウィンドーを設定する。
【０２８７】
図１４において、ケース２を参照すると、本発明の一実施形態で提案するＦＦＲＳＰ＋ＴＳが送信されないために、信号受信装置は、ＦＥＣソース又はリペアパケットブロックに含まれたＦＥＣソース又はリペアパケットの中で１番目に送信されたＦＥＣソース又はリペアパケットの送信時間情報を認識せず、また、１番目に受信したＦＥＣソース又はリペアパケットがＦＥＣソース又はリペアパケットブロックに含まれたＦＥＣソース又はリペアパケットの中で１番目に送信されたＦＥＣソース又はリペアパケットであるか否かを認識できない。
【０２８８】
これにより、信号受信装置は、１番目に受信したＦＥＣソース又はリペアパケットの送信時間情報（Ｔｓ）に基づいて、Ｔｗ及びＴｍａｘを考慮してＴｓ＋Ｔｗ＋Ｄｍａｘまで信号受信装置のＦＥＣ保護ウィンドーを設定しなければならない。
【０２８９】
これにより、ケース１と比較したケース２において、信号受信装置は、Ｔｓ−Ｔ０の間に不必要なバッファリング動作を実行するか、又は付加の遅延が発生し、Ｔｓ−Ｔ０の値が１番目に受信したＦＥＣソース又はリペアパケットの送信時間情報Ｔｓに従って変わるので、デジッタリングバッファの出力時間は、ＦＥＣデコーディングバッファがどのＦＥＣソース又はリペアパケットを最初に受信するかに従って変わる。
【０２９０】
図１４では、本発明の一実施形態によるＦＥＣ方式をサポートするＭＭＴシステムにおいてＦＦＲＳＴ＿ＴＳがパケットに含まれて送信される場合における信号受信装置でのＦＥＣ保護ウィンドー（ケース１）及びＦＦＲＳＴ＿ＴＳがパケットに含まれて送信されない場合における信号受信装置でのＦＥＣ保護ウィンドー（ケース２）について説明した。図１５を参照して、本発明の一実施形態によるＦＥＣ方式をサポートするＭＭＴシステムにおけるＭＭＴ送信エンティティの内部構造の一例について説明する。
【０２９１】
図１５は、本発明の一実施形態によるＦＥＣ方式をサポートするＭＭＴシステムにおけるＭＭＴ送信エンティティの内部構造の一例を概略的に示す図である。
【０２９２】
図１５を参照すると、ＭＭＴ送信エンティティ１５００は、プレゼンテーションエンジンレイヤー１５１１と、ファイルプロセッサ１５１３と、ジェネリックオブジェクト構成レイヤー１５１５と、メディアプロセッサ１５１７と、ＭＰＵ構成レイヤー１５１９と、シグナリングメッセージプロセッサ１５２１と、シグナリングメッセージ構成レイヤー１５２３と、ＭＭＴプロトコルレイヤー１５２５と、配信レイヤー１５２７とを含む。
【０２９３】
プレゼンテーションエンジンレイヤー１５１１は、マルチメディアシーン（multimedia scene）をセットアップする。
【０２９４】
ファイルプロセッサ１５１３は、ファイル、例えば、ＭＰＵファイルを処理し、ジェネリックオブジェクト構成レイヤー１５１５は、完全なＭＰＵのようなジェネリックオブジェクトを構成する。
【０２９５】
メディアプロセッサ１５１７は、メディアデータを処理し、ＭＰＵ構成レイヤー１５１９は、ＭＰＵを構成し、シグナリングメッセージプロセッサ１５２１は、ＭＭＴ受信エンティティに送信されるシグナリングメッセージに対する処理動作を実行する。また、シグナリングメッセージ構成レイヤー１５２３は、シグナリングメッセージプロセッサ１５２１で処理したシグナリングメッセージを構成する。
【０２９６】
ＭＭＴＰレイヤー１５２５は、ｐａｃｋｅｔ＿ｉｄ、ペイロードタイプなどのような様々なパラメータを考慮してストリームされたメディアを生成する。ここで、カプセル化手順は、配信されたペイロードタイプに基づいており、独立して実行されるので、図１５には、別途に図示しなかったことに留意すべきである。
【０２９７】
配信レイヤー１５２７は、ＭＭＴＰレイヤー１５２５で生成したストリームされたメディアデータをＭＭＴ受信レイヤーに送信するのに適合した形態で変換した後に、ＭＭＴ受信エンティティに送信する。
【０２９８】
一方、図１５には、プレゼンテーションエンジンレイヤー１５１１と、ファイルプロセッサ１５１３と、ジェネリックオブジェクト構成レイヤー１５１５と、メディアプロセッサ１５１７と、ＭＰＵ構成レイヤー１５１９と、シグナリングメッセージプロセッサ１５２１と、シグナリングメッセージ構成レイヤー１５２３と、ＭＭＴＰレイヤー１５２５と、配信レイヤー１５２７とが個別のユニットとして説明されたが、これは、説明の便宜のためのものであることを理解すべきである。言い換えれば、プレゼンテーションエンジンレイヤー１５１１と、ファイルプロセッサ１５１３と、ジェネリックオブジェクト構成レイヤー１５１５と、メディアプロセッサ１５１７と、ＭＰＵ構成レイヤー１５１９と、シグナリングメッセージプロセッサ１５２１と、シグナリングメッセージ構成レイヤー１５２３と、ＭＭＴＰレイヤー１５２５と、配信レイヤー１５２７の中の２つ以上が１つのユニットに統合される形態にも具現されることができる。
【０２９９】
図１５では、本発明の一実施形態によるＦＥＣ方式をサポートするＭＭＴシステムにおけるＭＭＴ送信エンティティの内部構造の一例について説明した。図１６を参照して、本発明の一実施形態によるＭＭＴシステムにおけるＭＭＴ送信エンティティの内部構造の他の例について説明する。
【０３００】
図１６は、本発明の一実施形態によるＭＭＴシステムにおけるＭＭＴ送信エンティティの内部構造の他の例を概略的に示す図である。
【０３０１】
図１６を参照すると、ＭＭＴ送信エンティティ１６００は、送信ユニット１６１１と、制御ユニット１６１３と、受信ユニット１６１５と、記憶ユニット１６１７とを含む。
【０３０２】
制御ユニット１６１３は、ＭＭＴ送信エンティティ１６００の全般的な動作を制御する。より具体的に、制御ユニット１６１３は、ＭＭＴ送信エンティティ１６００が本発明の一実施形態によるパケット送受信動作に関連した全般的な動作を実行するように制御する。ここで、パケット送受信動作に関連した動作は、図１乃至図１４で説明した方式で実行され、ここでは、その詳細な説明を省略する。
【０３０３】
送信ユニット１６１１は、制御ユニット１６１３の制御の下にＭＭＴ受信エンティティに様々なメッセージを送信する。送信ユニット１６１１が送信する様々なメッセージは、図１乃至図１４で説明した。ここでは、その詳細な説明を省略する。
【０３０４】
受信ユニット１６１５は、制御ユニット１６１３の制御の下にＭＭＴ受信エンティティから様々なメッセージを受信する。受信ユニット１６１５が受信する様々なメッセージは、図１乃至図１４で説明した。ここでは、その詳細な説明を省略する。
【０３０５】
記憶ユニット１６１７は、ＭＭＴ送信エンティティ１６００の動作に必要なプログラム、各種データなど、特に、本発明の一実施形態によるパケット送受信動作に関連した情報などを記憶する。また、記憶ユニット１６１７は、受信ユニット１６１５がＭＭＴ受信エンティティなどから受信した各種メッセージなどを記憶する。
【０３０６】
一方、図１６には、送信ユニット１６１１と、制御ユニット１６１３と、受信ユニット１６１５と、記憶ユニット１６１７とが個別のユニットとして説明されたが、これは、説明の便宜のためのものであることを理解すべきである。言い換えれば、送信ユニット１６１１、制御ユニット１６１３、受信ユニット１６１５、及び記憶ユニット１６１７の中の２つ以上が１つのユニットに統合される形態にも具現されることができる。
【０３０７】
図１６では、本発明の一実施形態によるＭＭＴシステムにおけるＭＭＴ送信エンティティの内部構造の他の例について説明した。図１７を参照して、本発明の一実施形態によるＭＭＴシステムにおけるＭＭＴ受信エンティティの内部構造の一例について説明する。
【０３０８】
図１７は、本発明の一実施形態によるＭＭＴシステムにおけるＭＭＴ受信エンティティの内部構造の一例を概略的に示す図である。
【０３０９】
図１７を参照すると、ＭＭＴ受信エンティティ１７００は、プレゼンテーションエンジンレイヤー１７１１と、ファイルプロセッサ１７１３と、ジェネリックオブジェクト再構成レイヤー１７１５と、メディアプロセッサ１７１７と、ＭＰＵ再構成レイヤー１７１９と、シグナリングメッセージプロセッサ１７２１と、シグナリングメッセージ再構成レイヤー１７２３と、ＭＭＴＰレイヤー１７２５と、配信レイヤー１７２７とを含む。
【０３１０】
ＭＭＴ受信エンティティ１７００は、１つ又はそれ以上のＭＭＴ機能領域（図１７には図示せず）で動作する。ＭＭＴ機能領域は、ＭＰＵ機能領域、配信機能領域、及びシグナリング機能領域を含む。以下では、ＭＰＵ機能領域、配信機能領域、及びシグナリング機能領域について説明する。
【０３１１】
ＭＰＵ機能領域は、メディアコンテンツの論理構造、パッケージ、及びＭＭＴエンティティにより処理されるデータユニットのフォーマット及びそのインスタンス生成（instantiation）、例えば、ＩＳＯ／ＩＥＣ１４４９６−１２に規定されているＩＳＯベースメディアファイルフォーマットを有するインスタンス生成を定義する。パッケージは、メディアコンテンツを含むコンポーネント及びコンポーネントの間の関係を規定することにより向上した配信のための必要な情報を提供する。データユニットのフォーマットは、記憶又は配信のための符号化されたメディアデータをカプセル化するために定義され、記憶されるデータと配信されるデータとの間の容易な変換を許容するように定義される。
【０３１２】
配信機能領域は、アプリケーションレイヤートランスポートプロトコル及びペイロードフォーマットを定義する。アプリケーションレイヤートランスポートプロトコルは、一般的なアプリケーションレイヤートランスポートプロトコル、例えば、単一のパケットフローでマルチプレキシング、ストリーミングの混合された使用のサポート、及びダウンロード配信に比べて向上した特性を提供する。ペイロードフォーマットは、メディアタイプ及び符号化方式に依存しない（agnostic）符号化されたメディアデータの運搬を可能にするように定義される。
【０３１３】
シグナリング機能領域は、メディアデータの配信及び消費を管理するシグナリングメッセージのフォーマットを定義する。消費を管理するためのシグナリングメッセージは、パッケージの構造をシグナルするために使用され、配信を管理するためのシグナリングメッセージは、ペイロードフォーマットの構造及びプロトコル構成をシグナリングするために使用される。
【０３１４】
ＭＭＴＰレイヤー１７２５は、ｐａｃｋｅｔ＿ｉｄ及びペイロードタイプなどのような様々なパラメータに基づいてストリームされたメディアの受信及びデマルチプレキシングを行うために使用される。ここで、デカプセル化手順は、配信されるペイロードのタイプに基づいており、独立して実行されるので、図１７には、図示しない。
【０３１５】
プレゼンテーションエンジンレイヤー１７１１は、マルチメディアシーンをセットアップし、ＭＭＴＰを使用して受信されるコンテンツを参照する。
【０３１６】
一方、図１７には、プレゼンテーションエンジンレイヤー１７１１、ファイルプロセッサ１７１３、ジェネリックオブジェクト再構成レイヤー１７１５、メディアプロセッサ１７１７、ＭＰＵ再構成レイヤー１７１９、シグナリングメッセージプロセッサ１７２１、シグナリングメッセージ再構成レイヤー１７２３、ＭＭＴＰレイヤー１７２５、及び配信レイヤー１７２７が個別のユニットとして説明されたが、これは、説明の便宜のためのものであることを理解すべきである。言い換えれば、プレゼンテーションエンジンレイヤー１７１１、ファイルプロセッサ１７１３、ジェネリックオブジェクト再構成レイヤー１７１５、メディアプロセッサ１７１７、ＭＰＵ再構成レイヤー１７１９、シグナリングメッセージプロセッサ１７２１、シグナリングメッセージ再構成レイヤー１７２３、ＭＭＴＰレイヤー１７２５、及び配信レイヤー１７２７の中の２つ以上が１つのユニットに統合される形態にも具現されることができる。
【０３１７】
図１７では、本発明の一実施形態によるＭＭＴシステムにおけるＭＭＴ受信エンティティの内部構造の一例について説明した。図１８を参照して、本発明の一実施形態によるＭＭＴシステムにおけるＭＭＴ受信エンティティの内部構造の他の例について説明する。
【０３１８】
図１８は、本発明の一実施形態によるＭＭＴシステムにおけるＭＭＴ受信エンティティの内部構造の他の例を概略的に示す図である。
【０３１９】
図１８を参照すると、ＭＭＴ受信エンティティ１８００は、送信ユニット１８１１と、制御ユニット１８１３と、受信ユニット１８１５と、記憶ユニット１８１７とを含む。
【０３２０】
制御ユニット１８１３は、ＭＭＴ受信エンティティ１８００の全般的な動作を制御する。より具体的に、制御ユニット１８１３は、ＭＭＴ受信エンティティ１８００が本発明の一実施形態によるパケット送受信動作に関連した全般的な動作を実行するように制御する。ここで、パケット送受信動作に関連した動作は、図１乃至図１４で説明した方式で実行され、ここでは、その詳細な説明を省略する。
【０３２１】
送信ユニット１８１１は、制御ユニット１８１３の制御の下にＭＭＴ送信エンティティに様々なメッセージを送信する。送信ユニット１８１１が送信する様々なメッセージは、図１乃至図１４で説明した。ここでは、その詳細な説明を省略する。
【０３２２】
受信ユニット１８１５は、制御ユニット１８１３の制御の下にＭＭＴ送信エンティティから様々なメッセージを受信する。受信ユニット１８１５が受信する様々なメッセージは、図１乃至図１４で説明した。ここでは、その詳細な説明を省略する。
【０３２３】
記憶ユニット１８１７は、ＭＭＴ受信エンティティ１８００の動作に必要なプログラム、各種データなど、特に、本発明の一実施形態によるパケット送受信動作に関連した情報などを記憶する。また、記憶ユニット１８１７は、受信ユニット１８１５がＭＭＴ送信エンティティなどから受信した各種メッセージなどを記憶する。
【０３２４】
送信ユニット１８１１と、制御ユニット１８１３と、受信ユニット１８１５と、記憶ユニット１８１７とが個別のユニットとして説明されたが、これは、説明の便宜のためのものであることを理解すべきである。言い換えれば、送信ユニット１８１１、制御ユニット１８１３、受信ユニット１８１５、及び記憶ユニット１８１７のうちの２つ以上が１つのユニットに統合される形態にも具現されることができる。
【０３２５】
上記した本発明による実施形態は、非一時的なコンピュータ読み取り可能な記録媒体でコンピュータ読み取り可能なコードとして実施されることができる。非一時的なコンピュータで読み取り可能な記憶媒体は、コンピュータシステムにより読出し可能なデータを記憶することができる任意のデータ記憶装置である。非一時的なコンピュータで読み取り可能な記憶媒体の例としては、読出し専用メモリ（ＲＯＭ）、ランダムアクセスメモリ（ＲＡＭ）、ＣＤ−ＲＯＭ、磁気テープ、フロッピー（登録商標）ディスク、及び光学データ記憶装置、及び搬送波が含まれるが、これらに限定されるものではない。また、上記非一時的な機械可読記録媒体は、ネットワーク結合型コンピュータシステムにわたって分散されることにより、コンピュータ読み取り可能なコードが分散形態で格納され実行される。また、本発明を達成するための機能的プログラム、コード、及びコードセグメントは、当該技術分野における熟練されたプログラマにとっては容易に理解できることである。
【０３２６】
また、本発明の一実施形態による装置及び方法は、ハードウェア、ソフトウェア、及び／又はハードウェア及びソフトウェアの組み合せの形態で実現することができる。このような任意のソフトウェアは、例えば、削除又は再記録が可能であるか否かに関係なく、ＲＯＭなどの記憶装置のような揮発性又は不揮発性記憶装置、又は、例えば、ＲＡＭ、メモリチップ、メモリ装置、又はメモリ集積回路（ＩＣ）、又は例えばＣＤ、ＤＶＤ、磁気ディスク又は磁気テープなどの光学的又は磁気的に記録可能であると同時に、機械（例えば、コンピュータ）で読み取ることができる記憶媒体に記憶することができる。本発明の一実施形態による方法及び装置は、制御部及びメモリを含むコンピュータ又は携帯用端末により具現化されてもよく、このメモリは、本発明の様々な実施形態を実現する指示を含むプログラム又は複数のプログラムを格納するのに適した機械可読の記憶装置である。
【０３２７】
したがって、本発明は、本願の任意の請求項に記載された装置又は方法を具現するためのコードを含むプログラム、及びこのようなプログラムを格納する機械（コンピュータ）可読な記憶媒体を含む。また、このようなプログラムは、有線又は無線接続を通じて送信される通信信号のような任意の媒体を通じて電子的に移送され、本発明は、このプログラムと均等なものを適切に含む。
【０３２８】
また、本発明の一実施形態による装置は、有線又は無線で接続されるプログラム提供装置からプログラムを受信し格納することができる。プログラム提供装置は、プログラム処理装置が予め定められたコンテンツ保護方法を実行するようにする指示を含むプログラム及びコンテンツ保護方法に必要な情報などを記憶するためのメモリと、グラフィック処理装置との有線又は無線通信を実行するための通信部と、グラフィック処理装置の要請又は自動で対応するプログラムを送受信装置に送信する制御部とを含むことができる。
【０３２９】
以上、本発明を具体的な実施形態を参照して詳細に説明してきたが、本発明の範囲及び趣旨を逸脱することなく様々な変更が可能であるということは、当業者には明らかであり、本発明の範囲は、上述の実施形態に限定されるべきではなく、特許請求の範囲の記載及びこれと均等なものの範囲内で定められるべきものである。
【図１】
0006530748.tif 000008
【図２】
0006530748.tif 000009
【図３】
0006530748.tif 000010
【図４】
0006530748.tif 000011
【図５】
0006530748.tif 000012
【図６】
0006530748.tif 000013
【図７】
0006530748.tif 000014
【図８】
0006530748.tif 000015
【図９】
0006530748.tif 000016
【図１０】
0006530748.tif 000017
【図１１】
0006530748.tif 000018
【図１２】
0006530748.tif 000019
【図１３】
0006530748.tif 000020
【図１４】
0006530748.tif 000021
【図１５】
0006530748.tif 000022
【図１６】
0006530748.tif 000023
【図１７】
0006530748.tif 000024
【図１８】
0006530748.tif 000025