(57)【特許請求の範囲】
【請求項１】
放送信号を受信するための方法において、前記方法は、
少なくとも１つの信号フレームを含む放送信号を受信するステップと、
前記受信された放送信号に対するＯＦＤＭ（Ｏｒｔｈｏｇｏｎａｌ  Ｆｒｅｑｕｅｎｃｙ  Ｄｉｖｉｓｉｏｎ  Ｍｕｌｔｉｐｌｅｘｉｎｇ）復調を行うステップと、
前記受信した放送信号の前記少なくとも１つの信号フレームをパーシングするステップと、
前記少なくとも１つの信号フレーム内のＰＬＰ（Ｐｈｙｓｉｃａｌ  Ｌａｙｅｒ  Ｐｉｐｅ）のデータをデマッピングするステップと、
前記ＰＬＰのデータをデコーディングするステップと、
データストリームを出力するために、前記ＰＬＰのデータ内の少なくとも１つのベースバンドフレームを処理するステップと、
を含み、
前記ベースバンドフレームは、ヘッダ及びペイロードを含み、
前記ヘッダは、他のヘッダが前記ヘッダに存在するか否か及び前記他のヘッダが存在する場合、前記他のヘッダの長さを表すためのインジケータ情報を含み、
前記他のヘッダは、拡張フィールドのタイプを表すタイプ情報及び前記拡張フィールドの長さを表す長さ情報を含む、方法。
【請求項２】
前記インジケータ情報が第１の値を有する場合、前記インジケータ情報の前記第１の値は、前記他のヘッダが存在しないことを表し、
前記インジケータ情報が第２の値を有する場合、前記インジケータ情報の前記第２の値は、前記他のヘッダが存在し、前記他のヘッダの長さが１バイトであることを表し、
前記インジケータ情報が第３の値を有する場合、前記インジケータ情報の前記第３の値は、前記他のヘッダが存在し、前記他のヘッダの長さが２バイトであることを表す、請求項１に記載の方法。
【請求項３】
前記他のヘッダの長さが２バイトである場合、１番目のバイトは、前記タイプ情報及び前記長さ情報のＬＳＢ（Ｌｅａｓｔ  Ｓｉｇｎｉｆｉｃａｎｔ  Ｂｉｔ）パートを含み、２番目のバイトは、前記長さ情報のＭＳＢ（Ｍｏｓｔ  Ｓｉｇｎｉｆｉｃａｎｔ  Ｂｉｔ）パートを含む、請求項２に記載の方法。
【請求項４】
前記タイプ情報の長さは３ビットであり、前記長さ情報のＬＳＢパートの長さは５ビットであり、前記長さ情報のＭＳＢパートの長さは８ビットである、請求項３に記載の方法。
【請求項５】
前記タイプ情報が第１の値を有する場合、前記タイプ情報の前記第１の値は、前記拡張フィールドがパディングデータを含むことを表し、
前記タイプ情報が第２の値を有する場合、前記タイプ情報の前記第２の値は、前記拡張フィールドが追加シグナリング情報を指示するデータを含むことを表す、請求項１に記載の方法。
【請求項６】
放送信号を受信するための装置において、
少なくとも１つの信号フレームを含む放送信号を受信するための受信機と、
前記受信された放送信号に対するＯＦＤＭ（Ｏｒｔｈｏｇｏｎａｌ  Ｆｒｅｑｕｅｎｃｙ  Ｄｉｖｉｓｉｏｎ  Ｍｕｌｔｉｐｌｅｘｉｎｇ）復調を行うための復調器と、
前記受信された放送信号の前記少なくとも１つの信号フレームをパーシングするためのフレームパーサと、
前記信号フレーム内のＰＬＰ（Ｐｈｙｓｉｃａｌ  Ｌａｙｅｒ  Ｐｉｐｅ）のデータをデマッピングするためのデマッパと、
前記ＰＬＰのデータをデコーディングするためのデコーダと、
データストリームを出力するために、前記ＰＬＰのデータ内の少なくとも１つのベースバンドフレームを処理するためのアウトプットプロセッサと、
を備え、
前記ベースバンドフレームは、ヘッダ及びペイロードを含み、
前記ヘッダは、他のヘッダが前記ヘッダに存在するか否か及び前記他のヘッダが存在する場合、前記他のヘッダの長さを表すためのインジケータ情報を含み、
前記他のヘッダは、拡張フィールドのタイプを表すタイプ情報及び前記拡張フィールドの長さを表す長さ情報を含む、装置。
【請求項７】
前記インジケータ情報が第１の値を有する場合、前記インジケータ情報の前記第１の値は、前記他のヘッダが存在しないことを表し、
前記インジケータ情報が第２の値を有する場合、前記インジケータ情報の前記第２の値は、前記他のヘッダが存在し、前記他のヘッダの長さが１バイトであることを表し、
前記インジケータ情報が第３の値を有する場合、前記インジケータ情報の前記第３の値は、前記他のヘッダが存在し、前記他のヘッダの長さが２バイトであることを表す、請求項６に記載の装置。
【請求項８】
前記他のヘッダの長さが２バイトである場合、１番目のバイトは、前記タイプ情報及び前記長さ情報のＬＳＢ（Ｌｅａｓｔ  Ｓｉｇｎｉｆｉｃａｎｔ  Ｂｉｔ）パートを含み、２番目のバイトは、前記長さ情報のＭＳＢ（Ｍｏｓｔ  Ｓｉｇｎｉｆｉｃａｎｔ  Ｂｉｔ）パートを含む、請求項７に記載の装置。
【請求項９】
前記タイプ情報が第１の値を有する場合、前記タイプ情報の前記第１の値は、前記拡張フィールドがパディングデータを含むことを表し、
前記タイプ情報が第２の値を有する場合、前記タイプ情報の前記第２の値は、前記拡張フィールドが追加シグナリング情報を指示するデータを含むことを表す、請求項６に記載の装置。
【請求項１０】
前記タイプ情報の長さは３ビットであり、前記長さ情報のＬＳＢパートの長さは５ビットであり、前記長さ情報のＭＳＢパートの長さは８ビットである、請求項８に記載の装置。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、放送信号送信装置、放送信号受信装置、及び放送信号送受信方法に関するものである。
【背景技術】
【０００２】
アナログ放送信号送信が終了するにつれて、ディジタル放送信号を送受信するための様々な技術が開発されている。ディジタル放送信号はアナログ放送信号に比べてより多い量のビデオ／オーディオデータを含むことができ、ビデオ／オーディオデータだけでなく、様々な種類の付加データをさらに含むことができる。
【発明の概要】
【発明が解決しようとする課題】
【０００３】
即ち、ディジタル放送システムはＨＤ（High Definition）イメージ、マルチャネル（multichannel、多チャネル）オーディオ、及び様々な付加サービスを提供することができる。しかしながら、ディジタル放送のためには、多量のデータ送信に対するデータ送信効率、送受信ネットワークの堅固性（robustness）、及びモバイル受信装置を考慮したネットワーク柔軟性（flexibility）が向上しなければならない。
【０００４】
また、本発明は、ＢＢＦ内にＳｔｕｆｆｉｎｇ  ｆｉｅｌｄの存在有無をシグナリングするための方法を提供することに目的がある。
【０００５】
また、本発明は、ＢＢＦ内に存在するＳｔｕｆｆｉｎｇ  ｆｉｅｌｄ、すなわち、Ｓｔｕｆｆｉｎｇデータの使用Ｔｙｐｅを指定するための方法を提供することに目的がある。
【０００６】
また、本発明は、Ｓｔｕｆｆｉｎｇ  Ｔｙｐｅフィールドを２種類の互いに異なるフィールドに分割して用いることにより、Ｓｔｕｆｆｉｎｇ  Ｔｙｐｅフィールドの効率的な利用を提供することに目的が  ある。
【０００７】
本明細書においてなそうとする技術的課題は、以上で言及した技術的課題に制限されず、言及していないさらに他の技術的課題は、下記の記載から本発明の属する技術分野における通常の知識を有する者に  明確に理解され得るであろう。
【課題を解決するための手段】
【０００８】
本明細書は、放送信号を受信するための方法において、少なくとも１つの信号フレームを含む放送信号を受信するステップと、前記受信された放送信号をＯＦＤＭ（Ｏｒｔｈｏｇｏｎａｌ  Ｆｒｅｑｕｅｎｃｙ  Ｄｉｖｉｓｉｏｎ  Ｍｕｌｔｉｐｌｅｘｉｎｇ）方式によってデータ復調を行うステップと、サービスデータ（ｓｅｒｖｉｃｅ  ｄａｔａ）またはサービスコンポーネントデータ（ｓｅｒｖｉｃｅ  ｃｏｍｐｏｎｅｎｔ  ｄａｔａ）を抽出するために、前記受信された放送信号に含まれた前記少なくとも１つの信号フレームをパーシング（Ｐａｒｓｉｎｇ）するステップと、前記サービスデータ（ｓｅｒｖｉｃｅ  ｄａｔａ）またはサービスコンポーネントデータ（ｓｅｒｖｉｃｅ  ｃｏｍｐｏｎｅｎｔ  ｄａｔａ）をビットに変換するステップと、前記変換されたビットをデコーディング（ｄｅｃｏｄｉｎｇ）するステップと、前記デコーディングされたビットを含むデータストリームを出力するステップとを含み、前記出力するステップは、ベースバンドフレーム（Ｂａｓｅｂａｎｄ  Ｆｒａｍｅ）のヘッダに含まれた情報をディテクティング（ｄｅｔｅｃｔｉｎｇ）または取得（ｏｂｔａｉｎｉｎｇ）するステップを含み、前記ＢＢＦは、スタッフィング（Ｓｔｕｆｆｉｎｇ）フィールドが前記ヘッダに存在するか否かを表す制御情報を含むことを特徴とする。
【０００９】
また、本明細書において前記制御情報は、前記ヘッダに含まれることを特徴とする。
【００１０】
また、本明細書において前記ヘッダは、スタッフィング長さのＭＳＢ（Ｍｏｓｔ  Ｓｉｇｎｉｆｉｃａｎｔ  Ｂｉｔ）ｐａｒｔが前記スタッフィング（Ｓｔｕｆｆｉｎｇ）フィールドに存在するか否かを表す指示情報またはスタッフィングデータのタイプを表すスタッフィングタイプ（ＳＴＵＦＦ＿ＴＹＰＥ）フィールドのうち、少なくとも１つを含むことを特徴とする。
【００１１】
また、本明細書において前記スタッフィングフィールドは、スタッフィングヘッダ（Ｓｔｕｆｆｉｎｇ  Ｈｅａｄｅｒ）及びスタッフィングデータ（Ｓｔｕｆｆｉｎｇ  Ｄａｔａ）を含み、前記指示情報及び前記スタッフィングタイプフィールドは、前記スタッフィングヘッダに含まれることを特徴とする。
【００１２】
また、本明細書において前記指示情報の大きさは、１ｂｉｔであり、前記スタッフィングタイプ（ＳＴＵＦＦ＿ＴＹＰＥ）フィールドは、２ｂｉｔｓであることを特徴とする。
【００１３】
また、本明細書において前記スタッフィングヘッダは、前記スタッフィングフィールドの長さを表すスタッフィング長さ（ＳＴＵＦＦ＿ＬＥＮ）フィールドをさらに含み、前記スタッフィング長さ（ＳＴＵＦＦ＿ＬＥＮ）フィールドは、スタッフィング長さのＭＳＢ（ＳＴＵＦＦ＿ＬＥＮ＿ＭＳＢ）ｐａｒｔ及びスタッフィング長さのＬＳＢ（ＳＴＵＦＦ＿ＬＥＮ＿ＬＳＢ）ｐａｒｔに区分されることを特徴とする。
【００１４】
また、本明細書において前記制御情報は、ＥＸＴ＿Ｉ（Ｅｘｔｅｎｓｉｏｎ  Ｉｎｄｉｃａｔｏｒ）フィールドであり、前記指示情報は、ＭＳＢ＿Ｉ（Ｉｎｄｉｃａｔｏｒ）フィールドであることを特徴とする。
【００１５】
また、本明細書において前記スタッフィングフィールドは、前記ペイロードにデータパケットが満たされないか、またはｉｎ−ｂａｎｄ  ｓｉｇｎａｌｉｎｇが使用される場合、前記ベースバンドフレームに含まれることを特徴とする。
【００１６】
また、本明細書において前記スタッフィングデータは、スタッフィングまたはｉｎ−ｂａｎｄ  ｓｉｇｎａｌｉｎｇのうち、少なくとも１つを表すことを特徴とする。
【００１７】
また、本明細書は、前記スタッフィングフィールドの長さが３２ｂｙｔｅｓ(バイト)以下である場合、前記スタッフィング長さのＭＳＢ（Ｌｅａｓｔ  Ｓｉｇｎｉｆｉｃａｎｔ  Ｂｉｔ）ｐａｒｔは、前記スタッフィングフィールドに含まれないことを特徴とする。
【００１８】
また、本明細書は、放送信号を受信するための受信装置において、少なくとも１つの信号フレームを含む放送信号を受信するための受信機（ｒｅｃｅｉｖｅｒ）と、前記受信された放送信号をＯＦＤＭ（Ｏｒｔｈｏｇｏｎａｌ  Ｆｒｅｑｕｅｎｃｙ  Ｄｉｖｉｓｉｏｎ  Ｍｕｌｔｉｐｌｅｘｉｎｇ）方式によってデータを復調するための復調器（ｄｅｍｏｄｕｌａｔｏｒ）と、サービスデータ（ｓｅｒｖｉｃｅ  ｄａｔａ）またはサービスコンポーネントデータ（ｓｅｒｖｉｃｅ  ｃｏｍｐｏｎｅｎｔ  ｄａｔａ）を抽出するために、前記受信された放送信号に含まれた前記少なくとも１つの信号フレームをパーシング（Ｐａｒｓｉｎｇ）するためのフレームパーサ（ｆｒａｍｅ  ｐａｒｓｅｒ）と、前記サービスデータ（ｓｅｒｖｉｃｅ  ｄａｔａ）またはサービスコンポーネントデータ（ｓｅｒｖｉｃｅ  ｃｏｍｐｏｎｅｎｔ  ｄａｔａ）をビットに変換するための変換器（ｃｏｎｖｅｒｔｅｒ）と、前記変換されたビットをデコーディング（ｄｅｃｏｄｉｎｇ）するためのデコーダ（ｄｅｃｏｄｅｒ）と、前記デコーディングされたビットを含むデータストリームを出力するためのアウトプットプロセッサ（ｏｕｔｐｕｔ  ｐｒｏｃｅｓｓｏｒ）とを備え、前記アウトプットプロセッサは、ベースバンドフレーム（Ｂａｓｅｂａｎｄ  Ｆｒａｍｅ）のヘッダに含まれた情報をディテクティング（検出）（ｄｅｔｅｃｔｉｎｇ）または取得（ｏｂｔａｉｎｉｎｇ）するためのベースバンドフレームプロセッサ（ｂａｓｅｂａｎｄ  ｆｒａｍｅ  ｐｒｏｃｅｓｓｏｒ）を含み、前記ＢＢＦは、スタッフィング（Ｓｔｕｆｆｉｎｇ）フィールドが前記ヘッダに存在するか否かを表す制御情報を含むことを特徴とする。
【発明の効果】
【００１９】
本発明は、サービス特性によってデータを処理し、各サービスまたはサービスコンポーネントに対するＱｏＳ（Ｑｕａｌｉｔｙ  ｏｆ  Ｓｅｒｖｉｃｅ）を制御することにより、様々な放送サービスを提供できる。
【００２０】
また、本発明は、同じＲＦ（ｒａｄｉｏ  ｆｒｅｑｕｅｎｃｙ）信号帯域幅を介して様々な放送サービスを送信することにより、送信柔軟性（ｆｌｅｘｉｂｉｌｉｔｙ）を達成できる。
【００２１】
また、本発明は、ＭＩＭＯ（Ｍｕｌｔｉｐｌｅ−Ｉｎｐｕｔ  Ｍｕｌｔｉｐｌｅ−Ｏｕｔｐｕｔ）システムを利用してデータ送信効率及び放送信号の送受信堅固性（Ｒｏｂｕｓｔｎｅｓｓ）を向上させることができる。
【００２２】
また、本発明によれば、モバイル受信装置を使用するか、室内環境にあっても、エラー無しでデジタル放送信号を受信できる放送信号送信及び受信方法及び装置を提供できる。
【００２３】
また、本発明は、ＢＢＦ内にＳｔｕｆｆｉｎｇ  ｆｉｅｌｄの存在有無を表す新しいフィールドを定義することにより、ＢＢＦ内にＳｔｕｆｆｉｎｇ  ｆｉｅｌｄが存在するか否かを速くかつ正確に分かることができるという効果がある。
【００２４】
また、本発明は、ＢＢＦ内に存在するＳｔｕｆｆｉｎｇ  ｆｉｅｌｄ、すなわち、Ｓｔｕｆｆｉｎｇデータの使用Ｔｙｐｅを定義することにより、Ｓｔｕｆｆｉｎｇ  ｆｉｅｌｄにＳｔｕｆｆｉｎｇ以外に、他の情報を使用させることができるという効果がある。
【００２５】
また、本発明は、Ｓｔｕｆｆｉｎｇ  Ｔｙｐｅフィールドを２種類の互いに異なるフィールドに分割して用いることにより、Ｓｔｕｆｆｉｎｇ  Ｔｙｐｅフィールドを効率的に運営することができるという効果がある。
【００２６】
本明細書において得ることができる効果は、以上で言及した効果に制限されず、言及していないさらに他の効果は、下記の記載から本発明の属する技術分野における通常の知識を有する者に明確に理解され得るであろう。
【図面の簡単な説明】
【００２７】
本発明に対してさらに理解するために含まれて、本出願に含まれて、その一部を構成する添付の図面は本発明の原理を説明する詳細な説明と共に本発明の実施形態を示す。
【図１】本発明の一実施形態に係る次世代放送サービスに対する放送信号送信装置の構造を示す。
【図２】本発明の一実施形態に係るインプットフォーマッティング（Input formatting：入力フォーマット）ブロックを示す。
【図３】本発明の他の一実施形態に係るインプットフォーマッティング（Input formatting：入力フォーマット）ブロックを示す。
【図４】本発明の他の一実施形態に係るインプットフォーマッティング（Input formatting：入力フォーマット）ブロックを示す。
【図５】本発明の一実施形態に係るＢＩＣＭ（bit interleaved coding & modulation）ブロックを示す。
【図６】本発明の他の一実施形態に係るＢＩＣＭブロックを示す。
【図７】本発明の一実施形態に係るフレームビルディング（Frame Building：フレーム生成）ブロックを示す。
【図８】本発明の一実施形態に係るＯＦＤＭ（orthogonal frequency division multiplexing）ジェネレーション（generation：生成）ブロックを示す。
【図９】本発明の一実施形態に係る次世代放送サービスに対する放送信号受信装置の構造を示す。
【図１０】本発明の一実施形態に係るフレーム構造を示す。
【図１１】本発明の一実施形態に係るフレームのシグナリング階層構造を示す。
【図１２】本発明の一実施形態に係るプリアンブルシグナリングデータを示す。
【図１３】本発明の一実施形態に係るＰＬＳ１データを示す。
【図１４】本発明の一実施形態に係るＰＬＳ２データを示す。
【図１５】本発明の他の一実施形態に係るＰＬＳ２データを示す。
【図１６】本発明の一実施形態に係るフレームのロジカル（logical：論理）構造を示す。
【図１７】本発明の一実施形態に係るＰＬＳ（physical layer signaling）マッピングを示す。
【図１８】本発明の一実施形態に係るＥＡＣ（emergency alert channel）マッピングを示す。
【図１９】本発明の一実施形態に係るＦＩＣ（fast information channel）マッピングを示す。
【図２０】本発明の一実施形態に係るＤＰ（data pipe：データパイプ）のタイプを示す。
【図２１】本発明の一実施形態に係るＤＰ（data pipe：データパイプ）マッピングを示す。
【図２２】本発明の一実施形態に係るＦＥＣ（forward error correction）構造を示す。
【図２３】本発明の一実施形態に係るビットインターリービングを示す。
【図２４】本発明の一実施形態に係るセル−ワードデマルチプレキシングを示す。
【図２５】本発明の一実施形態に係る時間インターリービングを示す。
【図２６】本発明の一実施形態に係るツイストされた行−列ブロックインターリーバの基本動作を示す。
【図２７】本発明の他の一実施形態に係るツイストされた行−列ブロックインターリーバの動作を示す。
【図２８】本発明の一実施形態に係るツイストされた行−列ブロックインターリーバの対角線方向リードパターンを示す。
【図２９】本発明の一実施形態に係る各インターリービングアレイ（ａｒｒａｙ）からインターリービングされたＸＦＥＣＢＬＯＣＫを示す。
【図３０】図９の同期及び復調（synchronization & demodulation）モジュールの一例を示す図である。
【図３１】図９のフレームパーシングモジュールの一例を示す図である。
【図３２】図９のデマッピング及びデコーディング（demapping & decoding）モジュールの一例を示す図である。
【図３３】図９のアウトプットプロセッサ（output processor）の一例を示す図である。
【図３４】図９のアウトプットプロセッサの更に他の一例を示す図である。
【図３５】本発明の他の実施形態に係るコーディングアンドモジュレーションモジュールを示す図である。
【図３６】本発明の他の実施形態に係るデマッピング及びデコーディングモジュールを示す図である。
【図３７】本明細書で提案するモードアダプテーションモジュールの一例を示す図である。
【図３８】本明細書で提案するアウトプットプロセッサの一例を示す図である。
【図３９】従来のＢＢフレーム構造の一例を示す図である。
【図４０】従来のＢＢフレーム構造の更に他の一例を示す図である。
【図４１】従来のＢＢフレーム構造の更に他の一例を示す図である。
【図４２】本明細書で提案するＢＢフレーム構造の一例を示す。
【図４３】本明細書で提案するＢＢフレーム構造の更に他の一例を示す図である。
【図４４】本明細書で提案するＢＢフレーム構造の更に他の一例を示す図である。
【図４５】本明細書で提案するＢＢフレーム構造の更に他の一例を示す図である。
【図４６】様々なＢＢフレーム構造でＢＢフレーム送信に対するオーバーヘッドを計算した結果を比較して示す図である。
【図４７】従来のＢＢフレーム構造の一例を示す。
【図４８】本明細書で提案するＢＢフレーム構造の一例を示す図である。
【図４９】本明細書で提案するＢＢフレーム構造の更に他の一例を示す図である。
【図５０】本明細書で提案するＢＢフレーム構造の更に他の一例を示す図である。
【図５１】本明細書で提案するＢＢフレーム構造の更に他の一例を示す図である。
【図５２】本明細書で提案する放送信号の送信方法の一例を示す順序図である。
【図５３】本明細書で提案する放送信号の受信方法の一例を示す順序図である。
【発明を実施するための形態】
【００２８】
本発明の好ましい実施形態に対して具体的に説明し、その例は添付した図面に示す。添付した図面を参照した以下の詳細な説明は、本発明の実施形態によって具現できる実施形態のみを示すよりは、本発明の好ましい実施形態を説明するためのものである。次の詳細な説明は、本発明に対する徹底した理解を提供するために細部事項を含む。しかしながら、本発明がこのような細部事項無しで実行できるということは当業者に自明である。
【００２９】
本発明で使用される大部分の用語は該当分野で広く使用される一般的なものから選択されるが、一部の用語は出願人により任意に選択され、その意味は必要によって次の説明で詳細に叙述する。したがって、本発明は用語の単純な名称や意味でない用語の意図した意味に基づいて理解されなければならない。
【００３０】
本発明は、次世代放送サービスに対する放送信号送信及び受信装置、及び方法を提供する。本発明の一実施形態に係る次世代放送サービスは、地上波放送サービス、モバイル放送サービス、ＵＨＤＴＶサービスなどを含む。本発明は一実施形態に従って非−ＭＩＭＯ（non-Multiple Input Multiple Output）またはＭＩＭＯ方式により次世代放送サービスに対する放送信号を処理することができる。本発明の一実施形態に係る非−ＭＩＭＯ方式は、ＭＩＳＯ（Multiple Input Single Output）方式、ＳＩＳＯ（Single Input Single Output）方式などを含むことができる。
【００３１】
以下、説明の便宜のためにＭＩＳＯまたはＭＩＭＯ方式は２つのアンテナを使用するが、本発明は２つ以上のアンテナを使用するシステムに適用できる。本発明は、特定用途に要求される性能を達成し、かつ受信機の複雑度を最小化するために最適化した３個のフィジカルプロファイル（PHY profile）（ベース（base）、ハンドヘルド（handheld）、アドバンス（advanced）プロファイル）を定義することができる。フィジカルプロファイルは、該当する受信機が具現しなければならない全ての構造のサブセットである。
【００３２】
３個のフィジカルプロファイルは大部分の機能ブロックを共有するが、特定ブロック及び／又はパラメータでは若干異なる。今後に追加でフィジカルプロファイルが定義できる。システムの発展のために、フューチャープロファイルはＦＥＦ（future extension frame）を通じて単一ＲＦ（radio frequency）チャネルに存在するプロファイルとマルチプレキシングされることもできる。各フィジカルプロファイルに対する詳細な内容は後述する。
【００３３】
１．ベースプロファイル
ベースプロファイルは主にルーフトップ（roof-top）アンテナと連結される固定された受信装置の主な用途を示す。ベースプロファイルはある場所に移動できるが、比較的停止した受信範疇に属する携帯用装置も含むことができる。ベースプロファイルの用途は若干の改善された実行によりハンドヘルド装置または車両用に拡張できるが、このような使用用途はベースプロファイル受信機動作では期待されない。
【００３４】
受信のターゲット信号対雑音比の範囲は略１０乃至２０ｄＢであるが、これは既存の放送システム（例えば、ＡＴＳＣ Ａ／５３）の１５ｄＢ信号対雑音比の受信能力を含む。受信機複雑度及び消費電力はハンドヘルドプロファイルを使用するバッテリーで駆動されるハンドヘルド装置ほど重要でない。ベースプロファイルに対する重要システムパラメータが以下の＜表１＞に記載されている。
【００３５】
【表１】
0006392463.tif 000002
【００３６】
２．ハンドヘルドプロファイル
ハンドヘルドプロファイルは、バッテリー電源で駆動されるハンドヘルド及び車両用装置における使用のために設計される。該当装置は歩行者または車両速度で移動することができる。受信機複雑度だけでなく、消費電力はハンドヘルドプロファイルの装置の具現のために非常に重要である。ハンドヘルドプロファイルのターゲット信号対雑音比の範囲は略０乃至１０ｄＢであるが、より低い室内受信のために意図された場合、０ｄＢ以下に達するように設定できる。
【００３７】
低信号対雑音比の能力だけでなく、受信機移動性により表れたドップラー効果に対する復原力はハンドヘルドプロファイルの最も重要な性能属性である。ハンドヘルドプロファイルに対する重要システムパラメータが以下の＜表２＞に記載されている。
【００３８】
【表２】
0006392463.tif 000003
【００３９】
３．アドバンスプロファイル
アドバンスプロファイルは、より大きい実行複雑度に対する代価としてより高いチャネル能力を提供する。該当プロファイルはＭＩＭＯ送信及び受信を使用することを要求し、ＵＨＤＴＶサービスはターゲット用途であり、このために該当プロファイルが特別に設計される。向上した能力は与えられた帯域幅でサービス数の増加、例えば、複数のＳＤＴＶまたはＨＤＴＶサービスを許容することにも使用できる。
【００４０】
アドバンスプロファイルのターゲット信号対雑音比の範囲は略２０乃至３０ｄＢである。ＭＩＭＯ送信は初期には既存の楕円分極送信装備を使用し、その後に全出力交差分極送信に拡張できる。アドバンスプロファイルに対する重要システムパラメータが以下の＜表３＞に記載されている。
【００４１】
【表３】
0006392463.tif 000004
【００４２】
この場合、ベースプロファイルは地上波放送サービス及びモバイル放送サービスの全てに対するプロファイルに使用できる。即ち、ベースプロファイルはモバイルプロファイルを含むプロファイルの概念を定義するために使用できる。また、アドバンスプロファイルはＭＩＭＯを有するベースプロファイルに対するアドバンスプロファイル及びＭＩＭＯを有するハンドヘルドプロファイルに対するアドバンスプロファイルに区分できる。そして、該当３個のプロファイルは設計者の意図によって変更できる。
【００４３】
次の用語及び定義は本発明に適用できる。次の用語及び定義は設計によって変更できる。
【００４４】
補助ストリーム：フューチャーエクステンション（future extension：今後拡張）または放送社やネットワーク運営者により要求されるにつれて、使用できる未だ定義されていない変調及びコーディングのデータを伝達するセルのシーケンス
【００４５】
ベースデータパイプ（base data pipe）：サービスシグナリングデータを伝達するデータパイプ
【００４６】
ベースバンドフレーム（または、BB FRAME）：１つのＦＥＣエンコーディング過程（ＢＣＨ及びＬＤＰＣエンコーディング）に対する入力を形成するＫｂｃｈビットの集合
【００４７】
セル（cell）：ＯＦＤＭ送信の１つのキャリアにより伝達される変調値
【００４８】
コーディングブロック（coded block）：ＰＬＳ１データのＬＤＰＣエンコーディングされたブロックまたはＰＬＳ２データのＬＤＰＣエンコーディングされたブロックのうちの１つ
【００４９】
データパイプ（data pipe）：１つまたは複数のサービスまたはサービスコンポーネントを伝達することができるサービスデータ、または関連したメタデータを伝達する物理階層（physical layer）におけるロジカルチャネル
【００５０】
また、データパイプは、データ送信チャネルで表現されることができる。
【００５１】
データパイプユニット（ＤＰＵ：data pipe unit）：データセルをフレームでのデータパイプに割り当てることができる基本ユニット
【００５２】
データシンボル（data symbol）：プリアンブルシンボルでないフレームでのＯＦＤＭシンボル（フレームシグナリングシンボル及びフレームエッジ（edge）シンボルはデータシンボルに含まれる。）
【００５３】
ＤＰ＿ＩＤ：該当８ビットフィールドはＳＹＳＴＥＭ＿ＩＤにより識別されたシステム内でデータパイプを唯一に識別する。
【００５４】
ダミーセル（dummy cell）：ＰＬＳ（physical layer signaling）シグナリング、データパイプ、または補助ストリームのために使われず残っている容量を詰めることに使用される疑似ランダム値を伝達するセル
【００５５】
ＦＡＣ（emergency alert channel：非常警報チャネル）：ＥＡＳ情報データを伝達するフレームのうちの一部
【００５６】
フレーム（frame）：プリアンブルで始めて、フレームエッジシンボルで終了する物理階層（physical layer）タイムスロット
【００５７】
フレームレピティションユニット（frame repetition unit：フレーム反復単位）：スーパーフレーム（super-frame）で８回反復されるＦＥＦを含む同一または異なるフィジカルプロファイルに属するフレームの集合
【００５８】
ＦＩＣ（fast information channel：高速情報チャネル）：サービスと該当ベースデータパイプとの間でのマッピング情報を伝達するフレームにおけるロジカルチャネル
【００５９】
ＦＥＣＢＬＯＣＫ：データパイプデータのＬＤＰＣエンコーディングされたビットの集合
【００６０】
ＦＦＴサイズ：基本周期Ｔのサイクルで表現されたアクティブシンボル周期Ｔｓと同一な特定モードに使用される名目上のＦＦＴサイズ
【００６１】
フレームシグナリングシンボル（frame signaling symbol）：ＰＬＳデータの一部を伝達する、ＦＦＴサイズ、ガードインターバル（guard interval）、及びスキャッタ（scattered）パイロットパターンの特定組合せにおけるフレームの開始で使用されるより高いパイロット密度を有するＯＦＤＭシンボル
【００６２】
フレームエッジシンボル（frame edge symbol）：ＦＦＴサイズ、ガードインターバル、及びスキャッタパイロットパターンの特定組合せにおけるフレームの端で使用される、より高いパイロット密度を有するＯＦＤＭシンボル
【００６３】
フレームグルーフ（frame-group）：スーパーフレームで同一のフィジカルプロファイルタイプを有する全てのフレームの集合
【００６４】
フューチャーエクステンションフレーム（future extention frame：今後拡張フレーム）：プリアンブルで始める、今後拡張に使用できるスーパーフレーム内で物理階層（physical layer）タイムスロット
【００６５】
フューチャーキャスト（future cast）ＵＴＢシステム：入力が１つ以上のＭＰＥＧ２−ＴＳまたはＩＰ（Internet protocol）または一般ストリームであり、出力がＲＦシグナルである提案された物理階層（physical layer）放送システム
【００６６】
インプットストリーム（input stream：入力ストリーム）：システムにより最終ユーザに伝達されるサービスの調和（ensemble）のためのデータのストリーム
【００６７】
ノーマル（normal）データシンボル：フレームシグナリングシンボル及びフレームエッジシンボルを除外したデータシンボル
【００６８】
フィジカルプロファイル（PHY profile）：該当する受信機が具現しなければならない全ての構造のサブセット
【００６９】
ＰＬＳ：ＰＬＳ１及びＰＬＳ２で構成された物理階層（physical layer）シグナリングデータ
【００７０】
ＰＬＳ１：ＰＬＳ２のデコーディングに必要とするパラメータだけでなく、システムに関する基本情報を伝達する固定されたサイズ、コーディング、変調を有するＦＳＳ（frame signaling symbol）に伝達されるＰＬＳデータの第１の集合
【００７１】
ＮＯＴＥ：ＰＬＳ１データはフレームグルーフのデュレーション（duration）の間一定である。
【００７２】
ＰＬＳ２：データパイプ及びシステムに関するより詳細なＰＬＳデータを伝達するＦＳＳに送信されるＰＬＳデータの第２の集合
【００７３】
ＰＬＳ２ダイナミック（dynamic：動的）データ：フレーム毎にダイナミック（dynamic：動的）に変化するＰＬＳ２データ
【００７４】
ＰＬＳ２スタティック（static：静的）データ：フレームグルーフのデュレーションの間スタティック（static：静的）なＰＬＳ２データ
【００７５】
プリアンブルシグナリングデータ（preamble signaling data）：プリアンブルシンボルにより伝達され、システムの基本モードを確認することに使用されるシグナリングデータ
【００７６】
プリアンブルシンボル（preamble symbol）：基本ＰＬＳデータを伝達し、フレームの開始に位置する固定された長さのパイロットシンボル
【００７７】
ＮＯＴＥ：プリアンブルシンボルは、システム信号、そのタイミング、周波数オフセット、及びＦＦＴサイズを検出するために高速初期バンドスキャンに主に使用される。
【００７８】
今後使用（future use）のためにリザーブド（reserved）：現在文書で定義されないが、今後に定義できる
【００７９】
スーパーフレーム（superframe）：８個のフレーム反復単位の集合
【００８０】
タイムインターリービングブロック（time interleaving block：TI block）：タイムインターリーバメモリの１つの用途に該当する、タイムインターリービングが実行されるセルの集合
【００８１】
タイムインターリービンググルーフ（time interleaving group：TI group）：整数、ダイナミック（dynamic：動的）に変化するＸＦＥＣＢＬＯＣＫの数からなる、特定データパイプに対するダイナミック（dynamic：動的）容量割当が実行される単位
【００８２】
ＮＯＴＥ：タイムインターリービンググルーフは１つのフレームに直接マッピングされるか、または複数のフレームにマッピングできる。タイムインターリービンググルーフは１つ以上のタイムインターリービングブロックを含むことができる。
【００８３】
タイプ１のデータパイプ（Type 1 DP）：全てのデータパイプがフレームにＴＤＭ（time division multiplexing）方式によりマッピングされるフレームのデータパイプ
【００８４】
タイプ２のデータパイプ（Type 2 DP）：全てのデータパイプがフレームにＦＤＭ方式によりマッピングされるフレームのデータパイプ
【００８５】
ＸＦＥＣＢＬＯＣＫ：１つのＬＤＰＣ ＦＥＣＢＬＯＣＫの全てのビットを伝達するＮｃｅｌｌｓセルの集合
【００８６】
図１は、本発明の一実施形態に係る次世代放送サービスに対する放送信号送信装置の構造を示す。
【００８７】
本発明の一実施形態に係る次世代放送サービスに対する放送信号送信装置は、インプットフォーマットブロック（Input Format block）１０００、ＢＩＣＭ（bit interleaved coding & modulation）ブロック１０１０、フレームビルディングブロック（Frame building block）１０２０、ＯＦＤＭ（orthogonal frequency division multiplexing）ジェネレーションブロック（OFDM generation block）１０３０、及びシグナリング生成ブロック１０４０を含むことができる。放送信号送信装置の各ブロックの動作について説明する。
【００８８】
ＩＰストリーム／パケット及びＭＰＥＧ２−ＴＳは主要入力フォーマットであり、他のストリームタイプは一般ストリームとして扱われる。これらデータ入力に追加で、管理情報が入力されて各入力ストリームに対する該当帯域幅のスケジューリング及び割当を制御する。１つまたは複数のＴＳストリーム、ＩＰストリーム、及び／又は一般ストリーム入力が同時に許容される。
【００８９】
インプットフォーマットブロック１０００は各々の入力ストリームを独立的なコーディング及び変調が適用される１つまたは複数のデータパイプにデマルチプレキシングすることができる。データパイプは堅固性（robustness）の制御のための基本単位であり、これはＱｏＳ（Quality of Service）に影響を及ぼす。１つまたは複数のサービスまたはサービスコンポーネントが１つのデータパイプにより伝達できる。インプットフォーマットブロック１０００の詳細な動作は後述する。
【００９０】
データパイプは１つまたは複数のサービスまたはサービスコンポーネントを伝達することができるサービスデータ、または関連メタデータを伝達する物理階層（physical layer）におけるロジカルチャネルである。
【００９１】
また、データパイプユニットは１つのフレームでデータセルをデータパイプに割り当てるための基本ユニットである。
【００９２】
インプットフォーマットブロック１０００で、パリティ（parity）データはエラー訂正のために追加され、エンコーディングされたビットストリームは複素数値コンステレーションシンボルにマッピングされる。該当シンボルは該当データパイプに使用される特定インターリービング深さに亘ってインターリービングされる。アドバンスプロファイルにおいて、ＢＩＣＭブロック１０１０でＭＩＭＯエンコーディングが実行され、追加データ経路がＭＩＭＯ送信のために出力に追加される。ＢＩＣＭブロック１０１０の詳細な動作は後述する。
【００９３】
図１のインプットフォーマットブロック（Input formatting）は、後述する図５０、図５１、及び図５２において提案された機能、過程、及び／又は方法を実現する。
【００９４】
フレームビルディングブロック１０２０は、１つのフレーム内で入力データパイプのデータセルをＯＦＤＭシンボルにマッピングすることができる。マッピング後、周波数領域ダイバーシティのために、特に周波数選択的フェーディングチャネルを防止するために、周波数インターリービングが用いられる。フレームビルディングブロック１０２０の詳細な動作は後述する。
【００９５】
プリアンブルを各フレームの開始に挿入した後、ＯＦＤＭジェネレーションブロック１０３０はサイクリックプレフィックス（cyclic prefix）をガードインターバルとして有する既存のＯＦＤＭ変調を適用することができる。アンテナスペースダイバーシティのために、分散された（distributed）ＭＩＳＯ方式が送信機に亘って適用される。また、ＰＡＰＲ（peak-to-average power ratio）方式が時間領域で実行される。柔軟なネットワーク方式のために、該当の提案は多様なＦＦＴサイズ、ガードインターバル長さ、該当パイロットパターンの集合を提供する。ＯＦＤＭジェネレーションブロック１０３０の詳細な動作は後述する。
【００９６】
シグナリング生成ブロック１０４０は、各機能ブロックの動作に使用される物理階層（physical layer）シグナリング情報を生成することができる。また、該当シグナリング情報は関心あるサービスが受信機側で適切に復旧されるように送信される。シグナリング生成ブロック１０４０の詳細な動作は後述する。
【００９７】
図２、図３、及び図４は、本発明の実施形態に係るインプットフォーマットブロック１０００を示す。各図面に対して説明する。
【００９８】
図２〜図４のインプットフォーマットブロック（Input formatting）は、後述する図５０、図５１、及び図５２において提案された機能、過程、及び／又は方法を実現する。
【００９９】
図２は、本発明の一実施形態に係るインプットフォーマットブロックを示す。図２は、入力信号が単一入力ストリーム（single input stream）の時のインプットフォーマットブロックを示す。
【０１００】
図２に図示されたインプットフォーマットブロックは、図１を参照して説明したインプットフォーマットブロック１０００の一実施形態に該当する。
【０１０１】
物理階層（physical layer）への入力は１つまたは複数のデータストリームで構成できる。各々のデータストリームは１つのデータパイプにより伝達される。モードアダプテーション（mode adaptation：モード適応）モジュールは入力されるデータストリームをＢＢＦ（baseband frame）のデータフィールドにスライスする。該当システムは３種類の入力データストリーム、即ちＭＰＥＧ２−ＴＳ、ＩＰ、ＧＳ（generic stream）をサポートする。ＭＰＥＧ２−ＴＳは第１のバイトが同期バイト（０×４７）である固定された長さ（１８８バイト）のパケットを特徴とする。ＩＰストリームはＩＰパケットヘッダ内でシグナリングされる可変長さＩＰデータグラムパケットで構成される。該当システムはＩＰストリームに対してＩＰｖ４とＩＰｖ６を全てサポートする。ＧＳはカプセル化パケットヘッダ内でシグナリングされる可変長さパケットまたは一定長さパケットで構成できる。
【０１０２】
（ａ）は信号データパイプに対するモードアダプテーション（mode adaptation：モード適応）ブロック２０００、及びストリームアダプテーション（stream adaptation：ストリーム適応）２０１０を示し、（ｂ）はＰＬＳデータを生成及び処理するためのＰＬＳ生成ブロック２０２０及びＰＬＳスクランブラー２０３０を示す。各ブロックの動作について説明する。
【０１０３】
入力ストリームスプリッタは、入力されたＴＳ、ＩＰ、ＧＳストリームを複数のサービスまたはサービスコンポーネント（オーディオ、ビデオなど）ストリームに分割する。モードアダプテーション（mode adaptation：モード適応）モジュール２０１０は、ＣＲＣエンコーダ、ＢＢ（baseband）フレームスライサー、及びＢＢフレームヘッダ挿入ブロックで構成される。
【０１０４】
ＣＲＣエンコーダは、ユーザパケット（user packet：ＵＰ）レベルでのエラー検出のための３種類のＣＲＣエンコーディング、即ちＣＲＣ−８、ＣＲＣ−１６、ＣＲＣ−３２を提供する。算出されたＣＲＣバイトはＵＰの後に添付される。ＣＲＣ−８はＴＳストリームに使われ、ＣＲＣ−３２はＩＰストリームに使用される。ＧＳストリームがＣＲＣエンコーディングを提供しなければ、提案されたＣＲＣエンコーディングが適用されなければならない。
【０１０５】
ＢＢフレームスライサーは、入力を内部ロジカルビットフォーマットにマッピングする。第１の受信ビットはＭＳＢと定義する。ＢＢフレームスライサーは、使用可能データフィールド容量と同一な数の入力ビットを割り当てる。ＢＢＦペイロードと同一な数の入力ビットを割り当てるために、ＵＰストリームがＢＢＦのデータフィールドに合うようにスライスされる。
【０１０６】
ＢＢフレームヘッダ挿入ブロックは、２バイトの固定された長さのＢＢＦヘッダをＢＢフレームの前に挿入することができる。ＢＢＦヘッダは、ＳＴＵＦＦＩ（１ビット）、ＳＹＮＣＤ（１３ビット）、及びＲＦＵ（２ビット）で構成される。固定された２バイトＢＢＦヘッダだけでなく、ＢＢＦは２バイトＢＢＦヘッダの端に拡張フィールド（１または３バイト）を有することができる。
【０１０７】
ストリームアダプテーション（stream adaptation：ストリーム適応）２０１０は、スタッフィング（stuffing）挿入ブロック及びＢＢスクランブラーで構成される。スタッフィング挿入ブロックは、スタッフィングフィールドをＢＢフレームのペイロードに挿入することができる。ストリームアダプテーション（stream adaptation：ストリーム適応）に対する入力データがＢＢフレームを詰めることに充分であれば、ＳＴＵＦＦＩは０に設定され、ＢＢＦはスタッフィングフィールドを有しない。でなければ、ＳＴＵＦＦＩは１に設定され、スタッフィングフィールドはＢＢＦヘッダの直後に挿入される。スタッフィングフィールドは、２バイトのスタッフィングフィールドヘッダ及び可変サイズのスタッフィングデータを含む。
【０１０８】
ＢＢスクランブラーは、エネルギー分散のために完全なＢＢＦをスクランブリングする。スクランブリングシーケンスは、ＢＢＦと同期化される。スクランブリングシーケンスは、フィードバックシフトレジスタにより生成される。
【０１０９】
ＰＬＳ生成ブロック２０２０は、ＰＬＳデータを生成することができる。ＰＬＳは、受信機でフィジカルレイヤ（physical layer）データパイプに接続できる手段を提供する。ＰＬＳデータは、ＰＬＳ１データ及びＰＬＳ２データで構成される。
【０１１０】
ＰＬＳ１データは、ＰＬＳ２データのデコーディングに必要とするパラメータだけでなく、システムに関する基本情報を伝達する固定されたサイズ、コーディング、変調を有するフレームからＦＳＳに伝達されるＰＬＳデータの第１の集合である。ＰＬＳ１データは、ＰＬＳ２データの受信及びデコーディングを可能にすることに要求されるパラメータを含む基本送信パラメータを提供する。また、ＰＬＳ１データはフレームグルーフのデュレーションの間一定である。
【０１１１】
ＰＬＳ２データは、データパイプ及びシステムに関するより詳しいＰＬＳデータを伝達するＦＳＳに送信されるＰＬＳデータの第２の集合である。ＰＬＳ２は、受信機が所望のデータパイプをデコーディングすることに充分の情報を提供するパラメータを含む。ＰＬＳ２シグナリングは、ＰＬＳ２スタティック（static：静的）データ（ＰＬＳ２−ＳＴＡＴデータ）及びＰＬＳ２ダイナミック（dynamic：動的）データ（ＰＬＳ２−ＤＹＮデータ）の２種類のパラメータでさらに構成される。ＰＬＳ２スタティック（static：静的）データは、フレームグルーフのデュレーションの間スタティック（static：静的）なＰＬＳ２データであり、ＰＬＳ２ダイナミック（dynamic：動的）データはフレーム毎にダイナミック（dynamic：動的）に変化するＰＬＳ２データである。
【０１１２】
ＰＬＳデータに対する詳細な内容は後述する。
【０１１３】
ＰＬＳスクランブラー２０３０は、エネルギー分散のために生成されたＰＬＳデータをスクランブリングすることができる。
【０１１４】
前述したブロックは省略されることもでき、類似または同一機能を有するブロックにより取り替えることもできる。
【０１１５】
図３は、本発明の他の一実施形態に係るインプットフォーマットブロックを示す。
【０１１６】
図３に図示されたインプットフォーマットブロックは、図１を参照して説明したインプットフォーマットブロック１０００の一実施形態に該当する。
【０１１７】
図３は、入力信号がマルチインプットストリーム（multi input stream：複数の入力ストリーム）に該当する場合、インプットフォーマットブロックのモードアダプテーション（mode adaptation：モード適応）ブロックを示す。
【０１１８】
マルチインプットストリーム（multi input stream：複数の入力ストリーム）を処理するためのインプットフォーマットブロックのモードアダプテーション（mode adaptation：モード適応）ブロックは、複数入力ストリームを独立的に処理することができる。
【０１１９】
図３を参照すると、マルチインプットストリーム（multi input stream：複数の入力ストリーム）を各々処理するためのモードアダプテーション（mode adaptation：モード適応）ブロックは、インプットストリームスプリッタ（input stream splitter）３０００、インプットストリームシンクロナイザー（input stream synchronizer）３０１０、コンペンセーティングディレイ（compensation delay：補償遅延）ブロック３０２０、ヌルパケットディリーションブロック（null packet deletion block）３０３０、ヘッダコンプレッションブロック（header compression block）３０４０、ＣＲＣエンコーダ（CRC encoder）３０５０、ＢＢフレームスライサー（BB frame slicer）３０６０、及びＢＢヘッダ挿入ブロック（BB header insertion block）３０７０を含むことができる。モードアダプテーション（mode adaptation：モード適応）ブロックの各ブロックに対して説明する。
【０１２０】
ＣＲＣエンコーダ３０５０、ＢＢフレームスライサー３０６０、及びＢＢヘッダ挿入ブロック３０７０の動作は、図２を参照して説明したＣＲＣエンコーダ、ＢＢフレームスライサー、及びＢＢヘッダ挿入ブロックの動作に該当するので、その説明は省略する。
【０１２１】
インプットストリームスプリッタ３０００は、入力されたＴＳ、ＩＰ、ＧＳストリームを複数のサービスまたはサービスコンポーネント（オーディオ、ビデオなど）ストリームに分割する。
【０１２２】
インプットストリームシンクロナイザー３０１０は、ＩＳＳＹと呼ばれることができる。ＩＳＳＹは如何なる入力データフォーマットに対してもＣＢＲ（constant bit rate）及び一定の終端間送信（end-to-end transmission）遅延を保証するに適した手段を提供することができる。ＩＳＳＹはＴＳを伝達する複数のデータパイプの場合に常に用いられ、ＧＳストリームを伝達する複数のデータパイプに選択的に用いられる。
【０１２３】
コンペンセーティングディレイ（compensation delay：補償遅延）ブロック３０２０は、受信機で追加のメモリを必要とせず、ＴＳパケット再結合メカニズムを許容するためにＩＳＳＹ情報の挿入に後続する分割されたＴＳパケットストリームを遅延させることができる。
【０１２４】
ヌルパケットディリーションブロック３０３０は、ＴＳ入力ストリームの場合のみに使用される。一部のＴＳ入力ストリームまたは分割されたＴＳストリームはＶＢＲ（variable bit-rate）サービスをＣＢＲ ＴＳストリームに収容するために存在する複数のヌルパケットを有することができる。この場合、不要な送信オーバーヘッドを避けるために、ヌルパケットは確認されて送信されないことがある。受信機で、除去されたヌルパケットは送信に挿入されたＤＮＰ（deleted null-packet：除去されたヌルパケット）カウンターを参照して元の存在していた正確な場所に再挿入できるので、ＣＢＲが保証され、タイムスタンプ（ＰＣＲ）更新の必要がなくなる。
【０１２５】
ヘッダコンプレッションブロック３０４０は、ＴＳまたはＩＰ入力ストリームに対する送信効率を増加させるためにパケットヘッダ圧縮を提供することができる。受信機はヘッダの特定部分に対する先験的な（a priori）情報を有することができるので、この知られた情報（known information）は送信機から削除できる。
【０１２６】
ＴＳに対し、受信機は同期バイト構成（０×４７）及びパケット長さ（１８８バイト）に関する先験的な情報を有することができる。入力されたＴＳが１つのＰＩＤのみを有するコンデンツを伝達すれば、即ち、１つのサービスコンポーネント（ビデオ、オーディオなど）、またはサービスサブコンポーネント（ＳＶＣベースレイヤ、ＳＶＣインヘンスメントレイヤ、ＭＶＣベースビュー、またはＭＶＣ依存ビュー）に対してのみ、ＴＳパケットヘッダ圧縮がＴＳに（選択的に）適用できる。ＴＳパケットヘッダ圧縮は入力ストリームがＩＰストリームの場合、選択的に使用される。前記ブロックは省略されるか、類似または同一機能を有するブロックに取り替えることができる。
【０１２７】
図４は、本発明の他の実施形態に係るインプットフォーマットブロックを示す。
【０１２８】
図４に図示されたインプットフォーマットブロックは、図１を参照して説明したインプットフォーマットブロック１０００の一実施形態に該当する。
【０１２９】
図４は、入力信号がマルチインプットストリーム（multi input stream：複数の入力ストリーム）に該当する場合、インプットフォーマットブロックのストリームアダプテーション（stream adaptation：ストリーム適応）ブロックを示す。
【０１３０】
図４を参照すると、マルチインプットストリーム（multi input stream：複数の入力ストリーム）を各々処理するためのモードアダプテーション（mode adaptation：モード適応）ブロックは、スケジューラー４０００、１−フレームディレイ（delay）ブロック４０１０、スタッフィング挿入ブロック４０２０、インバンド（In-band）シグナリングブロック４０３０、ＢＢフレームスクランブラー４０４０、ＰＬＳ生成ブロック４０５０、及びＰＬＳスクランブラー４０６０を含むことができる。ストリームアダプテーション（stream adaptation：ストリーム適応）ブロックの各ブロックに対して説明する。
【０１３１】
スタッフィング挿入ブロック４０２０、ＢＢフレームスクランブラー４０４０、ＰＬＳ生成ブロック４０５０、ＰＬＳスクランブラー４０６０の動作は、図２を参照して説明したスタッフィング挿入ブロック、ＢＢスクランブラー、ＰＬＳ生成ブロック、ＰＬＳスクランブラー４０６０の動作に該当するので、その説明は省略する。
【０１３２】
スケジューラー４０００は各データパイプのＦＥＣＢＬＯＣＫの量から全体フレームに亘って全体のセル割当を決定することができる。ＰＬＳ、ＥＡＣ、及びＦＩＣに対する割当を含んで、スケジューラーはフレームのＦＳＳのＰＬＳセルまたはインバンド（In-band）シグナリングに送信されるＰＬＳ２−ＤＹＮデータの値を生成する。ＦＥＣＢＬＯＣＫ、ＥＡＣ、ＦＩＣに対する詳細な内容は後述する。
【０１３３】
１−フレームディレイ（delay）ブロック４０１０は、次のフレームに関するスケジューリング情報がデータパイプに挿入されるインバンド（In-band）シグナリング情報に関する現フレームを通じて送信できるように入力データを１つの送信フレームだけ遅延させることができる。
【０１３４】
インバンド（In-band）シグナリングブロック４０３０は、ＰＬＳ２データの遅延されない部分をフレームのデータパイプに挿入することができる。
【０１３５】
前述したブロックは省略されるか、類似または同一機能を有するブロックに取り替えることができる。
【０１３６】
図５は、本発明の一実施形態に係るＢＩＣＭブロックを示す。
【０１３７】
図５に図示されたＢＩＣＭブロックは、図１を参照して説明したＢＩＣＭブロック１０１０の一実施形態に該当する。
【０１３８】
前述したように、本発明の一実施形態に係る次世代放送サービスに対する放送信号送信装置は、地上波放送サービス、モバイル放送サービス、ＵＨＤＴＶサービスなどを提供することができる。
【０１３９】
ＱｏＳが本発明の一実施形態に係る次世代放送サービスに対する放送信号送信装置により提供されるサービスの特性に依存するので、各々のサービスに該当するデータは互いに異なる方式により処理されなければならない。したがって、本発明の一実施形態に係るＢＩＣＭブロックは、ＳＩＳＯ、ＭＩＳＯ、ＭＩＭＯ方式を各々のデータ経路に該当するデータパイプに独立的に適用することによって、各データパイプを独立的に処理することができる。結果的に、本発明の一実施形態に係る次世代放送サービスに対する放送信号送信装置は、各々のデータパイプを介して送信される各サービスまたはサービスコンポーネントに対するＱｏＳを調節することができる。
【０１４０】
（ａ）はベースプロファイル及びハンドヘルドプロファイルにより共有されるＢＩＣＭブロックを示し、（ｂ）はアドバンスプロファイルのＢＩＣＭブロックを示す。
【０１４１】
ベースプロファイル及びハンドヘルドプロファイルにより共有されるＢＩＣＭブロック及びアドバンスプロファイルのＢＩＣＭブロックは、各々のデータパイプを処理するための複数の処理ブロックを含むことができる。
【０１４２】
ベースプロファイル及びハンドヘルドプロファイルに対するＢＩＣＭブロック及びアドバンスプロファイルに対するＢＩＣＭブロックの各々の処理ブロックに対して説明する。
【０１４３】
ベースプロファイル及びハンドヘルドプロファイルに対するＢＩＣＭブロックの処理ブロック５０００は、データＦＥＣエンコーダ５０１０、ビットインターリーバ５０２０、コンステレーションマッパー（mapper）５０３０、ＳＳＤ（signal space diversity）エンコーディングブロック５０４０、及びタイムインターリーバ５０５０を含むことができる。
【０１４４】
データＦＥＣエンコーダ５０１０は、外部コーディング（ＢＣＨ）及び内部コーディング（ＬＤＰＣ）を用いてＦＥＣＢＬＯＣＫ手続を生成するために入力ＢＢＦにＦＥＣエンコーディングを実行する。外部コーディング（ＢＣＨ）は選択的なコーディング方法である。データＦＥＣエンコーダ５０１０の具体的な動作に対しては後述する。
【０１４５】
ビットインターリーバ５０２０は、効率的に実現可能な構造を提供しながらデータＦＥＣエンコーダ５０１０の出力をインターリービングしてＬＤＰＣコード及び変調方式の組合せにより最適化された性能を達成することができる。ビットインターリーバ５０２０の具体的な動作に対しては後述する。
【０１４６】
コンステレーションマッパー５０３０は、ＱＰＳＫ、ＱＡＭ−１６、不均一ＱＡＭ（ＮＵＱ−６４、ＮＵＱ−２５６、ＮＵＱ−１０２４）、または不均一コンステレーション（ＮＵＣ−１６、ＮＵＣ−６４、ＮＵＣ−２５６、ＮＵＣ−１０２４）を用いてベース及びハンドヘルドプロファイルでビットインターリーバ５０２０からの各々のセルワードを変調するか、またはアドバンスプロファイルでセルワードデマルチプレクサ５０１０−１からのセルワードを変調してパワーが正規化されたコンステレーションポイントｅｌを提供することができる。該当コンステレーションマッピングは、データパイプに対してのみ適用される。ＮＵＱが任意の形態を有する一方、ＱＡＭ−１６及びＮＵＱは正四角形の形態を有することが観察される。各々のコンステレーションが９０度の倍数だけ回転されれば、回転されたコンステレーションは元のものと正確に重なる。回転対称特性によって実数及び虚数コンポーネントの容量及び平均パワーが互いに同一になる。ＮＵＱ及びＮＵＣは全て各コードレート（code rate）に対して特別に定義され、使用される特定の１つはＰＬＳ２データに保管されたパラメータＤＰ＿ＭＯＤによりシグナリングされる。
【０１４７】
ＳＳＤエンコーディングブロック５０４０は、２次元、３次元、４次元でセルをフリーコーディングして、難しいフェーディング条件で受信堅固性（robustness）を増加させることができる。
【０１４８】
タイムインターリーバ５０５０は、データパイプレベルで動作することができる。タイムインターリービングのパラメータは、各々のデータパイプに対して異なるように設定できる。タイムインターリーバ５０５０の具体的な動作に関しては後述する。
【０１４９】
アドバンスプロファイルに対するＢＩＣＭブロックの処理ブロック５０００−１は、データＦＥＣエンコーダ、ビットインターリーバ、コンステレーションマッパー、及びタイムインターリーバを含むことができる。
【０１５０】
但し、処理ブロック５０００−１はセルワードデマルチプレクサ５０１０−１及びＭＩＭＯエンコーディングブロック５０２０−１をさらに含むという点で処理ブロック５０００と区別される。
【０１５１】
また、処理ブロック５０００−１におけるデータＦＥＣエンコーダ、ビットインターリーバ、コンステレーションマッパー、タイムインターリーバの動作は、前述したデータＦＥＣエンコーダ５０１０、ビットインターリーバ５０２０、コンステレーションマッパー５０３０、タイムインターリーバ５０５０の動作に該当するので、その説明は省略する。
【０１５２】
セルワードデマルチプレクサ５０１０−１は、アドバンスプロファイルのデータパイプがＭＩＭＯ処理のために単一セルワードストリームを二重セルワードストリームに分離することに使用される。セルワードデマルチプレクサ５０１０−１の具体的な動作に関しては後述する。
【０１５３】
ＭＩＭＯエンコーディングブロック５０２０−１は、ＭＩＭＯエンコーディング方式を用いてセルワードデマルチプレクサ５０１０−１の出力を処理することができる。ＭＩＭＯエンコーディング方式は、放送信号送信のために最適化された。ＭＩＭＯ技術は、容量増加を得るための有望な方式であるが、チャネル特性に依存する。特別に放送に対して、互いに異なる信号伝搬特性による２アンテナの間の受信信号パワーの差、またはチャネルの強いＬＯＳコンポーネントはＭＩＭＯから容量利得を得ることを難しくする。提案されたＭＩＭＯエンコーディング方式は、ＭＩＭＯ出力信号のうちの１つの位相ランダム化及び回転基盤プリコーディングを用いてこの問題を克服する。
【０１５４】
ＭＩＭＯエンコーディングは、送信機及び受信機の全てで少なくとも２つのアンテナを必要とする２×２ＭＩＭＯシステムのために意図される。２つのＭＩＭＯエンコーディングモードは本提案であるＦＲ−ＳＭ（full-rate spatial multiplexing）及びＦＲＦＤ−ＳＭ（full-rate full-diversity spatial multiplexing）で定義される。ＦＲ−ＳＭエンコーディングは受信機側における比較的小さい複雑度増加により容量増加を提供する一方、ＦＲＦＤ−ＳＭエンコーディングは受信機側における大きい複雑度増加で容量増加及び追加的なダイバーシティ利得を提供する。提案されたＭＩＭＯエンコーディング方式はアンテナ極性配置を制限しない。
【０１５５】
ＭＩＭＯ処理はアドバンスプロファイルフレームに要求されるが、これはアドバンスプロファイルフレームにおける全てのデータパイプがＭＩＭＯエンコーダにより処理されることを意味する。ＭＩＭＯ処理はデータパイプレベルで適用される。コンステレーションマッパー出力のペア（pair：対）であるＮＵＱ（ｅ１，ｉ及びｅ２，ｉ）はＭＩＭＯエンコーダの入力により供給される。ＭＩＭＯエンコーダ出力ペア（pair：対）（ｇ１，ｉ及びｇ２，ｉ）は各々の送信アンテナの同一なキャリアｋ及びＯＦＤＭシンボルｌにより送信される。
【０１５６】
前述したブロックは省略されるか、類似または同一機能を有するブロックに取り替えることができる。
【０１５７】
図６は、本発明の他の実施形態に係るＢＩＣＭブロックを示す。
【０１５８】
図６に図示されたＢＩＣＭブロックは、図１を参照して説明したＢＩＣＭブロック１０１０の一実施形態に該当する。
【０１５９】
図６は、ＰＬＳ、ＥＡＣ、及びＦＩＣの保護のためのＢＩＣＭブロックを示す。ＥＡＣはＥＡＳ情報データを伝達するフレームの一部であり、ＦＩＣはサービスと該当するベースデータパイプとの間でマッピング情報を伝達するフレームにおけるロジカルチャネルである。ＥＡＣ及びＦＩＣに対する詳細な説明は後述する。
【０１６０】
図６を参照すると、ＰＬＳ、ＥＡＣ、及びＦＩＣの保護のためのＢＩＣＭブロックは、ＰＬＳ ＦＥＣエンコーダ６０００、ビットインターリーバ６０１０、及びコンステレーションマッパー６０２０を含むことができる。
【０１６１】
また、ＰＬＳ ＦＥＣエンコーダ６０００は、スクランブラー、ＢＣＨエンコーディング／ゼロ挿入ブロック、ＬＤＰＣエンコーディングブロック、及びＬＤＰＣパリティパンクチャリング（puncturing）ブロックを含むことができる。ＢＩＣＭブロックの各ブロックに対して説明する。
【０１６２】
ＰＬＳ ＦＥＣエンコーダ６０００は、スクランブリングされたＰＬＳ １／２データ、ＥＡＣ及びＦＩＣセクションをエンコーディングすることができる。
【０１６３】
スクランブラーは、ＢＣＨエンコーディング及びショートニング（shortening）及びパンクチャリングされたＬＤＰＣエンコーディングの前にＰＬＳ１データ及びＰＬＳ２データをスクランブリングすることができる。
【０１６４】
ＢＣＨエンコーディング／ゼロ挿入ブロックは、ＰＬＳ保護のためのショートニングされたＢＣＨコードを用いてスクランブリングされたＰＬＳ １／２データに外部エンコーディングを遂行し、ＢＣＨエンコーディングの後にゼロビットを挿入することができる。ＰＬＳ１データに対してのみゼロ挿入の出力ビットがＬＤＰＣエンコーディングの前にパーミュテーション（permutation）できる。
【０１６５】
ＬＤＰＣエンコーディングブロックは、ＬＤＰＣコードを用いてＢＣＨエンコーディング／ゼロ挿入ブロックの出力をエンコーディングすることができる。完全なコーディングブロックを生成するために、Ｃｌｄｐｃ及びパリティビットＰｌｄｐｃは各々のゼロが挿入されたＰＬＳ情報ブロックＩｌｄｐｃから組織的にエンコーディングされ、その後に添付される。
【０１６６】
【数１】
0006392463.tif 000005
【０１６７】
ＰＬＳ１及びＰＬＳ２に対するＬＤＰＣコードパラメータは、次の＜表４＞の通りである。
【０１６８】
【表４】
0006392463.tif 000006
【０１６９】
ＬＤＰＣパリティパンクチャリングブロックは、ＰＬＳ１データ及びＰＬＳ２データに対してパンクチャリングを遂行することができる。
【０１７０】
ショートニングがＰＬＳ１データ保護に適用されれば、一部のＬＤＰＣパリティビットはＬＤＰＣエンコーディングの後にパンクチャリングされる。また、ＰＬＳ２データ保護のために、ＰＬＳ２のＬＤＰＣパリティビットがＬＤＰＣエンコーディングの後にパンクチャリングされる。これらパンクチャリングされたビットは送信されない。
【０１７１】
ビットインターリーバ６０１０は、各々のショートニング及びパンクチャリングされたＰＬＳ１データ及びＰＬＳ２データをインターリービングすることができる。
【０１７２】
コンステレーションマッパー６０２０は、ビットインターリービングされたＰＬＳ１データ及びＰＬＳ２データをコンステレーションにマッピングすることができる。
【０１７３】
前述したブロックは省略されるか、類似または同一機能を有するブロックに取り替えることができる。
【０１７４】
図７は、本発明の一実施形態に係るフレームビルディングブロック（frame building block）を示す。
【０１７５】
図７に図示したフレームビルディングブロックは、図１を参照して説明したフレームビルディングブロック１０２０の一実施形態に該当する。
【０１７６】
図７を参照すると、フレームビルディングブロックは、ディレイコンペンセーション（delay compensation：遅延補償）ブロック７０００、セルマッパー（cell mapper）７０１０、及びフリークエンシーインターリーバ（frequency interleaver）７０２０を含むことができる。フレームビルディングブロックの各ブロックに関して説明する。
【０１７７】
ディレイコンペンセーション（delay compensation：遅延補償）ブロック７０００は、データパイプと該当するＰＬＳデータとの間のタイミングを調節して送信機側でデータパイプと該当するＰＬＳデータとの間の同時性（co-time）を保証することができる。インプットフォーマットブロック及びＢＩＣＭブロックによるデータパイプの遅延を扱うことによってＰＬＳデータはデータパイプだけ遅延される。ＢＩＣＭブロックの遅延は主にタイムインターリーバ５０５０によるものである。インバンド（In-band）シグナリングデータは、次のタイムインターリービンググルーフの情報をシグナリングされるデータパイプより１つのフレームの前に伝達されるようにすることができる。ディレイコンペンセーション（delay compensation：遅延補償）ブロックは、それに合せてインバンド（In-band）シグナリングデータを遅延させる。
【０１７８】
セルマッパー７０１０は、ＰＬＳ、ＥＡＣ、ＦＩＣ、データパイプ、補助ストリーム、及びダミーセルをフレーム内でＯＦＤＭシンボルのアクティブ（active）キャリアにマッピングすることができる。セルマッパー７０１０の基本機能は、各々のデータパイプ、ＰＬＳセル、及びＥＡＣ／ＦＩＣセルに対するタイムインターリービングにより生成されたデータセルを、存在していれば、１つのフレーム内で各々のＯＦＤＭシンボルに該当するアクティブ（active）ＯＦＤＭセルのアレイにマッピングするものである。（ＰＳＩ（program specific information）／ＳＩのような）サービスシグナリングデータは個別的に収集されてデータパイプにより送られることができる。セルマッパーはフレーム構造の構成及びスケジューラーにより生成されたダイナミックインフォメーション（dynamic information：動的情報）に従って動作する。フレームに関する詳細な内容は後述する。
【０１７９】
フリークエンシーインターリーバ７０２０は、セルマッパー７０１０から受信されたデータセルをランダムにインターリービングして周波数ダイバーシティを提供することができる。また、フリークエンシーインターリーバ７０２０は単一フレームで最大のインターリービング利得を得るために他のインターリービングシード（seed）の順序を用いて２つの順次的なＯＦＤＭシンボルで構成されたＯＦＤＭシンボルペア（pair：対）で動作することができる。
【０１８０】
前述したブロックは省略されるか、類似または同一機能を有するブロックに取り替えることができる。
【０１８１】
図８は、本発明の一実施形態に係るＯＦＤＭジェネレーションブロックを示す。
【０１８２】
図８に図示されたＯＦＤＭジェネレーションブロックは、図１を参照して説明したＯＦＤＭジェネレーションブロック１０３０の一実施形態に該当する。
【０１８３】
ＯＦＤＭジェネレーションブロックは、フレームビルディングブロックにより生成されたセルによりＯＦＤＭキャリアを変調し、パイロットを挿入し、送信のための時間領域信号を生成する。また、該当ブロックは順次的にガードインターバルを挿入し、ＰＡＰＲ減少処理を適用して最終のＲＦ信号を生成する。
【０１８４】
図８を参照すると、ＯＦＤＭジェネレーションブロックは、パイロット及びリザーブドトーン挿入ブロック（pilot and reserved tone insertion block）８０００、２Ｄ−ｅＳＦＮ（single frequency network）エンコーディングブロック８０１０、ＩＦＦＴ（inverse fast Fourier transform）ブロック８０２０、ＰＡＰＲ減少ブロック８０３０、ガードインターバル挿入ブロック（guard interval insertion block）８０４０、プリアンブル挿入ブロック（preamble insertion block）８０５０、その他のシステム挿入ブロック８０６０、及びＤＡＣブロック８０７０を含むことができる。ＯＦＤＭジェネレーションブロックの各ブロックに対して説明する。
【０１８５】
パイロット及びリザーブドトーン挿入ブロック８０００は、パイロット及びリザーブドトーンを挿入することができる。
【０１８６】
ＯＦＤＭシンボル内の多様なセルは受信機から先験的に知られた送信された値を有するパイロットとして知られた参照情報に変調される。パイロットセルの情報は、分散パイロット、連続パイロット、エッジパイロット、ＦＳＳ（frame signaling symbol）パイロット、及びＦＥＳ（frame edge symbol）パイロットで構成される。各パイロットは、パイロットタイプ及びパイロットパターンに従って特定増加パワーレベルで送信される。パイロット情報の値は与えられたシンボルで１つが各々の送信キャリアに対するものである一連の値に該当する参照シーケンスで誘導される。パイロットは、フレーム同期化、周波数同期化、時間同期化、チャネル推定、送信モード識別のために使用されることができ、また位相雑音を追跡するために使用できる。
【０１８７】
参照シーケンスから取った参照情報は、フレームのプリアンブル、ＦＳＳ及びＦＥＳを除外した全てのシンボルにおける分散パイロットセルで送信される。連続パイロットは、フレームの全てのシンボルに挿入される。連続パイロットの数及び位置はＦＦＴサイズ及び分散パイロットパターンに全て依存する。エッジキャリアは、プリアンブルシンボルを除外した全てのシンボル内のエッジパイロットと同一である。エッジキャリアは、スペクトルのエッジまで周波数インターポレーション（interpolation：補間）を許容するために挿入される。ＦＳＳパイロットはＦＳＳに挿入され、ＦＥＳパイロットはＦＥＳに挿入される。ＦＳＳパイロット及びＦＥＳパイロットはフレームのエッジまで時間インターポレーション（interpolation：補間）を許容するために挿入される。
【０１８８】
本発明の一実施形態に係るシステムは非常に堅い送信モードをサポートするために分散ＭＩＳＯ方式が選択的に使用されるＳＦＮをサポートする。２Ｄ−ｅＳＦＮは複数の送信アンテナを使用する分散ＭＩＳＯ方式であって、各アンテナはＳＦＮネットワークで各々異なる送信機に位置することができる。
【０１８９】
２Ｄ−ｅＳＦＮエンコーディングブロック８０１０は、ＳＦＮ構成で時間及び周波数ダイバーシティを生成するために２Ｄ−ｅＳＦＮ処理を行って複数の送信機から送信された信号の位相を歪曲させることがある。したがって、長時間の間の低い平面フェーディングまたは深いフェーディングによるバースト誤りが軽減できる。
【０１９０】
ＩＦＦＴブロック８０２０は、ＯＦＤＭ変調方式を用いて２Ｄ−ｅＳＦＮエンコーディングブロック８０１０からの出力を変調することができる。パイロット（または、リザーブドトーン）に指定されないデータシンボルでの全てのセルは、周波数インターリーバからのデータセルのうちの１つを伝達する。セルはＯＦＤＭキャリアにマッピングされる。
【０１９１】
ＰＡＰＲ減少ブロック８０３０は、時間領域で多様なＰＡＰＲ減少アルゴリズムを用いて入力信号にＰＡＰＲ減少を実行する。
【０１９２】
ガードインターバル挿入ブロック８０４０はガードインターバルを挿入することができ、プリアンブル挿入ブロック８０５０は信号の前にプリアンブルを挿入することができる。プリアンブルの構造に対する詳細な内容は後述する。
【０１９３】
その他のシステム挿入ブロック８０６０は、放送サービスを提供する２つ以上の互いに異なる放送送信／受信システムのデータが同一なＲＦ信号帯域で同時に送信できるように時間領域で複数の放送送信／受信システムの信号をマルチプレキシングすることができる。この場合、２つ以上の互いに異なる放送送信／受信システムは、互いに異なる放送サービスを提供するシステムをいう。互いに異なる放送サービスは、地上波放送サービス、モバイル放送サービスなどを意味することができる。各々の放送サービスに関連したデータは互いに異なるフレームを通じて送信できる。
【０１９４】
ＤＡＣブロック８０７０は、入力されたディジタル信号をアナログ信号に変換して出力することができる。ＤＡＣブロック８０７０から出力された信号は物理階層プロファイルによって複数の出力アンテナを介して送信できる。本発明の一実施形態に係る送信アンテナは垂直または水平極性を有することができる。
【０１９５】
前述したブロックは設計によって省略されるか、類似または同一機能を有するブロックに取替できる。
【０１９６】
図９は、本発明の一実施形態に係る次世代放送サービスに対する放送信号受信装置の構造を示す。
【０１９７】
本発明の一実施形態に係る次世代放送サービスに対する放送信号受信装置は、図１を参照して説明した次世代放送サービスに対する放送信号送信装置に対応することができる。
【０１９８】
本発明の一実施形態に係る次世代放送サービスに対する放送信号受信装置は、同期及び復調モジュール（synchronization & demodulation module）９０００、フレームパーシングモジュール（frame parsing module）９０１０、デマッピング及びデコーディングモジュール（demapping & decoding module）９０２０、出力プロセッサ（output processor）９０３０、及びシグナリングデコーディングモジュール（signaling decoding module）９０４０を含むことができる。放送信号受信装置の各モジュールの動作に対して説明する。
【０１９９】
同期及び復調モジュール９０００は、ｍ個の受信アンテナを介して入力信号を受信し、放送信号受信装置に該当するシステムに対して信号検出及び同期化を実行し、放送信号送信装置により実行される手続の逆過程に該当する復調を実行することができる。
【０２００】
フレームパーシングモジュール９０１０は、入力信号フレームをパーシングし、ユーザにより選択されたサービスが送信されるデータを抽出することができる。放送信号送信装置がインターリービングを実行すれば、フレームパーシングモジュール９０１０はインターリービングの逆過程に該当するデインターリービングを実行することができる。この場合、抽出されなければならない信号及びデータの位置がシグナリングデコーディングモジュール９０４０から出力されたデータをデコーディングすることにより取得されて、放送信号送信装置により生成されたスケジューリング情報が復元できる。
【０２０１】
デマッピング及びデコーディングモジュール９０２０は、入力信号をビット領域データに変換した後、必要によってビット領域データをデインターリービングすることができる。デマッピング及びデコーディングモジュール９０２０は、送信効率のために適用されたマッピングに対するデマッピングを実行し、デコーディングを通じて送信チャネルで発生したエラーを訂正することができる。この場合、デマッピング及びデコーディングモジュール９０２０はシグナリングデコーディングモジュール９０４０から出力されたデータをデコーディングすることによって、デマッピング及びデコーディングのために必要な送信パラメータを取得することができる。
【０２０２】
出力プロセッサ９０３０は、送信効率を向上させるために放送信号送信装置により適用される多様な圧縮／信号処理手続の逆過程を実行することができる。この場合、出力プロセッサ９０３０はシグナリングデコーディングモジュール９０４０から出力されたデータで必要とする制御情報を取得することができる。出力プロセッサ８３００の出力は、放送信号送信装置に入力される信号に該当し、ＭＰＥＧ−ＴＳ、ＩＰストリーム（ｖ４またはｖ６）及びＧＳでありうる。
【０２０３】
シグナリングデコーディングモジュール９０４０は、同期及び復調モジュール９０００により復調された信号からＰＬＳ情報を取得することができる。前述したように、フレームパーシングモジュール９０１０、デマッピング及びデコーディングモジュール９２００、及び出力プロセッサ９３００は、シグナリングデコーディングモジュール９０４０から出力されたデータを用いてその機能を実行することができる。
【０２０４】
図９の出力プロセッサ（Output Processor）は、後述する図５０、図５１、及び図５３において提案された機能、過程、及び／又は方法を実現する。
【０２０５】
図１０は、本発明の一実施形態に係るフレーム構造を示す。
【０２０６】
図１０は、フレームタイムの構成例及びスーパーフレームにおけるＦＲＵ（frame repetition unit：フレーム反復単位）を示す。（ａ）は本発明の一実施形態に係るスーパーフレームを示し、（ｂ）は本発明の一実施形態に係るＦＲＵを示し、（ｃ）はＦＲＵでの多様なフィジカルプロファイル（PHY profile）のフレームを示し、（ｄ）はフレームの構造を示す。
【０２０７】
スーパーフレームは８個のＦＲＵで構成できる。ＦＲＵはフレームのＴＤＭに対する基本マルチプレキシング単位であり、スーパーフレームで８回反復される。
【０２０８】
ＦＲＵで各フレームはフィジカルプロファイル（ベース、ハンドヘルド、アドバンスプロファイル）のうちの１つまたはＦＥＦに属する。ＦＲＵで、フレームの最大許容数は４であり、与えられたフィジカルプロファイルはＦＲＵで０回乃至４回のうちのいずれかの回数だけ表れることができる（例えば、ベース、ハンドヘルド、アドバンス）。フィジカルプロファイル定義は、必要時、プリアンブルにおけるＰHY_PROFILEのリザーブド値を用いて拡張できる。
【０２０９】
ＦＥＦ部分は、含まれれば、ＦＲＵの端に挿入される。ＦＥＦがＦＲＵに含まれる場合、ＦＥＦの最大数はスーパーフレームで８である。ＦＥＦ部分が互いに隣接することが推奨されない。
【０２１０】
１つのフレームは複数のＯＦＤＭシンボル及びプリアンブルにさらに分離される。（ｄ）に図示したように、フレームは、プリアンブル、１つ以上のＦＳＳ、ノーマルデータシンボル、及びＦＥＳを含む。
【０２１１】
プリアンブルは高速フューチャーキャストＵＴＢシステム信号検出を可能にし、信号の効率的な送信及び受信のための基本送信パラメータの集合を提供する特別なシンボルである。プリアンブルに対する詳細な内容は後述する。
【０２１２】
ＦＳＳの主な目的はＰＬＳデータを伝達するものである。高速同期化及びチャネル推定のために、これに従うＰＬＳデータの高速デコーディングのために、ＦＳＳはノーマルデータシンボルより高密度のパイロットパターンを有する。ＦＥＳはＦＳＳと完全に同一なパイロットを有するが、これはＦＥＳの直前のシンボルに対して外挿（extrapolation）無しでＦＥＳ内での周波数のみのインターポレーション（interpolation：補間）及び時間的補間（temporal interpolation）を可能にする。
【０２１３】
図１１は、本発明の一実施形態に係るフレームのシグナリング階層構造（signaling hierarchy structure）を示す。
【０２１４】
図１１はシグナリング階層構造を示すが、これは３個の主要部分であるプリアンブルシグナリングデータ１１０００、ＰＬＳ１データ１１０１０、及びＰＬＳ２データ１１０２０に分割される。毎フレーム毎にプリアンブル信号により伝達されるプリアンブルの目的は、フレームの基本送信パラメータ及び送信タイプを示すものである。ＰＬＳ１は、受信機が関心あるデータパイプに接続するためのパラメータを含むＰＬＳ２データに接続してデコーディングできるようにする。ＰＬＳ２は毎フレーム毎に伝達され、２つの主要部分であるＰＬＳ２−ＳＴＡＴデータとＰＬＳ２−ＤＹＮデータに分割される。ＰＬＳ２データのスタティック（static：静的）及びダイナミック（dynamic：動的）部分には、必要時、パッディングが後続する。
【０２１５】
図１２は、本発明の一実施形態に係るプリアンブルシグナリングデータを示す。
【０２１６】
プリアンブルシグナリングデータは、受信機がフレーム構造内でＰＬＳデータに接続し、データパイプを追跡できるようにするために必要とする２１ビットの情報を伝達する。プリアンブルシグナリングデータに対する詳細な内容は、次の通りである。
【０２１７】
ＰＨＹ＿ＰＲＯＦＩＬＥ：該当３ビットフィールドは現フレームのフィジカルプロファイルタイプを示す。互いに異なるフィジカルプロファイルタイプのマッピングは、以下の＜表５＞に与えられる。
【０２１８】
【表５】
0006392463.tif 000007
【０２１９】
ＦＦＴ＿ＳＩＺＥ：該当２ビットフィールドは以下の＜表６＞で説明した通り、フレームグルーフ内で現フレームのＦＦＴサイズを示す。
【０２２０】
【表６】
0006392463.tif 000008
【０２２１】
ＧＩ＿ＦＲＡＣＴＩＯＮ：該当３ビットフィールドは以下の＜表７＞で説明した通り、現スーパーフレームにおけるガードインターバルの一部（fraction）値を示す。
【０２２２】
【表７】
0006392463.tif 000009
【０２２３】
ＥＡＣ＿ＦＬＡＧ：該当１ビットフィールドはＥＡＣが現フレームに提供されるか否かを示す。該当フィールドが１に設定されれば、ＥＡＳが現フレームに提供される。該当フィールドが０に設定されれば、ＥＡＳが現フレームで伝達されない。該当フィールドはスーパーフレーム内でダイナミック（dynamic：動的）に転換できる。
【０２２４】
ＰＩＬＯＴ＿ＭＯＤＥ：該当１ビットフィールドは現フレームグルーフで現フレームに対してパイロットモードがモバイルモードであるか、または固定モードか否かを示す。該当フィールドが０に設定されれば、モバイルパイロットモードが使用される。該当フィールドが１に設定されれば、固定パイロットモードが使用される。
【０２２５】
ＰＡＰＲ＿ＦＬＡＧ：該当１ビットフィールドは現フレームグルーフで現フレームに対してＰＡＰＲ減少が使用されるか否かを示す。該当フィールドが１に設定されれば、トーン予約（tone reservation）がＰＡＰＲ減少のために使用される。該当フィールドが０に設定されれば、ＰＡＰＲ減少が使われない。
【０２２６】
ＦＲＵ＿ＣＯＮＦＩＧＵＲＥ：該当３ビットフィールドは現スーパーフレームで存在するＦＲＵのフィジカルプロファイルタイプ構成を示す。現スーパーフレームで全てのプリアンブルにおける該当フィールドで、現スーパーフレームで伝達される全てのプロファイルタイプが識別される。該当３ビットフィールドは以下の＜表８＞に示した通り、各々のプロファイルに対して異なるように定義される。
【０２２７】
【表８】
0006392463.tif 000010
【０２２８】
ＲＥＳＥＲＶＥＤ：該当７ビットフィールドは今後の使用のために予約（reserved）される。
【０２２９】
図１３は、本発明の一実施形態に係るＰＬＳ１データを示す。
【０２３０】
ＰＬＳ１データはＰＬＳ２の受信及びデコーディングを可能にするために必要なパラメータを含んだ基本送信パラメータを提供する。前述したように、ＰＬＳ１データは１つのフレームグルーフの全体デュレーションの間変化しない。ＰＬＳ１データのシグナリングフィールドの具体的な定義は、次の通りである。
【０２３１】
ＰＲＥＡＭＢＬＥ＿ＤＡＴＡ：該当２０ビットフィールドはＥＡＣ＿ＦＬＡＧを除外したプリアンブルシグナリングデータのコピーである。
【０２３２】
ＮＵＭ＿ＦＲＡＭＥ＿ＦＲＵ：該当２ビットフィールドはＦＲＵ当たりフレーム数を示す。
【０２３３】
ＰＡＹＬＯＡＤ＿ＴＹＰＥ：該当３ビットフィールドはフレームグルーフで伝達されるペイロードデータのフォーマットを示す。ＰＡＹＬＯＡＤ＿ＴＹＰＥは＜表９＞に示した通りシグナリングされる。
【０２３４】
【表９】
0006392463.tif 000011
【０２３５】
ＮＵＭ＿ＦＳＳ：該当２ビットフィールドは現フレームでＦＳＳの数を示す。
【０２３６】
ＳＹＳＴＥＭ＿ＶＥＲＳＩＯＮ：該当８ビットフィールドは送信される信号フォーマットのバージョンを示す。ＳＹＳＴＥＭ＿ＶＥＲＳＩＯＮは主バージョン及び副バージョンの２つの４ビットフィールドに分離される。
【０２３７】
主バージョン：ＳＹＳＴＥＭ＿ＶＥＲＳＩＯＮフィールドのＭＳＢである４ビットは主バージョン情報を示す。主バージョンフィールドでの変化は互換が不可能な変化を示す。デフォルト値は００００である。該当標準で叙述されたバージョンに対し、値が００００に設定される。
【０２３８】
副バージョン：ＳＹＳＴＥＭ＿ＶＥＲＳＩＯＮフィールドのＬＳＢである４ビットは副バージョン情報を示す。副バージョンフィールドでの変化は互換が可能である。
【０２３９】
ＣＥＬＬ＿ＩＤ：これはＡＴＳＣネットワークにおける地理的セルを唯一に識別する１６ビットフィールドである。ＡＴＳＣセルカバレッジはフューチャーキャストＵＴＢシステム当たり使用される周波数の数によって１つ以上の周波数で構成できる。ＣＥＬＬ＿ＩＤの値が知られていないか、特定されなければ、該当フィールドは０に設定される。
【０２４０】
ＮＥＴＷＯＲＫ＿ＩＤ：これは現ＡＴＳＣネットワークを唯一に識別する１６ビットフィールドである。
【０２４１】
ＳＹＳＴＥＭ＿ＩＤ：該当１６ビットフィールドはＡＴＳＣネットワーク内でフューチャーキャストＵＴＢシステムを唯一に識別する。フューチャーキャストＵＴＢシステムは入力が１つ以上の入力ストリーム（ＴＳ、ＩＰ、ＧＳ）であり、出力がＲＦ信号である地上波放送システムである。フューチャーキャストＵＴＢシステムは、存在していれば、ＦＥＦ及び１つ以上のフィジカルプロファイルを伝達する。同一なフューチャーキャストＵＴＢシステムは互いに異なる入力ストリームを伝達し、互いに異なる地理的領域で互いに異なるＲＦを使用することができるので、ローカルサービス挿入を許容する。フレーム構造及びスケジューリングは１つの場所で制御され、フューチャーキャストＵＴＢシステム内で全ての送信に対して同一である。１つ以上のフューチャーキャストＵＴＢシステムは全て同一なフィジカル構造及び構成を有するという同一なＳＹＳＴＥＭ＿ＩＤの意味を有することができる。
【０２４２】
次のループ（loop）は、各フレームタイプの長さ及びＦＲＵ構成を示すＦＲＵ＿ＰＨＹ＿ＰＲＯＦＩＬＥ、ＦＲＵ＿ＦＲＡＭＥ＿ＬＥＮＧＴＨ、ＦＲＵ＿ＧＩ＿ＦＲＡＣＴＩＯＮ、及びＲＥＳＥＲＶＥＤで構成される。ループ（loop）サイズはＦＲＵ内で４個のフィジカルプロファイル（ＦＥＦ含み）がシグナリングされるように固定される。ＮＵＭ＿ＦＲＡＭＥ＿ＦＲＵが４より小さければ、使われないフィールドはゼロで詰められる。
【０２４３】
ＦＲＵ＿ＰＨＹ＿ＰＲＯＦＩＬＥ：該当３ビットフィールドは関連したＦＲＵの（ｉ＋１）番目フレーム（ｉはループ（loop）インデックス）のフィジカルプロファイルタイプを示す。該当フィールドは＜表８＞に示したものと同一なシグナリングフォーマットを使用する。
【０２４４】
ＦＲＵ＿ＦＲＡＭＥ＿ＬＥＮＧＴＨ：該当２ビットフィールドは関連したＦＲＵの（ｉ＋１）番目フレームの長さを示す。ＦＲＵ＿ＧＩ＿ＦＲＡＣＴＩＯＮと共にＦＲＵ＿ＦＲＡＭＥ＿ＬＥＮＧＴＨを使用すれば、フレームデュレーションの正確な値が得られる。
【０２４５】
ＦＲＵ＿ＧＩ＿ＦＲＡＣＴＩＯＮ：該当３ビットフィールドは関連したＦＲＵの（ｉ＋１）番目フレームのガードインターバルの一部値を示す。ＦＲＵ＿ＧＩ＿ＦＲＡＣＴＩＯＮは＜表７＞に従ってシグナリングされる。
【０２４６】
ＲＥＳＥＲＶＥＤ：該当４ビットフィールドは今後の使用のために予約（reserved）される。
【０２４７】
次のフィールドは、ＰＬＳ２データをデコーディングするためのパラメータを提供する。
【０２４８】
ＰＬＳ２＿ＦＥＣ＿ＴＹＰＥ：該当２ビットフィールドはＰＬＳ２の保護により使用されるＦＥＣタイプを示す。ＦＥＣタイプは＜表１０＞に従ってシグナリングされる。ＬＤＰＣコードに対する詳細な内容は後述する。
【０２４９】
【表１０】
0006392463.tif 000012
【０２５０】
ＰＬＳ２＿ＭＯＤ：該当３ビットフィールドはＰＬＳ２により使用される変調タイプを示す。変調タイプは＜表１１＞に従ってシグナリングされる。
【０２５１】
【表１１】
0006392463.tif 000013
【０２５２】
ＰＬＳ２＿ＳＩＺＥ＿ＣＥＬＬ：該当１５ビットフィールドは現フレームグループで伝達されるＰＬＳ２に対する全てのコーディングブロックのサイズ（ＱＡＭセルの数に特定される）であるＣｔｏｔａｌ＿ｐａｒｔｉａｌ＿ｂｌｏｃｋを示す。該当値は現フレームグループの全体デュレーションの間一定である。
【０２５３】
ＰＬＳ２＿ＳＴＡＴ＿ＳＩＺＥ＿ＢＩＴ：該当１４ビットフィールドは現フレームグループに対するＰＬＳ２−ＳＴＡＴのサイズをビット数で示す。該当値は現フレームグループの全体デュレーションの間一定である。
【０２５４】
ＰＬＳ２＿ＤＹＮ＿ＳＩＺＥ＿ＢＩＴ：該当１４ビットフィールドは現フレームグループに対するＰＬＳ２−ＤＹＮのサイズをビット数で示す。該当値は現フレームグループの全体デュレーションの間一定である。
【０２５５】
ＰＬＳ２＿ＲＥＰ＿ＦＬＡＧ：該当１ビットフラグはＰＬＳ２反復モードが現フレームグループで使用されるか否かを示す。該当フィールドの値が１に設定されれば、ＰＬＳ２反復モードは活性化される。該当フィールドの値が０に設定されれば、ＰＬＳ２反復モードは不活性化される。
【０２５６】
ＰＬＳ２＿ＲＥＰ＿ＳＩＺＥ＿ＣＥＬＬ：該当１５ビットフィールドはＰＬＳ２反復が使用される場合、現フレームグループの毎フレーム毎に伝達されるＰＬＳ２に対する部分コーディングブロックのサイズ（ＱＡＭセルの数で特定される）であるＣｔｏｔａｌ＿ｐａｒｔｉａｌ＿ｂｌｏｃｋを示す。反復が使われない場合、該当フィールドの値は０と同一である。該当値は現フレームグループの全体デュレーションの間一定である。
【０２５７】
ＰＬＳ２＿ＮＥＸＴ＿ＦＥＣ＿ＴＹＰＥ：該当２ビットフィールドは次のフレームグループの毎フレームで伝達されるＰＬＳ２に使用されるＦＥＣタイプを示す。ＦＥＣタイプは＜表１０＞に従ってシグナリングされる。
【０２５８】
ＰＬＳ２＿ＮＥＸＴ＿ＭＯＤ：該当３ビットフィールドは次のフレームグループの毎フレームで伝達されるＰＬＳ２に使用される変調タイプを示す。変調タイプは＜表１１＞に従ってシグナリングされる。
【０２５９】
ＰＬＳ２＿ＮＥＸＴ＿ＲＥＰ＿ＦＬＡＧ：該当１ビットフラグはＰＬＳ２反復モードが次のフレームグループで使用されるか否かを示す。該当フィールドの値が１に設定されれば、ＰＬＳ２反復モードは活性化される。該当フィールドの値が０に設定されれば、ＰＬＳ２反復モードは非活性化される。
【０２６０】
ＰＬＳ２＿ＮＥＸＴ＿ＲＥＰ＿ＳＩＺＥ＿ＣＥＬＬ： 該当１５ビットフィールドはＰＬＳ２反復が使用される場合、次のフレームグループの毎フレーム毎に伝達されるＰＬＳ２に対する全体コーディングブロックのサイズ（ＱＡＭセルの数で特定される）であるＣｔｏｔａｌ＿ｆｕｌｌ＿ｂｌｏｃｋを示す。次のフレームグループで反復が使われない場合、該当フィールドの値は０と同一である。該当値は現フレームグループの全体デュレーションの間一定である。
【０２６１】
ＰＬＳ２＿ＮＥＸＴ＿ＲＥＰ＿ＳＴＡＴ＿ＳＩＺＥ＿ＢＩＴ：該当１４ビットフィールドは次のフレームグループに対するＰＬＳ２−ＳＴＡＴのサイズをビット数で示す。該当値は現フレームグループで一定である。
【０２６２】
ＰＬＳ２＿ＮＥＸＴ＿ＲＥＰ＿ＤＹＮ＿ＳＩＺＥ＿ＢＩＴ：該当１４ビットフィールドは次のフレームグループに対するＰＬＳ２−ＤＹＮのサイズをビット数で示す。該当値は現フレームグループで一定である。
【０２６３】
ＰＬＳ２＿ＡＰ＿ＭＯＤＥ：該当２ビットフィールドは現フレームグループでＰＬＳ２に対して追加パリティが提供されるか否かを示す。該当値は現フレームグループの全体デュレーションの間一定である。以下の＜表１２＞は該当フィールドの値を提供する。該当フィールドの値が００に設定されれば、現フレームグループで追加パリティがＰＬＳ２に対して使われない。
【０２６４】
【表１２】
0006392463.tif 000014
【０２６５】
ＰＬＳ２＿ＡＰ＿ＳＩＺＥ＿ＣＥＬＬ：該当１５ビットフィールドはＰＬＳ２の追加パリティビットのサイズ（ＱＡＭセルの数で特定される）を示す。該当値は現フレームグループの全体デュレーションの間一定である。
【０２６６】
ＰＬＳ２＿ＮＥＸＴ＿ＡＰ＿ＭＯＤＥ：該当２ビットフィールドは次のフレームグループの毎フレーム毎にＰＬＳ２シグナリングに対して追加パリティが提供されるか否かを示す。該当値は現フレームグループの全体デュレーションの間一定である。＜表１２＞は該当フィールドの値を定義する。
【０２６７】
ＰＬＳ２＿ＮＥＸＴ＿ＡＰ＿ＳＩＺＥ＿ＣＥＬＬ：該当１５ビットフィールドは次のフレームグループの毎フレーム毎にＰＬＳ２の追加パリティビットのサイズ（ＱＡＭセルの数で特定される）を示す。該当値は現フレームグループの全体デュレーションの間一定である。
【０２６８】
ＲＥＳＥＲＶＥＤ：該当３２ビットフィールドは今後の使用のために予約（reserved）される。
【０２６９】
ＣＲＣ＿３２：全体ＰＬＳ１シグナリングに適用される３２ビットエラー検出コード
【０２７０】
図１４は、本発明の一実施形態に係るＰＬＳ２データを示す。
【０２７１】
図１４は、ＰＬＳ２データのＰＬＳ２−ＳＴＡＴデータを示す。ＰＬＳ２−ＳＴＡＴデータはフレームグループ内で同一である一方、ＰＬＳ２−ＤＹＮデータは現フレームに対して特定の情報を提供する。
【０２７２】
ＰＬＳ２−ＳＴＡＴデータのフィールドに対し、次に具体的に説明する。
【０２７３】
ＦＩＣ＿ＦＬＡＧ：該当１ビットフィールドはＦＩＣが現フレームグループで使用されるか否かを示す。該当フィールドの値が１に設定されれば、ＦＩＣは現フレームで提供される。該当フィールドの値が０に設定されれば、ＦＩＣは現フレームで伝達されない。該当値は現フレームグループの全体デュレーションの間一定である。
【０２７４】
ＡＵＸ＿ＦＬＡＧ：該当１ビットフィールドは補助ストリームが現フレームグループで使用されるか否かを示す。該当フィールドの値が１に設定されれば、補助ストリームは現フレームで提供される。該当フィールドの値が０に設定されれば、補助フレームは現フレームで伝達されない。該当値は現フレームグループの全体デュレーションの間一定である。
【０２７５】
ＮＵＭ＿ＤＰ：該当６ビットフィールドは現フレーム内で伝達されるデータパイプの数を示す。該当フィールドの値は１から６４の間であり、データパイプの数はＮＵＭ＿ＤＰ＋１である。
【０２７６】
ＤＰ＿ＩＤ：該当６ビットフィールドはフィジカルプロファイル内で唯一に識別する。
【０２７７】
ＤＰ＿ＴＹＰＥ：該当３ビットフィールドはデータパイプのタイプを示す。これは、以下の＜表１３＞に従ってシグナリングされる。
【０２７８】
【表１３】
0006392463.tif 000015
【０２７９】
ＤＰ＿ＧＲＯＵＰ＿ＩＤ：該当８ビットフィールドは現データパイプが関連しているデータパイプグループを識別する。これは、受信機が同一なＤＰ＿ＧＲＯＵＰ＿ＩＤを有するようになる特定サービスと関連しているサービスコンポーネントのデータパイプに接続することに使用できる。
【０２８０】
ＢＡＳＥ＿ＤＰ＿ＩＤ：該当６ビットフィールドは管理階層で使用される（ＰＳＩ／ＳＩのような）サービスシグナリングデータを伝達するデータパイプを示す。ＢＡＳＥ＿ＤＰ＿ＩＤにより示すデータパイプは、サービスデータと共にサービスシグナリングデータを伝達するノーマルデータパイプであるか、またはサービスシグナリングデータのみを伝達する専用データパイプでありうる。
【０２８１】
ＤＰ＿ＦＥＣ＿ＴＹＰＥ：該当２ビットフィールドは関連したデータパイプにより使用されるＦＥＣタイプを示す。ＦＥＣタイプは、以下の＜表１４＞に従ってシグナリングされる。
【０２８２】
【表１４】
0006392463.tif 000016
【０２８３】
ＤＰ＿ＣＯＤ：該当４ビットフィールドは関連したデータパイプにより使用されるコードレート（code rate）を示す。コードレート（code rate）は以下の＜表１５＞に従ってシグナリングされる。
【０２８４】
【表１５】
0006392463.tif 000017
【０２８５】
ＤＰ＿ＭＯＤ：該当４ビットフィールドは関連したデータパイプにより使用される変調を示す。変調は以下の＜表１６＞に従ってシグナリングされる。
【０２８６】
【表１６】
0006392463.tif 000018
【０２８７】
ＤＰ_ＳＳＤ＿ＦＬＡＧ：該当１ビットフィールドはＳＳＤモードが関連したデータパイプで使用されるか否かを示す。該当フィールドの値が１に設定されれば、ＳＳＤは使用される。該当フィールドの値が０に設定されれば、ＳＳＤは使われない。
【０２８８】
次のフィールドはＰＨＹ＿ＰＲＯＦＩＬＥがアドバンスプロファイルを示す０１０と同じ時のみに表れる。
【０２８９】
ＤＰ＿ＭＩＭＯ：該当３ビットフィールドはどんなタイプのＭＩＭＯエンコーディング処理が関連したデータパイプに適用されるかを示す。ＭＩＭＯエンコーディング処理のタイプは、以下の＜表１７＞に従ってシグナリングされる。
【０２９０】
【表１７】
0006392463.tif 000019
【０２９１】
ＤＰ＿ＴＩ＿ＴＹＰＥ：該当１ビットフィールドはタイムインターリービングのタイプを示す。０の値は１つのタイムインターリービンググループが１つのフレームに該当し、１つ以上のタイムインターリービングブロックを含むことを示す。１の値は１つのタイムインターリービンググループが１つより多いフレームに伝達され、１つのタイムインターリービングブロックのみを含むことを示す。
【０２９２】
ＤＰ＿ＴＩ＿ＬＥＮＧＴＨ：該当２ビットフィールド（許容された値は１、２、４、８のみである）の使用は、次のようなＤＰ＿ＴＩ＿ＴＹＰＥフィールド内で設定される値により決定される。
【０２９３】
ＤＰ＿ＴＩ＿ＴＹＰＥの値が１に設定されれば、該当フィールドは各々のタイムインターリービンググループがマッピングされるフレームの数であるＰＩを示し、タイムインターリービンググループ当たり１つのタイムインターリービングブロックが存在する（ＮＴＩ＝１）。該当２ビットフィールドに許容されるＰＩの値は、以下の＜表１８＞に定義される。
【０２９４】
ＤＰ＿ＴＩ＿ＴＹＰＥの値が０に設定されれば、該当フィールドはタイムインターリービンググループ当たりタイムインターリービングブロックの数ＮＴＩを示し、フレーム当たり１つのタイムインターリービンググループが存在する（ＰＩ＝１）。該当２ビットフィールドに許容されるＰＩの値は以下の＜表１８＞に定義される。
【０２９５】
【表１８】
0006392463.tif 000020
【０２９６】
ＤＰ＿ＦＲＡＭＥ＿ＩＮＴＥＲＶＡＬ：該当２ビットフィールドは関連したデータパイプに対するフレームグループ内でフレーム間隔（ＩＪＵＭＰ）を示し、許容された値は１、２、４、８（該当する２ビットフィールドは各々００、０１、１０、１１）である。フレームグループの全てのフレームに表れないデータパイプに対し、該当フィールドの値は順次的なフレームの間の間隔と同一である。例えば、データパイプが１、５、９、１３などのフレームに表れれば、該当フィールドの値は４に設定される。全てのフレームに表れるデータパイプに対し、該当フィールドの値は１に設定される。
【０２９７】
ＤＰ＿ＴＩ＿ＢＹＰＡＳＳ：該当１ビットフィールドはタイムインターリーバ５０５０の使用可能性を決定する。データパイプに対してタイムインターリービングが使われないと、該当フィールド値は１に設定される。一方、タイムインターリービングが使われれば、該当フィールド値は０に設定される。
【０２９８】
ＤＰ＿ＦＩＲＳＴ＿ＦＲＡＭＥ＿ＩＤＸ：該当５ビットフィールドは現データパイプが発生するスーパーフレームの第１のフレームのインデックスを示す。ＤＰ＿ＦＩＲＳＴ＿ＦＲＡＭＥ＿ＩＤＸの値は０から３１の間である。
【０２９９】
ＤＰ＿ＮＵＭ＿ＢＬＯＣＫ＿ＭＡＸ：該当１０ビットフィールドは該当データパイプに対するＤＰ＿ＮＵＭ＿ＢＬＯＣＫＳの最大値を示す。該当フィールドの値はＤＰ＿ＮＵＭ＿ＢＬＯＣＫＳと同一な範囲を有する。
【０３００】
ＤＰ＿ＰＡＹＬＯＡＤ＿ＴＹＰＥ：該当２ビットフィールドは与えられたデータパイプにより伝達されるペイロードデータのタイプを示す。ＤＰ＿ＰＡＹＬＯＡＤ＿ＴＹＰＥは、以下の＜表１９＞に従ってシグナリングされる。
【０３０１】
【表１９】
0006392463.tif 000021
【０３０２】
ＤＰ＿ＩＮＢＡＮＤ＿ＭＯＤＥ：該当２ビットフィールドは現データパイプがインバンド（In-band）シグナリング情報を伝達するか否かを示す。インバンド（In-band）シグナリングタイプは、以下の＜表２０＞に従ってシグナリングされる。
【０３０３】
【表２０】
0006392463.tif 000022
【０３０４】
ＤＰ＿ＰＲＯＴＯＣＯＬ＿ＴＹＰＥ：該当２ビットフィールドは与えられたデータパイプにより伝達されるペイロードのプロトコルタイプを示す。ペイロードのプロトコルタイプは入力ペイロードタイプが選択されれば、以下の＜表２１＞に従ってシグナリングされる。
【０３０５】
【表２１】
0006392463.tif 000023
【０３０６】
ＤＰ＿ＣＲＣ＿ＭＯＤＥ：該当２ビットフィールドはＣＲＣエンコーディングがインプットフォーマットブロックで使用されるか否かを示す。ＣＲＣモードは、以下の＜表２２＞に従ってシグナリングされる。
【０３０７】
【表２２】
0006392463.tif 000024
【０３０８】
ＤＮＰ＿ＭＯＤＥ：該当２ビットフィールドはＤＰ＿ＰＡＹＬＯＡＤ＿ＴＹＰＥがＴＳ（‘００’）に設定される場合に関連したデータパイプにより使用されるヌルパケット削除モードを示す。ＤＮＰ＿ＭＯＤＥは、以下の＜表２３＞に従ってシグナリングされる。ＤＰ＿ＰＡＹＬＯＡＤ＿ＴＹＰＥがＴＳ（‘００’）でなければ、ＤＮＰ＿ＭＯＤＥは００の値に設定される。
【０３０９】
【表２３】
0006392463.tif 000025
【０３１０】
ＩＳＳＹ＿ＭＯＤＥ：該当２ビットフィールドはＤＰ＿ＰＡＹＬＯＡＤ＿ＴＹＰＥがＴＳ（‘００’）に設定される場合に関連したデータパイプにより使用されるＩＳＳＹモードを示す。ＩＳＳＹ＿ＭＯＤＥは、以下の＜表２４＞に従ってシグナリングされる。ＤＰ＿ＰＡＹＬＯＡＤ＿ＴＹＰＥがＴＳ（‘００’）でなければ、ＩＳＳＹ＿ＭＯＤＥは００の値に設定される。
【０３１１】
【表２４】
0006392463.tif 000026
【０３１２】
ＨＣ＿ＭＯＤＥ＿ＴＳ：該当２ビットフィールドはＤＰ＿ＰＡＹＬＯＡＤ＿ＴＹＰＥがＴＳ（‘００’）に設定される場合に関連したデータパイプにより使用されるＴＳヘッダ圧縮モードを示す。ＨＣ＿ＭＯＤＥ＿ＴＳは、以下の＜表２５＞に従ってシグナリングされる。
【０３１３】
【表２５】
0006392463.tif 000027
【０３１４】
ＨＣ＿ＭＯＤＥ＿ＩＰ：該当２ビットフィールドはＤＰ＿ＰＡＹＬＯＡＤ＿ＴＹＰＥがＩＰ（‘０１’）で設定される場合にＩＰヘッダ圧縮モードを示す。ＨＣ＿ＭＯＤＥ＿ＩＰは、以下の＜表２６＞に従ってシグナリングされる。
【０３１５】
【表２６】
0006392463.tif 000028
【０３１６】
ＰＩＤ：該当１３ビットフィールドはＤＰ＿ＰＡＹＬＯＡＤ＿ＴＹＰＥがＴＳ（‘００’）に設定され、ＨＣ＿ＭＯＤＥ＿ＴＳが０１または１０に設定される場合にＴＳヘッダ圧縮のためのＰＩＤ数を示す。
【０３１７】
ＲＥＳＥＲＶＥＤ：該当８ビットフィールドは今後の使用のためにリザーブド(予約）（reserved）される。
【０３１８】
次のフィールドは、ＦＩＣ＿ＦＬＡＧが１と同じ時のみに表れる。
【０３１９】
ＦＩＣ＿ＶＥＲＳＩＯＮ：該当８ビットフィールドはＦＩＣのバージョンナンバーを示す。
【０３２０】
ＦＩＣ＿ＬＥＮＧＴＨ＿ＢＹＴＥ：該当１３ビットフィールドはＦＩＣの長さをバイト単位で示す。
【０３２１】
ＲＥＳＥＲＶＥＤ：該当８ビットフィールドは今後の使用のためにリザーブド（reserved）される。
【０３２２】
次のフィールドは、ＡＵＸ＿ＦＬＡＧが１と同じ時のみに表れる。
【０３２３】
ＮＵＭ＿ＡＵＸ：該当４ビットフィールドは補助ストリームの数を示す。ゼロは補助ストリームが使われないことを示す。
【０３２４】
ＡＵＸ＿ＣＯＮＦＩＧ＿ＲＦＵ：該当８ビットフィールドは今後の使用のためにリザーブド（reserved）される。
【０３２５】
ＡＵＸ＿ＳＴＲＥＡＭ＿ＴＹＰＥ：該当４ビットは現補助ストリームのタイプを示すための今後の使用のためにリザーブド（reserved）される。
【０３２６】
ＡＵＸ＿ＰＲＩＶＡＴＥ＿ＣＯＮＦＩＧ：該当２８ビットフィールドは補助ストリームをシグナリングするための今後の使用のためにリザーブド（reserved）される。
【０３２７】
図１５は、本発明の他の一実施形態に係るＰＬＳ２データを示す。
【０３２８】
図１５は、ＰＬＳ２データのＰＬＳ２−ＤＹＮを示す。ＰＬＳ２−ＤＹＮデータの値は１つのフレームグループのデュレーションの間変化できる一方、フィールドのサイズは一定である。
【０３２９】
ＰＬＳ２−ＤＹＮデータのフィールドの具体的な内容は、次の通りである。
【０３３０】
ＦＲＡＭＥ＿ＩＮＤＥＸ：該当５ビットフィールドはスーパーフレーム内で現フレームのフレームインデックスを示す。スーパーフレームの第１のフレームのインデックスは０に設定される。
【０３３１】
ＰＬＳ＿ＣＨＡＮＧＥ＿ＣＯＵＮＴＥＲ：該当４ビットフィールドは構成が変化する前のスーパーフレームの数を示す。構成が変化する次のスーパーフレームは該当フィールド内でシグナリングされる値により示す。該当フィールドの値が００００に設定されれば、これは如何なる予定された変化も予測できないことを意味する。例えば、１の値は次のスーパーフレームに変化があるということを示す。
【０３３２】
ＦＩＣ＿ＣＨＡＮＧＥ＿ＣＯＵＮＴＥＲ：該当４ビットフィールドは構成（即ち、ＦＩＣのコンテンツ）が変化する前のスーパーフレームの数を示す。構成が変化する次のスーパーフレームは該当フィールド内でシグナリングされる値により示す。該当フィールドの値が００００に設定されれば、これは如何なる予定された変化も予測できないことを意味する。例えば、０００１の値は次のスーパーフレームに変化があることを示す。
【０３３３】
ＲＥＳＥＲＶＥＤ：該当１６ビットフィールドは今後の使用のためにリザーブド（reserved）される。
【０３３４】
次のフィールドは現フレームで伝達されるデータパイプと関連したパラメータを説明するＮＵＭ＿ＤＰでのループ（loop）に表れる。
【０３３５】
ＤＰ＿ＩＤ：該当６ビットフィールドはフィジカルプロファイル内でデータパイプを唯一に示す。
【０３３６】
ＤＰ＿ＳＴＡＲＴ：該当１５ビット（または、１３ビット）フィールドは、ＤＰＵアドレッシング（addressing）技法を使用してデータパイプの第１の開始位置を示す。ＤＰ＿ＳＴＡＲＴフィールドは、以下の＜表２７＞に示した通り、フィジカルプロファイル及びＦＦＴサイズによって異なる長さを有する。
【０３３７】
【表２７】
0006392463.tif 000029
【０３３８】
ＤＰ＿ＮＵＭ＿ＢＬＯＣＫ：該当１０ビットフィールドは現データパイプに対する現タイムインターリービンググループにおけるＦＥＣブロックの数を示す。ＤＰ＿ＮＵＭ＿ＢＬＯＣＫの値は０から１０２３の間にある。
【０３３９】
ＲＥＳＥＲＶＥＤ：該当８ビットフィールドは今後の使用のためにリザーブド（reserved）される。
【０３４０】
次のフィールドは、ＥＡＣと関連したＦＩＣパラメータを示す。
【０３４１】
ＥＡＣ＿ＦＬＡＧ：該当１ビットフィールドは現フレームでＥＡＣの存在を示す。該当ビットはプリアンブルにおけるＥＡＣ＿ＦＬＡＧと同一な値である。
【０３４２】
ＥＡＳ＿ＷＡＫＥ＿ＵＰ＿ＶＥＲＳＩＯＮ＿ＮＵＭ：該当８ビットフィールドは自動活性化指示のバージョンナンバーを示す。
【０３４３】
ＥＡＣ＿ＦＬＡＧフィールドが１と同一であれば、次の１２ビットがＥＡＣ＿ＬＥＮＧＴＨ＿ＢＹＴＥフィールドに割り当てられる。ＥＡＣ＿ＦＬＡＧフィールドが０と同一であれば、次の１２ビットがＥＡＣ＿ＣＯＵＮＴＥＲに割り当てられる。
【０３４４】
ＥＡＣ＿ＬＥＮＧＴＨ＿ＢＹＴＥ：該当１２ビットフィールドはＥＡＣの長さをバイトで示す。
【０３４５】
ＥＡＣ＿ＣＯＵＮＴＥＲ：該当１２ビットフィールドはＥＡＣが到達するフレームの前のフレームの数を示す。
【０３４６】
次のフィールドはＡＵＸ＿ＦＬＡＧフィールドが１と同一の場合のみに表れる。
【０３４７】
ＡＵＸ＿ＰＲＩＶＡＴＥ＿ＤＹＮ：該当４８ビットフィールドは補助ストリームをシグナリングするための今後の使用のためにリザーブド（reserved）される。該当フィールドの意味は、設定可能なＰＬＳ２−ＳＴＡＴでＡＵＸ＿ＳＴＲＥＡＭ＿ＴＹＰＥの値に依存する。
【０３４８】
ＣＲＣ＿３２：全体ＰＬＳ２に適用される３２ビットエラー検出コード。
【０３４９】
図１６は、本発明の一実施形態に係るフレームのロジカル（logical）構造を示す。
【０３５０】
前述したように、ＰＬＳ、ＥＡＣ、ＦＩＣ、データパイプ、補助ストリーム、ダミーセルは、フレームにおけるＯＦＤＭシンボルのアクティブ（active）キャリアにマッピングされる。ＰＬＳ１及びＰＬＳ２は、最初に１つ以上のＦＳＳにマッピングされる。その後、ＥＡＣが存在していれば、ＥＡＣセルは後続するＰＬＳフィールドにマッピングされる。次に、ＦＩＣが存在していれば、ＦＩＣセルがマッピングされる。データパイプはＰＬＳの次にマッピングされるか、ＥＡＣまたはＦＩＣが存在する場合、ＥＡＣまたはＦＩＣのその後にマッピングされる。タイプ１のデータパイプが最初にマッピングされ、タイプ２のデータパイプが次にマッピングされる。データパイプのタイプの具体的な内容は後述する。一部の場合、データパイプはＥＡＳに対する一部の特殊データまたはサービスシグナリングデータを伝達することができる。補助ストリームまたはストリームは、存在していれば、データパイプを次にマッピングされ、ここには順次にダミーセルが後続する。前述した順序、即ち、ＰＬＳ、ＥＡＣ、ＦＩＣ、データパイプ、補助ストリーム、及びダミーセルの順に全て共にマッピングすれば、フレームでセル容量を正確に詰める。
【０３５１】
図１７は、本発明の一実施形態に係るＰＬＳマッピングを示す。
【０３５２】
ＰＬＳセルは、ＦＳＳのアクティブ（active）キャリアにマッピングされる。ＰＬＳが占めるセルの数によって、１つ以上のシンボルがＦＳＳに指定され、ＦＳＳの数ＮＦＳＳはＰＬＳ１でのＮＵＭ＿ＦＳＳによりシグナリングされる。ＦＳＳはＰＬＳセルを伝達する特殊なシンボルである。堅固性及び遅延時間（latency）はＰＬＳで重大な事案であるので、ＦＳＳは高いパイロット密度を有しているので高速同期化及びＦＳＳ内での周波数のみのインターポレーション（interpolation：補間）を可能にする。
【０３５３】
ＰＬＳセルは、図１７の例に示すように、下向き式でＦＳＳのアクティブ（active）キャリアにマッピングされる。ＰＬＳ１セルは、最初に第１のＦＳＳの第１のセルからセルインデックスの昇順にマッピングされる。ＰＬＳ２セルはＰＬＳ１の最後のセルの直後に後続し、マッピングは第１のＦＳＳの最後のセルインデックスまで下方に続く。必要とするＰＬＳセルの総数が１つのＦＳＳのアクティブ（active）キャリアの数を超過すれば、マッピングは次のＦＳＳに進行され、第１のＦＳＳと完全に同一な方式により続く。
【０３５４】
ＰＬＳマッピングが完了した後、データパイプが次に伝達される。ＥＡＣ、ＦＩＣ、または両方とも現フレームに存在していれば、ＥＡＣ及びＦＩＣはＰＬＳとノーマルデータパイプとの間に配置される。
【０３５５】
図１８は、本発明の一実施形態に係るＥＡＣマッピングを示す。
【０３５６】
ＥＡＣはＥＡＳメッセージを伝達する専用チャネルであり、ＥＡＳに対するデータパイプに連結される。ＥＡＳサポートは提供されるが、ＥＡＣ自体は全てのフレームに存在することもあり、存在しないこともある。ＥＡＣが存在する場合、ＥＡＣはＰＬＳ２セルの直後にマッピングされる。ＰＬＳセルを除いて、ＦＩＣ、データパイプ、補助ストリーム、またはダミーセルのうち、いずれもＥＡＣの前に位置しない。ＥＡＣセルのマッピング手続はＰＬＳと完全に同一である。
【０３５７】
ＥＡＣセルは、図１８の例に示すように、ＰＬＳ２の次のセルからセルインデックスの昇順にマッピングされる。ＥＡＳメッセージの大きさによって、図１８に示すように、ＥＡＣセルは少ないシンボルを占めることができる。
【０３５８】
ＥＡＣセルは、ＰＬＳ２の最後のセルの直後に後続し、マッピングは最後のＦＳＳの最後のセルインデックスまで下方に続く。必要とするＥＡＣセルの総数が最後のＦＳＳの残っているアクティブ（active）キャリアの数を超過すれば、ＥＡＣマッピングは次のシンボルに進行され、ＦＳＳと完全に同一な方式により続く。この場合、ＥＡＣのマッピングがなされる次のシンボルはノーマルデータシンボルであり、これはＦＳＳより多いアクティブ（active）キャリアを有する。
【０３５９】
ＥＡＣマッピングが完了した後、存在していれば、ＦＩＣが次に伝達される。ＦＩＣが送信されなければ（ＰＬＳ２フィールドからシグナリングに）、データパイプがＥＡＣの最後のセルの直後に後続する。
【０３６０】
図１９は、本発明の一実施形態に係るＦＩＣマッピングを示す。
【０３６１】
（ａ）はＥＡＣ無しでＦＩＣセルのマッピングの例を示し、（ｂ）はＥＡＣと共にＦＩＣセルのマッピングの例を示す。
【０３６２】
ＦＩＣは、高速サービス取得及びチャネルスキャンを可能にするために階層間情報（cross-layer information）を伝達する専用チャネルである。該当情報は主にデータパイプの間のチャネルバインディング（channel binding）情報及び各放送社のサービスを含む。高速スキャンのために、受信機はＦＩＣをデコーディングし、放送社ＩＤ、サービス数、ＢＡＳＥ＿ＤＰ＿ＩＤのような情報を取得することができる。高速サービス取得のために、ＦＩＣだけでなく、ベースデータパイプもＢＡＳＥ＿ＤＰ＿ＩＤを用いてデコーディングできる。ベースデータパイプが送信するコンデンツを除いて、ベースデータパイプはノーマルデータパイプと正確に同一な方式によりエンコーディングされてフレームにマッピングされる。したがって、ベースデータパイプに対する追加説明が必要でない。ＦＩＣデータが生成されて管理階層で消費される。ＦＩＣデータのコンデンツは管理階層仕様に説明された通りである。
【０３６３】
ＦＩＣデータは選択的であり、ＦＩＣの使用はＰＬＳ２のスタティック（static：静的）な部分でＦＩＣ＿ＦＬＡＧパラメータによりシグナリングされる。ＦＩＣが使われれば、ＦＩＣ＿ＦＬＡＧは１に設定され、ＦＩＣに対するシグナリングフィールドはＰＬＳ２のスタティック（static：静的）な部分で定義される。該当フィールドでシグナリングされることはＦＩＣ＿ＶＥＲＳＩＯＮであり、ＦＩＣ＿ＬＥＮＧＴＨ＿ＢＹＴＥ＿ＦＩＣはＰＬＳ２と同一な変調、コーディング、タイムインターリービングパラメータを使用する。ＦＩＣは、ＰＬＳ２＿ＭＯＤ及びＰＬＳ２＿ＦＥＣのような同一なシグナリングパラメータを共有する。ＦＩＣデータは、存在していれば、ＰＬＳ２の後にマッピングされるか、またはＥＡＣが存在する場合、ＥＡＣの直後にマッピングされる。ノーマルデータパイプ、補助ストリーム、またはダミーセルのうち、いずれもＦＩＣの前に位置しない。ＦＩＣセルをマッピングする方法はＥＡＣと完全に同一であり、これはまたＰＬＳと同一である。
【０３６４】
ＰＬＳの後のＥＡＣが存在しない場合、ＦＩＣセルは（ａ）の例に示したように、ＰＬＳ２の次のセルからセルインデックスの昇順にマッピングされる。ＦＩＣデータサイズによって、（ｂ）に示したように、ＦＩＣセルは数個のシンボルに対してマッピングされる。
【０３６５】
ＦＩＣセルはＰＬＳ２の最後のセルの直後に後続し、マッピングは最後のＦＳＳの最後のセルインデックスまで下方に続く。必要なＦＩＣセルの総数が最後のＦＳＳの残っているアクティブ（active）キャリアの数を超過すれば、残りのＦＩＣセルのマッピングは次のシンボルに進行され、これはＦＳＳと完全に同一な方式により続く。この場合、ＦＩＣがマッピングされる次のシンボルはノーマルデータシンボルであり、これはＦＳＳより多いアクティブ（active）キャリアを有する。
【０３６６】
ＥＡＳメッセージが現フレームで送信されれば、ＥＡＣはＦＩＣより先にマッピングされ、（ｂ）に示したように、ＥＡＣの次のセルからＦＩＣセルはセルインデックスの昇順にマッピングされる。
【０３６７】
ＦＩＣマッピングが完了した後、１つ以上のデータパイプがマッピングされ、その後、存在していれば、補助ストリーム、ダミーセルが後続する。
【０３６８】
図２０は、本発明の一実施形態に係るデータパイプのタイプを示す。
【０３６９】
（ａ）はタイプ１のデータパイプを示し、（ｂ）はタイプ２のデータパイプを示す。
【０３７０】
先行するチャネル、即ちＰＬＳ、ＥＡＣ、ＦＩＣがマッピングされた後、データパイプのセルがマッピングされる。データパイプはマッピング方法によって２タイプのうちの１つに分類される。
【０３７１】
タイプ１のデータパイプ：データパイプがＴＤＭによりマッピングされる。
【０３７２】
タイプ２のデータパイプ：データパイプがＦＤＭによりマッピングされる。
【０３７３】
データパイプのタイプはＰＬＳ２のスタティック（static：静的）な部分でＤＰ＿ＴＹＰＥフィールドにより示す。図２０は、タイプ１のデータパイプ及びタイプ２のデータパイプのマッピング順序を示す。タイプ１のデータパイプは、まずセルインデックスの昇順にマッピングされた後、最後のセルインデックスに到達した後、シンボルインデックスが１ずつ増加する。次のシンボル内で、データパイプはｐ＝０を手始めにセルインデックスの昇順に続けてマッピングされる。１つのフレームで共にマッピングされる複数のデータパイプと共に、各々のタイプ１のデータパイプはデータパイプのＴＤＭと類似するように時間にグルーピングされる。
【０３７４】
タイプ２のデータパイプは、まずシンボルインデックスの昇順にマッピングされ、フレームの最後のＯＦＤＭシンボルに到達した後、セルインデックスは１ずつ増加し、シンボルインデックスは第１の使用可能シンボルに戻った後、そのシンボルインデックスから増加する。１つのフレームで複数のデータパイプをマッピングした後、各々のタイプ２のデータパイプはデータパイプのＦＤＭと類似するように周波数にグルーピングされる。
【０３７５】
タイプ１のデータパイプ及びタイプ２のデータパイプは、必要な時、フレームで共存できるが、タイプ１のデータパイプが常にタイプ２のデータパイプに先行するという制限がある。タイプ１及びタイプ２のデータパイプを伝達するＯＦＤＭセルの総数はデータパイプの送信に使用することができるＯＦＤＭセルの総数を超過できない。
【０３７６】
【数２】
0006392463.tif 000030
【０３７７】
この際、ＤＤＰ１はタイプ１のデータパイプが占めるＯＦＤＭセルの数に該当し、ＤＤＰ２はタイプ２のデータパイプが占めるセルの数に該当する。ＰＬＳ、ＥＡＣ、ＦＩＣが全てタイプ１のデータパイプと同様の方式によりマッピングされるので、ＰＬＳ、ＥＡＣ、ＦＩＣは全て“タイプ１のマッピング規則”に従う。したがって、概してタイプ１のマッピングが常にタイプ２のマッピングに先行する。
【０３７８】
図２１は、本発明の一実施形態に係るデータパイプマッピングを示す。
【０３７９】
（ａ）はタイプ１のデータパイプをマッピングするためのＯＦＤＭセルのアドレッシングを示し、（ｂ）はタイプ２のデータパイプをマッピングするためのＯＦＤＭセルのアドレッシングを示す。
【０３８０】
タイプ１のデータパイプ（０，．．．，ＤＤＰ１−１）をマッピングするためのＯＦＤＭセルのアドレッシングはタイプ１のデータパイプのアクティブ（active）データセルに対して定義される。アドレッシング方式は各々のタイプ１のデータパイプに対するタイムインターリービングからのセルがアクティブ（active）データセルに割り当てられる順序を定義する。また、アドレッシング方式はＰＬＳ２のダイナミック（dynamic：動的）部分でデータパイプの位置をシグナリングすることに使用される。
【０３８１】
ＥＡＣ及びＦＩＣ無しで、アドレス０は最後のＦＳＳでＰＬＳを伝達する最後のセルに後続するセルをいう。ＥＡＣが送信され、ＦＩＣが該当するフレームになければ、アドレス０はＥＡＣを伝達する最後のセルに後続するセルをいう。ＦＩＣが該当するフレームで送信されれば、アドレス０はＦＩＣを伝達する最後のセルに後続するセルをいう。タイプ１のデータパイプに対するアドレス０は（ａ）に示したような２つの互いに異なる場合を考慮して算出できる。（ａ）の例で、ＰＬＳ、ＥＡＣ、ＦＩＣは全て送信されると仮定する。ＥＡＣとＦＩＣのうちの１つまたは全てが省略される場合への拡張は自明である。（ａ）の左側に示したように、ＦＩＣまで全てのセルをマッピングした後、ＦＳＳに残っているセルがあれば、タイプ２のデータパイプ（０，．．．，ＤＤＰ２−１）をマッピングするためのＯＦＤＭセルのアドレッシングはタイプ２のデータパイプのアクティブ（active）データセルに対して定義される。アドレッシング方式は各々のタイプ２のデータパイプに対するタイムインターリービングからのセルがアクティブ（active）データセルに割り当てられる順序を定義する。また、アドレッシング方式はＰＬＳ２のダイナミック（dynamic：動的）部分でデータパイプの位置をシグナリングすることに使用される。
【０３８２】
（ｂ）に示すように、３種類の若干異なる場合が可能である。（ｂ）の左側に示した第１の場合に、最後のＦＳＳにあるセルはタイプ２のデータパイプマッピングに使用できる。中央に示した第２の場合に、ＦＩＣはノーマルシンボルのセルを占めるが、該当シンボルでのＦＩＣセルの数はＣＦＳＳより大きくない。（ｂ）の右側に示した第３の場合は該当シンボルにマッピングされたＦＩＣセルの数がＣＦＳＳを超過する点を除いて、第２の場合と同一である。
【０３８３】
ＰＬＳ、ＥＡＣ、ＦＩＣがタイプ１のデータパイプと同一な“タイプ１のマッピング規則”に従うので、タイプ１のデータパイプがタイプ２のデータパイプに先行する場合への拡張は自明である。
【０３８４】
データパイプユニット（ＤＰＵ）は、フレームにおけるデータセルをデータパイプに割り当てる基本単位である。
【０３８５】
ＤＰＵはフレームにおけるデータパイプの位置を探し出すためのシグナリング単位として定義される。セルマッパー７０１０は、各々のデータパイプに対してタイムインターリービングにより生成されたセルをマッピングすることができる。タイムインターリーバ５０５０は一連のタイムインターリービングブロックを出力し、各々のタイムインターリービングブロックはＸＦＥＣＢＬＯＣＫの可変数を含み、これは結局、セルの集合で構成される。ＸＦＥＣＢＬＯＣＫにおけるセルの数ＮｃｅｌｌｓはＦＥＣＢＬＯＣＫサイズ、Ｎｌｄｐｃ、コンステレーションシンボル当たり送信されるビット数に依存する。ＤＰＵは与えられたフィジカルプロファイルでサポートされるＸＦＥＣＢＬＯＣＫにおけるセルの数Ｎｃｅｌｌｓの全ての可能な値の最大公約数として定義される。セルでのＤＰＵの長さはＬＤＰＵとして定義される。各々のフィジカルプロファイルはＦＥＣＢＬＯＣＫサイズの互いに異なる組合せ及びコンステレーションシンボル当たり異なるビット数をサポートするので、ＬＤＰＵはフィジカルプロファイルに基づいて定義される。
【０３８６】
図２２は、本発明の一実施形態に係るＦＥＣ構造を示す。
【０３８７】
図２２は、ビットインターリービングの前の本発明の一実施形態に係るＦＥＣ構造を示す。前述したように、データＦＥＣエンコーダは外部コーディング（ＢＣＨ）及び内部コーディング（ＬＤＰＣ）を用いてＦＥＣＢＬＯＣＫ手続を生成するために入力ＢＢＦにＦＥＣエンコーディングを実行することができる。図示されたＦＥＣ構造はＦＥＣＢＬＯＣＫに該当する。また、ＦＥＣＢＬＯＣＫ及びＦＥＣ構造はＬＤＰＣコードワードの長さに該当する同一な値を有する。
【０３８８】
図２２に示すように、ＢＣＨエンコーディングが各々のＢＢＦ（Ｋｂｃｈビット）に適用された後、ＬＤＰＣエンコーディングがＢＣＨ−エンコーディングされたＢＢＦ（Ｋｌｄｐｃビット＝Ｎｂｃｈビット）に適用される。
【０３８９】
Ｎｌｄｐｃの値は６４８００ビット（ロングＦＥＣＢＬＯＣＫ）または１６２００ビット（ショートＦＥＣＢＬＯＣＫ）である。
【０３９０】
以下の＜表２８＞及び＜表２９＞はロングＦＥＣＢＬＯＣＫ及びショートＦＥＣＢＬＯＣＫの各々に対するＦＥＣエンコーディングパラメータを示す。
【０３９１】
【表２８】
0006392463.tif 000031
【０３９２】
【表２９】
0006392463.tif 000032
【０３９３】
ＢＣＨエンコーディング及びＬＤＰＣエンコーディングの具体的な動作は、次の通りである。
【０３９４】
１２−エラー訂正ＢＣＨコードがＢＢＦの外部エンコーディングに使用される。ショートＦＥＣＢＬＯＣＫ及びロングＦＥＣＢＬＯＣＫに対するＢＢＦ生成多項式は全ての多項式を掛けることによって得られる。
【０３９５】
ＬＤＰＣコードは外部ＢＣＨエンコーディングの出力をエンコーディングすることに使用される。完成されたＢｌｄｐｃ（ＦＥＣＢＬＯＣＫ）を生成するために、Ｐｌｄｐｃ（パリティビット）が各々のＩｌｄｐｃ（ＢＣＨ−エンコーディングされたＢＢＦ）から組織的にエンコーディングされ、Ｉｌｄｐｃに添付される。完成されたＢｌｄｐｃ（ＦＥＣＢＬＯＣＫ）は次の数式で表現される。
【０３９６】
【数３】
0006392463.tif 000033
【０３９７】
ロングＦＥＣＢＬＯＣＫ及びショートＦＥＣＢＬＯＣＫに対するパラメータは前記の＜表２８＞及び＜表２９＞に各々与えられる。
【０３９８】
ロングＦＥＣＢＬＯＣＫに対してＮｌｄｐｃ−Ｋｌｄｐｃパリティビットを計算する具体的な手続は、次の通りである。
【０３９９】
１）パリティビット初期化
【０４００】
【数４】
0006392463.tif 000034
【０４０１】
２）パリティーチェックマトリックスのアドレスの第１の行で特定されたパリティビットアドレスで第１の情報ビットｉＯ累算（accumulate）。パリティーチェックマトリックスのアドレスの詳細な内容は後述する。例えば、割合１３／１５に対し、
【０４０２】
【数５】
0006392463.tif 000035
【０４０３】
３）次の３５９個の情報ビットｉｓ、ｓ＝１，２，．．．，３５９に対し、次の数式を用いてパリティビットアドレスでｉｓ累算（accumulate）。
【０４０４】
【数６】
0006392463.tif 000036
【０４０５】
ここで、ｘは第１のビットｉ０に該当するパリティビット累算器のアドレスを示し、Ｑｌｄｐｃはパリティーチェックマトリックスのアドレッサで特定されたコードレート（code rate）依存定数である。前記の例である、割合１３／１５に対する、したがって情報ビットｉ１に対するＱｌｄｐｃ＝２４に引続き、次の動作が実行される。
【０４０６】
【数７】
0006392463.tif 000037
【０４０７】
４）３６１番目の情報ビットｉ３６０に対し、パリティビット累算器のアドレスはパリティーチェックマトリックスのアドレスの第２の行に与えられる。同様の方式により、次の３５９個の情報ビットｉｓ、ｓ＝３６１，３６２，．．．，７１９に対するパリティビット累算器のアドレスは＜数式６＞を用いて得られる。ここで、ｘは情報ビットｉ３６０に該当するパリティビット累算器のアドレス、即ちパリティーチェックマトリックスの第２の行のエントリーを示す。
【０４０８】
５）同様の方式で、３６０個の新たな情報ビットの全てのグループに対し、パリティーチェックマトリックスのアドレスからの新たな行はパリティビット累算器のアドレスを求めることに使用される。
【０４０９】
全ての情報ビットが用いられた後、最終パリティビットが次の通り得られる。
【０４１０】
６）ｉ＝１から始めて次の動作を順次に実行
【０４１１】
【数８】
0006392463.tif 000038
【０４１２】
ここで、ｐｉ、ｉ＝０，１，．．．，Ｎｌｄｐｃ−Ｋｌｄｐｃ−１の最終コンデンツはパリティビットｐｉと同一である。
【０４１３】
【表３０】
0006392463.tif 000039
【０４１４】
＜表３０＞を＜表３１＞に取り替えて、ロングＦＥＣＢＬＯＣＫに対するパリティーチェックマトリックスのアドレスをショートＦＥＣＢＬＯＣＫに対するパリティーチェックマトリックスのアドレスに取り替えることを除いて、ショートＦＥＣＢＬＯＣＫに対する該当ＬＤＰＣエンコーディング手続はロングＦＥＣＢＬＯＣＫに対するtＬＤＰＣエンコーディング手続に従う。
【０４１５】
【表３１】
0006392463.tif 000040
【０４１６】
図２３は、本発明の一実施形態に係るビットインターリービングを示す。
【０４１７】
ＬＤＰＣエンコーダの出力はビットインターリービングされるが、これはＱＣＢ（quasi-cyclic block）インターリービング及び内部グループインターリービングが後続するパリティインターリービングで構成される。
【０４１８】
（ａ）はＱＣＢインターリービングを示し、（ｂ）は内部グループインターリービングを示す。
【０４１９】
ＦＥＣＢＬＯＣＫはパリティインターリービングできる。パリティインターリービングの出力で、ＬＤＰＣコードワードはロングＦＥＣＢＬＯＣＫで１８０個の隣接するＱＣＢで構成され、ショートＦＥＣＢＬＯＣＫで４５個の隣接するＱＣＢで構成される。ロングまたはショートＦＥＣＢＬＯＣＫにおける各々のＱＣＢは３６０ビットで構成される。パリティインターリービングされたＬＤＰＣコードワードはＱＣＢインターリービングによりインターリービングされる。ＱＣＢインターリービングの単位はＱＣＢである。パリティインターリービングの出力でのＱＣＢは、図２３に示すように、ＱＣＢインターリービングによりパーミュテーションされるが、ここで、ＦＥＣＢＬＯＣＫ長さによってＮｃｅｌｌｓ＝６４８００／ηＭＯＤまたは１６２００／ηＭＯＤである。ＱＣＢインターリービングパターンは変調タイプ及びＬＤＰＣコードレート（code rate）の各組合せに固有である。
【０４２０】
ＱＣＢインターリービングの後に、内部グループインターリービングが以下の＜表３２＞に定義された変調タイプ及び次数（ηＭＯＤ）によって実行される。１つの内部グループに対するＱＣＢの数ＮＱＣＢ＿ＩＧも定義される。
【０４２１】
【表３２】
0006392463.tif 000041
【０４２２】
内部グループインターリービング過程はＱＣＢインターリービング出力のＮＱＣＢ＿ＩＧ個のＱＣＢで実行される。内部グループインターリービングは３６０個の列及びＮＱＣＢ＿ＩＧ個の行を用いて内部グループのビットを記入し読み取る過程を含む。記入動作で、ＱＣＢインターリービング出力からのビットが行方向に記入される。読取動作は列方向に実行されて各行でｍ個のビットを読み取る。ここで、ｍはＮＵＣの場合１と同一であり、ＮＵＱの場合２と同一である。
【０４２３】
図２４は、本発明の一実施形態に係るセル−ワードデマルチプレキシングを示す。
【０４２４】
図２４で、（ａ）は８及び１２ｂｐｃｕ ＭＩＭＯに対するセル−ワードデマルチプレキシングを示し、（ｂ）は１０ｂｐｃｕ ＭＩＭＯに対するセル−ワードデマルチプレキシングを示す。
【０４２５】
ビットインターリービング出力の各々のセルワード（ｃ０，ｌ，ｃ１，ｌ，．．． ，ｃｎｍｏｄ−１，ｌ）は１つのＸＦＥＣＢＬＯＣＫに対するセル−ワードデマルチプレキシング過程を説明する（ａ）に示したように（ｄ１，０，m，ｄ１，１，ｍ，．．．，ｄ１，ｎｍｏｄ−１，ｍ）及び（ｄ２，０，m，ｄ２，１，ｍ，．．．，ｄ２，ｎｍｏｄ−１，m）にデマルチプレキシングされる。
【０４２６】
ＭＩＭＯエンコーディングのために異なるタイプのＮＵＱを用いる１０ｂｐｃｕ ＭＩＭＯの場合に、ＮＵＱ−１０２４に対するビットインターリーバが再使用される。ビットインターリーバ出力の各々のセルワード（ｃ０，ｌ，ｃ１，ｌ，．．．，ｃ９，ｌ）は（ｂ）に示したように（ｄ１，０，ｍ，ｄ１，１，ｍ，．．．，ｄ１，３，ｍ）及び（ｄ２，０，ｍ，ｄ２，１，ｍ，．．．，ｄ２，５，ｍ）にデマルチプレキシングされる。
【０４２７】
図２５は、本発明の一実施形態に係るタイムインターリービングを示す。
【０４２８】
（ａ）から（ｃ）はタイムインターリービングモードの例を示す。
【０４２９】
タイムインターリーバはデータパイプレベルで動作する。タイムインターリービングのパラメータは各々のデータパイプに対して異に設定できる。
【０４３０】
ＰＬＳ２−ＳＴＡＴデータの一部に表れる次のパラメータはタイムインターリービングを構成する。
【０４３１】
ＤＰ＿ＴＩ＿ＴＹＰＥ（許容された値：０または１）：タイムインターリービングモードを示す。０はタイムインターリービンググループ当たり複数のタイムインターリービングブロック（１つ以上のタイムインターリービングブロック）を有するモードを示す。この場合、１つのタイムインターリービンググループは１つのフレームに（フレーム間インターリービング無しで）直接マッピングされる。１はタイムインターリービンググループ当たり１つのタイムインターリービングブロックのみを有するモードを示す。この場合、タイムインターリービングブロックは１つ以上のフレームに亘って拡散される（フレーム間インターリービング）。
【０４３２】
ＤＰ＿ＴＩ＿ＬＥＮＧＴＨ：ＤＰ＿ＴＩ＿ＴＹＰＥ＝‘０’であれば、該当パラメータはタイムインターリービンググループ当たりタイムインターリービングブロックの数ＮＴＩである。ＤＰ＿ＴＩ＿ＴＹＰＥ＝‘１’の場合、該当パラメータは１つのタイムインターリービンググループから拡散されるフレームの数ＰＩである。
【０４３３】
ＤＰ＿ＮＵＭ＿ＢＬＯＣＫ＿ＭＡＸ（許容された値：０乃至１０２３）：タイムインターリービンググループ当たりＸＦＥＣＢＬＯＣＫの最大数を示す。
【０４３４】
ＤＰ＿ＦＲＡＭＥ＿ＩＮＴＥＲＶＡＬ（許容された値：１、２、４、８）：与えられたフィジカルプロファイルの同一なデータパイプを伝達する２つの順次的なフレーム間のフレームの数ＩＪＵＭＰを示す。
【０４３５】
ＤＰ＿ＴＩ＿ＢＹＰＡＳＳ（許容された値：０または１）：タイムインターリービングがデータフレームに用いられなければ、該当パラメータは１に設定される。タイムインターリービングが用いられれば、０に設定される。
【０４３６】
さらに、ＰＬＳ２−ＤＹＮデータからのパラメータＤＰ＿ＮＵＭ＿ＢＬＯＣＫはデータグループの１つのタイムインターリービンググループにより伝達されるＸＦＥＣＢＬＯＣＫの数を示す。
【０４３７】
タイムインターリービングがデータフレームに用いられなければ、次のタイムインターリービンググループ、タイムインターリービング動作、タイムインターリービングモードは考慮されない。しかしながら、スケジューラからのダイナミック（dynamic：動的）構成情報のためのディレイコンペンセーション（delay compensation：遅延補償）ブロックは相変らず必要である。各々のデータパイプで、ＳＳＤ／ＭＩＭＯエンコーディングから受信したＸＦＥＣＢＬＯＣＫはタイムインターリービンググループにグルーピングされる。即ち、各々のタイムインターリービンググループは整数個のＸＦＥＣＢＬＯＣＫの集合であり、ダイナミック（dynamic：動的）に変化する数のＸＦＥＣＢＬＯＣＫを含む。インデックスｎのタイムインターリービンググループにあるＸＦＥＣＢＬＯＣＫの数はＮｘＢＬＯＣＫ＿Ｇｒｏｕｐ（ｎ）で示し、ＰＬＳ２−ＤＹＮデータでＤＰ＿ＮＵＭ＿ＢＬＯＣＫにシグナリングされる。この際、ＮｘＢＬＯＣＫ＿Ｇｒｏｕｐ（ｎ）は最小値０から最も大きい値が１０２３である最大値ＮｘＢＬＯＣＫ＿Ｇｒｏｕｐ＿ＭＡＸ（ＤＰ＿ＮＵＭ＿ＢＬＯＣＫ＿ＭＡＸに該当）まで変化することができる。
【０４３８】
各々のタイムインターリービンググループは１つのフレームに直接マッピングされるか、またはＰＩ個のフレームに亘って拡散される。また、各々のタイムインターリービンググループは１つ以上（ＮＴＩ個）のタイムインターリービングブロックに分離される。ここで、各々のタイムインターリービングブロックはタイムインターリーバメモリの１つの使用に該当する。タイムインターリービンググループ内のタイムインターリービングブロックは若干の異なる数のＸＦＥＣＢＬＯＣＫを含むことができる。タイムインターリービンググループが複数のタイムインターリービングブロックに分離されれば、タイムインターリービンググループは１つのフレームのみに直接マッピングされる。以下の＜表３３＞に示したように、タイムインターリービングには３種類のオプションがある（タイムインターリービングを省略する追加オプション除外）。
【０４３９】
【表３３】
0006392463.tif 000042
【０４４０】
各々のデータパイプで、タイムインターリービングメモリは入力されたＸＦＥＣＢＬＯＣＫ（ＳＳＤ／ＭＩＭＯエンコーディングブロックから出力されたＸＦＥＣＢＬＯＣＫ）を格納する。入力されたＸＦＥＣＢＬＯＣＫは、
0006392463.tif 000043
として定義されると仮定する。ここで、
0006392463.tif 000044
はｎ番目タイムインターリービンググループのｓ番目タイムインターリービングブロックでｒ番目ＸＦＥＣＢＬＯＣＫのｑ番目セルであり、次のようなＳＳＤ及びＭＩＭＯエンコーディングの出力を示す。
0006392463.tif 000045
【０４４１】
また、タイムインターリーバ５０５０から出力されたＸＦＥＣＢＬＯＣＫは
0006392463.tif 000046
として定義されると仮定する。ここで、
0006392463.tif 000047
はｎ番目タイムインターリービンググループのｓ番目タイムインターリービングブロックでｉ番目
0006392463.tif 000048
出力セルである。
【０４４２】
一般に、タイムインターリーバはフレーム生成過程の以前にデータパイプデータに対するバッファとしても作用する。これは、各々のデータパイプに対して２つのメモリバンクで達成される。第１のタイムインターリービングブロックは第１のバンクに記入される。第１のバンクで読取される間、第２のタイムインターリービングブロックが第２のバンクに記入される。
【０４４３】
タイムインターリービングはツイストされた行−列ブロックインターリーバである。ｎ番目タイムインターリービンググループのｓ番目タイムインターリービングブロックに対し、列の数Ｎｃが
0006392463.tif 000049
と同一である一方、タイムインターリービングメモリの行の数Ｎｒはセルの数Ｎｃｅｌｌと同一である（即ち、Ｎｒ＝Ｎｃｅｌｌ）。
【０４４４】
図２６は、本発明の一実施形態に係るツイストされた行−列ブロックインターリーバの基本動作を示す。
【０４４５】
図２６（ａ）は、タイムインターリーバで記入動作を示し、図２６（ｂ）は、タイムインターリーバで読取動作を示す。（ａ）に示したように、１番目のＸＦＥＣＢＬＯＣＫは、タイムインターリービングメモリの１番目の列に列方向に記入され、２番目のＸＦＥＣＢＬＯＣＫは、次の列に記入され、このような動作が続く。そして、インターリービングアレイで、セルが対角線方向に読み取られる。（ｂ）に示したように、１番目の行から（最も左側の列を始めとして行に沿って右に）最後の行まで対角線方向の読取が進まれる間、
0006392463.tif 000050
個のセルが読み取られる。具体的に、
0006392463.tif 000051
が順次読み取られるタイムインターリービングメモリセル位置と仮定すれば、このようなインターリービングアレイでの読取動作は、下記の式のように、行インデックス
0006392463.tif 000052
、列インデックス
0006392463.tif 000053
、関連したツイストパラメータ
0006392463.tif 000054
を算出することによって実行される。
【０４４６】
【数９】
0006392463.tif 000055
【０４４７】
ここで、
0006392463.tif 000056
に関係なく、対角線方向読取過程に対する共通シフト値であり、シフト値は、下記の式のように、ＰＬＳ２−ＳＴＡＴで与えられた
0006392463.tif 000057
により決定される。
【０４４８】
【数１０】
0006392463.tif 000058
【０４４９】
結果的に、読み取られるセル位置は、座標
0006392463.tif 000059
により算出される。
【０４５０】
図２７は、本発明の他の一実施形態に係るツイストされた行−列ブロックインターリーバの動作を示す。
【０４５１】
より具体的に、図２７は、
0006392463.tif 000060
であるとき、仮想ＸＦＥＣＢＬＯＣＫを含むそれぞれのタイムインターリービンググループに対するタイムインターリービングメモリでインターービングアレイを示す。
【０４５２】
変数
0006392463.tif 000061
より小さいか、同じであろう。したがって、
0006392463.tif 000062
に関係なく、受信機側で単一メモリデインターリービングを達成するために、ツイストされた行−列ブロックインターリーバ用インターリービングアレイは、仮想ＸＦＥＣＢＬＯＣＫをタイムインターリービングメモリに挿入することにより、
0006392463.tif 000063
の大きさに設定され、読取過程は、次の式のようになされる。
【０４５３】
【数１１】
0006392463.tif 000064
【０４５４】
タイムインターリービンググループの数は、３に設定される。タイムインターリーバのオプションは、ＤＰ＿ＴＩ＿ＴＹＰＥ＝‘０’、ＤＰ＿ＦＲＡＭＥ＿ＩＮＴＥＲＶＡＬ＝‘１’、ＤＰ＿ＴＩ＿ＬＥＮＧＴＨ＝‘１’、すなわち、ＮＴＩ＝１、ＩＪＵＭＰ＝１、ＰＩ＝１によりＰＬＳ２−ＳＴＡＴデータでシグナリングされる。各々Ｎｃｅｌｌｓ＝３０であるＸＦＥＣＢＬＯＣＫのタイムインターリービンググループ当たりの数は、それぞれのＮｘＢＬＯＣＫ＿ＴＩ（０、０）＝３、ＮｘＢＬＯＣＫ＿ＴＩ（１、０）＝６、ＮｘＢＬＯＣＫ＿ＴＩ（２、０）＝５によりＰＬＳ２−ＤＹＮデータでシグナリングされる。ＸＦＥＣＢＬＯＣＫの最大数は、ＮｘＢＬＯＣＫ＿Ｇｒｏｕｐ＿ＭＡＸによりＰＬＳ２−ＳＴＡＴデータでシグナリングされ、これは、
0006392463.tif 000065
に繋がる。
【０４５５】
図２８は、本発明の一実施形態に係るツイストされた行−列ブロックインターリーバの対角線方向読取パターンを示す。
【０４５６】
より具体的に、図２８は、パラメータ
0006392463.tif 000066
及びＳｓｈｉｆｔ＝（７−１）／２＝３を有するそれぞれのインターリービングアレイからの対角線方向読取パターンを示す。このとき、上記に類似コードで示した読取過程で、
0006392463.tif 000067
であれば、Ｖｉの値が省略され、Ｖｉの次の計算値が使用される。
【０４５７】
図２９は、本発明の一実施形態に係るそれぞれのインターリービングアレイからのインターリービングされたＸＦＥＣＢＬＯＣＫを示す。
【０４５８】
図２９は、パラメータ
0006392463.tif 000068
及びＳｓｈｉｆｔ＝３を有するそれぞれのインターリービングアレイからインターリービングされたＸＦＥＣＢＬＯＣＫを示す。
【０４５９】
図３０は本発明の一実施形態に係る同期及び復調（synchronization & demodulation）モジュールを示す図である。
【０４６０】
図３０に図示された同期及び復調モジュールは、図９で説明した同期及び復調モジュールの一実施形態に該当する。また、図３０に図示された同期及び復調モジュールは、図９で説明したウェーブフォームジェネレーションモジュールの逆動作を遂行することができる。
【０４６１】
図３０に示すように、本発明の一実施形態に係る同期及び復調モジュールは、ｍ個のＲｘアンテナを使用する受信装置の同期及び復調モジュールの実施形態であって、ｍ個のパス（path）だけ入力された信号を復調して出力するためのｍ個の処理ブロックを含むことができる。ｍ個の処理ブロックは全て同一な処理過程を遂行することができる。以下、ｍ個の処理ブロックのうち、第１の処理ブロック３００００の動作を中心に説明する。
【０４６２】
第１の処理ブロック３００００は、チューナー３０１００、ＡＤＣブロック３０２００、プリアンブルディテクタ（preamble dectector）３０３００、ガードシーケンスディテクタ（guard sequence detector）３０４００、ウェーブフォームトランスフォーム（waveform transform）ブロック３０５００、時間／周波数同期化（Time／freq sync）ブロック３０６００、レファレンスシグナルディテクタ（Reference signal detector）３０７００、チャネルイコライザー（Channel equalizer）３０８００、及びインバースウェーブフォームトランスフォーム（Inverse waveform transform）ブロック３０９００を含むことができる。
【０４６３】
チューナー３０１００は、所望の周波数帯域を選択し、受信した信号の大きさを補償してＡＤＣブロック３０２００に出力することができる。
【０４６４】
ＡＤＣブロック３０２００は、チューナー３０１００から出力された信号をディジタル信号に変換することができる。
【０４６５】
プリアンブルディテクタ３０３００は、ディジタル信号に対して受信装置に対応するシステムの信号か否かを確認するためにプリアンブル（または、プリアンブル信号またはプリアンブルシンボル）をディテクティングすることができる。この場合、プリアンブルディテクタ３０３００はプリアンブルを通じて受信される基本的な送信パラメータ（transmission parameter）を復号することができる。
【０４６６】
ガードシーケンスディテクタ３０４００は、ディジタル信号内のガードシーケンス（guard sequence）をディテクティング（検出）することができる。時間／周波数同期化ブロック３０６００は、ディテクティングされたガードシーケンスを用いて時間／周波数同期化（time/frequency synchronization）を遂行することができ、チャネルイコライザー３０８００はディテクティングされたガードシーケンスを用いて受信／復元されたシーケンスを通じてチャネルを推定することができる。
【０４６７】
ウェーブフォームトランスフォームブロック３０５００は、送信側でインバースウェーブフォームトランスフォームが遂行された場合、これに対する逆変換過程を遂行することができる。本発明の一実施形態に係る放送送受信システムが多重キャリアシステム（multi-carrier system）の場合、ウェーブフォームトランスフォームブロック３０５００はＦＦＴ変換過程を遂行することができる。また、本発明の一実施形態に係る放送送受信システムが単一キャリアシステム（single carrier system）の場合、受信された時間領域の信号が周波数領域で処理するために使用されるか、または時間領域で全て処理される場合、ウェーブフォームトランスフォームブロック３０５００は使用されないことがある。
【０４６８】
時間／周波数同期化ブロック３０６００は、プリアンブルディテクタ３０３００、ガードシーケンスディテクタ３０４００、レファレンスシグナルディテクタ３０７００の出力データを受信し、検出された信号に対してガードシーケンスディテクション（guard sequence detection）、ブロックウィンドウポジショニング（block window positioning）を含む時間同期化及びキャリア周波数同期化を遂行することができる。この際、周波数同期化のために時間／周波数同期化ブロック３０６００は、ウェーブフォームトランスフォームブロック３０５００の出力信号をフィードバックして使用することができる。
【０４６９】
レファレンスシグナルディテクタ３０７００は、受信されたレファレンスシグナルを検出することができる。したがって、本発明の一実施形態に係る受信装置は同期化を遂行するか、またはチャネル推定（channel estimation）を遂行することができる。
【０４７０】
チャネルイコライザー３０８００は、ガードシーケンスやレファレンスシグナルから各送信アンテナから各受信アンテナまでの送信チャネルを推定し、推定されたチャネルを用いて各受信データに対するチャネル補償（equalization）を遂行することができる。
【０４７１】
インバースウェーブフォームトランスフォームブロック３０９００は、同期及びチャネル推定／補償を効率的に遂行するために、ウェーブフォームトランスフォームブロック３０５００がウェーブフォームトランスフォームを遂行した場合、また元の受信データドメイン（domain）に復元してくれる役割を遂行することができる。本発明の一実施形態に係る放送送受信システムが単一キャリアシステムの場合、ウェーブフォームトランスフォームブロック３０５００は同期／チャネル推定／補償を周波数領域で遂行するためにＦＦＴを遂行することができ、インバースウェーブフォームトランスフォームブロック３０９００はチャネル補償が完了した信号に対してＩＦＦＴを遂行することで、送信されたデータシンボル（data symbol）を復元することができる。本発明の一実施形態に係る放送送受信システムが多重キャリアシステムの場合、インバースウェーブフォームトランスフォームブロック３０９００は使用されないこともある。
【０４７２】
また、前述したブロックは設計者の意図によって省略されるか、類似または同一機能を有する他のブロックにより取替できる。
【０４７３】
図３１は、本発明の一実施形態に係るフレームパーシングモジュールを示す図である。
【０４７４】
図３１に図示されたフレームパーシングモジュールは、図９で説明したフレームパーシングモジュールの一実施形態に該当する。
【０４７５】
図３１に示すように、本発明の一実施形態に係るフレームパーシングモジュールは、少なくとも１つ以上のブロックデインターリーバ３１０００及び少なくとも１つ以上のセルデマッパー３１１００を含むことができる。
【０４７６】
ブロックデインターリーバ３１０００はｍ個の受信アンテナの各データパスに入力されて同期及び復調モジュールで処理されたデータに対して、各シグナルブロック単位でデータに対するデインターリービングを遂行することができる。この場合、図８で説明したように、送信側でペアワイズインターリービング（pair-wise interleaving）が遂行された場合、ブロックデインターリーバ３１０００は各入力パス（path）に対して連続した２つのデータを１つのペアに処理することができる。したがって、ブロックデインターリーバ３１０００はデインターリービングを遂行した場合にも連続した２つの出力データを出力することができる。また、ブロックデインターリーバ３１０００は送信端で遂行したインターリービング過程の逆過程を遂行して元のデータ順に出力することができる。
【０４７７】
セルデマッパー３１１００は、受信された信号フレームからコモンデータに対応するセル、データパイプに対応するセル、及びＰＬＳデータに対応するセルを抽出することができる。必要の場合、セルデマッパー３１１００は複数個の部分に分散されて送信されたデータをマージ（merge）して１つのストリームに出力することができる。また、図７で説明したように、送信端で２つの連続したセル入力データが１つのペアに処理されてマッピングされた場合、セルデマッパー３１１００はこれに該当する逆過程で連続した２つの入力セルを１つの単位で処理するペアワイズセルデマッピングを遂行することができる。
【０４７８】
また、セルデマッパー３１１００は現在フレームを通じて受信したＰＬＳシグナリングデータに対し、各々ＰＬＳ−プリ（pre）及びＰＬＳ−ポスト（post）データとして全て抽出して出力することができる。
【０４７９】
前述したブロックは設計者の意図によって省略されるか、類似または同一機能を有する他のブロックにより取替できる。
【０４８０】
図３２は、本発明の一実施形態に係るデマッピング及びデコーディングモジュールを示す図である。
【０４８１】
図３２に図示されたデマッピング及びデコーディングモジュールは、図９で説明したデマッピング及びデコーディングモジュールの一実施形態に該当する。
【０４８２】
前述したように、本発明の一実施形態に係る送信装置のコーディングアンドモジュレーションモジュールは、入力されたデータパイプに対し、各々のパス別にＳＩＳＯ、ＭＩＳＯ、及びＭＩＭＯ方式を独立的に適用して処理することができる。したがって、図３２に図示されたデマッピング及びデコーディングモジュールやはり送信装置に対応してフレームパーサから出力されたデータを各々ＳＩＳＯ、ＭＩＳＯ、ＭＩＭＯ処理するためのブロックを含むことができる。
【０４８３】
図３２に示すように、本発明の一実施形態に係るデマッピング及びデコーディングモジュールは、ＳＩＳＯ方式のための第１ブロック３２０００、ＭＩＳＯ方式のための第２ブロック３２１００、ＭＩＭＯ方式のための第３ブロック３２２００、及びＰＬＳプリ／ポスト情報を処理するための第４ブロック３２３００を含むことができる。図３２に図示されたデマッピング及びデコーディングモジュールは一実施形態に過ぎず、設計者の意図によってデマッピング及びデコーディングモジュールは第１ブロック３２０００及び第４ブロック３２３００のみを含むこともでき、第２ブロック３２１００及び第４ブロック３２３００のみを含むこともでき、第３ブロック３２２００及び第４ブロック３２３００のみを含むこともできる。即ち、設計者の意図によってデマッピング及びデコーディングモジュールは各データパイプを同一に、または異なるように処理するためのブロックを含むことができる。
【０４８４】
以下、各ブロックについて説明する。
【０４８５】
第１ブロック３２０００は入力されたデータパイプをＳＩＳＯ処理するためのブロックであって、時間デインターリーバブロック３２０１０、セルデインターリーバブロック３２０２０、コンステレーションデマッパーブロック３２０３０、セルトゥビットマルチプレキシング（cell to bit mux）ブロック３２０４０、ビットデインターリーバブロック３２０５０、及びＦＥＣデコーダブロック３２０６０を含むことができる。
【０４８６】
時間デインターリーバブロック３２０１０は、時間インターリーバブロックの逆過程を遂行することができる。即ち、時間デインターリーバブロック３２０１０は時間領域でインターリービングされた入力シンボルを元の位置にデインターリービングすることができる。
【０４８７】
セルデインターリーバブロック３２０２０は、セルインターリーバブロックの逆過程を遂行することができる。即ち、セルデインターリーバブロック３２０２０は１つのＦＥＣブロック内でスプレッディング（spreading）されたセルの位置を元の位置にデインターリービングすることができる。
【０４８８】
コンステレーションデマッパーブロック３２０３０は、コンステレーションマッパーブロックの逆過程を遂行することができる。即ち、コンステレーションデマッパーブロック３２０３０はシンボルドメインの入力信号をビットドメインのデータにデマッピングすることができる。また、コンステレーションデマッパーブロック３２０３０は硬判定（hard decision）を遂行して判定されたビットデータを出力することもでき、軟判定（soft decision）値や、あるいは確率的な値に該当する各ビットの対数尤度比（Log-likelihood ratio：ＬＬＲ）を出力することができる。仮に、送信端で追加的なダイバーシティゲインを得るために回転（rotated）コンステレーションを適用した場合、コンステレーションデマッパーブロック３２０３０はこれに相応する２次元のＬＬＲ デマッピングを遂行することができる。この際、コンステレーションデマッパーブロック３２０３０はＬＬＲを計算する時、送信装置でＩまたはＱコンポネントに対して遂行された遅延値を補償できるように計算を遂行することができる。
【０４８９】
セルトゥビットマルチプレキシングブロック３２０４０は、ビットトゥセルデマルチプレキシングブロックの逆過程を遂行することができる。即ち、セルトゥビットマルチプレキシングブロック３２０４０は、ビットトゥセルデマルチプレキシングブロックでマッピングされたビットデータを元のビットストリーム形態に復元することができる。
【０４９０】
ビットデインターリーバブロック３２０５０は、ビットインターリーバブロックの逆過程を遂行することができる。即ち、ビットデインターリーバブロック３２０５０はセルトゥビットマルチプレキシングブロック３２０４０から出力されたビットストリームを元の順にデインターリービングすることができる。
【０４９１】
ＦＥＣデコーダブロック３２０６０は、ＦＥＣエンコーダブロックの逆過程を遂行することができる。即ち、ＦＥＣデコーダブロック３２０６０はＬＤＰＣデコーディングとＢＣＨデコーディングを遂行して送信チャネル上の発生したエラーを訂正することができる。
【０４９２】
第２ブロック３２１００は入力されたデータパイプをＭＩＳＯ処理するためのブロックであって、図３２に示すように、第１ブロック３２０００と同一に時間デインターリーバブロック、セルデインターリーバブロック、コンステレーションデマッパーブロック、セルトゥビットマルチプレキシングブロック、ビットデインターリーバブロック、及びＦＥＣデコーダブロックを含むことができるが、ＭＩＳＯデコーディングブロック３２１１０をさらに含むという点で差がある。第２ブロック３２１００は、第１ブロック３２０００と同様に時間デインターリーバから出力まで同一な役割の過程を遂行するので、同一なブロックに対する説明は省略する。
【０４９３】
ＭＩＳＯデコーディングブロック３２１１０は、ＭＩＳＯプロセッシングブロックの逆過程を遂行することができる。本発明の一実施形態に係る放送送受信システムがＳＴＢＣを使用したシステムの場合、ＭＩＳＯデコーディングブロック３２１１０はアラモウチ（Alamouti）デコーディングを遂行することができる。
【０４９４】
第３ブロック３２２００は入力されたデータパイプをＭＩＭＯ処理するためのブロックであって、図３２に示すように、第２ブロック３２１００と同一に時間デインターリーバブロック、セルデインターリーバブロック、コンステレーションデマッパーブロック、セルトゥビットマルチプレキシングブロック、ビットデインターリーバブロック、及びＦＥＣデコーダブロックを含むことができるが、ＭＩＭＯデコーディングブロック３２２１０を含むという点でデータ処理過程の差がある。第３ブロック３２２００に含まれた時間デインターリーバ、セルデインターリーバ、コンステレーションデマッパー、セルトゥビットマルチプレキシング、ビットデインターリーバブロックなどの動作は、第１乃至第２ブロック３２０００−３２１００に含まれた該当ブロックの動作と具体的な機能は異なることがあるが、基本的な役割は同一である。
【０４９５】
ＭＩＭＯデコーディングブロック３２２１０は、ｍ個の受信アンテナ入力信号に対してセルデインターリーバの出力データを入力に受けて、ＭＩＭＯプロセッシングブロックの逆過程としてＭＩＭＯデコーディングを遂行することができる。ＭＩＭＯデコーディングブロック３２２１０は、最高の復号化性能を得るために最尤復号（Maximum likelihood decoding）を遂行するか、複雑度を減少させたスフィアデコーディング（Sphere decoding）を遂行することができる。または、ＭＩＭＯデコーディングブロック３２２１０はＭＭＳＥディテクションを遂行するか、または反復デコーディング（iterative decoding）を共に結合遂行して、向上したデコーディング性能を確保することができる。
【０４９６】
第４ブロック３２３００はＰＬＳプリ／ポスト情報を処理するためのブロックであって、ＳＩＳＯまたはＭＩＳＯデコーディングを遂行することができる。第４ブロック３２３００は第４ブロックの逆過程を遂行することができる。
【０４９７】
第４ブロック３２３００に含まれた時間デインターリーバ、セルデインターリーバ、コンステレーションデマッパー、セルトゥビットマルチプレキシング、ビットデインターリーバブロックの動作は、第１乃至第３ブロック３２０００−３２２００に含まれた該当ブロックの動作と具体的な機能は異なることがあるが、基本的な役割は同一である。
【０４９８】
第４ブロック３２３００に含まれた短縮及びパンクチャリングＦＥＣデコーダ（Shortened/Punctured FEC decoder）３２３１０は、短縮及びパンクチャリングＦＥＣエンコーダブロックの逆過程を遂行することができる。即ち、短縮及びパンクチャリングＦＥＣデコーダ３２３１０はＰＬＳデータの長さによって短縮及びパンクチャリングされて受信されたデータに対して非短縮（de-shortening）とデパンクチャリング（de-puncturing）を遂行した後にＦＥＣデコーディングを遂行することができる。この場合、データパイプに使われたＦＥＣデコーダを同一にＰＬＳにも使用することができるので、ＰＬＳのみのための別途のＦＥＣデコーダハードウェアが必要でないので、システム設計が容易であり、効率的なコーディングが可能であるという長所がある。
【０４９９】
前述したブロックは設計者の意図によって省略されるか、類似または同一機能を有する他のブロックにより取替できる。
【０５００】
結果的に、図３２に示すように、本発明の一実施形態に係るデマッピング及びデコーディングモジュールは、各パス別に処理されたデータパイプ及びＰＬＳ情報をアウトプットプロセッサに出力することができる。
【０５０１】
図３３及び図３４は、本発明の一実施形態に係るアウトプットプロセッサ（output processor）を示す図である。
【０５０２】
図３３は、本発明の一実施形態に係る出力プロセッサを示す図である。
【０５０３】
図３３に図示された出力プロセッサは、図９で説明した出力プロセッサの一実施形態に該当する。また、図３３に図示された出力プロセッサはデマッピング及びデコーディングモジュールから出力された単一データパイプを受信して単一出力ストリームを出力するためのものであって、インプットフォーマッティングモジュールの逆動作を遂行することができる。
【０５０４】
図３３のアウトプットプロセッサは、後述する図５０、図５１、及び図５３において提案された機能、過程、及び／又は方法を実現する。
【０５０５】
図３３に図示された出力プロセッサは、ＢＢデスクランブラーブロック３３０００、パディング削除（Padding removal）ブロック３３１００、ＣＲＣ−８デコーダブロック３３２００、及びＢＢフレームプロセッサブロック３３３００を含むことができる。
【０５０６】
ＢＢデスクランブラーブロック３３０００は、入力されたビットストリームに対して送信端で使用したものと同一なＰＲＢＳを発生させてビット列とＸＯＲしてデスクランブリングを遂行することができる。
【０５０７】
パディング削除ブロック３３１００は、送信端で必要によって挿入されたパディングビットを除去することができる。
【０５０８】
ＣＲＣ−８デコーダブロック３３２００は、パディング削除ブロック３３１００から入力を受けたビットストリームに対してＣＲＣデコーディングを遂行してブロックエラーをチェックすることができる。
【０５０９】
ＢＢフレームプロセッサブロック３３３００は、ＢＢフレームヘッダに送信された情報をデコーディングし、デコーディングされた情報を用いてＭＰＥＧ−ＴＳ、ＩＰストリーム（ｖ４またはｖ６）またはジェネリックストリーム（Generic stream）を復元することができる。
【０５１０】
前述したブロックは設計者の意図によって省略されるか、類似または同一機能を有する他のブロックにより取替できる。
【０５１１】
図３４は、本発明の他の実施形態に係るアウトプットプロセッサを示す図である。
【０５１２】
図３４に図示されたアウトプットプロセッサは、図９で説明したアウトプットプロセッサの一実施形態に該当する。また、図３４に図示されたアウトプットプロセッサは、デマッピング及びデコーディングモジュールから出力された多重（multiple）データパイプを受信する場合に該当する。多重データパイプに対するデコーディングは複数のデータパイプに共通に適用できるコモンデータ及びこれと関連したデータパイプをマージしてデコーディングする場合、または受信装置が複数個のサービスあるいはサービスコンポーネント（scalable video serviceを含み）を同時にデコーディングする場合を含むことができる。
【０５１３】
図３４に図示されたアウトプットプロセッサは、アウトプットプロセッサの場合と同様に、ＢＢデスクランブラーブロック、パディング削除ブロック、ＣＲＣ−８デコーダブロック、及びＢＢフレームプロセッサブロックを含むことができる。各ブロックは図３３で説明したブロックの動作と具体的な動作は異なることがあるが、基本的な役割は同一である。
【０５１４】
図３４のアウトプットプロセッサは、後述する図５０、図５１、及び図５３において提案された機能、過程、及び／又は方法を実現する。
【０５１５】
図３４に図示されたアウトプットプロセッサに含まれたデ−ジッタバッファブロック３４０００は、多重データパイプ間の同期化のために送信端で任意に挿入された遅延（delay）を復元されたＴＴＯ（time to output）パラメータに従って補償することができる。
【０５１６】
また、ヌルパケット挿入ブロック３４１００は復元されたＤＮＰ（deleted null packet）情報を参考してストリーム内の除去されたヌルパケットを復元することができ、コモンデータを出力することができる。
【０５１７】
ＴＳクロック再生ブロック３４２００は、ＩＳＣＲインプットストリーム時間レファレンス（ISCR-Input Stream Time Reference）情報を基準に出力パケットの詳細な時間同期を復元することができる。
【０５１８】
ＴＳ再結合（recombining）ブロック３４３００は、ヌルパケット挿入ブロック３４１００から出力されたコモンデータ及びこれと関連したデータパイプを再結合して元のＭＰＥＧ−ＴＳ、ＩＰストリーム（ｖ４またはｖ６）、あるいはジェネリックストリームに復元して出力することができる。ＴＴＯ、ＤＮＰ、ＩＳＣＲ情報は全てＢＢフレームヘッダを通じて取得できる。
【０５１９】
インバンドシグナリングデコーダブロック３４４００は、データパイプの各ＦＥＣフレーム内のパディングビットフィールドを通じて送信されるインバンド物理階層シグナリング（in-band physical layer signaling）情報を復元して出力することができる。
【０５２０】
図３４に図示されたアウトプットプロセッサは、ＰＬＳ−プリパスとＰＬＳ−ポストパスによって入力されるＰＬＳ−プリ情報及びＰＬＳ−ポスト情報を各々ＢＢデスクランブリングし、デスクランブリングされたデータに対してデコーディングを遂行して、元のＰＬＳデータを復元することができる。復元されたＰＬＳデータは受信装置内のシステム制御器（system controller）に伝達され、システム制御器は受信装置の同期化及び復調モジュール、フレームパーシングモジュール、デマッピング及びデコーディングモジュール、及びアウトプットプロセッサモジュールに必要とするパラメータを供給することができる。
【０５２１】
前述したブロックは設計者の意図によって省略されるか、類似または同一機能を有する他のブロックにより取替できる。
【０５２２】
図３５は、本発明の他の実施形態に係るコーディングアンドモジュレーションモジュールを示す図である。
【０５２３】
図３５に図示されたコーディングアンドモジュレーションモジュールは、各データパイプを通じて送信するサービスやサービスコンポーネント別にＱｏＳを調節するために、モジュールはＳＩＳＯ方式のための第１ブロック３５０００、ＭＩＳＯ方式のための第２ブロック３５１００、ＭＩＭＯ方式のための第３ブロック３５２００、及びＰＬＳプリ／ポスト情報を処理するための第４ブロック３５３００を含むことができる。また、本発明の一実施形態に係るコーディングアンドモジュレーションモジュールは、前述したように、設計者の意図によって各データパイプを同一に、または異なるように処理するためのブロックを含むことができる。図３５に図示された第１ブロック乃至第４ブロック３５０００−３５３００は、第１ブロック乃至第４ブロックと略同一なブロックを含んでいる。
【０５２４】
しかしながら、第１ブロック乃至第３ブロック３５０００−３５２００に含まれたコンステレーションマッパーブロック３５０１０の機能が第１ブロック乃至第３ブロックに含まれたコンステレーションマッパーブロックの機能と異なるという点、第１ブロック乃至第４ブロック３５０００−３５３００のセルインターリーバ及び時間インターリーバの間に回転（rotation）及びＩ／Ｑインターリーバブロック３５０２０が含まれているという点、及びＭＩＭＯ方式のための第３ブロック３１２００の構成がＭＩＭＯ方式のための第３ブロックの構成が異なるという点に差がある。
【０５２５】
図３５に図示されたコンステレーションマッパーブロック３５０１０は、入力されたビットワードを複合シンボル（complex symbol）にマッピングすることができる。
【０５２６】
図３５に図示されたコンステレーションマッパーブロック３５０１０は、前述したように、第１ブロック乃至第３ブロック３５０００−３５２００に共通的に適用できる。
【０５２７】
回転及びＩ／Ｑインターリーバブロック３５０２０は、セルインターリーバから出力されたセルインターリービングされたデータの各複合シンボルの同相（In-phase）と直交位相（Quadrature-phase）コンポーネントを独立的にインターリービングしてシンボル単位で出力することができる。回転及びＩ／Ｑインターリーバブロック３５０２０の入力データ及び出力シンボルの個数は２つ以上であり、これは設計者の意図によって変更可能である。また、回転及びＩ／Ｑインターリーバブロック３５０２０は同相成分に対してはインターリービングを遂行しないこともある。
【０５２８】
回転及びＩ／Ｑインターリーバブロック３５０２０は、前述したように、第１ブロック乃至第４ブロック３５０００−３５３００に共通的に適用できる。この場合、回転及びＩ／Ｑインターリーバブロック３５０２０がＰＬＳプリ／ポスト情報を処理するための第４ブロック３５３００に適用されるか否かは前述したプリアンブルを通じてシグナリングできる。
【０５２９】
ＭＩＭＯ方式のための第３ブロック３５２００は、図３５に示すように、Ｑ−ブロックインターリーバブロック３５２１０、及び複合シンボル生成ブロック３５２２０を含むことができる。
【０５３０】
Ｑ−ブロックインターリーバブロック３５２１０は、ＦＥＣエンコーダから入力を受けたＦＥＣエンコーディングが遂行されたＦＥＣブロックのパリティパート（parity part）に対し、パーミュテーション（permutation）を遂行することができる。これを通じてＬＤＰＣ Ｈマトリックスのパリティパートを情報パート（information part）と同一に環状構造（cyclic structure）に作ることができる。Ｑ−ブロックインターリーバブロック３５２１０は、ＬＤＰＣＨマトリックスのＱサイズを有する出力ビットブロックの順序をパーミュテーションした後、行（row）−列（column）ブロックインターリービングを遂行して最終ビット列を生成して出力することができる。
【０５３１】
複合シンボル生成器ブロック３５２２０は、Ｑ−ブロックインターリーバブロック３５２１０から出力されたビット列の入力を受けて、複合シンボルにマッピングして出力することができる。この場合、複合シンボル生成器ブロック３５２２０は少なくとも２つの経路を通じてシンボルを出力することができる。これは、設計者の意図によって変更可能である。
【０５３２】
前述したブロックは設計者の意図によって省略されるか、類似または同一機能を有する他のブロックにより取替できる。
【０５３３】
結果的に、図３５に示すように、本発明の他の実施形態に係るコーディングアンドモジュレーションモジュールは、各パス別に処理されたデータパイプ、ＰＬＳ−プリ情報、ＰＬＳ−ポスト情報をフレーム構造モジュールに出力することができる。
【０５３４】
図３６は、本発明の他の実施形態に係るデマッピング及びデコーディングモジュールを示す図である。
【０５３５】
図３６に図示されたデマッピング及びデコーディングモジュールは、図９及び図３２で説明したデマッピング及びデコーディングモジュールの他の実施形態に該当する。また、図３６に図示されたデマッピング及びデコーディングモジュールは図３５で説明したコーディングアンドモジュレーションモジュールの逆動作を遂行することができる。
【０５３６】
図３６に示すように、本発明の他の実施形態に係るデマッピング及びデコーディングモジュールは、ＳＩＳＯ方式のための第１ブロック３６０００、ＭＩＳＯ方式のための第２ブロック３６１００、ＭＩＭＯ方式のための第３ブロック３６２００、及びＰＬＳプリ／ポスト情報を処理するための第４ブロック３６３００を含むことができる。また、本発明の一実施形態に係るデマッピング及びデコーディングモジュールは、前述したように、設計者の意図によって各データパイプを同一に、または異なるように処理するためのブロックを含むことができる。図３６に図示された第１ブロック乃至第４ブロック３６０００−３６３００は、図３２で説明した第１ブロック乃至第４ブロック３２０００−３２３００と略同一なブロックを含んでいる。
【０５３７】
しかしながら、第１ブロック乃至第４ブロック３６０００−３６３００の時間デインターリーバ及びセルデインターリーバの間にＩ／Ｑデインターリーバ及びデローテーションブロック３６０１０が含まれているという点、第１ブロック乃至第３ブロック３６０００−３６２００に含まれたコンステレーションデマッパーブロック３６０２０の機能が図３２の第１ブロック乃至第３ブロック３２０００−３２２００に含まれたコンステレーションマッパーブロック３２０３０の機能と異なるという点、及びＭＩＭＯ方式のための第３ブロック３６２００の構成が図３２に図示されたＭＩＭＯ方式のための第３ブロック３２２００の構成が異なるという点に差がある。以下、図３２と同一なブロックに対する説明は省略し、前述した差異点を中心に説明する。
【０５３８】
Ｉ／Ｑデインターリーバ及びデローテーションブロック３６０１０は、図３５で説明した回転及びＩ／Ｑインターリーバブロック３５０２０の逆過程を遂行することができる。即ち、Ｉ／Ｑデインターリーバ及びデローテーションブロック３６０１０は、送信端でＩ／Ｑインターリービングされて送信されたＩ及びＱコンポーネントに対して各々デインターリービングを遂行することができ、復元されたＩ／Ｑコンポーネントを有する複合シンボルをまたデローテーションして出力することができる。
【０５３９】
Ｉ／Ｑデインターリーバ及びデローテーションブロック３６０１０は、前述したように、第１ブロック乃至第４ブロック３６０００−３６３００に共通的に適用できる。この場合、Ｉ／Ｑデインターリーバ及びデローテーションブロック３６０１０がＰＬＳプリ／ポスト情報を処理するための第４ブロック３６３００に適用されるか否かは前述したプリアンブルを通じてシグナリングできる。
【０５４０】
コンステレーションデマッパーブロック３６０２０は、図３５で説明したコンステレーションマッパーブロック３５０１０の逆過程を遂行することができる。即ち、コンステレーションデマッパーブロック３６０２０は、デローテーションを遂行せず、セルデインターリービングされたデータに対してデマッピングを遂行することができる。
【０５４１】
ＭＩＭＯ方式のための第３ブロック３６２００は、図３６に示すように、複合シンボルパーシングブロック３６２１０及びＱ−ブロックデインターリーバブロック３６２２０を含むことができる。
【０５４２】
複合シンボルパーシングブロック３６２１０は、図３５で説明した複合シンボル生成器ブロック３５２２０の逆過程を遂行することができる。即ち、複合データシンボルをパーシングし、ビットデータにデマッピングして出力することができる。この場合、複合シンボルパーシングブロック３６２１０は少なくとも２つの経路を通じて複合データシンボルの入力を受けることができる。
【０５４３】
Ｑ−ブロックデインターリーバブロック３６２２０は、図３５で説明したＱ−ブロックインターリーバブロック３５２１０の逆過程を遂行することができる。即ち、Ｑ−ブロックデインターリーバブロック３６２２０は、行−列デインターリービングによりＱサイズブロックを復元した後、 パーミュテーションされた各ブロックの順序を元の順に復元した後、パリティデインターリービングを通じてパリティビットの位置を元の通り復元して出力することができる。
【０５４４】
前述したブロックは設計者の意図によって省略されるか、類似または同一機能を有する他のブロックにより取替できる。
【０５４５】
結果的に、図３６に示すように、本発明の他の実施形態に係るデマッピング及びデコーディングモジュールは、各パス別に処理されたデータパイプ及びＰＬＳ情報をアウトプットプロセッサに出力することができる。
【０５４６】
以下、本明細書で提案するＢＢＦ送信のオーバーヘッドを減らし、パディング（Padding）フィールドを用いて多様な機能を追加するための新たなＢＢＦヘッダ構造について具体的に説明する。
【０５４７】
図３７は、本明細書で提案するモードアダプテーションモジュールの一例を示す図である。
【０５４８】
前述したように、インプットフォーマッティング（Input Formatting）モジュールはモードアダプテーション（Mode Adaptation）モジュールを含む。
【０５４９】
図３７のモードアダプテーションモジュールの構成は、前述したモードアダプテーションモジュールの構成と一部相異することがある。
【０５５０】
図３７に示すように、モードアダプテーションモジュールは、プリプロセッシング（Pre ProcessingまたはSplitting）ブロック３７１０、インプットインターフェース（Input Interface）ブロック３７２０、インプットストリーム同期化（input stream synchronizer）をブロック３７３０、ディレイ補償（compensating delay）ブロック３７４０、ヘッダコンプレッション（Header Compression）ブロック３７５０、ヌルデータ再使用（Null data reuse）ブロック３７６０、ヌルパケット除去（null packet deletion）ブロック３７７０、またはＢＢフレームヘッダ挿入（BB Frame Header Insertion）ブロック３７８０のうち、少なくとも１つを含んで構成できる。
【０５５１】
プリプロセッシング（Pre Processing）ブロックは、複数個の入力ストリームを複数個のデータパイプにスプリッティング（splitting）またはデマルチプレキシングすることができる。ここで、データパイプはＰＬＰ（Physical Layer pipe）と呼ばれることもできる。ここで、入力ストリームはＴＳ（ＭＰＥＧ２−ＴＳ）、ＩＰ（Internet protocol）及び／又はＧＳ（Generic Stream）でありうる。
【０５５２】
実施形態によって他の形態の入力ストリームも可能でありうる。
【０５５３】
ヘッダコンプレッションブロックは、パケットヘッダを圧縮することができる。これは、ＴＳまたはＩＰ入力ストリームの送信効率を増加させるためでありうる。受信機が既にヘッダの先験的（a priori）情報を有しているので、既知データ（known data）が送信端から除去できる。例えば、ＰＩＤなどの情報が圧縮されることができ、他の形態の情報は除去または取替できる。実施形態によって、ヘッダコンプレッションブロックはヌルパケット除去ブロックの後に位置することができる。
【０５５４】
ヌルデータ再使用（Null data reuse）ブロックは、ヘッダコンプレッションのその後にヌルデータをパケットに挿入する動作を遂行することができる。このブロックは実施形態によって省略できる。
【０５５５】
ＢＢフレームヘッダ挿入ブロックは、前述したＢＢフレームヘッダ挿入ブロックと異なる方式により動作することもできる。
【０５５６】
本明細書は、ＢＢ（Base Band）フレームのデータフィールド長さのシグナリングを減少させる方法を提供する（data Field Length signaling reduction method）。
【０５５７】
また、本明細書はＢＢフレームのＦＥＣブロックへの送信に対するオーバーヘッドを減らすための方法を提供する。
【０５５８】
即ち、本明細書で提案する新たなＢＢフレーム構成方法はＢＢフレームヘッダ挿入ブロックで遂行できる。
【０５５９】
本明細書で提案する方法により、ＢＢフレーム及びＢＢフレームヘッダが構成できる。本明細書はインプットストリームがインプットプロセシングを経てＦＥＣブロックに伝達されるために、ＢＢフレームが生成される過程に関するものでありうる。
【０５６０】
また、本明細書はＢＢフレームヘッダの大きさを縮めて送信効率を高める方法でありうる。ＢＢフレームヘッダ挿入ブロックと関連した具体的な内容は後述する。
【０５６１】
従来技術において、ＢＢフレームはデータフィールドの長さを受信装置に知らせるために、ＤＦＬ（data field length）をＢＢフレームヘッダごとに割り当てた。前記ＤＦＬは１６ｂｉｔまたは１１ｂｉｔでありうる。これによって、従来技術はＢＢＦ送信に対するオーバーヘッドが大きい。
【０５６２】
常に同一なサイズのＢＢフレームでデータフィールドの長さが異なる場合は、データがＢＢフレームを全て詰められないか、またはＢＢフレームがインバンドシグナリング（in band signaling）情報を含んでいる場合でありうる。
【０５６３】
更に他の従来技術において、ＢＢフレームはデータフィールドの長さを直接知らせる代わり、インジケータ（indicator）のみ送信した。そして、ＢＢフレームはＢＢフレームのパディング（padding）の長さをパディングでシグナリングしてくれた。しかしながら、この場合、インバンドシグナリングを考慮していないので、インバンドシグナリングが運用される場合に制限を受けることができる。
【０５６４】
本明細書で提案する方法は、ＤＦＬを減らし、追加フィールドを挿入できるようにするＢＢフレームヘッダを構成する方法でありうる。ここで、追加フィールドはインバンドシグナリングのタイプなどを指示することもでき、他の用途に使用することもできる。
【０５６５】
本明細書で提案する方法によりＢＢＦ送信に対するオーバーヘッドを最小化することができ、パディング（または、スタッフィング（stuffing））フィールドに多様な機能が追加できる。
【０５６６】
図３８は、本明細書で提案するアウトプットプロセッサの一例を示す図である。
【０５６７】
前述したように、アウトプットプロセッサ（output processor）はＢＢフレームヘッダパーサブロックを含むことができる。図３８のアウトプットプロセッサの構成要素は前述したアウトプットプロセッサの構成要素と一部相異することがある。
【０５６８】
図３８のアウトプットプロセッサは、後述する図５０、図５１、及び図５３において提案された機能、過程、及び／又は方法を実現する。
【０５６９】
アウトプットプロセッサは、ＢＢフレームヘッダパーサブロック３８１０、ヌルパケット挿入（Null packet insertion）ブロック３８２０、ヌルデータ再生成（Null data regenerator）ブロック３８３０、ヘッダデコンプレッションブロック３８４０、ＴＳクロック再生成（TS clock regeneration）ブロック３８５０、デジッタバッファブロック３８６０、またはＴＳ再結合（TS recombining）ブロック３８７０のうち、少なくとも１つを含んで構成できる。
【０５７０】
ここで、ヌルパケット挿入ブロック、ＴＳクロック再生成ブロック、デジッタバッファブロック、及びＴＳ再結合ブロックは、前述したアウトプットプロセッサのブロックと同一の動作を遂行することができる。
【０５７１】
本明細書で提案するＢＢフレームヘッダ構成方法は、受信端（または、受信装置、受信機、レシーバー）ではＢＢフレームヘッダパーサブロックに対応できる。
【０５７２】
ＢＢフレームヘッダパーサブロック３８１０は、前述したＢＢフレームヘッダパーサブロックと相異するように動作することができる。ＢＢフレームヘッダパーサブロック３８１０は、本明細書で提案する方式に従うＢＢフレームヘッダをパーシングする動作を遂行することができる。
【０５７３】
本明細書で提案するＢＢフレーム及びＢＢフレームヘッダの構成方法は後述する。
【０５７４】
ヌルデータ再生成ブロックは、受信端のヌルデータ再使用ブロックに対応する構成でありうる。ヌルデータ再生成ブロックは、アウトプットをヘッダデコンプレッションブロックに出力することができる。このブロックは実施形態によって省略できる。
【０５７５】
ヘッダデコンプレッションブロックは、受信端のヘッダコンプレッションブロックに対応する構成でありうる。ヘッダデコンプレッションブロックは、圧縮されたパケットヘッダの圧縮を復元することができる。前述したように、パケットヘッダはＴＳまたはＩＰ入力ストリームの送信効率を増加させるために圧縮されていることができる。実施形態によって、ヘッダデコンプレッションブロックは、実施形態によってヌルパケット挿入ブロックの前に位置することができる。
【０５７６】
図３９は、従来のＢＢフレーム構造の一例を示す図である。
【０５７７】
インプットフォーマッティングモジュール、特に、モードアダプテーションモジュールに入力されたデータストリームはＢＩＣＭモジュールでＦＥＣを遂行することができるように適切な長さにスライシングできる。これを通じてＢＢフレームが生成できる。
【０５７８】
ＢＢフレームのデータフィールドの長さはＢＢフレームの全体長さからＢＢフレームヘッダの長さを引いた値に該当する。
【０５７９】
前記ＢＢＦのデータフィールド部分に実際ＵＰ（User Packet）が挿入できる。
【０５８０】
データフィールドの長さはＢＢフレームヘッダのＤＦＬ（data Field Length）フィールドで知らせることができる。ＤＦＬフィールドはＤＦＬで表現できる。
【０５８１】
インプットフォーマッティングを通じて生成されるＢＢフレームは、予め設定されたＦＥＣブロックでエンコーディングできる。
【０５８２】
ここで、ＢＢフレームの全長は固定されていることができる。
【０５８３】
また、ＢＢＦのデータフィールドの長さが変わる場合は、ＵＰが充分でなくてＢＢフレームを全て詰められない場合、または意図的にインバンドシグナリング（in-band signaling）情報が含まれた場合でありうる。
【０５８４】
ＢＢフレームを全て詰められない場合には、該当空間にスタッフィング（stuffing）が詰められる。前記スタッフィングはパディング（padding）で表現できる。
【０５８５】
図４０は、従来のＢＢフレーム構造の更に他の一例を示す図である。
【０５８６】
図４０ｂに示すように、ＢＢフレームのデータフィールド（または、ペイロード）に送信されるデータを全て詰められなかった場合、スタッフィングバイトが挿入できる。
【０５８７】
前記スタッフィングバイトをシグナリングするために、ＳＴＵＦＦＩフィールドがＢＢＦヘッダに挿入できる。前記ＢＢＦヘッダはＴＳヘッダでありうる。
【０５８８】
前記ＳＴＵＦＦＩフィールドはＢＢフレームにスタッフィングバイトの存否を示す１ビットの指示子を示す。
【０５８９】
ＢＢフレームのペイロードにＵＰが全て詰められる場合には、前記スタッフィングバイトが存在しなくなる。この際、前記ＳＴＵＦＦＩは‘０’に設定できる。
【０５９０】
ＢＢフレームにＵＰが全て詰められない場合には前記スタッフィングバイトが存在することができる。この場合、前記ＳＴＵＦＦＩは‘１’に設定できる。
【０５９１】
前記スタッフィングバイトがＢＢフレームに含まれている場合、前記スタッフィングバイトの長さはＢＢフレームペイロードの第１のバイトを通じて確認することができる。
【０５９２】
一例に、前記ＢＢフレームペイロードの第１のバイト値が０ｘＦＦの場合、ＢＢフレームペイロードに１つのスタッフィングバイト（１ｂｙｔｅのスタッフィングバイト）を含むことができる。
【０５９３】
前記ＢＢフレームペイロードの第１のバイト及び第２のバイト値が各々０ｘＦＥ、０ｘＦＦの場合、前記ＢＢフレームペイロードに２つのスタッフィングバイトを含むことができる。
【０５９４】
ここで、スタッフィングバイトが２つ以上（スタッフィングバイトの大きさが２ｂｙｔｅ以上）の場合には、第１及び第２のバイト値を各々ＭＳＢ、ＬＳＢにしてスタッフィングバイトの長さをシグナリングすることができる。
【０５９５】
図４０ａの表で、‘Ｎ’は全体スタッフィングバイトの長さを示す。
【０５９６】
‘Ｎ’値が１バイトの場合、スタッフィングバイトの全体長さを知らせるフィールドの長さは１バイトでありうる。この際、前記フィールド値は０ｘＦＦに設定できる。
【０５９７】
ここで、前記スタッフィングバイトの全長を知らせるフィールドはスタッフィングバイト長さフィールドで表現できる。
【０５９８】
‘Ｎ’値が２バイトの場合、スタッフィングバイト長さフィールドの長さは２バイトでありうる。
【０５９９】
この際、前記スタッフィングバイト長さフィールド値は０ｘＦＥ及び０ｘＦＦに設定できる。
【０６００】
‘Ｎ’値が‘３以上’の場合、一例に、Ｎが３から６５２７８の間の値を有する場合にも前記スタッフィングバイト長さフィールドの長さは２バイトでありうる。
【０６０１】
この際、前記スタッフィングバイト長さフィールドはＭＳＢとＬＳＢで構成できる。
【０６０２】
即ち、前記２ｂｙｔｅのスタッフィングバイト長さフィールドは全体スタッフィングバイトの長さをシグナリングすることができる。
【０６０３】
図４０に示すように、ＭＳＢとＬＳＢの後に追加的なスタッフィングバイトが存在することができる。即ち、総スタッフバイト長さがＮであり、ＭＳＢ及びＬＳＢの長さが２バイトであるので、後続するスタッフィングバイト長さはＮ−２バイトである。
【０６０４】
図４１は、従来のＢＢフレーム構造の更に他の一例を示す図である。
【０６０５】
図４１に示すように、スタッフィングバイトの状態を示すために２ｂｉｔのインジケータ（indicator）が使用できる。前記インジケータはＰＡＤＩ（Padding Indicator）で表現できる。
【０６０６】
ＢＢＦペイロード（または、データフィールドまたはＦＥＣフレーム）にスタッフィングバイト、即ちパディングが含まれない場合、前記ＰＡＤＩは‘００’に設定できる。
【０６０７】
図４１ｂに図示された第１のＢＢフレームで、ＰＡＤＩは‘００’に設定され、ＢＢＦペイロードにパディングが存在しないことを確認することができる。
【０６０８】
ＰＡＤＩが‘０１’の場合、ＢＢＦペイロードに含まれるパディングの長さは１バイトであることを示すことができる。
【０６０９】
図４１ｂに図示された第２のＢＢフレームで、ＰＡＤＩ値が‘０１’に設定され、パディングの長さは１バイトであることが分かる。‘Ｐ’で表示されたものがパディングバイトを示す。
【０６１０】
ＰＡＤＩが‘１０’の場合、パディングバイトは２つ以上であることを示すことができる。
【０６１１】
この場合にはパディングフィールドでＭＳＢ及びＬＳＢなどを用いてパディングの長さをシグナリングしてくれることができる。
【０６１２】
図４１ｂに図示された第３のＢＢフレームで、ＰＡＤＩ値が‘１０’に設定され、パディングフィールドの第１及び第２のバイトが各々ＭＳＢ、ＬＳＢに割り当てられたことを見ることができる。
【０６１３】
前記ＭＳＢ、ＬＳＢの次に‘Ｐ’で表記された追加的なパディングが存在することができる。
【０６１４】
図４２は、本明細書で提案するＢＢフレーム構造の一例を示す。
【０６１５】
本明細書はＢＢフレーム及びＢＢフレームヘッダの構成に対して以下のような方式を提供する。
【０６１６】
ＢＢフレームは、ＢＢフレームヘッダ、スタッフィングフィールド（stuffing field）、またはペイロード（payload）のうち、少なくとも１つを含んで構成できる。
【０６１７】
図４２は、前記スタッフィングフィールドが前記ペイロードの前に位置するＢＢフレーム構造の一例を示す。
【０６１８】
前記スタッフィングフィールドは実施形態によって前記ペイロードの後に位置することもでき、これに対しては図４４及び図４５で具体的に説明する。
【０６１９】
前記スタッフィングフィールド及びペイロードを含んでＢＢフレームペイロード（または、ＢＢフレームデータフィールドまたはＦＥＣフレーム）と称することもできる。
【０６２０】
前記ＢＢフレームヘッダはペイロード、即ちデータフィールドのフォーマットを記述することができる（describing）。
【０６２１】
また、前記スタッフィングフィールドの前にＤＮＰ（Deleted Null Packet）またはＩＳＳＹ（Input Stream Synchronizer）関連情報などが追加で挿入されることもできる。
【０６２２】
前述したように、前記ペイロードはデータフィールドを意味することができる。
【０６２３】
前記ＢＢフレームヘッダは、ＳＴＵＦＦＩフィールドを含むことができる。
【０６２４】
前記ＳＴＵＦＦＩフィールドはＢＢフレームにスタッフィングバイトが存在するか否かを示すインジケータの役割をすることができる。
【０６２５】
前記ＳＴＵＦＦＩフィールドは１ｂｉｔでありうる。実施形態によってＳＴＵＦＦＩの位置は変更できる。
【０６２６】
一例に、前記ＳＴＵＦＦＩ値が‘０’の場合、ＢＢフレームはスタッフィングフィールドを含まず、インバンドシグナリングフィールドやはり含まないことがある。
【０６２７】
ＳＴＵＦＦＩ値が‘１’の場合、ＢＢフレームはスタッフィングフィールドを含むか、またはインバンドシグナリングフィールドを含むことができる。即ち、前記ペイロードにＵＰの以外の情報、即ち、パディングまたはインバンドフィールドが追加で存在することができる。
【０６２８】
本発明の実施形態によって、ＳＴＵＦＦＩの値が有する‘０’と‘１’が示す意味は互いに後先になることもできる。
【０６２９】
スタッフィングフィールドは、スタッフィングフィールドヘッダまたはスタッフィングデータ領域のうち、少なくとも１つを含むことができる。
【０６３０】
前記スタッフィングデータ領域は、スタッフィングデータまたはインバンドシグナリング情報のうち、少なくとも１つを含むことができる。
【０６３１】
前記スタッフィングフィールドヘッダは、実施形態によって２バイトでありうる。
【０６３２】
また、前記スタッフィングフィールドヘッダは、ＳＴＵＦＦ＿ＯＮＥ（または、ＰＡＤ＿ＯＮＥ）、ＳＴＵＦＦ＿ＴＹＰＥ（ＰＡＤ＿ＴＹＰＥ）、またはＳＴＵＦＦ＿ＬＥＮ（または、ＰＡＤ＿ＬＥＮ）のうち、少なくとも１つを含むことができる。
【０６３３】
図４４に図示された１ｓｔＢｙｔｅはスタッフィングフィールドの第１のバイトを示す。
【０６３４】
２ｎｄＢｙｔｅやはりスタッフィングフィールドに属することができる。実施形態によって、最初の２バイト（１ｓｔＢｙｔｅ及び２ｎｄＢｙｔｅ）がスタッフィングフィールドヘッダに該当することができる。
【０６３５】
実施形態によって第３のバイト（３ｒｄＢｙｔｅ）からはスタッフィングデータ領域に含まれるか、またはペイロードに含まれることができる。
【０６３６】
ＰＡＤ＿ＯＮＥフィールドは、実施形態によって、ＳＴＵＦＦ＿ＯＮＥフィールドで表現できる。
【０６３７】
ＳＴＵＦＦＩが‘１’の場合、ＳＴＵＦＦ＿ＯＮＥが確認できる。ＳＴＵＦＦ＿ＯＮＥはスタッフィングバイトの長さが１バイトか否かを示すことができる。ＳＴＵＦＦ＿ＯＮＥは１ビット（ｂｉｔ）のＭＳＢでありうる。ＳＴＵＦＦ＿ＯＮＥが１であれば、スタッフィングバイトの長さが１バイトでありうる。この場合、スタッフィングバイトの長さを表してくれるＳＴＵＦＦ＿ＬＥＮ＿ＬＳＢは使用されないことがある。
【０６３８】
また、ＳＴＵＦＦ＿ＬＥＮ＿ＭＳＢは全て０に設定できる。この場合、実施形態によってＳＴＵＦＦ＿ＬＥＮ＿ＭＳＢは全て１に設定されることもできる。即ち、実施形態によって１バイトのスタッフィングバイトが００００００００、１１１１１１１１、１０００００００、または０１１１１１１１の値を有することができる。
【０６３９】
ＳＴＵＦＦ＿ＯＮＥが０であれば、スタッフィングバイトの長さが１バイトより大きいことがある。
【０６４０】
この場合、２バイトのスタッフィングフィールドヘッダがスタッフィングデータ領域の長さ及びタイプを示すことに使用できる。
【０６４１】
ＳＴＵＦＦ＿ＯＮＥの値が示すところは、設計者によって互いに後先になることもできる。即ち、１と０が示す意味が互いに後先になることもできる。
【０６４２】
図示されたＳＴＵＦＦ＿ＯＮＥ（ＰＡＤ＿ＯＮＥ）は第１のバイトの第１のビットに位置できる。この位置は実施形態によって変更可能な事項である。ＳＴＵＦＦ＿ＯＮＥは実施形態によってＢＢフレームヘッダに位置することもできる。
【０６４３】
実施形態によってＳＴＵＦＦＩとＳＴＵＦＦ＿ＯＮＥの役割をする２ビットの１フィールドが設定できる。ＳＴＵＦＦＩとＳＴＵＦＦ＿ＯＮＥは各々１ビットであるので、２ビットの１フィールドを設定することによって、その役割に代えることができる。このフィールドはＢＢフレームヘッダに位置することも、スタッフィングフィールドに位置することもできる。
【０６４４】
ＰＡＤ＿ＬＥＮは、実施形態によって、ＳＴＵＦＦ＿ＬＥＮと呼ばれることができる。ＳＴＵＦＦ＿ＬＥＮはＳＴＵＦＦ＿ＬＥＮ＿ＭＳＢまたはＳＴＵＦＦ＿ＬＥＮ＿ＬＳＢのうち、少なくとも１つを含むことができる。
【０６４５】
ＳＴＵＦＦ＿ＬＥＮ＿ＭＳＢ及びＳＴＵＦＦ＿ＬＥＮ＿ＬＳＢは、各々５ビット、８ビットのフィールドでありうる。
【０６４６】
前記ＳＴＵＦＦ＿ＬＥＮ＿ＭＳＢ及びＳＴＵＦＦ＿ＬＥＮ＿ＬＳＢフィールドは、全体スタッフィングフィールド長さを示すことに使用できる。実施形態によって、ＳＴＵＦＦ＿ＬＥＮ＿ＭＳＢ及びＳＴＵＦＦ＿ＬＥＮ＿ＬＳＢの長さは互いに変わって、各々８ビット、５ビットでありうる。また、実施形態によって、両者の位置も互いに変わることができる。実施形態によって、パディングの長さを示すフィールドはスタッフィングデータ領域に位置することもできる。
【０６４７】
従来の場合、最初の２バイトを用いてパディングの長さを表現した。しかしながら、６４Ｋ ＬＤＰＣを使用する場合、パディングの長さは最大６３７０バイト（６４ｋ、５／６コードレート、ＢＣＨコード）の値を有するようになる。したがって、パディングの長さは１３ビット２^１３＝８１９２バイト）で十分に表現できる。
【０６４８】
したがって、本明細書で提案するＰＡＤ＿ＬＥＮは１３ビット（５＋８）を有することができる。
【０６４９】
このように、パディングの長さを１３ビットで表現する場合、最初の２バイトのうち、余分の２ビットが残ることができる。
【０６５０】
本明細書では、前記余分の２ビットをＰＡＤ＿ＴＹＰＥに割り当てて、パディング領域が他の用途（例えば、インバンドシグナリング）に使用される場合、そのタイプをシグナリングすることができる方法を提供する。
【０６５１】
ＳＴＵＦＦ＿ＴＹＰＥは、実施形態によって、ＰＡＤ＿ＴＹＰＥで表現できる。
【０６５２】
ＳＴＵＦＦ＿ＴＹＰＥは、前述したように、２ビットのフィールドとして、スタッフィングデータ（または、スタッフィングデータ領域）のタイプを示すことができる。
【０６５３】
図４２に示すように、ＳＴＵＦＦ＿ＴＹＰＥ値が‘００’の場合、スタッフィングデータ領域はスタッフィングデータのみを含むことができる。
【０６５４】
ＳＴＵＦＦ＿ＴＹＰＥ値が‘０１’の場合、特定の種類のインバンドシグナリング情報がスタッフィングデータと共にスタッフィングデータ領域に含まれることができる。
【０６５５】
ＳＴＵＦＦ＿ＴＹＰＥ値が‘１０’の場合、異なる種類のインバンドシグナリング情報がスタッフィングデータと共にスタッフィングデータ領域に含まれることができる。
【０６５６】
ＳＴＵＦＦ＿ＴＹＰＥ値が‘１１’の場合、特定の種類及び他の種類のインバンドシグナリング情報が全てスタッフィングデータと共にスタッフィングデータ領域に含まれることができる。
【０６５７】
ここで、特定の種類のインバンドシグナリング情報とは、‘インバンドＡ’を意味することができ、他の種類のインバンドシグナリング情報とは、‘インバンドＢ’を意味することができる。
【０６５８】
これは、一実施形態に過ぎず、ＳＴＵＦＦ＿ＴＹＰＥ値が指示するタイプ種類は多様な方式により変更できる。
【０６５９】
また、ＳＴＵＦＦ＿ＴＹＰＥはＢＢフレームペイロードまたはペイロードの構成を指示することができる。例えば、ペイロードのうち、切られていない完全な第１のパケットの位置が指示されることもできる。
【０６６０】
本明細書で提案するように、スタッフィングフィールドでシグナリングする場合、インバンドシグナリングを他の複数のフレームに挿入可能になる。また、インバンドシグナリング無しでパディングのみ入っている場合と区別が可能になる長所がある。
【０６６１】
ＳＴＵＦＦ＿ＴＹＰＥの位置は、実施形態によって、ＢＢフレームヘッダに位置することもできる。
【０６６２】
または、本実施形態のように、スタッフィングフィールドに位置することもできる。実施形態によって、ＳＴＵＦＦ＿ＴＹＰＥの長さは変更されることもできる。
【０６６３】
ＳＴＵＦＦ＿ＴＹＰＥの値が示すところは、設計者によって互いに後先になることもできる。
【０６６４】
例えば、００が示すところと１１が示すところとが互いに後先になることもできる。また、１０が示すところと０１が示すところとが互いに後先になることもできる。
【０６６５】
スタッフィングデータは、実施形態によって、全て０または全て１の値を有することができる。
【０６６６】
以下、図４２に図示されたｃａｓｅ＃１からｃａｓｅ＃６について具体的に説明する。
【０６６７】
１）Ｃａｓｅ＃１は、ＢＢフレームにスタッフィングデータ及びインバンドシグナリングが含まれない場合を示す。
【０６６８】
この場合、ＳＴＵＦＦＩフィールドは‘０’に設定できる。したがって、ＢＢフレームの構造はＢＢフレームヘッダの直後のデータ領域、即ち、ペイロードが位置することができる。
【０６６９】
２）Ｃａｓｅ＃２は、ＢＢフレームに１バイトのスタッフィングフィールドが存在し、インバンドシグナリングが存在しない場合を示す。
【０６７０】
この場合、ＳＴＵＦＦＩフィールドは‘１’に設定できる。即ち、ＢＢフレームはスタッフィングフィールドを含み、前記スタッフィングフィールドは１バイトの大きさを有することができる。
【０６７１】
ここで、前記スタッフィングフィールドの第１のビットはＳＴＵＦＦ＿ＯＮＥフィールドを表し、前記スタッフィングフィールドの大きさが１バイトであるので、‘１’の値を有する。
【０６７２】
前記スタッフィングフィールドの残りの７個のビットは１１１１１１１の値を有することができる。
【０６７３】
したがって、１ｂｙｔｅのスタッフィングフィールドは１１１１１１１１で表現できる。
【０６７４】
３）Ｃａｓｅ＃３は、ＢＢフレームに１バイトより大きいスタッフィングフィールドが存在し、インバンドシグナリングが存在しない場合を示す。
【０６７５】
即ち、前記スタッフィングフィールドは２バイトまたは２バイトより大きいことがある。
【０６７６】
スタッフィングフィールドが存在するので、ＳＴＵＦＦＩフィールドは‘１’に設定できる。
【０６７７】
前記スタッフィングフィールドは、２バイトのスタッフィングフィールドヘッダを有することができる。前記スタッフィングフィールドヘッダの第１のバイトの第１のビットはＳＴＵＦＦ＿ＯＮＥフィールドに該当する。
【０６７８】
前記ＳＴＵＦＦ＿ＯＮＥフィールドは、前記スタッフィングフィールドの大きさが１バイトより大きいので‘０’値に設定できる。
【０６７９】
前記スタッフィングフィールドヘッダの第１のバイトの第２及び第３のビットはＳＴＵＦＦ＿ＴＹＰＥフィールドに該当する。
【０６８０】
ＢＢフレームのスタッフィングデータ領域にスタッフィングデータのみがある場合であるので、前述したように、ＳＴＵＦＦ＿ＴＹＰＥは００の値を有することができる。
【０６８１】
本図面では、他の実施形態として、ＳＴＵＦＦ＿ＴＹＰＥが１１値を有する場合が図示されている。
【０６８２】
即ち、この場合はＢＢフレームのスタッフィングデータ領域にスタッフィングデータのみがある場合であって、ＳＴＵＦ＿ＴＹＰＥフィールドが１１値として指示できる。
【０６８３】
この後、スタッフィングフィールドヘッダのＳＴＵＦＦ＿ＬＥＮ＿ＭＳＢ及びＳＴＵＦＦ＿ＬＥＮ＿ＬＳＢがスタッフィングフィールドの長さ情報を有することができる。前述したように、スタッフィングフィールドの長さは総１３ビットを用いて表現できる。ＳＴＵＦＦ＿ＬＥＮ＿ＭＳＢ及びＳＴＵＦＦ＿ＬＥＮ＿ＬＳＢのその後にはスタッフィングデータ領域が位置することができる。このケースで、スタッフィングデータ領域にはスタッフィングデータのみ来ることができる。
【０６８４】
（４）Ｃａｓｅ＃４は、ＢＢフレームに１バイトより大きいスタッフィングフィールドが存在し、インバンドＡシグナリングが存在する場合を示す。
【０６８５】
この場合、ＢＢフレームのスタッフィングデータ領域にはスタッフィングデータ及びインバンドＡシグナリングが存在することができる。
【０６８６】
前記インバンドＡシグナリングは、前述した特定の種類のインバンドシグナリングを意味することができる。この場合、スタッフィングフィールドが存在するので、ＳＴＵＦＦＩは１の値を有することができる。
【０６８７】
前記スタッフィングフィールドヘッダの第１のバイトの第１のビットはＳＴＵＦＦ＿ＯＮＥフィールドであって、スタッフィングフィールドの大きさが１バイトより大きいので‘０’の値を有することができる。
【０６８８】
スタッフィングフィールドヘッダの第１のバイトの第２、第３のビットは前述したＳＴＵＦＦ＿ＴＹＰＥフィールドでありうる。
【０６８９】
ＢＢフレームのスタッフィングデータ領域にインバンドＡシグナリングが存在する場合であるので、前述したように、ＳＴＵＦＦ＿ＴＹＰＥは１０の値を有することができる。実施形態によって、この値は０１でありうる。
【０６９０】
この後、スタッフィングフィールドヘッダのＳＴＵＦＦ＿ＬＥＮ＿ＭＳＢ及びＳＴＵＦＦ＿ＬＥＮ＿ＬＳＢがスタッフィングフィールドの長さ情報を有することができる。前述したように、スタッフィングフィールドの長さは総１３ビットを用いて表現できる。ＳＴＵＦＦ＿ＬＥＮ＿ＭＳＢ及びＳＴＵＦＦ＿ＬＥＮ＿ＬＳＢのその後にはスタッフィングデータ領域が位置することができる。このケースで、スタッフィングデータ領域にはスタッフィングデータの他にもインバンドＡシグナリングが存在することができる。
【０６９１】
（５）Ｃａｓｅ＃５は、ＢＢフレームに１バイトより大きいスタッフィングフィールドが存在し、インバンドＢシグナリングが存在する場合でありうる。
【０６９２】
この場合、ＢＢフレームのスタッフィングデータ領域にはスタッフィングデータ及びインバンドＢシグナリングが存在することができる。
【０６９３】
前記インバンドＢシグナリングとは、前述した他の種類のインバンドシグナリングを意味することができる。この場合、スタッフィングフィールドが存在するので、ＳＴＵＦＦＩは１の値を有することができる。
【０６９４】
スタッフィングフィールドヘッダの第１のバイトの第１のビットはＳＴＵＦＦ＿ＯＮＥフィールドであって、スタッフィングフィールドの大きさが１バイトより大きいので、０の値を有することができる。
【０６９５】
スタッフィングフィールドヘッダの第１のバイトの第２及び第３のビットは前述したＳＴＵＦＦ＿ＴＹＰＥフィールドでありうる。ＢＢフレームのスタッフィングデータ領域にインバンドＢシグナリングが存在する場合であるので、前述したように、ＳＴＵＦＦ＿ＴＹＰＥは０１の値を有することができる。実施形態によって、この値は１０でありうる。
【０６９６】
この後、スタッフィングフィールドヘッダのＳＴＵＦＦ＿ＬＥＮ＿ＭＳＢ及びＳＴＵＦＦ＿ＬＥＮ＿ＬＳＢがスタッフィングフィールドの長さ情報を有することができる。前述したように、スタッフィングフィールドの長さは総１３ビットを用いて表現できる。ＳＴＵＦＦ＿ＬＥＮ＿ＭＳＢ及びＳＴＵＦＦ＿ＬＥＮ＿ＬＳＢのその後には、スタッフィングデータ領域が位置することができる。このケースで、スタッフィングデータ領域にはスタッフィングデータの他にもインバンドＢシグナリングが存在することができる。
【０６９７】
（６）Ｃａｓｅ＃６は、ＢＢフレームに１バイトより大きいスタッフィングフィールドが存在し、インバンドＡ及びＢシグナリングが存在する場合でありうる。
【０６９８】
この場合、ＢＢフレームのスタッフィングデータ領域には、スタッフィングデータ及びインバンドＡ及びＢシグナリングが全て存在することができる。
【０６９９】
この場合、ＳＴＵＦＦＩは１の値を有することができる。スタッフィングフィールドヘッダの第１のバイトの第１のビットはＳＴＵＦＦ＿ＯＮＥフィールドであって、スタッフィングフィールドの大きさが１バイトより大きいので、０の値を有することができる。スタッフィングフィールドヘッダの第１のバイトの第２、第３のビットは、前述したＳＴＵＦＦ＿ＴＹＰＥフィールドでありうる。ＢＢフレームのスタッフィングデータ領域にインバンドＡ及びＢシグナリングが存在する場合であるので、前述したように、ＳＴＵＦＦ＿ＴＹＰＥは１１の値を有することができる。
【０７００】
本図面では、他の実施形態として、ＳＴＵＦＦ＿ＴＹＰＥこの００値を有する場合が図示されている。即ち、この場合はスタッフィングデータ領域にインバンドＡ及びＢシグナリングが全て存在する場合が、ＳＴＵＦ＿ＴＹＰＥフィールドが００値として指示できる。
【０７０１】
この後、スタッフィングフィールドヘッダのＳＴＵＦＦ＿ＬＥＮ＿ＭＳＢ及びＳＴＵＦＦ＿ＬＥＮ＿ＬＳＢがスタッフィングフィールドの長さ情報を有することができる。前述したように、スタッフィングフィールドの長さは総１３ビットを用いて表現できる。
【０７０２】
ＳＴＵＦＦ＿ＬＥＮ＿ＭＳＢ及びＳＴＵＦＦ＿ＬＥＮ＿ＬＳＢのその後にはスタッフィングデータ領域が位置することができる。このケースで、スタッフィングデータ領域にはスタッフィングデータの他にもインバンドＡ及びＢシグナリングが存在することができる。
【０７０３】
図４３は、本明細書で提案するＢＢフレーム構造の更に他の一例を示す図である。
【０７０４】
図４３（ａ）はパディング、即ちスタッフィングデータ無しでデータのみがある場合のＢＢフレームでありうる。
【０７０５】
ＢＢフレームヘッダのＳＴＵＦＦＩが０の値を有していることができる。ＢＢフレームヘッダの後にスタッフィングフィールド無しで、直ぐペイロードが位置することが分かる。図４２のＣａｓｅ＃１に該当することができる。
【０７０６】
図４３（ｂ）は、１バイトのパディングを有する場合でありうる。
【０７０７】
この場合、ＢＢフレームヘッダのＳＴＵＦＦＩが１の値を有することができる。第１のバイトの第１のビットはＳＴＵＦＦ＿ＯＮＥとして１の値を有することができる。これは、パディングが１バイトであることを意味することができる。図４３で、パディングの各ビットは１１１１１１１１の値を有することができる（０ｘＦＦ）。または、実施形態によって１０００００００の値を有することもできる。図４２のＣａｓｅ＃２に該当することができる。
【０７０８】
図４３（ｃ）は、ｎバイトのパディングを有する場合でありうる。
【０７０９】
この場合、ＢＢフレームヘッダのＳＴＵＦＦＩが１の値を有することができる。また、ＳＴＵＦＦ＿ＯＮＥは０の値を有することができる。ＳＴＵＦＦ＿ＴＹＰＥはインバンドシグナリング無しで、スタッフィングデータのみ使用されいるという点を指示することができる。
【０７１０】
即ち、実施形態によって、ＳＴＵＦＦ＿ＴＹＰＥは００の値を有することができる。
【０７１１】
その後、残りの１３ビットはスタッフィングフィールドの長さがｎバイトであることを指示することができる。この１３ビットは、ＳＴＵＦＦ＿ＬＥＮ＿ＭＳＢ及びＳＴＵＦＦ＿ＬＥＮ＿ＬＳＢでありうる。ＳＴＵＦＦ＿ＬＥＮ＿ＭＳＢ及びＳＴＵＦＦ＿ＬＥＮ＿ＬＳＢの後には、スタッフィングデータが来ることができる。図４２のＣａｓｅ＃３のうち、スタッフィングフィールドが３バイト以上の場合に該当することができる。
【０７１２】
図４３（ｄ）は、インバンドＡシグナリングと共にｎバイトのパディングを有する場合でありうる。
【０７１３】
この場合、ＢＢフレームヘッダのＳＴＵＦＦＩが１の値を有することができる。また、ＳＴＵＦＦ＿ＯＮＥは０の値を有することができる。ＳＴＵＦＦ＿ＴＹＰＥはインバンドＡシグナリングが使用されいることを指示することができる。
【０７１４】
即ち、実施形態によってＳＴＵＦＦ＿ＴＹＰＥは０１の値を有することもできる。ＳＴＵＦＦ＿ＴＹＰＥの値自体は前述したように変更できる。その後、残りの１３ビットはスタッフィングフィールドの長さがｎバイトであることを指示することができる。この１３ビットはＳＴＵＦＦ＿ＬＥＮ＿ＭＳＢ及びＳＴＵＦＦ＿ＬＥＮ＿ＬＳＢでありうる。ＳＴＵＦＦ＿ＬＥＮ＿ＭＳＢ及びＳＴＵＦＦ＿ＬＥＮ＿ＬＳＢの後にはインバンドＡシグナリングデータが来ることができる。図３８のＣａｓｅ＃４に該当することができる。
【０７１５】
図４３（ｅ）は、インバンドＢシグナリングと共にｎバイトのパディングを有する場合でありうる。
【０７１６】
この場合、ＢＢフレームヘッダのＳＴＵＦＦＩが１の値を有することができる。また、ＳＴＵＦＦ＿ＯＮＥは０の値を有することができる。ＳＴＵＦＦ＿ＴＹＰＥはインバンドＢシグナリングが使用されいることを指示することができる。
【０７１７】
即ち、実施形態によってＳＴＵＦＦ＿ＴＹＰＥは１０の値を有することもできる。ＳＴＵＦＦ＿ＴＹＰＥの値自体は前述したように変更できる。
【０７１８】
その後、残りの１３ビットはスタッフィングフィールドの長さがｎバイトであることを指示することができる。
【０７１９】
この１３ビットはＳＴＵＦＦ＿ＬＥＮ＿ＭＳＢ及びＳＴＵＦＦ＿ＬＥＮ＿ＬＳＢでありうる。ＳＴＵＦＦ＿ＬＥＮ＿ＭＳＢ及びＳＴＵＦＦ＿ＬＥＮ＿ＬＳＢの後にはインバンドＢシグナリングデータが来ることができる。図４２のＣａｓｅ＃５に該当することができる。
【０７２０】
図４３（ｆ）は、インバンドＡ及びＢシグナリングと共にｎバイトのパディングを有する場合でありうる。
【０７２１】
この場合、ＢＢフレームヘッダのＳＴＵＦＦＩが１の値を有することができる。また、ＳＴＵＦＦ＿ＯＮＥは０の値を有することができる。ＳＴＵＦＦ＿ＴＹＰＥはインバンドＡ及びＢシグナリングが全て使用されていることを指示することができる。
【０７２２】
即ち、実施形態によって、ＳＴＵＦＦ＿ＴＹＰＥは１１の値を有することもできる。ＳＴＵＦＦ＿ＴＹＰＥの値自体は前述したように変更できる。その後、残りの１３ビットはスタッフィングフィールドの長さがｎバイトであることを指示することができる。この１３ビットはＳＴＵＦＦ＿ＬＥＮ＿ＭＳＢ及びＳＴＵＦＦ＿ＬＥＮ＿ＬＳＢでありうる。ＳＴＵＦＦ＿ＬＥＮ＿ＭＳＢ及びＳＴＵＦＦ＿ＬＥＮ＿ＬＳＢの後にはインバンドＡ及びＢシグナリングデータが来ることができる。図３８のＣａｓｅ＃６に該当することができる。
【０７２３】
図４４は、本明細書で提案するＢＢフレーム構造の更に他の一例を示す図である。
【０７２４】
図４４は、スタッフィングフィールド（Stuffing field）がＢＢフレームの端（ペイロードの後）に位置する場合のＢＢフレーム構造の一例を示す。
【０７２５】
ＢＢフレームはＢＢＦヘッダ及びＢＢフレームペイロードを含む。
【０７２６】
前記ＢＢＦヘッダは、ＢＢＦデータフィールドのフォーマットを示すためにＢＢＦフレームペイロードの前に挿入される。
【０７２７】
前記ＢＢＦヘッダは２ｂｙｔｅｓ（バイト）の固定された長さを有することができる。
【０７２８】
前記ＢＢＦヘッダは、ＢＢフレームにスタッフィング（Stuffing）またはパディングがあるか否かを示すインジケータに該当するＳＴＵＦＦＩフィールドを含む。前記ＳＴＵＦＦＩフィールドは１ｂｉｔで表現できる。
【０７２９】
前記ＢＢフレームペイロードは、スタッフィングフィールド及びペイロードを含むことができる。
【０７３０】
前記スタッフィングフィールドは、前記ＢＢフレームペイロードにＵＰが全て詰められない場合に含まれる。
【０７３１】
一例に、前記ＳＴＵＦＦＩフィールドが‘１’に設定される場合、前記ＢＢフレームペイロードは前記スタッフィングフィールドを含むことができる。
【０７３２】
前記ペイロードは、ＵＰ（User Packet）が含まれる領域をいう。
【０７３３】
前記スタッフィングフィールドは、スタッフィングヘッダフィールド（または、スタッフィングフィールドヘッダ）及びスタッフィングデータ（領域）で構成できる。
【０７３４】
前記スタッフィングデータ領域は、スタッフィングデータフィールドまたはスタッフィングデータで表現できる。
【０７３５】
前記スタッフィングデータ領域にはスタッフィングデータ、インバンドシグナリング情報などが含まれることができる。
【０７３６】
前記スタッフィングヘッダフィールドは、ＳＴＵＦＦ＿ＯＮＥフィールド、ＳＴＵＦＦ＿ＴＹＰＥフィールド、及びＳＴＵＦＦ＿ＬＥＮフィールドを含むことができる。
【０７３７】
前記ＳＴＵＦＦ＿ＬＥＮフィールドは前記スタッフィングヘッダフィールドを含む全体スタッフィングフィールドの長さを示し、ＳＴＵＦＦ＿ＬＥＮ＿ＭＳＢフィールド及びＳＴＵＦＦ＿ＬＥＮ＿ＬＳＢフィールドを含むことができる。前記ＳＴＵＦＦ＿ＬＥＮフィールドは１３ｂｉｔ(ビット）で表現される。
【０７３８】
前記ＳＴＵＦＦ＿ＯＮＥフィールドは、前記スタッフィングフィールドの長さが１ｂｙｔｅか否かを示す１ｂｉｔのフィールドをいう。
【０７３９】
一例に、前記ＳＴＵＦＦ＿ＯＮＥフィールドが‘１’に設定された場合、前記スタッフィングフィールドの長さは１ｂｙｔｅであることを示す。この場合、前記ＳＴＵＦＦ＿ＬＥＮ＿ＬＳＢフィールドは、前記スタッフィングフィールド、即ちＳＴＵＦＦ＿ＬＥＮフィールドに含まれない。
【０７４０】
仮に、前記ＳＴＵＦＦ＿ＯＮＥフィールドが‘０’に設定された場合、前記スタッフィングフィールドの長さは１ｂｙｔｅより大きいことを示す。この場合、前記スタッフィングヘッダの２ｂｙｔｅｓはスタッフィングデータのタイプと長さを示すために使用される。
【０７４１】
即ち、前記ＳＴＵＦＦ＿ＴＹＰＥフィールドは、スタッフィングデータのタイプを示し、２ビットで表現できる。
【０７４２】
以下の＜表３４＞は、図４４のＳＴＵＦＦ＿ＴＹＰＥフィールドの一例を示す。
【０７４３】
【表３４】
0006392463.tif 000069
【０７４４】
＜表３４＞及び図４４を参照すると、ＳＴＵＦＦ＿ＴＹＰＥフィールドが（１）‘００’に設定された場合、スタッフィングデータ領域はスタッフィングデータのみに使用され、（２）‘０１’に設定された場合、スタッフィングデータ領域はインバンドＡシグナリング情報とスタッフィングデータに使用され、（３）‘１０’に設定された場合、スタッフィングデータ領域はインバンドＢシグナリング情報とスタッフィングデータに使用され、（４）‘１１’に設定された場合、スタッフィングデータ領域はインバンドＡシグナリング情報、インバンドＢシグナリング情報、及びスタッフィングデータに使用される。
【０７４５】
＜表３４＞で、インバンドＡはインバンドＩＳＳＹであり、インバンドＢはインバンドＰＬＳでありうる。
【０７４６】
前記ＳＴＵＦＦ＿ＬＥＮ＿ＭＳＢフィールドは、前記スタッフィングヘッダフィールドを含む全体スタッフィングフィールド長さのＭＳＢ（Most Significant Bit）値を示し、５ｂｉｔで表現される。
【０７４７】
一例に、ＳＴＵＦＦ＿ＯＮＥフィールドが‘１’に設定された場合、前記ＳＴＵＦＦ＿ＬＥＮ＿ＭＳＢフィールドは‘１１１１１’で表現できる。または、‘０００００’に設定されることもできる。
【０７４８】
前記ＳＴＵＦＦ＿ＬＥＮ＿ＬＳＢフィールドは、全体スタッフィングフィールド長さのＬＳＢ（Least Significant Bit）値を示し、８ビットで表現される。
【０７４９】
前記スタッフィングデータフィールドはスタッフィング及び／又はインバンドシグナリングフィールドを含むことができる。
【０７５０】
ここで、‘スタッフィング及び／又はインバンドシグナリング’は、スタッフィング、インバンド シグナリング、またはスタッフィング及びインバンドシグナリングを意味する。
【０７５１】
即ち、‘Ａ及び／又はＢ’の表現はＡまたはＢのうち、少なくともいずれか１つの意味と同一でありうる。
【０７５２】
図４４を参照すると、スタッフィングフィールドのＮｔｈ Ｂｙｔｅの第８のビットはＳＴＵＦＦ＿ＯＮＥフィールドを示し、Ｎｔｈ Ｂｙｔｅの第６及び第７のビットはＳＴＵＦＦ＿ＴＹＰＥフィールドを示し、スタッフィングフィールドのＮｔｈ Ｂｙｔｅの第１のビット乃至第５のビットはＳＴＵＦＦ＿ＬＥＮ＿ＬＳＢフィールドを示し、スタッフィングフィールドの（Ｎ−１）ｔｈ ＢｙｔｅはＳＴＵＦＦ＿ＬＥＮ＿ＭＳＢフィールドを示すことを見ることができる。
【０７５３】
また、スタッフィングフィールドの（Ｎ−２）ｔｈ Ｂｙｔｅからデータ（ＵＰ）またはスタッフィングデータまたはインバンドＡデータまたはインバンドＢデータ、またはインバンドＡ及びＢデータを示すことを見ることができる。
【０７５４】
図４４のＣａｓｅ＃１乃至Ｃａｓｅ＃６に対するより具体的な説明は、各々対応する図４２のＣａｓｅ＃１乃至Ｃａｓｅ＃６の説明を参照する。
【０７５５】
図４４のフレーム構造は、図４２のフレーム構造と同一な機能を遂行することができる。
【０７５６】
図４４に図示されたＢＢフレーム構造のように、スタッフィングフィールドがＢＢフレームの端に位置する場合、受信装置でスタッフィング確認無しでＵＰ（User Packet）を直ぐ受信することができるので、ＵＰに対するアクセス時間が図３８に図示されたＢＢフレーム構造に比べて短くなる効果がある。
【０７５７】
図４５は、本明細書で提案するＢＢフレーム構造の更に他の一例を示す図である。
【０７５８】
図４５は、スタッフィングフィールドがＢＢフレームの最後に位置（または、ペイロード、ＦＥＣフレームの後に位置）する場合の多様なＢＢフレーム構造を示す。
【０７５９】
図４５のフレーム構造は、図４３のフレーム構造とスタッフィングフィールドの位置のみ異なり、他の部分は全て同一であるので、図４５に対する具体的な説明は、図４３を参照する。
【０７６０】
図４６は、多様なＢＢフレーム構造でＢＢフレーム送信に対するオーバーヘッドを計算した結果を比較して示す図である。
【０７６１】
ＤＶＢ−Ｔ２で表記されたグラフは、前述した従来技術のオーバーヘッドグラフでありうる。ＤＶＢ−Ｔ２とは、ＤＶＢ（Digital Video Broadcasting）の地上波ＴＶ放送システム（terrestrial television broadcasting system）関連標準を意味することができる。ＤＶＢ−Ｔ２とは、ヨーロッパの次世代地上波放送に関連した標準を意味することができる。ＤＶＢ−Ｔ２で表記されたグラフは、この標準技術に従うＢＢフレームにおいて、そのオーバーヘッドを計算したグラフでありうる。
【０７６２】
ＭＨで表記されたグラフは、前述した他の従来技術のオーバーヘッドグラフでありうる。ＭＨとは、ＣＥＡ（Consumer Electronics Association）のモバイル／ハンドヘルド（Mobile／Handheld）ＤＴＶシステム関連標準を意味することがきる。ＭＨとは、北−米モバイルハンドヘルド（mobile handheld）関連標準を意味することができる。ＭＨで表記されたグラフは、この標準技術に従うＢＢフレームにおいて、そのオーバーヘッドを計算したグラフでありうる。
【０７６３】
ＳＳ ＆ ＳＮで表記されたグラフは、前述した更に他の従来技術のオーバーヘッドグラフでありうる。ＳＳ ＆ ＳＮは、従来技術のうちの１つを意味することができる。この従来技術で提示する方法によりＢＢフレーム及びＢＢフレームヘッダを構成した時のオーバーヘッドを計算したグラフが、ＳＳ ＆ ＳＮで表記されたグラフで図示されている。
【０７６４】
以下の＜表３５＞は各ＢＢフレーム送信時、オーバーヘッドを計算した結果を示した表である。
【０７６５】
【表３５】
0006392463.tif 000070
【０７６６】
オーバーヘッドは、データフィールドの長さを示すフィールドのオーバーヘッドを意味することができる。
【０７６７】
従来技術は毎ＢＢフレームに２バイトのフィールドを使用するので、オーバーヘッドを最大０．２２％有することができる。
【０７６８】
他の従来技術は１ビットのフィールドのみを使用するので、オーバーヘッドを最大０．０１３９％のみを有することができる。最も低い場合でありうる。
【０７６９】
更に他の従来技術は２ビットのフィールドを使用することができる。この場合、オーバーヘッドは他の従来技術に比べて２倍でありうる。
【０７７０】
ＬＧで表記されたグラフは、本発明によるオーバーヘッドグラフでありうる。本発明の場合、スタッフィングフィールドのシグナリングのために１ビットのフィールドのみを使用することができる。したがって、オーバーヘッドが最小になることができる。また、追加的に余分の２ビットフィールドを設けることによって、インバンドシグナリングのタイプなどを指示することに活用できるという長所がある。本発明はこの余分のフィールドを用いて、ＢＢフレームの構成を示すなど、他の用途にも利用可能な構造をサポートすることができる。
【０７７１】
図４７は、従来のＢＢフレーム構造の一例を示す。
【０７７２】
図４７に示すように、ＢＢフレームはヘッダ、オプショナルヘッダ、及びペイロードデータを含んで構成される。
【０７７３】
前記ヘッダは、ＰＳＰＭＩ（Packet Start Pointer Mode Indicator）フィールド、ＰＡＤＩ（Padding Indicator）フィールド、ＰＫＴＳＰＴＲ＿ＬＳＢ（Packet Start Pointer Low Significant Bits）フィールドを含む。
【０７７４】
前記ＰＳＰＭＩフィールドは、ＰＫＴＳＰＴＲ（Packet Start Pointer）フィールドがショートモード（short mode）か、またはロングモード（long mode）かを示す１ｂｉｔの大きさのフラグフィールドをいう。
【０７７５】
前記ＰＫＴＳＰＴＲ（Packet Start Pointer）フィールドはＳＹＮＣＤフィールドと同一な概念でありうる。
【０７７６】
即ち、前記ＰＳＰＭＩフィールドはＰＫＴＳＰＴＲ（Packet Start Pointer）フィールドの長さが短いか長いかを表示してくれるフラグをいう。
【０７７７】
前記ＰＫＴＳＰＴＲ＿ＬＳＢ（Packet Start Pointer Low Significant Bits）フィールドは、１３ｂｉｔのＰＫＴＳＰＴＲ（Packet Start Pointer）フィールドの５ＬＳＢ ｂｉｔｓを示す。
【０７７８】
前記オプショナルヘッダは、ＰＫＴＳＰＴＲ＿ＭＳＢ（Packet Start Pointer Most Significant Bits）フィールド、パディング（PADDING）フィールドを含むことができる。
【０７７９】
前記ＰＫＴＳＰＴＲ＿ＭＳＢフィールドは、１３ｂｉｔのＰＫＴＳＰＴＲ（Packet Start Pointer）フィールドの８ＭＳＢ ｂｉｔｓを示す。
【０７８０】
また、前記パディングフィールドはＰＡＤＬ（Padding data Length）フィールド及びＰＡＤＤＩＮＧ＿ＤＡＴＡフィールドを含むことができる。
【０７８１】
前記ＰＡＤＬフィールドはパディングデータフィールドの長さを示し、１６ｂｉｔの大きさを有する。
【０７８２】
前記ＰＡＤＤＩＮＧ＿ＤＡＴＡフィールドは可変的な長さを有し、パディング情報を示す。
【０７８３】
図４７に示すように、ＢＢフレーム構造は最大１３ｂｙｔｅの（Payload）データフィールドの長さを表現するために、前記データフィールドの長さを示す情報（例：ＤＦＬ）を使用せず、ＰＡＤＤＩＮＧフィールドの長さを送信して受信装置でデータフィールドの長さを計算するようになっている。
【０７８４】
ここで、前記パディングフィールドの長さはＢＢフレームのペイロードデータサイズ−データフィールド長さに該当する。
【０７８５】
ＢＢフレームにパディングフィールドが存在しない場合にはＢＢフレームサイズを用いてＤＦＬ（data Field Length）を計算する。
【０７８６】
前記ＢＢフレームにパディングフィールドがある場合にはＢＢフレームヘッダに２ｂｉｔのＰＡＤＩを含むことによって、パディングの長さを知らせるようになる。
【０７８７】
より効率的に、ＦＥＣブロックにＢＢＦ（BaseBand Frame）を送信するために、即ちＢＢフレームヘッダ送信に対するオーバーヘッドを減らすために、ＰＫＴＳＰＲＴフィールドをＰＫＴＳＰＴＲ＿ＬＳＢ及びＰＫＴＳＰＴＲ＿ＭＳＢに分けて運用する。
【０７８８】
即ち、ＰＫＴＳＰＴＲフィールドは２ｂｙｔｅの大きさまでサポート可能であるが、前記ＰＫＴＳＰＴＲフィールドの長さが短い場合（≦３１ｂｙｔｅ）、ＰＫＴＳＰＴＲ＿ＬＳＢのみ使用することができるので、前記ＰＫＴＳＰＴＲフィールドの送信大きさを１ｂｙｔｅに減らすことができる。
【０７８９】
しかしながら、ＰＫＴＳＰＴＲ＿ＬＳＢの長さが５ｂｉｔと短いため、ＰＫＴＳＰＴＲフィールドの大きさが３１ｂｙｔｅ以下の場合のみに１ｂｙｔｅのＢＢＦヘッダ構成が可能であるという短所がある。
【０７９０】
図３９で説明したように、従来のＢＢフレームはＢＢフレームのデータフィールドの長さを受信装置（または、受信端）に知らせるためにＤＦＬ（data field length：１６ビット、１１ビット）をＢＢフレームヘッダごとに割り当てて使用しているので、ＢＢフレームをＦＥＣブロックに送信するに当たってオーバーヘッドが大きく発生する。
【０７９１】
したがって、ＢＢフレームヘッダに対する送信効率を高めて、エラー確認（error check）の新たな機能を追加するための新たなＢＢフレーム構造について具体的に説明する。
【０７９２】
即ち、本明細書はＢＢフレームヘッダに含まれるＳＹＮＣＤフィールドの大きさを調節して全体的にＢＢフレームヘッダの大きさを減らす方法、ＢＢフレームヘッダ内の余分の１ｂｉｔを活用してエラー確認を遂行する方法などを提供する。
【０７９３】
以下、本明細書で提案する方法及びＢＢフレーム構造は、送信装置ではＢＢフレームヘッダ挿入（BB Frame Header Insertion）ブロックで、受信装置ではＢＢフレームヘッダパーサ（BB Frame Header Parser）ブロックで動作する。
【０７９４】
図４８は、本明細書における提案するＢＢフレーム構造の一例を示す図である。
【０７９５】
図４８ａのインプットストリームはインプットフォーマッティングモジュールのモードアダプテーション（mode adaptation）モジュールを通じて図４８ｂのＢＢフレーム構造を形成する。
【０７９６】
図４８に示すように、複数のパケットを含むインプットストリームはモードアダプテーションモジュールを通じてペイロード（Payload）にスライシング（slicing）またはマッピングされ、前記ペイロードの前に前記ペイロードと関連した情報を含むヘッダが付加される。
【０７９７】
前記ペイロードは、ＢＢフレームデータフィールドで表現できる。
【０７９８】
前記ヘッダは、ＯＰＴＩＯＮＩフィールド、ＳＴＵＦＦＩフィールド、ＳＹＮＣＤ＿ＬＳＢフィールド、ＳＹＮＣＤ＿ＭＳＢフィールド、Checksumフィールド、またはStuffingフィールドのうち、少なくとも１つを含んで構成できる。
【０７９９】
前述したように、前記Stuffingフィールドは、Stuffing Headerフィールド及びStuffing Byteフィールドを含むことができる。
【０８００】
前記Stuffing Byteフィールドは、スタッフィングデータフィールドまたはスタッフィングデータ領域で表現されることもできる。
【０８０１】
前記ＯＰＴＩＯＮＩフィールド、ＳＴＵＦＦＩフィールド、及びＳＹＮＣＤ＿ＬＳＢフィールドを含むＢＢフレームヘッダが定義されることもでき、ＳＹＮＣＤ＿ＭＳＢフィールド及びChecksumフィールドを含むオプションヘッダが定義されることもできる。
【０８０２】
図４８の場合、ＢＢフレームヘッダ及びオプションヘッダが定義されたことを見ることができる。
【０８０３】
また、前記スタッフィングフィールドは前記ヘッダに含まれることもでき、前記ヘッダに含まれないこともできる。
【０８０４】
前記スタッフィングフィールドが前記ヘッダに含まれない場合には、前記ペイロードと共にＢＢフレームペイロードを構成することができる。
【０８０５】
前記スタッフィングフィールドはペイロードの前に位置するか（図４８）、または前記ペイロードの後に位置することもできる。
【０８０６】
ＳＹＮＣＤフィールドは、データフィールドの開始から前記データフィールドで始まる最初に送信されるＵＰ（User Packet）の開始までの距離を示すことができる。
【０８０７】
ここで、前記ＳＹＮＣＤフィールドはＳＹＮＣＤ＿ＬＳＢフィールド及びＳＹＮＣＤ＿ＭＳＢフィールドに区分されることができ、１３ｂｉｔの大きさを有する。
【０８０８】
前記ＳＹＮＣＤ＿ＬＳＢフィールドはＳＹＮＣＤのＬＳＢ（Least Significant bit）を示す値で、６ｂｉｔｓの大きさを有し、最大６３ｂｙｔｅのＳＹＮＣＤを表現することができる。
【０８０９】
図４８に示すように、ヘッダがＢＢフレームヘッダとオプションヘッダに区分される場合、前記ＳＹＮＣＤ＿ＬＳＢフィールドは前記ＢＢフレームヘッダに含まれることができる。
【０８１０】
また、前記ＳＹＮＣＤ＿ＭＳＢフィールドはＳＹＮＣＤのＭＳＢ（Most Significant bit）を示す値で、７ｂｉｔｓの大きさを有する。
【０８１１】
図４８に示すように、ヘッダがＢＢフレームヘッダとオプションヘッダに区分される場合、前記ＳＹＮＣＤ＿ＭＳＢフィールドは前記オプションヘッダに含まれることができる。
【０８１２】
前記ＳＹＮＣＤ＿ＭＳＢフィールドはＯＰＴＩＯＮＩフィールドにより使用有無が定まる。
【０８１３】
前記ＯＰＴＩＯＮＩフィールドはペイロードを通じて送信されるパケットのうち、新しく始まるパケットの位置がＳＹＮＣＤ＿ＬＳＢ（６ビット）で表現できるか否かを示す。
【０８１４】
一例に、前記ＯＰＴＩＯＮＩフィールドが‘０’に設定された場合、ペイロードを通じて送信されるパケットのうち、新しく始まるパケットの位置がＳＹＮＣＤ＿ＬＳＢ（６ビット）で表現できることを示す。
【０８１５】
前記ＯＰＴＩＯＮＩフィールドが‘１’に設定された場合、ペイロードを通じて送信されるパケットのうち、新しく始まるパケットの位置がＳＹＮＣＤ＿ＬＳＢ（６ビット）で表現できない場合を示す。
【０８１６】
したがって、前記ＯＰＴＩＯＮＩフィールドが‘１’に設定された場合、ＳＹＮＣＤ＿ＬＳＢフィールド（６ビット）及びＳＹＮＣＤ＿ＭＳＢフィールド（７ビット）を用いてペイロード内の新しく始まるパケットの位置を示さなければならない。
【０８１７】
ここで、前記ＳＹＮＣＤ＿ＭＳＢフィールドがオプションヘッダに含まれる場合には前記オプションヘッダがＢＢフレームに含まれる。
【０８１８】
前記ＳＴＵＦＦＩフィールドは１ｂｉｔの大きさを有し、ＢＢフレームにStuffingフィールド（または、Stuffing byte）、またはin-band Signalingフィールドが存在するかを示すインジケータをいう。
【０８１９】
前記チェックサム（Check-sum）フィールドは１ｂｉｔの大きさで、ＢＢフレームヘッダまたはＯＰＴＩＯＮＩフィールドのエラー確認のための用途に使用できる。
【０８２０】
前記チェックサム（Check-sum）フィールドは、ヘッダがＢＢフレームヘッダ及びオプションヘッダに区分される場合、前記オプションヘッダに含まれることができる。
【０８２１】
説明したように、前記Stuffingフィールドはスタッフィングヘッダ及びスタッフィングバイトを含む。
【０８２２】
図４８のＳＹＮＣＤ＿ＬＳＢフィールドと図４３のＰＫＴＳＰＴＲ＿ＬＳＢフィールドは同一な意味として使用できる。
【０８２３】
ここで、前記ＰＫＴＳＰＴＲ＿ＬＳＢフィールドの大きさは５ｂｉｔｓである一方、本明細書で提案する図４８のＳＹＮＣＤ＿ＬＳＢフィールドの大きさは６ｂｉｔｓで、１ｂｉｔ増加するようになる。
【０８２４】
即ち、５ｂｉｔｓのＰＫＴＳＰＴＲ＿ＬＳＢフィールドで表現できるＰＫＴＳＰＴＲの長さは最大３１（２５−１）ｂｙｔｅｓであることに比べて、６ｂｉｔｓのＳＹＮＣＤ＿ＬＳＢフィールドで表現できるＳＹＮＣＤの長さは６３（２６−１）ｂｙｔｅｓで、約２倍が増加するようになる。
【０８２５】
即ち、本明細書で提案するＳＹＮＣＤ＿ＬＳＢフィールドの大きさ調節を通じてＳＹＮＣＤ＿ＭＳＢフィールドがヘッダまたはＢＢフレームヘッダまたはオプションヘッダに追加される場合が減るようになって、ＢＢフレームの送信に対するオーバーヘッドを減らすようになる。
【０８２６】
例えば、１８８ｂｙｔｅのＭＰＥＧ２−ＴＳストリームを送信すると仮定する。
【０８２７】
（１）図４７のＢＢフレーム構造の場合、１８８ｂｙｔｅのＴＳパケットを送信するためにＢＢフレームヘッダにＰＫＴＳＰＴＲ＿ＬＳＢフィールドのみ含まれる場合（即ち、ＰＫＴＳＰＴＲ長さが３１ｂｙｔｅ以下の値を有する場合）は約１６．４９％（３１ｂｙｔｅ／１８８ｂｙｔｅ）に該当する。
【０８２８】
即ち、１６．４９％に該当するＢＢフレームは１ｂｙｔｅの大きさを有するヘッダを含み、残りの８３．５１％に該当するＢＢフレームは２ｂｙｔｅの大きさを有するヘッダを含む。
【０８２９】
ここで、前記ヘッダはペイロードと関連したフォーマットを示し、ＢＢフレームヘッダを意味するか、またはＢＢフレームヘッダ及びオプションヘッダを含む意味でありうる。
【０８３０】
したがって、平均的にＢＢフレームは１．８３ｂｙｔｅの大きさを有するヘッダを含むようになる。
【０８３１】
（２）一方、図４８のＢＢフレーム構造の場合、１８８ｂｙｔｅのＴＳパケットを送信するためにＢＢフレームヘッダにＳＹＮＣＤ＿ＬＳＢフィールドのみが含まれる場合（即ち、ＳＹＮＣＤ長さが６３ｂｙｔｅ以下の値を有する場合）は約３３．５１％（６３ｂｙｔｅ／１８８ｂｙｔｅ）に該当する。
【０８３２】
即ち、３３．５１％に該当するＢＢフレームは１ｂｙｔｅの大きさを有するヘッダを含み、残りの６６．４９％に該当するＢＢフレームは２ｂｙｔｅの大きさを有するヘッダを含む。
【０８３３】
したがって、平均的にＢＢフレームは１．６６ｂｙｔｅの大きさを有するＢＢフレームヘッダを含むようになることで、図４７のＢＢフレーム構造を有する場合よりＢＢフレーム送信に対するオーバーヘッドを格段に減らすことができることが分かる。
【０８３４】
また、図４８のＢＢフレーム構造はオプショナルヘッダに含まれる１ｂｉｔをヘッダのチェックサム１ｂｉｔに使用するか、または前記ヘッダに含まれるＯＰＴＩＯＮＩフィールドのチェックサム１bitに使用することによって、ヘッダに対するエラーが検出できる追加機能を遂行することができるようになる。
【０８３５】
図４９は、本明細書で提案するＢＢフレーム構造の更に他の一例を示す図である。
【０８３６】
図４９のＢＢフレーム構造は、図４８のＢＢフレーム構造とＳＹＮＣＤ＿ＬＳＢフィールド／ＳＹＮＣＤ＿ＭＳＢフィールドの大きさとＳＴＵＦＦＩフィールドの位置において相異し、他の部分は同一である。
【０８３７】
以下、図４８のＢＢフレーム構造と同一な部分に対する説明は省略し、差がつく部分を中心に説明する。
【０８３８】
ＯＰＴＩＯＮＩフィールド及びＳＹＮＣＤ＿ＬＳＢフィールドが合わせられてＢＢフレームヘッダとして定義されることができ、ＳＹＮＣＤ＿ＭＳＢフィールド、ＳＴＵＦＦＩフィールド、及びチェックサムフィールドが合わせられてオプションヘッダとして定義できる。
【０８３９】
また、ＯＰＴＩＯＮＩフィールド、ＳＹＮＣＤ＿ＬＳＢフィールド、ＳＹＮＣＤ＿ＭＳＢフィールド、ＳＴＵＦＦＩフィールド、Checksumフィールドが合わせられて１つのヘッダとして定義できる。
【０８４０】
この場合、前記ヘッダをＢＢフレームヘッダとして表現することもできる。
【０８４１】
更に他の一例として、前記ＳＴＵＦＦＩフィールド及び前記Checksum フィールドは特定フィールドに合わせられることができる。これについては、後述する図５０及び図５１で具体的に説明する。図４９に示すように、前記ＳＹＮＣＤ＿ＬＳＢフィールドの大きさは７ｂｉｔであり、前記ＳＹＮＣＤ＿ＭＳＢフィールドの大きさは６ｂｉｔである。
【０８４２】
図４９のように、前記ＳＹＮＣＤ＿ＬＳＢフィールドの大きさが７ｂｉｔの場合、より多い数のＳＹＮＣＤの長さを表現できるようになる。
【０８４３】
即ち、前記ＳＹＮＣＤ＿ＬＳＢフィールドの大きさが７ｂｉｔの場合、表現できるＳＹＣＮＤの長さは１２７（２７−１）ｂｙｔｅであって、図４８の場合（３１ｂｙｔｅ）より約４倍増加するようになる。
【０８４４】
同様に、１８８ｂｙｔｅのＭＰＥＧ２−ＴＳストリームを送信すると仮定する。
【０８４５】
図４９のＢＢフレーム構造の場合、１８８ｂｙｔｅのＴＳパケットを送信するためにヘッダにＳＹＮＣＤ＿ＬＳＢフィールドのみ含まれる場合（即ち、ＳＹＮＣＤ長さが１２７ｂｙｔｅ以下の値を有する場合）は、約６７．５５％（１２７ｂｙｔｅ／１８８ｂｙｔｅ）に該当する。
【０８４６】
即ち、６７．５５％に該当するＢＢフレームは１ｂｙｔｅの大きさを有するヘッダを含み、残りの３２．４５％に該当するＢＢフレームは２ｂｙｔｅの大きさを有するヘッダを含む。
【０８４７】
したがって、平均的にＢＢフレームは１．３２ｂｙｔｅの大きさを有するヘッダを含むようになって、図４７及び図４８のＢＢフレーム構造を有する場合よりＢＢフレーム送信に対するオーバーヘッドを格段に減らすことができるようになる。
【０８４８】
図４９のＢＢフレーム構造でも同様に、ヘッダに存在する余分の１ｂｉｔをチェックサムに活用することによって（ヘッダのチェックサム１ビットに使用するか、またはＯＰＴＩＯＮＩフィールドのチェックサムに使用）、ヘッダに対するエラー確認を追加的に遂行できるようになる。
【０８４９】
図５０は、本明細書で提案するＢＢフレーム構造のさらに他の一例を示す図である。
【０８５０】
図５０に示すように、前述したＳＴＵＦＦＩフィールド及びＣｈｅｃｋｓｕｍフィールドは、１つの特定フィールド５０１０に合わせられることができる。
【０８５１】
前記特定フィールド５０１０は、ＢＢフレーム内のＳｔｕｆｆｉｎｇ  ｆｉｅｌｄの存在可否を表す値で使用されることができる。
【０８５２】
前記特定フィールド５０１０は、ＥＸＴ＿Ｉ（Ｅｘｔｅｎｓｉｏｎ  Ｉｎｄｉｃａｔｏｒ）フィールドで表現されることができ、２ｂｉｔの大きさを有することができる。
【０８５３】
また、前記特定フィールド５０１０は、ＯＰＴＩ（Ｏｐｔｉｏｎａｌ  Ｈｅａｄｅｒ  Ｉｎｄｉｃａｔｏｒ）フィールドで表現されることができる。
【０８５４】
前記ＯＰＴＩフィールドは、Ｓｔｕｆｆｉｎｇが含まれたヘッダの存在可否を表すフィールドを意味できる。
【０８５５】
ＢＢ  ｆｒａｍｅは、Ｈｅａｄｅｒ及びＰａｙｌｏａｄで構成されることができ、前記Ｈｅａｄｅｒは、１つ以上のｓｕｂ−ｈｅａｄｅｒなどで構成されることができる。
【０８５６】
すなわち、前記１つ以上のｓｕｂ−ｈｅａｄｅｒは、第１のヘッダ、第２のヘッダ、第３のヘッダなどで表現されることができる。
【０８５７】
一例として、前記第１のヘッダは、ＢＢＦ  Ｈｅａｄｅｒ、Ｂａｓｅ  Ｈｅａｄｅｒなどで表現されることができ、前記第２のヘッダは、Ｏｐｔｉｏｎ  Ｈｅａｄｅｒ、Ｏｐｔｉｏｎａｌ  Ｈｅａｄｅｒなどで表現されることができる。
【０８５８】
前記特定フィールド５０１０は、ＢＢ  ｆｒａｍｅのＯｐｔｉｏｎ（ａｌ）  Ｈｅａｄｅｒに含まれることができる。
【０８５９】
下記の表３６は、特定フィールド（ＥＸＴ＿Ｉフィールド）フォーマットの一例を示した表である。
【０８６０】
【表３６】
0006392463.tif 000071
【０８６１】
表３６において、前記特定フィールド値が（１）‘００’である場合、ＢＢフレーム内にスタッフィングがない場合を表し、（２）‘０１’である場合、ＢＢフレーム内に１ｂｙｔｅのスタッフィングが存在する場合を表し、（３）‘１０’である場合、ＢＢフレーム内に２ｂｙｔｅのスタッフィングが存在する場合を表し、（４）‘１１’である場合、ＢＢフレーム内に３ｂｙｔｅ以上のスタッフィングが存在する場合を表すことができる。
【０８６２】
前述したように、Ｓｔｕｆｆｉｎｇフィールドは、Ｓｔｕｆｆｉｎｇ  Ｈｅａｄｅｒフィールド及びＳｔｕｆｆｉｎｇ  Ｂｙｔｅフィールドを含むことができる。
【０８６３】
また、前記Ｓｔｕｆｆｉｎｇ  Ｈｅａｄｅｒフィールドは、ＳＴＵＦＦ＿ＴＹＰＥフィールド、ＳＴＵＦＦ＿ＬＥＮ＿ＬＳＢフィールド、及びＳＴＵＦＦ＿ＬＥＮ＿ＭＳＢフィールドを含むことができる。
【０８６４】
前記ＳＴＵＦＦ＿ＴＹＰＥフィールドは、ＥＸＴ＿ＴＹＰＥ（Ｅｘｔｅｎｓｉｏｎ  Ｔｙｐｅ）フィールドで表現されることができる。この場合、前記ＥＸＴ＿ＴＹＰＥフィールドは、スタッフィングフィールドのタイプを表すことができる。
【０８６５】
また、前記スタッフィングフィールドは、Ｅｘｔｅｎｓｉｏｎフィールドで表現されることもできる。
【０８６６】
前記ＳＴＵＦＦ＿ＴＹＰＥフィールドは、前記ＥＸＴ＿Ｉフィールドが‘０１’または‘１０’または‘１１’値を有する場合、ＢＢ  ｆｒａｍｅまたは前記ＢＢ  ｆｒａｍｅヘッダに含まれることができる。これに関する具体的な内容は、下記の表３７を参照する。
【０８６７】
前記ＳＴＵＦＦ＿ＴＹＰＥフィールドは、３ｂｉｔｓ、前記ＳＴＵＦＦ＿ＬＥＮ＿ＬＳＢフィールドは、５ｂｉｔｓ、前記ＳＴＵＦＦ＿ＬＥＮ＿ＭＳＢフィールドは、８ｂｉｔｓでありうる。
【０８６８】
前記ＳＴＵＦＦ＿ＬＥＮ＿ＬＳＢフィールドは、ＥＸＴ＿ＬＥＮＬＳＢフィールドで、前記ＳＴＵＦＦ＿ＬＥＮ＿ＭＳＢフィールドは、ＥＸＴ＿ＬＥＮ＿ＭＳＢフィールドで表現されることができる。
【０８６９】
以下では、前記特定フィールド値に応じて定義され得るＳＴＵＦＦ＿ＴＹＰＥフィールド、ＳＴＵＦＦ＿ＬＥＮフィールド、及びその意味について表３７を一例に挙げて説明する。
【０８７０】
【表３７】
0006392463.tif 000072
【０８７１】
表３７において、特定フィールド（例：ＥＸＴ＿Ｉフィールド）値が‘００’である場合、スタッフィングがないので、前記ＳＴＵＦＦ＿ＴＹＰＥフィールド及びＳＴＵＦＦ＿ＬＥＮフィールドは、スタッフィングフィールドに存在しない。
【０８７２】
前記特定フィールド値が‘０１’であり、前記ＳＴＵＦＦ＿ＴＹＰＥフィールド値が‘０００’であり、前記ＳＴＵＦＦ＿ＬＥＮフィールド値が‘０００００’である場合、１ｂｙｔｅスタッフィングがＢＢフレーム（または、スタッフィングフィールド）に含まれることを表すことができる。
【０８７３】
前記特定フィールド値が‘１０’であり、前記ＳＴＵＦＦ＿ＴＹＰＥフィールド値が‘０００’であり、前記ＳＴＵＦＦ＿ＬＥＮフィールド値が‘０００００’である場合、２ｂｙｔｅスタッフィングがＢＢフレーム（または、スタッフィングフィールド）に含まれることを表すことができる。前記特定フィールド値が‘１１’であり、前記ＳＴＵＦＦ＿ＴＹＰＥフィールド値が‘０００’であり、前記ＳＴＵＦＦ＿ＬＥＮフィールド値が‘ｓｔｕｆｆ＿ｌｅｎ’である場合、３ｂｙｔｅ以上のスタッフィングがＢＢフレーム（または、スタッフィングフィールド）に含まれることを表すことができる。
【０８７４】
前記特定フィールド値が‘１１’であり、前記ＳＴＵＦＦ＿ＴＹＰＥフィールド値が‘００１’であり、前記ＳＴＵＦＦ＿ＬＥＮフィールド値が‘ｓｔｕｆｆ＿ｌｅｎ’である場合、スタッフィングとｉｎ−ｂａｎｄ  Ａ  ｓｉｇｎａｌｉｎｇがＢＢフレーム（または、スタッフィングフィールド）に含まれることを表すことができる。
【０８７５】
前記ｉｎ−ｂａｎｄ  Ａは、ＩＮＢＡＮＤ＿ＩＳＳＹでありうる。
【０８７６】
前記特定フィールド値が‘１１’であり、前記ＳＴＵＦＦ＿ＴＹＰＥフィールド値が‘０１０’であり、前記ＳＴＵＦＦ＿ＬＥＮフィールド値が‘ｓｔｕｆｆ＿ｌｅｎ’である場合、スタッフィングとｉｎ−ｂａｎｄ  Ｂ  ｓｉｇｎａｌｉｎｇがＢＢフレーム（または、スタッフィングフィールド）に含まれることを表すことができる。
【０８７７】
前記ｉｎ−ｂａｎｄ  Ｂは、ＩＮＢＡＮＤ＿ＳＩＧでありうる。
【０８７８】
前記特定フィールド値が‘１１’であり、前記ＳＴＵＦＦ＿ＴＹＰＥフィールド値が‘１１１’であり、前記ＳＴＵＦＦ＿ＬＥＮフィールド値が‘ｓｔｕｆｆ＿ｌｅｎ’である場合、スタッフィング及び他の情報がＢＢフレーム（または、スタッフィングフィールド）に含まれることを表すことができる。
【０８７９】
また、前記ＳＴＵＦＦ＿ＬＥＮフィールド値は、ＳＴＵＦＦ＿ＬＥＮ＿ＬＳＢフィールド（５ｂｉｔ）値とＳＴＵＦＦ＿ＬＥＮ＿ＭＳＢフィールド（８ｂｉｔ）値とに区分されることができる。
【０８８０】
これについて、表３８を参考して説明する。
【０８８１】
【表３８】
0006392463.tif 000073
【０８８２】
表３８において、前記特定フィールド値が‘０１’であり、前記ＳＴＵＦＦ＿ＴＹＰＥフィールド値が‘０００’であり、前記ＳＴＵＦＦ＿ＬＥＮ＿ＬＳＢフィールド値が‘０００００’であり、前記ＳＴＵＦＦ＿ＬＥＮ＿ＭＳＢフィールド値が‘Ｎｏｔ  ｅｘｉｓｔ’である場合、１ｂｙｔｅスタッフィングがＢＢフレーム（または、スタッフィングフィールド）に含まれることを表すことができる。
【０８８３】
前記特定フィールド値が‘１０’であり、前記ＳＴＵＦＦ＿ＴＹＰＥフィールド値が‘０００’であり、前記ＳＴＵＦＦ＿ＬＥＮ＿ＬＳＢフィールド値が‘０００００’であり、前記ＳＴＵＦＦ＿ＬＥＮ＿ＭＳＢフィールド値が‘００００００００’である場合、２ｂｙｔｅスタッフィングがＢＢフレーム（または、スタッフィングフィールド）に含まれることを表すことができる。
【０８８４】
前記特定フィールド値が‘１１’であり、前記ＳＴＵＦＦ＿ＴＹＰＥフィールド値が‘０００’であり、前記ＳＴＵＦＦ＿ＬＥＮ＿ＬＳＢフィールド値が‘ｓｔｕｆｆ＿ｌｅｎ＿ｌｓｂ’であり、前記ＳＴＵＦＦ＿ＬＥＮ＿ＭＳＢフィールド値が‘ｓｔｕｆｆ＿ｌｅｎ＿ｍｓｂ’である場合、３ｂｙｔｅ以上のスタッフィングがＢＢフレーム（または、スタッフィングフィールド）に含まれることを表すことができる。
【０８８５】
前記特定フィールド値が‘１１’であり、前記ＳＴＵＦＦ＿ＴＹＰＥフィールド値が‘００１’であり、前記ＳＴＵＦＦ＿ＬＥＮ＿ＬＳＢフィールド値が‘ｓｔｕｆｆ＿ｌｅｎ＿ｌｓｂ’であり、前記ＳＴＵＦＦ＿ＬＥＮ＿ＭＳＢフィールド値が‘Ｎｏｔ  ｅｘｉｓｔ’である場合、ｉｎ−ｂａｎｄ  Ａ  ｓｉｇｎａｌｉｎｇのみがＢＢフレーム（または、スタッフィングフィールド）に含まれることを表すことができる。前記ｉｎ−ｂａｎｄ  Ａ  ｓｉｇｎａｌｉｎｇのみがスタッフィングフィールドに含まれる場合は、前記ｉｎ−ｂａｎｄ  Ａ  ｓｉｇｎａｌｉｎｇが３２ｂｙｔｅで表現可能な場合のみに使用することが好ましい。前記ｉｎ−ｂａｎｄ  Ａは、ＩＮＢＡＮＤ＿ＩＳＳＹでありうる。
【０８８６】
前記特定フィールド値が‘１１’であり、前記ＳＴＵＦＦ＿ＴＹＰＥフィールド値が‘０１０’であり、前記ＳＴＵＦＦ＿ＬＥＮ＿ＬＳＢフィールド値が‘ｓｔｕｆｆ＿ｌｅｎ＿ｌｓｂ’であり、前記ＳＴＵＦＦ＿ＬＥＮ＿ＭＳＢフィールド値が‘ｓｔｕｆｆ＿ｌｅｎ＿ｍｓｂ’である場合、スタッフィングとｉｎ−ｂａｎｄ  Ａ  ｓｉｇｎａｌｉｎｇがＢＢフレーム（または、スタッフィングフィールド）に含まれることを表すことができる。
【０８８７】
前記特定フィールド値が‘１１’であり、前記ＳＴＵＦＦ＿ＴＹＰＥフィールド値が‘１１１’であり、前記ＳＴＵＦＦ＿ＬＥＮ＿ＬＳＢフィールド値が‘ｓｔｕｆｆ＿ｌｅｎ＿ｌｓｂ’であり、前記ＳＴＵＦＦ＿ＬＥＮ＿ＭＳＢフィールド値が‘ｓｔｕｆｆ＿ｌｅｎ＿ｍｓｂ’である場合、スタッフィング及び他の情報がＢＢフレーム（またはスタッフィングフィールド）に含まれることを表すことができる。
【０８８８】
図５１は、本明細書で提案するＢＢフレーム構造のさらに他の一例を示す図である。
【０８８９】
図５１の場合、ＳＴＵＦＦ＿ＴＹＰＥフィールドの利用方法と関連したものであって、３ｂｉｔｓのＳＴＵＦＦ＿ＴＹＰＥフィールドを効率的な利用のために、１ｂｉｔのＭＳＢ＿Ｉ（ＭＳＢ  Ｉｎｄｉｃａｔｏｒ）フィールド５１１１と２ｂｉｔｓのＳＴＵＦＦ＿ＴＹＰＥフィールド５１１２とに分割して利用する方法を提供する。
【０８９０】
前記ＭＳＢ＿Ｉフィールド５１１１は、ＳＴＵＦＦ＿ＬＥＮ＿ＭＳＢフィールドの存在有無を表すｉｎｄｉｃａｔｏｒをいう。
【０８９１】
一例として、前記ＭＳＢ＿Ｉフィールド値が‘０’である場合、Ｓｔｕｆｆｉｎｇ  Ｈｅａｄｅｒ内にＳＴＵＦＦ＿ＬＥＮ＿ＬＳＢ（５ｂｉｔ）のみが使用されることを表すことができ、前記ＭＳＢ＿Ｉフィールド値が‘１’である場合、Ｓｔｕｆｆｉｎｇ  Ｈｅａｄｅｒ５１１０内にＳＴＵＦＦ＿ＬＥＮ＿ＬＳＢ（５ｂｉｔｓ）フィールド及びＳＴＵＦＦ＿ＬＥＮ＿ＭＳＢ（８ｂｉｔｓ）フィールドが使用されることを表すことができる。
【０８９２】
一例として、前記ＭＳＢ＿Ｉフィールド値が‘０’である場合、ＳＴＵＦＦ＿ＬＥＮ＿ＬＳＢ（５ｂｉｔｓ）フィールドのみがＳｔｕｆｆｉｎｇ  Ｈｅａｄｅｒに使用され（または、含まれ）、表現できるＳｔｕｆｆｉｎｇフィールドの大きさ（ｓｉｚｅ）は、３２ｂｙｔｅである。
【０８９３】
前記ＭＳＢ＿Ｉフィールド値が‘１’である場合、ＳＴＵＦＦ＿ＬＥＮ＿ＬＳＢ（５ｂｉｔｓ）フィールドとＳＴＵＦＦ＿ＬＥＮ＿ＭＳＢ（８ｂｉｔｓ）フィールドとがＳｔｕｆｆｉｎｇ  Ｈｅａｄｅｒに使用され（または、含まれ）、表現できるＳＴＵＦＦ＿ＬＥＮは、１３ｂｉｔとなる。
【０８９４】
次に、ＳＴＵＦＦ＿ＴＹＰＥフィールド（２ｂｉｔ、４７１２）は、Ｓｔｕｆｆｉｎｇフィールドの使用Ｔｙｐｅを知らせるフィールドを表す。
【０８９５】
前記ＳＴＵＦＦ＿ＴＹＰＥフィールドの一例としては、ＩＳＳＹ、ｉｎ−ｂａｎｄ  ｓｉｇｎａｌｉｎｇなどがありうる。
【０８９６】
前記ＳＴＵＦＦ＿ＴＹＰＥフィールドは、Ｓｔｕｆｆｉｎｇフィールド区間がＳｔｕｆｆｉｎｇ以外に、他の用途（例：ｉｎｂａｎｄ用ｓｉｇｎａｌｉｎｇ、ｉｎｂａｎｄ用ＩＳＳＹ）で使用することができるように指定されたＳＴＵＦＦ  ＴＹＰＥを知らせる。
【０８９７】
下記の表３９を参照してＭＳＢ＿Ｉフィールド及び２ｂｉｔｓの大きさで新しく定義されたＳＴＵＦＦ＿ＴＹＰＥフィールドの意味についてさらに具体的に説明する。
【０８９８】
【表３９】
0006392463.tif 000074
【０８９９】
表３９において、前記ＳＴＵＦＦ＿ＴＹＰＥフィールド値が‘００’である場合、Ｓｔｕｆｆｉｎｇフィールドは、ｓｔｕｆｆｉｎｇ  ｂｙｔｅのみで構成されている場合を表し、前記ＳＴＵＦＦ＿ＴＹＰＥフィールド値が０１、１０、１１である場合、Ｓｔｕｆｆｉｎｇフィールドで他の用途で使用されるそれぞれのモードを表現する。
【０９００】
図５１及び表３９において説明したように、Ｓｔｕｆｆｉｎｇ  Ｈｅａｄｅｒ内にＭＳＢ＿ＩフィールドとＳＴＵＦＦ＿ＴＹＰＥフィールドとを共に使用する場合、Ｓｔｕｆｆｉｎｇフィールド内のＩＳＳＹとｓｔｕｆｆｉｎｇとを合わせた値の大きさが３２ｂｙｔｅｓ以下である場合、Ｓｔｕｆｆｉｎｇ  Ｈｅａｄｅｒは、ＳＴＵＦＦ＿ＬＥＮ＿ＭＳＢフィールドを含まなくても良いので、１ｂｙｔｅのｏｖｅｒｈｅａｄを減らすことができるという長所がある。
【０９０１】
仮に、Ｓｔｕｆｆｉｎｇフィールド内のＩＳＳＹとｓｔｕｆｆｉｎｇとを合わせた値の大きさが３２ｂｙｔｅｓより大きい場合には、ＭＳＩ＿Ｉフィールドを‘１’に設定し（または、マークし）、ＳＴＵＦＦ＿ＬＥＮ＿ＭＳＢフィールドをＳｔｕｆｆｉｎｇ  Ｈｅａｄｅｒに使用することができる。
【０９０２】
図５２は、本明細書で提案する放送信号の送信方法の一例を示す順序図である。
【０９０３】
図５２に示すように、本明細書で提案する放送信号送信装置は、インプットストリーム（Ｉｎｐｕｔ  Ｓｔｒｅａｍ）をインプットフォーマッティング（Ｉｎｐｕｔ  Ｆｏｒｍａｔｔｉｎｇ）モジュールを介してプロセシング（Ｐｒｏｃｅｓｓｉｎｇ）する（Ｓ５２１０）。すなわち、前記放送信号送信装置は、インプットフォーマッティング（Ｉｎｐｕｔ  Ｆｏｒｍａｔｔｉｎｇ）モジュールで前記インプットストリームを複数のＤＰ（Ｄａｔａ  Ｐｉｐｅ）でフォーマッティングする。
【０９０４】
具体的に、前記放送信号送信装置は、Ｓ５２１０のインプットフォーマッティング（Ｉｎｐｕｔ  Ｆｏｒｍａｔｔｉｎｇ）のために、データパケットをベースバンドフレーム（Ｂａｓｅｂａｎｄ  Ｆｒａｍｅ：ＢＢＦ）のペイロード（Ｐａｙｌｏａｄ）に割り当て、前記ベースバンドフレームのペイロードに対するフォーマットを表すヘッダを付加する。
【０９０５】
ここで、前記複数のＤＰ（Ｄａｔａ  Ｐｉｐｅ）は、複数のデータ送信チャネル（ｄａｔａ  ｔｒａｎｓｍｉｓｓｉｏｎ  ｃｈａｎｎｅｌｓ）で表現されることができる。
【０９０６】
前記ヘッダは、図５０及び図５１において説明したように、ＥＸＴ＿Ｉフィールド及びＳｔｕｆｆｉｎｇフィールドを含むことができる。
【０９０７】
前記ＥＸＴ＿Ｉフィールドは、ＢＢフレーム内のＳｔｕｆｆｉｎｇ  ｆｉｅｌｄの存在可否を表すフィールドを意味し、２ｂｉｔｓの大きさを有することができる。
【０９０８】
前記Ｓｔｕｆｆｉｎｇフィールドは、Ｓｔｕｆｆｉｎｇ  Ｈｅａｄｅｒを含み、前記Ｓｔｕｆｆｉｎｇ  Ｈｅａｄｅｒは、ＭＳＢ＿Ｉフィールド及びＳＴＵＦＦ＿ＴＹＰＥフィールドを含む。
【０９０９】
前記ＭＳＢ＿Ｉフィールドは、ＳＴＵＦＦ＿ＬＥＮ＿ＭＳＢフィールドの存在有無を表すｉｎｄｉｃａｔｏｒをいい、１ｂｉｔの大きさを有することができる。
【０９１０】
また、前記ＳＴＵＦＦ＿ＴＹＰＥフィールドは、Ｓｔｕｆｆｉｎｇフィールドの使用Ｔｙｐｅを知らせるフィールドを意味し、２ｂｉｔｓの大きさを有することができる。
【０９１１】
前記ＥＸＴ＿Ｉフィールド、前記ＭＳＢ＿Ｉフィールド、及び前記ＳＴＵＦＦ＿ＴＹＰＥフィールドは、他の実施形態に適用されるために、制御情報の表現で使用されることもできる。
【０９１２】
その後、前記放送送信装置は、（フォーマッティングされた）複数のＤＰのデータをＢＩＣＭ（Ｂｉｔ  Ｉｎｔｅｒｌｅａｖｅｄ  Ｃｏｄｉｎｇ  ａｎｄ  Ｍｏｄｕｌａｔｉｏｎ）モジュールを介して各ＤＰ別にエンコーディング（ｅｎｃｏｄｉｎｇ）する（Ｓ５２２０）。
【０９１３】
前記ＢＩＣＭモジュールは、エンコーダ（ｅｎｃｏｄｅｒ）で表現されることもできる。
【０９１４】
したがって、前記放送送信装置は、エンコーダ（ｅｎｃｏｄｅｒ）を介してサービスデータまたはサービスコンポーネントデータを送信するデータ送信チャネルの各々に該当するデータをエンコーディングする。
【０９１５】
その後、前記放送送信装置は、前記エンコーディングされたＤＰのデータをフレームビルディング（Ｆｒａｍｅ  Ｂｕｉｌｄｉｎｇ）モジュールを介してマッピングして、少なくとも１つの信号フレームを生成する（Ｓ５２３０）。
【０９１６】
前記フレームビルディング（Ｆｒａｍｅ  Ｂｕｉｌｄｉｎｇ）モジュールは、フレームビルダー（ｆｒａｍｅ  ｂｕｉｌｄｅｒ）で表現されることもできる。
【０９１７】
その後、前記放送送信装置は、ＯＦＤＭジェネレーション（Ｏｒｔｈｏｇｏｎａｌ  Ｆｒｅｑｕｅｎｃｙ  Ｄｉｖｉｓｉｏｎ  Ｍｕｌｔｉｐｌｅｘｉｎｇ  Ｇｅｎｅｒａｔｉｏｎ）モジュールを介してＯＦＤＭ方式により前記生成された信号フレームのデータを変調し、前記変調された信号フレームのデータを含む放送信号を送信機（ｔｒａｎｓｍｉｔｔｅｒ）を介して送信する（Ｓ５２４０）。
【０９１８】
図５３は、本明細書で提案する放送信号の受信方法の一例を示す順序図である。
【０９１９】
図５３に示すように、本明細書で提案する放送信号受信装置は、Ｓｙｎｃｈｒｏｎｉｚａｔｉｏｎ及びＤｅｍｏｄｕｌａｔｉｏｎモジュールを介して外部から放送信号を受信し、前記受信された放送信号に対してＯＦＤＭ方式によりデータを復調する（Ｓ５３１０）。
【０９２０】
前記Ｓｙｎｃｈｒｏｎｉｚａｔｉｏｎ及びＤｅｍｏｄｕｌａｔｉｏｎモジュールは、受信機（ｒｅｃｅｉｖｅｒ）及び復調器（ｄｅｍｏｄｕｌａｔｏｒ）で表現されることもできる。
【０９２１】
したがって、前記放送信号受信装置は、受信機（ｒｅｃｅｉｖｅｒ）を介して前記少なくとも１つの信号フレームを含む放送信号を受信し、前記復調器（ｄｅｍｏｄｕｌａｔｏｒ）を介して前記受信された放送信号をＯＦＤＭ（Ｏｒｔｈｏｇｏｎａｌ  Ｆｒｅｑｕｅｎｃｙ  Ｄｉｖｉｓｉｏｎ  Ｍｕｌｔｉｐｌｅｘｉｎｇ）方式によりデータを復調する。
【０９２２】
その後、前記放送信号受信装置は、前記復調されたデータをフレームパーシング（Ｆｒａｍｅ  Ｐａｒｓｉｎｇ）モジュールを介して少なくとも１つの信号フレームでパーシングする（Ｐａｒｓｉｎｇ、Ｓ５３２０）。
【０９２３】
前記フレームパーシングモジュールは、フレームパーサ（ｆｒａｍｅ  ｐａｒｓｅｒ）で表現されることもできる。
【０９２４】
したがって、前記放送信号受信装置は、前記フレームパーサ（ｆｒａｍｅ  ｐａｒｓｅｒ）を介してサービスデータ（ｓｅｒｖｉｃｅ  ｄａｔａ）またはサービスコンポーネントデータ（ｓｅｒｖｉｃｅ  ｃｏｍｐｏｎｅｎｔ  ｄａｔａ）を抽出するために、前記受信された放送信号に含まれた前記少なくとも１つの信号フレームをパーシング（Ｐａｒｓｉｎｇ）する。
【０９２５】
その後、前記放送信号受信装置は、前記パーシングされた少なくとも１つの信号フレームをデマッピング及びデコーディング（ｄｅｍａｐｐｉｎｇ  ａｎｄ  ｄｅｃｏｄｉｎｇ）モジュールを介して複数のＤＰでデコーディングする（Ｓ５３３０）。
【０９２６】
前記デマッピング及びデコーディング（ｄｅｍａｐｐｉｎｇ  ａｎｄ  ｄｅｃｏｄｉｎｇ）モジュールは、変換機（ｃｏｎｖｅｒｔｅｒ）及びデコーダ（ｄｅｃｏｄｅｒ）で表現されることもできる。
【０９２７】
したがって、前記放送信号受信装置は、変換機（ｃｏｎｖｅｒｔｅｒ）を介して前記サービスデータ（ｓｅｒｖｉｃｅ  ｄａｔａ）またはサービスコンポーネントデータ（ｓｅｒｖｉｃｅ  ｃｏｍｐｏｎｅｎｔ  ｄａｔａ）をビットに変換し、デコーダ（ｄｅｃｏｄｅｒ）を介して前記変換されたビットをデコーディング（ｄｅｃｏｄｉｎｇ）する。
【０９２８】
その後、前記放送信号受信装置は、前記デマッピング及びデコーディングモジュールから出力される複数のＤＰ（Ｄａｔａ  Ｐｉｐｅ）をアウトプットプロセッサ（ｏｕｔｐｕｔ  ｐｒｏｃｅｓｓｏｒ）モジュールを介してインプットストリーム（Ｉｎｐｕｔ  Ｓｔｒｅａｍ）などで復元する（Ｓ５３４０）。
【０９２９】
または、前記放送信号受信装置は、前記アウトプットプロセッサ（ｏｕｔｐｕｔ  ｐｒｏｃｅｓｓｏｒ）を介して前記デコーディングされたビットを含むデータストリームを出力する。
【０９３０】
前記放送信号受信装置は、Ｓ５３４０のアウトプットプロセシングのために、ベースバンドフレームプロセッサ（Ｂａｓｅｂａｎｄ  Ｆｒａｍｅ  Ｐｒｏｃｅｓｓｏｒ）ブロックを介してベースバンドフレーム（Ｂａｓｅｂａｎｄ  Ｆｒａｍｅ）のヘッダに送信された情報をディテクティング(検出）（ｄｅｔｅｃｔｉｎｇ）または取得（ｏｂｔａｉｎｉｎｇ）し、前記デコーディングされた情報を利用してインプットストリーム（Ｉｎｐｕｔ  Ｓｔｒｅａｍ）を復元する。
【０９３１】
前記ヘッダは、図５０〜図５２において説明したように、ＥＸＴ＿Ｉフィールド及びＳｔｕｆｆｉｎｇフィールドを含むことができる。
【０９３２】
前記ＥＸＴ＿Ｉフィールドは、ＢＢフレーム内のＳｔｕｆｆｉｎｇ  ｆｉｅｌｄの存在可否を表すフィールドを意味し、２ｂｉｔｓの大きさを有することができる。
【０９３３】
前記Ｓｔｕｆｆｉｎｇフィールドは、Ｓｔｕｆｆｉｎｇ  Ｈｅａｄｅｒを含み、前記Ｓｔｕｆｆｉｎｇ  Ｈｅａｄｅｒは、ＭＳＢ＿Ｉフィールド及びＳＴＵＦＦ＿ＴＹＰＥフィールドを含む。
【０９３４】
前記ＭＳＢ＿Ｉフィールドは、ＳＴＵＦＦ＿ＬＥＮ＿ＭＳＢフィールドの存在有無を表すｉｎｄｉｃａｔｏｒをいい、１ｂｉｔの大きさを有することができる。
【０９３５】
また、前記ＳＴＵＦＦ＿ＴＹＰＥフィールドは、Ｓｔｕｆｆｉｎｇフィールドの使用Ｔｙｐｅを知らせるフィールドを意味し、２ｂｉｔｓの大きさを有することができる。
【０９３６】
前記ＥＸＴ＿Ｉフィールド、前記ＭＳＢ＿Ｉフィールド、及び前記ＳＴＵＦＦ＿ＴＹＰＥフィールドは、他の実施形態に適用されるために、制御情報の表現で使用されることができる。
【０９３７】
本発明の思想や範囲を逸脱することなく、本発明において多様な変更及び変形が可能であることは当業者に理解される。したがって、本発明は、添付された請求項及びその同等範囲内で提供される本発明の変更及び変形を含むことと意図される。
【０９３８】
本明細書において装置及び方法発明が全て言及され、装置及び方法発明の全ての説明は互いに補完して適用されることができる。
【産業上の利用可能性】
【０９３９】
本明細書は、放送信号を受信及び送信するための方法及び装置を利用することにある。
【図１】
0006392463.tif 000075
【図２】
0006392463.tif 000076
【図３】
0006392463.tif 000077
【図４】
0006392463.tif 000078
【図５】
0006392463.tif 000079
【図６】
0006392463.tif 000080
【図７】
0006392463.tif 000081
【図８】
0006392463.tif 000082
【図９】
0006392463.tif 000083
【図１０】
0006392463.tif 000084
【図１１】
0006392463.tif 000085
【図１２】
0006392463.tif 000086
【図１３】
0006392463.tif 000087
【図１４】
0006392463.tif 000088
【図１５】
0006392463.tif 000089
【図１６】
0006392463.tif 000090
【図１７】
0006392463.tif 000091
【図１８】
0006392463.tif 000092
【図１９】
0006392463.tif 000093
【図２０】
0006392463.tif 000094
【図２１】
0006392463.tif 000095
【図２２】
0006392463.tif 000096
【図２３】
0006392463.tif 000097
【図２４】
0006392463.tif 000098
【図２５】
0006392463.tif 000099
【図２６】
0006392463.tif 000100
【図２７】
0006392463.tif 000101
【図２８】
0006392463.tif 000102
【図２９】
0006392463.tif 000103
【図３０】
0006392463.tif 000104
【図３１】
0006392463.tif 000105
【図３２Ａ】
0006392463.tif 000106
【図３２Ｂ】
0006392463.tif 000107
【図３２Ｃ】
0006392463.tif 000108
【図３２Ｄ】
0006392463.tif 000109
【図３３】
0006392463.tif 000110
【図３４Ａ】
0006392463.tif 000111
【図３４Ｂ】
0006392463.tif 000112
【図３５Ａ】
0006392463.tif 000113
【図３５Ｂ】
0006392463.tif 000114
【図３５Ｃ】
0006392463.tif 000115
【図３５Ｄ】
0006392463.tif 000116
【図３６Ａ】
0006392463.tif 000117
【図３６Ｂ】
0006392463.tif 000118
【図３６Ｃ】
0006392463.tif 000119
【図３６Ｄ】
0006392463.tif 000120
【図３７】
0006392463.tif 000121
【図３８】
0006392463.tif 000122
【図３９】
0006392463.tif 000123
【図４０】
0006392463.tif 000124
【図４１】
0006392463.tif 000125
【図４２】
0006392463.tif 000126
【図４３】
0006392463.tif 000127
【図４４】
0006392463.tif 000128
【図４５】
0006392463.tif 000129
【図４６】
0006392463.tif 000130
【図４７】
0006392463.tif 000131
【図４８】
0006392463.tif 000132
【図４９】
0006392463.tif 000133
【図５０】
0006392463.tif 000134
【図５１】
0006392463.tif 000135
【図５２】
0006392463.tif 000136
【図５３】
0006392463.tif 000137