JP6449897B2

JP6449897B2 - 放送信号生成処理方法及び放送信号受信機

Info

Publication number: JP6449897B2
Application number: JP2016552269A
Authority: JP
Inventors: キョンソムン; ミンソンカク; チャンウォンリ; ウソクコ; ソンリョンホン
Original assignee: LG Electronics Inc
Current assignee: LG Electronics Inc
Priority date: 2014-11-13
Filing date: 2015-11-13
Publication date: 2019-01-09
Anticipated expiration: 2035-11-13
Also published as: US10356449B2; KR101789640B1; CN106233693A; KR20160091929A; EP3220649A1; US20170171575A1; US10687096B2; EP3220649A4; US20200314459A1; US10972771B2; CN106233693B; US20190289338A1; JP2017511040A; WO2016076654A1

Description

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

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

すなわち、デジタル放送システムは、ＨＤ（ＨｉｇｈＤｅｆｉｎｉｔｉｏｎ）イメージ、マルチチャネル（ｍｕｌｔｉｃｈａｎｎｅｌ、多チャネル）オーディオ、及び様々な付加サービスを提供することができる。しかしながら、デジタル放送のためには、多量のデータ伝送に対するデータ伝送効率、送受信ネットワークの堅固性（ｒｏｂｕｓｔｎｅｓｓ）、及びモバイル受信装置を考慮したネットワーク柔軟性（ｆｌｅｘｉｂｉｌｉｔｙ）を向上させなければならない。

上述した技術的課題を解決するための本発明の一実施例に係る放送信号生成処理方法は、一つ以上の放送サービスのための放送データをエンコードするステップと、前記一つ以上の放送サービスに対する属性を説明する情報を含む第１レベルシグナリング情報をエンコードするステップと、前記一つ以上の放送サービスをスキャンするための情報を含む第２レベルシグナリング情報をエンコードするステップと、前記放送データ、第１レベルシグナリング情報及び第２レベルシグナリング情報を含む放送信号を生成するステップとを含み、前記第２レベルシグナリング情報は、前記放送信号で既に定められた位置を通じて伝送され、前記第２レベルシグナリング情報は、前記第１シグナリング情報を伝送する各パケットのＩＰ住所を識別するＩＰ住所情報、及び前記第１シグナリング情報を含むＰＬＰ（ＰｈｙｓｉｃａｌＬａｙｅｒＰｉｐｅ）を識別するＰＬＰＩＤ情報を含む。

好ましくは、前記第１シグナリング情報は、放送サービスに対するサービス層属性を記述するＵＳＤ（ＵｓｅｒＳｅｒｖｉｃｅＤｅｓｃｒｉｐｔｉｏｎ）情報、前記放送サービスに含まれるコンポーネントを取得するための情報を提供する伝送セッション記述情報、及び前記放送サービスをストリーム（ｓｔｒｅａｍｉｎｇ）するために必要な情報を提供するＭＰＤ（ＭｅｄｉａＰｒｅｓｅｎｔａｔｉｏｎＤｅｓｃｒｉｐｔｉｏｎ）情報を含むことを特徴とする。

好ましくは、前記ＵＳＤ情報は、前記ＭＰＤ情報が提供される位置を識別するＵＲＩ（ＵｎｉｆｏｒｍＲｅｓｏｕｒｃｅＩｄｅｎｔｉｆｉｅｒ）を示すＭＰＤＵＲＩ情報を含むことを特徴とする。

好ましくは、前記ＵＳＤ情報は、前記伝送セッション記述情報が提供される位置を識別するＵＲＩを示すＵＲＩ情報をさらに含むことを特徴とする。

好ましくは、前記伝送セッション記述情報は、前記コンポーネントを伝送するＬＣＴ（ＬａｙｅｒｅｄＣｏｄｉｎｇＴｒａｎｓｐｏｒｔ）セッションを識別するＴＳＩ（ＴｒａｎｓｍｉｓｓｉｏｎＳｅｓｓｉｏｎＩｄｅｎｔｉｆｉｅｒ）情報を含むことを特徴とする。

好ましくは、前記ＵＳＤ情報は、前記放送サービスを識別するサービス識別情報、及び前記放送サービスに含まれる放送コンテンツの表出のために要求される受信機の能力（ｃａｐａｂｉｌｉｔｙ）を識別する能力情報をさらに含むことを特徴とする。

好ましくは、前記ＵＳＤ情報は、前記放送コンテンツが伝送される方法に関する情報を含むｄｅｌｉｖｅｒｙＭｅｔｈｏｄエレメントをさらに含むことを特徴とする。

上述した技術的課題を解決するための本発明の一実施例に係る放送信号受信機は、一つ以上の放送サービスのための放送データ、前記一つ以上の放送サービスに対する属性を説明する情報を含む第１レベルシグナリング情報、及び前記一つ以上の放送サービスをスキャンするための情報を含む第２レベルシグナリング情報を含む放送信号を受信する放送信号受信部であって、前記第２レベルシグナリング情報は、前記放送信号で既に定められた位置を通じて伝送され、前記第２レベルシグナリング情報は、前記第１シグナリング情報を伝送する各パケットのＩＰ住所を識別するＩＰ住所情報、及び前記第１シグナリング情報を含むＰＬＰ（ＰｈｙｓｉｃａｌＬａｙｅｒＰｉｐｅ）を識別するＰＬＰＩＤ情報を含む、放送信号受信部と、前記放送信号内の既に定められた位置で前記第２レベルシグナリング情報を抽出し、前記第２レベルシグナリング情報に含まれるＩＰ住所情報及びＰＬＰＩＤ情報を用いて前記第１レベルシグナリング情報を抽出し、前記第１レベルシグナリング情報を用いて前記放送サービスを取得し、前記放送サービスを表出するように制御するプロセッサとを含む。

好ましくは、前記第１シグナリング情報は、放送サービスに対するサービス層属性を記述するＵＳＤ（ＵｓｅｒＳｅｒｖｉｃｅＤｅｓｃｒｉｐｔｉｏｎ）情報、前記放送サービスに含まれるコンポーネントを取得するための情報を提供する伝送セッション記述情報、及び前記放送サービスをストリームするために必要な情報を提供するＭＰＤ（ＭｅｄｉａＰｒｅｓｅｎｔａｔｉｏｎＤｅｓｃｒｉｐｔｉｏｎ）情報を含むことを特徴とする。

好ましくは、前記ＵＳＤ情報は、前記放送サービスを識別するサービス識別情報、及び前記放送サービスに含まれる放送コンテンツの表出のために要求される受信機の能力を識別する能力情報をさらに含むことを特徴とする。

好ましくは、前記プロセッサは、前記第１レベルシグナリング情報内の前記ＵＳＤ情報をパースし、前記パースされたＵＳＤ情報内の前記ＵＲＩ情報が示す位置で前記伝送セッション記述情報をパースし、前記パースされた伝送セッション記述情報内の前記ＴＳＩ情報を用いて前記コンポーネントを取得し、前記パースされたＵＳＤ情報内の前記ＭＰＤＵＲＩ情報を用いて前記ＭＰＤ情報をパースし、前記パースされたＭＰＤ内の情報を用いて前記コンポーネントを表出し、前記放送サービスを処理することを特徴とする。

本発明は、サービス特性に応じてデータを処理し、各サービス又はサービスコンポーネントに対するＱｏＳ（ＱｕａｌｉｔｙｏｆＳｅｒｖｉｃｅ）を制御することによって様々な放送サービスを提供することができる。

本発明は、同じＲＦ（ｒａｄｉｏｆｒｅｑｕｅｎｃｙ）信号帯域幅で様々な放送サービスを伝送することによって伝送柔軟性（ｆｌｅｘｉｂｉｌｉｔｙ）を達成することができる。

本発明によれば、モバイル受信装置を使用したり、室内環境にいても、誤り無しでデジタル放送信号を受信することができる放送信号送信及び受信方法並びに装置を提供することができる。

本発明は、地上波放送網とインターネット網とを使用する次世代ハイブリッド放送を支援する環境で次世代放送サービスを効果的に支援することができる。

本発明のさらなる理解のために含まれ、本出願に含まれ、その一部を構成する添付の図面は、本発明の原理を説明する詳細な説明と共に本発明の実施例を示す。
本発明の一実施例に係る受信機プロトコルスタック（ｒｅｃｅｉｖｅｒｐｒｏｔｏｃｏｌｓｔａｃｋ）を示した図である。本発明の一実施例に係るＳＬＴとＳＬＳ（ｓｅｒｖｉｃｅｌａｙｅｒｓｉｇｎａｌｉｎｇ）の関係を示した図である。本発明の一実施例に係るＳＬＴを示した図である。本発明の一実施例に係るＳＬＳブートストラッピング及びサービスディスカバリ過程を示した図である。本発明の一実施例に係るＲＯＵＴＥ／ＤＡＳＨのためのＵＳＢＤフラグメントを示した図である。本発明の一実施例に係るＲＯＵＴＥ／ＤＡＳＨのためのＳ−ＴＳＩＤフラグメントを示した図である。本発明の一実施例に係るＭＭＴのためのＵＳＢＤ／ＵＳＤフラグメントを示した図である。本発明の一実施例に係るリンク層プロトコルアーキテクチャを示した図である。本発明の一実施例に係るリンク層パケットのベースヘッダーの構造を示した図である。本発明の一実施例に係るリンク層パケットの追加ヘッダーの構造を示した図である。本発明の他の実施例に係るリンク層パケットの追加ヘッダーの構造を示した図である。本発明の一実施例に係る、ＭＰＥＧ−２ＴＳパケットのためのリンク層パケットのヘッダー構造、及びそのカプセル化過程を示した図である。本発明の一実施例に係るＩＰヘッダー圧縮において、適応モードの実施例を示した図である（送信側）。本発明の一実施例に係るＬＭＴ（ＬｉｎｋＭａｐｐｉｎｇＴａｂｌｅ）及びＲＯＨＣ−Ｕ記述テーブルを示した図である。本発明の一実施例に係る送信機側のリンク層の構造を示した図である。本発明の一実施例に係る受信機側のリンク層の構造を示した図である。本発明の一実施例に係る、リンク層を介したシグナリング伝送構造を示した図である（送／受信側）。本発明の一実施例に係る、次世代放送サービスに対する放送信号送信装置の構造を示す図である。本発明の一実施例に係るＢＩＣＭ（ｂｉｔｉｎｔｅｒｌｅａｖｅｄｃｏｄｉｎｇ＆ｍｏｄｕｌａｔｉｏｎ）ブロックを示す図である。本発明の他の一実施例に係るＢＩＣＭブロックを示す図である。本発明の一実施例に係るＰＬＳのビットインターリービング過程を示す図である。本発明の一実施例に係る次世代放送サービスに対する放送信号受信装置の構造を示す図である。本発明の一実施例に係るフレームのシグナリング層の構造を示す図である。本発明の一実施例に係るＰＬＳ１データを示す図である。本発明の一実施例に係るＰＬＳ２データを示す図である。本発明の他の一実施例に係るＰＬＳ２データを示す図である。本発明の一実施例に係るフレームの論理構造を示す図である。本発明の一実施例に係るＰＬＳ（ｐｈｙｓｉｃａｌｌａｙｅｒｓｉｇｎａｌｌｉｎｇ）マッピングを示す図である。本発明の一実施例に係る時間インターリービングを示す図である。本発明の一実施例に係る、ツイストされた行−列ブロックインターリーバの基本動作を示す図である。本発明の他の一実施例に係る、ツイストされた行−列ブロックインターリーバの動作を示す図である。本発明の一実施例に係る、各ＦＦＴモードによるメイン−ＰＲＢＳ生成器とサブ−ＰＲＢＳ生成器で構成されたインターリービング住所生成器のブロックダイアグラムを示す図である。本発明の一実施例に係る、全てのＦＦＴモードに用いられるメイン−ＰＲＢＳを示す図である。本発明の一実施例に係る、周波数インターリービングのためのインターリービング住所及びＦＦＴモードに用いられるサブ−ＰＲＢＳを示す図である。本発明の一実施例に係る、時間インターリーバの書き込み（ｗｒｉｔｉｎｇ）動作を示す図である。ＰＬＰの個数によって適用するインターリービングタイプを表で示す図である。上述したハイブリッド時間インターリーバ構造の第１実施例を含むブロック図である。上述したハイブリッド時間インターリーバ構造の第２実施例を含むブロック図である。ハイブリッド時間デインターリーバの構造の第１実施例を含むブロック図である。ハイブリッド時間デインターリーバの構造の第２実施例を含むブロック図である。本発明の一実施例に係る次世代放送システムにおいて、放送サービスに接近するためのシグナリング体系を示した図である。本発明の一実施例に係る第１シグナリング方法と第２シグナリング方法を比較する表を示す図である。本発明の一実施例に係る放送システムで使用されるシグナリング方法を示した図である。本発明の一実施例に係る第４シグナリング方法によるシグナリング構造を示した図である。本発明の一実施例に係る第３シグナリング方法によるシグナリング構造を示した図である。本発明の一実施例に係る第３シグナリング方法によるシグナリング構造を具体的に示した図である。本発明の一実施例に係る第３シグナリング方法と第４シグナリング方法を比較した図表を示した図である。本発明の一実施例に係る、ｅＭＢＭＳ放送とブロードバンドを介してサービスが提供される過程を示した図である。本発明の一実施例に係る、ＡＴＳＣ放送とブロードバンドを介してサービスが提供される過程を示した図である。本発明の一実施例に係る、ＡＴＳＣ放送、ｅＭＢＭＳ放送及びブロードバンドを介してサービスが提供される過程を示した図である。本発明の一実施例に係るシグナリング体系を用いて、受信機が放送サービスを取得する過程を示した図である。本発明の一実施例に係るシグナリング体系を用いて、受信機が放送網とブロードバンドを介して提供される放送サービスを取得する過程を示した図である。本発明の一実施例に係るシグナリング体系を用いて、レイヤードコーディング（ｌａｙｅｒｄｃｏｄｉｎｇ）が放送サービスに適用された場合、受信機が放送サービスを取得する過程を示した図である。本発明の一実施例に係るシグナリング体系を用いて、放送サービス／コンテンツの一つの要素に対して複数のコンポーネントが提供される場合、受信機が放送サービスを取得する過程を示した図である。本発明の一実施例に係るサービスマップテーブル（ＳｅｒｖｉｃｅＭａｐＴａｂｌｅ；ＳＭＴ）を示した図である。本発明の一実施例に係るＡＴＳＣＵＳＤを示した図である。本発明の他の実施例によるａｔｓｃＵＳＤを示した図である。本発明の一実施例に係る放送信号を生成処理する方法を示したフローチャートである。本発明の一実施例に係る放送システムを示した図である。

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

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

本発明は、次世代放送サービスに対する放送信号の送信及び受信装置及び方法を提供する。本発明の一実施例に係る次世代放送サービスは、地上波放送サービス、モバイル放送サービス、ＵＨＤＴＶサービスなどを含む。本発明は、一実施例によって、非−ＭＩＭＯ（ｎｏｎ−ＭｕｌｔｉｐｌｅＩｎｐｕｔＭｕｌｔｉｐｌｅＯｕｔｐｕｔ）又はＭＩＭＯ方式を用いて次世代放送サービスに対する放送信号を処理することができる。本発明の一実施例に係る非−ＭＩＭＯ方式は、ＭＩＳＯ（ＭｕｌｔｉｐｌｅＩｎｐｕｔＳｉｎｇｌｅＯｕｔｐｕｔ）方式、ＳＩＳＯ（ＳｉｎｇｌｅＩｎｐｕｔＳｉｎｇｌｅＯｕｔｐｕｔ）方式などを含むことができる。

図１は、本発明の一実施例に係る受信機プロトコルスタック（ｒｅｃｅｉｖｅｒｐｒｏｔｏｃｏｌｓｔａｃｋ）を示した図である。

放送網を介したサービスデリバリ（ｂｒｏａｄｃａｓｔｓｅｒｖｉｃｅｄｅｌｉｖｅｒｙ）において、２つの方法があり得る。

第一の方法は、ＭＭＴ（ＭＰＥＧＭｅｄｉａＴｒａｎｓｐｏｒｔ）に基づいて、ＭＰＵ（ＭｅｄｉａＰｒｏｃｅｓｓｉｎｇＵｎｉｔｓ）をＭＭＴＰ（ＭＭＴｐｒｏｔｏｃｏｌ）を用いて伝送することである。第二の方法は、ＭＰＥＧＤＡＳＨに基づいて、ＤＡＳＨセグメントをＲＯＵＴＥ（ＲｅａｌｔｉｍｅＯｂｊｅｃｔｄｅｌｉｖｅｒｙｏｖｅｒＵｎｉｄｉｒｅｃｔｉｏｎａｌＴｒａｎｓｐｏｒｔ）を用いて伝送することである。

ＮＲＴメディア、ＥＰＧデータ、及び他のファイルを含む非時間コンテンツは、ＲＯＵＴＥで伝達される。シグナルは、ＭＭＴＰ及び／又はＲＯＵＴＥを介して伝達できる一方、ブートストラップシグナリング情報はＳＬＴ（ｓｅｒｖｉｃｅｌｉｓｔｔａｂｌｅ）によって提供される。

ハイブリッドサービスデリバリ（ｈｙｂｒｉｄｓｅｒｖｉｃｅｄｅｌｉｖｅｒｙ）においては、ＨＴＴＰ／ＴＣＰ／ＩＰ上のＭＰＥＧＤＡＳＨがブロードバンド側で用いられる。ＩＳＯＢＭＦＦ（ｂａｓｅｍｅｄｉａｆｉｌｅｆｏｒｍａｔ）のメディアファイルは、デリバリ、ブロードキャスト及びブロードバンドデリバリに対するメディアカプセル化及び同期化フォーマットとして使用される。ここで、ハイブリッドサービスデリバリとは、１つ又はそれ以上のプログラムエレメントがブロードバンド経路（ｐａｔｈ）を介して伝達される場合のことをいえる。

サービスは、３つの機能層を用いて伝達される。これらは、物理層、デリバリ層、サービス管理層である。物理層は、シグナル、サービス公知、ＩＰパケットストリームがブロードキャスト物理層及び／又はブロードバンド物理層で伝送されるメカニズムを提供する。デリバリ層は、オブジェクト及びオブジェクトフロー伝送機能を提供する。これは、ブロードキャスト物理層のＵＤＰ／ＩＰマルチキャストで動作するＭＭＴＰ又はＲＯＵＴＥプロトコルによって可能であり、ブロードバンド物理層のＴＣＰ／ＩＰユニキャストでＨＴＴＰプロトコルによって可能である。サービス管理層は、下位であるデリバリ及び物理層によって実行されるリニアＴＶ又はＨＴＭＬ５応用サービスのような全てのサービスを可能にする。

本図において、放送（ｂｒｏａｄｃａｓｔ）側のプロトコルスタック部分は、ＳＬＴとＭＭＴＰを介して伝送される部分、ＲＯＵＴＥを介して伝送される部分とに分けられる。

ＳＬＴは、ＵＤＰ、ＩＰ層を経てカプセル化されてもよい。ここで、ＳＬＴについては後述する。ＭＭＴＰは、ＭＭＴで定義されるＭＰＵフォーマットでフォーマットされたデータ、及びＭＭＴＰによるシグナリング情報を伝送することができる。これらのデータは、ＵＤＰ、ＩＰ層を経てカプセル化されてもよい。ＲＯＵＴＥは、ＤＡＳＨセグメントの形態でフォーマットされたデータとシグナリング情報、そして、ＮＲＴなどのノンタイムド（ｎｏｎｔｉｍｅｄ）データを伝送することができる。これらのデータも、ＵＤＰ、ＩＰ層を経てカプセル化されてもよい。実施例によって、ＵＤＰ、ＩＰ層によるプロセシングは一部又は全部省略されてもよい。ここで、図示されたシグナリング情報（ｓｉｇｎａｌｉｎｇ）は、サービスに関するシグナリング情報であり得る。

ＳＬＴとＭＭＴＰを介して伝送される部分、ＲＯＵＴＥを介して伝送される部分は、ＵＤＰ、ＩＰ層で処理された後、データリンク層（ＤａｔａＬｉｎｋＬａｙｅｒ）で再びカプセル化されてもよい。リンク層については後述する。リンク層で処理された放送データは、物理層でエンコーディング／インターリービングなどの過程を経て放送信号としてマルチキャストされてもよい。

本図において、ブロードバンド（ｂｒｏａｄｂａｎｄ）側のプロトコルスタック部分は、前述したように、ＨＴＴＰを介して伝送されてもよい。ＤＡＳＨセグメントの形態でフォーマットされたデータとシグナリング情報、ＮＲＴなどの情報がＨＴＴＰを介して伝送されてもよい。ここで、図示されたシグナリング情報（ｓｉｇｎａｌｉｎｇ）は、サービスに関するシグナリング情報であってもよい。このデータは、ＴＣＰ、ＩＰ層を経てプロセスされた後、リンク層でカプセル化されてもよい。実施例によって、ＴＣＰ、ＩＰ、リンク層の一部又は全部は省略されてもよい。この後、処理されたブロードバンドデータは、物理層で伝送のための処理を経てブロードバンドにユニキャストされてもよい。

サービスは、全体的にユーザに見せるメディアコンポーネントのコレクションであってもよく、コンポーネントは、種々のメディアタイプのものであってもよく、サービスは、連続的又は間欠的であってもよく、サービスは、リアルタイム又は非リアルタイムであってもよく、リアルタイムサービスはＴＶプログラムのシーケンスで構成されてもよい。

図２は、本発明の一実施例に係るＳＬＴとＳＬＳ（ｓｅｒｖｉｃｅｌａｙｅｒｓｉｇｎａｌｉｎｇ）の関係を示した図である。

サービスシグナリングは、サービスディスカバリ及び記述情報を提供し、２つの機能コンポーネントを含む。これらは、ＳＬＴを介したブートストラップシグナリングとＳＬＳである。これらは、ユーザサービスを発見し、取得するのに必要な情報を示す。ＳＬＴは、受信機が、基本サービスリストを作成し、各サービスに対するＳＬＳの発見をブートストラップできるようにする。

ＳＬＴは、基本サービス情報の非常に速い取得を可能にする。ＳＬＳは、受信機が、サービスとそのコンテンツコンポーネントを発見し、これに接続できるようにする。ＳＬＴとＳＬＳの具体的な内容については後述する。

前述したように、ＳＬＴは、ＵＤＰ／ＩＰを介して伝送され得る。このとき、実施例によって、この伝送において最もロバストな（ｒｏｂｕｓｔ）方法を通じて、ＳＬＴに該当するデータが伝達されてもよい。

ＳＬＴは、ＲＯＵＴＥプロトコルによって伝達されるＳＬＳに接近するためのアクセス情報を有することができる。すなわち、ＳＬＴは、ＲＯＵＴＥプロトコルによるＳＬＳにブートストラップすることができる。このＳＬＳは、前述したプロトコルスタックにおいてＲＯＵＴＥの上位層に位置するシグナリング情報であって、ＲＯＵＴＥ／ＵＤＰ／ＩＰを介して伝達され得る。このＳＬＳは、ＲＯＵＴＥセッションに含まれるＬＣＴセッションのうち１つを介して伝達され得る。このＳＬＳを用いて、所望のサービスに該当するサービスコンポーネントに接近することができる。

また、ＳＬＴは、ＭＭＴＰによって伝達されるＭＭＴシグナリングコンポーネントに接近するためのアクセス情報を有することができる。すなわち、ＳＬＴは、ＭＭＴＰによるＳＬＳにブートストラップすることができる。このＳＬＳは、ＭＭＴで定義するＭＭＴＰシグナリングメッセージ（ＳｉｇｎａｌｉｎｇＭｅｓｓａｇｅ）によって伝達され得る。このＳＬＳを用いて、所望のサービスに該当するストリーミングサービスコンポーネント（ＭＰＵ）に接近することができる。前述したように、本発明では、ＮＲＴサービスコンポーネントは、ＲＯＵＴＥプロトコルを介して伝達され、ＭＭＴＰによるＳＬＳは、これに接近するための情報も含むことができる。ブロードバンドデリバリにおいて、ＳＬＳはＨＴＴＰ（Ｓ）／ＴＣＰ／ＩＰで伝達される。

図３は、本発明の一実施例に係るＳＬＴを示した図である。

まず、サービスマネジメント、デリバリ、物理層の各論理的エンティティ間の関係について説明する。

サービスは、２つの基本タイプのうち１つとしてシグナルされ得る。第一のタイプは、アプリベースのエンハンスメントを有し得るリニアオーディオ／ビデオ又はオーディオのみのサービスである。第二のタイプは、プレゼンテーション及び構成が、サービスの取得によって実行されるダウンロードアプリケーションによって制御されるサービスである。後者は、アプリベースのサービスと呼ぶこともできる。

サービスのコンテンツコンポーネントを伝達するＭＭＴＰセッション及び／又はＲＯＵＴＥ／ＬＣＴセッションの存在と関連する規則は、次の通りである。

アプリベースのエンハンスメントがないリニアサービスのブロードキャストデリバリのために、サービスのコンテンツコンポーネントは、（１）１つ以上のＲＯＵＴＥ／ＬＣＴセッション、又は（２）１つ以上のＭＭＴＰセッションのうち１つ（両方ともではない）によって伝達され得る。

アプリベースのエンハンスメントがあるリニアサービスのブロードキャストデリバリのために、サービスのコンテンツコンポーネントは、（１）１つ以上のＲＯＵＴＥ／ＬＣＴセッション、及び（２）０個以上のＭＭＴＰセッションによって伝達され得る。

特定の実施例において、同一のサービスでストリーミングメディアコンポーネントに対するＭＭＴＰ及びＲＯＵＴＥの両者の使用が許容されないことがある。

アプリベースのサービスのブロードキャストデリバリのために、サービスのコンテンツコンポーネントは１つ以上のＲＯＵＴＥ／ＬＣＴセッションによって伝達され得る。

それぞれのＲＯＵＴＥセッションは、サービスを構成するコンテンツコンポーネントを全体的又は部分的に伝達する１つ以上のＬＣＴセッションを含む。ストリーミングサービスデリバリにおいて、ＬＣＴセッションは、オーディオ、ビデオ、又はクローズドキャプションストリームのようなユーザサービスの個別コンポーネントを伝達することができる。ストリーミングメディアは、ＤＡＳＨセグメントとしてフォーマットされる。

それぞれのＭＭＴＰセッションは、ＭＭＴシグナリングメッセージ又は全体又は一部のコンテンツコンポーネントを伝達する、１つ以上のＭＭＴＰパケットフローを含む。ＭＭＴＰパケットフローは、ＭＭＴシグナリングメッセージ、又はＭＰＵとしてフォーマットされたコンポーネントを伝達することができる。

ＮＲＴユーザサービス又はシステムメタデータのデリバリのために、ＬＣＴセッションは、ファイルベースのコンテンツアイテムを伝達する。これらのコンテンツファイルは、ＮＲＴサービスの連続的（タイムド）又は離散的（ノンタイムド）メディアコンポーネント、又はサービスシグナリングやＥＳＧフラグメントのようなメタデータで構成され得る。サービスシグナリングやＥＳＧフラグメントのようなシステムメタデータのデリバリも、ＭＭＴＰのシグナリングメッセージモードを通じて行われてもよい。

ブロードキャストストリームは、特定の帯域内に集中したキャリア周波数の観点で定義されたＲＦチャネルの概念である。それは、［地理的領域、周波数］ペアによって識別される。ＰＬＰ（ｐｈｙｓｉｃａｌｌａｙｅｒｐｉｐｅ）は、ＲＦチャネルの一部に該当する。各ＰＬＰは、特定のモジュレーション及びコーディングパラメータを有する。それは、属しているブロードキャストストリーム内で唯一のＰＬＰＩＤ（ＰＬＰｉｄｅｎｔｉｆｉｅｒ）によって識別される。ここで、ＰＬＰはＤＰ（ｄａｔａｐｉｐｅ）と呼ぶこともできる。

各サービスは、２つの形態のサービス識別子によって識別される。一方は、ＳＬＴで使用され、ブロードキャスト領域内でのみ唯一のコンパクト形態であり、他方は、ＳＬＳ及びＥＳＧで使用される全世界的に唯一の形態である。ＲＯＵＴＥセッションは、ソースＩＰ住所、目的地ＩＰ住所、目的地ポート番号によって識別される。ＬＣＴセッション（それが伝達するサービスコンポーネントと関連する）は、ペアレントＲＯＵＴＥセッションの範囲内で唯一のＴＳＩ（ｔｒａｎｓｐｏｒｔｓｅｓｓｉｏｎｉｄｅｎｔｉｆｉｅｒ）によって識別される。ＬＣＴセッションに共通した属性及び個別ＬＣＴセッションに唯一の特定の属性は、サービス層シグナリングの一部であるＳ−ＴＳＩＤ（ｓｅｒｖｉｃｅ−ｂａｓｅｄｔｒａｎｓｐｏｒｔｓｅｓｓｉｏｎｉｎｓｔａｎｃｅｄｅｓｃｒｉｐｔｉｏｎ）と呼ばれるＲＯＵＴＥシグナリング構造で与えられる。各ＬＣＴセッションは、１つのＰＬＰを介して伝達される。実施例によって、１つのＬＣＴセッションが複数個のＰＬＰを介して伝達されてもよい。ＲＯＵＴＥセッションの互いに異なるＬＣＴセッションは、互いに異なるＰＬＰに含まれてもよく、そうでなくてもよい。ここで、ＲＯＵＴＥセッションは、複数個のＰＬＰを介して伝達されてもよい。Ｓ−ＴＳＩＤに記述された属性は、各ＬＣＴセッションに対するＴＳＩ値及びＰＬＰＩＤ、デリバリオブジェクト／ファイルに対するディスクリプタ、アプリケーション層ＦＥＣパラメータを含む。

ＭＭＴＰセッションは、目的地ＩＰ住所及び目的地ポート番号によって識別される。ＭＭＴＰパケットフロー（それが伝達するサービスコンポーネントと関連する）は、ペアレントＭＭＴＰセッションの範囲内で唯一のｐａｃｋｅｔ＿ｉｄによって識別される。各ＭＭＴＰパケットフローに共通した属性及びＭＭＴＰパケットフローの特定の属性がＳＬＴに与えられる。各ＭＭＴＰセッションに対する属性は、ＭＭＴＰセッション内で伝達され得るＭＭＴシグナリングメッセージによって与えらえる。ＭＭＴＰセッションの互いに異なるＭＭＴＰパケットフローは、互いに異なるＰＬＰに含まれてもよく、そうでなくてもよい。ここで、ＭＭＴＰセッションは、複数個のＰＬＰを介して伝達されてもよい。ＭＭＴシグナリングメッセージに記述された属性は、各ＭＭＴＰパケットフローに対してｐａｃｋｅｔ＿ｉｄ値及びＰＬＰＩＤを含む。ここで、ＭＭＴシグナリングメッセージは、ＭＭＴで定義された形態であるか、又は後述する実施例によって変形が行われた形態であってもよい。

以下、ＬＬＳ（ＬｏｗＬｅｖｅｌＳｉｇｎａｌｉｎｇ）について説明する。

この機能に専用であるよく知られている住所／ポートを有するＩＰパケットのペイロードに伝達されるシグナリング情報は、ＬＬＳと呼ばれる。このＩＰ住所及びポート番号は、実施例によって異なって設定されてもよい。一実施例において、ＬＬＳは、住所が２２４．０．２３．６０であり、目的地ポートが４９３７／ｕｄｐであるＩＰパケットに伝達され得る。ＬＬＳは、前述したプロトコルスタック上で、「ＳＬＴ」で表現された部分に位置し得る。ただし、実施例によって、ＬＬＳは、ＵＤＰ／ＩＰ層のプロセシングを経ずに、信号フレーム上の別途の物理チャネル（ｄｅｄｉｃａｔｅｄｃｈａｎｎｅｌ）を介して伝送されてもよい。

ＬＬＳデータを伝達するＵＤＰ／ＩＰパケットは、ＬＬＳテーブルという形態でフォーマットすることができる。ＬＬＳデータを運搬する毎ＵＤＰ／ＩＰパケットの最初のバイトは、ＬＬＳテーブルの開始であり得る。全てのＬＬＳテーブルの最大の長さは、物理層から伝達され得る最も大きいＩＰパケットによって６５，５０７バイトに制限される。

ＬＬＳテーブルは、ＬＬＳテーブルのタイプを識別するＬＬＳテーブルＩＤフィールド、及びＬＬＳテーブルのバージョンを識別するＬＬＳテーブルバージョンフィールドを含むことができる。ＬＬＳテーブルＩＤフィールドが示す値に応じて、ＬＬＳテーブルは、前述したＳＬＴを含むか、又はＲＲＴ（ＲａｔｉｎｇＲｅｇｉｏｎＴａｂｌｅ）を含むことができる。ＲＲＴは、コンテンツ勧告レーティング（ＣｏｎｔｅｎｔＡｄｖｉｓｏｒｙＲａｔｉｎｇ）に関する情報を有することができる。

以下、ＳＬＴ（ＳｅｒｖｉｃｅＬｉｓｔＴａｂｌｅ）について説明する。ＬＬＳは、受信機によるサービス取得のブートストラッピング及び速いチャネルスキャンを支援するシグナリング情報であり、ＳＬＴは、基本サービスリスティングを構築し、ＳＬＳのブートストラップディスカバリを提供するために使用されるシグナリング情報のテーブルであり得る。

ＳＬＴの機能は、ＭＰＥＧ−２システムでのＰＡＴ（ｐｒｏｇｒａｍａｓｓｏｃｉａｔｉｏｎｔａｂｌｅ）及びＡＴＳＣシステムで発見されるＦＩＣ（ｆａｓｔｉｎｆｏｒｍａｔｉｏｎｃｈａｎｎｅｌ）とほぼ同一である。初めてブロードキャストエミッションを経験する受信機にとって、これは、開始される地点である。ＳＬＴは、受信機が、チャネル名、チャネル番号などでそれが受信できる全てのサービスのリストを構築できるようにする、速いチャネルスキャンを支援する。また、ＳＬＴは、受信機が各サービスに対してＳＬＳを発見できるようにするブートストラップ情報を提供する。ＲＯＵＴＥ／ＤＡＳＨで伝達されるサービスに対して、ブートストラップ情報は、ＳＬＳを伝達するＬＣＴセッションの目的地ＩＰ住所及び目的地ポートを含む。ＭＭＴ／ＭＰＵで伝達されるサービスに対して、ブートストラップ情報は、ＳＬＳを伝達するＭＭＴＰセッションの目的地ＩＰ住所及び目的地ポートを含む。

ＳＬＴは、ブロードキャストストリームで各サービスに関する次の情報を含むことによって、サービス取得及び速いチャネルスキャンを支援する。第一に、ＳＬＴは、視聴者にとって有意義であり、上／下の選択又はチャネル番号を介した初期サービス選択を支援できるサービスリストのプレゼンテーションを許容するのに必要な情報を含むことができる。第二に、ＳＬＴは、各リストされたサービスに対してＳＬＳの位置を見つけるのに必要な情報を含むことができる。すなわち、ＳＬＴは、ＳＬＳを伝達する位置（ｌｏｃａｔｉｏｎ）に対するアクセス情報を含むことができる。

図示された本発明の一実施例に係るＳＬＴは、ＳＬＴルートエレメント（ｒｏｏｔｅｌｅｍｅｎｔ）を有するＸＭＬドキュメントの形態で表現された。実施例によって、ＳＬＴは、バイナリフォーマット又はＸＭＬドキュメントの形態で表現することができる。

図示されたＳＬＴのＳＬＴルートエレメントは、＠ｂｓｉｄ、＠ｓｌｔＳｅｃｔｉｏｎＶｅｒｓｉｏｎ、＠ｓｌｔＳｅｃｔｉｏｎＮｕｍｂｅｒ、＠ｔｏｔａｌＳｌｔＳｅｃｔｉｏｎＮｕｍｂｅｒｓ、＠ｌａｎｇｕａｇｅ、＠ｃａｐａｂｉｌｉｔｉｅｓ、ＩｎｅｔＳｉｇＬｏｃ及び／又はＳｅｒｖｉｃｅを含むことができる。実施例によって、ＳＬＴルートエレメントは、＠ｐｒｏｖｉｄｅｒＩｄをさらに含むこともできる。実施例によって、ＳＬＴルートエレメントは、＠ｌａｎｇｕａｇｅを含まなくてもよい。

Ｓｅｒｖｉｃｅエレメントは、＠ｓｅｒｖｉｃｅＩｄ、＠ＳＬＴｓｅｒｖｉｃｅＳｅｑＮｕｍｂｅｒ、＠ｐｒｏｔｅｃｔｅｄ、＠ｍａｊｏｒＣｈａｎｎｅｌＮｏ、＠ｍｉｎｏｒＣｈａｎｎｅｌＮｏ、＠ｓｅｒｖｉｃｅＣａｔｅｇｏｒｙ、＠ｓｈｏｒｔＳｅｒｖｉｃｅＮａｍｅ、＠ｈｉｄｄｅｎ、＠ｓｌｓＰｒｏｔｏｃｏｌＴｙｐｅ、ＢｒｏａｄｃａｓｔＳｉｇｎａｌｉｎｇ、＠ｓｌｓＰｌｐＩｄ、＠ｓｌｓＤｅｓｔｉｎａｔｉｏｎＩｐＡｄｄｒｅｓｓ、＠ｓｌｓＤｅｓｔｉｎａｔｉｏｎＵｄｐＰｏｒｔ、＠ｓｌｓＳｏｕｒｃｅＩｐＡｄｄｒｅｓｓ、＠ｓｌｓＭａｊｏｒＰｒｏｔｏｃｏｌＶｅｒｓｉｏｎ、＠ＳｌｓＭｉｎｏｒＰｒｏｔｏｃｏｌＶｅｒｓｉｏｎ、＠ｓｅｒｖｉｃｅＬａｎｇｕａｇｅ、＠ｂｒｏａｄｂａｎｄＡｃｃｅｓｓＲｅｑｕｉｒｅｄ、＠ｃａｐａｂｉｌｉｔｉｅｓ及び／又はＩｎｅｔＳｉｇＬｏｃを含むことができる。

実施例によって、ＳＬＴの属性又はエレメントは追加／変更／削除されてもよい。ＳＬＴに含まれる各エレメントも、追加的に別途の属性又はエレメントを有することができ、本実施例に係る属性又はエレメントの一部が省略されてもよい。ここで、＠表記されたフィールドは属性（ａｔｔｒｉｂｕｔｅ）に該当し、＠表記されていないフィールドはエレメント（ｅｌｅｍｅｎｔ）に該当し得る。

＠ｂｓｉｄは、全ブロードキャストストリームの識別子である。ＢＳＩＤの値は、地域的レベルで唯一であり得る。

＠ｐｒｏｖｉｄｅｒＩｄは、このブロードキャストストリームの一部又は全体を使用する放送会社のインデックスである。これは選択的な属性である。それが存在しないということは、このブロードキャストストリームが一つの放送会社によって使用されていることを意味する。＠ｐｒｏｖｉｄｅｒＩｄは図示していない。

＠ｓｌｔＳｅｃｔｉｏｎＶｅｒｓｉｏｎは、ＳＬＴセクションのバージョン番号であり得る。ｓｌｔＳｅｃｔｉｏｎＶｅｒｓｉｏｎは、ｓｌｔ内で伝達される情報に変化が生じると１ずつ増分し得る。それが最大値に到達すると、０にシフトされる。

＠ｓｌｔＳｅｃｔｉｏｎＮｕｍｂｅｒは、ＳＬＴの当該セクションの番号であって、１からカウントすることができる。すなわち、当該ＳＬＴセクションのセクション番号に該当し得る。このフィールドが使用されない場合、デフォルト値１に設定されてもよい。

＠ｔｏｔａｌＳｌｔＳｅｃｔｉｏｎＮｕｍｂｅｒｓは、当該セクションが一部であるＳＬＴのセクション（即ち、最大のｓｌｔＳｅｃｔｉｏｎＮｕｍｂｅｒを有するセクション）の総番号であり得る。ｓｌｔＳｅｃｔｉｏｎＮｕｍｂｅｒとｔｏｔａｌＳｌｔＳｅｃｔｉｏｎＮｕｍｂｅｒｓは共にフラグメントで伝送される場合、ＳＬＴの一部の「ＮのＭ部分」を示すと見ることができる。すなわち、ＳＬＴを伝送するにおいて、分割（ｆｒａｇｍｅｎｔａｔｉｏｎ）を通じた伝送を支援できる。このフィールドが使用されない場合、デフォルト値１に設定されてもよい。フィールドが使用されない場合は、ＳＬＴが分割されて伝送されない場合であり得る。

＠ｌａｎｇｕａｇｅは、当該ｓｌｔの場合に含まれるサービスの主言語を示すことができる。実施例によって、このフィールド値は、ＩＳＯで定義される３−キャラクタ言語コード（ｔｈｒｅｅｃｈａｒａｃｔｅｒｌａｎｇｕａｇｅｃｏｄｅ）の形態であってもよい。本フィールドは省略されてもよい。

＠ｃａｐａｂｉｌｉｔｉｅｓは、当該ｓｌｔの場合において全てのサービスに対する内容をデコードし、有意義に示すために要求される能力を示すことができる。

ＩｎｅｔＳｉｇＬｏｃは、どこでブロードバンドを介して外部サーバーから全ての要求されるタイプのデータを取得できるかを受信機に知らせるＵＲＬを提供することができる。このエレメントは、＠ｕｒｌＴｙｐｅを下位フィールドとしてさらに含むこともできる。この＠ｕｒｌＴｙｐｅフィールドの値に応じて、ＩｎｅｔＳｉｇＬｏｃが提供するＵＲＬのタイプを指示することができる。実施例によって、＠ｕｒｌＴｙｐｅフィールド値が０である場合、ＩｎｅｔＳｉｇＬｏｃはシグナリングサーバーのＵＲＬを提供することができる。＠ｕｒｌＴｙｐｅフィールド値が１である場合、ＩｎｅｔＳｉｇＬｏｃはＥＳＧサーバーのＵＲＬを提供することができる。＠ｕｒｌＴｙｐｅフィールドが、それ以外の値を有する場合は、後で使用するために残すことができる（ｒｅｓｅｒｖｅｄｆｏｒｆｕｔｕｒｅｕｓｅ）。

Ｓｅｒｖｉｃｅフィールドは、各サービスに関する情報を有するエレメントであって、サービスエントリに該当し得る。ＳＬＴが指示するサービスの数（Ｎ）だけＳｅｒｖｉｃｅエレメントフィールドが存在し得る。以下、Ｓｅｒｖｉｃｅフィールドの下位属性／エレメントについて説明する。

＠ｓｅｒｖｉｃｅＩｄは、当該ブロードキャスト領域の範囲内で当該サービスを唯一に識別する整数であり得る。実施例によって、＠ｓｅｒｖｉｃｅＩｄのスコープ（ｓｃｏｐｅ）は変更されてもよい。＠ＳＬＴｓｅｒｖｉｃｅＳｅｑＮｕｍｂｅｒは、前記ｓｅｒｖｉｃｅＩｄ属性と同一のサービスＩＤを有するＳＬＴサービス情報のシーケンス番号を示す整数であり得る。ＳＬＴｓｅｒｖｉｃｅＳｅｑＮｕｍｂｅｒ値は、各サービスに対して０から始まることができ、当該Ｓｅｒｖｉｃｅエレメントにおいてある属性が変化するたびに１ずつ増分することができる。ＳｅｒｖｉｃｅＩＤの特定の値を有する以前のサービスエレメントに比べていかなる属性値も変化しない場合、ＳＬＴｓｅｒｖｉｃｅＳｅｑＮｕｍｂｅｒは増分しないはずである。ＳＬＴｓｅｒｖｉｃｅＳｅｑＮｕｍｂｅｒフィールドは、最大値に到達した後、０にシフトされる。

＠ｐｒｏｔｅｃｔｅｄは、フラグ情報であって、当該サービスの有意義な再生のための１つ又はそれ以上のコンポーネントが保護された（ｐｒｏｔｅｃｔｅｄ）状態であるかを示すことができる。「１」（真）に設定されると、有意義なプレゼンテーションに必要な１つ以上のコンポーネントが保護される。「０」（偽）に設定されると、当該フラグは、サービスの有意義なプレゼンテーションに必要なコンポーネントが何にも保護されないことを示す。デフォルト値は偽である。

＠ｍａｊｏｒＣｈａｎｎｅｌＮｏは、サービスの「主」チャネル番号を示す整数値である。本フィールドの一実施例は、１から９９９までの範囲を有することができる。

＠ｍｉｎｏｒＣｈａｎｎｅｌＮｏは、サービスの「副」チャネル番号を示す整数値である。本フィールドの一実施例は、１から９９９までの範囲を有することができる。

＠ｓｅｒｖｉｃｅＣａｔｅｇｏｒｙは、当該サービスのカテゴリを示すことができる。本フィールドが示す意味は、実施例によって変更されてもよい。一実施例によれば、本フィールドの値が１、２、３である場合、それぞれ当該サービスは、リニアＡ／Ｖサービス（ＬｉｎｅａｒＡ／Ｖｓｅｒｖｉｃｅ）、リニアオーディオサービス（Ｌｉｎｅａｒａｕｄｉｏｏｎｌｙｓｅｒｖｉｃｅ）、アプリベースのサービス（ａｐｐ−ｂａｓｅｄｓｅｒｖｉｃｅ）に該当し得る。本フィールドの値が０である場合、定義されていないカテゴリのサービスであり得、本フィールドの値が０、１、２、３以外の他の値を有する場合は、後で使用するために残すことができる（ｒｅｓｅｒｖｅｄｆｏｒｆｕｔｕｒｅｕｓｅ）。＠ｓｈｏｒｔＳｅｒｖｉｃｅＮａｍｅは、サービスのショートストリングネームであり得る。

＠ｈｉｄｄｅｎは、存在し、「真」に設定される場合、ブール値であり得、これは、サービスがテストや独占使用のためのものであり、通常のＴＶ受信機によっては選択されないことを示す。存在しない場合、デフォルト値は「偽」である。

＠ｓｌｓＰｒｏｔｏｃｏｌＴｙｐｅは、当該サービスによって使用されるＳＬＳのプロトコルのタイプを示す属性であり得る。本フィールドが示す意味は、実施例によって変更されてもよい。一実施例によれば、本フィールドの値が１、２である場合、それぞれ、当該サービスが使用するＳＬＳのプロトコルはＲＯＵＴＥ、ＭＭＴＰであり得る。本フィールドの値が０又はそれ以外の値を有する場合は、後で使用するために残すことができる（ｒｅｓｅｒｖｅｄｆｏｒｆｕｔｕｒｅｕｓｅ）。本フィールドは、＠ｓｌｓＰｒｏｔｏｃｏｌと呼ぶこともできる。

ＢｒｏａｄｃａｓｔＳｉｇｎａｌｉｎｇ及びその下位属性／エレメントは、放送シグナリングと関連する情報を提供することができる。ＢｒｏａｄｃａｓｔＳｉｇｎａｌｉｎｇエレメントが存在しない場合、ペアレントサービスエレメントのチャイルドエレメントであるＩｎｅｔＳｉｇＬｏｃが存在し得、その属性であるｕｒｌＴｙｐｅはＵＲＬ_ｔｙｐｅ０ｘ００（ＵＲＬｔｏｓｉｇｎａｌｉｎｇｓｅｒｖｅｒ）を含む。この場合、属性であるｕｒｌは、ｓｅｒｖｉｃｅ＿ｉｄがペアレントサービスエレメントに対するｓｅｒｖｉｃｅｄ属性に該当するクエリパラメータｓｖｃ＝＜ｓｅｒｖｉｃｅ＿ｉｄ＞を支援する。

又は、ＢｒｏａｄｃａｓｔＳｉｇｎａｌｉｎｇエレメントが存在しない場合、エレメントＩｎｅｔＳｉｇＬｏｃはｓｌｔルートエレメントのチャイルドエレメントとして存在し得、ＩｎｅｔＳｉｇＬｏｃエレメントの属性ｕｒｌＴｙｐｅはＵＲＬ＿ｔｙｐｅ０ｘ００（ＵＲＬｔｏｓｉｇｎａｌｉｎｇｓｅｒｖｅｒ）を含む。この場合、ＵＲＬ＿ｔｙｐｅ０ｘ００に対する属性ｕｒｌは、ｓｅｒｖｉｃｅ＿ｉｄがペアレントサービスエレメントのｓｅｒｖｉｃｅＩｄ属性に該当するクエリパラメータｓｖｃ＝＜ｓｅｒｖｉｃｅ＿ｉｄ＞を支援する。

＠ｓｌｓＰｌｐＩｄは、当該サービスに対してＳＬＳを伝達するＰＬＰのＰＬＰＩＤを示す整数を表現するストリングであり得る。

＠ｓｌｓＤｅｓｔｉｎａｔｉｏｎＩｐＡｄｄｒｅｓｓは、当該サービスに対してＳＬＳデータを伝達するパケットのｄｏｔｔｅｄ−ＩＰｖ４目的地住所を含むストリングであり得る。

＠ｓｌｓＤｅｓｔｉｎａｔｉｏｎＵｄｐＰｏｒｔは、当該サービスに対してＳＬＳデータを伝達するパケットのポート番号を含むストリングであり得る。前述したように、目的地ＩＰ／ＵＤＰ情報によってＳＬＳブートストラッピングを行うことができる。

＠ｓｌｓＳｏｕｒｃｅＩｐＡｄｄｒｅｓｓは、当該サービスに対してＳＬＳデータを伝達するパケットのｄｏｔｔｅｄ−ＩＰｖ４ソース住所を含むストリングであり得る。

＠ｓｌｓＭａｊｏｒＰｒｏｔｏｃｏｌＶｅｒｓｉｏｎは、当該サービスに対してＳＬＳを伝達するために使用されるプロトコルの主バージョン番号であり得る。デフォルト値は１である。

＠ＳｌｓＭｉｎｏｒＰｒｏｔｏｃｏｌＶｅｒｓｉｏｎは、当該サービスに対してＳＬＳを伝達するために使用されるプロトコルの副バージョン番号であり得る。デフォルト値は０である。

＠ｓｅｒｖｉｃｅＬａｎｇｕａｇｅは、サービスの主言語を示す３文字言語コードであり得る。本フィールド値の形式は、実施例によって変更されてもよい。

＠ｂｒｏａｄｂａｎｄａｃｃｅｓｓＲｅｑｕｉｒｅｄは、受信機がサービスの有意義なプレゼンテーションを行うためにブロードバンドアクセスが必要であることを示すブール値であり得る。本フィールドの値がＴｒｕｅである場合、受信機は、有意義なサービス再生のためにブロードバンドにアクセスしなければならず、これは、サービスのハイブリッドデリバリのケースに該当し得る。

＠ｃａｐａｂｉｌｉｔｉｅｓは、前記ｓｅｒｖｉｃｅＩｄ属性と同一のサービスＩＤであって、サービスに対する内容をデコードし、有意義に示すために要求される能力を示すことができる。

ＩｎｅｔＳｉｇＬｏｃは、使用可能な場合、ブロードバンドを介してシグナリングや公知の情報に接続するためのＵＲＬを提供することができる。そのデータタイプは、ＵＲＬがどこにアクセスするかを示す＠ｕｒｌＴｙｐｅ属性を追加する全てのＵＲＬデータタイプの拡張であり得る。本フィールドの＠ｕｒｌＴｙｐｅフィールドが意味することは、前述したＩｎｅｔＳｉｇＬｏｃの＠ｕｒｌＴｙｐｅフィールドが意味することと同一であり得る。属性ＵＲＬ＿ｔｙｐｅ０ｘ００のＩｎｅｔＳｉｇＬｏｃエレメントがＳＬＴのエレメントとして存在する場合、それは、シグナリングメタデータに対してＨＴＴＰ要求を行うために使用され得る。このＨＴＴＰＰＯＳＴメッセージボディーにはサービスタームが含まれてもよい。ＩｎｅｔＳｉｇＬｏｃエレメントがセクションレベルで現れる場合、サービスタームは、要求されたシグナリングメタデータオブジェクトが適用されるサービスを示すために使用される。サービスタームが存在しない場合、当該セクションの全てのサービスに対するシグナリングメタデータオブジェクトが要求される。ＩｎｅｔＳｉｇＬｏｃがサービスレベルで現れる場合、所望のサービスを指定するために必要なサービスタームがない。属性ＵＲＬ＿ｔｙｐｅ０ｘ０１のＩｎｅｔＳｉｇＬｏｃエレメントが提供されると、それは、ブロードバンドを介してＥＳＧデータを検索するのに使用することができる。当該エレメントがサービスエレメントのチャイルドエレメントとして現れる場合、ＵＲＬは、当該サービスに対してデータを検索するのに使用することができる。当該エレメントがＳＬＴエレメントのチャイルドエレメントとして現れる場合、ＵＲＬは、当該セクションで全てのサービスに対するＥＳＧデータを検索するのに使用することができる。

ＳＬＴの他の実施例において、ＳＬＴの＠ｓｌｔＳｅｃｔｉｏｎＶｅｒｓｉｏｎ、＠ｓｌｔＳｅｃｔｉｏｎＮｕｍｂｅｒ、＠ｔｏｔａｌＳｌｔＳｅｃｔｉｏｎＮｕｍｂｅｒｓ及び／又は＠ｌａｎｇｕａｇｅフィールドは省略されてもよい。

また、前述したＩｎｅｔＳｉｇＬｏｃフィールドは、＠ｓｌｔＩｎｅｔＳｉｇＵｒｉ及び／又は＠ｓｌｔＩｎｅｔＥｓｇＵｒｉフィールドに代替されてもよい。２つのフィールドは、それぞれシグナリングサーバーのＵＲＩ、ＥＳＧサーバーのＵＲＩ情報を含むことができる。ＳＬＴの下位エレメントであるＩｎｅｔＳｉｇＬｏｃフィールド及びＳｅｒｖｉｃｅの下位エレメントであるＩｎｅｔＳｉｇＬｏｃフィールドは、いずれも、前記のような方法で代替されてもよい。

提示されたデフォルト値は、実施例によって変更されてもよい。図示された使用（ｕｓｅ）列は各フィールドに関するもので、１は、当該フィールドが必須のフィールドであり、０..１は、当該フィールドがオプショナルフィールドであることを意味し得る。

図４は、本発明の一実施例に係るＳＬＳブートストラッピング及びサービスディスカバリ過程を示した図である。

以下、サービス層シグナリング（ＳＬＳ、ＳｅｒｖｉｃｅＬａｙｅｒＳｉｇｎａｌｉｎｇ）について説明する。

ＳＬＳは、サービス及びそのコンテンツコンポーネントを発見し、取得するための情報を提供するシグナリングであり得る。

ＲＯＵＴＥ／ＤＡＳＨについて、各サービスに対するＳＬＳは、コンポーネントのリスト、どこでそれらを取得できるのか、サービスの有意義なプレゼンテーションのために要求される受信機の能力のようなサービスの特性を記述する。ＲＯＵＴＥ／ＤＡＳＨシステムにおいて、ＳＬＳは、ＵＳＢＤ（ｕｓｅｒｓｅｒｖｉｃｅｂｕｎｄｌｅｄｅｓｃｒｉｐｔｉｏｎ）、Ｓ−ＴＳＩＤ、ＤＡＳＨＭＰＤ（ｍｅｄｉａｐｒｅｓｅｎｔａｔｉｏｎｄｅｓｃｒｉｐｔｉｏｎ）を含む。ここで、ＵＳＢＤ又はＵＳＤ（ＵｓｅｒＳｅｒｖｉｃｅＤｅｓｃｒｉｐｔｉｏｎ）は、ＳＬＳＸＭＬフラグメントのうちの１つであって、サービスの具体的な技術的情報を記述するシグナリングハブとしての役割を果たすことができる。このＵＳＢＤ／ＵＳＤは、３ＧＰＰＭＢＭＳで定義されたことよりもさらに拡張されてもよい。ＵＳＢＤ／ＵＳＤの具体的な内容については後述する。

サービスシグナリングは、サービス自体の基本属性、特に、サービスを取得するために必要な属性に焦点を置く。視聴者のためのサービス及びプログラミングの特徴は、サービスの公知又はＥＳＧデータとして現れる。

各サービスに対して別個のサービスシグナリングを有する場合、受信機は、ブロードキャストストリーム内で伝達される全ＳＬＳをパースすることなく所望のサービスに対する適切なＳＬＳを取得すればよい。

サービスシグナリングの選択的なブロードバンドデリバリに対して、ＳＬＴは、前述したように、サービスシグナリングファイルが取得され得るＨＴＴＰＵＲＬを含むことができる。

ＬＬＳは、ＳＬＳ取得をブートストラップするのに使用され、その後、ＳＬＳは、ＲＯＵＴＥセッション又はＭＭＴＰセッションで伝達されるサービスコンポーネントを取得するのに使用される。記述された図面は、次のシグナリングシーケンスを示す。受信機は、前述したＳＬＴを取得し始める。ＲＯＵＴＥセッションで伝達されるｓｅｒｖｉｃｅ＿ｉｄによって識別される各サービスは、ＰＬＰＩＤ（＃１）、ソースＩＰ住所（ｓＩＰ１）、目的地ＩＰ住所（ｄＩＰ１）、及び目的地ポート番号（ｄＰｏｒｔ１）のようなＳＬＳブートストラッピング情報を提供する。ＭＭＴＰセッションで伝達されるｓｅｒｖｉｃｅ＿ｉｄによって識別される各サービスは、ＰＬＰＩＤ（＃２）、目的地ＩＰ住所（ｄＩＰ２）、及び目的地ポート番号（ｄＰｏｒｔ２）のようなＳＬＳブートストラッピング情報を提供する。

ＲＯＵＴＥを用いたストリーミングサービスデリバリに対して、受信機は、ＰＬＰ及びＩＰ／ＵＤＰ／ＬＣＴセッションで伝達されるＳＬＳフラグメントを取得することができる。反面、ＭＭＴＰを用いたストリーミングサービスデリバリに対して、受信機は、ＰＬＰ及びＭＭＴＰセッションで伝達されるＳＬＳフラグメントを取得することができる。ＲＯＵＴＥを用いたサービスデリバリに対して、これらＳＬＳフラグメントは、ＵＳＢＤ／ＵＳＤフラグメント、Ｓ−ＴＳＩＤフラグメント、ＭＰＤフラグメントを含む。それらは一つのサービスと関連がある。ＵＳＢＤ／ＵＳＤフラグメントは、サービス層の特性を記述し、Ｓ−ＴＳＩＤフラグメントに対するＵＲＩリファレンス及びＭＰＤフラグメントに対するＵＲＩリファレンスを提供する。すなわち、ＵＳＢＤ／ＵＳＤは、Ｓ−ＴＳＩＤとＭＰＤをそれぞれ参照することができる。ＭＭＴＰを用いたサービスデリバリに対して、ＵＳＢＤは、ＭＭＴシグナリングのＭＭＴメッセージを参照し、そのＭＰテーブルは、サービスに属するアセット（ａｓｓｅｔ）のための位置情報及びパッケージＩＤの識別を提供する。ここで、Ａｓｓｅｔとは、マルチメディアデータエンティティであって、一つのユニークなＩＤに連合され、一つのマルチメディアプレゼンテーションを生成するのに使用されるデータエンティティを意味し得る。Ａｓｓｅｔは、一つのサービスを構成するサービスコンポーネントに該当し得る。ＭＰＴメッセージは、ＭＭＴのＭＰテーブルを有するメッセージであり、ここで、ＭＰテーブルは、ＭＭＴＡｓｓｅｔとコンテンツに関する情報を有する、ＭＭＴパッケージテーブル（ＭＭＴＰａｃｋａｇｅＴａｂｌｅ）であり得る。具体的な内容は、ＭＭＴで定義された通りである。ここで、メディアプレゼンテーションとは、メディアコンテンツのバウンド／アンバウンドされたプレゼンテーションを成立させるデータのコレクションであり得る。

Ｓ−ＴＳＩＤフラグメントは、一つのサービスと関連するコンポーネント取得情報と、当該サービスのコンポーネントに該当するＴＳＩ及びＭＰＤで発見されるＤＡＳＨ表現との間のマッピングを提供する。Ｓ−ＴＳＩＤは、ＴＳＩ及び関連するＤＡＳＨ表現識別子の形態のコンポーネント取得情報、及びＤＡＳＨ表現と関連するＤＡＳＨセグメントを伝達するＰＬＰＩＤを提供することができる。ＰＬＰＩＤ及びＴＳＩ値によって、受信機は、サービスからオーディオ／ビデオコンポーネントを収集し、ＤＡＳＨメディアセグメントのバッファリングを開始した後、適切なデコーディング過程を適用する。

ＭＭＴＰセッションで伝達されるＵＳＢＤリスティングサービスコンポーネントに対して、記述された図面の「Ｓｅｒｖｉｃｅ＃２」に示したように、受信機は、ＳＬＳを完了するためにマッチされるＭＭＴ＿ｐａｃｋａｇｅ＿ｉｄを有するＭＰＴメッセージを取得する。ＭＰＴメッセージは、各コンポーネントに対する取得情報及びサービスを含むサービスコンポーネントの完全なリストを提供する。コンポーネント取得情報は、ＭＭＴＰセッション情報、当該セッションを伝達するＰＬＰＩＤ、当該セッション内のｐａｃｋｅｔ＿ｉｄを含む。

実施例によって、例えば、ＲＯＵＴＥの場合、２つ以上のＳ−ＴＳＩＤフラグメントが使用されてもよい。それぞれのフラグメントは、各サービスのコンテンツを伝達するＬＣＴセッションに対するアクセス情報を提供することができる。

ＲＯＵＴＥの場合、Ｓ−ＴＳＩＤ、ＵＳＢＤ／ＵＳＤ、ＭＰＤ、又はこれらを伝達するＬＣＴセッションをサービスシグナリングチャネルと呼ぶこともできる。ＭＭＴＰの場合、ＵＳＢＤ／ＵＤ、ＭＭＴシグナリングメッセージ、又はこれらを伝達するパケットフローをサービスシグナリングチャネルと呼ぶこともできる。

図示された実施例とは異なり、一つのＲＯＵＴＥ又はＭＭＴＰセッションは複数個のＰＬＰを介して伝達され得る。すなわち、一つのサービスは一つ以上のＰＬＰを介して伝達されてもよい。前述したように、一つのＬＣＴセッションは一つのＰＬＰを介して伝達され得る。図示されたものとは異なり、実施例によって、一つのサービスを構成するコンポーネントが、互いに異なるＲＯＵＴＥセッションを介して伝達されてもよい。また、実施例によって、一つのサービスを構成するコンポーネントが、互いに異なるＭＭＴＰセッションを介して伝達されてもよい。実施例によって、一つのサービスを構成するコンポーネントが、ＲＯＵＴＥセッションとＭＭＴＰセッションとに分けられて伝達されてもよい。図示してはいないが、一つのサービスを構成するコンポーネントが、ブロードバンドを介して伝達（ハイブリッドデリバリ）される場合もあり得る。

図５は、本発明の一実施例に係るＲＯＵＴＥ／ＤＡＳＨのためのＵＳＢＤフラグメントを示した図である。

以下、ＲＯＵＴＥに基づいたデリバリにおいて、サービス層シグナリングについて説明する。

ＳＬＳは、サービス及びそのコンテンツコンポーネントの発見及び接近を可能にするために、受信機に、具体的な技術的な情報を提供する。それは、専用ＬＣＴセッションで伝達されるＸＭＬコードされたメタデータフラグメントの集合を含むことができる。当該ＬＣＴセッションは、前述したように、ＳＬＴに含まれたブートストラップ情報を用いて取得することができる。ＳＬＳは、サービスレベル毎に定義され、それは、コンテンツコンポーネントのリスト、どのようにそれらを取得するのか、サービスの有意義なプレゼンテーションを行うために要求される受信機の能力のようなサービスのアクセス情報及び特徴を記述する。ＲＯＵＴＥ／ＤＡＳＨシステムにおいて、リニアサービスデリバリのために、ＳＬＳは、ＵＳＢＤ、Ｓ−ＴＳＩＤ及びＤＡＳＨＭＰＤのようなメタデータフラグメントで構成される。ＳＬＳフラグメントは、ＴＳＩ＝０である専用のＬＣＴ伝送セッションで伝達され得る。実施例によって、ＳＬＳフラグメントが伝達される特定のＬＣＴセッション（ｄｅｄｉｃａｔｅｄＬＣＴｓｅｓｓｉｏｎ）のＴＳＩは、異なる値を有してもよい。実施例によって、ＳＬＳフラグメントが伝達されるＬＣＴセッションが、ＳＬＴ又は他の方法によってシグナルされてもよい。

ＲＯＵＴＥ／ＤＡＳＨＳＬＳは、ＵＳＢＤ及びＳ−ＴＳＩＤメタデータフラグメントを含むことができる。これらのサービスシグナリングフラグメントは、リニア及びアプリケーションに基づいたサービスに適用され得る。ＵＳＢＤフラグメントは、サービス識別、装置能力情報、サービス及び構成メディアコンポーネントにアクセスするのに要求される他のＳＬＳフラグメントに対するリファレンス、受信機がサービスコンポーネントの伝送モード（ブロードキャスト及び／又はブロードバンド）を決定できるようにするメタデータを含む。ＵＳＢＤによって参照されるＳ−ＴＳＩＤフラグメントは、サービスのメディアコンテンツコンポーネントが伝達される１つ以上のＲＯＵＴＥ／ＬＣＴセッションに対する伝送セッション記述、及び当該ＬＣＴセッションで伝達されるデリバリオブジェクトの記述を提供する。ＵＳＢＤ及びＳ−ＴＳＩＤは後述する。

ＲＯＵＴＥに基づいたデリバリにおけるストリーミングコンテンツシグナリング（ＳｔｒｅａｍｉｎｇＣｏｎｔｅｎｔＳｉｇｎａｌｉｎｇ）において、ＳＬＳのストリーミングコンテンツシグナリングコンポーネントはＭＰＤフラグメントに該当する。ＭＰＤは、主にストリーミングコンテンツとしてのＤＡＳＨセグメントのデリバリのためのリニアサービスと関連する。ＭＰＤは、セグメントＵＲＬの形態のリニア／ストリーミングサービスの個別メディアコンポーネントに対するソース識別子、及びメディアプレゼンテーション内の識別されたリソースのコンテキストを提供する。ＭＰＤについての具体的な内容は後述する。

ＲＯＵＴＥに基づいたデリバリにおけるアプリベースのエンハンスメントシグナリングにおいて、アプリベースのエンハンスメントシグナリングは、アプリケーションロジックファイル、局部的にキャッシュされたメディアファイル、ネットワークコンテンツアイテム、又は公知のストリームのようなアプリベースのエンハンスメントコンポーネントのデリバリに属する。アプリケーションはまた、可能な場合、ブロードバンドコネクション上で局部的にキャッシュされたデータを検索することができる。

以下、本図に示されたＵＳＢＤ／ＵＳＤの具体的な内容について説明する。

トップレベル又はエントリポイントＳＬＳフラグメントはＵＳＢＤフラグメントである。図示されたＵＳＢＤフラグメントは、本発明の一実施例であり、図示されていない基本的なＵＳＢＤフラグメントのフィールドが実施例によってさらに追加されてもよい。前述したように、図示されたＵＳＢＤフラグメントは、拡張された形態であって、基本構造にさらに追加されたフィールドを有することができる。

図示されたＵＳＢＤは、ｂｕｎｄｌｅＤｅｓｃｒｉｐｔｉｏｎルートエレメントを有することができる。ｂｕｎｄｌｅＤｅｓｃｒｉｐｔｉｏｎルートエレメントはｕｓｅｒＳｅｒｖｉｃｅＤｅｓｃｒｉｐｔｉｏｎエレメントを有することができる。ｕｓｅｒＳｅｒｖｉｃｅＤｅｓｃｒｉｐｔｉｏｎエレメントは、一つのサービスに対するインスタンスであり得る。

ｕｓｅｒＳｅｒｖｉｃｅＤｅｓｃｒｉｐｔｉｏｎエレメントは、＠ｓｅｒｖｉｃｅＩｄ、＠ａｔｓｃ：ｓｅｒｖｉｃｅＩｄ、＠ａｔｓｃ：ｓｅｒｖｉｃｅＳｔａｔｕｓ、＠ａｔｓｃ：ｆｕｌｌＭＰＤＵｒｉ、＠ａｔｓｃ：ｓＴＳＩＤＵｒｉ、ｎａｍｅ、ｓｅｒｖｉｃｅＬａｎｇｕａｇｅ、ａｔｓｃ：ｃａｐａｂｉｌｉｔｙＣｏｄｅ及び／又はｄｅｌｉｖｅｒｙＭｅｔｈｏｄを含むことができる。

＠ｓｅｒｖｉｃｅＩｄは、ＢＳＩＤの範囲内で唯一のサービスを識別する全世界的に唯一のＵＲＩであり得る。当該パラメータは、ＥＳＧデータ（Ｓｅｒｖｉｃｅ＠ｇｌｏｂａｌＳｅｒｖｉｃｅＩＤ）とリンクするのに使用することができる。

＠ａｔｓｃ：ｓｅｒｖｉｃｅｄは、ＬＬＳ（ＳＬＴ）において該当するサービスエントリに対するリファレンスである。当該属性の値は、当該エントリに割り当てられたｓｅｒｖｉｃｅＩｄの値と同一である。

＠ａｔｓｃ：ｓｅｒｖｉｃｅＳｔａｔｕｓは、当該サービスの状態を特定することができる。その値は、当該サービスが活性化されているか、又は非活性化されているかを示す。「１」（真）に設定されると、サービスが活性化されていることを示す。このフィールドが使用されない場合、デフォルト値１に設定されてもよい。

＠ａｔｓｃ：ｆｕｌｌＭＰＤＵｒｉは、ブロードキャスト上で選択的に、また、ブロードバンド上で伝達されるサービスのコンテンツコンポーネントに対する記述を含むＭＰＤフラグメントを参照することができる。

＠ａｔｓｃ：ｓＴＳＩＤＵｒｉは、当該サービスのコンテンツを伝達する伝送セッションにアクセス関連パラメータを提供するＳ−ＴＳＩＤフラグメントを参照することができる。

ｎａｍｅは、ｌａｎｇ属性によって与えられるサービスのネームを示すことができる。ｎａｍｅエレメントは、サービスネームの言語を示すｌａｎｇ属性を含むことができる。言語は、ＸＭＬデータタイプに応じて特定することができる。

ｓｅｒｖｉｃｅＬａｎｇｕａｇｅは、サービスの利用可能な言語を示すことができる。言語は、ＸＭＬデータタイプに応じて特定することができる。

ａｔｓｃ：ｃａｐａｂｉｌｉｔｙＣｏｄｅは、受信機が当該サービスのコンテンツの有意義なプレゼンテーションを生成できるように要求される能力を特定することができる。実施例によって、本フィールドは、予め定義された能力グループを特定してもよい。ここで、能力グループは、有意義なプレゼンテーションのための能力属性値のグループであり得る。本フィールドは、実施例によって省略されてもよい。

ｄｅｌｉｖｅｒｙＭｅｔｈｏｄは、アクセスのブロードキャスト及び（選択的に）ブロードバンドモード上でサービスのコンテンツに属する情報に関連するトランスポートのコンテナであり得る。当該サービスに含まれるデータにおいて、そのデータをＮ個とすれば、そのそれぞれのデータに対するデリバリ方法が、このエレメントによって記述され得る。ｄｅｌｉｖｅｒｙＭｅｔｈｏｄエレメントは、ｒ１２：ｂｒｏａｄｃａｓｔＡｐｐＳｅｒｖｉｃｅエレメント及びｒ１２：ｕｎｉｃａｓｔＡｐｐＳｅｒｖｉｃｅエレメントを含むことができる。それぞれの下位エレメントは、ｂａｓｅＰａｔｔｅｒｎエレメントを下位エレメントとして有することができる。

ｒ１２：ｂｒｏａｄｃａｓｔＡｐｐＳｅｒｖｉｃｅは、所属のメディアプレゼンテーションの全ての期間にわたって、サービスに属する当該メディアコンポーネントを含む、多重化又は非多重化された形態のブロードキャスト上で伝達されるＤＡＳＨリプレゼンテーションであり得る。すなわち、それぞれの本フィールドは、放送網を介して伝達されるＤＡＳＨリプレゼンテーション（ｒｅｐｒｅｓｅｎｔａｔｉｏｎ）を意味し得る。

ｒ１２：ｕｎｉｃａｓｔＡｐｐＳｅｒｖｉｃｅは、所属のメディアプレゼンテーションの全ての期間にわたって、サービスに属する構成メディアコンテンツコンポーネントを含む、多重化又は非多重化された形態のブロードバンド上で伝達されるＤＡＳＨリプレゼンテーションであり得る。すなわち、それぞれの本フィールドは、ブロードバンドを介して伝達されるＤＡＳＨリプレゼンテーション（ｒｅｐｒｅｓｅｎｔａｔｉｏｎ）を意味し得る。

ｂａｓｅＰａｔｔｅｒｎは、含まれた期間にペアレントリプレゼンテーションのメディアセグメントを要求するためにＤＡＳＨクライアントによって使用されるセグメントＵＲＬの全ての部分に対してマッチされるように受信機によって使用される文字パターンであり得る。マッチは、当該要求されたメディアセグメントがブロードキャストトランスポート上で伝達されることを暗示する。それぞれのｒ１２：ｂｒｏａｄｃａｓｔＡｐｐＳｅｒｖｉｃｅエレメントとｒ１２：ｕｎｉｃａｓｔＡｐｐＳｅｒｖｉｃｅエレメントで表現されるＤＡＳＨリプレゼンテーションを受信できるＵＲＬ住所において、そのＵＲＬの一部分などは特定のパターンを有することができ、そのパターンが本フィールドによって記述され得る。この情報を通じて、一定の部分のデータに対する区分が可能である。提示されたデフォルト値は、実施例によって変更されてもよい。図示された使用（ｕｓｅ）列は各フィールドに関するもので、Ｍは必須のフィールド、Ｏはオプショナルフィールド、ＯＤは、デフォルト値を有するオプショナルフィールド、ＣＭは、条件付きの必須のフィールドを意味し得る。０．．．１〜０．．．Ｎは、当該フィールドの使用可能な個数を意味し得る。

図６は、本発明の一実施例に係るＲＯＵＴＥ／ＤＡＳＨのためのＳ−ＴＳＩＤフラグメントを示した図である。

以下、本図に示されたＳ−ＴＳＩＤの具体的な内容について説明する。

Ｓ−ＴＳＩＤは、サービスのコンテンツコンポーネントを伝達する伝送セッションに対する全体的なセッション記述情報を提供するＳＬＳＸＭＬフラグメントであり得る。Ｓ−ＴＳＩＤは、サービスのメディアコンテンツコンポーネントが伝達される構成ＬＣＴセッション、及び０個以上のＲＯＵＴＥセッションに対する全体的な伝送セッション記述情報を含む、ＳＬＳメタデータフラグメントである。Ｓ−ＴＳＩＤはまた、ＬＣＴセッションで伝達されるコンテンツコンポーネント及びペイロードフォーマットに対する追加情報だけでなく、サービスのＬＣＴセッションで伝達されるデリバリオブジェクト又はオブジェクトフローに対するファイルメタデータを含む。

Ｓ−ＴＳＩＤフラグメントの各インスタンスは、ｕｓｅｒＳｅｒｖｉｃｅＤｅｓｃｒｉｐｔｉｏｎエレメントの＠ａｔｓｃ：ｓＴＳＩＤＵｒｉ属性によってＵＳＢＤフラグメントで参照される。図示された本発明の一実施例に係るＳ−ＴＳＩＤは、ＸＭＬドキュメントの形態で表現された。実施例によって、Ｓ−ＴＳＩＤは、バイナリフォーマット又はＸＭＬドキュメントの形態で表現されてもよい。

図示されたＳ−ＴＳＩＤは、Ｓ−ＴＳＩＤルートエレメントを有することができる。Ｓ−ＴＳＩＤルートエレメントは、＠ｓｅｒｖｉｃｅＩｄ及び／又はＲＳを含むことができる。

＠ｓｅｒｖｉｃｅＩＤは、ＵＳＤでサービスエレメントに該当するリファレンスであり得る。当該属性の値は、ｓｅｒｖｉｃｅ＿ｉｄの当該値を有するサービスを参照することができる。

ＲＳエレメントは、当該サービスデータを伝達するＲＯＵＴＥセッションに関する情報を有することができる。複数個のＲＯＵＴＥセッションを介してサービスデータ乃至サービスコンポーネントを伝達できるので、本エレメントは１個〜Ｎ個の個数を有することができる。

ＲＳエレメントは、＠ｂｓｉｄ、＠ｓＩｐＡｄｄｒ、＠ｄＩｐＡｄｄｒ、＠ｄｐｏｒｔ、＠ＰＬＰＩＤ及び／又はＬＳを含むことができる。

＠ｂｓｉｄは、ｂｒｏａｄｃａｓｔＡｐｐＳｅｒｖｉｃｅのコンテンツコンポーネントが伝達されるブロードキャストストリームの識別子であり得る。当該属性が存在しない場合、デフォルトブロードキャストストリームのＰＬＰが当該サービスに対するＳＬＳフラグメントを伝達することであり得る。その値は、ＳＬＴでｂｒｏａｄｃａｓｔ＿ｓｔｒｅａｍ＿ｉｄと同一であり得る。

＠ｓＩｐＡｄｄｒは、ソースＩＰ住所を示すことができる。ここで、ソースＩＰ住所は、当該サービスに含まれるサービスコンポーネントを伝達するＲＯＵＴＥセッションのソースＩＰ住所であり得る。前述したように、一つのサービスのサービスコンポーネントは、複数個のＲＯＵＴＥセッションを介して伝達されてもよい。そのため、当該Ｓ−ＴＳＩＤが伝達されるＲＯＵＴＥセッションではない他のＲＯＵＴＥセッションでそのサービスコンポーネントが伝送されてもよい。したがって、ＲＯＵＴＥセッションのソースＩＰ住所を指示するために本フィールドが使用され得る。本フィールドのデフォルト値は、現在のＲＯＵＴＥセッションのソースＩＰ住所であり得る。他のＲＯＵＴＥセッションを介して伝達されるサービスコンポーネントがあるので、そのＲＯＵＴＥセッションを指示しなければならない場合には、本フィールド値は、そのＲＯＵＴＥセッションのソースＩＰ住所値であり得る。この場合、本フィールドはＭ、すなわち、必須のフィールドであり得る。

＠ｄＩｐＡｄｄｒは、目的地ＩＰ住所を示すことができる。ここで、目的地ＩＰ住所は、当該サービスに含まれるサービスコンポーネントを伝達するＲＯＵＴＥセッションの目的地ＩＰ住所であり得る。＠ｓＩｐＡｄｄｒで説明したような場合のために、本フィールドは、サービスコンポーネントを伝達するＲＯＵＴＥセッションの目的地ＩＰ住所を指示してもよい。本フィールドのデフォルト値は、現在のＲＯＵＴＥセッションの目的地ＩＰ住所であり得る。他のＲＯＵＴＥセッションを介して伝達されるサービスコンポーネントがあるので、そのＲＯＵＴＥセッションを指示しなければならない場合には、本フィールド値は、そのＲＯＵＴＥセッションの目的地ＩＰ住所値であり得る。この場合、本フィールドはＭ、すなわち、必須フィールドであり得る。

＠ｄｐｏｒｔは、目的地ポートを示すことができる。ここで、目的地ポートは、当該サービスに含まれるサービスコンポーネントを伝達するＲＯＵＴＥセッションの目的地ポートであり得る。＠ｓＩｐＡｄｄｒで説明したような場合のために、本フィールドは、サービスコンポーネントを伝達するＲＯＵＴＥセッションの目的地ポートを指示することができる。本フィールドのデフォルト値は、現在のＲＯＵＴＥセッションの目的地ポート番号であり得る。他のＲＯＵＴＥセッションを介して伝達されるサービスコンポーネントがあるので、そのＲＯＵＴＥセッションを指示しなければならない場合には、本フィールド値は、そのＲＯＵＴＥセッションの目的地ポート番号値であり得る。この場合、本フィールドはＭ、すなわち、必須フィールドであり得る。

＠ＰＬＰＩＤは、ＲＳで表現されるＲＯＵＴＥセッションのためのＰＬＰのＩＤであり得る。デフォルト値は、現在のＳ−ＴＳＩＤが含まれたＬＣＴセッションのＰＬＰのＩＤであり得る。実施例によって、本フィールドは、当該ＲＯＵＴＥセッションでＳ−ＴＳＩＤが伝達されるＬＣＴセッションのためのＰＬＰのＩＤ値を有してもよく、当該ＲＯＵＴＥセッションのための全てのＰＬＰのＩＤ値を有してもよい。

ＬＳエレメントは、当該サービスデータを伝達するＬＣＴセッションに関する情報を有することができる。複数個のＬＣＴセッションを介してサービスデータ乃至サービスコンポーネントを伝達できるので、本エレメントは、１個〜Ｎ個の個数を有することができる。

ＬＳエレメントは、＠ｔｓｉ、＠ＰＬＰＩＤ、＠ｂｗ、＠ｓｔａｒｔＴｉｍｅ、＠ｅｎｄＴｉｍｅ、ＳｒｃＦｌｏｗ及び／又はＲｐｒＦｌｏｗを含むことができる。

＠ｔｓｉは、当該サービスのサービスコンポーネントが伝達されるＬＣＴセッションのＴＳＩ値を指示することができる。

＠ＰＬＰＩＤは、当該ＬＣＴセッションのためのＰＬＰのＩＤ情報を有することができる。この値は、基本ＲＯＵＴＥセッション値を上書きしてもよい。

＠ｂｗは、最大の帯域値を指示することができる。＠ｓｔａｒｔＴｉｍｅは当該ＬＣＴセッションのスタートタイム（Ｓｔａｒｔｔｉｍｅ）を指示することができる。＠ｅｎｄＴｉｍｅは、当該ＬＣＴセッションのエンドタイム（Ｅｎｄｔｉｍｅ）を指示することができる。ＳｒｃＦｌｏｗエレメントは、ＲＯＵＴＥのソースフローに対して記述することができる。ＲｐｒＦｌｏｗエレメントは、ＲＯＵＴＥのリペアフローに対して記述することができる。

提示されたデフォルト値は、実施例によって変更されてもよい。図示された使用（ｕｓｅ）列は、各フィールドに関するもので、Ｍは必須フィールド、Ｏはオプショナルフィールド、ＯＤは、デフォルト値を有するオプショナルフィールド、ＣＭは、条件付きの必須のフィールドを意味し得る。０．．．１〜０．．．Ｎは、当該フィールドの使用可能な個数を意味し得る。

以下、ＲＯＵＴＥ／ＤＡＳＨのためのＭＰＤ（ＭｅｄｉａＰｒｅｓｅｎｔａｔｉｏｎＤｅｓｃｒｉｐｔｉｏｎ）について説明する。

ＭＰＤは、放送会社によって定められた与えられたデューレーションのリニアサービスに該当するＤＡＳＨメディアプレゼンテーションの公式化された記述を含むＳＬＳメタデータフラグメントである（例えば、ある期間の間の一つのＴＶプログラム又は連続的なリニアＴＶプログラムの集合）。ＭＰＤのコンテンツは、メディアプレゼンテーション内で識別されたリソースに対するコンテキスト及びセグメントに対するソース識別子を提供する。ＭＰＤフラグメントのデータ構造及びセマンティクスは、ＭＰＥＧＤＡＳＨによって定義されたＭＰＤに従うことができる。

ＭＰＤで伝達される１つ以上のＤＡＳＨリプレゼンテーションは、ブロードキャスト上で伝達され得る。ＭＰＤは、ハイブリッドサービスの場合のようなブロードバンド上で伝達される追加リプレゼンテーションを記述したり、ブロードキャスト信号悪化（例えば、トンネルの中の走行）によるブロードキャストからブロードキャストへのハンドオフでサービス連続性を支援したりすることができる。

図７は、本発明の一実施例に係るＭＭＴのためのＵＳＢＤ／ＵＳＤフラグメントを示した図である。

リニアサービスのためのＭＭＴＳＬＳは、ＵＳＢＤフラグメント及びＭＰテーブルを含む。ＭＰテーブルは、前述した通りである。ＵＳＢＤフラグメントは、サービス識別、装置能力情報、サービス及び構成メディアコンポーネントにアクセスするのに要求される他のＳＬＳ情報に対するリファレンス、及び受信機がサービスコンポーネントの伝送モード（ブロードキャスト及び／又はブロードバンド）を決定できるようにするメタデータを含む。ＵＳＢＤによって参照されるＭＰＵコンポーネントに対するＭＰテーブルは、サービスのメディアコンテンツコンポーネントが伝達されるＭＭＴＰセッションに対する伝送セッション記述、及びＭＭＴＰセッションで伝達されるアセットの記述を提供する。

ＭＰＵコンポーネントに対するＳＬＳのストリーミングコンテンツシグナリングコンポーネントは、ＭＭＴで定義されたＭＰテーブルに該当する。ＭＰテーブルは、各アセットが単一のサービスコンポーネントに該当するＭＭＴアセットのリスト、及び当該コンポーネントに対する位置情報の記述を提供する。

ＵＳＢＤフラグメントは、ＲＯＵＴＥプロトコル及びブロードバンドによってそれぞれ伝達されるサービスコンポーネントに対して、前述したようなＳ−ＴＳＩＤ及びＭＰＤに対するリファレンスも含むことができる。実施例によって、ＭＭＴを通じたデリバリにおいて、ＲＯＵＴＥプロトコルを介して伝達されるサービスコンポーネントはＮＲＴなどのデータであるので、この場合において、ＭＰＤは用いられなくてもよい。また、ＭＭＴを通じたデリバリにおいて、ブロードバンドを介して伝達されるサービスコンポーネントはどのＬＣＴセッションを介して伝達されるかに対する情報が必要でないので、Ｓ−ＴＳＩＤは用いられなくてもよい。ここで、ＭＭＴパッケージは、ＭＭＴを用いて伝達される、メディアデータの論理的コレクションであり得る。ここで、ＭＭＴＰパケットは、ＭＭＴを用いて伝達されるメディアデータのフォーマットされたユニットを意味し得る。ＭＰＵ（ＭｅｄｉａＰｒｏｃｅｓｓｉｎｇＵｎｉｔ）は、独立してデコーディング可能なタイムド／ノン−タイムドデータのジェネリックコンテナを意味し得る。ここで、ＭＰＵでのデータはメディアコーデックアグノスティックである。

図示されたＵＳＢＤフラグメントは、本発明の一実施例であり、図示されていない基本的なＵＳＢＤフラグメントのフィールドが実施例によってさらに追加されてもよい。前述したように、図示されたＵＳＢＤフラグメントは、拡張された形態であって、基本構造にさらに追加されたフィールドを有することができる。

図示された本発明の一実施例に係るＵＳＢＤは、ＸＭＬドキュメントの形態で表現された。実施例によって、ＵＳＢＤは、バイナリフォーマット又はＸＭＬドキュメントの形態で表現されてもよい。

図示されたＵＳＢＤは、ｂｕｎｄｌｅＤｅｓｃｒｉｐｔｉｏｎルートエレメントを有することができる。ｂｕｎｄｌｅＤｅｓｃｒｉｐｔｉｏｎルートエレメントはｕｓｅｒＳｅｒｖｉｃｅＤｅｓｃｒｉｐｔｉｏｎエレメントを有することができる。ｕｓｅｒＳｅｒｖｉｃｅＤｅｓｃｒｉｐｔｉｏｎエレメントは、１つのサービスに対するインスタンスであり得る。

ｕｓｅｒＳｅｒｖｉｃｅＤｅｓｃｒｉｐｔｉｏｎエレメントは、＠ｓｅｒｖｉｃｅＩｄ、＠ａｔｓｃ：ｓｅｒｖｉｃｅＩｄ、ｎａｍｅ、ｓｅｒｖｉｃｅＬａｎｇｕａｇｅ、ａｔｓｃ：ｃａｐａｂｉｌｉｔｙＣｏｄｅ、ａｔｓｃ：Ｃｈａｎｎｅｌ、ａｔｓｃ：ｍｐｕＣｏｍｐｏｎｅｎｔ、ａｔｓｃ：ｒｏｕｔｅＣｏｍｐｏｎｅｎｔ、ａｔｓｃ：ｂｒｏａｄｂａｎｄＣｏｍｐｏｎｅｎｔ及び／又はａｔｓｃ：ＣｏｍｐｏｎｅｎｔＩｎｆｏを含むことができる。

ここで、＠ｓｅｒｖｉｃｅＩｄ、＠ａｔｓｃ：ｓｅｒｖｉｃｅＩｄ、ｎａｍｅ、ｓｅｒｖｉｃｅＬａｎｇｕａｇｅ、ａｔｓｃ：ｃａｐａｂｉｌｉｔｙＣｏｄｅは、前述したものと同一であり得る。ｎａｍｅフィールドの下のｌａｎｇフィールドも、前述したものと同一であり得る。ａｔｓｃ：ｃａｐａｂｉｌｉｔｙＣｏｄｅは、実施例によって省略されてもよい。

ｕｓｅｒＳｅｒｖｉｃｅＤｅｓｃｒｉｐｔｉｏｎエレメントは、実施例によってａｔｓｃ：ｃｏｎｔｅｎｔＡｄｖｉｓｏｒｙＲａｔｉｎｇエレメントをさらに含むことができる。このエレメントはオプショナルエレメントであり得る。ａｔｓｃ：ｃｏｎｔｅｎｔＡｄｖｉｓｏｒｙＲａｔｉｎｇは、コンテンツ諮問順位を特定することができる。本フィールドは図示していない。

ａｔｓｃ：Ｃｈａｎｎｅｌは、サービスのチャネルに対する情報を有することができる。ａｔｓｃ：Ｃｈａｎｎｅｌエレメントは、＠ａｔｓｃ：ｍａｊｏｒＣｈａｎｎｅｌＮｏ、＠ａｔｓｃ：ｍｉｎｏｒＣｈａｎｎｅｌＮｏ、＠ａｔｓｃ：ｓｅｒｖｉｃｅＬａｎｇ、＠ａｔｓｃ：ｓｅｒｖｉｃｅＧｅｎｒｅ、＠ａｔｓｃ：ｓｅｒｖｉｃｅＩｃｏｎ及び／又はａｔｓｃ：ＳｅｒｖｉｃｅＤｅｓｃｒｉｐｔｉｏｎを含むことができる。＠ａｔｓｃ：ｍａｊｏｒＣｈａｎｎｅｌＮｏ、＠ａｔｓｃ：ｍｉｎｏｒＣｈａｎｎｅｌＮｏ、＠ａｔｓｃ：ｓｅｒｖｉｃｅＬａｎｇは、実施例によって省略されてもよい。

＠ａｔｓｃ：ｍａｊｏｒＣｈａｎｎｅｌＮｏは、サービスの主チャネル番号を示す属性である。

＠ａｔｓｃ：ｍｉｎｏｒＣｈａｎｎｅｌＮｏは、サービスの副チャネル番号を示す属性である。

＠ａｔｓｃ：ｓｅｒｖｉｃｅＬａｎｇは、サービスで使用される主要言語を示す属性である。

＠ａｔｓｃ：ｓｅｒｖｉｃｅＧｅｎｒｅは、サービスの主要ジャンルを示す属性である。

＠ａｔｓｃ：ｓｅｒｖｉｃｅＩｃｏｎは、当該サービスを表現するために使用されるアイコンに対するＵＲＬを示す属性である。

ａｔｓｃ：ＳｅｒｖｉｃｅＤｅｓｃｒｉｐｔｉｏｎは、サービス記述を含み、これは多重言語であってもよい。ａｔｓｃ：ＳｅｒｖｉｃｅＤｅｓｃｒｉｐｔｉｏｎは、＠ａｔｓｃ：ｓｅｒｖｉｃｅＤｅｓｃｒＴｅｘｔ及び／又は＠ａｔｓｃ：ｓｅｒｖｉｃｅＤｅｓｃｒＬａｎｇを含むことができる。

＠ａｔｓｃ：ｓｅｒｖｉｃｅＤｅｓｃｒＴｅｘｔは、サービスの記述を示す属性である。

＠ａｔｓｃ：ｓｅｒｖｉｃｅＤｅｓｃｒＬａｎｇは、前記ｓｅｒｖｉｃｅＤｅｓｃｒＴｅｘｔ属性の言語を示す属性である。

ａｔｓｃ：ｍｐｕＣｏｍｐｏｎｅｎｔは、ＭＰＵの形態で伝達されるサービスのコンテンツコンポーネントに対する情報を有することができる。ａｔｓｃ：ｍｐｕＣｏｍｐｏｎｅｎｔは、＠ａｔｓｃ：ｍｍｔＰａｃｋａｇｅＩｄ及び／又は＠ａｔｓｃ：ｎｅｘｔＭｍｔＰａｃｋａｇｅＩｄを含むことができる。

＠ａｔｓｃ：ｍｍｔＰａｃｋａｇｅＩｄは、ＭＰＵとして伝達されるサービスのコンテンツコンポーネントに対するＭＭＴパッケージを参照することができる。

＠ａｔｓｃ：ｎｅｘｔＭｍｔＰａｃｋａｇｅＩｄは、ＭＰＵとして伝達されるサービスのコンテンツコンポーネントに合わせて＠ａｔｓｃ：ｍｍｔＰａｃｋａｇｅＩｄによって参照された後に使用されるＭＭＴパッケージを参照することができる。

ａｔｓｃ：ｒｏｕｔｅＣｏｍｐｏｎｅｎｔは、ＲＯＵＴＥを介して伝達されるサービスのコンテンツコンポーネントに対する情報を有することができる。ａｔｓｃ：ｒｏｕｔｅＣｏｍｐｏｎｅｎｔは、＠ａｔｓｃ：ｓＴＳＩＤＵｒｉ、＠ｓＴＳＩＤＰｌｐＩｄ、＠ｓＴＳＩＤＤｅｓｔｉｎａｔｉｏｎＩｐＡｄｄｒｅｓｓ、＠ｓＴＳＩＤＤｅｓｔｉｎａｔｉｏｎＵｄｐＰｏｒｔ、＠ｓＴＳＩＤＳｏｕｒｃｅＩｐＡｄｄｒｅｓｓ、＠ｓＴＳＩＤＭａｊｏｒＰｒｏｔｏｃｏｌＶｅｒｓｉｏｎ及び／又は＠ｓＴＳＩＤＭｉｎｏｒＰｒｏｔｏｃｏｌＶｅｒｓｉｏｎを含むことができる。

＠ａｔｓｃ：ｓＴＳＩＤＵｒｉは、当該サービスのコンテンツを伝達する伝送セッションにアクセス関連パラメータを提供するＳ−ＴＳＩＤフラグメントを参照することができる。このフィールドは、前述したＲＯＵＴＥのためのＵＳＢＤでのＳ−ＴＳＩＤを参照するためのＵＲＩと同一であり得る。前述したように、ＭＭＴＰによるサービスデリバリにおいても、ＮＲＴなどを介して伝達されるサービスコンポーネントはＲＯＵＴＥによって伝達され得る。そのためのＳ−ＴＳＩＤを参照するために、本フィールドが使用され得る。

＠ｓＴＳＩＤＰｌｐＩｄは、当該サービスに対するＳ−ＴＳＩＤを伝達するＰＬＰのＰＬＰＩＤを示す整数を表現するストリングであり得る。（デフォルト：現在のＰＬＰ）

＠ｓＴＳＩＤＤｅｓｔｉｎａｔｉｏｎＩｐＡｄｄｒｅｓｓは、当該サービスに対するＳ−ＴＳＩＤを伝達するパケットのｄｏｔｔｅｄ−ＩＰｖ４目的地住所を含むストリングであり得る。（デフォルト：現在のＭＭＴＰセッションのソースＩＰ住所）

＠ｓＴＳＩＤＤｅｓｔｉｎａｔｉｏｎＵｄｐＰｏｒｔは、当該サービスに対するＳ−ＴＳＩＤを伝達するパケットのポート番号を含むストリングであり得る。

＠ｓＴＳＩＤＳｏｕｒｃｅＩｐＡｄｄｒｅｓｓは、当該サービスに対するＳ−ＴＳＩＤを伝達するパケットのｄｏｔｔｅｄ−ＩＰｖ４ソース住所を含むストリングであり得る。

＠ｓＴＳＩＤＭａｊｏｒＰｒｏｔｏｃｏｌＶｅｒｓｉｏｎは、当該サービスに対するＳ−ＴＳＩＤを伝達するために使用されるプロトコルの主バージョン番号を示すことができる。デフォルト値は１である。

＠ｓＴＳＩＤＭｉｎｏｒＰｒｏｔｏｃｏｌＶｅｒｓｉｏｎは、当該サービスに対するＳ−ＴＳＩＤを伝達するために使用されるプロトコルの副バージョン番号を示すことができる。デフォルト値は０である。

ａｔｓｃ：ｂｒｏａｄｂａｎｄＣｏｍｐｏｎｅｎｔは、ブロードバンドを介して伝達されるサービスのコンテンツコンポーネントに対する情報を有することができる。すなわち、ハイブリッドデリバリを想定したフィールドであり得る。ａｔｓｃ：ｂｒｏａｄｂａｎｄＣｏｍｐｏｎｅｎｔは、＠ａｔｓｃ：ｆｕｌｌｆＭＰＤＵｒｉをさらに含むことができる。

＠ａｔｓｃ：ｆｕｌｌｆＭＰＤＵｒｉは、ブロードバンドで伝達されるサービスのコンテンツコンポーネントに対する記述を含むＭＰＤフラグメントに対するリファレンスであり得る。

ａｔｓｃ：ＣｏｍｐｏｎｅｎｔＩｎｆｏは、サービスのアベイラブルな（ａｖａｉｌａｂｌｅ）コンポーネントに対する情報を有することができる。それぞれのコンポーネントに対する、タイプ、ロール、名などの情報を有することができる。各コンポーネント（Ｎ個）の数だけ本フィールドが存在することができる。ａｔｓｃ：ＣｏｍｐｏｎｅｎｔＩｎｆｏは、＠ａｔｓｃ：ｃｏｍｐｏｎｅｎｔＴｙｐｅ、＠ａｔｓｃ：ｃｏｍｐｏｎｅｎｔＲｏｌｅ、＠ａｔｓｃ：ｃｏｍｐｏｎｅｎｔＰｒｏｔｅｃｔｅｄＦｌａｇ、＠ａｔｓｃ：ｃｏｍｐｏｎｅｎｔＩｄ及び／又は＠ａｔｓｃ：ｃｏｍｐｏｎｅｎｔＮａｍｅを含むことができる。

＠ａｔｓｃ：ｃｏｍｐｏｎｅｎｔＴｙｐｅは、当該コンポーネントのタイプを示す属性である。０の値はオーディオコンポーネントを示す。１の値はビデオコンポーネントを示す。２の値はクローズドキャプションコンポーネントを示す。３の値はアプリケーションコンポーネントを示す。４〜７の値は残す。本フィールド値の意味は、実施例によって異なって設定されてもよい。

＠ａｔｓｃ：ｃｏｍｐｏｎｅｎｔＲｏｌｅは、当該コンポーネントの役割及び種類を示す属性である。

オーディオに対して（前記ｃｏｍｐｏｎｅｎｔＴｙｐｅ属性が０と同一であるとき）、ｃｏｍｐｏｎｅｎｔＲｏｌｅ属性の値は、次の通りである。０＝Ｃｏｍｐｌｅｔｅｍａｉｎ、１＝音楽及び効果（ＭｕｓｉｃａｎｄＥｆｆｅｃｔｓ）、２＝対話（Ｄｉａｌｏｇ）、３＝解説（Ｃｏｍｍｅｎｔａｒｙ）、４＝視覚障害（ＶｉｓｕａｌｌｙＩｍｐａｉｒｅｄ）、５＝聴覚障害（ＨｅａｒｉｎｇＩｍｐａｉｒｅｄ）、６＝ボイスオーバー（Ｖｏｉｃｅ−Ｏｖｅｒ）、７−２５４＝ｒｅｓｅｒｖｅｄ、２５５＝未知（ｕｎｋｎｏｗｎ）。

オーディオに対して（前記ｃｏｍｐｏｎｅｎｔＴｙｐｅ属性が１と同一であるとき）、ｃｏｍｐｏｎｅｎｔＲｏｌｅ属性の値は、次の通りである。０＝プライマリビデオ（Ｐｒｉｍａｒｙｖｉｄｅｏ）、１＝代替カメラビュー（Ａｌｔｅｒｎａｔｉｖｅｃａｍｅｒａｖｉｅｗ）、２＝他の代替ビデオコンポーネント（Ｏｔｈｅｒａｌｔｅｒｎａｔｉｖｅｖｉｄｅｏｃｏｍｐｏｎｅｎｔ）、３＝手話挿入（Ｓｉｇｎｌａｎｇｕａｇｅｉｎｓｅｔ）、４＝フォローサブジェクトビデオ（Ｆｏｌｌｏｗｓｕｂｊｅｃｔｖｉｄｅｏ）、５＝３Ｄビデオの左側ビュー（３Ｄｖｉｄｅｏｌｅｆｔｖｉｅｗ）、６＝３Ｄビデオの右側ビュー（３Ｄｖｉｄｅｏｒｉｇｈｔｖｉｅｗ）、７＝３Ｄビデオの深さ情報（３Ｄｖｉｄｅｏｄｅｐｔｈｉｎｆｏｒｍａｔｉｏｎ）、８＝ビデオアレイの部分（Ｐａｒｔｏｆｖｉｄｅｏａｒｒａｙ）＜ｘ，ｙ＞ｏｆ＜ｎ，ｍ＞、９＝フォローサブジェクトメタデータ（Ｆｏｌｌｏｗ−Ｓｕｂｊｅｃｔｍｅｔａｄａｔａ）、１０−２５４＝ｒｅｓｅｒｖｅｄ、２５５＝ｕｎｋｎｏｗｎ。

クローズドキャプションコンポーネントに対して（前記ｃｏｍｐｏｎｅｎｔＴｙｐｅ属性が２と同一であるとき）、ｃｏｍｐｏｎｅｎｔＲｏｌｅ属性の値は、次の通りである。０＝正常（Ｎｏｒｍａｌ）、１＝イージーリーダー（Ｅａｓｙｒｅａｄｅｒ）、２−２５４＝ｒｅｓｅｒｖｅｄ、２５５＝ｕｎｋｎｏｗｎ。

前記ｃｏｍｐｏｎｅｎｔＴｙｐｅ属性の値が３と７との間であれば、ｃｏｍｐｏｎｅｎｔＲｏｌｅ２５５と同一であり得る。本フィールド値の意味は、実施例によって異なって設定されてもよい。

＠ａｔｓｃ：ｃｏｍｐｏｎｅｎｔＰｒｏｔｅｃｔｅｄＦｌａｇは、当該コンポーネントが保護されるか（例えば、暗号化されるか）を示す属性である。当該フラグが１の値に設定されると、当該コンポーネントは保護される（例えば、暗号化される）。当該フラグが０の値に設定されると、当該コンポーネントは保護されない（例えば、暗号化されない）。存在しない場合、ｃｏｍｐｏｎｅｎｔＰｒｏｔｅｃｔｅｄＦｌａｇ属性の値は０と同一であると推論される。本フィールド値の意味は、実施例によって異なって設定されてもよい。

＠ａｔｓｃ：ｃｏｍｐｏｎｅｎｔＩｄは、当該コンポーネントの識別子を示す属性である。当該属性の値は、当該コンポーネントに該当するＭＰテーブルにおいてａｓｓｅｔ＿ｉｄと同一であり得る。

＠ａｔｓｃ：ｃｏｍｐｏｎｅｎｔＮａｍｅは、当該コンポーネントの人が読み取り可能な名を示す属性である。

提示されたデフォルト値は、実施例によって変更されてもよい。図示された使用（ｕｓｅ）列は、各フィールドに関するもので、Ｍは必須のフィールド、Ｏはオプショナルフィールド、ＯＤは、デフォルト値を有するオプショナルフィールド、ＣＭは、条件付きの必須のフィールドを意味し得る。０．．．１〜０．．．Ｎは、当該フィールドの使用可能な個数を意味し得る。

以下、ＭＭＴのためのＭＰＤ（ＭｅｄｉａＰｒｅｓｅｎｔａｔｉｏｎＤｅｓｃｒｉｐｔｉｏｎ）について説明する。

ＭＰＤは、放送会社によって定められた与えられたデューレーションのリニアサービスに該当するＳＬＳメタデータフラグメントである（例えば、一つのＴＶプログラム、又はある期間の間の連続的なリニアＴＶプログラムの集合）。ＭＰＤのコンテンツは、セグメントに対するリソース識別子、及びメディアプレゼンテーション内で識別されたリソースに対するコンテキストを提供する。ＭＰＤのデータ構造及びセマンティクスは、ＭＰＥＧＤＡＳＨによって定義されたＭＰＤに従うことができる。

本発明の実施例において、ＭＭＴＰセッションによって伝達されるＭＰＤは、ハイブリッドサービスの場合のようなブロードバンド上で伝達されるリプレゼンテーションを記述したり、ブロードキャスト信号悪化（例えば、山の下やトンネルの中の走行）によるブロードキャストからブロードキャストへのハンドオフでサービス連続性を支援したりすることができる。

以下、ＭＭＴのためのＭＭＴシグナリングメッセージについて説明する。

ＭＭＴＰセッションがストリーミングサービスを伝達するために使用される場合、ＭＭＴによって定義されたＭＭＴシグナリングメッセージは、ＭＭＴによって定義されたシグナリングメッセージモードに応じてＭＭＴＰパケットによって伝達される。アセットを伝達するＭＭＴＰパケットと同一のｐａｃｋｅｔ＿ｉｄ値に設定され得る、アセットに特定のＭＭＴシグナリングメッセージを伝達するＭＭＴＰパケットを除いて、ＳＬＳを伝達するＭＭＴＰパケットのｐａｃｋｅｔ＿ｉｄフィールドの値は「００」に設定される。各サービスに対する適切なパケットを参照する識別子は、前述したように、ＵＳＢＤフラグメントによってシグナルされる。マッチするＭＭＴ＿ｐａｃｋａｇｅ＿ｉｄを有するＭＰＴメッセージは、ＳＬＴでシグナルされるＭＭＴＰセッション上で伝達され得る。各ＭＭＴＰセッションは、そのセッションに特定のＭＭＴシグナリングメッセージ、又はＭＭＴＰセッションによって伝達される各アセットを伝達する。

すなわち、ＳＬＴで特定のサービスに対するＳＬＳを有するパケットのＩＰ目的地住所／ポート番号などを特定して、ＭＭＴＰセッションのＵＳＢＤに接近することができる。前述したように、ＳＬＳを運搬するＭＭＴＰパケットのパケットＩＤは、００などの特定の値として指定できる。ＵＳＢＤの前述したパッケージＩＤ情報を用いて、マッチされるパッケージＩＤを有するＭＰＴメッセージに接近することができる。ＭＰＴメッセージは、後述するように、各サービスコンポーネント／アセットに接近するために使用することができる。

次のＭＭＴＰメッセージは、ＳＬＴでシグナルされるＭＭＴＰセッションによって伝達され得る。

ＭＰＴメッセージ：このメッセージは、全てのアセットのリスト及びＭＭＴによって定義されたようなそれらの位置情報を含む、ＭＰテーブルを伝達する。アセットがＭＰテーブルを伝達する現ＰＬＰと異なるＰＬＰによって伝達されると、当該アセットを伝達するＰＬＰの識別子は、ＰＬＰ識別子ディスクリプタを使用したＭＰテーブルで提供され得る。ＰＬＰ識別子ディスクリプタについては後述する。

ＭＭＴＡＴＳＣ３（ＭＡ３）ｍｅｓｓａｇｅｍｍｔ＿ａｔｓｃ３＿ｍｅｓｓａｇｅ（）：このメッセージは、前述したように、ＳＬＳを含むサービスに特定のシステムメタデータを伝達する。ｍｍｔ＿ａｔｓｃ３＿ｍｅｓｓａｇｅ（）については後述する。

次のＭＭＴＰメッセージは、必要であれば、ＳＬＴでシグナルされたＭＭＴＰセッションによって伝達されてもよい。

ＭＰＩメッセージ：このメッセージは、プレゼンテーション情報の全てのドキュメント又は一部のドキュメントを含む、ＭＰＩテーブルを伝達する。ＭＰＩテーブルと関連するＭＰテーブルは、このメッセージによって伝達され得る。

ＣＲＩ（ｃｌｏｃｋｒｅｌａｔｉｏｎｉｎｆｏｒｍａｔｉｏｎ）メッセージ：このメッセージは、ＮＴＰタイムスタンプとＭＰＥＧ−２ＳＴＣとの間のマッピングのためのクロック関連情報を含むＣＲＩテーブルを伝達する。実施例によって、ＣＲＩメッセージは当該ＭＭＴＰセッションを介して伝達されなくてもよい。

次のＭＭＴＰメッセージは、ストリーミングコンテンツを伝達する各ＭＭＴＰセッションによって伝達され得る。

仮想的な受信機バッファモデルメッセージ：このメッセージは、バッファを管理するために受信機によって要求される情報を伝達する。

仮想的な受信機バッファモデル除去メッセージ：このメッセージは、ＭＭＴデカプセル化バッファを管理するために受信機によって要求される情報を伝達する。

以下、ＭＭＴシグナリングメッセージのうち１つであるｍｍｔ＿ａｔｓｃ３＿ｍｅｓｓａｇｅ（）について説明する。ＭＭＴシグナリングメッセージであるｍｍｔ＿ａｔｓｃ３＿ｍｅｓｓａｇｅ（）は、前述した本発明によって、サービスに特定の情報を伝達するために定義される。本シグナリングメッセージは、ＭＭＴシグナリングメッセージの基本的なフィールドであるメッセージＩＤ、バージョン及び／又は長さ（ｌｅｎｇｔｈ）フィールドを含むことができる。本シグナリングメッセージのペイロードには、サービスＩＤ情報、コンテンツタイプ、コンテンツバージョン、コンテンツ圧縮情報及び／又はＵＲＩ情報が含まれてもよい。コンテンツタイプ情報は、本シグナリングメッセージのペイロードに含まれるデータのタイプを示すことができる。コンテンツバージョン情報は、ペイロードに含まれるデータのバージョンを、コンテンツ圧縮情報は、当該データに適用された圧縮タイプを示すことができる。ＵＲＩ情報は、本メッセージによって伝達されるコンテンツと関連するＵＲＩ情報を有することができる。

以下、ＰＬＰ識別子ディスクリプタについて説明する。

ＰＬＰ識別子ディスクリプタは、前述したＭＰテーブルのディスクリプタのうち１つとして使用できるディスクリプタである。ＰＬＰ識別子ディスクリプタは、アセットを伝達するＰＬＰに関する情報を提供する。アセットが、ＭＰテーブルを伝達する現在のＰＬＰと異なるＰＬＰによって伝達されると、ＰＬＰ識別子ディスクリプタは、そのアセットを伝達するＰＬＰを識別するために、関連するＭＰテーブルでアセットディスクリプタとして使用され得る。ＰＬＰ識別子ディスクリプタは、ＰＬＰＩＤ情報以外にＢＳＩＤ情報をさらに含むこともできる。ＢＳＩＤは、このディスクリプタによって記述されるＡｓｓｅｔのためのＭＭＴＰパケットを伝達するブロードキャストストリームのＩＤであり得る。

図８は、本発明の一実施例に係るリンク層プロトコルアーキテクチャを示した図である。

以下、リンク層（ＬｉｎｋＬａｙｅｒ）について説明する。

リンク層は、物理層とネットワーク層との間の層であり、送信側では、ネットワーク層から物理層にデータを伝送し、受信側では、物理層からネットワーク層にデータを伝送する。リンク層の目的は、物理層による処理のために全ての入力パケットタイプを一つのフォーマットで要約すること、まだ定義されていない入力タイプに対する柔軟性、及び将来の拡張可能性を保障することである。また、リンク層内で処理すれば、例えば、入力パケットのヘッダーにある不必要な情報を圧縮するのにオプションを提供することによって、入力データを効率的に伝送できるように保障する。カプセル化、圧縮などの動作はリンク層プロトコルと呼ばれ、当該プロトコルを用いて生成されたパケットはリンク層パケットと呼ばれる。リンク層は、パケットカプセル化（ｐａｃｋｅｔｅｎｃａｐｓｕｌａｔｉｏｎ）、オーバーヘッド削減（ＯｖｅｒｈｅａｄＲｅｄｕｃｔｉｏｎ）及び／又はシグナリング伝送（ＳｉｇｎａｌｉｎｇＴｒａｎｓｍｉｓｓｉｏｎ）などの機能を行うことができる。

以下、パケットカプセル化について説明する。リンク層プロトコルは、ＩＰパケット及びＭＰＥＧ−２ＴＳのようなものを含む全てのタイプのパケットのカプセル化を可能にする。リンク層プロトコルを用いて、物理層は、ネットワーク層プロトコルタイプと独立して一つのパケットフォーマットのみを処理すればよい（ここで、ネットワーク層パケットの一種としてＭＰＥＧ−２ＴＳパケットを考慮）。各ネットワーク層パケット又は入力パケットは、ジェネリックリンク層パケットのペイロードに変形する。追加的に、入力パケットのサイズが特に小さいか又は大きい場合、物理層リソースを効率的に用いるために、連鎖及び分割を行うことができる。

前述したように、パケットカプセル化過程で分割（ｓｅｇｍｅｎｔａｔｉｏｎ）を活用することができる。ネットワーク層パケットが大きすぎるため、物理層で容易に処理できない場合、ネットワーク層パケットは２つ以上のセグメントに分けられる。リンク層パケットヘッダーは、送信側で分割を行い、受信側で再結合を行うために、プロトコルフィールドを含む。ネットワーク層パケットが分割される場合、各セグメントは、ネットワーク層パケットでの元の位置と同一の順序でリンク層パケットにカプセル化されてもよい。また、ネットワーク層パケットのセグメントを含む各リンク層パケットは、結果的に物理層に伝送されてもよい。

前述したように、パケットカプセル化過程で連鎖（ｃｏｎｃａｔｅｎａｔｉｏｎ）も活用することができる。リンク層パケットのペイロードが多数のネットワーク層パケットを含む程度にネットワーク層パケットが十分に小さい場合、リンク層パケットヘッダーは、連鎖を行うためにプロトコルフィールドを含む。連鎖は、多数の小さい大きさのネットワーク層パケットを一つのペイロードに結合したものである。ネットワーク層パケットが連鎖すれば、各ネットワーク層パケットは、元の入力順序と同一の順序でリンク層パケットのペイロードに連鎖することができる。また、リンク層パケットのペイロードを構成する各パケットは、パケットのセグメントではない全体のパケットであり得る。

以下、オーバーヘッド削減について説明する。リンク層プロトコルの使用により、物理層上でデータの伝送に対するオーバーヘッドを大きく減少させることができる。本発明に係るリンク層プロトコルは、ＩＰオーバーヘッド削減及び／又はＭＰＥＧ−２ＴＳオーバーヘッド削減を提供することができる。ＩＰオーバーヘッド削減において、ＩＰパケットは、固定されたヘッダーフォーマットを有しているが、通信環境で必要な一部の情報はブロードキャスト環境で不要なことがある。リンク層プロトコルは、ＩＰパケットのヘッダーを圧縮することによってブロードキャストオーバーヘッドを削減するメカニズムを提供する。ＭＰＥＧ−２ＴＳオーバーヘッド削減において、リンク層プロトコルは、シンクバイト除去、ヌルパケット削除及び／又は共通ヘッダー除去（圧縮）を提供する。まず、シンクバイト除去は、ＴＳパケット当たり１バイトのオーバーヘッド削減を提供し、次に、ヌルパケット削除メカニズムは、受信機で再挿入できる方式で１８８バイトのヌルＴＳパケットを除去する。最後に、共通ヘッダー除去メカニズムが提供される。

シグナリング伝送に対して、リンク層プロトコルは、シグナリングパケットのための特定のフォーマットが、リンク層シグナリングを伝送するために提供され得る。これについては後述する。

図示された本発明の一実施例に係るリンク層プロトコルアーキテクチャにおいて、リンク層プロトコルは、入力パケットとして、ＩＰｖ４、ＭＰＥＧ−２ＴＳなどのような入力ネットワーク層パケットを取る。将来の拡張は、他のパケットタイプとリンク層で入力され得るプロトコルを示す。リンク層プロトコルは、物理層で特定のチャネルに対するマッピングに関する情報を含む全てのリンク層シグナリングに対するシグナリング及びフォーマットを特定する。図面は、ＡＬＰがどのように様々なヘッダー圧縮及び削除アルゴリズムを介して伝送効率を向上させるためにメカニズムを含むかを示す。また、リンク層プロトコルは、基本的に入力パケットをカプセル化することができる。

図９は、本発明の一実施例に係るリンク層パケットのベースヘッダー構造を示した図である。以下、ヘッダーの構造について説明する。

リンク層パケットは、データペイロードが後続するヘッダーを含むことができる。リンク層パケットのヘッダーは、ベースヘッダーを含むことができ、ベースヘッダーのコントロールフィールドに応じて追加ヘッダーを含むことができる。オプショナルヘッダーの存在は、追加ヘッダーのフラグフィールドから指示される。実施例によって、追加ヘッダー、オプショナルヘッダーの存在を示すフィールドはベースヘッダーに位置してもよい。

以下、ベースヘッダーの構造について説明する。リンク層パケットカプセル化に対するベースヘッダーは階層構造を有する。ベースヘッダーは、２バイトの長さを有することができ、リンク層パケットヘッダーの最小長さである。

図示された本発明の一実施例に係るベースヘッダーは、Ｐａｃｋｅｔ＿Ｔｙｐｅフィールド、ＰＣフィールド及び／又は長さ（ｌｅｎｇｔｈ）フィールドを含むことができる。実施例によって、ベースヘッダーは、ＨＭフィールド又はＳ／Ｃフィールドをさらに含むことができる。

Ｐａｃｋｅｔ＿Ｔｙｐｅフィールドは、リンク層パケットへのカプセル化の前の入力データのパケットタイプ又は元のプロトコルを示す、３ビットのフィールドである。ＩＰｖ４パケット、圧縮されたＩＰパケット（ｃｏｍｐｒｅｓｓｅｄＩＰｐａｃｋｅｔ）、リンク層シグナリングパケット、及びその他のタイプのパケットが、このようなベースヘッダーの構造を有し、カプセル化されてもよい。ただし、実施例によって、ＭＰＥＧ−２ＴＳパケットは、これとは異なる特別な構造を有し、カプセル化されてもよい。Ｐａｃｋｅｔ＿Ｔｙｐｅの値が「０００」、「００１」、「１００」又は「１１１」であると、ＡＬＰパケットの元のデータタイプは、ＩＰｖ４パケット、圧縮ＩＰパケット、リンク層シグナリング又は拡張パケットのうち１つである。ＭＰＥＧ−２ＴＳパケットがカプセル化されると、Ｐａｃｋｅｔ＿Ｔｙｐｅの値は「０１０」であり得る。他のＰａｃｋｅｔ＿Ｔｙｐｅフィールドの値は、将来の使用のために残すことができる（ｒｅｓｅｒｖｅｄｆｏｒｆｕｔｕｒｅｕｓｅ）。

Ｐａｙｌｏａｄ＿Ｃｏｎｆｉｇｕｒａｔｉｏｎ（ＰＣ）フィールドは、ペイロードの構成を示す１ビットのフィールドであり得る。０の値は、リンク層パケットが一つの全体の入力パケットを伝達し、次のフィールドがＨｅａｄｅｒ＿Ｍｏｄｅであることを示すことができる。１の値は、リンク層パケットが１つ以上の入力パケット（連鎖）や大きい入力パケット（分割）の一部を伝達し、次のフィールドがＳｅｇｍｅｎｔａｔｉｏｎ＿Ｃｏｎｃａｔｅｎａｔｉｏｎであることを示すことができる。

Ｈｅａｄｅｒ＿Ｍｏｄｅ（ＨＭ）フィールドは、０に設定される場合、追加ヘッダーがないことを示し、リンク層パケットのペイロードの長さが２０４８バイトよりも小さいことを示す、１ビットのフィールドであり得る。この数値は、実施例によって変更されてもよい。１の値は、下記に定義された１つのパケットのための追加ヘッダーが長さフィールドの次に存在することを示すことができる。この場合、ペイロードの長さは、２０４７バイトよりも大きく、及び／又はオプショナルフィーチャが使用され得る（サブストリーム識別、ヘッダー拡張など）。この数値は、実施例によって変更されてもよい。本フィールドは、リンク層パケットのＰａｙｌｏａｄ＿Ｃｏｎｆｉｇｕｒａｔｉｏｎフィールドが０の値を有するときのみ存在し得る。

Ｓｅｇｍｅｎｔａｔｉｏｎ＿Ｃｏｎｃａｔｅｎａｔｉｏｎ（Ｓ／Ｃ）フィールドは、０に設定された場合、ペイロードが入力パケットのセグメントを伝達し、下記に定義されるセグメントのための追加ヘッダーが長さフィールドの次に存在することを示す、１ビットのフィールドであり得る。１の値は、ペイロードが１つよりも多い完全な入力パケットを伝達し、下記に定義された連鎖のための追加ヘッダーが長さフィールドの次に存在することを示すことができる。本フィールドは、ＡＬＰパケットのＰａｙｌｏａｄ＿Ｃｏｎｆｉｇｕｒａｔｉｏｎフィールドの値が１であるときのみ存在し得る。

長さフィールドは、リンク層パケットによって伝達されるペイロードのバイト単位の長さの１１ＬＳＢｓ（ｌｅａｓｔｓｉｇｎｉｆｉｃａｎｔｂｉｔｓ）を示す、１１ビットのフィールドであり得る。次の追加ヘッダーにＬｅｎｇｔｈ＿ＭＳＢフィールドがあれば、長さフィールドは、Ｌｅｎｇｔｈ＿ＭＳＢフィールドに連鎖し、ペイロードの実際の全長を提供するためにＬＳＢとなる。長さフィールドのビット数は、１１ビット以外に他のビットに変更されてもよい。

したがって、次のパケット構造のタイプが可能である。すなわち、追加ヘッダーがない１つのパケット、追加ヘッダーがある１つのパケット、分割されたパケット、連鎖したパケットが可能である。実施例によって、各追加ヘッダーとオプショナルヘッダー、後述するシグナリング情報のための追加ヘッダーとタイプ拡張のための追加ヘッダーによる組み合わせで、さらに多くのパケット構成が可能である。

図１０は、本発明の一実施例に係るリンク層パケットの追加ヘッダーの構造を示した図である。

追加ヘッダー（ａｄｄｉｔｉｏｎａｌｈｅａｄｅｒ）は様々なタイプがあり得る。以下、シングルパケットのための追加ヘッダーについて説明する。

１つのパケットに対する当該追加ヘッダーは、Ｈｅａｄｅｒ＿Ｍｏｄｅ（ＨＭ）＝「１」である場合に存在し得る。リンク層パケットのペイロードの長さが２０４７バイトよりも大きいか、又はオプションフィールドが使用される場合、Ｈｅａｄｅｒ＿Ｍｏｄｅ（ＨＭ）は１に設定され得る。１つのパケットの追加ヘッダー（ｔｓｉｂ１００１０）は図面に示す。

Ｌｅｎｇｔｈ＿ＭＳＢフィールドは、現在のリンク層パケットにおいてバイト単位の全ペイロードの長さのＭＳＢｓ（ｍｏｓｔｓｉｇｎｉｆｉｃａｎｔｂｉｔｓ）を示すことができる、５ビットのフィールドであり得、全ペイロードの長さを得るために、１１ＬＳＢを含む長さフィールドに連鎖する。したがって、シグナルできるペイロードの最大長さは６５５３５バイトである。長さフィールドのビット数は、１１ビット以外の他のビットに変更されてもよい。また、Ｌｅｎｇｔｈ＿ＭＳＢフィールドも、ビット数が変更されてもよく、これによって、最大に表現可能なペイロードの長さも変更されてもよい。実施例によって、各長さフィールドは、ペイロードではなく全リンク層パケットの長さを示してもよい。

ＳＩＦ（Ｓｕｂ−ｓｔｒｅａｍＩｄｅｎｔｉｆｉｅｒＦｌａｇ）フィールドは、ＨＥＦ（ＨｅａｄｅｒＥｘｔｅｎｓｉｏｎＦｌａｇ）フィールドの後にＳＩＤ（ｓｕｂ−ｓｔｒｅａｍＩＤ）が存在するか否かを示すことができる、１ビットのフィールドであり得る。リンク層パケットにＳＩＤが存在しなければ、ＳＩＦフィールドは０に設定され得る。リンク層パケットにおいてＨＥＦフィールドの後にＳＩＤが存在すれば、ＳＩＦは１に設定され得る。ＳＩＤについての詳細は後述する。

ＨＥＦフィールドは、１に設定される場合、将来の拡張のために追加ヘッダーが存在することを示すことができる、１ビットのフィールドであり得る。０の値は、この拡張フィールダーが存在しないことを示すことができる。

以下、分割（ｓｅｇｍｅｎｔａｔｉｏｎ）が活用される場合における追加ヘッダーについて説明する。

Ｓｅｇｍｅｎｔａｔｉｏｎ＿Ｃｏｎｃａｔｅｎａｔｉｏｎ（Ｓ／Ｃ）＝「０」である場合、追加ヘッダー（ｔｓｉｂ１００２０）が存在し得る。Ｓｅｇｍｅｎｔ＿Ｓｅｑｕｅｎｃｅ＿Ｎｕｍｂｅｒは、リンク層パケットによって伝達される当該セグメントの順序を示すことができる、５ビットの符号なし整数であり得る。入力パケットの最初のセグメントを伝達するリンク層パケットに対して、当該フィールドの値は０ｘ０に設定され得る。当該フィールドは、分割される入力パケットに属する各追加セグメント毎に１ずつ増分し得る。

ＬＳＩ（Ｌａｓｔ＿Ｓｅｇｍｅｎｔ＿Ｉｎｄｉｃａｔｏｒ）は、１に設定される場合、当該ペイロードにあるセグメントが入力パケットの最後のものであることを示すことができる、１ビットのフィールドであり得る。０の値は、それが最後のセグメントではないことを示すことができる。

ＳＩＦ（Ｓｕｂ−ｓｔｒｅａｍＩｄｅｎｔｉｆｉｅｒＦｌａｇ）は、ＳＩＤがＨＥＦフィールドの後に存在するか否かを示すことができる、１ビットのフィールドであり得る。リンク層パケットにＳＩＤが存在しなければ、ＳＩＦフィールドは０に設定され得る。リンク層パケットにおいてＨＥＦフィールドの後にＳＩＤが存在すれば、ＳＩＦは１に設定され得る。

ＨＥＦフィールドは、１に設定される場合、リンク層ヘッダーの将来の拡張のために追加ヘッダーの後にオプショナルヘッダー拡張が存在することを示すことができる、１ビットのフィールドであり得る。０の値は、オプショナルヘッダー拡張が存在しないことを示すことができる。

実施例によって、各分割されたセグメントが同一の入力パケットから生成されたことを示すパケットＩＤフィールドが追加されてもよい。このフィールドは、分割されたセグメントが順に伝送されれば必要でないので、省略されてもよい。

以下、連鎖（ｃｏｎｃａｔｅｎａｔｉｏｎ）が活用される場合における追加ヘッダーについて説明する。

Ｓｅｇｍｅｎｔａｔｉｏｎ＿Ｃｏｎｃａｔｅｎａｔｉｏｎ（Ｓ／Ｃ）＝「１」である場合、追加ヘッダー（ｔｓｉｂ１００３０）が存在し得る。

Ｌｅｎｇｔｈ＿ＭＳＢは、当該リンク層パケットにおいてバイト単位のペイロードの長さのＭＳＢビットを示すことができる、４ビットのフィールドであり得る。当該ペイロードの最大長さは、連鎖のために３２７６７バイトとなる。前述したものと同様に、詳細な数値は変更されてもよい。

Ｃｏｕｎｔフィールドは、リンク層パケットに含まれたパケットの数を示すことができるフィールドであり得る。リンク層パケットに含まれたパケットの数に該当する２は、当該フィールドに設定され得る。したがって、リンク層パケットにおいて連鎖したパケットの最大値は９である。Ｃｏｕｎｔフィールドがその個数を指示する方法は、実施例毎に異なり得る。すなわち、１から８までの個数が指示されてもよい。

ＨＥＦフィールドは、１に設定される場合、リンク層ヘッダーの将来の拡張のための追加ヘッダーの後にオプショナルヘッダー拡張が存在することを示すことができる、１ビットのフィールドであり得る。０の値は、拡張ヘッダーが存在しないことを示すことができる。

Ｃｏｍｐｏｎｅｎｔ＿Ｌｅｎｇｔｈは、各パケットのバイト単位の長さを示すことができる１２ビットのフィールドであり得る。Ｃｏｍｐｏｎｅｎｔ＿Ｌｅｎｇｔｈフィールドは、最後のコンポーネントパケットを除いて、ペイロードに存在するパケットと同一の順序で含まれる。長さフィールドの数は、（Ｃｏｕｎｔ＋１）によって示すことができる。実施例によって、Ｃｏｕｎｔフィールドの値と同一の数の長さフィールドが存在してもよい。リンク層ヘッダーが奇数のＣｏｍｐｏｎｅｎｔ＿Ｌｅｎｇｔｈで構成される場合、４個のスタッフィングビットが最後のＣｏｍｐｏｎｅｎｔ＿Ｌｅｎｇｔｈフィールドに後続することができる。これらのビットは０に設定され得る。実施例によって、最後の連鎖した入力パケットの長さを示すＣｏｍｐｏｎｅｎｔ＿Ｌｅｎｇｔｈフィールドは存在しないこともある。この場合、最後の連鎖した入力パケットの長さは、全ペイロードの長さから、各Ｃｏｍｐｏｎｅｎｔ＿ｌｅｎｇｔｈフィールドが示す値の和を引いた長さで指示することができる。

以下、オプショナルヘッダーについて説明する。

前述したように、オプショナルヘッダーは、追加ヘッダーの後ろに追加されてもよい。オプショナルヘッダーフィールドは、ＳＩＤ及び／又はヘッダー拡張を含むことができる。ＳＩＤは、リンク層レベルで特定のパケットストリームをフィルタするのに使用される。ＳＩＤの一例は、多数のサービスを伝達するリンク層ストリームにおいてサービス識別子の役割を果たす。適用可能な場合、サービスと、サービスに該当するＳＩＤ値との間のマッピング情報はＳＬＴで提供され得る。ヘッダー拡張は、将来の使用のための拡張フィールドを含む。受信機は、自身が理解できない全てのヘッダー拡張を無視し得る。

ＳＩＤは、リンク層パケットに対するサブストリーム識別子を示すことができる８ビットのフィールドであり得る。オプショナルヘッダー拡張があれば、ＳＩＤは、追加ヘッダーとオプショナルヘッダー拡張との間に存在する。

Ｈｅａｄｅｒ＿Ｅｘｔｅｎｓｉｏｎ（）は、下記に定義されたフィールドを含むことができる。

Ｅｘｔｅｎｓｉｏｎ＿Ｔｙｐｅは、Ｈｅａｄｅｒ＿Ｅｘｔｅｎｓｉｏｎ（）のタイプを示すことができる８ビットのフィールドであり得る。

Ｅｘｔｅｎｓｉｏｎ＿Ｌｅｎｇｔｈは、Ｈｅａｄｅｒ＿Ｅｘｔｅｎｓｉｏｎ（）の次のバイトから最後のバイトまでカウントされるＨｅａｄｅｒＥｘｔｅｎｓｉｏｎ（）のバイトの長さを示すことができる、８ビットのフィールドであり得る。

Ｅｘｔｅｎｓｉｏｎ＿Ｂｙｔｅは、Ｈｅａｄｅｒ＿Ｅｘｔｅｎｓｉｏｎ（）の値を示すバイトであり得る。

図１１は、本発明の他の実施例に係るリンク層パケットの追加ヘッダーの構造を示した図である。

以下、シグナリング情報のための追加ヘッダーについて説明する。

リンク層シグナリングがどのようにリンク層パケットに含まれるかは、次の通りである。シグナリングパケットは、ベースヘッダーのＰａｃｋｅｔ＿Ｔｙｐｅフィールドが１００と同一であるときに識別される。

図（ｔｓｉｂ１１０１０）は、シグナリング情報のための追加ヘッダーを含むリンク層パケットの構造を示す。リンク層ヘッダーだけでなく、リンク層パケットは、シグナリング情報のための追加ヘッダー及び実際のシグナリングデータ自体の２つの追加部分で構成され得る。リンク層シグナリングパケットの全長はリンク層パケットヘッダーに示す。

シグナリング情報のための追加ヘッダーは、次のフィールドを含むことができる。実施例によって、一部のフィールドは省略されてもよい。

Ｓｉｇｎａｌｉｎｇ＿Ｔｙｐｅは、シグナリングのタイプを示すことができる８ビットのフィールドであり得る。

Ｓｉｇｎａｌｉｎｇ＿Ｔｙｐｅ＿Ｅｘｔｅｎｓｉｏｎは、シグナリングの属性を示すことができる１６ビットのフィールドであり得る。当該フィールドの詳細はシグナリングの仕様で定義され得る。

Ｓｉｇｎａｌｉｎｇ＿Ｖｅｒｓｉｏｎは、シグナリングのバージョンを示すことができる８ビットのフィールドであり得る。

Ｓｉｇｎａｌｉｎｇ＿Ｆｏｒｍａｔは、シグナリングデータのデータフォーマットを示すことができる２ビットのフィールドであり得る。ここで、シグナリングフォーマットとは、バイナリ、ＸＭＬなどのデータフォーマットを意味し得る。

Ｓｉｇｎａｌｉｎｇ＿Ｅｎｃｏｄｉｎｇは、エンコーディング／圧縮フォーマットを特定することができる２ビットのフィールドであり得る。本フィールドは、圧縮が行われなかったか、どのような特定の圧縮が行われたかを示すことができる。

以下、パケットタイプの拡張のための追加ヘッダーについて説明する。

将来にリンク層によって伝達されるパケットタイプ及び追加プロトコルの無制限に近い数を許容するメカニズムを提供するために、追加ヘッダーが定義される。前述したように、ベースヘッダーでＰａｃｋｅｔ＿ｔｙｐｅが１１１である場合、パケットタイプの拡張が使用され得る。図（ｔｓｉｂ１１０２０）は、タイプの拡張のための追加ヘッダーを含むリンク層パケットの構造を示す。

タイプの拡張のための追加ヘッダーは、次のフィールドを含むことができる。実施例によって、一部のフィールドは省略されてもよい。

ｅｘｔｅｎｄｅｄ＿ｔｙｐｅは、ペイロードとしてリンク層パケットにカプセル化される入力のプロトコルやパケットタイプを示すことができる、１６ビットのフィールドであり得る。当該フィールドは、Ｐａｃｋｅｔ＿Ｔｙｐｅフィールドによって既に定義された全てのプロトコルやパケットタイプに対して使用することができない。

図１２は、本発明の一実施例に係る、ＭＰＥＧ−２ＴＳパケットのためのリンク層パケットのヘッダーの構造、及びそのカプセル化の過程を示した図である。

以下、入力パケットとしてＭＰＥＧ−２ＴＳパケットが入力されたとき、リンク層パケットのフォーマットについて説明する。

この場合、ベースヘッダーのＰａｃｋｅｔ＿Ｔｙｐｅフィールドは０１０と同一である。各リンク層パケット内で多数のＴＳパケットがカプセル化されてもよい。ＴＳパケットの数は、ＮＵＭＴＳフィールドを介してシグナルされてもよい。この場合、前述したように、特別なリンク層パケットヘッダーフォーマットが使用されてもよい。

リンク層は、伝送効率を向上させるために、ＭＰＥＧ−２ＴＳのためのオーバーヘッド削減メカニズムを提供する。各ＴＳパケットのシンクバイト（０ｘ４７）は削除され得る。ヌルパケット及び類似のＴＳヘッダーを削除するオプションも提供される。

不必要な伝送オーバーヘッドを避けるために、ＴＳヌルパケット（ＰＩＤ＝０ｘ１ＦＦＦ）を除去することができる。削除されたヌルパケットは、ＤＮＰフィールドを用いて受信機側で復旧することができる。ＤＮＰフィールドは、削除されたヌルパケットのカウントを示す。ＤＮＰフィールドを用いたヌルパケット削除メカニズムは、後述する。

伝送効率をさらに向上させるために、ＭＰＥＧ−２ＴＳパケットの類似のヘッダーを除去することができる。２つ以上の順次的なＴＳパケットがＣＣ（ｃｏｎｔｉｎｕｉｔｙｃｏｕｎｔｅｒ）フィールドを順次増加させ、他のヘッダーフィールドも同一であれば、ヘッダーが最初のパケットで一回伝送され、他のヘッダーは削除される。ＨＤＭフィールドは、ヘッダーが削除されたか否かを示すことができる。共通ＴＳヘッダー削除の詳細な過程は後述する。

３つのオーバーヘッド削減メカニズムが全て行われる場合、オーバーヘッド削減は、シンク除去、ヌルパケット削除、共通ヘッダー削除の順に行うことができる。実施例によって、各メカニズムが行われる順序は変更されてもよい。また、実施例によって一部のメカニズムは省略されてもよい。

ＭＰＥＧ−２ＴＳパケットカプセル化を使用する場合のリンク層パケットヘッダーの全体的な構造が図（ｔｓｉｂ１２０１０）に示されている。

以下、図示された各フィールドについて説明する。Ｐａｃｋｅｔ＿Ｔｙｐｅは、前述したように、入力パケットのプロトコルタイプを示すことができる３ビットのフィールドであり得る。ＭＰＥＧ−２ＴＳパケットカプセル化のために、当該フィールドは、常に０１０に設定され得る。

ＮＵＭＴＳ（ＮｕｍｂｅｒｏｆＴＳｐａｃｋｅｔｓ）は、当該リンク層パケットのペイロードでＴＳパケットの数を示すことができる４ビットのフィールドであり得る。最大１６個のＴＳパケットが一つのリンク層パケットで支援され得る。ＮＵＭＴＳ＝０の値は、１６個のＴＳパケットがリンク層パケットのペイロードによって伝達されることを示すことができる。ＮＵＭＴＳの他の全ての値に対して、同じ数のＴＳパケットが認識される。例えば、ＮＵＭＴＳ＝０００１は、一つのＴＳパケットが伝達されることを意味する。

ＡＨＦ（ａｄｄｉｔｉｏｎａｌｈｅａｄｅｒｆｌａｇ）は、追加ヘッダーが存在するか否かを示すことができるフィールドであり得る。０の値は、追加ヘッダーが存在しないことを示す。１の値は、１バイト長の追加ヘッダーがベースヘッダーの次に存在することを示す。ヌルＴＳパケットが削除されるか、又はＴＳヘッダー圧縮が適用されれば、当該フィールドは１に設定され得る。ＴＳパケットカプセル化のための追加ヘッダーは、次の２つのフィールドで構成され、当該リンク層パケットでのＡＨＦの値が１に設定される場合にのみ存在する。

ＨＤＭ（ｈｅａｄｅｒｄｅｌｅｔｉｏｎｍｏｄｅ）は、ＴＳヘッダー削除を当該リンク層パケットに適用できるか否かを示す１ビットのフィールドであり得る。１の値は、ＴＳヘッダー削除を適用できることを示す。０の値は、ＴＳヘッダー削除の方法が当該リンク層パケットに適用されないことを示す。

ＤＮＰ（ｄｅｌｅｔｅｄｎｕｌｌｐａｃｋｅｔｓ）は、当該リンク層パケットの前に削除されたヌルＴＳパケットの数を示す７ビットのフィールドであり得る。最大１２８個のヌルＴＳパケットが削除され得る。ＨＤＭ＝０である場合、ＤＮＰ＝０の値は、１２８個のヌルパケットが削除されることを示すことができる。ＨＤＭ＝１である場合、ＤＮＰ＝０の値は、ヌルパケットが削除されないことを示すことができる。ＤＮＰの他の全ての値に対して、同じ数のヌルパケットが認識される。例えば、ＤＮＰ＝５は、５個のヌルパケットが削除されることを意味する。

前述した各フィールドのビット数は変更可能であり、変更されたビット数に応じて、当該フィールドが指示する値の最小／最大値は変更され得る。これは、設計者の意図によって変更されてもよい。

以下、シンクバイト削除（ＳＹＮＣｂｙｔｅｒｅｍｏｖａｌ）について説明する。

ＴＳパケットをリンク層パケットのペイロードにカプセル化する場合、各ＴＳパケットの開始からシンクバイト（０ｘ４７）が削除され得る。したがって、リンク層パケットのペイロードにカプセル化されたＭＰＥＧ２−ＴＳパケットの長さは（元の１８８バイトの代わりに）、常に１８７バイトである。

以下、ヌルパケット削除（ＮｕｌｌＰａｃｋｅｔＤｅｌｅｔｉｏｎ）について説明する。

伝送ストリーム規則は、送信機のマルチプレクサの出力及び受信機のデマルチプレクサの入力でのビットレートが時間に対して一定であり、終端間の遅延も一定であることを要求する。一部の伝送ストリーム入力信号に対して、ヌルパケットは、一定のビットレートストリームに可変的なビットレートサービスを収容するために存在することができる。この場合、不必要な伝送オーバーヘッドを避けるために、ＴＳヌルパケット（即ち、ＰＩＤ＝０ｘ１ＦＦＦであるＴＳパケット）が除去され得る。この処理は、除去されたヌルパケットが受信機で元の正確な位置に再び挿入され得る方式で実行されるので、一定のビットレートを保障し、ＰＣＲタイムスタンプ更新を行う必要がなくなる。

リンク層パケットの生成の前に、ＤＮＰと呼ばれるカウンターは、まず、０にリセットされた後に、現在のリンク層パケットのペイロードにカプセル化される最初のヌルＴＳパケットではない、パケットに先行する各削除されたヌルパケットに対して増分され得る。その後、連続した有用なＴＳパケットのグループが現在のリンク層パケットのペイロードにカプセル化され、そのヘッダーでの各フィールドの値が決定され得る。生成されたリンク層パケットが物理層に注入された後、ＤＮＰは０にリセットされる。ＤＮＰが最高の許容値に到達する場合、次のパケットもヌルパケットであれば、当該ヌルパケットは有用なパケットに維持され、次のリンク層パケットのペイロードにカプセル化される。各リンク層パケットは、そのペイロードに少なくとも１つの有用なＴＳパケットを含むことができる。

以下、ＴＳパケットヘッダー削除（ＴＳＰａｃｋｅｔＨｅａｄｅｒＤｅｌｅｔｉｏｎ）について説明する。ＴＳパケットヘッダー削除は、ＴＳパケットヘッダー圧縮と呼ぶこともできる。

２つ以上の順次的なＴＳパケットがＣＣフィールドを順次増加させ、他のヘッダーフィールドも同一であれば、ヘッダーが最初のパケットで一回伝送され、他のヘッダーは削除される。重複したＭＰＥＧ−２ＴＳパケットが２つ以上の順次的なＴＳパケットに含まれると、ヘッダーの削除は送信機側で適用することができない。ＨＤＭフィールドは、ヘッダーが削除されるか否かを示すことができる。ＴＳヘッダーが削除される場合、ＨＤＭは１に設定され得る。受信機側で、最初のパケットヘッダーを用いて、削除されたパケットヘッダーが復旧され、ＣＣが最初のヘッダーから順に増加することによって復旧される。

図示された実施例（ｔｓｉｂ１２０２０）は、ＴＳパケットの入力ストリームがリンク層パケットにカプセル化される過程の一実施例である。まず、ＳＹＮＣバイト（０ｘ４７）を有するＴＳパケットからなるＴＳストリームが入力され得る。まず、ＳＹＮＣバイトの削除過程を通じてシンクバイトを削除することができる。この実施例において、ヌルパケット削除は行われないと仮定する。

ここで、図示された８個のＴＳパケットのパケットヘッダーにおいて、ＣＣ（ＣｏｕｎｔｉｎｕｉｔｙＣｏｕｎｔｅｒ）フィールド値を除いた他の値が全て同一であると仮定する。この場合、ＴＳパケット削除／圧縮を行うことができる。ＣＣ＝１である最初のＴＳパケットのヘッダーのみを残し、残りの７個のＴＳパケットのヘッダーを削除する。処理されたＴＳパケットは、リンク層パケットのペイロードにカプセル化されてもよい。

完成されたリンク層パケットを見ると、Ｐａｃｋｅｔ＿Ｔｙｐｅフィールドは、ＴＳパケットが入力された場合であるので０１０の値を有することができる。ＮＵＭＴＳフィールドは、カプセル化されたＴＳパケットの個数を示すことができる。ＡＨＦフィールドは、パケットヘッダーの削除が行われたので１に設定され、追加ヘッダーの存在を知らせることができる。ＨＤＭフィールドは、ヘッダーの削除が行われたので１に設定され得る。ＤＮＰは、ヌルパケットの削除が行われなかったので、０に設定され得る。

図１３は、本発明の一実施例に係るＩＰヘッダー圧縮において、適応モードの実施例を示した図である（送信側）。

以下、ＩＰヘッダー圧縮（ＩＰＨｅａｄｅｒＣｏｍｐｒｅｓｓｉｏｎ）について説明する。

リンク層において、ＩＰヘッダー圧縮／圧縮解除スキームが提供され得る。ＩＰヘッダー圧縮は、ヘッダーコンプレッサ／デコンプレッサ及び適応モジュールの２つの部分を含むことができる。ヘッダー圧縮スキームはＲｏＨＣに基づくことができる。また、放送用途に適応機能が追加される。

送信機側で、ＲｏＨＣコンプレッサは、各パケットに対してヘッダーの大きさを減少させる。その後、適応モジュールは、コンテキスト情報を抽出し、各パケットストリームからシグナリング情報を生成する。受信機側で、適応モジュールは、受信されたパケットストリームと関連するシグナリング情報をパースし、コンテキスト情報を受信されたパケットストリームに付加する。ＲｏＨＣデコンプレッサは、パケットヘッダーを復旧することによって元のＩＰパケットを再構成する。

ヘッダー圧縮スキームは、前述したように、ＲＯＨＣをベースとすることができる。特に、本システムでは、ＲＯＨＣのＵモード（ｕｎｉｄｉｒｃｔｉｏｎａｌｍｏｄｅ）でＲＯＨＣフレームワークが動作することができる。また、本システムにおいて、０ｘ０００２のプロファイル識別子で識別されるＲＯＨＣＵＤＰヘッダー圧縮プロファイルが使用され得る。

以下、適応（Ａｄａｐｔａｔｉｏｎ）について説明する。

単方向リンクを介した伝送の場合、受信機がコンテキストの情報を有していないと、デコンプレッサは、完全なコンテキストを受信する時まで、受信されたパケットヘッダーを復旧することができない。これは、チャネル変更遅延及びターンオン遅延（ｔｕｒｎ−ｏｎｄｅｌａｙ）を招くことがある。このような理由で、コンプレッサとデコンプレッサとの間の構成パラメータ及びコンテキスト情報は、常にパケットフローと共に伝送され得る。

適応機能は、構成パラメータ及びコンテキスト情報の帯域外伝送を提供する。帯域外伝送は、リンク層シグナリングを通じて行うことができる。したがって、適応機能は、コンテキスト情報の損失による圧縮解除誤り及びチャネル変更遅延を減少させるために用いられる。

以下、コンテキスト情報（ＣｏｎｔｅｘｔＩｎｆｏｒｍａｔｉｏｎ）の抽出について説明する。

コンテキスト情報の抽出は、適応モードに応じて様々な方法で行うことができる。本発明では、以下の３つの実施例について説明する。本発明の範囲は、後述する適応モードの実施例に限定されない。ここで、適応モードは、コンテキスト抽出モードと呼ぶこともできる。

適応モード１（図示せず）は、基本的なＲＯＨＣパケットストリームに対していかなる追加的な動作も加えられていないモードであり得る。すなわち、このモードで適応モジュールは、バッファとして動作することができる。したがって、このモードでは、リンク層シグナリングにコンテキスト情報が含まれていない。

適応モード２（ｔｓｉｂ１３０１０）において、適応モジュールは、ＲｏＨＣパケットフローからＩＲパケットを検出し、コンテキスト情報（静的チェーン）を抽出することができる。コンテキスト情報を抽出した後、各ＩＲパケットは、ＩＲ−ＤＹＮパケットに転換され得る。転換されたＩＲ−ＤＹＮパケットは、元のパケットの代わりに、ＩＲパケットと同一の順序でＲｏＨＣパケットフロー内に含まれて伝送され得る。

適応モード３（ｔｓｉｂ１３０２０）において、適応モジュールは、ＲｏＨＣパケットフローからＩＲ及びＩＲ−ＤＹＮパケットを検出し、コンテキスト情報を抽出することができる。静的チェーン及び動的チェーンはＩＲパケットから抽出することができ、動的チェーンはＩＲ−ＤＹＮパケットから抽出することができる。コンテキスト情報を抽出した後、それぞれのＩＲ及びＩＲ−ＤＹＮパケットは圧縮されたパケットに転換され得る。圧縮されたパケットのフォーマットは、ＩＲ又はＩＲ−ＤＹＮパケットの次のパケットと同一であり得る。転換された圧縮パケットは、元のパケットの代わりに、ＩＲ又はＩＲ−ＤＹＮパケットと同一の順序でＲｏＨＣパケットフロー内に含まれて伝送され得る。

シグナリング（コンテキスト）情報は、伝送構造に基づいてカプセル化され得る。例えば、コンテキスト情報は、リンク層シグナリングにカプセル化され得る。この場合、パケットタイプ値は１００に設定され得る。

前述した適応モード２、３に対して、コンテキスト情報に対するリンク層パケットは、１００のパケットタイプ（ＰａｃｋｅｔＴｙｐｅ）フィールド値を有することができる。また、圧縮されたＩＰパケットに対するリンク層パケットは、００１のパケットタイプフィールド値を有することができる。これは、それぞれシグナリング情報、圧縮されたＩＰパケットがリンク層パケットに含まれていることを示すもので、前述した通りである。

以下、抽出されたコンテキスト情報を伝送する方法について説明する。

抽出されたコンテキスト情報は、特定の物理データ経路を介してシグナリングデータと共に、ＲｏＨＣパケットフローと別途に伝送され得る。コンテキストの伝送は、物理層経路の構成に依存する。コンテキスト情報は、シグナリングデータパイプを介して他のリンク層シグナリングと共に伝送され得る。

すなわち、コンテキスト情報を有するリンク層パケットは、他のリンク層シグナリング情報を有するリンク層パケットと共にシグナリングＰＬＰを介して伝送され得る（Ｐａｃｋｅｔ＿Ｔｙｐｅ＝１００）。コンテキスト情報が抽出された圧縮ＩＰパケットは、一般的なＰＬＰを介して伝送され得る（Ｐａｃｋｅｔ＿Ｔｙｐｅ＝００１）。ここで、実施例によって、シグナリングＰＬＰは、Ｌ１シグナリング経路（ｐａｔｈ）を意味してもよい。また、実施例によって、シグナリングＰＬＰは、一般的なＰＬＰと区分されず、シグナリング情報が伝送される特定の一般ＰＬＰを意味してもよい。

受信側では、パケットストリームを受信するに先立ち、受信機がシグナリング情報を得る必要がある。受信機が、シグナリング情報を取得するために最初のＰＬＰをデコードすると、コンテキストシグナリングも受信することができる。シグナリングの取得が行われた後、パケットストリームを受信するためのＰＬＰが選択され得る。すなわち、受信機は、まず、イニシャルＰＬＰを選択して、コンテキスト情報を含めてシグナリング情報を得ることができる。ここで、イニシャルＰＬＰは、前述したシグナリングＰＬＰであり得る。その後、受信機は、パケットストリームを得るためのＰＬＰを選択することができる。これを通じて、コンテキスト情報は、パケットストリームの受信に先立って取得できる。

パケットストリームを得るためのＰＬＰが選択された後、適応モジュールは、受信されたパケットフローからＩＲ−ＤＹＮパケットを検出することができる。その後、適応モジュールは、シグナリングデータにおいてコンテキスト情報から静的チェーンをパースする。これは、ＩＲパケットを受信することと類似している。同一のコンテキスト識別子に対して、ＩＲ−ＤＹＮパケットはＩＲパケットに復旧され得る。復旧されたＲｏＨＣパケットフローはＲｏＨＣデコンプレッサに送られる。その後、圧縮解除が開始され得る。

図１４は、本発明の一実施例に係るＬＭＴ（ＬｉｎｋＭａｐｐｉｎｇＴａｂｌｅ）及びＲＯＨＣ−Ｕ記述テーブルを示した図である。

以下、リンク層シグナリングについて説明する。

主に、リンク層シグナリングはＩＰレベル下で動作する。受信機側で、リンク層シグナリングは、ＳＬＴ及びＳＬＳのようなＩＰレベルシグナリングよりも先に取得され得る。したがって、リンク層シグナリングはセッション設定の前に取得できる。

リンク層シグナリングに対して、入力経路に応じて、インターナルリンク層シグナリング及びエクスターナルリンク層シグナリングの２種類のシグナリングが存在することができる。インターナルリンク層シグナリングは、送信機側でリンク層で生成される。また、リンク層は、外部のモジュール又はプロトコルからシグナリングを取る。このような種類のシグナリング情報はエクスターナルリンク層シグナリングであると見なされる。一部のシグナリングがＩＰレベルシグナリングに先立って取得される必要があれば、外部のシグナリングは、リンク層パケットのフォーマットで伝送される。

リンク層シグナリングは、前述したように、リンク層パケットにカプセル化され得る。リンク層パケットは、バイナリ及びＸＭＬを含んだ全てのフォーマットのリンク層シグナリングを伝達することができる。同一のシグナリング情報がリンク層シグナリングに対して異なるフォーマットで伝送され得る。

インターナルリンク層シグナリングには、リンクマッピングのためのシグナリング情報が含まれてもよい。ＬＭＴは、ＰＬＰに伝達される上位層セッションのリストを提供する。ＬＭＴはまた、リンク層で上位層セッションを伝達するリンク層パケットを処理するための追加情報を提供する。

本発明に係るＬＭＴの一実施例（ｔｓｉｂ１４０１０）が図示された。

ｓｉｇｎａｌｉｎｇ＿ｔｙｐｅは、当該テーブルによって伝達されるシグナリングのタイプを示す８ビットの符号なし整数フィールドであり得る。ＬＭＴに対するｓｉｇｎａｌｉｎｇ＿ｔｙｐｅフィールドの値は０ｘ０１に設定され得る。

ＰＬＰ＿ＩＤは、当該テーブルに該当するＰＬＰを示す８ビットのフィールドであり得る。

ｎｕｍ＿ｓｅｓｓｉｏｎは、前記ＰＬＰ＿ＩＤフィールドによって識別されるＰＬＰに伝達される上位層セッションの個数を提供する８ビットの符号なし整数フィールドであり得る。ｓｉｇｎａｌｉｎｇ＿ｔｙｐｅフィールドの値が０ｘ０１であれば、当該フィールドは、ＰＬＰでＵＤＰ／ＩＰセッションの個数を示すことができる。

ｓｒｃ＿ＩＰ＿ａｄｄは、ＰＬＰ＿ＩＤフィールドによって識別されるＰＬＰに伝達される上位層セッションのソースＩＰ住所を含む３２ビットの符号なし整数フィールドであり得る。

ｄｓｔ＿ＩＰ＿ａｄｄは、ＰＬＰ＿ＩＤフィールドによって識別されるＰＬＰに伝達される上位層セッションの目的地ＩＰ住所を含む３２ビットの符号なし整数フィールドであり得る。

ｓｒｃ＿ＵＤＰ＿ｐｏｒｔは、ＰＬＰ＿ＩＤフィールドによって識別されるＰＬＰに伝達される上位層セッションのソースＵＤＰポート番号を示す１６ビットの符号なし整数フィールドであり得る。

ｄｓｔ＿ＵＤＰ＿ｐｏｒｔは、ＰＬＰ＿ＩＤフィールドによって識別されるＰＬＰに伝達される上位層セッションの目的地ＵＤＰポート番号を示す１６ビットの符号なし整数フィールドであり得る。

ＳＩＤ＿ｆｌａｇは、前記４個のフィールドＳｒｃ＿ＩＰ＿ａｄｄ、Ｄｓｔ＿ＩＰ＿ａｄｄ、Ｓｒｃ＿ＵＤＰ＿Ｐｏｒｔ、Ｄｓｔ＿ＵＤＰ＿Ｐｏｒｔによって識別される上位層セッションを伝達するリンク層パケットがそのオプショナルヘッダーにＳＩＤフィールドを有するか否かを示す１ビットのブールフィールドであり得る。当該フィールドの値が０に設定されると、上位層セッションを伝達するリンク層パケットがそのオプショナルヘッダーにＳＩＤフィールドを有さない。当該フィールドの値が１に設定されると、上位層セッションを伝達するリンク層パケットがそのオプショナルヘッダーにＳＩＤフィールドを有することができ、ＳＩＤフィールドの値が、当該テーブルで次のＳＩＤフィールドと同一であり得る。

ｃｏｍｐｒｅｓｓｅｄ＿ｆｌａｇは、ヘッダー圧縮が、前記４個のフィールドＳｒｃ＿ＩＰ＿ａｄｄ、Ｄｓｔ＿ＩＰ＿ａｄｄ、Ｓｒｃ＿ＵＤＰ＿Ｐｏｒｔ、Ｄｓｔ＿ＵＤＰ＿Ｐｏｒｔによって識別される上位層セッションを伝達するリンク層パケットに適用されるか否かを示す１ビットのブールフィールドであり得る。当該フィールドの値が０に設定されると、上位層セッションを伝達するリンク層パケットは、そのベースヘッダーにＰａｃｋｅｔ＿Ｔｙｐｅフィールドの０ｘ００の値を有することができる。当該フィールドの値が１に設定されると、上位層セッションを伝達するリンク層パケットは、そのベースヘッダーにＰａｃｋｅｔ＿Ｔｙｐｅフィールドの０ｘ０１の値を有することができ、Ｃｏｎｔｅｘｔ＿ＩＤフィールドが存在することができる。

ＳＩＤは、前記４個のフィールドＳｒｃ＿ＩＰ＿ａｄｄ、Ｄｓｔ＿ＩＰ＿ａｄｄ、Ｓｒｃ＿ＵＤＰ＿Ｐｏｒｔ、Ｄｓｔ＿ＵＤＰ＿Ｐｏｒｔによって識別される上位層セッションを伝達するリンク層パケットに対するサブストリーム識別子を示す８ビットの符号なし整数フィールドであり得る。当該フィールドは、ＳＩＤ＿ｆｌａｇの値が１と同一であるときに存在することができる。

ｃｏｎｔｅｘｔ＿ｉｄは、ＲＯＨＣ−Ｕ記述テーブルに提供されたＣＩＤ（ｃｏｎｔｅｘｔｉｄ）に対するリファレンスを提供する８ビットのフィールドであり得る。当該フィールドは、ｃｏｍｐｒｅｓｓｅｄ＿ｆｌａｇの値が１と同一であるときに存在することができる。

本発明に係るＲＯＨＣ−Ｕ記述テーブルの一実施例（ｔｓｉｂ１４０２０）が図示された。前述したように、ＲＯＨＣ−Ｕ適応モジュールは、ヘッダー圧縮に関連する情報を生成することができる。

ｓｉｇｎａｌｉｎｇ＿ｔｙｐｅは、当該テーブルによって伝達されるシグナリングのタイプを示す８ビットのフィールドであり得る。ＲＯＨＣ−Ｕ記述テーブルに対するｓｉｇｎａｌｉｎｇ＿ｔｙｐｅフィールドの値は「０ｘ０２」に設定され得る。

ｃｏｎｔｅｘｔ＿ｉｄは、圧縮されたＩＰストリームのＣＩＤを示す８ビットのフィールドであり得る。当該システムにおいて、８ビットのＣＩＤは、大きいＣＩＤのために使用することができる。

ｃｏｎｔｅｘｔ＿ｐｒｏｆｉｌｅは、ストリームを圧縮するために使用されるプロトコルの範囲を示す８ビットのフィールドであり得る。当該フィールドは省略してもよい。

ａｄａｐｔａｔｉｏｎ＿ｍｏｄｅは、当該ＰＬＰで適応モジュールのモードを示す２ビットのフィールドであり得る。適応モードについては前述した。

ｃｏｎｔｅｘｔ＿ｃｏｎｆｉｇは、コンテキスト情報の組み合わせを示す２ビットのフィールドであり得る。当該テーブルにコンテキスト情報が存在しなければ、当該フィールドは「０ｘ０」に設定され得る。当該テーブルにｓｔａｔｉｃ＿ｃｈａｉｎ（）又はｄｙｎａｍｉｃ＿ｃｈａｉｎ（）バイトが含まれれば、当該フィールドは「０ｘ０１」又は「０ｘ０２」に設定され得る。当該テーブルにｓｔａｔｉｃ＿ｃｈａｉｎ（）及びｄｙｎａｍｉｃ＿ｃｈａｉｎ（）バイトが全て含まれれば、当該フィールドは「０ｘ０３」に設定され得る。

ｃｏｎｔｅｘｔ＿ｌｅｎｇｔｈは、静的チェーンバイトシーケンスの長さを示す８ビットのフィールドであり得る。当該フィールドは省略してもよい。

ｓｔａｔｉｃ＿ｃｈａｉｎ＿ｂｙｔｅ（）は、ＲｏＨＣ−Ｕデコンプレッサを初期化するために使用される静的情報を伝達するフィールドであり得る。当該フィールドの大きさ及び構造はコンテキストプロファイルに依存する。

ｄｙｎａｍｉｃ＿ｃｈａｉｎ＿ｂｙｔｅ（）は、ＲｏＨＣ−Ｕデコンプレッサを初期化するために使用される動的情報を伝達するフィールドであり得る。当該フィールドの大きさ及び構造はコンテキストプロファイルに依存する。

ｓｔａｔｉｃ＿ｃｈａｉｎ＿ｂｙｔｅは、ＩＲパケットのサブヘッダー情報として定義することができる。ｄｙｎａｍｉｃ＿ｃｈａｉｎ＿ｂｙｔｅは、ＩＲパケット及びＩＲ−ＤＹＮパケットのサブヘッダー情報として定義することができる。

図１５は、本発明の一実施例に係る送信機側のリンク層の構造を示した図である。

本実施例は、ＩＰパケットを処理することを仮定した実施例である。送信機側のリンク層は、機能的な観点から、大きく、シグナリング情報を処理するリンク層シグナリング部分、オーバーヘッド削減部分、及び／又はカプセル化部分を含むことができる。また、送信機側のリンク層は、リンク層全体の動作に対する制御及びスケジューリングのためのスケジューラ、及び／又はリンク層の入出力部分などを含むことができる。

まず、上位層のシグナリング情報及び／又はシステムパラメータ（ｔｓｉｂ１５０１０）がリンク層に伝達され得る。また、ＩＰ層（ｔｓｉｂ１５１１０）から、ＩＰパケットを含むＩＰストリームがリンク層に伝達され得る。

スケジューラ（ｔｓｉｂ１５０２０）は、前述したように、リンク層に含まれた多数のモジュールの動作を決定し、制御する役割を果たすことができる。伝達されたシグナリング情報及び／又はシステムパラメータ（ｔｓｉｂ１５０１０）は、スケジューラ（ｔｓｉｂ１５０２０）によってフィルタリング又は活用されてもよい。伝達されたシグナリング情報及び／又はシステムパラメータ（ｔｓｉｂ１５０１０）のうち、受信機で必要な情報はリンク層シグナリング部分に伝達されてもよい。また、シグナリング情報のうちリンク層の動作に必要な情報は、オーバーヘッド削減コントローラ（ｔｓｉｂ１５１２０）又はカプセル化コントローラ（ｔｓｉｂ１５１８０）に伝達されてもよい。

リンク層シグナリング部分は、物理層でシグナリングとして伝送される情報を収集し、これを、伝送に適した形態に変換／構成する役割を果たすことができる。リンク層シグナリング部分は、シグナリングマネジャー（ｔｓｉｂ１５０３０）、シグナリングフォーマッタ（ｔｓｉｂ１５０４０）、及び／又はチャネルのためのバッファ（ｔｓｉｂ１５０５０）を含むことができる。

シグナリングマネジャー（ｔｓｉｂ１５０３０）は、スケジューラ（ｔｓｉｂ１５０２０）から伝達されたシグナリング情報、及び／又はオーバーヘッド削減部分から伝達されたシグナリング及び／又はコンテキスト（ｃｏｎｔｅｘｔ）情報を受信することができる。シグナリングマネジャー（ｔｓｉｂ１５０３０）は、伝達されたデータに対して、各シグナリング情報が伝送される経路を決定することができる。各シグナリング情報は、シグナリングマネジャー（ｔｓｉｂ１５０３０）によって決定された経路で伝達されてもよい。前述したように、ＦＩＣ、ＥＡＳなどの区分されたチャネルで伝送されるシグナリング情報はシグナリングフォーマッタ（ｔｓｉｂ１５０４０）に伝達され、その他のシグナリング情報はカプセル化バッファ（ｔｓｉｂ１５０７０）に伝達されてもよい。

シグナリングフォーマッタ（ｔｓｉｂ１５０４０）は、別途に区分されたチャネルを介してシグナリング情報を伝送できるように、関連するシグナリング情報を各区分されたチャネルに合う形態でフォーマットする役割を果たすことができる。前述したように、物理層には、物理的／論理的に区分された別途のチャネルがあり得る。これらの区分されたチャネルは、ＦＩＣシグナリング情報や、ＥＡＳ関連情報を伝送するのに使用することができる。ＦＩＣ又はＥＡＳ関連情報は、シグナリングマネジャー（ｔｓｉｂ１５０３０）によって分類されてシグナリングフォーマッタ（ｔｓｉｂ１５０４０）に入力されてもよい。シグナリングフォーマッタ（ｔｓｉｂ１５０４０）は、各情報を、それぞれの別途のチャネルに合わせてフォーマットすることができる。ＦＩＣ、ＥＡＳ以外にも、物理層が特定のシグナリング情報を別途の区分されたチャネルを介して伝送するものと設計された場合には、その特定のシグナリング情報のためのシグナリングフォーマッタを追加することができる。このような方式を通じて、リンク層が、様々な物理層に対して互換可能となり得る。

チャネルのためのバッファ（ｔｓｉｂ１５０５０）は、シグナリングフォーマッタ（ｔｓｉｂ１５０４０）から伝達されたシグナリング情報を、指定された別途のチャネル（ｔｓｉｂ１５０６０）に伝達する役割を果たすことができる。別途のチャネルの数、内容は、実施例によって変更されてもよい。

前述したように、シグナリングマネジャー（ｔｓｉｂ１５０３０）は、特定のチャネルに伝達されないシグナリング情報をカプセル化バッファ（ｔｓｉｂ１５０７０）に伝達することができる。カプセル化バッファ（ｔｓｉｂ１５０７０）は、特定のチャネルに伝達されないシグナリング情報を受信するバッファの役割を果たすことができる。

シグナリング情報のためのカプセル化（ｔｓｉｂ１５０８０）は、特定のチャネルに伝達されないシグナリング情報に対してカプセル化を行うことができる。伝送バッファ（ｔｓｉｂ１５０９０）は、カプセル化されたシグナリング情報を、シグナリング情報のためのＤＰ（ｔｓｉｂ１５１００）に伝達するバッファの役割を果たすことができる。ここで、シグナリング情報のためのＤＰ（ｔｓｉｂ１５１００）は、前述したＰＬＳ領域を意味し得る。

オーバーヘッド削減部分は、リンク層に伝達されるパケットのオーバーヘッドを除去し、効率的な伝送を可能にすることができる。オーバーヘッド削減部分は、リンク層に入力されるＩＰストリームの数だけ構成することができる。

オーバーヘッド削減バッファ（ｔｓｉｂ１５１３０）は、上位層から伝達されたＩＰパケットの入力を受ける役割を果たすことができる。伝達されたＩＰパケットは、オーバーヘッド削減バッファ（ｔｓｉｂ１５１３０）を介してオーバーヘッド削減部分に入力されてもよい。

オーバーヘッド削減コントローラ（ｔｓｉｂ１５１２０）は、オーバーヘッド削減バッファ（ｔｓｉｂ１５１３０）に入力されるパケットストリームに対してオーバーヘッド削減を行うか否かを決定することができる。オーバーヘッド削減コントローラ（ｔｓｉｂ１５１２０）は、パケットストリーム別にオーバーヘッド削減を行うか否かを決定することができる。パケットストリームにオーバーヘッド削減が行われる場合、ＲｏＨＣコンプレッサ（ｔｓｉｂ１５１４０）にパケットが伝達され、オーバーヘッド削減が行われ得る。パケットストリームにオーバーヘッド削減が行われない場合、カプセル化部分にパケットが伝達され、オーバーヘッド削減なしにカプセル化が行われ得る。パケットにオーバーヘッド削減を行うか否かは、リンク層に伝達されたシグナリング情報（ｔｓｉｂ１５０１０）によって決定されてもよい。このシグナリング情報は、スケジューラ（ｔｓｉｂ１５０２０）によってカプセル化コントローラ（ｔｓｉｂ１５１８０）に伝達されてもよい。

ＲｏＨＣコンプレッサ（ｔｓｉｂ１５１４０）は、パケットストリームに対してオーバーヘッド削減を行うことができる。ＲｏＨＣコンプレッサ（ｔｓｉｂ１５１４０）は、パケットのヘッダーを圧縮する動作を行うことができる。オーバーヘッド削減には様々な方法を使用することができる。前述した、本発明が提案した方法によってオーバーヘッド削減を行うことができる。本実施例は、ＩＰストリームを仮定しており、ＲｏＨＣコンプレッサと表現したが、実施例によって名称は変更されてもよく、動作も、ＩＰストリームの圧縮に限定されず、全ての種類のパケットのオーバーヘッド削減がＲｏＨＣコンプレッサ（ｔｓｉｂ１５１４０）によって行われてもよい。

パケットストリーム構成ブロック（ｔｓｉｂ１５１５０）は、ヘッダーが圧縮されたＩＰパケットのうち、シグナリング領域に伝送される情報とパケットストリームに伝送される情報を分離することができる。パケットストリームに伝送される情報とは、ＤＰ領域に伝送される情報を意味し得る。シグナリング領域に伝送される情報は、シグナリング及び／又はコンテキストコントローラ（ｔｓｉｂ１５１６０）に伝達されてもよい。パケットストリームに伝送される情報はカプセル化部分に伝送されてもよい。

シグナリング及び／又はコンテキストコントローラ（ｔｓｉｂ１５１６０）は、シグナリング及び／又はコンテキスト（ｃｏｎｔｅｘｔ）情報を収集し、これをシグナリングマネジャーに伝達することができる。これは、シグナリング及び／又はコンテキスト情報をシグナリング領域に伝送するためである。

カプセル化部分は、パケットを物理層に伝達するのに適した形態でカプセル化する動作を行うことができる。カプセル化部分は、ＩＰストリームの数だけ構成することができる。

カプセル化バッファ（ｔｓｉｂ１５１７０）は、カプセル化のためにパケットストリームを受信する役割を果たすことができる。オーバーヘッド削減が行われた場合、オーバーヘッド削減されたパケットを受信し、オーバーヘッド削減が行われていない場合、入力されたＩＰパケットをそのまま受信することができる。

カプセル化コントローラ（ｔｓｉｂ１５１８０）は、入力されたパケットストリームに対してカプセル化を行うか否かを決定することができる。カプセル化が行われる場合、パケットストリームは分割／連鎖（ｔｓｉｂ１５１９０）に伝達されてもよい。カプセル化が行われない場合、パケットストリームは伝送バッファ（ｔｓｉｂ１５２３０）に伝達されてもよい。パケットをカプセル化するか否かは、リンク層に伝達されたシグナリング情報（ｔｓｉｂ１５０１０）によって決定されてもよい。このシグナリング情報は、スケジューラ（ｔｓｉｂ１５０２０）によってカプセル化コントローラ（ｔｓｉｂ１５１８０）に伝達されてもよい。

分割／連鎖ブロック（ｔｓｉｂ１５１９０）では、パケットに対して、前述した分割又は連鎖作業を行うことができる。すなわち、入力されたＩＰパケットが、リンク層の出力であるリンク層パケットよりも長い場合、一つのＩＰパケットを分割して多数個のセグメントに分けて複数個のリンク層パケットペイロードを作ることができる。また、入力されたＩＰパケットが、リンク層の出力であるリンク層パケットよりも短い場合、複数個のＩＰパケットをつなげて一つのリンク層パケットペイロードを作ることができる。

パケット構成テーブル（ｔｓｉｂ１５２００）は、分割及び／又は連鎖されたリンク層パケットの構成情報を有することができる。パケット構成テーブル（ｔｓｉｂ１５２００）の情報は、送信機と受信機が同じ情報を有することができる。パケット構成テーブル（ｔｓｉｂ１５２００）の情報が送信機と受信機で参照されてもよい。パケット構成テーブル（ｔｓｉｂ１５２００）の情報のインデックス値が当該リンク層パケットのヘッダーに含まれてもよい。

リンク層ヘッダー情報ブロック（ｔｓｉｂ１５２１０）は、カプセル化過程で発生するヘッダー情報を収集することができる。また、リンク層ヘッダー情報ブロック（ｔｓｉｂ１５２１０）は、パケット構成テーブル（ｔｓｉｂ１５２００）が有する情報を収集することができる。リンク層ヘッダー情報ブロック（ｔｓｉｂ１５２１０）は、リンク層パケットのヘッダーの構造に応じてヘッダー情報を構成することができる。

ヘッダーアタッチメントブロック（ｔｓｉｂ１５２２０）は、分割及び／又は連鎖されたリンク層パケットのペイロードにヘッダーを追加することができる。伝送バッファ（ｔｓｉｂ１５２３０）は、リンク層パケットを物理層のＤＰ（ｔｓｉｂ１５２４０）に伝達するためのバッファの役割を果たすことができる。

各ブロック乃至モジュール及び部分（ｐａｒｔ）は、リンク層において一つのモジュール／プロトコルとして構成されてもよく、複数個のモジュール／プロトコルとして構成されてもよい。

図１６は、本発明の一実施例に係る受信機側のリンク層の構造を示した図である。

本実施例は、ＩＰパケットを処理することを仮定した実施例である。受信機側のリンク層は、機能的な観点から、大きく、シグナリング情報を処理するリンク層シグナリング部分、オーバーヘッドプロセシング部分、及び／又はデカプセル化部分を含むことができる。また、受信機側のリンク層は、リンク層全体の動作に対する制御及びスケジューリングのためのスケジューラ、及び／又はリンク層の入出力部分などを含むことができる。

まず、物理層を介して伝送された各情報がリンク層に伝達され得る。リンク層は、各情報を処理して、送信側で処理する前の元の状態に戻した後、上位層に伝達することができる。この実施例において、上位層はＩＰ層であってもよい。

物理層で区分された特定のチャネル（ｔｓｉｂ１６０３０）を介して伝達された情報がリンク層シグナリング部分に伝達され得る。リンク層シグナリング部分は、物理層から受信されたシグナリング情報を判別し、リンク層の各部分に、判別されたシグナリング情報を伝達する役割を果たすことができる。

チャネルのためのバッファ（ｔｓｉｂ１６０４０）は、特定のチャネルを介して伝送されたシグナリング情報を受信するバッファの役割を果たすことができる。前述したように、物理層に物理的／論理的に区分された別途のチャネルが存在する場合、そのチャネルを介して伝送されたシグナリング情報を受信することができる。別途のチャネルから受信した情報が分割された状態である場合、完全な形態の情報になるまで、分割された情報を格納することができる。

シグナリングデコーダ／パーサ（ｔｓｉｂ１６０５０）は、特定のチャネルを介して受信されたシグナリング情報のフォーマットを確認し、リンク層で活用される情報を抽出することができる。特定のチャネルを介したシグナリング情報がエンコードされている場合にはデコーディングを行うことができる。また、実施例によって、当該シグナリング情報の無欠性などを確認してもよい。

シグナリングマネジャー（ｔｓｉｂ１６０６０）は、多数の経路を介して受信されたシグナリング情報を統合することができる。後述するシグナリングのためのＤＰ（ｔｓｉｂ１６０７０）を介して受信されたシグナリング情報もシグナリングマネジャー（ｔｓｉｂ１６０６０）で統合することができる。シグナリングマネジャー（ｔｓｉｂ１６０６０）は、リンク層内の各部分に必要なシグナリング情報を伝達することができる。例えば、オーバーヘッドプロセシング部分に、パケットのリカバリのためのコンテキスト情報などを伝達することができる。また、スケジューラ（ｔｓｉｂ１６０２０）に、制御のためのシグナリング情報を伝達することができる。

シグナリングのためのＤＰ（ｔｓｉｂ１６０７０）を介して、別途の特別なチャネルで受信されていない一般的なシグナリング情報が受信されてもよい。ここで、シグナリングのためのＤＰとは、ＰＬＳ又はＬ１などを意味し得る。ここで、ＤＰは、ＰＬＰ（ＰｈｙｓｉｃａｌＬａｙｅｒＰｉｐｅ）と呼ぶこともできる。受信バッファ（ｔｓｉｂ１６０８０）は、シグナリングのためのＤＰから伝送されたシグナリング情報を受信するバッファの役割を果たすことができる。シグナリング情報のデカプセル化ブロック（ｔｓｉｂ１６０９０）では、受信されたシグナリング情報をデカプセル化することができる。デカプセル化されたシグナリング情報は、デカプセル化バッファ（ｔｓｉｂ１６１００）を経てシグナリングマネジャー（ｔｓｉｂ１６０６０）に伝達されてもよい。前述したように、シグナリングマネジャー（ｔｓｉｂ１６０６０）は、シグナリング情報を組み合わせてリンク層内の必要な部分に伝達することができる。

スケジューラ（ｔｓｉｂ１６０２０）は、リンク層に含まれた多数のモジュールの動作を決定し、制御する役割を果たすことができる。スケジューラ（ｔｓｉｂ１６０２０）は、受信機情報（ｔｓｉｂ１６０１０）及び／又はシグナリングマネジャー（ｔｓｉｂ１６０６０）から伝達された情報を用いて、リンク層の各部分を制御することができる。また、スケジューラ（ｔｓｉｂ１６０２０）は、各部分の動作モードなどを決定することができる。ここで、受信機情報（ｔｓｉｂ１６０１０）は、受信機が予め格納していた情報を意味し得る。スケジューラ（ｔｓｉｂ１６０２０）は、チャネル切り替えなどのようにユーザが変更する情報も用いて、制御に活用することができる。

デカプセル化部分は、物理層のＤＰ（ｔｓｉｂ１６１１０）から受信されたパケットをフィルタし、当該パケットのタイプに応じてパケットを分離する役割を果たすことができる。デカプセル化部分は、物理層で同時にデコードできるＤＰの数だけ構成することができる。

デカプセル化バッファ（ｔｓｉｂ１６１１０）は、デカプセル化のために物理層からパケットストリームを受信するバッファの役割を果たすことができる。デカプセル化コントローラ（ｔｓｉｂ１６１３０）は、入力されたパケットストリームに対してデカプセル化を行うか否かを決定することができる。デカプセル化が行われる場合、パケットストリームはリンク層ヘッダーパーサ（ｔｓｉｂ１６１４０）に伝達されてもよい。デカプセル化が行われない場合、パケットストリームは出力バッファ（ｔｓｉｂ１６２２０）に伝達されてもよい。デカプセル化を行うか否かを決定するにおいて、スケジューラ（ｔｓｉｂ１６０２０）から伝達されたシグナリング情報を活用することができる。

リンク層ヘッダーパーサ（ｔｓｉｂ１６１４０）は、伝達されたリンク層パケットのヘッダーを確認することができる。ヘッダーを確認することによって、リンク層パケットのペイロードに含まれているＩＰパケットの構成を確認することができる。例えば、ＩＰパケットは、分割されているか、又は連鎖されていてもよい。

パケット構成テーブル（ｔｓｉｂ１６１５０）は、分割及び／又は連鎖で構成されるリンク層パケットのペイロード情報を含むことができる。パケット構成テーブル（ｔｓｉｂ１６１５０）の情報は、送信機と受信機が同じ情報を有することができる。パケット構成テーブル（ｔｓｉｂ１６１５０）の情報が送信機と受信機で参照されてもよい。リンク層パケットに含まれたインデックス情報に基づいて、再結合（ｒｅａｓｓｅｍｂｌｙ）に必要な値を見つけることができる。

再結合ブロック（ｒｅａｓｓｅｍｂｌｙ）（ｔｓｉｂ１６１６０）は、分割及び／又は連鎖で構成されたリンク層パケットのペイロードを元のＩＰストリームのパケットとして構成することができる。セグメントを一つに集めて一つのＩＰパケットとして再構成したり、連鎖されたパケットを分離して複数個のＩＰパケットストリームとして再構成したりすることができる。再結合されたＩＰパケットは、オーバーヘッドプロセシング部分に伝達されてもよい。

オーバーヘッドプロセシング部分は、送信機で行われたオーバーヘッド削減の逆過程として、オーバーヘッド削減されたパケットを元のパケットに戻す動作を行うことができる。この動作をオーバーヘッドプロセシングと呼ぶことができる。オーバーヘッドプロセシング部分は、物理層で同時にデコードできるＤＰの数だけ構成することができる。

パケットリカバリバッファ（ｔｓｉｂ１６１７０）は、オーバーヘッドプロセシングを行うためにデカプセル化されたＲｏＨＣパケット乃至ＩＰパケットを受信するバッファの役割を果たすことができる。

オーバーヘッドコントローラ（ｔｓｉｂ１６１８０）は、デカプセル化されたパケットに対してパケットリカバリ及び／又は圧縮解除を行うか否かを決定することができる。パケットリカバリ及び／又は圧縮解除が行われる場合、パケットストリームリカバリブロック（ｔｓｉｂ１６１９０）にパケットが伝達されてもよい。パケットリカバリ及び／又は圧縮解除が行われない場合、パケットは出力バッファ（ｔｓｉｂ１６２２０）に伝達されてもよい。パケットリカバリ及び／又は圧縮解除を行うか否かは、スケジューラ（ｔｓｉｂ１６０２０）によって伝達されたシグナリング情報に基づいて決定されてもよい。

パケットストリームリカバリブロック（ｔｓｉｂ１６１９０）は、送信機で分離されたパケットストリームと、パケットストリームのコンテキスト情報とを統合する動作を行うことができる。これは、ＲｏＨＣデコンプレッサ（ｔｓｉｂ１６２１０）で処理可能なように、パケットストリームを復旧する過程であり得る。この過程で、シグナリング及び／又はコンテキストコントローラ（ｔｓｉｂ１６２００）からシグナリング情報及び／又はコンテキスト情報を受信することができる。シグナリング及び／又はコンテキストコントローラ（ｔｓｉｂ１６２００）は、送信機から伝達されたシグナリング情報を判別し、当該コンテキストＩＤに合うストリームにマップできるようにパケットストリームリカバリブロック（ｔｓｉｂ１６１９０）にシグナリング情報を伝達することができる。

ＲｏＨＣデコンプレッサ（ｔｓｉｂ１６２１０）は、パケットストリームのパケットのヘッダーを復旧することができる。パケットストリームのパケットは、ヘッダーが復旧されることによって元のＩＰパケットの形態に復旧され得る。すなわち、ＲｏＨＣデコンプレッサ（ｔｓｉｂ１６２１０）はオーバーヘッドプロセシングを行うことができる。

出力バッファ（ｔｓｉｂ１６２２０）は、ＩＰ層（ｔｓｉｂ１６２３０）に出力ストリームを伝達するに先立ち、バッファの役割を果たすことができる。

本発明が提案する送信機と受信機のリンク層は、前述したようなブロック乃至モジュールを含むことができる。これを通じて、リンク層が上位層と下位レイヤに関係なく独立して動作することができ、オーバーヘッド削減を効率的に行うことができ、上／下位層などによって支援可能な機能の確定／追加／除去が容易となり得る。

図１７は、本発明の一実施例に係る、リンク層を介したシグナリング伝送構造を示した図である（送／受信側）。

本発明では、一つの周波数バンド内に複数個のサービスプロバイダ（放送会社）がサービスを提供することができる。また、サービスプロバイダは、複数個のサービスを伝送することができ、一つのサービスは１つ以上のコンポーネントを含むことができる。ユーザは、サービス単位でコンテンツを受信することを考慮することができる。

本発明は、ＩＰハイブリッド放送を支援するために、複数個のセッションベースの伝送プロトコルが使用されることを仮定する。各プロトコルの伝送構造に基づいて、そのシグナリング経路（ｐａｔｈ）で伝達されるシグナリング情報を決定することができる。各プロトコルは、実施例によって様々な名称が付与されてもよい。

図示された送信側のデータ構造（ｔｓｉｂ１７０１０）において、サービスプロバイダ（Ｂｒｏａｄｃａｓｔｅｒｓ）は複数個のサービス（Ｓｅｒｖｉｃｅ＃１，＃２，…）を提供することができる。一般に、サービスに対するシグナリングは、一般的な伝送セッションを介して伝送することができるが（ＳｉｇｎａｌｉｎｇＣ）、実施例によって、特定のセッション（ｄｅｄｉｃａｔｅｄｓｅｓｓｉｏｎ）を介して伝送してもよい（ＳｉｇｎａｌｉｎｇＢ）。

サービスデータ及びサービスシグナリング情報は、伝送プロトコルに従ってカプセル化することができる。実施例によってＩＰ／ＵＤＰが使用されてもよい。実施例によってＩＰ／ＵＤＰ層でのシグナリング（ＳｉｇｎａｌｉｎｇＡ）が追加されてもよい。このシグナリングは省略できる。

ＩＰ／ＵＤＰで処理されたデータはリンク層に入力されてもよい。リンク層では、前述したように、オーバーヘッド削減及び／又はカプセル化過程を行うことができる。ここで、リンク層シグナリングが追加されてもよい。リンク層シグナリングにはシステムパラメータなどが含まれてもよい。リンク層シグナリングについては前述した。

このような処理を経たサービスデータ及びシグナリング情報は、物理層でＰＬＰを介して処理されてもよい。ここで、ＰＬＰはＤＰと呼ぶこともできる。図示された実施例では、ベースＤＰ／ＰＬＰが使用される場合を想定しているが、実施例によってベースＤＰ／ＰＬＰなしに一般的なＤＰ／ＰＬＰのみで伝送が行われてもよい。

図示された実施例では、ＦＩＣ、ＥＡＣなどの特定のチャネル（ｄｅｄｉｃａｔｅｄｃｈａｎｎｅｌ）が使用されている。ＦＩＣを介して伝達されるシグナリングをＦＩＴ（ＦａｓｔＩｎｆｏｒｍａｔｉｏｎＴａｂｌｅ）、ＥＡＣを介して伝達されるシグナリングをＥＡＴ（ＥｍｅｒｇｅｎｃｙＡｌｅｒｔＴａｂｌｅ）と呼ぶことができる。ＦＩＴは、前述したＳＬＴと同一であってもよい。このような特定のチャネルは、実施例によって使用されなくてもよい。特定のチャネル（Ｄｅｄｉｃａｔｅｄｃｈａｎｎｅｌ）が構成されていない場合、ＦＩＴとＥＡＴは、一般的なリンク層シグナリング伝送方法によって伝送されるか、又は他のサービスデータのようにＩＰ／ＵＤＰを経てＰＬＰに伝送されてもよい。

実施例によって、システムパラメータには、送信機関連パラメータ、サービスプロバイダ関連パラメータなどが含まれてもよい。リンク層シグナリングには、ＩＰヘッダー圧縮関連コンテキスト情報、及び／又は当該コンテキストが適用されるデータに対する識別情報が含まれてもよい。上位層のシグナリングには、ＩＰ住所、ＵＤＰ番号、サービス／コンポーネント情報、緊急警報（Ｅｍｅｒｇｅｎｃｙａｌｅｒｔ）関連情報、サービスシグナリングに対するＩＰ／ＵＤＰ住所、セッションＩＤなどが含まれてもよい。詳細な実施例については前述した。

図示された受信側のデータ構造（ｔｓｉｂ１７０２０）において、受信機は、全てのＰＬＰをデコードすることなく、シグナリング情報を活用して当該サービスに対するＰＬＰのみをデコードすることができる。

まず、ユーザが、受信しようとするサービスを選択又は変更すると、受信機は、当該周波数にチューニングをし、当該チャネルと関連してＤＢなどに格納している受信機情報を読み込むことができる。受信機のＤＢなどに格納されている情報は、最初のチャネルスキャンの際にＳＬＴを読み込んで構成されてもよい。

ＳＬＴを受信し、当該チャネルの情報を受信した後、既存に格納されていたＤＢを更新し、ユーザが選択したサービスの伝送経路及びコンポーネント情報を取得したり、このような情報を取得するために必要なシグナリングが伝送される経路に対する情報を取得したりする。ＳＬＴのバージョン情報などを用いて、当該情報の変更がないと判断される場合には、デコーディング又はパーシング手順を省略することができる。

受信機は、当該放送ストリームにおいて、ＰＬＰの物理シグナリングをパースし、当該ＰＬＰ内にＳＬＴ情報があるかどうかを把握することができる（図示せず）。これは、物理シグナリングの特定のフィールドを介して指示されてもよい。ＳＬＴ情報に接近することによって、特定のサービスのサービス層シグナリングが伝送される位置に接近することができる。このサービス層シグナリングは、ＩＰ／ＵＤＰにカプセル化されて伝送セッションを介して伝達されてもよい。このサービス層シグナリングを用いて、当該サービスを構成するコンポーネントに対する情報を取得することができる。詳細なＳＬＴ−ＳＬＳの構造は、前述した通りである。

すなわち、ＳＬＴを用いて、現在のチャネルに伝送されている多数のパケットストリーム及びＰＬＰのうち、当該サービスの受信に必要な上位層シグナリング情報（サービスシグナリング情報）を受信するための伝送経路情報を取得することができる。この伝送経路情報には、ＩＰ住所、ＵＤＰポート番号、セッションＩＤ、ＰＬＰＩＤなどが含まれてもよい。ここで、実施例によって、ＩＰ／ＵＤＰ住所は、ＩＡＮＡ又はシステムで予め指定されている値を使用してもよい。このような情報は、ＤＢ及び共有メモリ接近などの方法で取得されてもよい。

リンク層シグナリングとサービスデータが同一のＰＬＰを介して伝送されるか、又は一つのＰＬＰのみが運用されている場合、ＰＬＰを介して伝達されるサービスデータは、リンク層シグナリングがデコードされる間、臨時にバッファなどの装置に格納されてもよい。

受信しようとするサービスに対するサービスシグナリング情報を用いて、当該サービスが実際に伝送される経路の情報を取得することができる。また、受信するＰＬＰに対するオーバーヘッド削減などの情報を用いて、受信されるパケットストリームに対してデカプセル化及びヘッダーリカバリを行うことができる。

図示された実施例（ｔｓｉｂ１７０２０）では、ＦＩＣ、ＥＡＣが使用され、ベースＤＰ／ＰＬＰの概念が想定された。前述したように、ＦＩＣ、ＥＡＣ、ベースＤＰ／ＰＬＰの概念は活用されなくてもよい。

以下では、説明の便宜のためにＭＩＳＯ又はＭＩＭＯ方式は２つのアンテナを使用するが、本発明は、２つ以上のアンテナを使用するシステムに適用されてもよい。本発明は、特定用途に要求される能力を達成しながら、受信機の複雑度を最小化するために最適化された物理プロファイル（又は、システム）を提案する。本発明の一実施例に係る物理プロファイル（ＰＨＹｐｒｏｆｉｌｅ）（ベース（ｂａｓｅ）、ハンドヘルド（ｈａｎｄｈｅｌｄ）、アドバンスド（ａｄｖａｎｃｅｄ）プロファイル）は、該当する受信機が具現しなければならない全ての構造のサブセットであり、大部分の機能ブロックを共有するが、特定ブロック及び／又はパラメータではやや異なる。システム発展のために、ヒューチャープロファイルは、ＦＥＦ（ｆｕｔｕｒｅｅｘｔｅｎｓｉｏｎｆｒａｍｅ）を介して、単一ＲＦ（ｒａｄｉｏｆｒｅｑｕｅｎｃｙ）チャネルに存在するプロファイルとマルチプレクスされてもよい。本発明の一実施例に係るベースプロファイル及びハンドヘルドプロファイルは、ＭＩＭＯが適用されないプロファイルを意味し、アドバンスドプロファイルは、ＭＩＭＯが適用されるプロファイルを意味する。ベースプロファイルは、地上波放送サービス及びモバイル放送サービスの両方に対するプロファイルとして用いることができる。すなわち、ベースプロファイルは、モバイルプロファイルを含むプロファイルの概念を定義するために用いることができる。また、アドバンスドプロファイルは、ＭＩＭＯを有するベースプロファイルに対するアドバンスドプロファイルとＭＩＭＯを有するハンドヘルドプロファイルに対するアドバンスドプロファイルとに区別できる。そして、本発明のプロファイルは、設計者の意図によって変更されてもよい。

次の用語及び定義を本発明に適用することができる。次の用語及び定義は、設計によって変更されてもよい。

補助ストリーム：ヒューチャー拡張（ｆｕｔｕｒｅｅｘｔｅｎｓｉｏｎ、将来の拡張）のために又は放送社やネットワーク運営者の要求によって用い得るまだ定義されていない変調及びコーディングのデータを伝達するセルのシーケンス

ベースデータパイプ（ｂａｓｅｄａｔａｐｉｐｅ）：サービスシグナリングデータを伝達するデータパイプ

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

セル（ｃｅｌｌ）：ＯＦＤＭ伝送の一つのキャリアによって伝達される変調値

コーディングブロック（ｃｏｄｅｄｂｌｏｃｋ）：ＰＬＳ１データのＬＤＰＣエンコードされたブロック又はＰＬＳ２データのＬＤＰＣエンコードされたブロックのうちの一つ

データパイプ（ｄａｔａｐｉｐｅ）：１つ又は複数のサービス又はサービスコンポーネントを伝達し得るサービスデータ又は関連したメタデータを伝達する物理層（ｐｈｙｓｉｃａｌｌａｙｅｒ）における論理チャネル

データパイプユニット（ＤＰＵ，ｄａｔａｐｉｐｅｕｎｉｔ）：データセルをフレームにおけるデータパイプに割り当て得る基本ユニット

データシンボル（ｄａｔａｓｙｍｂｏｌ）：プリアンブルシンボルでないフレームにおけるＯＦＤＭシンボル（フレームシグナリングシンボル及びフレームエッジ（ｅｄｇｅ）シンボルはデータシンボルに含まれる。）

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

ダミーセル（ｄｕｍｍｙｃｅｌｌ）：ＰＬＳ（ｐｈｙｓｉｃａｌｌａｙｅｒｓｉｇｎａｌｌｉｎｇ）シグナリング、データパイプ、又は補助ストリームのために使用されずに残っている容量を満たすために用いられる擬似ランダム値を伝達するセル

ＥＡＣ（ｅｍｅｒｇｅｎｃｙａｌｅｒｔｃｈａｎｎｅｌ、非常警報チャネル）：ＥＡＳ情報データを伝達するフレームの一部

フレーム（ｆｒａｍｅ）：プリアンブルから始まってフレームエッジシンボルで終了する物理層（ｐｈｙｓｉｃａｌｌａｙｅｒ）タイムスロット

フレーム反復単位（ｆｒａｍｅｒｅｐｅｔｉｔｉｏｎｕｎｉｔ）：スーパーフレーム（ｓｕｐｅｒ−ｆｒａｍｅ）で８回反復されるＦＥＦを含む、同一の又は異なる物理プロファイルに属するフレームの集合

ＦＩＣ（ｆａｓｔｉｎｆｏｒｍａｔｉｏｎｃｈａｎｎｅｌ、高速情報チャネル）：サービスと当該ベースデータパイプとの間におけるマッピング情報を伝達するフレームでの論理チャネル

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

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

フレームシグナリングシンボル（ｆｒａｍｅｓｉｇｎａｌｉｎｇｓｙｍｂｏｌ）：ＰＬＳデータの一部を伝達する、ＦＦＴサイズ、保護区間（ｇｕａｒｄｉｎｔｅｒｖａｌ）、及びスキャッタ（ｓｃａｔｔｅｒｅｄ）パイロットパターンの特定組合せにおいてフレームの先頭で用いられるより高いパイロット密度を有するＯＦＤＭシンボル

フレームエッジシンボル（ｆｒａｍｅｅｄｇｅｓｙｍｂｏｌ）：ＦＦＴサイズ、保護区間、及びスキャッタパイロットパターンの特定組合せにおいてフレームの末尾で用いられるより高いパイロット密度を有するＯＦＤＭシンボル

フレームグループ（ｆｒａｍｅ−ｇｒｏｕｐ）：スーパーフレームにおいて同じ物理プロファイルタイプを有する全てのフレームの集合

ヒューチャー拡張フレーム（ｆｕｔｕｒｅｅｘｔｅｎｔｉｏｎｆｒａｍｅ、将来の拡張フレーム）：プリアンブルで始まる、将来の拡張に用いられ得るスーパーフレーム内での物理層（ｐｈｙｓｉｃａｌｌａｙｅｒ）タイムスロット

ヒューチャーキャスト（ｆｕｔｕｒｅｃａｓｔ）ＵＴＢシステム：入力が一つ以上のＭＰＥＧ２−ＴＳ、ＩＰ（Ｉｎｔｅｒｎｅｔｐｒｏｔｏｃｏｌ）、又は一般ストリームであり、出力がＲＦシグナルである提案された物理層放送システム

入力ストリーム（ｉｎｐｕｔｓｔｒｅａｍ）：システムによって最終ユーザに伝達されるサービスの調和（ｅｎｓｅｍｂｌｅ）のためのデータのストリーム

正常（ｎｏｒｍａｌ）データシンボル：フレームシグナリングシンボル及びフレームエッジシンボルを除くデータシンボル

物理プロファイル（ＰＨＹｐｒｏｆｉｌｅ）：該当する受信機が具現すべき全ての構造のサブセット

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

ＰＬＳ１：ＰＬＳ２をデコードするために必要なパラメータだけでなく、システムに関する基本情報を伝達する固定されたサイズ、コーディング、変調を有するＦＳＳ（ｆｒａｍｅｓｉｇｎａｌｌｉｎｇｓｙｍｂｏｌ）で伝達されるＰＬＳデータの一番目の集合

ＮＯＴＥ：ＰＬＳ１データはフレームグループのデューレーション（ｄｕｒａｔｉｏｎ）において一定である。

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

ＰＬＳ２動的（ｄｙｎａｍｉｃ）データ：フレームごとに動的に変化するＰＬＳ２データ

ＰＬＳ２静的（ｓｔａｔｉｃ）データ：フレームグループのデューレーションにおいて静的であるＰＬＳ２データ

プリアンブルシグナリングデータ（ｐｒｅａｍｂｌｅｓｉｇｎａｌｉｎｇｄａｔａ）：プリアンブルシンボルによって伝達され、システムの基本モードを確認するために用いられるシグナリングデータ

プリアンブルシンボル（ｐｒｅａｍｂｌｅｓｙｍｂｏｌ）：基本ＰＬＳデータを伝達し、フレームの先頭に位置する固定された長さのパイロットシンボル

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

将来の使用（ｆｕｔｕｒｅｕｓｅ）のためにリザーブド（ｒｅｓｅｒｖｅｄ）：現在文書では定義されないが、将来に定義可能である。

スーパーフレーム（ｓｕｐｅｒｆｒａｍｅ）：８個のフレーム反復単位の集合

時間インターリービングブロック（ｔｉｍｅｉｎｔｅｒｌｅａｖｉｎｇｂｌｏｃｋ、ＴＩｂｌｏｃｋ）：時間インターリーバメモリーの一つの用途に該当する、時間インターリービングが実行されるセルの集合

時間インターリービンググループ（ｔｉｍｅｉｎｔｅｒｌｅａｖｉｎｇｇｒｏｕｐ，ＴＩｇｒｏｕｐ）：整数、動的に変化するＸＦＥＣＢＬＯＣＫの数で構成された、特定データパイプに対する動的容量割り当てが実行される単位

ＮＯＴＥ：時間インターリービンググループは一つのフレームに直接マップされてもよく、複数のフレームにマップされてもよい。時間インターリービンググループは、一つ以上の時間インターリービングブロックを含むことができる。

タイプ１データパイプ（Ｔｙｐｅ１ＤＰ）：全てのデータパイプがフレームにＴＤＭ（ｔｉｍｅｄｉｖｉｓｉｏｎｍｕｌｔｉｐｌｅｘｉｎｇ）方式でマップされるフレームのデータパイプ

タイプ２データパイプ（Ｔｙｐｅ２ＤＰ）：全てのデータパイプがフレームにＦＤＭ方式でマップされるフレームのデータパイプ

ＸＦＥＣＢＬＯＣＫ：一つのＬＤＰＣＦＥＣＢＬＯＣＫの全てのビットを伝達するＮ_cellsセルの集合

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

本発明の一実施例に係る、次世代放送サービスに対する放送信号送信装置は、入力フォーマットブロック（ＩｎｐｕｔＦｏｒｍａｔｂｌｏｃｋ）１０００、ＢＩＣＭ（ｂｉｔｉｎｔｅｒｌｅａｖｅｄｃｏｄｉｎｇ＆ｍｏｄｕｌａｔｉｏｎ）ブロック１０１０、フレームビルディングブロック（Ｆｒａｍｅｂｕｉｌｄｉｎｇｂｌｏｃｋ）１０２０、ＯＦＤＭ（ｏｒｔｈｏｇｏｎａｌｆｒｅｑｕｅｎｃｙｄｉｖｉｓｉｏｎｍｕｌｔｉｐｌｅｘｉｎｇ）生成ブロック（ＯＦＤＭｇｅｎｅｒａｔｉｏｎｂｌｏｃｋ）１０３０、及びシグナリング生成ブロック１０４０を含むことができる。放送信号送信装置の各ブロックの動作について説明する。

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

入力フォーマットブロック１０００は、それぞれの入力ストリームを、独立したコーディング及び変調が適用される一つ又は複数のデータパイプにデマチルプレクスすることができる。データパイプは堅固性（ｒｏｂｕｓｔｎｅｓｓ）制御のための基本単位であり、これはＱｏＳ（ＱｕａｌｉｔｙｏｆＳｅｒｖｉｃｅ）に影響を及ぼす。一つ又は複数のサービス又はサービスコンポーネントを一つのデータパイプによって伝達することができる。データパイプは、一つ又は複数のサービス又はサービスコンポーネントを伝達し得るサービスデータ又は関連メタデータを伝達する物理層における論理チャネルである。

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

物理層への入力は、一つ又は複数のデータストリームで構成されてもよい。それぞれのデータストリームは、一つのデータパイプによって伝達される。入力フォーマットブロック１０００は、一つ又はそれ以上の物理的経路（ｐｈｙｓｉｃａｌｐａｔｈ又はＤＰ）を介して入力されるデータストリームをＢＢＦ（ｂａｓｅｂａｎｄｆｒａｍｅ）に変換することができる。この場合、入力フォーマットブロック１０００は、入力データ（ＴＳ又はＩＰ入力ストリーム）に対して伝送効率を増加させるためにヌルパケット削除（ｎｕｌｌｐａｃｋｅｔｄｅｌｅｔｉｏｎ）又はヘッダー圧縮（ｈｅａｄｅｒｃｏｍｐｒｅｓｓｉｏｎ）を行うことができる。受信機は、ヘッダーの特定部分に対する先験的な（ａｐｒｉｏｒｉ）情報を有することができることから、この知られた情報（ｋｎｏｗｎｉｎｆｏｒｍａｔｉｏｎ）は送信機で削除されてもよい。ヌルパケット削除ブロック３０３０は、ＴＳ入力ストリームの場合にのみ利用可能である。

ＢＩＣＭブロック１０１０で、パリティ（ｐａｒｉｔｙ）データは誤り訂正のために追加され、エンコードされたビットストリームは複素数値星状シンボルにマップされる。当該シンボルは当該データパイプに用いられる特定インターリービング深さにわたってインターリーブされる。アドバンスドプロファイルにおいて、ＢＩＣＭブロック１０１０でＭＩＭＯエンコーディングが実行され、追加データ経路がＭＩＭＯ伝送のために出力に追加される。

フレームビルディングブロック１０２０は、一つのフレーム内で入力データパイプのデータセルをＯＦＤＭシンボルにマップし、周波数領域ダイバーシティのために、特に、周波数選択的フェーディングチャネルを防止するために周波数インターリービングを行うことができる。フレームビルディングブロックは、遅延補償（ｄｅｌａｙｃｏｍｐｅｎｓａｔｉｏｎ）ブロック、セルマッパー（ｃｅｌｌｍａｐｐｅｒ）及び周波数インターリーバ（ｆｒｅｑｕｅｎｃｙｉｎｔｅｒｌｅａｖｅｒ）を含むことができる。

遅延補償（ｄｅｌａｙｃｏｍｐｅｎｓａｔｉｏｎ）ブロックは、データパイプと該当するＰＬＳデータとの間のタイミングを調節して、送信機側でデータパイプと該当するＰＬＳデータとの間の同時性（ｃｏ−ｔｉｍｅ）を保障することができる。入力フォーマットブロック及びＢＩＣＭブロックによるデータパイプの遅延を扱うことにより、ＰＬＳデータはデータパイプの分だけ遅れる。ＢＩＣＭブロックの遅延は主に時間インターリーバに起因する。インバンド（Ｉｎ−ｂａｎｄ）シグナリングデータは、次の時間インターリービンググループの情報を、シグナルされるデータパイプよりも１フレーム先立って伝達されるようにすることができる。遅延補償（ｄｅｌａｙｃｏｍｐｅｎｓａｔｉｏｎ）ブロックは、それに合わせてインバンド（Ｉｎ−ｂａｎｄ）シグナリングデータを遅延させる。

セルマッパーは、ＰＬＳ、データパイプ、補助ストリーム、及びダミーセルなどを、フレーム内でＯＦＤＭシンボルのアクティブ（ａｃｔｉｖｅ）キャリアにマップすることができる。セルマッパーの基本機能は、それぞれのデータパイプ、ＰＬＳセルに対する時間インターリービングによって生成されたデータセルを、存在するなら、一つのフレーム内でそれぞれのＯＦＤＭシンボルに該当するアクティブ（ａｃｔｉｖｅ）ＯＦＤＭセルのアレイにマップすることである。（ＰＳＩ（ｐｒｏｇｒａｍｓｐｅｃｉｆｉｃｉｎｆｏｒｍａｔｉｏｎ）／ＳＩのような）サービスシグナリングデータは個別的に収集されてデータパイプによって送られてもよい。セルマッパーは、フレーム構造の構成及びスケジューラによって生成された動的情報（ｄｙｎａｍｉｃｉｎｆｏｒｍａｔｉｏｎ）に応じて動作する。周波数インターリーバは、セルマッパーから受信されたデータセルをランダムにインターリーブして周波数ダイバーシティを提供することができる。また、周波数インターリーバは、単一フレームで最大のインターリービング利得を得るために、異なるインターリービングシード（ｓｅｅｄ）順序を用いて、２つの順次的なＯＦＤＭシンボルで構成されたＯＦＤＭシンボルペア（ｐａｉｒ、対）で動作することができる。

ＯＦＤＭ生成ブロック１０３０は、フレームビルディングブロックによって生成されたセルによってＯＦＤＭキャリアを変調し、パイロットを挿入し、伝送のための時間領域信号を生成する。また、当該ブロックは順次に保護区間を挿入し、ＰＡＰＲ減少処理を適用して最終ＲＦ信号を生成する。

具体的には、プリアンブルを各フレームの先頭に挿入した後、ＯＦＤＭ生成ブロック１０３０は、サイクリックプレフィックス（ｃｙｃｌｉｃｐｒｅｆｉｘ）を保護区間として有する既存のＯＦＤＭ変調を適用することができる。アンテナスペースダイバーシティのために、分散された（ｄｉｓｔｒｉｂｕｔｅｄ）ＭＩＳＯ方式が送信機にわたって適用される。また、ＰＡＰＲ（ｐｅａｋ−ｔｏ−ａｖｅｒａｇｅｐｏｗｅｒｒａｔｉｏ）方式が時間領域で実行される。柔軟なネットワーク方式のために、本発明は、様々なＦＦＴサイズ、保護区間長さ、当該パイロットパターンの集合を提供する。

また、本発明は、放送サービスを提供する２つ以上の異なる放送送信／受信システムのデータが同じＲＦ信号帯域で同時に伝送され得るように、時間領域で複数の放送送信／受信システムの信号をマルチプレクスすることができる。この場合、２つ以上の異なる放送送信／受信システムは、それぞれ異なる放送サービスを提供するシステムのことをいう。それぞれ異なる放送サービスは、地上波放送サービス、モバイル放送サービスなどを意味することができる。

シグナリング生成ブロック１０４０は、各機能ブロックの動作に用いられる物理層シグナリング情報を生成することができる。当該シグナリング情報はまた、関心のあるサービスが受信機側で適切に復旧されるように伝送される。本発明の一実施例に係るシグナリング情報は、ＰＬＳデータを含むことができる。ＰＬＳは、受信機で物理層（ｐｈｙｓｉｃａｌｌａｙｅｒ）データパイプに接続し得る手段を提供する。ＰＬＳデータは、ＰＬＳ１データ及びＰＬＳ２データで構成される。

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

ＰＬＳ２データは、データパイプ及びシステムに関するより一層詳細なＰＬＳデータを伝達するＦＳＳで伝送される、ＰＬＳデータの二番目の集合である。ＰＬＳ２は、受信機が所望のデータパイプをデコードするのに十分な情報を提供するパラメータを含む。さらに、ＰＬＳ２シグナリングは、ＰＬＳ２静的（ｓｔａｔｉｃ）データ（ＰＬＳ２−ＳＴＡＴデータ）及びＰＬＳ２動的（ｄｙｎａｍｉｃ）データ（ＰＬＳ２−ＤＹＮデータ）の２種類のパラメータで構成される。ＰＬＳ２静的（ｓｔａｔｉｃ）データは、フレームグループのデューレーションの間に静的（ｓｔａｔｉｃ）であるＰＬＳ２データであり、ＰＬＳ２動的（ｄｙｎａｍｉｃ）データは、フレームごとに動的（ｄｙｎａｍｉｃ）に変化するＰＬＳ２データである。ＰＬＳデータに関する詳細な内容は後述する。

前述したブロックは省略されてもよく、類似又は同一の機能を有するブロックによって代替されてもよい。

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

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

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

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

（ａ）は、ＭＩＭＯが適用されないプロファイル（又は、システム）に適用されるＢＩＣＭブロックを示し、（ｂ）は、ＭＩＭＯが適用されるプロファイル（又は、システム）のＢＩＣＭブロックを示す。

ＭＩＭＯが適用されないＢＩＣＭブロック及びＭＩＭＯが適用されるＢＩＣＭブロックは、それぞれのデータパイプを処理するための複数の処理ブロックを含むことができる。

ＭＩＭＯが適用されないＢＩＣＭブロック及びＭＩＭＯが適用されるＢＩＣＭブロックのそれぞれの処理ブロックについて説明する。

ＭＩＭＯが適用されないＢＩＣＭブロックの処理ブロック５０００は、データＦＥＣエンコーダ５０１０、ビットインターリーバ５０２０、星状マッパー（ｍａｐｐｅｒ）５０３０、ＳＳＤ（ｓｉｇｎａｌｓｐａｃｅｄｉｖｅｒｓｉｔｙ）エンコーディングブロック５０４０、時間インターリーバ５０５０を含むことができる。

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

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

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

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

ＭＩＭＯが適用されるＢＩＣＭブロックの処理ブロック５０００−１は、データＦＥＣエンコーダ、ビットインターリーバ、星状マッパー、及び時間インターリーバを含むことができる。

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

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

セルワードデマルチプレクサ５０１０−１は、アドバンスドプロファイルのデータパイプがＭＩＭＯ処理のために単一セルワードストリームを二重セルワードストリームに分離するために用いられる。

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

ＭＩＭＯエンコーディングは、送信機及び受信機の両方で少なくとも２つのアンテナを必要とする２×２ＭＩＭＯシステムのために意図される。本発明のＭＩＭＯエンコーディングモードは、ＦＲ−ＳＭ（ｆｕｌｌ−ｒａｔｅｓｐａｔｉａｌｍｕｌｔｉｐｌｅｘｉｎｇ）と定義できる。ＦＲ−ＳＭエンコーディングは、受信機側における比較的小さい複雑度の増加で容量増加を提供することができる。また、本発明のＭＩＭＯエンコーディング方式は、アンテナ極性配置を制限しない。

ＭＩＭＯ処理は、データパイプレベルで適用される。星状マッパー出力のペア（ｐａｉｒ、対）であるＮＵＱ（ｅ_1,i及びｅ_2,i）は、ＭＩＭＯエンコーダの入力として供給される。ＭＩＭＯエンコーダ出力ペア（ｐａｉｒ、対）（ｇ１，ｉ及びｇ２，ｉ）は、それぞれの送信アンテナの同じキャリアｋ及びＯＦＤＭシンボルｌによって伝送される。

前述したブロックは、省略されてもよく、類似又は同一の機能を有するブロックに代替されてもよい。

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

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

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

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

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

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

スクランブラは、ＢＣＨエンコーディング及び短縮（ｓｈｏｒｔｅｎｉｎｇ）及びパンクチャリングが行われたＬＤＰＣエンコーディングの前にＰＬＳ１データ及びＰＬＳ２データをスクランブルすることができる。

ＢＣＨエンコーディング／ゼロ挿入ブロックは、ＰＬＳ保護のための短縮されたＢＣＨコードを用いて、スクランブルされたＰＬＳ１／２データに外部エンコーディングを行い、ＢＣＨエンコーディング後にゼロビットを挿入することができる。ＰＬＳ１データに対してのみ、ゼロ挿入の出力ビットをＬＤＰＣエンコーディング前にパーミュテート（ｐｅｒｍｕｔａｔｉｏｎ）することができる。

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

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

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

ビットインターリーバ６０１０は、それぞれの短縮及びパンクチャされたＰＬＳ１データ及びＰＬＳ２データをインターリーブすることができる。

星状マッパー６０２０は、ビットインターリーブされたＰＬＳ１データ及びＰＬＳ２データを星状にマップすることができる。

図２１は、本発明の一実施例に係るＰＬＳのビットインターリービング過程を示す図である。

それぞれの短縮及びパンクチャされたＰＬＳ１及びＰＬＳ２コーディングブロックは、図２１に示すように、１ビットずつインターリーブされる。追加パリティビットの各ブロックは、同じブロックインターリービング構造でインターリーブされるが、別途にインターリーブされる。

ＢＰＳＫの場合、実数及び虚数の部分でＦＥＣコーディングビットを複製するために、ビットインターリービングのための２つのブランチが存在する。それぞれのコーディングブロックは、上位ブランチにまず書き込まれる。ビットは、サイクリックシフト値フロアー（Ｎ_FEC／２）でモジュロＮ_FEC加算を適用することによって、下位ブランチにマッチされる。ここで、Ｎ_FECは、短縮及びパンクチャリング後のそれぞれのＬＤＰＣコーディングブロックの長さである。

ＱＳＰＫ、ＱＡＭ−１６、ＮＵＱ−６４のような他の変調の場合、ＦＥＣコーディングビットは列方向に順次にインターリーバに書き込まれる。ここで、列の数は変調次数と同一である。

読み出し動作で、一つの星状シンボルに対するビットは順次に行方向に読み出され、ビットデマルチプレクサブロックに入力される。これらの動作は列の最後まで続く。

それぞれのビットインターリービンググループは、星状マッピング前にグループで１ビットずつデマチルプレクスされる。変調次数によって、２つのマッピング規則がある。ＢＰＳＫ及びＱＰＳＫの場合、一つのシンボルにおいてビットの信頼度は同一である。したがって、ビットインターリービングブロックから読み出されたビットグループは、いかなる動作無しでＱＡＭシンボルにマッチされる。

ＱＡＭシンボルにマップされたＱＡＭ−１６及びＮＵＱ−６４の場合、動作の規則が図２１（ａ）に説明されている。図２１（ａ）に示すように、ｉは、ビットインターリービングにおいて列インデックスに該当するビットグループインデックスである。

図２１は、ＱＡＭ−１６に対するビットデマチルプレクシング規則を示す。この動作は、全てのビットグループがビットインターリービングブロックから読み出されるまで続く。

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

本発明の一実施例に係る次世代放送サービスに対する放送信号受信装置は、図１８を参照して説明した、次世代放送サービスに対する放送信号送信装置に対応し得る。

本発明の一実施例に係る、次世代放送サービスに対する放送信号受信装置は、同期及び復調モジュール（ｓｙｎｃｈｒｏｎｉｚａｔｉｏｎ＆ｄｅｍｏｄｕｌａｔｉｏｎｍｏｄｕｌｅ）９０００、フレームパーシングモジュール（ｆｒａｍｅｐａｒｓｉｎｇｍｏｄｕｌｅ）９０１０、デマッピング及びデコーディングモジュール（ｄｅｍａｐｐｉｎｇ＆ｄｅｃｏｄｉｎｇｍｏｄｕｌｅ）９０２０、出力プロセッサ（ｏｕｔｐｕｔｐｒｏｃｅｓｓｏｒ）９０３０、及びシグナリングデコーディングモジュール（ｓｉｇｎａｌｉｎｇｄｅｃｏｄｉｎｇｍｏｄｕｌｅ）９０４０を含むことができる。放送信号受信装置の各モジュールの動作について説明する。

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

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

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

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

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

本発明の一実施例に係るフレームは、複数のＯＦＤＭシンボル及びプリアンブルにさらに分離される。（ｄ）に示すように、フレームは、プリアンブル、一つ以上のＦＳＳ、正常データシンボル、及びＦＥＳを含む。

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

ＦＳＳの主な目的は、ＰＬＳデータを伝達することである。高速同期化及びチャネル推定のために、それによるＰＬＳデータの高速デコーディングのために、ＦＳＳは、正常データシンボルよりも高密度のパイロットパターンを有する。ＦＥＳは、ＦＳＳと全く同じパイロットを有するが、これは、ＦＥＳの直前のシンボルに対して外挿（ｅｘｔｒａｐｏｌａｔｉｏｎ）無しに、ＦＥＳ内における周波数だけの補間（ｉｎｔｅｒｐｏｌａｔｉｏｎ）及び時間的補間（ｔｅｍｐｏｒａｌｉｎｔｅｒｐｏｌａｔｉｏｎ）を可能にする。

図２３は、本発明の一実施例に係る、フレームのシグナリング階層構造（ｓｉｇｎａｌｉｎｇｈｉｅｒａｒｃｈｙｓｔｒｕｃｔｕｒｅ）を示す。

図２３は、シグナリング階層構造を示しているが、これは、３つの主要部分であるプリアンブルシグナリングデータ１１０００、ＰＬＳ１データ１１０１０、及びＰＬＳ２データ１１０２０に分割される。毎フレームごとにプリアンブル信号によって伝達されるプリアンブルの目的は、フレームの基本伝送パラメータ及び伝送タイプを示すことである。ＰＬＳ１は、受信機が関心のあるデータパイプに接続するためのパラメータを含むＰＬＳ２データに接続してデコードできるようにする。ＰＬＳ２は、毎フレームごとに伝達され、２つの主要部分である、ＰＬＳ２−ＳＴＡＴデータとＰＬＳ２−ＤＹＮデータとに分割される。ＰＬＳ２データの静的（ｓｔａｔｉｃ）及び動的（ｄｙｎａｍｉｃ）部分には、必要時にパディングが続く。

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

ＦＦＴ＿ＳＩＺＥ：当該２ビットフィールドは、下記の表１で説明しているとおり、フレームグループ内で現フレームのＦＦＴサイズを示す。

ＧＩ＿ＦＲＡＣＴＩＯＮ：当該３ビットフィールドは、下記の表２で説明しているとおり、現スーパーフレームにおける保護区間の一部（ｆｒａｃｔｉｏｎ）の値を示す。

ＥＡＣ＿ＦＬＡＧ：当該１ビットフィールドは、ＥＡＣが現フレームに提供されるか否かを示す。当該フィールドが１に設定されると、ＥＡＳが現フレームに提供される。当該フィールドが０に設定されると、ＥＡＳが現フレームで伝達されない。当該フィールドは、スーパーフレーム内で動的（ｄｙｎａｍｉｃ）に切り替えることができる。

ＰＩＬＯＴ＿ＭＯＤＥ：当該１ビットフィールドは、現フレームグループで現フレームに対してパイロットモードがモバイルモードか又は固定モードかを示す。当該フィールドが０に設定されると、モバイルパイロットモードが用いられる。当該フィールドが１に設定されると、固定パイロットモードが用いられる。

ＰＡＰＲ＿ＦＬＡＧ：当該１ビットフィールドは、現フレームグループで現フレームに対してＰＡＰＲ減少が用いられるか否かを示す。当該フィールドが１に設定されると、トーン予約（ｔｏｎｅｒｅｓｅｒｖａｔｉｏｎ）がＰＡＰＲ減少のために用いられる。当該フィールドが０に設定されると、ＰＡＰＲ減少が用いられない。

ＲＥＳＥＲＶＥＤ：当該７ビットフィールドは、将来の使用のためにリザーブされる。

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

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

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

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

ＰＡＹＬＯＡＤ＿ＴＹＰＥ：当該３ビットフィールドは、フレームグループで伝達されるペイロードデータのフォーマットを示す。ＰＡＹＬＯＡＤ＿ＴＹＰＥは、表３に示すようにシグナルされる。

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

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

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

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

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

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

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

次のループ（ｌｏｏｐ）は、各フレームタイプの長さ及びＦＲＵ構成を示すＦＲＵ＿ＰＨＹ＿ＰＲＯＦＩＬＥ、ＦＲＵ＿ＦＲＡＭＥ＿ＬＥＮＧＴＨ、ＦＲＵ＿ＧＩ＿ＦＲＡＣＴＩＯＮ、ＲＥＳＥＲＶＥＤで構成される。ループ（ｌｏｏｐ）サイズは、ＦＲＵ内で４個の物理プロファイル（ＦＥＦを含む）がシグナルされるように固定される。ＮＵＭ＿ＦＲＡＭＥ＿ＦＲＵが４よりも小さいと、使用されないフィールドはゼロで埋められる。

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

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

ＦＲＵ＿ＧＩ＿ＦＲＡＣＴＩＯＮ：当該３ビットフィールドは、関連したＦＲＵの（ｉ＋１）番目のフレームの保護区間の一部の値を示す。ＦＲＵ＿ＧＩ＿ＦＲＡＣＴＩＯＮは、表７によってシグナルされる。

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

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

ＰＬＳ２＿ＦＥＣ＿ＴＹＰＥ：当該２ビットフィールドは、ＰＬＳ２保護によって用いられるＦＥＣタイプを示す。ＦＥＣタイプは、表４によってシグナルされる。ＬＤＰＣコードに関する詳細な内容は後述する。

ＰＬＳ２＿ＭＯＤ：当該３ビットフィールドは、ＰＬＳ２によって用いられる変調タイプを示す。変調タイプは、表５によってシグナルされる。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

以下、ＰＬＳ２−ＳＴＡＴデータのフィールドについて具体的に説明する。

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

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

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

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

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

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

ＢＡＳＥ＿ＤＰ＿ＩＤ：当該６ビットフィールドは、管理層で用いられる（ＰＳＩ／ＳＩのような）サービスシグナリングデータを伝達するデータパイプを示す。ＢＡＳＥ＿ＤＰ＿ＩＤが示すデータパイプは、サービスデータと共にサービスシグナリングデータを伝達する正常データパイプであるか、サービスシグナリングデータのみを伝達する専用データパイプであってもよい。

ＤＰ＿ＦＥＣ＿ＴＹＰＥ：当該２ビットフィールドは、関連したデータパイプによって用いられるＦＥＣタイプを示す。ＦＥＣタイプは、下記の表８によってシグナルされる。

ＤＰ＿ＣＯＤ：当該４ビットフィールドは、関連したデータパイプによって用いられるコードレート（ｃｏｄｅｒａｔｅ）を示す。コードレート（ｃｏｄｅｒａｔｅ）は、下記の表９によってシグナルされる。

ＤＰ＿ＭＯＤ：当該４ビットフィールドは、関連したデータパイプによって用いられる変調を示す。変調は、下記の表１０によってシグナルされる。

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

次のフィールドは、ＰＨＹ＿ＰＲＯＦＩＬＥがアドバンスドプロファイルを示す０１０と同一である場合にのみ現れる。

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

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

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

ＤＰ＿ＴＩ＿ＴＹＰＥの値が１に設定されると、当該フィールドは、それぞれの時間インターリービンググループがマップされるフレームの数であるＰ_Iを示し、時間インターリービンググループ当たりに１つの時間インターリービングブロックが存在する（Ｎ_TI＝１）。当該２ビットフィールドで許容されるＰＩの値は、下記の表１２に定義される。

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

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

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

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

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

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

ＤＰ＿ＩＮＢＡＮＤ＿ＭＯＤＥ：当該２ビットフィールドは、現データパイプがインバンド（Ｉｎ−ｂａｎｄ）シグナリング情報を伝達するか否かを示す。インバンド（Ｉｎ−ｂａｎｄ）シグナリングタイプは、下記の表１４によってシグナルされる。

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

ＤＰ＿ＣＲＣ＿ＭＯＤＥ：当該２ビットフィールドは、ＣＲＣエンコーディングが入力フォーマットブロックで用いられるか否かを示す。ＣＲＣモードは、下記の表１６によってシグナルされる。

ＤＮＰ＿ＭＯＤＥ：当該２ビットフィールドは、ＤＰ＿ＰＡＹＬＯＡＤ＿ＴＹＰＥがＴＳ（「００」）に設定される場合に、関連したデータパイプによって用いられるヌルパケット削除モードを示す。ＤＮＰ＿ＭＯＤＥは、下記の表１７によってシグナルされる。ＤＰ＿ＰＡＹＬＯＡＤ＿ＴＹＰＥがＴＳ（「００」）でなければ、ＤＮＰ＿ＭＯＤＥは００の値に設定される。

ＩＳＳＹ＿ＭＯＤＥ：当該２ビットフィールドは、ＤＰ＿ＰＡＹＬＯＡＤ＿ＴＹＰＥがＴＳ（「００」）に設定される場合に、関連したデータパイプによって用いられるＩＳＳＹモードを示す。ＩＳＳＹ＿ＭＯＤＥは、下記の表１８によってシグナルされる。ＤＰ＿ＰＡＹＬＯＡＤ＿ＴＹＰＥがＴＳ（「００」）でなければ、ＩＳＳＹ＿ＭＯＤＥは００の値に設定される。

ＨＣ＿ＭＯＤＥ＿ＴＳ：当該２ビットフィールドは、ＤＰ＿ＰＡＹＬＯＡＤ＿ＴＹＰＥがＴＳ（「００」）に設定される場合に、関連したデータパイプによって用いられるＴＳヘッダー圧縮モードを示す。ＨＣ＿ＭＯＤＥ＿ＴＳは、下記の表１９によってシグナルされる。

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

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

ＲＥＳＥＲＶＥＤ：当該８ビットフィールドは、将来の使用のためにリザーブされる。

次のフィールドは、ＦＩＣ＿ＦＬＡＧが１と同一である場合にのみ現れる。

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

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

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

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

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

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

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

図２６は、本発明の他の実施例に係るＰＬＳ２データを示す。

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

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

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

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

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

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

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

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

ＤＰ＿ＳＴＡＲＴ：当該１５ビット（又は、１３ビット）フィールドは、ＤＰＵアドレシング（ａｄｄｒｅｓｓｉｎｇ）技法を用いてデータパイプの最初の開始位置を示す。ＤＰ＿ＳＴＡＲＴフィールドは、下記の表２１に示すとおり、物理プロファイル及びＦＦＴサイズによって異なる長さを有する。

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

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

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

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

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

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

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

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

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

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

図２７は、本発明の一実施例に係るフレームの論理（ｌｏｇｉｃａｌ）構造を示す。

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

図２８は、本発明の一実施例に係るＰＬＳマッピングを示す。

ＰＬＳセルはＦＳＳのアクティブ（ａｃｔｉｖｅ）キャリアにマップされる。ＰＬＳの占めるセルの数によって、一つ以上のシンボルがＦＳＳと指定され、ＦＳＳの数Ｎ_FSSは、ＰＬＳ１におけるＮＵＭ＿ＦＳＳによってシグナルされる。ＦＳＳは、ＰＬＳセルを伝達する特殊なシンボルである。警告性及び遅延時間（ｌａｔｅｎｃｙ）はＰＬＳにおいて重大な事項であるが、ＦＳＳは、高いパイロット密度を有しているので、高速同期化、及びＦＳＳ内における周波数のみの補間（ｉｎｔｅｒｐｏｌｏａｔｉｏｎ）を可能にする。

ＰＬＳセルは、図示しているように、下方に向いて、ＦＳＳのアクティブ（ａｃｔｉｖｅ）キャリアにマップされる。ＰＬＳ１セルは最初に、一番目のＦＳＳの一番目のセルから始まって、セルインデックスの昇順でマップされる。ＰＬＳ２セルは、ＰＬＳ１の最後のセルの直後に続き、最初のＦＳＳの最後のセルインデックスまで下方に続けてマップされる。必要なＰＬＳセルの総数が、一つのＦＳＳのアクティブ（ａｃｔｉｖｅ）キャリアの数を超えると、マッピングは、次のＦＳＳに進み、最初のＦＳＳと全く同じ方式で続いて行われる。

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

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

上述したとおり、ＢＣＨエンコーディングがそれぞれのＢＢＦ（Ｋ_bchビット）に適用された後、ＬＤＰＣエンコーディングがＢＣＨ−エンコーディングされたＢＢＦ（Ｋ_ldpcビット＝Ｎ_bchビット）に適用される。

Ｎ_ldpcの値は６４８００ビット（ロングＦＥＣＢＬＯＣＫ）又は１６２００ビット（ショートＦＥＣＢＬＯＣＫ）である。

下記の表２２及び表２３は、ロングＦＥＣＢＬＯＣＫ及びショートＦＥＣＢＬＯＣＫのそれぞれに対するＦＥＣエンコーディングパラメータを示す。

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

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

ＬＤＰＣコードは、外部ＢＣＨエンコーディングの出力をエンコードするために用いられる。完成されたＢ_ldpc（ＦＥＣＢＬＯＣＫ）を生成するために、Ｐ_ldpc（パリティビット）がそれぞれのＩ_ldpc（ＢＣＨ−エンコードされたＢＢＦ）から組織的にエンコードされ、Ｉ_ldpcに付加される。完成されたＢ_ldpc（ＦＥＣＢＬＯＣＫ）は、次の式で表現される。

ロングＦＥＣＢＬＯＣＫ及びショートＦＥＣＢＬＯＣＫに対するパラメータは、上記の表２２及び表２３にそれぞれ与えられる。

ロングＦＥＣＢＬＯＣＫに対してＮ_ldpc−Ｋ_ldpcパリティビットを計算する具体的な手順は、次のとおりである。

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

２）パリティチェックマトリクスの住所の一番目の行で特定されたパリティビット住所において一番目の情報ビットｉ₀を累算（ａｃｃｕｍｕｌａｔｅ）する。パリティチェックマトリクスの住所の詳細な内容は後述する。例えば、比率１３／１５に対して、

３）次の３５９個の情報ビットｉ_s、ｓ＝１，２，…，３５９に対して、次の式を用いてパリティビット住所でｉ_sを累算（ａｃｃｕｍｕｌａｔｅ）する。

ここで、ｘは、一番目のビットｉ₀に該当するパリティビット累算器の住所を表し、Ｑ_ldpcは、パリティチェックマトリクスの住所で特定されたコードレート（ｃｏｄｅｒａｔｅ）依存定数である。上記例である、比率１３／１５に対する、したがって情報ビットｉ₁に対するＱ_ldpc＝２４に続いて、次の動作が実行される。

４）３６１番目の情報ビットｉ₃₆₀に対して、パリティビット累算器の住所は、パリティチェックマトリクスの住所の二番目の行に与えられる。同様の方式で、次の３５９個の情報ビットｉ_s、ｓ＝３６１，３６２，…，７１９に対するパリティビット累算器の住所は、式６から得られる。ここで、ｘは、情報ビットｉ₃₆₀に該当するパリティビット累算器の住所、すなわち、パリティチェックマトリクスの二番目の行のエントリを表す。

５）同様の方式で、３６０個の新しい情報ビットの全てのグループに対して、パリティチェックマトリクスの住所からの新しい行は、パリティビット累算器の住所を求めるのに用いられる。

全ての情報ビットが利用された後、最終パリティビットが次のように得られる。

６）ｉ＝１から始まって次の動作を順次に実行する。

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

表２４を表２５に代え、且つロングＦＥＣＢＬＯＣＫに対するパリティチェックマトリクスの住所を、ショートＦＥＣＢＬＯＣＫに対するパリティチェックマトリクスの住所に代える以外は、ショートＦＥＣＢＬＯＣＫに対する当該ＬＤＰＣエンコーディング手順は、ロングＦＥＣＢＬＯＣＫに対するｔＬＤＰＣエンコーディング手順に従う。

図２９は、本発明の一実施例に係る時間インターリービングを示す。

（ａ）乃至（ｃ）は、時間インターリービングモードの例を示す。

時間インターリーバは、データパイプレベルで動作する。時間インターリービングのパラメータは、それぞれのデータパイプに対して異なるように設定されてもよい。

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

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

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

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

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

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

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

時間インターリービングがデータフレームに利用されないと、次の時間インターリービンググループ、時間インターリービング動作、時間インターリービングモードは考慮されない。しかし、スケジューラからの動的（ｄｙｎａｍｉｃ）構成情報のための遅延補償（ｄｅｌａｙｃｏｍｐｅｎｓａｔｉｏｎ）ブロックは相変らず必要である。それぞれのデータパイプで、ＳＳＤ／ＭＩＭＯエンコーディングから受信したＸＦＥＣＢＬＯＣＫは、時間インターリービンググループにグループ化される。すなわち、それぞれの時間インターリービンググループは、整数個のＸＦＥＣＢＬＯＣＫの集合であり、動的（ｄｙｎａｍｉｃ）に変化する数のＸＦＥＣＢＬＯＣＫを含むはずである。インデックスｎの時間インターリービンググループに存在するＸＦＥＣＢＬＯＣＫの数はＮ_{xBLOCK_Group}（ｎ）と表し、ＰＬＳ２−ＤＹＮデータにおいてＤＰ＿ＮＵＭ＿ＢＬＯＣＫでシグナルされる。この時、Ｎ_{xBLOCK_Group}（ｎ）は、最小値０から、最大の値が１０２３である最大値Ｎ_{xBLOCK_Group_MAX}（ＤＰ＿ＮＵＭ＿ＢＬＯＣＫ＿ＭＡＸに該当）まで変化してもよい。

それぞれの時間インターリービンググループは、一つのフレームに直接マップされたり、Ｐ_I個のフレームにわたって拡散される。また、それぞれの時間インターリービンググループは、一つ以上（Ｎ_TI個）の時間インターリービングブロックに分離される。ここで、それぞれの時間インターリービングブロックは、時間インターリーバメモリーの一つの使用に該当する。時間インターリービンググループ内の時間インターリービングブロックは、若干の異なる数のＸＦＥＣＢＬＯＣＫを含むことができる。時間インターリービンググループが複数の時間インターリービングブロックに分離されると、時間インターリービンググループは一つのフレームにのみ直接マップされる。下記の表２６に示すように、時間インターリービングには３つのオプションがある（時間インターリービングを省略する追加オプションは除く）。

一般に、時間インターリーバは、フレーム生成過程以前にデータパイプデータに対するバッファとしても働くことができる。これは、それぞれのデータパイプに対して２個のメモリバンクによって達成される。一番目の時間インターリービングブロックは一番目のバンクに書き込まれる。一番目のバンクから読み出される間に、二番目の時間インターリービングブロックが二番目のバンクに書き込まれる。

時間インターリービングは、ツイストされた行−列ブロックインターリーバである。ｎ番目の時間インターリービンググループのｓ番目の時間インターリービングブロックに対して、列の数Ｎ_cがＮ_{xBLOCK_TI}（ｎ，ｓ）と同一であるが、時間インターリービングメモリの行の数Ｎ_rは、セルの数Ｎ_cellsと同一である（すなわち、Ｎ_r＝Ｎ_cells）。

図３０は、本発明の一実施例に係るツイストされた行−列ブロックインターリーバの基本動作を示す。

図３０（ａ）は、時間インターリーバにおける書き込み動作を示し、図３０（ｂ）は、時間インターリーバにおける読み出し動作を示す。（ａ）に示すように、一番目のＸＦＥＣＢＬＯＣＫは、時間インターリービングメモリの一番目の列に列方向に書き込まれ、二番目のＸＦＥＣＢＬＯＣＫは次の列に書き込まれ、このような動作がつながる。そして、インターリービングアレイで、セルが対角線方向に読み出される。（ｂ）に示すように、一番目の行から（最も左側列から始まって行に沿って右に）最後の行まで対角線方向読み出しが進行される間に、Ｎ_r個のセルが読み出される。具体的には、ｚ_{ｎ，ｓ，ｉ}（i＝０,...，Ｎ_ｒＮ_ｃ）が順次に読み出される時間インターリービングメモリセル位置であると仮定すれば、このようなインターリービングアレイでの読み出し動作は、下記の式のように、行インデックスＲ_{ｎ，ｓ，ｉ}、列インデックスＣ_{ｎ，ｓ，ｉ}、関連したツイストパラメータＴ_{ｎ，ｓ，ｉ}を算出することによって実行される。

ここで、Ｓ_{ｓｈｉｆｔ}は、Ｎ_{ｘＢＬＯＣＫ＿ＴＩ}（ｎ，ｓ）に関係なく対角線方向読み出し過程に対する共通シフト値であり、シフト値は下記の式のようにＰＬＳ２−ＳＴＡＴで与えられたＮ_{ｘＢＬＯＣＫ＿ＴＩ＿ＭＡＸ}によって決定される。

結果的に、読み出されるセル位置は、座標ｚ_{ｎ，ｓ，ｉ}＝Ｎ_ｒＣ_{ｎ，ｓ，ｉ}+Ｒ_{ｎ，ｓ，ｉ}によって算出される。

図３１は、本発明の他の実施例に係るツイストされた行−列ブロックインターリーバの動作を示す。

より具体的に、図３１は、Ｎ_{ｘＢＬＯＣＫ＿ＴＩ}（０，０）＝３、Ｎ_{ｘＢＬＯＣＫ＿ＴＩ}（１，０）＝６、Ｎ_{ｘＢＬＯＣＫ＿ＴＩ}（２，０）＝５であるとき、仮想ＸＦＥＣＢＬＯＣＫを含むそれぞれの時間インターリービンググループに対する時間インターリービングメモリでのインターリービングアレイを示す。

変数Ｎ_{ｘＢＬＯＣＫ＿ＴＩ}（ｎ，ｓ）＝Ｎ_ｒは、Ｎ’_{ｘＢＬＯＣＫ＿ＴＩ＿ＭＡＸ}より小さい又は等しいだろう。したがって、Ｎ_{ｘＢＬＯＣＫ＿ＴＩ}（ｎ，ｓ）に関係なく受信機側で単一メモリデインターリービングを達成するために、ツイストされた行−列ブロックインターリーバ用インターリービングアレイは仮想ＸＦＥＣＢＬＯＣＫを時間インターリービングメモリに挿入することによって、Ｎ_ｒ×Ｎ_ｃ＝Ｎ_{ｃｅｌｌｓ}×Ｎ'_{ｘＢＬＯＣＫ＿ＴＩ＿ＭＡＸ}のサイズに設定され、読み出し過程は次の式のようになされる。

時間インターリービンググループの数は３に設定される。時間インターリーバのオプションは、ＤＰ＿ＴＩ＿ＴＹＰＥ＝「０」、ＤＰ＿ＦＲＡＭＥ＿ＩＮＴＥＲＶＡＬ＝「１」、ＤＰ＿ＴＩ＿ＬＥＮＧＴＨ＝「１」、すなわち、ＮＴＩ＝１、ＩＪＵＭＰ＝１、ＰＩ＝１によってＰＬＳ２−ＳＴＡＴデータでシグナルされる。それぞれＮｃｅｌｌｓ＝３０であるＸＦＥＣＢＬＯＣＫの時間インターリービンググループ当たりの数は、それぞれのＮｘＢＬＯＣＫ＿ＴＩ（０，０）＝３、ＮｘＢＬＯＣＫ＿ＴＩ（１，０）＝６、ＮｘＢＬＯＣＫ＿ＴＩ（２，０）＝５によってＰＬＳ２−ＤＹＮデータでシグナルされる。ＸＦＥＣＢＬＯＣＫの最大数は、ＮｘＢＬＯＣＫ＿Ｇｒｏｕｐ＿ＭＡＸによってＰＬＳ２−ＳＴＡＴデータでシグナルされ、これは
につながる。

一つのＯＦＤＭシンボルに該当するデータ上で動作する周波数インターリーバの目的は、フレームビルダーから受信されたデータセルを無作為にインターリーブすることによって周波数ダイバーシティを提供することである。一つのフレームで最大インターリービング利得を得るために、２つの順次的なＯＦＤＭシンボルからなる全てのＯＦＤＭシンボルペアに対して異なるインターリービングシーケンスが用いられる。

したがって、本発明の一実施例に係る周波数インターリーバは、シンボルペアに対応するデータに適用するためのインターリービング住所を生成するためのインターリービング住所生成器を含むことができる。

図３２は、本発明の一実施例に係る各ＦＦＴモードによるメイン−ＰＲＢＳ生成器及びサブ−ＰＲＢＳ生成器で構成されたインターリービング住所生成器のブロックダイアグラムを示す図である。

（ａ）は、８ＫＦＦＴモードに対するインターリービング住所生成器のブロックダイアグラムを示し、（ｂ）は、１６ＫＦＦＴモードに対するインターリービング住所生成器のブロックダイアグラムを示し、（ｃ）は、３２ＫＦＦＴモードに対するインターリービング住所生成器のブロックダイアグラムを示す。

図３３は、本発明の一実施例に係る全てのＦＦＴモードに用いられるメイン−ＰＲＢＳを示す図である。

（ａ）は、メイン−ＰＲＢＳを示し、（ｂ）は、各ＦＦＴモードのためのパラメータＮｍａｘを示す。

図３４は、本発明の一実施例に係る周波数インターリービングのためのインターリービング住所及びＦＦＴモードに用いられるサブ−ＰＲＢＳを示す図である。

（ａ）は、サブ−ＰＲＢＳ生成器を示し、（ｂ）は、周波数インターリービングのためのインターリービング住所を示す。本発明の一実施例に係るサイクリックシフト値は、シンボルオフセットと呼ぶことができる。

図３５は、本発明の一実施例に係る時間インターリーバの書き込み（ｗｒｉｔｉｎｇ）動作を示す。

図３５は、２つのＴＩグループに対する書き込み（ｗｒｉｔｉｎｇ）動作を示す。

図面の左側に示すブロックは、ＴＩメモリ住所アレイ（ｍｅｍｏｒｙａｄｄｒｅｓｓａｒｒａｙ）を示し、図面の右側に示すブロックは、連続した２つのＴＩグループに対してそれぞれ仮想（ｖｉｒｔｕａｌ）ＦＥＣブロックがＴＩグループの最も前にそれぞれ２個及び１個が挿入された場合の書き込み（ｗｒｉｔｉｎｇ）動作を示す。

以下、ＰＬＰ（ＰｈｙｓｉｃａｌＬａｙｅｒＰｉｐｅ）モードによってコンボリューションインターリーバ（ＣｏｎｖｏｌｕｔｉｏｎＩｎｔｅｒｌｅａｖｅｒ，ＣＩ）とブロックインターリーバ（ＢｌｏｃｋＩｎｔｅｒｌｅａｖｅｒ，ＢＩ）を選択的に使用したり、両方とも使用する時間インターリーバの構造及び時間インターリービング方法を説明する。本発明の一実施例に係るＰＬＰは、上述したＤＰと同じ概念で使われる物理経路（ｐｈｙｓｉｃａｌｐａｔｈ）であり、呼称は設計者の意図によって変更可能である。

本発明の一実施例に係るＰＬＰモードは、放送信号送信機又は放送信号送信装置で処理するＰＬＰの個数によって、シングルＰＬＰ（ｓｉｎｇｌｅＰＬＰ）モード又はマルチプルＰＬＰ（ｍｕｌｔｉｐｌｅＰＬＰ）モードを含むことができる。シングルＰＬＰモードは、放送信号送信装置で処理するＰＬＰの個数が一つである場合を意味する。シングルＰＬＰモードはシングルＰＬＰと呼ぶこともできる。

マルチプルＰＬＰモードは、放送信号送信装置で処理するＰＬＰの個数が一つ以上である場合であり、マルチプルＰＬＰモードは、マルチプルＰＬＰと呼ぶこともできる。

本発明ではＰＬＰモードによって異なる時間インターリービング方法を適用する時間インターリービングをハイブリッド時間インターリービング（ＨｙｂｒｉｄＴｉｍｅＩｎｔｅｒｌｅａｖｉｎｇ）と呼ぶことができる。本発明の一実施例に係るハイブリッド時間インターリービングは、マルチプルＰＬＰモードの場合、各ＰＬＰ別に（或いは、ＰＬＰレベルで）適用される。

図３６は、ＰＬＰの個数によって適用するインターリービングタイプを表で示す図である。

本発明の一実施例に係る時間インターリーバは、ＰＬＰ＿ＮＵＭの値に基づいてインターリービングタイプ（Ｉｎｔｅｒｌｅａｖｉｎｇｔｙｐｅ）が決定されてもよい。ＰＬＰ＿ＮＵＭは、ＰＬＰモードを示すシグナリングフィールド（ｓｉｇｎａｌｉｎｇｆｉｅｌｄ）である。ＰＬＰ＿ＮＵＭの値が１である場合、ＰＬＰモードはシングルＰＬＰである。本発明の一実施例に係るシングルＰＬＰには、コンボリューションインターリーバ（ＣｏｎｖｏｌｕｔｉｏｎａｌＩｎｔｅｒｌｅａｖｅｒ，ＣＩ）のみが適用されてもよい。

ＰＬＰ＿ＮＵＭの値が１よりも大きい場合、ＰＬＰモードは、マルチプルＰＬＰである。本発明の一実施例に係るマルチプルＰＬＰには、コンボリューションインターリーバ（ＣｏｎｖｏｌｕｔｉｏｎａｌＩｎｔｅｒｌｅａｖｅｒ，ＣＩ）とブロックインターリーバ（ＢｌｏｃｋＩｎｔｅｒｌｅａｖｅｒ，ＢＩ）が適用されてもよい。この場合、コンボリューションインターリーバはインターフレームインターリービング（Ｉｎｔｅｒｆｒａｍｅｉｎｔｅｒｌｅａｖｉｎｇ）を行うことができ、ブロックインターリーバはイントラフレームインターリービング（Ｉｎｔｒａｆｒａｍｅｉｎｔｅｒｌｅａｖｉｎｇ）を行うことができる。

図３７は、上述したハイブリッド時間インターリーバ構造の第１実施例を含むブロック図である。

第１実施例に係るハイブリッド時間インターリーバは、ブロックインターリーバ（ＢＩ）とコンボリューションインターリーバ（ＣＩ）を含むことができる。本発明の時間インターリーバは、ＢＩＣＭチェーン（ＢＩＣＭｃｈａｉｎ）ブロックとフレームビルダー（ＦｒａｍｅＢｕｉｌｄｅｒ）との間に位置し得る。

図３７及び図３８に示すＢＩＣＭチェーンブロックは、図１９に示すＢＩＣＭブロックの処理ブロック５０００のうち時間インターリーバ５０５０以外のブロックを含むことができる。図３７及び図３８に示すフレームビルダーは、図１８のフレームビルディング１０２０ブロックと同じ役割を担うことができる。

上述したとおり、ハイブリッド時間インターリーバ構造の第１実施例に係るブロックインターリーバは、ＰＬＰ＿ＮＵＭ値によって適用／非適用が決定されてもよい。すなわち、ＰＬＰ＿ＮＵＭ＝１である場合、ブロックインターリーバは適用されず（ブロックインターリーバオフ（ｏｆｆ））、コンボリューションインターリーバだけ適用される。ＰＬＰ＿ＮＵＭ＞１の場合、ブロックインターリーバとコンボリューションインターリーバが全て適用（ブロックインターリーバオン（ｏｎ））されてもよい。ＰＬＰ＿ＮＵＭ＞１の場合、適用されるコンボリューションインターリーバの構造及び動作は、ＰＬＰ＿ＮＵＭ＝１の場合に適用されるコンボリューションインターリーバの構造及び動作と同一又は類似してもよい。

図３８は、上述したハイブリッド時間インターリーバ構造の第２実施例を含むブロック図である。

ハイブリッド時間インターリーバ構造の第２実施例に含まれる各ブロックの動作は、図３７で説明した内容と同一である。ハイブリッド時間インターリーバ構造の第２実施例に係るブロックインターリーバは、ＰＬＰ＿ＮＵＭ値によって適用／非適用が決定され得る。第２実施例に係るハイブリッド時間インターリーバの各ブロックは、本発明の実施例に係る動作を実行することができる。この時、ＰＬＰ＿ＮＵＭ＝１の場合とＰＬＰ＿ＮＵＭ＞１の場合に適用されるコンボリューションインターリーバの構造及び動作が互いに異なってもよい。

図３９は、ハイブリッド時間デインターリーバの構造の第１実施例を含むブロック図である。

第１実施例に係るハイブリッド時間デインターリーバは、上述した第１実施例に係るハイブリッド時間インターリーバの逆動作に相応する動作を行うことができる。したがって、図３９の第１実施例に係るハイブリッド時間デインターリーバは、コンボリューションデインターリーバ（Ｃｏｎｖｏｌｕｔｉｏｎａｌｄｅｉｎｔｅｒｌｅａｖｅｒ，ＣＤＩ）とブロックデインターリーバ（Ｂｌｏｃｋｄｅｉｎｔｅｒｌｅａｖｅｒ，ＢＤＩ）を含むことができる。

ＰＬＰ＿ＮＵＭ＞１の場合に適用されるコンボリューションデインターリーバの構造及び動作は、ＰＬＰ＿ＮＵＭ＝１の場合に適用されるコンボリューションデインターリーバの構造及び動作と同一又は類似してもよい。

ハイブリッド時間デインターリーバ構造の第１実施例に係るブロックデインターリーバは、ＰＬＰ＿ＮＵＭ値によって適用／非適用が決定されてもよい。すなわち、ＰＬＰ＿ＮＵＭ＝１の場合、ブロックデインターリーバは適用されず（ブロックデインターリーバオフ（ｏｆｆ））、コンボリューションデインターリーバだけ適用される。

ハイブリッド時間デインターリーバのコンボリューションデインターリーバは、インターフレームデインターリービング（Ｉｎｔｅｒｆｒａｍｅｄｅｉｎｔｅｒｌｅａｖｉｎｇ）を行うことができ、ブロックデインターリーバは、イントラフレームデインターリービング（Ｉｎｔｒａｆｒａｍｅｄｅｉｎｔｅｒｌｅａｖｉｎｇ）を行うことができる。インターフレームデインターリービング及びイントラフレームデインターリービングの具体的な内容は、前述した内容と同一である。

図３９及び図４０に示すＢＩＣＭデコーディング（ＢＩＣＭｄｅｃｏｄｉｎｇ）ブロックは、図３７及び図３８のＢＩＣＭチェーン（ＢＩＣＭｃｈａｉｎ）ブロックの逆動作を行うことができる。

図４０は、ハイブリッド時間デインターリーバの構造の第２実施例を含むブロック図である。

第２実施例に係るハイブリッド時間デインターリーバは、上述した第２実施例に係るハイブリッド時間インターリーバの逆動作に相応する動作を行うことができる。ハイブリッド時間デインターリーバ構造の第２実施例に含まれる各ブロックの動作は、図３９で説明した内容と同一であってもよい。

ハイブリッド時間デインターリーバ構造の第２実施例に係るブロックデインターリーバは、ＰＬＰ＿ＮＵＭ値によって適用／非適用が決定されてもよい。第２実施例に係るハイブリッド時間デインターリーバの各ブロックは、本発明の実施例に係る動作を実行することができる。この時、ＰＬＰ＿ＮＵＭ＝１の場合とＰＬＰ＿ＮＵＭ＞１の場合に適用されるコンボリューションデインターリーバの構造及び動作が互いに異なってもよい。

図４１は、本発明の一実施例に係る、次世代放送システムにおいて放送サービスに接近するためのシグナリング体系を示した図である。

放送システムでは、上述したようなＦＩＣを定義することができる。ＦＩＣは、放送サービスをスキャンしたり、放送サービスに対するリストを生成するのに必要な情報を含むことができる。ＦＩＣは、下位層シグナリング（ＬｏｗＬａｙｅｒＳｉｇｎａｌｉｎｇ；ＬＬＳ）に含ませることができ、ＬＬＳは、物理層のデータがサービス層まで処理される過程で、物理層とその上位層とを連結するのに必要なシグナリング情報を含むことができる。

ＦＩＣは、サービス層のシグナリング情報（サービス層シグナリング；ＳｅｒｖｉｃｅＬａｙｅｒＳｉｇｎａｌｉｎｇ；ＳＬＳ)を伝送するデータパイプ（ＤＰ）を識別する情報を含むことができる。サービス層シグナリングは、サービスシグナリングチャネル（ＳｅｒｖｉｃｅＳｉｇｎａｌｉｎｇＣｈａｎｎｅｌ；ＳＳＣ）という名称で使用することもできる。

物理層で放送データが処理され、物理層パラメータが取得されると、物理層パラメータを用いて、放送受信機はＦＩＣに接近することができる。放送受信機は、ＦＩＣの情報を用いてＳＳＣに接近することができる。放送受信機はＳＳＣに接近し、放送サービス及び／又は放送コンテンツを取得して視聴者に表出することができる。

本発明の第１シグナリング方法によれば、ＳＳＣは、サービスマップテーブル（ＳｅｒｖｉｅＭａｐＴａｂｌｅ；ＳＭＴ）及び／又はＣＭＴ（ＣｏｎｔｅｎｔＭａｐＴａｂｌｅ）を含むことができる。ＳＭＴは、放送サービスを説明する情報を提供するシグナリング構造である。放送受信機は、ＳＭＴの情報を用いて、放送サービスを取得するのに必要な情報を取得することができる。ＣＭＴは、放送サービスに含まれる放送コンテンツを説明する情報を提供するシグナリング構造である。放送受信機は、ＣＭＴを用いて放送コンテンツを取得するのに必要な情報を取得することができる。

第１シグナリング方法によれば、放送受信機がＳＳＣに接近し、ＳＭＴを優先的に取得することができる。放送受信機は、ＳＭＴで、放送サービスに含まれるデータを伝送するＲＯＵＴＥセッションに接近するための情報及び／又はＲＯＵＴＥセッションを説明する情報を含むＬＳＩＤ（ＬＣＴＳｅｓｓｉｏｎＩＤ；ＬＣＴＳｅｓｓｉｏｎＩｄｅｎｔｉｆｉｅｒＤｅｓｃｒｉｐｔｉｏｎ）に接近するための情報を取得することができる。

一方、放送受信機は、ＳＭＴのｓｅｒｖｉｃｅ＿ＩＤによって識別される放送サービスに含まれる放送コンテンツに対する情報を取得するためにＣＭＴに接近することができる。ＳＭＴからＣＭＴへの連結はｓｅｒｖｉｃｅ＿ＩＤによって行うことができる。ＣＭＴは、ＣＭＴが説明する一つ以上の放送コンテンツが属する放送サービスを識別するｓｅｒｖｉｃｅ＿ＩＤ情報を含むことができる。ＣＭＴは、放送コンテンツに含まれるリプレゼンテーション（Ｒｅｐｒｅｓｅｎｔａｔｉｏｎ）を識別する情報（例えば、ＲｅｐＩＤ）を含むことができる。リプレゼンテーションは、放送コンテンツを構成するコンポーネント（例えば、オーディオコンポーネント、ビデオコンポーネント、データコンポーネントなど）のためのデータを伝送する単位と定義することができる。放送受信機は、ＣＭＴで取得したＲｅｐＩＤを用いて、放送コンテンツに含まれる各要素を説明する情報を含むＭＰＤ（ＭｅｄｉａＰｒｅｓｅｎｔａｔｉｏｎＤｅｓｃｒｉｔｉｏｎ）に接近し、該当要素を取得し、放送コンテンツを再生することができる。放送受信機は、放送コンテンツに含まれるデータを取得するために、ＤＰ＿ｉｄ（データパイプを識別する情報）及び／又はＴＳＩ（ＴｒａｎｓｐｏｒｔＳｅｓｓｉｏｎＩｄｅｎｔｉｆｉｅｒ）情報を用いて、該当データを伝送する伝送セッションに接近することができる。

本発明の第２シグナリング方法によれば、ＳＳＣは、ＵＳＤ（ＵｓｅｒＳｅｒｖｉｃｅＤｅｓｃｒｉｐｔｉｏｎ）及び／又はＳＤＰ（ＳｅｒｖｉｃｅＤｅｓｃｒｉｐｔｉｏｎＰｒｏｔｏｃｏｌ）を含むことができる。ＵＳＤは、放送サービスを識別する情報、放送サービスを処理するために要求される受信機の能力を示す情報、放送サービスに接近するために参照される他のシグナリング情報に接近するための情報及び／又は受信機が放送サービスに含まれるコンポーネントの伝送モードを判断できるようにする情報を含むことができる。ＳＤＰは、ＵＳＤによって参照することができる。ＳＤＰは、一つ又はそれ以上の伝送セッションを説明する情報及び／又はＬＣＴセッションによって伝送されるデリバリオブジェクトに対する説明情報を含むことができる。放送サービスに含まれるメディアコンテンツのコンポーネントは、伝送セッションを通じて伝送できるが、ＳＤＰは、このような伝送セッションに接近するための情報を提供する。

第２シグナリング方法によれば、受信機はＵＳＤに接近し、ＭＰＤ及び／又はＳＤＰに接近する情報を取得し、ＭＰＤ及び／又はＳＤＰを取得する。受信機は、ＳＤＰの情報を用いて、放送サービスのデータを伝送する伝送セッションに接近することができる。受信機は、この過程でＳＤＰに含まれるＤＰ＿ｉｄ及び／又はＴＳＩを用いて、必要なデータを伝送する伝送セッションに接近することができる。受信機は、放送サービスに含まれる放送コンテンツを表出するのに必要な情報をＭＰＤで取得することができる。

図４２は、本発明の一実施例に係る、第１シグナリング方法と第２シグナリング方法とを比較する表を示す図である。

本発明が提案する放送システム内でのシグナリング体系は上述した通りであるが、細部的な構造は第１シグナリング方法と第２シグナリング方法との間で差があり得る。

例えば、ＭＰＤとＬＳＩＤは、第１シグナリング方法と第２シグナリング方法のいずれにおいても使用することができる。

一方、放送サービスを説明する情報を含むシグナリング構造は、第１シグナリング方法ではＳＭＴ形態と定義できるが、第２シグナリング方法ではＵＳＤ形態と定義することができる。

また、放送サービスに含まれるデータを伝送する伝送セッション（例えば、ＲＯＵＴＥセッション）に対する情報は、第１シグナリング方法ではＳＭＴに関連情報が含まれ得るが、第２シグナリング方法ではＳＤＰに該当の情報が含まれ得る。

ＬＣＴセッションに関する情報は、第１シグナリング方法と第２シグナリング方法のいずれにおいても、ＬＳＩＤを使用して伝送することができる。

放送コンテンツに含まれる各コンポーネントに関する情報は、第１シグナリング方法ではＣＭＴ形態のシグナリング構造を使用できるが、第２シグナリング方法ではＳＤＰ及び／又はＵＳＤ形態のシグナリング構造を使用することができる。具体的には、ＤＰを識別するＤＰ＿ｉｄ及び／又は伝送セッションを識別するＴＳＩ情報は、第１シグナリング方法ではＣＭＴに含まれ得るが、第２シグナリング方法ではＳＤＰに含まれ得る。一方、コンポーネントがブロードバンド（Ｂｒｏａｄｂａｎｄ；ＢＢ）又はブロードキャスト（Ｂｒｏａｄｃａｓｔ；ＢＣ）を介して伝送できるが、コンポーネントの伝送経路と関連する情報は、第１シグナリング方法ではＣＭＴに含まれ得るが、第２シグナリング方法ではＵＳＤに含まれ得る。

第１シグナリング方法と第２シグナリング方法との間の主要な相違点は、放送サービス、放送コンテンツ、及び／又はコンポーネントに対する情報を伝送する位置での差にある。

図４３は、本発明の一実施例に係る、放送システムで使用されるシグナリング方法を示した図である。

本発明の一実施例によれば、次世代放送システムのために、３ＧＰＰで定義されたｅＭＢＭＳ（Ｅｖｏｌｖｅｄ−ＭｕｌｔｉｍｅｄｉａＢｒｏａｄｃａｓｔ＆ＭｕｌｔｉｃａｓｔＳｅｒｖｉｃｅ)のシグナリング構造の一部を使用することができる。ｅＭＢＭＳは、移動放送網を介して放送サービスを提供するために制定された標準であって、ＯＦＤＭ及び／又はＬＴＥ通信ベースで放送サービスを提供することを目標とする。

本発明で使用されるＦＩＣは、サービス層の下位層で定義されるローレベルシグナリング（Ｌｏｗｌｅｖｅｌｓｉｇｎａｌｉｎｇ）であって、サービスのための最小限の情報を含む。ＵＳＤは、３ＧＰＰＭＢＭＳで定義されるＵＳＤ（ＵｓｅｒＳｅｒｖｉｃｅＤｅｓｃｒｉｐｔｉｏｎ）に該当し得る。ｅＭＢＭＳＭＰＤは、ｅＭＢＭＳを介して伝達されるコンポーネントのためのＤＡＳＨの構造に従うＭＰＤである。ＡｐｐＳｖｃＭＰＤは、３ＧＰＰ放送及び／又はユニキャスト（ｕｎｉｃａｓｔ）コンポーネントのためのＤＡＳＨの構造に従うＭＰＤである。３ＧＰＰＳＤＰは、ｅＭＢＭＳＦＬＵＴＥセッションのためのＩＥＴＦＳＤＰに該当し得る。フル（Ｆｕｌｌ）ＭＰＤは、各サービス（ＡＴＳＣサービス及び／又は３ＧＰＰサービス）の全てのコンポーネントのためのＤＡＳＨ構造に従うＭＰＤに該当し得る。ＡＴＳＣＳＤＰは、ＲＯＵＴＥセッションのためのＩＥＴＦＳＤＰに該当し得る。ＬＳＩＤは、ＬＣＴ識別子ディスクリプション（ＬＣＴＳｅｓｓｉｏｎＩｄｅｎｔｉｆｉｅｒＤｅｓｃｒｉｐｔｉｏｎ）であって、ＲＯＵＴＥセッション内のＬＣＴストリームに対する情報を含むことができる。

図面に示した（１）を参照すれば、ｅＭＢＭＳで定義されたＵＳＤを拡張し、放送システムで放送サービスをシグナルするのに使用することができる。

すなわち、既存のｅＭＢＭＳで使用されたアプリケーションサービスをシグナルするためのＭＰＤ（ＡｐｐＳｖｃＭＰＤ）、ｅＭＢＭＳをシグナルするためのＭＰＤ（ｅＭＢＭＳＭＰＤ）、及び／又は３ＤＰＰサービスをシグナルするためのＳＤＰはｅＭＢＭＳの規格に合わせて使用し、放送システムのために拡張されたシグナリング構造（ＡＴＳＣＥｘｔｅｎｓｉｏｎ）をＵＳＤに追加することができる。例えば、放送システムで放送サービスをシグナルするための放送システムＳＤＰ（ＡＴＳＣＳＤＰ）を定義し、放送システムＳＤＰの情報を通じて、放送受信機がＲＯＵＴＥセッション及び／又はＬＳＩＤに接近できるようにシグナリング構造を定義することができる。一方、拡張されたシグナリング構造は、ＭＰＥＧ−ＤＡＳＨで定義されるＭＰＤの全体を含むこともできる。

図面に示した（２）を参照すれば、ｅＭＢＭＳのＵＳＤを拡張することなく、放送システムのためのシグナリング構造を新しく定義してシグナリング体系に含ませることができる。

図面に示した（２−１）を参照すれば、放送システムのためのＵＳＤ（ＡＴＳＣ＿ＵＳＤ）を定義し、放送受信機は、放送システムのためのＵＳＤに含まれた情報を用いて、ＡＴＳＣＳＤＰ及び／又はフルＭＰＤに接近することができる。放送受信機は、ＡＴＳＣＳＤＰに含まれたＲＯＵＴＥセッションに対する情報を用いてＲＯＵＴＥセッションに接近したり、ＬＳＩＤを取得することができる。

図面に示した（２−２）を参照すれば、放送システムのためのＳＭＴ（ＬＧＥＳＭＴ）を定義し、放送受信機は、放送システムのためのＳＭＴに含まれた情報を用いてＲＯＵＴＥセッションに接近したり、ＬＳＩＤを取得することができる。一方、ＣＭＴ及び／又はフルＭＰＤ情報もさらに定義され、これらに含まれた情報とＳＭＴに含まれた情報を用いて、放送受信機は、放送サービス、放送コンテンツ、及び／又はコンポーネントに接近することができる。

本発明の一実施例によれば、３ＧＰＰｅＭＢＭＳで定義されたシグナリング方法を修正したり、特定シグナリング構造を追加して放送システムに適用することができる。この場合、既存に存在していたシグナリング構造を用いるので、新しい放送システムでもシグナリング構造の混乱を起こさないという効果がある。また、３ＧＰＰｅＭＢＭＳと次世代放送システムが類似する構造のシグナリング体系を共有するので、両者に従う放送サービスは共存し得るという効果がある。

放送システムでは、フルＭＰＤとＡＴＳＣＳＤＰを使用し、ｅＭＢＭＳＭＰＤ、ＡｐｐＳｖｃＭＰＤ及び／又は３ＧＰＰＭＰＤは使用しない場合がある。このようなシグナリング構造において、放送システムで提供される放送サービスのための全てのコンポーネントを説明したり、その位置を定義することができる。

一方、既存の３ＧＰＰでは、ｅＭＢＭＳＭＰＤ、ＡｐｐＳｖｃＭＰＤ及び／又は３ＧＰＰＳＤＰを使用し、フルＭＰＤ又はＡＴＳＣＳＤＰは使用しない場合がある。このようなシグナリング構造は、３ＧＰＰで提供される３ＧＰＰサービスのための全てのコンポーネントを説明したり、その位置を定義することができる。

一方、放送システムと３ＧＰＰサービスとが結合されたハイブリッド形態のサービスを考慮することもできる。ハイブリッドサービスのためのシステムでは、フルＭＰＤ、ＡＴＳＣＳＤＰ、ｅＭＢＭＳＭＰＤ、ＡｐｐＳｖｃＭＰＤ及び／又は３ＧＰＰＭＰＤを使用することができる。このようなシグナリング構造は、ハイブリッドサービスのためのシステムで提供されるサービスのための全てのコンポーネントを説明したり、その位置を定義することができる。

本発明で定義されるサービスは、０又はそれ以上のＲＯＵＴＥセッションで構成することができる。ＲＯＵＴＥセッションは、複数の周波数でスパン（ｓｐａｎ）しないように定義することができる。

図４４は、本発明の一実施例に係る、第４シグナリング方法によるシグナリング構造を示した図である。

シグナリング構造は、受信機がシグナリング情報を用いて、受信機が望むサービス／コンテンツを取得するための一連の過程で説明することができる。

受信機は、ＦＩＣを取得し、放送サービスをスキャンする情報を取得したり、放送サービスのためのシグナリング情報が伝送されるＳＳＣの位置情報又はＳＳＣをブートストラップ（ｂｏｏｔｓｔｒａｐｉｎｇ）するための情報を取得する。受信機は、ＳＳＣに対する位置情報又はブートストラッピング情報を用いてＳＳＣに接近し、ＳＳＣに含まれるＵＳＤ及び／又はＳＰＤに接近する。ＵＳＤは、ＡｐｐＳｖｃＭＰＤ又はｅＭＢＭＳＭＰＤを含むことができ、３ＧＰＰＳＤＰを含むことができる。３ＧＰＰＳＤＰは、受信機が特定ＲＯＵＴＥセッションに接近するのに必要な情報を含むことができる。受信機は、３ＧＰＰＳＤＰ内の情報を用いてＲＯＵＴＥセッションに接近し、該当セッションでＬＳＩＤを取得することができる。受信機は、ＬＳＩＤ内の情報を用いて、受信機が望むサービス／コンテンツに対するデータ／コンポーネントを伝送するＬＣＴセッション／ストリームに接近することができる。

図４５は、本発明の一実施例に係る、第３シグナリング方法によるシグナリング構造を示した図である。

受信機は、ＦＩＣを取得し、放送サービスをスキャンする情報を取得したり、放送サービスのためのシグナリング情報が伝送されるＳＳＣの位置情報又はＳＳＣをブートストラップするための情報を取得する。受信機は、ＳＳＣに対する位置情報又はブートストラッピング情報を用いてＳＳＣに接近し、ＳＳＣに含まれるＵＳＤに接近する。ＵＳＤは、ＡｐｐＳｖｃＭＰＤ又はｅＭＢＭＳＭＰＤを含むことができ、３ＧＰＰＳＤＰ、フルＭＰＤ、及び／又はＡＴＳＣＳＤＰを含むことができる。ＡｐｐＳｖｃＭＰＤ、ｅＭＢＭＳＭＰＤ及び／又は３ＧＰＰＭＰＤは、３ＧＰＰｅＭＢＭＳを用いるサービスのためのシグナリングとして使用することができる。フルＭＰＤ、ＡＴＳＣＳＤＰ、ＲＯＵＴＥセッション情報及び／又はＬＳＩＤは、ＡＴＳＣシステム（放送システム；ＡＴＳＣ３．０システム）を通じて提供されるサービスのためのシグナリングとして使用することができる。受信機は、ＡＴＳＣＳＤＰ内の情報を用いてＲＯＵＴＥセッションに接近し、該当セッションでＬＳＩＤを取得することができる。受信機は、ＬＳＩＤ内の情報を用いて、受信機が望むサービス／コンテンツに対するデータ／コンポーネントを伝送するＬＣＴセッション／ストリームに接近することができる。

受信機は、放送サービスの属性情報を取得したり、放送サービスの属性を決定するためにＵＳＤを使用することができる。受信機は、ＲＯＵＴＥセッションの位置を探すためにＳＤＰを使用し、放送サービス／コンテンツのコンポーネントを選択するためにＭＰＤを使用することができる。受信機は、選択されたコンポーネントが伝送される位置を探すためにＬＳＩＤを使用することができる。

図４６は、本発明の一実施例に係る、第３シグナリング方法によるシグナリング構造を具体的に示した図である。

ＦＩＣは、放送サービスを識別するサービス識別子情報（ｓｅｒｖｉｃｅ＿ｉｄ）を含むことができる。受信機が特定放送サービスを取得しようとする場合、ＦＩＣ内の情報を通じて、該当放送サービスに対する情報を伝送するＳＳＣに接近する。受信機は、ＳＳＣ内で伝送されるＡＴＳＣＵＳＤ情報を取得する。

ＡＴＳＣＵＳＤは、＠ａｐｐＳｅｒｖｉｃｅＤｅｓｃｒｉｐｔｉｏｎＵＲＩ情報、ｍｐｄＵＲＩ情報、＠ｓｅｓｓｉｏｎＤｅｓｃｒｉｐｔｉｏｎＵＲＩ情報、ａｔｓｃＳｅｒｖｉｃｅＩｄ情報、ｓｅｒｖｉｃｅＩｄ情報、ＤｅｌｉｖｅｒｙＭｅｔｈｏｄ情報、ｂａｓｅＰａｔｔｅｒｎ情報、ＤＰ＿ＩＤ情報、ａｔｓｃＳｄｐＵｒｉ情報、及び／又はｆｕｌｌＭｐｄＵｒｉ情報を含むことができる。

一つ又はそれ以上のコンポーネントが放送サービスのために存在することができ、これらを伝送するデータパイプの位置をＡＴＳＣＵＳＤを介して識別することができる。

ａｔｓｃＳｅｒｖｉｃｅＩｄ情報、ｓｅｒｖｉｃｅＩｄ情報、ＤｅｌｉｖｅｒｙＭｅｔｈｏｄ情報、ｂａｓｅＰａｔｔｅｒｎ情報、ＤＰ＿ＩＤ情報、ａｔｓｃＳｄｐＵｒｉ情報、及び／又はｆｕｌｌＭｐｄＵｒｉ情報は、放送システムのためのシグナリングのために、３ＧＰＰＵＳＤで拡張された情報に該当し得る。

受信機は、＠ａｐｐＳｅｒｖｉｃｅＤｅｓｃｒｉｐｔｉｏｎＵＲＩ情報が示すＵＲＩを通じて、ＡｐｐＳｖｃＭＰＤが提供される位置に接近することができる。＠ａｐｐＳｅｒｖｉｃｅＤｅｓｃｒｉｐｔｉｏｎＵＲＩ情報は、ＡｐｐＳｅｒｖｉｃｅエレメント内で定義され、特定アプリケーションサービスのためのＭＰＤが提供される位置を識別する。

受信機は、ｍｐｄＵＲＩ情報が示すＵＲＩを通じて、ｅＭＢＭＳＭＰＤが提供される位置に接近することができる。ｍｐｄＵＲＩ情報は、ｍｅｄｉａＰｒｅｓｅｎｔａｔｉｏｎＤｅｓｃｒｉｐｔｉｏｎエレメント内で定義され、ｅＭＢＭＳＭＰＤが提供される位置を識別する。

受信機は、＠ｓｅｓｓｉｏｎＤｅｓｃｒｉｐｔｉｏｎＵＲＩ情報が示すＵＲＩを通じて、３ＧＰＰＳＤＰが提供される位置に接近することができる。

受信機は、ＦＩＣ内のｓｅｒｖｉｃｅ＿ｉｄの値と、ＡＴＳＣＵＳＤ内の放送サービスを識別するａｔｓｃＳｅｒｖｉｃｅＩｄ情報の値とが一致することを確認し、受信機が接近しようとする放送サービスに対する情報を識別することができる。

受信機は、放送サービスと３サービスで共通的に使用されるサービスを識別するｓｅｒｖｉｃｅＩｄ情報を用いて、放送サービスと３ＧＰＰサービスで共通的に使用されるサービスに接近することができる。例えば、受信機は、ｓｅｒｖｉｃｅＩｄとＥＳＧ（ＥｌｅｃｔｒｏｎｉｃＳｅｒｖｉｃｅＧｕｉｄｅ）で使用されるｇｌｏｂａｌＳｅｒｖｉｃｅＩＤとを連関させ、ＥＳＧを取得することができる。

受信機は、ＤｅｌｉｖｅｒｙＭｅｔｈｏｄ情報が示す放送サービスを伝送する方法によって、該当放送サービスに接近することができる。

ｂａｓｅＰａｔｔｅｒｎ情報は、伝送モードによって、特定サービスが伝送される方法内でサービスの位置を識別するのに使用される基本的なパターンを示すことができる。

ＤＰ＿ＩＤ情報は、放送サービスのコンポーネントを伝送するデータパイプを識別する。

ａｔｓｃＳｄｐＵｒｉ情報は、ＡＴＳＣＳＤＰが伝送される位置を示すＵＲＩを識別する。

ｆｕｌｌＭｐｄＵｒｉ情報は、フルＭＰＤが伝送される位置を示すＵＲＩを識別する。

受信機は、ａｔｓｃＳｄｐＵｒｉ情報を用いてＡＴＳＣＳＤＰを取得し、ＡＴＳＣＳＤＰ内の情報を用いてＲＯＵＴＥセッションに接近したり、ＲＯＵＴＥセッションを通じて伝送されるＬＳＩＤに接近し、放送サービスを構成するコンポーネント（ビデオコンポーネント及び／又はオーディオコンポーネント）を取得することができる。

受信機は、ｆｕｌｌＭｐｄＵｒｉ情報を用いてフルＭＰＤを取得し、フルＭＰＤで各コンポーネントを表出するための情報を取得することができる。例えば、オーディオ／ビデオコンポーネントに含まれる各セグメントを整列するための情報、各コンポーネント間の同期のための情報などをフルＭＰＤに含ませることができる。

フルＭＰＤは、放送を介して提供されるアプリケーションサービス、ユニキャストアプリケーションサービス及び／又は次世代放送用アプリケーションサービスを表出するための情報を含むことができる。

図４７は、本発明の一実施例に係る、第３シグナリング方法と第４シグナリング方法とを比較した図表を示した図である。

ＳＤＰ内で記述されるＲＯＵＴＥセッションの個数は、第３シグナリング方法によれば１個に該当するが、第４シグナリング方法によれば複数個になり得る。

受信機が放送サービスに含まれるデータを取得するために使用するシグナリング構造は、第３シグナリング方法によればＵＳＤ、ＭＰＤ、ＬＳＩＤになり、第４シグナリング方法によればＳＰＤ、ＭＰＤ、ＬＳＩＤになる。第３シグナリング方法において、ＵＳＤ内のａｔｓｃＳｅｒｖｉｃｅＩｄは、ＦＩＣ内のＳｅｒｖｉｃｅ＿ｉｄとのマッピングのために使用することができる。すなわち、受信機は、ＦＩＣのｓｅｒｖｉｃｅ＿ｉｄの値と同一の値を有するａｔｓｃＳｅｒｖｉｃｅＩｄ情報を探し、該当のａｔｓｃＳｅｒｖｉｃｅＩｄ情報のために提供される下位情報を用いて、ＦＩＣのｓｅｒｖｉｃｅ＿Ｉｄによって識別される放送サービスに接近することができる。一方、ＵＳＤに含まれるｓｅｒｖｉｃｅＩｄは、放送サービスのために提供されるＥＳＧに受信機が接近するのに使用される。すなわち、受信機は、ＵＳＤ内のｓｅｒｖｉｃｅＩｄと同一の値を有する＠ｇｌｏｂａｌＳｅｒｖｉｃｅＩＤによって提供されるＥＳＧに接近し、該当放送サービスに対するＥＳＧを取得することができる。

第３シグナリング方法において、フルＭＰＤは放送サービス（ＡＴＳＣ３．０）のために使用し、ｅＭＢＭＳＭＰＤはｅＭＢＭＳのために使用し、ＡｐｐＳｖｃＭＰＤはアプリケーションサービスのために使用することができる。一方、第４シグナリング方法において、ｅＭＢＭＳＭＰＤはｅＭＢＭＳのために使用し、ＡｐｐＳｖｃＭＰＤはアプリケーションサービスのために使用できるが、フルＭＰＤは使用しない場合がある。

第３シグナリング方法において、ＳＰＤは、放送サービスと関連するデータが伝送されるソースＩＰ住所（ＳｏｕｒｃｅＩＰａｄｄｒｅｓｓ）に関する情報を提供する。

第３シグナリング方法では、放送サービスと関連するデータを伝送するデータパイプは、ＵＳＤ又はＬＳＩＤに含まれるＤＰ＿ｉｄ情報を通じて識別できるが、第４シグナリング方法ではＳＤＰに含まれるＤＰ＿ｉｄを通じて識別することができる。

図４８は、本発明の一実施例に係る、ｅＭＢＭＳ放送とブロードバンドを介してサービスが提供される過程を示した図である。

ｅＭＢＭＳ放送を介して、ＵＨＤビデオ、ＨＤビデオ及び／又はオーディオサービス／コンポーネントを受信機に伝達することができる。ブロードバンドを介して、第２オーディオサービス／コンポーネント（例えば、オーディオサービスと異なる言語で提供されるオーディオサービス／コンポーネント）を受信機に伝達することができる。

上記のシナリオにおいて、受信機は、ＵＳＤに含まれるｂｒｏａｄｃａｓｔＡｐｐＳｅｒｖｉｃｅのための情報であるｅＭＢＭＳＭＰＤ及び／又は３ＧＰＰＳＤＰを用いて、ＵＨＤビデオ、ＨＤビデオ及び／又はオーディオサービス／コンポーネントに接近することができる。受信機は、ＵＳＤに含まれるｕｎｉｃａｓｔＡｐｐＳｅｒｖｉｃｅのための情報であるＡｐｐＳｖｃＭＰＤを用いて第２オーディオサービス／コンポーネントに接近することができる。

受信機は、ＵＳＤ内のｂｒｏａｄｃａｓｔＡｐｐＳｅｒｖｉｃｅエレメントで提供されるｂａｓｅＰａｔｔｅｒｎ１情報を通じてＵＨＤビデオサービス／コンポーネントが提供される位置の基本ＵＲＬ（ｂａｓｅＵＲＬ１）を取得することができ、ｂａｓｅＰａｔｔｅｒｎ２情報を通じてＨＤビデオサービス／コンポーネントが提供される位置の基本ＵＲＬ（ｂａｓｅＵＲＬ２）を取得することができ、ｂａｓｅＰａｔｔｅｒｎ３情報を通じてオーディオサービス／コンポーネントが提供される位置の基本ＵＲＬ（ｂａｓｅＵＲＬ３）を取得することができる。受信機は、ＵＳＤ内のｕｎｉｃａｓｔＡｐｐＳｅｒｖｉｃｅエレメントで提供されるｂａｓｅＰａｔｔｅｒｎ４情報を通じて、第２オーディオサービス／コンポーネントが提供される位置の基本ＵＲＬ（ｂａｓｅＵＲＬ４）を取得することができる。

受信機は、ｅＭＢＭＳＭＰＤ内の情報とｂａｓｅＰａｔｔｅｒｎ１、ｂａｓｅＰａｔｔｅｒｎ２及びｂａｓｅＰａｔｔｅｒｎ３を組み合わせ、ＵＨＤビデオサービス／コンポーネント、ＨＤビデオサービス／コンポーネント及び／又はオーディオサービス／コンポーネントを取得するためのＵＲＬ情報を決定することができる。

受信機は、ＡｐｐＳｖｃＭＰＤ内の情報とｂａｓｅＰａｔｔｅｒｎ４とを組み合わせ、第２オーディオサービス／コンポーネントを取得するためのＵＲＬ情報を決定することができる。

図４９は、本発明の一実施例に係る、ＡＴＳＣ放送とブロードバンドを介してサービスが提供される過程を示した図である。

ＡＴＳＣ放送を介して、ＵＨＤビデオ、ＨＤビデオ及び／又はオーディオサービス／コンポーネントを受信機に伝達することができる。ブロードバンドを介して、第２オーディオサービス／コンポーネント（例えば、オーディオサービスと異なる言語で提供されるオーディオサービス／コンポーネント）を受信機に伝達することができる。ＵＨＤビデオ、ＨＤビデオ及び／又はオーディオサービス／コンポーネントは、特定データパイプを介して伝送することができる。

上記のシナリオにおいて、受信機は、ＵＳＤに含まれるａｔｓｃＢｒｏａｄｃａｓｔＡｐｐＳｅｒｖｉｃｅのための情報であるフルＭＰＤ及び／又はＡＴＳＣＡＤＰを用いてＵＨＤビデオ、ＨＤビデオ及び／又はオーディオサービス／コンポーネントに接近することができる。受信機は、ＵＳＤに含まれるｕｎｉｃａｓｔＡｐｐＳｅｒｖｉｃｅのための情報であるフルＭＰＤ及び／又はＡｐｐＳｖｃＭＰＤを用いて第２オーディオサービス／コンポーネントに接近することができる。

受信機は、ＵＳＤ内のａｔｓｃＡｐｐＳｅｒｖｉｃｅエレメントで提供されるｂａｓｅＰａｔｔｅｒｎ１情報を通じてＵＨＤビデオサービス／コンポーネントが提供される位置の基本ＵＲＬ（ｂａｓｅＵＲＬ１）を取得することができ、ｂａｓｅＰａｔｔｅｒｎ２情報を通じてＨＤビデオサービス／コンポーネントが提供される位置の基本ＵＲＬ（ｂａｓｅＵＲＬ２）を取得することができ、ｂａｓｅＰａｔｔｅｒｎ３情報を通じてオーディオサービス／コンポーネントが提供される位置の基本ＵＲＬ（ｂａｓｅＵＲＬ３）を取得することができる。受信機は、ＵＳＤ内のｕｎｉｃａｓｔＡｐｐＳｅｒｖｉｃｅエレメントで提供されるｂａｓｅＰａｔｔｅｒｎ４情報を通じて、第２オーディオサービス／コンポーネントが提供される位置の基本ＵＲＬ（ｂａｓｅＵＲＬ４）を取得することができる。

受信機は、フルＭＰＤ内の情報とｂａｓｅＰａｔｔｅｒｎ１、ｂａｓｅＰａｔｔｅｒｎ２、ｂａｓｅＰａｔｔｅｒｎ３及びｂａｓｅＰａｔｔｅｒｎ４とを組み合わせ、ＵＨＤビデオサービス／コンポーネント、ＨＤビデオサービス／コンポーネント、オーディオサービス／コンポーネント及び／又は第２オーディオサービス／コンポーネントを取得するためのＵＲＬ情報を決定することができる。

図５０は、本発明の一実施例に係る、ＡＴＳＣ放送、ｅＭＢＭＳ放送及びブロードバンドを介してサービスが提供される過程を示した図である。

ｅＭＢＭＳ放送を介して、ＵＨＤビデオサービス／コンポーネントを受信機に伝達することができる。ＡＴＳＣ放送を介して、ＨＤビデオ及び／又はオーディオサービス／コンポーネントを受信機に伝達することができる。ブロードバンドを介して、第２オーディオサービス／コンポーネント（例えば、オーディオサービスと異なる言語で提供されるオーディオサービス／コンポーネント）を受信機に伝達することができる。ＨＤビデオ及び／又はオーディオサービス／コンポーネントは特定データパイプを介して伝送することができる。

受信機は、ＵＳＤに含まれるｂｒｏａｄｃａｓｔＡｐｐＳｅｒｖｉｃｅのための情報であるｅＭＢＭＳＭＰＤ及び／又は３ＧＰＰＳＤＰを用いてＵＨＤビデオサービス／コンポーネントに接近することができる。

受信機は、ＵＳＤに含まれるａｔｓｃＢｒｏａｄｃａｓｔＡｐｐＳｅｒｖｉｃｅのための情報であるフルＭＰＤ及び／又はＡＴＳＣＡＤＰを用いてＨＤビデオ及び／又はオーディオサービス／コンポーネントに接近することができる。受信機は、ＵＳＤに含まれるｕｎｉｃａｓｔＡｐｐＳｅｒｖｉｃｅのための情報であるフルＭＰＤ及び／又はＡｐｐＳｖｃＭＰＤを用いて第２オーディオサービス／コンポーネントに接近することができる。

受信機は、ＵＳＤ内のｂｒｏａｄｃａｓｔＡｐｐＳｅｒｖｉｃｅエレメントで提供されるｂａｓｅＰａｔｔｅｒｎ１情報を通じてＵＨＤビデオサービス／コンポーネントが提供される位置の基本ＵＲＬ（ｂａｓｅＵＲＬ１）を取得することができ、ＵＳＤ内のａｔｓｃＢｒｏａｄｃａｓｔＡｐｐＳｅｒｖｉｃｅエレメントで提供されるｂａｓｅＰａｔｔｅｒｎ２情報を通じてＨＤビデオサービス／コンポーネントが提供される位置の基本ＵＲＬ（ｂａｓｅＵＲＬ２）を取得することができ、ＵＳＤ内のａｔｓｃＢｒｏａｄｃａｓｔＡｐｐＳｅｒｖｉｃｅエレメントで提供されるｂａｓｅＰａｔｔｅｒｎ３情報を通じてオーディオサービス／コンポーネントが提供される位置の基本ＵＲＬ（ｂａｓｅＵＲＬ３）を取得することができる。受信機は、ＵＳＤ内のｕｎｉｃａｓｔＡｐｐＳｅｒｖｉｃｅエレメントで提供されるｂａｓｅＰａｔｔｅｒｎ４情報を通じて、第２オーディオサービス／コンポーネントが提供される位置の基本ＵＲＬ（ｂａｓｅＵＲＬ４）を取得することができる。

受信機は、ｅＭＢＭＳＭＰＤ内の情報とｂａｓｅＰａｔｔｅｒｎ１とを組み合わせ、ＵＨＤビデオサービス／コンポーネントを取得するためのＵＲＬ情報を決定することができる。

図５１は、本発明の一実施例に係るシグナリング体系を用いて、受信機が放送サービスを取得する過程を示した図である。

受信機は、放送ストリーム（ＢｒｏａｄｃａｓｔＳｔｒｅａｍ；ｂｓ−１）を受信する。受信した放送ストリームはＦＩＣ及び／又はデータパイプ（ｄｐ−１）を含む。データパイプは、一つ又はそれ以上のＩＰ住所（ｉｐ−１／ｓｉｐ−１)及び／又はＵＤＰ番号（ｕｄｐ−１）を通じて伝送することができる。データパイプは一つ以上のＬＣＴセッションを含むことができる。それぞれのＬＣＴセッションは、一つのコンポーネントを伝送することができる。コンポーネントは、一つ以上のセグメントを含むことができ、各セグメントはＬＣＴセッションを通じて伝送される。すなわち、データパイプは、シグナリング情報を含むシグナリングフラグメントを伝送する伝送セッション、オーディオコンポーネントのためのオーディオセグメントを伝送する伝送セッション及び／又はビデオコンポーネントのためのビデオセグメントを伝送する伝送セッションを含むことができる。

受信機は、放送ストリームの特定位置（特定ＩＰ住所及び／又はＵＤＰ番号を通じて伝送されるデータ）でＦＩＣを取得することができる。

ＦＩＣは、ｓｅｒｖｉｃｅ＿ｉｄ情報、ＳＳＣ＿ｓｒｃ＿ＩＰ＿ａｄｄｒｅｓｓ情報、ＳＳＣ＿ｄｓｔ＿ＩＰ＿ａｄｄｒｅｓｓ情報、ＳＳＣ＿ｄｓｔ＿ＵＤＰ＿ｐｏｒｔ情報、ＳＳＣ＿ｔｓｉ情報及び／又はＳＳＣ＿ＤＰ＿ｉｄ情報を含むことができる。

ｓｅｒｖｉｃｅ＿ｉｄ情報は、放送サービスを識別する情報である。

ＳＳＣ＿ｓｒｃ＿ＩＰ＿ａｄｄｒｅｓｓ情報は、ＳＳＣが伝送されるソース（Ｓｏｕｒｅｃｅ）ＩＰ住所を示す情報である。ＳＳＣ＿ｓｒｃ＿ＩＰ＿ａｄｄｒｅｓｓ情報は、ｓｅｒｖｉｃｅ＿ｉｄによって識別された放送サービスのためのＳＳＣが伝送される位置を識別する情報に該当する。

ＳＳＣ＿ｄｓｔ＿ＩＰ＿ａｄｄｒｅｓｓ情報は、ＳＳＣが伝送される目的地（Ｄｅｓｔｉｎａｔｉｏｎ）ＩＰ住所を示す情報である。ＳＳＣ＿ｄｓｔ＿ＩＰ＿ａｄｄｒｅｓｓ情報は、ｓｅｒｖｉｃｅ＿ｉｄによって識別された放送サービスのためのＳＳＣが伝送される位置を識別する情報に該当する。

ＳＳＣ＿ｄｓｔ＿ＵＤＰ＿ｐｏｒｔ情報は、ＳＳＣが伝送される目的地（Ｄｅｓｔｉｎａｔｉｏｎ）ＵＤＰ番号を示す情報である。ＳＳＣ＿ｄｓｔ＿ＵＤＰ＿ｐｏｒｔ情報は、ｓｅｒｖｉｃｅ＿ｉｄによって識別された放送サービスのためのＳＳＣが伝送される位置を識別する情報に該当する。

ＳＳＣ＿ｔｓｉ情報は、ＳＳＣを伝送する伝送セッション（ｔｒａｎｓｐｏｒｔｓｅｓｓｉｏｎ）を識別する情報である。ＳＳＣは、固定された、特定ｔｓｉの値を有する伝送セッションを通じて伝送することができる。例えば、ｔｓｉの値が「０」である伝送セッションは、ＳＳＣを伝送する伝送セッションに固定することができる。

ＳＳＣ＿ＤＰ＿ｉｄ情報は、ＳＳＣを伝送するデータパイプを識別する情報である。

受信機は、ＦＩＣに含まれた上述した一つ以上の情報を用いて、シグナリングフラグメントを伝送する伝送セッションに接近し、放送サービスを記述する情報（ＳＳＣ）を取得することができる。

受信機は、ＳＳＣでＡＴＳＣＵＳＤを取得し、ＡＴＳＣＵＳＤに含まれた情報を用いて、受信機が望む放送サービスに対するフルＭＰＤを提供する位置を探すことができる。受信機は、該当位置でＭＰＤを取得する。受信機は、ＭＰＤに含まれた情報を用いて、放送サービス／コンテンツに含まれる各コンポーネントを伝送する位置を探すことができ、該当位置でそれぞれのコンポーネントを取得する。

上述した過程で、ＡＴＳＣＵＳＤは、＠ａｔｓｃＳｅｒｖｃｉｅＩｄによって識別される放送サービスに含まれる各コンポーネントを取得するのに使用される基本住所に該当するｂａｓｅＰａｔｔｅｒｎ情報を含むことができる。ＭＰＤは、該当のｂａｓｅＰａｔｔｅｒｎ情報を基本ＵＲＬ（ＢａｓｅＵＲＬ）として使用することができる。

受信機は、ＭＰＤに含まれるＢａｓｅＵＲＬ情報と、コンポーネントに該当するデータユニットである、リプリゼンテーション（Ｒｅｐｒｅｓｅｎｔａｔｉｏｎ）を識別する情報を取得する。すなわち、受信機は、放送サービスを構成するそれぞれのコンポーネントに該当するリプレゼンテーションを識別するリプレゼンテーション情報を取得することができる。受信機は、ＬＳＩＤに含まれた情報を用いて、リプレゼンテーション情報によって識別されるリプレゼンテーションを伝送する伝送セッションに接近することができる。受信機は、該当の伝送セッションで、それぞれのコンポーネント又はセグメントを取得することができる。

図５２は、本発明の一実施例に係るシグナリング体系を用いて、受信機が放送網とブロードバンドを介して提供される放送サービスを取得する過程を示した図である。

受信機が放送ストリームで、ＦＩＣを通じてＳＳＣに接近する過程は上述した通りである。

本実施例では、上述した実施例に加えて、受信機が第２オーディオコンポーネントをさらに取得する過程を含むことができる。第２オーディオコンポーネントは、ブロードバンド網を介して提供することができる。

ＡＴＳＣＵＳＤは、ブロードバンドで伝送される第２オーディオコンポーネントが存在することを示す情報及び／又は第２オーディオコンポーネントが伝送される位置の基本住所を示す情報を含むことができる。

ＭＰＤは、第２オーディオコンポーネントに含まれるセグメントが提供される住所を示すセグメント住所情報（ｓｅｇｍｅｎｔＵＲＬｓ）を含むことができ、受信機は、セグメント住所情報が示す位置で、第２オーディオコンポーネントに含まれるセグメントを取得することができる。第２オーディオコンポーネントのセグメントが提供される住所は、第２オーディオコンポーネントが伝送される位置の基本住所を示す情報とセグメント住所情報との組合せで識別することができる。

ＳＳＣはＳＤＰをさらに含むことができ、ＡＴＳＣＵＳＤは、ＳＤＰが提供される位置を識別する情報（＠ａｔｓｃＳｄｐＵｒｉ）を含むことができる。

受信機は、ＳＤＰに含まれるｒｏｕｔｅ−ｔｓｉ情報を用いてＬＳＩＤに接近することができる。ｒｏｕｔｅ−ｔｓｉ情報は、ＬＳＩＤを伝送する伝送セッションを識別する情報に該当し得る。

図５３は、本発明の一実施例に係るシグナリング体系を用いて、レイヤードコーディング（ｌａｙｅｒｄｃｏｄｉｎｇ）が放送サービスに適用された場合、受信機が放送サービスを取得する過程を示した図である。

レイヤードコーディングが適用されると、放送サービスに含まれる一つ以上のコンポーネントは、基本形態のコンポーネント及びエンハンスド（ｅｎｈａｎｃｅｄ）形態のコンポーネントを含むことができる。例えば、同一の放送サービス／コンテンツのために、ＨＤ画質のビデオを提供するコンポーネントを基本形態のコンポーネントとして提供し、該当のビデオをＵＨＤ画質にレンダリングするのに必要なデータを提供するコンポーネントをエンハンスド形態のコンポーネントとして提供することができる。

受信機は、ＳＳＣでＡＴＳＣＵＳＤを取得し、ＡＴＳＣＵＳＤに含まれた情報を用いて、受信機が望む放送サービスに対するフルＭＰＤを提供する位置を探すことができる。受信機は、該当位置でＭＰＤを取得する。受信機は、ＭＰＤに含まれた情報を用いて、放送サービス／コンテンツに含まれるコンポーネントを伝送する位置を探すことができ、該当位置において、それぞれのコンポーネントを取得する。ＭＰＤは、一つのコンポーネントに対して、二つ以上のリプリゼンテーションが存在することを示すことができ、それぞれのリプレゼンテーションを識別する情報を含むことができる。二つ以上のリプリゼンテーションは、基本形態のコンポーネントとエンハンスド（ｅｎｈａｎｃｅｄ）形態のコンポーネントに該当し得る。

上述した過程で、ＡＴＳＣＵＳＤは＠ａｔｓｃＳｅｒｖｃｉｅＩｄによって識別される放送サービスに含まれるコンポーネントを取得するのに使用される基本住所に該当するｂａｓｅＰａｔｔｅｒｎ情報を含むことができる。ＭＰＤは、該当のｂａｓｅＰａｔｔｅｒｎ情報を基本ＵＲＬ（ＢａｓｅＵＲＬ）として使用することができる。

受信機は、ＭＰＤに含まれるＢａｓｅＵＲＬ情報と、コンポーネントに該当するデータユニットである、リプリゼンテーションを識別する情報を取得する。すなわち、受信機は、放送サービスを構成するそれぞれのコンポーネントに該当するリプレゼンテーションを識別するリプレゼンテーション情報を取得することができる。受信機は、ＬＳＩＤに含まれた情報を用いて、リプレゼンテーション情報によって識別されるリプレゼンテーションを伝送する伝送セッションに接近することができる。受信機は、該当の伝送セッションにおいて、それぞれのコンポーネント又はセグメントを取得することができる。

図５４は、本発明の一実施例に係るシグナリング体系を用いて、放送サービス／コンテンツの一つの要素に対して複数のコンポーネントが提供される場合、受信機が放送サービスを取得する過程を示した図である。

放送サービス／コンテンツの要素（オーディオ又はビデオなど）に対して一つ以上のコンポーネントを提供することができる。同一の要素に対して一つ以上のコンポーネントが存在する場合、それぞれのコンポーネントは異なる品質や異なる属性を有するデータを含むことができる。例えば、ビデオ要素に対して２個のコンポーネントを提供することができ、そのうち一つのコンポーネントはＨＤ画質のビデオデータを含み、他の一つのコンポーネントはＵＨＤ画質のビデオデータを含むことができる。これらのコンポーネントは、放送システムで同時に提供することができ、視聴者（受信機）の選択によって、視聴者はＨＤ画質又はＵＨＤ画質のビデオを選択的に視聴することができる。

受信機は、ＳＳＣでＡＴＳＣＵＳＤを取得し、ＡＴＳＣＵＳＤに含まれた情報を用いて、受信機が望む放送サービスに対するフルＭＰＤを提供する位置を探すことができる。受信機は、該当の位置でＭＰＤを取得する。受信機は、ＭＰＤに含まれた情報を用いて、放送サービス／コンテンツに含まれる各コンポーネントを伝送する位置を探すことができ、該当の位置で、それぞれのコンポーネントを取得する。ＭＰＤは、放送サービス／コンテンツの一つの要素に対して、二つ以上のリプリゼンテーションが存在することを示すことができ、それぞれのリプレゼンテーションを識別する情報を含むことができる。

図５５は、本発明の一実施例に係る、サービスマップテーブル（ＳｅｒｖｉｃｅＭａｐＴａｂｌｅ；ＳＭＴ）を示した図である。

本発明で提示するＳＭＴは、放送サービスに対する属性情報を提供するシグナリング構造である。ＳＭＴは、サービスレベルシグナリング（又は、ＳＳＣ）に含ませることができる。シグナリング方法によって、ＳＭＴで説明される情報はＵＳＤに含ませることもできる。すなわち、ＳＭＴはＵＳＤと類似する役割をすることもできる。

本発明の一実施例に係るＳＭＴは、＠ｐｒｏｔｏｃｏｌＶｅｒｓｉｏｎ情報、＠ａｔｓｃＳｅｒｖｉｃｅＩｄ情報、＠ｇｌｏｂａｌＳｅｒｖｉｃｅＩｄ情報、＠ｓｅｒｖｉｃｅＬａｎｇｕａｇｅ情報、ｆｕｌｌＭｐｄＵｒｉエレメント、Ｃａｐａｂｉｌｉｔｉｅｓエレメント、ＴａｒｇｅｔｉｎｇＰｒｏｐｅｒｔｉｅｓエレメント、ＣｏｎｔｅｎｔＡｄｖｉｓｏｒｙＲａｔｉｎｇエレメント、ＰｒｏｇｒａｍＴｉｔｌｅエレメント、ａｔｓｃＢｒｏａｄｃａｓｔＡｐｐＳｅｒｖｉｃｅエレメント、ｃｏｍｐｏｎｅｎｔエレメント、ｂａｓｅＰａｔｔｅｒｎエレメント、＠ＤＰ＿ＩＤ情報、＠ＢｒｏａｄｃａｓｔＩＤ情報、＠ＩＰＡｄｄｒｅｓｓ情報、＠ＵＤＰＰｏｒｔ情報、＠ＴＳＩ情報、ａｔｓｃＳｄｐＵＲＩエレメント、ａｔｓｃＵｎｉｃａｓｔＡｐｐＳｅｒｖｉｃｅエレメント、及び／又はｂａｓｅＰａｔｔｅｒｎエレメントを含むことができる。

＠ｐｒｏｔｏｃｏｌＶｅｒｓｉｏｎ情報は、ＳＭＴのプロトコルのバージョンを示す。

＠ａｔｓｃＳｅｒｖｉｃｅＩｄ情報は、サービスエントリに対するレファレンスである。該当の属性の値は、該当のエントリに割り当てられたｓｅｒｖｉｃｅＩｄの値と同一であり得る。＠ａｔｓｃＳｅｒｖｉｃｅＩｄ情報は、放送サービスを識別する情報に該当し得る。

＠ｇｌｏｂａｌＳｅｒｖｉｃｅＩｄ情報は、放送サービスを識別する、全世界的に唯一のＵＲＩであり得る。該当のパラメータは、ＥＳＧデータ（Ｓｅｒｖｉｃｅ＠ｇｌｏｂａｌＳｅｒｖｉｃｅＩＤ）と関連させるのに使用することができる。

＠ｓｅｒｖｉｃｅＬａｎｇｕａｇｅ情報は、サービスの利用可能な言語を示すことができる。言語は、ＸＭＬデータタイプによって特定することができる。

ｆｕｌｌＭｐｄＵｒｉエレメントは、ブロードキャスト上で選択的に、また、ブロードバンド上で伝達されるサービスのコンテンツコンポーネントに対する記述を含むＭＰＤ分割を参照することができる。ｆｕｌｌＭｐｄＵｒｉエレメントは、フルＭＰＤが提供される位置のＵＲＩを示すことができる。ｆｕｌｌＭｐｄＵｒｉエレメントはフルＭＰＤを含むこともできる。

Ｃａｐａｂｉｌｉｔｉｅｓエレメントは、受信機が該当サービスのコンテンツの有意義なプレゼンテーションを生成できるように要求される能力を特定することができる。実施例によって、本フィールドは、既に定義された能力グループを特定することもできる。ここで、能力グループは、有意義なプレゼンテーションのための能力属性値のグループであり得る。本フィールドは実施例によって省略可能である。

ＴａｒｇｅｔｉｎｇＰｒｏｐｅｒｔｉｅｓエレメントは、視聴ターゲッティングのためのデータ及び／又は情報を含むことができる。視聴ターゲッティングは、特定視聴者に特定放送サービス／コンテンツを提供しようとする方式である。

ｃｏｎｔｅｎｔａｄｖｉｓｏｒｙｒａｔｉｎｇエレメントは、視聴制限と関連したデータ及び／又は情報を含むことができる。

ＰｒｏｇｒａｍＴｉｔｌｅエレメントは、放送サービス／コンテンツのプログラム題目を示す情報である。

ａｔｓｃＢｒｏａｄｃａｓｔＡｐｐＳｅｒｖｉｃｅエレメントは、放送網を介して伝送されるアプリケーションサービスと関連するデータ及び／又は情報を含むことができる。ａｔｓｃＢｒｏａｄｃａｓｔＡｐｐＳｅｒｖｉｃｅエレメントは、所属したメディアプレゼンテーションの全ての期間にわたってサービスに属する該当のメディアコンポーネントを含む多重化又は非多重化された形態のブロードキャスト上で伝達されるＤＡＳＨリプレゼンテーションであり得る。すなわち、それぞれの本フィールドは、放送網を介して伝達されるＤＡＳＨリプレゼンテーション（ｒｅｐｒｅｓｅｎｔａｔｉｏｎ）を意味することができる。ａｔｓｃＢｒｏａｄｃａｓｔＡｐｐＳｅｒｖｉｃｅエレメントは、ｃｏｍｐｏｎｅｎｔエレメント、ｂａｓｅＰａｔｔｅｒｎエレメント、＠ＤＰ＿ＩＤ情報、＠ＢｒｏａｄｃａｓｔＩＤ情報、＠ＩＰＡｄｄｒｅｓｓ情報、＠ＵＤＰＰｏｒｔ情報、＠ＴＳＩ情報及び／又はａｔｓｃＳｄｐＵＲＩエレメントを含むことができる。

ｃｏｍｐｏｎｅｎｔエレメントは、放送網を介して伝送されるアプリケーションに含まれるコンポーネントに関する情報を含む。ｃｏｍｐｏｎｅｎｔエレメントは、放送網を介して伝送されるアプリケーションを識別する情報を含むことができる。

ｂａｓｅＰａｔｔｅｒｎエレメントは、含まれた期間にペアレントリプレゼンテーションのメディア分割を要求するためにＤＡＳＨクライアントによって使用される分割ＵＲＬの全ての部分に対してマッチされるように受信機によって使用される文字パターンであり得る。マッチは、該当の要求されたメディア分割がブロードキャストトランスポート上で伝達されることを暗示する。それぞれのａｔｓｃＢｒｏａｄｃａｓｔＡｐｐＳｅｒｖｉｃｅエレメントとａｔｓｃＵｎｉｃａｓｔＡｐｐＳｅｒｖｉｃｅエレメントで表現されるＤＡＳＨリプレゼンテーションの伝達を受けることができるＵＲＬ住所において、そのＵＲＬの一部分などは特定のパターンを有することができるが、そのパターンを本フィールドによって記述することができる。この情報を通じて、一定部分のデータに対する区分が可能になる。提示されたデフォルト値は、実施例によって変更可能である。図示した使用（ｕｓｅ）列は、各フィールドに関するものであって、Ｍは必須フィールド、Ｏはオプショナルフィールド、ＯＤはデフォルト値を有するオプショナルフィールド、ＣＭは条件付きの必須のフィールドを意味することができる。０…１〜０…Ｎは、該当フィールドの可能個数を意味することができる。

＠ＤＰ＿ＩＤ情報は、アプリケーションを含むデータパイプを識別する情報である。

＠ＢｒｏａｄｃａｓｔＩＤ情報は、アプリケーションを提供する放送網又は放送社を識別する情報である。

＠ＩＰＡｄｄｒｅｓｓ情報は、アプリケーションに含まれるデータが伝送される位置のＩＰ住所を示す情報である。

＠ＵＤＰＰｏｒｔ情報は、アプリケーションに含まれるデータが伝送される位置のＵＤＰ番号を示す情報である。

＠ＴＳＩ情報は、アプリケーションに含まれるデータを伝送する伝送セッションを識別する情報である。

ａｔｓｃＳｄｐＵＲＩエレメントＡＴＳＣＳＤＰが提供される位置を示すＵＲＩを識別する情報を含むことができる。

ａｔｓｃＵｎｉｃａｓｔＡｐｐＳｅｒｖｉｃｅエレメントは、所属したメディアプレゼンテーションの全ての期間にわたってサービスに属する構成メディアコンテンツコンポーネントを含む多重化又は非多重化された形態のブロードバンド上で伝達されるＤＡＳＨリプレゼンテーションであり得る。すなわち、それぞれの本フィールドは、ブロードバンドを介して伝達されるＤＡＳＨリプレゼンテーションを意味することができる。

図５６は、本発明の一実施例に係るＡＴＳＣＵＳＤを示した図である。

本発明の一実施例に係るＵＳＤは、バンドル（ｂｕｎｄｌｅ）形態で、一つ以上のＵＳＤに含まれる情報を含むことができる。これをＡＴＳＣＢＤ（ＢｕｎｄｌｅＤｅｓｃｒｉｐｔｏｒ）(又はＵＳＢＤ）と命名することができる。

ａｔｓｃＢＤエレメントは、ａｔｓｃＵＳＤエレメントを含むことができる。

ａｔｓｃＵＳＤエレメントは、＠ｐｒｏｔｏｃｏｌＶｅｒｓｉｏｎ情報、＠ａｔｓｃＳｅｒｖｉｃｅＩｄ情報、ｆｕｌｌＭｐｄＵｒｉエレメント、ＣａｐａｂｉｌｉｔｉｅｓＤｅｓｃｒｉｐｔｉｏｎエレメント、ＴａｒｇｅｔｉｎｇＤｅｓｃｒｉｐｔｉｏｎエレメント、ＣｏｎｔｅｎｔＡｄｖｉｓｏｒｙＤｅｓｃｒｉｐｔｉｏｎエレメント、ＰｒｏｇｒａｍＴｉｔｌｅエレメント、ｎａｍｅエレメント、＠ｌａｎｇ情報、ｓｅｒｖｉｃｅＬａｎｇｕａｇｅエレメント、ｆｅａｔｕｒｅエレメント、ｒｅｑｕｉｒｅｄＣａｐａｂｉｌｉｔｉｅｓエレメント、ｄｅｌｉｖｅｒｙＭｅｔｈｏｄエレメント、ｒ７：ｕｎｉｃａｓｔＡｃｃｅｓｓＵＲＩエレメント、ｂａｓｅＰａｔｔｅｒｎエレメント、ｒ８：ａｌｔｅｒｎａｔｉｖｅＡｃｃｅｓｓＤｅｌｉｖｅｒｙエレメント、ｕｎｉｃａｓｔＡｃｃｅｓｓＵＲＩエレメント、ｔｉｍｅＳｈｉｆｔｉｎｇＢｕｆｆｅｒエレメント、ｒ１２：ｂｒｏａｄｃａｓｔＡｐｐＳｅｒｖｉｃｅエレメント、ｓｅｒｖｉｃｅＡｒｅａエレメント、ｒ１２：ｕｎｉｃａｓｔＡｐｐＳｅｒｖｉｃｅエレメント、ａｔｓｃＢｒｏａｄｃａｓｔＡｐｐＳｅｒｖｉｃｅエレメント、ｂａｓｅＰａｔｔｅｒｎエレメント、＠ＤＰ＿ＩＤ情報、＠ＢｒｏａｄｃａｓｔＳｔｒｅａｍＩＤ情報、＠ＩＰＡｄｄｒｅｓｓ情報、＠ＵＤＰＰｏｒｔ情報、＠ＴＳＩ情報、ａｔｓｃＳｄｐＵＲＩエレメント、ａｃｃｅｓｓＧｒｏｕｐＩｄ情報、ａｓｓｏｃｉａｔｅｄＰｒｏｃｅｄｕｒｅＤｅｓｃｒｉｐｔｉｏｎＵＲＩ情報、ｐｒｏｔｅｃｔｉｏｎＤｅｓｃｒｉｐｔｉｏｎＵＲＩ情報、ｓｅｓｓｉｏｎＤｅｓｃｒｉｐｔｉｏｎＵＲＩ情報、及び／又はａｃｃｅｓｓＰｏｉｎｔＮａｍｅ情報を含むことができる。

＠ｐｒｏｔｏｃｏｌＶｅｒｓｉｏｎ情報は、ＵＳＤのプロトコルのバージョンを示す情報である。

＠ａｔｓｃＳｅｒｖｉｃｅＩｄ情報は、放送サービスを識別する情報である。

ｆｕｌｌＭｐｄＵｒｉエレメントは、フルＭＰＤが提供される位置のＵＲＩを示す情報である。

ＣａｐａｂｉｌｉｔｉｅｓＤｅｓｃｒｉｐｔｉｏｎエレメントは、放送サービス／コンテンツを有意義に表出するために、受信機に要求される能力（ｃａｐａｂｉｌｉｔｙ）を識別する情報を含むことができる。

ＴａｒｇｅｔｉｎｇＤｅｓｃｒｉｐｔｉｏｎエレメントは、視聴ターゲッティングのためのデータ及び／又は情報を含むことができる。

ＣｏｎｔｅｎｔＡｄｖｉｓｏｒｙＤｅｓｃｒｉｐｔｉｏｎエレメントは、視聴制限のためのデータ及び／又は情報を含むことができる。

ＰｒｏｇｒａｍＴｉｔｌｅエレメントは、放送プログラムの題目を示す情報を含むことができる。

ｎａｍｅエレメントは、＠ｌａｎｇ情報によって与えられるサービスのネームを示すことができる。ｎａｍｅエレメントは、サービスネームの言語を示す＠ｌａｎｇ情報を含むことができる。言語はＸＭＬデータタイプによって特定することができる。

ｓｅｒｖｉｃｅＬａｎｇｕａｇｅエレメントは、放送サービスが提供される言語を識別する情報を含む。

ｒｅｑｕｉｒｅｄＣａｐａｂｉｌｉｔｉｅｓエレメントは、特定サービスのために要求される受信機の能力を示す情報を含むことができる。

ｆｅａｔｕｒｅエレメントは、放送サービスに含まれる特定サービスを識別する情報を含むことができる。

ｄｅｌｉｖｅｒｙＭｅｔｈｏｄエレメントは、放送サービスが伝達される方法に関するデータ及び／又は情報を含むことができる。

ｒ７：ｕｎｉｃａｓｔＡｃｃｅｓｓＵＲＩエレメントは、ブロードバンドで伝送される放送サービスに接近するためのＵＲＩ情報を含むことができる。

ｂａｓｅＰａｔｔｅｒｎエレメントは、上述したような基本ＵＲＩ情報を含むことができる。

ｒ８：ａｌｔｅｒｎａｔｉｖｅＡｃｃｅｓｓＤｅｌｉｖｅｒｙエレメントは、放送サービスを伝送する代替方法に関するデータ及び／又は情報を含む。

ｕｎｉｃａｓｔＡｃｃｅｓｓＵＲＩエレメントは、代替方法によって伝送される放送サービスがブロードバンドを介して伝送される場合、放送サービスが提供される位置のＵＲＩを示す情報を含む。

ｔｉｍｅＳｈｉｆｔｉｎｇＢｕｆｆｅｒエレメントは、タイムシフティングのためのバッファに関するデータ及び／又は情報を含む。

ｒ１２：ｂｒｏａｄｃａｓｔＡｐｐＳｅｒｖｉｃｅエレメントは、放送網を介して伝送されるアプリケーションサービスに対するデータ及び／又は情報を含む。

ｓｅｒｖｉｃｅＡｒｅａエレメントは、アプリケーションサービスが提供される領域又はアプリケーションサービスのタイプを識別する情報を含むことができる。

ｒ１２：ｕｎｉｃａｓｔＡｐｐＳｅｒｖｉｃｅエレメントは、ブロードバンドを介して伝送されるアプリケーションサービスに関するデータ及び／又は情報を含むことができる。

ａｔｓｃＢｒｏａｄｃａｓｔＡｐｐＳｅｒｖｉｃｅエレメントに対する説明は、上述した説明の通りである。

ｂａｓｅＰａｔｔｅｒｎエレメントに対する説明は、上述した説明の通りである。

＠ＤＰ＿ＩＤ情報に対する説明は、上述した説明の通りである。

＠ＢｒｏａｄｃａｓｔＳｔｒｅａｍＩＤ情報は、アプリケーションサービスを伝送する放送ストリーム（又は放送局）を識別する情報である。

＠ＩＰＡｄｄｒｅｓｓ情報は、アプリケーションサービスが提供される位置のＩＰ住所を示す情報である。

＠ＵＤＰＰｏｒｔ情報に対する説明は、上述した説明の通りである。

＠ＴＳＩ情報に対する説明は、上述した説明の通りである。

ａｔｓｃＳｄｐＵＲＩエレメントに対する説明は、上述した説明の通りである。

ａｃｃｅｓｓＧｒｏｕｐＩｄ情報は、アクセスグループ（ａｃｃｅｓｓｇｒｏｕｐ）を識別する情報である。アクセスグループは、アクセスネットワークのリストを定義する。

ａｓｓｏｃｉａｔｅｄＰｒｏｃｅｄｕｒｅＤｅｓｃｒｉｐｔｉｏｎＵＲＩ情報は、関連するプロシージャ記述（ａｓｓｏｃｉａｔｅｄＰｒｏｃｅｄｕｒｅＤｅｓｃｒｉｐｔｉｏｎ）が提供される位置のＵＲＩを示す情報である。

ｐｒｏｔｅｃｔｉｏｎＤｅｓｃｒｉｐｔｉｏｎＵＲＩ情報は、保護記述（ｐｒｏｔｅｃｔｉｏｎＤｅｓｃｒｉｐｔｉｏｎ）が提供される位置のＵＲＩを示す情報である。

ｓｅｓｓｉｏｎＤｅｓｃｒｉｐｔｉｏｎＵＲＩ情報は、セッション記述（ｓｅｓｓｉｏｎＤｅｓｃｒｉｐｔｉｏｎ）が提供される位置のＵＲＩを示す情報である。

ａｃｃｅｓｓＰｏｉｎｔＮａｍｅ情報は、アクセスポイントのネームを示す情報である。

図５７は、本発明の他の実施例に係る、ａｔｓｃＵＳＤを示した図である。

本発明の他の実施例に係る、放送サービスに接近するための最小限の情報がａｔｓｃＵＳＤに含まれるようにａｔｓｃＵＳＤを定義することができる。

本発明の他の実施例に係るａｔｓｃＵＳＤは、＠ｐｒｏｔｏｃｏｌＶｅｒｓｉｏｎ情報、＠ａｔｓｃＳｅｒｖｉｃｅＩｄ情報、ｆｕｌｌＭｐｄＵｒｉエレメント、ＣａｐａｂｉｌｉｔｉｅｓＤｅｓｃｒｉｐｔｉｏｎ（ＣａｐａｂｉｌｉｔｉｅｓＰｒｏｐｅｒｔｉｅｓ）エレメント、ＴａｒｇｅｔｉｎｇＤｅｓｃｒｉｐｔｉｏｎ（ＴａｒｇｅｔｉｎｇＰｒｏｐｅｒｔｉｅｓ）エレメント、ＣｏｎｔｅｎｔＡｄｖｉｓｏｒｙＤｅｓｃｒｉｐｔｉｏｎ（ＣｏｎｔｅｎｔＡｄｖｉｓｏｒｙＲａｔｉｎｇｓ）エレメント、ＰｒｏｇｒａｍＴｉｔｌｅエレメント、ｄｅｌｉｖｅｒｙＭｅｔｈｏｄエレメント、ｒ１２：ｕｎｉｃａｓｔＡｐｐＳｅｒｖｉｃｅエレメント、ａｔｓｃＢｒｏａｄｃａｓｔＡｐｐＳｅｒｖｉｃｅエレメント、ｂａｓｅＰａｔｔｅｒｎエレメント、＠ＤＰ＿ＩＤ情報、＠ＢｒｏａｄｃａｓｔＳｔｒｅａｍＩＤ情報、＠ＩＰＡｄｄｒｅｓｓ情報、＠ＵＤＰＰｏｒｔ情報、＠ＴＳＩ情報、ａｔｓｃＳｄｐＵＲＩエレメント、ｓｅｒｖｉｃｅＩｄ情報及び／又はｓｖ：ｓｃｈｅｍＶｅｒｓｉｏｎエレメントを含むことができる。

本発明の他の実施例に係る、ａｔｓｃＵＳＤに含まれ得るエレメント及び／又は情報に対する説明は、上述した説明の通りである。

図５８は、本発明の一実施例に係る放送信号を生成処理する方法を示したフローチャートである。

放送送信機は、一つ以上の放送サービスのための放送データをエンコードする（ＪＳ５８０１０）。

放送送信機は、前記一つ以上の放送サービスに対する属性を説明する情報を含む第１レベルシグナリング情報をエンコードする（ＪＳ５８０２０）。

放送送信機は、前記一つ以上の放送サービスをスキャンするための情報を含む第２レベルシグナリング情報をエンコードする（ＪＳ５８０３０）。

放送送信機は、前記放送データ、第１レベルシグナリング情報及び第２レベルシグナリング情報を含む放送信号を生成する（ＪＳ５８０４０）。

第２レベルシグナリング情報は、前記放送信号で既に定められた位置を通じて伝送することができる。

第２レベルシグナリング情報は、第１シグナリング情報を伝送する各パケットのＩＰ住所を識別するＩＰ住所情報、及び前記第１シグナリング情報を含むＰＬＰ（ＰｈｙｓｉｃａｌＬａｙｅｒＰｉｐｅ）を識別するＰＬＰＩＤ情報を含むことができる。

図５９は、本発明の一実施例に係る放送システムを示した図である。

本発明の一実施例に係る放送システムは、放送送信機Ｊ５９１００及び／又は放送受信機Ｊ５９２００を含むことができる。

放送送信機Ｊ５９１００は、放送データエンコーダＪ５９１１０、シグナリングエンコーダＪ５９１２０及び／又は放送信号生成器Ｊ５９１３０を含むことができる。

放送受信機Ｊ５９２００は、放送信号受信部Ｊ５９２１０、プロセッサＪ５９２２０及び／又はディスプレイ部Ｊ５９２３０を含むことができる。

放送データエンコーダＪ５９１１０は、一つ以上の放送サービスのための放送データをエンコードする。

シグナリングエンコーダーＪ５９１２０は、一つ以上の放送サービスに対する属性を説明する情報を含む第１レベルシグナリング情報及び／又は一つ以上の放送サービスをスキャンするための情報を含む第２レベルシグナリング情報をエンコードする。

放送信号生成器Ｊ５９１３０は、放送データ、第１レベルシグナリング情報及び第２レベルシグナリング情報を含む放送信号を生成する。

放送信号受信部Ｊ５９２１０は、一つ以上の放送サービスのための放送データ、前記一つ以上の放送サービスに対する属性を説明する情報を含む第１レベルシグナリング情報、及び前記一つ以上の放送サービスをスキャンするための情報を含む第２レベルシグナリング情報を含む放送信号を受信する。ここで、前記第２レベルシグナリング情報は、前記放送信号で既に定められた位置を通じて伝送され、前記第２レベルシグナリング情報は、前記第１シグナリング情報を伝送する各パケットのＩＰ住所を識別するＩＰ住所情報、及び前記第１シグナリング情報を含むＰＬＰ（ＰｈｙｓｉｃａｌＬａｙｅｒＰｉｐｅ）を識別するＰＬＰＩＤ情報を含むことができる。

プロセッサＪ５９２２０は、放送信号内の既に定められた位置で前記第２レベルシグナリング情報を抽出し、前記第２レベルシグナリング情報に含まれるＩＰ住所情報及びＰＬＰＩＤ情報を用いて前記第１レベルシグナリング情報を抽出し、前記第１レベルシグナリング情報を用いて前記放送サービスを取得し、前記放送サービスを表出するように制御する。

ディスプレイ部Ｊ５９２３０は、放送サービスをディスプレイする。

モジュール又はユニットは、メモリ（又は、記憶ユニット）に記憶された連続した過程を実行するプロセッサであってもよい。前述した実施例に記述された各段階は、ハードウェア／プロセッサによって実行することができる。前述した実施例に記述された各モジュール／ブロック／ユニットは、ハードウェア／プロセッサとして動作することができる。また、本発明が提示する方法はコードとして実現されてもよい。このコードは、プロセッサが読み出し可能な記憶媒体に書き込まれ、よって、装置（ａｐｐａｒａｔｕｓ）が提供するプロセッサによって読み出されてもよい。

説明の便宜のため、各図を区別して説明したが、各図に開示した実施例を組み合わせて新しい実施例として具現するように設計することも可能である。そして、通常の技術者の必要に応じて、以前に説明された実施例を実行するためのプログラムが記録されているコンピュータで読み出し可能な記録媒体を設計することも、本発明の権利範囲に属する。

本発明に係る装置及び方法は、上述した実施例の構成及び方法が限定的に適用されるものではなく、上述した実施例は、様々な変形が可能なように、各実施例の全部又は一部が選択的に組み合わされて構成されてもよい。

一方、本発明が提案する方法を、ネットワークデバイスに具備された、プロセッサが読み出し可能な記録媒体に、プロセッサが読み出し可能なコードとして具現することができる。プロセッサが読み出し可能な記録媒体は、プロセッサによって読み出されるデータが記憶されるいかなる種類の記録装置をも含む。プロセッサが読み出し可能な記録媒体の例には、ＲＯＭ、ＲＡＭ、ＣＤ−ＲＯＭ、磁気テープ、フロッピーディスク、光データ記憶装置などがあり、また、インターネットを介した伝送などのようなキャリアウェーブの形態で具現されるものも含む。また、プロセッサが読み出し可能な記録媒体は、ネットワークで接続されたコンピュータシステムに分散されて、分散方式でプロセッサが読み出し可能なコードが記憶され、実行されてもよい。

また、以上では、本発明の好適な実施例について図示及び説明したが、本発明は、上述した特定の実施例に限定されず、特許請求の範囲で請求する本発明の要旨を逸脱することなく、当該発明の属する技術分野における通常の知識を有する者にとって様々な変形実施が可能であることはもちろんであり、このような変形実施は、本発明の技術的思想や展望から個別的に理解されてはならない。

そして、当該明細書では、物の発明及び方法の発明の両方が説明されており、必要に応じて、両発明の説明は補充的に適用されてもよい。

本発明の思想や範囲内で本発明の様々な変更及び変形が可能であることは当業者にとって明らかである。したがって、本発明は、添付の請求項及びその同等範囲内で提供される本発明の変更及び変形を含むように意図される。

本明細書において、装置の発明も方法の発明も言及されており、装置及び方法の発明に関する説明は互いに補完して適用されてもよい。

様々な実施例が、本発明を実施するための形態において説明されている。

本発明は、一連の放送信号提供分野で利用される。

Claims

放送サービスのための放送データをエンコードするステップと、
前記放送サービスの発見及び取得に関する情報を提供する第１シグナリング情報を生成するステップと、
前記放送サービスの速い取得に関する情報を有する第２シグナリング情報を生成するステップであって、
前記第２シグナリング情報は、前記放送サービスを識別する第１サービス識別子と前記第１シグナリング情報を伝達する伝送セッションを示すブートストラップ情報とを有するステップと、
固定サイズを有する第１物理層シグナリング情報と可変サイズを有する第２物理層シグナリング情報とを有する物理層シグナリング情報をエンコードするステップであって、
前記第１物理層シグナリング情報は、前記第２物理層シグナリング情報の保護に関する前方誤り訂正（ＦＥＣ）タイプを示す情報と前記第２物理層シグナリング情報のサイズを示す情報とを有し、
前記第２物理層シグナリング情報は、前記放送データをデコードするのに必要な情報と前記第２シグナリング情報に関する情報とを有するステップと、
前記エンコードされた放送データ、前記生成された第１シグナリング情報、前記生成された第２シグナリング情報及び前記エンコードされた物理層シグナリング情報を有する放送信号を生成するステップと、を有し、
前記第１シグナリング情報は、第２サービス識別子を有するユーザサービス記述（User Service Description；ＵＳＤ）情報を有し、前記第２サービス識別子は、前記第１サービス識別子と同じ値を有することによって前記第２シグナリング情報における前記放送サービスに関するサービスエントリを参照し、
前記ＵＳＤ情報は、前記放送サービスに関する技術的情報の詳細を記述し、
前記第１シグナリング情報は、メディアプレゼンテーション記述（Media Presentation Description；ＭＰＤ）情報及び伝送セッションインスタンス記述（transport session instance description）情報をさらに有し、
前記伝送セッションインスタンス記述情報は、前記放送サービスの第１コンポーネントを伝達する第１ＬＣＴチャネルを識別する第１伝送セッション識別子（Transport Session Identifier；ＴＳＩ）値を有する、放送信号生成処理方法。
前記ＵＳＤ情報は、第３サービス識別子をさらに有し、
前記第３サービス識別子は、電子サービスガイド（Electronic Service Guide；ＥＳＧ）データとリンクするのに使用される、請求項１に記載の放送信号生成処理方法。
前記第１シグナリング情報は、受信機が前記放送サービスに有される放送コンテンツを示す（present）のに必要な能力を特定する能力情報をさらに有する、請求項１に記載の放送信号生成処理方法。
前記ＵＳＤ情報は、基本的パターン情報をさらに有し、
前記基本的パターン情報は、前記ＭＰＤ情報におけるリソース識別子とマッチさせて識別するのに使用される文字パターンを有する、請求項１に記載の放送信号生成処理方法。
前記伝送セッションインスタンス記述情報は、前記放送サービスの第２コンポーネントを伝達する第２ＬＣＴチャネルを識別する第２ＴＳＩ値をさらに有し、
前記第２コンポーネントは、前記第１コンポーネントと異なるプレゼンテーション能力を有する、請求項１に記載の放送信号生成処理方法。
放送サービスのための放送データと、前記放送サービスの発見及び取得に関する情報を提供する第１シグナリング情報と、前記放送サービスを識別する第１サービス識別子と前記第１シグナリング情報を伝達する伝送セッションを示すブートストラップ情報とを有する第２シグナリング情報と、物理層シグナリング情報と、を有する放送信号を受信するよう構成された放送信号受信部と、
前記放送信号に有される前記物理層シグナリング情報をデコードし、前記放送信号に有される前記第２シグナリング情報をデコードし、前記放送信号に有される前記第１シグナリング情報をデコードし、前記放送信号に有される前記放送データをデコードするよう構成されたプロセッサと、を有し、
前記第２シグナリング情報は、前記放送サービスの速い取得に関する情報を有し、
前記第１シグナリング情報は、第２サービス識別子を有するユーザサービス記述（User Service Description；ＵＳＤ）情報を有し、前記第２サービス識別子は、前記第１サービス識別子と同じ値を有することによって前記第２シグナリング情報における前記放送サービスに関するサービスエントリを参照し、
前記ＵＳＤ情報は、前記放送サービスに関する技術的情報の詳細を記述し、
前記第１シグナリング情報は、メディアプレゼンテーション記述（Media Presentation Description；ＭＰＤ）情報及び伝送セッションインスタンス記述（transport session instance description）情報をさらに有し、
前記伝送セッションインスタンス記述情報は、前記放送サービスの第１コンポーネントを伝達する第１ＬＣＴチャネルを識別する第１伝送セッション識別子（Transport Session Identifier；ＴＳＩ）値を有し、
前記物理層シグナリング情報は、固定サイズを有する第１物理層シグナリング情報と可変サイズを有する第２物理層シグナリング情報とを有し、
前記第１物理層シグナリング情報は、前記第２物理層シグナリング情報の保護に関する前方誤り訂正（ＦＥＣ）タイプを示す情報と前記第２物理層シグナリング情報のサイズを示す情報とを有し、
前記第２物理層シグナリング情報は、前記放送データをデコードするのに必要な情報と前記第２シグナリング情報に関する情報とを有する、受信装置における放送信号受信機。
前記ＵＳＤ情報は、第３サービス識別子をさらに有し、
前記第３サービス識別子は、電子サービスガイド（Electronic Service Guide；ＥＳＧ）データとリンクするのに使用される、請求項６に記載の放送信号受信機。
前記第１シグナリング情報は、受信機が前記放送サービスに有される放送コンテンツを示す（present）のに必要な能力を特定する能力情報をさらに有する、請求項６に記載の放送信号受信機。
前記ＵＳＤ情報は、基本的パターン情報をさらに有し、
前記基本的パターン情報は、前記ＭＰＤ情報におけるリソース識別子とマッチさせて識別するのに使用される文字パターンを有する、請求項６に記載の放送信号受信機。
前記伝送セッションインスタンス記述情報は、前記放送サービスの第２コンポーネントを伝達する第２ＬＣＴチャネルを識別する第２ＴＳＩ値をさらに有し、
前記第２コンポーネントは、前記第１コンポーネントと異なるプレゼンテーション能力を有する、請求項６に記載の放送信号受信機。