JP2018504070A - 放送信号送信装置、放送信号受信装置、放送信号送信方法、及び放送信号受信方法 - Google Patents

放送信号送信装置、放送信号受信装置、放送信号送信方法、及び放送信号受信方法 Download PDF

Info

Publication number
JP2018504070A
JP2018504070A JP2017543676A JP2017543676A JP2018504070A JP 2018504070 A JP2018504070 A JP 2018504070A JP 2017543676 A JP2017543676 A JP 2017543676A JP 2017543676 A JP2017543676 A JP 2017543676A JP 2018504070 A JP2018504070 A JP 2018504070A
Authority
JP
Japan
Prior art keywords
field
stuffing
data
frame
block
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Granted
Application number
JP2017543676A
Other languages
English (en)
Other versions
JP6392463B2 (ja
Inventor
チェホ ファン
チェホ ファン
ウソク コ
ウソク コ
ソンリョン ホン
ソンリョン ホン
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
LG Electronics Inc
Original Assignee
LG Electronics Inc
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by LG Electronics Inc filed Critical LG Electronics Inc
Publication of JP2018504070A publication Critical patent/JP2018504070A/ja
Application granted granted Critical
Publication of JP6392463B2 publication Critical patent/JP6392463B2/ja
Expired - Fee Related legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L27/00—Modulated-carrier systems
    • H04L27/26—Systems using multi-frequency codes
    • H04L27/2601—Multicarrier modulation systems
    • H04L27/2602—Signal structure
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L27/00—Modulated-carrier systems
    • H04L27/26—Systems using multi-frequency codes
    • H04L27/2601—Multicarrier modulation systems
    • H04L27/2626—Arrangements specific to the transmitter only
    • H04L27/2627—Modulators
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L1/00—Arrangements for detecting or preventing errors in the information received
    • H04L1/0001—Systems modifying transmission characteristics according to link quality, e.g. power backoff
    • H04L1/0006—Systems modifying transmission characteristics according to link quality, e.g. power backoff by adapting the transmission format
    • H04L1/0007—Systems modifying transmission characteristics according to link quality, e.g. power backoff by adapting the transmission format by modifying the frame length
    • H04L1/0008—Systems modifying transmission characteristics according to link quality, e.g. power backoff by adapting the transmission format by modifying the frame length by supplementing frame payload, e.g. with padding bits
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L1/00—Arrangements for detecting or preventing errors in the information received
    • H04L1/0078—Avoidance of errors by organising the transmitted data in a format specifically designed to deal with errors, e.g. location
    • H04L1/0083—Formatting with frames or packets; Protocol or part of protocol for error control
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L5/00—Arrangements affording multiple use of the transmission path
    • H04L5/0001—Arrangements for dividing the transmission path
    • H04L5/0003—Two-dimensional division
    • H04L5/0005—Time-frequency
    • H04L5/0007—Time-frequency the frequencies being orthogonal, e.g. OFDM(A), DMT
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L5/00—Arrangements affording multiple use of the transmission path
    • H04L5/003—Arrangements for allocating sub-channels of the transmission path
    • H04L5/0053—Allocation of signaling, i.e. of overhead other than pilot signals
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/80—Responding to QoS
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/23—Processing of content or additional data; Elementary server operations; Server middleware
    • H04N21/236—Assembling of a multiplex stream, e.g. transport stream, by combining a video stream with other content or additional data, e.g. inserting a URL [Uniform Resource Locator] into a video stream, multiplexing software data into a video stream; Remultiplexing of multiplex streams; Insertion of stuffing bits into the multiplex stream, e.g. to obtain a constant bit-rate; Assembling of a packetised elementary stream
    • H04N21/23611—Insertion of stuffing data into a multiplex stream, e.g. to obtain a constant bitrate
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L1/00—Arrangements for detecting or preventing errors in the information received
    • H04L2001/0092—Error control systems characterised by the topology of the transmission link
    • H04L2001/0093—Point-to-multipoint

Landscapes

  • Engineering & Computer Science (AREA)
  • Signal Processing (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Multimedia (AREA)
  • Quality & Reliability (AREA)
  • Two-Way Televisions, Distribution Of Moving Picture Or The Like (AREA)
  • Error Detection And Correction (AREA)

Abstract

本明細書は、放送信号を受信するための方法において、少なくとも１つの信号フレームを含む放送信号を受信するステップと、前記受信された放送信号をＯＦＤＭ方式によってデータ復調を行うステップと、サービスデータまたはサービスコンポーネントデータを抽出するために、前記受信された放送信号に含まれた前記少なくとも１つの信号フレームをパーシングするステップと、前記サービスデータまたはサービスコンポーネントデータをビットに変換するステップと、前記変換されたビットをデコーディングするステップと、前記デコーディングされたビットを含むデータストリームを出力するステップとを含むことを特徴とする【選択図】図４８

Description

本発明は、放送信号送信装置、放送信号受信装置、及び放送信号送受信方法に関するものである。
アナログ放送信号送信が終了するにつれて、ディジタル放送信号を送受信するための様々な技術が開発されている。ディジタル放送信号はアナログ放送信号に比べてより多い量のビデオ／オーディオデータを含むことができ、ビデオ／オーディオデータだけでなく、様々な種類の付加データをさらに含むことができる。
即ち、ディジタル放送システムはＨＤ（High Definition）イメージ、マルチャネル（multichannel、多チャネル）オーディオ、及び様々な付加サービスを提供することができる。しかしながら、ディジタル放送のためには、多量のデータ送信に対するデータ送信効率、送受信ネットワークの堅固性（robustness）、及びモバイル受信装置を考慮したネットワーク柔軟性（flexibility）が向上しなければならない。
また、本発明は、ＢＢＦ内にＳｔｕｆｆｉｎｇ ｆｉｅｌｄの存在有無をシグナリングするための方法を提供することに目的がある。
また、本発明は、ＢＢＦ内に存在するＳｔｕｆｆｉｎｇ ｆｉｅｌｄ、すなわち、Ｓｔｕｆｆｉｎｇデータの使用Ｔｙｐｅを指定するための方法を提供することに目的がある。
また、本発明は、Ｓｔｕｆｆｉｎｇ Ｔｙｐｅフィールドを２種類の互いに異なるフィールドに分割して用いることにより、Ｓｔｕｆｆｉｎｇ Ｔｙｐｅフィールドの効率的な利用を提供することに目的が ある。
本明細書においてなそうとする技術的課題は、以上で言及した技術的課題に制限されず、言及していないさらに他の技術的課題は、下記の記載から本発明の属する技術分野における通常の知識を有する者に 明確に理解され得るであろう。
本明細書は、放送信号を受信するための方法において、少なくとも１つの信号フレームを含む放送信号を受信するステップと、前記受信された放送信号をＯＦＤＭ（Ｏｒｔｈｏｇｏｎａｌ Ｆｒｅｑｕｅｎｃｙ Ｄｉｖｉｓｉｏｎ Ｍｕｌｔｉｐｌｅｘｉｎｇ）方式によってデータ復調を行うステップと、サービスデータ（ｓｅｒｖｉｃｅ ｄａｔａ）またはサービスコンポーネントデータ（ｓｅｒｖｉｃｅ ｃｏｍｐｏｎｅｎｔ ｄａｔａ）を抽出するために、前記受信された放送信号に含まれた前記少なくとも１つの信号フレームをパーシング（Ｐａｒｓｉｎｇ）するステップと、前記サービスデータ（ｓｅｒｖｉｃｅ ｄａｔａ）またはサービスコンポーネントデータ（ｓｅｒｖｉｃｅ ｃｏｍｐｏｎｅｎｔ ｄａｔａ）をビットに変換するステップと、前記変換されたビットをデコーディング（ｄｅｃｏｄｉｎｇ）するステップと、前記デコーディングされたビットを含むデータストリームを出力するステップとを含み、前記出力するステップは、ベースバンドフレーム（Ｂａｓｅｂａｎｄ Ｆｒａｍｅ）のヘッダに含まれた情報をディテクティング（ｄｅｔｅｃｔｉｎｇ）または取得（ｏｂｔａｉｎｉｎｇ）するステップを含み、前記ＢＢＦは、スタッフィング（Ｓｔｕｆｆｉｎｇ）フィールドが前記ヘッダに存在するか否かを表す制御情報を含むことを特徴とする。
また、本明細書において前記制御情報は、前記ヘッダに含まれることを特徴とする。
また、本明細書において前記ヘッダは、スタッフィング長さのＭＳＢ（Ｍｏｓｔ Ｓｉｇｎｉｆｉｃａｎｔ Ｂｉｔ）ｐａｒｔが前記スタッフィング（Ｓｔｕｆｆｉｎｇ）フィールドに存在するか否かを表す指示情報またはスタッフィングデータのタイプを表すスタッフィングタイプ（ＳＴＵＦＦ＿ＴＹＰＥ）フィールドのうち、少なくとも１つを含むことを特徴とする。
また、本明細書において前記スタッフィングフィールドは、スタッフィングヘッダ（Ｓｔｕｆｆｉｎｇ Ｈｅａｄｅｒ）及びスタッフィングデータ（Ｓｔｕｆｆｉｎｇ Ｄａｔａ）を含み、前記指示情報及び前記スタッフィングタイプフィールドは、前記スタッフィングヘッダに含まれることを特徴とする。
また、本明細書において前記指示情報の大きさは、１ｂｉｔであり、前記スタッフィングタイプ（ＳＴＵＦＦ＿ＴＹＰＥ）フィールドは、２ｂｉｔｓであることを特徴とする。
また、本明細書において前記スタッフィングヘッダは、前記スタッフィングフィールドの長さを表すスタッフィング長さ（ＳＴＵＦＦ＿ＬＥＮ）フィールドをさらに含み、前記スタッフィング長さ（ＳＴＵＦＦ＿ＬＥＮ）フィールドは、スタッフィング長さのＭＳＢ（ＳＴＵＦＦ＿ＬＥＮ＿ＭＳＢ）ｐａｒｔ及びスタッフィング長さのＬＳＢ（ＳＴＵＦＦ＿ＬＥＮ＿ＬＳＢ）ｐａｒｔに区分されることを特徴とする。
また、本明細書において前記制御情報は、ＥＸＴ＿Ｉ（Ｅｘｔｅｎｓｉｏｎ Ｉｎｄｉｃａｔｏｒ）フィールドであり、前記指示情報は、ＭＳＢ＿Ｉ（Ｉｎｄｉｃａｔｏｒ）フィールドであることを特徴とする。
また、本明細書において前記スタッフィングフィールドは、前記ペイロードにデータパケットが満たされないか、またはｉｎ−ｂａｎｄ ｓｉｇｎａｌｉｎｇが使用される場合、前記ベースバンドフレームに含まれることを特徴とする。
また、本明細書において前記スタッフィングデータは、スタッフィングまたはｉｎ−ｂａｎｄ ｓｉｇｎａｌｉｎｇのうち、少なくとも１つを表すことを特徴とする。
また、本明細書は、前記スタッフィングフィールドの長さが３２ｂｙｔｅｓ(バイト)以下である場合、前記スタッフィング長さのＭＳＢ（Ｌｅａｓｔ Ｓｉｇｎｉｆｉｃａｎｔ Ｂｉｔ）ｐａｒｔは、前記スタッフィングフィールドに含まれないことを特徴とする。
また、本明細書は、放送信号を受信するための受信装置において、少なくとも１つの信号フレームを含む放送信号を受信するための受信機（ｒｅｃｅｉｖｅｒ）と、前記受信された放送信号をＯＦＤＭ（Ｏｒｔｈｏｇｏｎａｌ Ｆｒｅｑｕｅｎｃｙ Ｄｉｖｉｓｉｏｎ Ｍｕｌｔｉｐｌｅｘｉｎｇ）方式によってデータを復調するための復調器（ｄｅｍｏｄｕｌａｔｏｒ）と、サービスデータ（ｓｅｒｖｉｃｅ ｄａｔａ）またはサービスコンポーネントデータ（ｓｅｒｖｉｃｅ ｃｏｍｐｏｎｅｎｔ ｄａｔａ）を抽出するために、前記受信された放送信号に含まれた前記少なくとも１つの信号フレームをパーシング（Ｐａｒｓｉｎｇ）するためのフレームパーサ（ｆｒａｍｅ ｐａｒｓｅｒ）と、前記サービスデータ（ｓｅｒｖｉｃｅ ｄａｔａ）またはサービスコンポーネントデータ（ｓｅｒｖｉｃｅ ｃｏｍｐｏｎｅｎｔ ｄａｔａ）をビットに変換するための変換器（ｃｏｎｖｅｒｔｅｒ）と、前記変換されたビットをデコーディング（ｄｅｃｏｄｉｎｇ）するためのデコーダ（ｄｅｃｏｄｅｒ）と、前記デコーディングされたビットを含むデータストリームを出力するためのアウトプットプロセッサ（ｏｕｔｐｕｔ ｐｒｏｃｅｓｓｏｒ）とを備え、前記アウトプットプロセッサは、ベースバンドフレーム（Ｂａｓｅｂａｎｄ Ｆｒａｍｅ）のヘッダに含まれた情報をディテクティング（検出）（ｄｅｔｅｃｔｉｎｇ）または取得（ｏｂｔａｉｎｉｎｇ）するためのベースバンドフレームプロセッサ（ｂａｓｅｂａｎｄ ｆｒａｍｅ ｐｒｏｃｅｓｓｏｒ）を含み、前記ＢＢＦは、スタッフィング（Ｓｔｕｆｆｉｎｇ）フィールドが前記ヘッダに存在するか否かを表す制御情報を含むことを特徴とする。
本発明は、サービス特性によってデータを処理し、各サービスまたはサービスコンポーネントに対するＱｏＳ（Ｑｕａｌｉｔｙ ｏｆ Ｓｅｒｖｉｃｅ）を制御することにより、様々な放送サービスを提供できる。
また、本発明は、同じＲＦ（ｒａｄｉｏ ｆｒｅｑｕｅｎｃｙ）信号帯域幅を介して様々な放送サービスを送信することにより、送信柔軟性（ｆｌｅｘｉｂｉｌｉｔｙ）を達成できる。
また、本発明は、ＭＩＭＯ（Ｍｕｌｔｉｐｌｅ−Ｉｎｐｕｔ Ｍｕｌｔｉｐｌｅ−Ｏｕｔｐｕｔ）システムを利用してデータ送信効率及び放送信号の送受信堅固性（Ｒｏｂｕｓｔｎｅｓｓ）を向上させることができる。
また、本発明によれば、モバイル受信装置を使用するか、室内環境にあっても、エラー無しでデジタル放送信号を受信できる放送信号送信及び受信方法及び装置を提供できる。
また、本発明は、ＢＢＦ内にＳｔｕｆｆｉｎｇ ｆｉｅｌｄの存在有無を表す新しいフィールドを定義することにより、ＢＢＦ内にＳｔｕｆｆｉｎｇ ｆｉｅｌｄが存在するか否かを速くかつ正確に分かることができるという効果がある。
また、本発明は、ＢＢＦ内に存在するＳｔｕｆｆｉｎｇ ｆｉｅｌｄ、すなわち、Ｓｔｕｆｆｉｎｇデータの使用Ｔｙｐｅを定義することにより、Ｓｔｕｆｆｉｎｇ ｆｉｅｌｄにＳｔｕｆｆｉｎｇ以外に、他の情報を使用させることができるという効果がある。
また、本発明は、Ｓｔｕｆｆｉｎｇ Ｔｙｐｅフィールドを２種類の互いに異なるフィールドに分割して用いることにより、Ｓｔｕｆｆｉｎｇ Ｔｙｐｅフィールドを効率的に運営することができるという効果がある。
本明細書において得ることができる効果は、以上で言及した効果に制限されず、言及していないさらに他の効果は、下記の記載から本発明の属する技術分野における通常の知識を有する者に明確に理解され得るであろう。
本発明に対してさらに理解するために含まれて、本出願に含まれて、その一部を構成する添付の図面は本発明の原理を説明する詳細な説明と共に本発明の実施形態を示す。
本発明の一実施形態に係る次世代放送サービスに対する放送信号送信装置の構造を示す。 本発明の一実施形態に係るインプットフォーマッティング（Input formatting：入力フォーマット）ブロックを示す。 本発明の他の一実施形態に係るインプットフォーマッティング（Input formatting：入力フォーマット）ブロックを示す。 本発明の他の一実施形態に係るインプットフォーマッティング（Input formatting：入力フォーマット）ブロックを示す。 本発明の一実施形態に係るＢＩＣＭ（bit interleaved coding & modulation）ブロックを示す。 本発明の他の一実施形態に係るＢＩＣＭブロックを示す。 本発明の一実施形態に係るフレームビルディング（Frame Building：フレーム生成）ブロックを示す。 本発明の一実施形態に係るＯＦＤＭ（orthogonal frequency division multiplexing）ジェネレーション（generation：生成）ブロックを示す。 本発明の一実施形態に係る次世代放送サービスに対する放送信号受信装置の構造を示す。 本発明の一実施形態に係るフレーム構造を示す。 本発明の一実施形態に係るフレームのシグナリング階層構造を示す。 本発明の一実施形態に係るプリアンブルシグナリングデータを示す。 本発明の一実施形態に係るＰＬＳ１データを示す。 本発明の一実施形態に係るＰＬＳ２データを示す。 本発明の他の一実施形態に係るＰＬＳ２データを示す。 本発明の一実施形態に係るフレームのロジカル（logical：論理）構造を示す。 本発明の一実施形態に係るＰＬＳ（physical layer signaling）マッピングを示す。 本発明の一実施形態に係るＥＡＣ（emergency alert channel）マッピングを示す。 本発明の一実施形態に係るＦＩＣ（fast information channel）マッピングを示す。 本発明の一実施形態に係るＤＰ（data pipe：データパイプ）のタイプを示す。 本発明の一実施形態に係るＤＰ（data pipe：データパイプ）マッピングを示す。 本発明の一実施形態に係るＦＥＣ（forward error correction）構造を示す。 本発明の一実施形態に係るビットインターリービングを示す。 本発明の一実施形態に係るセル−ワードデマルチプレキシングを示す。 本発明の一実施形態に係る時間インターリービングを示す。 本発明の一実施形態に係るツイストされた行−列ブロックインターリーバの基本動作を示す。 本発明の他の一実施形態に係るツイストされた行−列ブロックインターリーバの動作を示す。 本発明の一実施形態に係るツイストされた行−列ブロックインターリーバの対角線方向リードパターンを示す。 本発明の一実施形態に係る各インターリービングアレイ（ａｒｒａｙ）からインターリービングされたＸＦＥＣＢＬＯＣＫを示す。 図９の同期及び復調（synchronization & demodulation）モジュールの一例を示す図である。 図９のフレームパーシングモジュールの一例を示す図である。 図９のデマッピング及びデコーディング（demapping & decoding）モジュールの一例を示す図である。 図９のアウトプットプロセッサ（output processor）の一例を示す図である。 図９のアウトプットプロセッサの更に他の一例を示す図である。 本発明の他の実施形態に係るコーディングアンドモジュレーションモジュールを示す図である。 本発明の他の実施形態に係るデマッピング及びデコーディングモジュールを示す図である。 本明細書で提案するモードアダプテーションモジュールの一例を示す図である。 本明細書で提案するアウトプットプロセッサの一例を示す図である。 従来のＢＢフレーム構造の一例を示す図である。 従来のＢＢフレーム構造の更に他の一例を示す図である。 従来のＢＢフレーム構造の更に他の一例を示す図である。 本明細書で提案するＢＢフレーム構造の一例を示す。 本明細書で提案するＢＢフレーム構造の更に他の一例を示す図である。 本明細書で提案するＢＢフレーム構造の更に他の一例を示す図である。 本明細書で提案するＢＢフレーム構造の更に他の一例を示す図である。 様々なＢＢフレーム構造でＢＢフレーム送信に対するオーバーヘッドを計算した結果を比較して示す図である。 従来のＢＢフレーム構造の一例を示す。 本明細書で提案するＢＢフレーム構造の一例を示す図である。 本明細書で提案するＢＢフレーム構造の更に他の一例を示す図である。 本明細書で提案するＢＢフレーム構造の更に他の一例を示す図である。 本明細書で提案するＢＢフレーム構造の更に他の一例を示す図である。 本明細書で提案する放送信号の送信方法の一例を示す順序図である。 本明細書で提案する放送信号の受信方法の一例を示す順序図である。
本発明の好ましい実施形態に対して具体的に説明し、その例は添付した図面に示す。添付した図面を参照した以下の詳細な説明は、本発明の実施形態によって具現できる実施形態のみを示すよりは、本発明の好ましい実施形態を説明するためのものである。次の詳細な説明は、本発明に対する徹底した理解を提供するために細部事項を含む。しかしながら、本発明がこのような細部事項無しで実行できるということは当業者に自明である。
本発明で使用される大部分の用語は該当分野で広く使用される一般的なものから選択されるが、一部の用語は出願人により任意に選択され、その意味は必要によって次の説明で詳細に叙述する。したがって、本発明は用語の単純な名称や意味でない用語の意図した意味に基づいて理解されなければならない。
本発明は、次世代放送サービスに対する放送信号送信及び受信装置、及び方法を提供する。本発明の一実施形態に係る次世代放送サービスは、地上波放送サービス、モバイル放送サービス、ＵＨＤＴＶサービスなどを含む。本発明は一実施形態に従って非−ＭＩＭＯ（non-Multiple Input Multiple Output）またはＭＩＭＯ方式により次世代放送サービスに対する放送信号を処理することができる。本発明の一実施形態に係る非−ＭＩＭＯ方式は、ＭＩＳＯ（Multiple Input Single Output）方式、ＳＩＳＯ（Single Input Single Output）方式などを含むことができる。
以下、説明の便宜のためにＭＩＳＯまたはＭＩＭＯ方式は２つのアンテナを使用するが、本発明は２つ以上のアンテナを使用するシステムに適用できる。本発明は、特定用途に要求される性能を達成し、かつ受信機の複雑度を最小化するために最適化した３個のフィジカルプロファイル（PHY profile）（ベース（base）、ハンドヘルド（handheld）、アドバンス（advanced）プロファイル）を定義することができる。フィジカルプロファイルは、該当する受信機が具現しなければならない全ての構造のサブセットである。
３個のフィジカルプロファイルは大部分の機能ブロックを共有するが、特定ブロック及び／又はパラメータでは若干異なる。今後に追加でフィジカルプロファイルが定義できる。システムの発展のために、フューチャープロファイルはＦＥＦ（future extension frame）を通じて単一ＲＦ（radio frequency）チャネルに存在するプロファイルとマルチプレキシングされることもできる。各フィジカルプロファイルに対する詳細な内容は後述する。
１．ベースプロファイル
ベースプロファイルは主にルーフトップ（roof-top）アンテナと連結される固定された受信装置の主な用途を示す。ベースプロファイルはある場所に移動できるが、比較的停止した受信範疇に属する携帯用装置も含むことができる。ベースプロファイルの用途は若干の改善された実行によりハンドヘルド装置または車両用に拡張できるが、このような使用用途はベースプロファイル受信機動作では期待されない。
受信のターゲット信号対雑音比の範囲は略１０乃至２０ｄＢであるが、これは既存の放送システム（例えば、ＡＴＳＣ Ａ／５３）の１５ｄＢ信号対雑音比の受信能力を含む。受信機複雑度及び消費電力はハンドヘルドプロファイルを使用するバッテリーで駆動されるハンドヘルド装置ほど重要でない。ベースプロファイルに対する重要システムパラメータが以下の＜表１＞に記載されている。
Figure 2018504070
２．ハンドヘルドプロファイル
ハンドヘルドプロファイルは、バッテリー電源で駆動されるハンドヘルド及び車両用装置における使用のために設計される。該当装置は歩行者または車両速度で移動することができる。受信機複雑度だけでなく、消費電力はハンドヘルドプロファイルの装置の具現のために非常に重要である。ハンドヘルドプロファイルのターゲット信号対雑音比の範囲は略０乃至１０ｄＢであるが、より低い室内受信のために意図された場合、０ｄＢ以下に達するように設定できる。
低信号対雑音比の能力だけでなく、受信機移動性により表れたドップラー効果に対する復原力はハンドヘルドプロファイルの最も重要な性能属性である。ハンドヘルドプロファイルに対する重要システムパラメータが以下の＜表２＞に記載されている。
Figure 2018504070
３．アドバンスプロファイル
アドバンスプロファイルは、より大きい実行複雑度に対する代価としてより高いチャネル能力を提供する。該当プロファイルはＭＩＭＯ送信及び受信を使用することを要求し、ＵＨＤＴＶサービスはターゲット用途であり、このために該当プロファイルが特別に設計される。向上した能力は与えられた帯域幅でサービス数の増加、例えば、複数のＳＤＴＶまたはＨＤＴＶサービスを許容することにも使用できる。
アドバンスプロファイルのターゲット信号対雑音比の範囲は略２０乃至３０ｄＢである。ＭＩＭＯ送信は初期には既存の楕円分極送信装備を使用し、その後に全出力交差分極送信に拡張できる。アドバンスプロファイルに対する重要システムパラメータが以下の＜表３＞に記載されている。
Figure 2018504070
この場合、ベースプロファイルは地上波放送サービス及びモバイル放送サービスの全てに対するプロファイルに使用できる。即ち、ベースプロファイルはモバイルプロファイルを含むプロファイルの概念を定義するために使用できる。また、アドバンスプロファイルはＭＩＭＯを有するベースプロファイルに対するアドバンスプロファイル及びＭＩＭＯを有するハンドヘルドプロファイルに対するアドバンスプロファイルに区分できる。そして、該当３個のプロファイルは設計者の意図によって変更できる。
次の用語及び定義は本発明に適用できる。次の用語及び定義は設計によって変更できる。
補助ストリーム：フューチャーエクステンション（future extension：今後拡張）または放送社やネットワーク運営者により要求されるにつれて、使用できる未だ定義されていない変調及びコーディングのデータを伝達するセルのシーケンス
ベースデータパイプ（base data pipe）：サービスシグナリングデータを伝達するデータパイプ
ベースバンドフレーム（または、BB FRAME）：１つのＦＥＣエンコーディング過程（ＢＣＨ及びＬＤＰＣエンコーディング）に対する入力を形成するＫｂｃｈビットの集合
セル（cell）：ＯＦＤＭ送信の１つのキャリアにより伝達される変調値
コーディングブロック（coded block）：ＰＬＳ１データのＬＤＰＣエンコーディングされたブロックまたはＰＬＳ２データのＬＤＰＣエンコーディングされたブロックのうちの１つ
データパイプ（data pipe）：１つまたは複数のサービスまたはサービスコンポーネントを伝達することができるサービスデータ、または関連したメタデータを伝達する物理階層（physical layer）におけるロジカルチャネル
また、データパイプは、データ送信チャネルで表現されることができる。
データパイプユニット（ＤＰＵ：data pipe unit）：データセルをフレームでのデータパイプに割り当てることができる基本ユニット
データシンボル（data symbol）：プリアンブルシンボルでないフレームでのＯＦＤＭシンボル（フレームシグナリングシンボル及びフレームエッジ（edge）シンボルはデータシンボルに含まれる。）
ＤＰ＿ＩＤ：該当８ビットフィールドはＳＹＳＴＥＭ＿ＩＤにより識別されたシステム内でデータパイプを唯一に識別する。
ダミーセル（dummy cell）：ＰＬＳ（physical layer signaling）シグナリング、データパイプ、または補助ストリームのために使われず残っている容量を詰めることに使用される疑似ランダム値を伝達するセル
ＦＡＣ（emergency alert channel：非常警報チャネル）：ＥＡＳ情報データを伝達するフレームのうちの一部
フレーム（frame）：プリアンブルで始めて、フレームエッジシンボルで終了する物理階層（physical layer）タイムスロット
フレームレピティションユニット（frame repetition unit：フレーム反復単位）：スーパーフレーム（super-frame）で８回反復されるＦＥＦを含む同一または異なるフィジカルプロファイルに属するフレームの集合
ＦＩＣ（fast information channel：高速情報チャネル）：サービスと該当ベースデータパイプとの間でのマッピング情報を伝達するフレームにおけるロジカルチャネル
ＦＥＣＢＬＯＣＫ：データパイプデータのＬＤＰＣエンコーディングされたビットの集合
ＦＦＴサイズ：基本周期Ｔのサイクルで表現されたアクティブシンボル周期Ｔｓと同一な特定モードに使用される名目上のＦＦＴサイズ
フレームシグナリングシンボル（frame signaling symbol）：ＰＬＳデータの一部を伝達する、ＦＦＴサイズ、ガードインターバル（guard interval）、及びスキャッタ（scattered）パイロットパターンの特定組合せにおけるフレームの開始で使用されるより高いパイロット密度を有するＯＦＤＭシンボル
フレームエッジシンボル（frame edge symbol）：ＦＦＴサイズ、ガードインターバル、及びスキャッタパイロットパターンの特定組合せにおけるフレームの端で使用される、より高いパイロット密度を有するＯＦＤＭシンボル
フレームグルーフ（frame-group）：スーパーフレームで同一のフィジカルプロファイルタイプを有する全てのフレームの集合
フューチャーエクステンションフレーム（future extention frame：今後拡張フレーム）：プリアンブルで始める、今後拡張に使用できるスーパーフレーム内で物理階層（physical layer）タイムスロット
フューチャーキャスト（future cast）ＵＴＢシステム：入力が１つ以上のＭＰＥＧ２−ＴＳまたはＩＰ（Internet protocol）または一般ストリームであり、出力がＲＦシグナルである提案された物理階層（physical layer）放送システム
インプットストリーム（input stream：入力ストリーム）：システムにより最終ユーザに伝達されるサービスの調和（ensemble）のためのデータのストリーム
ノーマル（normal）データシンボル：フレームシグナリングシンボル及びフレームエッジシンボルを除外したデータシンボル
フィジカルプロファイル（PHY profile）：該当する受信機が具現しなければならない全ての構造のサブセット
ＰＬＳ：ＰＬＳ１及びＰＬＳ２で構成された物理階層（physical layer）シグナリングデータ
ＰＬＳ１：ＰＬＳ２のデコーディングに必要とするパラメータだけでなく、システムに関する基本情報を伝達する固定されたサイズ、コーディング、変調を有するＦＳＳ（frame signaling symbol）に伝達されるＰＬＳデータの第１の集合
ＮＯＴＥ：ＰＬＳ１データはフレームグルーフのデュレーション（duration）の間一定である。
ＰＬＳ２：データパイプ及びシステムに関するより詳細なＰＬＳデータを伝達するＦＳＳに送信されるＰＬＳデータの第２の集合
ＰＬＳ２ダイナミック（dynamic：動的）データ：フレーム毎にダイナミック（dynamic：動的）に変化するＰＬＳ２データ
ＰＬＳ２スタティック（static：静的）データ：フレームグルーフのデュレーションの間スタティック（static：静的）なＰＬＳ２データ
プリアンブルシグナリングデータ（preamble signaling data）：プリアンブルシンボルにより伝達され、システムの基本モードを確認することに使用されるシグナリングデータ
プリアンブルシンボル（preamble symbol）：基本ＰＬＳデータを伝達し、フレームの開始に位置する固定された長さのパイロットシンボル
ＮＯＴＥ：プリアンブルシンボルは、システム信号、そのタイミング、周波数オフセット、及びＦＦＴサイズを検出するために高速初期バンドスキャンに主に使用される。
今後使用（future use）のためにリザーブド（reserved）：現在文書で定義されないが、今後に定義できる
スーパーフレーム（superframe）：８個のフレーム反復単位の集合
タイムインターリービングブロック（time interleaving block：TI block）：タイムインターリーバメモリの１つの用途に該当する、タイムインターリービングが実行されるセルの集合
タイムインターリービンググルーフ（time interleaving group：TI group）：整数、ダイナミック（dynamic：動的）に変化するＸＦＥＣＢＬＯＣＫの数からなる、特定データパイプに対するダイナミック（dynamic：動的）容量割当が実行される単位
ＮＯＴＥ：タイムインターリービンググルーフは１つのフレームに直接マッピングされるか、または複数のフレームにマッピングできる。タイムインターリービンググルーフは１つ以上のタイムインターリービングブロックを含むことができる。
タイプ１のデータパイプ（Type 1 DP）：全てのデータパイプがフレームにＴＤＭ（time division multiplexing）方式によりマッピングされるフレームのデータパイプ
タイプ２のデータパイプ（Type 2 DP）：全てのデータパイプがフレームにＦＤＭ方式によりマッピングされるフレームのデータパイプ
ＸＦＥＣＢＬＯＣＫ：１つのＬＤＰＣ ＦＥＣＢＬＯＣＫの全てのビットを伝達するＮｃｅｌｌｓセルの集合
図１は、本発明の一実施形態に係る次世代放送サービスに対する放送信号送信装置の構造を示す。
本発明の一実施形態に係る次世代放送サービスに対する放送信号送信装置は、インプットフォーマットブロック（Input Format block）１０００、ＢＩＣＭ（bit interleaved coding & modulation）ブロック１０１０、フレームビルディングブロック（Frame building block）１０２０、ＯＦＤＭ（orthogonal frequency division multiplexing）ジェネレーションブロック（OFDM generation block）１０３０、及びシグナリング生成ブロック１０４０を含むことができる。放送信号送信装置の各ブロックの動作について説明する。
ＩＰストリーム／パケット及びＭＰＥＧ２−ＴＳは主要入力フォーマットであり、他のストリームタイプは一般ストリームとして扱われる。これらデータ入力に追加で、管理情報が入力されて各入力ストリームに対する該当帯域幅のスケジューリング及び割当を制御する。１つまたは複数のＴＳストリーム、ＩＰストリーム、及び／又は一般ストリーム入力が同時に許容される。
インプットフォーマットブロック１０００は各々の入力ストリームを独立的なコーディング及び変調が適用される１つまたは複数のデータパイプにデマルチプレキシングすることができる。データパイプは堅固性（robustness）の制御のための基本単位であり、これはＱｏＳ（Quality of Service）に影響を及ぼす。１つまたは複数のサービスまたはサービスコンポーネントが１つのデータパイプにより伝達できる。インプットフォーマットブロック１０００の詳細な動作は後述する。
データパイプは１つまたは複数のサービスまたはサービスコンポーネントを伝達することができるサービスデータ、または関連メタデータを伝達する物理階層（physical layer）におけるロジカルチャネルである。
また、データパイプユニットは１つのフレームでデータセルをデータパイプに割り当てるための基本ユニットである。
インプットフォーマットブロック１０００で、パリティ（parity）データはエラー訂正のために追加され、エンコーディングされたビットストリームは複素数値コンステレーションシンボルにマッピングされる。該当シンボルは該当データパイプに使用される特定インターリービング深さに亘ってインターリービングされる。アドバンスプロファイルにおいて、ＢＩＣＭブロック１０１０でＭＩＭＯエンコーディングが実行され、追加データ経路がＭＩＭＯ送信のために出力に追加される。ＢＩＣＭブロック１０１０の詳細な動作は後述する。
図１のインプットフォーマットブロック（Input formatting）は、後述する図５０、図５１、及び図５２において提案された機能、過程、及び／又は方法を実現する。
フレームビルディングブロック１０２０は、１つのフレーム内で入力データパイプのデータセルをＯＦＤＭシンボルにマッピングすることができる。マッピング後、周波数領域ダイバーシティのために、特に周波数選択的フェーディングチャネルを防止するために、周波数インターリービングが用いられる。フレームビルディングブロック１０２０の詳細な動作は後述する。
プリアンブルを各フレームの開始に挿入した後、ＯＦＤＭジェネレーションブロック１０３０はサイクリックプレフィックス（cyclic prefix）をガードインターバルとして有する既存のＯＦＤＭ変調を適用することができる。アンテナスペースダイバーシティのために、分散された（distributed）ＭＩＳＯ方式が送信機に亘って適用される。また、ＰＡＰＲ（peak-to-average power ratio）方式が時間領域で実行される。柔軟なネットワーク方式のために、該当の提案は多様なＦＦＴサイズ、ガードインターバル長さ、該当パイロットパターンの集合を提供する。ＯＦＤＭジェネレーションブロック１０３０の詳細な動作は後述する。
シグナリング生成ブロック１０４０は、各機能ブロックの動作に使用される物理階層（physical layer）シグナリング情報を生成することができる。また、該当シグナリング情報は関心あるサービスが受信機側で適切に復旧されるように送信される。シグナリング生成ブロック１０４０の詳細な動作は後述する。
図２、図３、及び図４は、本発明の実施形態に係るインプットフォーマットブロック１０００を示す。各図面に対して説明する。
図２〜図４のインプットフォーマットブロック（Input formatting）は、後述する図５０、図５１、及び図５２において提案された機能、過程、及び／又は方法を実現する。
図２は、本発明の一実施形態に係るインプットフォーマットブロックを示す。図２は、入力信号が単一入力ストリーム（single input stream）の時のインプットフォーマットブロックを示す。
図２に図示されたインプットフォーマットブロックは、図１を参照して説明したインプットフォーマットブロック１０００の一実施形態に該当する。
物理階層（physical layer）への入力は１つまたは複数のデータストリームで構成できる。各々のデータストリームは１つのデータパイプにより伝達される。モードアダプテーション（mode adaptation：モード適応）モジュールは入力されるデータストリームをＢＢＦ（baseband frame）のデータフィールドにスライスする。該当システムは３種類の入力データストリーム、即ちＭＰＥＧ２−ＴＳ、ＩＰ、ＧＳ（generic stream）をサポートする。ＭＰＥＧ２−ＴＳは第１のバイトが同期バイト（０×４７）である固定された長さ（１８８バイト）のパケットを特徴とする。ＩＰストリームはＩＰパケットヘッダ内でシグナリングされる可変長さＩＰデータグラムパケットで構成される。該当システムはＩＰストリームに対してＩＰｖ４とＩＰｖ６を全てサポートする。ＧＳはカプセル化パケットヘッダ内でシグナリングされる可変長さパケットまたは一定長さパケットで構成できる。
（ａ）は信号データパイプに対するモードアダプテーション（mode adaptation：モード適応）ブロック２０００、及びストリームアダプテーション（stream adaptation：ストリーム適応）２０１０を示し、（ｂ）はＰＬＳデータを生成及び処理するためのＰＬＳ生成ブロック２０２０及びＰＬＳスクランブラー２０３０を示す。各ブロックの動作について説明する。
入力ストリームスプリッタは、入力されたＴＳ、ＩＰ、ＧＳストリームを複数のサービスまたはサービスコンポーネント（オーディオ、ビデオなど）ストリームに分割する。モードアダプテーション（mode adaptation：モード適応）モジュール２０１０は、ＣＲＣエンコーダ、ＢＢ（baseband）フレームスライサー、及びＢＢフレームヘッダ挿入ブロックで構成される。
ＣＲＣエンコーダは、ユーザパケット（user packet：ＵＰ）レベルでのエラー検出のための３種類のＣＲＣエンコーディング、即ちＣＲＣ−８、ＣＲＣ−１６、ＣＲＣ−３２を提供する。算出されたＣＲＣバイトはＵＰの後に添付される。ＣＲＣ−８はＴＳストリームに使われ、ＣＲＣ−３２はＩＰストリームに使用される。ＧＳストリームがＣＲＣエンコーディングを提供しなければ、提案されたＣＲＣエンコーディングが適用されなければならない。
ＢＢフレームスライサーは、入力を内部ロジカルビットフォーマットにマッピングする。第１の受信ビットはＭＳＢと定義する。ＢＢフレームスライサーは、使用可能データフィールド容量と同一な数の入力ビットを割り当てる。ＢＢＦペイロードと同一な数の入力ビットを割り当てるために、ＵＰストリームがＢＢＦのデータフィールドに合うようにスライスされる。
ＢＢフレームヘッダ挿入ブロックは、２バイトの固定された長さのＢＢＦヘッダをＢＢフレームの前に挿入することができる。ＢＢＦヘッダは、ＳＴＵＦＦＩ（１ビット）、ＳＹＮＣＤ（１３ビット）、及びＲＦＵ（２ビット）で構成される。固定された２バイトＢＢＦヘッダだけでなく、ＢＢＦは２バイトＢＢＦヘッダの端に拡張フィールド（１または３バイト）を有することができる。
ストリームアダプテーション（stream adaptation：ストリーム適応）２０１０は、スタッフィング（stuffing）挿入ブロック及びＢＢスクランブラーで構成される。スタッフィング挿入ブロックは、スタッフィングフィールドをＢＢフレームのペイロードに挿入することができる。ストリームアダプテーション（stream adaptation：ストリーム適応）に対する入力データがＢＢフレームを詰めることに充分であれば、ＳＴＵＦＦＩは０に設定され、ＢＢＦはスタッフィングフィールドを有しない。でなければ、ＳＴＵＦＦＩは１に設定され、スタッフィングフィールドはＢＢＦヘッダの直後に挿入される。スタッフィングフィールドは、２バイトのスタッフィングフィールドヘッダ及び可変サイズのスタッフィングデータを含む。
ＢＢスクランブラーは、エネルギー分散のために完全なＢＢＦをスクランブリングする。スクランブリングシーケンスは、ＢＢＦと同期化される。スクランブリングシーケンスは、フィードバックシフトレジスタにより生成される。
ＰＬＳ生成ブロック２０２０は、ＰＬＳデータを生成することができる。ＰＬＳは、受信機でフィジカルレイヤ（physical layer）データパイプに接続できる手段を提供する。ＰＬＳデータは、ＰＬＳ１データ及びＰＬＳ２データで構成される。
ＰＬＳ１データは、ＰＬＳ２データのデコーディングに必要とするパラメータだけでなく、システムに関する基本情報を伝達する固定されたサイズ、コーディング、変調を有するフレームからＦＳＳに伝達されるＰＬＳデータの第１の集合である。ＰＬＳ１データは、ＰＬＳ２データの受信及びデコーディングを可能にすることに要求されるパラメータを含む基本送信パラメータを提供する。また、ＰＬＳ１データはフレームグルーフのデュレーションの間一定である。
ＰＬＳ２データは、データパイプ及びシステムに関するより詳しいＰＬＳデータを伝達するＦＳＳに送信されるＰＬＳデータの第２の集合である。ＰＬＳ２は、受信機が所望のデータパイプをデコーディングすることに充分の情報を提供するパラメータを含む。ＰＬＳ２シグナリングは、ＰＬＳ２スタティック（static：静的）データ（ＰＬＳ２−ＳＴＡＴデータ）及びＰＬＳ２ダイナミック（dynamic：動的）データ（ＰＬＳ２−ＤＹＮデータ）の２種類のパラメータでさらに構成される。ＰＬＳ２スタティック（static：静的）データは、フレームグルーフのデュレーションの間スタティック（static：静的）なＰＬＳ２データであり、ＰＬＳ２ダイナミック（dynamic：動的）データはフレーム毎にダイナミック（dynamic：動的）に変化するＰＬＳ２データである。
ＰＬＳデータに対する詳細な内容は後述する。
ＰＬＳスクランブラー２０３０は、エネルギー分散のために生成されたＰＬＳデータをスクランブリングすることができる。
前述したブロックは省略されることもでき、類似または同一機能を有するブロックにより取り替えることもできる。
図３は、本発明の他の一実施形態に係るインプットフォーマットブロックを示す。
図３に図示されたインプットフォーマットブロックは、図１を参照して説明したインプットフォーマットブロック１０００の一実施形態に該当する。
図３は、入力信号がマルチインプットストリーム（multi input stream：複数の入力ストリーム）に該当する場合、インプットフォーマットブロックのモードアダプテーション（mode adaptation：モード適応）ブロックを示す。
マルチインプットストリーム（multi input stream：複数の入力ストリーム）を処理するためのインプットフォーマットブロックのモードアダプテーション（mode adaptation：モード適応）ブロックは、複数入力ストリームを独立的に処理することができる。
図３を参照すると、マルチインプットストリーム（multi input stream：複数の入力ストリーム）を各々処理するためのモードアダプテーション（mode adaptation：モード適応）ブロックは、インプットストリームスプリッタ（input stream splitter）３０００、インプットストリームシンクロナイザー（input stream synchronizer）３０１０、コンペンセーティングディレイ（compensation delay：補償遅延）ブロック３０２０、ヌルパケットディリーションブロック（null packet deletion block）３０３０、ヘッダコンプレッションブロック（header compression block）３０４０、ＣＲＣエンコーダ（CRC encoder）３０５０、ＢＢフレームスライサー（BB frame slicer）３０６０、及びＢＢヘッダ挿入ブロック（BB header insertion block）３０７０を含むことができる。モードアダプテーション（mode adaptation：モード適応）ブロックの各ブロックに対して説明する。
ＣＲＣエンコーダ３０５０、ＢＢフレームスライサー３０６０、及びＢＢヘッダ挿入ブロック３０７０の動作は、図２を参照して説明したＣＲＣエンコーダ、ＢＢフレームスライサー、及びＢＢヘッダ挿入ブロックの動作に該当するので、その説明は省略する。
インプットストリームスプリッタ３０００は、入力されたＴＳ、ＩＰ、ＧＳストリームを複数のサービスまたはサービスコンポーネント（オーディオ、ビデオなど）ストリームに分割する。
インプットストリームシンクロナイザー３０１０は、ＩＳＳＹと呼ばれることができる。ＩＳＳＹは如何なる入力データフォーマットに対してもＣＢＲ（constant bit rate）及び一定の終端間送信（end-to-end transmission）遅延を保証するに適した手段を提供することができる。ＩＳＳＹはＴＳを伝達する複数のデータパイプの場合に常に用いられ、ＧＳストリームを伝達する複数のデータパイプに選択的に用いられる。
コンペンセーティングディレイ（compensation delay：補償遅延）ブロック３０２０は、受信機で追加のメモリを必要とせず、ＴＳパケット再結合メカニズムを許容するためにＩＳＳＹ情報の挿入に後続する分割されたＴＳパケットストリームを遅延させることができる。
ヌルパケットディリーションブロック３０３０は、ＴＳ入力ストリームの場合のみに使用される。一部のＴＳ入力ストリームまたは分割されたＴＳストリームはＶＢＲ（variable bit-rate）サービスをＣＢＲ ＴＳストリームに収容するために存在する複数のヌルパケットを有することができる。この場合、不要な送信オーバーヘッドを避けるために、ヌルパケットは確認されて送信されないことがある。受信機で、除去されたヌルパケットは送信に挿入されたＤＮＰ（deleted null-packet：除去されたヌルパケット）カウンターを参照して元の存在していた正確な場所に再挿入できるので、ＣＢＲが保証され、タイムスタンプ（ＰＣＲ）更新の必要がなくなる。
ヘッダコンプレッションブロック３０４０は、ＴＳまたはＩＰ入力ストリームに対する送信効率を増加させるためにパケットヘッダ圧縮を提供することができる。受信機はヘッダの特定部分に対する先験的な（a priori）情報を有することができるので、この知られた情報（known information）は送信機から削除できる。
ＴＳに対し、受信機は同期バイト構成（０×４７）及びパケット長さ（１８８バイト）に関する先験的な情報を有することができる。入力されたＴＳが１つのＰＩＤのみを有するコンデンツを伝達すれば、即ち、１つのサービスコンポーネント（ビデオ、オーディオなど）、またはサービスサブコンポーネント（ＳＶＣベースレイヤ、ＳＶＣインヘンスメントレイヤ、ＭＶＣベースビュー、またはＭＶＣ依存ビュー）に対してのみ、ＴＳパケットヘッダ圧縮がＴＳに（選択的に）適用できる。ＴＳパケットヘッダ圧縮は入力ストリームがＩＰストリームの場合、選択的に使用される。前記ブロックは省略されるか、類似または同一機能を有するブロックに取り替えることができる。
図４は、本発明の他の実施形態に係るインプットフォーマットブロックを示す。
図４に図示されたインプットフォーマットブロックは、図１を参照して説明したインプットフォーマットブロック１０００の一実施形態に該当する。
図４は、入力信号がマルチインプットストリーム（multi input stream：複数の入力ストリーム）に該当する場合、インプットフォーマットブロックのストリームアダプテーション（stream adaptation：ストリーム適応）ブロックを示す。
図４を参照すると、マルチインプットストリーム（multi input stream：複数の入力ストリーム）を各々処理するためのモードアダプテーション（mode adaptation：モード適応）ブロックは、スケジューラー４０００、１−フレームディレイ（delay）ブロック４０１０、スタッフィング挿入ブロック４０２０、インバンド（In-band）シグナリングブロック４０３０、ＢＢフレームスクランブラー４０４０、ＰＬＳ生成ブロック４０５０、及びＰＬＳスクランブラー４０６０を含むことができる。ストリームアダプテーション（stream adaptation：ストリーム適応）ブロックの各ブロックに対して説明する。
スタッフィング挿入ブロック４０２０、ＢＢフレームスクランブラー４０４０、ＰＬＳ生成ブロック４０５０、ＰＬＳスクランブラー４０６０の動作は、図２を参照して説明したスタッフィング挿入ブロック、ＢＢスクランブラー、ＰＬＳ生成ブロック、ＰＬＳスクランブラー４０６０の動作に該当するので、その説明は省略する。
スケジューラー４０００は各データパイプのＦＥＣＢＬＯＣＫの量から全体フレームに亘って全体のセル割当を決定することができる。ＰＬＳ、ＥＡＣ、及びＦＩＣに対する割当を含んで、スケジューラーはフレームのＦＳＳのＰＬＳセルまたはインバンド（In-band）シグナリングに送信されるＰＬＳ２−ＤＹＮデータの値を生成する。ＦＥＣＢＬＯＣＫ、ＥＡＣ、ＦＩＣに対する詳細な内容は後述する。
１−フレームディレイ（delay）ブロック４０１０は、次のフレームに関するスケジューリング情報がデータパイプに挿入されるインバンド（In-band）シグナリング情報に関する現フレームを通じて送信できるように入力データを１つの送信フレームだけ遅延させることができる。
インバンド（In-band）シグナリングブロック４０３０は、ＰＬＳ２データの遅延されない部分をフレームのデータパイプに挿入することができる。
前述したブロックは省略されるか、類似または同一機能を有するブロックに取り替えることができる。
図５は、本発明の一実施形態に係るＢＩＣＭブロックを示す。
図５に図示されたＢＩＣＭブロックは、図１を参照して説明したＢＩＣＭブロック１０１０の一実施形態に該当する。
前述したように、本発明の一実施形態に係る次世代放送サービスに対する放送信号送信装置は、地上波放送サービス、モバイル放送サービス、ＵＨＤＴＶサービスなどを提供することができる。
ＱｏＳが本発明の一実施形態に係る次世代放送サービスに対する放送信号送信装置により提供されるサービスの特性に依存するので、各々のサービスに該当するデータは互いに異なる方式により処理されなければならない。したがって、本発明の一実施形態に係るＢＩＣＭブロックは、ＳＩＳＯ、ＭＩＳＯ、ＭＩＭＯ方式を各々のデータ経路に該当するデータパイプに独立的に適用することによって、各データパイプを独立的に処理することができる。結果的に、本発明の一実施形態に係る次世代放送サービスに対する放送信号送信装置は、各々のデータパイプを介して送信される各サービスまたはサービスコンポーネントに対するＱｏＳを調節することができる。
（ａ）はベースプロファイル及びハンドヘルドプロファイルにより共有されるＢＩＣＭブロックを示し、（ｂ）はアドバンスプロファイルのＢＩＣＭブロックを示す。
ベースプロファイル及びハンドヘルドプロファイルにより共有されるＢＩＣＭブロック及びアドバンスプロファイルのＢＩＣＭブロックは、各々のデータパイプを処理するための複数の処理ブロックを含むことができる。
ベースプロファイル及びハンドヘルドプロファイルに対するＢＩＣＭブロック及びアドバンスプロファイルに対するＢＩＣＭブロックの各々の処理ブロックに対して説明する。
ベースプロファイル及びハンドヘルドプロファイルに対するＢＩＣＭブロックの処理ブロック５０００は、データＦＥＣエンコーダ５０１０、ビットインターリーバ５０２０、コンステレーションマッパー（mapper）５０３０、ＳＳＤ（signal space diversity）エンコーディングブロック５０４０、及びタイムインターリーバ５０５０を含むことができる。
データＦＥＣエンコーダ５０１０は、外部コーディング（ＢＣＨ）及び内部コーディング（ＬＤＰＣ）を用いてＦＥＣＢＬＯＣＫ手続を生成するために入力ＢＢＦにＦＥＣエンコーディングを実行する。外部コーディング（ＢＣＨ）は選択的なコーディング方法である。データＦＥＣエンコーダ５０１０の具体的な動作に対しては後述する。
ビットインターリーバ５０２０は、効率的に実現可能な構造を提供しながらデータＦＥＣエンコーダ５０１０の出力をインターリービングしてＬＤＰＣコード及び変調方式の組合せにより最適化された性能を達成することができる。ビットインターリーバ５０２０の具体的な動作に対しては後述する。
コンステレーションマッパー５０３０は、ＱＰＳＫ、ＱＡＭ−１６、不均一ＱＡＭ（ＮＵＱ−６４、ＮＵＱ−２５６、ＮＵＱ−１０２４）、または不均一コンステレーション（ＮＵＣ−１６、ＮＵＣ−６４、ＮＵＣ−２５６、ＮＵＣ−１０２４）を用いてベース及びハンドヘルドプロファイルでビットインターリーバ５０２０からの各々のセルワードを変調するか、またはアドバンスプロファイルでセルワードデマルチプレクサ５０１０−１からのセルワードを変調してパワーが正規化されたコンステレーションポイントｅｌを提供することができる。該当コンステレーションマッピングは、データパイプに対してのみ適用される。ＮＵＱが任意の形態を有する一方、ＱＡＭ−１６及びＮＵＱは正四角形の形態を有することが観察される。各々のコンステレーションが９０度の倍数だけ回転されれば、回転されたコンステレーションは元のものと正確に重なる。回転対称特性によって実数及び虚数コンポーネントの容量及び平均パワーが互いに同一になる。ＮＵＱ及びＮＵＣは全て各コードレート（code rate）に対して特別に定義され、使用される特定の１つはＰＬＳ２データに保管されたパラメータＤＰ＿ＭＯＤによりシグナリングされる。
ＳＳＤエンコーディングブロック５０４０は、２次元、３次元、４次元でセルをフリーコーディングして、難しいフェーディング条件で受信堅固性（robustness）を増加させることができる。
タイムインターリーバ５０５０は、データパイプレベルで動作することができる。タイムインターリービングのパラメータは、各々のデータパイプに対して異なるように設定できる。タイムインターリーバ５０５０の具体的な動作に関しては後述する。
アドバンスプロファイルに対するＢＩＣＭブロックの処理ブロック５０００−１は、データＦＥＣエンコーダ、ビットインターリーバ、コンステレーションマッパー、及びタイムインターリーバを含むことができる。
但し、処理ブロック５０００−１はセルワードデマルチプレクサ５０１０−１及びＭＩＭＯエンコーディングブロック５０２０−１をさらに含むという点で処理ブロック５０００と区別される。
また、処理ブロック５０００−１におけるデータＦＥＣエンコーダ、ビットインターリーバ、コンステレーションマッパー、タイムインターリーバの動作は、前述したデータＦＥＣエンコーダ５０１０、ビットインターリーバ５０２０、コンステレーションマッパー５０３０、タイムインターリーバ５０５０の動作に該当するので、その説明は省略する。
セルワードデマルチプレクサ５０１０−１は、アドバンスプロファイルのデータパイプがＭＩＭＯ処理のために単一セルワードストリームを二重セルワードストリームに分離することに使用される。セルワードデマルチプレクサ５０１０−１の具体的な動作に関しては後述する。
ＭＩＭＯエンコーディングブロック５０２０−１は、ＭＩＭＯエンコーディング方式を用いてセルワードデマルチプレクサ５０１０−１の出力を処理することができる。ＭＩＭＯエンコーディング方式は、放送信号送信のために最適化された。ＭＩＭＯ技術は、容量増加を得るための有望な方式であるが、チャネル特性に依存する。特別に放送に対して、互いに異なる信号伝搬特性による２アンテナの間の受信信号パワーの差、またはチャネルの強いＬＯＳコンポーネントはＭＩＭＯから容量利得を得ることを難しくする。提案されたＭＩＭＯエンコーディング方式は、ＭＩＭＯ出力信号のうちの１つの位相ランダム化及び回転基盤プリコーディングを用いてこの問題を克服する。
ＭＩＭＯエンコーディングは、送信機及び受信機の全てで少なくとも２つのアンテナを必要とする２×２ＭＩＭＯシステムのために意図される。２つのＭＩＭＯエンコーディングモードは本提案であるＦＲ−ＳＭ（full-rate spatial multiplexing）及びＦＲＦＤ−ＳＭ（full-rate full-diversity spatial multiplexing）で定義される。ＦＲ−ＳＭエンコーディングは受信機側における比較的小さい複雑度増加により容量増加を提供する一方、ＦＲＦＤ−ＳＭエンコーディングは受信機側における大きい複雑度増加で容量増加及び追加的なダイバーシティ利得を提供する。提案されたＭＩＭＯエンコーディング方式はアンテナ極性配置を制限しない。
ＭＩＭＯ処理はアドバンスプロファイルフレームに要求されるが、これはアドバンスプロファイルフレームにおける全てのデータパイプがＭＩＭＯエンコーダにより処理されることを意味する。ＭＩＭＯ処理はデータパイプレベルで適用される。コンステレーションマッパー出力のペア（pair：対）であるＮＵＱ（ｅ１，ｉ及びｅ２，ｉ）はＭＩＭＯエンコーダの入力により供給される。ＭＩＭＯエンコーダ出力ペア（pair：対）（ｇ１，ｉ及びｇ２，ｉ）は各々の送信アンテナの同一なキャリアｋ及びＯＦＤＭシンボルｌにより送信される。
前述したブロックは省略されるか、類似または同一機能を有するブロックに取り替えることができる。
図６は、本発明の他の実施形態に係るＢＩＣＭブロックを示す。
図６に図示されたＢＩＣＭブロックは、図１を参照して説明したＢＩＣＭブロック１０１０の一実施形態に該当する。
図６は、ＰＬＳ、ＥＡＣ、及びＦＩＣの保護のためのＢＩＣＭブロックを示す。ＥＡＣはＥＡＳ情報データを伝達するフレームの一部であり、ＦＩＣはサービスと該当するベースデータパイプとの間でマッピング情報を伝達するフレームにおけるロジカルチャネルである。ＥＡＣ及びＦＩＣに対する詳細な説明は後述する。
図６を参照すると、ＰＬＳ、ＥＡＣ、及びＦＩＣの保護のためのＢＩＣＭブロックは、ＰＬＳ ＦＥＣエンコーダ６０００、ビットインターリーバ６０１０、及びコンステレーションマッパー６０２０を含むことができる。
また、ＰＬＳ ＦＥＣエンコーダ６０００は、スクランブラー、ＢＣＨエンコーディング／ゼロ挿入ブロック、ＬＤＰＣエンコーディングブロック、及びＬＤＰＣパリティパンクチャリング（puncturing）ブロックを含むことができる。ＢＩＣＭブロックの各ブロックに対して説明する。
ＰＬＳ ＦＥＣエンコーダ６０００は、スクランブリングされたＰＬＳ １／２データ、ＥＡＣ及びＦＩＣセクションをエンコーディングすることができる。
スクランブラーは、ＢＣＨエンコーディング及びショートニング（shortening）及びパンクチャリングされたＬＤＰＣエンコーディングの前にＰＬＳ１データ及びＰＬＳ２データをスクランブリングすることができる。
ＢＣＨエンコーディング／ゼロ挿入ブロックは、ＰＬＳ保護のためのショートニングされたＢＣＨコードを用いてスクランブリングされたＰＬＳ １／２データに外部エンコーディングを遂行し、ＢＣＨエンコーディングの後にゼロビットを挿入することができる。ＰＬＳ１データに対してのみゼロ挿入の出力ビットがＬＤＰＣエンコーディングの前にパーミュテーション（permutation）できる。
ＬＤＰＣエンコーディングブロックは、ＬＤＰＣコードを用いてＢＣＨエンコーディング／ゼロ挿入ブロックの出力をエンコーディングすることができる。完全なコーディングブロックを生成するために、Ｃｌｄｐｃ及びパリティビットＰｌｄｐｃは各々のゼロが挿入されたＰＬＳ情報ブロックＩｌｄｐｃから組織的にエンコーディングされ、その後に添付される。
Figure 2018504070
ＰＬＳ１及びＰＬＳ２に対するＬＤＰＣコードパラメータは、次の＜表４＞の通りである。
Figure 2018504070
ＬＤＰＣパリティパンクチャリングブロックは、ＰＬＳ１データ及びＰＬＳ２データに対してパンクチャリングを遂行することができる。
ショートニングがＰＬＳ１データ保護に適用されれば、一部のＬＤＰＣパリティビットはＬＤＰＣエンコーディングの後にパンクチャリングされる。また、ＰＬＳ２データ保護のために、ＰＬＳ２のＬＤＰＣパリティビットがＬＤＰＣエンコーディングの後にパンクチャリングされる。これらパンクチャリングされたビットは送信されない。
ビットインターリーバ６０１０は、各々のショートニング及びパンクチャリングされたＰＬＳ１データ及びＰＬＳ２データをインターリービングすることができる。
コンステレーションマッパー６０２０は、ビットインターリービングされたＰＬＳ１データ及びＰＬＳ２データをコンステレーションにマッピングすることができる。
前述したブロックは省略されるか、類似または同一機能を有するブロックに取り替えることができる。
図７は、本発明の一実施形態に係るフレームビルディングブロック（frame building block）を示す。
図７に図示したフレームビルディングブロックは、図１を参照して説明したフレームビルディングブロック１０２０の一実施形態に該当する。
図７を参照すると、フレームビルディングブロックは、ディレイコンペンセーション（delay compensation：遅延補償）ブロック７０００、セルマッパー（cell mapper）７０１０、及びフリークエンシーインターリーバ（frequency interleaver）７０２０を含むことができる。フレームビルディングブロックの各ブロックに関して説明する。
ディレイコンペンセーション（delay compensation：遅延補償）ブロック７０００は、データパイプと該当するＰＬＳデータとの間のタイミングを調節して送信機側でデータパイプと該当するＰＬＳデータとの間の同時性（co-time）を保証することができる。インプットフォーマットブロック及びＢＩＣＭブロックによるデータパイプの遅延を扱うことによってＰＬＳデータはデータパイプだけ遅延される。ＢＩＣＭブロックの遅延は主にタイムインターリーバ５０５０によるものである。インバンド（In-band）シグナリングデータは、次のタイムインターリービンググルーフの情報をシグナリングされるデータパイプより１つのフレームの前に伝達されるようにすることができる。ディレイコンペンセーション（delay compensation：遅延補償）ブロックは、それに合せてインバンド（In-band）シグナリングデータを遅延させる。
セルマッパー７０１０は、ＰＬＳ、ＥＡＣ、ＦＩＣ、データパイプ、補助ストリーム、及びダミーセルをフレーム内でＯＦＤＭシンボルのアクティブ（active）キャリアにマッピングすることができる。セルマッパー７０１０の基本機能は、各々のデータパイプ、ＰＬＳセル、及びＥＡＣ／ＦＩＣセルに対するタイムインターリービングにより生成されたデータセルを、存在していれば、１つのフレーム内で各々のＯＦＤＭシンボルに該当するアクティブ（active）ＯＦＤＭセルのアレイにマッピングするものである。（ＰＳＩ（program specific information）／ＳＩのような）サービスシグナリングデータは個別的に収集されてデータパイプにより送られることができる。セルマッパーはフレーム構造の構成及びスケジューラーにより生成されたダイナミックインフォメーション（dynamic information：動的情報）に従って動作する。フレームに関する詳細な内容は後述する。
フリークエンシーインターリーバ７０２０は、セルマッパー７０１０から受信されたデータセルをランダムにインターリービングして周波数ダイバーシティを提供することができる。また、フリークエンシーインターリーバ７０２０は単一フレームで最大のインターリービング利得を得るために他のインターリービングシード（seed）の順序を用いて２つの順次的なＯＦＤＭシンボルで構成されたＯＦＤＭシンボルペア（pair：対）で動作することができる。
前述したブロックは省略されるか、類似または同一機能を有するブロックに取り替えることができる。
図８は、本発明の一実施形態に係るＯＦＤＭジェネレーションブロックを示す。
図８に図示されたＯＦＤＭジェネレーションブロックは、図１を参照して説明したＯＦＤＭジェネレーションブロック１０３０の一実施形態に該当する。
ＯＦＤＭジェネレーションブロックは、フレームビルディングブロックにより生成されたセルによりＯＦＤＭキャリアを変調し、パイロットを挿入し、送信のための時間領域信号を生成する。また、該当ブロックは順次的にガードインターバルを挿入し、ＰＡＰＲ減少処理を適用して最終のＲＦ信号を生成する。
図８を参照すると、ＯＦＤＭジェネレーションブロックは、パイロット及びリザーブドトーン挿入ブロック（pilot and reserved tone insertion block）８０００、２Ｄ−ｅＳＦＮ（single frequency network）エンコーディングブロック８０１０、ＩＦＦＴ（inverse fast Fourier transform）ブロック８０２０、ＰＡＰＲ減少ブロック８０３０、ガードインターバル挿入ブロック（guard interval insertion block）８０４０、プリアンブル挿入ブロック（preamble insertion block）８０５０、その他のシステム挿入ブロック８０６０、及びＤＡＣブロック８０７０を含むことができる。ＯＦＤＭジェネレーションブロックの各ブロックに対して説明する。
パイロット及びリザーブドトーン挿入ブロック８０００は、パイロット及びリザーブドトーンを挿入することができる。
ＯＦＤＭシンボル内の多様なセルは受信機から先験的に知られた送信された値を有するパイロットとして知られた参照情報に変調される。パイロットセルの情報は、分散パイロット、連続パイロット、エッジパイロット、ＦＳＳ（frame signaling symbol）パイロット、及びＦＥＳ（frame edge symbol）パイロットで構成される。各パイロットは、パイロットタイプ及びパイロットパターンに従って特定増加パワーレベルで送信される。パイロット情報の値は与えられたシンボルで１つが各々の送信キャリアに対するものである一連の値に該当する参照シーケンスで誘導される。パイロットは、フレーム同期化、周波数同期化、時間同期化、チャネル推定、送信モード識別のために使用されることができ、また位相雑音を追跡するために使用できる。
参照シーケンスから取った参照情報は、フレームのプリアンブル、ＦＳＳ及びＦＥＳを除外した全てのシンボルにおける分散パイロットセルで送信される。連続パイロットは、フレームの全てのシンボルに挿入される。連続パイロットの数及び位置はＦＦＴサイズ及び分散パイロットパターンに全て依存する。エッジキャリアは、プリアンブルシンボルを除外した全てのシンボル内のエッジパイロットと同一である。エッジキャリアは、スペクトルのエッジまで周波数インターポレーション（interpolation：補間）を許容するために挿入される。ＦＳＳパイロットはＦＳＳに挿入され、ＦＥＳパイロットはＦＥＳに挿入される。ＦＳＳパイロット及びＦＥＳパイロットはフレームのエッジまで時間インターポレーション（interpolation：補間）を許容するために挿入される。
本発明の一実施形態に係るシステムは非常に堅い送信モードをサポートするために分散ＭＩＳＯ方式が選択的に使用されるＳＦＮをサポートする。２Ｄ−ｅＳＦＮは複数の送信アンテナを使用する分散ＭＩＳＯ方式であって、各アンテナはＳＦＮネットワークで各々異なる送信機に位置することができる。
２Ｄ−ｅＳＦＮエンコーディングブロック８０１０は、ＳＦＮ構成で時間及び周波数ダイバーシティを生成するために２Ｄ−ｅＳＦＮ処理を行って複数の送信機から送信された信号の位相を歪曲させることがある。したがって、長時間の間の低い平面フェーディングまたは深いフェーディングによるバースト誤りが軽減できる。
ＩＦＦＴブロック８０２０は、ＯＦＤＭ変調方式を用いて２Ｄ−ｅＳＦＮエンコーディングブロック８０１０からの出力を変調することができる。パイロット（または、リザーブドトーン）に指定されないデータシンボルでの全てのセルは、周波数インターリーバからのデータセルのうちの１つを伝達する。セルはＯＦＤＭキャリアにマッピングされる。
ＰＡＰＲ減少ブロック８０３０は、時間領域で多様なＰＡＰＲ減少アルゴリズムを用いて入力信号にＰＡＰＲ減少を実行する。
ガードインターバル挿入ブロック８０４０はガードインターバルを挿入することができ、プリアンブル挿入ブロック８０５０は信号の前にプリアンブルを挿入することができる。プリアンブルの構造に対する詳細な内容は後述する。
その他のシステム挿入ブロック８０６０は、放送サービスを提供する２つ以上の互いに異なる放送送信／受信システムのデータが同一なＲＦ信号帯域で同時に送信できるように時間領域で複数の放送送信／受信システムの信号をマルチプレキシングすることができる。この場合、２つ以上の互いに異なる放送送信／受信システムは、互いに異なる放送サービスを提供するシステムをいう。互いに異なる放送サービスは、地上波放送サービス、モバイル放送サービスなどを意味することができる。各々の放送サービスに関連したデータは互いに異なるフレームを通じて送信できる。
ＤＡＣブロック８０７０は、入力されたディジタル信号をアナログ信号に変換して出力することができる。ＤＡＣブロック８０７０から出力された信号は物理階層プロファイルによって複数の出力アンテナを介して送信できる。本発明の一実施形態に係る送信アンテナは垂直または水平極性を有することができる。
前述したブロックは設計によって省略されるか、類似または同一機能を有するブロックに取替できる。
図９は、本発明の一実施形態に係る次世代放送サービスに対する放送信号受信装置の構造を示す。
本発明の一実施形態に係る次世代放送サービスに対する放送信号受信装置は、図１を参照して説明した次世代放送サービスに対する放送信号送信装置に対応することができる。
本発明の一実施形態に係る次世代放送サービスに対する放送信号受信装置は、同期及び復調モジュール（synchronization & demodulation module）９０００、フレームパーシングモジュール（frame parsing module）９０１０、デマッピング及びデコーディングモジュール（demapping & decoding module）９０２０、出力プロセッサ（output processor）９０３０、及びシグナリングデコーディングモジュール（signaling decoding module）９０４０を含むことができる。放送信号受信装置の各モジュールの動作に対して説明する。
同期及び復調モジュール９０００は、ｍ個の受信アンテナを介して入力信号を受信し、放送信号受信装置に該当するシステムに対して信号検出及び同期化を実行し、放送信号送信装置により実行される手続の逆過程に該当する復調を実行することができる。
フレームパーシングモジュール９０１０は、入力信号フレームをパーシングし、ユーザにより選択されたサービスが送信されるデータを抽出することができる。放送信号送信装置がインターリービングを実行すれば、フレームパーシングモジュール９０１０はインターリービングの逆過程に該当するデインターリービングを実行することができる。この場合、抽出されなければならない信号及びデータの位置がシグナリングデコーディングモジュール９０４０から出力されたデータをデコーディングすることにより取得されて、放送信号送信装置により生成されたスケジューリング情報が復元できる。
デマッピング及びデコーディングモジュール９０２０は、入力信号をビット領域データに変換した後、必要によってビット領域データをデインターリービングすることができる。デマッピング及びデコーディングモジュール９０２０は、送信効率のために適用されたマッピングに対するデマッピングを実行し、デコーディングを通じて送信チャネルで発生したエラーを訂正することができる。この場合、デマッピング及びデコーディングモジュール９０２０はシグナリングデコーディングモジュール９０４０から出力されたデータをデコーディングすることによって、デマッピング及びデコーディングのために必要な送信パラメータを取得することができる。
出力プロセッサ９０３０は、送信効率を向上させるために放送信号送信装置により適用される多様な圧縮／信号処理手続の逆過程を実行することができる。この場合、出力プロセッサ９０３０はシグナリングデコーディングモジュール９０４０から出力されたデータで必要とする制御情報を取得することができる。出力プロセッサ８３００の出力は、放送信号送信装置に入力される信号に該当し、ＭＰＥＧ−ＴＳ、ＩＰストリーム（ｖ４またはｖ６）及びＧＳでありうる。
シグナリングデコーディングモジュール９０４０は、同期及び復調モジュール９０００により復調された信号からＰＬＳ情報を取得することができる。前述したように、フレームパーシングモジュール９０１０、デマッピング及びデコーディングモジュール９２００、及び出力プロセッサ９３００は、シグナリングデコーディングモジュール９０４０から出力されたデータを用いてその機能を実行することができる。
図９の出力プロセッサ（Output Processor）は、後述する図５０、図５１、及び図５３において提案された機能、過程、及び／又は方法を実現する。
図１０は、本発明の一実施形態に係るフレーム構造を示す。
図１０は、フレームタイムの構成例及びスーパーフレームにおけるＦＲＵ（frame repetition unit：フレーム反復単位）を示す。（ａ）は本発明の一実施形態に係るスーパーフレームを示し、（ｂ）は本発明の一実施形態に係るＦＲＵを示し、（ｃ）はＦＲＵでの多様なフィジカルプロファイル（PHY profile）のフレームを示し、（ｄ）はフレームの構造を示す。
スーパーフレームは８個のＦＲＵで構成できる。ＦＲＵはフレームのＴＤＭに対する基本マルチプレキシング単位であり、スーパーフレームで８回反復される。
ＦＲＵで各フレームはフィジカルプロファイル（ベース、ハンドヘルド、アドバンスプロファイル）のうちの１つまたはＦＥＦに属する。ＦＲＵで、フレームの最大許容数は４であり、与えられたフィジカルプロファイルはＦＲＵで０回乃至４回のうちのいずれかの回数だけ表れることができる（例えば、ベース、ハンドヘルド、アドバンス）。フィジカルプロファイル定義は、必要時、プリアンブルにおけるＰHY_PROFILEのリザーブド値を用いて拡張できる。
ＦＥＦ部分は、含まれれば、ＦＲＵの端に挿入される。ＦＥＦがＦＲＵに含まれる場合、ＦＥＦの最大数はスーパーフレームで８である。ＦＥＦ部分が互いに隣接することが推奨されない。
１つのフレームは複数のＯＦＤＭシンボル及びプリアンブルにさらに分離される。（ｄ）に図示したように、フレームは、プリアンブル、１つ以上のＦＳＳ、ノーマルデータシンボル、及びＦＥＳを含む。
プリアンブルは高速フューチャーキャストＵＴＢシステム信号検出を可能にし、信号の効率的な送信及び受信のための基本送信パラメータの集合を提供する特別なシンボルである。プリアンブルに対する詳細な内容は後述する。
ＦＳＳの主な目的はＰＬＳデータを伝達するものである。高速同期化及びチャネル推定のために、これに従うＰＬＳデータの高速デコーディングのために、ＦＳＳはノーマルデータシンボルより高密度のパイロットパターンを有する。ＦＥＳはＦＳＳと完全に同一なパイロットを有するが、これはＦＥＳの直前のシンボルに対して外挿（extrapolation）無しでＦＥＳ内での周波数のみのインターポレーション（interpolation：補間）及び時間的補間（temporal interpolation）を可能にする。
図１１は、本発明の一実施形態に係るフレームのシグナリング階層構造（signaling hierarchy structure）を示す。
図１１はシグナリング階層構造を示すが、これは３個の主要部分であるプリアンブルシグナリングデータ１１０００、ＰＬＳ１データ１１０１０、及びＰＬＳ２データ１１０２０に分割される。毎フレーム毎にプリアンブル信号により伝達されるプリアンブルの目的は、フレームの基本送信パラメータ及び送信タイプを示すものである。ＰＬＳ１は、受信機が関心あるデータパイプに接続するためのパラメータを含むＰＬＳ２データに接続してデコーディングできるようにする。ＰＬＳ２は毎フレーム毎に伝達され、２つの主要部分であるＰＬＳ２−ＳＴＡＴデータとＰＬＳ２−ＤＹＮデータに分割される。ＰＬＳ２データのスタティック（static：静的）及びダイナミック（dynamic：動的）部分には、必要時、パッディングが後続する。
図１２は、本発明の一実施形態に係るプリアンブルシグナリングデータを示す。
プリアンブルシグナリングデータは、受信機がフレーム構造内でＰＬＳデータに接続し、データパイプを追跡できるようにするために必要とする２１ビットの情報を伝達する。プリアンブルシグナリングデータに対する詳細な内容は、次の通りである。
ＰＨＹ＿ＰＲＯＦＩＬＥ：該当３ビットフィールドは現フレームのフィジカルプロファイルタイプを示す。互いに異なるフィジカルプロファイルタイプのマッピングは、以下の＜表５＞に与えられる。
Figure 2018504070
ＦＦＴ＿ＳＩＺＥ：該当２ビットフィールドは以下の＜表６＞で説明した通り、フレームグルーフ内で現フレームのＦＦＴサイズを示す。
Figure 2018504070
ＧＩ＿ＦＲＡＣＴＩＯＮ：該当３ビットフィールドは以下の＜表７＞で説明した通り、現スーパーフレームにおけるガードインターバルの一部（fraction）値を示す。
Figure 2018504070
ＥＡＣ＿ＦＬＡＧ：該当１ビットフィールドはＥＡＣが現フレームに提供されるか否かを示す。該当フィールドが１に設定されれば、ＥＡＳが現フレームに提供される。該当フィールドが０に設定されれば、ＥＡＳが現フレームで伝達されない。該当フィールドはスーパーフレーム内でダイナミック（dynamic：動的）に転換できる。
ＰＩＬＯＴ＿ＭＯＤＥ：該当１ビットフィールドは現フレームグルーフで現フレームに対してパイロットモードがモバイルモードであるか、または固定モードか否かを示す。該当フィールドが０に設定されれば、モバイルパイロットモードが使用される。該当フィールドが１に設定されれば、固定パイロットモードが使用される。
ＰＡＰＲ＿ＦＬＡＧ：該当１ビットフィールドは現フレームグルーフで現フレームに対してＰＡＰＲ減少が使用されるか否かを示す。該当フィールドが１に設定されれば、トーン予約（tone reservation）がＰＡＰＲ減少のために使用される。該当フィールドが０に設定されれば、ＰＡＰＲ減少が使われない。
ＦＲＵ＿ＣＯＮＦＩＧＵＲＥ：該当３ビットフィールドは現スーパーフレームで存在するＦＲＵのフィジカルプロファイルタイプ構成を示す。現スーパーフレームで全てのプリアンブルにおける該当フィールドで、現スーパーフレームで伝達される全てのプロファイルタイプが識別される。該当３ビットフィールドは以下の＜表８＞に示した通り、各々のプロファイルに対して異なるように定義される。
Figure 2018504070
ＲＥＳＥＲＶＥＤ：該当７ビットフィールドは今後の使用のために予約（reserved）される。
図１３は、本発明の一実施形態に係るＰＬＳ１データを示す。
ＰＬＳ１データはＰＬＳ２の受信及びデコーディングを可能にするために必要なパラメータを含んだ基本送信パラメータを提供する。前述したように、ＰＬＳ１データは１つのフレームグルーフの全体デュレーションの間変化しない。ＰＬＳ１データのシグナリングフィールドの具体的な定義は、次の通りである。
ＰＲＥＡＭＢＬＥ＿ＤＡＴＡ：該当２０ビットフィールドはＥＡＣ＿ＦＬＡＧを除外したプリアンブルシグナリングデータのコピーである。
ＮＵＭ＿ＦＲＡＭＥ＿ＦＲＵ：該当２ビットフィールドはＦＲＵ当たりフレーム数を示す。
ＰＡＹＬＯＡＤ＿ＴＹＰＥ：該当３ビットフィールドはフレームグルーフで伝達されるペイロードデータのフォーマットを示す。ＰＡＹＬＯＡＤ＿ＴＹＰＥは＜表９＞に示した通りシグナリングされる。
Figure 2018504070
ＮＵＭ＿ＦＳＳ：該当２ビットフィールドは現フレームでＦＳＳの数を示す。
ＳＹＳＴＥＭ＿ＶＥＲＳＩＯＮ：該当８ビットフィールドは送信される信号フォーマットのバージョンを示す。ＳＹＳＴＥＭ＿ＶＥＲＳＩＯＮは主バージョン及び副バージョンの２つの４ビットフィールドに分離される。
主バージョン：ＳＹＳＴＥＭ＿ＶＥＲＳＩＯＮフィールドのＭＳＢである４ビットは主バージョン情報を示す。主バージョンフィールドでの変化は互換が不可能な変化を示す。デフォルト値は００００である。該当標準で叙述されたバージョンに対し、値が００００に設定される。
副バージョン：ＳＹＳＴＥＭ＿ＶＥＲＳＩＯＮフィールドのＬＳＢである４ビットは副バージョン情報を示す。副バージョンフィールドでの変化は互換が可能である。
ＣＥＬＬ＿ＩＤ：これはＡＴＳＣネットワークにおける地理的セルを唯一に識別する１６ビットフィールドである。ＡＴＳＣセルカバレッジはフューチャーキャストＵＴＢシステム当たり使用される周波数の数によって１つ以上の周波数で構成できる。ＣＥＬＬ＿ＩＤの値が知られていないか、特定されなければ、該当フィールドは０に設定される。
ＮＥＴＷＯＲＫ＿ＩＤ：これは現ＡＴＳＣネットワークを唯一に識別する１６ビットフィールドである。
ＳＹＳＴＥＭ＿ＩＤ：該当１６ビットフィールドはＡＴＳＣネットワーク内でフューチャーキャストＵＴＢシステムを唯一に識別する。フューチャーキャストＵＴＢシステムは入力が１つ以上の入力ストリーム（ＴＳ、ＩＰ、ＧＳ）であり、出力がＲＦ信号である地上波放送システムである。フューチャーキャストＵＴＢシステムは、存在していれば、ＦＥＦ及び１つ以上のフィジカルプロファイルを伝達する。同一なフューチャーキャストＵＴＢシステムは互いに異なる入力ストリームを伝達し、互いに異なる地理的領域で互いに異なるＲＦを使用することができるので、ローカルサービス挿入を許容する。フレーム構造及びスケジューリングは１つの場所で制御され、フューチャーキャストＵＴＢシステム内で全ての送信に対して同一である。１つ以上のフューチャーキャストＵＴＢシステムは全て同一なフィジカル構造及び構成を有するという同一なＳＹＳＴＥＭ＿ＩＤの意味を有することができる。
次のループ（loop）は、各フレームタイプの長さ及びＦＲＵ構成を示すＦＲＵ＿ＰＨＹ＿ＰＲＯＦＩＬＥ、ＦＲＵ＿ＦＲＡＭＥ＿ＬＥＮＧＴＨ、ＦＲＵ＿ＧＩ＿ＦＲＡＣＴＩＯＮ、及びＲＥＳＥＲＶＥＤで構成される。ループ（loop）サイズはＦＲＵ内で４個のフィジカルプロファイル（ＦＥＦ含み）がシグナリングされるように固定される。ＮＵＭ＿ＦＲＡＭＥ＿ＦＲＵが４より小さければ、使われないフィールドはゼロで詰められる。
ＦＲＵ＿ＰＨＹ＿ＰＲＯＦＩＬＥ：該当３ビットフィールドは関連したＦＲＵの（ｉ＋１）番目フレーム（ｉはループ（loop）インデックス）のフィジカルプロファイルタイプを示す。該当フィールドは＜表８＞に示したものと同一なシグナリングフォーマットを使用する。
ＦＲＵ＿ＦＲＡＭＥ＿ＬＥＮＧＴＨ：該当２ビットフィールドは関連したＦＲＵの（ｉ＋１）番目フレームの長さを示す。ＦＲＵ＿ＧＩ＿ＦＲＡＣＴＩＯＮと共にＦＲＵ＿ＦＲＡＭＥ＿ＬＥＮＧＴＨを使用すれば、フレームデュレーションの正確な値が得られる。
ＦＲＵ＿ＧＩ＿ＦＲＡＣＴＩＯＮ：該当３ビットフィールドは関連したＦＲＵの（ｉ＋１）番目フレームのガードインターバルの一部値を示す。ＦＲＵ＿ＧＩ＿ＦＲＡＣＴＩＯＮは＜表７＞に従ってシグナリングされる。
ＲＥＳＥＲＶＥＤ：該当４ビットフィールドは今後の使用のために予約（reserved）される。
次のフィールドは、ＰＬＳ２データをデコーディングするためのパラメータを提供する。
ＰＬＳ２＿ＦＥＣ＿ＴＹＰＥ：該当２ビットフィールドはＰＬＳ２の保護により使用されるＦＥＣタイプを示す。ＦＥＣタイプは＜表１０＞に従ってシグナリングされる。ＬＤＰＣコードに対する詳細な内容は後述する。
Figure 2018504070
ＰＬＳ２＿ＭＯＤ：該当３ビットフィールドはＰＬＳ２により使用される変調タイプを示す。変調タイプは＜表１１＞に従ってシグナリングされる。
Figure 2018504070
ＰＬＳ２＿ＳＩＺＥ＿ＣＥＬＬ：該当１５ビットフィールドは現フレームグループで伝達されるＰＬＳ２に対する全てのコーディングブロックのサイズ（ＱＡＭセルの数に特定される）であるＣｔｏｔａｌ＿ｐａｒｔｉａｌ＿ｂｌｏｃｋを示す。該当値は現フレームグループの全体デュレーションの間一定である。
ＰＬＳ２＿ＳＴＡＴ＿ＳＩＺＥ＿ＢＩＴ：該当１４ビットフィールドは現フレームグループに対するＰＬＳ２−ＳＴＡＴのサイズをビット数で示す。該当値は現フレームグループの全体デュレーションの間一定である。
ＰＬＳ２＿ＤＹＮ＿ＳＩＺＥ＿ＢＩＴ：該当１４ビットフィールドは現フレームグループに対するＰＬＳ２−ＤＹＮのサイズをビット数で示す。該当値は現フレームグループの全体デュレーションの間一定である。
ＰＬＳ２＿ＲＥＰ＿ＦＬＡＧ：該当１ビットフラグはＰＬＳ２反復モードが現フレームグループで使用されるか否かを示す。該当フィールドの値が１に設定されれば、ＰＬＳ２反復モードは活性化される。該当フィールドの値が０に設定されれば、ＰＬＳ２反復モードは不活性化される。
ＰＬＳ２＿ＲＥＰ＿ＳＩＺＥ＿ＣＥＬＬ：該当１５ビットフィールドはＰＬＳ２反復が使用される場合、現フレームグループの毎フレーム毎に伝達されるＰＬＳ２に対する部分コーディングブロックのサイズ（ＱＡＭセルの数で特定される）であるＣｔｏｔａｌ＿ｐａｒｔｉａｌ＿ｂｌｏｃｋを示す。反復が使われない場合、該当フィールドの値は０と同一である。該当値は現フレームグループの全体デュレーションの間一定である。
ＰＬＳ２＿ＮＥＸＴ＿ＦＥＣ＿ＴＹＰＥ：該当２ビットフィールドは次のフレームグループの毎フレームで伝達されるＰＬＳ２に使用されるＦＥＣタイプを示す。ＦＥＣタイプは＜表１０＞に従ってシグナリングされる。
ＰＬＳ２＿ＮＥＸＴ＿ＭＯＤ：該当３ビットフィールドは次のフレームグループの毎フレームで伝達されるＰＬＳ２に使用される変調タイプを示す。変調タイプは＜表１１＞に従ってシグナリングされる。
ＰＬＳ２＿ＮＥＸＴ＿ＲＥＰ＿ＦＬＡＧ：該当１ビットフラグはＰＬＳ２反復モードが次のフレームグループで使用されるか否かを示す。該当フィールドの値が１に設定されれば、ＰＬＳ２反復モードは活性化される。該当フィールドの値が０に設定されれば、ＰＬＳ２反復モードは非活性化される。
ＰＬＳ２＿ＮＥＸＴ＿ＲＥＰ＿ＳＩＺＥ＿ＣＥＬＬ： 該当１５ビットフィールドはＰＬＳ２反復が使用される場合、次のフレームグループの毎フレーム毎に伝達されるＰＬＳ２に対する全体コーディングブロックのサイズ（ＱＡＭセルの数で特定される）であるＣｔｏｔａｌ＿ｆｕｌｌ＿ｂｌｏｃｋを示す。次のフレームグループで反復が使われない場合、該当フィールドの値は０と同一である。該当値は現フレームグループの全体デュレーションの間一定である。
ＰＬＳ２＿ＮＥＸＴ＿ＲＥＰ＿ＳＴＡＴ＿ＳＩＺＥ＿ＢＩＴ：該当１４ビットフィールドは次のフレームグループに対するＰＬＳ２−ＳＴＡＴのサイズをビット数で示す。該当値は現フレームグループで一定である。
ＰＬＳ２＿ＮＥＸＴ＿ＲＥＰ＿ＤＹＮ＿ＳＩＺＥ＿ＢＩＴ：該当１４ビットフィールドは次のフレームグループに対するＰＬＳ２−ＤＹＮのサイズをビット数で示す。該当値は現フレームグループで一定である。
ＰＬＳ２＿ＡＰ＿ＭＯＤＥ：該当２ビットフィールドは現フレームグループでＰＬＳ２に対して追加パリティが提供されるか否かを示す。該当値は現フレームグループの全体デュレーションの間一定である。以下の＜表１２＞は該当フィールドの値を提供する。該当フィールドの値が００に設定されれば、現フレームグループで追加パリティがＰＬＳ２に対して使われない。
Figure 2018504070
ＰＬＳ２＿ＡＰ＿ＳＩＺＥ＿ＣＥＬＬ：該当１５ビットフィールドはＰＬＳ２の追加パリティビットのサイズ（ＱＡＭセルの数で特定される）を示す。該当値は現フレームグループの全体デュレーションの間一定である。
ＰＬＳ２＿ＮＥＸＴ＿ＡＰ＿ＭＯＤＥ：該当２ビットフィールドは次のフレームグループの毎フレーム毎にＰＬＳ２シグナリングに対して追加パリティが提供されるか否かを示す。該当値は現フレームグループの全体デュレーションの間一定である。＜表１２＞は該当フィールドの値を定義する。
ＰＬＳ２＿ＮＥＸＴ＿ＡＰ＿ＳＩＺＥ＿ＣＥＬＬ：該当１５ビットフィールドは次のフレームグループの毎フレーム毎にＰＬＳ２の追加パリティビットのサイズ（ＱＡＭセルの数で特定される）を示す。該当値は現フレームグループの全体デュレーションの間一定である。
ＲＥＳＥＲＶＥＤ：該当３２ビットフィールドは今後の使用のために予約（reserved）される。
ＣＲＣ＿３２：全体ＰＬＳ１シグナリングに適用される３２ビットエラー検出コード
図１４は、本発明の一実施形態に係るＰＬＳ２データを示す。
図１４は、ＰＬＳ２データのＰＬＳ２−ＳＴＡＴデータを示す。ＰＬＳ２−ＳＴＡＴデータはフレームグループ内で同一である一方、ＰＬＳ２−ＤＹＮデータは現フレームに対して特定の情報を提供する。
ＰＬＳ２−ＳＴＡＴデータのフィールドに対し、次に具体的に説明する。
ＦＩＣ＿ＦＬＡＧ：該当１ビットフィールドはＦＩＣが現フレームグループで使用されるか否かを示す。該当フィールドの値が１に設定されれば、ＦＩＣは現フレームで提供される。該当フィールドの値が０に設定されれば、ＦＩＣは現フレームで伝達されない。該当値は現フレームグループの全体デュレーションの間一定である。
ＡＵＸ＿ＦＬＡＧ：該当１ビットフィールドは補助ストリームが現フレームグループで使用されるか否かを示す。該当フィールドの値が１に設定されれば、補助ストリームは現フレームで提供される。該当フィールドの値が０に設定されれば、補助フレームは現フレームで伝達されない。該当値は現フレームグループの全体デュレーションの間一定である。
ＮＵＭ＿ＤＰ：該当６ビットフィールドは現フレーム内で伝達されるデータパイプの数を示す。該当フィールドの値は１から６４の間であり、データパイプの数はＮＵＭ＿ＤＰ＋１である。
ＤＰ＿ＩＤ：該当６ビットフィールドはフィジカルプロファイル内で唯一に識別する。
ＤＰ＿ＴＹＰＥ：該当３ビットフィールドはデータパイプのタイプを示す。これは、以下の＜表１３＞に従ってシグナリングされる。
Figure 2018504070
ＤＰ＿ＧＲＯＵＰ＿ＩＤ：該当８ビットフィールドは現データパイプが関連しているデータパイプグループを識別する。これは、受信機が同一なＤＰ＿ＧＲＯＵＰ＿ＩＤを有するようになる特定サービスと関連しているサービスコンポーネントのデータパイプに接続することに使用できる。
ＢＡＳＥ＿ＤＰ＿ＩＤ：該当６ビットフィールドは管理階層で使用される（ＰＳＩ／ＳＩのような）サービスシグナリングデータを伝達するデータパイプを示す。ＢＡＳＥ＿ＤＰ＿ＩＤにより示すデータパイプは、サービスデータと共にサービスシグナリングデータを伝達するノーマルデータパイプであるか、またはサービスシグナリングデータのみを伝達する専用データパイプでありうる。
ＤＰ＿ＦＥＣ＿ＴＹＰＥ：該当２ビットフィールドは関連したデータパイプにより使用されるＦＥＣタイプを示す。ＦＥＣタイプは、以下の＜表１４＞に従ってシグナリングされる。
Figure 2018504070
ＤＰ＿ＣＯＤ：該当４ビットフィールドは関連したデータパイプにより使用されるコードレート（code rate）を示す。コードレート（code rate）は以下の＜表１５＞に従ってシグナリングされる。
Figure 2018504070
ＤＰ＿ＭＯＤ：該当４ビットフィールドは関連したデータパイプにより使用される変調を示す。変調は以下の＜表１６＞に従ってシグナリングされる。
Figure 2018504070
ＤＰ_ＳＳＤ＿ＦＬＡＧ：該当１ビットフィールドはＳＳＤモードが関連したデータパイプで使用されるか否かを示す。該当フィールドの値が１に設定されれば、ＳＳＤは使用される。該当フィールドの値が０に設定されれば、ＳＳＤは使われない。
次のフィールドはＰＨＹ＿ＰＲＯＦＩＬＥがアドバンスプロファイルを示す０１０と同じ時のみに表れる。
ＤＰ＿ＭＩＭＯ：該当３ビットフィールドはどんなタイプのＭＩＭＯエンコーディング処理が関連したデータパイプに適用されるかを示す。ＭＩＭＯエンコーディング処理のタイプは、以下の＜表１７＞に従ってシグナリングされる。
Figure 2018504070
ＤＰ＿ＴＩ＿ＴＹＰＥ：該当１ビットフィールドはタイムインターリービングのタイプを示す。０の値は１つのタイムインターリービンググループが１つのフレームに該当し、１つ以上のタイムインターリービングブロックを含むことを示す。１の値は１つのタイムインターリービンググループが１つより多いフレームに伝達され、１つのタイムインターリービングブロックのみを含むことを示す。
ＤＰ＿ＴＩ＿ＬＥＮＧＴＨ：該当２ビットフィールド（許容された値は１、２、４、８のみである）の使用は、次のようなＤＰ＿ＴＩ＿ＴＹＰＥフィールド内で設定される値により決定される。
ＤＰ＿ＴＩ＿ＴＹＰＥの値が１に設定されれば、該当フィールドは各々のタイムインターリービンググループがマッピングされるフレームの数であるＰＩを示し、タイムインターリービンググループ当たり１つのタイムインターリービングブロックが存在する（ＮＴＩ＝１）。該当２ビットフィールドに許容されるＰＩの値は、以下の＜表１８＞に定義される。
ＤＰ＿ＴＩ＿ＴＹＰＥの値が０に設定されれば、該当フィールドはタイムインターリービンググループ当たりタイムインターリービングブロックの数ＮＴＩを示し、フレーム当たり１つのタイムインターリービンググループが存在する（ＰＩ＝１）。該当２ビットフィールドに許容されるＰＩの値は以下の＜表１８＞に定義される。
Figure 2018504070
ＤＰ＿ＦＲＡＭＥ＿ＩＮＴＥＲＶＡＬ：該当２ビットフィールドは関連したデータパイプに対するフレームグループ内でフレーム間隔（ＩＪＵＭＰ）を示し、許容された値は１、２、４、８（該当する２ビットフィールドは各々００、０１、１０、１１）である。フレームグループの全てのフレームに表れないデータパイプに対し、該当フィールドの値は順次的なフレームの間の間隔と同一である。例えば、データパイプが１、５、９、１３などのフレームに表れれば、該当フィールドの値は４に設定される。全てのフレームに表れるデータパイプに対し、該当フィールドの値は１に設定される。
ＤＰ＿ＴＩ＿ＢＹＰＡＳＳ：該当１ビットフィールドはタイムインターリーバ５０５０の使用可能性を決定する。データパイプに対してタイムインターリービングが使われないと、該当フィールド値は１に設定される。一方、タイムインターリービングが使われれば、該当フィールド値は０に設定される。
ＤＰ＿ＦＩＲＳＴ＿ＦＲＡＭＥ＿ＩＤＸ：該当５ビットフィールドは現データパイプが発生するスーパーフレームの第１のフレームのインデックスを示す。ＤＰ＿ＦＩＲＳＴ＿ＦＲＡＭＥ＿ＩＤＸの値は０から３１の間である。
ＤＰ＿ＮＵＭ＿ＢＬＯＣＫ＿ＭＡＸ：該当１０ビットフィールドは該当データパイプに対するＤＰ＿ＮＵＭ＿ＢＬＯＣＫＳの最大値を示す。該当フィールドの値はＤＰ＿ＮＵＭ＿ＢＬＯＣＫＳと同一な範囲を有する。
ＤＰ＿ＰＡＹＬＯＡＤ＿ＴＹＰＥ：該当２ビットフィールドは与えられたデータパイプにより伝達されるペイロードデータのタイプを示す。ＤＰ＿ＰＡＹＬＯＡＤ＿ＴＹＰＥは、以下の＜表１９＞に従ってシグナリングされる。
Figure 2018504070
ＤＰ＿ＩＮＢＡＮＤ＿ＭＯＤＥ：該当２ビットフィールドは現データパイプがインバンド（In-band）シグナリング情報を伝達するか否かを示す。インバンド（In-band）シグナリングタイプは、以下の＜表２０＞に従ってシグナリングされる。
Figure 2018504070
ＤＰ＿ＰＲＯＴＯＣＯＬ＿ＴＹＰＥ：該当２ビットフィールドは与えられたデータパイプにより伝達されるペイロードのプロトコルタイプを示す。ペイロードのプロトコルタイプは入力ペイロードタイプが選択されれば、以下の＜表２１＞に従ってシグナリングされる。
Figure 2018504070
ＤＰ＿ＣＲＣ＿ＭＯＤＥ：該当２ビットフィールドはＣＲＣエンコーディングがインプットフォーマットブロックで使用されるか否かを示す。ＣＲＣモードは、以下の＜表２２＞に従ってシグナリングされる。
Figure 2018504070
ＤＮＰ＿ＭＯＤＥ：該当２ビットフィールドはＤＰ＿ＰＡＹＬＯＡＤ＿ＴＹＰＥがＴＳ（‘００’）に設定される場合に関連したデータパイプにより使用されるヌルパケット削除モードを示す。ＤＮＰ＿ＭＯＤＥは、以下の＜表２３＞に従ってシグナリングされる。ＤＰ＿ＰＡＹＬＯＡＤ＿ＴＹＰＥがＴＳ（‘００’）でなければ、ＤＮＰ＿ＭＯＤＥは００の値に設定される。
Figure 2018504070
ＩＳＳＹ＿ＭＯＤＥ：該当２ビットフィールドはＤＰ＿ＰＡＹＬＯＡＤ＿ＴＹＰＥがＴＳ（‘００’）に設定される場合に関連したデータパイプにより使用されるＩＳＳＹモードを示す。ＩＳＳＹ＿ＭＯＤＥは、以下の＜表２４＞に従ってシグナリングされる。ＤＰ＿ＰＡＹＬＯＡＤ＿ＴＹＰＥがＴＳ（‘００’）でなければ、ＩＳＳＹ＿ＭＯＤＥは００の値に設定される。
Figure 2018504070
ＨＣ＿ＭＯＤＥ＿ＴＳ：該当２ビットフィールドはＤＰ＿ＰＡＹＬＯＡＤ＿ＴＹＰＥがＴＳ（‘００’）に設定される場合に関連したデータパイプにより使用されるＴＳヘッダ圧縮モードを示す。ＨＣ＿ＭＯＤＥ＿ＴＳは、以下の＜表２５＞に従ってシグナリングされる。
Figure 2018504070
ＨＣ＿ＭＯＤＥ＿ＩＰ：該当２ビットフィールドはＤＰ＿ＰＡＹＬＯＡＤ＿ＴＹＰＥがＩＰ（‘０１’）で設定される場合にＩＰヘッダ圧縮モードを示す。ＨＣ＿ＭＯＤＥ＿ＩＰは、以下の＜表２６＞に従ってシグナリングされる。
Figure 2018504070
ＰＩＤ：該当１３ビットフィールドはＤＰ＿ＰＡＹＬＯＡＤ＿ＴＹＰＥがＴＳ（‘００’）に設定され、ＨＣ＿ＭＯＤＥ＿ＴＳが０１または１０に設定される場合にＴＳヘッダ圧縮のためのＰＩＤ数を示す。
ＲＥＳＥＲＶＥＤ：該当８ビットフィールドは今後の使用のためにリザーブド(予約）（reserved）される。
次のフィールドは、ＦＩＣ＿ＦＬＡＧが１と同じ時のみに表れる。
ＦＩＣ＿ＶＥＲＳＩＯＮ：該当８ビットフィールドはＦＩＣのバージョンナンバーを示す。
ＦＩＣ＿ＬＥＮＧＴＨ＿ＢＹＴＥ：該当１３ビットフィールドはＦＩＣの長さをバイト単位で示す。
ＲＥＳＥＲＶＥＤ：該当８ビットフィールドは今後の使用のためにリザーブド（reserved）される。
次のフィールドは、ＡＵＸ＿ＦＬＡＧが１と同じ時のみに表れる。
ＮＵＭ＿ＡＵＸ：該当４ビットフィールドは補助ストリームの数を示す。ゼロは補助ストリームが使われないことを示す。
ＡＵＸ＿ＣＯＮＦＩＧ＿ＲＦＵ：該当８ビットフィールドは今後の使用のためにリザーブド（reserved）される。
ＡＵＸ＿ＳＴＲＥＡＭ＿ＴＹＰＥ：該当４ビットは現補助ストリームのタイプを示すための今後の使用のためにリザーブド（reserved）される。
ＡＵＸ＿ＰＲＩＶＡＴＥ＿ＣＯＮＦＩＧ：該当２８ビットフィールドは補助ストリームをシグナリングするための今後の使用のためにリザーブド（reserved）される。
図１５は、本発明の他の一実施形態に係るＰＬＳ２データを示す。
図１５は、ＰＬＳ２データのＰＬＳ２−ＤＹＮを示す。ＰＬＳ２−ＤＹＮデータの値は１つのフレームグループのデュレーションの間変化できる一方、フィールドのサイズは一定である。
ＰＬＳ２−ＤＹＮデータのフィールドの具体的な内容は、次の通りである。
ＦＲＡＭＥ＿ＩＮＤＥＸ：該当５ビットフィールドはスーパーフレーム内で現フレームのフレームインデックスを示す。スーパーフレームの第１のフレームのインデックスは０に設定される。
ＰＬＳ＿ＣＨＡＮＧＥ＿ＣＯＵＮＴＥＲ：該当４ビットフィールドは構成が変化する前のスーパーフレームの数を示す。構成が変化する次のスーパーフレームは該当フィールド内でシグナリングされる値により示す。該当フィールドの値が００００に設定されれば、これは如何なる予定された変化も予測できないことを意味する。例えば、１の値は次のスーパーフレームに変化があるということを示す。
ＦＩＣ＿ＣＨＡＮＧＥ＿ＣＯＵＮＴＥＲ：該当４ビットフィールドは構成（即ち、ＦＩＣのコンテンツ）が変化する前のスーパーフレームの数を示す。構成が変化する次のスーパーフレームは該当フィールド内でシグナリングされる値により示す。該当フィールドの値が００００に設定されれば、これは如何なる予定された変化も予測できないことを意味する。例えば、０００１の値は次のスーパーフレームに変化があることを示す。
ＲＥＳＥＲＶＥＤ：該当１６ビットフィールドは今後の使用のためにリザーブド（reserved）される。
次のフィールドは現フレームで伝達されるデータパイプと関連したパラメータを説明するＮＵＭ＿ＤＰでのループ（loop）に表れる。
ＤＰ＿ＩＤ：該当６ビットフィールドはフィジカルプロファイル内でデータパイプを唯一に示す。
ＤＰ＿ＳＴＡＲＴ：該当１５ビット（または、１３ビット）フィールドは、ＤＰＵアドレッシング（addressing）技法を使用してデータパイプの第１の開始位置を示す。ＤＰ＿ＳＴＡＲＴフィールドは、以下の＜表２７＞に示した通り、フィジカルプロファイル及びＦＦＴサイズによって異なる長さを有する。
Figure 2018504070
ＤＰ＿ＮＵＭ＿ＢＬＯＣＫ：該当１０ビットフィールドは現データパイプに対する現タイムインターリービンググループにおけるＦＥＣブロックの数を示す。ＤＰ＿ＮＵＭ＿ＢＬＯＣＫの値は０から１０２３の間にある。
ＲＥＳＥＲＶＥＤ：該当８ビットフィールドは今後の使用のためにリザーブド（reserved）される。
次のフィールドは、ＥＡＣと関連したＦＩＣパラメータを示す。
ＥＡＣ＿ＦＬＡＧ：該当１ビットフィールドは現フレームでＥＡＣの存在を示す。該当ビットはプリアンブルにおけるＥＡＣ＿ＦＬＡＧと同一な値である。
ＥＡＳ＿ＷＡＫＥ＿ＵＰ＿ＶＥＲＳＩＯＮ＿ＮＵＭ：該当８ビットフィールドは自動活性化指示のバージョンナンバーを示す。
ＥＡＣ＿ＦＬＡＧフィールドが１と同一であれば、次の１２ビットがＥＡＣ＿ＬＥＮＧＴＨ＿ＢＹＴＥフィールドに割り当てられる。ＥＡＣ＿ＦＬＡＧフィールドが０と同一であれば、次の１２ビットがＥＡＣ＿ＣＯＵＮＴＥＲに割り当てられる。
ＥＡＣ＿ＬＥＮＧＴＨ＿ＢＹＴＥ：該当１２ビットフィールドはＥＡＣの長さをバイトで示す。
ＥＡＣ＿ＣＯＵＮＴＥＲ：該当１２ビットフィールドはＥＡＣが到達するフレームの前のフレームの数を示す。
次のフィールドはＡＵＸ＿ＦＬＡＧフィールドが１と同一の場合のみに表れる。
ＡＵＸ＿ＰＲＩＶＡＴＥ＿ＤＹＮ：該当４８ビットフィールドは補助ストリームをシグナリングするための今後の使用のためにリザーブド（reserved）される。該当フィールドの意味は、設定可能なＰＬＳ２−ＳＴＡＴでＡＵＸ＿ＳＴＲＥＡＭ＿ＴＹＰＥの値に依存する。
ＣＲＣ＿３２：全体ＰＬＳ２に適用される３２ビットエラー検出コード。
図１６は、本発明の一実施形態に係るフレームのロジカル（logical）構造を示す。
前述したように、ＰＬＳ、ＥＡＣ、ＦＩＣ、データパイプ、補助ストリーム、ダミーセルは、フレームにおけるＯＦＤＭシンボルのアクティブ（active）キャリアにマッピングされる。ＰＬＳ１及びＰＬＳ２は、最初に１つ以上のＦＳＳにマッピングされる。その後、ＥＡＣが存在していれば、ＥＡＣセルは後続するＰＬＳフィールドにマッピングされる。次に、ＦＩＣが存在していれば、ＦＩＣセルがマッピングされる。データパイプはＰＬＳの次にマッピングされるか、ＥＡＣまたはＦＩＣが存在する場合、ＥＡＣまたはＦＩＣのその後にマッピングされる。タイプ１のデータパイプが最初にマッピングされ、タイプ２のデータパイプが次にマッピングされる。データパイプのタイプの具体的な内容は後述する。一部の場合、データパイプはＥＡＳに対する一部の特殊データまたはサービスシグナリングデータを伝達することができる。補助ストリームまたはストリームは、存在していれば、データパイプを次にマッピングされ、ここには順次にダミーセルが後続する。前述した順序、即ち、ＰＬＳ、ＥＡＣ、ＦＩＣ、データパイプ、補助ストリーム、及びダミーセルの順に全て共にマッピングすれば、フレームでセル容量を正確に詰める。
図１７は、本発明の一実施形態に係るＰＬＳマッピングを示す。
ＰＬＳセルは、ＦＳＳのアクティブ（active）キャリアにマッピングされる。ＰＬＳが占めるセルの数によって、１つ以上のシンボルがＦＳＳに指定され、ＦＳＳの数ＮＦＳＳはＰＬＳ１でのＮＵＭ＿ＦＳＳによりシグナリングされる。ＦＳＳはＰＬＳセルを伝達する特殊なシンボルである。堅固性及び遅延時間（latency）はＰＬＳで重大な事案であるので、ＦＳＳは高いパイロット密度を有しているので高速同期化及びＦＳＳ内での周波数のみのインターポレーション（interpolation：補間）を可能にする。
ＰＬＳセルは、図１７の例に示すように、下向き式でＦＳＳのアクティブ（active）キャリアにマッピングされる。ＰＬＳ１セルは、最初に第１のＦＳＳの第１のセルからセルインデックスの昇順にマッピングされる。ＰＬＳ２セルはＰＬＳ１の最後のセルの直後に後続し、マッピングは第１のＦＳＳの最後のセルインデックスまで下方に続く。必要とするＰＬＳセルの総数が１つのＦＳＳのアクティブ（active）キャリアの数を超過すれば、マッピングは次のＦＳＳに進行され、第１のＦＳＳと完全に同一な方式により続く。
ＰＬＳマッピングが完了した後、データパイプが次に伝達される。ＥＡＣ、ＦＩＣ、または両方とも現フレームに存在していれば、ＥＡＣ及びＦＩＣはＰＬＳとノーマルデータパイプとの間に配置される。
図１８は、本発明の一実施形態に係るＥＡＣマッピングを示す。
ＥＡＣはＥＡＳメッセージを伝達する専用チャネルであり、ＥＡＳに対するデータパイプに連結される。ＥＡＳサポートは提供されるが、ＥＡＣ自体は全てのフレームに存在することもあり、存在しないこともある。ＥＡＣが存在する場合、ＥＡＣはＰＬＳ２セルの直後にマッピングされる。ＰＬＳセルを除いて、ＦＩＣ、データパイプ、補助ストリーム、またはダミーセルのうち、いずれもＥＡＣの前に位置しない。ＥＡＣセルのマッピング手続はＰＬＳと完全に同一である。
ＥＡＣセルは、図１８の例に示すように、ＰＬＳ２の次のセルからセルインデックスの昇順にマッピングされる。ＥＡＳメッセージの大きさによって、図１８に示すように、ＥＡＣセルは少ないシンボルを占めることができる。
ＥＡＣセルは、ＰＬＳ２の最後のセルの直後に後続し、マッピングは最後のＦＳＳの最後のセルインデックスまで下方に続く。必要とするＥＡＣセルの総数が最後のＦＳＳの残っているアクティブ（active）キャリアの数を超過すれば、ＥＡＣマッピングは次のシンボルに進行され、ＦＳＳと完全に同一な方式により続く。この場合、ＥＡＣのマッピングがなされる次のシンボルはノーマルデータシンボルであり、これはＦＳＳより多いアクティブ（active）キャリアを有する。
ＥＡＣマッピングが完了した後、存在していれば、ＦＩＣが次に伝達される。ＦＩＣが送信されなければ（ＰＬＳ２フィールドからシグナリングに）、データパイプがＥＡＣの最後のセルの直後に後続する。
図１９は、本発明の一実施形態に係るＦＩＣマッピングを示す。
（ａ）はＥＡＣ無しでＦＩＣセルのマッピングの例を示し、（ｂ）はＥＡＣと共にＦＩＣセルのマッピングの例を示す。
ＦＩＣは、高速サービス取得及びチャネルスキャンを可能にするために階層間情報（cross-layer information）を伝達する専用チャネルである。該当情報は主にデータパイプの間のチャネルバインディング（channel binding）情報及び各放送社のサービスを含む。高速スキャンのために、受信機はＦＩＣをデコーディングし、放送社ＩＤ、サービス数、ＢＡＳＥ＿ＤＰ＿ＩＤのような情報を取得することができる。高速サービス取得のために、ＦＩＣだけでなく、ベースデータパイプもＢＡＳＥ＿ＤＰ＿ＩＤを用いてデコーディングできる。ベースデータパイプが送信するコンデンツを除いて、ベースデータパイプはノーマルデータパイプと正確に同一な方式によりエンコーディングされてフレームにマッピングされる。したがって、ベースデータパイプに対する追加説明が必要でない。ＦＩＣデータが生成されて管理階層で消費される。ＦＩＣデータのコンデンツは管理階層仕様に説明された通りである。
ＦＩＣデータは選択的であり、ＦＩＣの使用はＰＬＳ２のスタティック（static：静的）な部分でＦＩＣ＿ＦＬＡＧパラメータによりシグナリングされる。ＦＩＣが使われれば、ＦＩＣ＿ＦＬＡＧは１に設定され、ＦＩＣに対するシグナリングフィールドはＰＬＳ２のスタティック（static：静的）な部分で定義される。該当フィールドでシグナリングされることはＦＩＣ＿ＶＥＲＳＩＯＮであり、ＦＩＣ＿ＬＥＮＧＴＨ＿ＢＹＴＥ＿ＦＩＣはＰＬＳ２と同一な変調、コーディング、タイムインターリービングパラメータを使用する。ＦＩＣは、ＰＬＳ２＿ＭＯＤ及びＰＬＳ２＿ＦＥＣのような同一なシグナリングパラメータを共有する。ＦＩＣデータは、存在していれば、ＰＬＳ２の後にマッピングされるか、またはＥＡＣが存在する場合、ＥＡＣの直後にマッピングされる。ノーマルデータパイプ、補助ストリーム、またはダミーセルのうち、いずれもＦＩＣの前に位置しない。ＦＩＣセルをマッピングする方法はＥＡＣと完全に同一であり、これはまたＰＬＳと同一である。
ＰＬＳの後のＥＡＣが存在しない場合、ＦＩＣセルは（ａ）の例に示したように、ＰＬＳ２の次のセルからセルインデックスの昇順にマッピングされる。ＦＩＣデータサイズによって、（ｂ）に示したように、ＦＩＣセルは数個のシンボルに対してマッピングされる。
ＦＩＣセルはＰＬＳ２の最後のセルの直後に後続し、マッピングは最後のＦＳＳの最後のセルインデックスまで下方に続く。必要なＦＩＣセルの総数が最後のＦＳＳの残っているアクティブ（active）キャリアの数を超過すれば、残りのＦＩＣセルのマッピングは次のシンボルに進行され、これはＦＳＳと完全に同一な方式により続く。この場合、ＦＩＣがマッピングされる次のシンボルはノーマルデータシンボルであり、これはＦＳＳより多いアクティブ（active）キャリアを有する。
ＥＡＳメッセージが現フレームで送信されれば、ＥＡＣはＦＩＣより先にマッピングされ、（ｂ）に示したように、ＥＡＣの次のセルからＦＩＣセルはセルインデックスの昇順にマッピングされる。
ＦＩＣマッピングが完了した後、１つ以上のデータパイプがマッピングされ、その後、存在していれば、補助ストリーム、ダミーセルが後続する。
図２０は、本発明の一実施形態に係るデータパイプのタイプを示す。
（ａ）はタイプ１のデータパイプを示し、（ｂ）はタイプ２のデータパイプを示す。
先行するチャネル、即ちＰＬＳ、ＥＡＣ、ＦＩＣがマッピングされた後、データパイプのセルがマッピングされる。データパイプはマッピング方法によって２タイプのうちの１つに分類される。
タイプ１のデータパイプ：データパイプがＴＤＭによりマッピングされる。
タイプ２のデータパイプ：データパイプがＦＤＭによりマッピングされる。
データパイプのタイプはＰＬＳ２のスタティック（static：静的）な部分でＤＰ＿ＴＹＰＥフィールドにより示す。図２０は、タイプ１のデータパイプ及びタイプ２のデータパイプのマッピング順序を示す。タイプ１のデータパイプは、まずセルインデックスの昇順にマッピングされた後、最後のセルインデックスに到達した後、シンボルインデックスが１ずつ増加する。次のシンボル内で、データパイプはｐ＝０を手始めにセルインデックスの昇順に続けてマッピングされる。１つのフレームで共にマッピングされる複数のデータパイプと共に、各々のタイプ１のデータパイプはデータパイプのＴＤＭと類似するように時間にグルーピングされる。
タイプ２のデータパイプは、まずシンボルインデックスの昇順にマッピングされ、フレームの最後のＯＦＤＭシンボルに到達した後、セルインデックスは１ずつ増加し、シンボルインデックスは第１の使用可能シンボルに戻った後、そのシンボルインデックスから増加する。１つのフレームで複数のデータパイプをマッピングした後、各々のタイプ２のデータパイプはデータパイプのＦＤＭと類似するように周波数にグルーピングされる。
タイプ１のデータパイプ及びタイプ２のデータパイプは、必要な時、フレームで共存できるが、タイプ１のデータパイプが常にタイプ２のデータパイプに先行するという制限がある。タイプ１及びタイプ２のデータパイプを伝達するＯＦＤＭセルの総数はデータパイプの送信に使用することができるＯＦＤＭセルの総数を超過できない。
Figure 2018504070
この際、ＤＤＰ１はタイプ１のデータパイプが占めるＯＦＤＭセルの数に該当し、ＤＤＰ２はタイプ２のデータパイプが占めるセルの数に該当する。ＰＬＳ、ＥＡＣ、ＦＩＣが全てタイプ１のデータパイプと同様の方式によりマッピングされるので、ＰＬＳ、ＥＡＣ、ＦＩＣは全て“タイプ１のマッピング規則”に従う。したがって、概してタイプ１のマッピングが常にタイプ２のマッピングに先行する。
図２１は、本発明の一実施形態に係るデータパイプマッピングを示す。
（ａ）はタイプ１のデータパイプをマッピングするためのＯＦＤＭセルのアドレッシングを示し、（ｂ）はタイプ２のデータパイプをマッピングするためのＯＦＤＭセルのアドレッシングを示す。
タイプ１のデータパイプ（０，．．．，ＤＤＰ１−１）をマッピングするためのＯＦＤＭセルのアドレッシングはタイプ１のデータパイプのアクティブ（active）データセルに対して定義される。アドレッシング方式は各々のタイプ１のデータパイプに対するタイムインターリービングからのセルがアクティブ（active）データセルに割り当てられる順序を定義する。また、アドレッシング方式はＰＬＳ２のダイナミック（dynamic：動的）部分でデータパイプの位置をシグナリングすることに使用される。
ＥＡＣ及びＦＩＣ無しで、アドレス０は最後のＦＳＳでＰＬＳを伝達する最後のセルに後続するセルをいう。ＥＡＣが送信され、ＦＩＣが該当するフレームになければ、アドレス０はＥＡＣを伝達する最後のセルに後続するセルをいう。ＦＩＣが該当するフレームで送信されれば、アドレス０はＦＩＣを伝達する最後のセルに後続するセルをいう。タイプ１のデータパイプに対するアドレス０は（ａ）に示したような２つの互いに異なる場合を考慮して算出できる。（ａ）の例で、ＰＬＳ、ＥＡＣ、ＦＩＣは全て送信されると仮定する。ＥＡＣとＦＩＣのうちの１つまたは全てが省略される場合への拡張は自明である。（ａ）の左側に示したように、ＦＩＣまで全てのセルをマッピングした後、ＦＳＳに残っているセルがあれば、タイプ２のデータパイプ（０，．．．，ＤＤＰ２−１）をマッピングするためのＯＦＤＭセルのアドレッシングはタイプ２のデータパイプのアクティブ（active）データセルに対して定義される。アドレッシング方式は各々のタイプ２のデータパイプに対するタイムインターリービングからのセルがアクティブ（active）データセルに割り当てられる順序を定義する。また、アドレッシング方式はＰＬＳ２のダイナミック（dynamic：動的）部分でデータパイプの位置をシグナリングすることに使用される。
（ｂ）に示すように、３種類の若干異なる場合が可能である。（ｂ）の左側に示した第１の場合に、最後のＦＳＳにあるセルはタイプ２のデータパイプマッピングに使用できる。中央に示した第２の場合に、ＦＩＣはノーマルシンボルのセルを占めるが、該当シンボルでのＦＩＣセルの数はＣＦＳＳより大きくない。（ｂ）の右側に示した第３の場合は該当シンボルにマッピングされたＦＩＣセルの数がＣＦＳＳを超過する点を除いて、第２の場合と同一である。
ＰＬＳ、ＥＡＣ、ＦＩＣがタイプ１のデータパイプと同一な“タイプ１のマッピング規則”に従うので、タイプ１のデータパイプがタイプ２のデータパイプに先行する場合への拡張は自明である。
データパイプユニット（ＤＰＵ）は、フレームにおけるデータセルをデータパイプに割り当てる基本単位である。
ＤＰＵはフレームにおけるデータパイプの位置を探し出すためのシグナリング単位として定義される。セルマッパー７０１０は、各々のデータパイプに対してタイムインターリービングにより生成されたセルをマッピングすることができる。タイムインターリーバ５０５０は一連のタイムインターリービングブロックを出力し、各々のタイムインターリービングブロックはＸＦＥＣＢＬＯＣＫの可変数を含み、これは結局、セルの集合で構成される。ＸＦＥＣＢＬＯＣＫにおけるセルの数ＮｃｅｌｌｓはＦＥＣＢＬＯＣＫサイズ、Ｎｌｄｐｃ、コンステレーションシンボル当たり送信されるビット数に依存する。ＤＰＵは与えられたフィジカルプロファイルでサポートされるＸＦＥＣＢＬＯＣＫにおけるセルの数Ｎｃｅｌｌｓの全ての可能な値の最大公約数として定義される。セルでのＤＰＵの長さはＬＤＰＵとして定義される。各々のフィジカルプロファイルはＦＥＣＢＬＯＣＫサイズの互いに異なる組合せ及びコンステレーションシンボル当たり異なるビット数をサポートするので、ＬＤＰＵはフィジカルプロファイルに基づいて定義される。
図２２は、本発明の一実施形態に係るＦＥＣ構造を示す。
図２２は、ビットインターリービングの前の本発明の一実施形態に係るＦＥＣ構造を示す。前述したように、データＦＥＣエンコーダは外部コーディング（ＢＣＨ）及び内部コーディング（ＬＤＰＣ）を用いてＦＥＣＢＬＯＣＫ手続を生成するために入力ＢＢＦにＦＥＣエンコーディングを実行することができる。図示されたＦＥＣ構造はＦＥＣＢＬＯＣＫに該当する。また、ＦＥＣＢＬＯＣＫ及びＦＥＣ構造はＬＤＰＣコードワードの長さに該当する同一な値を有する。
図２２に示すように、ＢＣＨエンコーディングが各々のＢＢＦ（Ｋｂｃｈビット）に適用された後、ＬＤＰＣエンコーディングがＢＣＨ−エンコーディングされたＢＢＦ（Ｋｌｄｐｃビット＝Ｎｂｃｈビット）に適用される。
Ｎｌｄｐｃの値は６４８００ビット（ロングＦＥＣＢＬＯＣＫ）または１６２００ビット（ショートＦＥＣＢＬＯＣＫ）である。
以下の＜表２８＞及び＜表２９＞はロングＦＥＣＢＬＯＣＫ及びショートＦＥＣＢＬＯＣＫの各々に対するＦＥＣエンコーディングパラメータを示す。
Figure 2018504070
Figure 2018504070
ＢＣＨエンコーディング及びＬＤＰＣエンコーディングの具体的な動作は、次の通りである。
１２−エラー訂正ＢＣＨコードがＢＢＦの外部エンコーディングに使用される。ショートＦＥＣＢＬＯＣＫ及びロングＦＥＣＢＬＯＣＫに対するＢＢＦ生成多項式は全ての多項式を掛けることによって得られる。
ＬＤＰＣコードは外部ＢＣＨエンコーディングの出力をエンコーディングすることに使用される。完成されたＢｌｄｐｃ（ＦＥＣＢＬＯＣＫ）を生成するために、Ｐｌｄｐｃ（パリティビット）が各々のＩｌｄｐｃ（ＢＣＨ−エンコーディングされたＢＢＦ）から組織的にエンコーディングされ、Ｉｌｄｐｃに添付される。完成されたＢｌｄｐｃ（ＦＥＣＢＬＯＣＫ）は次の数式で表現される。
Figure 2018504070
ロングＦＥＣＢＬＯＣＫ及びショートＦＥＣＢＬＯＣＫに対するパラメータは前記の＜表２８＞及び＜表２９＞に各々与えられる。
ロングＦＥＣＢＬＯＣＫに対してＮｌｄｐｃ−Ｋｌｄｐｃパリティビットを計算する具体的な手続は、次の通りである。
１）パリティビット初期化
Figure 2018504070
２）パリティーチェックマトリックスのアドレスの第１の行で特定されたパリティビットアドレスで第１の情報ビットｉＯ累算（accumulate）。パリティーチェックマトリックスのアドレスの詳細な内容は後述する。例えば、割合１３／１５に対し、
Figure 2018504070
３）次の３５９個の情報ビットｉｓ、ｓ＝１，２，．．．，３５９に対し、次の数式を用いてパリティビットアドレスでｉｓ累算（accumulate）。
Figure 2018504070
ここで、ｘは第１のビットｉ０に該当するパリティビット累算器のアドレスを示し、Ｑｌｄｐｃはパリティーチェックマトリックスのアドレッサで特定されたコードレート（code rate）依存定数である。前記の例である、割合１３／１５に対する、したがって情報ビットｉ１に対するＱｌｄｐｃ＝２４に引続き、次の動作が実行される。
Figure 2018504070
４）３６１番目の情報ビットｉ３６０に対し、パリティビット累算器のアドレスはパリティーチェックマトリックスのアドレスの第２の行に与えられる。同様の方式により、次の３５９個の情報ビットｉｓ、ｓ＝３６１，３６２，．．．，７１９に対するパリティビット累算器のアドレスは＜数式６＞を用いて得られる。ここで、ｘは情報ビットｉ３６０に該当するパリティビット累算器のアドレス、即ちパリティーチェックマトリックスの第２の行のエントリーを示す。
５）同様の方式で、３６０個の新たな情報ビットの全てのグループに対し、パリティーチェックマトリックスのアドレスからの新たな行はパリティビット累算器のアドレスを求めることに使用される。
全ての情報ビットが用いられた後、最終パリティビットが次の通り得られる。
６）ｉ＝１から始めて次の動作を順次に実行
Figure 2018504070
ここで、ｐｉ、ｉ＝０，１，．．．，Ｎｌｄｐｃ−Ｋｌｄｐｃ−１の最終コンデンツはパリティビットｐｉと同一である。
Figure 2018504070
＜表３０＞を＜表３１＞に取り替えて、ロングＦＥＣＢＬＯＣＫに対するパリティーチェックマトリックスのアドレスをショートＦＥＣＢＬＯＣＫに対するパリティーチェックマトリックスのアドレスに取り替えることを除いて、ショートＦＥＣＢＬＯＣＫに対する該当ＬＤＰＣエンコーディング手続はロングＦＥＣＢＬＯＣＫに対するtＬＤＰＣエンコーディング手続に従う。
Figure 2018504070
図２３は、本発明の一実施形態に係るビットインターリービングを示す。
ＬＤＰＣエンコーダの出力はビットインターリービングされるが、これはＱＣＢ（quasi-cyclic block）インターリービング及び内部グループインターリービングが後続するパリティインターリービングで構成される。
（ａ）はＱＣＢインターリービングを示し、（ｂ）は内部グループインターリービングを示す。
ＦＥＣＢＬＯＣＫはパリティインターリービングできる。パリティインターリービングの出力で、ＬＤＰＣコードワードはロングＦＥＣＢＬＯＣＫで１８０個の隣接するＱＣＢで構成され、ショートＦＥＣＢＬＯＣＫで４５個の隣接するＱＣＢで構成される。ロングまたはショートＦＥＣＢＬＯＣＫにおける各々のＱＣＢは３６０ビットで構成される。パリティインターリービングされたＬＤＰＣコードワードはＱＣＢインターリービングによりインターリービングされる。ＱＣＢインターリービングの単位はＱＣＢである。パリティインターリービングの出力でのＱＣＢは、図２３に示すように、ＱＣＢインターリービングによりパーミュテーションされるが、ここで、ＦＥＣＢＬＯＣＫ長さによってＮｃｅｌｌｓ＝６４８００／ηＭＯＤまたは１６２００／ηＭＯＤである。ＱＣＢインターリービングパターンは変調タイプ及びＬＤＰＣコードレート（code rate）の各組合せに固有である。
ＱＣＢインターリービングの後に、内部グループインターリービングが以下の＜表３２＞に定義された変調タイプ及び次数（ηＭＯＤ）によって実行される。１つの内部グループに対するＱＣＢの数ＮＱＣＢ＿ＩＧも定義される。
Figure 2018504070
内部グループインターリービング過程はＱＣＢインターリービング出力のＮＱＣＢ＿ＩＧ個のＱＣＢで実行される。内部グループインターリービングは３６０個の列及びＮＱＣＢ＿ＩＧ個の行を用いて内部グループのビットを記入し読み取る過程を含む。記入動作で、ＱＣＢインターリービング出力からのビットが行方向に記入される。読取動作は列方向に実行されて各行でｍ個のビットを読み取る。ここで、ｍはＮＵＣの場合１と同一であり、ＮＵＱの場合２と同一である。
図２４は、本発明の一実施形態に係るセル−ワードデマルチプレキシングを示す。
図２４で、（ａ）は８及び１２ｂｐｃｕ ＭＩＭＯに対するセル−ワードデマルチプレキシングを示し、（ｂ）は１０ｂｐｃｕ ＭＩＭＯに対するセル−ワードデマルチプレキシングを示す。
ビットインターリービング出力の各々のセルワード（ｃ０，ｌ，ｃ１，ｌ，．．． ，ｃｎｍｏｄ−１，ｌ）は１つのＸＦＥＣＢＬＯＣＫに対するセル−ワードデマルチプレキシング過程を説明する（ａ）に示したように（ｄ１，０，m，ｄ１，１，ｍ，．．．，ｄ１，ｎｍｏｄ−１，ｍ）及び（ｄ２，０，m，ｄ２，１，ｍ，．．．，ｄ２，ｎｍｏｄ−１，m）にデマルチプレキシングされる。
ＭＩＭＯエンコーディングのために異なるタイプのＮＵＱを用いる１０ｂｐｃｕ ＭＩＭＯの場合に、ＮＵＱ−１０２４に対するビットインターリーバが再使用される。ビットインターリーバ出力の各々のセルワード（ｃ０，ｌ，ｃ１，ｌ，．．．，ｃ９，ｌ）は（ｂ）に示したように（ｄ１，０，ｍ，ｄ１，１，ｍ，．．．，ｄ１，３，ｍ）及び（ｄ２，０，ｍ，ｄ２，１，ｍ，．．．，ｄ２，５，ｍ）にデマルチプレキシングされる。
図２５は、本発明の一実施形態に係るタイムインターリービングを示す。
（ａ）から（ｃ）はタイムインターリービングモードの例を示す。
タイムインターリーバはデータパイプレベルで動作する。タイムインターリービングのパラメータは各々のデータパイプに対して異に設定できる。
ＰＬＳ２−ＳＴＡＴデータの一部に表れる次のパラメータはタイムインターリービングを構成する。
ＤＰ＿ＴＩ＿ＴＹＰＥ（許容された値：０または１）：タイムインターリービングモードを示す。０はタイムインターリービンググループ当たり複数のタイムインターリービングブロック（１つ以上のタイムインターリービングブロック）を有するモードを示す。この場合、１つのタイムインターリービンググループは１つのフレームに（フレーム間インターリービング無しで）直接マッピングされる。１はタイムインターリービンググループ当たり１つのタイムインターリービングブロックのみを有するモードを示す。この場合、タイムインターリービングブロックは１つ以上のフレームに亘って拡散される（フレーム間インターリービング）。
ＤＰ＿ＴＩ＿ＬＥＮＧＴＨ：ＤＰ＿ＴＩ＿ＴＹＰＥ＝‘０’であれば、該当パラメータはタイムインターリービンググループ当たりタイムインターリービングブロックの数ＮＴＩである。ＤＰ＿ＴＩ＿ＴＹＰＥ＝‘１’の場合、該当パラメータは１つのタイムインターリービンググループから拡散されるフレームの数ＰＩである。
ＤＰ＿ＮＵＭ＿ＢＬＯＣＫ＿ＭＡＸ（許容された値：０乃至１０２３）：タイムインターリービンググループ当たりＸＦＥＣＢＬＯＣＫの最大数を示す。
ＤＰ＿ＦＲＡＭＥ＿ＩＮＴＥＲＶＡＬ（許容された値：１、２、４、８）：与えられたフィジカルプロファイルの同一なデータパイプを伝達する２つの順次的なフレーム間のフレームの数ＩＪＵＭＰを示す。
ＤＰ＿ＴＩ＿ＢＹＰＡＳＳ（許容された値：０または１）：タイムインターリービングがデータフレームに用いられなければ、該当パラメータは１に設定される。タイムインターリービングが用いられれば、０に設定される。
さらに、ＰＬＳ２−ＤＹＮデータからのパラメータＤＰ＿ＮＵＭ＿ＢＬＯＣＫはデータグループの１つのタイムインターリービンググループにより伝達されるＸＦＥＣＢＬＯＣＫの数を示す。
タイムインターリービングがデータフレームに用いられなければ、次のタイムインターリービンググループ、タイムインターリービング動作、タイムインターリービングモードは考慮されない。しかしながら、スケジューラからのダイナミック（dynamic：動的）構成情報のためのディレイコンペンセーション（delay compensation：遅延補償）ブロックは相変らず必要である。各々のデータパイプで、ＳＳＤ／ＭＩＭＯエンコーディングから受信したＸＦＥＣＢＬＯＣＫはタイムインターリービンググループにグルーピングされる。即ち、各々のタイムインターリービンググループは整数個のＸＦＥＣＢＬＯＣＫの集合であり、ダイナミック（dynamic：動的）に変化する数のＸＦＥＣＢＬＯＣＫを含む。インデックスｎのタイムインターリービンググループにあるＸＦＥＣＢＬＯＣＫの数はＮｘＢＬＯＣＫ＿Ｇｒｏｕｐ（ｎ）で示し、ＰＬＳ２−ＤＹＮデータでＤＰ＿ＮＵＭ＿ＢＬＯＣＫにシグナリングされる。この際、ＮｘＢＬＯＣＫ＿Ｇｒｏｕｐ（ｎ）は最小値０から最も大きい値が１０２３である最大値ＮｘＢＬＯＣＫ＿Ｇｒｏｕｐ＿ＭＡＸ（ＤＰ＿ＮＵＭ＿ＢＬＯＣＫ＿ＭＡＸに該当）まで変化することができる。
各々のタイムインターリービンググループは１つのフレームに直接マッピングされるか、またはＰＩ個のフレームに亘って拡散される。また、各々のタイムインターリービンググループは１つ以上（ＮＴＩ個）のタイムインターリービングブロックに分離される。ここで、各々のタイムインターリービングブロックはタイムインターリーバメモリの１つの使用に該当する。タイムインターリービンググループ内のタイムインターリービングブロックは若干の異なる数のＸＦＥＣＢＬＯＣＫを含むことができる。タイムインターリービンググループが複数のタイムインターリービングブロックに分離されれば、タイムインターリービンググループは１つのフレームのみに直接マッピングされる。以下の＜表３３＞に示したように、タイムインターリービングには３種類のオプションがある（タイムインターリービングを省略する追加オプション除外）。
Figure 2018504070

各々のデータパイプで、タイムインターリービングメモリは入力されたＸＦＥＣＢＬＯＣＫ（ＳＳＤ／ＭＩＭＯエンコーディングブロックから出力されたＸＦＥＣＢＬＯＣＫ）を格納する。入力されたＸＦＥＣＢＬＯＣＫは、
Figure 2018504070
として定義されると仮定する。ここで、
Figure 2018504070
はｎ番目タイムインターリービンググループのｓ番目タイムインターリービングブロックでｒ番目ＸＦＥＣＢＬＯＣＫのｑ番目セルであり、次のようなＳＳＤ及びＭＩＭＯエンコーディングの出力を示す。
Figure 2018504070
また、タイムインターリーバ５０５０から出力されたＸＦＥＣＢＬＯＣＫは
Figure 2018504070
として定義されると仮定する。ここで、
Figure 2018504070
はｎ番目タイムインターリービンググループのｓ番目タイムインターリービングブロックでｉ番目
Figure 2018504070
出力セルである。
一般に、タイムインターリーバはフレーム生成過程の以前にデータパイプデータに対するバッファとしても作用する。これは、各々のデータパイプに対して２つのメモリバンクで達成される。第１のタイムインターリービングブロックは第１のバンクに記入される。第１のバンクで読取される間、第２のタイムインターリービングブロックが第２のバンクに記入される。
タイムインターリービングはツイストされた行−列ブロックインターリーバである。ｎ番目タイムインターリービンググループのｓ番目タイムインターリービングブロックに対し、列の数Ｎｃが
Figure 2018504070
と同一である一方、タイムインターリービングメモリの行の数Ｎｒはセルの数Ｎｃｅｌｌと同一である（即ち、Ｎｒ＝Ｎｃｅｌｌ）。
図２６は、本発明の一実施形態に係るツイストされた行−列ブロックインターリーバの基本動作を示す。
図２６（ａ）は、タイムインターリーバで記入動作を示し、図２６（ｂ）は、タイムインターリーバで読取動作を示す。（ａ）に示したように、１番目のＸＦＥＣＢＬＯＣＫは、タイムインターリービングメモリの１番目の列に列方向に記入され、２番目のＸＦＥＣＢＬＯＣＫは、次の列に記入され、このような動作が続く。そして、インターリービングアレイで、セルが対角線方向に読み取られる。（ｂ）に示したように、１番目の行から（最も左側の列を始めとして行に沿って右に）最後の行まで対角線方向の読取が進まれる間、
Figure 2018504070
個のセルが読み取られる。具体的に、
Figure 2018504070

が順次読み取られるタイムインターリービングメモリセル位置と仮定すれば、このようなインターリービングアレイでの読取動作は、下記の式のように、行インデックス
Figure 2018504070
、列インデックス
Figure 2018504070
、関連したツイストパラメータ
Figure 2018504070
を算出することによって実行される。
Figure 2018504070
ここで、
Figure 2018504070
に関係なく、対角線方向読取過程に対する共通シフト値であり、シフト値は、下記の式のように、ＰＬＳ２−ＳＴＡＴで与えられた
Figure 2018504070
により決定される。
Figure 2018504070
結果的に、読み取られるセル位置は、座標
Figure 2018504070
により算出される。
図２７は、本発明の他の一実施形態に係るツイストされた行−列ブロックインターリーバの動作を示す。
より具体的に、図２７は、
Figure 2018504070
であるとき、仮想ＸＦＥＣＢＬＯＣＫを含むそれぞれのタイムインターリービンググループに対するタイムインターリービングメモリでインターービングアレイを示す。
変数
Figure 2018504070
より小さいか、同じであろう。したがって、

Figure 2018504070
に関係なく、受信機側で単一メモリデインターリービングを達成するために、ツイストされた行−列ブロックインターリーバ用インターリービングアレイは、仮想ＸＦＥＣＢＬＯＣＫをタイムインターリービングメモリに挿入することにより、
Figure 2018504070
の大きさに設定され、読取過程は、次の式のようになされる。
Figure 2018504070
タイムインターリービンググループの数は、３に設定される。タイムインターリーバのオプションは、ＤＰ＿ＴＩ＿ＴＹＰＥ＝‘０’、ＤＰ＿ＦＲＡＭＥ＿ＩＮＴＥＲＶＡＬ＝‘１’、ＤＰ＿ＴＩ＿ＬＥＮＧＴＨ＝‘１’、すなわち、ＮＴＩ＝１、ＩＪＵＭＰ＝１、ＰＩ＝１によりＰＬＳ２−ＳＴＡＴデータでシグナリングされる。各々Ｎｃｅｌｌｓ＝３０であるＸＦＥＣＢＬＯＣＫのタイムインターリービンググループ当たりの数は、それぞれのＮｘＢＬＯＣＫ＿ＴＩ（０、０）＝３、ＮｘＢＬＯＣＫ＿ＴＩ（１、０）＝６、ＮｘＢＬＯＣＫ＿ＴＩ（２、０）＝５によりＰＬＳ２−ＤＹＮデータでシグナリングされる。ＸＦＥＣＢＬＯＣＫの最大数は、ＮｘＢＬＯＣＫ＿Ｇｒｏｕｐ＿ＭＡＸによりＰＬＳ２−ＳＴＡＴデータでシグナリングされ、これは、
Figure 2018504070
に繋がる。
図２８は、本発明の一実施形態に係るツイストされた行−列ブロックインターリーバの対角線方向読取パターンを示す。
より具体的に、図２８は、パラメータ
Figure 2018504070
及びＳｓｈｉｆｔ＝（７−１）／２＝３を有するそれぞれのインターリービングアレイからの対角線方向読取パターンを示す。このとき、上記に類似コードで示した読取過程で、
Figure 2018504070
であれば、Ｖｉの値が省略され、Ｖｉの次の計算値が使用される。
図２９は、本発明の一実施形態に係るそれぞれのインターリービングアレイからのインターリービングされたＸＦＥＣＢＬＯＣＫを示す。
図２９は、パラメータ
Figure 2018504070
及びＳｓｈｉｆｔ＝３を有するそれぞれのインターリービングアレイからインターリービングされたＸＦＥＣＢＬＯＣＫを示す。
図３０は本発明の一実施形態に係る同期及び復調（synchronization & demodulation）モジュールを示す図である。
図３０に図示された同期及び復調モジュールは、図９で説明した同期及び復調モジュールの一実施形態に該当する。また、図３０に図示された同期及び復調モジュールは、図９で説明したウェーブフォームジェネレーションモジュールの逆動作を遂行することができる。
図３０に示すように、本発明の一実施形態に係る同期及び復調モジュールは、ｍ個のＲｘアンテナを使用する受信装置の同期及び復調モジュールの実施形態であって、ｍ個のパス（path）だけ入力された信号を復調して出力するためのｍ個の処理ブロックを含むことができる。ｍ個の処理ブロックは全て同一な処理過程を遂行することができる。以下、ｍ個の処理ブロックのうち、第１の処理ブロック３００００の動作を中心に説明する。
第１の処理ブロック３００００は、チューナー３０１００、ＡＤＣブロック３０２００、プリアンブルディテクタ（preamble dectector）３０３００、ガードシーケンスディテクタ（guard sequence detector）３０４００、ウェーブフォームトランスフォーム（waveform transform）ブロック３０５００、時間／周波数同期化（Time／freq sync）ブロック３０６００、レファレンスシグナルディテクタ（Reference signal detector）３０７００、チャネルイコライザー（Channel equalizer）３０８００、及びインバースウェーブフォームトランスフォーム（Inverse waveform transform）ブロック３０９００を含むことができる。
チューナー３０１００は、所望の周波数帯域を選択し、受信した信号の大きさを補償してＡＤＣブロック３０２００に出力することができる。
ＡＤＣブロック３０２００は、チューナー３０１００から出力された信号をディジタル信号に変換することができる。
プリアンブルディテクタ３０３００は、ディジタル信号に対して受信装置に対応するシステムの信号か否かを確認するためにプリアンブル（または、プリアンブル信号またはプリアンブルシンボル）をディテクティングすることができる。この場合、プリアンブルディテクタ３０３００はプリアンブルを通じて受信される基本的な送信パラメータ（transmission parameter）を復号することができる。
ガードシーケンスディテクタ３０４００は、ディジタル信号内のガードシーケンス（guard sequence）をディテクティング（検出）することができる。時間／周波数同期化ブロック３０６００は、ディテクティングされたガードシーケンスを用いて時間／周波数同期化（time/frequency synchronization）を遂行することができ、チャネルイコライザー３０８００はディテクティングされたガードシーケンスを用いて受信／復元されたシーケンスを通じてチャネルを推定することができる。
ウェーブフォームトランスフォームブロック３０５００は、送信側でインバースウェーブフォームトランスフォームが遂行された場合、これに対する逆変換過程を遂行することができる。本発明の一実施形態に係る放送送受信システムが多重キャリアシステム（multi-carrier system）の場合、ウェーブフォームトランスフォームブロック３０５００はＦＦＴ変換過程を遂行することができる。また、本発明の一実施形態に係る放送送受信システムが単一キャリアシステム（single carrier system）の場合、受信された時間領域の信号が周波数領域で処理するために使用されるか、または時間領域で全て処理される場合、ウェーブフォームトランスフォームブロック３０５００は使用されないことがある。
時間／周波数同期化ブロック３０６００は、プリアンブルディテクタ３０３００、ガードシーケンスディテクタ３０４００、レファレンスシグナルディテクタ３０７００の出力データを受信し、検出された信号に対してガードシーケンスディテクション（guard sequence detection）、ブロックウィンドウポジショニング（block window positioning）を含む時間同期化及びキャリア周波数同期化を遂行することができる。この際、周波数同期化のために時間／周波数同期化ブロック３０６００は、ウェーブフォームトランスフォームブロック３０５００の出力信号をフィードバックして使用することができる。
レファレンスシグナルディテクタ３０７００は、受信されたレファレンスシグナルを検出することができる。したがって、本発明の一実施形態に係る受信装置は同期化を遂行するか、またはチャネル推定（channel estimation）を遂行することができる。
チャネルイコライザー３０８００は、ガードシーケンスやレファレンスシグナルから各送信アンテナから各受信アンテナまでの送信チャネルを推定し、推定されたチャネルを用いて各受信データに対するチャネル補償（equalization）を遂行することができる。
インバースウェーブフォームトランスフォームブロック３０９００は、同期及びチャネル推定／補償を効率的に遂行するために、ウェーブフォームトランスフォームブロック３０５００がウェーブフォームトランスフォームを遂行した場合、また元の受信データドメイン（domain）に復元してくれる役割を遂行することができる。本発明の一実施形態に係る放送送受信システムが単一キャリアシステムの場合、ウェーブフォームトランスフォームブロック３０５００は同期／チャネル推定／補償を周波数領域で遂行するためにＦＦＴを遂行することができ、インバースウェーブフォームトランスフォームブロック３０９００はチャネル補償が完了した信号に対してＩＦＦＴを遂行することで、送信されたデータシンボル（data symbol）を復元することができる。本発明の一実施形態に係る放送送受信システムが多重キャリアシステムの場合、インバースウェーブフォームトランスフォームブロック３０９００は使用されないこともある。
また、前述したブロックは設計者の意図によって省略されるか、類似または同一機能を有する他のブロックにより取替できる。
図３１は、本発明の一実施形態に係るフレームパーシングモジュールを示す図である。
図３１に図示されたフレームパーシングモジュールは、図９で説明したフレームパーシングモジュールの一実施形態に該当する。
図３１に示すように、本発明の一実施形態に係るフレームパーシングモジュールは、少なくとも１つ以上のブロックデインターリーバ３１０００及び少なくとも１つ以上のセルデマッパー３１１００を含むことができる。
ブロックデインターリーバ３１０００はｍ個の受信アンテナの各データパスに入力されて同期及び復調モジュールで処理されたデータに対して、各シグナルブロック単位でデータに対するデインターリービングを遂行することができる。この場合、図８で説明したように、送信側でペアワイズインターリービング（pair-wise interleaving）が遂行された場合、ブロックデインターリーバ３１０００は各入力パス（path）に対して連続した２つのデータを１つのペアに処理することができる。したがって、ブロックデインターリーバ３１０００はデインターリービングを遂行した場合にも連続した２つの出力データを出力することができる。また、ブロックデインターリーバ３１０００は送信端で遂行したインターリービング過程の逆過程を遂行して元のデータ順に出力することができる。
セルデマッパー３１１００は、受信された信号フレームからコモンデータに対応するセル、データパイプに対応するセル、及びＰＬＳデータに対応するセルを抽出することができる。必要の場合、セルデマッパー３１１００は複数個の部分に分散されて送信されたデータをマージ（merge）して１つのストリームに出力することができる。また、図７で説明したように、送信端で２つの連続したセル入力データが１つのペアに処理されてマッピングされた場合、セルデマッパー３１１００はこれに該当する逆過程で連続した２つの入力セルを１つの単位で処理するペアワイズセルデマッピングを遂行することができる。
また、セルデマッパー３１１００は現在フレームを通じて受信したＰＬＳシグナリングデータに対し、各々ＰＬＳ−プリ（pre）及びＰＬＳ−ポスト（post）データとして全て抽出して出力することができる。
前述したブロックは設計者の意図によって省略されるか、類似または同一機能を有する他のブロックにより取替できる。
図３２は、本発明の一実施形態に係るデマッピング及びデコーディングモジュールを示す図である。
図３２に図示されたデマッピング及びデコーディングモジュールは、図９で説明したデマッピング及びデコーディングモジュールの一実施形態に該当する。
前述したように、本発明の一実施形態に係る送信装置のコーディングアンドモジュレーションモジュールは、入力されたデータパイプに対し、各々のパス別にＳＩＳＯ、ＭＩＳＯ、及びＭＩＭＯ方式を独立的に適用して処理することができる。したがって、図３２に図示されたデマッピング及びデコーディングモジュールやはり送信装置に対応してフレームパーサから出力されたデータを各々ＳＩＳＯ、ＭＩＳＯ、ＭＩＭＯ処理するためのブロックを含むことができる。
図３２に示すように、本発明の一実施形態に係るデマッピング及びデコーディングモジュールは、ＳＩＳＯ方式のための第１ブロック３２０００、ＭＩＳＯ方式のための第２ブロック３２１００、ＭＩＭＯ方式のための第３ブロック３２２００、及びＰＬＳプリ／ポスト情報を処理するための第４ブロック３２３００を含むことができる。図３２に図示されたデマッピング及びデコーディングモジュールは一実施形態に過ぎず、設計者の意図によってデマッピング及びデコーディングモジュールは第１ブロック３２０００及び第４ブロック３２３００のみを含むこともでき、第２ブロック３２１００及び第４ブロック３２３００のみを含むこともでき、第３ブロック３２２００及び第４ブロック３２３００のみを含むこともできる。即ち、設計者の意図によってデマッピング及びデコーディングモジュールは各データパイプを同一に、または異なるように処理するためのブロックを含むことができる。
以下、各ブロックについて説明する。
第１ブロック３２０００は入力されたデータパイプをＳＩＳＯ処理するためのブロックであって、時間デインターリーバブロック３２０１０、セルデインターリーバブロック３２０２０、コンステレーションデマッパーブロック３２０３０、セルトゥビットマルチプレキシング（cell to bit mux）ブロック３２０４０、ビットデインターリーバブロック３２０５０、及びＦＥＣデコーダブロック３２０６０を含むことができる。
時間デインターリーバブロック３２０１０は、時間インターリーバブロックの逆過程を遂行することができる。即ち、時間デインターリーバブロック３２０１０は時間領域でインターリービングされた入力シンボルを元の位置にデインターリービングすることができる。
セルデインターリーバブロック３２０２０は、セルインターリーバブロックの逆過程を遂行することができる。即ち、セルデインターリーバブロック３２０２０は１つのＦＥＣブロック内でスプレッディング（spreading）されたセルの位置を元の位置にデインターリービングすることができる。
コンステレーションデマッパーブロック３２０３０は、コンステレーションマッパーブロックの逆過程を遂行することができる。即ち、コンステレーションデマッパーブロック３２０３０はシンボルドメインの入力信号をビットドメインのデータにデマッピングすることができる。また、コンステレーションデマッパーブロック３２０３０は硬判定（hard decision）を遂行して判定されたビットデータを出力することもでき、軟判定（soft decision）値や、あるいは確率的な値に該当する各ビットの対数尤度比（Log-likelihood ratio：ＬＬＲ）を出力することができる。仮に、送信端で追加的なダイバーシティゲインを得るために回転（rotated）コンステレーションを適用した場合、コンステレーションデマッパーブロック３２０３０はこれに相応する２次元のＬＬＲ デマッピングを遂行することができる。この際、コンステレーションデマッパーブロック３２０３０はＬＬＲを計算する時、送信装置でＩまたはＱコンポネントに対して遂行された遅延値を補償できるように計算を遂行することができる。
セルトゥビットマルチプレキシングブロック３２０４０は、ビットトゥセルデマルチプレキシングブロックの逆過程を遂行することができる。即ち、セルトゥビットマルチプレキシングブロック３２０４０は、ビットトゥセルデマルチプレキシングブロックでマッピングされたビットデータを元のビットストリーム形態に復元することができる。
ビットデインターリーバブロック３２０５０は、ビットインターリーバブロックの逆過程を遂行することができる。即ち、ビットデインターリーバブロック３２０５０はセルトゥビットマルチプレキシングブロック３２０４０から出力されたビットストリームを元の順にデインターリービングすることができる。
ＦＥＣデコーダブロック３２０６０は、ＦＥＣエンコーダブロックの逆過程を遂行することができる。即ち、ＦＥＣデコーダブロック３２０６０はＬＤＰＣデコーディングとＢＣＨデコーディングを遂行して送信チャネル上の発生したエラーを訂正することができる。
第２ブロック３２１００は入力されたデータパイプをＭＩＳＯ処理するためのブロックであって、図３２に示すように、第１ブロック３２０００と同一に時間デインターリーバブロック、セルデインターリーバブロック、コンステレーションデマッパーブロック、セルトゥビットマルチプレキシングブロック、ビットデインターリーバブロック、及びＦＥＣデコーダブロックを含むことができるが、ＭＩＳＯデコーディングブロック３２１１０をさらに含むという点で差がある。第２ブロック３２１００は、第１ブロック３２０００と同様に時間デインターリーバから出力まで同一な役割の過程を遂行するので、同一なブロックに対する説明は省略する。
ＭＩＳＯデコーディングブロック３２１１０は、ＭＩＳＯプロセッシングブロックの逆過程を遂行することができる。本発明の一実施形態に係る放送送受信システムがＳＴＢＣを使用したシステムの場合、ＭＩＳＯデコーディングブロック３２１１０はアラモウチ（Alamouti）デコーディングを遂行することができる。
第３ブロック３２２００は入力されたデータパイプをＭＩＭＯ処理するためのブロックであって、図３２に示すように、第２ブロック３２１００と同一に時間デインターリーバブロック、セルデインターリーバブロック、コンステレーションデマッパーブロック、セルトゥビットマルチプレキシングブロック、ビットデインターリーバブロック、及びＦＥＣデコーダブロックを含むことができるが、ＭＩＭＯデコーディングブロック３２２１０を含むという点でデータ処理過程の差がある。第３ブロック３２２００に含まれた時間デインターリーバ、セルデインターリーバ、コンステレーションデマッパー、セルトゥビットマルチプレキシング、ビットデインターリーバブロックなどの動作は、第１乃至第２ブロック３２０００−３２１００に含まれた該当ブロックの動作と具体的な機能は異なることがあるが、基本的な役割は同一である。
ＭＩＭＯデコーディングブロック３２２１０は、ｍ個の受信アンテナ入力信号に対してセルデインターリーバの出力データを入力に受けて、ＭＩＭＯプロセッシングブロックの逆過程としてＭＩＭＯデコーディングを遂行することができる。ＭＩＭＯデコーディングブロック３２２１０は、最高の復号化性能を得るために最尤復号（Maximum likelihood decoding）を遂行するか、複雑度を減少させたスフィアデコーディング（Sphere decoding）を遂行することができる。または、ＭＩＭＯデコーディングブロック３２２１０はＭＭＳＥディテクションを遂行するか、または反復デコーディング（iterative decoding）を共に結合遂行して、向上したデコーディング性能を確保することができる。
第４ブロック３２３００はＰＬＳプリ／ポスト情報を処理するためのブロックであって、ＳＩＳＯまたはＭＩＳＯデコーディングを遂行することができる。第４ブロック３２３００は第４ブロックの逆過程を遂行することができる。
第４ブロック３２３００に含まれた時間デインターリーバ、セルデインターリーバ、コンステレーションデマッパー、セルトゥビットマルチプレキシング、ビットデインターリーバブロックの動作は、第１乃至第３ブロック３２０００−３２２００に含まれた該当ブロックの動作と具体的な機能は異なることがあるが、基本的な役割は同一である。
第４ブロック３２３００に含まれた短縮及びパンクチャリングＦＥＣデコーダ（Shortened/Punctured FEC decoder）３２３１０は、短縮及びパンクチャリングＦＥＣエンコーダブロックの逆過程を遂行することができる。即ち、短縮及びパンクチャリングＦＥＣデコーダ３２３１０はＰＬＳデータの長さによって短縮及びパンクチャリングされて受信されたデータに対して非短縮（de-shortening）とデパンクチャリング（de-puncturing）を遂行した後にＦＥＣデコーディングを遂行することができる。この場合、データパイプに使われたＦＥＣデコーダを同一にＰＬＳにも使用することができるので、ＰＬＳのみのための別途のＦＥＣデコーダハードウェアが必要でないので、システム設計が容易であり、効率的なコーディングが可能であるという長所がある。
前述したブロックは設計者の意図によって省略されるか、類似または同一機能を有する他のブロックにより取替できる。
結果的に、図３２に示すように、本発明の一実施形態に係るデマッピング及びデコーディングモジュールは、各パス別に処理されたデータパイプ及びＰＬＳ情報をアウトプットプロセッサに出力することができる。
図３３及び図３４は、本発明の一実施形態に係るアウトプットプロセッサ（output processor）を示す図である。
図３３は、本発明の一実施形態に係る出力プロセッサを示す図である。
図３３に図示された出力プロセッサは、図９で説明した出力プロセッサの一実施形態に該当する。また、図３３に図示された出力プロセッサはデマッピング及びデコーディングモジュールから出力された単一データパイプを受信して単一出力ストリームを出力するためのものであって、インプットフォーマッティングモジュールの逆動作を遂行することができる。
図３３のアウトプットプロセッサは、後述する図５０、図５１、及び図５３において提案された機能、過程、及び／又は方法を実現する。
図３３に図示された出力プロセッサは、ＢＢデスクランブラーブロック３３０００、パディング削除（Padding removal）ブロック３３１００、ＣＲＣ−８デコーダブロック３３２００、及びＢＢフレームプロセッサブロック３３３００を含むことができる。
ＢＢデスクランブラーブロック３３０００は、入力されたビットストリームに対して送信端で使用したものと同一なＰＲＢＳを発生させてビット列とＸＯＲしてデスクランブリングを遂行することができる。
パディング削除ブロック３３１００は、送信端で必要によって挿入されたパディングビットを除去することができる。
ＣＲＣ−８デコーダブロック３３２００は、パディング削除ブロック３３１００から入力を受けたビットストリームに対してＣＲＣデコーディングを遂行してブロックエラーをチェックすることができる。
ＢＢフレームプロセッサブロック３３３００は、ＢＢフレームヘッダに送信された情報をデコーディングし、デコーディングされた情報を用いてＭＰＥＧ−ＴＳ、ＩＰストリーム（ｖ４またはｖ６）またはジェネリックストリーム（Generic stream）を復元することができる。
前述したブロックは設計者の意図によって省略されるか、類似または同一機能を有する他のブロックにより取替できる。
図３４は、本発明の他の実施形態に係るアウトプットプロセッサを示す図である。
図３４に図示されたアウトプットプロセッサは、図９で説明したアウトプットプロセッサの一実施形態に該当する。また、図３４に図示されたアウトプットプロセッサは、デマッピング及びデコーディングモジュールから出力された多重（multiple）データパイプを受信する場合に該当する。多重データパイプに対するデコーディングは複数のデータパイプに共通に適用できるコモンデータ及びこれと関連したデータパイプをマージしてデコーディングする場合、または受信装置が複数個のサービスあるいはサービスコンポーネント（scalable video serviceを含み）を同時にデコーディングする場合を含むことができる。
図３４に図示されたアウトプットプロセッサは、アウトプットプロセッサの場合と同様に、ＢＢデスクランブラーブロック、パディング削除ブロック、ＣＲＣ−８デコーダブロック、及びＢＢフレームプロセッサブロックを含むことができる。各ブロックは図３３で説明したブロックの動作と具体的な動作は異なることがあるが、基本的な役割は同一である。
図３４のアウトプットプロセッサは、後述する図５０、図５１、及び図５３において提案された機能、過程、及び／又は方法を実現する。
図３４に図示されたアウトプットプロセッサに含まれたデ−ジッタバッファブロック３４０００は、多重データパイプ間の同期化のために送信端で任意に挿入された遅延（delay）を復元されたＴＴＯ（time to output）パラメータに従って補償することができる。
また、ヌルパケット挿入ブロック３４１００は復元されたＤＮＰ（deleted null packet）情報を参考してストリーム内の除去されたヌルパケットを復元することができ、コモンデータを出力することができる。
ＴＳクロック再生ブロック３４２００は、ＩＳＣＲインプットストリーム時間レファレンス（ISCR-Input Stream Time Reference）情報を基準に出力パケットの詳細な時間同期を復元することができる。
ＴＳ再結合（recombining）ブロック３４３００は、ヌルパケット挿入ブロック３４１００から出力されたコモンデータ及びこれと関連したデータパイプを再結合して元のＭＰＥＧ−ＴＳ、ＩＰストリーム（ｖ４またはｖ６）、あるいはジェネリックストリームに復元して出力することができる。ＴＴＯ、ＤＮＰ、ＩＳＣＲ情報は全てＢＢフレームヘッダを通じて取得できる。
インバンドシグナリングデコーダブロック３４４００は、データパイプの各ＦＥＣフレーム内のパディングビットフィールドを通じて送信されるインバンド物理階層シグナリング（in-band physical layer signaling）情報を復元して出力することができる。
図３４に図示されたアウトプットプロセッサは、ＰＬＳ−プリパスとＰＬＳ−ポストパスによって入力されるＰＬＳ−プリ情報及びＰＬＳ−ポスト情報を各々ＢＢデスクランブリングし、デスクランブリングされたデータに対してデコーディングを遂行して、元のＰＬＳデータを復元することができる。復元されたＰＬＳデータは受信装置内のシステム制御器（system controller）に伝達され、システム制御器は受信装置の同期化及び復調モジュール、フレームパーシングモジュール、デマッピング及びデコーディングモジュール、及びアウトプットプロセッサモジュールに必要とするパラメータを供給することができる。
前述したブロックは設計者の意図によって省略されるか、類似または同一機能を有する他のブロックにより取替できる。
図３５は、本発明の他の実施形態に係るコーディングアンドモジュレーションモジュールを示す図である。
図３５に図示されたコーディングアンドモジュレーションモジュールは、各データパイプを通じて送信するサービスやサービスコンポーネント別にＱｏＳを調節するために、モジュールはＳＩＳＯ方式のための第１ブロック３５０００、ＭＩＳＯ方式のための第２ブロック３５１００、ＭＩＭＯ方式のための第３ブロック３５２００、及びＰＬＳプリ／ポスト情報を処理するための第４ブロック３５３００を含むことができる。また、本発明の一実施形態に係るコーディングアンドモジュレーションモジュールは、前述したように、設計者の意図によって各データパイプを同一に、または異なるように処理するためのブロックを含むことができる。図３５に図示された第１ブロック乃至第４ブロック３５０００−３５３００は、第１ブロック乃至第４ブロックと略同一なブロックを含んでいる。
しかしながら、第１ブロック乃至第３ブロック３５０００−３５２００に含まれたコンステレーションマッパーブロック３５０１０の機能が第１ブロック乃至第３ブロックに含まれたコンステレーションマッパーブロックの機能と異なるという点、第１ブロック乃至第４ブロック３５０００−３５３００のセルインターリーバ及び時間インターリーバの間に回転（rotation）及びＩ／Ｑインターリーバブロック３５０２０が含まれているという点、及びＭＩＭＯ方式のための第３ブロック３１２００の構成がＭＩＭＯ方式のための第３ブロックの構成が異なるという点に差がある。
図３５に図示されたコンステレーションマッパーブロック３５０１０は、入力されたビットワードを複合シンボル（complex symbol）にマッピングすることができる。
図３５に図示されたコンステレーションマッパーブロック３５０１０は、前述したように、第１ブロック乃至第３ブロック３５０００−３５２００に共通的に適用できる。
回転及びＩ／Ｑインターリーバブロック３５０２０は、セルインターリーバから出力されたセルインターリービングされたデータの各複合シンボルの同相（In-phase）と直交位相（Quadrature-phase）コンポーネントを独立的にインターリービングしてシンボル単位で出力することができる。回転及びＩ／Ｑインターリーバブロック３５０２０の入力データ及び出力シンボルの個数は２つ以上であり、これは設計者の意図によって変更可能である。また、回転及びＩ／Ｑインターリーバブロック３５０２０は同相成分に対してはインターリービングを遂行しないこともある。
回転及びＩ／Ｑインターリーバブロック３５０２０は、前述したように、第１ブロック乃至第４ブロック３５０００−３５３００に共通的に適用できる。この場合、回転及びＩ／Ｑインターリーバブロック３５０２０がＰＬＳプリ／ポスト情報を処理するための第４ブロック３５３００に適用されるか否かは前述したプリアンブルを通じてシグナリングできる。
ＭＩＭＯ方式のための第３ブロック３５２００は、図３５に示すように、Ｑ−ブロックインターリーバブロック３５２１０、及び複合シンボル生成ブロック３５２２０を含むことができる。
Ｑ−ブロックインターリーバブロック３５２１０は、ＦＥＣエンコーダから入力を受けたＦＥＣエンコーディングが遂行されたＦＥＣブロックのパリティパート（parity part）に対し、パーミュテーション（permutation）を遂行することができる。これを通じてＬＤＰＣ Ｈマトリックスのパリティパートを情報パート（information part）と同一に環状構造（cyclic structure）に作ることができる。Ｑ−ブロックインターリーバブロック３５２１０は、ＬＤＰＣＨマトリックスのＱサイズを有する出力ビットブロックの順序をパーミュテーションした後、行（row）−列（column）ブロックインターリービングを遂行して最終ビット列を生成して出力することができる。
複合シンボル生成器ブロック３５２２０は、Ｑ−ブロックインターリーバブロック３５２１０から出力されたビット列の入力を受けて、複合シンボルにマッピングして出力することができる。この場合、複合シンボル生成器ブロック３５２２０は少なくとも２つの経路を通じてシンボルを出力することができる。これは、設計者の意図によって変更可能である。
前述したブロックは設計者の意図によって省略されるか、類似または同一機能を有する他のブロックにより取替できる。
結果的に、図３５に示すように、本発明の他の実施形態に係るコーディングアンドモジュレーションモジュールは、各パス別に処理されたデータパイプ、ＰＬＳ−プリ情報、ＰＬＳ−ポスト情報をフレーム構造モジュールに出力することができる。
図３６は、本発明の他の実施形態に係るデマッピング及びデコーディングモジュールを示す図である。
図３６に図示されたデマッピング及びデコーディングモジュールは、図９及び図３２で説明したデマッピング及びデコーディングモジュールの他の実施形態に該当する。また、図３６に図示されたデマッピング及びデコーディングモジュールは図３５で説明したコーディングアンドモジュレーションモジュールの逆動作を遂行することができる。
図３６に示すように、本発明の他の実施形態に係るデマッピング及びデコーディングモジュールは、ＳＩＳＯ方式のための第１ブロック３６０００、ＭＩＳＯ方式のための第２ブロック３６１００、ＭＩＭＯ方式のための第３ブロック３６２００、及びＰＬＳプリ／ポスト情報を処理するための第４ブロック３６３００を含むことができる。また、本発明の一実施形態に係るデマッピング及びデコーディングモジュールは、前述したように、設計者の意図によって各データパイプを同一に、または異なるように処理するためのブロックを含むことができる。図３６に図示された第１ブロック乃至第４ブロック３６０００−３６３００は、図３２で説明した第１ブロック乃至第４ブロック３２０００−３２３００と略同一なブロックを含んでいる。
しかしながら、第１ブロック乃至第４ブロック３６０００−３６３００の時間デインターリーバ及びセルデインターリーバの間にＩ／Ｑデインターリーバ及びデローテーションブロック３６０１０が含まれているという点、第１ブロック乃至第３ブロック３６０００−３６２００に含まれたコンステレーションデマッパーブロック３６０２０の機能が図３２の第１ブロック乃至第３ブロック３２０００−３２２００に含まれたコンステレーションマッパーブロック３２０３０の機能と異なるという点、及びＭＩＭＯ方式のための第３ブロック３６２００の構成が図３２に図示されたＭＩＭＯ方式のための第３ブロック３２２００の構成が異なるという点に差がある。以下、図３２と同一なブロックに対する説明は省略し、前述した差異点を中心に説明する。
Ｉ／Ｑデインターリーバ及びデローテーションブロック３６０１０は、図３５で説明した回転及びＩ／Ｑインターリーバブロック３５０２０の逆過程を遂行することができる。即ち、Ｉ／Ｑデインターリーバ及びデローテーションブロック３６０１０は、送信端でＩ／Ｑインターリービングされて送信されたＩ及びＱコンポーネントに対して各々デインターリービングを遂行することができ、復元されたＩ／Ｑコンポーネントを有する複合シンボルをまたデローテーションして出力することができる。
Ｉ／Ｑデインターリーバ及びデローテーションブロック３６０１０は、前述したように、第１ブロック乃至第４ブロック３６０００−３６３００に共通的に適用できる。この場合、Ｉ／Ｑデインターリーバ及びデローテーションブロック３６０１０がＰＬＳプリ／ポスト情報を処理するための第４ブロック３６３００に適用されるか否かは前述したプリアンブルを通じてシグナリングできる。
コンステレーションデマッパーブロック３６０２０は、図３５で説明したコンステレーションマッパーブロック３５０１０の逆過程を遂行することができる。即ち、コンステレーションデマッパーブロック３６０２０は、デローテーションを遂行せず、セルデインターリービングされたデータに対してデマッピングを遂行することができる。
ＭＩＭＯ方式のための第３ブロック３６２００は、図３６に示すように、複合シンボルパーシングブロック３６２１０及びＱ−ブロックデインターリーバブロック３６２２０を含むことができる。
複合シンボルパーシングブロック３６２１０は、図３５で説明した複合シンボル生成器ブロック３５２２０の逆過程を遂行することができる。即ち、複合データシンボルをパーシングし、ビットデータにデマッピングして出力することができる。この場合、複合シンボルパーシングブロック３６２１０は少なくとも２つの経路を通じて複合データシンボルの入力を受けることができる。
Ｑ−ブロックデインターリーバブロック３６２２０は、図３５で説明したＱ−ブロックインターリーバブロック３５２１０の逆過程を遂行することができる。即ち、Ｑ−ブロックデインターリーバブロック３６２２０は、行−列デインターリービングによりＱサイズブロックを復元した後、 パーミュテーションされた各ブロックの順序を元の順に復元した後、パリティデインターリービングを通じてパリティビットの位置を元の通り復元して出力することができる。
前述したブロックは設計者の意図によって省略されるか、類似または同一機能を有する他のブロックにより取替できる。
結果的に、図３６に示すように、本発明の他の実施形態に係るデマッピング及びデコーディングモジュールは、各パス別に処理されたデータパイプ及びＰＬＳ情報をアウトプットプロセッサに出力することができる。
以下、本明細書で提案するＢＢＦ送信のオーバーヘッドを減らし、パディング（Padding）フィールドを用いて多様な機能を追加するための新たなＢＢＦヘッダ構造について具体的に説明する。
図３７は、本明細書で提案するモードアダプテーションモジュールの一例を示す図である。
前述したように、インプットフォーマッティング（Input Formatting）モジュールはモードアダプテーション（Mode Adaptation）モジュールを含む。
図３７のモードアダプテーションモジュールの構成は、前述したモードアダプテーションモジュールの構成と一部相異することがある。
図３７に示すように、モードアダプテーションモジュールは、プリプロセッシング（Pre ProcessingまたはSplitting）ブロック３７１０、インプットインターフェース（Input Interface）ブロック３７２０、インプットストリーム同期化（input stream synchronizer）をブロック３７３０、ディレイ補償（compensating delay）ブロック３７４０、ヘッダコンプレッション（Header Compression）ブロック３７５０、ヌルデータ再使用（Null data reuse）ブロック３７６０、ヌルパケット除去（null packet deletion）ブロック３７７０、またはＢＢフレームヘッダ挿入（BB Frame Header Insertion）ブロック３７８０のうち、少なくとも１つを含んで構成できる。
プリプロセッシング（Pre Processing）ブロックは、複数個の入力ストリームを複数個のデータパイプにスプリッティング（splitting）またはデマルチプレキシングすることができる。ここで、データパイプはＰＬＰ（Physical Layer pipe）と呼ばれることもできる。ここで、入力ストリームはＴＳ（ＭＰＥＧ２−ＴＳ）、ＩＰ（Internet protocol）及び／又はＧＳ（Generic Stream）でありうる。
実施形態によって他の形態の入力ストリームも可能でありうる。
ヘッダコンプレッションブロックは、パケットヘッダを圧縮することができる。これは、ＴＳまたはＩＰ入力ストリームの送信効率を増加させるためでありうる。受信機が既にヘッダの先験的（a priori）情報を有しているので、既知データ（known data）が送信端から除去できる。例えば、ＰＩＤなどの情報が圧縮されることができ、他の形態の情報は除去または取替できる。実施形態によって、ヘッダコンプレッションブロックはヌルパケット除去ブロックの後に位置することができる。
ヌルデータ再使用（Null data reuse）ブロックは、ヘッダコンプレッションのその後にヌルデータをパケットに挿入する動作を遂行することができる。このブロックは実施形態によって省略できる。
ＢＢフレームヘッダ挿入ブロックは、前述したＢＢフレームヘッダ挿入ブロックと異なる方式により動作することもできる。
本明細書は、ＢＢ（Base Band）フレームのデータフィールド長さのシグナリングを減少させる方法を提供する（data Field Length signaling reduction method）。
また、本明細書はＢＢフレームのＦＥＣブロックへの送信に対するオーバーヘッドを減らすための方法を提供する。
即ち、本明細書で提案する新たなＢＢフレーム構成方法はＢＢフレームヘッダ挿入ブロックで遂行できる。
本明細書で提案する方法により、ＢＢフレーム及びＢＢフレームヘッダが構成できる。本明細書はインプットストリームがインプットプロセシングを経てＦＥＣブロックに伝達されるために、ＢＢフレームが生成される過程に関するものでありうる。
また、本明細書はＢＢフレームヘッダの大きさを縮めて送信効率を高める方法でありうる。ＢＢフレームヘッダ挿入ブロックと関連した具体的な内容は後述する。
従来技術において、ＢＢフレームはデータフィールドの長さを受信装置に知らせるために、ＤＦＬ（data field length）をＢＢフレームヘッダごとに割り当てた。前記ＤＦＬは１６ｂｉｔまたは１１ｂｉｔでありうる。これによって、従来技術はＢＢＦ送信に対するオーバーヘッドが大きい。
常に同一なサイズのＢＢフレームでデータフィールドの長さが異なる場合は、データがＢＢフレームを全て詰められないか、またはＢＢフレームがインバンドシグナリング（in band signaling）情報を含んでいる場合でありうる。
更に他の従来技術において、ＢＢフレームはデータフィールドの長さを直接知らせる代わり、インジケータ（indicator）のみ送信した。そして、ＢＢフレームはＢＢフレームのパディング（padding）の長さをパディングでシグナリングしてくれた。しかしながら、この場合、インバンドシグナリングを考慮していないので、インバンドシグナリングが運用される場合に制限を受けることができる。
本明細書で提案する方法は、ＤＦＬを減らし、追加フィールドを挿入できるようにするＢＢフレームヘッダを構成する方法でありうる。ここで、追加フィールドはインバンドシグナリングのタイプなどを指示することもでき、他の用途に使用することもできる。
本明細書で提案する方法によりＢＢＦ送信に対するオーバーヘッドを最小化することができ、パディング（または、スタッフィング（stuffing））フィールドに多様な機能が追加できる。
図３８は、本明細書で提案するアウトプットプロセッサの一例を示す図である。
前述したように、アウトプットプロセッサ（output processor）はＢＢフレームヘッダパーサブロックを含むことができる。図３８のアウトプットプロセッサの構成要素は前述したアウトプットプロセッサの構成要素と一部相異することがある。
図３８のアウトプットプロセッサは、後述する図５０、図５１、及び図５３において提案された機能、過程、及び／又は方法を実現する。
アウトプットプロセッサは、ＢＢフレームヘッダパーサブロック３８１０、ヌルパケット挿入（Null packet insertion）ブロック３８２０、ヌルデータ再生成（Null data regenerator）ブロック３８３０、ヘッダデコンプレッションブロック３８４０、ＴＳクロック再生成（TS clock regeneration）ブロック３８５０、デジッタバッファブロック３８６０、またはＴＳ再結合（TS recombining）ブロック３８７０のうち、少なくとも１つを含んで構成できる。
ここで、ヌルパケット挿入ブロック、ＴＳクロック再生成ブロック、デジッタバッファブロック、及びＴＳ再結合ブロックは、前述したアウトプットプロセッサのブロックと同一の動作を遂行することができる。
本明細書で提案するＢＢフレームヘッダ構成方法は、受信端（または、受信装置、受信機、レシーバー）ではＢＢフレームヘッダパーサブロックに対応できる。
ＢＢフレームヘッダパーサブロック３８１０は、前述したＢＢフレームヘッダパーサブロックと相異するように動作することができる。ＢＢフレームヘッダパーサブロック３８１０は、本明細書で提案する方式に従うＢＢフレームヘッダをパーシングする動作を遂行することができる。
本明細書で提案するＢＢフレーム及びＢＢフレームヘッダの構成方法は後述する。
ヌルデータ再生成ブロックは、受信端のヌルデータ再使用ブロックに対応する構成でありうる。ヌルデータ再生成ブロックは、アウトプットをヘッダデコンプレッションブロックに出力することができる。このブロックは実施形態によって省略できる。
ヘッダデコンプレッションブロックは、受信端のヘッダコンプレッションブロックに対応する構成でありうる。ヘッダデコンプレッションブロックは、圧縮されたパケットヘッダの圧縮を復元することができる。前述したように、パケットヘッダはＴＳまたはＩＰ入力ストリームの送信効率を増加させるために圧縮されていることができる。実施形態によって、ヘッダデコンプレッションブロックは、実施形態によってヌルパケット挿入ブロックの前に位置することができる。
図３９は、従来のＢＢフレーム構造の一例を示す図である。
インプットフォーマッティングモジュール、特に、モードアダプテーションモジュールに入力されたデータストリームはＢＩＣＭモジュールでＦＥＣを遂行することができるように適切な長さにスライシングできる。これを通じてＢＢフレームが生成できる。
ＢＢフレームのデータフィールドの長さはＢＢフレームの全体長さからＢＢフレームヘッダの長さを引いた値に該当する。
前記ＢＢＦのデータフィールド部分に実際ＵＰ（User Packet）が挿入できる。
データフィールドの長さはＢＢフレームヘッダのＤＦＬ（data Field Length）フィールドで知らせることができる。ＤＦＬフィールドはＤＦＬで表現できる。
インプットフォーマッティングを通じて生成されるＢＢフレームは、予め設定されたＦＥＣブロックでエンコーディングできる。
ここで、ＢＢフレームの全長は固定されていることができる。
また、ＢＢＦのデータフィールドの長さが変わる場合は、ＵＰが充分でなくてＢＢフレームを全て詰められない場合、または意図的にインバンドシグナリング（in-band signaling）情報が含まれた場合でありうる。
ＢＢフレームを全て詰められない場合には、該当空間にスタッフィング（stuffing）が詰められる。前記スタッフィングはパディング（padding）で表現できる。
図４０は、従来のＢＢフレーム構造の更に他の一例を示す図である。
図４０ｂに示すように、ＢＢフレームのデータフィールド（または、ペイロード）に送信されるデータを全て詰められなかった場合、スタッフィングバイトが挿入できる。
前記スタッフィングバイトをシグナリングするために、ＳＴＵＦＦＩフィールドがＢＢＦヘッダに挿入できる。前記ＢＢＦヘッダはＴＳヘッダでありうる。
前記ＳＴＵＦＦＩフィールドはＢＢフレームにスタッフィングバイトの存否を示す１ビットの指示子を示す。
ＢＢフレームのペイロードにＵＰが全て詰められる場合には、前記スタッフィングバイトが存在しなくなる。この際、前記ＳＴＵＦＦＩは‘０’に設定できる。
ＢＢフレームにＵＰが全て詰められない場合には前記スタッフィングバイトが存在することができる。この場合、前記ＳＴＵＦＦＩは‘１’に設定できる。
前記スタッフィングバイトがＢＢフレームに含まれている場合、前記スタッフィングバイトの長さはＢＢフレームペイロードの第１のバイトを通じて確認することができる。
一例に、前記ＢＢフレームペイロードの第１のバイト値が０ｘＦＦの場合、ＢＢフレームペイロードに１つのスタッフィングバイト（１ｂｙｔｅのスタッフィングバイト）を含むことができる。
前記ＢＢフレームペイロードの第１のバイト及び第２のバイト値が各々０ｘＦＥ、０ｘＦＦの場合、前記ＢＢフレームペイロードに２つのスタッフィングバイトを含むことができる。
ここで、スタッフィングバイトが２つ以上（スタッフィングバイトの大きさが２ｂｙｔｅ以上）の場合には、第１及び第２のバイト値を各々ＭＳＢ、ＬＳＢにしてスタッフィングバイトの長さをシグナリングすることができる。
図４０ａの表で、‘Ｎ’は全体スタッフィングバイトの長さを示す。
‘Ｎ’値が１バイトの場合、スタッフィングバイトの全体長さを知らせるフィールドの長さは１バイトでありうる。この際、前記フィールド値は０ｘＦＦに設定できる。
ここで、前記スタッフィングバイトの全長を知らせるフィールドはスタッフィングバイト長さフィールドで表現できる。
‘Ｎ’値が２バイトの場合、スタッフィングバイト長さフィールドの長さは２バイトでありうる。
この際、前記スタッフィングバイト長さフィールド値は０ｘＦＥ及び０ｘＦＦに設定できる。
‘Ｎ’値が‘３以上’の場合、一例に、Ｎが３から６５２７８の間の値を有する場合にも前記スタッフィングバイト長さフィールドの長さは２バイトでありうる。
この際、前記スタッフィングバイト長さフィールドはＭＳＢとＬＳＢで構成できる。
即ち、前記２ｂｙｔｅのスタッフィングバイト長さフィールドは全体スタッフィングバイトの長さをシグナリングすることができる。
図４０に示すように、ＭＳＢとＬＳＢの後に追加的なスタッフィングバイトが存在することができる。即ち、総スタッフバイト長さがＮであり、ＭＳＢ及びＬＳＢの長さが２バイトであるので、後続するスタッフィングバイト長さはＮ−２バイトである。
図４１は、従来のＢＢフレーム構造の更に他の一例を示す図である。
図４１に示すように、スタッフィングバイトの状態を示すために２ｂｉｔのインジケータ（indicator）が使用できる。前記インジケータはＰＡＤＩ（Padding Indicator）で表現できる。
ＢＢＦペイロード（または、データフィールドまたはＦＥＣフレーム）にスタッフィングバイト、即ちパディングが含まれない場合、前記ＰＡＤＩは‘００’に設定できる。
図４１ｂに図示された第１のＢＢフレームで、ＰＡＤＩは‘００’に設定され、ＢＢＦペイロードにパディングが存在しないことを確認することができる。
ＰＡＤＩが‘０１’の場合、ＢＢＦペイロードに含まれるパディングの長さは１バイトであることを示すことができる。
図４１ｂに図示された第２のＢＢフレームで、ＰＡＤＩ値が‘０１’に設定され、パディングの長さは１バイトであることが分かる。‘Ｐ’で表示されたものがパディングバイトを示す。
ＰＡＤＩが‘１０’の場合、パディングバイトは２つ以上であることを示すことができる。
この場合にはパディングフィールドでＭＳＢ及びＬＳＢなどを用いてパディングの長さをシグナリングしてくれることができる。
図４１ｂに図示された第３のＢＢフレームで、ＰＡＤＩ値が‘１０’に設定され、パディングフィールドの第１及び第２のバイトが各々ＭＳＢ、ＬＳＢに割り当てられたことを見ることができる。
前記ＭＳＢ、ＬＳＢの次に‘Ｐ’で表記された追加的なパディングが存在することができる。
図４２は、本明細書で提案するＢＢフレーム構造の一例を示す。
本明細書はＢＢフレーム及びＢＢフレームヘッダの構成に対して以下のような方式を提供する。
ＢＢフレームは、ＢＢフレームヘッダ、スタッフィングフィールド（stuffing field）、またはペイロード（payload）のうち、少なくとも１つを含んで構成できる。
図４２は、前記スタッフィングフィールドが前記ペイロードの前に位置するＢＢフレーム構造の一例を示す。
前記スタッフィングフィールドは実施形態によって前記ペイロードの後に位置することもでき、これに対しては図４４及び図４５で具体的に説明する。
前記スタッフィングフィールド及びペイロードを含んでＢＢフレームペイロード（または、ＢＢフレームデータフィールドまたはＦＥＣフレーム）と称することもできる。
前記ＢＢフレームヘッダはペイロード、即ちデータフィールドのフォーマットを記述することができる（describing）。
また、前記スタッフィングフィールドの前にＤＮＰ（Deleted Null Packet）またはＩＳＳＹ（Input Stream Synchronizer）関連情報などが追加で挿入されることもできる。
前述したように、前記ペイロードはデータフィールドを意味することができる。
前記ＢＢフレームヘッダは、ＳＴＵＦＦＩフィールドを含むことができる。
前記ＳＴＵＦＦＩフィールドはＢＢフレームにスタッフィングバイトが存在するか否かを示すインジケータの役割をすることができる。
前記ＳＴＵＦＦＩフィールドは１ｂｉｔでありうる。実施形態によってＳＴＵＦＦＩの位置は変更できる。
一例に、前記ＳＴＵＦＦＩ値が‘０’の場合、ＢＢフレームはスタッフィングフィールドを含まず、インバンドシグナリングフィールドやはり含まないことがある。
ＳＴＵＦＦＩ値が‘１’の場合、ＢＢフレームはスタッフィングフィールドを含むか、またはインバンドシグナリングフィールドを含むことができる。即ち、前記ペイロードにＵＰの以外の情報、即ち、パディングまたはインバンドフィールドが追加で存在することができる。
本発明の実施形態によって、ＳＴＵＦＦＩの値が有する‘０’と‘１’が示す意味は互いに後先になることもできる。
スタッフィングフィールドは、スタッフィングフィールドヘッダまたはスタッフィングデータ領域のうち、少なくとも１つを含むことができる。
前記スタッフィングデータ領域は、スタッフィングデータまたはインバンドシグナリング情報のうち、少なくとも１つを含むことができる。
前記スタッフィングフィールドヘッダは、実施形態によって２バイトでありうる。
また、前記スタッフィングフィールドヘッダは、ＳＴＵＦＦ＿ＯＮＥ（または、ＰＡＤ＿ＯＮＥ）、ＳＴＵＦＦ＿ＴＹＰＥ（ＰＡＤ＿ＴＹＰＥ）、またはＳＴＵＦＦ＿ＬＥＮ（または、ＰＡＤ＿ＬＥＮ）のうち、少なくとも１つを含むことができる。
図４４に図示された１ｓｔＢｙｔｅはスタッフィングフィールドの第１のバイトを示す。
２ｎｄＢｙｔｅやはりスタッフィングフィールドに属することができる。実施形態によって、最初の２バイト（１ｓｔＢｙｔｅ及び２ｎｄＢｙｔｅ）がスタッフィングフィールドヘッダに該当することができる。
実施形態によって第３のバイト（３ｒｄＢｙｔｅ）からはスタッフィングデータ領域に含まれるか、またはペイロードに含まれることができる。
ＰＡＤ＿ＯＮＥフィールドは、実施形態によって、ＳＴＵＦＦ＿ＯＮＥフィールドで表現できる。
ＳＴＵＦＦＩが‘１’の場合、ＳＴＵＦＦ＿ＯＮＥが確認できる。ＳＴＵＦＦ＿ＯＮＥはスタッフィングバイトの長さが１バイトか否かを示すことができる。ＳＴＵＦＦ＿ＯＮＥは１ビット（ｂｉｔ）のＭＳＢでありうる。ＳＴＵＦＦ＿ＯＮＥが１であれば、スタッフィングバイトの長さが１バイトでありうる。この場合、スタッフィングバイトの長さを表してくれるＳＴＵＦＦ＿ＬＥＮ＿ＬＳＢは使用されないことがある。
また、ＳＴＵＦＦ＿ＬＥＮ＿ＭＳＢは全て０に設定できる。この場合、実施形態によってＳＴＵＦＦ＿ＬＥＮ＿ＭＳＢは全て１に設定されることもできる。即ち、実施形態によって１バイトのスタッフィングバイトが００００００００、１１１１１１１１、１０００００００、または０１１１１１１１の値を有することができる。
ＳＴＵＦＦ＿ＯＮＥが０であれば、スタッフィングバイトの長さが１バイトより大きいことがある。
この場合、２バイトのスタッフィングフィールドヘッダがスタッフィングデータ領域の長さ及びタイプを示すことに使用できる。
ＳＴＵＦＦ＿ＯＮＥの値が示すところは、設計者によって互いに後先になることもできる。即ち、１と０が示す意味が互いに後先になることもできる。
図示されたＳＴＵＦＦ＿ＯＮＥ（ＰＡＤ＿ＯＮＥ）は第１のバイトの第１のビットに位置できる。この位置は実施形態によって変更可能な事項である。ＳＴＵＦＦ＿ＯＮＥは実施形態によってＢＢフレームヘッダに位置することもできる。
実施形態によってＳＴＵＦＦＩとＳＴＵＦＦ＿ＯＮＥの役割をする２ビットの１フィールドが設定できる。ＳＴＵＦＦＩとＳＴＵＦＦ＿ＯＮＥは各々１ビットであるので、２ビットの１フィールドを設定することによって、その役割に代えることができる。このフィールドはＢＢフレームヘッダに位置することも、スタッフィングフィールドに位置することもできる。
ＰＡＤ＿ＬＥＮは、実施形態によって、ＳＴＵＦＦ＿ＬＥＮと呼ばれることができる。ＳＴＵＦＦ＿ＬＥＮはＳＴＵＦＦ＿ＬＥＮ＿ＭＳＢまたはＳＴＵＦＦ＿ＬＥＮ＿ＬＳＢのうち、少なくとも１つを含むことができる。
ＳＴＵＦＦ＿ＬＥＮ＿ＭＳＢ及びＳＴＵＦＦ＿ＬＥＮ＿ＬＳＢは、各々５ビット、８ビットのフィールドでありうる。
前記ＳＴＵＦＦ＿ＬＥＮ＿ＭＳＢ及びＳＴＵＦＦ＿ＬＥＮ＿ＬＳＢフィールドは、全体スタッフィングフィールド長さを示すことに使用できる。実施形態によって、ＳＴＵＦＦ＿ＬＥＮ＿ＭＳＢ及びＳＴＵＦＦ＿ＬＥＮ＿ＬＳＢの長さは互いに変わって、各々８ビット、５ビットでありうる。また、実施形態によって、両者の位置も互いに変わることができる。実施形態によって、パディングの長さを示すフィールドはスタッフィングデータ領域に位置することもできる。
従来の場合、最初の２バイトを用いてパディングの長さを表現した。しかしながら、６４Ｋ ＬＤＰＣを使用する場合、パディングの長さは最大６３７０バイト（６４ｋ、５／６コードレート、ＢＣＨコード）の値を有するようになる。したがって、パディングの長さは１３ビット２^１３＝８１９２バイト）で十分に表現できる。
したがって、本明細書で提案するＰＡＤ＿ＬＥＮは１３ビット（５＋８）を有することができる。
このように、パディングの長さを１３ビットで表現する場合、最初の２バイトのうち、余分の２ビットが残ることができる。
本明細書では、前記余分の２ビットをＰＡＤ＿ＴＹＰＥに割り当てて、パディング領域が他の用途（例えば、インバンドシグナリング）に使用される場合、そのタイプをシグナリングすることができる方法を提供する。
ＳＴＵＦＦ＿ＴＹＰＥは、実施形態によって、ＰＡＤ＿ＴＹＰＥで表現できる。
ＳＴＵＦＦ＿ＴＹＰＥは、前述したように、２ビットのフィールドとして、スタッフィングデータ（または、スタッフィングデータ領域）のタイプを示すことができる。
図４２に示すように、ＳＴＵＦＦ＿ＴＹＰＥ値が‘００’の場合、スタッフィングデータ領域はスタッフィングデータのみを含むことができる。
ＳＴＵＦＦ＿ＴＹＰＥ値が‘０１’の場合、特定の種類のインバンドシグナリング情報がスタッフィングデータと共にスタッフィングデータ領域に含まれることができる。
ＳＴＵＦＦ＿ＴＹＰＥ値が‘１０’の場合、異なる種類のインバンドシグナリング情報がスタッフィングデータと共にスタッフィングデータ領域に含まれることができる。
ＳＴＵＦＦ＿ＴＹＰＥ値が‘１１’の場合、特定の種類及び他の種類のインバンドシグナリング情報が全てスタッフィングデータと共にスタッフィングデータ領域に含まれることができる。
ここで、特定の種類のインバンドシグナリング情報とは、‘インバンドＡ’を意味することができ、他の種類のインバンドシグナリング情報とは、‘インバンドＢ’を意味することができる。
これは、一実施形態に過ぎず、ＳＴＵＦＦ＿ＴＹＰＥ値が指示するタイプ種類は多様な方式により変更できる。
また、ＳＴＵＦＦ＿ＴＹＰＥはＢＢフレームペイロードまたはペイロードの構成を指示することができる。例えば、ペイロードのうち、切られていない完全な第１のパケットの位置が指示されることもできる。
本明細書で提案するように、スタッフィングフィールドでシグナリングする場合、インバンドシグナリングを他の複数のフレームに挿入可能になる。また、インバンドシグナリング無しでパディングのみ入っている場合と区別が可能になる長所がある。
ＳＴＵＦＦ＿ＴＹＰＥの位置は、実施形態によって、ＢＢフレームヘッダに位置することもできる。
または、本実施形態のように、スタッフィングフィールドに位置することもできる。実施形態によって、ＳＴＵＦＦ＿ＴＹＰＥの長さは変更されることもできる。
ＳＴＵＦＦ＿ＴＹＰＥの値が示すところは、設計者によって互いに後先になることもできる。
例えば、００が示すところと１１が示すところとが互いに後先になることもできる。また、１０が示すところと０１が示すところとが互いに後先になることもできる。
スタッフィングデータは、実施形態によって、全て０または全て１の値を有することができる。
以下、図４２に図示されたｃａｓｅ＃１からｃａｓｅ＃６について具体的に説明する。
１）Ｃａｓｅ＃１は、ＢＢフレームにスタッフィングデータ及びインバンドシグナリングが含まれない場合を示す。
この場合、ＳＴＵＦＦＩフィールドは‘０’に設定できる。したがって、ＢＢフレームの構造はＢＢフレームヘッダの直後のデータ領域、即ち、ペイロードが位置することができる。
２）Ｃａｓｅ＃２は、ＢＢフレームに１バイトのスタッフィングフィールドが存在し、インバンドシグナリングが存在しない場合を示す。
この場合、ＳＴＵＦＦＩフィールドは‘１’に設定できる。即ち、ＢＢフレームはスタッフィングフィールドを含み、前記スタッフィングフィールドは１バイトの大きさを有することができる。
ここで、前記スタッフィングフィールドの第１のビットはＳＴＵＦＦ＿ＯＮＥフィールドを表し、前記スタッフィングフィールドの大きさが１バイトであるので、‘１’の値を有する。
前記スタッフィングフィールドの残りの７個のビットは１１１１１１１の値を有することができる。
したがって、１ｂｙｔｅのスタッフィングフィールドは１１１１１１１１で表現できる。
３）Ｃａｓｅ＃３は、ＢＢフレームに１バイトより大きいスタッフィングフィールドが存在し、インバンドシグナリングが存在しない場合を示す。
即ち、前記スタッフィングフィールドは２バイトまたは２バイトより大きいことがある。
スタッフィングフィールドが存在するので、ＳＴＵＦＦＩフィールドは‘１’に設定できる。
前記スタッフィングフィールドは、２バイトのスタッフィングフィールドヘッダを有することができる。前記スタッフィングフィールドヘッダの第１のバイトの第１のビットはＳＴＵＦＦ＿ＯＮＥフィールドに該当する。
前記ＳＴＵＦＦ＿ＯＮＥフィールドは、前記スタッフィングフィールドの大きさが１バイトより大きいので‘０’値に設定できる。
前記スタッフィングフィールドヘッダの第１のバイトの第２及び第３のビットはＳＴＵＦＦ＿ＴＹＰＥフィールドに該当する。
ＢＢフレームのスタッフィングデータ領域にスタッフィングデータのみがある場合であるので、前述したように、ＳＴＵＦＦ＿ＴＹＰＥは００の値を有することができる。
本図面では、他の実施形態として、ＳＴＵＦＦ＿ＴＹＰＥが１１値を有する場合が図示されている。
即ち、この場合はＢＢフレームのスタッフィングデータ領域にスタッフィングデータのみがある場合であって、ＳＴＵＦ＿ＴＹＰＥフィールドが１１値として指示できる。
この後、スタッフィングフィールドヘッダのＳＴＵＦＦ＿ＬＥＮ＿ＭＳＢ及びＳＴＵＦＦ＿ＬＥＮ＿ＬＳＢがスタッフィングフィールドの長さ情報を有することができる。前述したように、スタッフィングフィールドの長さは総１３ビットを用いて表現できる。ＳＴＵＦＦ＿ＬＥＮ＿ＭＳＢ及びＳＴＵＦＦ＿ＬＥＮ＿ＬＳＢのその後にはスタッフィングデータ領域が位置することができる。このケースで、スタッフィングデータ領域にはスタッフィングデータのみ来ることができる。
（４）Ｃａｓｅ＃４は、ＢＢフレームに１バイトより大きいスタッフィングフィールドが存在し、インバンドＡシグナリングが存在する場合を示す。
この場合、ＢＢフレームのスタッフィングデータ領域にはスタッフィングデータ及びインバンドＡシグナリングが存在することができる。
前記インバンドＡシグナリングは、前述した特定の種類のインバンドシグナリングを意味することができる。この場合、スタッフィングフィールドが存在するので、ＳＴＵＦＦＩは１の値を有することができる。
前記スタッフィングフィールドヘッダの第１のバイトの第１のビットはＳＴＵＦＦ＿ＯＮＥフィールドであって、スタッフィングフィールドの大きさが１バイトより大きいので‘０’の値を有することができる。
スタッフィングフィールドヘッダの第１のバイトの第２、第３のビットは前述したＳＴＵＦＦ＿ＴＹＰＥフィールドでありうる。
ＢＢフレームのスタッフィングデータ領域にインバンドＡシグナリングが存在する場合であるので、前述したように、ＳＴＵＦＦ＿ＴＹＰＥは１０の値を有することができる。実施形態によって、この値は０１でありうる。
この後、スタッフィングフィールドヘッダのＳＴＵＦＦ＿ＬＥＮ＿ＭＳＢ及びＳＴＵＦＦ＿ＬＥＮ＿ＬＳＢがスタッフィングフィールドの長さ情報を有することができる。前述したように、スタッフィングフィールドの長さは総１３ビットを用いて表現できる。ＳＴＵＦＦ＿ＬＥＮ＿ＭＳＢ及びＳＴＵＦＦ＿ＬＥＮ＿ＬＳＢのその後にはスタッフィングデータ領域が位置することができる。このケースで、スタッフィングデータ領域にはスタッフィングデータの他にもインバンドＡシグナリングが存在することができる。
（５）Ｃａｓｅ＃５は、ＢＢフレームに１バイトより大きいスタッフィングフィールドが存在し、インバンドＢシグナリングが存在する場合でありうる。
この場合、ＢＢフレームのスタッフィングデータ領域にはスタッフィングデータ及びインバンドＢシグナリングが存在することができる。
前記インバンドＢシグナリングとは、前述した他の種類のインバンドシグナリングを意味することができる。この場合、スタッフィングフィールドが存在するので、ＳＴＵＦＦＩは１の値を有することができる。
スタッフィングフィールドヘッダの第１のバイトの第１のビットはＳＴＵＦＦ＿ＯＮＥフィールドであって、スタッフィングフィールドの大きさが１バイトより大きいので、０の値を有することができる。
スタッフィングフィールドヘッダの第１のバイトの第２及び第３のビットは前述したＳＴＵＦＦ＿ＴＹＰＥフィールドでありうる。ＢＢフレームのスタッフィングデータ領域にインバンドＢシグナリングが存在する場合であるので、前述したように、ＳＴＵＦＦ＿ＴＹＰＥは０１の値を有することができる。実施形態によって、この値は１０でありうる。
この後、スタッフィングフィールドヘッダのＳＴＵＦＦ＿ＬＥＮ＿ＭＳＢ及びＳＴＵＦＦ＿ＬＥＮ＿ＬＳＢがスタッフィングフィールドの長さ情報を有することができる。前述したように、スタッフィングフィールドの長さは総１３ビットを用いて表現できる。ＳＴＵＦＦ＿ＬＥＮ＿ＭＳＢ及びＳＴＵＦＦ＿ＬＥＮ＿ＬＳＢのその後には、スタッフィングデータ領域が位置することができる。このケースで、スタッフィングデータ領域にはスタッフィングデータの他にもインバンドＢシグナリングが存在することができる。
（６）Ｃａｓｅ＃６は、ＢＢフレームに１バイトより大きいスタッフィングフィールドが存在し、インバンドＡ及びＢシグナリングが存在する場合でありうる。
この場合、ＢＢフレームのスタッフィングデータ領域には、スタッフィングデータ及びインバンドＡ及びＢシグナリングが全て存在することができる。
この場合、ＳＴＵＦＦＩは１の値を有することができる。スタッフィングフィールドヘッダの第１のバイトの第１のビットはＳＴＵＦＦ＿ＯＮＥフィールドであって、スタッフィングフィールドの大きさが１バイトより大きいので、０の値を有することができる。スタッフィングフィールドヘッダの第１のバイトの第２、第３のビットは、前述したＳＴＵＦＦ＿ＴＹＰＥフィールドでありうる。ＢＢフレームのスタッフィングデータ領域にインバンドＡ及びＢシグナリングが存在する場合であるので、前述したように、ＳＴＵＦＦ＿ＴＹＰＥは１１の値を有することができる。
本図面では、他の実施形態として、ＳＴＵＦＦ＿ＴＹＰＥこの００値を有する場合が図示されている。即ち、この場合はスタッフィングデータ領域にインバンドＡ及びＢシグナリングが全て存在する場合が、ＳＴＵＦ＿ＴＹＰＥフィールドが００値として指示できる。
この後、スタッフィングフィールドヘッダのＳＴＵＦＦ＿ＬＥＮ＿ＭＳＢ及びＳＴＵＦＦ＿ＬＥＮ＿ＬＳＢがスタッフィングフィールドの長さ情報を有することができる。前述したように、スタッフィングフィールドの長さは総１３ビットを用いて表現できる。
ＳＴＵＦＦ＿ＬＥＮ＿ＭＳＢ及びＳＴＵＦＦ＿ＬＥＮ＿ＬＳＢのその後にはスタッフィングデータ領域が位置することができる。このケースで、スタッフィングデータ領域にはスタッフィングデータの他にもインバンドＡ及びＢシグナリングが存在することができる。
図４３は、本明細書で提案するＢＢフレーム構造の更に他の一例を示す図である。
図４３（ａ）はパディング、即ちスタッフィングデータ無しでデータのみがある場合のＢＢフレームでありうる。
ＢＢフレームヘッダのＳＴＵＦＦＩが０の値を有していることができる。ＢＢフレームヘッダの後にスタッフィングフィールド無しで、直ぐペイロードが位置することが分かる。図４２のＣａｓｅ＃１に該当することができる。
図４３（ｂ）は、１バイトのパディングを有する場合でありうる。
この場合、ＢＢフレームヘッダのＳＴＵＦＦＩが１の値を有することができる。第１のバイトの第１のビットはＳＴＵＦＦ＿ＯＮＥとして１の値を有することができる。これは、パディングが１バイトであることを意味することができる。図４３で、パディングの各ビットは１１１１１１１１の値を有することができる（０ｘＦＦ）。または、実施形態によって１０００００００の値を有することもできる。図４２のＣａｓｅ＃２に該当することができる。
図４３（ｃ）は、ｎバイトのパディングを有する場合でありうる。
この場合、ＢＢフレームヘッダのＳＴＵＦＦＩが１の値を有することができる。また、ＳＴＵＦＦ＿ＯＮＥは０の値を有することができる。ＳＴＵＦＦ＿ＴＹＰＥはインバンドシグナリング無しで、スタッフィングデータのみ使用されいるという点を指示することができる。
即ち、実施形態によって、ＳＴＵＦＦ＿ＴＹＰＥは００の値を有することができる。
その後、残りの１３ビットはスタッフィングフィールドの長さがｎバイトであることを指示することができる。この１３ビットは、ＳＴＵＦＦ＿ＬＥＮ＿ＭＳＢ及びＳＴＵＦＦ＿ＬＥＮ＿ＬＳＢでありうる。ＳＴＵＦＦ＿ＬＥＮ＿ＭＳＢ及びＳＴＵＦＦ＿ＬＥＮ＿ＬＳＢの後には、スタッフィングデータが来ることができる。図４２のＣａｓｅ＃３のうち、スタッフィングフィールドが３バイト以上の場合に該当することができる。
図４３（ｄ）は、インバンドＡシグナリングと共にｎバイトのパディングを有する場合でありうる。
この場合、ＢＢフレームヘッダのＳＴＵＦＦＩが１の値を有することができる。また、ＳＴＵＦＦ＿ＯＮＥは０の値を有することができる。ＳＴＵＦＦ＿ＴＹＰＥはインバンドＡシグナリングが使用されいることを指示することができる。
即ち、実施形態によってＳＴＵＦＦ＿ＴＹＰＥは０１の値を有することもできる。ＳＴＵＦＦ＿ＴＹＰＥの値自体は前述したように変更できる。その後、残りの１３ビットはスタッフィングフィールドの長さがｎバイトであることを指示することができる。この１３ビットはＳＴＵＦＦ＿ＬＥＮ＿ＭＳＢ及びＳＴＵＦＦ＿ＬＥＮ＿ＬＳＢでありうる。ＳＴＵＦＦ＿ＬＥＮ＿ＭＳＢ及びＳＴＵＦＦ＿ＬＥＮ＿ＬＳＢの後にはインバンドＡシグナリングデータが来ることができる。図３８のＣａｓｅ＃４に該当することができる。
図４３（ｅ）は、インバンドＢシグナリングと共にｎバイトのパディングを有する場合でありうる。
この場合、ＢＢフレームヘッダのＳＴＵＦＦＩが１の値を有することができる。また、ＳＴＵＦＦ＿ＯＮＥは０の値を有することができる。ＳＴＵＦＦ＿ＴＹＰＥはインバンドＢシグナリングが使用されいることを指示することができる。
即ち、実施形態によってＳＴＵＦＦ＿ＴＹＰＥは１０の値を有することもできる。ＳＴＵＦＦ＿ＴＹＰＥの値自体は前述したように変更できる。
その後、残りの１３ビットはスタッフィングフィールドの長さがｎバイトであることを指示することができる。
この１３ビットはＳＴＵＦＦ＿ＬＥＮ＿ＭＳＢ及びＳＴＵＦＦ＿ＬＥＮ＿ＬＳＢでありうる。ＳＴＵＦＦ＿ＬＥＮ＿ＭＳＢ及びＳＴＵＦＦ＿ＬＥＮ＿ＬＳＢの後にはインバンドＢシグナリングデータが来ることができる。図４２のＣａｓｅ＃５に該当することができる。
図４３（ｆ）は、インバンドＡ及びＢシグナリングと共にｎバイトのパディングを有する場合でありうる。
この場合、ＢＢフレームヘッダのＳＴＵＦＦＩが１の値を有することができる。また、ＳＴＵＦＦ＿ＯＮＥは０の値を有することができる。ＳＴＵＦＦ＿ＴＹＰＥはインバンドＡ及びＢシグナリングが全て使用されていることを指示することができる。
即ち、実施形態によって、ＳＴＵＦＦ＿ＴＹＰＥは１１の値を有することもできる。ＳＴＵＦＦ＿ＴＹＰＥの値自体は前述したように変更できる。その後、残りの１３ビットはスタッフィングフィールドの長さがｎバイトであることを指示することができる。この１３ビットはＳＴＵＦＦ＿ＬＥＮ＿ＭＳＢ及びＳＴＵＦＦ＿ＬＥＮ＿ＬＳＢでありうる。ＳＴＵＦＦ＿ＬＥＮ＿ＭＳＢ及びＳＴＵＦＦ＿ＬＥＮ＿ＬＳＢの後にはインバンドＡ及びＢシグナリングデータが来ることができる。図３８のＣａｓｅ＃６に該当することができる。
図４４は、本明細書で提案するＢＢフレーム構造の更に他の一例を示す図である。
図４４は、スタッフィングフィールド（Stuffing field）がＢＢフレームの端（ペイロードの後）に位置する場合のＢＢフレーム構造の一例を示す。
ＢＢフレームはＢＢＦヘッダ及びＢＢフレームペイロードを含む。
前記ＢＢＦヘッダは、ＢＢＦデータフィールドのフォーマットを示すためにＢＢＦフレームペイロードの前に挿入される。
前記ＢＢＦヘッダは２ｂｙｔｅｓ（バイト）の固定された長さを有することができる。
前記ＢＢＦヘッダは、ＢＢフレームにスタッフィング（Stuffing）またはパディングがあるか否かを示すインジケータに該当するＳＴＵＦＦＩフィールドを含む。前記ＳＴＵＦＦＩフィールドは１ｂｉｔで表現できる。
前記ＢＢフレームペイロードは、スタッフィングフィールド及びペイロードを含むことができる。
前記スタッフィングフィールドは、前記ＢＢフレームペイロードにＵＰが全て詰められない場合に含まれる。
一例に、前記ＳＴＵＦＦＩフィールドが‘１’に設定される場合、前記ＢＢフレームペイロードは前記スタッフィングフィールドを含むことができる。
前記ペイロードは、ＵＰ（User Packet）が含まれる領域をいう。
前記スタッフィングフィールドは、スタッフィングヘッダフィールド（または、スタッフィングフィールドヘッダ）及びスタッフィングデータ（領域）で構成できる。
前記スタッフィングデータ領域は、スタッフィングデータフィールドまたはスタッフィングデータで表現できる。
前記スタッフィングデータ領域にはスタッフィングデータ、インバンドシグナリング情報などが含まれることができる。
前記スタッフィングヘッダフィールドは、ＳＴＵＦＦ＿ＯＮＥフィールド、ＳＴＵＦＦ＿ＴＹＰＥフィールド、及びＳＴＵＦＦ＿ＬＥＮフィールドを含むことができる。
前記ＳＴＵＦＦ＿ＬＥＮフィールドは前記スタッフィングヘッダフィールドを含む全体スタッフィングフィールドの長さを示し、ＳＴＵＦＦ＿ＬＥＮ＿ＭＳＢフィールド及びＳＴＵＦＦ＿ＬＥＮ＿ＬＳＢフィールドを含むことができる。前記ＳＴＵＦＦ＿ＬＥＮフィールドは１３ｂｉｔ(ビット）で表現される。
前記ＳＴＵＦＦ＿ＯＮＥフィールドは、前記スタッフィングフィールドの長さが１ｂｙｔｅか否かを示す１ｂｉｔのフィールドをいう。
一例に、前記ＳＴＵＦＦ＿ＯＮＥフィールドが‘１’に設定された場合、前記スタッフィングフィールドの長さは１ｂｙｔｅであることを示す。この場合、前記ＳＴＵＦＦ＿ＬＥＮ＿ＬＳＢフィールドは、前記スタッフィングフィールド、即ちＳＴＵＦＦ＿ＬＥＮフィールドに含まれない。
仮に、前記ＳＴＵＦＦ＿ＯＮＥフィールドが‘０’に設定された場合、前記スタッフィングフィールドの長さは１ｂｙｔｅより大きいことを示す。この場合、前記スタッフィングヘッダの２ｂｙｔｅｓはスタッフィングデータのタイプと長さを示すために使用される。
即ち、前記ＳＴＵＦＦ＿ＴＹＰＥフィールドは、スタッフィングデータのタイプを示し、２ビットで表現できる。
以下の＜表３４＞は、図４４のＳＴＵＦＦ＿ＴＹＰＥフィールドの一例を示す。
Figure 2018504070
＜表３４＞及び図４４を参照すると、ＳＴＵＦＦ＿ＴＹＰＥフィールドが（１）‘００’に設定された場合、スタッフィングデータ領域はスタッフィングデータのみに使用され、（２）‘０１’に設定された場合、スタッフィングデータ領域はインバンドＡシグナリング情報とスタッフィングデータに使用され、（３）‘１０’に設定された場合、スタッフィングデータ領域はインバンドＢシグナリング情報とスタッフィングデータに使用され、（４）‘１１’に設定された場合、スタッフィングデータ領域はインバンドＡシグナリング情報、インバンドＢシグナリング情報、及びスタッフィングデータに使用される。
＜表３４＞で、インバンドＡはインバンドＩＳＳＹであり、インバンドＢはインバンドＰＬＳでありうる。
前記ＳＴＵＦＦ＿ＬＥＮ＿ＭＳＢフィールドは、前記スタッフィングヘッダフィールドを含む全体スタッフィングフィールド長さのＭＳＢ（Most Significant Bit）値を示し、５ｂｉｔで表現される。
一例に、ＳＴＵＦＦ＿ＯＮＥフィールドが‘１’に設定された場合、前記ＳＴＵＦＦ＿ＬＥＮ＿ＭＳＢフィールドは‘１１１１１’で表現できる。または、‘０００００’に設定されることもできる。
前記ＳＴＵＦＦ＿ＬＥＮ＿ＬＳＢフィールドは、全体スタッフィングフィールド長さのＬＳＢ（Least Significant Bit）値を示し、８ビットで表現される。
前記スタッフィングデータフィールドはスタッフィング及び／又はインバンドシグナリングフィールドを含むことができる。
ここで、‘スタッフィング及び／又はインバンドシグナリング’は、スタッフィング、インバンド シグナリング、またはスタッフィング及びインバンドシグナリングを意味する。
即ち、‘Ａ及び／又はＢ’の表現はＡまたはＢのうち、少なくともいずれか１つの意味と同一でありうる。
図４４を参照すると、スタッフィングフィールドのＮｔｈ Ｂｙｔｅの第８のビットはＳＴＵＦＦ＿ＯＮＥフィールドを示し、Ｎｔｈ Ｂｙｔｅの第６及び第７のビットはＳＴＵＦＦ＿ＴＹＰＥフィールドを示し、スタッフィングフィールドのＮｔｈ Ｂｙｔｅの第１のビット乃至第５のビットはＳＴＵＦＦ＿ＬＥＮ＿ＬＳＢフィールドを示し、スタッフィングフィールドの（Ｎ−１）ｔｈ ＢｙｔｅはＳＴＵＦＦ＿ＬＥＮ＿ＭＳＢフィールドを示すことを見ることができる。
また、スタッフィングフィールドの（Ｎ−２）ｔｈ Ｂｙｔｅからデータ（ＵＰ）またはスタッフィングデータまたはインバンドＡデータまたはインバンドＢデータ、またはインバンドＡ及びＢデータを示すことを見ることができる。
図４４のＣａｓｅ＃１乃至Ｃａｓｅ＃６に対するより具体的な説明は、各々対応する図４２のＣａｓｅ＃１乃至Ｃａｓｅ＃６の説明を参照する。
図４４のフレーム構造は、図４２のフレーム構造と同一な機能を遂行することができる。
図４４に図示されたＢＢフレーム構造のように、スタッフィングフィールドがＢＢフレームの端に位置する場合、受信装置でスタッフィング確認無しでＵＰ（User Packet）を直ぐ受信することができるので、ＵＰに対するアクセス時間が図３８に図示されたＢＢフレーム構造に比べて短くなる効果がある。
図４５は、本明細書で提案するＢＢフレーム構造の更に他の一例を示す図である。
図４５は、スタッフィングフィールドがＢＢフレームの最後に位置（または、ペイロード、ＦＥＣフレームの後に位置）する場合の多様なＢＢフレーム構造を示す。
図４５のフレーム構造は、図４３のフレーム構造とスタッフィングフィールドの位置のみ異なり、他の部分は全て同一であるので、図４５に対する具体的な説明は、図４３を参照する。
図４６は、多様なＢＢフレーム構造でＢＢフレーム送信に対するオーバーヘッドを計算した結果を比較して示す図である。
ＤＶＢ−Ｔ２で表記されたグラフは、前述した従来技術のオーバーヘッドグラフでありうる。ＤＶＢ−Ｔ２とは、ＤＶＢ（Digital Video Broadcasting）の地上波ＴＶ放送システム（terrestrial television broadcasting system）関連標準を意味することができる。ＤＶＢ−Ｔ２とは、ヨーロッパの次世代地上波放送に関連した標準を意味することができる。ＤＶＢ−Ｔ２で表記されたグラフは、この標準技術に従うＢＢフレームにおいて、そのオーバーヘッドを計算したグラフでありうる。
ＭＨで表記されたグラフは、前述した他の従来技術のオーバーヘッドグラフでありうる。ＭＨとは、ＣＥＡ（Consumer Electronics Association）のモバイル／ハンドヘルド（Mobile／Handheld）ＤＴＶシステム関連標準を意味することがきる。ＭＨとは、北−米モバイルハンドヘルド（mobile handheld）関連標準を意味することができる。ＭＨで表記されたグラフは、この標準技術に従うＢＢフレームにおいて、そのオーバーヘッドを計算したグラフでありうる。
ＳＳ ＆ ＳＮで表記されたグラフは、前述した更に他の従来技術のオーバーヘッドグラフでありうる。ＳＳ ＆ ＳＮは、従来技術のうちの１つを意味することができる。この従来技術で提示する方法によりＢＢフレーム及びＢＢフレームヘッダを構成した時のオーバーヘッドを計算したグラフが、ＳＳ ＆ ＳＮで表記されたグラフで図示されている。
以下の＜表３５＞は各ＢＢフレーム送信時、オーバーヘッドを計算した結果を示した表である。
Figure 2018504070
オーバーヘッドは、データフィールドの長さを示すフィールドのオーバーヘッドを意味することができる。
従来技術は毎ＢＢフレームに２バイトのフィールドを使用するので、オーバーヘッドを最大０．２２％有することができる。
他の従来技術は１ビットのフィールドのみを使用するので、オーバーヘッドを最大０．０１３９％のみを有することができる。最も低い場合でありうる。
更に他の従来技術は２ビットのフィールドを使用することができる。この場合、オーバーヘッドは他の従来技術に比べて２倍でありうる。
ＬＧで表記されたグラフは、本発明によるオーバーヘッドグラフでありうる。本発明の場合、スタッフィングフィールドのシグナリングのために１ビットのフィールドのみを使用することができる。したがって、オーバーヘッドが最小になることができる。また、追加的に余分の２ビットフィールドを設けることによって、インバンドシグナリングのタイプなどを指示することに活用できるという長所がある。本発明はこの余分のフィールドを用いて、ＢＢフレームの構成を示すなど、他の用途にも利用可能な構造をサポートすることができる。
図４７は、従来のＢＢフレーム構造の一例を示す。
図４７に示すように、ＢＢフレームはヘッダ、オプショナルヘッダ、及びペイロードデータを含んで構成される。
前記ヘッダは、ＰＳＰＭＩ（Packet Start Pointer Mode Indicator）フィールド、ＰＡＤＩ（Padding Indicator）フィールド、ＰＫＴＳＰＴＲ＿ＬＳＢ（Packet Start Pointer Low Significant Bits）フィールドを含む。
前記ＰＳＰＭＩフィールドは、ＰＫＴＳＰＴＲ（Packet Start Pointer）フィールドがショートモード（short mode）か、またはロングモード（long mode）かを示す１ｂｉｔの大きさのフラグフィールドをいう。
前記ＰＫＴＳＰＴＲ（Packet Start Pointer）フィールドはＳＹＮＣＤフィールドと同一な概念でありうる。
即ち、前記ＰＳＰＭＩフィールドはＰＫＴＳＰＴＲ（Packet Start Pointer）フィールドの長さが短いか長いかを表示してくれるフラグをいう。
前記ＰＫＴＳＰＴＲ＿ＬＳＢ（Packet Start Pointer Low Significant Bits）フィールドは、１３ｂｉｔのＰＫＴＳＰＴＲ（Packet Start Pointer）フィールドの５ＬＳＢ ｂｉｔｓを示す。
前記オプショナルヘッダは、ＰＫＴＳＰＴＲ＿ＭＳＢ（Packet Start Pointer Most Significant Bits）フィールド、パディング（PADDING）フィールドを含むことができる。
前記ＰＫＴＳＰＴＲ＿ＭＳＢフィールドは、１３ｂｉｔのＰＫＴＳＰＴＲ（Packet Start Pointer）フィールドの８ＭＳＢ ｂｉｔｓを示す。
また、前記パディングフィールドはＰＡＤＬ（Padding data Length）フィールド及びＰＡＤＤＩＮＧ＿ＤＡＴＡフィールドを含むことができる。
前記ＰＡＤＬフィールドはパディングデータフィールドの長さを示し、１６ｂｉｔの大きさを有する。
前記ＰＡＤＤＩＮＧ＿ＤＡＴＡフィールドは可変的な長さを有し、パディング情報を示す。
図４７に示すように、ＢＢフレーム構造は最大１３ｂｙｔｅの（Payload）データフィールドの長さを表現するために、前記データフィールドの長さを示す情報（例：ＤＦＬ）を使用せず、ＰＡＤＤＩＮＧフィールドの長さを送信して受信装置でデータフィールドの長さを計算するようになっている。
ここで、前記パディングフィールドの長さはＢＢフレームのペイロードデータサイズ−データフィールド長さに該当する。
ＢＢフレームにパディングフィールドが存在しない場合にはＢＢフレームサイズを用いてＤＦＬ（data Field Length）を計算する。
前記ＢＢフレームにパディングフィールドがある場合にはＢＢフレームヘッダに２ｂｉｔのＰＡＤＩを含むことによって、パディングの長さを知らせるようになる。
より効率的に、ＦＥＣブロックにＢＢＦ（BaseBand Frame）を送信するために、即ちＢＢフレームヘッダ送信に対するオーバーヘッドを減らすために、ＰＫＴＳＰＲＴフィールドをＰＫＴＳＰＴＲ＿ＬＳＢ及びＰＫＴＳＰＴＲ＿ＭＳＢに分けて運用する。
即ち、ＰＫＴＳＰＴＲフィールドは２ｂｙｔｅの大きさまでサポート可能であるが、前記ＰＫＴＳＰＴＲフィールドの長さが短い場合（≦３１ｂｙｔｅ）、ＰＫＴＳＰＴＲ＿ＬＳＢのみ使用することができるので、前記ＰＫＴＳＰＴＲフィールドの送信大きさを１ｂｙｔｅに減らすことができる。
しかしながら、ＰＫＴＳＰＴＲ＿ＬＳＢの長さが５ｂｉｔと短いため、ＰＫＴＳＰＴＲフィールドの大きさが３１ｂｙｔｅ以下の場合のみに１ｂｙｔｅのＢＢＦヘッダ構成が可能であるという短所がある。
図３９で説明したように、従来のＢＢフレームはＢＢフレームのデータフィールドの長さを受信装置（または、受信端）に知らせるためにＤＦＬ（data field length：１６ビット、１１ビット）をＢＢフレームヘッダごとに割り当てて使用しているので、ＢＢフレームをＦＥＣブロックに送信するに当たってオーバーヘッドが大きく発生する。
したがって、ＢＢフレームヘッダに対する送信効率を高めて、エラー確認（error check）の新たな機能を追加するための新たなＢＢフレーム構造について具体的に説明する。
即ち、本明細書はＢＢフレームヘッダに含まれるＳＹＮＣＤフィールドの大きさを調節して全体的にＢＢフレームヘッダの大きさを減らす方法、ＢＢフレームヘッダ内の余分の１ｂｉｔを活用してエラー確認を遂行する方法などを提供する。
以下、本明細書で提案する方法及びＢＢフレーム構造は、送信装置ではＢＢフレームヘッダ挿入（BB Frame Header Insertion）ブロックで、受信装置ではＢＢフレームヘッダパーサ（BB Frame Header Parser）ブロックで動作する。
図４８は、本明細書における提案するＢＢフレーム構造の一例を示す図である。
図４８ａのインプットストリームはインプットフォーマッティングモジュールのモードアダプテーション（mode adaptation）モジュールを通じて図４８ｂのＢＢフレーム構造を形成する。
図４８に示すように、複数のパケットを含むインプットストリームはモードアダプテーションモジュールを通じてペイロード（Payload）にスライシング（slicing）またはマッピングされ、前記ペイロードの前に前記ペイロードと関連した情報を含むヘッダが付加される。
前記ペイロードは、ＢＢフレームデータフィールドで表現できる。
前記ヘッダは、ＯＰＴＩＯＮＩフィールド、ＳＴＵＦＦＩフィールド、ＳＹＮＣＤ＿ＬＳＢフィールド、ＳＹＮＣＤ＿ＭＳＢフィールド、Checksumフィールド、またはStuffingフィールドのうち、少なくとも１つを含んで構成できる。
前述したように、前記Stuffingフィールドは、Stuffing Headerフィールド及びStuffing Byteフィールドを含むことができる。
前記Stuffing Byteフィールドは、スタッフィングデータフィールドまたはスタッフィングデータ領域で表現されることもできる。
前記ＯＰＴＩＯＮＩフィールド、ＳＴＵＦＦＩフィールド、及びＳＹＮＣＤ＿ＬＳＢフィールドを含むＢＢフレームヘッダが定義されることもでき、ＳＹＮＣＤ＿ＭＳＢフィールド及びChecksumフィールドを含むオプションヘッダが定義されることもできる。
図４８の場合、ＢＢフレームヘッダ及びオプションヘッダが定義されたことを見ることができる。
また、前記スタッフィングフィールドは前記ヘッダに含まれることもでき、前記ヘッダに含まれないこともできる。
前記スタッフィングフィールドが前記ヘッダに含まれない場合には、前記ペイロードと共にＢＢフレームペイロードを構成することができる。
前記スタッフィングフィールドはペイロードの前に位置するか（図４８）、または前記ペイロードの後に位置することもできる。
ＳＹＮＣＤフィールドは、データフィールドの開始から前記データフィールドで始まる最初に送信されるＵＰ（User Packet）の開始までの距離を示すことができる。
ここで、前記ＳＹＮＣＤフィールドはＳＹＮＣＤ＿ＬＳＢフィールド及びＳＹＮＣＤ＿ＭＳＢフィールドに区分されることができ、１３ｂｉｔの大きさを有する。
前記ＳＹＮＣＤ＿ＬＳＢフィールドはＳＹＮＣＤのＬＳＢ（Least Significant bit）を示す値で、６ｂｉｔｓの大きさを有し、最大６３ｂｙｔｅのＳＹＮＣＤを表現することができる。
図４８に示すように、ヘッダがＢＢフレームヘッダとオプションヘッダに区分される場合、前記ＳＹＮＣＤ＿ＬＳＢフィールドは前記ＢＢフレームヘッダに含まれることができる。
また、前記ＳＹＮＣＤ＿ＭＳＢフィールドはＳＹＮＣＤのＭＳＢ（Most Significant bit）を示す値で、７ｂｉｔｓの大きさを有する。
図４８に示すように、ヘッダがＢＢフレームヘッダとオプションヘッダに区分される場合、前記ＳＹＮＣＤ＿ＭＳＢフィールドは前記オプションヘッダに含まれることができる。
前記ＳＹＮＣＤ＿ＭＳＢフィールドはＯＰＴＩＯＮＩフィールドにより使用有無が定まる。
前記ＯＰＴＩＯＮＩフィールドはペイロードを通じて送信されるパケットのうち、新しく始まるパケットの位置がＳＹＮＣＤ＿ＬＳＢ（６ビット）で表現できるか否かを示す。
一例に、前記ＯＰＴＩＯＮＩフィールドが‘０’に設定された場合、ペイロードを通じて送信されるパケットのうち、新しく始まるパケットの位置がＳＹＮＣＤ＿ＬＳＢ（６ビット）で表現できることを示す。
前記ＯＰＴＩＯＮＩフィールドが‘１’に設定された場合、ペイロードを通じて送信されるパケットのうち、新しく始まるパケットの位置がＳＹＮＣＤ＿ＬＳＢ（６ビット）で表現できない場合を示す。
したがって、前記ＯＰＴＩＯＮＩフィールドが‘１’に設定された場合、ＳＹＮＣＤ＿ＬＳＢフィールド（６ビット）及びＳＹＮＣＤ＿ＭＳＢフィールド（７ビット）を用いてペイロード内の新しく始まるパケットの位置を示さなければならない。
ここで、前記ＳＹＮＣＤ＿ＭＳＢフィールドがオプションヘッダに含まれる場合には前記オプションヘッダがＢＢフレームに含まれる。
前記ＳＴＵＦＦＩフィールドは１ｂｉｔの大きさを有し、ＢＢフレームにStuffingフィールド（または、Stuffing byte）、またはin-band Signalingフィールドが存在するかを示すインジケータをいう。
前記チェックサム（Check-sum）フィールドは１ｂｉｔの大きさで、ＢＢフレームヘッダまたはＯＰＴＩＯＮＩフィールドのエラー確認のための用途に使用できる。
前記チェックサム（Check-sum）フィールドは、ヘッダがＢＢフレームヘッダ及びオプションヘッダに区分される場合、前記オプションヘッダに含まれることができる。
説明したように、前記Stuffingフィールドはスタッフィングヘッダ及びスタッフィングバイトを含む。
図４８のＳＹＮＣＤ＿ＬＳＢフィールドと図４３のＰＫＴＳＰＴＲ＿ＬＳＢフィールドは同一な意味として使用できる。
ここで、前記ＰＫＴＳＰＴＲ＿ＬＳＢフィールドの大きさは５ｂｉｔｓである一方、本明細書で提案する図４８のＳＹＮＣＤ＿ＬＳＢフィールドの大きさは６ｂｉｔｓで、１ｂｉｔ増加するようになる。
即ち、５ｂｉｔｓのＰＫＴＳＰＴＲ＿ＬＳＢフィールドで表現できるＰＫＴＳＰＴＲの長さは最大３１（２５−１）ｂｙｔｅｓであることに比べて、６ｂｉｔｓのＳＹＮＣＤ＿ＬＳＢフィールドで表現できるＳＹＮＣＤの長さは６３（２６−１）ｂｙｔｅｓで、約２倍が増加するようになる。
即ち、本明細書で提案するＳＹＮＣＤ＿ＬＳＢフィールドの大きさ調節を通じてＳＹＮＣＤ＿ＭＳＢフィールドがヘッダまたはＢＢフレームヘッダまたはオプションヘッダに追加される場合が減るようになって、ＢＢフレームの送信に対するオーバーヘッドを減らすようになる。
例えば、１８８ｂｙｔｅのＭＰＥＧ２−ＴＳストリームを送信すると仮定する。
（１）図４７のＢＢフレーム構造の場合、１８８ｂｙｔｅのＴＳパケットを送信するためにＢＢフレームヘッダにＰＫＴＳＰＴＲ＿ＬＳＢフィールドのみ含まれる場合（即ち、ＰＫＴＳＰＴＲ長さが３１ｂｙｔｅ以下の値を有する場合）は約１６．４９％（３１ｂｙｔｅ／１８８ｂｙｔｅ）に該当する。
即ち、１６．４９％に該当するＢＢフレームは１ｂｙｔｅの大きさを有するヘッダを含み、残りの８３．５１％に該当するＢＢフレームは２ｂｙｔｅの大きさを有するヘッダを含む。
ここで、前記ヘッダはペイロードと関連したフォーマットを示し、ＢＢフレームヘッダを意味するか、またはＢＢフレームヘッダ及びオプションヘッダを含む意味でありうる。
したがって、平均的にＢＢフレームは１．８３ｂｙｔｅの大きさを有するヘッダを含むようになる。
（２）一方、図４８のＢＢフレーム構造の場合、１８８ｂｙｔｅのＴＳパケットを送信するためにＢＢフレームヘッダにＳＹＮＣＤ＿ＬＳＢフィールドのみが含まれる場合（即ち、ＳＹＮＣＤ長さが６３ｂｙｔｅ以下の値を有する場合）は約３３．５１％（６３ｂｙｔｅ／１８８ｂｙｔｅ）に該当する。
即ち、３３．５１％に該当するＢＢフレームは１ｂｙｔｅの大きさを有するヘッダを含み、残りの６６．４９％に該当するＢＢフレームは２ｂｙｔｅの大きさを有するヘッダを含む。
したがって、平均的にＢＢフレームは１．６６ｂｙｔｅの大きさを有するＢＢフレームヘッダを含むようになることで、図４７のＢＢフレーム構造を有する場合よりＢＢフレーム送信に対するオーバーヘッドを格段に減らすことができることが分かる。
また、図４８のＢＢフレーム構造はオプショナルヘッダに含まれる１ｂｉｔをヘッダのチェックサム１ｂｉｔに使用するか、または前記ヘッダに含まれるＯＰＴＩＯＮＩフィールドのチェックサム１bitに使用することによって、ヘッダに対するエラーが検出できる追加機能を遂行することができるようになる。
図４９は、本明細書で提案するＢＢフレーム構造の更に他の一例を示す図である。
図４９のＢＢフレーム構造は、図４８のＢＢフレーム構造とＳＹＮＣＤ＿ＬＳＢフィールド／ＳＹＮＣＤ＿ＭＳＢフィールドの大きさとＳＴＵＦＦＩフィールドの位置において相異し、他の部分は同一である。
以下、図４８のＢＢフレーム構造と同一な部分に対する説明は省略し、差がつく部分を中心に説明する。
ＯＰＴＩＯＮＩフィールド及びＳＹＮＣＤ＿ＬＳＢフィールドが合わせられてＢＢフレームヘッダとして定義されることができ、ＳＹＮＣＤ＿ＭＳＢフィールド、ＳＴＵＦＦＩフィールド、及びチェックサムフィールドが合わせられてオプションヘッダとして定義できる。
また、ＯＰＴＩＯＮＩフィールド、ＳＹＮＣＤ＿ＬＳＢフィールド、ＳＹＮＣＤ＿ＭＳＢフィールド、ＳＴＵＦＦＩフィールド、Checksumフィールドが合わせられて１つのヘッダとして定義できる。
この場合、前記ヘッダをＢＢフレームヘッダとして表現することもできる。
更に他の一例として、前記ＳＴＵＦＦＩフィールド及び前記Checksum フィールドは特定フィールドに合わせられることができる。これについては、後述する図５０及び図５１で具体的に説明する。図４９に示すように、前記ＳＹＮＣＤ＿ＬＳＢフィールドの大きさは７ｂｉｔであり、前記ＳＹＮＣＤ＿ＭＳＢフィールドの大きさは６ｂｉｔである。
図４９のように、前記ＳＹＮＣＤ＿ＬＳＢフィールドの大きさが７ｂｉｔの場合、より多い数のＳＹＮＣＤの長さを表現できるようになる。
即ち、前記ＳＹＮＣＤ＿ＬＳＢフィールドの大きさが７ｂｉｔの場合、表現できるＳＹＣＮＤの長さは１２７（２７−１）ｂｙｔｅであって、図４８の場合（３１ｂｙｔｅ）より約４倍増加するようになる。
同様に、１８８ｂｙｔｅのＭＰＥＧ２−ＴＳストリームを送信すると仮定する。
図４９のＢＢフレーム構造の場合、１８８ｂｙｔｅのＴＳパケットを送信するためにヘッダにＳＹＮＣＤ＿ＬＳＢフィールドのみ含まれる場合（即ち、ＳＹＮＣＤ長さが１２７ｂｙｔｅ以下の値を有する場合）は、約６７．５５％（１２７ｂｙｔｅ／１８８ｂｙｔｅ）に該当する。
即ち、６７．５５％に該当するＢＢフレームは１ｂｙｔｅの大きさを有するヘッダを含み、残りの３２．４５％に該当するＢＢフレームは２ｂｙｔｅの大きさを有するヘッダを含む。
したがって、平均的にＢＢフレームは１．３２ｂｙｔｅの大きさを有するヘッダを含むようになって、図４７及び図４８のＢＢフレーム構造を有する場合よりＢＢフレーム送信に対するオーバーヘッドを格段に減らすことができるようになる。
図４９のＢＢフレーム構造でも同様に、ヘッダに存在する余分の１ｂｉｔをチェックサムに活用することによって（ヘッダのチェックサム１ビットに使用するか、またはＯＰＴＩＯＮＩフィールドのチェックサムに使用）、ヘッダに対するエラー確認を追加的に遂行できるようになる。
図５０は、本明細書で提案するＢＢフレーム構造のさらに他の一例を示す図である。
図５０に示すように、前述したＳＴＵＦＦＩフィールド及びＣｈｅｃｋｓｕｍフィールドは、１つの特定フィールド５０１０に合わせられることができる。
前記特定フィールド５０１０は、ＢＢフレーム内のＳｔｕｆｆｉｎｇ ｆｉｅｌｄの存在可否を表す値で使用されることができる。
前記特定フィールド５０１０は、ＥＸＴ＿Ｉ（Ｅｘｔｅｎｓｉｏｎ Ｉｎｄｉｃａｔｏｒ）フィールドで表現されることができ、２ｂｉｔの大きさを有することができる。
また、前記特定フィールド５０１０は、ＯＰＴＩ（Ｏｐｔｉｏｎａｌ Ｈｅａｄｅｒ Ｉｎｄｉｃａｔｏｒ）フィールドで表現されることができる。
前記ＯＰＴＩフィールドは、Ｓｔｕｆｆｉｎｇが含まれたヘッダの存在可否を表すフィールドを意味できる。
ＢＢ ｆｒａｍｅは、Ｈｅａｄｅｒ及びＰａｙｌｏａｄで構成されることができ、前記Ｈｅａｄｅｒは、１つ以上のｓｕｂ−ｈｅａｄｅｒなどで構成されることができる。
すなわち、前記１つ以上のｓｕｂ−ｈｅａｄｅｒは、第１のヘッダ、第２のヘッダ、第３のヘッダなどで表現されることができる。
一例として、前記第１のヘッダは、ＢＢＦ Ｈｅａｄｅｒ、Ｂａｓｅ Ｈｅａｄｅｒなどで表現されることができ、前記第２のヘッダは、Ｏｐｔｉｏｎ Ｈｅａｄｅｒ、Ｏｐｔｉｏｎａｌ Ｈｅａｄｅｒなどで表現されることができる。
前記特定フィールド５０１０は、ＢＢ ｆｒａｍｅのＯｐｔｉｏｎ（ａｌ） Ｈｅａｄｅｒに含まれることができる。
下記の表３６は、特定フィールド（ＥＸＴ＿Ｉフィールド）フォーマットの一例を示した表である。
Figure 2018504070
表３６において、前記特定フィールド値が（１）‘００’である場合、ＢＢフレーム内にスタッフィングがない場合を表し、（２）‘０１’である場合、ＢＢフレーム内に１ｂｙｔｅのスタッフィングが存在する場合を表し、（３）‘１０’である場合、ＢＢフレーム内に２ｂｙｔｅのスタッフィングが存在する場合を表し、（４）‘１１’である場合、ＢＢフレーム内に３ｂｙｔｅ以上のスタッフィングが存在する場合を表すことができる。
前述したように、Ｓｔｕｆｆｉｎｇフィールドは、Ｓｔｕｆｆｉｎｇ Ｈｅａｄｅｒフィールド及びＳｔｕｆｆｉｎｇ Ｂｙｔｅフィールドを含むことができる。
また、前記Ｓｔｕｆｆｉｎｇ Ｈｅａｄｅｒフィールドは、ＳＴＵＦＦ＿ＴＹＰＥフィールド、ＳＴＵＦＦ＿ＬＥＮ＿ＬＳＢフィールド、及びＳＴＵＦＦ＿ＬＥＮ＿ＭＳＢフィールドを含むことができる。
前記ＳＴＵＦＦ＿ＴＹＰＥフィールドは、ＥＸＴ＿ＴＹＰＥ（Ｅｘｔｅｎｓｉｏｎ Ｔｙｐｅ）フィールドで表現されることができる。この場合、前記ＥＸＴ＿ＴＹＰＥフィールドは、スタッフィングフィールドのタイプを表すことができる。
また、前記スタッフィングフィールドは、Ｅｘｔｅｎｓｉｏｎフィールドで表現されることもできる。
前記ＳＴＵＦＦ＿ＴＹＰＥフィールドは、前記ＥＸＴ＿Ｉフィールドが‘０１’または‘１０’または‘１１’値を有する場合、ＢＢ ｆｒａｍｅまたは前記ＢＢ ｆｒａｍｅヘッダに含まれることができる。これに関する具体的な内容は、下記の表３７を参照する。
前記ＳＴＵＦＦ＿ＴＹＰＥフィールドは、３ｂｉｔｓ、前記ＳＴＵＦＦ＿ＬＥＮ＿ＬＳＢフィールドは、５ｂｉｔｓ、前記ＳＴＵＦＦ＿ＬＥＮ＿ＭＳＢフィールドは、８ｂｉｔｓでありうる。
前記ＳＴＵＦＦ＿ＬＥＮ＿ＬＳＢフィールドは、ＥＸＴ＿ＬＥＮＬＳＢフィールドで、前記ＳＴＵＦＦ＿ＬＥＮ＿ＭＳＢフィールドは、ＥＸＴ＿ＬＥＮ＿ＭＳＢフィールドで表現されることができる。
以下では、前記特定フィールド値に応じて定義され得るＳＴＵＦＦ＿ＴＹＰＥフィールド、ＳＴＵＦＦ＿ＬＥＮフィールド、及びその意味について表３７を一例に挙げて説明する。
Figure 2018504070
表３７において、特定フィールド（例：ＥＸＴ＿Ｉフィールド）値が‘００’である場合、スタッフィングがないので、前記ＳＴＵＦＦ＿ＴＹＰＥフィールド及びＳＴＵＦＦ＿ＬＥＮフィールドは、スタッフィングフィールドに存在しない。
前記特定フィールド値が‘０１’であり、前記ＳＴＵＦＦ＿ＴＹＰＥフィールド値が‘０００’であり、前記ＳＴＵＦＦ＿ＬＥＮフィールド値が‘０００００’である場合、１ｂｙｔｅスタッフィングがＢＢフレーム（または、スタッフィングフィールド）に含まれることを表すことができる。
前記特定フィールド値が‘１０’であり、前記ＳＴＵＦＦ＿ＴＹＰＥフィールド値が‘０００’であり、前記ＳＴＵＦＦ＿ＬＥＮフィールド値が‘０００００’である場合、２ｂｙｔｅスタッフィングがＢＢフレーム（または、スタッフィングフィールド）に含まれることを表すことができる。前記特定フィールド値が‘１１’であり、前記ＳＴＵＦＦ＿ＴＹＰＥフィールド値が‘０００’であり、前記ＳＴＵＦＦ＿ＬＥＮフィールド値が‘ｓｔｕｆｆ＿ｌｅｎ’である場合、３ｂｙｔｅ以上のスタッフィングがＢＢフレーム（または、スタッフィングフィールド）に含まれることを表すことができる。
前記特定フィールド値が‘１１’であり、前記ＳＴＵＦＦ＿ＴＹＰＥフィールド値が‘００１’であり、前記ＳＴＵＦＦ＿ＬＥＮフィールド値が‘ｓｔｕｆｆ＿ｌｅｎ’である場合、スタッフィングとｉｎ−ｂａｎｄ Ａ ｓｉｇｎａｌｉｎｇがＢＢフレーム（または、スタッフィングフィールド）に含まれることを表すことができる。
前記ｉｎ−ｂａｎｄ Ａは、ＩＮＢＡＮＤ＿ＩＳＳＹでありうる。
前記特定フィールド値が‘１１’であり、前記ＳＴＵＦＦ＿ＴＹＰＥフィールド値が‘０１０’であり、前記ＳＴＵＦＦ＿ＬＥＮフィールド値が‘ｓｔｕｆｆ＿ｌｅｎ’である場合、スタッフィングとｉｎ−ｂａｎｄ Ｂ ｓｉｇｎａｌｉｎｇがＢＢフレーム（または、スタッフィングフィールド）に含まれることを表すことができる。
前記ｉｎ−ｂａｎｄ Ｂは、ＩＮＢＡＮＤ＿ＳＩＧでありうる。
前記特定フィールド値が‘１１’であり、前記ＳＴＵＦＦ＿ＴＹＰＥフィールド値が‘１１１’であり、前記ＳＴＵＦＦ＿ＬＥＮフィールド値が‘ｓｔｕｆｆ＿ｌｅｎ’である場合、スタッフィング及び他の情報がＢＢフレーム（または、スタッフィングフィールド）に含まれることを表すことができる。
また、前記ＳＴＵＦＦ＿ＬＥＮフィールド値は、ＳＴＵＦＦ＿ＬＥＮ＿ＬＳＢフィールド（５ｂｉｔ）値とＳＴＵＦＦ＿ＬＥＮ＿ＭＳＢフィールド（８ｂｉｔ）値とに区分されることができる。
これについて、表３８を参考して説明する。
Figure 2018504070
表３８において、前記特定フィールド値が‘０１’であり、前記ＳＴＵＦＦ＿ＴＹＰＥフィールド値が‘０００’であり、前記ＳＴＵＦＦ＿ＬＥＮ＿ＬＳＢフィールド値が‘０００００’であり、前記ＳＴＵＦＦ＿ＬＥＮ＿ＭＳＢフィールド値が‘Ｎｏｔ ｅｘｉｓｔ’である場合、１ｂｙｔｅスタッフィングがＢＢフレーム（または、スタッフィングフィールド）に含まれることを表すことができる。
前記特定フィールド値が‘１０’であり、前記ＳＴＵＦＦ＿ＴＹＰＥフィールド値が‘０００’であり、前記ＳＴＵＦＦ＿ＬＥＮ＿ＬＳＢフィールド値が‘０００００’であり、前記ＳＴＵＦＦ＿ＬＥＮ＿ＭＳＢフィールド値が‘００００００００’である場合、２ｂｙｔｅスタッフィングがＢＢフレーム（または、スタッフィングフィールド）に含まれることを表すことができる。
前記特定フィールド値が‘１１’であり、前記ＳＴＵＦＦ＿ＴＹＰＥフィールド値が‘０００’であり、前記ＳＴＵＦＦ＿ＬＥＮ＿ＬＳＢフィールド値が‘ｓｔｕｆｆ＿ｌｅｎ＿ｌｓｂ’であり、前記ＳＴＵＦＦ＿ＬＥＮ＿ＭＳＢフィールド値が‘ｓｔｕｆｆ＿ｌｅｎ＿ｍｓｂ’である場合、３ｂｙｔｅ以上のスタッフィングがＢＢフレーム（または、スタッフィングフィールド）に含まれることを表すことができる。
前記特定フィールド値が‘１１’であり、前記ＳＴＵＦＦ＿ＴＹＰＥフィールド値が‘００１’であり、前記ＳＴＵＦＦ＿ＬＥＮ＿ＬＳＢフィールド値が‘ｓｔｕｆｆ＿ｌｅｎ＿ｌｓｂ’であり、前記ＳＴＵＦＦ＿ＬＥＮ＿ＭＳＢフィールド値が‘Ｎｏｔ ｅｘｉｓｔ’である場合、ｉｎ−ｂａｎｄ Ａ ｓｉｇｎａｌｉｎｇのみがＢＢフレーム（または、スタッフィングフィールド）に含まれることを表すことができる。前記ｉｎ−ｂａｎｄ Ａ ｓｉｇｎａｌｉｎｇのみがスタッフィングフィールドに含まれる場合は、前記ｉｎ−ｂａｎｄ Ａ ｓｉｇｎａｌｉｎｇが３２ｂｙｔｅで表現可能な場合のみに使用することが好ましい。前記ｉｎ−ｂａｎｄ Ａは、ＩＮＢＡＮＤ＿ＩＳＳＹでありうる。
前記特定フィールド値が‘１１’であり、前記ＳＴＵＦＦ＿ＴＹＰＥフィールド値が‘０１０’であり、前記ＳＴＵＦＦ＿ＬＥＮ＿ＬＳＢフィールド値が‘ｓｔｕｆｆ＿ｌｅｎ＿ｌｓｂ’であり、前記ＳＴＵＦＦ＿ＬＥＮ＿ＭＳＢフィールド値が‘ｓｔｕｆｆ＿ｌｅｎ＿ｍｓｂ’である場合、スタッフィングとｉｎ−ｂａｎｄ Ａ ｓｉｇｎａｌｉｎｇがＢＢフレーム（または、スタッフィングフィールド）に含まれることを表すことができる。
前記特定フィールド値が‘１１’であり、前記ＳＴＵＦＦ＿ＴＹＰＥフィールド値が‘１１１’であり、前記ＳＴＵＦＦ＿ＬＥＮ＿ＬＳＢフィールド値が‘ｓｔｕｆｆ＿ｌｅｎ＿ｌｓｂ’であり、前記ＳＴＵＦＦ＿ＬＥＮ＿ＭＳＢフィールド値が‘ｓｔｕｆｆ＿ｌｅｎ＿ｍｓｂ’である場合、スタッフィング及び他の情報がＢＢフレーム（またはスタッフィングフィールド）に含まれることを表すことができる。
図５１は、本明細書で提案するＢＢフレーム構造のさらに他の一例を示す図である。
図５１の場合、ＳＴＵＦＦ＿ＴＹＰＥフィールドの利用方法と関連したものであって、３ｂｉｔｓのＳＴＵＦＦ＿ＴＹＰＥフィールドを効率的な利用のために、１ｂｉｔのＭＳＢ＿Ｉ（ＭＳＢ Ｉｎｄｉｃａｔｏｒ）フィールド５１１１と２ｂｉｔｓのＳＴＵＦＦ＿ＴＹＰＥフィールド５１１２とに分割して利用する方法を提供する。
前記ＭＳＢ＿Ｉフィールド５１１１は、ＳＴＵＦＦ＿ＬＥＮ＿ＭＳＢフィールドの存在有無を表すｉｎｄｉｃａｔｏｒをいう。
一例として、前記ＭＳＢ＿Ｉフィールド値が‘０’である場合、Ｓｔｕｆｆｉｎｇ Ｈｅａｄｅｒ内にＳＴＵＦＦ＿ＬＥＮ＿ＬＳＢ（５ｂｉｔ）のみが使用されることを表すことができ、前記ＭＳＢ＿Ｉフィールド値が‘１’である場合、Ｓｔｕｆｆｉｎｇ Ｈｅａｄｅｒ５１１０内にＳＴＵＦＦ＿ＬＥＮ＿ＬＳＢ（５ｂｉｔｓ）フィールド及びＳＴＵＦＦ＿ＬＥＮ＿ＭＳＢ（８ｂｉｔｓ）フィールドが使用されることを表すことができる。
一例として、前記ＭＳＢ＿Ｉフィールド値が‘０’である場合、ＳＴＵＦＦ＿ＬＥＮ＿ＬＳＢ（５ｂｉｔｓ）フィールドのみがＳｔｕｆｆｉｎｇ Ｈｅａｄｅｒに使用され（または、含まれ）、表現できるＳｔｕｆｆｉｎｇフィールドの大きさ（ｓｉｚｅ）は、３２ｂｙｔｅである。
前記ＭＳＢ＿Ｉフィールド値が‘１’である場合、ＳＴＵＦＦ＿ＬＥＮ＿ＬＳＢ（５ｂｉｔｓ）フィールドとＳＴＵＦＦ＿ＬＥＮ＿ＭＳＢ（８ｂｉｔｓ）フィールドとがＳｔｕｆｆｉｎｇ Ｈｅａｄｅｒに使用され（または、含まれ）、表現できるＳＴＵＦＦ＿ＬＥＮは、１３ｂｉｔとなる。
次に、ＳＴＵＦＦ＿ＴＹＰＥフィールド（２ｂｉｔ、４７１２）は、Ｓｔｕｆｆｉｎｇフィールドの使用Ｔｙｐｅを知らせるフィールドを表す。
前記ＳＴＵＦＦ＿ＴＹＰＥフィールドの一例としては、ＩＳＳＹ、ｉｎ−ｂａｎｄ ｓｉｇｎａｌｉｎｇなどがありうる。
前記ＳＴＵＦＦ＿ＴＹＰＥフィールドは、Ｓｔｕｆｆｉｎｇフィールド区間がＳｔｕｆｆｉｎｇ以外に、他の用途（例：ｉｎｂａｎｄ用ｓｉｇｎａｌｉｎｇ、ｉｎｂａｎｄ用ＩＳＳＹ）で使用することができるように指定されたＳＴＵＦＦ ＴＹＰＥを知らせる。
下記の表３９を参照してＭＳＢ＿Ｉフィールド及び２ｂｉｔｓの大きさで新しく定義されたＳＴＵＦＦ＿ＴＹＰＥフィールドの意味についてさらに具体的に説明する。
Figure 2018504070
表３９において、前記ＳＴＵＦＦ＿ＴＹＰＥフィールド値が‘００’である場合、Ｓｔｕｆｆｉｎｇフィールドは、ｓｔｕｆｆｉｎｇ ｂｙｔｅのみで構成されている場合を表し、前記ＳＴＵＦＦ＿ＴＹＰＥフィールド値が０１、１０、１１である場合、Ｓｔｕｆｆｉｎｇフィールドで他の用途で使用されるそれぞれのモードを表現する。
図５１及び表３９において説明したように、Ｓｔｕｆｆｉｎｇ Ｈｅａｄｅｒ内にＭＳＢ＿ＩフィールドとＳＴＵＦＦ＿ＴＹＰＥフィールドとを共に使用する場合、Ｓｔｕｆｆｉｎｇフィールド内のＩＳＳＹとｓｔｕｆｆｉｎｇとを合わせた値の大きさが３２ｂｙｔｅｓ以下である場合、Ｓｔｕｆｆｉｎｇ Ｈｅａｄｅｒは、ＳＴＵＦＦ＿ＬＥＮ＿ＭＳＢフィールドを含まなくても良いので、１ｂｙｔｅのｏｖｅｒｈｅａｄを減らすことができるという長所がある。
仮に、Ｓｔｕｆｆｉｎｇフィールド内のＩＳＳＹとｓｔｕｆｆｉｎｇとを合わせた値の大きさが３２ｂｙｔｅｓより大きい場合には、ＭＳＩ＿Ｉフィールドを‘１’に設定し（または、マークし）、ＳＴＵＦＦ＿ＬＥＮ＿ＭＳＢフィールドをＳｔｕｆｆｉｎｇ Ｈｅａｄｅｒに使用することができる。
図５２は、本明細書で提案する放送信号の送信方法の一例を示す順序図である。
図５２に示すように、本明細書で提案する放送信号送信装置は、インプットストリーム（Ｉｎｐｕｔ Ｓｔｒｅａｍ）をインプットフォーマッティング（Ｉｎｐｕｔ Ｆｏｒｍａｔｔｉｎｇ）モジュールを介してプロセシング（Ｐｒｏｃｅｓｓｉｎｇ）する（Ｓ５２１０）。すなわち、前記放送信号送信装置は、インプットフォーマッティング（Ｉｎｐｕｔ Ｆｏｒｍａｔｔｉｎｇ）モジュールで前記インプットストリームを複数のＤＰ（Ｄａｔａ Ｐｉｐｅ）でフォーマッティングする。
具体的に、前記放送信号送信装置は、Ｓ５２１０のインプットフォーマッティング（Ｉｎｐｕｔ Ｆｏｒｍａｔｔｉｎｇ）のために、データパケットをベースバンドフレーム（Ｂａｓｅｂａｎｄ Ｆｒａｍｅ：ＢＢＦ）のペイロード（Ｐａｙｌｏａｄ）に割り当て、前記ベースバンドフレームのペイロードに対するフォーマットを表すヘッダを付加する。
ここで、前記複数のＤＰ（Ｄａｔａ Ｐｉｐｅ）は、複数のデータ送信チャネル（ｄａｔａ ｔｒａｎｓｍｉｓｓｉｏｎ ｃｈａｎｎｅｌｓ）で表現されることができる。
前記ヘッダは、図５０及び図５１において説明したように、ＥＸＴ＿Ｉフィールド及びＳｔｕｆｆｉｎｇフィールドを含むことができる。
前記ＥＸＴ＿Ｉフィールドは、ＢＢフレーム内のＳｔｕｆｆｉｎｇ ｆｉｅｌｄの存在可否を表すフィールドを意味し、２ｂｉｔｓの大きさを有することができる。
前記Ｓｔｕｆｆｉｎｇフィールドは、Ｓｔｕｆｆｉｎｇ Ｈｅａｄｅｒを含み、前記Ｓｔｕｆｆｉｎｇ Ｈｅａｄｅｒは、ＭＳＢ＿Ｉフィールド及びＳＴＵＦＦ＿ＴＹＰＥフィールドを含む。
前記ＭＳＢ＿Ｉフィールドは、ＳＴＵＦＦ＿ＬＥＮ＿ＭＳＢフィールドの存在有無を表すｉｎｄｉｃａｔｏｒをいい、１ｂｉｔの大きさを有することができる。
また、前記ＳＴＵＦＦ＿ＴＹＰＥフィールドは、Ｓｔｕｆｆｉｎｇフィールドの使用Ｔｙｐｅを知らせるフィールドを意味し、２ｂｉｔｓの大きさを有することができる。
前記ＥＸＴ＿Ｉフィールド、前記ＭＳＢ＿Ｉフィールド、及び前記ＳＴＵＦＦ＿ＴＹＰＥフィールドは、他の実施形態に適用されるために、制御情報の表現で使用されることもできる。
その後、前記放送送信装置は、（フォーマッティングされた）複数のＤＰのデータをＢＩＣＭ（Ｂｉｔ Ｉｎｔｅｒｌｅａｖｅｄ Ｃｏｄｉｎｇ ａｎｄ Ｍｏｄｕｌａｔｉｏｎ）モジュールを介して各ＤＰ別にエンコーディング（ｅｎｃｏｄｉｎｇ）する（Ｓ５２２０）。
前記ＢＩＣＭモジュールは、エンコーダ（ｅｎｃｏｄｅｒ）で表現されることもできる。
したがって、前記放送送信装置は、エンコーダ（ｅｎｃｏｄｅｒ）を介してサービスデータまたはサービスコンポーネントデータを送信するデータ送信チャネルの各々に該当するデータをエンコーディングする。
その後、前記放送送信装置は、前記エンコーディングされたＤＰのデータをフレームビルディング（Ｆｒａｍｅ Ｂｕｉｌｄｉｎｇ）モジュールを介してマッピングして、少なくとも１つの信号フレームを生成する（Ｓ５２３０）。
前記フレームビルディング（Ｆｒａｍｅ Ｂｕｉｌｄｉｎｇ）モジュールは、フレームビルダー（ｆｒａｍｅ ｂｕｉｌｄｅｒ）で表現されることもできる。
その後、前記放送送信装置は、ＯＦＤＭジェネレーション（Ｏｒｔｈｏｇｏｎａｌ Ｆｒｅｑｕｅｎｃｙ Ｄｉｖｉｓｉｏｎ Ｍｕｌｔｉｐｌｅｘｉｎｇ Ｇｅｎｅｒａｔｉｏｎ）モジュールを介してＯＦＤＭ方式により前記生成された信号フレームのデータを変調し、前記変調された信号フレームのデータを含む放送信号を送信機（ｔｒａｎｓｍｉｔｔｅｒ）を介して送信する（Ｓ５２４０）。
図５３は、本明細書で提案する放送信号の受信方法の一例を示す順序図である。
図５３に示すように、本明細書で提案する放送信号受信装置は、Ｓｙｎｃｈｒｏｎｉｚａｔｉｏｎ及びＤｅｍｏｄｕｌａｔｉｏｎモジュールを介して外部から放送信号を受信し、前記受信された放送信号に対してＯＦＤＭ方式によりデータを復調する（Ｓ５３１０）。
前記Ｓｙｎｃｈｒｏｎｉｚａｔｉｏｎ及びＤｅｍｏｄｕｌａｔｉｏｎモジュールは、受信機（ｒｅｃｅｉｖｅｒ）及び復調器（ｄｅｍｏｄｕｌａｔｏｒ）で表現されることもできる。
したがって、前記放送信号受信装置は、受信機（ｒｅｃｅｉｖｅｒ）を介して前記少なくとも１つの信号フレームを含む放送信号を受信し、前記復調器（ｄｅｍｏｄｕｌａｔｏｒ）を介して前記受信された放送信号をＯＦＤＭ（Ｏｒｔｈｏｇｏｎａｌ Ｆｒｅｑｕｅｎｃｙ Ｄｉｖｉｓｉｏｎ Ｍｕｌｔｉｐｌｅｘｉｎｇ）方式によりデータを復調する。
その後、前記放送信号受信装置は、前記復調されたデータをフレームパーシング（Ｆｒａｍｅ Ｐａｒｓｉｎｇ）モジュールを介して少なくとも１つの信号フレームでパーシングする（Ｐａｒｓｉｎｇ、Ｓ５３２０）。
前記フレームパーシングモジュールは、フレームパーサ（ｆｒａｍｅ ｐａｒｓｅｒ）で表現されることもできる。
したがって、前記放送信号受信装置は、前記フレームパーサ（ｆｒａｍｅ ｐａｒｓｅｒ）を介してサービスデータ（ｓｅｒｖｉｃｅ ｄａｔａ）またはサービスコンポーネントデータ（ｓｅｒｖｉｃｅ ｃｏｍｐｏｎｅｎｔ ｄａｔａ）を抽出するために、前記受信された放送信号に含まれた前記少なくとも１つの信号フレームをパーシング（Ｐａｒｓｉｎｇ）する。
その後、前記放送信号受信装置は、前記パーシングされた少なくとも１つの信号フレームをデマッピング及びデコーディング（ｄｅｍａｐｐｉｎｇ ａｎｄ ｄｅｃｏｄｉｎｇ）モジュールを介して複数のＤＰでデコーディングする（Ｓ５３３０）。
前記デマッピング及びデコーディング（ｄｅｍａｐｐｉｎｇ ａｎｄ ｄｅｃｏｄｉｎｇ）モジュールは、変換機（ｃｏｎｖｅｒｔｅｒ）及びデコーダ（ｄｅｃｏｄｅｒ）で表現されることもできる。
したがって、前記放送信号受信装置は、変換機（ｃｏｎｖｅｒｔｅｒ）を介して前記サービスデータ（ｓｅｒｖｉｃｅ ｄａｔａ）またはサービスコンポーネントデータ（ｓｅｒｖｉｃｅ ｃｏｍｐｏｎｅｎｔ ｄａｔａ）をビットに変換し、デコーダ（ｄｅｃｏｄｅｒ）を介して前記変換されたビットをデコーディング（ｄｅｃｏｄｉｎｇ）する。
その後、前記放送信号受信装置は、前記デマッピング及びデコーディングモジュールから出力される複数のＤＰ（Ｄａｔａ Ｐｉｐｅ）をアウトプットプロセッサ（ｏｕｔｐｕｔ ｐｒｏｃｅｓｓｏｒ）モジュールを介してインプットストリーム（Ｉｎｐｕｔ Ｓｔｒｅａｍ）などで復元する（Ｓ５３４０）。
または、前記放送信号受信装置は、前記アウトプットプロセッサ（ｏｕｔｐｕｔ ｐｒｏｃｅｓｓｏｒ）を介して前記デコーディングされたビットを含むデータストリームを出力する。
前記放送信号受信装置は、Ｓ５３４０のアウトプットプロセシングのために、ベースバンドフレームプロセッサ（Ｂａｓｅｂａｎｄ Ｆｒａｍｅ Ｐｒｏｃｅｓｓｏｒ）ブロックを介してベースバンドフレーム（Ｂａｓｅｂａｎｄ Ｆｒａｍｅ）のヘッダに送信された情報をディテクティング(検出）（ｄｅｔｅｃｔｉｎｇ）または取得（ｏｂｔａｉｎｉｎｇ）し、前記デコーディングされた情報を利用してインプットストリーム（Ｉｎｐｕｔ Ｓｔｒｅａｍ）を復元する。
前記ヘッダは、図５０〜図５２において説明したように、ＥＸＴ＿Ｉフィールド及びＳｔｕｆｆｉｎｇフィールドを含むことができる。
前記ＥＸＴ＿Ｉフィールドは、ＢＢフレーム内のＳｔｕｆｆｉｎｇ ｆｉｅｌｄの存在可否を表すフィールドを意味し、２ｂｉｔｓの大きさを有することができる。
前記Ｓｔｕｆｆｉｎｇフィールドは、Ｓｔｕｆｆｉｎｇ Ｈｅａｄｅｒを含み、前記Ｓｔｕｆｆｉｎｇ Ｈｅａｄｅｒは、ＭＳＢ＿Ｉフィールド及びＳＴＵＦＦ＿ＴＹＰＥフィールドを含む。
前記ＭＳＢ＿Ｉフィールドは、ＳＴＵＦＦ＿ＬＥＮ＿ＭＳＢフィールドの存在有無を表すｉｎｄｉｃａｔｏｒをいい、１ｂｉｔの大きさを有することができる。
また、前記ＳＴＵＦＦ＿ＴＹＰＥフィールドは、Ｓｔｕｆｆｉｎｇフィールドの使用Ｔｙｐｅを知らせるフィールドを意味し、２ｂｉｔｓの大きさを有することができる。
前記ＥＸＴ＿Ｉフィールド、前記ＭＳＢ＿Ｉフィールド、及び前記ＳＴＵＦＦ＿ＴＹＰＥフィールドは、他の実施形態に適用されるために、制御情報の表現で使用されることができる。
本発明の思想や範囲を逸脱することなく、本発明において多様な変更及び変形が可能であることは当業者に理解される。したがって、本発明は、添付された請求項及びその同等範囲内で提供される本発明の変更及び変形を含むことと意図される。
本明細書において装置及び方法発明が全て言及され、装置及び方法発明の全ての説明は互いに補完して適用されることができる。
本明細書は、放送信号を受信及び送信するための方法及び装置を利用することにある。

Claims (12)

  1. 放送信号を受信するための方法において、前記方法は、
    少なくとも１つの信号フレームを含む放送信号を受信するステップと、
    前記受信された放送信号をＯＦＤＭ（Ｏｒｔｈｏｇｏｎａｌ Ｆｒｅｑｕｅｎｃｙ Ｄｉｖｉｓｉｏｎ Ｍｕｌｔｉｐｌｅｘｉｎｇ）方式によってデータ復調を行うステップと、
    サービスデータ（ｓｅｒｖｉｃｅ ｄａｔａ）またはサービスコンポーネントデータ（ｓｅｒｖｉｃｅ ｃｏｍｐｏｎｅｎｔ ｄａｔａ）を抽出するために、前記受信した放送信号に含まれた前記少なくとも１つの信号フレームをパーシング（Ｐａｒｓｉｎｇ）するステップと、
    前記サービスデータ（ｓｅｒｖｉｃｅ ｄａｔａ）またはサービスコンポーネントデータ（ｓｅｒｖｉｃｅ ｃｏｍｐｏｎｅｎｔ ｄａｔａ）をビットに変換するステップと、
    前記変換されたビットをデコーディング（ｄｅｃｏｄｉｎｇ）するステップと、
    前記デコーディングされたビットを含むデータストリームを出力するステップと、
    を含み、
    前記出力するステップは、
    ベースバンドフレーム（Ｂａｓｅｂａｎｄ Ｆｒａｍｅ）のヘッダに含まれた情報をディテクティング（ｄｅｔｅｃｔｉｎｇ）するステップを含み、
    前記ＢＢＦは、スタッフィング（Ｓｔｕｆｆｉｎｇ）フィールドが前記ヘッダに存在するか否かを表す制御情報を含む、方法。
  2. 前記制御情報は、前記ヘッダに含まれる、請求項１に記載の方法。
  3. 前記ヘッダは、スタッフィング長さのＭＳＢ（Ｍｏｓｔ Ｓｉｇｎｉｆｉｃａｎｔ Ｂｉｔ）ｐａｒｔが前記スタッフィング（Ｓｔｕｆｆｉｎｇ）フィールドに存在するか否かを表す指示情報またはスタッフィングデータのタイプを表すスタッフィングタイプ（ＳＴＵＦＦ＿ＴＹＰＥ）フィールドのうち、少なくとも１つを含む、請求項２に記載の方法。
  4. 前記スタッフィングフィールドは、スタッフィングヘッダ（Ｓｔｕｆｆｉｎｇ Ｈｅａｄｅｒ）及びスタッフィングデータ（Ｓｔｕｆｆｉｎｇ Ｄａｔａ）を含み、
    前記指示情報及び前記スタッフィングタイプフィールドは、前記スタッフィングヘッダに含まれる、請求項３に記載の方法。
  5. 前記指示情報の大きさは、１ビットであり、
    前記スタッフィングタイプ（ＳＴＵＦＦ＿ＴＹＰＥ）フィールドは、２ビットである、請求項３に記載の方法。
  6. 前記スタッフィングヘッダは、前記スタッフィングフィールドの長さを表すスタッフィング長さ（ＳＴＵＦＦ＿ＬＥＮ）フィールドをさらに含み、
    前記スタッフィング長さ（ＳＴＵＦＦ＿ＬＥＮ）フィールドは、スタッフィング長さのＭＳＢ（ＳＴＵＦＦ＿ＬＥＮ＿ＭＳＢ）ｐａｒｔ及びスタッフィング長さのＬＳＢ（ＳＴＵＦＦ＿ＬＥＮ＿ＬＳＢ）ｐａｒｔに区分される、請求項４に記載の方法。
  7. 前記制御情報は、ＥＸＴ＿Ｉ（Ｅｘｔｅｎｓｉｏｎ Ｉｎｄｉｃａｔｏｒ）フィールドであり、
    前記指示情報は、ＭＳＢ＿Ｉ（Ｉｎｄｉｃａｔｏｒ）フィールドである、請求項３に記載の方法。
  8. 前記スタッフィングフィールドは、前記ペイロードにデータパケットが満たされないか、またはｉｎ−ｂａｎｄ ｓｉｇｎａｌｉｎｇが使用される場合、前記ベースバンドフレームに含まれる、請求項２に記載の方法。
  9. 前記スタッフィングデータは、スタッフィングまたはｉｎ−ｂａｎｄ ｓｉｇｎａｌｉｎｇのうち、少なくとも１つを表す、請求項３に記載の方法。
  10. 前記スタッフィングフィールドの長さが３２バイト以下である場合、前記スタッフィング長さのＭＳＢ（Ｌｅａｓｔ Ｓｉｇｎｉｆｉｃａｎｔ Ｂｉｔ）ｐａｒｔは、前記スタッフィングフィールドに含まれない、請求項２に記載の方法。
  11. 放送信号を受信するための受信装置において、
    少なくとも１つの信号フレームを含む放送信号を受信するための受信機（ｒｅｃｅｉｖｅｒ）と、
    前記受信された放送信号をＯＦＤＭ（Ｏｒｔｈｏｇｏｎａｌ Ｆｒｅｑｕｅｎｃｙ Ｄｉｖｉｓｉｏｎ Ｍｕｌｔｉｐｌｅｘｉｎｇ）方式によってデータを復調するための復調器（ｄｅｍｏｄｕｌａｔｏｒ）と、
    サービスデータ（ｓｅｒｖｉｃｅ ｄａｔａ）またはサービスコンポーネントデータ（ｓｅｒｖｉｃｅ ｃｏｍｐｏｎｅｎｔ ｄａｔａ）を抽出するために、前記受信された放送信号に含まれた前記少なくとも１つの信号フレームをパーシング（Ｐａｒｓｉｎｇ）するためのフレームパーサ（ｆｒａｍｅ ｐａｒｓｅｒ）と、
    前記サービスデータ（ｓｅｒｖｉｃｅ ｄａｔａ）またはサービスコンポーネントデータ（ｓｅｒｖｉｃｅ ｃｏｍｐｏｎｅｎｔ ｄａｔａ）をビットに変換するための変換器（ｃｏｎｖｅｒｔｅｒ）と、
    前記変換されたビットをデコーディング（ｄｅｃｏｄｉｎｇ）するためのデコーダ（ｄｅｃｏｄｅｒ）と、
    前記デコーディングされたビットを含むデータストリームを出力するためのアウトプットプロセッサ（ｏｕｔｐｕｔ ｐｒｏｃｅｓｓｏｒ）と、
    を備え、
    前記アウトプットプロセッサは、
    ベースバンドフレーム（Ｂａｓｅｂａｎｄ Ｆｒａｍｅ）のヘッダに含まれた情報をディテクティング（ｄｅｔｅｃｔｉｎｇ）するためのベースバンドフレームプロセッサ（ｂａｓｅｂａｎｄ ｆｒａｍｅ ｐｒｏｃｅｓｓｏｒ）を含み、
    前記ＢＢＦは、スタッフィング（Ｓｔｕｆｆｉｎｇ）フィールドが前記ヘッダに存在するか否かを表す制御情報を含む、受信装置。
  12. 前記ヘッダは、前記スタッフィング（ｓｔｕｆｆｉｎｇ）フィールドにスタッフィング長さのＭＳＢ（Ｍｏｓｔ Ｓｉｇｎｉｆｉｃａｎｔ Ｂｉｔ）ｐａｒｔが存在するか否かを表す指示情報またはスタッフィングデータのタイプを表すスタッフィングタイプ（ＳＴＵＦＦ＿ＴＹＰＥ）フィールドのうち、少なくとも１つを含む、請求項１１に記載の受信装置。
JP2017543676A 2014-11-06 2015-03-05 放送信号送信装置、放送信号受信装置、放送信号送信方法、及び放送信号受信方法 Expired - Fee Related JP6392463B2 (ja)

Applications Claiming Priority (5)

Application Number Priority Date Filing Date Title
US201462075898P 2014-11-06 2014-11-06
US62/075,898 2014-11-06
US201462080382P 2014-11-16 2014-11-16
US62/080,382 2014-11-16
PCT/KR2015/002127 WO2016072566A1 (ko) 2014-11-06 2015-03-05 방송 신호 송신 장치, 방송 신호 수신 장치, 방송 신호 송신 방법, 및 방송 신호 수신 방법

Publications (2)

Publication Number Publication Date
JP2018504070A true JP2018504070A (ja) 2018-02-08
JP6392463B2 JP6392463B2 (ja) 2018-09-19

Family

ID=55909283

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2017543676A Expired - Fee Related JP6392463B2 (ja) 2014-11-06 2015-03-05 放送信号送信装置、放送信号受信装置、放送信号送信方法、及び放送信号受信方法

Country Status (7)

Country Link
US (3) US9729372B2 (ja)
EP (2) EP3236606A4 (ja)
JP (1) JP6392463B2 (ja)
KR (3) KR101771091B1 (ja)
CN (4) CN107409003B (ja)
CA (3) CA2966980C (ja)
WO (2) WO2016072566A1 (ja)

Families Citing this family (12)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP3236606A4 (en) * 2014-11-06 2018-09-26 LG Electronics Inc. Method and apparatus for receiving broadcast signal, and method and apparatus for transmitting broadcast signal
JP6502764B2 (ja) * 2015-02-10 2019-04-17 日本放送協会 送信装置、受信装置、及び半導体チップ
US9918326B2 (en) * 2015-05-27 2018-03-13 Comcast Cable Communications, Llc Optimizing resources in data transmission
WO2016203719A1 (ja) * 2015-06-17 2016-12-22 パナソニック インテレクチュアル プロパティ コーポレーション オブ アメリカ 送信方法、受信方法、送信装置、及び受信装置
KR20230019987A (ko) * 2016-12-16 2023-02-09 소니그룹주식회사 송신 장치, 송신 방법, 수신 장치, 및 수신 방법
JP7069542B2 (ja) * 2016-12-16 2022-05-18 ソニーグループ株式会社 送信装置、及び、送信方法
US10541845B2 (en) * 2017-09-25 2020-01-21 Kenneth Stuart Pseudo random multi-carrier method and system
KR101967299B1 (ko) * 2017-12-19 2019-04-09 엘지전자 주식회사 방송 신호를 수신하는 차량용 수신 장치 및 방송 신호를 수신하는 차량용 수신 방법
CN110312275B (zh) * 2018-03-20 2022-08-02 中兴通讯股份有限公司 Cbr业务在以太网帧上实现业务监控的方法
CN111435888B (zh) * 2019-01-11 2022-02-08 大唐移动通信设备有限公司 一种参考信号的发送、接收方法和通信设备
US11570004B2 (en) * 2019-06-13 2023-01-31 Fidelity Information Services, Llc Dynamic self-defined API via digital signatures
CN111865860B (zh) * 2020-06-29 2023-04-11 湖南省时空基准科技有限公司 一种基于ofdm技术的无线广播授时系统

Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2011082834A1 (en) * 2010-01-11 2011-07-14 Nokia Corporation Error correction
US20110286535A1 (en) * 2009-02-13 2011-11-24 Woo Suk Ko Apparatus for transmitting and receiving a signal and method of transmitting and receiving a signal
JP2013520036A (ja) * 2010-02-26 2013-05-30 パナソニック株式会社 デジタル放送システムにおける物理レイヤシグナリング
JP2013520850A (ja) * 2010-02-26 2013-06-06 パナソニック株式会社 送信方法、受信方法、送信装置、受信装置
WO2014112806A1 (en) * 2013-01-17 2014-07-24 Lg Electronics Inc. Apparatus for transmitting broadcast signals, apparatus for receiving broadcast signals, method for transmitting broadcast signals and method for receiving broadcast signals
JP2017501650A (ja) * 2013-11-13 2017-01-12 エルジー エレクトロニクス インコーポレイティド 放送信号送信装置、放送信号受信装置、放送信号送信方法、及び放送信号受信方法

Family Cites Families (41)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP1021048A3 (en) * 1999-01-14 2002-10-02 Kabushiki Kaisha Toshiba Digital video recording system and its recording medium
US7570656B2 (en) * 2001-06-18 2009-08-04 Yitran Communications Ltd. Channel access method for powerline carrier based media access control protocol
US7486680B1 (en) 2002-03-21 2009-02-03 Ji Zhang Packet schedule timestamp for a compressed bitstream
US7383483B2 (en) * 2003-12-11 2008-06-03 International Business Machines Corporation Data transfer error checking
JP2008527928A (ja) * 2005-01-11 2008-07-24 クゥアルコム・インコーポレイテッド 階層化されたデータと階層化されていないデータとを階層化された変調によって送信する方法および装置
CN101147374B (zh) * 2005-01-11 2012-10-17 高通股份有限公司 用于经由分层调制发送分层及非分层数据的方法和装置
KR100854090B1 (ko) * 2005-11-25 2008-08-25 삼성전자주식회사 수신 성능이 향상된 디지털 방송 송수신기 및 그의신호처리방법
KR101227506B1 (ko) * 2006-06-16 2013-01-30 엘지전자 주식회사 디지털 방송 시스템 및 처리 방법
KR101227507B1 (ko) * 2006-06-20 2013-01-30 엘지전자 주식회사 디지털 방송 신호 송신 시스템 및 송신 방법
KR101486372B1 (ko) * 2007-07-25 2015-01-26 엘지전자 주식회사 디지털 방송 시스템 및 데이터 처리 방법
KR101572875B1 (ko) * 2007-09-21 2015-11-30 엘지전자 주식회사 디지털 방송 시스템 및 데이터 처리 방법
DK2056549T3 (da) 2007-10-30 2013-02-04 Sony Corp Databehandlingsanordning og -fremgangsmåde
WO2009075538A2 (en) * 2007-12-12 2009-06-18 Lg Electronics Inc. Apparatus for transmitting and receiving a signal and method of transmitting and receiving a signal
JP5298622B2 (ja) * 2007-12-21 2013-09-25 ソニー株式会社 送信装置および方法、受信装置および方法
KR100937430B1 (ko) 2008-01-25 2010-01-18 엘지전자 주식회사 신호 송수신 방법 및 신호 송수신 장치
KR101509257B1 (ko) * 2008-03-18 2015-04-08 한국전자통신연구원 광대역 고주파수 무선 시스템에서 다양한 형태의 비압축 동영상 신호 전송을 위한 차별적 오류 보호 방법 및 그 장치
KR101556168B1 (ko) * 2009-01-29 2015-09-30 엘지전자 주식회사 신호 송수신 장치 및 방법
KR101643616B1 (ko) * 2009-11-06 2016-07-29 삼성전자주식회사 모바일 서비스 수신 방법 및 모바일 서비스 수신기
WO2011105781A2 (ko) * 2010-02-23 2011-09-01 엘지전자 주식회사 방송 신호 송신 장치, 방송 신호 수신 장치, 및 방송 신호 송/수신 장치에서 방송 신호 송수신 방법
WO2011105784A2 (ko) * 2010-02-23 2011-09-01 엘지전자 주식회사 방송 신호 송신 장치, 방송 신호 수신 장치, 및 방송 신호 송/수신 장치에서 방송 신호 송수신 방법
WO2011105804A2 (ko) * 2010-02-23 2011-09-01 엘지전자 주식회사 방송 신호 송신 장치, 방송 신호 수신 장치, 및 방송 신호 송/수신 장치에서 방송 신호 송수신 방법
EP2362653A1 (en) * 2010-02-26 2011-08-31 Panasonic Corporation Transport stream packet header compression
JP5542580B2 (ja) * 2010-08-25 2014-07-09 日本放送協会 送信装置及び受信装置
CN202014249U (zh) * 2011-03-29 2011-10-19 合肥菲特通信技术有限公司 一种基于rs帧结构的信道复接装置
EP2552043A1 (en) * 2011-07-25 2013-01-30 Panasonic Corporation Spatial multiplexing for bit-interleaved coding and modulation with quasi-cyclic LDPC codes
EP2568650B1 (en) 2011-09-07 2020-05-06 LG Electronics Inc. -1- Method and apparatus for transceiving broadcast signals
CN102497346B (zh) * 2011-12-13 2014-10-29 安徽华东光电技术研究所 基于cofdm的高清视频无线传输系统的基带发射机
KR101893833B1 (ko) * 2012-02-01 2018-09-03 삼성전자주식회사 방송 시스템에서 패킷 송수신 방법 및 장치
GB201208389D0 (en) * 2012-05-10 2012-06-27 Samsung Electronics Co Ltd Integrated circuit, communication unit, wireless communication system and methods therefor
KR101759957B1 (ko) * 2013-01-17 2017-07-20 엘지전자 주식회사 방송 신호 송신 장치, 방송 신호 수신 장치, 방송 신호 송신 방법 및 방송 신호 수신 방법
EP2957083B1 (en) * 2013-04-21 2018-10-10 LG Electronics Inc. Method and apparatus for transmitting and for receiving broadcast signals
WO2014185729A1 (en) 2013-05-15 2014-11-20 Lg Electronics Inc. Apparatus for transmitting broadcast signals, apparatus for receiving broadcast signals, method for transmitting broadcast signals and method for receiving broadcast signals
JP6561226B2 (ja) * 2013-06-05 2019-08-21 サターン ライセンシング エルエルシーＳａｔｕｒｎ Ｌｉｃｅｎｓｉｎｇ ＬＬＣ ペイロードデータおよび緊急情報を送信するための送信装置および送信方法
KR102025878B1 (ko) * 2013-06-28 2019-09-26 삼성전자주식회사 송신 장치, 수신 장치 및 그 제어방법
KR102130151B1 (ko) * 2013-07-22 2020-07-03 삼성전자주식회사 송신 장치, 수신 장치 및 그 신호 처리 방법
CN105556953B (zh) 2013-07-29 2019-04-19 Lg电子株式会社 发送广播信号的装置、接收广播信号的装置、发送广播信号的方法和接收广播信号的方法
EP3033879B1 (en) * 2013-08-14 2019-05-15 LG Electronics Inc. Apparatus for transmitting broadcast signals, apparatus for receiving broadcast signals, method for transmitting broadcast signals and method for receiving broadcast signals
KR20160052313A (ko) * 2014-11-04 2016-05-12 삼성전자주식회사 송신 장치, 수신 장치 및 그 신호 처리 방법
US9948753B2 (en) * 2014-11-04 2018-04-17 Samsung Electronics Co., Ltd. Transmitting apparatus and signal processing method thereof
EP3236606A4 (en) * 2014-11-06 2018-09-26 LG Electronics Inc. Method and apparatus for receiving broadcast signal, and method and apparatus for transmitting broadcast signal
EP3219080B1 (en) * 2014-11-11 2023-02-15 Samsung Electronics Co., Ltd. Transmitting apparatus, receiving apparatus and controlling method thereof

Patent Citations (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20110286535A1 (en) * 2009-02-13 2011-11-24 Woo Suk Ko Apparatus for transmitting and receiving a signal and method of transmitting and receiving a signal
WO2011082834A1 (en) * 2010-01-11 2011-07-14 Nokia Corporation Error correction
JP2013520036A (ja) * 2010-02-26 2013-05-30 パナソニック株式会社 デジタル放送システムにおける物理レイヤシグナリング
JP2013520850A (ja) * 2010-02-26 2013-06-06 パナソニック株式会社 送信方法、受信方法、送信装置、受信装置
WO2014112806A1 (en) * 2013-01-17 2014-07-24 Lg Electronics Inc. Apparatus for transmitting broadcast signals, apparatus for receiving broadcast signals, method for transmitting broadcast signals and method for receiving broadcast signals
JP2016509769A (ja) * 2013-01-17 2016-03-31 エルジー エレクトロニクス インコーポレイティド 放送信号送信装置、放送信号受信装置、放送信号送信方法及び放送信号受信方法
JP2017501650A (ja) * 2013-11-13 2017-01-12 エルジー エレクトロニクス インコーポレイティド 放送信号送信装置、放送信号受信装置、放送信号送信方法、及び放送信号受信方法

Non-Patent Citations (2)

* Cited by examiner, † Cited by third party
Title
ATSC MOBILE DTV STANDARD: A/153 PART 3, SERVICE MULTIPLEX AND TRANSPORT SUBSYSTEM CHARACTERISTICS, vol. Doc.A/153 Part 3:2013, JPN6018027757, 29 October 2013 (2013-10-29), pages Pages 1-4,21-24 *
FINAL DRAFT ETSI EN 302 755 V1.3.1 (2011-11), JPN6018027755, November 2011 (2011-11-01), pages Pages 1-6,17-34,189 *

Also Published As

Publication number Publication date
EP3236606A1 (en) 2017-10-25
US9729372B2 (en) 2017-08-08
WO2016072566A1 (ko) 2016-05-12
EP3217581A1 (en) 2017-09-13
KR20170098332A (ko) 2017-08-29
US9876664B2 (en) 2018-01-23
EP3236606A4 (en) 2018-09-26
WO2016072567A9 (ko) 2017-06-15
KR102031097B1 (ko) 2019-11-08
KR20170060038A (ko) 2017-05-31
KR101807673B1 (ko) 2017-12-11
CA2966980A1 (en) 2016-05-12
CA3079690A1 (en) 2016-05-12
EP3217581A4 (en) 2018-12-19
KR101771091B1 (ko) 2017-08-24
CN105940626A (zh) 2016-09-14
CN111934817A (zh) 2020-11-13
US20160134453A1 (en) 2016-05-12
CN107409003B (zh) 2020-08-11
KR20160075538A (ko) 2016-06-29
CA2966980C (en) 2020-06-30
WO2016072567A1 (ko) 2016-05-12
JP6392463B2 (ja) 2018-09-19
CA3079698C (en) 2022-01-25
CA3079690C (en) 2021-12-07
USRE49255E1 (en) 2022-10-18
CN111934818A (zh) 2020-11-13
US20160134454A1 (en) 2016-05-12
CA3079698A1 (en) 2016-05-12
CN107409003A (zh) 2017-11-28

Similar Documents

Publication Publication Date Title
JP6405051B2 (ja) 放送信号送信装置、放送信号受信装置、放送信号送信方法、及び放送信号受信方法
JP6180651B2 (ja) 放送信号送信装置、放送信号受信装置、放送信号送信方法、及び放送信号受信方法
JP6392463B2 (ja) 放送信号送信装置、放送信号受信装置、放送信号送信方法、及び放送信号受信方法
JP6437639B2 (ja) 放送信号送受信装置及び方法
JP6266802B2 (ja) 放送信号送信装置、放送信号受信装置、放送信号送信方法、及び放送信号受信方法
JP6352524B2 (ja) 放送信号送受信装置及び方法
KR102550656B1 (ko) 방송 신호 송수신 장치 및 방법
KR101780038B1 (ko) 방송 신호 송수신 장치 및 방법
JP6480469B2 (ja) 放送信号送受信装置及び方法

Legal Events

Date Code Title Description
A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20180403

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20180608

TRDD Decision of grant or rejection written
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20180724

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20180822

R150 Certificate of patent or registration of utility model

Ref document number: 6392463

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R150

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

LAPS Cancellation because of no payment of annual fees