特許 6180651 放送信号送信装置、放送信号受信装置、放送信号送信方法、及び放送信号受信方法

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

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

(11)【特許番号】6180651

(24)【登録日】2017年7月28日

(45)【発行日】2017年8月16日

(54)【発明の名称】放送信号送信装置、放送信号受信装置、放送信号送信方法、及び放送信号受信方法

(51)【国際特許分類】

   H04N 21/238 20110101AFI20170807BHJP

   H04N 21/438 20110101ALI20170807BHJP

【ＦＩ】

   H04N21/238

   H04N21/438

【請求項の数】12

【全頁数】101

(21)【出願番号】特願2016-552391(P2016-552391)

(86)(22)【出願日】2014年11月13日

(65)【公表番号】特表2017-501650(P2017-501650A)

(43)【公表日】2017年1月12日

(86)【国際出願番号】KR2014010914

(87)【国際公開番号】WO2015072768

(87)【国際公開日】20150521

【審査請求日】2016年4月28日

(31)【優先権主張番号】61/903,400

(32)【優先日】2013年11月13日

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

(31)【優先権主張番号】61/908,169

(32)【優先日】2013年11月24日

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

(73)【特許権者】

【識別番号】502032105

【氏名又は名称】エルジー エレクトロニクス インコーポレイティド

(74)【代理人】

【識別番号】100109841

【弁理士】

【氏名又は名称】堅田 健史

(74)【代理人】

【識別番号】230112025

【弁護士】

【氏名又は名称】小林 英了

(74)【代理人】

【識別番号】230117802

【弁護士】

【氏名又は名称】大野 浩之

(74)【代理人】

【識別番号】100131451

【弁理士】

【氏名又は名称】津田 理

(74)【代理人】

【識別番号】100167933

【弁理士】

【氏名又は名称】松野 知紘

(74)【代理人】

【識別番号】100174137

【弁理士】

【氏名又は名称】酒谷 誠一

(74)【代理人】

【識別番号】100184181

【弁理士】

【氏名又は名称】野本 裕史

(72)【発明者】

【氏名】フワン，ジェホ

(72)【発明者】

【氏名】ホン，スンリョン

(72)【発明者】

【氏名】コ，ウスク

【審査官】 富樫 明

(56)【参考文献】

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

【文献】 特開２００３−００６９９９（ＪＰ，Ａ）

【文献】 特開２００６−２４６４６３（ＪＰ，Ａ）

【文献】 国際公開第２０１５／００２００７（ＷＯ，Ａ１）

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

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

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

Ｈ０４Ｎ ２１／００−２１／８５８

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

【請求項1】

放送信号を転送するための方法であって、前記方法は、
インプットストリーム（Input Stream）を少なくとも１つの物理階層パイプ（physical layer pipe：ＰＬＰ）にフォーマッティングする（formatting）ステップと、
前記少なくとも１つのＰＬＰのデータをエンコーディングする（encoding）ステップと、
前記エンコーディングされた データをマッピングして少なくとも１つの信号フレームを生成するステップと、
ＯＦＤＭ（Orthogonal Frequency Division Multiplexing）方式を使用して前記少なくとも１つの信号フレームを変調するステップと、
前記少なくとも１つの変調された信号フレームを含む放送信号を転送するステップとを含み、かつ
前記フォーマッティングする（formatting）ステップは、
データパケットをベースバンドフレーム（Baseband Frame：ＢＢＦ）のペイロード（Payload）に マッピングするステップと、
前記ペイロードの前にヘッダを付加するステップとをさらに含み、
前記ヘッダは第１制御情報または第２制御情報のうち、少なくとも１つを含み、
前記第２制御情報は第２制御情報ＬＳＢ（Least Significant Bit）フィールドまたは第２制御情報ＭＳＢ（Most Significant Bit）フィールドのうちの少なくとも１つを含み、
前記第１制御情報は前記第２制御情報ＭＳＢフィールドが含まれるか否かを示し、
前記第２制御情報は前記ＢＢＦで第１のデータパケットの開始位置と関連した情報であることを特徴とする、方法。

【請求項2】

前記第２制御情報の値は前記ペイロードの開始から前記ＢＢＦで第１のデータパケットの開始までのオフセットであることを特徴とする、請求項１に記載の方法。

【請求項3】

前記第２制御情報ＬＳＢフィールドのサイズは７ビットであり、前記第２制御情報ＭＳＢフィールドのサイズは６ビットであることを特徴とする、請求項１に記載の方法。

【請求項4】

前記ベースバンドフレームはスタッフィング（stuffing）データを含むスタッフィングフィールドを含み、
前記スタッフィングフィールドは前記ペイロードにデータパケットが詰められない場合、前記ベースバンドフレームに含まれることを特徴とする、請求項１に記載の方法。

【請求項5】

前記スタッフィングフィールドは 前記スタッフィングデータのタイプを示すＳＴＵＦＦ＿ＴＹＰＥフィールド、または前記スタッフィングフィールドの長さを示すＳＴＵＦＦ＿ＬＥＮフィールドのうち、少なくとも１つを含むことを特徴とする、請求項４に記載の方法。

【請求項6】

前記ＳＴＵＦＦ＿ＬＥＮフィールドはＳＴＵＦＦ＿ＬＥＮ＿ＭＳＢ（Most Significant Bit）及びＳＴＵＦＦ＿ＬＥＮ＿ＬＳＢ（Least Significant Bit）に区分されることを特徴とする、請求項５に記載の方法。

【請求項7】

前記スタッフィングデータはスタッフィングまたはインバンドシグナリングのうち、少なくとも１つを示すことを特徴とする、請求項６に記載の方法。

【請求項8】

前記ペイロードに含まれる最後のデータパケットは振り分けることを特徴とする、請求項１に記載の方法。

【請求項9】

前記スタッフィングフィールドは前記ペイロードの後に位置することを特徴とする、請求項４に記載の方法。

【請求項10】

前記第１制御情報はＯＰＴＩＯＮＩフィールドまたはＰＳＰＭＩ（Packet Start Pointer Mode Indicator）フィールドであり、
前記第２制御情報はＳＹＮＣＤフィールドまたはＰＫＴＳＰＴＲ（Packet Start Pointer）フィールドであることを特徴とする、請求項１に記載の方法。

【請求項11】

放送信号を転送するための送信装置であって、
インプットストリーム（Input Stream）を少なくとも１つの物理階層パイプ（physical layer pipe：ＰＬＰ）にフォーマッティングする（formatting）インプットフォーマッティング（Input Formatting）モジュールと、
前記少なくとも１つのＰＬＰのデータをエンコーディングする（encoding）ＢＩＣＭ（Bit Interleaved Coding and Modulation）モジュールと、
前記エンコーディングされたデータをマッピングして少なくとも１つの信号フレームを生成するフレームビルディング（Frame Building）モジュールと、
ＯＦＤＭ（Orthogonal Frequency Division Multiplexing）方式を使用して前記少なくとも１つの信号フレームを変調し、前記少なくとも１つの変調された信号フレームを含む放送信号を転送するＯＦＤＭジェネレーション（OFDM Generation）モジュールとを含み、かつ
前記インプットフォーマッティングモジュールは、
データパケットをベースバンドフレーム（Baseband Frame：ＢＢＦ）のペイロード（Payload）にマッピングするベースバンドフレームスライサー（Baseband Frame Slicer）モジュールと、
前記ペイロードの前にヘッダを付加するベースバンドフレームヘッダ挿入（Baseband Frame Header Insertion）モジュールとを含み、
前記ヘッダは第１制御情報または第２制御情報のうち、少なくとも１つを含み、
前記第２制御情報は第２制御情報ＬＳＢ（Least Significant Bit）フィールドまたは第２制御情報ＭＳＢ（Most Significant Bit）フィールドのうちの少なくとも１つを含み、
前記第１制御情報は前記第２制御情報ＭＳＢフィールドが含まれるか否かを示し、
前記第２制御情報は前記ＢＢＦで第１のデータパケットの開始位置と関連した情報であることを特徴とする、送信装置。

【請求項12】

放送信号を受信するための受信装置であって、
デマッピング及びデコーディング（demapping and decoding）モジュールと、
前記デマッピング及びデコーディングモジュールから出力される少なくとも１つの物理階層パイプ（physical layer pipe：ＰＬＰ）をインプットストリーム（Input Stream）に復元するアウトプットプロセッサ（Output Processor）モジュールを含み、かつ
前記アウトプットプロセッサモジュールは、
ベースバンドフレーム（Baseband Frame）のヘッダに転送された情報をデコーディング（decoding）し、前記デコーディングされた情報を用いてインプットストリーム（Input Stream）を復元するベースバンドフレームプロセッサ（Baseband Frame Processor）ブロックを含み、
前記ヘッダは第１制御情報または第２制御情報のうち、少なくとも１つを含み、
前記第２制御情報は第２制御情報ＬＳＢ（Least Significant Bit）フィールドまたは第２制御情報ＭＳＢ（Most Significant Bit）フィールドのうちの少なくとも１つを含み、
前記第１制御情報は前記第２制御情報ＭＳＢフィールドが含まれるか否かを示し、
前記第２制御情報は前記ＢＢＦで第１のデータパケットの開始位置と関連した情報であることを特徴とする、受信装置。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は、放送信号送信装置、放送信号受信装置、及び放送信号送受信方法に関するものである。

【背景技術】

【0002】

アナログ放送信号送信が終了するにつれて、ディジタル放送信号を送受信するための多様な技術が開発されている。ディジタル放送信号はアナログ放送信号に比べてより多い量のビデオ／オーディオデータを含むことができ、ビデオ／オーディオデータだけでなく、多様な種類の付加データをさらに含むことができる。

【発明の概要】

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

【0003】

本明細書は、ベースバンドフレーム（Baseband Frame）構造を新しく定義することによって、ＢＢフレーム転送、特にＢＢフレームヘッダの転送に対するオーバーヘッドを減らす方法を提供することをその目的とする。

【0004】

また、本明細書はＢＢフレームに含まれるスタッフィング（または、パディング）フィールドを活用してインバンドシグナリング（in-band signaling）など、多様な機能を追加する方法を提供することをその目的とする。

【0005】

また、本明細書はＢＢフレームヘッダの残っているビットを活用してエラーチェック（error check）の機能を追加的に遂行する方法を提供することをその目的とする。

【0006】

本明細書が達成しようとする技術的課題は、以上で言及した技術的課題に制限されず、言及していない更に他の技術的課題は以下の記載から本発明が属する技術分野で通常の知識を有する者に明確に理解されるべきである。

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

【0007】

本明細書は放送信号を転送するための方法において、前記方法はインプットストリーム（Input Stream）を多数のＤＰ（Data Pipe）にフォーマッティングする（formatting）ステップ；前記多数のＤＰのデータを各ＤＰ別にエンコーディングする（encoding）ステップ；前記エンコーディングされたＤＰのデータをマッピングして少なくとも１つの信号フレームを生成するステップ；及びＯＦＤＭ（Orthogonal Frequency Division Multiplexing）方式により前記生成された信号フレームのデータを変調し、前記変調された信号フレームのデータを含む放送信号を転送するステップを含み、かつ前記フォーマッティングする（formatting）ステップはデータパケットをベースバンドフレーム（Baseband Frame：ＢＢＦ）のペイロード（Payload）に割り当てるステップ；及びベースバンドフレームのペイロードに対するフォーマットを示すヘッダを付加するステップを含み、前記ヘッダは第１制御情報または第２情報のうちの少なくとも１つを含み、前記第２制御情報は第２制御情報ＬＳＢ（Least Significant Bit）及び第２制御情報ＭＳＢ（Most Significant Bit）に区分され、前記第１制御情報は前記第２制御情報が前記第２制御情報ＬＳＢのみで表現できるか否かを示し、前記第２制御情報は前記ペイロードの開始から前記ペイロードで初めて転送されるデータパケットまでの距離を示すことを特徴とする。

【0008】

また、本明細書において、前記ヘッダは前記ヘッダまたは前記第１制御情報のエラーチェック（error check）のためのチェックサム（Check-Sum）フィールドをさらに含むことを特徴とする。

【0009】

また、本明細書において、前記第２制御情報ＬＳＢの大きさは６ｂｉｔまたは７ｂｉｔであり、前記第２制御情報ＭＳＢの大きさは７ｂｉｔまたは６ｂｉｔであることを特徴とする。

【0010】

また、本明細書において、前記ベースバンドフレームはスタッフィング（stuffing）データを含むスタッフィングフィールドを含み、前記スタッフィングフィールドは前記ペイロードにデータパケットが詰められないか、またはインバンドシグナリング（in-band signaling）が使われる場合、前記ベースバンドフレームに含まれることを特徴とする。

【0011】

また、本明細書において、前記ヘッダは前記ベースバンドフレームに前記スタッフィングフィールドを含むか否かを示すＳＴＵＦＦＩフィールドを含むことを特徴とする。

【0012】

また、本明細書において、前記ＳＴＵＦＦＩフィールドは前記第２制御情報の次に位置するか、または前記第１制御情報の次に位置することを特徴とする。

【0013】

また、本明細書において、前記スタッフィングフィールドはスタッフィングヘッダ（Stuffing Header）とスタッフィングデータを含むことを特徴とする。

【0014】

また、本明細書において、前記スタッフィングフィールドは前記スタッフィングフィールドの長さが１ｂｙｔｅか否かを示すＳＴＵＦＦ＿ＯＮＥフィールド、前記スタッフィングデータのタイプを示すＳＴＵＦＦ＿ＴＹＰＥフィールド、または前記スタッフィングフィールドの長さを示すＳＴＵＦＦ＿ＬＥＮフィールドのうち、少なくとも１つを含むことを特徴とする。

【0015】

また、本明細書において、前記ＳＴＵＦＦ＿ＬＥＮフィールドはＳＴＵＦＦ＿ＬＥＮ＿ＭＳＢ（Most Significant bit）及びＳＴＵＦＦ＿ＬＥＮ＿ＬＳＢ（Least Significant bit）に区分されることを特徴とする。

【0016】

また、本明細書において、前記スタッフィングデータはスタッフィングまたはインバンドシグナリングのうち、少なくとも１つを示すことを特徴とする。

【0017】

また、本明細書は前記スタッフィングフィールドの長さが１ｂｙｔｅの場合、前記ＳＴＵＦＦ＿ＬＥＮ＿ＬＳＢ（Least Significant bit）は前記ＳＴＵＦＦ＿ＬＥＮフィールドに含まれないことを特徴とする。

【0018】

また、本明細書において、前記スタッフィングフィールドは前記ペイロードの次に位置することを特徴とする。

【0019】

また、本明細書において、前記第１制御情報はＯＰＴＩＯＮＩフィールドまたはＰＳＰＭＩ（Packet Start Pointer Mode Indicator）フィールドであり、前記第２制御情報はＳＹＮＣＤフィールドまたはＰＫＴＳＰＴＲ（Packet Start Pointer）フィールドであることを特徴とする。

【0020】

また、本明細書は放送信号を転送するための送信装置において、インプットストリーム（Input Stream）を多数のＤＰ（Data Pipe）にフォーマッティングする（formatting）インプットフォーマッティング（Input Formatting）モジュール；前記多数の例のデータを各ＤＰ別にエンコーディングする（encoding）ＢＩＣＭ（bit Interleaved Coding and Modulation）モジュール；前記エンコーディングされたＤＰのデータをマッピングして少なくとも１つの信号フレームを生成するフレームビルディング（Frame Building）モジュール；及びＯＦＤＭ（Orthogonal Frequency Division Multiplexing）方式により前記生成された信号フレームのデータを変調し、前記変調された信号フレームのデータを含む放送信号を転送するＯＦＤＭジェネレーション（OFDM Generation）モジュールを含み、かつ前記インプットフォーマッティングモジュールはデータパケットをベースバンドフレーム（Baseband Frame：ＢＢＦ）のペイロード（Payload）に割り当てるベースバンドフレームスライサー（Baseband Frame Slicer）モジュール；及びベースバンドフレームのペイロードに対するフォーマットを示すヘッダを付加するベースバンドフレームヘッダ挿入（Baseband Frame Header Insertion）モジュールを含み、前記ヘッダは第１制御情報または第２情報のうちの少なくとも１つを含み、前記第２制御情報は第２制御情報ＬＳＢ（Least Significant bit）及び第２制御情報ＭＳＢ（Most Significant bit）に区分され、前記第１制御情報は前記第２制御情報が前記第２制御情報ＬＳＢのみで表現できるか否かを示し、前記第２制御情報は前記ペイロードの開始から前記ペイロードで初めて転送されるデータパケットまでの距離を示すことを特徴とする。

【0021】

また、本明細書は放送信号を受信するための受信装置において、デマッピング及びデコーディング（demapping and decoding）モジュール；及び前記デマッピング及びデコーディングモジュールから出力される多数のＤＰ（Data Pipe）をインプットストリーム（Input Stream）に復元するアウトプットプロセッサ（output processor）モジュールを含み、かつ前記アウトプットプロセッサモジュールはベースバンドフレーム（Baseband Frame）のヘッダに転送された情報をデコーディング（decoding）し、前記デコーディングされた情報を用いてインプットストリーム（Input Stream）を復元するベースバンドフレームプロセッサ（Baseband Frame Processor）ブロックを含み、前記ヘッダは第１制御情報または第２情報のうちの少なくとも１つを含み、前記第２制御情報は第２制御情報ＬＳＢ（Least Significant bit）及び第２制御情報ＭＳＢ（Most Significant bit）に区分され、前記第１制御情報は前記第２制御情報が前記第２制御情報ＬＳＢのみで表現できるか否かを示し、前記第２制御情報は前記ペイロードの開始から前記ペイロードで初めて転送されるデータパケットまでの距離を示すことを特徴とする。

【発明の効果】

【0022】

本明細書は、ベースバンドフレーム（Baseband Frame）構造を新しく定義することによって、ＢＢフレームヘッダの転送に対するオーバーヘッドを減らすことができる効果がある。

【0023】

また、本明細書はＢＢフレームに含まれるスタッフィング（または、パディング）フィールドを活用してインバンドシグナリングなど、多様な機能を追加することができる効果がある。

【0024】

また、本明細書はＢＢフレームヘッダの残っているビットを活用してエラーチェック（error check）の機能を追加的に遂行することができる効果がある。

【0025】

本明細書における得られる効果は、以上で言及した効果に制限されず、言及しない更に他の効果は以下の記載から本発明が属する技術分野で通常の知識を有する者に明確に理解されるべきである。

【図面の簡単な説明】

【0026】

本発明に対してさらに理解するために含まれて、本出願に含まれて、その一部を構成する添付の図面は本発明の原理を説明する詳細な説明と共に本発明の実施形態を示す。

【0027】

【図1】本発明の一実施形態に係る次世代放送サービスに対する放送信号送信装置の構造を示す。

【図2】本発明の一実施形態に係るインプットフォーマッティング（Input formatting：入力フォーマット）ブロックを示す。

【図3】本発明の他の一実施形態に係るインプットフォーマッティング（Input formatting：入力フォーマット）ブロックを示す。

【図4】本発明の他の一実施形態に係るインプットフォーマッティング（Input formatting：入力フォーマット）ブロックを示す。

【図5】本発明の一実施形態に係るＢＩＣＭ（bit interleaved coding & modulation）ブロックを示す。

【図6】本発明の他の一実施形態に係るＢＩＣＭブロックを示す。

【図7】本発明の一実施形態に係るフレームビルディング（Frame Building：フレーム生成）ブロックを示す。

【図8】本発明の一実施形態に係るＯＦＤＭ（orthogonal frequency division multiplexing）ジェネレーション（generation：生成）ブロックを示す。

【図9】本発明の一実施形態に係る次世代放送サービスに対する放送信号受信装置の構造を示す。

【図10】本発明の一実施形態に係るフレーム構造を示す。

【図11】本発明の一実施形態に係るフレームのシグナリング階層構造を示す。

【図12】本発明の一実施形態に係るプリアンブルシグナリングデータを示す。

【図13】本発明の一実施形態に係るＰＬＳ１データを示す。

【図14】本発明の一実施形態に係るＰＬＳ２データを示す。

【図15】本発明の他の一実施形態に係るＰＬＳ２データを示す。

【図16】本発明の一実施形態に係るフレームのロジカル（logical：論理）構造を示す。

【図17】本発明の一実施形態に係るＰＬＳ（physical layer signalling）マッピングを示す。

【図18】本発明の一実施形態に係るＥＡＣ（emergency alert channel）マッピングを示す。

【図19】本発明の一実施形態に係るＦＩＣ（fast information channel）マッピングを示す。

【図20】本発明の一実施形態に係るＤＰ（data pipe：データパイプ）のタイプを示す。

【図21】本発明の一実施形態に係るＤＰ（data pipe：データパイプ）マッピングを示す。

【図22】本発明の一実施形態に係るＦＥＣ（forward error correction）構造を示す。

【図23】本発明の一実施形態に係るビットインターリービングを示す。

【図24】本発明の一実施形態に係るセル−ワードデマルチプレキシングを示す。

【図25】本発明の一実施形態に係る時間インターリービングを示す。

【図26】図９の同期及び復調（synchronization & demodulation）モジュールの一例を示す図である。

【図27】図９のフレームパーシングモジュールの一例を示す図である。

【図28】図９のデマッピング及びデコーディング（demapping& decoding）モジュールの一例を示す図である。

【図29】図９のアウトプットプロセッサ（output processor）の一例を示す図である。

【図30】図９のアウトプットプロセッサの更に他の一例を示す図である。

【図31】本発明の他の実施形態に係るコーディングアンドモジュレーションモジュールを示す図である。

【図32】本発明の他の実施形態に係るデマッピング及びデコーディングモジュールを示す図である。

【図33】本明細書で提案するモードアダプテーションモジュールの一例を示す図である。

【図34】本明細書で提案するアウトプットプロセッサの一例を示す図である。

【図35】従来のＢＢフレーム構造の一例を示す図である。

【図36】従来のＢＢフレーム構造の更に他の一例を示す図である。

【図37】従来のＢＢフレーム構造の更に他の一例を示す図である。

【図38】本明細書で提案するＢＢフレーム構造の一例を示す。

【図39】本明細書で提案するＢＢフレーム構造の更に他の一例を示す図である。

【図40】本明細書で提案するＢＢフレーム構造の更に他の一例を示す図である。

【図41】本明細書で提案するＢＢフレーム構造の更に他の一例を示す図である。

【図42】多様なＢＢフレーム構造でＢＢフレーム転送に対するオーバーヘッドを計算した結果を比較して示す図である。

【図43】従来のＢＢフレーム構造の一例を示す。

【図44】本明細書で提案するＢＢフレーム構造の一例を示す図である。

【図45】本明細書で提案するＢＢフレーム構造の更に他の一例を示す図である。

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

【0028】

本発明の好ましい実施形態に対して具体的に説明し、その例は添付した図面に示す。添付した図面を参照した以下の詳細な説明は、本発明の実施形態によって具現できる実施形態のみを示すよりは、本発明の好ましい実施形態を説明するためのものである。次の詳細な説明は、本発明に対する徹底した理解を提供するために細部事項を含む。しかしながら、本発明がこのような細部事項無しで実行できるということは当業者に自明である。

【0029】

本発明で使われる大部分の用語は該当分野で広く使われる一般的なものから選択されるが、一部の用語は出願人により任意に選択され、その意味は必要によって次の説明で詳細に叙述する。したがって、本発明は用語の単純な名称や意味でない用語の意図した意味に基づいて理解されなければならない。

【0030】

本発明は、次世代放送サービスに対する放送信号送信及び受信装置、及び方法を提供する。本発明の一実施形態に係る次世代放送サービスは、地上波放送サービス、モバイル放送サービス、ＵＨＤＴＶサービスなどを含む。本発明は一実施形態に従って非−ＭＩＭＯ（non-Multiple Input Multiple Output）またはＭＩＭＯ方式により次世代放送サービスに対する放送信号を処理することができる。本発明の一実施形態に係る非−ＭＩＭＯ方式は、ＭＩＳＯ（Multiple Input Single Output）方式、ＳＩＳＯ（Single Input Single Output）方式などを含むことができる。

【0031】

以下、説明の便宜のためにＭＩＳＯまたはＭＩＭＯ方式は２つのアンテナを使用するが、本発明は２つ以上のアンテナを使用するシステムに適用できる。本発明は、特定用途に要求される性能を達成し、かつ受信機の複雑度を最小化するために最適化した３個のフィジカルプロファイル（PHY profile）（ベース（base）、ハンドヘルド（handheld）、アドバンス（advanced）プロファイル）を定義することができる。フィジカルプロファイルは、該当する受信機が具現しなければならない全ての構造のサブセットである。

【0032】

３個のフィジカルプロファイルは大部分の機能ブロックを共有するが、特定ブロック及び／又はパラメータでは若干異なる。今後に追加でフィジカルプロファイルが定義できる。システムの発展のために、フューチャープロファイルはＦＥＦ（future extension frame）を通じて単一ＲＦ（radio frequency）チャンネルに存在するプロファイルとマルチプレキシングされることもできる。各フィジカルプロファイルに対する詳細な内容は後述する。

【0033】

１．ベースプロファイル
ベースプロファイルは主にルーフトップ（roof-top）アンテナと連結される固定された受信装置の主な用途を示す。ベースプロファイルはある場所に移動できるが、比較的停止した受信範疇に属する携帯用装置も含むことができる。ベースプロファイルの用途は若干の改善された実行によりハンドヘルド装置または車両用に拡張できるが、このような使用用途はベースプロファイル受信機動作では期待されない。

【0034】

受信のターゲット信号対雑音比の範囲は略１０乃至２０ｄＢであるが、これは既存の放送システム（例えば、ＡＴＳＣ Ａ／５３）の１５ｄＢ信号対雑音比の受信能力を含む。受信機複雑度及び消費電力はハンドヘルドプロファイルを使用するバッテリーで駆動されるハンドヘルド装置ほど重要でない。ベースプロファイルに対するの重要システムパラメータが以下の＜表１＞に記載されている。

【0035】

【表1】

【0036】

２．ハンドヘルドプロファイル
ハンドヘルドプロファイルは、バッテリー電源で駆動されるハンドヘルド及び車両用装置における使用のために設計される。該当装置は歩行者または車両速度で移動することができる。受信機複雑度だけでなく、消費電力はハンドヘルドプロファイルの装置の具現のために非常に重要である。ハンドヘルドプロファイルのターゲット信号対雑音比の範囲は略０乃至１０ｄＢであるが、より低い室内受信のために意図された場合、０ｄＢ以下に達するように設定できる。

【0037】

低信号対雑音比の能力だけでなく、受信機移動性により表れたドップラー効果に対する復原力はハンドヘルドプロファイルの最も重要な性能属性である。ハンドヘルドプロファイルに対する重要システムパラメータが以下の＜表２＞に記載されている。

【0038】

【表2】

【0039】

３．アドバンスプロファイル
アドバンスプロファイルは、より大きい実行複雑度に対する代価としてより高いチャンネル能力を提供する。該当プロファイルはＭＩＭＯ送信及び受信を使用することを要求し、ＵＨＤＴＶサービスはターゲット用途であり、このために該当プロファイルが特別に設計される。向上した能力は与えられた帯域幅でサービス数の増加、例えば、多数のＳＤＴＶまたはＨＤＴＶサービスを許容することにも使用できる。

【0040】

アドバンスプロファイルのターゲット信号対雑音比の範囲は略２０乃至３０ｄＢである。ＭＩＭＯ転送は初期には既存の楕円分極転送装備を使用し、以後に全出力交差分極転送に拡張できる。アドバンスプロファイルに対する重要システムパラメータが以下の＜表３＞に記載されている。

【0041】

【表3】

【0042】

この場合、ベースプロファイルは地上波放送サービス及びモバイル放送サービスの全てに対するプロファイルに使用できる。即ち、ベースプロファイルはモバイルプロファイルを含むプロファイルの概念を定義するために使用できる。また、アドバンスプロファイルはＭＩＭＯを有するベースプロファイルに対するアドバンスプロファイル及びＭＩＭＯを有するハンドヘルドプロファイルに対するアドバンスプロファイルに区分できる。そして、該当３個のプロファイルは設計者の意図によって変更できる。

【0043】

次の用語及び定義は本発明に適用できる。次の用語及び定義は設計によって変更できる。

【0044】

補助ストリーム：フューチャーエクステンション（future extension：今後拡張）または放送社やネットワーク運営者により要求されるにつれて、使用できる未だ定義されていない変調及びコーディングのデータを伝達するセルのシーケンス

【0045】

ベースデータパイプ（base data pipe）：サービスシグナリングデータを伝達するデータパイプ

【0046】

ベースバンドフレーム（または、BB FRAME）：１つのＦＥＣエンコーディング過程（ＢＣＨ及びＬＤＰＣエンコーディング）に対する入力を形成するＫｂｃｈビットの集合

【0047】

セル（cell）：ＯＦＤＭ転送の１つのキャリアにより伝達される変調値

【0048】

コーディングブロック（coded block）：ＰＬＳ１データのＬＤＰＣエンコーディングされたブロックまたはＰＬＳ２データのＬＤＰＣエンコーディングされたブロックのうちの１つ

【0049】

データパイプ（data pipe）：１つまたは多数のサービスまたはサービスコンポーネントを伝達することができるサービスデータ、または関連したメタデータを伝達する物理階層（physical layer）におけるロジカルチャンネル

【0050】

データパイプユニット（ＤＰＵ：data pipe unit）：データセルをフレームでのデータパイプに割り当てることができる基本ユニット

【0051】

データシンボル（data symbol）：プリアンブルシンボルでないフレームでのＯＦＤＭシンボル（フレームシグナリングシンボル及びフレームエッジ（edge）シンボルはデータシンボルに含まれる。）

【0052】

ＤＰ＿ＩＤ：該当８ビットフィールドはＳＹＳＴＥＭ＿ＩＤにより識別されたシステム内でデータパイプを唯一に識別する。

【0053】

ダミーセル（dummy cell）：ＰＬＳ（physical layer signalling）シグナリング、データパイプ、または補助ストリームのために使われない残っている容量を詰めることに使われる疑似ランダム値を伝達するセル

【0054】

ＦＡＣ（emergency alert channel：非常警報チャンネル）：ＥＡＳ情報データを伝達するフレームのうちの一部

【0055】

フレーム（frame）：プリアンブルで始めてフレームエッジシンボルで終了する物理階層（physical layer）タイムスロット

【0056】

フレームレピティションユニット（frame repetition unit：フレーム反復単位）：スーパーフレーム（super-frame）で８回反復されるＦＥＦを含む同一または異なるフィジカルプロファイルに属するフレームの集合

【0057】

ＦＩＣ（fast information channel：高速情報チャンネル）：サービスと該当ベースデータパイプとの間でのマッピング情報を伝達するフレームにおけるロジカルチャンネル

【0058】

ＦＥＣＢＬＯＣＫ：データパイプデータのＬＤＰＣエンコーディングされたビットの集合

【0059】

ＦＦＴサイズ：基本周期Ｔのサイクルで表現されたアクティブシンボル周期Ｔｓと同一な特定モードに使われる名目上のＦＦＴサイズ

【0060】

フレームシグナリングシンボル（frame signaling symbol）：ＰＬＳデータの一部を伝達する、ＦＦＴサイズ、ガードインターバル（guard interval）、及びスキャッタ（scattered）パイロットパターンの特定組合せにおけるフレームの開始で使われるより高いパイロット密度を有するＯＦＤＭシンボル

【0061】

フレームエッジシンボル（frame edge symbol）：ＦＦＴサイズ、ガードインターバル、及びスキャッタパイロットパターンの特定組合せにおけるフレームの端で使われる、より高いパイロット密度を有するＯＦＤＭシンボル

【0062】

フレームグルーフ（frame-group）：スーパーフレームで同一なフィジカルプロファイルタイプを有する全てのフレームの集合

【0063】

フューチャーエクステンションフレーム（future extention frame：今後拡張フレーム）：プリアンブルで始める、今後拡張に使用できるスーパーフレーム内で物理階層（physical layer）タイムスロット

【0064】

フューチャーキャスト（future cast）ＵＴＢシステム：入力が１つ以上のＭＰＥＧ２−ＴＳまたはＩＰ（Internet protocol）または一般ストリームであり、出力がＲＦシグナルである提案された物理階層（physical layer）放送システム

【0065】

インプットストリーム（input stream：入力ストリーム）：システムにより最終ユーザに伝達されるサービスの調和（ensemble）のためのデータのストリーム

【0066】

ノーマル（normal）データシンボル：フレームシグナリングシンボル及びフレームエッジシンボルを除外したデータシンボル

【0067】

フィジカルプロファイル（PHY profile）：該当する受信機が具現しなければならない全ての構造のサブセット

【0068】

ＰＬＳ：ＰＬＳ１及びＰＬＳ２で構成された物理階層（physical layer）シグナリングデータ

【0069】

ＰＬＳ１：ＰＬＳ２のデコーディングに必要とするパラメータだけでなく、システムに関する基本情報を伝達する固定されたサイズ、コーディング、変調を有するＦＳＳ（frame signalling symbol）に伝達されるＰＬＳデータの第１の集合

【0070】

ＮＯＴＥ：ＰＬＳ１データはフレームグルーフのデュレーション（duration）の間一定である。

【0071】

ＰＬＳ２：データパイプ及びシステムに関するより詳細なＰＬＳデータを伝達するＦＳＳに転送されるＰＬＳデータの第２の集合

【0072】

ＰＬＳ２ダイナミック（dynamic：動的）データ：フレーム毎にダイナミック（dynamic：動的）に変化するＰＬＳ２データ

【0073】

ＰＬＳ２スタティック（static：静的）データ：フレームグルーフのデュレーションの間スタティック（static：静的）なＰＬＳ２データ

【0074】

プリアンブルシグナリングデータ（preamble signaling data）：プリアンブルシンボルにより伝達され、システムの基本モードを確認することに使われるシグナリングデータ

【0075】

プリアンブルシンボル（preamble symbol）：基本ＰＬＳデータを伝達し、フレームの開始に位置する固定された長さのパイロットシンボル

【0076】

ＮＯＴＥ：プリアンブルシンボルは、システム信号、そのタイミング、周波数オフセット、及びＦＦＴサイズを検出するために高速初期バンドスキャンに主に使われる。

【0077】

今後使用（future use）のためにリザーブド（reserved）：現在文書で定義されないが、今後に定義できる

【0078】

スーパーフレーム（superframe）：８個のフレーム反復単位の集合

【0079】

タイムインターリービングブロック（time interleaving block：TI block）：タイムインターリーバメモリの１つの用途に該当する、タイムインターリービングが実行されるセルの集合

【0080】

タイムインターリービンググルーフ（time interleaving group：TI group）：整数、ダイナミック（dynamic：動的）に変化するＸＦＥＣＢＬＯＣＫの数からなる、特定データパイプに対するダイナミック（dynamic：動的）容量割当が実行される単位

【0081】

ＮＯＴＥ：タイムインターリービンググルーフは１つのフレームに直接マッピングされるか、または多数のフレームにマッピングできる。タイムインターリービンググルーフは１つ以上のタイムインターリービングブロックを含むことができる。

【0082】

タイプ１のデータパイプ（Type 1 DP）：全てのデータパイプがフレームにＴＤＭ（time division multiplexing）方式によりマッピングされるフレームのデータパイプ

【0083】

タイプ２のデータパイプ（Type 2 DP）：全てのデータパイプがフレームにＦＤＭ方式によりマッピングされるフレームのデータパイプ

【0084】

ＸＦＥＣＢＬＯＣＫ：１つのＬＤＰＣ ＦＥＣＢＬＯＣＫの全てのビットを伝達するＮ_{ｃｅｌｌｓ}セルの集合

【0085】

図１は、本発明の一実施形態に係る次世代放送サービスに対する放送信号送信装置の構造を示す。

【0086】

本発明の一実施形態に係る次世代放送サービスに対する放送信号送信装置は、インプットフォーマットブロック（Input Format block）１０００、ＢＩＣＭ（bit interleaved coding & modulation）ブロック１０１０、フレームビルディングブロック（Frame building block）１０２０、ＯＦＤＭ（orthogonal frequency division multiplexing）ジェネレーションブロック（OFDM generation block）１０３０、及びシグナリング生成ブロック１０４０を含むことができる。放送信号送信装置の各ブロックの動作について説明する。

【0087】

ＩＰストリーム／パケット及びＭＰＥＧ２−ＴＳは主要入力フォーマットであり、他のストリームタイプは一般ストリームとして扱われる。これらデータ入力に追加で、管理情報が入力されて各入力ストリームに対する該当帯域幅のスケジューリング及び割当を制御する。１つまたは多数のＴＳストリーム、ＩＰストリーム、及び／又は一般ストリーム入力が同時に許容される。

【0088】

インプットフォーマットブロック１０００は各々の入力ストリームを独立的なコーディング及び変調が適用される１つまたは多数のデータパイプにデマルチプレキシングすることができる。データパイプは堅固性（robustness）の制御のための基本単位であり、これはＱｏＳ（Quality of Service）に影響を及ぼす。１つまたは多数のサービスまたはサービスコンポーネントが１つのデータパイプにより伝達できる。インプットフォーマットブロック１０００の詳細な動作は後述する。

【0089】

データパイプは１つまたは多数のサービスまたはサービスコンポーネントを伝達することができるサービスデータ、または関連メタデータを伝達する物理階層（physical layer）におけるロジカルチャンネルである。

【0090】

また、データパイプユニットは１つのフレームでデータセルをデータパイプに割り当てるための基本ユニットである。

【0091】

インプットフォーマットブロック１０００で、パリティ（parity）データはエラー訂正のために追加され、エンコーディングされたビットストリームは複素数値コンステレーションシンボルにマッピングされる。該当シンボルは該当データパイプに使われる特定インターリービング深さに亘ってインターリービングされる。アドバンスプロファイルにおいて、ＢＩＣＭブロック１０１０でＭＩＭＯエンコーディングが実行され、追加データ経路がＭＩＭＯ転送のために出力に追加される。ＢＩＣＭブロック１０１０の詳細な動作は後述する。

【0092】

フレームビルディングブロック１０２０は、１つのフレーム内で入力データパイプのデータセルをＯＦＤＭシンボルにマッピングすることができる。マッピング後、周波数領域ダイバーシティのために、特に周波数選択的フェーディングチャンネルを防止するために、周波数インターリービングが用いられる。フレームビルディングブロック１０２０の詳細な動作は後述する。

【0093】

プリアンブルを各フレームの開始に挿入した後、ＯＦＤＭジェネレーションブロック１０３０はサイクリックプレフィックス（cyclic prefix）をガードインターバルとして有する既存のＯＦＤＭ変調を適用することができる。アンテナスペースダイバーシティのために、分散された（distributed）ＭＩＳＯ方式が送信機に亘って適用される。また、ＰＡＰＲ（peak-to-average power ratio）方式が時間領域で実行される。柔軟なネットワーク方式のために、該当の提案は多様なＦＦＴサイズ、ガードインターバル長さ、該当パイロットパターンの集合を提供する。ＯＦＤＭジェネレーションブロック１０３０の詳細な動作は後述する。

【0094】

シグナリング生成ブロック１０４０は、各機能ブロックの動作に使われる物理階層（physical layer）シグナリング情報を生成することができる。また、該当シグナリング情報は関心あるサービスが受信機側で適切に復旧されるように転送される。シグナリング生成ブロック１０４０の詳細な動作は後述する。

【0095】

図２、図３、及び図４は、本発明の実施形態に係るインプットフォーマットブロック１０００を示す。各図面に対して説明する。

【0096】

図２は、本発明の一実施形態に係るインプットフォーマットブロックを示す。図２は、入力信号が単一入力ストリーム（single input stream）の時のインプットフォーマットブロックを示す。

【0097】

図２に図示されたインプットフォーマットブロックは、図１を参照して説明したインプットフォーマットブロック１０００の一実施形態に該当する。

【0098】

物理階層（physical layer）への入力は１つまたは多数のデータストリームで構成できる。各々のデータストリームは１つのデータパイプにより伝達される。モードアダプテーション（mode adaptaion：モード適応）モジュールは入力されるデータストリームをＢＢＦ（baseband frame）のデータフィールドにスライスする。該当システムは３種類の入力データストリーム、即ちＭＰＥＧ２−ＴＳ、ＩＰ、ＧＳ（generic stream）をサポートする。ＭＰＥＧ２−ＴＳは第１のバイトが同期バイト（０×４７）である固定された長さ（１８８バイト）のパケットを特徴とする。ＩＰストリームはＩＰパケットヘッダ内でシグナリングされる可変長さＩＰデータグラムパケットで構成される。該当システムはＩＰストリームに対してＩＰｖ４とＩＰｖ６を全てサポートする。ＧＳはカプセル化パケットヘッダ内でシグナリングされる可変長さパケットまたは一定長さパケットで構成できる。

【0099】

（ａ）は信号データパイプに対するモードアダプテーション（mode adaptaion：モード適応）ブロック２０００、及びストリームアダプテーション（stream adaptation：ストリーム適応）２０１０を示し、（ｂ）はＰＬＳデータを生成及び処理するためのＰＬＳ生成ブロック２０２０及びＰＬＳスクランブラー２０３０を示す。各ブロックの動作について説明する。

【0100】

入力ストリームスプリッタは、入力されたＴＳ、ＩＰ、ＧＳストリームを多数のサービスまたはサービスコンポーネント（オーディオ、ビデオなど）ストリームに分割する。モードアダプテーション（mode adaptaion：モード適応）モジュール２０１０は、ＣＲＣエンコーダ、ＢＢ（baseband）フレームスライサー、及びＢＢフレームヘッダ挿入ブロックで構成される。

【0101】

ＣＲＣエンコーダは、ユーザパケット（user packet：ＵＰ）レベルでのエラー検出のための３種類のＣＲＣエンコーディング、即ちＣＲＣ−８、ＣＲＣ−１６、ＣＲＣ−３２を提供する。算出されたＣＲＣバイトはＵＰの後に添付される。ＣＲＣ−８はＴＳストリームに使われ、ＣＲＣ−３２はＩＰストリームに使われる。ＧＳストリームがＣＲＣエンコーディングを提供しなければ、提案されたＣＲＣエンコーディングが適用されなければならない。

【0102】

ＢＢフレームスライサーは、入力を内部ロジカルビットフォーマットにマッピングする。第１の受信ビットはＭＳＢと定義する。ＢＢフレームスライサーは、使用可能データフィールド容量と同一な数の入力ビットを割り当てる。ＢＢＦペイロードと同一な数の入力ビットを割り当てるために、ＵＰストリームがＢＢＦのデータフィールドに合うようにスライスされる。

【0103】

ＢＢフレームヘッダ挿入ブロックは、２バイトの固定された長さのＢＢＦヘッダをＢＢフレームの前に挿入することができる。ＢＢＦヘッダは、ＳＴＵＦＦＩ（１ビット）、ＳＹＮＣＤ（１３ビット）、及びＲＦＵ（２ビット）で構成される。固定された２バイトＢＢＦヘッダだけでなく、ＢＢＦは２バイトＢＢＦヘッダの端に拡張フィールド（１または３バイト）を有することができる。

【0104】

ストリームアダプテーション（stream adaptation：ストリーム適応）２０１０は、スタッフィング（stuffing）挿入ブロック及びＢＢスクランブラーで構成される。スタッフィング挿入ブロックは、スタッフィングフィールドをＢＢフレームのペイロードに挿入することができる。ストリームアダプテーション（stream adaptation：ストリーム適応）に対する入力データがＢＢフレームを詰めることに充分であれば、ＳＴＵＦＦＩは０に設定され、ＢＢＦはスタッフィングフィールドを有しない。でなければ、ＳＴＵＦＦＩは１に設定され、スタッフィングフィールドはＢＢＦヘッダの直後に挿入される。スタッフィングフィールドは、２バイトのスタッフィングフィールドヘッダ及び可変サイズのスタッフィングデータを含む。

【0105】

ＢＢスクランブラーは、エネルギー分散のために完全なＢＢＦをスクランブリングする。スクランブリングシーケンスは、ＢＢＦと同期化される。スクランブリングシーケンスは、フィードバックシフトレジスタにより生成される。

【0106】

ＰＬＳ生成ブロック２０２０は、ＰＬＳデータを生成することができる。ＰＬＳは、受信機でフィジカルレイヤ（physical layer）データパイプに接続できる手段を提供する。ＰＬＳデータは、ＰＬＳ１データ及びＰＬＳ２データで構成される。

【0107】

ＰＬＳ１データは、ＰＬＳ２データのデコーディングに必要とするパラメータだけでなく、システムに関する基本情報を伝達する固定されたサイズ、コーディング、変調を有するフレームからＦＳＳに伝達されるＰＬＳデータの第１の集合である。ＰＬＳ１データは、ＰＬＳ２データの受信及びデコーディングを可能にすることに要求されるパラメータを含む基本送信パラメータを提供する。また、ＰＬＳ１データはフレームグルーフのデュレーションの間一定である。

【0108】

ＰＬＳ２データは、データパイプ及びシステムに関するより詳しいＰＬＳデータを伝達するＦＳＳに転送されるＰＬＳデータの第２の集合である。ＰＬＳ２は、受信機が所望のデータパイプをデコーディングすることに充分の情報を提供するパラメータを含む。ＰＬＳ２シグナリングは、ＰＬＳ２スタティック（static：静的）データ（ＰＬＳ２−ＳＴＡＴデータ）及びＰＬＳ２ダイナミック（dynamic：動的）データ（ＰＬＳ２−ＤＹＮデータ）の２種類のパラメータでさらに構成される。ＰＬＳ２スタティック（static：静的）データは、フレームグルーフのデュレーションの間スタティック（static：静的）なＰＬＳ２データであり、ＰＬＳ２ダイナミック（dynamic：動的）データはフレーム毎にダイナミック（dynamic：動的）に変化するＰＬＳ２データである。

【0109】

ＰＬＳデータに対する詳細な内容は後述する。

【0110】

ＰＬＳスクランブラー２０３０は、エネルギー分散のために生成されたＰＬＳデータをスクランブリングすることができる。

【0111】

前述したブロックは省略されることもでき、類似または同一機能を有するブロックにより取り替えることもできる。

【0112】

図３は、本発明の他の一実施形態に係るインプットフォーマットブロックを示す。

【0113】

図３に図示されたインプットフォーマットブロックは、図１を参照して説明したインプットフォーマットブロック１０００の一実施形態に該当する。

【0114】

図３は、入力信号がマルチインプットストリーム（multi input stream：多数の入力ストリーム）に該当する場合、インプットフォーマットブロックのモードアダプテーション（mode adaptaion：モード適応）ブロックを示す。

【0115】

マルチインプットストリーム（multiinput stream：多数の入力ストリーム）を処理するためのインプットフォーマットブロックのモードアダプテーション（mode adaptaion：モード適応）ブロックは、多数入力ストリームを独立的に処理することができる。

【0116】

図３を参照すると、マルチインプットストリーム（multiinput stream：多数の入力ストリーム）を各々処理するためのモードアダプテーション（mode adaptaion：モード適応）ブロックは、インプットストリームスプリッタ（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 adaptaion：モード適応）ブロックの各ブロックに対して説明する。

【0117】

ＣＲＣエンコーダ３０５０、ＢＢフレームスライサー３０６０、及びＢＢヘッダ挿入ブロック３０７０の動作は、図２を参照して説明したＣＲＣエンコーダ、ＢＢフレームスライサー、及びＢＢヘッダ挿入ブロックの動作に該当するので、その説明は省略する。

【0118】

インプットストリームスプリッタ３０００は、入力されたＴＳ、ＩＰ、ＧＳストリームを多数のサービスまたはサービスコンポーネント（オーディオ、ビデオなど）ストリームに分割する。

【0119】

インプットストリームシンクロナイザー３０１０は、ＩＳＳＹと呼ばれることができる。ＩＳＳＹは如何なる入力データフォーマットに対してもＣＢＲ（constant bit rate）及び一定の終端間転送（end-to-end transmission）遅延を保証する適した手段を提供することができる。ＩＳＳＹはＴＳを伝達する多数のデータパイプの場合に常に用いられ、ＧＳストリームを伝達する多数のデータパイプに選択的に用いられる。

【0120】

コンペンセーティングディレイ（compensation delay：補償遅延）ブロック３０２０は、受信機で追加でメモリを必要とせず、ＴＳパケット再結合メカニズムを許容するためにＩＳＳＹ情報の挿入に後続する分割されたＴＳパケットストリームを遅延させることができる。

【0121】

ヌルパケットディリーションブロック３０３０は、ＴＳ入力ストリームの場合のみに使われる。一部のＴＳ入力ストリームまたは分割されたＴＳストリームはＶＢＲ（variable bit-rate）サービスをＣＢＲ ＴＳストリームに収容するために存在する多数のヌルパケットを有することができる。この場合、不要な転送オーバーヘッドを避けるために、ヌルパケットは確認されて転送されないことがある。受信機で、除去されたヌルパケットは転送に挿入されたＤＮＰ（deleted null-packet：除去されたヌルパケット）カウンターを参照して元の存在していた正確な場所に再挿入できるので、ＣＢＲが保証され、タイムスタンプ（ＰＣＲ）更新の必要がなくなる。

【0122】

ヘッダコンプレッションブロック３０４０は、ＴＳまたはＩＰ入力ストリームに対する転送効率を増加させるためにパケットヘッダ圧縮を提供することができる。受信機はヘッダの特定部分に対する先験的な（a priori）情報を有することができるので、この知られた情報（known information）は送信機から削除できる。

【0123】

ＴＳに対し、受信機は同期バイト構成（０×４７）及びパケット長さ（１８８バイト）に関する先験的な情報を有することができる。入力されたＴＳが１つのＰＩＤのみを有するコンデンツを伝達すれば、即ち、１つのサービスコンポーネント（ビデオ、オーディオなど）、またはサービスサブコンポーネント（ＳＶＣベースレイヤ、ＳＶＣインヘンスメントレイヤ、ＭＶＣベースビュー、またはＭＶＣ依存ビュー）に対してのみ、ＴＳパケットヘッダ圧縮がＴＳに（選択的に）適用できる。ＴＳパケットヘッダ圧縮は入力ストリームがＩＰストリームの場合、選択的に使われる。前記ブロックは省略されるか、類似または同一機能を有するブロックに取り替えることができる。

【0124】

図４は、本発明の他の実施形態に係るインプットフォーマットブロックを示す。

【0125】

図４に図示されたインプットフォーマットブロックは、図１を参照して説明したインプットフォーマットブロック１０００の一実施形態に該当する。

【0126】

図４は、入力信号がマルチインプットストリーム（multi input stream：多数の入力ストリーム）に該当する場合、インプットフォーマットブロックのストリームアダプテーション（stream adaptation：ストリーム適応）ブロックを示す。

【0127】

図４を参照すると、マルチインプットストリーム（multi input stream：多数の入力ストリーム）を各々処理するためのモードアダプテーション（mode adaptaion：モード適応）ブロックは、スケジューラー４０００、１−フレームディレイ（delay）ブロック４０１０、スタッフィング挿入ブロック４０２０、インバンド（In-band）シグナリングブロック４０３０、ＢＢフレームスクランブラー４０４０、ＰＬＳ生成ブロック４０５０、及びＰＬＳスクランブラー４０６０を含むことができる。ストリームアダプテーション（stream adaptation：ストリーム適応）ブロックの各ブロックに対して説明する。

【0128】

スタッフィング挿入ブロック４０２０、ＢＢフレームスクランブラー４０４０、ＰＬＳ生成ブロック４０５０、ＰＬＳスクランブラー４０６０の動作は、図２を参照して説明したスタッフィング挿入ブロック、ＢＢスクランブラー、ＰＬＳ生成ブロック、ＰＬＳスクランブラー４０６０の動作に該当するので、その説明は省略する。

【0129】

スケジューラー４０００は各データパイプのＦＥＣＢＬＯＣＫの量から全体フレームに亘って全体のセル割当を決定することができる。ＰＬＳ、ＥＡＣ、及びＦＩＣに対する割当を含んで、スケジューラーはフレームのＦＳＳのＰＬＳセルまたはインバンド（In-band）シグナリングに転送されるＰＬＳ２−ＤＹＮデータの値を生成する。ＦＥＣＢＬＯＣＫ、ＥＡＣ、ＦＩＣに対する詳細な内容は後述する。

【0130】

１−フレームディレイ（delay）ブロック４０１０は、次のフレームに関するスケジューリング情報がデータパイプに挿入されるインバンド（In-band）シグナリング情報に関する現フレームを通じて転送できるように入力データを１つの転送フレームだけ遅延させることができる。

【0131】

インバンド（In-band）シグナリングブロック４０３０は、ＰＬＳ２データの遅延されない部分をフレームのデータパイプに挿入することができる。

【0132】

前述したブロックは省略されるか、類似または同一機能を有するブロックに取り替えることができる。

【0133】

図５は、本発明の一実施形態に係るＢＩＣＭブロックを示す。

【0134】

図５に図示されたＢＩＣＭブロックは、図１を参照して説明したＢＩＣＭブロック１０１０の一実施形態に該当する。

【0135】

前述したように、本発明の一実施形態に係る次世代放送サービスに対する放送信号送信装置は、地上波放送サービス、モバイル放送サービス、ＵＨＤＴＶサービスなどを提供することができる。

【0136】

ＱｏＳが本発明の一実施形態に係る次世代放送サービスに対する放送信号送信装置により提供されるサービスの特性に依存するので、各々のサービスに該当するデータは互いに異なる方式により処理されなければならない。したがって、本発明の一実施形態に係るＢＩＣＭブロックは、ＳＩＳＯ、ＭＩＳＯ、ＭＩＭＯ方式を各々のデータ経路に該当するデータパイプに独立的に適用することによって、各データパイプを独立的に処理することができる。結果的に、本発明の一実施形態に係る次世代放送サービスに対する放送信号送信装置は、各々のデータパイプを介して転送される各サービスまたはサービスコンポーネントに対するＱｏＳを調節することができる。

【0137】

（ａ）はベースプロファイル及びハンドヘルドプロファイルにより共有されるＢＩＣＭブロックを示し、（ｂ）はアドバンスプロファイルのＢＩＣＭブロックを示す。
ベースプロファイル及びハンドヘルドプロファイルにより共有されるＢＩＣＭブロック及びアドバンスプロファイルのＢＩＣＭブロックは、各々のデータパイプを処理するための複数の処理ブロックを含むことができる。

【0138】

ベースプロファイル及びハンドヘルドプロファイルに対するＢＩＣＭブロック及びアドバンスプロファイルに対するＢＩＣＭブロックの各々の処理ブロックに対して説明する。

【0139】

ベースプロファイル及びハンドヘルドプロファイルに対するＢＩＣＭブロックの処理ブロック５０００は、データＦＥＣエンコーダ５０１０、ビットインターリーバ５０２０、コンステレーションマッパー（mapper）５０３０、ＳＳＤ（signal space diversity）エンコーディングブロック５０４０、及びタイムインターリーバ５０５０を含むことができる。

【0140】

データＦＥＣエンコーダ５０１０は、外部コーディング（ＢＣＨ）及び内部コーディング（ＬＤＰＣ）を用いてＦＥＣＢＬＯＣＫ手続を生成するために入力ＢＢＦにＦＥＣエンコーディングを実行する。外部コーディング（ＢＣＨ）は選択的なコーディング方法である。データＦＥＣエンコーダ５０１０の具体的な動作に対しては後述する。

【0141】

ビットインターリーバ５０２０は、効率的に実現可能な構造を提供しながらデータＦＥＣエンコーダ５０１０の出力をインターリービングしてＬＤＰＣコード及び変調方式の組合せにより最適化された性能を達成することができる。ビットインターリーバ５０２０の具体的な動作に対しては後述する。

【0142】

コンステレーションマッパー５０３０は、ＱＰＳＫ、ＱＡＭ−１６、不均一ＱＡＭ（ＮＵＱ−６４、ＮＵＱ−２５６、ＮＵＱ−１０２４）、または不均一コンステレーション（ＮＵＣ−１６、ＮＵＣ−６４、ＮＵＣ−２５６、ＮＵＣ−１０２４）を用いてベース及びハンドヘルドプロファイルでビットインターリーバ５０２０からの各々のセルワードを変調するか、またはアドバンスプロファイルでセルワードデマルチプレクサ５０１０−１からのセルワードを変調してパワーが正規化されたコンステレーションポイントｅ_ｌを提供することができる。該当コンステレーションマッピングは、データパイプに対してのみ適用される。ＮＵＱが任意の形態を有する一方、ＱＡＭ−１６及びＮＵＱは正四角形の形態を有することが観察される。各々のコンステレーションが９０度の倍数だけ回転されれば、回転されたコンステレーションは元のものと正確に重なる。回転対称特性によって実数及び虚数コンポーネントの容量及び平均パワーが互いに同一になる。ＮＵＱ及びＮＵＣは全て各コードレート（code rate）に対して特別に定義され、使用される特定の１つはＰＬＳ２データに保管されたパラメータＤＰ＿ＭＯＤによりシグナリングされる。

【0143】

ＳＳＤエンコーディングブロック５０４０は、２次元、３次元、４次元でセルをフリーコーディングして、難しいフェーディング条件で受信堅固性（robustness）を増加させることができる。

【0144】

タイムインターリーバ５０５０は、データパイプレベルで動作することができる。タイムインターリービングのパラメータは、各々のデータパイプに対して異なるように設定できる。タイムインターリーバ５０５０の具体的な動作に関しては後述する。

【0145】

アドバンスプロファイルに対するＢＩＣＭブロックの処理ブロック５０００−１は、データＦＥＣエンコーダ、ビットインターリーバ、コンステレーションマッパー、及びタイムインターリーバを含むことができる。

【0146】

但し、処理ブロック５０００−１はセルワードデマルチプレクサ５０１０−１及びＭＩＭＯエンコーディングブロック５０２０−１をさらに含むという点で処理ブロック５０００と区別される。

【0147】

また、処理ブロック５０００−１におけるデータＦＥＣエンコーダ、ビットインターリーバ、コンステレーションマッパー、タイムインターリーバの動作は、前述したデータＦＥＣエンコーダ５０１０、ビットインターリーバ５０２０、コンステレーションマッパー５０３０、タイムインターリーバ５０５０の動作に該当するので、その説明は省略する。

【0148】

セルワードデマルチプレクサ５０１０−１は、アドバンスプロファイルのデータパイプがＭＩＭＯ処理のために単一セルワードストリームを二重セルワードストリームに分離することに使われる。セルワードデマルチプレクサ５０１０−１の具体的な動作に関しては後述する。

【0149】

ＭＩＭＯエンコーディングブロック５０２０−１は、ＭＩＭＯエンコーディング方式を用いてセルワードデマルチプレクサ５０１０−１の出力を処理することができる。ＭＩＭＯエンコーディング方式は、放送信号送信のために最適化された。ＭＩＭＯ技術は、容量増加を得るための有望な方式であるが、チャンネル特性に依存する。特別に放送に対して、互いに異なる信号伝搬特性による２アンテナの間の受信信号パワーの差、またはチャンネルの強いＬＯＳコンポーネントはＭＩＭＯから容量利得を得ることを難しくする。提案されたＭＩＭＯエンコーディング方式は、ＭＩＭＯ出力信号のうちの１つの位相ランダム化及び回転基盤プリコーディングを用いてこの問題を克服する。

【0150】

ＭＩＭＯエンコーディングは、送信機及び受信機の全てで少なくとも２つのアンテナを必要とする２×２ＭＩＭＯシステムのために意図される。２つのＭＩＭＯエンコーディングモードは本提案であるＦＲ−ＳＭ（full-rate spatial multiplexing）及びＦＲＦＤ−ＳＭ（full-rate full-diversity spatial multiplexing）で定義される。ＦＲ−ＳＭエンコーディングは受信機側における比較的小さい複雑度増加により容量増加を提供する一方、ＦＲＦＤ−ＳＭエンコーディングは受信機側における大きい複雑度増加で容量増加及び追加的なダイバーシティ利得を提供する。提案されたＭＩＭＯエンコーディング方式はアンテナ極性配置を制限しない。

【0151】

ＭＩＭＯ処理はアドバンスプロファイルフレームに要求されるが、これはアドバンスプロファイルフレームにおける全てのデータパイプがＭＩＭＯエンコーダにより処理されることを意味する。ＭＩＭＯ処理はデータパイプレベルで適用される。コンステレーションマッパー出力のペア（pair：対）であるＮＵＱ（ｅ_１，ｉ及びｅ_２，ｉ）はＭＩＭＯエンコーダの入力により供給される。ＭＩＭＯエンコーダ出力ペア（pair：対）（ｇ_１，ｉ及びｇ_２，ｉ）は各々の送信アンテナの同一なキャリアｋ及びＯＦＤＭシンボルｌにより転送される。

【0152】

前述したブロックは省略されるか、類似または同一機能を有するブロックに取り替えることができる。

【0153】

図６は、本発明の他の実施形態に係るＢＩＣＭブロックを示す。

【0154】

図６に図示されたＢＩＣＭブロックは、図１を参照して説明したＢＩＣＭブロック１０１０の一実施形態に該当する。

【0155】

図６は、ＰＬＳ、ＥＡＣ、及びＦＩＣの保護のためのＢＩＣＭブロックを示す。ＥＡＣはＥＡＳ情報データを伝達するフレームの一部であり、ＦＩＣはサービスと該当するベースデータパイプとの間でマッピング情報を伝達するフレームにおけるロジカルチャンネルである。ＥＡＣ及びＦＩＣに対する詳細な説明は後述する。

【0156】

図６を参照すると、ＰＬＳ、ＥＡＣ、及びＦＩＣの保護のためのＢＩＣＭブロックは、ＰＬＳ ＦＥＣエンコーダ６０００、ビットインターリーバ６０１０、及びコンステレーションマッパー６０２０を含むことができる。

【0157】

また、ＰＬＳ ＦＥＣエンコーダ６０００は、スクランブラー、ＢＣＨエンコーディング／ゼロ挿入ブロック、ＬＤＰＣエンコーディングブロック、及びＬＤＰＣパリティパンクチャリング（puncturing）ブロックを含むことができる。ＢＩＣＭブロックの各ブロックに対して説明する。

【0158】

ＰＬＳ ＦＥＣエンコーダ６０００は、スクランブリングされたＰＬＳ １／２データ、ＥＡＣ及びＦＩＣセクションをエンコーディングすることができる。

【0159】

スクランブラーは、ＢＣＨエンコーディング及びショートニング（shortening）及びパンクチャリングされたＬＤＰＣエンコーディングの前にＰＬＳ１データ及びＰＬＳ２データをスクランブリングすることができる。

【0160】

ＢＣＨエンコーディング／ゼロ挿入ブロックは、ＰＬＳ保護のためのショートニングされたＢＣＨコードを用いてスクランブリングされたＰＬＳ １／２データに外部エンコーディングを遂行し、ＢＣＨエンコーディングの後にゼロビットを挿入することができる。ＰＬＳ１データに対してのみゼロ挿入の出力ビットがＬＤＰＣエンコーディングの前にパーミュテーション（permutation）できる。

【0161】

ＬＤＰＣエンコーディングブロックは、ＬＤＰＣコードを用いてＢＣＨエンコーディング／ゼロ挿入ブロックの出力をエンコーディングすることができる。完全なコーディングブロックを生成するために、Ｃ_ｌｄｐｃ及びパリティビットＰ_ｌｄｐｃは各々のゼロが挿入されたＰＬＳ情報ブロックＩ_ｌｄｐｃから組織的にエンコーディングされ、その後に添付される。

【0162】

【数1】

【0163】

ＰＬＳ１及びＰＬＳ２に対するＬＤＰＣコードパラメータは、次の＜表４＞の通りである。

【0164】

【表4】

【0165】

ＬＤＰＣパリティパンクチャリングブロックは、ＰＬＳ１データ及びＰＬＳ２データに対してパンクチャリングを遂行することができる。

【0166】

ショートニングがＰＬＳ１データ保護に適用されれば、一部のＬＤＰＣパリティビットはＬＤＰＣエンコーディングの後にパンクチャリングされる。また、ＰＬＳ２データ保護のために、ＰＬＳ２のＬＤＰＣパリティビットがＬＤＰＣエンコーディングの後にパンクチャリングされる。これらパンクチャリングされたビットは転送されない。

【0167】

ビットインターリーバ６０１０は、各々のショートニング及びパンクチャリングされたＰＬＳ１データ及びＰＬＳ２データをインターリービングすることができる。

【0168】

コンステレーションマッパー６０２０は、ビットインターリービングされたＰＬＳ１データ及びＰＬＳ２データをコンステレーションにマッピングすることができる。

【0169】

前述したブロックは省略されるか、類似または同一機能を有するブロックに取り替えることができる。

【0170】

図７は、本発明の一実施形態に係るフレームビルディングブロック（frame building block）を示す。

【0171】

図７に図示したフレームビルディングブロックは、図１を参照して説明したフレームビルディングブロック１０２０の一実施形態に該当する。

【0172】

図７を参照すると、フレームビルディングブロックは、ディレイコンペンセーション（delay compensation：遅延補償）ブロック７０００、セルマッパー（cell mapper）７０１０、及びフリークエンシーインターリーバ（frequency interleaver）７０２０を含むことができる。フレームビルディングブロックの各ブロックに関して説明する。

【0173】

ディレイコンペンセーション（delay compensation：遅延補償）ブロック７０００は、データパイプと該当するＰＬＳデータとの間のタイミングを調節して送信機側でデータパイプと該当するＰＬＳデータとの間の同時性（co-time）を保証することができる。インプットフォーマットブロック及びＢＩＣＭブロックによるデータパイプの遅延を扱うことによってＰＬＳデータはデータパイプだけ遅延される。ＢＩＣＭブロックの遅延は主にタイムインターリーバ５０５０によるものである。インバンド（In-band）シグナリングデータは、次のタイムインターリービンググルーフの情報をシグナリングされるデータパイプより１つのフレームの前に伝達されるようにすることができる。ディレイコンペンセーション（delay compensation：遅延補償）ブロックは、それに合せてインバンド（In-band）シグナリングデータを遅延させる。

【0174】

セルマッパー７０１０は、ＰＬＳ、ＥＡＣ、ＦＩＣ、データパイプ、補助ストリーム、及びダミーセルをフレーム内でＯＦＤＭシンボルのアクティブ（active）キャリアにマッピングすることができる。セルマッパー７０１０の基本機能は、各々のデータパイプ、ＰＬＳセル、及びＥＡＣ／ＦＩＣセルに対するタイムインターリービングにより生成されたデータセルを、存在していれば、１つのフレーム内で各々のＯＦＤＭシンボルに該当するアクティブ（active）ＯＦＤＭセルのアレイにマッピングするものである。（ＰＳＩ（program specific information）／ＳＩのような）サービスシグナリングデータは個別的に収集されてデータパイプにより送られることができる。セルマッパーはフレーム構造の構成及びスケジューラーにより生成されたダイナミックインフォメーション（dynamic information：動的情報）に従って動作する。フレームに関する詳細な内容は後述する。

【0175】

フリークエンシーインターリーバ７０２０は、セルマッパー７０１０から受信されたデータセルをランダムにインターリービングして周波数ダイバーシティを提供することができる。また、フリークエンシーインターリーバ７０２０は単一フレームで最大のインターリービング利得を得るために他のインターリービングシード（seed）の順序を用いて２つの順次的なＯＦＤＭシンボルで構成されたＯＦＤＭシンボルペア（pair：対）で動作することができる。

【0176】

前述したブロックは省略されるか、類似または同一機能を有するブロックに取り替えることができる。

【0177】

図８は、本発明の一実施形態に係るＯＦＤＭジェネレーションブロックを示す。

【0178】

図８に図示されたＯＦＤＭジェネレーションブロックは、図１を参照して説明したＯＦＤＭジェネレーションブロック１０３０の一実施形態に該当する。

【0179】

ＯＦＤＭジェネレーションブロックは、フレームビルディングブロックにより生成されたセルによりＯＦＤＭキャリアを変調し、パイロットを挿入し、転送のための時間領域信号を生成する。また、該当ブロックは順次的にガードインターバルを挿入し、ＰＡＰＲ減少処理を適用して最終のＲＦ信号を生成する。

【0180】

図８を参照すると、ＯＦＤＭジェネレーションブロックは、パイロット及びリザーブドトーン挿入ブロック（pilot and revserved tone insertion block）８０００、２Ｄ−ｅＳＦＮ（single frequency network）エンコーディングブロック８０１０、ＩＦＦＴ（inverse fast Fourier transform）ブロック８０２０、ＰＡＰＲ減少ブロック８０３０、ガードインターバル挿入ブロック（guard interval insertion block）８０４０、プリアンブル挿入ブロック（preamble insertion block）８０５０、その他のシステム挿入ブロック８０６０、及びＤＡＣブロック８０７０を含むことができる。ＯＦＤＭジェネレーションブロックの各ブロックに対して説明する。

【0181】

パイロット及びリザーブドトーン挿入ブロック８０００は、パイロット及びリザーブドトーンを挿入することができる。

【0182】

ＯＦＤＭシンボル内の多様なセルは受信機から先験的に知られた転送された値を有するパイロットとして知られた参照情報に変調される。パイロットセルの情報は、分散パイロット、連続パイロット、エッジパイロット、ＦＳＳ（frame signalling symbol）パイロット、及びＦＥＳ（frame edge symbol）パイロットで構成される。各パイロットは、パイロットタイプ及びパイロットパターンに従って特定増加パワーレベルで転送される。パイロット情報の値は与えられたシンボルで１つが各々の転送キャリアに対するものである一連の値に該当する参照シーケンスで誘導される。パイロットは、フレーム同期化、周波数同期化、時間同期化、チャンネル推定、転送モード識別のために使われることができ、また位相雑音を追跡するために使用できる。

【0183】

参照シーケンスから取った参照情報は、フレームのプリアンブル、ＦＳＳ及びＦＥＳを除外した全てのシンボルにおける分散パイロットセルで転送される。連続パイロットは、フレームの全てのシンボルに挿入される。連続パイロットの数及び位置はＦＦＴサイズ及び分散パイロットパターンに全て依存する。エッジキャリアは、プリアンブルシンボルを除外した全てのシンボル内のエッジパイロットと同一である。エッジキャリアは、スペクトルのエッジまで周波数インターポレーション（interpolation：補間）を許容するために挿入される。ＦＳＳパイロットはＦＳＳに挿入され、ＦＥＳパイロットはＦＥＳに挿入される。ＦＳＳパイロット及びＦＥＳパイロットはフレームのエッジまで時間インターポレーション（interpolation：補間）を許容するために挿入される。

【0184】

本発明の一実施形態に係るシステムは非常に堅い転送モードをサポートするために分散ＭＩＳＯ方式が選択的に使われるＳＦＮをサポートする。２Ｄ−ｅＳＦＮは多数の送信アンテナを使用する分散ＭＩＳＯ方式であって、各アンテナはＳＦＮネットワークで各々異なる送信機に位置することができる。

【0185】

２Ｄ−ｅＳＦＮエンコーディングブロック８０１０は、ＳＦＮ構成で時間及び周波数ダイバーシティを生成するために２Ｄ−ｅＳＦＮ処理を行って多数の送信機から転送された信号の位相を歪曲させることがある。したがって、長時間の間の低い平面フェーディングまたは深いフェーディングによるバースト誤りが軽減できる。

【0186】

ＩＦＦＴブロック８０２０は、ＯＦＤＭ変調方式を用いて２Ｄ−ｅＳＦＮエンコーディングブロック８０１０からの出力を変調することができる。パイロット（または、リザーブドトーン）に指定されないデータシンボルでの全てのセルは、周波数インターリーバからのデータセルのうちの１つを伝達する。セルはＯＦＤＭキャリアにマッピングされる。

【0187】

ＰＡＰＲ減少ブロック８０３０は、時間領域で多様なＰＡＰＲ減少アルゴリズムを用いて入力信号にＰＡＰＲ減少を実行する。

【0188】

ガードインターバル挿入ブロック８０４０はガードインターバルを挿入することができ、プリアンブル挿入ブロック８０５０は信号の前にプリアンブルを挿入することができる。プリアンブルの構造に対する詳細な内容は後述する。

【0189】

その他のシステム挿入ブロック８０６０は、放送サービスを提供する２つ以上の互いに異なる放送送信／受信システムのデータが同一なＲＦ信号帯域で同時に転送できるように時間領域で複数の放送送信／受信システムの信号をマルチプレキシングすることができる。この場合、２つ以上の互いに異なる放送送信／受信システムは、互いに異なる放送サービスを提供するシステムをいう。互いに異なる放送サービスは、地上波放送サービス、モバイル放送サービスなどを意味することができる。各々の放送サービスに関連したデータは互いに異なるフレームを通じて転送できる。

【0190】

ＤＡＣブロック８０７０は、入力されたディジタル信号をアナログ信号に変換して出力することができる。ＤＡＣブロック８０７０から出力された信号は物理階層プロファイルによって多数の出力アンテナを介して転送できる。本発明の一実施形態に係る送信アンテナは垂直または水平極性を有することができる。

【0191】

前述したブロックは設計によって省略されるか、類似または同一機能を有するブロックに取替できる。

【0192】

図９は、本発明の一実施形態に係る次世代放送サービスに対する放送信号受信装置の構造を示す。

【0193】

本発明の一実施形態に係る次世代放送サービスに対する放送信号受信装置は、図１を参照して説明した次世代放送サービスに対する放送信号送信装置に対応することができる。

【0194】

本発明の一実施形態に係る次世代放送サービスに対する放送信号受信装置は、同期及び復調モジュール（synchronization & demodulation module）９０００、フレームパーシングモジュール（frame parsing module）９０１０、デマッピング及びデコーディングモジュール（demapping & decoding module）９０２０、出力プロセッサ（output processor）９０３０、及びシグナリングデコーディングモジュール（signaling decoding module）９０４０を含むことができる。放送信号受信装置の各モジュールの動作に対して説明する。

【0195】

同期及び復調モジュール９０００は、ｍ個の受信アンテナを介して入力信号を受信し、放送信号受信装置に該当するシステムに対して信号検出及び同期化を実行し、放送信号送信装置により実行される手続の逆過程に該当する復調を実行することができる。

【0196】

フレームパーシングモジュール９０１０は、入力信号フレームをパーシングし、ユーザにより選択されたサービスが転送されるデータを抽出することができる。放送信号送信装置がインターリービングを実行すれば、フレームパーシングモジュール９０１０はインターリービングの逆過程に該当するデインターリービングを実行することができる。この場合、抽出されなければならない信号及びデータの位置がシグナリングデコーディングモジュール９０４０から出力されたデータをデコーディングすることにより獲得されて、放送信号送信装置により生成されたスケジューリング情報が復元できる。

【0197】

デマッピング及びデコーディングモジュール９０２０は、入力信号をビット領域データに変換した後、必要によってビット領域データをデインターリービングすることができる。デマッピング及びデコーディングモジュール９０２０は、転送効率のために適用されたマッピングに対するデマッピングを実行し、デコーディングを通じて転送チャンネルで発生したエラーを訂正することができる。この場合、デマッピング及びデコーディングモジュール９０２０はシグナリングデコーディングモジュール９０４０から出力されたデータをデコーディングすることによって、デマッピング及びデコーディングのために必要な転送パラメータを獲得することができる。

【0198】

出力プロセッサ９０３０は、転送効率を向上させるために放送信号送信装置により適用される多様な圧縮／信号処理手続の逆過程を実行することができる。この場合、出力プロセッサ９０３０はシグナリングデコーディングモジュール９０４０から出力されたデータで必要とする制御情報を獲得することができる。出力プロセッサ８３００の出力は、放送信号送信装置に入力される信号に該当し、ＭＰＥＧ−ＴＳ、ＩＰストリーム（ｖ４またはｖ６）及びＧＳでありうる。

【0199】

シグナリングデコーディングモジュール９０４０は、同期及び復調モジュール９０００により復調された信号からＰＬＳ情報を獲得することができる。前述したように、フレームパーシングモジュール９０１０、デマッピング及びデコーディングモジュール９２００、及び出力プロセッサ９３００は、シグナリングデコーディングモジュール９０４０から出力されたデータを用いてその機能を実行することができる。

【0200】

図１０は、本発明の一実施形態に係るフレーム構造を示す。

【0201】

図１０は、フレームタイムの構成例及びスーパーフレームにおけるＦＲＵ（frame repetition unit：フレーム反復単位）を示す。（ａ）は本発明の一実施形態に係るスーパーフレームを示し、（ｂ）は本発明の一実施形態に係るＦＲＵを示し、（ｃ）はＦＲＵでの多様なフィジカルプロファイル（PHY profile）のフレームを示し、（ｄ）はフレームの構造を示す。

【0202】

スーパーフレームは８個のＦＲＵで構成できる。ＦＲＵはフレームのＴＤＭに対する基本マルチプレキシング単位であり、スーパーフレームで８回反復される。

【0203】

ＦＲＵで各フレームはフィジカルプロファイル（ベース、ハンドヘルド、アドバンスプロファイル）のうちの１つまたはＦＥＦに属する。ＦＲＵで、フレームの最大許容数は４であり、与えられたフィジカルプロファイルはＦＲＵで０回乃至４回のうちのいずれかの回数だけ表れることができる（例えば、ベース、ハンドヘルド、アドバンス）。フィジカルプロファイル定義は、必要時、プリアンブルにおけるＰHY_PROFILEのリザーブド値を用いて拡張できる。

【0204】

ＦＥＦ部分は、含まれれば、ＦＲＵの端に挿入される。ＦＥＦがＦＲＵに含まれる場合、ＦＥＦの最大数はスーパーフレームで８である。ＦＥＦ部分が互いに隣接することが推奨されない。

【0205】

１つのフレームは多数のＯＦＤＭシンボル及びプリアンブルにさらに分離される。（ｄ）に図示したように、フレームは、プリアンブル、１つ以上のＦＳＳ、ノーマルデータシンボル、及びＦＥＳを含む。

【0206】

プリアンブルは高速フューチャーキャストＵＴＢシステム信号検出を可能にし、信号の効率的な送信及び受信のための基本転送パラメータの集合を提供する特別なシンボルである。プリアンブルに対する詳細な内容は後述する。

【0207】

ＦＳＳの主な目的はＰＬＳデータを伝達するものである。高速同期化及びチャンネル推定のために、これに従うＰＬＳデータの高速デコーディングのために、ＦＳＳはノーマルデータシンボルより高密度のパイロットパターンを有する。ＦＥＳはＦＳＳと完全に同一なパイロットを有するが、これはＦＥＳの直前のシンボルに対して外挿（extrapolation）無しでＦＥＳ内での周波数のみのインターポレーション（interpolation：補間）及び時間的補間（temporal interpolation）を可能にする。

【0208】

図１１は、本発明の一実施形態に係るフレームのシグナリング階層構造（signaling hierarchy structure）を示す。

【0209】

図１１はシグナリング階層構造を示すが、これは３個の主要部分であるプリアンブルシグナリングデータ１１０００、ＰＬＳ１データ１１０１０、及びＰＬＳ２データ１１０２０に分割される。毎フレーム毎にプリアンブル信号により伝達されるプリアンブルの目的は、フレームの基本転送パラメータ及び転送タイプを示すものである。ＰＬＳ１は、受信機が関心あるデータパイプに接続するためのパラメータを含むＰＬＳ２データに接続してデコーディングできるようにする。ＰＬＳ２は毎フレーム毎に伝達され、２つの主要部分であるＰＬＳ２−ＳＴＡＴデータとＰＬＳ２−ＤＹＮデータに分割される。ＰＬＳ２データのスタティック（static：静的）及びダイナミック（dynamic：動的）部分には、必要時、パッディングが後続する。

【0210】

図１２は、本発明の一実施形態に係るプリアンブルシグナリングデータを示す。

【0211】

プリアンブルシグナリングデータは、受信機がフレーム構造内でＰＬＳデータに接続し、データパイプを追跡できるようにするために必要とする２１ビットの情報を伝達する。プリアンブルシグナリングデータに対する詳細な内容は、次の通りである。

【0212】

ＰＨＹ＿ＰＲＯＦＩＬＥ：該当３ビットフィールドは現フレームのフィジカルプロファイルタイプを示す。互いに異なるフィジカルプロファイルタイプのマッピングは、以下の＜表５＞に与えられる。

【0213】

【表5】

【0214】

ＦＦＴ＿ＳＩＺＥ：該当２ビットフィールドは以下の＜表６＞で説明した通り、フレームグルーフ内で現フレームのＦＦＴサイズを示す。

【0215】

【表6】

【0216】

ＧＩ＿ＦＲＡＣＴＩＯＮ：該当３ビットフィールドは以下の＜表７＞で説明した通り、現スーパーフレームにおけるガードインターバルの一部（fraction）値を示す。

【0217】

【表7】

【0218】

ＥＡＣ＿ＦＬＡＧ：該当１ビットフィールドはＥＡＣが現フレームに提供されるか否かを示す。該当フィールドが１に設定されれば、ＥＡＳが現フレームに提供される。該当フィールドが０に設定されれば、ＥＡＳが現フレームで伝達されない。該当フィールドはスーパーフレーム内でダイナミック（dynamic：動的）に転換できる。

【0219】

ＰＩＬＯＴ＿ＭＯＤＥ：該当１ビットフィールドは現フレームグルーフで現フレームに対してパイロットモードがモバイルモードであるか、または固定モードか否かを示す。該当フィールドが０に設定されれば、モバイルパイロットモードが使われる。該当フィールドが１に設定されれば、固定パイロットモードが使われる。

【0220】

ＰＡＰＲ＿ＦＬＡＧ：該当１ビットフィールドは現フレームグルーフで現フレームに対してＰＡＰＲ減少が使われるか否かを示す。該当フィールドが１に設定されれば、トーン予約（tone reservation）がＰＡＰＲ減少のために使われる。該当フィールドが０に設定されれば、ＰＡＰＲ減少が使われない。

【0221】

ＦＲＵ＿ＣＯＮＦＩＧＵＲＥ：該当３ビットフィールドは現スーパーフレームで存在するＦＲＵのフィジカルプロファイルタイプ構成を示す。現スーパーフレームで全てのプリアンブルにおける該当フィールドで、現スーパーフレームで伝達される全てのプロファイルタイプが識別される。該当３ビットフィールドは以下の＜表８＞に示した通り、各々のプロファイルに対して異なるように定義される。

【0222】

【表8】

【0223】

ＲＥＳＥＲＶＥＤ：該当７ビットフィールドは今後の使用のためにリザーブド（reserved）される。

【0224】

図１３は、本発明の一実施形態に係るＰＬＳ１データを示す。

【0225】

ＰＬＳ１データはＰＬＳ２の受信及びデコーディングを可能にするために必要なパラメータを含んだ基本転送パラメータを提供する。前述したように、ＰＬＳ１データは１つのフレームグルーフの全体デュレーションの間変化しない。ＰＬＳ１データのシグナリングフィールドの具体的な定義は、次の通りである。

【0226】

ＰＲＥＡＭＢＬＥ＿ＤＡＴＡ：該当２０ビットフィールドはＥＡＣ＿ＦＬＡＧを除外したプリアンブルシグナリングデータのコピーである。

【0227】

ＮＵＭ＿ＦＲＡＭＥ＿ＦＲＵ：該当２ビットフィールドはＦＲＵ当たりフレーム数を示す。

【0228】

ＰＡＹＬＯＡＤ＿ＴＹＰＥ：該当３ビットフィールドはフレームグルーフで伝達されるペイロードデータのフォーマットを示す。ＰＡＹＬＯＡＤ＿ＴＹＰＥは＜表９＞に示した通りシグナリングされる。

【0229】

【表9】

【0230】

ＮＵＭ＿ＦＳＳ：該当２ビットフィールドは現フレームでＦＳＳの数を示す。

【0231】

ＳＹＳＴＥＭ＿ＶＥＲＳＩＯＮ：該当８ビットフィールドは転送される信号フォーマットのバージョンを示す。ＳＹＳＴＥＭ＿ＶＥＲＳＩＯＮは主バージョン及び副バージョンの２つの４ビットフィールドに分離される。

【0232】

主バージョン：ＳＹＳＴＥＭ＿ＶＥＲＳＩＯＮフィールドのＭＳＢである４ビットは主バージョン情報を示す。主バージョンフィールドでの変化は互換が不可能な変化を示す。デフォルト値は００００である。該当標準で叙述されたバージョンに対し、値が００００に設定される。

【0233】

副バージョン：ＳＹＳＴＥＭ＿ＶＥＲＳＩＯＮフィールドのＬＳＢである４ビットは副バージョン情報を示す。副バージョンフィールドでの変化は互換が可能である。

【0234】

ＣＥＬＬ＿ＩＤ：これはＡＴＳＣネットワークにおける地理的セルを唯一に識別する１６ビットフィールドである。ＡＴＳＣセルカバレッジはフューチャーキャストＵＴＢシステム当たり使われる周波数の数によって１つ以上の周波数で構成できる。ＣＥＬＬ＿ＩＤの値が知られていないか、特定されなければ、該当フィールドは０に設定される。

【0235】

ＮＥＴＷＯＲＫ＿ＩＤ：これは現ＡＴＳＣネットワークを唯一に識別する１６ビットフィールドである。

【0236】

ＳＹＳＴＥＭ＿ＩＤ：該当１６ビットフィールドはＡＴＳＣネットワーク内でフューチャーキャストＵＴＢシステムを唯一に識別する。フューチャーキャストＵＴＢシステムは入力が１つ以上の入力ストリーム（ＴＳ、ＩＰ、ＧＳ）であり、出力がＲＦ信号である地上波放送システムである。フューチャーキャストＵＴＢシステムは、存在していれば、ＦＥＦ及び１つ以上のフィジカルプロファイルを伝達する。同一なフューチャーキャストＵＴＢシステムは互いに異なる入力ストリームを伝達し、互いに異なる地理的領域で互いに異なるＲＦを使用することができるので、ローカルサービス挿入を許容する。フレーム構造及びスケジューリングは１つの場所で制御され、フューチャーキャストＵＴＢシステム内で全ての転送に対して同一である。１つ以上のフューチャーキャストＵＴＢシステムは全て同一なフィジカル構造及び構成を有するという同一なＳＹＳＴＥＭ＿ＩＤの意味を有することができる。

【0237】

次のループ（loop）は、各フレームタイプの長さ及びＦＲＵ構成を示すＦＲＵ＿ＰＨＹ＿ＰＲＯＦＩＬＥ、ＦＲＵ＿ＦＲＡＭＥ＿ＬＥＮＧＴＨ、ＦＲＵ＿ＧＩ＿ＦＲＡＣＴＩＯＮ、及びＲＥＳＥＲＶＥＤで構成される。ループ（loop）サイズはＦＲＵ内で４個のフィジカルプロファイル（ＦＥＦ含み）がシグナリングされるように固定される。ＮＵＭ＿ＦＲＡＭＥ＿ＦＲＵが４より小さければ、使われないフィールドはゼロで詰められる。

【0238】

ＦＲＵ＿ＰＨＹ＿ＰＲＯＦＩＬＥ：該当３ビットフィールドは関連したＦＲＵの（ｉ＋１）番目フレーム（ｉはループ（loop）インデックス）のフィジカルプロファイルタイプを示す。該当フィールドは＜表８＞に示したものと同一なシグナリングフォーマットを使用する。

【0239】

ＦＲＵ＿ＦＲＡＭＥ＿ＬＥＮＧＴＨ：該当２ビットフィールドは関連したＦＲＵの（ｉ＋１）番目フレームの長さを示す。ＦＲＵ＿ＧＩ＿ＦＲＡＣＴＩＯＮと共にＦＲＵ＿ＦＲＡＭＥ＿ＬＥＮＧＴＨを使用すれば、フレームデュレーションの正確な値が得られる。

【0240】

ＦＲＵ＿ＧＩ＿ＦＲＡＣＴＩＯＮ：該当３ビットフィールドは関連したＦＲＵの（ｉ＋１）番目フレームのガードインターバルの一部値を示す。ＦＲＵ＿ＧＩ＿ＦＲＡＣＴＩＯＮは＜表７＞に従ってシグナリングされる。

【0241】

ＲＥＳＥＲＶＥＤ：該当４ビットフィールドは今後の使用のためにリザーブド（reserved）される。

【0242】

次のフィールドは、ＰＬＳ２データをデコーディングするためのパラメータを提供する。

【0243】

ＰＬＳ２＿ＦＥＣ＿ＴＹＰＥ：該当２ビットフィールドはＰＬＳ２の保護により使われるＦＥＣタイプを示す。ＦＥＣタイプは＜表１０＞に従ってシグナリングされる。ＬＤＰＣコードに対する詳細な内容は後述する。

【0244】

【表10】

【0245】

ＰＬＳ２＿ＭＯＤ：該当３ビットフィールドはＰＬＳ２により使われる変調タイプを示す。変調タイプは＜表１１＞に従ってシグナリングされる。

【0246】

【表11】

【0247】

ＰＬＳ２＿ＳＩＺＥ＿ＣＥＬＬ：該当１５ビットフィールドは現フレームグループで伝達されるＰＬＳ２に対する全てのコーディングブロックのサイズ（ＱＡＭセルの数に特定される）であるＣ_{ｔｏｔａｌ＿ｐａｒｔｉａｌ＿ｂｌｏｃｋ}を示す。該当値は現フレームグループの全体デュレーションの間一定である。

【0248】

ＰＬＳ２＿ＳＴＡＴ＿ＳＩＺＥ＿ＢＩＴ：該当１４ビットフィールドは現フレームグループに対するＰＬＳ２−ＳＴＡＴのサイズをビット数で示す。該当値は現フレームグループの全体デュレーションの間一定である。

【0249】

ＰＬＳ２＿ＤＹＮ＿ＳＩＺＥ＿ＢＩＴ：該当１４ビットフィールドは現フレームグループに対するＰＬＳ２−ＤＹＮのサイズをビット数で示す。該当値は現フレームグループの全体デュレーションの間一定である。

【0250】

ＰＬＳ２＿ＲＥＰ＿ＦＬＡＧ：該当１ビットフラグはＰＬＳ２反復モードが現フレームグループで使われるか否かを示す。該当フィールドの値が１に設定されれば、ＰＬＳ２反復モードは活性化される。該当フィールドの値が０に設定されれば、ＰＬＳ２反復モードは不活性化される。

【0251】

ＰＬＳ２＿ＲＥＰ＿ＳＩＺＥ＿ＣＥＬＬ：該当１５ビットフィールドはＰＬＳ２反復が使われる場合、現フレームグループの毎フレーム毎に伝達されるＰＬＳ２に対する部分コーディングブロックのサイズ（ＱＡＭセルの数で特定される）であるＣ_{ｔｏｔａｌ＿ｐａｒｔｉａｌ＿ｂｌｏｃｋ}を示す。反復が使われない場合、該当フィールドの値は０と同一である。該当値は現フレームグループの全体デュレーションの間一定である。

【0252】

ＰＬＳ２＿ＮＥＸＴ＿ＦＥＣ＿ＴＹＰＥ：該当２ビットフィールドは次のフレームグループの毎フレームで伝達されるＰＬＳ２に使われるＦＥＣタイプを示す。ＦＥＣタイプは＜表１０＞に従ってシグナリングされる。

【0253】

ＰＬＳ２＿ＮＥＸＴ＿ＭＯＤ：該当３ビットフィールドは次のフレームグループの毎フレームで伝達されるＰＬＳ２に使われる変調タイプを示す。変調タイプは＜表１１＞に従ってシグナリングされる。

【0254】

ＰＬＳ２＿ＮＥＸＴ＿ＲＥＰ＿ＦＬＡＧ：該当１ビットフラグはＰＬＳ２反復モードが次のフレームグループで使われるか否かを示す。該当フィールドの値が１に設定されれば、ＰＬＳ２反復モードは活性化される。該当フィールドの値が０に設定されれば、ＰＬＳ２反復モードは非活性化される。

【0255】

ＰＬＳ２＿ＮＥＸＴ＿ＲＥＰ＿ＳＩＺＥ＿ＣＥＬＬ：該当１５ビットフィールドはＰＬＳ２反復が使われる場合、次のフレームグループの毎フレーム毎に伝達されるＰＬＳ２に対する全体コーディングブロックのサイズ（ＱＡＭセルの数で特定される）であるＣ_{ｔｏｔａｌ＿ｆｕｌｌ＿ｂｌｏｃｋ}を示す。次のフレームグループで反復が使われない場合、該当フィールドの値は０と同一である。該当値は現フレームグループの全体デュレーションの間一定である。

【0256】

ＰＬＳ２＿ＮＥＸＴ＿ＲＥＰ＿ＳＴＡＴ＿ＳＩＺＥ＿ＢＩＴ：該当１４ビットフィールドは次のフレームグループに対するＰＬＳ２−ＳＴＡＴのサイズをビット数で示す。該当値は現フレームグループで一定である。

【0257】

ＰＬＳ２＿ＮＥＸＴ＿ＲＥＰ＿ＤＹＮ＿ＳＩＺＥ＿ＢＩＴ：該当１４ビットフィールドは次のフレームグループに対するＰＬＳ２−ＤＹＮのサイズをビット数で示す。該当値は現フレームグループで一定である。

【0258】

ＰＬＳ２＿ＡＰ＿ＭＯＤＥ：該当２ビットフィールドは現フレームグループでＰＬＳ２に対して追加パリティが提供されるか否かを示す。該当値は現フレームグループの全体デュレーションの間一定である。以下の＜表１２＞は該当フィールドの値を提供する。該当フィールドの値が００に設定されれば、現フレームグループで追加パリティがＰＬＳ２に対して使われない。

【0259】

【表12】

【0260】

ＰＬＳ２＿ＡＰ＿ＳＩＺＥ＿ＣＥＬＬ：該当１５ビットフィールドはＰＬＳ２の追加パリティビットのサイズ（ＱＡＭセルの数で特定される）を示す。該当値は現フレームグループの全体デュレーションの間一定である。

【0261】

ＰＬＳ２＿ＮＥＸＴ＿ＡＰ＿ＭＯＤＥ：該当２ビットフィールドは次のフレームグループの毎フレーム毎にＰＬＳ２シグナリングに対して追加パリティが提供されるか否かを示す。該当値は現フレームグループの全体デュレーションの間一定である。＜表１２＞は該当フィールドの値を定義する。`

【0262】

ＰＬＳ２＿ＮＥＸＴ＿ＡＰ＿ＳＩＺＥ＿ＣＥＬＬ：該当１５ビットフィールドは次のフレームグループの毎フレーム毎にＰＬＳ２の追加パリティビットのサイズ（ＱＡＭセルの数で特定される）を示す。該当値は現フレームグループの全体デュレーションの間一定である。

【0263】

ＲＥＳＥＲＶＥＤ：該当３２ビットフィールドは今後の使用のためにリザーブド（reserved）される。

【0264】

ＣＲＣ＿３２：全体ＰＬＳ１シグナリングに適用される３２ビットエラー検出コード

【0265】

図１４は、本発明の一実施形態に係るＰＬＳ２データを示す。

【0266】

図１４は、ＰＬＳ２データのＰＬＳ２−ＳＴＡＴデータを示す。ＰＬＳ２−ＳＴＡＴデータはフレームグループ内で同一である一方、ＰＬＳ２−ＤＹＮデータは現フレームに対して特定の情報を提供する。

【0267】

ＰＬＳ２−ＳＴＡＴデータのフィールドに対し、次に具体的に説明する。

【0268】

ＦＩＣ＿ＦＬＡＧ：該当１ビットフィールドはＦＩＣが現フレームグループで使われるか否かを示す。該当フィールドの値が１に設定されれば、ＦＩＣは現フレームで提供される。該当フィールドの値が０に設定されれば、ＦＩＣは現フレームで伝達されない。該当値は現フレームグループの全体デュレーションの間一定である。

【0269】

ＡＵＸ＿ＦＬＡＧ：該当１ビットフィールドは補助ストリームが現フレームグループで使われるか否かを示す。該当フィールドの値が１に設定されれば、補助ストリームは現フレームで提供される。該当フィールドの値が０に設定されれば、補助フレームは現フレームで伝達されない。該当値は現フレームグループの全体デュレーションの間一定である。

【0270】

ＮＵＭ＿ＤＰ：該当６ビットフィールドは現フレーム内で伝達されるデータパイプの数を示す。該当フィールドの値は１から６４の間であり、データパイプの数はＮＵＭ＿ＤＰ＋１である。

【0271】

ＤＰ＿ＩＤ：該当６ビットフィールドはフィジカルプロファイル内で唯一に識別する。

【0272】

ＤＰ＿ＴＹＰＥ：該当３ビットフィールドはデータパイプのタイプを示す。これは、以下の＜表１３＞に従ってシグナリングされる。

【0273】

【表13】

【0274】

ＤＰ＿ＧＲＯＵＰ＿ＩＤ：該当８ビットフィールドは現データパイプが関連しているデータパイプグループを識別する。これは、受信機が同一なＤＰ＿ＧＲＯＵＰ＿ＩＤを有するようになる特定サービスと関連しているサービスコンポーネントのデータパイプに接続することに使用できる。

【0275】

ＢＡＳＥ＿ＤＰ＿ＩＤ：該当６ビットフィールドは管理階層で使われる（ＰＳＩ／ＳＩのような）サービスシグナリングデータを伝達するデータパイプを示す。ＢＡＳＥ＿ＤＰ＿ＩＤにより示すデータパイプは、サービスデータと共にサービスシグナリングデータを伝達するノーマルデータパイプであるか、またはサービスシグナリングデータのみを伝達する専用データパイプでありうる。

【0276】

ＤＰ＿ＦＥＣ＿ＴＹＰＥ：該当２ビットフィールドは関連したデータパイプにより使われるＦＥＣタイプを示す。ＦＥＣタイプは、以下の＜表１４＞に従ってシグナリングされる。

【0277】

【表14】

【0278】

ＤＰ＿ＣＯＤ：該当４ビットフィールドは関連したデータパイプにより使われるコードレート（code rate）を示す。コードレート（code rate）は以下の＜表１５＞に従ってシグナリングされる。

【0279】

【表15】

【0280】

ＤＰ＿ＭＯＤ：該当４ビットフィールドは関連したデータパイプにより使われる変調を示す。変調は以下の＜表１６＞に従ってシグナリングされる。

【0281】

【表16】

【0282】

ＤＰ_ＳＳＤ＿ＦＬＡＧ：該当１ビットフィールドはＳＳＤモードが関連したデータパイプで使われるか否かを示す。該当フィールドの値が１に設定されれば、ＳＳＤは使われる。該当フィールドの値が０に設定されれば、ＳＳＤは使われない。

【0283】

次のフィールドはＰＨＹ＿ＰＲＯＦＩＬＥがアドバンスプロファイルを示す０１０と同じ時のみに表れる。

【0284】

ＤＰ＿ＭＩＭＯ：該当３ビットフィールドはどんなタイプのＭＩＭＯエンコーディング処理が関連したデータパイプに適用されるかを示す。ＭＩＭＯエンコーディング処理のタイプは、以下の＜表１７＞に従ってシグナリングされる。

【0285】

【表17】

【0286】

ＤＰ＿ＴＩ＿ＴＹＰＥ：該当１ビットフィールドはタイムインターリービングのタイプを示す。０の値は１つのタイムインターリービンググループが１つのフレームに該当し、１つ以上のタイムインターリービングブロックを含むことを示す。１の値は１つのタイムインターリービンググループが１つより多いフレームに伝達され、１つのタイムインターリービングブロックのみを含むことを示す。

【0287】

ＤＰ＿ＴＩ＿ＬＥＮＧＴＨ：該当２ビットフィールド（許容された値は１、２、４、８のみである）の使用は、次のようなＤＰ＿ＴＩ＿ＴＹＰＥフィールド内で設定される値により決定される。

【0288】

ＤＰ＿ＴＩ＿ＴＹＰＥの値が１に設定されれば、該当フィールドは各々のタイムインターリービンググループがマッピングされるフレームの数であるＰ_Ｉを示し、タイムインターリービンググループ当たり１つのタイムインターリービングブロックが存在する（Ｎ_ＴＩ＝１）。該当２ビットフィールドに許容されるＰ_Ｉの値は、以下の＜表１８＞に定義される。

【0289】

ＤＰ＿ＴＩ＿ＴＹＰＥの値が０に設定されれば、該当フィールドはタイムインターリービンググループ当たりタイムインターリービングブロックの数Ｎ_ＴＩを示し、フレーム当たり１つのタイムインターリービンググループが存在する（Ｐ_Ｉ＝１）。該当２ビットフィールドに許容されるＰ_Ｉの値は以下の＜表１８＞に定義される。

【0290】

【表18】

【0291】

ＤＰ＿ＦＲＡＭＥ＿ＩＮＴＥＲＶＡＬ：該当２ビットフィールドは関連したデータパイプに対するフレームグループ内でフレーム間隔（Ｉ_ＪＵＭＰ）を示し、許容された値は１、２、４、８（該当する２ビットフィールドは各々００、０１、１０、１１）である。フレームグループの全てのフレームに表れないデータパイプに対し、該当フィールドの値は順次的なフレームの間の間隔と同一である。例えば、データパイプが１、５、９、１３などのフレームに表れれば、該当フィールドの値は４に設定される。全てのフレームに表れるデータパイプに対し、該当フィールドの値は１に設定される。

【0292】

ＤＰ＿ＴＩ＿ＢＹＰＡＳＳ：該当１ビットフィールドはタイムインターリーバ５０５０の使用可能性を決定する。データパイプに対してタイムインターリービングが使われないと、該当フィールド値は１に設定される。一方、タイムインターリービングが使われれば、該当フィールド値は０に設定される。

【0293】

ＤＰ＿ＦＩＲＳＴ＿ＦＲＡＭＥ＿ＩＤＸ：該当５ビットフィールドは現データパイプが発生するスーパーフレームの第１のフレームのインデックスを示す。ＤＰ＿ＦＩＲＳＴ＿ＦＲＡＭＥ＿ＩＤＸの値は０から３１の間である。

【0294】

ＤＰ＿ＮＵＭ＿ＢＬＯＣＫ＿ＭＡＸ：該当１０ビットフィールドは該当データパイプに対するＤＰ＿ＮＵＭ＿ＢＬＯＣＫＳの最大値を示す。該当フィールドの値はＤＰ＿ＮＵＭ＿ＢＬＯＣＫＳと同一な範囲を有する。

【0295】

ＤＰ＿ＰＡＹＬＯＡＤ＿ＴＹＰＥ：該当２ビットフィールドは与えられたデータパイプにより伝達されるペイロードデータのタイプを示す。ＤＰ＿ＰＡＹＬＯＡＤ＿ＴＹＰＥは、以下の＜表１９＞に従ってシグナリングされる。

【0296】

【表19】

【0297】

ＤＰ＿ＩＮＢＡＮＤ＿ＭＯＤＥ：該当２ビットフィールドは現データパイプがインバンド（In-band）シグナリング情報を伝達するか否かを示す。インバンド（In-band）シグナリングタイプは、以下の＜表２０＞に従ってシグナリングされる。

【0298】

【表20】

【0299】

ＤＰ＿ＰＲＯＴＯＣＯＬ＿ＴＹＰＥ：該当２ビットフィールドは与えられたデータパイプにより伝達されるペイロードのプロトコルタイプを示す。ペイロードのプロトコルタイプは入力ペイロードタイプが選択されれば、以下の＜表２１＞に従ってシグナリングされる。

【0300】

【表21】

【0301】

ＤＰ＿ＣＲＣ＿ＭＯＤＥ：該当２ビットフィールドはＣＲＣエンコーディングがインプットフォーマットブロックで使われるか否かを示す。ＣＲＣモードは、以下の＜表２２＞に従ってシグナリングされる。

【0302】

【表22】

【0303】

ＤＮＰ＿ＭＯＤＥ：該当２ビットフィールドはＤＰ＿ＰＡＹＬＯＡＤ＿ＴＹＰＥがＴＳ（‘００’）に設定される場合に関連したデータパイプにより使われるヌルパケット削除モードを示す。ＤＮＰ＿ＭＯＤＥは、以下の＜表２３＞に従ってシグナリングされる。ＤＰ＿ＰＡＹＬＯＡＤ＿ＴＹＰＥがＴＳ（‘００’）でなければ、ＤＮＰ＿ＭＯＤＥは００の値に設定される。

【0304】

【表23】

【0305】

ＩＳＳＹ＿ＭＯＤＥ：該当２ビットフィールドはＤＰ＿ＰＡＹＬＯＡＤ＿ＴＹＰＥがＴＳ（‘００’）に設定される場合に関連したデータパイプにより使われるＩＳＳＹモードを示す。ＩＳＳＹ＿ＭＯＤＥは、以下の＜表２４＞に従ってシグナリングされる。ＤＰ＿ＰＡＹＬＯＡＤ＿ＴＹＰＥがＴＳ（‘００’）でなければ、ＩＳＳＹ＿ＭＯＤＥは００の値に設定される。

【0306】

【表24】

【0307】

ＨＣ＿ＭＯＤＥ＿ＴＳ：該当２ビットフィールドはＤＰ＿ＰＡＹＬＯＡＤ＿ＴＹＰＥがＴＳ（‘００’）に設定される場合に関連したデータパイプにより使われるＴＳヘッダ圧縮モードを示す。ＨＣ＿ＭＯＤＥ＿ＴＳは、以下の＜表２５＞に従ってシグナリングされる。

【0308】

【表25】

【0309】

ＨＣ＿ＭＯＤＥ＿ＩＰ：該当２ビットフィールドはＤＰ＿ＰＡＹＬＯＡＤ＿ＴＹＰＥがＩＰ（‘０１’）で設定される場合にＩＰヘッダ圧縮モードを示す。ＨＣ＿ＭＯＤＥ＿ＩＰは、以下の＜表２６＞に従ってシグナリングされる。

【0310】

【表26】

【0311】

ＰＩＤ：該当１３ビットフィールドはＤＰ＿ＰＡＹＬＯＡＤ＿ＴＹＰＥがＴＳ（‘００’）に設定され、ＨＣ＿ＭＯＤＥ＿ＴＳが０１または１０に設定される場合にＴＳヘッダ圧縮のためのＰＩＤ数を示す。

【0312】

ＲＥＳＥＲＶＥＤ：該当８ビットフィールドは今後の使用のためにリザーブド（reserved）される。

【0313】

次のフィールドは、ＦＩＣ＿ＦＬＡＧが１と同じ時のみに表れる。

【0314】

ＦＩＣ＿ＶＥＲＳＩＯＮ：該当８ビットフィールドはＦＩＣのバージョンナンバーを示す。

【0315】

ＦＩＣ＿ＬＥＮＧＴＨ＿ＢＹＴＥ：該当１３ビットフィールドはＦＩＣの長さをバイト単位で示す。

【0316】

ＲＥＳＥＲＶＥＤ：該当８ビットフィールドは今後の使用のためにリザーブド（reserved）される。

【0317】

次のフィールドは、ＡＵＸ＿ＦＬＡＧが１と同じ時のみに表れる。

【0318】

ＮＵＭ＿ＡＵＸ：該当４ビットフィールドは補助ストリームの数を示す。ゼロは補助ストリームが使われないことを示す。

【0319】

ＡＵＸ＿ＣＯＮＦＩＧ＿ＲＦＵ：該当８ビットフィールドは今後の使用のためにリザーブド（reserved）される。

【0320】

ＡＵＸ＿ＳＴＲＥＡＭ＿ＴＹＰＥ：該当４ビットは現補助ストリームのタイプを示すための今後の使用のためにリザーブド（reserved）される。

【0321】

ＡＵＸ＿ＰＲＩＶＡＴＥ＿ＣＯＮＦＩＧ：該当２８ビットフィールドは補助ストリームをシグナリングするための今後の使用のためにリザーブド（reserved）される。

【0322】

図１５は、本発明の他の一実施形態に係るＰＬＳ２データを示す。

【0323】

図１５は、ＰＬＳ２データのＰＬＳ２−ＤＹＮを示す。ＰＬＳ２−ＤＹＮデータの値は１つのフレームグループのデュレーションの間変化できる一方、フィールドのサイズは一定である。

【0324】

ＰＬＳ２−ＤＹＮデータのフィールドの具体的な内容は、次の通りである。

【0325】

ＦＲＡＭＥ＿ＩＮＤＥＸ：該当５ビットフィールドはスーパーフレーム内で現フレームのフレームインデックスを示す。スーパーフレームの第１のフレームのインデックスは０に設定される。

【0326】

ＰＬＳ＿ＣＨＡＮＧＥ＿ＣＯＵＮＴＥＲ：該当４ビットフィールドは構成が変化する前のスーパーフレームの数を示す。構成が変化する次のスーパーフレームは該当フィールド内でシグナリングされる値により示す。該当フィールドの値が００００に設定されれば、これは如何なる予定された変化も予測できないことを意味する。例えば、１の値は次のスーパーフレームに変化があるということを示す。

【0327】

ＦＩＣ＿ＣＨＡＮＧＥ＿ＣＯＵＮＴＥＲ：該当４ビットフィールドは構成（即ち、ＦＩＣのコンテンツ）が変化する前のスーパーフレームの数を示す。構成が変化する次のスーパーフレームは該当フィールド内でシグナリングされる値により示す。該当フィールドの値が００００に設定されれば、これは如何なる予定された変化も予測できないことを意味する。例えば、０００１の値は次のスーパーフレームに変化があることを示す。

【0328】

ＲＥＳＥＲＶＥＤ：該当１６ビットフィールドは今後の使用のためにリザーブド（reserved）される。

【0329】

次のフィールドは現フレームで伝達されるデータパイプと関連したパラメータを説明するＮＵＭ＿ＤＰでのループ（loop）に表れる。

【0330】

ＤＰ＿ＩＤ：該当６ビットフィールドはフィジカルプロファイル内でデータパイプを唯一に示す。

【0331】

ＤＰ＿ＳＴＡＲＴ：該当１５ビット（または、１３ビット）フィールドは、ＤＰＵアドレッシング（addressing）技法を使用してデータパイプの第１の開始位置を示す。ＤＰ＿ＳＴＡＲＴフィールドは、以下の＜表２７＞に示した通り、フィジカルプロファイル及びＦＦＴサイズによって異なる長さを有する。

【0332】

【表27】

【0333】

ＤＰ＿ＮＵＭ＿ＢＬＯＣＫ：該当１０ビットフィールドは現データパイプに対する現タイムインターリービンググループにおけるＦＥＣブロックの数を示す。ＤＰ＿ＮＵＭ＿ＢＬＯＣＫの値は０から１０２３の間にある。

【0334】

ＲＥＳＥＲＶＥＤ：該当８ビットフィールドは今後の使用のためにリザーブド（reserved）される。

【0335】

次のフィールドは、ＥＡＣと関連したＦＩＣパラメータを示す。

【0336】

ＥＡＣ＿ＦＬＡＧ：該当１ビットフィールドは現フレームでＥＡＣの存在を示す。該当ビットはプリアンブルにおけるＥＡＣ＿ＦＬＡＧと同一な値である。

【0337】

ＥＡＳ＿ＷＡＫＥ＿ＵＰ＿ＶＥＲＳＩＯＮ＿ＮＵＭ：該当８ビットフィールドは自動活性化指示のバージョンナンバーを示す。

【0338】

ＥＡＣ＿ＦＬＡＧフィールドが１と同一であれば、次の１２ビットがＥＡＣ＿ＬＥＮＧＴＨ＿ＢＹＴＥフィールドに割り当てられる。ＥＡＣ＿ＦＬＡＧフィールドが０と同一であれば、次の１２ビットがＥＡＣ＿ＣＯＵＮＴＥＲに割り当てられる。

【0339】

ＥＡＣ＿ＬＥＮＧＴＨ＿ＢＹＴＥ：該当１２ビットフィールドはＥＡＣの長さをバイトで示す。

【0340】

ＥＡＣ＿ＣＯＵＮＴＥＲ：該当１２ビットフィールドはＥＡＣが到達するフレームの前のフレームの数を示す。

【0341】

次のフィールドはＡＵＸ＿ＦＬＡＧフィールドが１と同一の場合のみに表れる。

【0342】

ＡＵＸ＿ＰＲＩＶＡＴＥ＿ＤＹＮ：該当４８ビットフィールドは補助ストリームをシグナリングするための今後の使用のためにリザーブド（reserved）される。該当フィールドの意味は、設定可能なＰＬＳ２−ＳＴＡＴでＡＵＸ＿ＳＴＲＥＡＭ＿ＴＹＰＥの値に依存する。

【0343】

ＣＲＣ＿３２：全体ＰＬＳ２に適用される３２ビットエラー検出コード。

【0344】

図１６は、本発明の一実施形態に係るフレームのロジカル（logical）構造を示す。

【0345】

前述したように、ＰＬＳ、ＥＡＣ、ＦＩＣ、データパイプ、補助ストリーム、ダミーセルは、フレームにおけるＯＦＤＭシンボルのアクティブ（active）キャリアにマッピングされる。ＰＬＳ１及びＰＬＳ２は、最初に１つ以上のＦＳＳにマッピングされる。その後、ＥＡＣが存在していれば、ＥＡＣセルは後続するＰＬＳフィールドにマッピングされる。次に、ＦＩＣが存在していれば、ＦＩＣセルがマッピングされる。データパイプはＰＬＳの次にマッピングされるか、ＥＡＣまたはＦＩＣが存在する場合、ＥＡＣまたはＦＩＣの以後にマッピングされる。タイプ１のデータパイプが最初にマッピングされ、タイプ２のデータパイプが次にマッピングされる。データパイプのタイプの具体的な内容は後述する。一部の場合、データパイプはＥＡＳに対する一部の特殊データまたはサービスシグナリングデータを伝達することができる。補助ストリームまたはストリームは、存在していれば、データパイプを次にマッピングされ、ここには順次にダミーセルが後続する。前述した順序、即ち、ＰＬＳ、ＥＡＣ、ＦＩＣ、データパイプ、補助ストリーム、及びダミーセルの順に全て共にマッピングすれば、フレームでセル容量を正確に詰める。

【0346】

図１７は、本発明の一実施形態に係るＰＬＳマッピングを示す。

【0347】

ＰＬＳセルは、ＦＳＳのアクティブ（active）キャリアにマッピングされる。ＰＬＳが占めるセルの数によって、１つ以上のシンボルがＦＳＳに指定され、ＦＳＳの数ＮＦＳＳはＰＬＳ１でのＮＵＭ＿ＦＳＳによりシグナリングされる。ＦＳＳはＰＬＳセルを伝達する特殊なシンボルである。堅固性及び遅延時間（latency）はＰＬＳで重大な事案であるので、ＦＳＳは高いパイロット密度を有しているので高速同期化及びＦＳＳ内での周波数のみのインターポレーション（interpoloation：補間）を可能にする。

【0348】

ＰＬＳセルは、図１７の例に示すように、下向き式でＦＳＳのアクティブ（active）キャリアにマッピングされる。ＰＬＳ１セルは、最初に第１のＦＳＳの第１のセルからセルインデックスの昇順にマッピングされる。ＰＬＳ２セルはＰＬＳ１の最後のセルの直後に後続し、マッピングは第１のＦＳＳの最後のセルインデックスまで下方に続く。必要とするＰＬＳセルの総数が１つのＦＳＳのアクティブ（active）キャリアの数を超過すれば、マッピングは次のＦＳＳに進行され、第１のＦＳＳと完全に同一な方式により続く。

【0349】

ＰＬＳマッピングが完了した後、データパイプが次に伝達される。ＥＡＣ、ＦＩＣ、または両方とも現フレームに存在していれば、ＥＡＣ及びＦＩＣはＰＬＳとノーマルデータパイプとの間に配置される。

【0350】

図１８は、本発明の一実施形態に係るＥＡＣマッピングを示す。

【0351】

ＥＡＣはＥＡＳメッセージを伝達する専用チャンネルであり、ＥＡＳに対するデータパイプに連結される。ＥＡＳサポートは提供されるが、ＥＡＣ自体は全てのフレームに存在することもあり、存在しないこともある。ＥＡＣが存在する場合、ＥＡＣはＰＬＳ２セルの直後にマッピングされる。ＰＬＳセルを除いて、ＦＩＣ、データパイプ、補助ストリーム、またはダミーセルのうち、いずれもＥＡＣの前に位置しない。ＥＡＣセルのマッピング手続はＰＬＳと完全に同一である。

【0352】

ＥＡＣセルは、図１８の例に示すように、ＰＬＳ２の次のセルからセルインデックスの昇順にマッピングされる。ＥＡＳメッセージの大きさによって、図１８に示すように、ＥＡＣセルは少ないシンボルを占めることができる。

【0353】

ＥＡＣセルは、ＰＬＳ２の最後のセルの直後に後続し、マッピングは最後のＦＳＳの最後のセルインデックスまで下方に続く。必要とするＥＡＣセルの総数が最後のＦＳＳの残っているアクティブ（active）キャリアの数を超過すれば、ＥＡＣマッピングは次のシンボルに進行され、ＦＳＳと完全に同一な方式により続く。この場合、ＥＡＣのマッピングがなされる次のシンボルはノーマルデータシンボルであり、これはＦＳＳより多いアクティブ（active）キャリアを有する。

【0354】

ＥＡＣマッピングが完了した後、存在していれば、ＦＩＣが次に伝達される。ＦＩＣが転送されなければ（ＰＬＳ２フィールドからシグナリングに）、データパイプがＥＡＣの最後のセルの直後に後続する。

【0355】

図１９は、本発明の一実施形態に係るＦＩＣマッピングを示す。

【0356】

（ａ）はＥＡＣ無しでＦＩＣセルのマッピングの例を示し、（ｂ）はＥＡＣと共にＦＩＣセルのマッピングの例を示す。

【0357】

ＦＩＣは、高速サービス獲得及びチャンネルスキャンを可能にするために階層間情報（cross-layer information）を伝達する専用チャンネルである。該当情報は主にデータパイプの間のチャンネルバインディング（channel binding）情報及び各放送社のサービスを含む。高速スキャンのために、受信機はＦＩＣをデコーディングし、放送社ＩＤ、サービス数、ＢＡＳＥ＿ＤＰ＿ＩＤのような情報を獲得することができる。高速サービス獲得のために、ＦＩＣだけでなく、ベースデータパイプもＢＡＳＥ＿ＤＰ＿ＩＤを用いてデコーディングできる。ベースデータパイプが転送するコンデンツを除いて、ベースデータパイプはノーマルデータパイプと正確に同一な方式によりエンコーディングされてフレームにマッピングされる。したがって、ベースデータパイプに対する追加説明が必要でない。ＦＩＣデータが生成されて管理階層で消費される。ＦＩＣデータのコンデンツは管理階層仕様に説明された通りである。

【0358】

ＦＩＣデータは選択的であり、ＦＩＣの使用はＰＬＳ２のスタティック（static：静的）な部分でＦＩＣ＿ＦＬＡＧパラメータによりシグナリングされる。ＦＩＣが使われれば、ＦＩＣ＿ＦＬＡＧは１に設定され、ＦＩＣに対するシグナリングフィールドはＰＬＳ２のスタティック（static：静的）な部分で定義される。該当フィールドでシグナリングされることはＦＩＣ＿ＶＥＲＳＩＯＮであり、ＦＩＣ＿ＬＥＮＧＴＨ＿ＢＹＴＥ＿ＦＩＣはＰＬＳ２と同一な変調、コーディング、タイムインターリービングパラメータを使用する。ＦＩＣは、ＰＬＳ２＿ＭＯＤ及びＰＬＳ２＿ＦＥＣのような同一なシグナリングパラメータを共有する。ＦＩＣデータは、存在していれば、ＰＬＳ２の後にマッピングされるか、またはＥＡＣが存在する場合、ＥＡＣの直後にマッピングされる。ノーマルデータパイプ、補助ストリーム、またはダミーセルのうち、いずれもＦＩＣの前に位置しない。ＦＩＣセルをマッピングする方法はＥＡＣと完全に同一であり、これはまたＰＬＳと同一である。

【0359】

ＰＬＳの後のＥＡＣが存在しない場合、ＦＩＣセルは（ａ）の例に示したように、ＰＬＳ２の次のセルからセルインデックスの昇順にマッピングされる。ＦＩＣデータサイズによって、（ｂ）に示したように、ＦＩＣセルは数個のシンボルに対してマッピングされる。

【0360】

ＦＩＣセルはＰＬＳ２の最後のセルの直後に後続し、マッピングは最後のＦＳＳの最後のセルインデックスまで下方に続く。必要なＦＩＣセルの総数が最後のＦＳＳの残っているアクティブ（active）キャリアの数を超過すれば、残りのＦＩＣセルのマッピングは次のシンボルに進行され、これはＦＳＳと完全に同一な方式により続く。この場合、ＦＩＣがマッピングされる次のシンボルはノーマルデータシンボルであり、これはＦＳＳより多いアクティブ（active）キャリアを有する。

【0361】

ＥＡＳメッセージが現フレームで転送されれば、ＥＡＣはＦＩＣより先にマッピングされ、（ｂ）に示したように、ＥＡＣの次のセルからＦＩＣセルはセルインデックスの昇順にマッピングされる。

【0362】

ＦＩＣマッピングが完了した後、１つ以上のデータパイプがマッピングされ、以後、存在していれば、補助ストリーム、ダミーセルが後続する。

【0363】

図２０は、本発明の一実施形態に係るデータパイプのタイプを示す。

【0364】

（ａ）はタイプ１のデータパイプを示し、（ｂ）はタイプ２のデータパイプを示す。

【0365】

先行するチャンネル、即ちＰＬＳ、ＥＡＣ、ＦＩＣがマッピングされた後、データパイプのセルがマッピングされる。データパイプはマッピング方法によって２タイプのうちの１つに分類される。

【0366】

タイプ１のデータパイプ：データパイプがＴＤＭによりマッピングされる。

【0367】

タイプ２のデータパイプ：データパイプがＦＤＭによりマッピングされる。

【0368】

データパイプのタイプはＰＬＳ２のスタティック（static：静的）な部分でＤＰ＿ＴＹＰＥフィールドにより示す。図２０は、タイプ１のデータパイプ及びタイプ２のデータパイプのマッピング順序を示す。タイプ１のデータパイプは、まずセルインデックスの昇順にマッピングされた後、最後のセルインデックスに到達した後、シンボルインデックスが１ずつ増加する。次のシンボル内で、データパイプはｐ＝０を手始めにセルインデックスの昇順に続けてマッピングされる。１つのフレームで共にマッピングされる多数のデータパイプと共に、各々のタイプ１のデータパイプはデータパイプのＴＤＭと類似するように時間にグルーピングされる。

【0369】

タイプ２のデータパイプは、まずシンボルインデックスの昇順にマッピングされ、フレームの最後のＯＦＤＭシンボルに到達した後、セルインデックスは１ずつ増加し、シンボルインデックスは第１の使用可能シンボルに戻った後、そのシンボルインデックスから増加する。１つのフレームで多数のデータパイプをマッピングした後、各々のタイプ２のデータパイプはデータパイプのＦＤＭと類似するように周波数にグルーピングされる。

【0370】

タイプ１のデータパイプ及びタイプ２のデータパイプは、必要時、フレームで共存できるが、タイプ１のデータパイプが常にタイプ２のデータパイプに先行するという制限がある。タイプ１及びタイプ２のデータパイプを伝達するＯＦＤＭセルの総数はデータパイプの転送に使用することができるＯＦＤＭセルの総数を超過できない。

【0371】

【数2】

【0372】

この際、Ｄ_ＤＰ１はタイプ１のデータパイプが占めるＯＦＤＭセルの数に該当し、Ｄ_ＤＰ２はタイプ２のデータパイプが占めるセルの数に該当する。ＰＬＳ、ＥＡＣ、ＦＩＣが全てタイプ１のデータパイプと同様の方式によりマッピングされるので、ＰＬＳ、ＥＡＣ、ＦＩＣは全て“タイプ１のマッピング規則”に従う。したがって、概してタイプ１のマッピングが常にタイプ２のマッピングに先行する。

【0373】

図２１は、本発明の一実施形態に係るデータパイプマッピングを示す。

【0374】

（ａ）はタイプ１のデータパイプをマッピングするためのＯＦＤＭセルのアドレッシングを示し、（ｂ）はタイプ２のデータパイプをマッピングするためのＯＦＤＭセルのアドレッシングを示す。

【0375】

タイプ１のデータパイプ（０，．．．，ＤＤＰ１−１）をマッピングするためのＯＦＤＭセルのアドレッシングはタイプ１のデータパイプのアクティブ（active）データセルに対して定義される。アドレッシング方式は各々のタイプ１のデータパイプに対するタイムインターリービングからのセルがアクティブ（active）データセルに割り当てられる順序を定義する。また、アドレッシング方式はＰＬＳ２のダイナミック（dynamic：動的）部分でデータパイプの位置をシグナリングすることに使われる。

【0376】

ＥＡＣ及びＦＩＣ無しで、アドレス０は最後のＦＳＳでＰＬＳを伝達する最後のセルに後続するセルをいう。ＥＡＣが転送され、ＦＩＣが該当するフレームになければ、アドレス０はＥＡＣを伝達する最後のセルに後続するセルをいう。ＦＩＣが該当するフレームで転送されれば、アドレス０はＦＩＣを伝達する最後のセルに後続するセルをいう。タイプ１のデータパイプに対するアドレス０は（ａ）に示したような２つの互いに異なる場合を考慮して算出できる。（ａ）の例で、ＰＬＳ、ＥＡＣ、ＦＩＣは全て転送されると仮定する。ＥＡＣとＦＩＣのうちの１つまたは全てが省略される場合への拡張は自明である。（ａ）の左側に示したように、ＦＩＣまで全てのセルをマッピングした後、ＦＳＳに残っているセルがあれば、タイプ２のデータパイプ（０，．．．，ＤＤＰ２−１）をマッピングするためのＯＦＤＭセルのアドレッシングはタイプ２のデータパイプのアクティブ（active）データセルに対して定義される。アドレッシング方式は各々のタイプ２のデータパイプに対するタイムインターリービングからのセルがアクティブ（active）データセルに割り当てられる順序を定義する。また、アドレッシング方式はＰＬＳ２のダイナミック（dynamic：動的）部分でデータパイプの位置をシグナリングすることに使われる。

【0377】

（ｂ）に示すように、３種類の若干異なる場合が可能である。（ｂ）の左側に示した第１の場合に、最後のＦＳＳにあるセルはタイプ２のデータパイプマッピングに使用できる。中央に示した第２の場合に、ＦＩＣはノーマルシンボルのセルを占めるが、該当シンボルでのＦＩＣセルの数はＣ_ＦＳＳより大きくない。（ｂ）の右側に示した第３の場合は該当シンボルにマッピングされたＦＩＣセルの数がＣ_ＦＳＳを超過する点を除いて、第２の場合と同一である。

【0378】

ＰＬＳ、ＥＡＣ、ＦＩＣがタイプ１のデータパイプと同一な“タイプ１のマッピング規則”に従うので、タイプ１のデータパイプがタイプ２のデータパイプに先行する場合への拡張は自明である。

【0379】

データパイプユニット（ＤＰＵ）は、フレームにおけるデータセルをデータパイプに割り当てる基本単位である。

【0380】

ＤＰＵはフレームにおけるデータパイプの位置を探し出すためのシグナリング単位として定義される。セルマッパー７０１０は、各々のデータパイプに対してタイムインターリービングにより生成されたセルをマッピングすることができる。タイムインターリーバ５０５０は一連のタイムインターリービングブロックを出力し、各々のタイムインターリービングブロックはＸＦＥＣＢＬＯＣＫの可変数を含み、これは結局、セルの集合で構成される。ＸＦＥＣＢＬＯＣＫにおけるセルの数Ｎ_{ｃｅｌｌｓ}はＦＥＣＢＬＯＣＫサイズ、Ｎ_ｌｄｐｃ、コンステレーションシンボル当たり転送されるビット数に依存する。ＤＰＵは与えられたフィジカルプロファイルでサポートされるＸＦＥＣＢＬＯＣＫにおけるセルの数Ｎ_{ｃｅｌｌｓ}の全ての可能な値の最大公約数として定義される。セルでのＤＰＵの長さはＬ_ＤＰＵとして定義される。各々のフィジカルプロファイルはＦＥＣＢＬＯＣＫサイズの互いに異なる組合せ及びコンステレーションシンボル当たり異なるビット数をサポートするので、Ｌ_ＤＰＵはフィジカルプロファイルに基づいて定義される。

【0381】

図２２は、本発明の一実施形態に係るＦＥＣ構造を示す。

【0382】

図２２は、ビットインターリービングの前の本発明の一実施形態に係るＦＥＣ構造を示す。前述したように、データＦＥＣエンコーダは外部コーディング（ＢＣＨ）及び内部コーディング（ＬＤＰＣ）を用いてＦＥＣＢＬＯＣＫ手続を生成するために入力ＢＢＦにＦＥＣエンコーディングを実行することができる。図示されたＦＥＣ構造はＦＥＣＢＬＯＣＫに該当する。また、ＦＥＣＢＬＯＣＫ及びＦＥＣ構造はＬＤＰＣコードワードの長さに該当する同一な値を有する。

【0383】

図２２に示すように、ＢＣＨエンコーディングが各々のＢＢＦ（Ｋ_ｂｃｈビット）に適用された後、ＬＤＰＣエンコーディングがＢＣＨ−エンコーディングされたＢＢＦ（Ｋ_ｌｄｐｃビット＝Ｎ_ｂｃｈビット）に適用される。

【0384】

Ｎ_ｌｄｐｃの値は６４８００ビット（ロングＦＥＣＢＬＯＣＫ）または１６２００ビット（ショートＦＥＣＢＬＯＣＫ）である。

【0385】

以下の＜表２８＞及び＜表２９＞はロングＦＥＣＢＬＯＣＫ及びショートＦＥＣＢＬＯＣＫの各々に対するＦＥＣエンコーディングパラメータを示す。

【0386】

【表28】

【0387】

【表29】

【0388】

ＢＣＨエンコーディング及びＬＤＰＣエンコーディングの具体的な動作は、次の通りである。

【0389】

１２−エラー訂正ＢＣＨコードがＢＢＦの外部エンコーディングに使われる。ショートＦＥＣＢＬＯＣＫ及びロングＦＥＣＢＬＯＣＫに対するＢＢＦ生成多項式は全ての多項式を掛けることによって得られる。

【0390】

ＬＤＰＣコードは外部ＢＣＨエンコーディングの出力をエンコーディングすることに使われる。完成されたＢ_ｌｄｐｃ（ＦＥＣＢＬＯＣＫ）を生成するために、Ｐ_ｌｄｐｃ（パリティビット）が各々のＩ_ｌｄｐｃ（ＢＣＨ−エンコーディングされたＢＢＦ）から組織的にエンコーディングされ、Ｉ_ｌｄｐｃに添付される。完成されたＢ_ｌｄｐｃ（ＦＥＣＢＬＯＣＫ）は次の数式で表現される。

【0391】

【数3】

【0392】

ロングＦＥＣＢＬＯＣＫ及びショートＦＥＣＢＬＯＣＫに対するパラメータは前記の＜表２８＞及び＜表２９＞に各々与えられる。

【0393】

ロングＦＥＣＢＬＯＣＫに対してＮ_ｌｄｐｃ−Ｋ_ｌｄｐｃパリティビットを計算する具体的な手続は、次の通りである。

【0394】

１）パリティビット初期化

【0395】

【数4】

【0396】

２）パリティーチェックマトリックスのアドレスの第１の行で特定されたパリティビットアドレスで第１の情報ビットｉ_Ｏ累算（accumulate）。パリティーチェックマトリックスのアドレスの詳細な内容は後述する。例えば、割合１３／１５に対し、

【0397】

【数5】

【0398】

３）次の３５９個の情報ビットｉ_ｓ、ｓ＝１，２，．．．，３５９に対し、次の数式を用いてパリティビットアドレスでｉ_ｓ累算（accumulate）。

【0399】

【数6】

【0400】

ここで、ｘは第１のビットｉ_０に該当するパリティビット累算器のアドレスを示し、Ｑ_ｌｄｐｃはパリティーチェックマトリックスのアドレッサで特定されたコードレート（code rate）依存定数である。前記の例である、割合１３／１５に対する、したがって情報ビットｉ_１に対するＱ_ｌｄｐｃ＝２４に引続き、次の動作が実行される。

【0401】

【数7】

【0402】

４）３６１番目の情報ビットｉ_３６０に対し、パリティビット累算器のアドレスはパリティーチェックマトリックスのアドレスの第２の行に与えられる。同様の方式により、次の３５９個の情報ビットｉ_ｓ、ｓ＝３６１，３６２，．．．，７１９に対するパリティビット累算器のアドレスは＜数式６＞を用いて得られる。ここで、ｘは情報ビットｉ_３６０に該当するパリティビット累算器のアドレス、即ちパリティーチェックマトリックスの第２の行のエントリーを示す。

【0403】

５）同様の方式で、３６０個の新たな情報ビットの全てのグループに対し、パリティーチェックマトリックスのアドレスからの新たな行はパリティビット累算器のアドレスを求めることに使われる。

【0404】

全ての情報ビットが用いられた後、最終パリティビットが次の通り得られる。
６）ｉ＝１から始めて次の動作を順次に実行

【0405】

【数8】

【0406】

ここで、ｐ_ｉ、ｉ＝０，１，．．．，Ｎ_ｌｄｐｃ−Ｋ_ｌｄｐｃ−１の最終コンデンツはパリティビットｐ_ｉと同一である。

【0407】

【表30】

【0408】

＜表３０＞を＜表３１＞に取り替えて、ロングＦＥＣＢＬＯＣＫに対するパリティーチェックマトリックスのアドレスをショートＦＥＣＢＬＯＣＫに対するパリティーチェックマトリックスのアドレスに取り替えることを除いて、ショートＦＥＣＢＬＯＣＫに対する該当ＬＤＰＣエンコーディング手続はロングＦＥＣＢＬＯＣＫに対するtＬＤＰＣエンコーディング手続に従う。

【0409】

【表31】

【0410】

図２３は、本発明の一実施形態に係るビットインターリービングを示す。

【0411】

ＬＤＰＣエンコーダの出力はビットインターリービングされるが、これはＱＣＢ（quasi-cyclic block）インターリービング及び内部グループインターリービングが後続するパリティインターリービングで構成される。

【0412】

（ａ）はＱＣＢインターリービングを示し、（ｂ）は内部グループインターリービングを示す。

【0413】

ＦＥＣＢＬＯＣＫはパリティインターリービングできる。パリティインターリービングの出力で、ＬＤＰＣコードワードはロングＦＥＣＢＬＯＣＫで１８０個の隣接するＱＣＢで構成され、ショートＦＥＣＢＬＯＣＫで４５個の隣接するＱＣＢで構成される。ロングまたはショートＦＥＣＢＬＯＣＫにおける各々のＱＣＢは３６０ビットで構成される。パリティインターリービングされたＬＤＰＣコードワードはＱＣＢインターリービングによりインターリービングされる。ＱＣＢインターリービングの単位はＱＣＢである。パリティインターリービングの出力でのＱＣＢは、図２３に示すように、ＱＣＢインターリービングによりパーミュテーションされるが、ここで、ＦＥＣＢＬＯＣＫ長さによってＮ_{ｃｅｌｌｓ}＝６４８００／η_ＭＯＤまたは１６２００／η_ＭＯＤである。ＱＣＢインターリービングパターンは変調タイプ及びＬＤＰＣコードレート（code rate）の各組合せに固有である。

【0414】

ＱＣＢインターリービングの後に、内部グループインターリービングが以下の＜表３２＞に定義された変調タイプ及び次数（η_ＭＯＤ）によって実行される。１つの内部グループに対するＱＣＢの数Ｎ_{ＱＣＢ＿ＩＧ}も定義される。

【0415】

【表32】

【0416】

内部グループインターリービング過程はＱＣＢインターリービング出力のＮ_{ＱＣＢ＿ＩＧ}個のＱＣＢで実行される。内部グループインターリービングは３６０個の列及びＮ_{ＱＣＢ＿ＩＧ}個の行を用いて内部グループのビットを記入し読み取る過程を含む。記入動作で、ＱＣＢインターリービング出力からのビットが行方向に記入される。読取動作は列方向に実行されて各行でｍ個のビットを読み取る。ここで、ｍはＮＵＣの場合１と同一であり、ＮＵＱの場合２と同一である。

【0417】

図２４は、本発明の一実施形態に係るセル−ワードデマルチプレキシングを示す。

【0418】

図２４で、（ａ）は８及び１２ｂｐｃｕ ＭＩＭＯに対するセル−ワードデマルチプレキシングを示し、（ｂ）は１０ｂｐｃｕ ＭＩＭＯに対するセル−ワードデマルチプレキシングを示す。

【0419】

ビットインターリービング出力の各々のセルワード（ｃ_０，ｌ，ｃ_１，ｌ，．．． ，ｃ_{ｎｍｏｄ−１，ｌ}）は１つのＸＦＥＣＢＬＯＣＫに対するセル−ワードデマルチプレキシング過程を説明する（ａ）に示したように（ｄ_{１，０，m}，ｄ_{１，１，ｍ}，．．．，ｄ_{１，ｎｍｏｄ−１，ｍ}）及び（ｄ_{２，０，m}，ｄ_{２，１，ｍ}，．．．，ｄ_{２，ｎｍｏｄ−１，m}）にデマルチプレキシングされる。

【0420】

ＭＩＭＯエンコーディングのために異なるタイプのＮＵＱを用いる１０ｂｐｃｕ ＭＩＭＯの場合に、ＮＵＱ−１０２４に対するビットインターリーバが再使用される。ビットインターリーバ出力の各々のセルワード（ｃ_０，ｌ，ｃ_１，ｌ，．．．，ｃ_９，ｌ）は（ｂ）に示したように（ｄ_{１，０，ｍ}，ｄ_{１，１，ｍ}，．．．，ｄ_{１，３，ｍ}）及び（ｄ_{２，０，ｍ}，ｄ_{２，１，ｍ}，．．．，ｄ_{２，５，ｍ}）にデマルチプレキシングされる。

【0421】

図２５は、本発明の一実施形態に係るタイムインターリービングを示す。

【0422】

（ａ）から（ｃ）はタイムインターリービングモードの例を示す。

【0423】

タイムインターリーバはデータパイプレベルで動作する。タイムインターリービングのパラメータは各々のデータパイプに対して異に設定できる。

【0424】

ＰＬＳ２−ＳＴＡＴデータの一部に表れる次のパラメータはタイムインターリービングを構成する。

【0425】

ＤＰ＿ＴＩ＿ＴＹＰＥ（許容された値：０または１）：タイムインターリービングモードを示す。０はタイムインターリービンググループ当たり多数のタイムインターリービングブロック（１つ以上のタイムインターリービングブロック）を有するモードを示す。この場合、１つのタイムインターリービンググループは１つのフレームに（フレーム間インターリービング無しで）直接マッピングされる。１はタイムインターリービンググループ当たり１つのタイムインターリービングブロックのみを有するモードを示す。この場合、タイムインターリービングブロックは１つ以上のフレームに亘って拡散される（フレーム間インターリービング）。

【0426】

ＤＰ＿ＴＩ＿ＬＥＮＧＴＨ：ＤＰ＿ＴＩ＿ＴＹＰＥ＝‘０’であれば、該当パラメータはタイムインターリービンググループ当たりタイムインターリービングブロックの数Ｎ_ＴＩである。ＤＰ＿ＴＩ＿ＴＹＰＥ＝‘１’の場合、該当パラメータは１つのタイムインターリービンググループから拡散されるフレームの数Ｐ_Ｉである。

【0427】

ＤＰ＿ＮＵＭ＿ＢＬＯＣＫ＿ＭＡＸ（許容された値：０乃至１０２３）：タイムインターリービンググループ当たりＸＦＥＣＢＬＯＣＫの最大数を示す。

【0428】

ＤＰ＿ＦＲＡＭＥ＿ＩＮＴＥＲＶＡＬ（許容された値：１、２、４、８）：与えられたフィジカルプロファイルの同一なデータパイプを伝達する２つの順次的なフレーム間のフレームの数Ｉ_ＪＵＭＰを示す。

【0429】

ＤＰ＿ＴＩ＿ＢＹＰＡＳＳ（許容された値：０または１）：タイムインターリービングがデータフレームに用いられなければ、該当パラメータは１に設定される。タイムインターリービングが用いられれば、０に設定される。

【0430】

さらに、ＰＬＳ２−ＤＹＮデータからのパラメータＤＰ＿ＮＵＭ＿ＢＬＯＣＫはデータグループの１つのタイムインターリービンググループにより伝達されるＸＦＥＣＢＬＯＣＫの数を示す。

【0431】

タイムインターリービングがデータフレームに用いられなければ、次のタイムインターリービンググループ、タイムインターリービング動作、タイムインターリービングモードは考慮されない。しかしながら、スケジューラからのダイナミック（dynamic：動的）構成情報のためのディレイコンペンセーション（delay compensation：遅延補償）ブロックは相変らず必要である。各々のデータパイプで、ＳＳＤ／ＭＩＭＯエンコーディングから受信したＸＦＥＣＢＬＯＣＫはタイムインターリービンググループにグルーピングされる。即ち、各々のタイムインターリービンググループは整数個のＸＦＥＣＢＬＯＣＫの集合であり、ダイナミック（dynamic：動的）に変化する数のＸＦＥＣＢＬＯＣＫを含む。インデックスｎのタイムインターリービンググループにあるＸＦＥＣＢＬＯＣＫの数はＮ_{ｘＢＬＯＣＫ＿Ｇｒｏｕｐ}（ｎ）で示し、ＰＬＳ２−ＤＹＮデータでＤＰ＿ＮＵＭ＿ＢＬＯＣＫにシグナリングされる。この際、Ｎ_{ｘＢＬＯＣＫ＿Ｇｒｏｕｐ}（ｎ）は最小値０から最も大きい値が１０２３である最大値Ｎ_{ｘＢＬＯＣＫ＿Ｇｒｏｕｐ＿ＭＡＸ}（ＤＰ＿ＮＵＭ＿ＢＬＯＣＫ＿ＭＡＸに該当）まで変化することができる。

【0432】

各々のタイムインターリービンググループは１つのフレームに直接マッピングされるか、またはＰ_Ｉ個のフレームに亘って拡散される。また、各々のタイムインターリービンググループは１つ以上（Ｎ_ＴＩ個）のタイムインターリービングブロックに分離される。ここで、各々のタイムインターリービングブロックはタイムインターリーバメモリの１つの使用に該当する。タイムインターリービンググループ内のタイムインターリービングブロックは若干の異なる数のＸＦＥＣＢＬＯＣＫを含むことができる。タイムインターリービンググループが多数のタイムインターリービングブロックに分離されれば、タイムインターリービンググループは１つのフレームのみに直接マッピングされる。以下の＜表３３＞に示したように、タイムインターリービングには３種類のオプションがある（タイムインターリービングを省略する追加オプション除外）。

【0433】

【表33】

【0434】

各々のデータパイプで、タイムインターリービングメモリは入力されたＸＦＥＣＢＬＯＣＫ（ＳＳＤ／ＭＩＭＯエンコーディングブロックから出力されたＸＦＥＣＢＬＯＣＫ）を格納する。入力されたＸＦＥＣＢＬＯＣＫは、

【数9】

として定義されると仮定する。ここで、

【数10】

はｎ番目タイムインターリービンググループのｓ番目タイムインターリービングブロックでｒ番目ＸＦＥＣＢＬＯＣＫのｑ番目セルであり、次のようなＳＳＤ及びＭＩＭＯエンコーディングの出力を示す。

【数11】

【0435】

また、タイムインターリーバ５０５０から出力されたＸＦＥＣＢＬＯＣＫは

【数12】

として定義されると仮定する。ここで、

【数13】

はｎ番目タイムインターリービンググループのｓ番目タイムインターリービングブロックでｉ番目（

【数14】

）出力セルである。

【0436】

一般に、タイムインターリーバはフレーム生成過程の以前にデータパイプデータに対するバッファとしても作用する。これは、各々のデータパイプに対して２つのメモリバンクで達成される。第１のタイムインターリービングブロックは第１のバンクに記入される。第１のバンクで読取される間、第２のタイムインターリービングブロックが第２のバンクに記入される。

【0437】

タイムインターリービングはツイストされた行−列ブロックインターリーバである。ｎ番目タイムインターリービンググループのｓ番目タイムインターリービングブロックに対し、列の数Ｎ_ｃが

【数15】

と同一である一方、タイムインターリービングメモリの行の数Ｎ_ｒはセルの数Ｎ_ｃｅｌｌと同一である（即ち、Ｎ_ｒ＝Ｎ_ｃｅｌｌ）。

【0438】

図２６は本発明の一実施形態に係る同期及び復調（synchronization & demodulation）モジュールを示す図である。

【0439】

図２６に図示された同期及び復調モジュールは、図９で説明した同期及び復調モジュールの一実施形態に該当する。また、図２６に図示された同期及び復調モジュールは、図９で説明したウェーブフォームジェネレーションモジュールの逆動作を遂行することができる。

【0440】

図２６に示すように、本発明の一実施形態に係る同期及び復調モジュールは、ｍ個のＲｘアンテナを使用する受信装置の同期及び復調モジュールの実施形態であって、ｍ個のパス（path）だけ入力された信号を復調して出力するためのｍ個の処理ブロックを含むことができる。ｍ個の処理ブロックは全て同一な処理過程を遂行することができる。以下、ｍ個の処理ブロックのうち、第１の処理ブロック２６０００の動作を中心に説明する。

【0441】

第１の処理ブロック２６０００は、チューナー２６１００、ＡＤＣブロック２６２００、プリアンブルディテクタ（preamble dectector）２６３００、ガードシーケンスディテクタ（guard sequence detector）２６４００、ウェーブフォームトランスフォーム（waveform transform）ブロック２６５００、時間／周波数同期化（Time／freq sync）ブロック２６６００、レファレンスシグナルディテクタ（Reference signal detector）２６７００、チャンネルイコライザー（Channel equalizer）２６８００、及びインバースウェーブフォームトランスフォーム（Inverse waveform transform）ブロック２６９００を含むことができる。
チューナー２６１００は、所望の周波数帯域を選択し、受信した信号の大きさを補償してＡＤＣブロック２６２００に出力することができる。

【0442】

ＡＤＣブロック２６２００は、チューナー２６１００から出力された信号をディジタル信号に変換することができる。

【0443】

プリアンブルディテクタ２６３００は、ディジタル信号に対して受信装置に対応するシステムの信号か否かを確認するためにプリアンブル（または、プリアンブル信号またはプリアンブルシンボル）をディテクティングすることができる。この場合、プリアンブルディテクタ２６３００はプリアンブルを通じて受信される基本的な転送パラメータ（transmission parameter）を復号することができる。

【0444】

ガードシーケンスディテクタ２６４００は、ディジタル信号内のガードシーケンス（guard sequence）をディテクティングすることができる。時間／周波数同期化ブロック２６６００は、ディテクティングされたガードシーケンスを用いて時間／周波数同期化（time/frequency synchronization）を遂行することができ、チャンネルイコライザー２６８００はディテクティングされたガードシーケンスを用いて受信／復元されたシーケンスを通じてチャンネルを推定することができる。

【0445】

ウェーブフォームトランスフォームブロック２６５００は、送信側でインバースウェーブフォームトランスフォームが遂行された場合、これに対する逆変換過程を遂行することができる。本発明の一実施形態に係る放送送受信システムが多重キャリアシステム（multi-carrier system）の場合、ウェーブフォームトランスフォームブロック２６５００はＦＦＴ変換過程を遂行することができる。また、本発明の一実施形態に係る放送送受信システムが単一キャリアシステム（single carrier system）の場合、受信された時間領域の信号が周波数領域で処理するために使われるか、または時間領域で全て処理される場合、ウェーブフォームトランスフォームブロック２６５００は使用されないことがある。

【0446】

時間／周波数同期化ブロック２６６００は、プリアンブルディテクタ２６３００、ガードシーケンスディテクタ２６４００、レファレンスシグナルディテクタ２６７００の出力データを受信し、検出された信号に対してガードシーケンスディテクション（guard sequence detection）、ブロックウィンドウポジショニング（block window positioning）を含む時間同期化及びキャリア周波数同期化を遂行することができる。この際、周波数同期化のために時間／周波数同期化ブロック２６６００は、ウェーブフォームトランスフォームブロック２６５００の出力信号をフィードバックして使用することができる。

【0447】

レファレンスシグナルディテクタ２６７００は、受信されたレファレンスシグナルを検出することができる。したがって、本発明の一実施形態に係る受信装置は同期化を遂行するか、またはチャンネル推定（channel estimation）を遂行することができる。

【0448】

チャンネルイコライザー２６８００は、ガードシーケンスやレファレンスシグナルから各転送アンテナから各受信アンテナまでの転送チャンネルを推定し、推定されたチャンネルを用いて各受信データに対するチャンネル補償（equalization）を遂行することができる。

【0449】

インバースウェーブフォームトランスフォームブロック２６９００は、同期及びチャンネル推定／補償を効率的に遂行するために、ウェーブフォームトランスフォームブロック２６５００がウェーブフォームトランスフォームを遂行した場合、また元の受信データドメイン（domain）に復元してくれる役割を遂行することができる。本発明の一実施形態に係る放送送受信システムが単一キャリアシステムの場合、ウェーブフォームトランスフォームブロック２６５００は同期／チャンネル推定／補償を周波数領域で遂行するためにＦＦＴを遂行することができ、インバースウェーブフォームトランスフォームブロック２６９００はチャンネル補償が完了した信号に対してＩＦＦＴを遂行することで、転送されたデータシンボル（data symbol）を復元することができる。本発明の一実施形態に係る放送送受信システムが多重キャリアシステムの場合、インバースウェーブフォームトランスフォームブロック２６９００は使用されないこともある。

【0450】

また、前述したブロックは設計者の意図によって省略されるか、類似または同一機能を有する他のブロックにより取替できる。

【0451】

図２７は、本発明の一実施形態に係るフレームパーシングモジュールを示す図である。

【0452】

図２７に図示されたフレームパーシングモジュールは、図９で説明したフレームパーシングモジュールの一実施形態に該当する。

【0453】

図２７に示すように、本発明の一実施形態に係るフレームパーシングモジュールは、少なくとも１つ以上のブロックデインターリーバ２７０００及び少なくとも１つ以上のセルデマッパー２７１００を含むことができる。

【0454】

ブロックデインターリーバ２７０００はｍ個の受信アンテナの各データパスに入力されて同期及び復調モジュールで処理されたデータに対して、各シグナルブロック単位でデータに対するデインターリービングを遂行することができる。この場合、図８で説明したように、送信側でペアワイズインターリービング（pair-wise interleaving）が遂行された場合、ブロックデインターリーバ２７０００は各入力パス（path）に対して連続した２つのデータを１つのペアに処理することができる。したがって、ブロックデインターリーバ２７０００はデインターリービングを遂行した場合にも連続した２つの出力データを出力することができる。また、ブロックデインターリーバ２７０００は送信端で遂行したインターリービング過程の逆過程を遂行して元のデータ順に出力することができる。

【0455】

セルデマッパー２７１００は、受信された信号フレームからコモンデータに対応するセル、データパイプに対応するセル、及びＰＬＳデータに対応するセルを抽出することができる。必要の場合、セルデマッパー２７１００は多数個の部分に分散されて転送されたデータをマージ（merge）して１つのストリームに出力することができる。また、図７で説明したように、送信端で２つの連続したセル入力データが１つのペアに処理されてマッピングされた場合、セルデマッパー２７１００はこれに該当する逆過程で連続した２つの入力セルを１つの単位で処理するペアワイズセルデマッピングを遂行することができる。

【0456】

また、セルデマッパー２７１００は現在フレームを通じて受信したＰＬＳシグナリングデータに対し、各々ＰＬＳ−プリ（pre）及びＰＬＳ−ポスト（post）データとして全て抽出して出力することができる。

【0457】

前述したブロックは設計者の意図によって省略されるか、類似または同一機能を有する他のブロックにより取替できる。

【0458】

図２８は、本発明の一実施形態に係るデマッピング及びデコーディングモジュールを示す図である。

【0459】

図２８に図示されたデマッピング及びデコーディングモジュールは、図９で説明したデマッピング及びデコーディングモジュールの一実施形態に該当する。

【0460】

前述したように、本発明の一実施形態に係る送信装置のコーディングアンドモジュレーションモジュールは、入力されたデータパイプに対し、各々のパス別にＳＩＳＯ、ＭＩＳＯ、及びＭＩＭＯ方式を独立的に適用して処理することができる。したがって、図２８に図示されたデマッピング及びデコーディングモジュールやはり送信装置に対応してフレームパーサから出力されたデータを各々ＳＩＳＯ、ＭＩＳＯ、ＭＩＭＯ処理するためのブロックを含むことができる。

【0461】

図２８に示すように、本発明の一実施形態に係るデマッピング及びデコーディングモジュールは、ＳＩＳＯ方式のための第１ブロック２８０００、ＭＩＳＯ方式のための第２ブロック２８１００、ＭＩＭＯ方式のための第３ブロック２８２００、及びＰＬＳプリ／ポスト情報を処理するための第４ブロック２８３００を含むことができる。図２８に図示されたデマッピング及びデコーディングモジュールは一実施形態に過ぎず、設計者の意図によってデマッピング及びデコーディングモジュールは第１ブロック２８０００及び第４ブロック２８３００のみを含むこともでき、第２ブロック２８１００及び第４ブロック２８３００のみを含むこともでき、第３ブロック２８２００及び第４ブロック２８３００のみを含むこともできる。即ち、設計者の意図によってデマッピング及びデコーディングモジュールは各データパイプを同一に、または異なるように処理するためのブロックを含むことができる。

【0462】

以下、各ブロックについて説明する。

【0463】

第１ブロック２８０００は入力されたデータパイプをＳＩＳＯ処理するためのブロックであって、時間デインターリーバブロック２８０１０、セルデインターリーバブロック２８０２０、コンステレーションデマッパーブロック２８０３０、セルトゥビットマルチプレキシング（cell to bit mux）ブロック２８０４０、ビットデインターリーバブロック２８０５０、及びＦＥＣデコーダブロック２８０６０を含むことができる。

【0464】

時間デインターリーバブロック２８０１０は、時間インターリーバブロックの逆過程を遂行することができる。即ち、時間デインターリーバブロック２８０１０は時間領域でインターリービングされた入力シンボルを元の位置にデインターリービングすることができる。

【0465】

セルデインターリーバブロック２８０２０は、セルインターリーバブロックの逆過程を遂行することができる。即ち、セルデインターリーバブロック２８０２０は１つのＦＥＣブロック内でスプレッディング（spreading）されたセルの位置を元の位置にデインターリービングすることができる。

【0466】

コンステレーションデマッパーブロック２８０３０は、コンステレーションマッパーブロックの逆過程を遂行することができる。即ち、コンステレーションデマッパーブロック２８０３０はシンボルドメインの入力信号をビットドメインのデータにデマッピングすることができる。また、コンステレーションデマッパーブロック２８０３０は硬判定（hard decision）を遂行して判定されたビットデータを出力することもでき、軟判定（soft decision）値や、あるいは確率的な値に該当する各ビットの対数尤度比（Log-likelihood ratio：ＬＬＲ）を出力することができる。仮に、送信端で追加的なダイバーシティゲインを得るために回転（rotated）コンステレーションを適用した場合、コンステレーションデマッパーブロック２８０３０はこれに相応する２次元のＬＬＲ デマッピングを遂行することができる。この際、コンステレーションデマッパーブロック２８０３０はＬＬＲを計算する時、送信装置でＩまたはＱコンポネントに対して遂行された遅延値を補償できるように計算を遂行することができる。

【0467】

セルトゥビットマルチプレキシングブロック２８０４０は、ビットトゥセルデマルチプレキシングブロックの逆過程を遂行することができる。即ち、セルトゥビットマルチプレキシングブロック２８０４０は、ビットトゥセルデマルチプレキシングブロックでマッピングされたビットデータを元のビットストリーム形態に復元することができる。

【0468】

ビットデインターリーバブロック２８０５０は、ビットインターリーバブロックの逆過程を遂行することができる。即ち、ビットデインターリーバブロック２８０５０はセルトゥビットマルチプレキシングブロック２８０４０から出力されたビットストリームを元の順にデインターリービングすることができる。

【0469】

ＦＥＣデコーダブロック２８０６０は、ＦＥＣエンコーダブロックの逆過程を遂行することができる。即ち、ＦＥＣデコーダブロック２８０６０はＬＤＰＣデコーディングとＢＣＨデコーディングを遂行して転送チャンネル上の発生したエラーを訂正することができる。

【0470】

第２ブロック２８１００は入力されたデータパイプをＭＩＳＯ処理するためのブロックであって、図２８に示すように、第１ブロック２８０００と同一に時間デインターリーバブロック、セルデインターリーバブロック、コンステレーションデマッパーブロック、セルトゥビットマルチプレキシングブロック、ビットデインターリーバブロック、及びＦＥＣデコーダブロックを含むことができるが、ＭＩＳＯデコーディングブロック２８１１０をさらに含むという点で差がある。第２ブロック２８１００は、第１ブロック２８０００と同様に時間デインターリーバから出力まで同一な役割の過程を遂行するので、同一なブロックに対する説明は省略する。

【0471】

ＭＩＳＯデコーディングブロック２８１１０は、ＭＩＳＯプロセッシングブロックの逆過程を遂行することができる。本発明の一実施形態に係る放送送受信システムがＳＴＢＣを使用したシステムの場合、ＭＩＳＯデコーディングブロック２８１１０はアラモウチ（Alamouti）デコーディングを遂行することができる。

【0472】

第３ブロック２８２００は入力されたデータパイプをＭＩＭＯ処理するためのブロックであって、図２８に示すように、第２ブロック２８１００と同一に時間デインターリーバブロック、セルデインターリーバブロック、コンステレーションデマッパーブロック、セルトゥビットマルチプレキシングブロック、ビットデインターリーバブロック、及びＦＥＣデコーダブロックを含むことができるが、ＭＩＭＯデコーディングブロック２８２１０を含むという点でデータ処理過程の差がある。第３ブロック２８２００に含まれた時間デインターリーバ、セルデインターリーバ、コンステレーションデマッパー、セルトゥビットマルチプレキシング、ビットデインターリーバブロックなどの動作は、第１乃至第２ブロック２８０００−２８１００に含まれた該当ブロックの動作と具体的な機能は異なることがあるが、基本的な役割は同一である。

【0473】

ＭＩＭＯデコーディングブロック２８２１０は、ｍ個の受信アンテナ入力信号に対してセルデインターリーバの出力データを入力に受けて、ＭＩＭＯプロセッシングブロックの逆過程としてＭＩＭＯデコーディングを遂行することができる。ＭＩＭＯデコーディングブロック２８２１０は、最高の復号化性能を得るために最尤復号（Maximum likelihood decoding）を遂行するか、複雑度を減少させたスフィアデコーディング（Sphere decoding）を遂行することができる。または、ＭＩＭＯデコーディングブロック２８２１０はＭＭＳＥディテクションを遂行するか、または反復デコーディング（iterative decoding）を共に結合遂行して、向上したデコーディング性能を確保することができる。

【0474】

第４ブロック２８３００はＰＬＳプリ／ポスト情報を処理するためのブロックであって、ＳＩＳＯまたはＭＩＳＯデコーディングを遂行することができる。第４ブロック２８３００は第４ブロックの逆過程を遂行することができる。

【0475】

第４ブロック２８３００に含まれた時間デインターリーバ、セルデインターリーバ、コンステレーションデマッパー、セルトゥビットマルチプレキシング、ビットデインターリーバブロックの動作は、第１乃至第３ブロック２８０００−２８２００に含まれた該当ブロックの動作と具体的な機能は異なることがあるが、基本的な役割は同一である。

【0476】

第４ブロック２８３００に含まれた短縮及びパンクチャリングＦＥＣデコーダ（Shortened/Punctured FEC decoder）２８３１０は、短縮及びパンクチャリングＦＥＣエンコーダブロックの逆過程を遂行することができる。即ち、短縮及びパンクチャリングＦＥＣデコーダ２８３１０はＰＬＳデータの長さによって短縮及びパンクチャリングされて受信されたデータに対して非短縮（de-shortening）とデパンクチャリング（de-puncturing）を遂行した後にＦＥＣデコーディングを遂行することができる。この場合、データパイプに使われたＦＥＣデコーダを同一にＰＬＳにも使用することができるので、ＰＬＳのみのための別途のＦＥＣデコーダハードウェアが必要でないので、システム設計が容易であり、効率的なコーディングが可能であるという長所がある。

【0477】

前述したブロックは設計者の意図によって省略されるか、類似または同一機能を有する他のブロックにより取替できる。

【0478】

結果的に、図２８に示すように、本発明の一実施形態に係るデマッピング及びデコーディングモジュールは、各パス別に処理されたデータパイプ及びＰＬＳ情報をアウトプットプロセッサに出力することができる。

【0479】

図２９乃至図３０は、本発明の一実施形態に係るアウトプットプロセッサ（output processor）を示す図である。

【0480】

図２９は、本発明の一実施形態に係る出力プロセッサを示す図である。

【0481】

図２９に図示された出力プロセッサは、図９で説明した出力プロセッサの一実施形態に該当する。また、図２９に図示された出力プロセッサはデマッピング及びデコーディングモジュールから出力された単一データパイプを受信して単一出力ストリームを出力するためのものであって、インプットフォーマッティングモジュールの逆動作を遂行することができる。

【0482】

図２９に図示された出力プロセッサは、ＢＢスクランブラーブロック２９０００、パディング削除（Padding removal）ブロック２９１００、ＣＲＣ−８デコーダブロック２９２００、及びＢＢフレームプロセッサブロック２９３００を含むことができる。

【0483】

ＢＢスクランブラーブロック２９０００は、入力されたビットストリームに対して送信端で使用したものと同一なＰＲＢＳを発生させてビット列とＸＯＲしてデスクランブリングを遂行することができる。

【0484】

パディング削除ブロック２９１００は、送信端で必要によって挿入されたパディングビットを除去することができる。

【0485】

ＣＲＣ−８デコーダブロック２９２００は、パディング削除ブロック２９１００から入力を受けたビットストリームに対してＣＲＣデコーディングを遂行してブロックエラーをチェックすることができる。

【0486】

ＢＢフレームプロセッサブロック２９３００は、ＢＢフレームヘッダに転送された情報をデコーディングし、デコーディングされた情報を用いてＭＰＥＧ−ＴＳ、ＩＰストリーム（ｖ４またはｖ６）またはジェネリックストリーム（Generic stream）を復元することができる。

【0487】

前述したブロックは設計者の意図によって省略されるか、類似または同一機能を有する他のブロックにより取替できる。

【0488】

図３０は、本発明の他の実施形態に係るアウトプットプロセッサを示す図である。

【0489】

図３０に図示されたアウトプットプロセッサは、図９で説明したアウトプットプロセッサの一実施形態に該当する。また、図３０に図示されたアウトプットプロセッサは、デマッピング及びデコーディングモジュールから出力された多重（multiple）データパイプを受信する場合に該当する。多重データパイプに対するデコーディングは複数のデータパイプに共通に適用できるコモンデータ及びこれと関連したデータパイプをマージしてデコーディングする場合、または受信装置が多数個のサービスあるいはサービスコンポネント（scalable video serviceを含み）を同時にデコーディングする場合を含むことができる。

【0490】

図３０に図示されたアウトプットプロセッサは、アウトプットプロセッサの場合と同様に、ＢＢデスクランブラーブロック、パディング削除ブロック、ＣＲＣ−８デコーダブロック、及びＢＢフレームプロセッサブロックを含むことができる。各ブロックは図２９で説明したブロックの動作と具体的な動作は異なることがあるが、基本的な役割は同一である。

【0491】

図３０に図示されたアウトプットプロセッサに含まれたデ−ジッタバッファブロック３００００は、多重データパイプ間の同期化のために送信端で任意に挿入された遅延（delay）を復元されたＴＴＯ（time to output）パラメータに従って補償することができる。

【0492】

また、ヌルパケット挿入ブロック３０１００は復元されたＤＮＰ（deleted null packet）情報を参考してストリーム内の除去されたヌルパケットを復元することができ、コモンデータを出力することができる。

【0493】

ＴＳクロック再生ブロック３０２００は、ＩＳＣＲインプットストリーム時間レファレンス（ISCR-Input Stream Time Reference）情報を基準に出力パケットの詳細な時間同期を復元することができる。

【0494】

ＴＳ再結合（recombining）ブロック３０３００は、ヌルパケット挿入ブロック３０１００から出力されたコモンデータ及びこれと関連したデータパイプを再結合して元のＭＰＥＧ−ＴＳ、ＩＰストリーム（ｖ４またはｖ６）、あるいはジェネリックストリームに復元して出力することができる。ＴＴＯ、ＤＮＰ、ＩＳＣＲ情報は全てＢＢフレームヘッダを通じて獲得できる。

【0495】

インバンドシグナリングデコーダブロック３０４００は、データパイプの各ＦＥＣフレーム内のパディングビットフィールドを通じて転送されるインバンド物理階層シグナリング（in-band physical layer signaling）情報を復元して出力することができる。

【0496】

図３０に図示されたアウトプットプロセッサは、ＰＬＳ−プリパスとＰＬＳ−ポストパスによって入力されるＰＬＳ−プリ情報及びＰＬＳ−ポスト情報を各々ＢＢデスクランブリングし、デスクランブリングされたデータに対してデコーディングを遂行して、元のＰＬＳデータを復元することができる。復元されたＰＬＳデータは受信装置内のシステム制御器（system controller）に伝達され、システム制御器は受信装置の同期化及び復調モジュール、フレームパーシングモジュール、デマッピング及びデコーディングモジュール、及びアウトプットプロセッサモジュールに必要とするパラメータを供給することができる。

【0497】

前述したブロックは設計者の意図によって省略されるか、類似または同一機能を有する他のブロックにより取替できる。

【0498】

図３１は、本発明の他の実施形態に係るコーディングアンドモジュレーションモジュールを示す図である。

【0499】

図３１に図示されたコーディングアンドモジュレーションモジュールは、各データパイプを通じて転送するサービスやサービスコンポネント別にＱｏＳを調節するために、モジュールはＳＩＳＯ方式のための第１ブロック３１０００、ＭＩＳＯ方式のための第２ブロック３１１００、ＭＩＭＯ方式のための第３ブロック３１２００、及びＰＬＳプリ／ポスト情報を処理するための第４ブロック３１３００を含むことができる。また、本発明の一実施形態に係るコーディングアンドモジュレーションモジュールは、前述したように、設計者の意図によって各データパイプを同一に、または異なるように処理するためのブロックを含むことができる。図３１に図示された第１ブロック乃至第４ブロック３１０００−３１３００は、第１ブロック乃至第４ブロックと略同一なブロックを含んでいる。

【0500】

しかしながら、第１ブロック乃至第３ブロック３１０００−３１２００に含まれたコンステレーションマッパーブロック１４０１０の機能が第１ブロック乃至第３ブロックに含まれたコンステレーションマッパーブロックの機能と異なるという点、第１ブロック乃至第４ブロック３１０００−３１３００のセルインターリーバ及び時間インターリーバの間に回転（rotation）及びＩ／Ｑインターリーバブロック３１０２０が含まれているという点、及びＭＩＭＯ方式のための第３ブロック３１２００の構成がＭＩＭＯ方式のための第３ブロックの構成が異なるという点に差がある。

【0501】

図３１に図示されたコンステレーションマッパーブロック３１０１０は、入力されたビットワードを複合シンボル（complex symbol）にマッピングすることができる。

【0502】

図３１に図示されたコンステレーションマッパーブロック３１０１０は、前述したように、第１ブロック乃至第３ブロック３１０００−３１２００に共通的に適用できる。

【0503】

回転及びＩ／Ｑインターリーバブロック３１０２０は、セルインターリーバから出力されたセルインターリービングされたデータの各複合シンボルの同相（In-phase）と直交位相（Quadrature-phase）コンポネントを独立的にインターリービングしてシンボル単位で出力することができる。回転及びＩ／Ｑインターリーバブロック３１０２０の入力データ及び出力シンボルの個数は２つ以上であり、これは設計者の意図によって変更可能である。また、回転及びＩ／Ｑインターリーバブロック３１０２０は同相成分に対してはインターリービングを遂行しないこともある。

【0504】

回転及びＩ／Ｑインターリーバブロック３１０２０は、前述したように、第１ブロック乃至第４ブロック３１０００−３１３００に共通的に適用できる。この場合、回転及びＩ／Ｑインターリーバブロック３１０２０がＰＬＳプリ／ポスト情報を処理するための第４ブロック３１３００に適用されるか否かは前述したプリアンブルを通じてシグナリングできる。

【0505】

ＭＩＭＯ方式のための第３ブロック３１２００は、図３１に示すように、Ｑ−ブロックインターリーバブロック３１２１０、及び複合シンボル生成ブロック３１２２０を含むことができる。

【0506】

Ｑ−ブロックインターリーバブロック３１２１０は、ＦＥＣエンコーダから入力を受けたＦＥＣエンコーディングが遂行されたＦＥＣブロックのパリティパート（parity part）に対し、パーミュテーション（permutation）を遂行することができる。これを通じてＬＤＰＣ Ｈマトリックスのパリティパートを情報パート（information part）と同一に環状構造（cyclic structure）に作ることができる。Ｑ−ブロックインターリーバブロック３１２１０は、ＬＤＰＣＨマトリックスのＱサイズを有する出力ビットブロックの順序をパーミュテーションした後、行（row）−列（column）ブロックインターリービングを遂行して最終ビット列を生成して出力することができる。

【0507】

複合シンボル生成器ブロック３１２２０は、Ｑ−ブロックインターリーバブロック１４２１０から出力されたビット列の入力を受けて、複合シンボルにマッピングして出力することができる。この場合、複合シンボル生成器ブロック３１２２０は少なくとも２つの経路を通じてシンボルを出力することができる。これは、設計者の意図によって変更可能である。

【0508】

前述したブロックは設計者の意図によって省略されるか、類似または同一機能を有する他のブロックにより取替できる。

【0509】

結果的に、図３１に示すように、本発明の他の実施形態に係るコーディングアンドモジュレーションモジュールは、各パス別に処理されたデータパイプ、ＰＬＳ−プリ情報、ＰＬＳ−ポスト情報をフレーム構造モジュールに出力することができる。

【0510】

図３２は、本発明の他の実施形態に係るデマッピング及びデコーディングモジュールを示す図である。

【0511】

図３２に図示されたデマッピング及びデコーディングモジュールは、図９及び図２８で説明したデマッピング及びデコーディングモジュールの他の実施形態に該当する。また、図３２に図示されたデマッピング及びデコーディングモジュールは図３１で説明したコーディングアンドモジュレーションモジュールの逆動作を遂行することができる。

【0512】

図３２に示すように、本発明の他の実施形態に係るデマッピング及びデコーディングモジュールは、ＳＩＳＯ方式のための第１ブロック３２０００、ＭＩＳＯ方式のための第２ブロック３２１００、ＭＩＭＯ方式のための第３ブロック３２２００、及びＰＬＳプリ／ポスト情報を処理するための第４ブロック３２３００を含むことができる。また、本発明の一実施形態に係るデマッピング及びデコーディングモジュールは、前述したように、設計者の意図によって各データパイプを同一に、または異なるように処理するためのブロックを含むことができる。図３２に図示された第１ブロック乃至第４ブロック３２０００−３２３００は、図２８で説明した第１ブロック乃至第４ブロック２８０００−２８３００と略同一なブロックを含んでいる。

【0513】

しかしながら、第１ブロック乃至第４ブロック３２０００−３２３００の時間デインターリーバ及びセルデインターリーバの間にＩ／Ｑデインターリーバ及びデローテーションブロック３２０１０が含まれているという点、第１ブロック乃至第３ブロック３２０００−３２２００に含まれたコンステレーションデマッパーブロック１５０２０の機能が図２８の第１ブロック乃至第３ブロック２８０００−２８２００に含まれたコンステレーションマッパーブロック２８０３０の機能と異なるという点、及びＭＩＭＯ方式のための第３ブロック２８２００の構成が図２８に図示されたＭＩＭＯ方式のための第３ブロック２８２００の構成が異なるという点に差がある。以下、図２８と同一なブロックに対する説明は省略し、前述した差異点を中心に説明する。

【0514】

Ｉ／Ｑデインターリーバ及びデローテーションブロック３２０１０は、図３１で説明した回転及びＩ／Ｑインターリーバブロック３１０２０の逆過程を遂行することができる。即ち、Ｉ／Ｑデインターリーバ及びデローテーションブロック３２０１０は、送信端でＩ／Ｑインターリービングされて転送されたＩ及びＱコンポネントに対して各々デインターリービングを遂行することができ、復元されたＩ／Ｑコンポネントを有する複合シンボルをまたデローテーションして出力することができる。

【0515】

Ｉ／Ｑデインターリーバ及びデローテーションブロック３２０１０は、前述したように、第１ブロック乃至第４ブロック３２０００−３２３００に共通的に適用できる。この場合、Ｉ／Ｑデインターリーバ及びデローテーションブロック３２０１０がＰＬＳプリ／ポスト情報を処理するための第４ブロック３２３００に適用されるか否かは前述したプリアンブルを通じてシグナリングできる。

【0516】

コンステレーションデマッパーブロック３２０２０は、図３１で説明したコンステレーションマッパーブロック３１０１０の逆過程を遂行することができる。即ち、コンステレーションデマッパーブロック３２０２０は、デローテーションを遂行せず、セルデインターリービングされたデータに対してデマッピングを遂行することができる。

【0517】

ＭＩＭＯ方式のための第３ブロック３２２００は、図３２に示すように、複合シンボルパーシングブロック３２２１０及びＱ−ブロックデインターリーバブロック３２２２０を含むことができる。

【0518】

複合シンボルパーシングブロック３２２１０は、図３１で説明した複合シンボル生成器ブロック３１２２０の逆過程を遂行することができる。即ち、複合データシンボルをパーシングし、ビットデータにデマッピングして出力することができる。この場合、複合シンボルパーシングブロック３２２１０は少なくとも２つの経路を通じて複合データシンボルの入力を受けることができる。

【0519】

Ｑ−ブロックデインターリーバブロック３２２２０は、図３１で説明したＱ−ブロックインターリーバブロック３１２１０の逆過程を遂行することができる。即ち、Ｑ−ブロックデインターリーバブロック３２２２０は、行−列デインターリービングによりＱサイズブロックを復元した後、 パーミュテーションされた各ブロックの順序を元の順に復元した後、パリティデインターリービングを通じてパリティビットの位置を元の通り復元して出力することができる。

【0520】

前述したブロックは設計者の意図によって省略されるか、類似または同一機能を有する他のブロックにより取替できる。

【0521】

結果的に、図３２に示すように、本発明の他の実施形態に係るデマッピング及びデコーディングモジュールは、各パス別に処理されたデータパイプ及びＰＬＳ情報をアウトプットプロセッサに出力することができる。

【0522】

以下、本明細書で提案するＢＢＦ転送のオーバーヘッドを減らし、パディング（Padding）フィールドを用いて多様な機能を追加するための新たなＢＢＦヘッダ構造について具体的に説明する。

【0523】

図３３は、本明細書で提案するモードアダプテーションモジュールの一例を示す図である。

【0524】

前述したように、インプットフォーマッティング（Input Formatting）モジュールはモードアダプテーション（Mode Adaptation）モジュールを含む。

【0525】

図３３のモードアダプテーションモジュールの構成は、前述したモードアダプテーションモジュールの構成と一部相異することがある。

【0526】

図３３に示すように、モードアダプテーションモジュールは、プリプロセッシング（Pre ProcessingまたはSpliting）ブロック３３１０、インプットインターフェース（Input Interface）ブロック３３２０、インプットストリーム同期化（input stream synchronizer）をブロック３３３０、ディレイ補償（compensating delay）ブロック３３４０、ヘッダコンプレッション（Header Compression）ブロック３３５０、ヌルデータ再使用（Null data reuse）ブロック３３６０、ヌルパケット除去（null paket deletion）ブロック３３７０、またはＢＢフレームヘッダ挿入（BB Frame Header Insertion）ブロック３３８０のうち、少なくとも１つを含んで構成できる。

【0527】

プリプロセッシング（Pre Processing）ブロックは、複数個の入力ストリームを複数個のデータパイプにスプリッティング（splitting）またはデマルチプレキシングすることができる。ここで、データパイプはＰＬＰ（Physical Layer pipe）と呼ばれることもできる。ここで、入力ストリームはＴＳ（ＭＰＥＧ２−ＴＳ）、ＩＰ（Internet protocol）及び／又はＧＳ（Generic Stream）でありうる。

【0528】

実施形態によって他の形態の入力ストリームも可能でありうる。

【0529】

ヘッダコンプレッションブロックは、パケットヘッダを圧縮することができる。これは、ＴＳまたはＩＰ入力ストリームの転送効率を増加させるためでありうる。受信機が既にヘッダの先験的（a priori）情報を有しているので、既知データ（known data）が送信端から除去できる。例えば、ＰＩＤなどの情報が圧縮されることができ、他の形態の情報は除去または取替できる。実施形態によって、ヘッダコンプレッションブロックはヌルパケット除去ブロックの後に位置することができる。

【0530】

ヌルデータ再使用（Null data reuse）ブロックは、ヘッダコンプレッションの以後にヌルデータをパケットに挿入する動作を遂行することができる。このブロックは実施形態によって省略できる。

【0531】

ＢＢフレームヘッダ挿入ブロックは、前述したＢＢフレームヘッダ挿入ブロックと異なる方式により動作することもできる。

【0532】

本明細書は、ＢＢ（Base Band）フレームのデータフィールド長さのシグナリングを減少させる方法を提供する（data Field Length signaling reduction method）。

【0533】

また、本明細書はＢＢフレームのＦＥＣブロックへの転送に対するオーバーヘッドを減らすための方法を提供する。

【0534】

即ち、本明細書で提案する新たなＢＢフレーム構成方法はＢＢフレームヘッダ挿入ブロックで遂行できる。

【0535】

本明細書で提案する方法により、ＢＢフレーム及びＢＢフレームヘッダが構成できる。本明細書はインプットストリームがインプットプロセシングを経てＦＥＣブロックに伝達されるために、ＢＢフレームが生成される過程に関するものでありうる。

【0536】

また、本明細書はＢＢフレームヘッダの大きさを縮めて転送効率を高める方法でありうる。ＢＢフレームヘッダ挿入ブロックと関連した具体的な内容は後述する。

【0537】

従来技術において、ＢＢフレームはデータフィールドの長さを受信装置に知らせるために、ＤＦＬ（data field length）を毎ＢＢフレームヘッダに割り当てた。前記ＤＦＬは１６ｂｉｔまたは１１ｂｉｔでありうる。これによって、従来技術はＢＢＦ転送に対するオーバーヘッドが大きい。

【0538】

常に同一なサイズのＢＢフレームでデータフィールドの長さが異なる場合は、データがＢＢフレームを全て詰められないか、またはＢＢフレームがインバンドシグナリング（in band signaling）情報を含んでいる場合でありうる。

【0539】

更に他の従来技術において、ＢＢフレームはデータフィールドの長さを直接知らせる代わり、インジケータ（indicator）のみ送信した。そして、ＢＢフレームはＢＢフレームのパディング（padding）の長さをパディングでシグナリングしてくれた。しかしながら、この場合、インバンドシグナリングを考慮していないので、インバンドシグナリングが運用される場合に制限を受けることができる。

【0540】

本明細書で提案する方法は、ＤＦＬを減らし、追加フィールドを挿入できるようにするＢＢフレームヘッダを構成する方法でありうる。ここで、追加フィールドはインバンドシグナリングのタイプなどを指示することもでき、他の用途に使用することもできる。

【0541】

本明細書で提案する方法によりＢＢＦ転送に対するオーバーヘッドを最小化することができ、パディング（または、スタッフィング（stuffing））フィールドに多様な機能が追加できる。

【0542】

図３４は、本明細書で提案するアウトプットプロセッサの一例を示す図である。

【0543】

前述したように、アウトプットプロセッサ（output processor）はＢＢフレームヘッダパーサブロックを含むことができる。図３４のアウトプットプロセッサの構成要素は前述したアウトプットプロセッサの構成要素と一部相異することがある。

【0544】

アウトプットプロセッサは、ＢＢフレームヘッダパーサブロック３４１０、ヌルパケット挿入（Null packet insertion）ブロック３４２０、ヌルデータ再生成（Null data regenerator）ブロック３４３０、ヘッダデコンプレッションブロック３４４０、ＴＳクロック再生成（TS clock regeneration）ブロック３４５０、デジッタバッファブロック３４６０、またはＴＳ再結合（TS recombining）ブロック３４７０のうち、少なくとも１つを含んで構成できる。

【0545】

ここで、ヌルパケット挿入ブロック、ＴＳクロック再生成ブロック、デジッタバッファブロック、及びＴＳ再結合ブロックは、前述したアウトプットプロセッサのブロックと同一な動作を遂行することができる。

【0546】

本明細書で提案するＢＢフレームヘッダ構成方法は、受信端（または、受信装置、受信機、レシーバー）ではＢＢフレームヘッダパーサブロックに対応できる。

【0547】

ＢＢフレームヘッダパーサブロック３４１０は、前述したＢＢフレームヘッダパーサブロックと相異するように動作することができる。ＢＢフレームヘッダパーサブロック３４１０は、本明細書で提案する方式に従うＢＢフレームヘッダをパーシングする動作を遂行することができる。

【0548】

本明細書で提案するＢＢフレーム及びＢＢフレームヘッダの構成方法は後述する。

【0549】

ヌルデータ再生成ブロックは、受信端のヌルデータ再使用ブロックに対応する構成でありうる。ヌルデータ再生成ブロックは、アウトプットをヘッダデコンプレッションブロックに出力することができる。このブロックは実施形態によって省略できる。

【0550】

ヘッダデコンプレッションブロックは、受信端のヘッダコンプレッションブロックに対応する構成でありうる。ヘッダデコンプレッションブロックは、圧縮されたパケットヘッダの圧縮を復元することができる。前述したように、パケットヘッダはＴＳまたはＩＰ入力ストリームの転送効率を増加させるために圧縮されていることができる。実施形態によって、ヘッダデコンプレッションブロックは、実施形態によってヌルパケット挿入ブロックの前に位置することができる。

【0551】

図３５は、従来のＢＢフレーム構造の一例を示す図である。

【0552】

インプットフォーマッティングモジュール、特に、モードアダプテーションモジュールに入力されたデータストリームはＢＩＣＭモジュールでＦＥＣを遂行することができるように適切な長さにスライシングできる。これを通じてＢＢフレームが生成できる。

【0553】

ＢＢフレームのデータフィールドの長さはＢＢフレームの全体長さからＢＢフレームヘッダの長さを引いた値に該当する。

【0554】

前記ＢＢＦのデータフィールド部分に実際ＵＰ（User Packet）が挿入できる。

【0555】

データフィールドの長さはＢＢフレームヘッダのＤＦＬ（data Field Length）フィールドで知らせることができる。ＤＦＬフィールドはＤＦＬで表現できる。

【0556】

インプットフォーマッティングを通じて生成されるＢＢフレームは、予め設定されたＦＥＣブロックでエンコーディングできる。

【0557】

ここで、ＢＢフレームの全長は固定されていることができる。

【0558】

また、ＢＢＦのデータフィールドの長さが変わる場合は、ＵＰが充分でなくてＢＢフレームを全て詰められない場合、または意図的にインバンドシグナリング（in-band signaling）情報が含まれた場合でありうる。

【0559】

ＢＢフレームを全て詰められない場合には、該当空間にスタッフィング（stuffing）が詰められる。前記スタッフィングはパディング（padding）で表現できる。

【0560】

図３６は、従来のＢＢフレーム構造の更に他の一例を示す図である。

【0561】

図３６に示すように、ＢＢフレームのデータフィールド（または、ペイロード）に転送されるデータを全て詰められなかった場合、スタッフィングバイトが挿入できる。

【0562】

前記スタッフィングバイトをシグナリングするために、ＳＴＵＦＦＩフィールドがＢＢＦヘッダに挿入できる。前記ＢＢＦヘッダはＴＳヘッダでありうる。

【0563】

前記ＳＴＵＦＦＩフィールドはＢＢフレームにスタッフィングバイトの存否を示す１ビットの指示子を示す。

【0564】

ＢＢフレームのペイロードにＵＰが全て詰められる場合には、前記スタッフィングバイトが存在しなくなる。この際、前記ＳＴＵＦＦＩは‘０’に設定できる。

【0565】

ＢＢフレームにＵＰが全て詰められない場合には前記スタッフィングバイトが存在することができる。この場合、前記ＳＴＵＦＦＩは‘１’に設定できる。

【0566】

前記スタッフィングバイトがＢＢフレームに含まれている場合、前記スタッフィングバイトの長さはＢＢフレームペイロードの第１のバイトを通じて確認することができる。

【0567】

一例に、前記ＢＢフレームペイロードの第１のバイト値が０ｘＦＦの場合、ＢＢフレームペイロードに１つのスタッフィングバイト（１ｂｙｔｅのスタッフィングバイト）を含むことができる。

【0568】

前記ＢＢフレームペイロードの第１のバイト及び第２のバイト値が各々０ｘＦＥ、０ｘＦＦの場合、前記ＢＢフレームペイロードに２つのスタッフィングバイトを含むことができる。

【0569】

ここで、スタッフィングバイトが２つ以上（スタッフィングバイトの大きさが２ｂｙｔｅ以上）の場合には、第１及び第２のバイト値を各々ＭＳＢ、ＬＳＢにしてスタッフィングバイトの長さをシグナリングすることができる。

【0570】

図３６ａの表で、‘Ｎ’は全体スタッフィングバイトの長さを示す。

【0571】

‘Ｎ’値が１バイトの場合、スタッフィングバイトの全体長さを知らせるフィールドの長さは１バイトでありうる。この際、前記フィールド値は０ｘＦＦに設定できる。

【0572】

ここで、前記スタッフィングバイトの全長を知らせるフィールドはスタッフィングバイト長さフィールドで表現できる。

【0573】

‘Ｎ’値が２バイトの場合、スタッフィングバイト長さフィールドの長さは２バイトでありうる。

【0574】

この際、前記スタッフィングバイト長さフィールド値は０ｘＦＥ及び０ｘＦＦに設定できる。

【0575】

‘Ｎ’値が‘３以上’の場合、一例に、Ｎが３から６５２７８の間の値を有する場合にも前記スタッフィングバイト長さフィールドの長さは２バイトでありうる。

【0576】

この際、前記スタッフィングバイト長さフィールドはＭＳＢとＬＳＢで構成できる。

【0577】

即ち、前記２ｂｙｔｅのスタッフィングバイト長さフィールドは全体スタッフィングバイトの長さをシグナリングすることができる。

【0578】

図３６に示すように、ＭＳＢとＬＳＢの後に追加的なスタッフィングバイトが存在することができる。即ち、総スタッフバイト長さがＮであり、ＭＳＢ及びＬＳＢの長さが２バイトであるので、後続するスタッフィングバイト長さはＮ−２バイトである。

【0579】

図３７は、従来のＢＢフレーム構造の更に他の一例を示す図である。

【0580】

図３７に示すように、スタッフィングバイトの状態を示すために２ｂｉｔのインジケータ（indicator）が使用できる。前記インジケータはＰＡＤＩ（Padding Indicator）で表現できる。

【0581】

ＢＢＦペイロード（または、データフィールドまたはＦＥＣフレーム）にスタッフィングバイト、即ちパディングが含まれない場合、前記ＰＡＤＩは‘００’に設定できる。

【0582】

図３７ｂに図示された第１のＢＢフレームで、ＰＡＤＩは‘００’に設定され、ＢＢＦペイロードにパディングが存在しないことを確認することができる。

【0583】

ＰＡＤＩが‘０１’の場合、ＢＢＦペイロードに含まれるパディングの長さは１バイトであることを示すことができる。

【0584】

図３７ｂに図示された第２のＢＢフレームで、ＰＡＤＩ値が‘０１’に設定され、パディングの長さは１バイトであることが分かる。‘Ｐ’で表示されたものがパディングバイトを示す。

【0585】

ＰＡＤＩが‘１０’の場合、パディングバイトは２つ以上であることを示すことができる。

【0586】

この場合にはパディングフィールドでＭＳＢ及びＬＳＢなどを用いてパディングの長さをシグナリングしてくれることができる。

【0587】

図３７ｂに図示された第３のＢＢフレームで、ＰＡＤＩ値が‘１０’に設定され、パディングフィールドの第１及び第２のバイトが各々ＭＳＢ、ＬＳＢに割り当てられたことを見ることができる。

【0588】

前記ＭＳＢ、ＬＳＢの次に‘Ｐ’で表記された追加的なパディングが存在することができる。

【0589】

図３８は、本明細書で提案するＢＢフレーム構造の一例を示す。

【0590】

本明細書はＢＢフレーム及びＢＢフレームヘッダの構成に対して以下のような方式を提供する。

【0591】

ＢＢフレームは、ＢＢフレームヘッダ、スタッフィングフィールド（stuffing field）、またはペイロード（payload）のうち、少なくとも１つを含んで構成できる。

【0592】

図３８は、前記スタッフィングフィールドが前記ペイロードの前に位置するＢＢフレーム構造の一例を示す。

【0593】

前記スタッフィングフィールドは実施形態によって前記ペイロードの後に位置することもでき、これに対しては図４０及び図４１で具体的に説明する。

【0594】

前記スタッフィングフィールド及びペイロードを含んでＢＢフレームペイロード（または、ＢＢフレームデータフィールドまたはＦＥＣフレーム）と称することもできる。

【0595】

前記ＢＢフレームヘッダはペイロード、即ちデータフィールドのフォーマットを記述することができる（describing）。

【0596】

また、前記スタッフィングフィールドの前にＤＮＰ（Deleted Null Packet）またはＩＳＳＹ（Input Stream Synchronizer）関連情報などが追加で挿入されることもできる。

【0597】

前述したように、前記ペイロードはデータフィールドを意味することができる。

【0598】

前記ＢＢフレームヘッダは、ＳＴＵＦＦＩフィールドを含むことができる。

【0599】

前記ＳＴＵＦＦＩフィールドはＢＢフレームにスタッフィングバイトが存在するか否かを示すインジケータの役割をすることができる。

【0600】

前記ＳＴＵＦＦＩフィールドは１ｂｉｔでありうる。実施形態によってＳＴＵＦＦＩの位置は変更できる。

【0601】

一例に、前記ＳＴＵＦＦＩ値が‘０’の場合、ＢＢフレームはスタッフィングフィールドを含まず、インバンドシグナリングフィールドやはり含まないことがある。

【0602】

ＳＴＵＦＦＩ値が‘１’の場合、ＢＢフレームはスタッフィングフィールドを含むか、またはインバンドシグナリングフィールドを含むことができる。即ち、前記ペイロードにＵＰの以外の情報、即ち、パディングまたはインバンドフィールドが追加で存在することができる。

【0603】

本発明の実施形態によって、ＳＴＵＦＦＩの値が有する‘０’と‘１’が示す意味は互いに後先になることもできる。

【0604】

スタッフィングフィールドは、スタッフィングフィールドヘッダまたはスタッフィングデータ領域のうち、少なくとも１つを含むことができる。

【0605】

前記スタッフィングデータ領域は、スタッフィングデータまたはインバンドシグナリング情報のうち、少なくとも１つを含むことができる。

【0606】

前記スタッフィングフィールドヘッダは、実施形態によって２バイトでありうる。

【0607】

また、前記スタッフィングフィールドヘッダは、ＳＴＵＦＦ＿ＯＮＥ（または、ＰＡＤ＿ＯＮＥ）、ＳＴＵＦＦ＿ＴＹＰＥ（ＰＡＤ＿ＴＹＰＥ）、またはＳＴＵＦＦ＿ＬＥＮ（または、ＰＡＤ＿ＬＥＮ）のうち、少なくとも１つを含むことができる。

【0608】

図３８に図示された１^ｓｔＢｙｔｅはスタッフィングフィールドの第１のバイトを示す。

【0609】

２^ｎｄＢｙｔｅやはりスタッフィングフィールドに属することができる。実施形態によって、最初の２バイト（１^ｓｔＢｙｔｅ及び２^ｎｄＢｙｔｅ）がスタッフィングフィールドヘッダに該当することができる。

【0610】

実施形態によって第３のバイト（３^ｒｄＢｙｔｅ）からはスタッフィングデータ領域に含まれるか、またはペイロードに含まれることができる。

【0611】

ＰＡＤ＿ＯＮＥフィールドは、実施形態によって、ＳＴＵＦＦ＿ＯＮＥフィールドで表現できる。

【0612】

ＳＴＵＦＦＩが‘１’の場合、ＳＴＵＦＦ＿ＯＮＥが確認できる。ＳＴＵＦＦ＿ＯＮＥはスタッフィングバイトの長さが１バイトか否かを示すことができる。ＳＴＵＦＦ＿ＯＮＥは１ビット（ｂｉｔ）のＭＳＢでありうる。ＳＴＵＦＦ＿ＯＮＥが１であれば、スタッフィングバイトの長さが１バイトでありうる。この場合、スタッフィングバイトの長さを表してくれるＳＴＵＦＦ＿ＬＥＮ＿ＬＳＢは使用されないことがある。

【0613】

また、ＳＴＵＦＦ＿ＬＥＮ＿ＭＳＢは全て０に設定できる。この場合、実施形態によってＳＴＵＦＦ＿ＬＥＮ＿ＭＳＢは全て１に設定されることもできる。即ち、実施形態によって１バイトのスタッフィングバイトが００００００００、１１１１１１１１、１０００００００、または０１１１１１１１の値を有することができる。

【0614】

ＳＴＵＦＦ＿ＯＮＥが０であれば、スタッフィングバイトの長さが１バイトより大きいことがある。

【0615】

この場合、２バイトのスタッフィングフィールドヘッダがスタッフィングデータ領域の長さ及びタイプを示すことに使用できる。

【0616】

ＳＴＵＦＦ＿ＯＮＥの値が示すところは、設計者によって互いに後先になることもできる。即ち、１と０が示す意味が互いに後先になることもできる。

【0617】

図示されたＳＴＵＦＦ＿ＯＮＥ（ＰＡＤ＿ＯＮＥ）は第１のバイトの第１のビットに位置できる。この位置は実施形態によって変更可能な事項である。ＳＴＵＦＦ＿ＯＮＥは実施形態によってＢＢフレームヘッダに位置することもできる。

【0618】

実施形態によってＳＴＵＦＦＩとＳＴＵＦＦ＿ＯＮＥの役割をする２ビットの１フィールドが設定できる。ＳＴＵＦＦＩとＳＴＵＦＦ＿ＯＮＥは各々１ビットであるので、２ビットの１フィールドを設定することによって、その役割に代えることができる。このフィールドはＢＢフレームヘッダに位置することも、スタッフィングフィールドに位置することもできる。

【0619】

ＰＡＤ＿ＬＥＮは、実施形態によって、ＳＴＵＦＦ＿ＬＥＮと呼ばれることができる。ＳＴＵＦＦ＿ＬＥＮはＳＴＵＦＦ＿ＬＥＮ＿ＭＳＢまたはＳＴＵＦＦ＿ＬＥＮ＿ＬＳＢのうち、少なくとも１つを含むことができる。

【0620】

ＳＴＵＦＦ＿ＬＥＮ＿ＭＳＢ及びＳＴＵＦＦ＿ＬＥＮ＿ＬＳＢは、各々５ビット、８ビットのフィールドでありうる。

【0621】

前記ＳＴＵＦＦ＿ＬＥＮ＿ＭＳＢ及びＳＴＵＦＦ＿ＬＥＮ＿ＬＳＢフィールドは、全体スタッフィングフィールド長さを示すことに使用できる。実施形態によって、ＳＴＵＦＦ＿ＬＥＮ＿ＭＳＢ及びＳＴＵＦＦ＿ＬＥＮ＿ＬＳＢの長さは互いに変わって、各々８ビット、５ビットでありうる。また、実施形態によって、両者の位置も互いに変わることができる。実施形態によって、パディングの長さを示すフィールドはスタッフィングデータ領域に位置することもできる。

【0622】

従来の場合、最初の２バイトを用いてパディングの長さを表現した。しかしながら、６４Ｋ ＬＤＰＣを使用する場合、パディングの長さは最大６３７０バイト（６４ｋ、５／６コードレート、ＢＣＨコード）の値を有するようになる。したがって、パディングの長さは１３ビット２^１３＝８１９２バイト）で十分に表現できる。

【0623】

したがって、本明細書で提案するＰＡＤ＿ＬＥＮは１３ビット（５＋８）を有することができる。

【0624】

このように、パディングの長さを１３ビットで表現する場合、最初の２バイトのうち、余分の２ビットが残ることができる。

【0625】

本明細書では、前記余分の２ビットをＰＡＤ＿ＴＹＰＥに割り当てて、パディング領域が他の用途（例えば、インバンドシグナリング）に使われる場合、そのタイプをシグナリングすることができる方法を提供する。

【0626】

ＳＴＵＦＦ＿ＴＹＰＥは、実施形態によって、ＰＡＤ＿ＴＹＰＥで表現できる。

【0627】

ＳＴＵＦＦ＿ＴＹＰＥは、前述したように、２ビットのフィールドとして、スタッフィングデータ（または、スタッフィングデータ領域）のタイプを示すことができる。

【0628】

図３８に示すように、ＳＴＵＦＦ＿ＴＹＰＥ値が‘００’の場合、スタッフィングデータ領域はスタッフィングデータのみ含むことができる。

【0629】

ＳＴＵＦＦ＿ＴＹＰＥ値が‘０１’の場合、特定の種類のインバンドシグナリング情報がスタッフィングデータと共にスタッフィングデータ領域に含まれることができる。

【0630】

ＳＴＵＦＦ＿ＴＹＰＥ値が‘１０’の場合、異なる種類のインバンドシグナリング情報がスタッフィングデータと共にスタッフィングデータ領域に含まれることができる。

【0631】

ＳＴＵＦＦ＿ＴＹＰＥ値が‘１１’の場合、特定の種類及び他の種類のインバンドシグナリング情報が全てスタッフィングデータと共にスタッフィングデータ領域に含まれることができる。

【0632】

ここで、特定の種類のインバンドシグナリング情報とは、‘インバンドＡ’を意味することができ、他の種類のインバンドシグナリング情報とは、‘インバンドＢ’を意味することができる。

【0633】

これは、一実施形態に過ぎず、ＳＴＵＦＦ＿ＴＹＰＥ値が指示するタイプ種類は多様な方式により変更できる。

【0634】

また、ＳＴＵＦＦ＿ＴＹＰＥはＢＢフレームペイロードまたはペイロードの構成を指示することができる。例えば、ペイロードのうち、切られていない完全な第１のパケットの位置が指示されることもできる。

【0635】

本明細書で提案するように、スタッフィングフィールドでシグナリングする場合、インバンドシグナリングを他の多数のフレームに挿入可能になる。また、インバンドシグナリング無しでパディングのみ入っている場合と区別が可能になる長所がある。

【0636】

ＳＴＵＦＦ＿ＴＹＰＥの位置は、実施形態によって、ＢＢフレームヘッダに位置することもできる。

【0637】

または、本実施形態のように、スタッフィングフィールドに位置することもできる。実施形態によって、ＳＴＵＦＦ＿ＴＹＰＥの長さは変更されることもできる。

【0638】

ＳＴＵＦＦ＿ＴＹＰＥの値が示すところは、設計者によって互いに後先になることもできる。

【0639】

例えば、００が示すところと１１が示すところとが互いに後先になることもできる。また、１０が示すところと０１が示すところとが互いに後先になることもできる。

【0640】

スタッフィングデータは、実施形態によって、全て０または全て１の値を有することができる。

【0641】

以下、図３８に図示されたｃａｓｅ＃１からｃａｓｅ＃６について具体的に説明する。

【0642】

１）Ｃａｓｅ＃１は、ＢＢフレームにスタッフィングデータ及びインバンドシグナリングが含まれない場合を示す。

【0643】

この場合、ＳＴＵＦＦＩフィールドは‘０’に設定できる。したがって、ＢＢフレームの構造はＢＢフレームヘッダの直後のデータ領域、即ち、ペイロードが位置することができる。

【0644】

２）Ｃａｓｅ＃２は、ＢＢフレームに１バイトのスタッフィングフィールドが存在し、インバンドシグナリングが存在しない場合を示す。

【0645】

この場合、ＳＴＵＦＦＩフィールドは‘１’に設定できる。即ち、ＢＢフレームはスタッフィングフィールドを含み、前記スタッフィングフィールドは１バイトの大きさを有することができる。

【0646】

ここで、前記スタッフィングフィールドの第１のビットはＳＴＵＦＦ＿ＯＮＥフィールドを表し、前記スタッフィングフィールドの大きさが１バイトであるので、‘１’の値を有する。

【0647】

前記スタッフィングフィールドの残りの７個のビットは１１１１１１１の値を有することができる。

【0648】

したがって、１ｂｙｔｅのスタッフィングフィールドは１１１１１１１１で表現できる。

【0649】

３）Ｃａｓｅ＃３は、ＢＢフレームに１バイトより大きいスタッフィングフィールドが存在し、インバンドシグナリングが存在しない場合を示す。

【0650】

即ち、前記スタッフィングフィールドは２バイトまたは２バイトより大きいことがある。

【0651】

スタッフィングフィールドが存在するので、ＳＴＵＦＦＩフィールドは‘１’に設定できる。

【0652】

前記スタッフィングフィールドは、２バイトのスタッフィングフィールドヘッダを有することができる。前記スタッフィングフィールドヘッダの第１のバイトの第１のビットはＳＴＵＦＦ＿ＯＮＥフィールドに該当する。

【0653】

前記ＳＴＵＦＦ＿ＯＮＥフィールドは、前記スタッフィングフィールドの大きさが１バイトより大きいので‘０’値に設定できる。

【0654】

前記スタッフィングフィールドヘッダの第１のバイトの第２及び第３のビットはＳＴＵＦＦ＿ＴＹＰＥフィールドに該当する。

【0655】

ＢＢフレームのスタッフィングデータ領域にスタッフィングデータのみがある場合であるので、前述したように、ＳＴＵＦＦ＿ＴＹＰＥは００の値を有することができる。

【0656】

本図面では、他の実施形態として、ＳＴＵＦＦ＿ＴＹＰＥが１１値を有する場合が図示されている。

【0657】

即ち、この場合はＢＢフレームのスタッフィングデータ領域にスタッフィングデータのみがある場合であって、ＳＴＵＦ＿ＴＹＰＥフィールドが１１値として指示できる。

【0658】

この後、スタッフィングフィールドヘッダのＳＴＵＦＦ＿ＬＥＮ＿ＭＳＢ及びＳＴＵＦＦ＿ＬＥＮ＿ＬＳＢがスタッフィングフィールドの長さ情報を有することができる。前述したように、スタッフィングフィールドの長さは総１３ビットを用いて表現できる。ＳＴＵＦＦ＿ＬＥＮ＿ＭＳＢ及びＳＴＵＦＦ＿ＬＥＮ＿ＬＳＢの以後にはスタッフィングデータ領域が位置することができる。このケースで、スタッフィングデータ領域にはスタッフィングデータのみ来ることができる。

【0659】

（４）Ｃａｓｅ＃４は、ＢＢフレームに１バイトより大きいスタッフィングフィールドが存在し、インバンドＡシグナリングが存在する場合を示す。

【0660】

この場合、ＢＢフレームのスタッフィングデータ領域にはスタッフィングデータ及びインバンドＡシグナリングが存在することができる。

【0661】

前記インバンドＡシグナリングは、前述した特定の種類のインバンドシグナリングを意味することができる。この場合、スタッフィングフィールドが存在するので、ＳＴＵＦＦＩは１の値を有することができる。

【0662】

前記スタッフィングフィールドヘッダの第１のバイトの第１のビットはＳＴＵＦＦ＿ＯＮＥフィールドであって、スタッフィングフィールドの大きさが１バイトより大きいので‘０’の値を有することができる。

【0663】

スタッフィングフィールドヘッダの第１のバイトの第２、第３のビットは前述したＳＴＵＦＦ＿ＴＹＰＥフィールドでありうる。

【0664】

ＢＢフレームのスタッフィングデータ領域にインバンドＡシグナリングが存在する場合であるので、前述したように、ＳＴＵＦＦ＿ＴＹＰＥは１０の値を有することができる。実施形態によって、この値は０１でありうる。

【0665】

この後、スタッフィングフィールドヘッダのＳＴＵＦＦ＿ＬＥＮ＿ＭＳＢ及びＳＴＵＦＦ＿ＬＥＮ＿ＬＳＢがスタッフィングフィールドの長さ情報を有することができる。前述したように、スタッフィングフィールドの長さは総１３ビットを用いて表現できる。ＳＴＵＦＦ＿ＬＥＮ＿ＭＳＢ及びＳＴＵＦＦ＿ＬＥＮ＿ＬＳＢの以後にはスタッフィングデータ領域が位置することができる。このケースで、スタッフィングデータ領域にはスタッフィングデータの他にもインバンドＡシグナリングが存在することができる。

【0666】

（５）Ｃａｓｅ＃５は、ＢＢフレームに１バイトより大きいスタッフィングフィールドが存在し、インバンドＢシグナリングが存在する場合でありうる。

【0667】

この場合、ＢＢフレームのスタッフィングデータ領域にはスタッフィングデータ及びインバンドＢシグナリングが存在することができる。

【0668】

前記インバンドＢシグナリングとは、前述した他の種類のインバンドシグナリングを意味することができる。この場合、スタッフィングフィールドが存在するので、ＳＴＵＦＦＩは１の値を有することができる。

【0669】

スタッフィングフィールドヘッダの第１のバイトの第１のビットはＳＴＵＦＦ＿ＯＮＥフィールドであって、スタッフィングフィールドの大きさが１バイトより大きいので、０の値を有することができる。

【0670】

スタッフィングフィールドヘッダの第１のバイトの第２及び第３のビットは前述したＳＴＵＦＦ＿ＴＹＰＥフィールドでありうる。ＢＢフレームのスタッフィングデータ領域にインバンドＢシグナリングが存在する場合であるので、前述したように、ＳＴＵＦＦ＿ＴＹＰＥは０１の値を有することができる。実施形態によって、この値は１０でありうる。

【0671】

この後、スタッフィングフィールドヘッダのＳＴＵＦＦ＿ＬＥＮ＿ＭＳＢ及びＳＴＵＦＦ＿ＬＥＮ＿ＬＳＢがスタッフィングフィールドの長さ情報を有することができる。前述したように、スタッフィングフィールドの長さは総１３ビットを用いて表現できる。ＳＴＵＦＦ＿ＬＥＮ＿ＭＳＢ及びＳＴＵＦＦ＿ＬＥＮ＿ＬＳＢの以後には、スタッフィングデータ領域が位置することができる。このケースで、スタッフィングデータ領域にはスタッフィングデータの他にもインバンドＢシグナリングが存在することができる。

【0672】

（６）Ｃａｓｅ＃６は、ＢＢフレームに１バイトより大きいスタッフィングフィールドが存在し、インバンドＡ及びＢシグナリングが存在する場合でありうる。

【0673】

この場合、ＢＢフレームのスタッフィングデータ領域には、スタッフィングデータ及びインバンドＡ及びＢシグナリングが全て存在することができる。

【0674】

この場合、ＳＴＵＦＦＩは１の値を有することができる。スタッフィングフィールドヘッダの第１のバイトの第１のビットはＳＴＵＦＦ＿ＯＮＥフィールドであって、スタッフィングフィールドの大きさが１バイトより大きいので、０の値を有することができる。スタッフィングフィールドヘッダの第１のバイトの第２、第３のビットは、前述したＳＴＵＦＦ＿ＴＹＰＥフィールドでありうる。ＢＢフレームのスタッフィングデータ領域にインバンドＡ及びＢシグナリングが存在する場合であるので、前述したように、ＳＴＵＦＦ＿ＴＹＰＥは１１の値を有することができる。

【0675】

本図面では、他の実施形態として、ＳＴＵＦＦ＿ＴＹＰＥこの００値を有する場合が図示されている。即ち、この場合はスタッフィングデータ領域にインバンドＡ及びＢシグナリングが全て存在する場合がＳＴＵＦ＿ＴＹＰＥフィールドが００値として指示できる。

【0676】

この後、スタッフィングフィールドヘッダのＳＴＵＦＦ＿ＬＥＮ＿ＭＳＢ及びＳＴＵＦＦ＿ＬＥＮ＿ＬＳＢがスタッフィングフィールドの長さ情報を有することができる。前述したように、スタッフィングフィールドの長さは総１３ビットを用いて表現できる。

【0677】

ＳＴＵＦＦ＿ＬＥＮ＿ＭＳＢ及びＳＴＵＦＦ＿ＬＥＮ＿ＬＳＢの以後にはスタッフィングデータ領域が位置することができる。このケースで、スタッフィングデータ領域にはスタッフィングデータの他にもインバンドＡ及びＢシグナリングが存在することができる。

【0678】

図３９は、本明細書で提案するＢＢフレーム構造の更に他の一例を示す図である。

【0679】

図３９（ａ）はパディング、即ちスタッフィングデータ無しでデータのみがある場合のＢＢフレームでありうる。

【0680】

ＢＢフレームヘッダのＳＴＵＦＦＩが０の値を有していることができる。ＢＢフレームヘッダの後にスタッフィングフィールド無しで、直ぐペイロードが位置することが分かる。図３８のＣａｓｅ＃１に該当することができる。

【0681】

図３９（ｂ）は、１バイトのパディングを有する場合でありうる。

【0682】

この場合、ＢＢフレームヘッダのＳＴＵＦＦＩが１の値を有することができる。第１のバイトの第１のビットはＳＴＵＦＦ＿ＯＮＥとして１の値を有することができる。これは、パディングが１バイトであることを意味することができる。図３９で、パディングの各ビットは１１１１１１１１の値を有することができる（０ｘＦＦ）。または、実施形態によって１０００００００の値を有することもできる。図３８のＣａｓｅ＃２に該当することができる。

【0683】

図３９（ｃ）は、ｎバイトのパディングを有する場合でありうる。

【0684】

この場合、ＢＢフレームヘッダのＳＴＵＦＦＩが１の値を有することができる。また、ＳＴＵＦＦ＿ＯＮＥは０の値を有することができる。ＳＴＵＦＦ＿ＴＹＰＥはインバンドシグナリング無しで、スタッフィングデータのみ使われているという点を指示することができる。

【0685】

即ち、実施形態によって、ＳＴＵＦＦ＿ＴＹＰＥは００の値を有することができる。

【0686】

以後、残りの１３ビットはスタッフィングフィールドの長さがｎバイトであることを指示することができる。この１３ビットは、ＳＴＵＦＦ＿ＬＥＮ＿ＭＳＢ及びＳＴＵＦＦ＿ＬＥＮ＿ＬＳＢでありうる。ＳＴＵＦＦ＿ＬＥＮ＿ＭＳＢ及びＳＴＵＦＦ＿ＬＥＮ＿ＬＳＢの後には、スタッフィングデータが来ることができる。図３８のＣａｓｅ＃３のうち、スタッフィングフィールドが３バイト以上の場合に該当することができる。

【0687】

図３９（ｄ）は、インバンドＡシグナリングと共にｎバイトのパディングを有する場合でありうる。

【0688】

この場合、ＢＢフレームヘッダのＳＴＵＦＦＩが１の値を有することができる。また、ＳＴＵＦＦ＿ＯＮＥは０の値を有することができる。ＳＴＵＦＦ＿ＴＹＰＥはインバンドＡシグナリングが使われていることを指示することができる。

【0689】

即ち、実施形態によってＳＴＵＦＦ＿ＴＹＰＥは０１の値を有することもできる。ＳＴＵＦＦ＿ＴＹＰＥの値自体は前述したように変更できる。以後、残りの１３ビットはスタッフィングフィールドの長さがｎバイトであることを指示することができる。この１３ビットはＳＴＵＦＦ＿ＬＥＮ＿ＭＳＢ及びＳＴＵＦＦ＿ＬＥＮ＿ＬＳＢでありうる。ＳＴＵＦＦ＿ＬＥＮ＿ＭＳＢ及びＳＴＵＦＦ＿ＬＥＮ＿ＬＳＢの後にはインバンドＡシグナリングデータが来ることができる。図３８のＣａｓｅ＃４に該当することができる。

【0690】

図３９（ｅ）は、インバンドＢシグナリングと共にｎバイトのパディングを有する場合でありうる。

【0691】

この場合、ＢＢフレームヘッダのＳＴＵＦＦＩが１の値を有することができる。また、ＳＴＵＦＦ＿ＯＮＥは０の値を有することができる。ＳＴＵＦＦ＿ＴＹＰＥはインバンドＢシグナリングが使われていることを指示することができる。

【0692】

即ち、実施形態によってＳＴＵＦＦ＿ＴＹＰＥは１０の値を有することもできる。ＳＴＵＦＦ＿ＴＹＰＥの値自体は前述したように変更できる。

【0693】

以後、残りの１３ビットはスタッフィングフィールドの長さがｎバイトであることを指示することができる。

【0694】

この１３ビットはＳＴＵＦＦ＿ＬＥＮ＿ＭＳＢ及びＳＴＵＦＦ＿ＬＥＮ＿ＬＳＢでありうる。ＳＴＵＦＦ＿ＬＥＮ＿ＭＳＢ及びＳＴＵＦＦ＿ＬＥＮ＿ＬＳＢの後にはインバンドＢシグナリングデータが来ることができる。図３８のＣａｓｅ＃５に該当することができる。

【0695】

図３９（ｆ）は、インバンドＡ及びＢシグナリングと共にｎバイトのパディングを有する場合でありうる。

【0696】

この場合、ＢＢフレームヘッダのＳＴＵＦＦＩが１の値を有することができる。また、ＳＴＵＦＦ＿ＯＮＥは０の値を有することができる。ＳＴＵＦＦ＿ＴＹＰＥはインバンドＡ及びＢシグナリングが全て使われていることを指示することができる。

【0697】

即ち、実施形態によって、ＳＴＵＦＦ＿ＴＹＰＥは１１の値を有することもできる。ＳＴＵＦＦ＿ＴＹＰＥの値自体は前述したように変更できる。以後、残りの１３ビットはスタッフィングフィールドの長さがｎバイトであることを指示することができる。この１３ビットはＳＴＵＦＦ＿ＬＥＮ＿ＭＳＢ及びＳＴＵＦＦ＿ＬＥＮ＿ＬＳＢでありうる。ＳＴＵＦＦ＿ＬＥＮ＿ＭＳＢ及びＳＴＵＦＦ＿ＬＥＮ＿ＬＳＢの後にはインバンドＡ及びＢシグナリングデータが来ることができる。図３８のＣａｓｅ＃６に該当することができる。

【0698】

図４０は、本明細書で提案するＢＢフレーム構造の更に他の一例を示す図である。

【0699】

図４０は、スタッフィングフィールド（Stuffing field）がＢＢフレームの端（ペイロードの後）に位置する場合のＢＢフレーム構造の一例を示す。

【0700】

ＢＢフレームはＢＢＦヘッダ及びＢＢフレームペイロードを含む。

【0701】

前記ＢＢＦヘッダは、ＢＢＦデータフィールドのフォーマットを示すためにＢＢＦフレームペイロードの前に挿入される。

【0702】

前記ＢＢＦヘッダは２ｂｙｔｅｓの固定された長さを有することができる。

【0703】

前記ＢＢＦヘッダは、ＢＢフレームにスタッフィング（Stuffing）またはパディングがあるか否かを示すインジケータに該当するＳＴＵＦＦＩフィールドを含む。前記ＳＴＵＦＦＩフィールドは１ｂｉｔで表現できる。

【0704】

前記ＢＢフレームペイロードは、スタッフィングフィールド及びペイロードを含むことができる。

【0705】

前記スタッフィングフィールドは、前記ＢＢフレームペイロードにＵＰが全て詰められない場合に含まれる。

【0706】

一例に、前記ＳＴＵＦＦＩフィールドが‘１’に設定される場合、前記ＢＢフレームペイロードは前記スタッフィングフィールドを含むことができる。

【0707】

前記ペイロードは、ＵＰ（User Packet）が含まれる領域をいう。

【0708】

前記スタッフィングフィールドは、スタッフィングヘッダフィールド（または、スタッフィングフィールドヘッダ）及びスタッフィングデータ（領域）で構成できる。

【0709】

前記スタッフィングデータ領域は、スタッフィングデータフィールドまたはスタッフィングデータで表現できる。

【0710】

前記スタッフィングデータ領域にはスタッフィングデータ、インバンドシグナリング情報などが含まれることができる。

【0711】

前記スタッフィングヘッダフィールドは、ＳＴＵＦＦ＿ＯＮＥフィールド、ＳＴＵＦＦ＿ＴＹＰＥフィールド、及びＳＴＵＦＦ＿ＬＥＮフィールドを含むことができる。

【0712】

前記ＳＴＵＦＦ＿ＬＥＮフィールドは前記スタッフィングヘッダフィールドを含む全体スタッフィングフィールドの長さを示し、ＳＴＵＦＦ＿ＬＥＮ＿ＭＳＢフィールド及びＳＴＵＦＦ＿ＬＥＮ＿ＬＳＢフィールドを含むことができる。前記ＳＴＵＦＦ＿ＬＥＮフィールドは１３ｂｉｔで表現される。

【0713】

前記ＳＴＵＦＦ＿ＯＮＥフィールドは、前記スタッフィングフィールドの長さが１ｂｙｔｅか否かを示す１ｂｉｔのフィールドをいう。

【0714】

一例に、前記ＳＴＵＦＦ＿ＯＮＥフィールドが‘１’に設定された場合、前記スタッフィングフィールドの長さは１ｂｙｔｅであることを示す。この場合、前記ＳＴＵＦＦ＿ＬＥＮ＿ＬＳＢフィールドは、前記スタッフィングフィールド、即ちＳＴＵＦＦ＿ＬＥＮフィールドに含まれない。

【0715】

仮に、前記ＳＴＵＦＦ＿ＯＮＥフィールドが‘０’に設定された場合、前記スタッフィングフィールドの長さは１ｂｙｔｅより大きいことを示す。この場合、前記スタッフィングヘッダの２ｂｙｔｅｓはスタッフィングデータのタイプと長さを示すために使われる。

【0716】

即ち、前記ＳＴＵＦＦ＿ＴＹＰＥフィールドは、スタッフィングデータのタイプを示し、２ビットで表現できる。

【0717】

以下の＜表３４＞は、図４０のＳＴＵＦＦ＿ＴＹＰＥフィールドの一例を示す。

【0718】

【表34】

【0719】

＜表３４＞及び図４０を参照すると、ＳＴＵＦＦ＿ＴＹＰＥフィールドが（１）‘００’に設定された場合、スタッフィングデータ領域はスタッフィングデータのみに使用され、２）‘０１’に設定された場合、スタッフィングデータ領域はインバンドＡシグナリング情報とスタッフィングデータに使用され、３）‘１０’に設定された場合、スタッフィングデータ領域はインバンドＢシグナリング情報とスタッフィングデータに使用され、（４）‘１１’に設定された場合、スタッフィングデータ領域はインバンドＡシグナリング情報、インバンドＢシグナリング情報、及びスタッフィングデータに使用される。

【0720】

＜表３４＞で、インバンドＡはインバンドＩＳＳＹであり、インバンドＢはインバンドＰＬＳでありうる。

【0721】

前記ＳＴＵＦＦ＿ＬＥＮ＿ＭＳＢフィールドは、前記スタッフィングヘッダフィールドを含む全体スタッフィングフィールド長さのＭＳＢ（Most Significant Bit）値を示し、５ｂｉｔで表現される。

【0722】

一例に、ＳＴＵＦＦ＿ＯＮＥフィールドが‘１’に設定された場合、前記ＳＴＵＦＦ＿ＬＥＮ＿ＭＳＢフィールドは‘１１１１１’で表現できる。または、‘０００００’に設定されることもできる。

【0723】

前記ＳＴＵＦＦ＿ＬＥＮ＿ＬＳＢフィールドは、全体スタッフィングフィールド長さのＬＳＢ（Least Significant）値を示し、８ビットで表現される。

【0724】

前記スタッフィングデータフィールドはスタッフィング及び／又はインバンドシグナリングフィールドを含むことができる。

【0725】

ここで、‘スタッフィング及び／又はインバンドシグナリング’は、スタッフィング、インバンド シグナリング、またはスタッフィング及びインバンドシグナリングを意味する。

【0726】

即ち、‘Ａ及び／又はＢ’の表現はＡまたはＢのうち、少なくともいずれか１つの意味と同一でありうる。

【0727】

図４０を参照すると、スタッフィングフィールドのＮｔｈ Ｂｙｔｅの第８のビットはＳＴＵＦＦ＿ＯＮＥフィールドを示し、Ｎｔｈ Ｂｙｔｅの第６及び第７のビットはＳＴＵＦＦ＿ＴＹＰＥフィールドを示し、スタッフィングフィールドのＮｔｈ Ｂｙｔｅの第１のビット乃至第５のビットはＳＴＵＦＦ＿ＬＥＮ＿ＬＳＢフィールドを示し、スタッフィングフィールドの（Ｎ−１）ｔｈ ＢｙｔｅはＳＴＵＦＦ＿ＬＥＮ＿ＭＳＢフィールドを示すことを見ることができる。

【0728】

また、スタッフィングフィールドの（Ｎ−２）ｔｈ Ｂｙｔｅからデータ（ＵＰ）またはスタッフィングデータまたはインバンドＡデータまたはインバンドＢデータ、またはインバンドＡ及びＢデータを示すことを見ることができる。

【0729】

図４０のＣａｓｅ＃１乃至Ｃａｓｅ＃６に対するより具体的な説明は、各々対応する図３８のＣａｓｅ＃１乃至Ｃａｓｅ＃６の説明を参照する。

【0730】

図４０のフレーム構造は、図３８のフレーム構造と同一な機能を遂行することができる。

【0731】

図４０に図示されたＢＢフレーム構造のように、スタッフィングフィールドがＢＢフレームの端に位置する場合、受信装置でスタッフィング確認無しでＵＰ（User Packet）を直ぐ受信することができるので、ＵＰに対するアクセス時間が図３８に図示されたＢＢフレーム構造に比べて短くなる効果がある。

【0732】

図４１は、本明細書で提案するＢＢフレーム構造の更に他の一例を示す図である。

【0733】

図４１は、スタッフィングフィールドがＢＢフレームの最後に位置（または、ペイロード、ＦＥＣフレームの後に位置）する場合の多様なＢＢフレーム構造を示す。

【0734】

図４１のフレーム構造は、図３９のフレーム構造とスタッフィングフィールドの位置のみ異なり、他の部分は全て同一であるので、図４１に対する具体的な説明は、図３９を参照する。

【0735】

図４２は、多様なＢＢフレーム構造でＢＢフレーム転送に対するオーバーヘッドを計算した結果を比較して示す図である。

【0736】

ＤＶＢ−Ｔ２で表記されたグラフは、前述した従来技術のオーバーヘッドグラフでありうる。ＤＶＢ−Ｔ２とは、ＤＶＢ（Digital Video Broadcasting）の地上波ＴＶ放送システム（terrestrial television broadcasting system）関連標準を意味することができる。ＤＶＢ−Ｔ２とは、ヨーロッパの次世代地上波放送に関連した標準を意味することができる。ＤＶＢ−Ｔ２で表記されたグラフは、この標準技術に従うＢＢフレームにおいて、そのオーバーヘッドを計算したグラフでありうる。

【0737】

ＭＨで表記されたグラフは、前述した他の従来技術のオーバーヘッドグラフでありうる。ＭＨとは、ＣＥＡ（Consumer Electronics Association）のモバイル／ハンドヘルド（Mobile／Handheld）ＤＴＶシステム関連標準を意味することがきる。ＭＨとは、北−米モバイルハンドヘルド（mobile handheld）関連標準を意味することができる。ＭＨで表記されたグラフは、この標準技術に従うＢＢフレームにおいて、そのオーバーヘッドを計算したグラフでありうる。

【0738】

ＳＳ ＆ＳＮで表記されたグラフは、前述した更に他の従来技術のオーバーヘッドグラフでありうる。ＳＳ ＆ ＳＮは、従来技術のうちの１つを意味することができる。この従来技術で提示する方法によりＢＢフレーム及びＢＢフレームヘッダを構成した時のオーバーヘッドを計算したグラフが、ＳＳ ＆ ＳＮで表記されたグラフで図示されている。

【0739】

以下の＜表３５＞は各ＢＢフレーム転送時、オーバーヘッドを計算した結果を示した表である。

【0740】

【表35】

【0741】

オーバーヘッドは、データフィールドの長さを示すフィールドのオーバーヘッドを意味することができる。

【0742】

従来技術は毎ＢＢフレームに２バイトのフィールドを使用するので、オーバーヘッドを最大０．２２％を有することができる。

【0743】

他の従来技術は１ビットのフィールドのみを使用するので、オーバーヘッドを最大０．０１３９％のみを有することができる。最も低い場合でありうる。

【0744】

更に他の従来技術は２ビットのフィールドを使用することができる。この場合、オーバーヘッドは他の従来技術に比べて２倍でありうる。

【0745】

ＬＧで表記されたグラフは、本発明によるオーバーヘッドグラフでありうる。本発明の場合、スタッフィングフィールドのシグナリングのために１ビットのフィールドのみを使用することができる。したがって、オーバーヘッドが最小になることができる。また、追加的に余分の２ビットフィールドを設けることによって、インバンドシグナリングのタイプなどを指示することに活用できるという長所がある。本発明はこの余分のフィールドを用いて、ＢＢフレームの構成を示すなど、他の用途にも利用可能な構造をサポートすることができる。

【0746】

図４３は、従来のＢＢフレーム構造の一例を示す。

【0747】

図４３に示すように、ＢＢフレームはヘッダ、オプショナルヘッダ、及びペイロードデータを含んで構成される。

【0748】

前記ヘッダは、ＰＳＰＭＩ（Packet Start Pointer Mode Indicator）フィールド、ＰＡＤＩ（Padding Indicator）フィールド、ＰＫＴＳＰＴＲ＿ＬＳＢ（Packet Start Pointer Low Significant Bits）フィールドを含む。

【0749】

前記ＰＳＰＭＩフィールドは、ＰＫＴＳＰＴＲ（Packet Start Pointer）フィールドがショートモード（short mode）か、またはロングモード（long mode）かを示す１ｂｉｔ大きさのフラグフィールドをいう。

【0750】

前記ＰＫＴＳＰＴＲ（Packet Start Pointer）フィールドはＳＹＮＣＤフィールドと同一な概念でありうる。

【0751】

即ち、前記ＰＳＰＭＩフィールドはＰＫＴＳＰＴＲ（Packet Start Pointer）フィールドの長さが短いか、長いかを表示してくれるフラグをいう。

【0752】

前記ＰＫＴＳＰＴＲ＿ＬＳＢ（Packet Start Pointer Low Significant Bits）フィールドは、１３ｂｉｔのＰＫＴＳＰＴＲ（Packet Start Pointer）フィールドの５ＬＳＢ ｂｉｔｓを示す。

【0753】

前記オプショナルヘッダは、ＰＫＴＳＰＴＲ＿ＭＳＢ（Packet Start Pointer Most Significant Bits）フィールド、パディング（PADDING）フィールドを含むことができる。

【0754】

前記ＰＫＴＳＰＴＲ＿ＭＳＢフィールドは、１３ｂｉｔのＰＫＴＳＰＴＲ（Packet Start Pointer）フィールドの８ＭＳＢ ｂｉｔｓを示す。

【0755】

また、前記パディングフィールドはＰＡＤＬ（Padding data Length）フィールド及びＰＡＤＤＩＮＧ＿ＤＡＴＡフィールドを含むことができる。

【0756】

前記ＰＡＤＬフィールドはパディングデータフィールドの長さを示し、１６ｂｉｔ大きさを有する。

【0757】

前記ＰＡＤＤＩＮＧ＿ＤＡＴＡフィールドは可変的な長さを有し、パディング情報を示す。

【0758】

図４３に示すように、ＢＢフレーム構造は最大１３ｂｙｔｅの（Payload）データフィールドの長さを表現するために、前記データフィールドの長さを示す情報（例：ＤＦＬ）を使用せず、ＰＡＤＤＩＮＧフィールドの長さを転送して受信装置でデータフィールドの長さを計算するようになっている。

【0759】

ここで、前記パディングフィールドの長さはＢＢフレームのペイロードデータサイズ−データフィールド長さに該当する。

【0760】

ＢＢフレームにパディングフィールドが存在しない場合にはＢＢフレームサイズを用いてＤＦＬ（data Field Length）を計算する。

【0761】

前記ＢＢフレームにパディングフィールドがある場合にはＢＢフレームヘッダに２ｂｉｔのＰＡＤＩを含むことによって、パディングの長さを知らせるようになる。

【0762】

より効率的に、ＦＥＣブロックにＢＢＦ（BaseBand Frame）を転送するために、即ちＢＢフレームヘッダ転送に対するオーバーヘッドを減らすために、ＰＫＴＳＰＲＴフィールドをＰＫＴＳＰＴＲ＿ＬＳＢ及びＰＫＴＳＰＴＲ＿ＭＳＢに分けて運用する。

【0763】

即ち、ＰＫＴＳＰＴＲフィールドは２ｂｙｔｅの大きさまでサポート可能であるが、前記ＰＫＴＳＰＴＲフィールドの長さが短い場合（＜３１ｂｙｔｅ）、ＰＫＴＳＰＴＲ＿ＬＳＢのみ使用することができるので、前記ＰＫＴＳＰＴＲフィールドの転送大きさを１ｂｙｔｅに減らすことができる。

【0764】

しかしながら、ＰＫＴＳＰＴＲ＿ＬＳＢの長さが５ｂｉｔに短いため、ＰＫＴＳＰＴＲフィールドの大きさが３１ｂｙｔｅ以下の場合のみに１ｂｙｔｅのＢＢＦヘッダ構成が可能であるという短所がある。

【0765】

図３５で説明したように、従来のＢＢフレームはＢＢフレームのデータフィールドの長さを受信装置（または、受信端）に知らせるためにＤＦＬ（data field length：１６ビット、１１ビット）を毎ＢＢフレームヘッダに割り当てて使用しているので、ＢＢフレームをＦＥＣブロックに転送するに当たってオーバーヘッドが大きく発生する。

【0766】

したがって、ＢＢフレームヘッダに対する転送効率を高めて、エラー確認（error check）の新たな機能を追加するための新たなＢＢフレーム構造について具体的に説明する。

【0767】

即ち、本明細書はＢＢフレームヘッダに含まれるＳＹＮＣＤフィールドの大きさを調節して全体的にＢＢフレームヘッダの大きさを減らす方法、ＢＢフレームヘッダ内の余分の１ｂｉｔを活用してエラー確認を遂行する方法などを提供する。

【0768】

以下、本明細書で提案する方法及びＢＢフレーム構造は、送信装置ではＢＢフレームヘッダ挿入（BB Frame Header Insertion）ブロックで、受信装置ではＢＢフレームヘッダパーサ（BB Frame Header Parser）ブロックで動作する。

【0769】

図４４は、本明細書における提案するＢＢフレーム構造の一例を示す図である。

【0770】

図４４ａのインプットストリームはインプットフォーマッティングモジュールのモードアダプテーション（mode adaptation）モジュールを通じて図４４ｂのＢＢフレーム構造を形成する。

【0771】

図４４に示すように、多数のパケットを含むインプットストリームはモードアダプテーションモジュールを通じてペイロード（Payload）にスライシング（slicing）またはマッピングされ、前記ペイロードの前に前記ペイロードと関連した情報を含むヘッダが付加される。

【0772】

前記ペイロードは、ＢＢフレームデータフィールドで表現できる。

【0773】

前記ヘッダは、ＯＰＴＩＯＮＩフィールド、ＳＴＵＦＦＩフィールド、ＳＹＮＣＤ＿ＬＳＢフィールド、ＳＹＮＣＤ＿ＭＳＢフィールド、Checksumフィールド、またはStuffingフィールドのうち、少なくとも１つを含んで構成できる。

【0774】

前述したように、前記Stuffingフィールドは、Stuffing Headerフィールド及びStuffing Byteフィールドを含むことができる。

【0775】

前記Stuffing Byteフィールドは、スタッフィングデータフィールドまたはスタッフィングデータ領域で表現されることもできる。

【0776】

前記ＯＰＴＩＯＮＩフィールド、ＳＴＵＦＦＩフィールド、及びＳＹＮＣＤ＿ＬＳＢフィールドを含むＢＢフレームヘッダが定義されることもでき、ＳＹＮＣＤ＿ＭＳＢフィールド及びChecksumフィールドを含むオプションヘッダが定義されることもできる。

【0777】

図４４の場合、ＢＢフレームヘッダ及びオプションヘッダが定義されたことを見ることができる。

【0778】

また、前記スタッフィングフィールドは前記ヘッダに含まれることもでき、前記ヘッダに含まれないこともできる。

【0779】

前記スタッフィングフィールドが前記ヘッダに含まれない場合には、前記ペイロードと共にＢＢフレームペイロードを構成することができる。

【0780】

前記スタッフィングフィールドはペイロードの前に位置するか（図４４）、または前記ペイロードの後に位置することもできる。

【0781】

ＳＹＮＣＤフィールドは、データフィールドの開始から前記データフィールドで始まる最初に転送されるＵＰ（User Packet）の開始までの距離を示すことができる。

【0782】

ここで、前記ＳＹＮＣＤフィールドはＳＹＮＣＤ＿ＬＳＢフィールド及びＳＹＮＣＤ＿ＭＳＢフィールドに区分されることができ、１３ｂｉｔの大きさを有する。

【0783】

前記ＳＹＮＣＤ＿ＬＳＢフィールドはＳＹＮＣＤのＬＳＢ（Least Significant bit）を示す値で、６ｂｉｔｓの大きさを有し、最大６３ｂｙｔｅのＳＹＮＣＤを表現することができる。

【0784】

図４４に示すように、ヘッダがＢＢフレームヘッダとオプションヘッダに区分される場合、前記ＳＹＮＣＤ＿ＬＳＢフィールドは前記ＢＢフレームヘッダに含まれることができる。

【0785】

また、前記ＳＹＮＣＤ＿ＭＳＢフィールドはＳＹＮＣＤのＭＳＢ（Most Significant bit）を示す値で、７ｂｉｔｓの大きさを有する。

【0786】

図４４に示すように、ヘッダがＢＢフレームヘッダとオプションヘッダに区分される場合、前記ＳＹＮＣＤ＿ＭＳＢフィールドは前記オプションヘッダに含まれることができる。

【0787】

前記ＳＹＮＣＤ＿ＭＳＢフィールドはＯＰＴＩＯＮＩフィールドにより使用有無が定まる。

【0788】

前記ＯＰＴＩＯＮＩフィールドはペイロードを通じて転送されるパケットのうち、新しく始まるパケットの位置がＳＹＮＣＤ＿ＬＳＢ（６ビット）で表現できるか否かを示す。

【0789】

一例に、前記ＯＰＴＩＯＮＩフィールドが‘０’に設定された場合、ペイロードを通じて転送されるパケットのうち、新しく始まるパケットの位置がＳＹＮＣＤ＿ＬＳＢ（６ビット）で表現できることを示す。

【0790】

前記ＯＰＴＩＯＮＩフィールドが‘１’に設定された場合、ペイロードを通じて転送されるパケットのうち、新しく始まるパケットの位置がＳＹＮＣＤ＿ＬＳＢ（６ビット）で表現できない場合を示す。

【0791】

したがって、前記ＯＰＴＩＯＮＩフィールドが‘１’に設定された場合、ＳＹＮＣＤ＿ＬＳＢフィールド（６ビット）及びＳＹＮＣＤ＿ＭＳＢフィールド（７ビット）を用いてペイロード内の新しく始まるパケットの位置を示さなければならない。

【0792】

ここで、前記ＳＹＮＣＤ＿ＭＳＢフィールドがオプションヘッダに含まれる場合には前記オプションヘッダがＢＢフレームに含まれる。

【0793】

前記ＳＴＵＦＦＩフィールドは１ｂｉｔの大きさを有し、ＢＢフレームにStuffingフィールド（または、Stuffing byte）、またはin-band Signalingフィールドが存在するかを示すインジケータをいう。

【0794】

前記チェックサム（Check-sum）フィールドは１ｂｉｔの大きさで、ＢＢフレームヘッダまたはＯＰＴＩＯＮＩフィールドのエラー確認のための用途に使用できる。

【0795】

前記チェックサム（Check-sum）フィールドは、ヘッダがＢＢフレームヘッダ及びオプションヘッダに区分される場合、前記オプションヘッダに含まれることができる。

【0796】

説明したように、前記Stuffingフィールドはスタッフィングヘッダ及びスタッフィングバイトを含む。

【0797】

図４４のＳＹＮＣＤ＿ＬＳＢフィールドと図４３のＰＫＴＳＰＴＲ＿ＬＳＢフィールドは同一な意味として使用できる。

【0798】

ここで、前記ＰＫＴＳＰＴＲ＿ＬＳＢフィールドの大きさは５ｂｉｔｓである一方、本明細書で提案する図４４のＳＹＮＣＤ＿ＬＳＢフィールドの大きさは６ｂｉｔｓで、１ｂｉｔ増加するようになる。

【0799】

即ち、５ｂｉｔｓのＰＫＴＳＰＴＲ＿ＬＳＢフィールドで表現できるＰＫＴＳＰＴＲの長さは最大３１（２^５−１）ｂｙｔｅｓであることに比べて、６ｂｉｔｓのＳＹＮＣＤ＿ＬＳＢフィールドで表現できるＳＹＮＣＤの長さは６３（２^６−１）ｂｙｔｅｓで、約２倍が増加するようになる。

【0800】

即ち、本明細書で提案するＳＹＮＣＤ＿ＬＳＢフィールドの大きさ調節を通じてＳＹＮＣＤ＿ＭＳＢフィールドがヘッダまたはＢＢフレームヘッダまたはオプションヘッダに追加される場合が減るようになって、ＢＢフレームの転送に対するオーバーヘッドを減らすようになる。

【0801】

例えば、１８８ｂｙｔｅのＭＰＥＧ２−ＴＳストリームを転送すると仮定する。

【0802】

（１）図４３のＢＢフレーム構造の場合、１８８ｂｙｔｅのＴＳパケットを転送するためにＢＢフレームヘッダにＰＫＴＳＰＴＲ＿ＬＳＢフィールドのみ含まれる場合（即ち、ＰＫＴＳＰＴＲ長さが３１ｂｙｔｅ以下の値を有する場合）は約１６．４９％（３１ｂｙｔｅ／１８８ｂｙｔｅ）に該当する。

【0803】

即ち、１６．４９％に該当するＢＢフレームは１ｂｙｔｅの大きさを有するヘッダを含み、残りの８３．５１％に該当するＢＢフレームは２ｂｙｔｅの大きさを有するヘッダを含む。

【0804】

ここで、前記ヘッダはペイロードと関連したフォーマットを示し、ＢＢフレームヘッダを意味するか、またはＢＢフレームヘッダ及びオプションヘッダを含む意味でありうる。

【0805】

したがって、平均的にＢＢフレームは１．８３ｂｙｔｅの大きさを有するヘッダを含むようになる。

【0806】

（２）一方、図４４のＢＢフレーム構造の場合、１８８ｂｙｔｅのＴＳパケットを転送するためにＢＢフレームヘッダにＳＹＮＣＤ＿ＬＳＢフィールドのみが含まれる場合（即ち、ＳＹＮＣＤ長さが６３ｂｙｔｅ以下の値を有する場合）は約３３．５１％（６３ｂｙｔｅ／１８８ｂｙｔｅ）に該当する。

【0807】

即ち、３３．５１％に該当するＢＢフレームは１ｂｙｔｅの大きさを有するヘッダを含み、残りの６６．４９％に該当するＢＢフレームは２ｂｙｔｅの大きさを有するヘッダを含む。

【0808】

したがって、平均的にＢＢフレームは１．６６ｂｙｔｅの大きさを有するＢＢフレームヘッダを含むようになることで、図４３のＢＢフレーム構造を有する場合よりＢＢフレーム転送に対するオーバーヘッドを格段に減らすことができることが分かる。

【0809】

また、図４４のＢＢフレーム構造はオプショナルヘッダに含まれる１ｂｉｔをヘッダのチェックサム１ｂｉｔに使用するか、または前記ヘッダに含まれるＯＰＴＩＯＮＩフィールドのチェックサム１bitに使用することによって、ヘッダに対するエラーが検出できる追加機能を遂行することができるようになる。

【0810】

図４５は、本明細書で提案するＢＢフレーム構造の更に他の一例を示す図である。

【0811】

図４５のＢＢフレーム構造は、図４４のＢＢフレーム構造とＳＹＮＣＤ＿ＬＳＢフィールド／ＳＹＮＣＤ＿ＭＳＢフィールドの大きさとＳＴＵＦＦＩフィールドの位置において相異し、他の部分は同一である。

【0812】

以下、図４４のＢＢフレーム構造と同一な部分に対する説明は省略し、差がつく部分を中心に説明する。

【0813】

ＯＰＴＩＯＮＩフィールド及びＳＹＮＣＤ＿ＬＳＢフィールドが合わせられてＢＢフレームヘッダとして定義されることができ、ＳＹＮＣＤ＿ＭＳＢフィールド、ＳＴＵＦＦＩフィールド、及びチェックサムフィールドが合わせられてオプションヘッダとして定義できる。

【0814】

また、ＯＰＴＩＯＮＩフィールド、ＳＹＮＣＤ＿ＬＳＢフィールド、ＳＹＮＣＤ＿ＭＳＢフィールド、ＳＴＵＦＦＩフィールド、Checksumフィールドが合わせられて１つのヘッダとして定義できる。

【0815】

この場合、前記ヘッダをＢＢフレームヘッダとして表現することもできる。

【0816】

更に他の一例として、前記ＳＴＵＦＦＩフィールド及び前記Checksum フィールドは特定フィールドに合わせられることができる。

【0817】

この場合、前記特定フィールドはＢＢフレーム内のStuffingフィールドの存否を示す値として使用できる。

【0818】

前記特定フィールドはＥＸＴ＿Ｉフィールドで表現されることができ、２ｂｉｔの大きさを有することができる。

【0819】

一例に、前記特定フィールド値が（１）‘００’の場合、ＢＢフレーム内のスタッフィングがない場合を示し、（２）‘０１’の場合、ＢＢフレーム内の１ｂｙｔｅのスタッフィングが存在する場合を示し、３）‘１０’の場合、ＢＢフレーム内の２ｂｙｔｅのスタッフィングが存在する場合を示し、（４）‘１１’の場合、ＢＢフレーム内の３ｂｙｔｅ以上のスタッフィングが存在する場合を示すことができる。

【0820】

前記特定フィールド値によって定義できるＳＴＵＦＦ＿ＴＹＰＥフィールド、ＳＴＵＦＦ＿ＬＥＮフィールド、及びその意味に対して一例を挙げて説明する。

【0821】

前記特定フィールド（例：ＥＸＴ＿Ｉフィールド）値が‘００’の場合、スタッフィングがないため、前記ＳＴＵＦＦ＿ＴＹＰＥフィールド及びＳＴＵＦＦ＿ＬＥＮフィールドはスタッフィングフィールドに存在しない。

【0822】

前記特定フィールド値が‘０１’であり、前記ＳＴＵＦＦ＿ＴＹＰＥフィールド値が‘０００’であり、前記ＳＴＵＦＦ＿ＬＥＮフィールド値が‘０００００’の場合、１ｂｙｔｅスタッフィングがＢＢフレーム（または、スタッフィングフィールド）に含まれることを示すことができる。

【0823】

前記特定フィールド値が‘１０’であり、前記ＳＴＵＦＦ＿ＴＹＰＥフィールド値が‘０００’であり、前記ＳＴＵＦＦ＿ＬＥＮフィールド値が‘０００００’の場合、２ｂｙｔｅスタッフィングがＢＢフレーム（または、スタッフィングフィールド）に含まれることを示すことができる。前記特定フィールド値が‘１１’であり、前記ＳＴＵＦＦ＿ＴＹＰＥフィールド値が‘０００’であり、前記ＳＴＵＦＦ＿ＬＥＮフィールド値が‘ｓｔｕｆｆ＿ｌｅｎ’の場合、３ｂｙｔｅ以上のスタッフィングがＢＢフレーム（または、スタッフィングフィールド）に含まれることを示すことができる。

【0824】

前記特定フィールド値が‘１１’であり、前記ＳＴＵＦＦ＿ＴＹＰＥフィールド値が‘００１’であり、前記ＳＴＵＦＦ＿ＬＥＮフィールド値が‘ｓｔｕｆｆ＿ｌｅｎ’の場合、スタッフィングとインバンドＡシグナリングがＢＢフレーム（または、スタッフィングフィールド）に含まれることを示すことができる。

【0825】

前記インバンドＡはＩＮＢＡＮＤ＿ＩＳＳＹでありうる。

【0826】

前記特定フィールド値が‘１１’であり、前記ＳＴＵＦＦ＿ＴＹＰＥフィールド値が‘０１０’であり、前記ＳＴＵＦＦ＿ＬＥＮフィールド値が‘ｓｔｕｆｆ＿ｌｅｎ’の場合、スタッフィングとインバンドＢシグナリングがＢＢフレーム（または、スタッフィングフィールド）に含まれることを示すことができる。

【0827】

前記インバンドＢはＩＮＢＡＮＤ＿ＳＩＧでありうる。

【0828】

前記特定フィールド値が‘１１’であり、前記ＳＴＵＦＦ＿ＴＹＰＥフィールド値が‘１１１’であり、前記ＳＴＵＦＦ＿ＬＥＮフィールド値が‘ｓｔｕｆｆ＿ｌｅｎ’の場合、スタッフィング及び他の情報がＢＢフレーム（または、スタッフィングフィールド）に含まれることを示すことができる。

【0829】

また、前記ＳＴＵＦＦ＿ＬＥＮフィールド値はＳＴＵＦＦ＿ＬＥＮ＿ＬＳＢフィールド（５ｂｉｔ）値とＳＴＵＦＦ＿ＬＥＮ＿ＭＳＢフィールド（８ｂｉｔ）値に区分できる。

【0830】

更に他の一例として、前記特定フィールド値が‘０１’であり、前記ＳＴＵＦＦ＿ＴＹＰＥフィールド値が‘０００’であり、前記ＳＴＵＦＦ＿ＬＥＮ＿ＬＳＢフィールド値が‘０００００’であり、前記ＳＴＵＦＦ＿ＬＥＮ＿ＭＳＢフィールド値が‘Not exist’の場合、１ｂｙｔｅスタッフィングがＢＢフレーム（または、スタッフィングフィールド）に含まれることを示すことができる。

【0831】

前記特定フィールド値が‘１０’であり、前記ＳＴＵＦＦ＿ＴＹＰＥフィールド値が‘０００’であり、前記ＳＴＵＦＦ＿ＬＥＮ＿ＬＳＢフィールド値が‘０００００’であり、前記ＳＴＵＦＦ＿ＬＥＮ＿ＭＳＢフィールド値が‘００００００００’の場合、２ｂｙｔｅスタッフィングがＢＢフレーム（または、スタッフィングフィールド）に含まれることを示すことができる。

【0832】

前記特定フィールド値が‘１１’であり、前記ＳＴＵＦＦ＿ＴＹＰＥフィールド値が‘０００’であり、前記ＳＴＵＦＦ＿ＬＥＮ＿ＬＳＢフィールド値が‘ｓｔｕｆｆ＿ｌｅｎ＿ｌｓｂ’であり、前記ＳＴＵＦＦ＿ＬＥＮ＿ＭＳＢフィールド値が‘ｓｔｕｆｆ＿ｌｅｎ＿ｍｓｂ’の場合、３ｂｙｔｅ以上のスタッフィングがＢＢフレーム（または、スタッフィングフィールド）に含まれることを示すことができる。

【0833】

前記特定フィールド値が‘１１’であり、前記ＳＴＵＦＦ＿ＴＹＰＥフィールド値が‘００１’であり、前記ＳＴＵＦＦ＿ＬＥＮ＿ＬＳＢフィールド値が‘ｓｔｕｆｆ＿ｌｅｎ＿ｌｓｂ’であり、前記ＳＴＵＦＦ＿ＬＥＮ＿ＭＳＢフィールド値が‘Not exist’ の場合、インバンドＡシグナリングのみＢＢフレーム（または、スタッフィングフィールド）に含まれることを示すことができる。前記インバンドＡシグナリングのみスタッフィングフィールドに含まれる場合は、前記インバンドＡシグナリングが３２ｂｙｔｅで表現可能な場合のみに使用することが好ましい。前記インバンドＡはＩＮＢＡＮＤ＿ＩＳＳＹでありうる。

【0834】

前記特定フィールド値が‘１１’であり、前記ＳＴＵＦＦ＿ＴＹＰＥフィールド値が‘０１０’であり、前記ＳＴＵＦＦ＿ＬＥＮ＿ＬＳＢフィールド値が‘ｓｔｕｆｆ＿ｌｅｎ＿ｌｓｂ’であり、前記ＳＴＵＦＦ＿ＬＥＮ＿ＭＳＢフィールド値が‘ｓｔｕｆｆ＿ｌｅｎ＿ｍｓｂ’の場合、スタッフィングとインバンドＡシグナリングがＢＢフレーム（または、スタッフィングフィールド）に含まれることを示すことができる。

【0835】

前記特定フィールド値が‘１１’であり、前記ＳＴＵＦＦ＿ＴＹＰＥフィールド値が‘１１１’であり、前記ＳＴＵＦＦ＿ＬＥＮ＿ＬＳＢフィールド値が‘ｓｔｕｆｆ＿ｌｅｎ＿ｌｓｂ’であり、前記ＳＴＵＦＦ＿ＬＥＮ＿ＭＳＢフィールド値が‘ｓｔｕｆｆ＿ｌｅｎ＿ｍｓｂ’の場合、スタッフィング及び他の情報がＢＢフレーム（または、スタッフィングフィールド）に含まれることを示すことができる。

【0836】

図４５に示すように、前記ＳＹＮＣＤ＿ＬＳＢフィールドの大きさは７ｂｉｔであり、前記ＳＹＮＣＤ＿ＭＳＢフィールドの大きさは６ｂｉｔである。

【0837】

図４５のように、前記ＳＹＮＣＤ＿ＬＳＢフィールドの大きさが７ｂｉｔの場合、より多い数のＳＹＮＣＤの長さを表現できるようになる。

【0838】

即ち、前記ＳＹＮＣＤ＿ＬＳＢフィールドの大きさが７ｂｉｔの場合、表現できるＳＹＣＮＤの長さは１２７（２^７−１）ｂｙｔｅであって、図４４の場合（３１ｂｙｔｅ）より約４倍増加するようになる。

【0839】

同様に、１８８ｂｙｔｅのＭＰＥＧ２−ＴＳストリームを転送すると仮定する。

【0840】

図４５のＢＢフレーム構造の場合、１８８ｂｙｔｅのＴＳパケットを転送するためにヘッダにＳＹＮＣＤ＿ＬＳＢフィールドのみ含まれる場合（即ち、ＳＹＮＣＤ長さが１２７ｂｙｔｅ以下の値を有する場合）は、約６７．５５％１２７ｂｙｔｅ／１８８ｂｙｔｅ）に該当する。

【0841】

即ち、６７．５５％に該当するＢＢフレームは１ｂｙｔｅの大きさを有するヘッダを含み、残りの３２．４５％に該当するＢＢフレームは２ｂｙｔｅの大きさを有するヘッダを含む。

【0842】

したがって、平均的にＢＢフレームは１．３２ｂｙｔｅの大きさを有するヘッダを含むようになって、図４３及び図４４のＢＢフレーム構造を有する場合よりＢＢフレーム転送に対するオーバーヘッドを格段に減らすことができるようになる。

【0843】

図４５のＢＢフレーム構造でも同様に、ヘッダに存在する余分の１ｂｉｔをチェックサムに活用することによって（ヘッダのチェックサム１ビットに使用するか、またはＯＰＴＩＯＮＩフィールドのチェックサムに使用）、ヘッダに対するエラー確認を追加的に遂行できるようになる。

【0844】

本発明の思想や範囲を逸脱することなく、本発明で多様な変更及び変形が可能であることは当業者に理解できる。したがって、本発明は添付した請求項及びその同等範囲内で提供される本発明の変更及び変形を含むことと意図される。

【0845】

本明細書で装置及び方法発明が全て言及され、装置及び方法発明の全ての説明は互いに補完して適用できる。

【符号の説明】

【0846】

１０００ インプットフォーマットブロック
１０１０ ＢＩＣＭブロック
１０２０ フレームビルディングブロック
１０３０ ＯＦＤＭジェネレーションブロック
１０４０ シグナリング生成ブロック

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】

【図10】

【図11】

【図12】

【図13】

【図14】

【図15】

【図16】

【図17】

【図18】

【図19】

【図20】

【図21】

【図22】

【図23】

【図24】

【図25】

【図26】

【図27】

【図28a】

【図28b】

【図28c】

【図28d】

【図29】

【図30a】

【図30b】

【図31a】

【図31b】

【図31c】

【図31d】

【図32a】

【図32b】

【図32c】

【図32d】

【図33】

【図34】

【図35】

【図36】

【図37】

【図38】

【図39】

【図40】

【図41】

【図42】

【図43】

【図44】

【図45】