JP2017175634A - 通信システムにおけるパケット送受信装置及び方法 - Google Patents

Abstract

【課題】ネットワークで発生したデータ損失を復旧する方法及び装置を提供する。
【解決手段】パケット送信方法はアプリケーションレイヤーフォワードエラー訂正（ＡＬ−ＦＥＣ）で保護されるＭＰＥＧメディアトランスポート（ＭＭＴ）アセットを決定するステップと、ＭＭＴアセットを送信するためのＦＥＣフローを決定するステップと、ＦＥＣフローの各々で送信されるＭＭＴアセットを決定し、ＦＥＣフローに適用するためのＦＥＣ符号化構造を決定するステップと、ＦＥＣフローで送信されるＭＭＴアセットを送信のための単位に分けてソースフローを生成するステップと、ＦＥＣ符号化構造に従ってソースフローでＡＬ−ＦＥＣエンコーディングを実行することによりパリティフローを生成して送信するステップとを含む。
【選択図】図１８

Description

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

様々なコンテンツの増加及び高解像度（High Definition：ＨＤ）コンテンツ及び超高解像度（Ultra High Definition：ＵＨＤ）コンテンツのような高容量コンテンツの増加の結果として、ネットワーク上でデータ輻輳（data Congestion）がさらに悪化している。このようなデータ輻輳により、送信器（Sender、例えば、Ｈｏｓｔ Ａ）により送信されたコンテンツは、受信器に完全に転送されず、コンテンツの一部は、ルート上で損失される状況が発生する。

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

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

本発明の別の目的は、ＭＰＥＧメディアトランスポート（ＭＭＴ）パッケージのＭＭＴアセット（Asset）を送信するにあたり、アプリケーションレイヤーフォワードエラー訂正（Application Layer Forward Error Correction：ＡＬ−ＦＥＣ）保護が行われたＭＭＴフロー、すなわち、ＦＥＣフローを送信するためのＦＥＣフロー構成方法及びＡＬ−ＦＥＣ運用方法を提供することにある。

上記のような目的を達成するために、本発明の一態様によれば、通信システムにおけるパケット送信方法を提供する。上記パケット送信方法は、アプリケーションレイヤーフォワードエラー訂正（ＡＬ−ＦＥＣ）で保護される少なくとも１つのＭＰＥＧメディアトランスポート（ＭＭＴ）アセットを決定するステップと、上記少なくとも１つのＭＭＴアセットを送信するための少なくとも１つのＦＥＣフローを決定するステップと、上記少なくとも１つのＦＥＣフローの各々で送信されるＭＭＴアセットを決定し、上記少なくとも１つのＦＥＣフローに適用するためのＦＥＣ符号化構造を決定するステップと、上記少なくとも１つのＦＥＣフローで送信される上記ＭＭＴアセットを送信のための単位に分けて少なくとも１つのソースフローを生成するステップと、上記ＦＥＣ符号化構造に従って上記少なくとも１つのソースフローでＡＬ−ＦＥＣエンコーディングを実行することにより、少なくとも１つのパリティフローを生成して送信するステップと、を有することを特徴とする。

本発明の他の態様によれば、通信システムにおけるパケット受信方法を提供する。上記パケット受信方法は、送信器からフォワードエラー訂正（ＦＥＣ）フローメッセージを受信するステップと、上記ＦＥＣフローメッセージからＦＥＣフローの個数及びＦＥＣフロー別に適用されたＦＥＣ符号化構造を確認するステップと、上記送信器から受信したＭＭＴパケットからＦＥＣフローを分類するステップと、上記分類されたＦＥＣフローに対するＦＥＣ符号化構造に基づいてＦＥＣデコーディングを実行するステップと、を有することを特徴とする。

本発明のさらに他の態様によれば、通信システムにおけるパケット送信装置を提供する。上記パケット送信装置は、アプリケーションレイヤーフォワードエラー訂正（ＡＬ−ＦＥＣ）で保護される少なくとも１つのＭＰＥＧメディアトランスポート（ＭＭＴ）アセットを決定し、上記少なくとも１つのＭＭＴアセットを送信するための少なくとも１つのＦＥＣフローを決定し、上記少なくとも１つのＦＥＣフローのそれぞれで送信されるＭＭＴアセットを決定し、上記少なくとも１つのＦＥＣフローに適用するためのＦＥＣ符号化構造を決定する制御部と、上記少なくとも１つのＦＥＣフローで送信される上記ＭＭＴアセットを送信のための単位に分けて少なくとも１つのソースフローを生成し、上記ＦＥＣ符号化構造に従って上記少なくとも１つのソースフローでＡＬ−ＦＥＣエンコーディングを実行することにより、少なくとも１つのパリティフローを生成して送信する符号化部と、を有することを特徴とする。

本発明のさらなる他の態様によれば、通信システムにおけるパケット受信装置を提供する。上記パケット受信装置は、フォワードエラー訂正（ＦＥＣ）フローディスクリプタを受信する受信部と、上記ＦＥＣフローメッセージからＦＥＣフローの個数及びＦＥＣフロー別に適用されたＦＥＣ符号化構造を確認し、上記送信器から受信したＭＭＴパケットからＦＥＣフローを分類する制御部と、上記分類されたＦＥＣフローに対するＦＥＣ符号化構造に基づいてＦＥＣデコーディングを実行するデコーディング部と、を有することを特徴とする。

本発明によると、送信器がＭＭＴパッケージ内のＭＭＴフローに含まれるＭＭＴアセットのＱｏＳに基づいてＭＭＴフローを保護するメカニズムを提供し、ＦＥＣフローに関するディスクリプション情報を送信器と受信器との間で相互に通信するようにすることにより、受信器が受信した複数のＭＭＴパケットからＦＥＣフローに関するディスクリプション情報を予め認識できる。したがって、受信器は、受信したＭＭＴパケットを効率的にデコーディングできるという長所がある。

本発明の一実施形態によるネットワークトポロジー（Network Topology）及びデータフロー（Data Flow）を示す図である。 本発明の一実施形態によるＭＭＴシステムの構成を示す図である。 本発明の一実施形態によるＭＭＴパッケージの構造を示す図である。 本発明の一実施形態による１ステージ（One Stage）対２ステージ（Two Stages）のＦＥＣ符号化の構造を示す図である。 本発明の一実施形態によるＡＬ−ＦＥＣのエンコーディング／デコーディングフローに対する概念図である。 本発明の一実施形態による１ステージ及び２ステージＦＥＣ符号化の構造を示す図である。 本発明の一実施形態によるＦＥＣ配信ブロック（Delivery Block）及びＦＥＣ配信クラスタ（Delivery Cluster）の構成を示す図である。 本発明の一実施形態によるソースブロックを情報ブロックにマッピングさせる過程を説明するための図である。 本発明の一実施形態によるソースブロックを情報ブロックにマッピングさせる過程を説明するための図である。 本発明の一実施形態によるソースブロックを情報ブロックにマッピングさせる過程を説明するための図である。 本発明の一実施形態による情報シンボルを用いてパリティシンボルを生成する過程を説明するための図である。 本発明の一実施形態による情報シンボルを用いてパリティシンボルを生成する過程を説明するための図である。 本発明の一実施形態によるパリティシンボルを用いてパリティブロックを生成する過程を説明するための図である。 本発明の一実施形態によるパリティシンボルを用いてパリティブロックを生成する過程を説明するための図である。 本発明の一実施形態によるパリティシンボルを用いてパリティブロックを生成する過程を説明するための図である。 本発明の一実施形態によるＦＥＣパケットブロックを説明するための図である。 本発明の他の実施形態によるＭＭＴフローを説明するための図である。 本発明の一実施形態による送信器の動作を示すフローチャートである。 本発明の一実施形態による受信器の動作を示すフローチャートである。

以下、本発明を説明するにあたって、関連した公知機能或いは構成に対する具体的な説明が本発明の要旨を不必要に不明瞭にすると判断された場合、その詳細な説明は省略する。また、後述する用語は、本発明での機能を考慮して定義された用語であり、これは、ユーザー及び運用者の意図又は慣例に従って変わっても良い。従って、これらの定義は、本発明の全体の内容に基づいて定義されなければならない。

まず、本発明で使用される用語を次のように定義する。

− ＦＥＣ：エラーシンボルまたは削除シンボル（erasure symbol）を訂正するために使用されるエラー訂正符号を示す。

− ＦＥＣフレーム：保護しようとする情報をＦＥＣエンコーディング方式を用いてエンコーディングすることにより生成されるコードワードを示す。ＦＥＣフレームは、情報パート（information part）及びパリティパート（parity part）を含む。ここで、パリティパートは、“リペア（repair）パート”とも称する。

− シンボル：シンボルは、データのユニットを示し、ビット又はバイトのシンボルサイズを有する。(A unit of data. Its size, in bits, is referred to as the symbol size.)

− ソースシンボル：ＦＥＣフレーム内の情報パートで保護されるデータシンボル（unprotected data symbol）を示し、非保護データシンボルは、保護されない元来のデータシンボルを示す。

− 情報シンボル：ＦＥＣフレーム内の情報パートで保護されるデータ又はパディングシンボル。

− コードワード：情報シンボルをＦＥＣ符号化することにより生成されるＦＥＣフレーム。

− パリティシンボル：情報シンボルに基づいてＦＥＣ符号化方式を用いて生成される。このパリティシンボルは、ＦＥＣフレームに含まれる。

− パケット：ヘッダ及びペイロードを含むデータの送信単位を示す。

− ペイロード：パケットに含まれ、送信器から送信されるユーザデータの一部（piece）を示す。

− パケットヘッダ：ペイロードを含むパケットのためのヘッダ。

− ソースペイロード：ソースシンボルを含むペイロードを示し、ＦＥＣ方式により保護される基本単位を示す。

− 情報ペイロード：情報シンボルで構成されたペイロード。(FEC information payload is a set of FEC symbols with the same index of FEC information symbol parts of the associated FEC information block or FEC information sub-block.)

− パリティペイロード：パリティシンボルで構成されたペイロード。(FEC parity payload is a set of FEC symbols with the same index of FEC parity symbol parts of FEC parity block.)

− ソースブロック：１つ以上のソースペイロードで構成されたペイロードの集合。(FEC source block is a segmented set of a FEC source flow and consists of pre-determined number of FEC source payloads.)

− サブブロック：予め定められた数のＦＥＣソースペイロードで構成され、ＦＥＣソースブロックのサブセット。(FEC sub-block is a subset of FEC source block and consists of pre-determined number of FEC source payloads.)

− 情報ブロック：１つ以上の情報ペイロードで構成されたペイロードの集合。(FEC information block is a set of pre-determined number of FEC information payloads which has the equal size and is generated from FEC source block.)

− パリティブロック：１つ以上のパリティペイロードで構成されたペイロードの集合。( FEC parity block is a set of FEC parity symbol parts.)

− パリティシンボルパート：ＦＥＣエンコーディングによりＦＥＣ情報シンボルパートから発生されるパリティＦＥＣシンボル。(FEC parity symbol part is parity FEC symbols which are generated from an FEC information symbol part by FEC encoding.)

− 情報シンボルパート：ＦＥＣエンコーディングのためにともに考慮されるＦＥＣシンボルデータ。(An information symbol part is data FEC symbols which are considered together for FEC encoding)

− 情報サブブロック：ＦＥＣサブブロックから発生し、同一のサイズを有する予め定められた数の情報ペイロードの集合。(FEC information sub-block is a set of pre-determined number of information payloads which has the equal size and is generated from FEC sub-block.)

− ＦＥＣブロック：コードワードの集合又は情報ブロック及びパリティブロックで構成されたペイロードの集合。(FEC block consists of FEC information block or FEC information sub-block and its associated parity block.)

− ＦＥＣ配信ブロック：ソースブロック及びパリティ（リペア）ブロックで構成されたペイロードの集合。

− ＦＥＣパケット：ＦＥＣブロックを送信するためのパケット。

− ソースパケット：ソースブロックを送信するためのパケット。

− パリティ（リペア）パケット：パリティ（リペア）ブロックを送信するためのパケット。

− ＦＥＣパケットブロック：ＦＥＣ配信ブロックを送信するためのパケットの集合。

− ＭＭＴフロー：１つのＭＭＴパッケージの１つ又はそれ以上のＭＭＴアセットを送信するためのＭＭＴパケットのシーケンス。(A sequence of MMT packets to deliver one or more MMT Assets of one MMT Package)

− ソースフロー：１つのＭＭＴサーバで１つ又はそれ以上のＭＭＴクライアントに１つ又はそれ以上のＭＭＴアセットを送信するために同一のソースフロー識別子により識別されるソースペイロードのシーケンス。(A Source Flow is a sequence of Source Payloads identified by the same Source Flow identifier to deliver one or more MMT Assets from one MMT Server to one or more MMT Clients.)

− パリティフロー：同一のパリティフロー識別子により識別され、ソースフローを保護するためのＦＥＣ符号化過程で生成されるパリティペイロードのシーケンス。(A Parity Flow is a sequence of Parity Payloads, which are generated by FEC encoding to protect a Source Flow, identified by the same Parity Flow identifier.)

− ＦＥＣフロー（又はＦＥＣ保護フロー）：ソースフロー及びこれに関連した１つ又はそれ以上のパリティフローで構成される。(A FEC Flow consists of a Source Flow and its associated one or more Parity Flows.)

− アクセスユニット（ＡＵ）：時間情報が属性化されることができるもっとも小さいデータエンティティ

− ＭＭＴプロセッシングユニット（ＭＰＵ）：特定のメディアコーデックを独立してタイムドデータ（timed data）又はノンタイムドデータ（non-timed data）のための一般的なコンテナ。(Media Processing Unit is a generic container for timed or non-timed data, independent of any specific media codec. It contains one or more AUs for timed data or portion of data without AU boundaries for non-timed data and additional delivery and consumption related information. MPU is coded media data unit that can be completely and independently processed. In this context processing means encapsulation into MMT Package or packetization for delivery.)

− ＭＭＴアセット：１つ又はそれ以上のＭユニットで構成されるデータエンティティである。ＭＭＴアセットは、コンポジション情報及びトランスポート特性を定義するためのデータユニット。(MMT Asset is a logical data entity that is composed of one or more MPUs with same MMT Asset ID. An MMT Asset is the largest data unit for which same composition information and transport characteristics are applied.)

− ＭＭＴパッケージ：コンポジション情報及びトランスポート特性のような追加の情報とともに１つ又はそれ以上のＭＭＴアセットで構成される。(MMT Package is a logically structured collection of data, which is composed of one or more MMT Assets, MMT Composition Information, MMT Asset Delivery Characteristics and descriptive information.)

− ＭＭＴペイロード：ＭＭＴパッケージ又はＭＭＴシグナリングメッセージを運搬するフォーマットされたユニット。(MMT payload is a formatted unit of data to carry the MMT Package or MMT signaling message either using MMT Protocol or Internet application layer protocols (e.g. RTP))

− ＭＭＴパケット：ＭＭＴプロトコルにより発生するか又は消費されるデータのフォーマット化されたユニット。(MMT packet is a formatted unit of the data generated or consumed by MMT Protocol)

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

図１を参照すると、データ１５０は、ホストＡ１０５とホストＢ１１０との間でアプリケーション１４０、トランスポート１６０、インターネット１７０、及びリンク１８０を通してイーサネット（登録商標）１９０を通して送受信される。例えば、データ１５０は、トランスポート１６０でＵＤＰパケットでパケット化され、インターネット１７０でＩＰパケットでパケット化され、リンク１８０でフレームに送信される。

ホストＡ１０５から送信したＩＰパケットは、ルータ１２０及び１３０を通してホストＢ１１０に送信され、ホストＢ１１０は、ホストＡ１０５が送信した順にＩＰパケットを常に受信するのではない。したがって、ＩＰパケットを送信する時に送信順序を示す必要があり、このために、アプリケーション１４０において、データ１５０は、ＡＶコーデックで圧縮されたデータをリアルタイムプロトコル（ＲＴＰ）を使用してパケット化した後のＲＴＰパケットデータと見なされるか、又は図２で後述するＭＭＴトランスポートパケットデータとともにアプリケーション１４０のトランスポートプロトコルによりパケット化される。

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

図２において、左側１０は、ＭＭＴシステムの構成を示す図であり、右側２０は、配信機能（Delivery Function）の細部構成を示す図である。

メディアコーティングレイヤー（Media Coding Layer）２０５は、オーディオ又は／及びビデオデータを圧縮することによりカプセル化機能レイヤー（Encapsulation Function Layer）２１０に送信する。カプセル化機能レイヤー２１０は、圧縮されたオーディオ／ビデオデータをファイルフォーマットと類似した形態でパケット化することにより配信機能２２０に出力する。

配信機能２２０（Ｄ．レイヤー）では、カプセル化機能レイヤー２１０の出力をＭＭＴペイロードフォーマット化した後にＭＭＴペイロードフォーマットにＭＭＴトランスポートパケットヘッダを付加することにより、ＭＭＴトランスポートパケット形態でトランスポートプロトコル２３０に出力するか、又はカプセル化機能レイヤー２１０の出力をＲＴＰプロトコルを使用してＲＴＰパケット形態でトランスポートプロトコル２３０に出力する。その後に、トランスポートプロトコル２３０では、ユーザデータグラムプロトコル（User Datagram Protocol：以下、‘ＵＤＰ’と称する）／トランスポート制御プロトコル（Transport Control Protocol：以下、‘ＴＣＰ’と称する）の中の１つのトランスポートプロトコルに変換した後にインターネットプロトコル２４０に送信する。

最終的に、インターネットプロトコル２４０は、トランスポートプロトコル２３０の出力をＩＰパケット化する。本発明のソースペイロードは、ＭＭＴペイロードフォーマット、ＭＭＴ転送フォーマット（ＭＭＴプロトコル又はＭＭＴパケット）、ＲＴＰパケットの中の少なくとも１つの形態で可能である。

制御機能２００（Ｃ．レイヤー）（又はシグナリング機能（Ｓ．レイヤー））は、プレゼンテーションセッション（Presentation Session）及び配信セッション（Delivery Session）を管理する。

配信機能２２０（Ｄ．レイヤー）は、ＭＭＴＤ．３レイヤー２５０、ＭＭＴ Ｄ．１レイヤー２６０、及びＭＭＴ Ｄ.２レイヤー２７０で構成され、ＭＭＴ Ｄ.３レイヤー２５０は、クロスレイヤーインターフェース（Cross Layer Interface）であり、ＭＡＣ／ＰＨＹレイヤーを含む下位レイヤー（underlying layer）とアプリケーションレイヤー（Application layer）との間のＱｏＳ関連情報（related information）を相互に交換することによりＱｏＳをサポートするための１つのエンティティ（送信端又は受信端）での手段を提供する。アプリケーションレイヤーは、トップダウン（top-down）ＱｏＳ情報としてメディア特性に関する情報を提供し、下位レイヤーネットワークチャネル条件（network channel condition）のようなボトムアップ（bottom-up）ＱｏＳ情報を提供する。ＭＭＴ Ｄ．１レイヤー２６０は、カプセル化機能レイヤー２１０からのＭＭＴパッケージを送信するためのジェネリックペイロードフォーマット（generic payload format）としてＭＭＴペイロードを提供し、ＲＴＰのようなＩＥＴＦアプリケーションプロトコル２８０又はＭＭＴプロトコルのペイロードフォーマットとして使用され、本発明によるＦＥＣメッセージのようなＭＭＴシグナリングメッセージを運搬（carry）できる。また、本発明によるソースペイロードがＭＭＴペイロードである場合には、ＦＥＣエンコーディングにより生成されたパリティパケットを運搬することもある。ＭＭＴパッケージのアセットのそれぞれは、１つ又は複数のＭＰＵで構成され、ＭＭＴペイロードは、同一のアセットＩＤを有する１つ又は複数のＭＰＵを運搬できるだけでなく、比較的大きいＭＰＵに対しては、複数のＭＭＴペイロードでフラグメント（fragment）される。ＭＭＴ Ｄ.２レイヤー２７０は、ＭＭＴパッケージを効率的にかつ安定して送信するために考案されたアプリケーションレイヤープロトコルとしてＭＭＴプロトコル（ＭＭＴパケット）を提供する。ＭＭＴプロトコルは、コード化されたメディアデータの様々なタイプで構成されたコンテンツを送信するのに必須のマルチプレキシング、ネットワークジッタ計算（network jitter calculation）、及びＱｏＳ指示（indication）のような様々な類型（feature）をサポートする。ＭＭＴパケットは、ＭＭＴペイロードにＭＭＴヘッダを付加することにより生成され、ＭＭＴヘッダは、マルチプレキシングされたそれぞれのアセットを識別するための本発明による圧縮されたアセット（compressed Asset）ＩＤ、ネットワークジッタ計算のための配信タイムスタンプ（delivery time stamp）、及びＱｏＳ指示のような情報を含む。ＭＭＴペイロードは、１つのＭＭＴパケット内で送信され、本発明によるソースペイロードがＭＭＴパケットである場合に、ＦＥＣエンコーディングにより生成されたパリティパケットは、ＭＭＴヘッダを付加することによりＭＭＴパケット形態で送信される。この場合に、パリティパケットのためのＭＭＴヘッダの圧縮されたアセットＩＤフィールドは、ＦＥＣメッセージで送信されるパケットフローＩＤ情報値が設定され送信される。ＩＥＴＦアプリケーションプロトコル（例えば、ＲＴＰ）２８０は、ヘッダをＭＭＴペイロードに付加（例えば、ＲＴＰヘッダ）することによりアプリケーションプロトコルを生成する。トランスポートプロトコル（ＴＣＰ、ＵＤＰ）２９０は、ＭＭＴプロトコル又はＩＥＴＦアプリケーションプロトコルをペイロード形態で受信することにより、ＴＣＰ／ＵＤＰヘッダを付加して送信する。

図３は、本発明の一実施形態によるＭＭＴパッケージの構造を示す図である。

図３を参照すると、ＭＭＴパッケージ３００は、制御部３６０の制御の下にネットワークのＤ．レイヤー３４０を通してクライアント３５０と送受信され、ＭＭＴアセット３２０と、コンポジション情報（composition information）３１０と、トランスポート特性（Transport characteristic）３３０とを含む。

また、ＭＭＴパッケージ３００は、コンフィギュレーション情報（configuration information）を使用するための機能性（functionality）及び動作（operation）を有し、コンフィギュレーション情報は、ＭＭＴアセット３２０のリストと、コンポジション情報と、トランスポート特性とを含む。

また、ＭＭＴパッケージ３００は、ＭＭＴパッケージ３００及びＭＭＴアセット３２０を説明するディスクリプション情報（Description information）と、ＭＭＴアセット３２０の消費を助けるコンポジション情報と、ＭＭＴアセット３２０の送信のためのヒントを提供するトランスポート特性情報（Transport characteristics information）とを含む。

また、ＭＭＴパッケージ３００は、ＭＭＴアセット３２０別にトランスポート特性を記述し、トランスポート特性は、エラー復元力（Error Resiliency）情報を含み、１つのＭＭＴアセット３２０のための単純なトランスポート特性（Simple Transport Characteristic）情報は、損失されるか又は損失されないことがある。また、トランスポート特性は、各ＭＭＴアセット３２０のＱｏＳ（損失許容程度、遅延許容程度）を含むことができる。

一方、アプリケーションレイヤーフォワードエラー訂正（Application Layer Forward Error Correction：ＡＬ−ＦＥＣ）に対する具体的なシグナリング方法は、次のようである。

１．損失モデル

ＡＬ−ＦＥＣのためのチャネルモデルは、次のような２種類の損失モデルを仮定する。

通常、ネットワーク上での削除（erasure）は、ランダムだけでなくバーストも伴うためにランダム＋バースト削除チャネルモデルを仮定することが望ましい。

また、ＤＶＢ ＡＬ−ＦＥＣブルーブック（Bluebook）に記載されたＲＥＩＮ削除チャネルをランダム削除チャネルと結合する形態を挙げることができる。ＲＥＩＮチャネルは、ＤＳＬライン上で８ｍｓの固定された時間バースト削除（fixed time burst erasure）を誘発させる。

１．１ ランダム＋ＲＥＩＮ削除チャネルモデル［Ｒｅｆ．ＤＶＢ ＡＬ−ＦＥＣ Ｂｌｕｅｂｏｏｋ］

− 反復電気インパルス雑音（Repetitive Electric Impulse Noise：ＲＥＩＮ）：固定された時間バースト削除（Fixed Time Burst Erasure）（８ｍｓ）

ＩＴＵ Ｇ．１０５０文書に記載されている２ステート（Two-State）ギルバート−エリオット消去チャネル（Gilbert-Elliot Erasure Channel：ＧＥＥＣ）は、よい状態（Good state）及び悪い状態（Bad state）を有し、よい状態は、低い損失状態を示し、悪い状態は、バースト削除を誘発する高い損失状態を示す。

１．２ ２ステートギルバート−エリオット消去チャネル（ＧＥＥＣ）モデル［Ｒｅｆ．ＩＴＵ Ｇ．１０５０］
− 良い状態：ランダム削除チャネル（低い損失状態）
− 悪い状態：バースト削除チャネル（高い損失状態）

２．シミュレーションオン２ステージ（Simulation on Two-Stage）ＦＥＣ符号化の構造

図４は、本発明の一実施形態による１ステージ（One Stage）対２ステージ（Two Stages）のＦＥＣ符号化の構造を示す図である。

図４には図示していないが、２ステージＦＥＣ符号化のために、ソースブロックは、Ｍ個のサブブロックに分けられる。

図４は、オーディオ／ビデオ（ＡＶ）データだけがサービスされる場合に、ＦＥＣ符号化構造４００のそれぞれのサブブロックがＰ１ ＦＥＣパリティ（Ｐ１ ＰＬｓ）を付加するのに要求されるＦＥＣ性能を達成する時に、ハイブリッドコンテンツ配信サービス（Hybrid Contents Delivery Service）（例えば、AV streaming with File）のために、１ステージ４１０では、それぞれのサブブロックにＰ２ ＦＥＣパリティ（Ｐ２ ＰＬｓ）をさらに付加した場合と、２ステージ４２０では、Ｍ個のサブブロックの全体にＭ＊Ｐ２ ＦＥＣパリティ（Ｍ＊Ｐ２ ＰＬｓ）を付加した場合とを示す。

ハイブリッドコンテンツ配信サービスの場合に、ＡＶデータ及びファイルデータがともに送信され、また、ファイルデータは、ＡＶデータよりさらによいＦＥＣ性能を要求するために、ＡＶデータだけがサービスされる場合より追加のＦＥＣパリティが要求される。

通常に、ライブストリーム（Live Stream）のようなＡＶデータは、遅延が小さいほどよいために、ＡＶストリーミングサービスは、低い遅延を得るために相対的に短いブロック（short block）でＦＥＣ保護され送信される。他方、ファイルデータは、遅延に大きく影響を受けないが、データの一部の損失を許容しないために高いＦＥＣ性能を要求し、相対的に長いブロック（long block）でＦＥＣ保護され送信される。これは、ＦＥＣ特性の上、同一のパリティ付加率である場合に長いブロックが短いブロックよりさらによいＦＥＣ性能を示すためである。

このように、ＡＶデータだけサービスされるか又はファイルデータだけサービスされるものとは異なり、ディジタルマッシュアップ（digital mash-up）サービスのようなハイブリッドコンテンツ配信サービスが発達している。これにより、同一のストリーム内にＡＶデータ及びファイルデータをともに送信しなければならず、ＡＶデータ及びファイルデータが要求されるサービス品質（Quality of Service：ＱｏＳ）は、相互に異なるために、２つの異なるＱｏＳを効率的に満足させることができる方法が必要である。すなわち、ＡＶデータのためには、低い遅延を達成し、ファイルデータに対しては、より高いＦＥＣ性能が要求されるＦＥＣ符号化構造が必要である。したがって、本発明では、短いブロックでＡＶデータを保護し、長いブロックでファイルデータを保護する２ステージＦＥＣ符号化構造を提案する。

例えば、ＡＶストリーミング及びファイル転送を同一のストリーム内で送信する場合に、図４に示すように、それぞれのＡＶデータの中間にファイルデータがともに送信される。通常、ＡＶデータのためにＰ１だけのＦＥＣパリティを必要とする場合に、ファイルデータは、ＡＶデータより高いＦＥＣ性能を要求するので、ＡＶデータとファイルデータとを同時にストリーミングする場合に、ファイルデータの要求性能に合うようにＰ＝Ｐ１＋Ｐ２だけのＦＥＣパリティを要求する。通常、同一のＦＥＣパリティ比率である場合には、長いコードを使用して復旧することでよりよいＦＥＣ性能を得ることができる。したがって、Ｐ２パリティをサブブロックに追加で割り当てて訂正する場合に、ファイルデータの性能は、Ｐ２パリティを付加しただけよくなるが、ＡＶデータの場合には、すでにＰ１パリティで要求されるＦＥＣ性能を満足しているので、Ｐ２パリティにより改善するＦＥＣ性能は、大きい意味を有しない。また、バースト削除が発生するチャネル環境では、より効率的な方法が要求され、通常、バースト削除を訂正するための方法では、非常に長いコードを使用するか、又はインターリービングを通してバースト削除をランダム削除に切り替える場合にデコーディング性能を向上させることができる。しかしながら、インターリービング又は長いコードを使用してバースト削除を訂正しようとする場合には、ＡＶデータの遅延が大きくなるために、バースト削除が発生する環境では、ハイブリッドコンテンツ配信サービス（例えば、AV streaming with File）を実行しようとする場合に効率的な方法が要求される。すなわち、ＡＶデータのためには遅延が小さいほどよいので、低い遅延のための短いブロックで構成して要求されるＦＥＣ性能を満たし、ファイルデータのためには、遅延よりもＦＥＣ性能がさらに要求されるので、長いブロックで構成してＦＥＣ性能を最大に向上させる方法が必要である。したがって、図４の１ステージ４１０のためには、それぞれのサブブロックにＰ＝Ｐ１＋Ｐ２だけのＦＥＣパリティを付加し、２ステージ４２０のためには、それぞれのサブブロックにＰ１ ＦＥＣパリティを付加し、Ｍ個のサブブロックの全体で構成されたソースブロックには、Ｐ２ ＦＥＣパリティを付加する。このように、ＡＶデータは、サブブロックのためのＰ１ ＦＥＣパリティで復旧することにより低い遅延を達成し、ファイルデータは、Ｐ１ ＦＥＣパリティで復旧に失敗する時にＭ＊Ｐ２ ＦＥＣパリティを用いて復旧できるので、よりよいＦＥＣ性能を得ることができる。

図５は、本発明の一実施形態によるＡＬ−ＦＥＣのエンコーディング／デコーディングフローに対する概念図である。

図５を参照すると、エンコーディングの時に、ＭＭＴ Ｄ．１レイヤー５１０は、ＭＭＴ Ｅ．１レイヤー５００からＭＭＴパッケージ（ＡＶデータ、ファイル、ｔｘｔなどを保存するか又は送信を考慮した目的で作られたフォーマット）を受信することにより、送信のための一定の単位（Source Payload）に分けてソースブロック５５０を構成する。ＡＬ−ＦＥＣ５４０内のモジュールコンバータ（module Converter）５６０は、所定数のソースペイロードで構成されたソースブロック５５０を同一の長さを有する情報ペイロードで構成された２次元アレイである情報ブロック５７０に転換する。ＦＥＣエンコーダは、情報ブロック５７０から与えられたＦＥＣコードによりＦＥＣエンコーディングを実行し、パリティブロック５８０を生成してペイロードフォーマット生成器（Payload Format Generator）５３０に送信する。ペイロードフォーマット生成器５３０は、パリティブロック５８０をソースブロック５５０に付加し、ペイロードヘッダ（Payload Header：ＰＬＨ）をそれぞれのペイロードに付加することにより、パケット化されたＭＭＴペイロードフォーマットをＭＭＴ Ｄ．２レイヤー又はＩＥＴＦアプリケーションプロトコルレイヤー５２０に送信する。このとき、ペイロードヘッダ（ＰＬＨ）は、ＦＥＣ関連情報を含み、ＦＥＣパケットブロックの開始及び終わり、ＦＥＣパケットブロック内の各ＦＥＣパケットの順序、ソースブロック及びパリティブロックの長さ又は情報ブロック及びパリティブロックの長さなどを含むことにより、受信端でＦＥＣメッセージ及びＦＥＣ関連情報からＦＥＣデコーディングを介して損失されたパケットを復旧できるようにする。また、ＵＤＰのようなトランスポートプロトコルによりＵＤＰヘッダを付加し、さらにＩＰヘッダを付加して送信する。

図５では、例えば、ソースペイロードがＭＭＴペイロードであると図示したが、これに限定されず、ソースペイロードは、ＭＭＴパケット又はＲＴＰパケットであり得る。ソースペイロードがＭＭＴパケット又はＲＴＰパケットである場合に、図５のペイロードフォーマット生成器５３０は、パケットフォーマット発生器となり、ソースブロックは、所定のＭＭＴパケット（又はＲＴＰパケット）となり、残りの過程は、上述した過程と同一に進行され、パリティブロックを生成してソースブロックに付加し、ＰＬＨを付加してＡＬ−ＦＥＣが適用されたＭＭＴパケット（又はＲＴＰパケット）を送信する。また、ＵＤＰのようなトランスポートプロトコルによりＵＤＰヘッダを付加し、さらにＩＰヘッダを付加して送信する。

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

所定数のソースペイロードで構成されるソースブロックは、送信の間に損失を復旧するために２ステージＦＥＣ符号化構造により４通りの場合に保護される。

− ケース０：符号化しない構造 − ケース１：ＦＥＣ１符号化構造（１ステージＦＥＣ符号化構造） − ケース２：ＦＥＣ２符号化構造（１ステージＦＥＣ符号化構造）
− ケース３：ＦＥＣ１及びＦＥＣ２符号化構造（２ステージＦＥＣ符号化構造）

ＦＥＣ１コード及びＦＥＣ２コードのためにＲＳコード及びＬＤＰＣ（又はラプター／ラプターＱ）が使用される。

ケース０のためにＦＥＣ１及びＦＥＣ２エンコーディングが省略され、１ステージＦＥＣ符号化構造である場合に、Ｍは１に設定され、ケース１のためのＦＥＣ１エンコーディングが省略され、ケース２のためのＦＥＣ２エンコーディングが省略される。

２ステージＦＥＣ符号化構造のために、ソースブロックは、Ｍ個のサブブロックで構成され、それぞれのサブブロックは、ＦＥＣ１コードによりエンコーディングされ、ソースブロックは、ＦＥＣ２コードによりエンコーディングされる。

下記の＜表１＞は、２ステージＦＥＣ符号化構造のためのＲＳとＬＤＰＣとの可能な組み合せを示す。ここで、ＬＤＰＣは、ラプター又はラプターＱに置き換えられることができる。

したがって、１ステージＦＥＣ符号化構造を含む２ステージＦＥＣ符号化設計（scheme）で可能なＦＥＣ符号化構造は、次のように６通りの場合が可能である（ＬＤＰＣは、ラプター又はラプターＱに置き換えられることができる。）。

− 符号化なし − ＲＳ符号化（１ステージ） − ＬＤＰＣ符号化（１ステージ） − ＲＳ−ＲＳ符号化（２ステージ） − ＲＳ−ＬＤＰＣ符号化（２ステージ） − ＬＤＰＣ−ＬＤＰＣ符号化（２ステージ）

このとき、注目することは、ケース１は、相対的に小さい個数のソースペイロードで構成されたソースブロックのためのものであり、ケース２は、相対的に大きい個数のソースペイロードで構成されたソースブロックのためのものである。ソース／サブブロックのためのソースペイロードの個数とＦＥＣコードにより付加されるパリティペイロードの個数が２５５より小さいか又は同一である場合に、ＲＳコードが使用され、そうでない場合には、ＬＤＰＣが使用され得る。簡単に、ソース／サブブロックのためのソースペイロードの個数を２００以下、４００、８００、１６００、３２００、６４００に分類化して対応する場合に、２００以下は、ＲＳコードでエンコーディングし、４００以上は、ＬＤＰＣコード（又はラプター／ラプターＱ）を使用できる。

＜表１＞は、例えば、相対的に小さい個数のソースペイロードで構成されたソースブロックのための符号及び相対的に大きい個数のソースペイロードで構成されたソースブロックのための符号がそれぞれ１つずつ使用される場合を仮定した場合である。ＦＥＣ符号は、エラー訂正能力及び複雑度を通して評価されることができ、大部分の場合に、高いエラー訂正能力を有するＦＥＣ符号は、その複雑度も大きく、複雑度が低いＦＥＣ符号は、相対的に低いエラー訂正能力を有する傾向がある。したがって、ＭＭＴのようにその応用が多様化しており、送信器の処理能力（computing power）の範囲が広い場合には、３個以上のＦＥＣ符号を使用する可能性が高い。この場合に、２ステージＦＥＣ符号化構造のためのＦＥＣ符号の組み合わせは、２個のＦＥＣ符号を使用する場合に比べて多様化しており、その組み合わせは、２個のＦＥＣ符号を使用する場合の組み合わせで簡単な拡張を介して得ることができる。

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

図６を参照すると、図面符号６００は、１ステージＦＥＣ符号化構造を示しており、図面符号６１０は、２ステージＦＥＣ符号化構造を示している。

まず、１ステージＦＥＣ符号化構造６００において、ソースブロック６２０は、１つのソースフローからＦＥＣエンコーディングにより保護しようとする単位を決定することにより、所定数のソースペイロードで構成されたブロック単位（ソースブロック）に区分される。保護しようとする単位は、時間又はソースペイロードの個数であり得る。ＦＥＣエンコーダ６３０は、入力されるそれぞれのソースブロックから図８のような一連のステップを通して情報ブロックを生成することにより、ＦＥＣエンコーディングを通して所定数のパリティペイロードを生成し、最終的に、ソースブロック６４０とパリティブロック（Ｐ１）で構成された図７のようなＦＥＣ配信ブロックを生成する。このようなＦＥＣ配信ブロックは、実際の送信のために、図１６のような過程を介してＦＥＣパケットブロックで構成されて送信される。例えば、ソースペイロードがＭＭＴパケットである場合に、ＦＥＣ関連シグナリング情報のためのＰＬＨをそれぞれのソースペイロードに付加してＦＥＣ適用されたＭＭＴパケットとし、ＭＭＴパケットヘッダとＦＥＣ関連シグナリング情報のためのＰＬＨとを付加してＦＥＣ適用されたＭＭＴパケットとすることにより、それぞれのＦＥＣパケットを送信する。

２ステージＦＥＣ符号化構造６１０において、ソースブロック６５０は、Ｍ個のサブブロックに分けられ、複数のサブブロック６６０の各々は、ＦＥＣ１エンコーダ６７０を用いて１ステージＦＥＣ符号化構造と同一の方式にすることにより、サブブロック及びパリティブロック（Ｐ１）で構成されたＦＥＣ配信ブロックを生成する。ＦＥＣ２エンコーダ６９０を用いて１ステージＦＥＣ符号化構造と同様に、ソースブロックからパリティブロック（Ｐ２）を生成してＦＥＣ配信ブロックを生成する。

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

図７を参照すると、ＦＥＣ配信ブロック７００は、ソースブロックとこのソースブロックから一連のステップを経た後にＦＥＣエンコーダから生成されたパリティブロックを含む。

ＦＥＣ送信クラスタ７１０は、２ステージＦＥＣ符号化構造が適用された場合に、第１のサブブロック、第１のサブブロックからＦＥＣ１エンコーダにより生成されたパリティ１ブロック（第１のパリティ１ブロック）で構成された第１のＦＥＣ１送信ブロック、第Ｍのサブブロック、及び第ＭのサブブロックからＦＥＣ１エンコーダにより生成されたパリティ１ブロック（第Ｍのパリティ１ブロック）で構成された第ＭのＦＥＣ１送信ブロック、及びＭ個のサブブロック（＝ソースブロック）からＦＥＣ２エンコーダにより生成されたパリティ２ブロックで構成される。図７のソースブロックのソースペイロードは、その長さがすべて同一であることもあり、相互に異なることもある。相互に異なる場合には、パディングデータをそれぞれのソースペイロードに付加することにより、同一の長さを有する２次元アレイ（Information Block）を図８のように生成する。

図８乃至図１０は、本発明の一実施形態によるソースブロック８００を情報ブロック８１０にマッピングさせる過程を説明するための図である。

図８を参照すると、ソースブロック８００は、長さが相互に異なるソースペイロードで構成される。ここで、ソースペイロードの最大長さは、Ｓ_ｍａｘバイトであり、Ｓ_ｍａｘは、通常、最大トランスポート単位（Maximum Transport Unit）のサイズにより制約されてより小さい値に設定される。説明の便宜上、ソースブロック内のソースペイロードの個数Ｋは、Ｍの倍数であり、それぞれのソースブロックは、Ｋ’個の固定された個数のソースペイロードで構成されるが、これに限定されず、ソースブロック内のそれぞれのソースブロックのサイズは、相互に異なる個数のソースペイロードで構成されることができる。

情報ブロック８１０は、同一の長さを有する情報ペイロードで構成され、それぞれの情報ペイロードは、ソースブロックのソースペイロードからその長さをＳ_ｍａｘにするために必要に応じて予め定められた値を有するパディングデータを付加することにより生成される。すなわち、Ｋ個の情報ペイロードで構成された情報ブロック８１０のｉ番目（Ｉ番目）の情報ペイロードは、Ｋ個のソースペイロードで構成されたソースブロック８００のｉ番目のソースペイロードにその長さをＳ_ｍａｘにするために、必要に応じて予め定められた値を有するパディングデータを付加することにより生成される（ｉ＝１、２、．．．、Ｋ）

情報ブロック８１０からＫが２００以下である場合に、ソースブロックを情報ブロック８１０にマッピングさせることにより、図９に示すように、ＲＳ符号化のための情報シンボル（情報シンボルパート）を生成することもあり、図１０に示すように、ＬＤＰＣ符号化のための情報シンボル（情報シンボルパート）を生成することもある。図９及び図１０において、左側情報ブロック（Information（Sub-）Block）９００、１０００及び右側情報ブロック（Information（Sub-）Block）９１０、１０１０は、同一のブロックである。すなわち、左側情報ブロック９００、１０００のｉ番目のカラムのｊ番目の行の値は、右側情報ブロック９１０、１０１０のi番目のカラムのｊ番目の行の値と同一である（ｉ＝１、２、．．．、Ｋ及びｊ＝１、２、．．．、８＊Ｓ）。左側情報ブロック９００、１０００は、情報ペイロードの観点で示すものであり、右側情報ブロック９１０、１０１０は、情報シンボルの観点で示すものである。

図９において、情報ペイロード＃ｒの第ｐのバイトは、第ｐの情報シンボルの第ｒのバイトにマッピングされる（ｒ＝０、１、．．．Ｋ−１及びｐ＝１、２、．．．、Ｓ）。

図１０において、情報ペイロード＃ｒの第ｐのビットは、第ｐの情報シンボルの第ｒのビットにマッピングされる（ｒ＝０、１、．．．Ｋ−１及びｐ＝１、２、．．．、８＊Ｓ）。

図１１及び図１２は、本発明の一実施形態による情報シンボルを用いてパリティシンボルを生成する過程を説明するための図である。

それぞれの情報シンボル（情報シンボルパート）に対し、図１１に示すようにＲＳエンコーディングを実行し、図１２に示すように、ＬＤＰＣエンコーディングを実行することによりパリティシンボル（パリティシンボルパート）を生成する。図１２の場合、短縮（Shortening）及びパンクチャリング（Puncturing）を図示していないが、定められた長さを有するＬＤＰＣコードを用いて様々なＫ及びＰに対して図１０の場合と類似した短縮及びパンクチャリングを実行することによりパリティシンボルを生成できる。このとき、当然、短縮だけを実行してもよく、パンクチャリングだけを実行してもよい。

図１１において、短縮された２００−Ｋバイトとは、Ｋバイトで構成された第ｐの情報シンボルでＫが２００より小さいので、第ｐの情報シンボルの先頭に２００−Ｋ個のパディングバイト（ａｌｌ ００ｈ）を付加することにより、ＲＳエンコーディングのための情報シンボルの数を２００で作ったものであり、パンクチャリングされた４０−Ｐバイトは、２００バイトで構成された情報シンボルからＲＳ（２４０，２００）コードにより生成された４０個のパリティバイトのうち、Ｐバイトのみ実際に送信し、残りは、意図的に送信を行わないためのものである。このような短縮及びパンクチャリング方法により１つのＲＳ（２４０、２００）コードで様々な情報の長さから様々な長さのパリティを生成することが可能である。

Ｂ（ｐ、ｉ）は、図９の第ｐの情報シンボルでi番目の情報バイトを意味し（ｉ＝０、１、．．．、Ｋ−１）、Ｂ（ｐ、ｊ）は、図９の第ｐのパリティシンボルでｊ−Ｋ番目のパリティバイトを意味する（ｊ＝Ｋ、Ｋ＋１、．．．、Ｎ−１）。

図１２において、ｂ（ｐ、ｉ）は、図１０の第ｐの情報シンボルでｉ番目の情報ビットを意味し（ｉ＝０、１、…、Ｋ−１）、ｂ（ｐ、ｊ）は、図１０の第ｐのパリティシンボルでｊ−Ｋ番目のパリティビットを意味する（ｊ＝Ｋ、Ｋ＋１、．．．Ｎ−１）。

図１３乃至図１５は、本発明の一実施形態によるパリティシンボルを用いてパリティブロックを生成する過程を説明するための図である。

生成されたパリティシンボル（パリティシンボルパート））を用いて図１３のようなＲＳパリティブロック及び図１４のようなＬＤＰＣパリティブロックを生成する。図１３及び図１４の左側パリティブロック１３００、１４００及び右側パリティブロック１３１０、１４１０の構成を示すブロック図であり、図１０及び図１１と同様に、すべて同一のブロックであり、左側パリティブロック１３００、１４００は、パリティシンボル（パリティシンボルパート））の観点で示したものであり、右側パリティブロック１３１０、１４１０は、パリティペイロードの観点で示したものである。

一方、ＲＳコード及びＬＤＰＣコードの項目（specification）を説明すると、次のようである。

ＲＳ（Ｎ，Ｋ） ｃｏｄｅ ｏｖｅｒ ｔｈｅ ｆｉｎｉｔｅ ｆｉｅｌｄ ＧＦ（２^８）の Ｐｒｉｍｉｔｉｖｅ ｐｏｌｙｎｏｍｉａｌ

ｐ（ｘ）＝ｘ^８＋ｘ^４＋ｘ^３＋ｘ^２＋１で定義される。

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

ここで、α＝００００００１０（２進数）である。

それぞれのＲＳコードワード（ｒｓｃ）は、ベクトルで表現する時に、ｒｓｃ＝（ｅ０、ｅ１、．．．、ｅ１９９、ｐ２００、．．．、ｐ２３９）で示され、その情報は、２００バイトであり、パリティが４０バイトであるＲＳ（２４０，４０）ｃｏｄｅ ｏｖｅｒ ｔｈｅ ｆｉｎｉｔｅ ｆｉｅｌｄ ＧＦ（２^８）である。

ＬＤＰＣ（Ｋ＋Ｐ，Ｋ）ｃｏｄｅ ｏｖｅｒ ｔｈｅ ｆｉｎｉｔｅ ｆｉｅｌｄ ＧＦ（２）は、Ｋ個の情報ビット及びＰ個のパリティビットで構成されるＱＣ−ＬＤＰＣ構造である。ここで、Ｋ＝Ｌ×４００及びＰ＝Ｌ×８０、Ｌ＝１、２、４、８又は１６である。

特に、ＬＤＰＣのパリティパートは、図１５に示すように、ほぼ三角行列（approximately triangular matrix）の形態を有する。図１５は、Ｈ行列の構造を示し、図１５において、Ｋ＝４００及びＰ＝Ｌ×８０（Ｌ＝１、２、４、８、又は１６）である。

図１３において、第ｐのパリティシンボルの第ｒのバイトは、第ｒのパリティペイロードの第ｐのバイトにマッピングされ（ｐ＝１、２、．．．、Ｓ及びｒ＝０、１、．．．、Ｐ−１）、図１４において、第ｐのパリティシンボルの第ｒのビットは、第ｒのパリティペイロードの第ｐのビットにマッピングされる（ｐ＝１、２、．．．、８＊Ｓ及びｒ＝０、１、．．．、Ｐ−１）。

図１６は、本発明の一実施形態によるＦＥＣパケットブロックを説明するための図である。

図１６を参照すると、ＦＥＣパケットブロックは、ソースブロック及びパリティブロックで構成され、ＦＥＣパケットクラスタは、サブブロック及びパリティブロックで構成される。ソース又はサブブロック及びパリティブロックで構成されたＦＥＣパケットブロック又はＦＥＣクラスタは、各ペイロードの先頭にＦＥＣパケットヘッダ（ペイロードヘッダ（ＰＬＨ））が与えられることにより、ＦＥＣパケットで構成されたＦＥＣパケットブロック又はＦＥＣパケットクラスタに送信される。図１６において、ＦＥＣパケットヘッダ（ＰＬＨ）は、ペイロードの先頭に付加されるが、これに限定されず、ペイロードの後尾に位置してもよい。

ＦＥＣコンフィギュレーション情報を保存して送信するＦＥＣパケットヘッダは、ＦＥＣパケット内でＦＥＣ関連情報を保存するフィールドと解析されることが望ましく、ＦＥＣ関連情報を含むことができる。すなわち、ＦＥＣパケットブロックの開始及び終わり、ＦＥＣパケットブロック内の各ＦＥＣパケットの順序、ソースブロック及びパリティブロックの長さ（又は情報ブロック及びパリティブロックの長さ）などを含み、受信端でＦＥＣメッセージ及びＦＥＣ関連情報からＦＥＣデコーディングを通して損失されたパケットを復旧できる。また、受信端でＦＥＣパケットが属するＦＥＣフローｉｄ、ソースフローｉｄ、及びパリティフローｉｄが何であるかを識別できる情報が保存されるか又は圧縮されたアセットＩＤ情報が保存されることができる。このとき、圧縮されたアセットＩＤ情報は、ＦＥＣパケットヘッダでないＭＭＴヘッダ又はＭＭＴペイロードヘッダのようにＤレイヤーヘッダに保存される場合に、これを活用できる。

ＦＥＣパケットヘッダは、送信器によりＡＬ−ＦＥＣ適用された符号化構造が何であるかを示す。すなわち、ＦＥＣパケットヘッダフォーマットは、ｆｅｃ＿ｃｏｄｉｎｇ＿ｓｔｒｕｃｔｕｒｅフィールドを含み、その定義は、次のようである。

ｆｅｃ＿ｃｏｄｉｎｇ＿ｓｔｒｕｃｔｕｒｅ：対応するソースフローを保護するために使用されたＦＥＣ符号化構造を示す。

本発明の一実施形態において、２ステージ符号化構造及びレイヤー−アウェア（Layer-Aware）ＦＥＣ（ＬＡ−ＦＥＣ）などの構造化された多重ＦＥＣ符号化方式を適用した場合に、ｆｅｃ＿ｃｏｄｉｎｇ＿ｓｔｒｕｃｔｕｒｅは、次のように定義されることができる。

ｂ０００：符号化しない構造（ケース０）
ｂ００１：１ステージＦＥＣ符号化構造（ケース１）
ｂ０１０：１ステージＦＥＣ符号化構造（ケース２）
ｂ０１１：２ステージＦＥＣ符号化構造（ケース３）
ｂ１００：ＬＡ−ＦＥＣ符号化構造
ｂ１０１〜ｂ１１１：予備

上述したように、ｂ００１（ケース１）は、相対的に小さい数のソースペイロードで構成されたソースブロックを保護するのに適合したＦＥＣ符号の使用を意味し、ｂ０１０（ケース２）は、相対的に大きい数のソースペイロードで構成されたソースブロックを保護するのに適合したＦＥＣ符号の使用を意味する。

また、ｂ０１１（ケース３）は、２ステージＦＥＣ符号化構造が適用された場合を示し、ｂ１００は、レイヤーアウェアＦＥＣ（ＬＡ−ＦＥＣ）符号化構造が適用された場合を示し、ＬＡ−ＦＥＣは、ソースブロックがベースレイヤー（base layer）のためのサブブロックとエンハンスレイヤー（enhance layer）のためのサブブロックとに分けられ、ソースブロックは、ＦＥＣ１エンコーダによりパリティ１ブロック（Parity 1 block）を生成し、ベースレイヤーのためのサブブロックは、ＦＥＣ２エンコーダによりパリティ２ブロック（Parity 2 block）を生成することを示す。

本発明の他の実施形態において、＜表１＞のような組み合わせのＦＥＣ符号を使用する場合に、ｆｅｃ＿ｃｏｄｉｎｇ＿ｓｔｒｕｃｔｕｒｅは、次のように定義されることができる。

＜１番目＞ ｂ０００：符号化しない構造 ｂ００１：ＲＳ符号化構造 ｂ０１０：ＬＤＰＣ符号化構造 ｂ０１１：ＲＳ−ＲＳ２ステージ符号化構造 ｂ１００：ＲＳ−ＬＤＰＣ２ステージ符号化構造 ｂ１０１：ＬＤＰＣ−ＬＤＰＣ２ステージ符号化構造
その他：予備

＜２番目＞ ｂ０００：符号化しない構造 ｂ００１：ＲＳ符号化構造 ｂ０１０：ＬＤＰＣ符号化構造 ｂ１０１：ＲＳ−ＲＳ２ステージ符号化構造 ｂ１１０：ＬＤＰＣ−ＬＤＰＣ２ステージ符号化構造 ｂ１１１：ＲＳ−ＬＤＰＣ２ステージ符号化構造 その他：予備

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

ｆｅｃ＿ｃｏｄｉｎｇ＿ｓｔｒｕｃｔｕｒｅに対するシグナルは、ＦＥＣパケットヘッダに保存されてインバンドシグナル（in-band signal）方式で送信されることもあり、本発明のＦＥＣメッセージのようにＦＥＣ制御パケット又はＲＴＣＰのようなＲＴＰ制御パケットのヘッダ又はペイロードに保存され送信されることにより、受信器が分かるようにする。

一方、本発明は、ＭＭＴパッケージの１つ又はそれ以上のＭＭＴアセットを送信器（Sender）が受信器（Receiver）にＭＭＴフローで送信するにあたり、各ＭＭＴアセットのＱｏＳ（損失特性、遅延特性など）に基づいてＡＬ−ＦＥＣ保護が行われたＭＭＴフロー、すなわち、ＦＥＣフローを送信するためのＦＥＣフローの構成及びＡＬ−ＦＥＣ運用方法を提供する。このために、本発明の送信器は、送信しようとするＭＭＴパッケージ内のＭＭＴアセットをＡＬ−ＦＥＣ保護が行われたパケット及びそのパリティ（parities）で構成されたＭＭＴパケットのシーケンスで構成された１つ又はそれ以上のＦＥＣフローをＤ．レイヤーを介して送信し、Ｄ．レイヤーは、ＭＭＴパッケージ内のＭＭＴフローに含まれるＭＭＴアセットのＱｏＳに基づいてＭＭＴフローを保護するメカニズムを提供し、Ｃ．レイヤーは、ＦＥＣフローに関する説明（ディスクリプション）情報を送信器と受信器との間で相互に通信するようにすることにより、受信器が受信したＭＭＴパケットからＦＥＣフローに関する説明情報（ＦＥＣフローディスクリプタ＝ＦＥＣメッセージ）を予め知っているようにする。

本発明によるＦＥＣ関連メッセージをＣ．レイヤーを通して送信するための一例は、次のような表及び関連情報で構成されることができる。

Ｃ．レイヤーのＦＥＣ関連制御メッセージは、＜表２＞のように構成される。

＜表２＞において、各フィールドの意味は、次のようである。

− fec_flag：１つのＭＭＴサーバで１つ又はそれ以上のＭＭＴクライアントに１つ又はそれ以上のソースフローが送信される時にＦＥＣが適用されるか否かを示す。
− length_of_fec_flow_descriptor()：このフィールドを含むＦＥＣフローディスクリプタのサイズ（バイト）を示す。この値は、少なくとも１つのソースフローがＦＥＣにより保護されて送信される場合に設定される。

fec_flagの実施形態は、次のようである。

− ｂ０：すべてのソースフローがＦＥＣ符号で保護されず送信される。 − ｂ１：少なくとも１つのソースフローは、ＦＥＣ符号で保護されて送信される。

また、ＦＥＣフローディスクリプタは、各ＦＥＣフローに含まれたＭＭＴアセットに対するＱｏＳ（損失特性、遅延特性など）とこれに適用されたＦＥＣ符号化構造及びＦＥＣ符号化アルゴリズムに関する情報を含む。

ＦＥＣフローディスクリプタは、＜表３＞のように構成される。

＜表３＞において、各フィールドの意味は、次のようである。

− protection_mode：ＦＥＣにより保護されるソースペイロードの範囲を示す。例えば、ソースペイロードがＤ．１レイヤーで生成されるＭＭＴペイロードフォーマットそれ自体であるか又はＤ．２ヘッダを付加したＭＭＴトランスポートパケットである場合に、protection_modeフィールドの値及びその意味は、次のようである。 ０：ＭＭＴペイロードフォーマットをソースペイロードとして使用してＦＥＣを適用する。 １：ＭＭＴトランスポートパケットをソースペイロードとして使用してＦＥＣを適用する。 − number_of_fec_flows：ＦＥＣフローの個数を示す。
− number_of_assets_for_fec_flow_i：それぞれのＦＥＣフローｉ（ｉ＝０、１、２、．．．、Ｎ１−１）により適用されたＭＭＴアセットの個数を示す。 − asset_id：ＭＭＴアセットＩＤを示す。 − compressed_asset_id：圧縮されたＭＭＴアセットＩＤを示す。 − error_resiliency：フィールド値に従って次のようなエラー復元力を示す。 ０：損失なし（lossless） １：損失あり（lossy）
− delay_correlation_indicator：他のアセットと遅延に対する相関関係があるかないかを示す。対応するアセットが他のアセットとの同期を必要とするアセットである場合には１に設定され、そうでない場合には、０に設定される。例えば、対応するアセットがビデオアセットであり、オーディオアセットとの同期が必要な場合に、このフィールドの値とオーディオアセットのためのこのフィールドの値をそれぞれ１に設定することにより同期が必要であることを示すか、又は対応するアセットがファイルアセットであり、他のアセットとの同期が必要でない場合に、このフィールドの値を０に設定する。複数のＭＭＴアセットが１つのＦＥＣフローで２ステージＦＥＣ符号化で保護されて送信される場合に、それぞれのＭＭＴアセットに対するこのフィールドの値は、状況に合うように設定され、それぞれのアセットに対して受信端でＦＥＣ２デコーディングが実行されるか否かを決定できる。例えば、１つのＦＥＣフローでオーディオアセット、ビデオアセット、ファイルアセットが２ステージＦＥＣ符号化が行われ、オーディオアセット及びビデオアセットに対するこのフィールドの値が１に同一に設定されており、ファイルアセットのためのこのフィールドの値が０に設定される場合に、オーディオアセット及びビデオアセットは、ＦＥＣ１デコーディングの後にともに出力されるか又はＦＥＣ２デコーディングの後にともに出力されるもののように同一の遅延を有するように出力されなければならないことを意味し、ファイルアセットの場合には、オーディオアセット、ビデオアセットと同一の遅延を有するようにともに出力される必要はないので、ＦＥＣ１デコーディングの失敗の時にＦＥＣ２デコーディングを実行することにより最大に復旧することが好ましい。

すなわち、オーディオアセットは、ＦＥＣ１デコーディングの後に出力され、ビデオアセットは、ＦＥＣ２デコーディングの後に出力されるもののように相互に異なる遅延で出力されないことが好ましい。

− fec_coding_structure_for_fec_flow_i：フィールド値に従ってＦＥＣフローｉ（ｉ＝０、１、２、．．．、Ｎ１−１）に適用されるＦＥＣ符号化構造を示す。 ｂ０００：符号化しない構造（ケース０） ｂ００１：１ステージＦＥＣ符号化構造（ケース１） ｂ０１０：１ステージＦＥＣ符号化構造（ケース２） ｂ０１１：２ステージＦＥＣ符号化構造（ケース３） ｂ１００：ＬＡ−ＦＥＣ符号化構造
ｂ１０１〜ｂ１１１：予備
− parity_flow_descriptor（FCS_i）：パリティフローの識別子及びパリティフローに属するパリティペイロードを生成するために使用された情報語ブロック生成方法及びそれに従う制御情報及びＦＥＣ符号に関する情報及びＦＥＣ符号を復号するために受信器で準備すべきバッファサイズに関する情報を含む。parity_flow_descriptor（FCS_i）に対する具体的な実施形態については後述する。

表３には示さなかったが、各ＦＥＣフローに対するＦＥＣフローラベル（flow label）値を設定することによりそれぞれのＦＥＣフローを区分することが可能である。また、このようなＦＥＣフローラベル情報を１つのＦＥＣフローで送信される各パケットのＤ．レイヤーヘッダに保存して送信することにより、受信器がこの情報からＦＥＣフローを容易に識別するようにできる。

Ｄ．レイヤーヘッダは、ＭＭＴペイロード内の各メディアコンポーネントを識別するための情報であるアセットＩＤフィールドを含み、Ｄ．レイヤーヘッダのアセットＩＤフィールドは、＜表４＞のように構成される。

＜表４＞において、各フィールドの意味は、次のようである。

− number_of_media_components：関連するＭＭＴペイロード内のメディアコンポーネントの個数を示す。
− compressed_asset_id_of_media_component_k：メディアコンポーネントｋ（ｋ＝０、１、２、．．．、Ｎ３−１）を有する関連するＭＭＴアセットの圧縮されたアセットＩＤ
− length_of_media_component_k：メディアコンポーネントｋ（ｋ＝０、１、２、．．．、Ｎ３−１）のサイズ（バイト）を示す。

＜表４＞において、メディアコンポーネントは、ペイロードに送信されるアセットのデータを意味する。

本発明によるＦＥＣ関連メッセージをＣ．レイヤーを通して送信するためのもう１つの実施形態として下記のような表及び情報で構成される。

Ｃ．レイヤーのＭＭＴフロー関連メッセージは、＜表５＞のように構成される。

＜表５＞において、各フィールドの意味は、次のようである。

− package_id：ＭＭＴパッケージのＩＤを示す。 − number_of_mmt_flows：ＭＭＴフローの数を示す。 − mmt_flow_id：ＭＭＴフロー識別子 − number_of_assets：対応するＭＭＴフローで送信されるＭＭＴアセットの数を示す。 − asset_id：ＭＭＴアセットの識別子
− short_asset_id：Ｄ．レイヤーヘッダで使用するショートアセットＩＤ（アセットＩＤを示すためのフィールドのビット数が非常に多い場合に、これを送信する時に圧縮された値でＤ．レイヤーに保存して示す場合に、アセットＩＤを示すためのフィールドのビット数を減少させることによりオーバーヘッドを減少させることができる。 − error_resiliency：フィールド値に従って次のようなエラー復元力を示す
０：損失なし（lossless）
１：損失あり（lossy）
− delay_correlation_indicator：他のアセットと遅延に対する相関関係があるかないかを示す。対応するアセットが他のアセットとの同期を必要とするアセットである場合には、１に設定され、そうでない場合には、０に設定される。例えば、対応するアセットがビデオアセットであり、オーディオアセットとの同期が必要な場合に、このフィールドの値とオーディオアセットのためのこのフィールドの値をそれぞれ１に設定することにより同期が必要であることを示すか、又は対応するアセットがファイルアセットであり、他のアセットとの同期が必要でない場合に、このフィールドの値を０に設定する。

複数のＭＭＴアセットが１つのＦＥＣフローで２ステージＦＥＣ符号化で保護されて送信される場合に、それぞれのＭＭＴアセットに対するこのフィールドの値は、状況に合うように設定されることにより、それぞれのアセットに対して受信端でＦＥＣ２デコーディングが実行されるか否かを決定できる。例えば、１つのＦＥＣフローでオーディオアセット、ビデオアセット、ファイルアセットが２ステージＦＥＣ符号化され、オーディオアセット及びビデオアセットに対するこのフィールドの値が１に同一に設定されており、ファイルアセットのためのこのフィールドの値が０に設定される場合に、オーディオアセット及びビデオアセットは、ＦＥＣ１デコーディングの後にともに出力されるか又はＦＥＣ２デコーディングの後にともに出力されるもののように同一の遅延を有するように出力されなければならないことを意味し、ファイルアセットの場合には、オーディオアセット、ビデオアセットと同一の遅延を有するようにともに出力される必要はないので、ＦＥＣ１デコーディングの失敗の時にＦＥＣ２デコーディングを実行することにより最大に復旧することが好ましい。

すなわち、オーディオアセットは、ＦＥＣ１デコーディングの後に出力され、ビデオアセットは、ＦＥＣ２デコーディングの後に出力されるもののように相互に異なる遅延で出力されないことが好ましい。ＦＥＣフローディスクリプタは、＜表６＞のように構成される。

＜表６＞において、各フィールドの意味は、次のようである。

− number_of_fec_flows：ＦＥＣフローの個数を示す。 − fec_flow_id：ＦＥＣフローｉ（ｉ＝０、１、２、．．．、Ｎ３−１）を識別するためのＦＥＣフロー識別子
− fec_coding_structure_for_fec_flow_i：フィールド値に従ってＦＥＣフローｉ（ｉ＝０、１、２、．．．、Ｎ３−１）に適用されるＦＥＣ符号化構造を示す。 ｂ０００：符号化しない構造（ケース０） ｂ００１：１ステージＦＥＣ符号化構造（ケース１） ｂ０１０：１ステージＦＥＣ符号化構造（ケース２） ｂ０１１：２ステージＦＥＣ符号化構造（ケース３）
ｂ１００：ＬＡ−ＦＥＣ符号化構造
ｂ１０１〜ｂ１１１：予備
− parity_flow_descriptor（FCS_i）：パリティフローの識別子及びパリティフローに属するパリティペイロードを生成するために使用された情報語ブロック生成方法及びそれに従う制御情報、ＦＥＣ符号に関する情報、及びＦＥＣ符号を復号するために受信器で準備すべきバッファサイズに関する情報を含む。parity_flow_descriptor（FCS_i）に対する具体的な実施形態については、後述する。 − number_of_mmt_flows：ＦＥＣフローｉ（ｉ＝０、１、２、．．．、Ｎ３−１）により保護されるＭＭＴフローの個数を示す。 − mmt_flow_id_list：ＦＥＣフローi（ｉ＝０、１、２、．．．、Ｎ３−１）により保護されるＭＭＴフロー識別子のリスト。

ＭＭＴフロー識別子のリストからＭＭＴフローディスクリプタに記述されているそれぞれのＭＭＴフロー識別子が示すＭＭＴフローで送信されるＭＭＴアセットの個数、ＭＭＴアセット識別子、及びショートアセットＩＤがわかる。結局、対応するＦＥＣフロー内にどのＭＭＴアセットが保護されて送信されるかがわかる。それぞれのＭＭＴアセット識別子のために、Ｄ．レイヤーヘッダに保存されることによりショートアセットＩＤがわかる。

Ｄ．レイヤーヘッダは、ＭＭＴペイロード内の各メディアコンポーネントを識別するための情報であるアセットＩＤフィールドを含み、Ｄ．レイヤーヘッダのアセットＩＤフィールドは、＜表７＞のように構成される。

＜表７＞において、各フィールドの意味は、次のようである。

− fec_flow_id：ＦＥＣフロー識別子
− fec_coding_structure：対応するＦＥＣフローＩＤで送信されるそれぞれのＦＥＣブロックに適用されたＦＥＣ符号化を示す。Ｃ．レイヤーで対応するＦＥＣフローＩＤが２ステージＦＥＣ符号化を示していても、それぞれのＦＥＣブロックに適用されたＦＥＣ符号化構造がかならず２ステージで制約する必要がない場合のためにそれぞれのＦＥＣブロックに適用されたＦＥＣ符号化を示すための目的である。すなわち、Ｃ．レイヤーメッセージ上で対応するＦＥＣフローＩＤが２ステージＦＥＣ符号化を示していることは、対応するＦＥＣフローが２ステージＦＥＣ符号化を有するＦＥＣブロックを含んでいるという意味で解釈される。
− sequence number：ＦＥＣフローＩＤ別にＤ．レイヤーパケットのシーケンスを区分するために１つのＦＥＣフローＩＤ内で順次に増加する。 − number_of_media_components：関連するＭＭＴペイロード内のメディアコンポーネントの個数を示す。
− short_asset_id_of_media_component：メディアコンポーネントｋ（ｋ＝０、１、２、．．．、Ｎ５−１）を有する関連するＭＭＴアセットの短いアセットＩＤを示す。受信端は、Ｃ．レイヤーから受信されしたＦＥＣディスクリプタ（）情報から短いアセットＩＤがどのＭＭＴアセットであるかがわかる。
− offset_of_media_component：メディアコンポーネントｋ（ｋ＝０、１、２、．．．、Ｎ５−１）Ｄ．レイヤーペイロード内での開始位置（in bytes）を示す。０を示す場合に、ペイロードの第１のバイトから対応するメディアコンポーネントが開始されることを示す。特に、それぞれのメディアコンポーネントが連続して配置されない場合に有用である。
− length_of_media_component：メディアコンポーネントｋ（ｋ＝０、１、２、．．．、Ｎ５−１）のサイズ（in bytes）を示す。

＜表７＞において、メディアコンポーネントは、ペイロードに送信されるアセットのデータを意味し、様々なアセットが１つのペイロードにマルチプレキシングされた場合を仮定した。１つのペイロードに１つのアセットからのデータだけを送信する場合に、短いアセットＩＤは、送信するペイロードが属するアセットＩＤを示し、この場合には、ＭＭＴパケットヘッダ又はＭＭＴペイロードヘッダに保存される。

本発明の他の実施形態において、ソースフローＩＤ及びパリティフローＩＤをそれぞれソースパケット及びパリティパケットのヘッダから直接得るか又はヘッダに含まれた情報とＣ．レイヤーのフロー関連情報とを組み合せて抽出できる。このとき、ＦＥＣフローディスクリプタは、＜表８＞のようである。

＜表８＞において、各フィールドの意味は、次のようである。

− protection_mode：ＦＥＣにより保護されるソースペイロードの範囲を示す。例えば、ソースペイロードがＤ．１レイヤーで生成されるＭＭＴペイロードフォーマットそれ自体であるか、又はＤ．２ヘッダを付加したＭＭＴトランスポートパケットである場合には、protection_modeフィールドの値及びその意味は、次のようである。
０：ＭＭＴペイロードフォーマットをソースペイロードとして使用してＦＥＣを適用する １：ＭＭＴトランスポートパケットをソースペイロードとして使用してＦＥＣを適用する − number_of_fec_flows：ＦＥＣフローの個数を示す。
− fec_flow_id_for_fec_flow_i：それぞれのＦＥＣフローｉ（ｉ＝０、１、２、．．．、Ｎ１−１）を識別するための識別子を示す。
− source_flow_id_for_fec_flow_i：それぞれのＦＥＣフローｉ（ｉ＝０、１、２、．．．、Ｎ１−１）が保護するソースフローを識別するための識別子を示す。
− fec_coding_structure_for_fec_flow_i：フィールド値に従ってＦＥＣフローi（ｉ＝０、１、２、．．．、Ｎ１−１）に適用されるＦＥＣ符号化構造を示す。 ｂ０００：符号化しない構造（ケース０） ｂ００１：１ステージＦＥＣ符号化構造（ケース１）
ｂ０１０：１ステージＦＥＣ符号化構造（ケース２）
ｂ０１１：２ステージＦＥＣ符号化構造（ケース３）
ｂ１００：ＬＡ−ＦＥＣ符号化構造
ｂ１０１〜ｂ１１１：予備
− parity_flow_descriptor（FCS_i）：パリティフローの識別子及びパリティフローに属するパリティペイロードを生成するために使用された情報語ブロック生成方法及びそれに従う制御情報、ＦＥＣ符号に関する情報、及びＦＥＣ符号を復号するために受信器で準備すべきバッファサイズに関する情報を含む。parity_flow_descriptor（FCS_i）に対する具体的な実施形態については後述する。

＜表８＞とは異なるＦＥＣフローディスクリプタは、＜表９＞のようである。

＜表９＞において、各フィールドの意味は、＜表５＞及び＜表８＞で説明したものと同様である。

一方、本発明の一実施形態において、１ステージ及び２ステージＦＥＣ符号化構造及びレイヤーアウェアＦＥＣ符号化構造をサポートし、３つ以上のｉｂｇ＿ｍｏｄｅをサポートするＡＬ−ＦＥＣ方式を考慮できる。ＦＥＣ観点において、上位レイヤーからの入力であるソースペイロードで構成されたソースブロックをＦＥＣ符号化に適合するように情報ペイロードで構成された情報ブロックに変換する前処理過程が必要である。この時に、前処理過程は、ソースペイロードの特性及び復号器の処理能力に従って様々なアルゴリズムが使用されることができ、このアルゴリズムをｉｂｇ＿ｍｏｄｅと称する。ｉｂｇ＿ｍｏｄｅの実施形態については、後述する。

ソースペイロードの長さがすべて同一である場合に使用されるｉｂｇ＿ｍｏｄｅ０の実施形態は、次のようである。ｉｂｇ＿ｍｏｄｅ０において、ソースブロックを構成するソースペイロードの長さは、すべて同一であり、この時に、情報ブロックは、ソースブロックと一致する。したがって、ソースブロックを構成するソースペイロードの個数と情報ブロックを構成する情報ペイロードの個数とは一致する。

ソースペイロードの長さが異なる場合に使用されるｉｂｇ＿ｍｏｄｅ１の実施形態は、次のようである。ｉｂｇ＿ｍｏｄｅ１において、各ソースペイロードは、１つの情報ペイロードに対応し、情報ペイロードは、ソースペイロードの長さに関する情報とソースペイロードのそれ自体及びパディングデータで構成される。パディングデータは、情報ペイロードの長さを与えられたＳ_ｍａｘと同一に設定するための値であり、通常に、００ｈを各バイトに割り当てる。Ｓ_ｍａｘは、システムの最大送信単位で与えられるか又はソースブロックに含まれたソースペイロードの長さの最大値で与えられる。

ソースペイロードの長さが異なる場合に使用されるｉｂｇ＿ｍｏｄｅ２の実施形態は、次のようである。

ｉｂｇ＿ｍｏｄｅ２において、各情報ペイロードは、Ｎ個の情報サブペイロードで構成され、各ソースペイロード及びその長さに関する情報を情報ブロックに位置させる時に、その開始地点が情報サブペイロードの開始地点と一致するようにパディングデータを含む。ｉｂｇ＿ｍｏｄｅ２の具体的な構成方法を記述するためには、次のような値を定義する。

Ｋ_ＳＰ：ソースブロックを構成するソースペイロードの個数
Ｋ_ＩＰ：情報ブロックを構成する情報ペイロードの個数
Ｒ_ｉ：情報ブロックに付加されるi番目のソースペイロードのオクテット
ｌ_ｉ：Ｒ_ｉのオクテット単位の長さ
Ｌ_ｉ：ｌ_ｉの値を示すネットワークバイトオーダーで作成された２個のオクテット
Ｔ：情報ペイロードのバイト単位の長さ
Ｎ：１つの情報ペイロードを構成する情報サブペイロードの個数 Ｔ’：情報ペイロードのバイト単位の長さ（Ｔ’＝Ｔ／Ｎ）
ｓ_ｉ：次を満足させる最小の整数、ｓ_ｉＴ／Ｎ＝ｓ_ｉＴ’＞＝（ｌ_ｉ＋２）
Ｐ_ｉ：０の値を有するｓ_ｉＴ’（ｌ_ｉ＋２）個のオクテット
Ｐ：０の値をＫ_ＩＰ−Ｓ個のオクテット（Ｓ＝ｓｕｍ｛ｓ_ｉＴ’、ｉ＝１、．．．、Ｋ_ＳＰ ｝）

このとき、この情報ブロックは、ｉ＝１、２、．．．、Ｋ_ＳＰに対してＬ_ｉ、Ｒ_ｉ、Ｐ_ｉを連接した後にＰを連接することにより得られた結果を連続したＴ間隔で分割することにより情報ペイロードを生成する方式で構成される。

本発明の実施形態によるfec_coding_structure_for_fec_flow_iが１ステージ符号化構造（ｂ００１又はｂ０１０）である場合に、Parity_flow_descriptorの実施形態は、＜表１０＞のようである。

＜表１０＞において、各フィールドの意味は、次のようである。

− parity_flow_id_for_fec_flow_i：ｉ番目のＦＥＣフローを構成するパリティフローの識別子
− fec_code_id_for_parity_flow_i：パリティフローに属するパリティペイロードを生成するために使用されるＦＥＣ符号の識別子 − maximum_k：情報ブロックを構成する情報ペイロード個数の最大値
− maximum_p：ＦＥＣブロックを構成するパリティペイロード個数の最大値
− length_of_parity_payload：パリティペイロードのバイト単位の長さ

受信器は、３個のフィールドmaximum_k、maximum_p、length_of_parity_payloadをＦＥＣ復号のために必要なバッファサイズを決定できる。

− ibg_mode：情報ブロックを生成する時に使用されたモード（アルゴリズム）を示す。 ｂ００：ｉｂｇ＿ｍｏｄｅ０
ｂ０１：ｉｂｇ＿ｍｏｄｅ１
ｂ１０：ｉｂｇ＿ｍｏｄｅ２
ｂ１１：ｉｂｇ＿ｍｏｄｅ３
− num_of_parity_payloads_per_packet：１つのＦＥＣリペアパケットに含まれたパリティペイロードの個数。Ｉｂｇ＿ｍｏｄｅ２である場合のみに適用される。
− num_of_sub_payloads_per_information_payload：１つの情報ペイロードを構成する情報サブペイロードの個数。Ｉｂｇ＿ｍｏｄｅ２である場合のみに適用される。

本発明の実施形態によるfec_coding_structure_for_fec_flow_iが２ステージ符号化構造（ｂ０１１）である場合にParity_flow_descriptorの実施形態は、次の＜表１１＞のようである。

＜表１１＞において、各フィールドの意味は、次のようである。

− parity1_flow_id_for_fec_flow_i：i番目のＦＥＣフローを構成するパリティ１フローの識別子
− fec_code_id_for_parity1_flow：パリティ１フローに属するパリティペイロードを生成するために使用されたＦＥＣ符号の識別子
− maximum_k_for_parity1_flow：パリティ１フローに属するパリティペイロードを生成するために使用された情報ブロックを構成する情報ペイロード個数の最大値
− maximum_p_for_parity1_flow：パリティ１フローに属するパリティペイロードが含まれたＦＥＣブロックを構成するパリティペイロード個数の最大値 − parity2_flow_id_for_fec_flow_i：ｉ番目のＦＥＣフローを構成するパリティ２フローの識別子
− fec_code_id_for_parity2_flow：パリティ２フローに属するパリティペイロードを生成するために使用されたＦＥＣ符号の識別子
− maximum_k_for_parity2_flow：パリティ２フローに属するパリティペイロードを生成するために使用された情報ブロックを構成する情報ペイロード個数の最大値
− maximum_p_for_parity2_flow：パリティ２フローに属するパリティペイロードが含まれたＦＥＣブロックを構成するパリティペイロード個数の最大値

− num_of_sub_block_per_source_block：１つのソースブロックを構成するソースサブブロックの数で２ステージ符号化構造を示す。 − length_of_parity_payload：パリティペイロードのバイト単位の長さ − ibg_mode：情報ブロックを生成する時に使用されるモード（アルゴリズム）を示す。 ｂ００：ｉｂｇ＿ｍｏｄｅ０ ｂ０１：ｉｂｇ＿ｍｏｄｅ１
ｂ１０：ｉｂｇ＿ｍｏｄｅ２
ｂ１１：ｉｂｇ＿ｍｏｄｅ３
− num_of_parity_payloads_per_packet：１つのＦＥＣリペアパケットに含まれたパリティペイロードの個数。Ｉｂｇ＿ｍｏｄｅ２である場合のみに適用される。
− num_of_sub_payloads_per_information_payload：１つの情報ペイロードを構成する情報サブペイロードの個数。Ｉｂｇ＿ｍｏｄｅ２である場合のみに適用される。

本発明の実施形態によるfec_coding_structure_for_fec_flow_iがＬＡ−ＦＥＣ符号化構造（ｂ１００）である場合に、Parity_flow_descriptorの実施形態は、次の＜表１２＞のようである。＜表１２＞及びその説明において、ＢＬパリティフローは、ＬＡ−ＦＥＣのベースレイヤーを保護するために生成されたパリティフローを意味し、ＥＬパリティフローは、ＬＡ−ＦＥＣのベースレイヤー及びエンハンスメントレイヤーを同時に保護するために生成されたパリティフローを意味する。

＜表１２＞において、各フィールドの意味は、次のようである。

− BL_parity1_flow_id_for_fec_flow_i：i番目のＦＥＣフローを構成するＢＬパリティフローの識別子
− fec_code_id_for_BL_parity_flow：ＢＬパリティフローに属するパリティペイロードを生成するために使用されるＦＥＣ符号の識別子
− maximum_k_for_BL_parity_flow：ＢＬパリティフローに属するパリティペイロードを生成するために使用される情報ブロックを構成する情報ペイロード個数の最大値
− maximum_p_for_BL_parity_flow：ＢＬパリティフローに属するパリティペイロードが含まれたＦＥＣブロックを構成するパリティペイロード個数の最大値 − EL_parity_flow_id_for_fec_flow_i：ｉ番目のＦＥＣフローを構成するＥＬパリティフローの識別子
− fec_code_id_for_EL_parity_flow：ＥＬパリティフローに属するパリティペイロードを生成するために使用されるＦＥＣ符号の識別子
− maximum_k_for_EL_parity_flow：ＥＬパリティ２フローに属するパリティペイロードを生成するために使用される情報ブロックを構成する情報ペイロード個数の最大値
− maximum_p_for_EL_parity_flow：ＥＬパリティフローに属するパリティペイロードが含まれたＦＥＣブロックを構成するパリティペイロード個数の最大値 − length_of_parity_payload：パリティペイロードのバイト単位の長さ
− ibg_mode：情報ブロックを生成する時に使用されるモード（アルゴリズム）を示す。 ｂ００：ｉｂｇ＿ｍｏｄｅ０
ｂ０１：ｉｂｇ＿ｍｏｄｅ１
ｂ１０：ｉｂｇ＿ｍｏｄｅ２
ｂ１１：ｉｂｇ＿ｍｏｄｅ３
− num_of_parity_payloads_per_packet：１つのＦＥＣリペアパケットに含まれたパリティペイロードの個数。Ｉｂｇ＿ｍｏｄｅ２である場合のみに適用される。
− num_of_sub_payloads_per_information_payload：１つの情報ペイロードを構成する情報サブペイロードの個数。Ｉｂｇ＿ｍｏｄｅ２である場合のみに適用される。

本発明の実施形態によるＭＭＴフロー及びＦＥＣフロー構成方法において、ＭＭＴパッケージeは、次の３通りのアセットで構成される。

− ビデオアセット（ＩＤ０） − オーディオアセット（ＩＤ１）
− ファイルアセット（ＩＤ２）

図１７は、本発明の他の実施形態によるＭＭＴフローを説明するための図である。

ここで、ＭＭＴフローは、ソースペイロードがＭＭＴペイロードである場合に、ＭＭＴペイロードのシーケンスを意味し、ソースペイロードがＭＭＴパケットである場合に、ＭＭＴパケットのシーケンスを意味する。それぞれのＭＭＴアセットは、１つ又は複数のＭＰＵで構成され、それぞれのＭＰＵは、送信のために所定の大きさを有するデータ単位（例えば、最大トランスポートユニット（ＭＴＵ）サイズに基づいて）に分割され、それぞれのデータ単位でペイロードヘッダを付加することによりＭＭＴペイロードでパケット化した後に、ＭＭＴアセットのためのＭＭＴペイロードのシーケンスが構成される。

また、ＭＭＴパケットヘッダをそれぞれのＭＭＴペイロードに付加することによりＭＭＴパケットのシーケンスが構成され、それぞれのシーケンスでＭＭＴペイロードヘッダ又はＭＭＴパケットヘッダには、シーケンスに対応するアセットＩＤの圧縮されたアセットＩＤ値が保存され送信され、アセットＩＤ及び圧縮されたアセットＩＤ情報は、アセットメッセージで受信端に送信される。これにより、受信端は、アセットメッセージ及びＭＭＴペイロードヘッダ又はＭＭＴパケットヘッダにある圧縮されたアセットＩＤ値から対応するアセットのデータを保存しているＭＭＴペイロード又はＭＭＴパケットを識別できる。

− ケース１（１７１０）：オーディオ、ビデオ、ファイルアセットのそれぞれに対して１つのＭＭＴフローを構成する。
− ケース２（１７２０）：オーディオ及びビデオアセットのために１つのＭＭＴフローを構成し、ファイルアセットのために他の１つのＭＭＴフローを構成する。
− ケース３（１７３０）：オーディオ、ビデオ、ファイルアセットのために１つのＭＭＴフローを構成する。
− ケース４（１７４０）：オーディオ及びビデオアセットが多重化される場合に、オーディオ及びビデオアセットに対して１つのＭＭＴフローを構成し、ファイルアセットのために他の１つのＭＭＴフローを構成する。 − ケース５（１７５０）：多重化されたオーディオ／ビデオ（ＡＶ）アセット及びファイルアセットのために１つのＭＭＴフローを構成する。
− ケース６（１７６０）：オーディオ、ビデオ、及びファイルが多重化される場合にオーディオ、ビデオ、及びファイルアセットのために１つのＭＭＴフローを構成する。

図１７において、複数のＭＭＴアセットは、ＭＭＴペイロード端で多重化されており、１つのＭＭＴペイロードは、複数のＭＭＴアセットからのデータを含む。図１７に図示していないが、多重化がＭＭＴパケット端でなされる場合に、１つのＭＭＴパケットが複数のＭＭＴアセットからのデータを含むものでなく、１つのＭＭＴパケットは、１つのＭＭＴアセットからのデータだけを含む。

ここで、多重化は、複数のＭＭＴアセットからのＭＭＴパケットのシーケンスが相互に混じり、１つのＭＭＴパケットのシーケンスを構成する意味である。すなわち、ＭＭＴパケット端での多重化は、例えば、ビデオアセットのためのＭＭＴペイロードシーケンスとオーディオアセットのためのＭＭＴペイロードシーケンスとが相互に混ざり、１つのＭＭＴペイロードシーケンスを構成した後に、それぞれのＭＭＴペイロードにＭＭＴパケットヘッダを付加することによりＭＭＴパケットシーケンスを構成するか又はビデオアセットのためのＭＭＴパケットシーケンスとオーディオアセットのためのＭＭＴパケットシーケンスとが相互に混ざり１つのＭＭＴパケットシーケンスを構成することを意味する。

図１７に示すケース１（１７１０）乃至ケース６（１７６０）については、次のようにＦＥＣフローを構成できる。

１．ケース１（１７１０）

− ケース１−１：３個のアセットのために１つのＦＥＣフローを構成する。これは、３個のＭＭＴアセットを１つのソースフローで構成し、ＦＥＣ保護で送信するためにＦＥＣエンコーディングの実行の後にパリティフローを生成することにより、１つのＦＥＣフローを構成し送信することを意味する。ソースフローのソースペイロードがＭＭＴパケットであり、２ステージＦＥＣ符号化構造（ｂ０１１）により保護される場合に、２個のパリティフローが生成される。これに関連して、＜表９＞のようなＦＥＣフローディスクリプタ上でのＦＥＣメッセージの実施形態は、次のようである。

protection_mode=b0: to indicate which MMT packet is protected.（ＭＭＴパケットだけ保護されるモードを有する場合にこのフィールドは必要でない。） number_of_fec_flows=0x01：to indicate the number of FEC flows.
fec_flow_id_for_ fec_flow=0x01：to indicate the identifier of the FEC flow.
source_flow_id_for_fec_flow=0x01：to indicate the identifier of the Source flow.
number_of_assets=0x03：to indicate the number of MMT assets which the source flow is composed of.
1^st asset_id=0x00000000：to indicate the identifier of the MMT asset (Video)
1^st short_asset_id=0x0000：to indicate the compressed identifier of the MMT asset (Video).（ビデオＭＭＴアセットのためのＭＭＴパケットストリーム上でそれぞれのＭＭＴパケットヘッダの圧縮されたアセットＩＤフィールドには、同一の値（０×００００）を保存することにより、このＭＭＴパケットがビデオのためのパケットであることを示す。）
error_resiliency = b1: to indicate lossy of the MMT asset (Video)
delay_correlation_indicator = b1: to indicate which the MMT asset (Video) is synchronized with other MMT assets which has delay_correlation_indicator = b1.
2^nd asset_id = 0x00000001: to indicate the identifier of the MMT asset (Audio)
2^nd short_asset_id = 0x0001: to indicate the compressed identifier of the MMT asset (Audio).（オーディオＭＭＴアセットのためのＭＭＴパケットストリーム上でそれぞれのＭＭＴパケットヘッダの圧縮されたアセットＩＤフィールドには、上記と同一の値（０×０００１）を保存することにより、このＭＭＴパケットがこのオーディオのためのパケットであることを示す。）
error_resiliency = b1: to indicate lossy of the MMT asset (Audio)
delay_correlation_indicator = b1: to indicate which the MMT asset (Audio) is synchronized with other MMT assets which has delay_correlation_indicator = b1.
3^rd asset_id = 0x00000002: to indicate the identifier of the MMT asset (File)
3^rd short_asset_id = 0x0002: to indicate the compressed identifier of the MMT asset (File)（ファイルＭＭＴアセットのためのＭＭＴパケットストリーム上でそれぞれのＭＭＴパケットヘッダの圧縮されたアセットＩＤフィールドには、上記と同一の値（０×０００２）を保存することにより、このＭＭＴパケットがファイルのためのパケットであることを示す。） error_resiliency = b0: to indicate lossless of the MMT asset (File)
delay_correlation_indicator = b0: to indicate which the MMT asset (File) is not synchronized with other MMT assets.
fec_coding_structure_for_fec_flow = b011: to indicate two stage FEC coding structure. Parity_flow_descriptor() {
parity1_flow_id_for_fec_flow = 0x0003: to indicate the identifier of parity flow which is generated by FEC 1 encoder.（パリティフローのためのＭＭＴパケットストリーム上でそれぞれのＭＭＴパケットヘッダの圧縮されたアセットＩＤフィールドには、上記と同一の値（０×０００３）を保存することにより、このＭＭＴパケットがパリティ１フロー（Parity 1 flow）のためのパケットであることを示す。）
fec_code_id_for_parity1_flow = 0x0001: to indicate the identifier of FEC 1 code.
maximum_k_for_parity1_flow = 0x0000C8: to indicate the maximum number of Information payloads for sub-block = 200.
maximum_p_for_parity1_flow = 0x000028: to indicate the maximum number of Parity payloads for parity1 block = 40.
Parity2_flow_id_for_fec_flow = 0x0004: to indicate the identifier of parity flow which is generated by FEC 2 encoder.（パリティフローのためのＭＭＴパケットストリーム上でそれぞれのＭＭＴパケットヘッダの圧縮されたアセットＩＤフィールドには、上記と同一の値（０×０００４）を保存することにより、このＭＭＴパケットがパリティ２フロー（parity 2 flow）のためのパケットであることを示す。）
fec_code_id_for_parity2_flow = 0x0002: to indicate the identifier of FEC 2 code.
maximum_k_for_parity2_flow = 0x001900: to indicate the maximum number of Information payloads for Source block = 6400.
maximum_p_for_parity2_flow = 0x000500: to indicate the maximum number of Parity payloads for parity2 block = 1280.
number_of_sub_block_per_source_block = 0x20 : to indicate the number of sub-blocks per Source block.
length_of_parity_payload = 0x0400 : to indicate the size (in bytes) of parity payload = 1024. ibg_mode = b01: to indicate ibg_mode1

− ケース１−２：オーディオ、ビデオアセットのための１つのＦＥＣフローとファイルアセットのための他の１つのＦＥＣフローとを構成する（２個のＦＥＣフロー）。これは、オーディオ及びビデオアセットを１つのソースフローで構成し、ファイルアセットをＦＥＣ保護又は他のソースフローで構成し、２個のソースフローの形態で構成し、ＦＥＣ保護で送信するためにそれぞれのソースフローでＦＥＣエンコーディングの実行の後にパリティフローを生成してＦＥＣフローの形態で構成することを意味する。すなわち、オーディオ、ビデオアセットのための１つのＦＥＣフロー、ファイルアセットのための他の１つのＦＥＣフロー、すなわち、２個のＦＥＣフローで送信することを意味する。ソースフローのソースペイロードがＭＭＴパケットであり、１ステージＦＥＣ符号化構造（ｂ００１又はｂ０１０）により保護される場合に１個のパリティフローが生成される。これに関連して、＜表９＞のようなＦＥＣフローディスクリプタ上でのＦＥＣメッセージの実施形態は、次のようである。

protection_mode = b0: to indicate which MMT packet is protected.
（ＭＭＴパケットだけが保護されるモードを有する場合に、このフィールドは必要でない。） number_of_fec_flows = 0x02: to indicate the number of FEC flows.
***** Start for the first FEC flow *****
fec_flow_id_for_fec_flow = 0x01: to indicate the identifier of the FEC flow for Video and Audio MMT assets.
source_flow_id_for_fec_flow = 0x01: to indicate the identifier of the Source flow.
number_of_assets = 0x02: to indicate the number of MMT assets which the source flow is composed of.
1^st asset_id = 0x00000000: to indicate the identifier of the MMT asset (Video)
1^st short_asset_id = 0x0000: to indicate the compressed identifier of the MMT asset (Video).（ビデオＭＭＴアセットのためのＭＭＴパケットストリーム上でそれぞれのＭＭＴパケットヘッダの圧縮されたアセットＩＤフィールドには、上記と同一の値（０×００００）を保存することによりこのＭＭＴパケットがビデオのためのパケットであることを示す。） error_resiliency = b1: to indicate lossy of the MMT asset (Video)
delay_correlation_indicator = b1: to indicate which the MMT asset (Video) is synchronized with other MMT assets which has delay_correlation_indicator = b1.
2^nd asset_id = 0x00000001: to indicate the identifier of the MMT asset (Audio)
2^nd short_asset_id = 0x0001: to indicate the compressed identifier of the MMT asset (Audio).（オーディオＭＭＴアセットのためのＭＭＴパケットストリーム上でそれぞれのＭＭＴパケットヘッダの圧縮されたアセットＩＤフィールドには、上記と同一の値（０×０００１）を保存することによりこのＭＭＴパケットがオーディオのためのパケットであることを示す。） error_resiliency = b1: to indicate lossy of the MMT asset (Audio)
delay_correlation_indicator = b1: to indicate which the MMT asset (Audio) is synchronized with other MMT assets which has delay_correlation_indicator = b1.
fec_coding_structure_for_fec_flow = b001: to indicate one stage FEC coding structure (Case1). Parity_flow_descriptor() {
parity_flow_id_for_fec_flow = 0x0003: to indicate the identifier of parity flow which is generated by FEC encoder.（パリティフローのためのＭＭＴパケットストリーム上でそれぞれのＭＭＴパケットヘッダの圧縮されたアセットＩＤフィールドには、上記と同一の値（０×０００３）を保存することによりＭＭＴパケットがパリティフローのためのパケットであることを示す。）。
fec_code_id_for_parity_flow = 0x0001: to indicate the identifier of FEC code.
maximum_k_for_parity_flow = 0x0000C8: to indicate the maximum number of Information payloads for Source block = 200.
maximum_p_for_parity_flow = 0x000028: to indicate the maximum number of Parity payloads for parity block = 40.
length_of_parity_payload = 0x0400 : to indicate the size (in bytes) of parity payload = 1024. ibg_mode = b01: to indicate ibg_mode1 ***** End for the first FEC flow ***** ***** Start for the Second FEC flow *****
fec_flow_id_for_fec_flow = 0x02: to indicate the identifier of the FEC flow for File MMT asset.
source_flow_id_for_fec_flow = 0x02: to indicate the identifier of the Source flow.
number_of_assets = 0x01: to indicate the number of MMT assets which the source flow is composed of.
asset_id = 0x00000002: to indicate the identifier of the MMT asset (File)
short_asset_id = 0x0002: to indicate the compressed identifier of the MMT asset (File)（ファイルＭＭＴアセットのためのＭＭＴパケットストリーム上でそれぞれのＭＭＴパケットヘッダの圧縮されたアセットＩＤフィールドには、上記と同一の値（０×０００２）を保存することによりＭＭＴパケットがファイルのためのパケットであることを示す。） error_resiliency = b0: to indicate lossless of the MMT asset (File)
delay_correlation_indicator = b0: to indicate which the MMT asset (File) is not synchronized with other MMT assets.
fec_coding_structure_for_fec_flow = b010: to indicate one stage FEC coding structure (Case2). Parity_flow_descriptor() {
Parity2_flow_id_for_fec_flow = 0x0004: to indicate the identifier of parity flow which is generated by FEC 2 encoder.（パリティフローのためのＭＭＴパケットストリーム上でそれぞれのＭＭＴパケットヘッダの圧縮されたアセットＩＤフィールドには、上記と同一の値（０×０００４）を保存することにより、ＭＭＴパケットがパリティ２フローのためのパケットであることを示す。）。
fec_code_id_for_parity2_flow = 0x0002: to indicate the identifier of FEC 2 code.
maximum_k_for_parity_flow = 0x001900: to indicate the maximum number of Information payloads for Source block = 6400.
maximum_p_for_parity_flow = 0x000500: to indicate the maximum number of Parity payloads for parity block = 1280.
length_of_parity_payload = 0x0400 : to indicate the size (in bytes) of parity payload = 1024. ibg_mode = b00: to indicate ibg_mode0 ***** End for the second FEC flow *****

− ケース１−３：アセット別にそれぞれ１つのＦＥＣフローを構成する（３個のＦＥＣフロー）。これは、それぞれのアセットを１つのソースフローの形態で構成し、ＦＥＣ保護して送信するためにＦＥＣエンコーディングによりパリティフローを生成することによりＦＥＣフローの形態で送信することを意味する。すなわち、オーディオアセットのための１つのＦＥＣフロー、ビデオアセットのための他の１つのＦＥＣフロー、ファイルアセットのための他の１つのＦＥＣフロー、すなわち、３個のＦＥＣフローの形態で送信することを意味する。

２．ケース２

− ケース２−１：オーディオ／ビデオアセット及びファイルアセットのための１つのＦＥＣフローを構成する（ケース１−１と同一である）。
− ケース２−２：オーディオ／ビデオアセットのための１つのＦＥＣフローとファイルアセットのための他の１つのＦＥＣフローとを構成する（２個のＦＥＣフロー）（ケース１−２と同一である）。

３．ケース３

− ケース３−１：オーディオ／ビデオ／ファイルアセットのための１つのＦＥＣフローを構成する（ケース１−１と同一である）。

４．ケース４

− ケース４−１：多重化されたオーディオ／ビデオ（ＡＶ）アセット及びファイルアセットのための１つのＦＥＣフローを構成する。
− ケース４−２：多重化されたオーディオ／ビデオ（ＡＶ）アセットのための１つのＦＥＣフロー及びファイルアセットのための他の１つのＦＥＣフローを構成する。

５．ケース５

− ケース５−１：多重化されたオーディオ／ビデオ（ＡＶ）アセット及びファイルアセットのための１つのＦＥＣフローを構成する。

６．ケース６

− ケース６−１：多重化されたオーディオ／ビデオ／ファイル（ＡＶＦ）アセットのための１つのＦＥＣフローを構成する。

図１８は、本発明の一実施形態による送信器の動作を示すフローチャートである。

本発明の送信器は、受信器とデータを送受信する送信部及び受信部と、ＭＭＴアセット、ＦＥＣフロー、及びＦＥＣ符号化構造などを決定する送信器を全般的に制御する制御部と、ソースフロー生成、ＡＬ−ＦＥＣエンコーディングなどを実行する符号化部とを含む。

図１８を参照して送信器の動作について説明する。ステップ１８１０において、送信器は、ＭＭＴパッケージ内の送信しようとするＭＭＴアセットのＡＬ−ＦＥＣ保護を行うか否かを決定する。この後に、ステップ１８２０において、ＭＭＴパッケージ内の送信しようとする１つ又はそれ以上のＭＭＴアセットを幾つかのＦＥＣフローに区分して送信するかを決定し、各ＦＥＣフローの形態で送信されるＭＭＴアセットを決定し、各ＦＥＣフローの形態で送信されるＭＭＴアセットのＱｏＳに基づいてＦＥＣ符号化構造を１ステージＦＥＣ符号化構造又は２ステージＦＥＣ符号化構造の中のいずれか１つで決定する。

また、ステップ１８３０において、各ＦＥＣフローの形態で送信される１つ又はそれ以上のＭＭＴアセットに対するＦＥＣフローディスクリプタをＣ．レイヤーを通して受信器と通信し、ステップ１８４０において、送信しようとするＭＭＴアセットを送信のための単位に分けてＭＭＴフローを生成する。この時に、Ｄ．レイヤーヘッダは、ペイロードのデータが属するアセットＩＤ情報フィールドを保存して送信される。ペイロードが様々なアセットのデータで多重化された場合には、それぞれのデータに対するアセットＩＤ情報フィールドを保存する。ステップ１８５０において、ＭＭＴフローが生成される場合に、送信しようとするＭＭＴアセットのための各ＦＥＣフローのために決定されたＦＥＣ符号化構造でＡＬ−ＦＥＣエンコーディングを実行する。

例えば、ＦＥＣフローの形態で送信されるＭＭＴアセットがオーディオ／ビデオ（ＡＶ）アセット及びファイルアセットであり、これらのＱｏＳが相互に異なる場合、すなわち、オーディオ／ビデオ（ＡＶ）アセットの２００ｍｓ以下の遅延及び損失を許容し、ファイルアセットが遅延にかかわらず損失を許容しない場合、オーディオ、ビデオ、ファイルアセットで構成されたＭＭＴフローを２ステージＦＥＣ符号化構造でエンコーディングする。すなわち、２ステージＦＥＣ符号化構造によるエンコーディングのために十分な大きさのソースブロックを構成し、これをｍ個の小さいサブブロックに分ける。このとき、それぞれのサブブロックは、オーディオ／ビデオ（ＡＶ）アセットの遅延特性を満たす小さいサイズで構成してＦＥＣエンコーディングを実行することにより、ＦＥＣ１ブロックを生成した後にソースブロック全体に対してはファイルアセットの損失特性を満たすようにＦＥＣ２符号化を実行することにより２ステージＦＥＣ符号化を実行する。

図１９は、本発明の一実施形態による受信器の動作を示すフローチャートである。

本発明の受信器は、送信器とデータを送受信する送信部及び受信部と、ＦＥＣ符号化構造の確認及びＦＥＣフローの分類などを実行する、受信器を全般的に制御する制御部と、デコーディングを実行するデコーディング部と、を含む。

図１９を参照して受信器の動作を説明すると、受信器は、ステップ１９１０において、Ｃ．レイヤーを通して送信器と通信したＦＥＣフローディスクリプタから各ＦＥＣフローの形態で送信されるアセットが何であり、そのアセットのエラー復元力特性又はＱｏＳがどうであるかを把握し、各ＦＥＣフローに適用されたＦＥＣ符号化構造が何であるかを把握する。この後に、受信されたパケットのＤ．レイヤーヘッダにＦＥＣフローラベルが保存されて送信されたかを確認して、保存されて送信された場合には、ステップ１９２０において、この値から各ＦＥＣフローを分類するか、または、Ｄ．レイヤーヘッダのアセットＩＤ情報フィールドから対応するパケットが送信しているデータのアセットＩＤを把握することによりそれぞれのＦＥＣフローを分類する。それぞれのＦＥＣフローが分類される場合には、ステップ１９３０において、分類されたそれぞれのＦＥＣフローを送信器が適用したＦＥＣ符号化構造に基づいてＦＥＣデコーディングを実行する。

このとき、送信器が適用したＦＥＣ符号化構造が２ステージＦＥＣ符号化構造である場合に、ＦＥＣフローの形態で送信されるアセットのエラー復元力特性又はＱｏＳに従って様々なＦＥＣデコーディング方法を実行することができる。例えば、オーディオ、ビデオ、及びファイルアセットが１つのＦＥＣフローの形態で２ステージＦＥＣ符号化構造でエンコーディングされ送信され、オーディオ及びビデオアセットのＱｏＳが低い遅延及び損失を許容する。他方、ファイルアセットのＱｏＳが遅延には大きく影響しないが、損失を許容しない場合に、ＦＥＣデコーダは、ＦＥＣ１デコーディングを通して低い遅延でオーディオ／ビデオ（ＡＶ）データを再生し、ＦＥＣ１デコーディングの失敗の時に、ＦＥＣ２デコーディングを通してファイルアセットを復旧する。

一方、本発明において、Ｃ．レイヤーは、コンポジション情報を含むＣ．１レイヤー及び配信を制御するためのＣ．２レイヤーを含み、Ｄ．レイヤーは、ＭＭＴペイロードを生成するためのＤ．１レイヤーであるか、又はＭＭＴトランスポートパケットを生成するＤ．２レイヤーである。

また、本明細書では、ＦＥＣエンコーディングのためのソースペイロードがＭＭＴペイロードフォーマットのペイロードと明示しているが、本発明は、これに制約されず、ソースペイロードがＤ．１レイヤーで生成されるＭＭＴペイロードフォーマットそれ自体であるか、又はＤ．２ヘッダを付加したＭＭＴトランスポートパケットであるか、又はＭＭＴペイロードフォーマットのペイロードにＤ．１ヘッダ及びＤ．２ヘッダの情報の中でＦＥＣ保護が要求される情報を含んで構成される場合をすべて含むことができる。また、本発明で使用したディスクリプタは、Ｃ．レイヤーＦＥＣ関連制御メッセージに対する構成例として使用したものであるだけ、本発明は、ここに制約されず、その内容をいかなる形態でも伝達することが可能である。

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

１０５ ホストＡ
１１０ ホストＢ
１２０ ルータ
１３０ ルータ
１４０ アプリケーション
１５０ データ
１６０ トランスポート
１７０ インターネット
１８０ リンク
１９０ イーサネット（登録商標）
２００ 制御機能
２０５ メディアコーティングレイヤー
２１０ カプセル化機能レイヤー
２２０ 配信機能
２３０ トランスポートプロトコル
２４０ インターネットプロトコル
２５０ ＭＭＴ Ｄ．３レイヤー
２６０ ＭＭＴ Ｄ．１レイヤー
２７０ ＭＭＴ Ｄ．２レイヤー
２８０ ＩＥＴＦアプリケーションプロトコル
２９０ トランスポートプロトコル（ＴＣＰ、ＵＤＰ）
３００ ＭＭＴパッケージ
３１０ コンポジション情報
３２０ ＭＭＴアセット
３３０ トランスポート特性
３４０ Ｄ．レイヤー
３５０ クライアント
３６０ 制御部
４００ ＦＥＣ符号化構造
４１０ １ステージ
４２０ ２ステージ
５００ ＭＭＴ Ｅ．１レイヤー
５１０ ＭＭＴ Ｄ．１レイヤー
５２０ ＩＥＴＦアプリケーションプロトコルレイヤー
５３０ ペイロードフォーマット生成器
５４０ ＡＬ−ＦＥＣ
５５０ ソースブロック
５６０ モジュールコンバータ
５７０ 情報ブロック
５８０ パリティブロック
６００ １ステージＦＥＣ符号化構造
６１０ ２ステージＦＥＣ符号化構造
６２０ ソースブロック
６３０ ＦＥＣエンコーダ
６４０ ソースブロック
６５０ ソースブロック
６６０ サブブロック
６７０ ＦＥＣ１エンコーダ
６９０ ＦＥＣ２エンコーダ
７００ ＦＥＣ配信ブロック
７１０ ＦＥＣ送信クラスタ
８００ ソースブロック
８１０ 情報ブロック
９００ 左側情報ブロック
９１０ 右側情報ブロック
１０００ 左側情報ブロック
１０１０ 右側情報ブロック
１３００ 左側パリティブロック
１３１０ 右側パリティブロック
１４００ 左側パリティブロック
１４１０ 右側パリティブロック

Claims (6)

1. 通信システムにおけるパケット受信方法であって、
   送信器からリペアシンボルを含むフォワードエラー訂正（ＦＥＣ）リペアパケットを受信するステップと、
   前記送信器からＦＥＣ構成情報を含むＦＥＣメッセージを受信するステップと、を含み、
   少なくとも一つのＦＥＣリペアフローを含む前記リペアシンボルは、ＦＥＣで保護される少なくとも１つのＭＰＥＧメディアトランスポート（ＭＭＴ）アセットを決定し、
   前記少なくとも１つのＭＭＴアセットを送信するための少なくとも１つのＦＥＣフローを決定し、
   前記ＭＭＴアセットを運搬するＭＭＴパケットを含むＦＥＣソースフローの個数を決定し、
   前記ＦＥＣソースフローに適用するためのＦＥＣ符号化構造とＦＥＣ符号に基づいてＦＥＣ構成情報を識別し、
   前記ＦＥＣ符号を用いて前記ＦＥＣソースフローに対してＦＥＣエンコーディングを実行することにより生成され、
   前記ＦＥＣメッセージは、前記ＦＥＣフローに対する情報を示すＦＥＣフローディスクリプタに関する情報を含み、
   前記ＦＥＣフローディスクリプタは、ＦＥＣ符号化されたフローの個数に関する情報、同一のＦＥＣソースフローに属するアセットの個数に関する情報、ＦＥＣ符号化されたフローを識別するためのＦＥＣフロー識別子に関する情報、ＦＥＣソースフローを識別するためのソースフロー識別子に関する情報、関連ＦＥＣソースフローに適用されたＦＥＣ符号化構造を示す情報を含むことを特徴とするパケット受信方法。
2. 前記ＦＥＣメッセージは、前記ＦＥＣ符号が適用された前記少なくとも１個のソースフローが存在するか否かを示す情報、前記ＦＥＣフローディスクリプタの長さに関する情報をさらに含むことを特徴とする請求項１に記載のパケット受信方法。
3. 前記ＦＥＣフローディスクリプタは、ソースシンボルブロックを生成するために使用されるモードタイプを示す情報、リペアシンボルの長さに関する情報、ＦＥＣリペアパケットで運搬されるリペアシンボルの個数に関する情報、ソースシンボルを構成するシンボルエレメントの個数に関する情報のうちの少なくとも一つを含むことを特徴とする請求項１に記載のパケット受信方法。
4. 前記ＦＥＣ符号化構造が１ステージＦＥＣ符号化構造である場合に、前記ＦＥＣフローディスクリプタは、ＦＥＣリペアフローを識別するためのリペアフロー識別子に関する情報、関連ＦＥＣリペアフローに適用されるＦＥＣ符号に関する情報、前記関連ＦＥＣリペアフローのためのソースシンボルブロック内で許容されたソースシンボルの最大個数を示すＫに関する情報、前記関連ＦＥＣリペアフローのためのリペアシンボルブロック内で許容されたリペアシンボルの最大個数を示すＰに関する情報のうちの少なくとも一つを含むことを特徴とする請求項１に記載のパケット受信方法。
5. 前記ＦＥＣ符号化構造が２ステージＦＥＣ符号化構造である場合に、前記ＦＥＣフローディスクリプタは、前記２ステージＦＥＣ符号化構造のためのソースパケットブロックを構成するソースサブブロックの個数に関する情報、ＦＥＣリペアフローを識別するためのリペアフロー識別子に関する情報、関連ＦＥＣリペアフローに適用されるＦＥＣ符号に関する情報、前記関連ＦＥＣリペアフローのためのソースシンボルブロック内で許容されたソースシンボルの最大個数を示すＫに関する情報、前記関連ＦＥＣリペアフローのためのリペアシンボルブロック内で許容されたリペアシンボルの最大個数を示すＰに関する情報のうちの少なくとも一つを含むことを特徴とする請求項１に記載のパケット受信方法。
6. 前記ＦＥＣ符号化構造がレイヤーアウェアＦＥＣ符号化構造である場合に、前記ＦＥＣフローディスクリプタは、関連ＦＥＣリペアフローに適用されるＦＥＣ符号に関する情報、ＦＥＣリペアフローを識別するためのリペアフロー識別子に関する情報、前記関連ＦＥＣリペアフローのためのソースシンボルブロック内で許容されたソースシンボルの最大個数を示すＫに関する情報、前記関連ＦＥＣリペアフローのためのリペアシンボルブロック内で許容されたリペアシンボルの最大個数を示すＰに関する情報のうちの少なくとも一つを含むことを特徴とする請求項１に記載のパケット受信方法。